概述

大家好，我是洋子。有很多粉絲朋友目前還是在做功能測試，日常會遇到很多繁瑣，棘手的問題，今天分享一篇在testerhome社區(qū)的帖子《三年功能測試，測試工作吐槽》

原文鏈接https://testerhome.com/topics/38546

這篇文章基于中小公司的工作經(jīng)驗，中小廠的測試流程往往沒有大廠那么規(guī)范，也會遇到很多挑戰(zhàn)，來看下他是怎么解決的

問題一：測試時間評估

這是一個工作日常經(jīng)常需要回復(fù)的問題，理論上 測試這邊要做出較科學(xué)合理的回復(fù)，那就要將
【需求變更】
【開發(fā)進(jìn)度延誤】
【bug 修復(fù)不穩(wěn)定】
【復(fù)雜業(yè)務(wù)流程】
【測試環(huán)境不穩(wěn)定】
【上下游服務(wù)依賴】
【人員資源】
【是否引入新技術(shù)】
【回歸范圍】
等等不確定因素考慮進(jìn)去，再多方溝通確定才能獲得相對合理的答案。但現(xiàn)實里 一個功能測試會同時測試幾個項目，通常是最晚得知新需求的內(nèi)容，需求評審會議都是被冷不丁拉入，然后產(chǎn)品劈里啪啦講完后就讓你給個測試時間，方便他安排工作。

1. 臨時進(jìn)入會議，需要你馬上給個估計時間場景：

• 【解決方法】詢問開發(fā)所用的時間，將測試時間設(shè)定為開發(fā)時間的 50%、70% 或 80%（根據(jù)現(xiàn)場氛圍說自己的百分比）

2. 流程較規(guī)范，測試先拿到需求文檔進(jìn)行評估：

• 【解決方法】編寫完測試點，根據(jù)一條用例平均 5 分鐘的時間，然后根據(jù)一天實際能干活的時間，例如用 6 小時去粗劣計算天數(shù)，越多越好（測試時間肯定會被壓縮）

注意：如果覺得系統(tǒng)很復(fù)雜，自己無法正確評估，拉上你的領(lǐng)導(dǎo)/組長一起判斷，千萬別不好意思或者覺得這樣顯得自己很差，我們是功能測試，要學(xué)會哭慘！，任務(wù)太難或者太多就讓組長拉多一個人來幫忙。同時測試這邊投入的人力數(shù)量需要告知下產(chǎn)品，防止那種一旦看到時間有盈余，就瘋狂后期加需求的產(chǎn)品。

問題二：同一時間需要完成多項測試任務(wù)

大多數(shù)功能測試的現(xiàn)狀應(yīng)該差不多，通常是測試著 A 任務(wù)，就接到 B 任務(wù)的需求評審，已上線的 C 任務(wù)現(xiàn)網(wǎng)出現(xiàn)了些問題反饋需要你跟進(jìn)，然后測試組自動化的任務(wù) D 也要完成進(jìn)度，最后 C 任務(wù)根據(jù)用戶的一些反饋做了功能整改，拉你評審和排期

1. 需要當(dāng)天確定的任務(wù)：

• 緊急且重要、緊急但不重要、不緊急但重要、不緊急且不重要。四個級別分類任務(wù)，雖然老套，但是真的有用，事情一多時，人特別容易煩躁，這時候就需要一個指導(dǎo)思想

2. 多個周期任務(wù)：

• 依據(jù)截止日期， 根據(jù)任務(wù)的截止日期制定計劃。先處理最緊急的任務(wù)，確保不會因為延誤而影響項目進(jìn)度
  注意： 任務(wù)多頂不住就求救，別硬撐，看過應(yīng)屆生一個人測試著吃力不說，搞得老同事接鍋加班的

問題三：需求不明確

這應(yīng)該幾乎是所有功能測試都會遇到的問題，主要分為三種：

1. 一句話需求，甚至需求文檔寫在 txt 里，就一句話，eg:【充值滿 XX 元獲得獎勵】（本人真實經(jīng)歷）
2. 抄襲的需求，同為差不多的功能，拿了其他產(chǎn)品的需求文檔適當(dāng)做了修改就發(fā)出給研發(fā)
3. 全文字需求，無流程圖 無交互稿

情況一：一句話需求

老實說這種類型的產(chǎn)品一般都是愣頭青，你要是把需求文檔打回去，通常情況下只是從一句話需求變成十句話需求，解決不了問題，你還是要在時間內(nèi)完成測試

1. 測試這邊辛苦些，拿上述一句話的例子【充值滿 XX 元獲得獎勵】，列出不清晰的點：缺乏詳細(xì)活動規(guī)則說明、獎勵類型不明確、具體數(shù)值、活動觸發(fā)條件、用戶資格驗證條件、界面展示交互、獎勵發(fā)放的觸發(fā)時機等
2. 與產(chǎn)品經(jīng)理電話溝通，詢問有關(guān)背景、業(yè)務(wù)目標(biāo)、關(guān)鍵功能、用戶期望等方面的問題，然后將列出的不清晰點發(fā)到大群并 @ 開發(fā)和產(chǎn)品，讓其在文檔里做補充
3. 千萬別和產(chǎn)品私聊然后自己一個人確認(rèn)需求，全部互動都要在大群

情況二：抄襲需求

通常拿來主義的產(chǎn)品都是很懶的，同時沒啥主見，甚至他會叫你去找他抄襲的那個產(chǎn)品聊，麻煩的點主要在于實際轉(zhuǎn)測后發(fā)現(xiàn)功能實現(xiàn)與文檔不一致，開發(fā)給的原因是其中的業(yè)務(wù)邏輯或用戶需求不適用于當(dāng)前項目

1. 轉(zhuǎn)測后，讓產(chǎn)品提前先體驗，讓產(chǎn)品先滿意后再測試
2. 其他參考情況一

情況三：全文字需求

通常這類產(chǎn)品還挺固執(zhí)，認(rèn)為自己描述得很清楚

1. 解決方式基本和情況 1 一致

注意：以上三種情況，務(wù)必都要告知自己的直屬領(lǐng)導(dǎo)，同時減少和產(chǎn)品的私聊，多在大群里聊，多留刷鍋的證據(jù)

問題四：線上出現(xiàn) bug

線上出現(xiàn) bug 時，大多第一時間會很慌，生怕是自己的鍋，所以步驟很重要，一方面防止非自己的鍋被人甩在身上，一方面要顯得自己是個負(fù)責(zé)的成熟測試

通常都是群里忽然炸鍋，截圖出 bug 點，然后產(chǎn)品們嘰嘰喳喳

1. 冷靜點，群里先發(fā)一句：“我定位下，看能不能復(fù)現(xiàn)”
2. 現(xiàn)網(wǎng)嘗試復(fù)現(xiàn) bug，如果 bug 能百分百復(fù)現(xiàn)，@ 相關(guān)開發(fā)排查，并發(fā)出便于定位的相關(guān)的日志和信息
3. 測試環(huán)境嘗試復(fù)現(xiàn)，若能復(fù)現(xiàn)，查詢下測試用例有無覆蓋當(dāng)前的場景【確保不是測試用例執(zhí)行遺漏，執(zhí)行遺漏和覆蓋遺漏是兩個不同的鍋，執(zhí)行遺漏是態(tài)度問題，很嚴(yán)重的】
4. 如果是自己的鍋，記得表現(xiàn)出積極解決問題的態(tài)度，配合開發(fā)檢查修復(fù)狀態(tài)，并同步到大群，要將 bug 出現(xiàn)的原因和修復(fù)方法了解清楚，方便后續(xù)做復(fù)盤和回答領(lǐng)導(dǎo)的詢問。
5. 如果是他人/環(huán)境的鍋，要表現(xiàn)出超級積極解決問題的態(tài)度，將 bug 原因和修復(fù)情況實時同步到大群

注意： 遇到線上 bug，一定不要急著瘋狂甩鍋和疊buff（這個在測試階段時就要上的護(hù)甲，測試報告提示風(fēng)險和大群聊天記錄），要表現(xiàn)出先解決問題的態(tài)度，同時搜索對自己有利的條件。

問題五：測試報告風(fēng)險規(guī)避

主要有幾點：

1. 測試日報中，阻塞測試進(jìn)度 bug、偶現(xiàn) bug、p0 級未解決 bug 需要標(biāo)紅加粗放在測試報告醒目的地方
2. 對于測試環(huán)境無法完美模擬現(xiàn)網(wǎng)環(huán)境的測試場景，需要在報告中標(biāo)紅加粗體現(xiàn)（風(fēng)險多說不虧）
3. 測試進(jìn)度根據(jù)測試用例執(zhí)行的百分比來寫

問題六：測試時間不足

造成測試時間壓力的通常有以下幾種：開發(fā)時間延期、產(chǎn)品上線日期提前【大 boss 給的壓力】、需求變更、測試人力資源變動、測試物料阻塞、復(fù)雜的業(yè)務(wù)邏輯。通常遇到時間不足，最好的解決方式還是加人，其他的只能前期進(jìn)行預(yù)防```

• 開發(fā)延期：喜聞樂見的情況，鑒于經(jīng)驗通常都是延期 1-0.5 天，所以測試時間評估一般都要在自己評估的時間上至少 +1 天，同時保持在開發(fā)轉(zhuǎn)測時間的前一天問下開發(fā)進(jìn)度的習(xí)慣。如果開發(fā)給了進(jìn)度不樂觀，及時同步給產(chǎn)品和測試領(lǐng)導(dǎo)，看產(chǎn)品是否可以調(diào)整時間或者領(lǐng)導(dǎo)這邊加測試人力。將測試壓力盡量提前告知，給測試領(lǐng)導(dǎo)和產(chǎn)品有調(diào)整分配的時間，不要依賴開發(fā)去反饋

• 產(chǎn)品上線日期提前：沒有任何方法預(yù)防，一般大老板開口了，測試領(lǐng)導(dǎo)比你還緊張，會積極詢問你測試進(jìn)度情況和風(fēng)險，你這邊要是沒把握，可以提出增加人力的要求。

• 需求變更： 需求變更也是很常見的，特別是都轉(zhuǎn)測了，產(chǎn)品那逼還在每天優(yōu)化更新他的需求文檔。這里需要預(yù)防一個坑：你要截圖保存他轉(zhuǎn)測前的最后一次需求文檔并發(fā)到大群 @ 相關(guān)人，防止后面現(xiàn)網(wǎng)出現(xiàn)需求不一致情況時，產(chǎn)品拿著他未同步且更新過的文檔來興師問罪。到時你百口莫辯，特別是測試地位比較低的公司，產(chǎn)品修改需求是不跟測試及時同步的。 時間上也以每次變動的大小產(chǎn)生的影響，記錄在測試報告上，規(guī)避背鍋的風(fēng)險。

• 測試人力變動： 原本兩個人測試的任務(wù)，因為其他原因變成一個人。這也是很常見的情況，特別是兩個人當(dāng)初分好了測試范圍，你這邊只了解和評估了自己的范圍，對其他人那部分并不了解，無形之中增加了后期的測試壓力和時間。這種情況通常沒啥好的解決方法，記得要哭慘，要讓測試領(lǐng)導(dǎo)和產(chǎn)品去協(xié)調(diào)。別一個人傻傻的硬撐瘋狂加班

• 測試物料阻塞：電商類型的項目通常涉及一些消費券的申請和配置，同時這些券的使用還帶風(fēng)控判斷。測試這邊要根據(jù)情況，轉(zhuǎn)測前提前溝通準(zhǔn)備好測試物料，申請需要用的白名單和權(quán)限，熟悉好對應(yīng)的配置系統(tǒng)。防止正式轉(zhuǎn)測前，被一堆權(quán)限和申請的事情嚴(yán)重拖延到進(jìn)度。

• 復(fù)雜的業(yè)務(wù)邏輯： 具體情況具體分析，根據(jù)經(jīng)驗，面對復(fù)雜的業(yè)務(wù)邏輯，最好的方法就是編寫清晰、詳細(xì)的測試用例。對自己要有 B 數(shù)，評審階段感覺吃力就求救兵

問題七：用例執(zhí)行困難

• 用例執(zhí)行困難，通常是開發(fā)質(zhì)量差導(dǎo)致

目前感覺最好的辦法：轉(zhuǎn)測前，出一份冒煙用例給開發(fā)，通過冒煙用例后才能轉(zhuǎn)測，否則主流程測試阻塞，只要代碼有大改動，基本都要重新測。測試地位比較低的公司，可以把這個流程安利給測試領(lǐng)導(dǎo)和產(chǎn)品，讓領(lǐng)導(dǎo)去推動

問題八：測試數(shù)據(jù)陷阱

常出現(xiàn)于前端開發(fā)，轉(zhuǎn)測時給你的 mock 數(shù)據(jù)與實際現(xiàn)網(wǎng)數(shù)據(jù)結(jié)構(gòu)不匹配，如果你是比較擅長 mock 數(shù)據(jù)和做代碼 review 的，通常還挺容易踩這種坑，拿著這個錯誤的數(shù)據(jù)模板做了多個邊界值和數(shù)據(jù)類型變化測試，代碼對每個數(shù)據(jù)的處理邏輯也是正確的。然后發(fā)布到現(xiàn)網(wǎng)就報錯無法交互

• 對開發(fā)要保持懷疑的態(tài)度： 驗證環(huán)節(jié)需要接入現(xiàn)網(wǎng)數(shù)據(jù)去看測試頁面的響應(yīng)是否正確

問題九： 業(yè)務(wù)自動化實現(xiàn)

很多公司的業(yè)務(wù)通常都是未經(jīng)探討直接強行自動化的，UI 自動化能阻止就阻止，阻止不了就加入。對于接口/ui 自動化，老實說我一直覺得最好的提效方式就是找個市面上商業(yè)化的自動化平臺工具，直接買來就用（面過一個國企，他們就是這樣干的），都不用投入什么人力，付費工具那點錢對公司來說也不多，測試這邊還能把精力放在業(yè)務(wù)上，有需求就給技術(shù)方提，這才是最好的提效方式。

可惜現(xiàn)在都要抽出一部分人力去搞這種做完很少人用且不好用的平臺，搞笑的是這些平臺的技術(shù)難點都集中在前后端框架業(yè)務(wù)實現(xiàn)，反而能在業(yè)務(wù)中起到多大作用的考慮倒是最低的，基本還是走的請求返回再斷言那套，或者更魔幻點的 UI 自動化都給你加上 AI 賦能尋找控件。。。。。其實大部分都是把實現(xiàn)過程復(fù)雜化，然后起作用的還是你用最原始的 pytest+request 組合去斷言那套

• 公司最好的方法就是跟隨大眾，自動化技術(shù)能力基本都是測試標(biāo)配了，但是能把自動化設(shè)計好的估計沒幾個