我所理解的"測試"工作
寫在前沿
入行第5年了，最近發現自己心態上起了一些微妙的變化，如果在頭三年，別人問我，軟體測試到底是幹啥的，我肯定會回答，就是測軟體上bug的，當然，你的bug測得越多越好，甚至，你在測試時候如果沒有發現Bug，你會莫名的感覺焦灼甚至有點心慌，媽呀，我是不是漏測了？那時候以為，發現bug的數量和質量或許體現了測試工程師存在於這個行業的最大價值和意義。
直到，我經歷過一個專案，心路慢慢的有了些轉變，因為專案上線質量和快速迭代的壓力，我發現從剛開始儘管一遍又一遍的測出了很多的bug，但是專案質量仍然堪憂，專案上線仍然沒有安全感，特別是上線以後，開發一句：這個怎麼沒測出來讓我有點風中凌亂（寶寶心裡苦，寶寶不說），按照我以前的理解，我自認為已經是一個合格的測試了，但是我所面臨的讓我思考，我是不是該從專案下游的環節往上捋捋是不是團隊出了什麼問題？
迴歸專案
首先說下專案特點，該專案迭代速度很快，平均一個月釋出三次，後端相對於比較穩定，前端程式碼Bug率較大，其中我所碰到過以下主要幾個問題：
迴歸範圍的不確定性
經常出現的問題可能就是，當前端修改過一個問題後，可能會產生其他的前端問題。
另外一個問題可能是剛開始專案交接的時候，本身該專案沒有需求文件，以及產品經理，測試需求點的介入需要強依賴開發的口頭溝通；
案例：有一次，前端修改一個ini介面，開發評估自測，但是線上出現某個活動頁面登入不上。
思考：如何從測試的角度去預知前端程式碼的變更所造成的影響範圍，從而評估出測試範圍？
目前的解決方案：
a． 在測試階段，讓前端開發去評估的測試範圍，針對專案需求在建立jira任務的時候去儘可能的給出測試版本，測試內容以及相對應的互動稿。
圖1. 完善需求
b． 加強開發程式碼CodeReview流程，多個前端互動評審，給出評審報告；
當然，最好的解決方案是測試人員學會前端程式碼，參與程式碼評審，從上游和開發一起做一個程式碼質量保證。
無法把控的專案節奏
案例：在迭代過程中，經常會面臨測試節奏被打亂的情況；可能有以下幾種原因：
- 線上Hotfix緊急上線；
2. 在已經確定好開發計劃後又新增需求；
以上幾點原因直接導致我們在專案進度上被某些突發事件打亂，無法按照預定的專案節奏走。
圖2.某個專案迭代過程
解決方案：
針對Hotfix，可能確實已經相對比較緊急了；在開發給出測試範圍以後，測試根據自己的經驗做一些相應的迴歸；
針對新增需求，各個團隊人員進行相應的評估，由新增需求的人提出一個需求變更表；需要團隊隊員確認；
圖3.需求變更風險評估表
劍拔弩張的溝通
開發與測試的矛盾點很大部分集中在，開發在產品質量意識上，對產品質量和測試人員有些誤解，他們會認為線上如果有Bug那是因為測試人員的問題，他們沒有給產品把好關，導致Bug流到了線上，然後巴拉巴拉的吐槽測試，在整個團隊裡面，我覺得集中突出了以下2個問題：
1.“這個怎麼沒測出來？”：
曾經經歷過一次線上Bug，在和一個開發聊天的過程中，在交談過程中他跟我抱怨“你怎麼連這個都沒測出來呢？我們怎麼信任你的測試質量？”。說實話那句話讓我心裡很不爽，因為在他的意識裡面把那次線上Bug的責任全部歸咎到了我沒有測試到位。當時直接爭執了起來，“你說我測試差，我還沒說你開發能力差呢？”
儘管，我們所瞭解的測試其實是一個服務型的行業，有時候會是一個“背鍋俠”，但是真的像開發所說的那樣，線上Bug只是我們測試不到位的原因嘛？如果我們細細挖掘整個產品生產過程，事實是，“測試”這個環節是所有產品生產裡面最不會產生”Bug”的環節。
2.如何去看待線上問題？：
團隊面臨的另外一個問題，就是對線上Bug的零容忍，這樣會導致一個很直接的結果，就是一旦出現線上Bug，團隊氛圍會因為線上壓力而變得很緊張；其次，剛開始的時候，一旦出現問題大家都會把矛頭直接對準測試，並且會把目光聚焦到產品生產下游—從測試的底端去想如何去避免該類問題；
解決方案：
- 如何讓開發有質量保障的參與感---增加開發用例設計的參與感。
除了一般的用例評審環節，還會增加一個用例站會評審環境，測試需要把所有的測試思路以及測試重點再進行一輪展示，全體參與查漏補缺（可能一部分原因是想說，讓開發去體會測試所處的位置和難處）。
圖4. 用例評審模式
2.儘可能的引導團隊在出現線上問題的時候從產品生產上游去解決問題。因為增加自動化迴歸範圍這些手段來說，可能會避免這個問題，但還是無法去解決真正發生這些問題的原因，儘管這個過程中在推廣這些理念的時候會和開發產生一些衝突和爭執，過程比較艱辛，是一個任重而道遠的過程。
圖5.線上問題解決方案
產品質量的困惑
每次迭代上線，我們都會寫一個測試報告，在每次報告總結裡面，我們都會填寫一個總結，產品質量怎麼樣，能不能上線等等？這些很多都是憑藉我們自己的經驗去判斷，當有人真正問你的時候，你還真的無法說出一個一二，什麼叫好，什麼叫不好？
這個專案可能會給我增加一些判定的維度方面的經驗：
- 產品質量：
包含了我們最終在交付產品的時候，對Bug（數量+嚴重度+概概述），功能點（包含了功能，效能，異常是否全部覆蓋），用例（是否包含了全部功能點以及執行情況，測試過程的程式碼覆蓋率等）的一個整體產品評估。
- 產品過程質量：
引入這個概念，是因為一些測試經驗；比如，我們在做功能測試的時候，一般我們會進行相對較全的功能迴歸，在第一輪迴歸以後，可能會出現一些問題，然後修復好以後又進行相應的冒煙，此時在迴歸次數增加的同時，可能也會存在一些未知的風險，比如第一輪迴歸完成後，第二輪修的Bug可能會影響到前面的測試功能，所以存在說迴歸次數和產品質量的一個風險關係；
其次，比如我們在迭代過程中的需求挖掘，如果在剛開始需求挖掘的時候，沒有挖掘出一些潛在的需求Bug，那可能後續會增加一些迴歸的風險，再比如開發的冒煙的通過率等等還有很多，也可以根據自己的專案經驗去增加。
圖6.日常迭代過程記錄
- 上線過程質量：
主要考慮2個方面：
- 上線過程中前後端是否相互完全隔離；
- 上線是否採用靜默升級，升級後會不會影響線上現有的功能點。
如何提專案質量風險？
整個測試過程中，質量保障的最後一步，我認為也是最難的一步，就是如何去預估產品所在的風險點，我曾經和開發有過一些爭執的矛盾點是在於立場的不一致會對風險點的看法理解不一樣，所以在寫風險點的時候儘可能和開發在意見上達成一致。
其次，除了遺漏Bug等一些質量風險，專案風險的話儘可能由“大”到“小”的去思考，“大”是指方向性，比如相容性，安全，效能，異常等等的角度入手，“小”是結合產品所在的一些細節。
比如，一個移動端的產品要上線，可能因為我的測試時間有限我相容性只測了一部分，相容性問題可能是我的一個風險點；
再比如，後端新增一個介面或者新增一個服務 ，效能和異常這塊可能要考慮是不是一個風險點。
這些都是需要去考慮和專案經驗積累的。
寫在最後：
如果現在，專案要上線了我還沒有發現bug，那種焦灼感反而由一些欣慰替代，我發現我心態的轉變可能是源於我意識的轉變，當別人問我，測試是幹嘛的時候，我可能更偏重於，測試是一個把質量意識輸出到整個團隊的人，是一個流程推動者，是一個需求挖掘者，是一個質量把關者，一方面我們確實通過自己的經驗和技術手段去挖掘更多的Bug，另外最重要的一方面，通過一些測試需求的挖掘，流程把控，質量意識以及測試方法的傳播儘可能的去從產品生產上游去避免Bug。希望有一天，在我們的推動下，行業沒有了測試人員，因為專案里人人都是測試專家。
共勉！