1 全程軟件測試圖解

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

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

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

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

圖-2-全程軟件測試圖

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

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

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

簡單來說可以歸納為下圖所示：

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

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

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

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

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

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

2 需求階段測試

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

作為測試人員的主要實踐如下：

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

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

“客戶希望提高響應時間”

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

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

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

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

“備注：5s為非功能性需求，也是驗收要點”

參考經(jīng)驗庫質(zhì)疑開發(fā)的時間估算

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

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

3 開發(fā)階段測試

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

作為測試人員的主要實踐如下：

功能要點確認

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

圖-5-腦圖用例模板

測試用例設計

測試人員主要設計測試故事點，使用DSL(Domain Specific language)，infoq文章（敏捷測試之借力DSL），對測試用例進行描述，包括三個基本要素：

Feature、Scenario、Example，補充要素：xmind、Requirement。

Feature：把測試分類到某個模塊，并對這個特性本身的業(yè)務目的進行相關描述，帶進業(yè) 務目標，傳遞業(yè)務知識。

Scenario：標明這個Feature的測試場景，可以使用文字描述步驟，或者使用xmind腦圖

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

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

Xmind：腦圖文件，展示測試故事點

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

用例評審

主要是堅持同行評審的原則，主要在測試組內(nèi)進行，負責該任務的開發(fā)人員也會參與，簡單來說就是對測試用例進行查漏補缺的工作。

測試探索

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

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

燃盡圖發(fā)布

另外，測試人員還有一項重要工作，每日發(fā)布燃盡圖，讓團隊了解當前進度情況，總結問題

所在，尋求耗時超過預期時間任務的解決辦法。

圖-6-燃盡圖

圖形特點：

1）剩余工時在計劃基準上方，代表進度有所延遲，應抓緊進度；

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

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

此時也需要查看在這種進度下，優(yōu)先級高的任務是否得到時間保證，而不是因為處理完簡單任務才使得燃盡圖長的好看。往往有些開發(fā)人員，喜歡挑著任務來做，把簡單易做、優(yōu)先級的任務先完成了，因為這些總在預期內(nèi)能夠完成，所以前期燃盡圖的趨勢看起來沒有問題。

缺陷經(jīng)驗庫

每個團隊都存在開發(fā)/測試新人和開發(fā)/測試老人，當測試人員與開發(fā)新人進行需求確認的時候，還需要進行缺陷經(jīng)驗教訓的提醒，避免多走彎路。

圖-7-缺陷總結

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

測試人員可以提供相關checklist（大家可以根據(jù)原作者提供的修改為符合團隊的）幫助開發(fā)人員在編碼過程中關注開發(fā)自測的要點，從而提升質(zhì)量。

圖-8-web軟件測試checklist

持續(xù)集成

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

負責單元測試的開發(fā)人員，會收到失敗構建的郵件；

負責集成測試的開發(fā)人員，會收到失敗構建的郵件；

負責自動化測試（Selenium）的測試負責人員，會收到失敗構建的郵件；

這種方式，確保單元測試、集成測試、自動化測試，有相關人員關注和維護。

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

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類別的代碼規(guī)則缺陷在20以下；

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

小結：

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

4 發(fā)布階段測試

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

作為測試人員的主要實踐如下：

測試報告

完成驗收測試，提供測試報告，給出測試數(shù)據(jù)度量，例如：

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

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

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

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

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

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

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

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

缺陷統(tǒng)計分析報告

另外，測試人員還有一項重要工作，對當前版本的缺陷進行統(tǒng)計分析：

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

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

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

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

測試進度和問題分析：

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

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

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

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

小結：

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

5 日常運營階段測試

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

日常運營階段，并不是終止階段，即便需求、開發(fā)、發(fā)布階段暫停活動，只要產(chǎn)品提供服務，日常運營都存在著。

作為測試人員的主要實踐如下：

版本問題反饋和改進提議

對日常運營發(fā)生的問題，總結反饋，提出改進建議，并且跟蹤實施。

生產(chǎn)故障分析

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

6 總結

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

全程軟件測試實踐，強調(diào)的是貫穿每個階段的測試活動，不論是開發(fā)、還是測試，要理解雙方的活動價值，什么時候該做什么事情，什么事情該做到什么程度才算好，保證每個環(huán)節(jié)的質(zhì)量，才能夠保證產(chǎn)品的全程質(zhì)量，另外產(chǎn)品質(zhì)量不是測試出來的，而是構建過程中沉淀下來的，開發(fā)人員的素養(yǎng)、測試人員的素養(yǎng)、以及團隊對開發(fā)測試過程的重視程度，決定了產(chǎn)品質(zhì)量。產(chǎn)品質(zhì)量就如同一塊蛋糕，應當切分為小塊，落實到每個人手里，讓每個人嘗到甜頭，擔當起來。 如果對軟件測試有興趣，想了解更多的測試知識，可以加入我的QQ群 高級測試學習大家庭：652068511