軟件測試工作中2個高難度問題的思考

　　首先在我們回顧下這2個問題：

　　問題1:如何最大限度的降低需求的變更對測試質量的影響?

　　問題2:有沒有什么有效的方法來降低測試用例的不斷修改率?

　　記得好像測試用例PK里面也提出這2個問題，而且這些問題對于測試人員在工作過程中也是比較難以解決的，同樣需要不斷的嘗試與探索新的方法與流程來增加問題解決的可能性。其實我覺得這2個問題是有一定的共性，第一個問題解決了，第二個問題也就解決了一大半了。那我就首先談談個人對第一個問題的理解：

　　注意看題目的幾個關鍵詞：一個是“最大限度的降低”，另一個是“需求的變更”。最后一個是“測試質量”。我們要解決好這個問題，必須要很好的理解這個幾個關鍵詞的內在含義。我想并不是所有人都能很好的理解這些術語。

　　那什么叫需求的變更呢?顧名思義就是項目需求發生了變化與修改(先不談什么原因)，對應測試這邊測試需求也就相應的變化。這里可不要忘了一個重要的時間點，那就是一旦PRD評審通過后。其后任何一個時間點，不管是UC設計還是測試設計或是什么，只要需求發生了變化，這都屬于需求的變更。

　　那什么叫測試質量呢?這個概念比較大，一般我們講軟件質量，這個就與我們測試人員的工作職責相關的。而對于測試質量，個人認為包括2大塊，一個是測試各個階段的產出的高質量，一個是測試各個階段的控制的高效性。解釋一下第一個是各個階段的產出的文檔的高質量，這里面包括文檔的規范性，完整性，正確性，統一性。第二個是各個階段的進度控制和項目管理的高效率。包括測試目標以及發現缺陷，甚至是缺陷預防的持續改進等。

　　想必大家都知道需求變更不是個好東西吧，那我們就要想辦法減少需求變更。首先需求變更往往是不可避免的。通常是項目負責人員花費了大量的氣力避免需求變更，可最后需求變更總是會出現。在需求并更發生之前盡量減少需求變更，以將需求變更帶來的風險降低到最低。因此，在需求人員(PD)同用戶代表或用戶部門主管人員接觸時，就應該向他們挑明態度，和他們協商好，特別是應該讓他們清楚軟件的定價應該與軟件的功能相關，以及需求隨意變更所帶來的風險的承擔者應該由客戶和項目開發者共同承擔。簡單說讓客戶明白減少需求變更的重要性后，需求分析人員應該采取合適的方法同客戶交流，幫助他們明確他們的需求。

　　還有一個就是我們要規范需求文檔，需求文檔應該按照一定的格式和規范來寫，而且應該具備完整性、一致性、基線控制、歷史記錄等特性。需求變更發生后，也應該生成相應的文檔，并且這些文檔的書寫也應該采用規范的形式來寫。

　　前面說到得是減少需求變更的方法，這個不是一個人能做到的，是整個項目組成員共同努力的。正如前面所說，需求變更不可避免的會發生，那么當需求變更發生后我們測試人員應該如何應對呢?一般來講，需求的變更通常意味著需求的增加，需求的減少相對很少，而且處理也比較容易。而且發現現在開發人員和PM對需求變更起主導作用，同時需求的變更并不能實時反饋到測試人員。這就需要流程的監控了，之前也

　　說了一旦出現什么樣的需求變更，就相應的走需求變更的流程(相信這里應該充分考慮測試人員的參與度)。充分的與開發人員溝通加上SQA的實時跟蹤也許會減少需求的變更對測試質量的影響。

　　我們說到了對測試質量的影響，那么有哪些呢?一個測試設計與測試用例的文檔的修改;一個是與開發溝通需求變更的成本;再一個是測試人員重復測試執行的成本。另外最關鍵的是由于需求變更帶來的測試覆蓋率的風險，特別是在測試執行后期階段，時間計劃都已經安排的很合理，這時由于需求變更，其影響可想而知。

　　那總結下解決第一個問題的思路：

　　減少需求變更

　　規范需求文檔

　　與開發及時溝通需求問題

　　需求變更流程控制執行到位

　　盡量避免需求變更在測試后期階段(成本大，風險大)

　　及時采取辦法應對需求變更(時間延期，覆蓋率，評估需求變更)

　　至于第二個問題就要搞清楚為什么測試用例需要修改，個人理解大概有這些情況：一個是上面說的由于需求變更，之前根據之前的需求寫的測試用例肯定要修改;一個是由于理解需求有誤導致測試用例本來就寫錯了，但測試用例評審沒有發現問題;另一個是比較小的修改，就是一些測試用例的細節與測試執行時得到的結果描述有偏差(最常見的就是報錯信息內容);最后一個是自己在測試執行時，通過探索性測試發現了bug，而且沒有測試用例，這時就需要增加測試用例。等等。

　　搞清楚了原因，那么我們就可以有針對性的解決測試用例的修改率問題。比如第一個就需要把控需求變更的問題;或延長測試設計的時間，增加需求理解的正確性;還有就是加強測試用例的評審力度和監控力度;多關注測試用例的細節，用例設計時要求開發給出明確的輸出信息。

　　這里同樣的是測試用例的修改也是不可避免的，這樣做的目的就是要做好測試用例的基線，更好的管理和維護測試用例，更好的回歸測試日常需求。更好的加強自己以后在測試設計時思維角度的多變性。

　　以上是自己對這2個問題的理解，其實這2個問題也是在測試領域比較難以量化和解決的，這些解決思路都需要不斷的探索和思考，去不斷的總結，加上自己Team內部管理的一些規范，共同探索出適合自己的解決辦法。

原文轉自：http://blog.sina.com.cn/s/blog_6cf812be0100ngbh.html