淺談測試工作好習慣

為什麼突然想寫這個測試習慣呢？源於一次會議。

在一次和後端開發、itpm開會期間，關於bug解決的時效性問題上引發了一場爭執：

開發同學：我們沒辦法做到和測試同學一樣，時時刻刻關注bug。

測試同學：我們每天上班後會及時打開缺陷管理平台，了解bug的情況，及時進行跟進和回歸。你們開發為什麼做不到？

當時心裡就在想，這不應該是一些習慣嗎？

測試將BUG的狀態管理，視為自己的本職工作，於是形成一種行為慣性。

習慣

我詢問過一些比較熟的開發同學，得到的結論是，有些開發會每天都關注，有些就是關注會少點，沒那麼頻繁，所以，怎麼說呢，每個人有每個人的工作習慣，測試人員有測試人員的工作習慣，開發人員有開發人員的工作習慣，不同角色的工作習慣又不同，習慣是每個人自己養成的，有好的有壞的，但是，好的習慣會讓工作進展的更順利，更效率。

以下是我自己的一些好的工作習慣分享，結尾會附上一些測試人員的一些想法，歡迎指正。

一、溝通的習慣

我所在的項目中，最基本溝通的方式就是郵件。於是每天到公司的第一件事就是打開郵箱，把最新的未讀郵件按照我定義的優先順序看完，再分根據緊急和重要成都劃分程四個象限，按照一定的主次順序處理。

郵件我大致進行了分類，諸如@我關注處理的、我負責的項目、流程要求類、企業文化宣傳類，構建通知類、培訓分享類等等，分類也決定了我閱讀和郵件的優先順序。

郵件分類

掃完一遍郵件後在頭腦中有個概念，將郵件按照緊急且重要、緊急不重要，重要但不是特別緊急，不重要不緊急，四個象限進行劃分，接下來一天的工作中穿插解決。

以下是對郵件處理的簡單的象限圖：

時間象限圖

有時候放個周末或者長假，那麼未讀的郵件有時候好幾十甚至將近100，一封一封的去處理查看肯定費時，這個時候就要活用郵箱的功能，我習慣設置各種規則，分不同的文件夾，每次新啟動一個項目就會設置好規則，一鍵運行規則，然後再根據象限圖中的方法去處理。

除了最基本的溝通方式郵件，有時候還需要輔助其他的方式，來推動事情的解決速度，特別是緊急的情況。我一般會採用郵件發出——電話通知——微信響應的順序，根據不同的情況，靈活的運用各種溝通方式，甚至於直接face to face，視頻會議等。

二、追根尋底的習慣

在根據項目的不同階段，都做到追根尋底。

需求階段，總是習慣一次性把各種需求文檔，各種設計稿，交互，還會把備忘錄打開，一邊了解需求，一邊把不清楚的，有歧義的地方，圈圈畫畫，記下，大概過一遍之後，結合上述各種溝通方式，進行逐一確認和補充，不放過任何一處紕漏。

用例編寫階段，我習慣藉助不同的工具和展現形式，一步步細化來完成。

用xmind來理順邏輯用例，列好大綱，接著用excel細化用例，遇到有變動的地方會跟開發，產品再次確認，或者詢問邏輯實現方式，然後導入到平台中，後續執行中，如遇到跟初始的情況不同，有變動的，再在用例管理平台里進行少量的修改和新增。

三、善於借鑒，保持自我思維的習慣

每個人都有自己的思維，很多時候我們可以在保持自己原則思維的情況下，借鑒其他人的想法，方式等，說句俗話就是取其精華，去其糟粕。

以下簡單舉個例子：

用例是用來加固我對這個需求的了解，理順邏輯，從而幫助接下來的測試任務。

1.編寫設計時是從各個層次角度來考慮如何測試這個功能，可以借鑒一下其他人的設計思維。例如參加其他人的用例評審，看看其他人的用例等；

2.編寫用例，有時候是處於一個理想的狀態下進行設計，實際上，會因為各種原因導致邏輯的改變或者一些細節只有在實際測試中才能發現，所以用例也只是一個指導的作用。

3.經過了設計編寫用例的梳理，對大致的測試方向實際在腦中已經有一個概念了，個人不推薦看著用例測試，很多時候，就能自主的進行更廣更深的測試，等到進行的一定程度了，這個時候回顧一下用例，可以查漏補缺。

所以一般情況下，我還是比較傾向於看交互，需求，只有對這個功能原型了解，我覺得才能發揮測試的舉一反三能力，而不是被圈在別人的思維中，可以借鑒，但不希望被禁錮住。

有時間還會偶爾去觀察一下其他同事報的bug，了解其他同事思考的維度，對比一下自己缺失的地方。

四、多用圖示的習慣

有時候文字很難表達清楚，用圖示來表示更清晰，上面說過了思維導圖的一個作用，用於剖析需求；編寫測試用例，除了用思維導圖，當邏輯依賴不同的條件得出不同的結果，可以使用判定表來整理用例。

某個功能的思維導圖圖示：

思維導圖

對於比較複雜的邏輯，可以通過流程圖來梳理，加強記憶，百度百科有這麼一句話，千言萬語不如一張圖，從而可以看出，通過流程圖，能夠對需求解讀的更清晰；如圖：

流程圖

在其它的地方也可用圖示來分析，例如分析bug，用表格，用餅圖等，項目問題總結，用魚骨圖等，以下圖示是舉例。

圖示一

圖示二

圖示三

五、測試的習慣

模塊化測試階段，這個時候我會習慣兩台手機一起（對於app測試而講），iOS和android一起操作，然後連上電腦，打開各種抓包工具，日誌平台，既可以看同時對兩個端進行測試，檢查兩個端樣式，操作方式，也可以了解兩個端處理的方式，過程中也可以順利的抓取到前端日誌，也會把redmine等管理bug的工具打開，一段時間了解bug的進度，有時候結合修改後的bug一起測試。

有時候還會把視覺和交互打開，進一步確認實現不一致的地方。

對於驗證bug的習慣，比較傾向於開發備註原因影響範圍，這樣一來，驗證bug就可以在在開發修改過的文件以及備註的影響點進行bug的回歸，不僅僅是驗證當前bug的問題，還要對其他相應的影響範圍進行回歸。如果開發人員沒有標註原因，對於一些複雜點的bug，也最好還是跟開發諮詢一下原因，影響的範圍，驗證也最好是備註好驗證的點。

相信很多測試同學都有相同的習慣，如果有其他提高效率的方式或者好的習慣，歡迎提出，以下是我諮詢一些同學關於測試習慣，經過同意可以展示出來的，中心思想大抵一致：

@Nancy：我覺得我是讓開發給評估風險，重點影響哪裡，這樣結合經驗，快速評估測試重點，相對好些效率稍微高點

@Celina：大需求就先測試主流程，主流程通了再過細節，有些內容錯了就得重新測試的，能預估到哪個點容易出錯就先測試哪個點，時間緊的話，就看自己所有的測試內容中有耦合的部分不，有的話就規劃一起測試

@王丹：還沒開始測試的時候可以根據細化捋清業務流程，整理測試場景，確認環境，準備數據；後續測試發現問題，解決之後驗證問題等