LinkedIn的軟體測試生命周期

　　如果我們按時交貨,但産品有缺陷,還是證明我們沒有按時傳遞。——Philip Crosby

　　測試生命周期

　　看看在LinkedIn中測試生命周期是什麼樣子的:

　　1.需求收集

　　産品團隊定義了功能需求和設計者建立的線框圖。在設計和産品需求文檔(PRD)被建立後,一切都涉及到整個團隊,包括開發人員和測試工程師。

　　2.測試計劃

　　在生命周期的下一步是對産品或功能的所有測試,進行計劃,包括:

　　建立測試計劃

　　按高、中或低的順序進行優先測試用例,這樣他們可以基于項目的範圍運作

　　舉行一個測試計劃和測試用例評審會議,以確定溝通和充分了解測試範圍

　　3.功能測試

　　新功能測試:浏覽器相容性測試，使用VMWare(Firefox、Safari、Chrome、IE)。

　　A / B測試:我們一步一步來釋出功能。首先釋出到内部組織,然後是公司，是以我們要捕獲所有邊界情況。畢竟錯誤是固定的,我們會慢慢傾斜于我們的使用者。

　　4.自動化

　　5.回歸運作和CI

　　我們建立一個持續內建(CI)在Hudson上運作,開始單元測試運作和自動化的回歸測試用例集。為了一個分支通過“GO”的标準,它必須在上述所有取得成功。

6.釋出分支的建立

　　分支的特性确認合格後,與所有其他功能分支合并釋出。執行回歸測試和功能測試分支的釋出，以確定分支合并之間的相容性。

　　7.部署和測試

　　接着，釋出分支被部署到傳遞的準備環境。執行完整性測試，用不同的措施來保證向後相容的代碼被推為應用程式和服務。所有發現的問題都需要修複以確定順利部署。測試工程師進行最後一輪回歸和特性測試，開發人員需要檢視日志。

　　8.性能測試

　　我們的性能團隊要進行JMeter測試,確定功能可以在工作中正常負載。這些測試在測試環境上運作,1/8th 的生産負荷。

　　9.産品推進

　　我們密切關注代碼，使其生産方式,確定傳遞出去的代碼具有良好的品質。這幾乎是可以慶祝的事。

　　10.監控

　　我們的工作還沒有完成。我們還需要不斷地通過監控日志和實時圖表,以確定一切都順利工作。

　　11.更新檔(如果需要)

　　功能運用生産環境中後,我們的客戶服務團隊、産品團隊和工程師會不斷地從我們的網站會從回報工具中監控到所有客戶的回報。如果有任何問題,我們試圖盡快修複它們。在大多數情況下，會在24小時内修複。這被稱為hotfixing bug。

　　在LinkedIn的測試工作

　　我們的目标是，在LinkedIn中，發揮産品的可用性，提供最優質的産品。作為測試工程師,我可以得到一個良好的睡眠，你要知道在LinkedIn中永遠不會在任何環節對品質進行妥協。

　　Quality is never an accident; It is always the result of intelligent effort. -- John Ruskin

　　品質從來不是偶然的,它總是聰明努力的結果。——約翰·拉斯金

最新内容請見作者的GitHub頁：http://qaseven.github.io/