文章目的
本文是作者在創業公司進行測試過程中，通過對每次迭代測試工作進行總結和改進而提出的一套行之有效的測試分析方法，能通過此方法，在保證可接受的質量前提下，縮小迭代所需的測試范圍，提高測試效率。該方法經過幾次迭代實踐，可操作性強，無難度，能達到事半功倍的效果，特別適合在初創公司（研發流程不規范）實踐。
背景
提出此方法的原因是因為我們的軟件經過半年迭代后，功能相比初期增加了很多功能模塊，功能交互也變得復雜，測試用例從200-300條增長至1000條，在測試人員沒有相應增加的情況下，每次回歸測試（FFT）無法在2-3天之內完成，已經到了通過加班無法解決的狀況，且每次回歸測試后我們發現的缺陷不多，但是確實有嚴重bug和測試的必要性。在不能不做的情況下，我們被迫做出改變，在犧牲一定質量的情況下，提高測試效率，保證產品能按時發布。
回歸缺陷產生的原因
在談如何做回歸測試分析前，先分析一下回歸缺陷產生的原因，熟悉缺陷產生的原因是測試分析的基礎，才能準確的找出缺陷可能產生的地方，從而能準確的找出測試范圍。
這里不談缺陷產生的如下兩個原因，因為這類bug主要在新功能提測的期間產生，回歸測試不應該出現。
1.需求描述不清楚
2.溝通不暢
我認為，在每次的迭代周期里回歸缺陷產生的根本原因只有一個，就是軟件代碼由于某些原因發生了變化，變化的過程中沒有控制好質量引入的。變化的主要原因如下：
1.新需求或者新功能的加入
2. 重構或者缺陷的修改
知道了回歸缺陷產生的原因，那么我們做測試分析，確定測試范圍就要從這兩個變化的主因入手。下面我們就針對這兩個主因來一個一個分析。
對新需求或者新功能做測試分析
這個不多說，步驟如下：
需求分析 -> 測試點 ->測試點審查(review) ->測試用例
1. 根據項目經理發的項目計劃，確定新功能范圍，找到相應需求，對需求進行分析，分析過程中要和產品經理多溝通，多提問
2. 需求分析完之后，提煉測試點，一定要做，通過測試點能清楚的展示測試的思路和脈絡
3. 對測試點進行review，一定要得到開發人員的反饋
4. 最后總結成測試用例
對這一部分分析完之后，所得到的測試用例即可加入回歸的測試范圍。
對重構或者缺陷修改進行測試分析
對重構和缺陷修改進行測試分析從如下兩方面入手：
1. 和開發人員，開發負責人多溝通
2. 總結開發人員的提交改動，根據提交信息和修改文件做測試分析
針對以上兩點，實踐如下：
1. 找到上次發布版本和當前測試版本對應工程的commit號，運行git log —oneline ?commit1..commit2能拿到該工程的所有修改。其他版本管理工具如svn，diff也能夠拿到
2. 拿到修改后，總結成列表，開發人員是不會給我們總結的，自己先做分析，做完分析后，叫上開發一起進行分析。特別是對那些修改變動大的提交要重點分析，這個分析過程是測試一個積累過程，通過3-4次，對軟件代碼的結構，每個文件代表的模塊都會很熟悉，分析的準確率和效率會越來越高。這里可以對開發的提交日志有所要求，比如提交日志包含目的，修改影響范圍兩部分，這樣有助于測試人員進行分析。
3. 做分析的時候要學會引導開發人員，比如要從功能測試，兼容性測試，性能測試，穩定性測試來去引導開發來做確認和分析
這兩方面都做好之后，測試分析也會分析的到位，最后測試范圍很容易也就出來了，測試范圍出來了，測試計劃也就出來了。
