本文首發(fā)于【林子的空間】
之前寫過一篇文章《神圣的QA》瘪贱，是面向想從事QA工作的畢業(yè)生同學的牙寞，文中有講到QA的五個基本職責：
- 理解和澄清業(yè)務需求
- 制定策略并設計測試
- 實現和執(zhí)行測試
- 缺陷管理與分析
- 質量反饋與風險識別
最近有朋友希望我能分享體系化的測試需要關注哪些方面逢倍，我又想到了這五個基本職責面粮。原文中基于“生產杯子”的需求對于五個職責有解釋嚣州，本文將展開每個職責途事，從測試實踐和方法集的角度來分析測試需要做什么和怎么做后室。
01 理解和澄清業(yè)務需求
業(yè)務需求是軟件開發(fā)的源頭躯护，正確理解需求的正確性不言而喻本股，理解和澄清需求也是測試工作至關重要的一部分攀痊。
1. 理解和澄清業(yè)務需求的維度
具體該如何去理解和澄清需求呢？我認為測試人員可以從以下三個維度去理解和澄清業(yè)務需求：
關于這幾個維度的詳細內容拄显，在文章《敏捷測試如何優(yōu)化業(yè)務價值》中有介紹苟径。
2. 需求的可測試性
正確理解業(yè)務需求以外，對需求的描述質量也需要關注躬审，其中需求的可測試性是最為重要的一個方面：
- 如果需求不可測棘街，也就不可驗收，沒辦法知道項目是否成功完成盒件；
- 以可測試的方式編寫需求蹬碧，才能確保需求能夠正確實現并驗證。
需求的可測試性主要體現在下面三個維度：
完備性
需求的完備性主要指流程路徑需要考慮全面炒刁，要求邏輯鏈路完整恩沽，既要有正向路徑，也要包括異常場景翔始。
比如：正確的用戶名密碼可以登錄罗心，不正確的用戶名和密碼登錄會發(fā)生什么里伯，這兩者都是需要清晰定義的。
客觀性
需求的描述不要用一些主觀性的詞語渤闷，而是需要客觀的數據和示例來說明疾瓮。比如下面這段主觀性的描述是個非常糟糕的需求示例：
系統(tǒng)應該易于有經驗的工程師使用，并且應該使得用戶的出錯盡可能少飒箭。
推薦采用《實例化需求》的方式來編寫需求文檔狼电，將業(yè)務規(guī)則通過實例表述出來，不僅易于團隊不同角色的理解弦蹂，而且不容易產生歧義肩碟。
獨立性
獨立性主要是針對單個業(yè)務功能點（敏捷開發(fā)中的用戶故事），要盡量的獨立凸椿，跟其他功能邊界清晰削祈，減少因為依賴導致的功能點不可測。
比如：輸入和輸出要在同一個功能點里可驗證脑漫，A功能點的輸入不能通過B功能點的輸出來驗證髓抑。
敏捷開發(fā)中的用戶故事有INVEST原則，將可測試性和獨立性是分開描述的优幸，我認為獨立性也會影響可測試性吨拍，在這里把獨立性作為可測試性的一個因素。
02 制定策略并設計測試
制定策略并設計測試是五個職責里最為關鍵的一個劈伴，涵蓋的內容較多密末。看上去是策略和測試設計兩部分跛璧，但實際上包含了測試所需要考慮的方方面面严里。下面挑選我認為比較有價值的內容分別介紹。
1. 一頁紙測試策略
策略是方向追城，要做好軟件的測試工作刹碾，離不開測試策略的指導。測試策略通常對于經驗不是太豐富的測試人員來講座柱，可能挑戰(zhàn)比較大迷帜。不過，我曾經提出來的“一頁紙測試策略”可以很好地幫助測試人員去思考和制定自己項目適配的測試策略色洞。一頁紙測試策略如下如所示：
在一頁紙測試策略里邊戏锹，清晰地定義了測試策略需要考慮的三個部分：
- 指導性原則：團隊為質量負責
- 測什么：測試的內容
- 怎么測：測試左移、測試右移和精益測試
更多詳情請參考我的文章《一頁紙測試策略》火诸。
2. 測試流程與質量門禁
我們經常會發(fā)現有些團隊的測試流程定義的也很清晰锦针，但是每個環(huán)節(jié)要求做到什么效果并沒有嚴格的要求，很多質量工作做的并不到位，導致后面測試階段測試人員的壓力巨大或者最終交付的質量并不高奈搜。
前面一頁紙測試策略里已經有包含測試流程部分悉盆，這里再次單獨提及主要是為了強調質量門禁的重要性。測試流程每個項目或團隊可能都不太一樣馋吗，但是不管測試流程包括哪些環(huán)節(jié)焕盟，每個環(huán)節(jié)的輸出結果要求務必定義清晰，也就是要清晰定義每個環(huán)節(jié)的質量門禁宏粤，如下圖所示：
注意：此圖僅為示例脚翘，實際情況需要根據自身團隊情況適配。
3. 典型測試類型
上面的流程圖示例中列出了多種不同的測試類型商架，而實際的測試類型遠不止這些堰怨。由于篇幅有限且這部分內容不是本文的重點，本文只介紹跟測試人員關系非常緊密的四種典型的測試類型蛇摸。這四類測試的分類維度并不相同，這里不求詳盡灿巧。不清楚但又感興趣的同學赶袄，請自行網上搜索。
冒煙測試
冒煙測試來源于電路板的測試抠藕，也就是通電后看電路板是否冒煙饿肺，如果冒煙說明這塊電路板是不可能正常工作的，也就不用去驗證其他功能了盾似。
對應到軟件的冒煙測試敬辣，就是驗證軟件的最基本行為是否正常，例如：“程序是否運行零院？”溉跃，“用戶界面是否打開？”或“單擊事件是否有效告抄？”等撰茎。只有冒煙測試通過，才有進一步開展驗證軟件功能測試的必要打洼，否則就需要先修復重新出新版本才可以龄糊。
我們發(fā)現有的團隊只對新開發(fā)功能進行冒煙測試，其實這是不太正確的募疮，或者說這個測試就不叫冒煙測試炫惩。冒煙測試應該是對整個系統(tǒng)級別的基本行為進行驗證，不區(qū)分什么新舊功能阿浓。
回歸測試
回歸測試的目的是驗證新開發(fā)功能或者修復bug的時候他嚷，是否對已有功能有破壞。因此，回歸測試的對象主要是針對已有功能爸舒，對于新功能的測試不叫回歸蟋字。
回歸測試的策略通常有四類：
- 全面回歸：這種就是不分青紅皂白，對所有已有功能進行全面的測試扭勉，這種策略成本較高鹊奖，但是覆蓋率較全，一般對質量要求特別高的金融類產品采用全面回歸的方式較多涂炎。
- 選擇性回歸：這種一般是測試會跟開發(fā)進行溝通忠聚，了解當前代碼編寫可能影響到的范圍，選擇對這些受影響的功能模塊進行回歸唱捣。這種形式可能漏掉沒有意識到但是關聯到的功能两蟀，有一定的風險，但是較為經濟的一種做法震缭。
- 指標法回歸：這種一般是團隊對回歸測試的覆蓋率有要求赂毯，比如要覆蓋50%的已有功能測試用例，執(zhí)行回歸測試不能低于這個覆蓋率拣宰。這種光看指標數字的做法是最不推薦的党涕，雖然覆蓋率達標了，但是有可能該測的沒有測到巡社。
- 精準回歸：精準回歸就是當下非常熱門的精準測試膛堤，這是采用技術的手段將代碼改變所影響到的范圍跟測試用例關聯起來，精準地執(zhí)行受影響的用例晌该。這種質量最為有保證肥荔，但是精準測試實現成本是非常高的。
回歸測試可以手動進行朝群，也可以是自動化測試燕耿，但通常回歸測試的量都會比較大潜圃，以自動化的方式進行會比較高效缸棵。
端到端測試
端到端測試基于測試覆蓋的粒度分類，是針對單元測試和接口測試等而言的谭期。
端到端測試是從頭到尾驗證整個軟件及其與外部接口的集成堵第，其目的是測試整個軟件的依賴性、數據完整性以及與其他系統(tǒng)隧出、接口和數據庫等的通信踏志，以模擬完整的業(yè)務流程。因此胀瞪，端到端測試是最能體現用戶真實業(yè)務行為的測試针余，有著非常重要的價值饲鄙。
但是，由于端到端測試涉及到系統(tǒng)各個相關組件和外部依賴圆雁，其穩(wěn)定性和執(zhí)行成本相對都是比較高的忍级。于是有了覆蓋范圍較小的接口測試和單元測試，這些測試一般都是通過隔離依賴來實現的測試伪朽，此處不再細述轴咱。
探索式測試
探索式測試由Cem Kanner博士于1983年提出，是針對腳本化測試而言的烈涮。
Cem Kanner對探索式測試的定義如下：
“探索式測試是一種軟件測試風格朴肺，它強調獨立測試人員的個人自由和職責，為了持續(xù)優(yōu)化其工作的價值坚洽，將測試相關學習戈稿、測試設計、測試執(zhí)行和測試結果分析作為相互支持的活動讶舰，在整個項目過程中并行地執(zhí)行鞍盗。”
探索式測試的核心旨在將測試學習跳昼、測試設計橡疼、測試執(zhí)行和測試結果分析作為一個循環(huán)快速地迭代，以不斷收集反饋庐舟、調整測試、優(yōu)化價值住拭。
探索式測試特別需要測試人員的主觀能動性挪略，需要有較為寬松的鼓勵測試創(chuàng)新的環(huán)境才能較好地開展，如果對于測試指標要求過高滔岳，測試人員主觀能動性難以發(fā)揮的情況下杠娱，探索式測試的效果也很有限。
探索式測試是一種相對自由的測試風格谱煤，不建議被各種測試模型套住摊求，也不建議嚴格規(guī)定探索式測試的執(zhí)行方式，這些都會影響到探索式測試的發(fā)揮刘离。
更多的關于探索式測試的內容歡迎參考Thoughtworks同事劉冉的文章《探索式測試落地實踐》和史湘陽的文章《敏捷項目中的探索性測試》室叉。
4. 自動化測試分層策略
前面介紹端到端測試的時候提到了不同覆蓋范圍的測試，可能有單元測試和接口測試等硫惕。自動化分層策略就是針對這些不同粒度的測試類型進行分層茧痕，根據成本、穩(wěn)定性等因素建議自動化測試需要考慮不同層的覆蓋比例恼除。
根據下圖谷歌測試定律踪旷，我們能夠很清晰的看到不同層的測試發(fā)現問題之后的修復成本的差異性，單元測試比端到端測試發(fā)現的問題修復成本要低得多，因此令野，通常建議測試分層應該傾向于測試金字塔的模式舀患，也就是下圖右側的樣子。Thoughtworks同事Ham Vocke的文章《測試金字塔實戰(zhàn)》對此有很詳細的介紹气破。
需要注意的是測試金字塔不是銀彈聊浅，測試策略不是一成不變的，需要根據實際情況階段性調整堵幽、演進狗超，滿足當下產品/項目質量目標才是關鍵。
更多的關于自動化測試分層的內容朴下，還可以參考下列文章：
5. 測試用例
設計測試用例是每一名測試人員必備的基本功努咐，測試用例的好壞直接影響到測試的有效性，測試用例的重要性不言而喻殴胧，但是要設計好的測試用例也不是一件很簡單的事情渗稍。這里說的測試用例不區(qū)分手動用例和自動化用例。
好的測試用例
首先团滥，我們有必要了解什么樣的測試用例算是好的用例竿屹。
好的測試用例應該是正好能夠覆蓋所測軟件系統(tǒng)、能夠測出所有問題的灸姊。因此拱燃，好的測試用例需要具備下列特點：
- 整體完備性，且不過度設計：有效測試用例組成的集合力惯，能夠完全覆蓋測試需求碗誉；同時也不會有用例超出測試需求。
- 等價類劃分的準確性：每個等價類都能保證只要其中一個輸入測試通過父晶，其他輸入也一定測試通過哮缺。
- 等價類集合的完備性：所有可能的邊界值和邊界條件都已經正確識別。
當然甲喝，因為軟件系統(tǒng)的復雜性尝苇，不是所有測試用例都能做到正好100%覆蓋，只能是做到盡量的完備埠胖。
測試用例設計方法
力求完備的測試用例糠溜，就需要了解相應的測試用例設計方法。測試用例應該是結合業(yè)務需求和系統(tǒng)特點押袍，綜合起來考慮設計诵冒。通常建議的用例設計方法有如下幾種：
- 數據流法：基于業(yè)務流程中的數據流來切分測試場景的方法∫瓴眩考慮業(yè)務流程中的數據流汽馋，在數據存儲或者發(fā)生變化的點進行流程的切斷侮东，形成多個用例場景。這個在我的文章《說起B(yǎng)DD豹芯，你會想到什么》里有介紹悄雅。
- 等價類劃分法：把程序所有可能的輸入數據劃分為若干部分，然后從每個部分中選取少數有代表性的數據作為測試用例铁蹈。等價類分有效等價類和無效等價類宽闲，根據等價類劃分方法設計測試用例要注意無冗余和完備性。
- 邊界值法：邊界值分析方法是對等價類劃分的補充握牧，通常取正好等于容诬、剛剛大于或剛剛小于邊界的值作為測試數據，包括對輸入輸出的邊界值進行測試和來自等價類邊界的用例沿腰。
- 探索式測試模型法：推薦史亮和高翔兩位老師的著作《探索式測試實踐之路》览徒，書中將探索式測試按測試對象不同分為系統(tǒng)交互測試、交互特性測試和單個特性測試三個層次颂龙，每個層次都分別介紹了不同的探索模型习蓬。雖然我不認為探索式測試需要嚴格按照這些模型來做，但是這些模型是可以幫助測試人員在探索過程中進行思考的措嵌，同時也是設計測試用例非常有價值的參考躲叼。
關于用例設計，還可以參考下列文章：
03 實現和執(zhí)行測試
實現和執(zhí)行測試就是以測試策略為指導枫慷、根據設計的測試來落地執(zhí)行的相應的測試活動。這部分內容相對比較簡單浪规，從手動測試和自動化測試兩個維度來簡單介紹流礁。
1. 手動測試
手動測試，顧名思義就是手工執(zhí)行的測試罗丰，根據是否有提前設計好的測試用例（腳本）可以分為腳本化測試和探索式測試。
腳本化測試的執(zhí)行再姑，在有成熟測試用例的前提下萌抵，相對比較簡單。但是元镀，有些測試可能準備工作較為復雜绍填，比如要通過長鏈路來準備測試數據、或者讓系統(tǒng)到達測試觸發(fā)的狀態(tài)等栖疑，還有可能要考慮不同的環(huán)境對應的配置調整讨永，同時也會包括環(huán)境的準備和管理。這些都是測試人員要做好手工測試可能需要涉及的內容遇革。
關于探索式測試卿闹，在《探索式測試實踐之路》中有詳細介紹基于測程的測試管理（Session Based Test Management揭糕，SBTM）方法來執(zhí)行探索式測試：將測試章程分解成一系列測程，測試人員在測程中完成一個特定測試章程的設計锻霎、執(zhí)行和記錄著角。
同樣，這個方法對探索式測試有一定的指導意義旋恼，但是不建議嚴格規(guī)定必須按照這個模式來執(zhí)行吏口，不然的話就破壞了探索式測試的本質，達不到相應的效果冰更。
2. 自動化測試
前面部分介紹了自動化測試的分層策略产徊，把自動化測試的實現和執(zhí)行放到這里介紹。
工具選型
自動化測試的實現依賴于自動化測試工具蜀细，對于工具的選型非常關鍵舟铜。通常在工具選型時需要考慮如下幾個因素：
- 滿足需求：不同的項目有不同的需求，根據需求來選擇审葬，不求最好深滚，只求適合就好。
- 易于使用：常見的易用性涣觉，以及跟寫測試的人技能匹配的易用性痴荐，都是需要考慮的。同時需要易于上手官册，如果一款工具對于新人不友好生兆、很難上手的話，就很難動員大家都來積極地使用膝宁。
- 支持的語言：較好的作法是使用與項目開發(fā)相同的語言編寫自動化腳本鸦难，讓開發(fā)人員能夠靈活地添加測試。
- 兼容性：包括瀏覽器员淫、平臺和操作系統(tǒng)之間的兼容合蔽。
- 報告機制：自動化測試的結果報告至關重要，優(yōu)先選擇能夠提高完備的報告機制的工具介返。
- 測試腳本易于維護：測試代碼跟產品代碼一樣重要拴事，對測試的維護不可忽視，需要一款易于維護的工具圣蝎。
- 工具的穩(wěn)定性：不穩(wěn)定性會導致測試有效性降低刃宵，首先要保證工具本身的穩(wěn)定性，不然得不償失徘公。
- 代碼執(zhí)行速度：測試代碼的執(zhí)行速度直接影響到測試效率牲证，比如Selenium和Cypress編寫的測試代碼執(zhí)行速度就有很大差別。
測試實現
關于自動化測試的文章隨處可見关面，這里強調一點坦袍，不要把測試數據寫死在測試腳本里十厢，要將數據獨立出來，做到數據驅動键闺，以提高測試代碼的可復用性寿烟。
自動化測試的執(zhí)行
是不是覺得自動化測試實現以后，執(zhí)行就是簡單的跑起來就可以呢辛燥？也不是筛武。測試的執(zhí)行也需要一定的策略，例如：對不同的測試按需設置不同的執(zhí)行頻率挎塌，將自動化測試跟流水線集成做到持續(xù)地測試徘六，以持續(xù)反饋，最大化發(fā)揮自動化測試的價值榴都。
關于自動化測試待锈，推薦閱讀以下文章：
04 缺陷管理與分析
缺陷對軟件質量、軟件測試來講是非常寶貴的嘴高，好的缺陷管理和分析將會帶來很大的價值竿音，但是往往容易被忽略。
缺陷管理很重要的一個部分是搞清楚缺陷的生命周期是什么樣的。往往大家覺得缺陷從發(fā)現到修復并驗證通過了就可以了，其實并不止這些山上。我認為缺陷的生命周期應該包括如下階段：
- 發(fā)現缺陷：這個比較簡單，就是發(fā)現跟期望行為不一致的系統(tǒng)行為宽气，或者性能、安全等非功能性問題潜沦。缺陷可能是在測試過程中發(fā)現萄涯，也可能由用戶報告，還可以是例行日志分析或日志監(jiān)控報警等等通過日志來發(fā)現唆鸡。
- 定位和信息收集：發(fā)現缺陷之后涝影，需要收集相應的缺陷信息并做初步定位。其中争占，缺陷相關信息要盡可能收集全袄琳，包括完整的重現步驟、影響范圍燃乍、用戶、平臺宛琅、數據刻蟹、屏幕截圖、日志信息等嘿辟。這一步有的時候可能需要開發(fā)或者運維人員幫忙舆瘪。
- 記錄缺陷：就是將收集到的日志信息記錄在日志管理系統(tǒng)片效，關聯相應的功能模塊，并定義嚴重性英古。
- Triage/排優(yōu)先級：對于記錄的缺陷也不是所有的都要修復淀衣，所以要先對缺陷進行分類整理，確定缺陷是否有效召调、對有效缺陷的優(yōu)先級排序膨桥，并且確定哪些是要修復以及在什么時間修復。這一步可能需要跟業(yè)務和開發(fā)人員一起來完成唠叛。
- 修復缺陷：這一步就交給開發(fā)人員來完成只嚣，對缺陷進行修復。
- 測試缺陷修復：對開發(fā)修復的缺陷進行驗證艺沼，確保缺陷本身已經修復册舞，并且需要對相關功能進行適當的回歸測試。
- 添加相應的自動化測試：對于已經發(fā)現的缺陷障般，最好添加自動化測試调鲸，下次如果再發(fā)生類似的問題可以通過自動化測試及時地發(fā)現。自動化測試可以是單元測試挽荡、接口測試或者UI測試藐石，根據實際情況結合自動化測試分層策略來定。這一步可能跟上一步順序倒過來徐伐。
- 統(tǒng)計和分析缺陷：對缺陷的數量和嚴重程度進行統(tǒng)計分析其同比/環(huán)比趨勢贯钩，用魚骨圖和5 Why法等分析缺陷發(fā)生的根因，定位缺陷引入的階段办素，并且分析之前缺陷預防舉措的執(zhí)行效果等角雷。
- 制定改進舉措預防缺陷：根據第8步分析的結果，制定相應的可以落地的改進舉措性穿，以預防缺陷的發(fā)生勺三。
- 定期回顧和檢查改進情況：結合缺陷的統(tǒng)計分析，定期回顧缺陷管理的系列活動需曾，并檢查改進舉措的執(zhí)行情況吗坚，以持續(xù)優(yōu)化缺陷管理流程，更好的預防缺陷呆万。
關于缺陷的管理和分析商源，我之前有寫過相應的文章，朋友們歡迎移步閱讀：
05 質量反饋與風險識別
測試對產品質量狀態(tài)需要有清晰的認識谋减，能夠及時識別質量風險牡彻，并反饋給整個團隊。
前面講到缺陷的統(tǒng)計分析出爹，與質量相關的除了有缺陷信息以外庄吼，可能還有很多其他的數據缎除，將這些數據進行收集和統(tǒng)計，并且可視化展示給團隊总寻，將會幫助團隊不同角色更好地做到為質量負責器罐。在對質量數據的統(tǒng)計和分析過程中可以識別到相關的質量風險，將風險也一并反饋給團隊很有必要渐行。
質量狀態(tài)信息可能包括測試覆蓋率轰坊、缺陷相關數據、代碼凍結期長度殊轴、測試等待時間等內容衰倦，具體需要收集哪些信息還得根據項目實際的質量需求來定制化。
質量反饋建議周期性的進行旁理，由測試人員主導定義需要收集的數據有哪些樊零，開發(fā)人員協(xié)同測試人員一起收集相關數據，后面的分析過程可能也需要開發(fā)人員的參與孽文。
06 寫在最后
本文為構建測試的體系化思維的基礎篇驻襟，主要是從測試的基本職責出發(fā)展開，介紹了相關的方法芋哭、工具和實踐沉衣，適合初級測試人員；當然减牺，對于中高級測試人員豌习，也可以對照著看看是不是這些基本職責平常都做到了，在自身的測試體系里邊是否涵蓋了相關內容拔疚。
后續(xù)計劃還會出高級篇肥隆，在新的文章出來之前，大家可以先關注我的自出版小書《不止測試》(點擊鏈接可以免費下載電子版)稚失，書中介紹的其實是測試人員或者QA需要關注的超出測試基本職責之外的內容栋艳。
