全程軟件測試，強調整個軟件生命週期中，各階段的測試活動。無論是需求階段，開發階段，還是測試階段，都需要確定在當前階段測試活動的內容以及成都，確保每個階段的質量，才能保證產品最終的質量。
全程軟件測試
全程軟件測試圖解
根據全程軟件測試的時間軸線圖，我們可以發現測試活動貫穿軟件開發的整個生命週期，各個階段測試活動內容如下：
那每個測試活動又到底是如何進行的？需要用的哪些技能或者方法呢？
需求階段
一、測試需求分析
我個人一直認爲需求分析是整個測試活動中除了測試用例設計之外最重要的部分。
需求分析目的是理解需求，理解業務。
弄清楚我們的產品有哪些功能？有哪些非功能性需求？
明白我們的用戶羣體是什麼？用戶會如何來使用我們的產品？
那我們到底該怎麼來進行需求分析呢？
具體執行如下：
二、測試計劃制定
當對需求有完整和全面的理解後，接下來我們需要制定詳細的測試計劃，爲即將開始的測試工作做好充足的準備。對於測試計劃的理解，我一直分爲兩種工作規模去看（個人理解，不正確的地方還請見諒）
小公司團隊
小公司測試團隊可能本身都沒幾個人，按照傳統理論需要考慮測試活動中各方面的問題，給人的感覺就像殺雞用3米長的大砍刀一樣。
我的理解是小團隊的測試計劃講清楚以下四個要素就行。
時間：根據以往經驗以及需求理解進行時間估算（小建議：時間節點多爭取1到2天時間緩衝，項目過程中難免出現意外事件）
任務：將測試活動拆分成具體的任務
人：任務的執行人以及質量監控負責人
風險控制
大作坊團隊
大公司測試團隊往往是涉及多個項目，整個公司的硬件、時間、人力等資源的分配就更爲複雜。在這種情況下，需要對各方面有更爲精細的計劃。
資源估算：整個項目需要多少資源？硬件資源，人力、時間資源等
進度控制：每個測試活動時間點控制
風險控制：對於在測試活動過程中出現問題的解決方案
資源配置：如何更有效率的使用資源
驗收標準：文檔、項目、測試過程的驗收標準定義
測試策略：測試中使用的測試策略
小結：
在需求分析階段，測試人員既要詳細的理解產品需要，又要從用戶的角度出發，分析出需求中不完善的地方，還要協調開發與測試對於需求理解的一致性，保證需求信息在開發和測試雙方中的統一。
這也就是儘早的將產品缺陷給暴露出來，也會有效的預防缺陷。
開發階段
在經過需求階段的準備工作後，進入開發階段就意味着擼起袖子加油乾的時候。開發階段對於軟件生命週期而言是最重要的階段。那在這個階段，又是如何開展測試活動的呢？
一、測試用例設計
測試用例設計是軟件測試工作的靈魂。
任何一項測試活動的核心都是測試思維，即如何進行測試。而測試用例就是測試思維的體現。功能的測試優先級、如何操作、輸入什麼數據、應該有什麼的結果等等都體現在測試用例中。那麼問題來了
到底怎麼設計測試用例呢？
（由於篇幅原因，這次我主要介紹一下接口測試用例設計方法）
首先，我們來看一看接口的執行過程
任何一個接口其實都由這三部分構成，那我們在設計測試用例時就可以根據這方面進行考慮。
針對接口的輸入條件進行設計：
針對接口的處理邏輯進行設計：
針對輸出結果設計：
其他方面考慮：
接口超時處理
廢棄接口處理
二、測試用例評審
測試用例的評審無疑是爲了給測試用例進行查漏補缺。
評審方式：
測試內部評審
項目組評審：項目相關人蔘與評審（開發、測試、產品）
注意：
項目組評審時，一般是會議的形式，由於測試用例的數量關係，會議上評審會佔用很長的時間，造成時間資源的浪費。
建議大家在評審前先將測試用例郵件發送給評審會議相關人，讓他們提前能對測試用例進行了解，熟悉。會議中進行反饋，記錄後，會後再修改。
三、測試執行
前面的工作做的充足的話，在測試執行的時候就會非常簡單了。只需要根據測試用例一條一條去執行程序即可。發現缺陷就提交缺陷，測試通過就繼續迴歸。
各位看官現在應該是心裏一萬個XXX呼嘯而過～～哪有說的那麼簡單。
其實測試執行的過程真的很簡單，只是在執行的過程中各部門的協作，溝通以及各項文檔的輸出很複雜。下面我們來聊聊在測試執行過程要注意的幾方面問題。
1、測試與開發的溝通
“XXX 我這有個問題，你過來看下”
“什麼問題？你演示下我看看”
“這不是問題，這個地方只能這樣做”或者 “這不是問題，我剛剛跟需求確認過的”
“這樣做不合邏輯啊！”
“那你說怎麼處理？”
“我覺得應該....處理”
“你先跟需求確認下吧”
這應該是測試工程師的日常吧。測試與開發溝通無疑是關於某個功能或者產品的，主要圍繞幾個以下幾個點：
程序某個地方存在問題
產品需求信息在測試和開發中不統一
程序某功能應該是怎麼處理
缺陷修復後的驗證
既然知道問題的核心，我們就要想辦法規避這些問題。假設一開始提問題的時候就把問題的特徵，位置，以及操作步驟，截圖都一目瞭然的提交給開發，是不是很大程度上可以節省測試演示的時間？
另一個最容易出現的問題就是信息不統一，這個需要整個項目組有意識的培養健全的工作流程，通過工作流程來規避這種信息不對稱的情況。這種情況將大大增加測試與開發的溝通成本。
2、測試與需求的溝通
測試人員與需求的溝通難點主要還是體現在需求不明確或者需求變更上。
很多時候需求人員的需求文檔都是不全面的，測試人員在寫測試用例時需要一次又一次的與需求進行確認，一來二去，需求估計有種想把桌子裏40米長的大刀放桌上來。
另一方面在項目過程中，不可避免的會出現需求變更，只要出現變更就意味着之前的測試準備工作就作廢。
所以在與需求的溝通是非常頻繁又火星四濺的，那怎麼更好的與需求進行溝通呢？
切記不能停留在口頭溝通，確認
所有的需求確認或者需求變更都需要文檔化，實在不行也需要發郵件
每一次確認、變更都需要通過項目相關人
建立完善的需求變更體系，流程上控制需求變更
3、測試結果的反饋
相信大家應該遇到過偶現的缺陷，開發重現時就沒有了，忙活了半天，被開發嫌棄了一頓
測試結果的反饋容易出現問題的地方就是結果描述不清楚，增加項目的時間和溝通成本。解決這個問題最好的辦法就是將測試結果儘可能的描述清楚。
測試結果反饋分爲兩種：
在溝通工具中向開發反饋缺陷
在缺陷管理工具中提交缺陷
到底怎樣提交/描述清楚一個缺陷？在下文中，我會詳細介紹。
四、缺陷管理
在開發階段，測試人員最重要的產出就是缺陷。缺陷不僅僅是數量多，就越有價值。更應該關注缺陷的質量、缺陷的管理以及缺陷分析。
怎麼樣提出質量高的缺陷？怎麼樣對缺陷進行管理和分析？見下圖
缺陷處理流程圖
缺陷管理是軟件測試活動中極其重要的一環，很多時候測試用例並沒有發現多少缺陷，反而自己在運行程序的過程中發現了很多缺陷，那這些缺陷就是對測試用例的補充，對之後的測試就可以提供思路。
小結：
在開發階段，測試人員最主要的工作就是發現缺陷，但是在這個過程中會伴隨着很多其他的問題，需要我們在工作流程中去規避。最重要的就是把測試放在整個項目中，是各個部門的團隊協作。
很多團隊的問題並沒有出在測試用例設計，測試執行，缺陷提交中，更多的出現在各部門之間的溝通、協作中。
發佈階段
進入發佈階段就意味着產品已經通過了測試，可以發佈到線上，交付給用戶使用。那如何確認測試已經通過？在發佈過程中，我們測試人員又需要完成哪些工作？
測試通過準則規範
上線前，需要確認測試已經通過，現在程序越來越複雜，如果沒有量化的規範，就很難確定測試到什麼時候可以上線。所以我們需要設定測試通過的準則，只有達到準則才能上線
測試需求功能覆蓋率100%
測試用例通過率95%以上
遺留缺陷沒有嚴重程度3級以及以上的缺陷
測試報告
完成測試後，提交測試報告，給出此次測試過程中的數據，例如：測試用例的數量，發現缺陷的總數，各個嚴重程度的缺陷數量，總共修復的缺陷數量以及缺陷修復率等等
系統回滾方案
每一次發佈都不能說百分之百的沒有問題，如果真的出現問題，我們該如何處理？
如果線上出現的問題不是很嚴重，儘量當時處理掉再上線
如果線上出現的問題很嚴重，就必須要系統回滾，保證線上用戶的正常使用
系統回滾方案須跟開發/項目經理確認
線上功能檢查
程序原有功能的迴歸測試
新上線的功能全面測試
小結：
每一次發佈後，測試人員都應該持續反饋，改進、總結每個版本中遇到的問題，不管是缺陷還是流程問題，從一次次的問題中總結一些經驗，提高整個軟件生命週期的質量
日常維護階段
產品上線後，用戶能穩定的長期使用，就意味着發佈的功能進入到日常維護階段。而這裏並不是終點，這個階段將一直存在。
在這個階段，測試人員的主要工作就比較簡單
持續測試，沒有產品是沒有缺陷的
即使收集用戶反饋的問題，並儘快組織人員修復
長時間穩定性測試（自動化測試）
總結
全程軟件測試，關注的是在整個軟件生命週期中，各個階段的測試活動。
通過對各個階段的過程質量把控，從而提高產品的測試質量。產品的質量並不是測試能決定的，而是整個項目構建過程中，通過一次次的優化過程，不斷的總結成長，是整個項目團隊決定的。
不同的工種都在這個過程中起到舉足輕重的作用，而全程軟件測試強調不斷提高每個階段的質量，最終提高項目團隊的綜合能力，從而提高產品質量
看到這裏，非常感謝您的耐心，如果您覺得有收穫，就記得幫我分享哦。