Infoq已經(jīng)發(fā)表了文章（http://www.infoq.com/cn/articles/whole-software-testing-practice-requirements-to-operational），這里把原文公布下：

為夷陵等地區(qū)用戶提供了全套網(wǎng)頁設(shè)計(jì)制作服務(wù)，及夷陵網(wǎng)站建設(shè)行業(yè)解決方案。主營業(yè)務(wù)為網(wǎng)站設(shè)計(jì)制作、成都做網(wǎng)站、夷陵網(wǎng)站設(shè)計(jì)，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務(wù)。我們深信只要達(dá)到每一位用戶的要求，就會(huì)得到認(rèn)可，從而選擇與我們長(zhǎng)期合作。這樣，我們也可以走得更遠(yuǎn)！

之前一篇文章《軟件測(cè)試轉(zhuǎn)型之路》

(http://www.infoq.com/cn/articles/transformation-way-software-testing/)介紹過轉(zhuǎn)型的一些實(shí)踐，下文將介紹從2011年3月至今，持續(xù)改進(jìn)的全程軟件測(cè)試實(shí)踐活動(dòng)。

1 全程軟件測(cè)試圖解

傳統(tǒng)的軟件測(cè)試，可以簡(jiǎn)單描述為下圖所示：

圖-1-傳統(tǒng)交付測(cè)試

開發(fā)人員完成任務(wù)之后，最后交付給測(cè)試人員，這種模式下，測(cè)試人員不能及早發(fā)現(xiàn)需求階段的缺陷，同時(shí)測(cè)試工作的開展也滯后了，產(chǎn)品質(zhì)量得不到有效的過程控制和分析，總體進(jìn)度可能會(huì)由于返工問題造成拖延。

那什么是全程軟件測(cè)試，如下圖所示：

圖-2-全程軟件測(cè)試圖

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

三條角色主線：開發(fā)、QA、測(cè)試，文中主要講解測(cè)試。

四個(gè)階段：需求、開發(fā)、發(fā)布、日常運(yùn)營。

簡(jiǎn)單來說可以歸納為下圖所示：

圖-3-全程軟件測(cè)試概述

測(cè)試人員貫穿這四個(gè)階段，開展測(cè)試活動(dòng)，測(cè)試實(shí)踐活動(dòng)簡(jiǎn)單描述如下圖所示：

圖-4-測(cè)試實(shí)踐活動(dòng)

每個(gè)階段也有開發(fā)人員對(duì)應(yīng)的活動(dòng)，以及QA人員對(duì)應(yīng)的活動(dòng)。

對(duì)于產(chǎn)品而言，每次版本迭代，都會(huì)經(jīng)歷：需求、開發(fā)、發(fā)布，最后推向日常運(yùn)營，發(fā)布階段虛線指向的需求階段和日常運(yùn)營階段，并不是一個(gè)終止階段，而是不斷迭代的過程。

那測(cè)試人員是如何開展全程軟件測(cè)試活動(dòng)的呢？

2 需求階段測(cè)試

在需求階段，開發(fā)人員、測(cè)試人員、QA人員主要做的事情，如下表所示：

作為測(cè)試人員的主要實(shí)踐如下：

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

在sprint會(huì)議上，對(duì)用戶故事進(jìn)行分析，檢查功能性需求和非功能性需求是否描述清晰，其中可以將非功能性需求作為驗(yàn)收要點(diǎn)，例如一個(gè)用戶故事：

“客戶希望提高響應(yīng)時(shí)間”

測(cè)試人員應(yīng)當(dāng)協(xié)助開發(fā)人員消除故事的含混性：提高什么的響應(yīng)時(shí)間和響應(yīng)時(shí)間為多少？可以建議修改為：

“客戶信息普通查詢返回結(jié)果的響應(yīng)時(shí)間為5s內(nèi)”

說明在“客戶信息”模塊，進(jìn)行“普通查詢”操作，返回結(jié)果的時(shí)間在5s內(nèi)，這個(gè)陳述句已經(jīng)清晰表達(dá)了，也達(dá)到了消除含混性的效果。同樣，測(cè)試人員可以編寫提高查詢效率的用戶故事：

“客戶在信息查詢模塊，進(jìn)行普通查詢，能夠在5s內(nèi)返回結(jié)果”

“備注：5s為非功能性需求，也是驗(yàn)收要點(diǎn)”

?參考經(jīng)驗(yàn)庫質(zhì)疑開發(fā)的時(shí)間估算

在sprint會(huì)議上，開發(fā)人員根據(jù)經(jīng)驗(yàn)出牌（團(tuán)隊(duì)自己定義的規(guī)則，用撲克牌）估算時(shí)間，當(dāng)給出最終結(jié)果的時(shí)候，測(cè)試人員應(yīng)當(dāng)對(duì)其進(jìn)行質(zhì)疑。測(cè)試人員借鑒歷史經(jīng)驗(yàn)庫：開發(fā)人員在某方面的技能如何、該模塊曾經(jīng)產(chǎn)生過何種程度的缺陷、修復(fù)缺陷的消耗時(shí)間是多少等等，綜合考慮，提出疑問，讓開發(fā)估算最終的時(shí)間，盡可能考慮這些因素。當(dāng)然，測(cè)試人員能夠質(zhì)疑的其中一個(gè)前提是：測(cè)試人員具備相關(guān)開發(fā)經(jīng)驗(yàn)。

小結(jié)：在需求階段，測(cè)試人員要發(fā)揮作用，減少含混性需求引入到開發(fā)階段、同時(shí)協(xié)助開發(fā)做好時(shí)間估算。

3 開發(fā)階段測(cè)試

在開發(fā)階段，開發(fā)人員、測(cè)試人員、QA人員主要做的事情，如下表所示：

作為測(cè)試人員的主要實(shí)踐如下：

?功能要點(diǎn)確認(rèn)

Xmind是一個(gè)非常好用的腦圖工具，通常在開發(fā)人員進(jìn)行編碼前，測(cè)試人員會(huì)針對(duì)需求處理的用戶故事，與開發(fā)人員進(jìn)行確認(rèn)，修正理解偏差，確保需求理解一致。

圖-5-腦圖用例模板

?測(cè)試用例設(shè)計(jì)

測(cè)試人員主要設(shè)計(jì)測(cè)試故事點(diǎn)，使用DSL(Domain Specific language)，infoq文章（敏捷測(cè)試 之 借力DSL：http://www.infoq.com/cn/articles/leveraging-dsl-in-agile-test），對(duì)測(cè)試用例進(jìn)行描述，包括三個(gè)基本要素：

Feature、Scenario、Example，補(bǔ)充要素：xmind、Requirement。

Feature：把測(cè)試分類到某個(gè)模塊，并對(duì)這個(gè)特性本身的業(yè)務(wù)目的進(jìn)行相關(guān)描述，帶進(jìn)業(yè)務(wù)目標(biāo)，傳遞業(yè)務(wù)知識(shí)。

Scenario：標(biāo)明這個(gè)Feature的測(cè)試場(chǎng)景，可以使用文字描述步驟，或者使用xmind腦圖

        描述，場(chǎng)景中的數(shù)據(jù)使用Examples中列出的。

Example：引出具體的數(shù)據(jù)表格把用到的數(shù)據(jù)都展示出來，避免相同步驟因?yàn)闇y(cè)試數(shù)據(jù) 的變化而重復(fù)若干遍造成冗余。

Xmind：腦圖文件，展示測(cè)試故事點(diǎn)

Requirement：關(guān)聯(lián)需求管理系統(tǒng)的需求id。

?用例評(píng)審

主要是堅(jiān)持同行評(píng)審的原則，主要在測(cè)試組內(nèi)進(jìn)行，負(fù)責(zé)該任務(wù)的開發(fā)人員也會(huì)參與，簡(jiǎn)單來說就是對(duì)測(cè)試用例進(jìn)行查漏補(bǔ)缺的工作。

?測(cè)試探索

進(jìn)行了“功能要點(diǎn)確認(rèn)”和“用例評(píng)審”后，為了保證測(cè)試場(chǎng)景的覆蓋率，需要再進(jìn)行測(cè)試探索。在開發(fā)人員完成雛形之后，使用探索式測(cè)試的策略，對(duì)功能基本流程進(jìn)行有目的的快速走查，挖掘功能不確定的地方和補(bǔ)充測(cè)試場(chǎng)景，避免不確定的因素拖延到開發(fā)階段后期，造成返工。

其中：功能測(cè)試、Bug Tracking、回歸測(cè)試、系統(tǒng)測(cè)試、驗(yàn)收測(cè)試都是日常測(cè)試工作所需環(huán)節(jié)。

?燃盡圖發(fā)布

另外，測(cè)試人員還有一項(xiàng)重要工作，每日發(fā)布燃盡圖，讓團(tuán)隊(duì)了解當(dāng)前進(jìn)度情況，總結(jié)問題

所在，尋求耗時(shí)超過預(yù)期時(shí)間任務(wù)的解決辦法。

圖-6-燃盡圖

圖形特點(diǎn)：

1）剩余工時(shí)在計(jì)劃基準(zhǔn)上方，代表進(jìn)度有所延遲，應(yīng)抓緊進(jìn)度；

發(fā)現(xiàn)此類問題，需要分析總結(jié)，原則是保證交付時(shí)間，對(duì)相應(yīng)任務(wù)進(jìn)行調(diào)整，擁抱變化，發(fā)現(xiàn)任務(wù)粒度太大，該拆分的繼續(xù)拆分；對(duì)于重構(gòu)需要慎重，不要過度深入重構(gòu)，給測(cè)試帶來額外工作量，影響整個(gè)進(jìn)度，對(duì)于整個(gè)版本而言，只有開發(fā)、測(cè)試在承諾的時(shí)間內(nèi)完成任務(wù)，才是真正完成，僅僅開發(fā)完成交付算不上成功。

2）剩余工時(shí)在計(jì)劃基準(zhǔn)接近，代表進(jìn)展良好，繼續(xù)保持；

此時(shí)也需要查看在這種進(jìn)度下，優(yōu)先級(jí)高的任務(wù)是否得到時(shí)間保證，而不是因?yàn)樘幚硗旰?jiǎn)單任務(wù)才使得燃盡圖長(zhǎng)的好看。往往有些開發(fā)人員，喜歡挑著任務(wù)來做，把簡(jiǎn)單易做、優(yōu)先級(jí)低的任務(wù)先完成了，因?yàn)檫@些總在預(yù)期內(nèi)能夠完成，所以前期燃盡圖的趨勢(shì)看起來沒有問題。

?缺陷經(jīng)驗(yàn)庫

每個(gè)團(tuán)隊(duì)都存在開發(fā)/測(cè)試新人和開發(fā)/測(cè)試老人，當(dāng)測(cè)試人員與開發(fā)新人進(jìn)行需求確認(rèn)的時(shí)候，還需要進(jìn)行缺陷經(jīng)驗(yàn)教訓(xùn)的提醒，避免多走彎路。

圖-7-缺陷總結(jié)

?提升開發(fā)自測(cè)質(zhì)量

測(cè)試人員可以提供相關(guān)checklist（參考：http://www.ibm.com/developerworks/cn/web/1303_sujg_webchecklist1/index.html，大家可以根據(jù)原作者提供的修改為符合團(tuán)隊(duì)的）幫助開發(fā)人員在編碼過程中關(guān)注開發(fā)自測(cè)的要點(diǎn)，從而提升質(zhì)量。

圖-8-web軟件測(cè)試checklist

?持續(xù)集成

利用持續(xù)集成（Jenkins）平臺(tái)，做到快速的構(gòu)建開發(fā)代碼，自動(dòng)的單元測(cè)試化，來提高開發(fā)代碼的效率和質(zhì)量。

負(fù)責(zé)單元測(cè)試的開發(fā)人員，會(huì)收到失敗構(gòu)建的郵件；

負(fù)責(zé)集成測(cè)試的開發(fā)人員，會(huì)收到失敗構(gòu)建的郵件；

負(fù)責(zé)自動(dòng)化測(cè)試（Selenium）的測(cè)試負(fù)責(zé)人員，會(huì)收到失敗構(gòu)建的郵件；

這種方式，確保單元測(cè)試、集成測(cè)試、自動(dòng)化測(cè)試，有相關(guān)人員關(guān)注和維護(hù)。

圖-9-持續(xù)集成

?Sonar反饋

Sonar is an open platform to manage code quality. As such, it covers the 7 axes of code quality。

圖-10-sonar分析結(jié)果

測(cè)試人員主要反饋問題如下：

Code coverage：團(tuán)隊(duì)要求代碼覆蓋率在80%以上；

Test success：團(tuán)隊(duì)要求測(cè)試成功率在100%；

Duplications：團(tuán)隊(duì)要求代碼重復(fù)率在10%以下；

Violations：團(tuán)隊(duì)要求Major類別的代碼規(guī)則缺陷在20以下；

開發(fā)團(tuán)隊(duì)必須保證每個(gè)環(huán)境的質(zhì)量目標(biāo)，才能夠保證整個(gè)的質(zhì)量目標(biāo)。

小結(jié)：

測(cè)試人員與開發(fā)人員永遠(yuǎn)不是敵對(duì)關(guān)系，而是協(xié)助關(guān)系，確切來說是質(zhì)量天枰的兩邊，任何一邊的工作沒有做好，都會(huì)失去平衡。

4 發(fā)布階段測(cè)試

在發(fā)布階段，開發(fā)人員、測(cè)試人員、QA人員主要做的事情，如下表所示：

作為測(cè)試人員的主要實(shí)踐如下：

?測(cè)試報(bào)告

完成驗(yàn)收測(cè)試，提供測(cè)試報(bào)告，給出測(cè)試數(shù)據(jù)度量，例如：

1)測(cè)試發(fā)現(xiàn)缺陷總數(shù)：測(cè)試過程中產(chǎn)生的去除狀態(tài)為“無效”、“不用改”的缺陷數(shù)目。

2)測(cè)試發(fā)現(xiàn)嚴(yán)重缺陷數(shù)：測(cè)試過程中產(chǎn)生的并去除狀態(tài)為“無效”、“不用改”的、且嚴(yán)重性為“Major”和“Critical”的缺陷總數(shù)目。

3)測(cè)試發(fā)現(xiàn)缺陷修復(fù)數(shù)：測(cè)試過程中產(chǎn)生的狀態(tài)為“已關(guān)閉”的缺陷數(shù)量；

4)未解決缺陷數(shù)：去除狀態(tài)為“無效”、“不用改”、“關(guān)閉”的缺陷總數(shù)。

5)缺陷修復(fù)率：（測(cè)試發(fā)現(xiàn)缺陷的修復(fù)數(shù)）÷（測(cè)試發(fā)現(xiàn)缺陷總數(shù)）×100％

6)嚴(yán)重缺陷率：（測(cè)試發(fā)現(xiàn)嚴(yán)重缺陷數(shù)）÷（測(cè)試發(fā)現(xiàn)缺陷總數(shù)）×100％

7)嚴(yán)重缺陷修復(fù)率：（已修復(fù)的嚴(yán)重缺陷數(shù)）÷（測(cè)試發(fā)現(xiàn)嚴(yán)重缺陷數(shù)）×100％

8)測(cè)試需求覆蓋率：已測(cè)試需求個(gè)數(shù)÷需求總數(shù)×100%

?缺陷統(tǒng)計(jì)分析報(bào)告

另外，測(cè)試人員還有一項(xiàng)重要工作，對(duì)當(dāng)前版本的缺陷進(jìn)行統(tǒng)計(jì)分析：

按缺陷級(jí)別統(tǒng)計(jì)：

圖-11-缺陷統(tǒng)計(jì)

按缺陷來源統(tǒng)計(jì)：

按缺陷狀態(tài)統(tǒng)計(jì)：

測(cè)試進(jìn)度和問題分析：

1、從BUG的嚴(yán)重級(jí)別分布來看，Major級(jí)別以上的BUG占12%，占的比重不高，說明大部分的主要功能已經(jīng)實(shí)現(xiàn)了；

2、其中在sonar定義級(jí)別的缺陷，主要集中在代碼規(guī)范和單元測(cè)試覆蓋率，說明代碼質(zhì)量有待提高；

3、版本測(cè)試的前期時(shí)間較充足，后期隨著開發(fā)提交完成的功能點(diǎn)增多，BUG數(shù)量增多，剩余測(cè)試時(shí)間變得緊張；

4、在版本測(cè)試期間，發(fā)現(xiàn)測(cè)試環(huán)境存在一次代碼被覆蓋、兩次因開發(fā)人員操作失誤影響測(cè)試執(zhí)行的情況；

小結(jié)：

測(cè)試人員應(yīng)當(dāng)持續(xù)反饋、改進(jìn)、總結(jié)每個(gè)版本發(fā)生的問題（不管是缺陷，還是過程中出現(xiàn)的），并對(duì)缺陷進(jìn)行分析，總結(jié)出一些規(guī)律，幫助開發(fā)人員建立良好的習(xí)慣，改進(jìn)代碼的質(zhì)量。

5 日常運(yùn)營階段測(cè)試

在日常運(yùn)營階段，開發(fā)人員、測(cè)試人員、QA人員主要做的事情，如下表所示：

日常運(yùn)營階段，并不是終止階段，即便需求、開發(fā)、發(fā)布階段暫?；顒?dòng)，只要產(chǎn)品提供服務(wù)，日常運(yùn)營都存在著。

作為測(cè)試人員的主要實(shí)踐如下：

?版本問題反饋和改進(jìn)提議

對(duì)日常運(yùn)營發(fā)生的問題，總結(jié)反饋，提出改進(jìn)建議，并且跟蹤實(shí)施。

?生產(chǎn)故障分析

協(xié)助開發(fā)排查生產(chǎn)故障，避免測(cè)試場(chǎng)景的遺漏。

6 總結(jié)

軟件測(cè)試并不是保證產(chǎn)品質(zhì)量的最后一道防線，測(cè)試人員也不是，測(cè)試人員的工作完全可以由更加資深的開發(fā)人員來完成，不過現(xiàn)實(shí)總是殘酷的，目前測(cè)試與開發(fā)的比例為：1:3，在成熟的團(tuán)隊(duì)是這樣子，另外一些還在持續(xù)改進(jìn)的團(tuán)隊(duì)，由于資源不足，可能去到1:7。開發(fā)人員在相當(dāng)長(zhǎng)的一段時(shí)間內(nèi)不可能完全替代測(cè)試人員，有個(gè)關(guān)鍵要素：思維方式不同，有句古話來形容：江山易改本性難移。當(dāng)開發(fā)人員的思維方式改變的時(shí)候，那就成為測(cè)試人員了，倒不如把測(cè)試人員獨(dú)立出來更好，并且培養(yǎng)給開發(fā)人員一定的測(cè)試素養(yǎng)，這個(gè)對(duì)保證產(chǎn)品質(zhì)量都是有幫助的。

全程軟件測(cè)試實(shí)踐，強(qiáng)調(diào)的是貫穿每個(gè)階段的測(cè)試活動(dòng)，不論是開發(fā)、還是測(cè)試，要理解雙方的活動(dòng)價(jià)值，什么時(shí)候該做什么事情，什么事情該做到什么程度才算好，保證每個(gè)環(huán)節(jié)的質(zhì)量，才能夠保證產(chǎn)品的全程質(zhì)量，另外產(chǎn)品質(zhì)量不是測(cè)試出來的，而是構(gòu)建過程中沉淀下來的，開發(fā)人員的素養(yǎng)、測(cè)試人員的素養(yǎng)、以及團(tuán)隊(duì)對(duì)開發(fā)測(cè)試過程的重視程度，決定了產(chǎn)品質(zhì)量。產(chǎn)品質(zhì)量就如同一塊蛋糕，應(yīng)當(dāng)切分為小塊，落實(shí)到每個(gè)人手里，讓每個(gè)人嘗到甜頭，擔(dān)當(dāng)起來。