軟體測試心得|我在LinkedIn從事軟體測試工作的體會

01-31

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

我想談談自身的經歷。

我一年前在外包公司工作，客戶是一家美國頂尖公司LinkedIn，產品發展前景挺好，全球最大的職場社交軟體，就連NASA宇航員都是這家公司推薦的。

我想說說他們的測試管理制度。

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

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

第一階段：

需求出來後，開發和測試同步進行，開發完成代碼實現，測試完成

outline

和test

case，這些文檔都會上傳到Wiki上。我們在理解Spec和完成testcase的時候，會及時提出自己的問題，這些問題一般在第二天就能從開發人員

得到反饋。而test outline和test

case最終完成後也要經過開發人員的驗證，有時他們會提出自己的意見，測試要點和一些你未曾想到的case。

第二階段：

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

第三階段：回歸測試。

每

一個版本的下半階段都是做回歸測試，這是一個比較漫長的過程，一般分兩部分，一是執行所有的case（一萬之多，有趕超兩萬之勢），二是執行任意測試。在

執行case的時候，我們還要同時更新case，有些是更新內容，有些是添加新的bug，有些case可能會過時。當然，新的bug也會提交到JIRA。

在這個階段，測試人員會安排在不同的平台上測試。可以說，在做回歸測試的時候，測試覆蓋率極高。

第四階段：預發布版本測試。

做

完回歸測試會形成一個較穩定的版本作為預發布版本，預發布版本會被部署到另一台測試伺服器上。這時候需要在不同平台上做一次QL（Quick

Look）及任意測試。預發布版本上一般不會再遷入changlist，除非在此之上發現了較嚴重的bug，就會有新的r2的預發布版本以及再一次的測

試。

第五階段：內部測試。

新版本發

布前一兩天可以說是全民皆兵，公司里大大小小所有人都進行測試，包括CEO。（當然CEO

不會自己來報bug，她會把問題反饋給我們的技術副總裁）。當然他們所報的bug也會成為我們的談資。作為測試人員，我們不僅追求bug數量，更要追求

bug被fix的概率。當發現一個bug時，首先我們得確定它不會成為wont fix或invalid的問題，並且它can be

reproduced，然後它不會duplicate某個已有的bug，如果這個已有的bug已經被close了，就應該reopen它。而這些非測試部

的人不管三七二十一，看到是個問題的就報，一天下來新加的bug數就該讓相關的開發人員頭疼死了。好在這些問題都會一個個地得到它們應有的解決方式。

第六階段：產品發布測試

產品發布前會在和產品環境相同的伺服器上做一次QL（Quick Look）和任意測試，產品發布後又會在產品伺服器上做一次QL（Quick Look）和任意測試。

第七階段：測試整理

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

值得一提的是，他們有非常強的創新能力和執行能力。也就是說，在測試工作中發現流程或管理問題後，能快速的改變團隊自身，並能夠堅決的執行下去。我覺得這是我們國內大部分互聯網公司極度欠缺的能力，我們總是安於現狀或者照搬現成的東西。

變化才是唯一不變的真理。