[[353844]]

大家好，我是安醬。

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

1

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

互聯(lián)網(wǎng)黑話：

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

RD：Research & Develop研發(fā)工程師，俗稱開發(fā)。

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

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

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

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

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

「別說了，我這還有幾個歷史遺留bug，你這么有空來幫我看看吧?！?/p>

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

2

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

小美不一會就開始測試今天的第一個需求。這是一個需要客戶端及服務(wù)端聯(lián)調(diào)的需求。經(jīng)過了多次測試，她發(fā)現(xiàn)這是客戶端穩(wěn)定可復(fù)現(xiàn)的bug，問題就在于客戶端并沒有觸發(fā)相應(yīng)的接口請求。

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

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

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

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

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

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

小美在入職之前其實并不理解QA是做什么的，聽人說就是用鼠標(biāo)在電腦上點點點，測測有沒有響應(yīng)什么，天天就是干重復(fù)的工作。但是也聽說QA對于軟件的更新?lián)Q代至關(guān)重要。

只不過她現(xiàn)在也沒空想這些問題了，專心的看著RD同學(xué)的演示。不一會兒，抓包工具還真彈出了一條網(wǎng)絡(luò)包。

得，又是這樣。在小美短暫的測試生涯里，經(jīng)常出現(xiàn)這種所謂「無法穩(wěn)定復(fù)現(xiàn)」的bug，有苦說不出。

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

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

「行吧，那可能是本地設(shè)置或者線上環(huán)境的問題。等我確認(rèn)下再來找你。」小美也沒啥辦法，只能先去確認(rèn)下兩邊的版本或環(huán)境有沒有差異。

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

3

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

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

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

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

• - 測試計劃和方案
• - 編寫測試用例
• - 搭建測試環(huán)境
• - 執(zhí)行測試用例
• - 提交Bug
• - 管理跟蹤bug
• - 復(fù)測
• - 穩(wěn)定性測試、壓力測試等
• - 編寫測試報告

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

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

編寫測試用例，是測試人員的基本功也是硬實力呀，優(yōu)秀的測試用例，不僅可以提高測試的質(zhì)量，還能保證測試更加全面，盡可能地發(fā)現(xiàn)軟件存在的問題和風(fēng)險。

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

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

這一步的目的是要保證測試環(huán)境的獨立，確保測試環(huán)境穩(wěn)定和版本的正確~萬事具備，那就開始測試?yán)病?/p>

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

4

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

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

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

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

除此之外還需要進(jìn)行穩(wěn)定性測試、壓力測試等，需要利用一些自動化測試工具完成，或者自己寫一些測試腳本，分析測試數(shù)據(jù)，提出優(yōu)化方案或存在的風(fēng)險。

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

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

作者簡介：我是安醬，一個稀里糊涂地進(jìn)了大廠的業(yè)余碼農(nóng)。講解全棧技術(shù)，分享菜雞的打怪升級之路。

本文轉(zhuǎn)載自微信公眾號「業(yè)余碼農(nóng)」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系業(yè)余碼農(nóng)公眾號。