第1章 測(cè)試觀概述

1.1 引言

在正式介紹iOS測(cè)試前，先為讀者引入一個(gè)思  考問(wèn)題：一千個(gè)人有一千種測(cè)試觀，那么測(cè)試人員到底應(yīng)該持有何種測(cè)試觀？我們先來(lái)看看測(cè)試的定義發(fā)展史。

20世紀(jì)60年代：軟件開(kāi)發(fā)過(guò)程中，將測(cè)試等同于“調(diào)試”。

1957年，軟件測(cè)試區(qū)別于調(diào)試，成為一種發(fā)現(xiàn)軟件缺陷的活動(dòng)。

1972年，在北卡羅來(lái)納大學(xué)舉行了首屆軟件測(cè)試正式會(huì)議。

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

1979年，在Glen ford Myers的《軟件測(cè)試藝術(shù)》中，定義“測(cè)試是為發(fā)現(xiàn)錯(cuò)誤而執(zhí)行的一個(gè)程序或者系統(tǒng)的過(guò)程”。

1983年，Bill Hetzel在《軟件測(cè)試完全指南》中指出，“測(cè)試是以評(píng)價(jià)一個(gè)程序或者系統(tǒng)屬性為目標(biāo)的任何一種活動(dòng)，是對(duì)軟件質(zhì)量的度量?！?/p>

2002年，Rick和Stefan在《系統(tǒng)的軟件測(cè)試》一書(shū)中對(duì)軟件測(cè)試做了進(jìn)一步定義，“測(cè)試是為了度量和提高被測(cè)試軟件的質(zhì)量而對(duì)測(cè)試軟件進(jìn)行工程設(shè)計(jì)、實(shí)施和維護(hù)的整個(gè)生命周期過(guò)程。”

軟件測(cè)試的經(jīng)典定義：在規(guī)定的條件下對(duì)程序進(jìn)行操作，以發(fā)現(xiàn)程序錯(cuò)誤、衡量軟件質(zhì)量，并對(duì)其能否滿足設(shè)計(jì)要求而進(jìn)行評(píng)估的過(guò)程。——百度百科

以上測(cè)試（軟件測(cè)試）的定義都沒(méi)錯(cuò)，那么測(cè)試工程師應(yīng)該怎么做呢？

通俗一點(diǎn)來(lái)解釋，筆者理解的測(cè)試為：測(cè)試=工程效率+品質(zhì)管理。相應(yīng)地，測(cè)試人員做的事情就是提升工程效率，做好品質(zhì)管理。引用谷歌團(tuán)隊(duì)的一段話[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”可以理解為品質(zhì)管理。就像上面谷歌團(tuán)隊(duì)的這段話，測(cè)試人員應(yīng)該每天思考怎樣提升團(tuán)隊(duì)的研發(fā)效率，怎樣提升產(chǎn)品品質(zhì)來(lái)讓用戶滿意。

1.2 工程效率

總體來(lái)說(shuō)，工程效率就是研發(fā)效率（包含測(cè)試效率）。這里我們會(huì)把測(cè)試效率單獨(dú)提出來(lái)進(jìn)行說(shuō)明，因?yàn)檫@是與測(cè)試工程師相關(guān)度最大的工作。研發(fā)效率，其實(shí)就是讓產(chǎn)品上線的時(shí)間更快（在品質(zhì)有保障的前提下），大多數(shù)時(shí)候是說(shuō)與研發(fā)流程相關(guān)的（不局限于敏捷流程，F(xiàn)eature Team研發(fā)模型），例如包含但不局限于以下活動(dòng)。

?需求評(píng)審：需求評(píng)審機(jī)制以及更新通知，避免需求有改動(dòng)而沒(méi)有及時(shí)同步到相關(guān)角色。

?代碼質(zhì)量：靜態(tài)代碼掃描，千行代碼缺陷率等。

?架構(gòu)評(píng)審：代碼架構(gòu)的討論以及評(píng)審。

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

?Code Review：代碼評(píng)審，如果有代碼評(píng)審委員會(huì)就更好了。

?Dogfood：自己做的產(chǎn)品自己（項(xiàng)目各成員）先體驗(yàn)。

?Showcase：完成某個(gè)特性，可以通過(guò)會(huì)議針對(duì)某個(gè)特性進(jìn)行展示，一般由產(chǎn)品經(jīng)理主持。

上面提到的活動(dòng)，只有通過(guò)整個(gè)項(xiàng)目團(tuán)隊(duì)（各個(gè)角色）的通力配合，才能更加高效。

再提一下測(cè)試效率，這大多數(shù)由測(cè)試工程師主導(dǎo)，也是測(cè)試工程師最主要的工作內(nèi)容。測(cè)試效率包含但不局限于以下這些活動(dòng)。

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

?測(cè)試設(shè)計(jì)：包括需求覆蓋度、用例覆蓋度、用例執(zhí)行效率等。

?自動(dòng)化測(cè)試：使用自動(dòng)化執(zhí)行的方式進(jìn)行測(cè)試，可以快速得出測(cè)試結(jié)果，節(jié)省人力成本。

?靜態(tài)代碼分析：使用一定的工具來(lái)對(duì)代碼進(jìn)行靜態(tài)掃描，提前發(fā)現(xiàn)代碼隱藏的問(wèn)題。

?測(cè)試技術(shù)創(chuàng)新：通過(guò)對(duì)測(cè)試技術(shù)的創(chuàng)新，例如精準(zhǔn)測(cè)試、機(jī)器學(xué)習(xí)等方式，來(lái)變更測(cè)試方式，大幅度提升測(cè)試質(zhì)量和效率。

接下來(lái)舉兩個(gè)例子具體看下。

1.2.1 自動(dòng)化測(cè)試

自動(dòng)化測(cè)試于20世紀(jì)90年代才開(kāi)始逐漸成熟，特別是敏捷研發(fā)的流行以及推崇的TDD模式，自動(dòng)化測(cè)試也逐漸流行起來(lái)。對(duì)于自動(dòng)化測(cè)試，我們還是得多關(guān)注其投入產(chǎn)出比（ROI），特別是對(duì)于UI自動(dòng)化測(cè)試。業(yè)界自動(dòng)化測(cè)試金字塔模型建議做單元測(cè)試或者接口測(cè)試多于UI自動(dòng)化測(cè)試。關(guān)于自動(dòng)化測(cè)試投入產(chǎn)出比，請(qǐng)參閱第6章介紹的內(nèi)容。

對(duì)于iOS平臺(tái)上的自動(dòng)化測(cè)試實(shí)踐，我們也有在不同方向上的嘗試（參見(jiàn)第5章），并都有不錯(cuò)的收獲。相關(guān)自動(dòng)化測(cè)試的開(kāi)展還需要有一些自動(dòng)化測(cè)試框架的支持（詳細(xì)自動(dòng)化測(cè)試框架的內(nèi)容會(huì)在第7章介紹）, QQ瀏覽器（iPhone）測(cè)試團(tuán)隊(duì)主要移植Google開(kāi)源的EarlGrey框架來(lái)作為自動(dòng)化測(cè)試的基礎(chǔ)框架。本節(jié)先簡(jiǎn)單介紹幾種主流自動(dòng)化測(cè)試類型。

1．BVT（Build Verification Test）

業(yè)界現(xiàn)在流行持續(xù)交付的模式。那么每次持續(xù)集成編譯出包后，自動(dòng)化會(huì)運(yùn)行一些基礎(chǔ)功能測(cè)試用例，保證版本基礎(chǔ)功能可用，而不會(huì)因?yàn)樾麓a合入影響基礎(chǔ)功能。這部分主要介紹UI自動(dòng)化測(cè)試，當(dāng)然，隨著版本需求的變更，維護(hù)成本也會(huì)增加。但對(duì)于QQ瀏覽器的UI變更還不是很頻繁，維護(hù)成本還相對(duì)可控，整體的投入產(chǎn)出也不錯(cuò)，具體可參考第6章的內(nèi)容。

2．監(jiān)控類

根據(jù)產(chǎn)品的業(yè)務(wù)特點(diǎn)，我們會(huì)對(duì)產(chǎn)品進(jìn)行一些監(jiān)控，例如手機(jī)QQ瀏覽器（iPhone）項(xiàng)目實(shí)現(xiàn)了三種類型的監(jiān)控測(cè)試，即終端視頻嗅探監(jiān)控、終端feeds流短視頻可播性監(jiān)控、終端資訊類監(jiān)控。這部分監(jiān)控的基礎(chǔ)框架和BVT實(shí)現(xiàn)是一致的，只是基于業(yè)務(wù)形態(tài)做了調(diào)整，采用的也是EarlGrey框架并進(jìn)行了二次開(kāi)發(fā)?？蓞⒖嫉?章關(guān)于測(cè)試框架的二次開(kāi)發(fā)。

3．性能自動(dòng)化測(cè)試

性能測(cè)試涉及各種數(shù)據(jù)的采集和分析，而數(shù)據(jù)采集往往很復(fù)雜并且非常耗時(shí)，性能自動(dòng)化測(cè)試也都集中在數(shù)據(jù)采集這一塊。目前我們針對(duì)頁(yè)面速度、產(chǎn)品穩(wěn)定性、電量、流量、內(nèi)存等各個(gè)方面進(jìn)行性能自動(dòng)化測(cè)試的嘗試，詳細(xì)內(nèi)容請(qǐng)參見(jiàn)第4章。

1.2.2 靜態(tài)代碼分析

靜態(tài)代碼分析就是在不執(zhí)行代碼的情況下，通過(guò)一定的算法規(guī)則（詞法分析、語(yǔ)法分析、單函數(shù)分析、代碼段分析、數(shù)據(jù)流分析、資源分析、依賴鏈分析、更高級(jí)的智能邏輯分析）對(duì)整個(gè)工程的代碼進(jìn)行分析，以此來(lái)找出代碼中的缺陷。這樣就可以提早發(fā)現(xiàn)問(wèn)題，大大降低研發(fā)成本。美國(guó)軟件工程專家Capers Jones提出的軟件測(cè)試缺陷價(jià)值圖如圖1-1所示。

圖1-1中的三條曲線分別代表引入的缺陷、發(fā)現(xiàn)缺陷、缺陷修復(fù)成本。越是在前期發(fā)現(xiàn)的缺陷，修復(fù)缺陷的成本越低，越是到后期，修復(fù)缺陷的成本越高。通常來(lái)說(shuō)，發(fā)現(xiàn)缺陷主要在功能測(cè)試、集成測(cè)試階段。

如果能夠在Coding階段發(fā)現(xiàn)大部分缺陷，就能大大降低修復(fù)缺陷的成本。靜態(tài)代碼分析技術(shù)恰恰能夠很好地在Coding階段發(fā)現(xiàn)部分代碼問(wèn)題，這樣就能夠大大節(jié)約軟件開(kāi)發(fā)成本。

經(jīng)過(guò)實(shí)踐論證，iOS平臺(tái)比較好用的兩款工具如下。

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

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

目前這兩款工具都是開(kāi)源的，除了能夠使用其基本的功能外，如果還有其他的業(yè)務(wù)需求，可以對(duì)這兩款工具進(jìn)行二次開(kāi)發(fā)：添加自己的靜態(tài)分析規(guī)則和分析算法。

QQ瀏覽器（iPhone）項(xiàng)目采用Scan-Build工具發(fā)現(xiàn)代碼缺陷，如圖1-2所示。

采用Infer工具發(fā)現(xiàn)代碼缺陷統(tǒng)計(jì)圖如圖1-3所示，共發(fā)現(xiàn)1275處缺陷。

每日構(gòu)建版本時(shí)，配置工程會(huì)自動(dòng)采用這兩款工具對(duì)工程代碼進(jìn)行靜態(tài)代碼分析，這樣在測(cè)試任務(wù)前就能發(fā)現(xiàn)代碼缺陷，大大降低軟件缺陷修復(fù)成本。

1.3 品質(zhì)管理

品質(zhì)管理分為兩大類，即研發(fā)品質(zhì)和線上品質(zhì)。

研發(fā)品質(zhì)：包括品質(zhì)體系（性能指標(biāo)+用戶評(píng)測(cè)）、測(cè)試過(guò)程數(shù)據(jù)（Bug、通過(guò)率）。

線上品質(zhì)：包括線上數(shù)據(jù)、用戶反饋、漏測(cè)率。

品質(zhì)體系，除產(chǎn)品本身的特性功能外，還包含流暢度、內(nèi)存、耗電量、啟動(dòng)速度、弱網(wǎng)絡(luò)等功能，是用戶體驗(yàn)?zāi)芨兄蛘哂绊懹脩艨诒?。同時(shí)需要思考各個(gè)指標(biāo)的比重（主要考慮對(duì)用戶的影響程度），這樣可以更好地優(yōu)化核心指標(biāo)。

線上品質(zhì)，研發(fā)品質(zhì)的指標(biāo)都可以通過(guò)預(yù)設(shè)在被測(cè)App里的埋點(diǎn)上報(bào)上來(lái)，這樣就有了線上數(shù)據(jù)。用戶反饋主要是通過(guò)各反饋渠道收集用戶的反饋信息。通過(guò)對(duì)用戶反饋信息的分析，可以得知哪些問(wèn)題是應(yīng)當(dāng)提前發(fā)現(xiàn)而漏出去的。漏出去的問(wèn)題有些可能是因?yàn)闇y(cè)試工程師測(cè)試設(shè)計(jì)覆蓋不全導(dǎo)致的，有些可能是因?yàn)殚_(kāi)發(fā)直接修改沒(méi)經(jīng)過(guò)測(cè)試引起的，有些可能是運(yùn)營(yíng)活動(dòng)引起的。

上面提到了品質(zhì)體系，那么具體的產(chǎn)品品質(zhì)如何衡量？很多公司都以Bug來(lái)衡量，除Bug外，還有一些指標(biāo)大家會(huì)用到，例如代碼質(zhì)量、代碼覆蓋率、測(cè)試過(guò)程數(shù)據(jù)。性能指標(biāo)、用戶評(píng)測(cè)、用戶反饋和線上數(shù)據(jù)。具體解釋參考如下。

?代碼質(zhì)量：指靜態(tài)代碼掃描、架構(gòu)評(píng)審、代碼規(guī)范、代碼評(píng)審。

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

?測(cè)試過(guò)程數(shù)據(jù)：指測(cè)試通過(guò)率、回歸通過(guò)率。

?性能指標(biāo)：指啟動(dòng)時(shí)間、響應(yīng)時(shí)間、內(nèi)存、流暢度（FPS）、CPU、耗電量。

?用戶評(píng)測(cè)：指產(chǎn)品進(jìn)行用戶調(diào)研、用戶體驗(yàn)、用戶問(wèn)卷調(diào)查等。

?用戶反饋：指用戶反饋的問(wèn)題或者建議。

?線上數(shù)據(jù)：指上線后的產(chǎn)品數(shù)據(jù)，如啟動(dòng)時(shí)間、用戶行為數(shù)據(jù)。

?Bug：指Bug模塊分類（FT分布）、Bug各研發(fā)階段數(shù)據(jù)、Bug分析。

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

關(guān)于產(chǎn)品品質(zhì)的衡量，不少公司還是以Bug來(lái)衡量的，下面先重點(diǎn)介紹Bug維度。

引用Elisabeth Hendrickson在文章《BETTER TESTING-WORSE QUALITY? 》中的圖來(lái)說(shuō)明“質(zhì)量”的相關(guān)概念，如圖1-5所示。

圖1-5中左邊的三部分是跟Bug相關(guān)的，分別是“已知Bug”“未知Bug”和“預(yù)防Bug”，右邊兩部分分別是開(kāi)發(fā)質(zhì)量工作和測(cè)試質(zhì)量工作。

?開(kāi)發(fā)質(zhì)量工作：涉及架構(gòu)評(píng)審、代碼規(guī)范、代碼評(píng)審、單元測(cè)試、開(kāi)發(fā)自測(cè)等。

?測(cè)試質(zhì)量工作：需求評(píng)審、用例設(shè)計(jì)（利用測(cè)試建模、測(cè)試分析等方法來(lái)提升測(cè)試設(shè)計(jì)覆蓋度）、自動(dòng)化測(cè)試（BVT或者接口測(cè)試等）、性能測(cè)試、精準(zhǔn)測(cè)試、探索式測(cè)試、基于風(fēng)險(xiǎn)測(cè)試（RBT）、Bug大掃除、Bug分析、Bug統(tǒng)計(jì)、眾測(cè)等。測(cè)試質(zhì)量工作涉及的內(nèi)容很多，可以考慮再抽練幾個(gè)分類，如圖1-6所示。

而這些測(cè)試質(zhì)量工作的開(kāi)展還需要借助一些平臺(tái)和工具才可以更高效地完成，如圖1-7所示。

測(cè)試質(zhì)量工作除品質(zhì)體系外，還包含工程效率。對(duì)于工程效率，測(cè)試團(tuán)隊(duì)一般圍繞兩個(gè)主題來(lái)開(kāi)展：測(cè)試效率提升和可測(cè)性擴(kuò)展。

?測(cè)試效率提升：可以通過(guò)項(xiàng)目流程的規(guī)范、測(cè)試方法論應(yīng)用、自動(dòng)化測(cè)試的應(yīng)用等工作，從而更高效地達(dá)到工作預(yù)期。

?可測(cè)性擴(kuò)展：可以聯(lián)合開(kāi)發(fā)做一些可測(cè)性提升的工作，例如接口暴露、代碼解耦等。當(dāng)然，也可以嘗試覆蓋更多沒(méi)有覆蓋的內(nèi)容，例如有些項(xiàng)目終端類測(cè)試開(kāi)展不錯(cuò)，就可以考慮加強(qiáng)后臺(tái)接口的覆蓋；還有黑盒類測(cè)試，可以考慮白盒類測(cè)試或者灰盒類測(cè)試等。

總的來(lái)說(shuō)，測(cè)試質(zhì)量工作一方面是做得更快，另一方面是做得更多。

通過(guò)上面對(duì)各個(gè)模塊的分析，我們?cè)侔焉厦嫣岬劫|(zhì)量保證的各項(xiàng)工作映射到Elisabeth Hendrickson的圖上，如圖1-8所示。

1．已知Bug

團(tuán)隊(duì)成員在測(cè)試過(guò)程中發(fā)現(xiàn)的Bug（包括但不局限于Code review、show case、dogfood、測(cè)試發(fā)現(xiàn)的Bug等）。這些Bug一般都會(huì)記錄到Bug系統(tǒng)中（例如騰訊的TAPD），這樣就可以方便進(jìn)行分析，例如Bug分布模塊（瀏覽模塊、支付模塊、個(gè)人中心等）、各FT的分布（有可能跟模塊有關(guān)聯(lián)）、各研發(fā)階段（迭代、集成、上線前等）、嚴(yán)重級(jí)別等。通過(guò)對(duì)Bug系統(tǒng)性分析來(lái)評(píng)估待發(fā)布產(chǎn)品的質(zhì)量風(fēng)險(xiǎn)，這樣可以給予決策者更好的數(shù)據(jù)支持。當(dāng)然，有些Bug是可以掛起的，不一定所有都需要修復(fù)。

2．未知Bug

產(chǎn)品發(fā)布之前未發(fā)現(xiàn)的Bug，發(fā)布后通過(guò)海量用戶反饋的問(wèn)題或者通過(guò)統(tǒng)計(jì)埋點(diǎn)上報(bào)的問(wèn)題。因?yàn)橛脩舻臋C(jī)型網(wǎng)絡(luò)以及數(shù)據(jù)環(huán)境等因素可能觸發(fā)潛在Bug（而這些Bug是整個(gè)團(tuán)隊(duì)研發(fā)過(guò)程中很難出現(xiàn)或者偶爾出現(xiàn)漏過(guò)的），借助海量用戶可以放大出現(xiàn)的概率，然后用戶主動(dòng)反饋或者被動(dòng)埋點(diǎn)上報(bào)可以收集到這類潛在Bug。

一般產(chǎn)品里都有用戶反饋意見(jiàn)的入口，通過(guò)這個(gè)入口可以收集用戶使用過(guò)程中的問(wèn)題或者意見(jiàn)。同時(shí)有些產(chǎn)品會(huì)對(duì)某些關(guān)鍵邏輯路徑進(jìn)行埋點(diǎn)，這樣，只要用戶使用過(guò)程中觸發(fā)這個(gè)埋點(diǎn)，就會(huì)自動(dòng)上報(bào)到后臺(tái)。主動(dòng)上報(bào)的數(shù)據(jù)就可以進(jìn)行統(tǒng)計(jì)分析，這類數(shù)據(jù)統(tǒng)計(jì)可能區(qū)別于用戶行為的統(tǒng)計(jì)，更多的是某個(gè)邏輯或者路徑的上報(bào)。針對(duì)這些上報(bào)的數(shù)據(jù)進(jìn)行數(shù)據(jù)挖掘，可以幫助發(fā)現(xiàn)某些問(wèn)題最有可能出現(xiàn)的場(chǎng)景，進(jìn)而可以再結(jié)合眾測(cè)用戶進(jìn)行重現(xiàn)，最后解決這些問(wèn)題。

3．預(yù)防Bug

主要通過(guò)一些流程或者機(jī)制充分體驗(yàn)產(chǎn)品，提前發(fā)現(xiàn)一些潛在Bug，例如通過(guò)需求評(píng)審、Showcase、DogFood等手段，全員積極參與各階段產(chǎn)品的體驗(yàn)，就可能提前發(fā)現(xiàn)一些需求問(wèn)題或者設(shè)計(jì)問(wèn)題等。

?需求評(píng)審：需要各方角色（產(chǎn)品、開(kāi)發(fā)、測(cè)試、PM、設(shè)計(jì)等）都能投入精力討論P(yáng)K，這樣可以提前把不合理的需求扼殺在搖籃中。

?Showcase：各個(gè)迭代完成后，PM可以組織各個(gè)角色參與體驗(yàn)，盡早發(fā)現(xiàn)潛在問(wèn)題，例如某些設(shè)計(jì)問(wèn)題或者體驗(yàn)上的問(wèn)題，快速返工，避免后期返工帶來(lái)更大的人力消耗。

?DogFood：通過(guò)持續(xù)集成編譯出版本后（有重點(diǎn)需求說(shuō)明），發(fā)送給團(tuán)隊(duì)各成員體驗(yàn)，及時(shí)快速發(fā)現(xiàn)問(wèn)題。這里更強(qiáng)調(diào)產(chǎn)品質(zhì)量需要全員的參與。

質(zhì)量工作涉及方方面面以及各個(gè)角色，同時(shí)必須考慮人力、時(shí)間等因素，還得考慮項(xiàng)目的市場(chǎng)競(jìng)爭(zhēng)狀況，這樣才能平衡好以上各項(xiàng)措施的選擇。

1.4 測(cè)試分析

1.4.1 黑盒測(cè)試分析

“黑盒測(cè)試是軟件測(cè)試的主要方法之一，也可以稱為功能測(cè)試、數(shù)據(jù)驅(qū)動(dòng)測(cè)試或基于規(guī)格說(shuō)明的測(cè)試。測(cè)試者無(wú)須了解程序的內(nèi)部情況，無(wú)須掌握應(yīng)用程序的代碼、內(nèi)部結(jié)構(gòu)和編程語(yǔ)言的知識(shí)，只要知道程序的輸入、輸出和系統(tǒng)的功能即可。這是從用戶的角度針對(duì)軟件界面、功能及外部結(jié)構(gòu)進(jìn)行測(cè)試，而不考慮程序內(nèi)部邏輯結(jié)構(gòu)?！边@段關(guān)于黑盒測(cè)試的定義參考自維基百科。

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

圖1-9中的A代表黑盒測(cè)試的沒(méi)覆蓋部分，B代表黑盒測(cè)試的冗余部分，C代表黑盒測(cè)試的有效部分。

從業(yè)界的統(tǒng)計(jì)數(shù)據(jù)來(lái)看，有效測(cè)試部分的百分比范圍為35%～65%。從圖1-9來(lái)看，要提升有效測(cè)試部分比例，就要把右邊的圓（B+C）往左移動(dòng)，盡可能使兩個(gè)圓重合面積（C）增大?？梢钥闯鰞?yōu)化測(cè)試策略有兩個(gè)方向：一是增加有效測(cè)試，二是減少冗余測(cè)試或者無(wú)效測(cè)試。

1．增加有效測(cè)試

增加有效測(cè)試的方法有兩種：一是加強(qiáng)相關(guān)評(píng)審，二是應(yīng)用業(yè)界的測(cè)試方法或者測(cè)試建模思想。

加強(qiáng)相關(guān)評(píng)審是從源頭的需求抓起，加強(qiáng)對(duì)需求的評(píng)審，多從用戶角度思考相關(guān)可用性及可能場(chǎng)景等。測(cè)試用例設(shè)計(jì)的評(píng)審，以及加強(qiáng)對(duì)產(chǎn)品開(kāi)發(fā)等角色用例的評(píng)審。

應(yīng)用業(yè)界的測(cè)試方法或者測(cè)試建模思想（詳細(xì)方法參考第3章的內(nèi)容），需要在測(cè)試用例設(shè)計(jì)的時(shí)候盡可能地覆蓋更多功能，這就需要大家充分利用業(yè)界各種先進(jìn)的測(cè)試模型來(lái)設(shè)計(jì)測(cè)試用例，這樣可以更科學(xué)、更高效地?cái)U(kuò)大有效測(cè)試范圍。如果有條件的話，可以通過(guò)閱讀開(kāi)發(fā)代碼來(lái)梳理相關(guān)邏輯，這樣用例設(shè)計(jì)的覆蓋面會(huì)更全。

2．減少冗余測(cè)試

減少冗余測(cè)試可以通過(guò)減少無(wú)效用例或者低成效的用例、優(yōu)化精簡(jiǎn)測(cè)試用例等方式進(jìn)行。

減少無(wú)效用例或者低成效的用例，詳細(xì)方法可以參考1.6節(jié)的數(shù)據(jù)反推。根據(jù)用例模塊化劃分，對(duì)Bug根據(jù)模塊（TAPD上相應(yīng)的模塊選項(xiàng)）進(jìn)行分類，統(tǒng)計(jì)每個(gè)模塊出現(xiàn)Bug的個(gè)數(shù)，如果多次執(zhí)行后Bug個(gè)數(shù)少的模塊，優(yōu)先級(jí)就降低。如果客戶端架構(gòu)穩(wěn)定后，對(duì)于后續(xù)新功能沒(méi)有涉及的這些模塊，則可以考慮不執(zhí)行相關(guān)用例。后續(xù)在每次集成測(cè)試后，測(cè)試結(jié)果都必須保存，統(tǒng)計(jì)經(jīng)常出現(xiàn)Bug的相關(guān)用例，優(yōu)化和增加相關(guān)測(cè)試用例，并且同步到各個(gè)平臺(tái)。

優(yōu)化精簡(jiǎn)測(cè)試用例，可以借助代碼覆蓋率作為標(biāo)準(zhǔn)，執(zhí)行原來(lái)的用例和精簡(jiǎn)優(yōu)化后的用例，如果兩者的代碼覆蓋率差不多，那就達(dá)到目的了。通過(guò)代碼覆蓋率測(cè)試，還可以找出沒(méi)有執(zhí)行過(guò)的冗余代碼，這樣可以減少安裝包的大小。借助精準(zhǔn)測(cè)試方法，通過(guò)精準(zhǔn)測(cè)試系統(tǒng)，分析測(cè)試用例以及代碼映射關(guān)系，可以進(jìn)一步確定測(cè)試用例的覆蓋情況。這樣就可以選擇適當(dāng)?shù)臏y(cè)試用例保證合理的覆蓋度。詳細(xì)的原理方法可以參見(jiàn)第10章。

1.4.2 白盒測(cè)試分析

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

1.5 測(cè)試設(shè)計(jì)

測(cè)試設(shè)計(jì)是一個(gè)系統(tǒng)性工程，涉及內(nèi)容比較多，從前期需求分析到用例設(shè)計(jì)，再到各類數(shù)據(jù)的分析等。下面我們擇取主流的理論來(lái)看一下。

1.5.1 探索式測(cè)試

探索式測(cè)試是目前業(yè)界比較流行的一種測(cè)試風(fēng)格，是由測(cè)試專家Cem Kaner博士于1983年提出的，后來(lái)經(jīng)過(guò)James Bach、James Whittaker等人的發(fā)展流行起來(lái)。國(guó)內(nèi)大多數(shù)人是因?yàn)镴ames Whittaker撰寫(xiě)了《Exploratory Software Testing》（探索式軟件測(cè)試）一書(shū)才了解探索式測(cè)試，并逐漸開(kāi)始應(yīng)用探索式測(cè)試，國(guó)內(nèi)的互聯(lián)網(wǎng)公司基本都會(huì)使用探索式測(cè)試。

探索式測(cè)試建議在整個(gè)項(xiàng)目過(guò)程中將測(cè)試學(xué)習(xí)、測(cè)試設(shè)計(jì)、測(cè)試執(zhí)行和測(cè)試結(jié)果解讀作為相互支持的活動(dòng)，并行地執(zhí)行?？捎脠D1-10來(lái)說(shuō)明。

探索式測(cè)試目前已經(jīng)充分應(yīng)用到騰訊公司的各個(gè)產(chǎn)品中，具體實(shí)踐案例請(qǐng)參見(jiàn)第8章的介紹。

1.5.2 基于模型的測(cè)試

基于模型的測(cè)試（Model-Based Testing, MBT）是根據(jù)用戶的需求建模，進(jìn)而根據(jù)模型自動(dòng)生成用例、自動(dòng)執(zhí)行驗(yàn)證過(guò)程的測(cè)試方式。圖1-11引用自《什么是基于模型的測(cè)試》[2]。

基于模型的測(cè)試在傳統(tǒng)軟件行業(yè)應(yīng)用較多，例如愛(ài)立信以及西門(mén)子使用比較廣泛，國(guó)內(nèi)的華為也有一些改進(jìn)應(yīng)用?；ヂ?lián)網(wǎng)公司如BAT也有一些嘗試，不過(guò)沒(méi)有太大規(guī)模應(yīng)用起來(lái)。在騰訊內(nèi)部，有些項(xiàng)目也在嘗試MBT，不過(guò)目前還沒(méi)有很好的典型案例，這里就不展開(kāi)介紹。MBT對(duì)測(cè)試人員的建模能力有很高的要求，同時(shí)學(xué)習(xí)成本也相對(duì)較高，整體收益周期較長(zhǎng)，所以比較難普及起來(lái)。

1.6 數(shù)據(jù)反推

1.6.1 測(cè)試過(guò)程中的數(shù)據(jù)

測(cè)試數(shù)據(jù)反推——充分利用各類測(cè)試數(shù)據(jù)的優(yōu)化流程，進(jìn)一步保障產(chǎn)品的質(zhì)量。在各階段的測(cè)試過(guò)程中會(huì)產(chǎn)生大量數(shù)據(jù)，例如Bug數(shù)據(jù)、測(cè)試通過(guò)率、回歸通過(guò)率等。那么如何充分利用這些數(shù)據(jù)呢？前面已對(duì)已知Bug以及未知Bug進(jìn)行了討論。現(xiàn)在換個(gè)角度，從Bug產(chǎn)生的階段來(lái)分析，圖1-12是不同階段Bug修復(fù)成本曲線。

針對(duì)Bug各階段的分析，根據(jù)圖1-12中Bug越早發(fā)現(xiàn)解決成本越低的結(jié)論，需要盡可能在最早引入的階段發(fā)現(xiàn)Bug。針對(duì)某些階段漏過(guò)的Bug分析，要盡可能完善測(cè)試設(shè)計(jì)覆蓋，避免Bug都留到集成階段發(fā)現(xiàn)，降低版本延期發(fā)布風(fēng)險(xiǎn)，從而開(kāi)發(fā)出更高效的發(fā)布版本。

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

也許有人會(huì)說(shuō)3%～6%并不算少，確實(shí)，不同項(xiàng)目有不同要求。這里介紹的思路就是充分利用這些數(shù)據(jù)去思考與分析，推動(dòng)團(tuán)隊(duì)采取動(dòng)作，逐步降低該比例，逐步降低發(fā)布風(fēng)險(xiǎn)，提升發(fā)布效率。分支合流模型的測(cè)試如何開(kāi)展是另外一個(gè)話題，不過(guò)大體思路都差不多，除了基本持續(xù)集成外，還需要自動(dòng)化測(cè)試（BVT、接口測(cè)試、終端性能測(cè)試等）的支持，才能快速支持分支合流的快速研發(fā)模型。

再舉一個(gè)例子，Bug各模塊分布，有些模塊Bug問(wèn)題比較多，可能需要特別關(guān)注測(cè)試，因?yàn)楦鶕?jù)測(cè)試的二八法則——80%的缺陷出現(xiàn)在20%的代碼中，所以對(duì)這些模塊需要多分析多做測(cè)試，這樣可以更大可能發(fā)現(xiàn)潛在問(wèn)題。一般來(lái)說(shuō)，不同模塊會(huì)對(duì)應(yīng)不同的開(kāi)發(fā)團(tuán)隊(duì)或者FT，也可以通過(guò)Bug來(lái)評(píng)估開(kāi)發(fā)團(tuán)隊(duì)（或者FT）的成熟度，根據(jù)不同的開(kāi)發(fā)團(tuán)隊(duì)（FT）制定相應(yīng)的改善措施，用數(shù)據(jù)說(shuō)話，這樣更好地推動(dòng)團(tuán)隊(duì)的正向優(yōu)化。表1-1所示的是另外一個(gè)項(xiàng)目團(tuán)隊(duì)某個(gè)版本的各個(gè)FT存在的缺陷占比，從表中可以看出模塊A是缺陷高發(fā)區(qū)，出現(xiàn)這種情況需要和對(duì)應(yīng)模塊的負(fù)責(zé)人進(jìn)行溝通，細(xì)查原因，以利于改進(jìn)。

以上僅僅是從Bug模塊分布來(lái)分析Bug數(shù)據(jù)，其實(shí)還可以從很多維度（從開(kāi)發(fā)人員的維度、用戶行為的維度等）去挖掘Bug數(shù)據(jù)，充分利用Bug數(shù)據(jù)來(lái)優(yōu)化測(cè)試設(shè)計(jì)，提升測(cè)試效率。

1.6.2 線上數(shù)據(jù)

以上介紹的大多是與研發(fā)過(guò)程品質(zhì)相關(guān)的，其實(shí)還有一個(gè)很重要的方向就是線上品質(zhì)，通過(guò)線上海量用戶上報(bào)的數(shù)據(jù)來(lái)度量產(chǎn)品品質(zhì)。大多數(shù)情況下，研發(fā)過(guò)程品質(zhì)始終無(wú)法保證線上品質(zhì)。比如用戶反饋的重現(xiàn)問(wèn)題，就是線上用戶反饋的問(wèn)題我們?cè)趺匆仓噩F(xiàn)不了，即使嚴(yán)格按照用戶的步驟、機(jī)型、網(wǎng)絡(luò)等場(chǎng)景也重現(xiàn)不了。研發(fā)過(guò)程中測(cè)試的數(shù)據(jù)跟線上用戶的數(shù)據(jù)對(duì)應(yīng)不上，例如某個(gè)產(chǎn)品的啟動(dòng)速度，研發(fā)過(guò)程中測(cè)試的啟動(dòng)時(shí)間是2.3秒（測(cè)試20次取平均值），而線上用戶上報(bào)的數(shù)據(jù)是3.2秒（20萬(wàn)個(gè)用戶上報(bào)的平均值）。

業(yè)界也有相關(guān)測(cè)試方法，例如微軟公司提出的TiP（Testing in Production），就是通過(guò)版本上線后海量用戶上報(bào)各類數(shù)據(jù)來(lái)發(fā)現(xiàn)潛在的問(wèn)題。測(cè)試人員需要關(guān)注各類性能數(shù)據(jù)，例如啟動(dòng)速度、內(nèi)存、流暢度、響應(yīng)時(shí)間、Crash率等。因?yàn)橛脩舻臋C(jī)型、網(wǎng)絡(luò)、地域、數(shù)據(jù)環(huán)境不同，所以不同用戶上報(bào)的數(shù)據(jù)差異很大，這里需要做一些數(shù)據(jù)統(tǒng)計(jì)的分析處理，才能更好地展現(xiàn)出來(lái)。由于線上環(huán)境的復(fù)雜性，線上數(shù)據(jù)反映的結(jié)果會(huì)比測(cè)試數(shù)據(jù)差一些。

那么如何通過(guò)線上數(shù)據(jù)來(lái)分析定位問(wèn)題呢？主要的方法就是對(duì)某些指標(biāo)進(jìn)行詳細(xì)埋點(diǎn)上報(bào)，這樣才能獲得更詳細(xì)數(shù)據(jù)并進(jìn)行分析，最后找到問(wèn)題所在。還是以某個(gè)產(chǎn)品的啟動(dòng)速度為例來(lái)說(shuō)明（啟動(dòng)速度是指用戶點(diǎn)擊應(yīng)用圖標(biāo)開(kāi)始到拉取完數(shù)據(jù)展示給用戶的這個(gè)時(shí)間段）。

App啟動(dòng)后就會(huì)到后臺(tái)服務(wù)器拉取數(shù)據(jù)，從大的方向來(lái)看，需要區(qū)分后臺(tái)服務(wù)器耗時(shí)以及App處理的耗時(shí)，這樣可以方便前端或者后臺(tái)解決問(wèn)題。如圖1-14所展示的，“等待響應(yīng)”就是后臺(tái)服務(wù)器耗時(shí)（其中也包含網(wǎng)絡(luò)傳輸?shù)暮臅r(shí)）。一般可以通過(guò)抓取網(wǎng)絡(luò)包分析得出相關(guān)耗時(shí)。

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

當(dāng)然，只區(qū)分客戶端跟后臺(tái)服務(wù)器各自的耗時(shí)是遠(yuǎn)遠(yuǎn)不夠的，還需要細(xì)分到每個(gè)主要函數(shù)的耗時(shí)，這樣才能更好地定位具體是哪部分耗時(shí)。圖1-15所示的是某個(gè)App對(duì)關(guān)鍵函數(shù)（節(jié)點(diǎn)）的日志統(tǒng)計(jì)。

圖1-15只是啟動(dòng)速度這個(gè)指標(biāo)需要記錄的數(shù)據(jù)，可能發(fā)現(xiàn)需要記錄的數(shù)據(jù)非常多，對(duì)這些記錄的日志也會(huì)進(jìn)行分級(jí)，線上發(fā)布版本的日志會(huì)盡量少一些，不過(guò)關(guān)鍵的地方還是需要記錄的。當(dāng)然，版本加了日志會(huì)對(duì)性能有所損耗，不過(guò)在可接受的范圍內(nèi)，還是有必要的；通過(guò)線上版本的數(shù)據(jù)上報(bào)，可以得到用戶真實(shí)的數(shù)據(jù)，發(fā)現(xiàn)潛在問(wèn)題并逐步優(yōu)化，給用戶更好的體驗(yàn)，提升產(chǎn)品口碑。

測(cè)試數(shù)據(jù)還可以預(yù)測(cè)即將發(fā)布版本的質(zhì)量，不管是研發(fā)過(guò)程還是灰度階段，都將會(huì)產(chǎn)生很多測(cè)試數(shù)據(jù)。那么是否可以充分利用這些數(shù)據(jù)來(lái)預(yù)測(cè)上線版本的質(zhì)量趨勢(shì)呢？這確實(shí)是一個(gè)方向，但是需要大量的測(cè)試數(shù)據(jù)才可能有機(jī)會(huì)預(yù)測(cè)靠譜。因?yàn)榫€上用戶的各種機(jī)型系統(tǒng)、網(wǎng)絡(luò)狀況、用戶環(huán)境數(shù)據(jù)，這些都很難在上線前的環(huán)境覆蓋到，所以就很難預(yù)測(cè)線上版本的質(zhì)量。如果灰度群體足夠，那么還是有機(jī)會(huì)的。騰訊內(nèi)部的很多項(xiàng)目，產(chǎn)品穩(wěn)定性問(wèn)題（Crash率）都是通過(guò)灰度來(lái)發(fā)現(xiàn)問(wèn)題的，Crash率達(dá)到一定程度，就可以進(jìn)一步擴(kuò)大灰度規(guī)模，逐步迭代放大灰度數(shù)量，直至上線。

1.7 未來(lái)的測(cè)試

這一節(jié)內(nèi)容都是筆者暢想的，如有雷同，純屬意外。

移動(dòng)互聯(lián)網(wǎng)時(shí)代，特別是Native的App，版本更新的成本很高（除時(shí)間成本，還有對(duì)用戶體驗(yàn)的影響），所以大多數(shù)App都會(huì)經(jīng)過(guò)充分的測(cè)試再發(fā)布版本。

隨著熱補(bǔ)?。╤otfix）技術(shù)的演進(jìn)以及H5的流行，可以不需要發(fā)布新版本而發(fā)布一個(gè)補(bǔ)丁就可以發(fā)布新功能或者修復(fù)問(wèn)題（而且用戶基本無(wú)感知，不需要安裝過(guò)程，下次啟動(dòng)就自動(dòng)更新了），這樣就可以在沒(méi)有充分測(cè)試的情況下，快速通過(guò)用戶來(lái)驗(yàn)證。這樣對(duì)測(cè)試的依賴可能會(huì)越來(lái)越小。那么未來(lái)的產(chǎn)品都是通過(guò)用戶（灰度或者正式上線）直接驗(yàn)證嗎？

應(yīng)該不可能全部都通過(guò)用戶來(lái)驗(yàn)證（灰度或者正式上線），不經(jīng)過(guò)測(cè)試而直接上線，可能出現(xiàn)問(wèn)題的概率會(huì)增大，如果真的出現(xiàn)問(wèn)題，那么會(huì)對(duì)產(chǎn)品的口碑帶來(lái)很大的影響。但是熱補(bǔ)丁技術(shù)確實(shí)是可以快速修復(fù)問(wèn)題的方案，以后會(huì)被逐步應(yīng)用。即使利用熱補(bǔ)丁技術(shù)，還是需要度量產(chǎn)品品質(zhì)的，例如線上用戶各類性能指標(biāo)以及用戶反饋等，對(duì)于品質(zhì)的追求還是始終存在的，也就是仍需要有人來(lái)做品質(zhì)這樣的工作。

1.7.1 線上數(shù)據(jù)挖掘

既然線上數(shù)據(jù)會(huì)越來(lái)越重要，那么就需要一整套埋點(diǎn)上報(bào)體系（終端是SDK形式，服務(wù)端存儲(chǔ)各類數(shù)據(jù)），同時(shí)對(duì)上報(bào)數(shù)據(jù)進(jìn)行數(shù)據(jù)分析，可能需要利用到機(jī)器學(xué)習(xí)等技術(shù)分析數(shù)據(jù)，判斷是否有潛在問(wèn)題。數(shù)據(jù)上報(bào)體系是每個(gè)App都有的基本功能，包含需要關(guān)注具體上報(bào)什么信息，例如，

（1）路徑埋點(diǎn)：關(guān)鍵路徑的埋點(diǎn)。

（2）錯(cuò)誤碼信息：統(tǒng)一錯(cuò)誤碼設(shè)計(jì)，方便排查。

（3）調(diào)用堆棧：堆棧調(diào)用信息。

（4）方法跟蹤：函數(shù)方法的鏈條。

（5）用戶動(dòng)作：用戶操作路徑（可以詳細(xì)到用戶何時(shí)點(diǎn)擊哪個(gè)控件）。

（6）機(jī)型網(wǎng)絡(luò)信息：基礎(chǔ)手機(jī)信息收集。

（7）性能指標(biāo)（內(nèi)存/CPU/FPS）：各類性能指標(biāo)的消息速度/流量/函數(shù)調(diào)用時(shí)間。

在對(duì)App全方位埋點(diǎn)后，就會(huì)有上報(bào)的數(shù)據(jù)，哪些數(shù)據(jù)需要進(jìn)行分析，具體分析方法各種各樣，如圖1-16所示。該圖主要描述了一種線上數(shù)據(jù)分析模型，包括數(shù)據(jù)收集容器、數(shù)據(jù)分析容器、Bug處理容器三個(gè)部分。

如果埋點(diǎn)上報(bào)體系建設(shè)完善，任何人（Dogfood、Showcase、眾測(cè)、灰度等）只要體驗(yàn)產(chǎn)品，就是給產(chǎn)品做測(cè)試，這樣就會(huì)上報(bào)很多數(shù)據(jù)，再系統(tǒng)分析這些數(shù)據(jù)，進(jìn)而找到某些潛在問(wèn)題。

1.7.2 人工智能

最近，F(xiàn)acebook發(fā)布聊天機(jī)器人Chatbot, Google發(fā)布Google Assistant以及Google Home音箱，Amazon也發(fā)布Echo音箱，整個(gè)業(yè)界的發(fā)展趨勢(shì)變成從App演進(jìn)到Bot。同時(shí)，Google的戰(zhàn)略也從Mobile First轉(zhuǎn)變?yōu)锳I First。那么對(duì)于人工智能（Bot），應(yīng)該怎么測(cè)試呢？

業(yè)界暫時(shí)還沒(méi)有開(kāi)源或者公開(kāi)的測(cè)試方案，可能各公司也都在探索中，傳統(tǒng)上針對(duì)AI的算法測(cè)試也是持續(xù)演進(jìn)的。我們先回到人工智能本身，其實(shí)就是對(duì)數(shù)據(jù)的智能處理（這也是擁有大數(shù)據(jù)的Google等公司的人工智能快速發(fā)展的原因之一），那么人工智能測(cè)試還是得圍繞數(shù)據(jù)進(jìn)行測(cè)試。當(dāng)然，這樣的數(shù)據(jù)是海量的，因此要采用抽樣模型進(jìn)行評(píng)測(cè)?？偟膩?lái)說(shuō)，就是構(gòu)建以及收集數(shù)據(jù)樣本。數(shù)據(jù)樣本的構(gòu)建，需要對(duì)具體處理數(shù)據(jù)結(jié)構(gòu)足夠了解，然后通過(guò)自動(dòng)化方式生成樣本數(shù)據(jù)。同時(shí)，除了構(gòu)建樣本數(shù)據(jù)，還可以通過(guò)另外的渠道來(lái)收集用戶數(shù)據(jù)，例如眾測(cè)或者眾包的方式收集樣本數(shù)據(jù)。

除了對(duì)數(shù)據(jù)的測(cè)試外，在人工智能出現(xiàn)后，人機(jī)交互方式會(huì)出現(xiàn)大的變化，語(yǔ)音交互可能是主要交互模式之一，那么如何保證優(yōu)秀的用戶體驗(yàn)?zāi)兀拷换ピu(píng)測(cè)需要真實(shí)用戶的參與，首先設(shè)計(jì)合理的評(píng)測(cè)問(wèn)卷，然后通過(guò)眾測(cè)或者眾包等平臺(tái)引入不同用戶的參與，通過(guò)雙盲測(cè)試收集各類數(shù)據(jù)。同時(shí)也會(huì)通過(guò)AB Test來(lái)收集線上用戶的反饋，不斷改善用戶體驗(yàn)。

總的來(lái)說(shuō)，人工智能測(cè)試除了對(duì)AI算法的測(cè)試外，還需要關(guān)注數(shù)據(jù)類測(cè)試+交互類測(cè)試。

1.7.3 眾測(cè)

上面提到的線上數(shù)據(jù)挖掘（需要各種機(jī)型、網(wǎng)絡(luò)、數(shù)據(jù)環(huán)境等）以及人工智能（數(shù)據(jù)樣本采集）都需要有一定量的真實(shí)用戶參與，才能更好地評(píng)測(cè)產(chǎn)品品質(zhì)。那么可能就需要用共享經(jīng)濟(jì)的方式，快速集合一群合適用戶來(lái)幫忙做評(píng)測(cè)（收集數(shù)據(jù)或者產(chǎn)品體驗(yàn)等），這就是最近幾年業(yè)界流行的眾測(cè)（眾包）模式。眾測(cè)（眾包）模式的優(yōu)點(diǎn)如下。

（1）閉環(huán)時(shí)間短，溝通效率高：因?yàn)橛袌?bào)酬等激勵(lì)，眾測(cè)（眾包）用戶積極度更高。

（2）定向用戶屬性支持：眾測(cè)（眾包）平臺(tái)會(huì)收集用戶屬性，例如性別、年齡、職務(wù)、學(xué)歷等，更有針對(duì)性地向合適人群做評(píng)測(cè)。

（3）定向設(shè)備屬性支持：眾測(cè)（眾包）平臺(tái)會(huì)收集設(shè)備屬性，例如機(jī)型、ROM、網(wǎng)絡(luò)、地域等，更有針對(duì)性地向合適人群做評(píng)測(cè)，特別是對(duì)于地域有特殊要求的，可以快速響應(yīng)。

（4）用戶行為高度可控、可刷機(jī)、可支付。眾測(cè)（眾包）平臺(tái)的用戶都是相對(duì)狂熱的粉絲，可以幫助做一些特殊操作，例如重復(fù)刷機(jī)、重復(fù)嘗試某個(gè)問(wèn)題。

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

（1）需求評(píng)測(cè)（評(píng)估需求的適用范圍等）。

（2）機(jī)型覆蓋測(cè)試（覆蓋各類機(jī)型適配情況）。

（3）重要問(wèn)題復(fù)現(xiàn)（某些問(wèn)題的復(fù)現(xiàn)）。

（4）大量數(shù)據(jù)收集（數(shù)據(jù)標(biāo)準(zhǔn)類）。

（5）問(wèn)卷調(diào)查收集（用戶調(diào)研）。

（6）復(fù)雜環(huán)境評(píng)測(cè)（某些功能的評(píng)測(cè)）。

眾測(cè)（眾包）使用可能是一個(gè)趨勢(shì)，有能力的公司可以逐步建設(shè)這樣的平臺(tái)，這樣能更快地驗(yàn)證產(chǎn)品，產(chǎn)品驗(yàn)證的成本會(huì)更低。

1.8 小結(jié)

通過(guò)本章的內(nèi)容，先和讀者建立了一個(gè)測(cè)試基礎(chǔ)共識(shí)，便于接下來(lái)的章節(jié)理解?？傮w來(lái)說(shuō)，我們認(rèn)為測(cè)試=工程效率+品質(zhì)管理，如何提升工程效率和品質(zhì)管理是測(cè)試提升的核心內(nèi)容。在測(cè)試的不同階段，測(cè)試分析、測(cè)試設(shè)計(jì)、數(shù)據(jù)反推都能發(fā)揮一定的作用，未來(lái)的空間很大，需要我們一起去探索。