第1章 測試觀概述

1.1 引言

在正式介紹iOS測試前，先為讀者引入一個思  考問題：一千個人有一千種測試觀，那么測試人員到底應該持有何種測試觀？我們先來看看測試的定義發展史。

20世紀60年代：軟件開發過程中，將測試等同于“調試”。

1957年，軟件測試區別于調試，成為一種發現軟件缺陷的活動。

1972年，在北卡羅來納大學舉行了首屆軟件測試正式會議。

1975年，John Good Enough和Susan Gerhart在IEEE上發表了文章《測試數據選擇的原理》，從此軟件測試被確定為一種研究方向。

1979年，在Glen ford Myers的《軟件測試藝術》中，定義“測試是為發現錯誤而執行的一個程序或者系統的過程”。

1983年，Bill Hetzel在《軟件測試完全指南》中指出，“測試是以評價一個程序或者系統屬性為目標的任何一種活動，是對軟件質量的度量。”

2002年，Rick和Stefan在《系統的軟件測試》一書中對軟件測試做了進一步定義，“測試是為了度量和提高被測試軟件的質量而對測試軟件進行工程設計、實施和維護的整個生命周期過程。”

軟件測試的經典定義：在規定的條件下對程序進行操作，以發現程序錯誤、衡量軟件質量，并對其能否滿足設計要求而進行評估的過程。——百度百科

以上測試（軟件測試）的定義都沒錯，那么測試工程師應該怎么做呢？

通俗一點來解釋，筆者理解的測試為：測試=工程效率+品質管理。相應地，測試人員做的事情就是提升工程效率，做好品質管理。引用谷歌團隊的一段話[1]：Essentially, every day we ask ourselves, “How can we make our software development process more efficient to deliver products that make our users happy? ”其中“make process more efficient”可以理解為工程效率，“make users happy”可以理解為品質管理。就像上面谷歌團隊的這段話，測試人員應該每天思考怎樣提升團隊的研發效率，怎樣提升產品品質來讓用戶滿意。

1.2 工程效率

總體來說，工程效率就是研發效率（包含測試效率）。這里我們會把測試效率單獨提出來進行說明，因為這是與測試工程師相關度最大的工作。研發效率，其實就是讓產品上線的時間更快（在品質有保障的前提下），大多數時候是說與研發流程相關的（不局限于敏捷流程，Feature Team研發模型），例如包含但不局限于以下活動。

?需求評審：需求評審機制以及更新通知，避免需求有改動而沒有及時同步到相關角色。

?代碼質量：靜態代碼掃描，千行代碼缺陷率等。

?架構評審：代碼架構的討論以及評審。

?Bug流程：Bug生命周期，避免隨便修改Bug狀態以及備注缺失。

?Code Review：代碼評審，如果有代碼評審委員會就更好了。

?Dogfood：自己做的產品自己（項目各成員）先體驗。

?Showcase：完成某個特性，可以通過會議針對某個特性進行展示，一般由產品經理主持。

上面提到的活動，只有通過整個項目團隊（各個角色）的通力配合，才能更加高效。

再提一下測試效率，這大多數由測試工程師主導，也是測試工程師最主要的工作內容。測試效率包含但不局限于以下這些活動。

?測試周期：測試與研發周期是密切關聯的，包括迭代測試、集成測試、回歸測試、上線測試等，每個階段都要把握好測試效率和測試資源分配。

?測試設計：包括需求覆蓋度、用例覆蓋度、用例執行效率等。

?自動化測試：使用自動化執行的方式進行測試，可以快速得出測試結果，節省人力成本。

?靜態代碼分析：使用一定的工具來對代碼進行靜態掃描，提前發現代碼隱藏的問題。

?測試技術創新：通過對測試技術的創新，例如精準測試、機器學習等方式，來變更測試方式，大幅度提升測試質量和效率。

接下來舉兩個例子具體看下。

1.2.1 自動化測試

自動化測試于20世紀90年代才開始逐漸成熟，特別是敏捷研發的流行以及推崇的TDD模式，自動化測試也逐漸流行起來。對于自動化測試，我們還是得多關注其投入產出比（ROI），特別是對于UI自動化測試。業界自動化測試金字塔模型建議做單元測試或者接口測試多于UI自動化測試。關于自動化測試投入產出比，請參閱第6章介紹的內容。

對于iOS平臺上的自動化測試實踐，我們也有在不同方向上的嘗試（參見第5章），并都有不錯的收獲。相關自動化測試的開展還需要有一些自動化測試框架的支持（詳細自動化測試框架的內容會在第7章介紹）, QQ瀏覽器（iPhone）測試團隊主要移植Google開源的EarlGrey框架來作為自動化測試的基礎框架。本節先簡單介紹幾種主流自動化測試類型。

1．BVT（Build Verification Test）

業界現在流行持續交付的模式。那么每次持續集成編譯出包后，自動化會運行一些基礎功能測試用例，保證版本基礎功能可用，而不會因為新代碼合入影響基礎功能。這部分主要介紹UI自動化測試，當然，隨著版本需求的變更，維護成本也會增加。但對于QQ瀏覽器的UI變更還不是很頻繁，維護成本還相對可控，整體的投入產出也不錯，具體可參考第6章的內容。

2．監控類

根據產品的業務特點，我們會對產品進行一些監控，例如手機QQ瀏覽器（iPhone）項目實現了三種類型的監控測試，即終端視頻嗅探監控、終端feeds流短視頻可播性監控、終端資訊類監控。這部分監控的基礎框架和BVT實現是一致的，只是基于業務形態做了調整，采用的也是EarlGrey框架并進行了二次開發。可參考第6章關于測試框架的二次開發。

3．性能自動化測試

性能測試涉及各種數據的采集和分析，而數據采集往往很復雜并且非常耗時，性能自動化測試也都集中在數據采集這一塊。目前我們針對頁面速度、產品穩定性、電量、流量、內存等各個方面進行性能自動化測試的嘗試，詳細內容請參見第4章。

1.2.2 靜態代碼分析

靜態代碼分析就是在不執行代碼的情況下，通過一定的算法規則（詞法分析、語法分析、單函數分析、代碼段分析、數據流分析、資源分析、依賴鏈分析、更高級的智能邏輯分析）對整個工程的代碼進行分析，以此來找出代碼中的缺陷。這樣就可以提早發現問題，大大降低研發成本。美國軟件工程專家Capers Jones提出的軟件測試缺陷價值圖如圖1-1所示。

圖1-1中的三條曲線分別代表引入的缺陷、發現缺陷、缺陷修復成本。越是在前期發現的缺陷，修復缺陷的成本越低，越是到后期，修復缺陷的成本越高。通常來說，發現缺陷主要在功能測試、集成測試階段。

如果能夠在Coding階段發現大部分缺陷，就能大大降低修復缺陷的成本。靜態代碼分析技術恰恰能夠很好地在Coding階段發現部分代碼問題，這樣就能夠大大節約軟件開發成本。

經過實踐論證，iOS平臺比較好用的兩款工具如下。

?Clang的Scan-Build工具（下載地址：http://clang-analyzer.llvm.org/scan-build.html）。

?FaceBook的Infer工具（下載地址：https://github.com/facebook/infer）。

目前這兩款工具都是開源的，除了能夠使用其基本的功能外，如果還有其他的業務需求，可以對這兩款工具進行二次開發：添加自己的靜態分析規則和分析算法。

QQ瀏覽器（iPhone）項目采用Scan-Build工具發現代碼缺陷，如圖1-2所示。

采用Infer工具發現代碼缺陷統計圖如圖1-3所示，共發現1275處缺陷。

每日構建版本時，配置工程會自動采用這兩款工具對工程代碼進行靜態代碼分析，這樣在測試任務前就能發現代碼缺陷，大大降低軟件缺陷修復成本。

1.3 品質管理

品質管理分為兩大類，即研發品質和線上品質。

研發品質：包括品質體系（性能指標+用戶評測）、測試過程數據（Bug、通過率）。

線上品質：包括線上數據、用戶反饋、漏測率。

品質體系，除產品本身的特性功能外，還包含流暢度、內存、耗電量、啟動速度、弱網絡等功能，是用戶體驗能感知或者影響用戶口碑的。同時需要思考各個指標的比重（主要考慮對用戶的影響程度），這樣可以更好地優化核心指標。

線上品質，研發品質的指標都可以通過預設在被測App里的埋點上報上來，這樣就有了線上數據。用戶反饋主要是通過各反饋渠道收集用戶的反饋信息。通過對用戶反饋信息的分析，可以得知哪些問題是應當提前發現而漏出去的。漏出去的問題有些可能是因為測試工程師測試設計覆蓋不全導致的，有些可能是因為開發直接修改沒經過測試引起的，有些可能是運營活動引起的。

上面提到了品質體系，那么具體的產品品質如何衡量？很多公司都以Bug來衡量，除Bug外，還有一些指標大家會用到，例如代碼質量、代碼覆蓋率、測試過程數據。性能指標、用戶評測、用戶反饋和線上數據。具體解釋參考如下。

?代碼質量：指靜態代碼掃描、架構評審、代碼規范、代碼評審。

?代碼覆蓋率：指行覆蓋、類覆蓋、條件覆蓋、分支覆蓋。

?測試過程數據：指測試通過率、回歸通過率。

?性能指標：指啟動時間、響應時間、內存、流暢度（FPS）、CPU、耗電量。

?用戶評測：指產品進行用戶調研、用戶體驗、用戶問卷調查等。

?用戶反饋：指用戶反饋的問題或者建議。

?線上數據：指上線后的產品數據，如啟動時間、用戶行為數據。

?Bug：指Bug模塊分類（FT分布）、Bug各研發階段數據、Bug分析。

對于產品度量，騰訊各產品的度量方式也各有特色，圖1-4所示是瀏覽器品質體系的一小部分，僅供參考。

關于產品品質的衡量，不少公司還是以Bug來衡量的，下面先重點介紹Bug維度。

引用Elisabeth Hendrickson在文章《BETTER TESTING-WORSE QUALITY? 》中的圖來說明“質量”的相關概念，如圖1-5所示。

圖1-5中左邊的三部分是跟Bug相關的，分別是“已知Bug”“未知Bug”和“預防Bug”，右邊兩部分分別是開發質量工作和測試質量工作。

?開發質量工作：涉及架構評審、代碼規范、代碼評審、單元測試、開發自測等。

?測試質量工作：需求評審、用例設計（利用測試建模、測試分析等方法來提升測試設計覆蓋度）、自動化測試（BVT或者接口測試等）、性能測試、精準測試、探索式測試、基于風險測試（RBT）、Bug大掃除、Bug分析、Bug統計、眾測等。測試質量工作涉及的內容很多，可以考慮再抽練幾個分類，如圖1-6所示。

而這些測試質量工作的開展還需要借助一些平臺和工具才可以更高效地完成，如圖1-7所示。

測試質量工作除品質體系外，還包含工程效率。對于工程效率，測試團隊一般圍繞兩個主題來開展：測試效率提升和可測性擴展。

?測試效率提升：可以通過項目流程的規范、測試方法論應用、自動化測試的應用等工作，從而更高效地達到工作預期。

?可測性擴展：可以聯合開發做一些可測性提升的工作，例如接口暴露、代碼解耦等。當然，也可以嘗試覆蓋更多沒有覆蓋的內容，例如有些項目終端類測試開展不錯，就可以考慮加強后臺接口的覆蓋；還有黑盒類測試，可以考慮白盒類測試或者灰盒類測試等。

總的來說，測試質量工作一方面是做得更快，另一方面是做得更多。

通過上面對各個模塊的分析，我們再把上面提到質量保證的各項工作映射到Elisabeth Hendrickson的圖上，如圖1-8所示。

1．已知Bug

團隊成員在測試過程中發現的Bug（包括但不局限于Code review、show case、dogfood、測試發現的Bug等）。這些Bug一般都會記錄到Bug系統中（例如騰訊的TAPD），這樣就可以方便進行分析，例如Bug分布模塊（瀏覽模塊、支付模塊、個人中心等）、各FT的分布（有可能跟模塊有關聯）、各研發階段（迭代、集成、上線前等）、嚴重級別等。通過對Bug系統性分析來評估待發布產品的質量風險，這樣可以給予決策者更好的數據支持。當然，有些Bug是可以掛起的，不一定所有都需要修復。

2．未知Bug

產品發布之前未發現的Bug，發布后通過海量用戶反饋的問題或者通過統計埋點上報的問題。因為用戶的機型網絡以及數據環境等因素可能觸發潛在Bug（而這些Bug是整個團隊研發過程中很難出現或者偶爾出現漏過的），借助海量用戶可以放大出現的概率，然后用戶主動反饋或者被動埋點上報可以收集到這類潛在Bug。

一般產品里都有用戶反饋意見的入口，通過這個入口可以收集用戶使用過程中的問題或者意見。同時有些產品會對某些關鍵邏輯路徑進行埋點，這樣，只要用戶使用過程中觸發這個埋點，就會自動上報到后臺。主動上報的數據就可以進行統計分析，這類數據統計可能區別于用戶行為的統計，更多的是某個邏輯或者路徑的上報。針對這些上報的數據進行數據挖掘，可以幫助發現某些問題最有可能出現的場景，進而可以再結合眾測用戶進行重現，最后解決這些問題。

3．預防Bug

主要通過一些流程或者機制充分體驗產品，提前發現一些潛在Bug，例如通過需求評審、Showcase、DogFood等手段，全員積極參與各階段產品的體驗，就可能提前發現一些需求問題或者設計問題等。

?需求評審：需要各方角色（產品、開發、測試、PM、設計等）都能投入精力討論PK，這樣可以提前把不合理的需求扼殺在搖籃中。

?Showcase：各個迭代完成后，PM可以組織各個角色參與體驗，盡早發現潛在問題，例如某些設計問題或者體驗上的問題，快速返工，避免后期返工帶來更大的人力消耗。

?DogFood：通過持續集成編譯出版本后（有重點需求說明），發送給團隊各成員體驗，及時快速發現問題。這里更強調產品質量需要全員的參與。

質量工作涉及方方面面以及各個角色，同時必須考慮人力、時間等因素，還得考慮項目的市場競爭狀況，這樣才能平衡好以上各項措施的選擇。

1.4 測試分析

1.4.1 黑盒測試分析

“黑盒測試是軟件測試的主要方法之一，也可以稱為功能測試、數據驅動測試或基于規格說明的測試。測試者無須了解程序的內部情況，無須掌握應用程序的代碼、內部結構和編程語言的知識，只要知道程序的輸入、輸出和系統的功能即可。這是從用戶的角度針對軟件界面、功能及外部結構進行測試，而不考慮程序內部邏輯結構。”這段關于黑盒測試的定義參考自維基百科。

黑盒測試也是應用最廣的方法之一，不少公司都是以黑盒測試為主。那么黑盒測試有什么不足呢？我們先看看《微軟的軟件測試之道》對黑盒測試的分析，如圖1-9所示。

圖1-9中的A代表黑盒測試的沒覆蓋部分，B代表黑盒測試的冗余部分，C代表黑盒測試的有效部分。

從業界的統計數據來看，有效測試部分的百分比范圍為35%～65%。從圖1-9來看，要提升有效測試部分比例，就要把右邊的圓（B+C）往左移動，盡可能使兩個圓重合面積（C）增大。可以看出優化測試策略有兩個方向：一是增加有效測試，二是減少冗余測試或者無效測試。

1．增加有效測試

增加有效測試的方法有兩種：一是加強相關評審，二是應用業界的測試方法或者測試建模思想。

加強相關評審是從源頭的需求抓起，加強對需求的評審，多從用戶角度思考相關可用性及可能場景等。測試用例設計的評審，以及加強對產品開發等角色用例的評審。

應用業界的測試方法或者測試建模思想（詳細方法參考第3章的內容），需要在測試用例設計的時候盡可能地覆蓋更多功能，這就需要大家充分利用業界各種先進的測試模型來設計測試用例，這樣可以更科學、更高效地擴大有效測試范圍。如果有條件的話，可以通過閱讀開發代碼來梳理相關邏輯，這樣用例設計的覆蓋面會更全。

2．減少冗余測試

減少冗余測試可以通過減少無效用例或者低成效的用例、優化精簡測試用例等方式進行。

減少無效用例或者低成效的用例，詳細方法可以參考1.6節的數據反推。根據用例模塊化劃分，對Bug根據模塊（TAPD上相應的模塊選項）進行分類，統計每個模塊出現Bug的個數，如果多次執行后Bug個數少的模塊，優先級就降低。如果客戶端架構穩定后，對于后續新功能沒有涉及的這些模塊，則可以考慮不執行相關用例。后續在每次集成測試后，測試結果都必須保存，統計經常出現Bug的相關用例，優化和增加相關測試用例，并且同步到各個平臺。

優化精簡測試用例，可以借助代碼覆蓋率作為標準，執行原來的用例和精簡優化后的用例，如果兩者的代碼覆蓋率差不多，那就達到目的了。通過代碼覆蓋率測試，還可以找出沒有執行過的冗余代碼，這樣可以減少安裝包的大小。借助精準測試方法，通過精準測試系統，分析測試用例以及代碼映射關系，可以進一步確定測試用例的覆蓋情況。這樣就可以選擇適當的測試用例保證合理的覆蓋度。詳細的原理方法可以參見第10章。

1.4.2 白盒測試分析

上文提到的優化測試策略都是從黑盒的角度進行分析的，因為黑盒測試有局限性，測試有效代碼覆蓋率只有35%～65%，那么如何保證黑盒測試沒有測試到的部分代碼的穩定性和可靠性，就需要進行白盒測試。業界通常采用的是單元測試。通過合適的單元測試，可以讓代碼覆蓋率達到75%以上。但是由于單元測試的工作量比較大，剛開始不可能對全部代碼進行單元測試，所以可以考慮先用黑盒測試，借助代碼覆蓋率工具，找出黑盒測試沒有覆蓋到的代碼或模塊（有可能某些代碼屬于冗余或者死代碼），然后對這部分代碼進行單元測試，這樣可以最大限度地提高覆蓋率，更好地保證代碼質量。

1.5 測試設計

測試設計是一個系統性工程，涉及內容比較多，從前期需求分析到用例設計，再到各類數據的分析等。下面我們擇取主流的理論來看一下。

1.5.1 探索式測試

探索式測試是目前業界比較流行的一種測試風格，是由測試專家Cem Kaner博士于1983年提出的，后來經過James Bach、James Whittaker等人的發展流行起來。國內大多數人是因為James Whittaker撰寫了《Exploratory Software Testing》（探索式軟件測試）一書才了解探索式測試，并逐漸開始應用探索式測試，國內的互聯網公司基本都會使用探索式測試。

探索式測試建議在整個項目過程中將測試學習、測試設計、測試執行和測試結果解讀作為相互支持的活動，并行地執行。可用圖1-10來說明。

探索式測試目前已經充分應用到騰訊公司的各個產品中，具體實踐案例請參見第8章的介紹。

1.5.2 基于模型的測試

基于模型的測試（Model-Based Testing, MBT）是根據用戶的需求建模，進而根據模型自動生成用例、自動執行驗證過程的測試方式。圖1-11引用自《什么是基于模型的測試》[2]。

基于模型的測試在傳統軟件行業應用較多，例如愛立信以及西門子使用比較廣泛，國內的華為也有一些改進應用。互聯網公司如BAT也有一些嘗試，不過沒有太大規模應用起來。在騰訊內部，有些項目也在嘗試MBT，不過目前還沒有很好的典型案例，這里就不展開介紹。MBT對測試人員的建模能力有很高的要求，同時學習成本也相對較高，整體收益周期較長，所以比較難普及起來。

1.6 數據反推

1.6.1 測試過程中的數據

測試數據反推——充分利用各類測試數據的優化流程，進一步保障產品的質量。在各階段的測試過程中會產生大量數據，例如Bug數據、測試通過率、回歸通過率等。那么如何充分利用這些數據呢？前面已對已知Bug以及未知Bug進行了討論。現在換個角度，從Bug產生的階段來分析，圖1-12是不同階段Bug修復成本曲線。

針對Bug各階段的分析，根據圖1-12中Bug越早發現解決成本越低的結論，需要盡可能在最早引入的階段發現Bug。針對某些階段漏過的Bug分析，要盡可能完善測試設計覆蓋，避免Bug都留到集成階段發現，降低版本延期發布風險，從而開發出更高效的發布版本。

例如某個項目，集成測試發現的Bug占比只有整個版本（所有各分支版本）發現Bug的3%～6%，這些Bug大多是分支合流跟主干耦合的問題，還有一些是機型覆蓋或者運營配置問題。大多數Bug都已經在各FT（Feature Team，特性模塊）分支上發現了，這樣集成后的發布風險就會大大降低，加快了發布速度。圖1-13是FT分支的合流模型，各個分支FT都能充分保證質量，這樣合流后集成測試問題就很少了。

也許有人會說3%～6%并不算少，確實，不同項目有不同要求。這里介紹的思路就是充分利用這些數據去思考與分析，推動團隊采取動作，逐步降低該比例，逐步降低發布風險，提升發布效率。分支合流模型的測試如何開展是另外一個話題，不過大體思路都差不多，除了基本持續集成外，還需要自動化測試（BVT、接口測試、終端性能測試等）的支持，才能快速支持分支合流的快速研發模型。

再舉一個例子，Bug各模塊分布，有些模塊Bug問題比較多，可能需要特別關注測試，因為根據測試的二八法則——80%的缺陷出現在20%的代碼中，所以對這些模塊需要多分析多做測試，這樣可以更大可能發現潛在問題。一般來說，不同模塊會對應不同的開發團隊或者FT，也可以通過Bug來評估開發團隊（或者FT）的成熟度，根據不同的開發團隊（FT）制定相應的改善措施，用數據說話，這樣更好地推動團隊的正向優化。表1-1所示的是另外一個項目團隊某個版本的各個FT存在的缺陷占比，從表中可以看出模塊A是缺陷高發區，出現這種情況需要和對應模塊的負責人進行溝通，細查原因，以利于改進。

以上僅僅是從Bug模塊分布來分析Bug數據，其實還可以從很多維度（從開發人員的維度、用戶行為的維度等）去挖掘Bug數據，充分利用Bug數據來優化測試設計，提升測試效率。

1.6.2 線上數據

以上介紹的大多是與研發過程品質相關的，其實還有一個很重要的方向就是線上品質，通過線上海量用戶上報的數據來度量產品品質。大多數情況下，研發過程品質始終無法保證線上品質。比如用戶反饋的重現問題，就是線上用戶反饋的問題我們怎么也重現不了，即使嚴格按照用戶的步驟、機型、網絡等場景也重現不了。研發過程中測試的數據跟線上用戶的數據對應不上，例如某個產品的啟動速度，研發過程中測試的啟動時間是2.3秒（測試20次取平均值），而線上用戶上報的數據是3.2秒（20萬個用戶上報的平均值）。

業界也有相關測試方法，例如微軟公司提出的TiP（Testing in Production），就是通過版本上線后海量用戶上報各類數據來發現潛在的問題。測試人員需要關注各類性能數據，例如啟動速度、內存、流暢度、響應時間、Crash率等。因為用戶的機型、網絡、地域、數據環境不同，所以不同用戶上報的數據差異很大，這里需要做一些數據統計的分析處理，才能更好地展現出來。由于線上環境的復雜性，線上數據反映的結果會比測試數據差一些。

那么如何通過線上數據來分析定位問題呢？主要的方法就是對某些指標進行詳細埋點上報，這樣才能獲得更詳細數據并進行分析，最后找到問題所在。還是以某個產品的啟動速度為例來說明（啟動速度是指用戶點擊應用圖標開始到拉取完數據展示給用戶的這個時間段）。

App啟動后就會到后臺服務器拉取數據，從大的方向來看，需要區分后臺服務器耗時以及App處理的耗時，這樣可以方便前端或者后臺解決問題。如圖1-14所展示的，“等待響應”就是后臺服務器耗時（其中也包含網絡傳輸的耗時）。一般可以通過抓取網絡包分析得出相關耗時。

圖1-14中的RTT（Round-Trip Time）是客戶端到服務器往返所花的時間。

當然，只區分客戶端跟后臺服務器各自的耗時是遠遠不夠的，還需要細分到每個主要函數的耗時，這樣才能更好地定位具體是哪部分耗時。圖1-15所示的是某個App對關鍵函數（節點）的日志統計。

圖1-15只是啟動速度這個指標需要記錄的數據，可能發現需要記錄的數據非常多，對這些記錄的日志也會進行分級，線上發布版本的日志會盡量少一些，不過關鍵的地方還是需要記錄的。當然，版本加了日志會對性能有所損耗，不過在可接受的范圍內，還是有必要的；通過線上版本的數據上報，可以得到用戶真實的數據，發現潛在問題并逐步優化，給用戶更好的體驗，提升產品口碑。

測試數據還可以預測即將發布版本的質量，不管是研發過程還是灰度階段，都將會產生很多測試數據。那么是否可以充分利用這些數據來預測上線版本的質量趨勢呢？這確實是一個方向，但是需要大量的測試數據才可能有機會預測靠譜。因為線上用戶的各種機型系統、網絡狀況、用戶環境數據，這些都很難在上線前的環境覆蓋到，所以就很難預測線上版本的質量。如果灰度群體足夠，那么還是有機會的。騰訊內部的很多項目，產品穩定性問題（Crash率）都是通過灰度來發現問題的，Crash率達到一定程度，就可以進一步擴大灰度規模，逐步迭代放大灰度數量，直至上線。

1.7 未來的測試

這一節內容都是筆者暢想的，如有雷同，純屬意外。

移動互聯網時代，特別是Native的App，版本更新的成本很高（除時間成本，還有對用戶體驗的影響），所以大多數App都會經過充分的測試再發布版本。

隨著熱補丁（hotfix）技術的演進以及H5的流行，可以不需要發布新版本而發布一個補丁就可以發布新功能或者修復問題（而且用戶基本無感知，不需要安裝過程，下次啟動就自動更新了），這樣就可以在沒有充分測試的情況下，快速通過用戶來驗證。這樣對測試的依賴可能會越來越小。那么未來的產品都是通過用戶（灰度或者正式上線）直接驗證嗎？

應該不可能全部都通過用戶來驗證（灰度或者正式上線），不經過測試而直接上線，可能出現問題的概率會增大，如果真的出現問題，那么會對產品的口碑帶來很大的影響。但是熱補丁技術確實是可以快速修復問題的方案，以后會被逐步應用。即使利用熱補丁技術，還是需要度量產品品質的，例如線上用戶各類性能指標以及用戶反饋等，對于品質的追求還是始終存在的，也就是仍需要有人來做品質這樣的工作。

1.7.1 線上數據挖掘

既然線上數據會越來越重要，那么就需要一整套埋點上報體系（終端是SDK形式，服務端存儲各類數據），同時對上報數據進行數據分析，可能需要利用到機器學習等技術分析數據，判斷是否有潛在問題。數據上報體系是每個App都有的基本功能，包含需要關注具體上報什么信息，例如，

（1）路徑埋點：關鍵路徑的埋點。

（2）錯誤碼信息：統一錯誤碼設計，方便排查。

（3）調用堆棧：堆棧調用信息。

（4）方法跟蹤：函數方法的鏈條。

（5）用戶動作：用戶操作路徑（可以詳細到用戶何時點擊哪個控件）。

（6）機型網絡信息：基礎手機信息收集。

（7）性能指標（內存/CPU/FPS）：各類性能指標的消息速度/流量/函數調用時間。

在對App全方位埋點后，就會有上報的數據，哪些數據需要進行分析，具體分析方法各種各樣，如圖1-16所示。該圖主要描述了一種線上數據分析模型，包括數據收集容器、數據分析容器、Bug處理容器三個部分。

如果埋點上報體系建設完善，任何人（Dogfood、Showcase、眾測、灰度等）只要體驗產品，就是給產品做測試，這樣就會上報很多數據，再系統分析這些數據，進而找到某些潛在問題。

1.7.2 人工智能

最近，Facebook發布聊天機器人Chatbot, Google發布Google Assistant以及Google Home音箱，Amazon也發布Echo音箱，整個業界的發展趨勢變成從App演進到Bot。同時，Google的戰略也從Mobile First轉變為AI First。那么對于人工智能（Bot），應該怎么測試呢？

業界暫時還沒有開源或者公開的測試方案，可能各公司也都在探索中，傳統上針對AI的算法測試也是持續演進的。我們先回到人工智能本身，其實就是對數據的智能處理（這也是擁有大數據的Google等公司的人工智能快速發展的原因之一），那么人工智能測試還是得圍繞數據進行測試。當然，這樣的數據是海量的，因此要采用抽樣模型進行評測。總的來說，就是構建以及收集數據樣本。數據樣本的構建，需要對具體處理數據結構足夠了解，然后通過自動化方式生成樣本數據。同時，除了構建樣本數據，還可以通過另外的渠道來收集用戶數據，例如眾測或者眾包的方式收集樣本數據。

除了對數據的測試外，在人工智能出現后，人機交互方式會出現大的變化，語音交互可能是主要交互模式之一，那么如何保證優秀的用戶體驗呢？交互評測需要真實用戶的參與，首先設計合理的評測問卷，然后通過眾測或者眾包等平臺引入不同用戶的參與，通過雙盲測試收集各類數據。同時也會通過AB Test來收集線上用戶的反饋，不斷改善用戶體驗。

總的來說，人工智能測試除了對AI算法的測試外，還需要關注數據類測試+交互類測試。

1.7.3 眾測

上面提到的線上數據挖掘（需要各種機型、網絡、數據環境等）以及人工智能（數據樣本采集）都需要有一定量的真實用戶參與，才能更好地評測產品品質。那么可能就需要用共享經濟的方式，快速集合一群合適用戶來幫忙做評測（收集數據或者產品體驗等），這就是最近幾年業界流行的眾測（眾包）模式。眾測（眾包）模式的優點如下。

（1）閉環時間短，溝通效率高：因為有報酬等激勵，眾測（眾包）用戶積極度更高。

（2）定向用戶屬性支持：眾測（眾包）平臺會收集用戶屬性，例如性別、年齡、職務、學歷等，更有針對性地向合適人群做評測。

（3）定向設備屬性支持：眾測（眾包）平臺會收集設備屬性，例如機型、ROM、網絡、地域等，更有針對性地向合適人群做評測，特別是對于地域有特殊要求的，可以快速響應。

（4）用戶行為高度可控、可刷機、可支付。眾測（眾包）平臺的用戶都是相對狂熱的粉絲，可以幫助做一些特殊操作，例如重復刷機、重復嘗試某個問題。

眾測（眾包）的具體使用模式大概有以下幾類。

（1）需求評測（評估需求的適用范圍等）。

（2）機型覆蓋測試（覆蓋各類機型適配情況）。

（3）重要問題復現（某些問題的復現）。

（4）大量數據收集（數據標準類）。

（5）問卷調查收集（用戶調研）。

（6）復雜環境評測（某些功能的評測）。

眾測（眾包）使用可能是一個趨勢，有能力的公司可以逐步建設這樣的平臺，這樣能更快地驗證產品，產品驗證的成本會更低。

1.8 小結

通過本章的內容，先和讀者建立了一個測試基礎共識，便于接下來的章節理解。總體來說，我們認為測試=工程效率+品質管理，如何提升工程效率和品質管理是測試提升的核心內容。在測試的不同階段，測試分析、測試設計、數據反推都能發揮一定的作用，未來的空間很大，需要我們一起去探索。