在國外做軟件測試工作的體會

　　經常在網上看到有在國內從事軟件測試的同行抱怨：測試不受重視，測試管理混亂，產品質量差等問題。說到底這都是管理上的問題。

　　我想談談自身的經歷。

　　我畢業后在外包公司工作，客戶是一家美國公司，產品發展前景挺好，也有一筆不菲的風險投資。我想說說他們的測試管理制度。

　　首先，他們有一個很好的資源共享平臺，我們叫Wiki，上面包括每一個版本的任務，每一項任務的開發負責人及測試負責人，相關的Spec以及其他開放文檔。而且，每當這一版本的任務快完成時，下一版本的任務的雛形就出來了。

　　其次，開發和測試嚴格按照軟件生命周期執行。

　　第一階段：

　　需求出來后，開發和測試同步進行，開發完成代碼實現，測試完成test outline和test case，這些文檔都會上傳到Wiki上。我們在理解Spec和完成testcase的時候，會及時提出自己的問題，這些問題一般在第二天就能從開發人員得到反饋。而test outline和test case最終完成后也要經過開發人員的驗證，有時他們會提出自己的意見，測試要點和一些你未曾想到的case。

　　第二階段：

　　新功能的測試階段，測試提交bug，開發修改bug，這一過程由JIRA管理。

　　第三階段：

　　回歸測試：

　　每一個版本的下半階段都是做回歸測試，這是一個比較漫長的過程，一般分兩部分，一是執行所有的case(一萬之多，有趕超兩萬之勢)，二是執行任意測試。在執行case的時候，我們還要同時更新case，有些是更新內容，有些是添加新的bug，有些case可能會過時。當然，新的bug也會提交到JIRA。在這個階段，測試人員會安排在不同的平臺上測試?？梢哉f，在做回歸測試的時候，測試覆蓋率極高。

　　第四階段：

　　預發布版本測試：

　　做完回歸測試會形成一個較穩定的版本作為預發布版本，預發布版本會被部署到另一臺測試服務器上。這時候需要在不同平臺上做一次QL(Quick Look)及任意測試。預發布版本上一般不會再遷入changlist，除非在此之上發現了較嚴重的bug，就會有新的r2的預發布版本以及再一次的測試。

　　第五階段：

　　內部測試：

　　新版本發布前一兩天可以說是全民皆兵，公司里大大小小所有人都進行測試，包括CEO。(當然CEO不會自己來報bug，她會把問題反饋給我們的技術副總裁)。當然他們所報的bug也會成為我們的談資。作為測試人員，我們不僅追求bug數量，更要追求bug被fix的概率。當發現一個bug時，首先我們得確定它不會成為won't fix或invalid的問題，并且它can be reproduced，然后它不會duplicate某個已有的bug，如果這個已有的bug已經被close了，就應該reopen它。而這些非測試部的人不管三七二十一，看到是個問題的就報，一天下來新加的bug數就該讓相關的開發人員頭疼死了。好在這些問題都會一個個地得到它們應有的解決方式。

　　第六階段：

　　產品發布測試：

　　產品發布前會在和產品環境相同的服務器上做一次QL(Quick Look)和任意測試，產品發布后又會在產品服務器上做一次QL(Quick Look)和任意測試。

　　第七階段：

　　測試整理：

　　這一階段主要是整理在這一版本生成的測試文檔和測試用例，新功能的用例和一些之前未覆蓋的用例會被導入測試用例管理工具。

　　----------------------------------------------------

　　可以說，以上測試流程都是經過計劃并且嚴格執行的，和大家一起分享，也許你會從中有所收獲。 

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