[[353844]]

大家好，我是安醬。

今天我們用一個小故事來聊一聊測試與開發之間的那些事兒。

1

小美到公司的時候已經九點半了，但是偌大的辦公室室卻還沒幾個人。早來的幾位同事還都是跟自己同屬一個組的QA同學。

互聯網黑話：

QA：QUALITY ASSURANCE質量保障工程師，俗稱測試。

RD：Research & Develop研發工程師，俗稱開發。

「早呀各位!」小美熱情的對身邊的同事打起了招呼。小美對自己目前的工作還是挺滿意的，她不太喜歡編程，但是又熱愛著互聯網行業，所以軟件測試對于她來說是兩全其美的崗位。

「不早了，都快十點啦。不過那群RD估計都還沒出門呢?！挂晃煌绿痤^打趣道，目光還朝旁邊的區域瞅了一眼，那兒還是空蕩蕩的。

小美聳聳肩，努了努嘴，似乎在表示這不是很正常的情況嘛。隨后從背包中掏出筆記本，開始整理一下今天要測試的需求。

過了一會，小美旁邊那片區域慢慢的來人了，整個辦公室開始變得嘈雜起來。

「臥槽，我昨晚兩點才下班!本來十點就打算走了，沒想到一個JIRA就過來了，跑都沒跑掉!」

「別說了，我這還有幾個歷史遺留bug，你這么有空來幫我看看吧。」

「別別，那還是算了?！箖晌籖D互相吐槽了一番，也沒繼續接茬了。辦公室瞬間安靜了下來。

2

眾所周知，測試和開發之間始終保持著迷一樣的關系，他們之間的聯系最為緊密但又互相看不慣。作為質量保障人員，QA的工作就是發現并提交bug;而RD自然是對bug敬而遠之。

小美不一會就開始測試今天的第一個需求。這是一個需要客戶端及服務端聯調的需求。經過了多次測試，她發現這是客戶端穩定可復現的bug，問題就在于客戶端并沒有觸發相應的接口請求。

她首先通過公司內部的通訊工具小窗了一下客戶端開發的RD，將測試結果告知于他。同時，她熟練的打開JIRA平臺，迅速的將這次測試的信息填上并提交，包括測試版本，問題描述，處理人，修復時間等。

等她搞定了這些操作后，發現她給RD同學發的那條信息還處于未讀狀態。她扭頭看了下RD的位置，發現他正在位置上，皺著眉頭正盯著屏幕。

算了，還是去找他吧。猶豫了片刻，小美還是決定起身去當面把這個問題描述清楚。

「你昨天提的MR有問題呀，那個接口請求就沒有觸發。我試過很多次了，抓包也沒抓到。服務端是沒問題的。」

「不可能吧，我自測都沒問題的。我測的時候肯定抓到了，沒道理的。反正在我這是好的。不信你看嘛!」

小美早就意料到會是這么個回復，但是臉上并沒有顯露出來。仍然一臉懇切的望著RD同學，看著他緊張的演示。

小美在入職之前其實并不理解QA是做什么的，聽人說就是用鼠標在電腦上點點點，測測有沒有響應什么，天天就是干重復的工作。但是也聽說QA對于軟件的更新換代至關重要。

只不過她現在也沒空想這些問題了，專心的看著RD同學的演示。不一會兒，抓包工具還真彈出了一條網絡包。

得，又是這樣。在小美短暫的測試生涯里，經常出現這種所謂「無法穩定復現」的bug，有苦說不出。

小美覺得自己還是挺喜歡QA這個崗位的，入職以后才真正體會到找到Bug時的愉悅，但也偶爾能感受到開發提刀的沖動。

這不，RD同學經過一系列的操作，成功的證明了自己，的確在他那兒是沒問題的。他扭頭盯著小美，嘴角上揚，抖了下眉頭。

「行吧，那可能是本地設置或者線上環境的問題。等我確認下再來找你?！剐∶酪矝]啥辦法，只能先去確認下兩邊的版本或環境有沒有差異。

這估計是小美的工作日常了，畢竟很多bug的復現和定位都沒那么容易。而事實上測試小姐姐每天除了和開發小哥哥講道理「chao jia」之外，他們每天的工作內容主要是什么呢?

3

這里我們便去采訪了下小姐姐，用她的親身經驗來告訴大家，在一個具體的測試項目里面，測試需要做的工作和流程有哪些。

大多數沒有真正接觸過軟件測試的同學都有一個誤區，覺得測試就只是點點點。那測試小姐姐就要問了，你知道為啥需要點點點?

為什么你看來這么簡單的點點點還需要大量的測試人員去實現?你知道一個軟件版本的發布沒有測試人員的點點點，它的風險有多大嘛?

那在一個測試項目中測試人員需要做些什么呢?可以簡單歸納為以下幾點：

• - 測試計劃和方案
• - 編寫測試用例
• - 搭建測試環境
• - 執行測試用例
• - 提交Bug
• - 管理跟蹤bug
• - 復測
• - 穩定性測試、壓力測試等
• - 編寫測試報告

以上步驟并不是固定的，可能會根據不同的公司不同的產品和性質有變化，一些較為成熟的測試項目大體上是一致的，具體的測試內容會不同。

測試計劃和方案這里主要是測試負責人需要做的事情啦，包括人員安排、任務劃分、進度安排、文檔要求、測試工具等等的。(咱也不知道，咱也不敢問呀～)

編寫測試用例，是測試人員的基本功也是硬實力呀，優秀的測試用例，不僅可以提高測試的質量，還能保證測試更加全面，盡可能地發現軟件存在的問題和風險。

需要參考需求文檔、設計文檔等等，寫好之后需要評審。至于如何寫好測試用例，這里可以大作文章了，就先不鋪開講了。

搭建測試環境正所謂磨刀不誤砍柴工，為了保證測試的順利進行，那就要提前做好測試的準備工作。

這一步的目的是要保證測試環境的獨立，確保測試環境穩定和版本的正確~萬事具備，那就開始測試啦～

執行測試用例(有事找開發，沒事找bug～)講到這里不得不跟大家分享我踩過的坑。

4

許多人在執行測試用例上習慣按照順序依次往下測，根本不管測試用例的優先級，實際上這樣是不對的。一般應該先做冒煙測試，這是最為基本的，冒煙都沒過，那些低優先級的也沒必要繼續測了。冒煙通過后，再依次按照高-中-低優先級依次執行，這是最為高效的測試方式。

管理跟蹤Bug，測試過程中，難免會找出一個一個又一個的bug, 當遇到一個bug，首先應該確認并非因為自己測試方式或者操作不對造成的(別問我怎么知道的，開發小哥的眼神會讓你明白的~)，其次要確認是否滿足需求文檔中的要求。

如果確實不滿足需求，那你可以理直氣壯給開發小哥哥提bug, 如果需求文檔中并沒有涉及到，那就跟開發小哥一起評估，還是不能達成統一，那可能就需要找上級或者產品經理一起評估決定。

開發小哥按照你提交的bug記錄進行版本的修復和更新，并給你最新的版本，你需要進行bug驗證，驗證通過后不要忘記更新bug的狀態(并順帶夸獎一下開發小哥，畢竟他開心了，你也好意思督促他繼續改Bug呀～);要是驗證不通過，重新掛起(不要管開發小哥一個勁說著：在我這明明就成功的呀～)。

除此之外還需要進行穩定性測試、壓力測試等，需要利用一些自動化測試工具完成，或者自己寫一些測試腳本，分析測試數據，提出優化方案或存在的風險。

編寫測試報告在不斷的發現Bug-修改Bug-復測Bug- 關閉Bug，直到軟件達到測試發布的要求，沒有重大Bug的存在，那就需要整理測試報告，用客觀和數據的方式總結和評估測試的情況。待測試報告通過評審后，就可以正式發布軟件啦～

綜上，測試也是需要全面發展的，比如，要有良好的溝通能力(避免跟開發小哥講道理的時候不會吵起來～);要具備專業的技術能力，掌握測試技術更好的執行測試任務;要有定位分析能力，發現Bug可以分析問題進行準確定位，幫助開發小哥更好地修復Bug。

作者簡介：我是安醬，一個稀里糊涂地進了大廠的業余碼農。講解全棧技術，分享菜雞的打怪升級之路。

本文轉載自微信公眾號「業余碼農」，可以通過以下二維碼關注。轉載本文請聯系業余碼農公眾號。