一、測試流程是什麼？
最近這個項目是比較全的因為我去的時候是從頭跟進的，當時的話我們是有開項目立項會，然後的話我們組長去寫他的一個測試計劃，然後他給我們分模塊，給項目排期，然後的話設計他的第一輪 第二輪 第三輪的一個測試，他的一個測試的範圍，然後他給我們分到模塊之後，我要去想他的測試點、然後的話呢 去編寫測試用例 然後我們也去開評審。開始他的一輪測試 ，開發那邊提交代碼之後，我們首先去進行他的一個冒煙測試，對他的一個主要功能先去測一遍，然後第一輪主要就是解決他的一個功能性的嚴重性的bug 就是崩潰或者是説他有嚴重性的卡頓，主要就是解決這些問題，第二輪的話這些就全覆蓋了 第二輪的話主要就是解決他的一個卡頓還有功能上的一些bug，那第三輪的話呢？我們主要就是做他的一個迴歸測試。

測試流程依次如下：

1、需求：閲讀需求，理解需求，與客户、開發、架構多方交流，深入瞭解需求。--testing team

2、測試計劃: 根據需求估算測試所需資源（人力、設備等）、所需時間、功能點劃分、如何合理分配安排資源等。---testing leader or testing manager

3、用例設計：根據測試計劃、任務分配、功能點劃分，設計合理的測試用例。---testing leader, senior tester

4、執行測試：根據測試用例的詳細步驟，執行測試用例。--every tester(主要是初級測試人員)

5、執行結果記錄和bug記錄：對每個case記錄測試的結果，有bug的在測試管理工具中編寫bug記錄。--every tester(主要是初級測試人員)

6、defect tracking：追蹤leader分配給你追蹤的bug.直到 bug fixed。--every tester

7、測試報告：通過不斷測試、追蹤，直到被測軟件達到測試需求要求，並沒有重大bug.

8、用户體驗、軟件發佈等。

擴展資料：

流程分析：

這個流程唯一的優點，就是能快速的發現並修復問題。

這個流程中，項目經理是核心，項目經理也確實是有多年開發與項目經驗的牛人，他喜歡不定期分享上些前沿的技術。

對於測試來説，需求很不明確，測試文檔與用例也是可有可無的產物，沒有需求文檔，或非常簡陋，根據需求文檔根本無法編寫用例。

通用的測試用例，如登錄、文件上傳下載、列表翻頁、日期選擇、輸入框驗證、搜索等有一些“通用型”用例，以便在測試過程中做參考。

二、如何設計測試用例？
那麼在給出上述答案之前，先帶大家熟悉一下 什麼是測試用例？測試用例有什麼作用？ 然後在結合上述拋出的案例拋磚引玉一起討論 如何編寫測試用例？
下面就是此文目錄截圖：

1、什麼是測試用例
測試用例：為了特定的目的（證明軟件存在某問題）而設計的一組由測試輸入、執行條件、預期結果構成的文檔
1、測試用例簡單來説就是指導如何做測試的文檔，該文檔主要記錄需要驗證被測軟件的是否滿足需求

2、測試用例表現形式常見的有兩種，可以以模板形式展示

1）一種是通過Excel直接編寫

——大多數項目中都需要按照這種方式設計編寫

2）一種是通過xmind直接整理測試點

——時間緊迫，項目沒有強制要求時，可以設計測試點的形式編寫
——對於業務流程類的測試，也可以整理為測試點進行測試

3、設計及執行人員：測試工程師

4、用例的模板：描述編寫用例核心內容，一般項目都有自己的設計用例的模板，常見測試用例模板可參照如下：

2、為什麼要寫測試用例
為什麼要寫測試用例，實際中產品出現問題，第一責任人首先想到的是測試為啥沒有測到？
產品出現問題了，你為啥沒有測出來呢？

當然，除了避免“甩鍋和背鍋”，其實寫測試用例更重要的作用如下：

技術上將需求轉化為具體可驗證的指標
以文檔的形式記錄軟件可能存在的問題
防止測試過程的活動出現遺漏，提高工作效率
測試工作量的展示
3、如何編寫測試用例
既然寫測試用例如此重要，那麼如何更好的編寫測試用例呢？個人認為需要滿足如下幾點：

常規思考，設身處地的從用户角度出發（比如：實際用户是這麼使用的麼，會不會遇到異常情況呢？）
測試理論方法的支撐（比如：根據需求設計測試用例時，能用到哪些常見的測試用例設計方法？）
產品的熟悉和經驗的積累（比如：已經有過類型項目經驗，曾經在某個方面有過問題，當時是如何處理的呢？）
上述的設計用例過程，有個前提，就是對於測試有耐心和毅力，加上日常有意識的思維訓練，才會寫出全面的用例。

1、常規思考

迴歸到開篇的問題，對於一個基本的登錄頁面，按照常規思路能否會想到如下截圖的測試點呢？實際，這些測試點都是源於從用户角度出發，結合需求進行細化設計的過程。實際測試中是不是隻有這些測試點呢？

2、學習積累

相信大多數測試工程師都能夠想到上述基本的測試點，然在實際工作中面對的項目不同，設計測試用例的顆粒度也有不同的要求，如果針對上述登錄的模塊，更深入一層考慮呢？此時需要對產品的熟悉程度及測試經驗的加持，而且這些點的設計是不斷學習、熟悉項目、測試積累中得到的。

3、理論支撐

有了常規的思考，有了經驗的積累，還需要理論的支撐。測試用例畢竟是通過人去思考設計，這個過程不可避免有疏漏。如何規避？實際就需要測試理論的支撐，個人認為深入思考設計用例不外乎以下兩方面：

1）測試用例的設計方法

測試理論中很關鍵一塊就是將需求拆分為具體的測試點，然後根據用例設計方法進行具體的設計，其中拆分需求的關鍵是熟悉需求，將文檔中已有的描述內容，按照用户使用場景、個人測試經驗的積累（如果有的話）、把大段的內容拆分成能夠直接用用例設計方法的測試點，這樣就直接可以通過簡明扼要的文字描述轉化為Excel的測試用例，在這個過程通俗理解就是拆分細化的過程，直到可以直接寫用例驗證一個具體的功能點即可。
其中熟知的設計用例方法有：

觀察法
等價類、邊界值
判定表、因果圖
流程圖、場景法
錯誤推測法等
2）測試設計的思路開拓

倘若按照需求將已有的描述信息都已經拆分完畢了，是不是就可以確保測試沒有問題了呢？
其實不然，在上述基礎上如果還需要再拓展全面測試，還需要藉助於軟件質量模型的特性，從這些特性出發，給予測試用例設計者更多的思考空間。這樣的設計就更加的全面可靠。
常見軟件質量模型特性説明：

功能性：功能有沒有，好不好用
性能效率：對應系統的資源耗費程度及響應時間
易用性：容易理解、學習、使用
兼容性：能夠兼容不同的軟硬件平台
可靠性：不易出問題，萬一出問題容易恢復
安全性：對於用户的安全保障（外在的人生安全、內在的信息安全等）
可移植性：能否在不同環境條件下無故障運行
可維護性：對於後期的修復維護是否方便快捷
因此，對於上述登錄功能，按照上述質量模型的思路指導，就得到如下的測試點：

三、寫在最後
此時的你再回過頭來看看，還會認為登錄這個百試不爽的功能就設計十幾條甚至幾十條測試用例了嗎？顯然不是那麼簡單，需要在熟悉需求基礎上，進行拆分細化，將常規的思考、經驗的積累、理論的支撐結合起來使用，最終才能轉化為測試待驗證的結果。

熟悉需求上第一步，在此基礎上進行測試點的拆分細化，這個過程如果對於複雜一點的功能點，需要藉助於測試用例的設計方法，對於頁面級的測試點應用最多的不外乎是等價類、邊界值。

僅僅熟悉了需要，還需要結合經驗的積累，從質量模型的特性出發，進行全面的思考功能點的設計，是否出現遺漏的，是否有項目特殊要求的。

最後，用例的設計不是一蹴而就的事情，好的用例也是需要不斷的練習，反覆的修改評審，才能編寫出卓越的用例。

歡迎大家關注筆者的公眾號：程序員老奕，專注於軟件測試幹活分享，全套測試資源可免費分享！

最後如果你想學習自動化測試，歡迎加入筆者的交流羣：771645171，裏面會有很多資源和大佬答疑解惑，我們一起交流一起學習！