回歸測試用例的設計和挑選

　　在我們的軟件開發過程中，只要軟件發生了改動，不管是功能的變更、模塊的增加或者bug的修改，都會對現有的軟件造成影響，也就可能帶來問題。當軟件的 bug被發現提交后，有可能發生以下幾種情況：a、追蹤系統不夠完善，該bug被疏忽沒有得到修改；b、開發對于bug的理解不同，造成修改后的結果與期望仍不一致；c、理解不夠深入，只修改了bug描述的表面現象，深層原因沒有找到； d、bug被修改，但沒有考慮到與此問題關聯的其他模塊；e、本bug被修改，之前被本bug掩蓋的其他錯誤得以顯現出來?；貧w測試正是為了檢查以上情況是否發生，檢驗已經被發現的缺陷有沒有被正確的修改和修改過程中有沒有引發新的缺陷，以確保修改達到了預期的目的。

　　由此我們可以看出進行回歸測試的必要性，但在每一次回歸測試中遍歷所有的用例又是不現實的，特別是在測試后期，所以選擇正確的回歸測試策略來改進回歸測試的效率是非常有意義的，現在就回到我們本次的問題上來。

　　針對上面列出的幾種情況，總結歸納出幾種選取回歸測試用例的方法：1、發現缺陷的用例，這些用例可以驗證發現的缺陷是否得到正確修改，可以完全檢測出上述 a、b中情況，在一定程度上也可以發現c；2、發現缺陷用例所在模塊的其他用例；3、出錯模塊周邊以及與其有聯系模塊的用例，這些模塊的識別可以尋求開發人員的幫助；通過方法2、3，可以基本檢測出c、d；另外，通過執行方法1、2、3選取的用例，也基本可以檢測e的情況。4、軟件的核心用例，這些用例應該在設計測試用例的時候就被定義出，它們體現整個軟件的核心流程、必須實現、完成的重要功能點，回歸測試時執行它們是為了確定本次修改對核心流程和重要功能是否造成影響；5、如果時間、精力、資源允許，可以再執行全部用例，不過一般很難碰到“時間、精力、資源允許”的實際情況。

　　回歸測試一項很重要、但也很費時且重復性很多的活動，同時由于該階段處于后期，也許錯誤都被正確的修復好了、也許沒有引入新缺陷、執行了很多測試用例都沒有再發現新問題（很遺憾，這些情況一般都不會發生），這當然是我們理想的狀態，但也容易給測試人員帶來疲憊感，所以我認為在回歸測試中引用自動化是一項不錯的選擇，這里的自動化主要針對4中描述的軟件核心用例，對于這些每一輪測試都必須執行的用例使用自動化，可以提高不少的效率！

原文轉自：http://www.anti-gravitydesign.com