? ? ? ? 一個完整的軟件測試流程至少包括以下幾個環(huán)節(jié)：

1. 需求評審。在需求評審階段，產(chǎn)品會向開發(fā)、測試等介紹當次迭代的需求，但需求評審除了產(chǎn)品介紹需求外，還有一個重要目的就是評審出需求的優(yōu)先級，砍掉非核心的、設(shè)計有缺陷的需求，對小瑕疵的需求提出建議，明確當次迭代的需求。因此，需求評審階段，作為開發(fā)、測試，也一定要學會向產(chǎn)品問問題，需求評審上問題理得越清楚，實際開發(fā)及后期測試中，問題就會越少。但在不少互聯(lián)網(wǎng)公司中，需求評審?fù)饔谛问剑粋€重要的原因在于需求評審階段，開發(fā)、測試等問的問題不多；而開發(fā)、測試之所以問不出高質(zhì)量的問題，一個重要原因也是因為開發(fā)、測試并沒有去提前閱讀需求文檔。因此，要做好需求評審，一定要提前閱讀需求文檔，批判性地閱讀需求文檔，多問幾個“這樣設(shè)計會不會有邏輯Bug？這個需求有必要嗎？產(chǎn)品文檔寫清楚了嗎？我看懂了嗎？”等問題。然后帶著問題去需求評審會，提出建設(shè)性的建議和意見，解除疑惑，明確需求，我相信這樣會讓需求評審更有價值。

2. 測試需求分析。這也是非常關(guān)鍵的一步，是測試工程師的重要分水嶺。拿到產(chǎn)品需求后，我們要把一個特定的產(chǎn)品需求轉(zhuǎn)換為多個測試需求，再把每個測試需求轉(zhuǎn)換為多個測試點，基于每個測試點寫去設(shè)計測試用例。一個產(chǎn)品需求和多個測試需求是一對多的關(guān)系，一個測試需求和多個測試用例也是一對多的關(guān)系。例如登錄功能，這個產(chǎn)品需求就對應(yīng)了登錄的功能測試需求、安全測試需求、性能測試需求、兼容性測試和UI界面測試需求。而功能測試需求，又分為輸入正確的用戶名和密碼進行登錄、輸入錯誤的用戶名和密碼進行登錄、不輸入密碼登錄等測試用例。安全測試需求則有登錄成功后長期不使用軟件是否會自動登出、是否支持多端登錄（如果不支持，一端登錄會導致另一端登出）等測試用例。性能測試和UI界面測試同理（如下圖）。測試需求分析，經(jīng)常會借助思維導圖或Excel等工具。此外，優(yōu)秀的測試工程師是一定要非常熟悉業(yè)務(wù)的，如果在需求評審階段對需求不是很熟悉很理解，那需求分析階段就一定要熟悉需求、理解需求，明確有疑問的、模糊的、設(shè)計有缺陷的需求。

3. 安排測試計劃、設(shè)計測試方案。在傳統(tǒng)互聯(lián)網(wǎng)公司，由于迭代周期長達1-2個月，因此測試負責人會基于當次迭代的需求安排測試人員分工、時間計劃等。在節(jié)奏快、經(jīng)常1-2個禮拜一迭代的互聯(lián)網(wǎng)公司，測試計劃和測試方案的比重不會太大，但作為測試負責人，要對整個測試節(jié)奏、測試進度有把控。

4. 測試用例設(shè)計。這塊是核心環(huán)節(jié)，測試團隊一定要產(chǎn)出高質(zhì)量、全面不遺落的測試用例。

5. 用例評審。用例評審一般會先后進行測試部內(nèi)部評審和部門間評審。測試部內(nèi)部評審主要是測試人員交叉評審，部門間評審的參與人員主要是產(chǎn)品、開發(fā)、測試；不管是部門內(nèi)評審還是部門間評審，用例評審的目的都是對用例進行查漏補缺以及確保產(chǎn)品、前后端開發(fā)、測試等對需求理解是否一致。

6. 開發(fā)轉(zhuǎn)測-冒煙測試。開發(fā)同學開發(fā)完一個個功能模塊后，會逐步把相關(guān)需求轉(zhuǎn)給測試同學，測試同學在新版本上測試。但注意了，在真正執(zhí)行完整的測試用例前，測試同學先跑一遍當次需求的核心流程，以防止出現(xiàn)轉(zhuǎn)測的版本流程不通過的情況。如果核心流程不通過，就打回給開發(fā)（核心流程不通過，執(zhí)行完整的測試用例是沒意義的）。這就是冒煙測試了。

7. 用例執(zhí)行。用例執(zhí)行階段，測試同學基于之前設(shè)計并評審的用例，一條條仔細、耐心執(zhí)行即可。

8. 提交Bug。執(zhí)行用例過程中，如果出現(xiàn)問題，測試同學要定位清楚是前后端哪塊的問題，并盡可能定位出產(chǎn)生問題的原因。最后再以結(jié)構(gòu)化的語言向開發(fā)提交缺陷報告（大白話就是提交Bug），以讓開發(fā)同學修改Bug（怎樣提交Bug可參考如何提交一個清楚的Bug？）

9. 回歸Bug。開發(fā)同學修好Bug后，測試同學要對修好的Bug進行回歸，回歸時如果Bug未修復(fù)，則把Bug打回給開發(fā)同學繼續(xù)修改；如果Bug已修復(fù)，還要多測試一下直接相關(guān)的功能、思考下會不會帶來新的問題。因為在實際工作中，出現(xiàn)不少情況開發(fā)同學為了修改一個Bug，帶來了其他新的Bug。

10. 發(fā)布流程。當次迭代所有需求都完成、所有Bug都已修復(fù)后，就進入到產(chǎn)品發(fā)布流程了。

? ? ? ?最后非常重要的是，適用于一切項目的完美流程是不存在的，以上測試的幾個環(huán)節(jié)只是軟件測試的通用流程。在實際工作中，我們還要根據(jù)每個公司、每個項目的實際情況針對性地優(yōu)化測試流程（不斷優(yōu)化測試流程也是中高級測試人員的素質(zhì)之一），比如有的公司需求設(shè)計的問題比較多（需求功能遺漏、需求設(shè)計邏輯Bug、需求對用戶的意義不大），那需求評審環(huán)節(jié)、測試需求分析環(huán)節(jié)就要多花時間去提出需求設(shè)計上的問題，提醒產(chǎn)品同學補充遺漏的功能、改進有邏輯缺陷的功能、砍掉對用戶意義不大的不必要的需求等；再如，軟件常見問題反復(fù)出現(xiàn)，那就需要整理一份軟件常見缺陷的checkList（即錯誤推斷法），作為每次迭代，用例設(shè)計完后的查漏補缺；再如，測試環(huán)境沒有問題，生產(chǎn)環(huán)境時不時出現(xiàn)問題，那么就需要增加預(yù)生產(chǎn)環(huán)境的測試，以及加大生產(chǎn)測試的比重；接著如，生產(chǎn)測試也無法保障產(chǎn)品在生產(chǎn)環(huán)境的質(zhì)量，那么也很有必要增加生產(chǎn)環(huán)境的質(zhì)量監(jiān)控。優(yōu)化測試流程，總的原則就是哪里薄弱優(yōu)化哪里，哪里問題多優(yōu)化哪里（步步高點讀機，哪里不會點哪里）。