模板
教程
環境
性能
功能
管理
軟件測試工作的三個階段(3)
- 有一套自動化驗收的用例，可以掛接到自動部署之后或者daily build。前提是我們的自動化要足夠的問題，效果才會好。
這個階段除了業務測試的努力，也體現出了QA的價值。這里的QA是指質量管理，有的地方叫SQA，專注在質量度量和研發流程的管理上。
到這個階段，發現事情順了很多，質量也有更大程度的提升，并有改善額趨勢。
第三個階段：推動全面的質量提升
到上面第二個階段，我們發現質量有了一定的提升，但是還是有不少的問題，而且有些問題需要我們把思路和眼界拓寬來看。這里討論的一些東西可能更適合互聯網的產品。
這里列一些我們可以去做的事情，受限于個人的經驗，可能還很片面。
1. 研發流程的梳理
其實在階段2的時候也可能有些團隊已經開始做這樣的事情，因為在分析質量和效率問題的時候，我們發現很多問題不單純是代碼的問題，可能還涉及研發流程的很多方面，比如：
- 需求不清楚
- 跨團隊的配合問題
- 代碼版本管理
- 技術方面的評審和大家的理解
所以整個研發流程的規范和梳理，以及配合對應的需求和版本管理的系統也是非常的必要，實際中發現效果也是比較的明顯。而且還有一點體會，在接手一個很混亂的狀況時，這樣角度的數量和調整比技術方案的引入更重要和切中要點，能從40分到60分，技術是往80分走的過程效果更明顯。
2. 提交測試前后做的一些事情
- 代碼的靜態掃描
這個方法很多的團隊都在做，但是實際的效果似乎差別很多，而且ROI也很難說，不過從方法本身來說還是值得去做的，對測試人員也提出來更高的要求。
- code review
這個開發應該要做，特別是開發間的交叉review，非常的有幫助。不過這個也和自測一樣，取決于開發負責人的態度。另外，測試也應該去做，特別是對于 diff 代碼的review，我們檢查做了大概兩個月的時間，發現還是非常的有收獲。發現了一些黑盒難以發現的問題，以及開發的代碼夾帶，并且對于這個版本影響范圍的評估也更準確。但問題是短期會花費測試更多時間，以及需要測試人員有一定的技術能力。
3. 測試能力的提升
測試階段有很多的事情可以去做，覺得最主要的還是兩個方面
- 自動化。 越來越覺得這個是繞不開的話題，要想盡辦法去做，做得更高效更全面。前面有篇blog也提到了一些輕量級的做法，業務測試的團隊可以參考 http://blog.csdn.net/superqa/article/details/20644285
- 輔助手段，比如代碼覆蓋率，特別是差異的覆蓋率。這個大家都比較容易理解就不展開了。
- 拓展測試的類型
這個方面說起來有些泛，需要結合團隊和業務的情況，比如安全測試，性能測試，兼容性測試等，去發現一些對于產品來說很重要的風險。
這方面有兩個前提，一是我們的基本功能質量到了一個階段，可以讓大家騰出手去拓展測試的面，另一方面我們測試人員的能力要跟得上。
4. 發布環節的質量把控
這個方面和傳統的測試不太一樣，而且了解到不同的組織做法不同，執行發布的人員可能不同，有開發，運維，專職的版本管理或者測試來做。
在我們的實踐中，發布后來都逐步收到測試這邊，回頭來看覺得還是有不少有幫助的地方。當然也不絕對的必須測試來做。
- DO分離，避免了隨意的發布，特別是在開發手上的時候。所有的bugfix都經過測試發布，可以更準確的度量質量(除非這個問題可以不修復，否則肯定要過發布環節)
- 知道最近發了什么，可能的影響是什么，需要線上關注什么。
- 灰度。 互聯網產品常用的一個控制風險和節奏的手段。
- 擴容的快速自動化檢查，這方面也依賴于自動化的建設。
- 發布過程支持灰度的控制，備份和快速的回滾。對發布系統有一定的要求，而且有可追溯性。
原文轉自：http://blog.csdn.net/superqa/article/details/21485737
