軟件測試工作中2個(gè)高難度問(wèn)題的思考

　　首先在我們回顧下這2個(gè)問(wèn)題：

　　問(wèn)題1:如何最大限度的降低需求的變更對測試質(zhì)量的影響?

　　問(wèn)題2:有沒(méi)有什么有效的方法來(lái)降低測試用例的不斷修改率?

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

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

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

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

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

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

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

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

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

　　那總結下解決第一個(gè)問(wèn)題的思路：

　　減少需求變更

　　規范需求文檔

　　與開(kāi)發(fā)及時(shí)溝通需求問(wèn)題

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

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

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

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

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

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

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

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