全程軟件測試實踐

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 全程軟件測試圖解

傳統的軟件測試，能夠簡單描述爲下圖所示：

 

圖-1-傳統交付測試

開發人員完成任務以後，最後交付給測試人員，這種模式下，測試人員不能及早發現需求階段的缺陷，同時測試工做的開展也滯後了，產品質量得不到有效的過程控制和分析，整體進度可能會因爲返工問題形成拖延。

那什麼是全程軟件測試，以下圖所示：

 

 

圖-2-全程軟件測試圖

在整個SDLC中，三條角色主線和四個階段。

三條角色主線：開發、QA、測試，文中主要講解測試。

四個階段：需求、開發、發佈、平常運營。

簡單來講能夠概括爲下圖所示：

 

圖-3-全程軟件測試概述

 

測試人員貫穿這四個階段，開展測試活動，測試實踐活動簡單描述以下圖所示：

 

圖-4-測試實踐活動

每一個階段也有開發人員對應的活動，以及QA人員對應的活動。

對於產品而言，每次版本迭代，都會經歷：需求、開發、發佈，最後推向平常運營，發佈階段虛線指向的需求階段和平常運營階段，並非一個終止階段，而是不斷迭代的過程。

 

那測試人員是如何開展全程軟件測試活動的呢？

 

2 需求階段測試

在需求階段，開發人員、測試人員、QA人員主要作的事情，以下表所示：

階段	開發人員	測試人員	QA人員
需求階段	? 用戶故事分析 ? 用戶故事估時	? 參與用戶故事分析、挖掘故事含混性 ? 參考經驗庫質疑開發的時間估算	? 保證確認需求活動符合需求管理過程 ? 管理用戶故事評審 ? 管理需求變動

做爲測試人員的主要實踐以下：

? 參與用戶故事分析、挖掘故事含混性

在sprint會議上，對用戶故事進行分析，檢查功能性需求和非功能性需求是否描述清晰，其中能夠將非功能性需求做爲驗收要點，例如一個用戶故事：

「客戶但願提升響應時間」

測試人員應當協助開發人員消除故事的含混性：提升什麼的響應時間和響應時間爲多少？能夠建議修改成：

「客戶信息普通查詢返回結果的響應時間爲5s內」

說明在「客戶信息」模塊，進行「普通查詢」操做，返回結果的時間在5s內，這個陳述句已經清晰表達了，也達到了消除含混性的效果。一樣，測試人員能夠編寫提升查詢效率的用戶故事：

「客戶在信息查詢模塊，進行普通查詢，可以在5s內返回結果」

「備註：5s爲非功能性需求，也是驗收要點」

 

? 參考經驗庫質疑開發的時間估算

在sprint會議上，開發人員根據經驗出牌（團隊本身定義的規則，用撲克牌）估算時間，當給出最終結果的時候，測試人員應當對其進行質疑。測試人員借鑑歷史經驗庫：開發人員在某方面的技能如何、該模塊曾經產生過何種程度的缺陷、修復缺陷的消耗時間是多少等等，綜合考慮，提出疑問，讓開發估算最終的時間，儘量考慮這些因素。固然，測試人員可以質疑的其中一個前提是：測試人員具有相關開發經驗。

 

小結：在需求階段，測試人員要發揮做用，減小含混性需求引入到開發階段、同時協助開發作好時間估算。

 

3 開發階段測試

在開發階段，開發人員、測試人員、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如下；

開發團隊必須保證每一個環境的質量目標，纔可以保證整個的質量目標。

小結：

測試人員與開發人員永遠不是敵對關係，而是協助關係，確切來講是質量天枰的兩邊，任何一邊的工做沒有作好，都會失去平衡。

4 發佈階段測試

在發佈階段，開發人員、測試人員、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、在版本測試期間，發現測試環境存在一次代碼被覆蓋、兩次因開發人員操做失誤影響測試執行的狀況；

小結：

測試人員應當持續反饋、改進、總結每一個版本發生的問題（不論是缺陷，仍是過程當中出現的），並對缺陷進行分析，總結出一些規律，幫助開發人員創建良好的習慣，改進代碼的質量。

 

5 平常運營階段測試

在平常運營階段，開發人員、測試人員、QA人員主要作的事情，以下表所示：

階段	開發人員	測試人員	QA人員
平常運營	? 生產故障登記	? 版本問題反饋和改進提議 ? 生產故障分析	? 管理平常運營活動

平常運營階段，並非終止階段，即使需求、開發、發佈階段暫停活動，只要產品提供服務，平常運營都存在着。

做爲測試人員的主要實踐以下：

? 版本問題反饋和改進提議

對平常運營發生的問題，總結反饋，提出改進建議，而且跟蹤實施。

? 生產故障分析

協助開發排查生產故障，避免測試場景的遺漏。

 

6 總結

軟件測試並非保證產品質量的最後一道防線，測試人員也不是，測試人員的工做徹底能夠由更加資深的開發人員來完成，不過現實老是殘酷的，目前測試與開發的比例爲：1:3，在成熟的團隊是這樣子，另一些還在持續改進的團隊，因爲資源不足，可能去到1:7。開發人員在至關長的一段時間內不可能徹底替代測試人員，有個關鍵要素：思惟方式不一樣，有句古話來形容：江山易改本性難移。當開發人員的思惟方式改變的時候，那就成爲測試人員了，倒不如把測試人員獨立出來更好，而且培養給開發人員必定的測試素養，這個對保證產品質量都是有幫助的。

全程軟件測試實踐，強調的是貫穿每一個階段的測試活動，不管是開發、仍是測試，要理解雙方的活動價值，何時該作什麼事情，什麼事情該作到什麼程度纔算好，保證每一個環節的質量，纔可以保證產品的全程質量，另外產品質量不是測試出來的，而是構建過程當中沉澱下來的，開發人員的素養、測試人員的素養、以及團隊對開發測試過程的重視程度，決定了產品質量。產品質量就如同一塊蛋糕，應當切分爲小塊，落實到每一個人手裏，讓每一個人嚐到甜頭，擔當起來。