前言
1) 我應該在什麼階段去做專項測試。
2) 每個階段做什麼。
3) 應該做到什麼顆粒度。
4) 怎麼樣才算完成了專項測試。
下面我們就來聊聊專項測試在專案不同階段的不同策略及專項基線、規範。
一、專案中的專項實踐流程
1.1 第一階段：專案需求階段
該階段屬於專案需求說明書、測試分析、系統分析三個文件的評審階段。開發並沒有編寫**，測試也沒有編寫用例，僅僅都在做專案需求和研發架構的確定。這裡簡單說明下三個不同的文件。
1.需求說明書：prd。就是一般的需求說明文件，各企業應該都類似。
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等(這裡需要詳細列出場景以及對應要測試的專項型別)。
當然在詳細的計畫書中，我們需要詳細的描述每項專項到底使用什麼技術，獲取資料的顆粒度，包括單位以及達到什麼樣的目的等。其中也有與技術不相關的東西，包括業務分析、場景分析等。
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測試之專項測試
前言 1 我應該在什麼階段去做專項測試。2 每個階段做什麼。3 應該做到什麼顆粒度。4 怎麼樣才算完成了專項測試。下面我們就來聊聊專項測試在專案不同階段的不同策略及專項基線 規範。一 專案中的專項實踐流程 1.1 第一階段 專案需求階段該階段屬於專案需求說明書 測試分析 系統分析三個文件的評審階段。...
測試規範包括哪些 功能測試流程規範建設
測試規範 測試計畫，描述了要進行的測試活動的範圍 方法 資源和進度，確定出測試項 被測特性 測試任務 誰執行任務 各種可能的風險。通常測試計畫的範圍包括以下幾點 1.描述測試的各個階段 例如，單元測試 整合測試或系統測試 並說明本計畫所針對的測試型別 如功能測試或效能測試 2.簡要地列出測試物件中將...
測試規範包括哪些 跟我學 測試計畫如何制定？
測試計畫旨在說明各測試階段任務 人員分配 時間安排 測試要點 工作規範等。測試計畫在策略和方法方面說明如何計畫 組織和管理測試專案。測試計畫包含足夠的資訊使測試人員明白專案需要做什麼是如何運作的。測試計畫不包括測試用例的細節和系統功能的詳細資訊。測試計畫應包含以下6個方面的內容 1 why 為什麼要...