testkuaibao|軟體測試自學公眾號
前言
說到專項測試，大家的第一反應可能是流量測試、電量測試、弱網路測試等及其對應的專項測試工具。除了以上，關於專項測試我們還要知道：
1） 我應該在什麼階段去做專項測試。
2） 每個階段做什麼。
3） 應該做到什麼顆粒度。
4） 怎麼樣才算完成了專項測試。
下面我們就來聊聊專項測試在專案不同階段的不同策略及專項基線、規範。
一、專案中的專項實踐流程
1.1 第一階段：專案需求階段
該階段屬於專案需求說明書、測試分析、系統分析三個文件的評審階段。開發並沒有編寫程式碼，測試也沒有編寫用例，僅僅都在做專案需求和研發架構的確定。這裡簡單說明下三個不同的文件。
1。
需求說明書
：PRD。就是一般的需求說明文件，各企業應該都類似。
2。
系統分析
：一般分成APP的系統分析及後臺的系統分析。包括以下幾點：
1） 系統或者模組架構。
2） 系統或者模組的互動時序圖。
3） 每個模組的詳細的業務描述。
4） 本次新增哪些功能。
5） 本次哪些模組、系統會有升級。
6） 影響的風險評估。
7） API的描述以及詳細的引數型別列表。
往往這些都會有很詳細的說明，之後的實施則完全根據這份文件來做。
3。
測試分析
：測試分析往往都在系統分析之後，測試分析和往常的checklist有點類似，但又不僅僅只是checklist，它基本包括了以下幾點：
1） 本次測試的功能點範圍。
2） 詳細的業務描述以及業務對應的前後端的系統時序圖。
3） 每個業務對應的測試點，類似於checklist。
4） 每個模組的測試負責人等相關資訊。
這三個文件都要有評審會議，產品、測試和開發都需要參加。我們這提到的專項測試的流程和技術則是讓業務組中的測試人員去實踐的，針對某個模組做深入的專項測試，而不是用工具組那類整合的專項測試。
從上面描述上看可能覺得測試好像在這個過程中也不用做什麼，實際上專項測試人員要做的事情很多，而且其中還有一部分需要憑藉自己豐富的經驗來做判斷。
1） 需要深入去了解被測產品的研發架構，對產品有一個全面的理解。
2） 需要去制訂詳細的專項測試計劃。比如測試會選用哪些機型，哪些版本號，會測試哪些網路等。
3） 需要去深入瞭解被測產品到底有哪些需要專項特別注意的功能點。
4） 需要去緊跟開發人員每天check in的程式碼。這並不是需要專項人員去做所謂的CR（Code Review），更多的是去了解開發的一些細節，每天跟著會比最終一股腦地去看程式碼有效得多。
5） 需要去評估哪些場景要測試哪些專項，哪些專項可能在技術上攻克有困難等。
接下來根據第一個階段，舉個實際的案例。
專項測試計劃書
（一） 本次專項要覆蓋的網路有：弱網、2G、3G、4G、WiFi（各個網路的上下行、延遲、丟包等資料全部根據國際標準資料來進行模擬），模擬的工具為ATC和Charles以及iOS開發者模式。
（二） 專項測試的場景都會包括以下三種：首次啟動、非首次啟動、靜默狀態。
（三） 要對比的競品有：A、B、C。
（四） Android使用的機型分別是Nexus6（CM rom或者原生rom）、小米9（開發者系統）以及魅族16s（Android10）。iOS使用機型分別是iPhone8（12。4）、iPhone XR（12。0），有必要的話可能還需要一個越獄的機器。
（五）本次專項會涉及的功能場景有a、b、c等（這裡需要詳細列出場景以及對應要測試的專項型別）。
（六）重點專項：定位服務、長連結機制、Push相關機制等。
（七）其他：目前Android和iOS針對A專項的技術所獲取的資料顆粒度比較粗，需要進一步探索相關深入的技術和測試工具。
當然在詳細的計劃書中，我們需要詳細的描述每項專項到底使用什麼技術，獲取資料的顆粒度，包括單位以及達到什麼樣的目的等。其中也有與技術不相關的東西，包括業務分析、場景分析等。
1.2 第二階段：功能測試與修復bug
其實在第一階段和第二階段我們還有個過渡的階段——開發編寫程式碼和測試編寫測試用例的階段。該階段之前已經提到過一部分，也就是CR。但同樣的，專項人員在這個過程中要做三件事：
1） 跟著check in的日誌對產品程式碼有一個及時的瞭解。
2） 初步對程式碼進行掃描。比如FindBugs、Lint等。
3） 準備好本地編譯除錯程式碼的環境。Mvn、Gradle等，很多產品模組分的很細，而且也有自己的打包工具和流程，所以在這個階段專項人員整理清楚這些很重要。
接下來說第二階段。在該階段，專項團隊會根據專案在每一週的實際情況以及本次專案迭代功能的新功能和影響功能制定對應的測試重點。包括但不僅限於以下幾點：
1） 跟蹤程式碼。
2） 耗電量測試。
3） 風險評估。
4） ……
在第二階段以周為單位來做彙報，一方面在修復bug的過程中程式碼變更更大，同時功能也沒穩定下來。另一方面也和公司專案架構模型有關係。所以這裡的流程和方法也要視公司專案而定，不要按部就班。
1.3 第三階段：整合測試與灰度測試
終於到了最後一個階段了，在該階段功能基本上也穩定了，應用的各個模組都會進入最後的整合測試。一般稍大規模的公司就會進行RC測試以及灰度測試。在這個時間點，我們就需要進行最後一輪完整的專項測試了，根據我們最初定的專項測試計劃即可。不過由於最後的這段時間基本上臨近釋出了，所以以天為單位來做彙報，而且在這個階段內專項的缺陷優先順序會比其他相對應的功能缺陷更高（當然，具體問題具體分析）。那麼最終需要在釋出時間點之後給出一個完整的詳細報告。
二、專項基線和規範
專項基線和規範也是專項測試中最為關鍵的一塊。但是基線和規範這個資料是最為機密和不可複用的。這裡只簡單說下實踐的思路。
首先，基線本身的來源一般有以下三種，重點是顆粒度要儘可能的細。
1） 結合自己產品的幾次迭代所產生的資料。
2） 結合競品的專項資料。
3） 拍腦袋。
可能很多人說大部分情況都是第三種，因為前兩種相對來講還是要有很多資料和技術積累才能夠獲取的。一般結合這三者的資料，然後透過團隊的討論評審最終可以定出初步的專項基線。其實大家不要小看拍腦袋，尤其是定基線這種工作往往會是產生分歧的，這個時候就需要拍腦袋先定下來，畢竟基線是一個目標，不是一個死線，制定基線也是為了讓大家在做專案的時候奔著這個目標前進，而不是說不達標就不能release。在很全的專項測試報告中可能會有許多不達標的指標存在，但是隻要是風險不高的，或者說與之前的版本相比是進步的，那麼不會block整個專案的釋出。
基線的指標很多。幾乎可以說每個專項背後都是有基線的，比如CPU、記憶體、圖片大小、流量大小、弱網響應等。每一項都是需要有具體的資料來作為基線標準，資料的獲取方法和詳細程度在專項的基線中有著決定性的意義。比如：
1） 客戶端中的小縮圖流量控制在小於5KB。
2） 客戶端中的中縮圖流量控制在25KB左右。
3） 客戶端中的大縮圖流量控制在50KB左右。
類似上面的這些指標等都是需要這樣去細化的。僅僅有標準和基線還是不夠的，更多地需要有程式碼編寫規範、埋點規範、最佳化我們自己產品的架構等，只有這些做好了，才能夠真正地去保證我們的專項質量，所以作為測試來講不能老是兜著問題，更多地需要去最佳化、改變導致這些問題的源頭。
關於基線和標準還有一個重要的注意點就是需要去固定一些Android和iOS的測試機型、系統版本以及應用的型別。做專項最忌諱的就是每次測試環境、機型、應用都不同，說明不了問題也就罷了，更會擾亂整個專案組的判斷。
三、總結
專項測試一定要結合業務背景、產品技術實現、產品定位等各個方面的資訊來做，否則就是空中樓閣。掌握了工具的使用並不是關鍵，落地和找到問題才是主要的。專項測試既需要面的廣度也需要深度。
注：引用書籍-《大話APP測試2。0-移動網際網路產品測試實錄》、搜狗測試
軟體品質評測系統-任務分發管理平臺
關於sdk測試，這些你都知道嗎？
測試資料不會造？可以用這個工具
介面測試之檔案重定向法
覺得文章不錯就點個在看唄，轉發就更好了