如何做好回歸測試

　　在總結回歸測試的方法時(shí)發(fā)現，不管?chē)鴥葒?，這都是個(gè)頭疼的話(huà)題。做是要做，也能做，但是從效率角度說(shuō)可是千差萬(wàn)別。給我足夠多的人或是時(shí)間，總是可以保證回歸測試進(jìn)行的徹底，可是那并不是做事情的方法和解決問(wèn)題的手段。我覺(jué)得google的James Whittaker說(shuō)的好“事實(shí)上，有些測試組堅持要保持一個(gè)規模相對比較大的團隊主要是因為他們的假設前提就是有些事情做錯了。這也意味著(zhù)編碼和測試之間的工作失衡。添加更多的測試人員并不能解決任何問(wèn)題。”“In fact, teams that insist on having a large testing presence are generally assumed to be doing something wrong. Having too large a test team is a very strong sign that the code/test mix is out of balance. Adding more testers is not going to solve anything.”當然，google把quality交給developer去own才能將測試人員的工作真正做到是質(zhì)量環(huán)節的最后確保。而不是去檢查developer犯的錯誤。

　　從執行方法的角度看，回歸測試大多要通過(guò)兩種方式去執行：一類(lèi)借助于工具完成的自動(dòng)化測試，一類(lèi)是手動(dòng)完成。從回歸測試的計劃和策略上講，一般有以下兩種方法：

　　一、基于風(fēng)險的

　　這是一個(gè)比較簡(jiǎn)單和常用的方法，顧名思義，就是在分析出改動(dòng)所帶來(lái)的風(fēng)險以后，在易出錯的地方進(jìn)行回歸測試以保證原有的功能沒(méi)有被新的變化影響。這么看，對于新的改動(dòng)的分析風(fēng)險能力很重要。如何準確的獲得風(fēng)險列表呢?

　　· 大家最頭疼的地方，也許就是風(fēng)險所在

　　這可以從以往和dev以及product owner等人的會(huì )議及email的討論中獲得。

　　· 新功能的測試計劃

　　在編寫(xiě)測試用例和寫(xiě)測試計劃的時(shí)候，因為比較系統和全面的了解新功能，所以可以同時(shí)把可能有的風(fēng)險列出來(lái)，以供日后的回歸測試來(lái)進(jìn)行雙重保證。

　　· 商業(yè)價(jià)值

　　說(shuō)白了，就是最賺錢(qián)的地方，客戶(hù)最在意的地方。因為這些地方的一點(diǎn)點(diǎn)小錯誤都可能引來(lái)客戶(hù)的抱怨和不滿(mǎn)，所以這些地方就尤其重要。相反，商業(yè)價(jià)值比較小的地方，有點(diǎn)錯誤也無(wú)傷大雅。那么，測試重點(diǎn)就該有所先后。

　　· 權重計算

　　影響產(chǎn)品質(zhì)量的權重參數很多，我們可以估計和預測的有以下方面：

　　1. 項目架構，包括功能之間的依賴(lài)關(guān)系、功能的復雜度以及需求變更等

　　2. 大小，多少人開(kāi)發(fā)多少人測試

　　3. 開(kāi)發(fā)人員的能力，這個(gè)常常被忽略的因素往往起到很大的作用。我們可以從開(kāi)發(fā)人員的薄弱環(huán)節，或是某個(gè)能力稍差的開(kāi)發(fā)人員做的模塊下手，找到bug是在情理之中的。

　　二、矩陣法

　　這種方法雖然麻煩，但是卻最高效，也是目前看來(lái)最佳的辦法。但是這個(gè)方法的執行需要QA manager有很強的執行能力以及一個(gè)溝通比較通暢的團隊。以下為這種方法執行的具體步驟：

　　· 首先，創(chuàng )建一個(gè)影響回歸的功能\特性矩陣(regression impact matrix)

　　列出所有的特征和功能，例如

原文轉自：http://www.uml.org.cn/Test/20113113.asp