Infoq已經發表了文章（http://www.infoq.com/cn/articles/whole-software-testing-practice-requirements-to-operational），這裏把原文公佈下：
之前一篇文章《軟件測試轉型之路》
(http://www.infoq.com/cn/articles/transformation-way-software-testing/)介紹過轉型的一些實踐，下文將介紹從2011年3月至今，持續改進的全程軟件測試實踐活動。
傳統的軟件測試，可以簡單描述爲下圖所示：
圖-1-傳統交付測試
開發人員完成任務之後，最後交付給測試人員，這種模式下，測試人員不能及早發現需求階段的缺陷，同時測試工作的開展也滯後了，產品質量得不到有效的過程控制和分析，總體進度可能會由於返工問題造成拖延。
那什麼是全程軟件測試，如下圖所示：
圖-2-全程軟件測試圖
在整個SDLC中，三條角色主線和四個階段。
三條角色主線：開發、QA、測試，文中主要講解測試。
四個階段：需求、開發、發佈、日常運營。
簡單來說可以歸納爲下圖所示：
圖-3-全程軟件測試概述
測試人員貫穿這四個階段，開展測試活動，測試實踐活動簡單描述如下圖所示：
圖-4-測試實踐活動
每個階段也有開發人員對應的活動，以及QA人員對應的活動。
對於產品而言，每次版本迭代，都會經歷：需求、開發、發佈，最後推向日常運營，發佈階段虛線指向的需求階段和日常運營階段，並不是一個終止階段，而是不斷迭代的過程。
那測試人員是如何開展全程軟件測試活動的呢？
在需求階段，開發人員、測試人員、QA人員主要做的事情，如下表所示：
| 階段 | 開發人員 | 測試人員 | QA人員 |
| 需求階段 | ? 用戶故事分析 ? 用戶故事估時 | ? 參與用戶故事分析、挖掘故事含混性 ? 參考經驗庫質疑開發的時間估算 | ? 保證確認需求活動符合需求管理過程 ? 管理用戶故事評審 ? 管理需求變更 |
作爲測試人員的主要實踐如下：
? 參與用戶故事分析、挖掘故事含混性
在sprint會議上，對用戶故事進行分析，檢查功能性需求和非功能性需求是否描述清晰，其中可以將非功能性需求作爲驗收要點，例如一個用戶故事：
“客戶希望提高響應時間”
測試人員應當協助開發人員消除故事的含混性：提高什麼的響應時間和響應時間爲多少？可以建議修改爲：
“客戶信息普通查詢返回結果的響應時間爲5s內”
說明在“客戶信息”模塊，進行“普通查詢”操作，返回結果的時間在5s內，這個陳述句已經清晰表達了，也達到了消除含混性的效果。同樣，測試人員可以編寫提高查詢效率的用戶故事：
“客戶在信息查詢模塊，進行普通查詢，能夠在5s內返回結果”
“備註：5s爲非功能性需求，也是驗收要點”
? 參考經驗庫質疑開發的時間估算
在sprint會議上，開發人員根據經驗出牌（團隊自己定義的規則，用撲克牌）估算時間，當給出最終結果的時候，測試人員應當對其進行質疑。測試人員借鑑歷史經驗庫：開發人員在某方面的技能如何、該模塊曾經產生過何種程度的缺陷、修復缺陷的消耗時間是多少等等，綜合考慮，提出疑問，讓開發估算最終的時間，儘可能考慮這些因素。當然，測試人員能夠質疑的其中一個前提是：測試人員具備相關開發經驗。
小結：在需求階段，測試人員要發揮作用，減少含混性需求引入到開發階段、同時協助開發做好時間估算。
在開發階段，開發人員、測試人員、QA人員主要做的事情，如下表所示：
| 階段 | 開發人員 | 測試人員 | QA人員 |
| 開發階段 | ? 架構評審 ? 功能要點確認 ? 編碼開發 ? 單元測試 ? 開發自測 ? 代碼評審 ? Bug Fix | ? 功能要點確認 ? 測試用例設計 ? 用例評審 ? 測試探索 ? 功能測試 ? Bug Tracking ? 迴歸測試 ? 系統測試 ? 驗收測試 | ? 管理評審活動 ? 管理文檔產物 |
作爲測試人員的主要實踐如下：
? 功能要點確認
Xmind是一個非常好用的腦圖工具，通常在開發人員進行編碼前，測試人員會針對需求處理的用戶故事，與開發人員進行確認，修正理解偏差，確保需求理解一致。
圖-5-腦圖用例模板
? 測試用例設計
測試人員主要設計測試故事點，使用DSL(Domain Specific language)，infoq文章（敏捷測試 之 借力DSL：http://www.infoq.com/cn/articles/leveraging-dsl-in-agile-test），對測試用例進行描述，包括三個基本要素：
Feature、Scenario、Example，補充要素：xmind、Requirement。
Feature：把測試分類到某個模塊，並對這個特性本身的業務目的進行相關描述，帶進業 務目標，傳遞業務知識。
Scenario：標明這個Feature的測試場景，可以使用文字描述步驟，或者使用xmind腦圖
描述，場景中的數據使用Examples中列出的。
Example：引出具體的數據表格把用到的數據都展示出來，避免相同步驟因爲測試數據 的變化而重複若干遍造成冗餘。
Xmind：腦圖文件，展示測試故事點
Requirement：關聯需求管理系統的需求id。
? 用例評審
主要是堅持同行評審的原則，主要在測試組內進行，負責該任務的開發人員也會參與，簡單來說就是對測試用例進行查漏補缺的工作。
? 測試探索
進行了“功能要點確認”和“用例評審”後，爲了保證測試場景的覆蓋率，需要再進行測試探索。在開發人員完成雛形之後，使用探索式測試的策略，對功能基本流程進行有目的的快速走查，挖掘功能不確定的地方和補充測試場景，避免不確定的因素拖延到開發階段後期，造成返工。
其中：功能測試、Bug Tracking、迴歸測試、系統測試、驗收測試都是日常測試工作所需環節。
? 燃盡圖發佈
另外，測試人員還有一項重要工作，每日發佈燃盡圖，讓團隊瞭解當前進度情況，總結問題
所在，尋求耗時超過預期時間任務的解決辦法。
圖-6-燃盡圖
圖形特點：
1）剩餘工時在計劃基準上方，代表進度有所延遲，應抓緊進度；
發現此類問題，需要分析總結，原則是保證交付時間，對相應任務進行調整，擁抱變化，發現任務粒度太大，該拆分的繼續拆分；對於重構需要慎重，不要過度深入重構，給測試帶來額外工作量，影響整個進度，對於整個版本而言，只有開發、測試在承諾的時間內完成任務，纔是真正完成，僅僅開發完成交付算不上成功。
2）剩餘工時在計劃基準接近，代表進展良好，繼續保持；
此時也需要查看在這種進度下，優先級高的任務是否得到時間保證，而不是因爲處理完簡單任務才使得燃盡圖長的好看。往往有些開發人員，喜歡挑着任務來做，把簡單易做、優先級低的任務先完成了，因爲這些總在預期內能夠完成，所以前期燃盡圖的趨勢看起來沒有問題。
? 缺陷經驗庫
每個團隊都存在開發/測試新人和開發/測試老人，當測試人員與開發新人進行需求確認的時候，還需要進行缺陷經驗教訓的提醒，避免多走彎路。
圖-7-缺陷總結
? 提升開發自測質量
測試人員可以提供相關checklist（參考：http://www.ibm.com/developerworks/cn/web/1303_sujg_webchecklist1/index.html，大家可以根據原作者提供的修改爲符合團隊的）幫助開發人員在編碼過程中關注開發自測的要點，從而提升質量。
圖-8-web軟件測試checklist
? 持續集成
利用持續集成（Jenkins）平臺，做到快速的構建開發代碼，自動的單元測試化，來提高開發代碼的效率和質量。
負責單元測試的開發人員，會收到失敗構建的郵件；
負責集成測試的開發人員，會收到失敗構建的郵件；
負責自動化測試（Selenium）的測試負責人員，會收到失敗構建的郵件；
這種方式，確保單元測試、集成測試、自動化測試，有相關人員關注和維護。
圖-9-持續集成
? Sonar反饋
Sonar is an open platform to manage code quality. As such, it covers the 7 axes of code quality。
圖-10-sonar分析結果
測試人員主要反饋問題如下：
Code coverage：團隊要求代碼覆蓋率在80%以上；
Test success：團隊要求測試成功率在100%；
Duplications：團隊要求代碼重複率在10%以下；
Violations：團隊要求Major類別的代碼規則缺陷在20以下；
開發團隊必須保證每個環境的質量目標，才能夠保證整個的質量目標。
小結：
測試人員與開發人員永遠不是敵對關係，而是協助關係，確切來說是質量天枰的兩邊，任何一邊的工作沒有做好，都會失去平衡。
在發佈階段，開發人員、測試人員、QA人員主要做的事情，如下表所示：
| 階段 | 開發人員 | 測試人員 | QA人員 |
| 發佈階段 | ? 上線申請 ? 上線部署 ? 服務監控 | ? 測試報告 ? 線上功能檢查 | ? 管理評審活動 ? 管理文檔產物 |
作爲測試人員的主要實踐如下：
? 測試報告
完成驗收測試，提供測試報告，給出測試數據度量，例如：
1) 測試發現缺陷總數：測試過程中產生的去除狀態爲“無效”、“不用改”的缺陷數目。
2) 測試發現嚴重缺陷數：測試過程中產生的並去除狀態爲“無效”、“不用改”的、且嚴重性爲“Major”和“Critical”的缺陷總數目。
3) 測試發現缺陷修復數：測試過程中產生的狀態爲“已關閉”的缺陷數量；
4) 未解決缺陷數：去除狀態爲“無效”、“不用改”、“關閉”的缺陷總數。
5) 缺陷修復率：（測試發現缺陷的修復數）÷（測試發現缺陷總數）×100％
6) 嚴重缺陷率：（測試發現嚴重缺陷數）÷（測試發現缺陷總數）×100％
7) 嚴重缺陷修復率：（已修復的嚴重缺陷數）÷（測試發現嚴重缺陷數）×100％
8) 測試需求覆蓋率：已測試需求個數÷需求總數×100%
? 缺陷統計分析報告
另外，測試人員還有一項重要工作，對當前版本的缺陷進行統計分析：
按缺陷級別統計：
| | Critical | Major | Medium | Minor | 總計 |
| 首頁 | 0 | 0 | 1 | 0 | 1 |
| 模塊一 | 0 | 0 | 0 | 2 | 2 |
| 模塊二 | 0 | 1 | 2 | 10 | 13 |
| 模塊三 | 0 | 0 | 1 | 4 | 5 |
| 模塊四 | 0 | 0 | 1 | 2 | 3 |
| 模塊五 | 0 | 0 | 3 | 2 | 5 |
| 模塊六 | 0 | 1 | 0 | 1 | 2 |
| 模塊七 | 0 | 2 | 0 | 6 | 8 |
| sonar | 0 | 1 | 2 | 0 | 3 |
| 總計 | 0 | 5 | 10 | 27 | |
圖-11-缺陷統計
按缺陷來源統計：
| | 開發1 | 開發2 | 開發3 | 開發4 | 開發5 | 遺留 |
| Critical | 0 | 0 | 0 | 0 | 0 | 0 |
| Major | 1 | 2 | 0 | 0 | 0 | 2 |
| Medium | 1 | 7 | 0 | 1 | 0 | 1 |
| Minor | 1 | 7 | 4 | 6 | 3 | 6 |
| 總計 | 3 | 16 | 4 | 7 | 3 | 9 |
按缺陷狀態統計：
| 缺陷總數 | 已關閉缺陷數 | 遺留 | 缺陷修復率 | 嚴重缺陷數 | 嚴重缺陷率 | 已關閉嚴重缺陷數 | 嚴重缺陷修復率 |
| 42 | 40 | 2 | 95% | 5 | 12% | 5 | 100% |
測試進度和問題分析：
1、從BUG的嚴重級別分佈來看，Major級別以上的BUG佔12%，佔的比重不高，說明大部分的主要功能已經實現了；
2、其中在sonar定義級別的缺陷，主要集中在代碼規範和單元測試覆蓋率，說明代碼質量有待提高；
3、版本測試的前期時間較充足，後期隨着開發提交完成的功能點增多，BUG數量增多，剩餘測試時間變得緊張；
4、在版本測試期間，發現測試環境存在一次代碼被覆蓋、兩次因開發人員操作失誤影響測試執行的情況；
小結：
測試人員應當持續反饋、改進、總結每個版本發生的問題（不管是缺陷，還是過程中出現的），並對缺陷進行分析，總結出一些規律，幫助開發人員建立良好的習慣，改進代碼的質量。
在日常運營階段，開發人員、測試人員、QA人員主要做的事情，如下表所示：
| 階段 | 開發人員 | 測試人員 | QA人員 |
| 日常運營 | ? 生產故障登記 | ? 版本問題反饋和改進提議 ? 生產故障分析 | ? 管理日常運營活動 |
日常運營階段，並不是終止階段，即便需求、開發、發佈階段暫停活動，只要產品提供服務，日常運營都存在着。
作爲測試人員的主要實踐如下：
? 版本問題反饋和改進提議
對日常運營發生的問題，總結反饋，提出改進建議，並且跟蹤實施。
? 生產故障分析
協助開發排查生產故障，避免測試場景的遺漏。
軟件測試並不是保證產品質量的最後一道防線，測試人員也不是，測試人員的工作完全可以由更加資深的開發人員來完成，不過現實總是殘酷的，目前測試與開發的比例爲：1:3，在成熟的團隊是這樣子，另外一些還在持續改進的團隊，由於資源不足，可能去到1:7。開發人員在相當長的一段時間內不可能完全替代測試人員，有個關鍵要素：思維方式不同，有句古話來形容：江山易改本性難移。當開發人員的思維方式改變的時候，那就成爲測試人員了，倒不如把測試人員獨立出來更好，並且培養給開發人員一定的測試素養，這個對保證產品質量都是有幫助的。
全程軟件測試實踐，強調的是貫穿每個階段的測試活動，不論是開發、還是測試，要理解雙方的活動價值，什麼時候該做什麼事情，什麼事情該做到什麼程度纔算好，保證每個環節的質量，才能夠保證產品的全程質量，另外產品質量不是測試出來的，而是構建過程中沉澱下來的，開發人員的素養、測試人員的素養、以及團隊對開發測試過程的重視程度，決定了產品質量。產品質量就如同一塊蛋糕，應當切分爲小塊，落實到每個人手裏，讓每個人嚐到甜頭，擔當起來。