1 全程軟件測(cè)試圖解
傳統(tǒng)的軟件測(cè)試竞帽，可以簡單描述為下圖所示：
圖-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)營。
簡單來說可以歸納為下圖所示：
圖-3-全程軟件測(cè)試概述
測(cè)試人員貫穿這四個(gè)階段孽亲，開展測(cè)試活動(dòng)坎穿，試實(shí)踐活動(dòng)簡單描述如下圖所示：
圖-4-全程軟件測(cè)試概述
每個(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）拓萌，對(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è)試場景额嘿，可以使用文字描述步驟，或者使用xmind腦圖
描述劣挫，場景中的數(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ì)參與愧膀，簡單來說就是對(duì)測(cè)試用例進(jìn)行查漏補(bǔ)缺的工作。
測(cè)試探索
進(jìn)行了“功能要點(diǎn)確認(rèn)”和“用例評(píng)審”后谣光，為了保證測(cè)試場景的覆蓋率檩淋，需要再進(jìn)行測(cè)試探索。在開發(fā)人員完成雛形之后萄金，使用探索式測(cè)試的策略蟀悦，對(duì)功能基本流程進(jìn)行有目的的快速走查，挖掘功能不確定的地方和補(bǔ)充測(cè)試場景氧敢，避免不確定的因素拖延到開發(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)樘幚硗旰唵稳蝿?wù)才使得燃盡圖長的好看看尼。往往有些開發(fā)人員，喜歡挑著任務(wù)來做盟步，把簡單易做藏斩、優(yōu)先級(jí)的任務(wù)先完成了，因?yàn)檫@些總在預(yù)期內(nèi)能夠完成却盘，所以前期燃盡圖的趨勢(shì)看起來沒有問題狰域。
缺陷經(jīng)驗(yàn)庫
每個(gè)團(tuán)隊(duì)都存在開發(fā)/測(cè)試新人和開發(fā)/測(cè)試?yán)先耍?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（大家可以根據(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ù)度量，例如：
測(cè)試發(fā)現(xiàn)缺陷總數(shù)：測(cè)試過程中產(chǎn)生的去除狀態(tài)為“無效”秸妥、“不用改”的缺陷數(shù)目滚停。
測(cè)試發(fā)現(xiàn)嚴(yán)重缺陷數(shù)：測(cè)試過程中產(chǎn)生的并去除狀態(tài)為“無效”、“不用改”的粥惧、且嚴(yán)重性為“Major”和“Critical”的缺陷總數(shù)目铐刘。
測(cè)試發(fā)現(xiàn)缺陷修復(fù)數(shù)：測(cè)試過程中產(chǎn)生的狀態(tài)為“已關(guān)閉”的缺陷數(shù)量；
未解決缺陷數(shù)：去除狀態(tài)為“無效”影晓、“不用改”镰吵、“關(guān)閉”的缺陷總數(shù)。
缺陷修復(fù)率：（測(cè)試發(fā)現(xiàn)缺陷的修復(fù)數(shù)）÷（測(cè)試發(fā)現(xiàn)缺陷總數(shù)）×100％
嚴(yán)重缺陷率：（測(cè)試發(fā)現(xiàn)嚴(yán)重缺陷數(shù)）÷（測(cè)試發(fā)現(xiàn)缺陷總數(shù)）×100％
嚴(yán)重缺陷修復(fù)率：（已修復(fù)的嚴(yán)重缺陷數(shù)）÷（測(cè)試發(fā)現(xiàn)嚴(yán)重缺陷數(shù)）×100％
測(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)度和問題分析：
從BUG的嚴(yán)重級(jí)別分布來看，Major級(jí)別以上的BUG占12%饵婆，占的比重不高勺馆，說明大部分的主要功能已經(jīng)實(shí)現(xiàn)了；
其中在sonar定義級(jí)別的缺陷侨核，主要集中在代碼規(guī)范和單元測(cè)試覆蓋率草穆，說明代碼質(zhì)量有待提高；
版本測(cè)試的前期時(shí)間較充足搓译，后期隨著開發(fā)提交完成的功能點(diǎn)增多悲柱，BUG數(shù)量增多，剩余測(cè)試時(shí)間變得緊張些己；
在版本測(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è)試場景的遺漏弃甥。
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)長的一段時(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)起來。 如果對(duì)軟件測(cè)試有興趣呐萌，想了解更多的測(cè)試知識(shí)馁痴，可以加入我的QQ群 高級(jí)測(cè)試學(xué)習(xí)大家庭：652068511
