入行第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。希望有一天，在我們的推動下，行業沒有了測試人員，因為專案裡人人都是測試專家。
共勉！
我所理解的前端
轉眼間，在鵝廠的實習已經過去三個多月，涉及到實習生轉正留用的考核流程也逐步開始了。帶著一堆疑問，以及自己實習期間的心得體會，與導師暢談了一番。他作為資深前端工程師，就前端領域及我個人未來的職業規劃等方面分享了他自己的經驗。這次與導師的溝通讓我受益匪淺，現簡單總結如下。前端知識學習路線 首先，當然是就...
我所理解的陣列
陣列 一 一維陣列 1 陣列的建立 陣列顧名思義是含有相同元素的集合，類似我們高中數學所學習的集合 例如int arr 10 char arr1 2 float arr2 3 double arr3 5 注意 切記 這個中要給常量，不能使用變數。2 陣列的初始化 初始化是指 在陣列的建立同時並賦予合...
我所理解的OpenSocial
昨天在google參加了opensocial的講座，通過三位opensocial工程師的精彩演講，我對這個東西有了一些簡單的理解。下面就把我所理解的opensocial，也算是筆記整理在這裡。1 為什麼會有opensocial？當前社會是乙個網路的社會，當前的網路是乙個社會性的網路，sns遍地開花到...