前言
說到專項測試，大家的第一反應可能是流量測試、電量測試、弱網絡測試等及其對應的專項測試工具。除了以上，關于專項測試我們還要知道：
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等(這裡需要詳細列出場景以及對應要測試的專項類型)。
| 場景 | 網絡流量 | 電量 | ... |
|---|---|---|---|
| A | √ | ... | |
| B | √ | ... |
(六)重點專項：定位服務、長連結機制、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-移動網際網路産品測試實錄》