么是產(chǎn)品測(cè)試？測(cè)試可歸為兩點(diǎn)：程序做了它應(yīng)該做的事情；程序沒(méi)有做它不該做的事情。

1、寫(xiě)在前面

文章主要涉及產(chǎn)品經(jīng)理工作上經(jīng)常接觸到的基礎(chǔ)的測(cè)試知識(shí)，包括測(cè)試的定義、測(cè)試何時(shí)進(jìn)行、產(chǎn)品經(jīng)理應(yīng)該懂的測(cè)試概念、產(chǎn)品經(jīng)理如何測(cè)試驗(yàn)收產(chǎn)品。

2、為什么產(chǎn)品經(jīng)理需要懂測(cè)試

產(chǎn)品每個(gè)階段都有驗(yàn)收標(biāo)準(zhǔn)，比如需求評(píng)審階段驗(yàn)收、開(kāi)發(fā)階段驗(yàn)收，所以每個(gè)階段都需要測(cè)試。產(chǎn)品經(jīng)理盡管不是專業(yè)的測(cè)試人員，但產(chǎn)品經(jīng)理作為最熟悉產(chǎn)品的人，理應(yīng)對(duì)產(chǎn)品每個(gè)階段都進(jìn)行相應(yīng)的測(cè)試驗(yàn)收產(chǎn)品，比如功能測(cè)試、可用性測(cè)試、用戶體驗(yàn)測(cè)試，確保符合需求文檔的要求，所以產(chǎn)品經(jīng)理應(yīng)該懂得相應(yīng)的測(cè)試知識(shí)。

產(chǎn)品經(jīng)理懂測(cè)試，在相應(yīng)的測(cè)試方式中驗(yàn)收產(chǎn)品的時(shí)候，能更清楚的系統(tǒng)地記錄產(chǎn)品的每個(gè)問(wèn)題，然后用產(chǎn)品思維去思考如何解決這些問(wèn)題。

可以用極簡(jiǎn)主義去思考如何把選擇復(fù)雜的問(wèn)題簡(jiǎn)單化減少用戶的選擇，比如刻意顯示引導(dǎo)用戶選擇的功能按鈕或隱藏用戶很少用到的功能，比如微信用戶很少用到的朋友圈停用的功能，使用路徑刻意加深隱藏。

可以用可用性原則的思維去思考如何去引導(dǎo)用戶更好的完成產(chǎn)品使用，比如頁(yè)面說(shuō)明該頁(yè)面所處的位置狀態(tài)，比如微信的朋友圈頁(yè)面頂部顯示朋友圈的位置說(shuō)明。

可以用情感化設(shè)計(jì)的思維去思考如何超出用戶的期望，比如微信聊天窗口發(fā)送我想你了會(huì)落下滿天星星的效果超出用戶的期望。

可以用可行性的思維去思考如何用現(xiàn)有的資源解決產(chǎn)品的問(wèn)題，比如前端工程師人數(shù)少的情況下可以直接借助前端開(kāi)源框架快速開(kāi)發(fā)MVP，比如借助bootstrap。

還可以去和開(kāi)發(fā)人員溝通如何解決app使用卡頓啟動(dòng)難加載緩慢等產(chǎn)品本身的性能問(wèn)題，比如使用網(wǎng)易新聞app滑動(dòng)時(shí)卡頓，開(kāi)發(fā)人員會(huì)告訴你其中的一個(gè)原因是因?yàn)槊總€(gè)頁(yè)面上承受的控件過(guò)多，app一個(gè)頁(yè)面看起來(lái)的效果是一個(gè)平面，但app中一個(gè)頁(yè)面的組成由webview或者文本框等多個(gè)控件布局疊加的，控件過(guò)多會(huì)占用內(nèi)存，導(dǎo)致使用卡頓，這時(shí)你可以思考如何去平衡控件數(shù)量和卡頓體驗(yàn)問(wèn)題。

所以懂得測(cè)試，產(chǎn)品經(jīng)理能更好地溝通，能更好地測(cè)試驗(yàn)收產(chǎn)品確保符合產(chǎn)品需求文檔，能更好地解決和優(yōu)化產(chǎn)品。

產(chǎn)品經(jīng)理不應(yīng)該只為一個(gè)產(chǎn)品設(shè)計(jì)而不為一個(gè)產(chǎn)品測(cè)試。

補(bǔ)充說(shuō)明：網(wǎng)易新聞app使用卡頓的原因之控件

以android為例，首先打開(kāi)顯示布局邊界，在開(kāi)發(fā)者選項(xiàng)里可以找到顯示布局邊界，打開(kāi)。然后再打開(kāi)網(wǎng)易新聞，如下圖，你會(huì)看到界面布滿各種邊界，每個(gè)邊界都是一個(gè)控件，控件可以包括控件，所以你會(huì)看到大邊界包括小邊界。如下圖所示：

當(dāng)然有些為了使用流暢度，會(huì)采用webview控件，就相當(dāng)于調(diào)用一個(gè)網(wǎng)頁(yè)顯示內(nèi)容的控件，但是也影響使用用戶體驗(yàn)，內(nèi)容加載慢，目前利用cache緩存技術(shù)提供離線功能，預(yù)加載。新聞詳情的大邊界就是一個(gè)webview，如下圖所示：

一些建議：

原生UI應(yīng)用場(chǎng)景：

• 流暢度體驗(yàn)要求高的
• UI樣式相對(duì)固定
• 交互復(fù)雜

webview的HTML5頁(yè)面應(yīng)用場(chǎng)景：

• 活動(dòng)運(yùn)營(yíng)的頁(yè)面需求，可重復(fù)調(diào)用
• 交互簡(jiǎn)單

3、測(cè)試的定義

測(cè)試，顧名思義就是測(cè)試程序保證其可正確運(yùn)行。而早期的測(cè)試定義就是如此，即對(duì)程序能夠按預(yù)期運(yùn)行建立起一種信心。隨著技術(shù)的發(fā)展，目前測(cè)試的經(jīng)典定義是，在規(guī)定的條件下對(duì)程序進(jìn)行操作，以發(fā)現(xiàn)程序錯(cuò)誤，衡量軟件質(zhì)量，并對(duì)其是否能滿足設(shè)計(jì)要求進(jìn)行評(píng)估的過(guò)程。即運(yùn)行程序發(fā)現(xiàn)錯(cuò)誤。

目前普遍使用行業(yè)標(biāo)準(zhǔn)IEEE/ANSI的測(cè)試定義：使用人工或自動(dòng)的手段來(lái)運(yùn)行或測(cè)定某個(gè)軟件系統(tǒng)的過(guò)程，其目的在于檢驗(yàn)它是否滿足規(guī)定的需求或弄清預(yù)期結(jié)果與實(shí)際結(jié)果之間的差別。目的是為了檢驗(yàn)軟件系統(tǒng)是否滿足需求。

從以上我們可以看出，不管怎么定義，測(cè)試既需要程序能符合需求文檔的要求運(yùn)行，也不能產(chǎn)生錯(cuò)誤，測(cè)試可以歸為兩點(diǎn)：程序做了它應(yīng)該做的事情；程序沒(méi)有做它不該做的事情。

注意，軟件測(cè)試不等于程序測(cè)試，測(cè)試的對(duì)象包括文檔、數(shù)據(jù)、程序。

4、測(cè)試何時(shí)進(jìn)行

我們看看一張發(fā)現(xiàn)缺陷的時(shí)間和缺陷修復(fù)成本的關(guān)系圖，下圖，其中，橫軸表示項(xiàng)目開(kāi)發(fā)周期時(shí)間階段，縱軸表示缺陷占比。如下圖所示：

從圖中，我們可以看出越后期修復(fù)缺陷的成本就越高，且指數(shù)增長(zhǎng)，而缺陷主要是開(kāi)發(fā)前期引入的，且前期缺陷修復(fù)成本很低，所以我們應(yīng)該知道，測(cè)試越早越好。

前面說(shuō)過(guò)，測(cè)試的對(duì)象包括文檔、數(shù)據(jù)、程序，即測(cè)試貫穿軟件開(kāi)發(fā)開(kāi)發(fā)周期，從需求開(kāi)始到編碼到驗(yàn)收測(cè)試結(jié)束，包括但不限于對(duì)需求、概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)、源碼、可運(yùn)行程序、運(yùn)行環(huán)境的測(cè)試。所以，產(chǎn)品經(jīng)理應(yīng)該從需求開(kāi)始階段就進(jìn)行測(cè)試產(chǎn)品，當(dāng)然，專門(mén)的測(cè)試人員也應(yīng)該從需求開(kāi)始階段就參與測(cè)試，產(chǎn)品的相關(guān)人員越早參與進(jìn)來(lái)，對(duì)產(chǎn)品的需求理解就越透徹，還可以對(duì)需求二次分析補(bǔ)充。

當(dāng)然這里我們主要講產(chǎn)品程序可運(yùn)行后的相關(guān)測(cè)試，畢竟編碼前的需求評(píng)審、原型、UE、UI的測(cè)試，這是每個(gè)產(chǎn)品經(jīng)理必須具備的技能，編碼期間的單元測(cè)試集成測(cè)試主要是開(kāi)發(fā)人員實(shí)施，所以我們主要是討論產(chǎn)品程序可運(yùn)行后的相關(guān)測(cè)試。

產(chǎn)品程序可運(yùn)行后開(kāi)發(fā)人員交付build給產(chǎn)品經(jīng)理和測(cè)試人員的測(cè)試流程一般為用例測(cè)試（是否符合需求文檔）、探索測(cè)試（是否存在隱患bug）、其他測(cè)試（兼容性、安全性……）。

補(bǔ)充說(shuō)明：編碼前的需求評(píng)審、原型、UE、UI的測(cè)試重點(diǎn)：

• 需求評(píng)審：定位、用戶畫(huà)像、說(shuō)明規(guī)則是否明確；
• 原型：頁(yè)面是否完整，信息架構(gòu)是否清晰；
• UE：業(yè)務(wù)流程是否舒適；
• UI：視覺(jué)設(shè)計(jì)是否干凈，風(fēng)格是否一致；

這些編碼前的測(cè)試一定要驗(yàn)收，因?yàn)闀?huì)直接影響到產(chǎn)品開(kāi)發(fā)的后續(xù)，比如UI測(cè)試的視覺(jué)設(shè)計(jì)，直接影響到目標(biāo)產(chǎn)品的整個(gè)生命周期的視覺(jué)效果。

5、產(chǎn)品經(jīng)理應(yīng)該懂的測(cè)試概念

產(chǎn)品經(jīng)理和測(cè)試人員溝通需求或者反饋產(chǎn)品的bug時(shí)，經(jīng)常聽(tīng)到測(cè)試人員說(shuō)的腳本錄制及自動(dòng)化測(cè)試的一些測(cè)試概念上名詞，經(jīng)常會(huì)說(shuō)什么這個(gè)功能模塊采用黑盒測(cè)試的流程分析法就知道bug的位置了，這個(gè)時(shí)候產(chǎn)品經(jīng)理就懵逼，感覺(jué)溝通不下去了，產(chǎn)品做不下去了。

產(chǎn)品經(jīng)理懂得崗位的相關(guān)上下游知識(shí)，可以更好的處理好工作，比如和測(cè)試人員溝通需求時(shí)，測(cè)試人員會(huì)說(shuō)文檔測(cè)試通過(guò)了嗎，或者說(shuō)這個(gè)等到集成測(cè)試后再系統(tǒng)測(cè)試驗(yàn)證這個(gè)問(wèn)題吧，這些測(cè)試上的名詞，如果你懂的話，那么溝通起來(lái)就會(huì)很順利，你就不會(huì)去問(wèn)什么是文檔測(cè)試，什么是集成測(cè)試，既節(jié)約時(shí)間，更主要可以讓產(chǎn)品的相關(guān)人員都能清楚地理解需求。

所以，這里我們講講產(chǎn)品經(jīng)理一般接觸到的測(cè)試概念。

測(cè)試一般是隨著項(xiàng)目開(kāi)發(fā)周期進(jìn)行，根據(jù)開(kāi)發(fā)模型對(duì)應(yīng)相應(yīng)的測(cè)試模式，比如瀑布開(kāi)發(fā)模型的測(cè)試模式。測(cè)試分類有多個(gè)維度分類，比如根據(jù)測(cè)試階段、測(cè)試手段、測(cè)試模塊的維度分類，每個(gè)測(cè)試分類都有相應(yīng)的測(cè)試辦法，比如系統(tǒng)測(cè)試、白盒測(cè)試、黑盒測(cè)試、自動(dòng)化測(cè)試。

目前，我們最常用的開(kāi)發(fā)模型是V模型，如下圖所示：

所以我們主要是根據(jù)V模型講講解測(cè)試知識(shí)。

V模型是按測(cè)試階段來(lái)分類測(cè)試，分為單元測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試、驗(yàn)收測(cè)試，這也是根據(jù)開(kāi)發(fā)進(jìn)度進(jìn)行的測(cè)試分類。

單元測(cè)試：又稱模塊測(cè)試，是針對(duì)軟件設(shè)計(jì)的最小單位 ─ 程序模塊，進(jìn)行正確性檢驗(yàn)的測(cè)試工作。其目的在于發(fā)現(xiàn)各模塊內(nèi)部可能存在的各種差錯(cuò)。由開(kāi)發(fā)人員實(shí)施，用以檢驗(yàn)所開(kāi)發(fā)的代碼功能符合設(shè)計(jì)要求。單元測(cè)試是其他測(cè)試的基礎(chǔ)，單元測(cè)試用例代碼和函數(shù)一對(duì)一，便于維護(hù)和實(shí)現(xiàn)條件覆蓋與路徑覆蓋，可以盡早發(fā)現(xiàn)缺陷和利于重構(gòu)，但一行代碼需要3-5行測(cè)試代碼才能完成單元測(cè)試，支出較大，典型的空間換取利益，所以需要權(quán)衡。

單元測(cè)試有相應(yīng)的測(cè)試框架，比如Xunit、Junit、PHPunit。我們平時(shí)接觸的敏捷開(kāi)發(fā)比較強(qiáng)調(diào)TDD（測(cè)試驅(qū)動(dòng)開(kāi)發(fā)），即在開(kāi)發(fā)功能代碼之前，先編寫(xiě)單元測(cè)試用例代碼，測(cè)試代碼確定需要編寫(xiě)什么產(chǎn)品代碼。這樣能保證功能代碼的正確性，也能保證對(duì)需求的二次確認(rèn)和理解，對(duì)需求設(shè)計(jì)有個(gè)清晰的認(rèn)識(shí)。

集成測(cè)試：也稱聯(lián)合測(cè)試，將程序模塊采用適當(dāng)?shù)募刹呗越M裝起來(lái)，對(duì)系統(tǒng)的接口及集成后的功能進(jìn)行正確性檢測(cè)的測(cè)試工作。其主要目的是檢查軟件單位之間的接口是否正確，集成測(cè)試的對(duì)象是已經(jīng)經(jīng)過(guò)單元測(cè)試的模塊。

集成測(cè)試的主要實(shí)施方案：一次性集成方法（big bang），即一次性把所有模塊組裝起來(lái)測(cè)試；增殖式集成方式，即一個(gè)個(gè)模塊持續(xù)集成測(cè)試，最后把所有模塊組裝起來(lái)。

系統(tǒng)測(cè)試：通過(guò)確認(rèn)測(cè)試的軟件，作為整個(gè)基于計(jì)算機(jī)系統(tǒng)的一個(gè)元素，與計(jì)算機(jī)硬件、外設(shè)、某些支持軟件、數(shù)據(jù)和人員等其它系統(tǒng)元素結(jié)合在一起，在實(shí)際運(yùn)行環(huán)境下，對(duì)計(jì)算機(jī)系統(tǒng)進(jìn)行一系列的組裝測(cè)試和確認(rèn)測(cè)試。系統(tǒng)測(cè)試的目的在于通過(guò)與系統(tǒng)（軟件）的需求定義作比較， 發(fā)現(xiàn)軟件與系統(tǒng)（軟件）的定義不符合或與之矛盾的地方。即把可運(yùn)行的軟件安裝在真實(shí)環(huán)境下操作使用，測(cè)試軟件的功能和性能，比如某功能能否正常運(yùn)行，軟件在該平臺(tái)下能否正常運(yùn)行。

系統(tǒng)測(cè)試主要是從業(yè)務(wù)角度驗(yàn)證產(chǎn)品是否符合需求文檔，所以，產(chǎn)品經(jīng)理測(cè)試產(chǎn)品是否符合需求文檔和設(shè)計(jì)的要求，一般都是在系統(tǒng)測(cè)試階段。當(dāng)然，測(cè)試人員主要針對(duì)的也是系統(tǒng)測(cè)試階段。

驗(yàn)收測(cè)試：也稱交付測(cè)試，以用戶為主的測(cè)試，由用戶參加設(shè)計(jì)測(cè)試用例，使用生產(chǎn)中的實(shí)際數(shù)據(jù)進(jìn)行測(cè)試，確定軟件是否滿足驗(yàn)收標(biāo)準(zhǔn)，是否接受系統(tǒng)軟件。

驗(yàn)收測(cè)試驅(qū)動(dòng)開(kāi)發(fā)，是TDD的延伸，也就是定義好用戶故事，驗(yàn)收標(biāo)準(zhǔn)，再去開(kāi)發(fā)功能，功能通過(guò)驗(yàn)收標(biāo)準(zhǔn)，功能滿足用戶故事。

從上面的定義，我們知道產(chǎn)品經(jīng)理測(cè)試驗(yàn)收產(chǎn)品一般是在系統(tǒng)測(cè)試階段，系統(tǒng)測(cè)試主要包括功能測(cè)試、界面測(cè)試、可靠性測(cè)試、易用性測(cè)試、兼容性測(cè)試、性能測(cè)試。 功能測(cè)試主要針對(duì)包括功能可用性、功能實(shí)現(xiàn)程度（功能流程&業(yè)務(wù)流程、數(shù)據(jù)處理&業(yè)務(wù)數(shù)據(jù)處理）方面測(cè)試。其中功能測(cè)試是最主要的一種測(cè)試類型，一般說(shuō)測(cè)試就是功能測(cè)試。

功能測(cè)試：對(duì)產(chǎn)品的各功能進(jìn)行驗(yàn)證，根據(jù)功能測(cè)試用例，逐項(xiàng)測(cè)試，檢查產(chǎn)品是否達(dá)到用戶要求的功能。測(cè)試人員會(huì)借助一些功能測(cè)試工具，比如QTP winrunner，主要是測(cè)試業(yè)務(wù)流程。

界面測(cè)試：也稱UI測(cè)試，測(cè)試用戶界面的功能模塊的布局是否合理、整體風(fēng)格是否一致、各個(gè)控件的放置位置是否符合客戶使用習(xí)慣，此外還要測(cè)試界面操作便捷性、導(dǎo)航簡(jiǎn)單易懂性，頁(yè)面元素的可用性，界面中文字是否正確，命名是否統(tǒng)一，頁(yè)面是否美觀，文字、圖片組合是否完美等。

可靠性測(cè)試：對(duì)軟件或者硬件的一種質(zhì)量測(cè)試，用來(lái)檢測(cè)產(chǎn)品是否存在不可靠因素，比如硬件老化。

易用性測(cè)試：指用戶使用軟件時(shí)是否感覺(jué)方便，主要特點(diǎn)為易理解性、易學(xué)性、易操作性、吸引性、易用的依從性，比如是否最多點(diǎn)擊鼠標(biāo)三次就可以達(dá)到用戶的目的。易用性和可用性存在一定的區(qū)別，可用性是指是否可以使用，強(qiáng)調(diào)軟件可運(yùn)行性，而易用性是指是否方便使用，強(qiáng)調(diào)用戶體驗(yàn)，是交互的適應(yīng)性、功能性和有效性的集中體現(xiàn)。

兼容性測(cè)試：主要測(cè)試軟件是否能在不同的操作系統(tǒng)平臺(tái)上兼容，是否能在不同的設(shè)備上兼容；軟件本身能否向前或向后兼容；軟件能否與其他相關(guān)的軟件兼容；數(shù)據(jù)是否兼容，主要是指數(shù)據(jù)能否共享等。

推薦個(gè)網(wǎng)頁(yè)跨平臺(tái)瀏覽器兼容性測(cè)試網(wǎng)址http://browsershots.org/有興趣的產(chǎn)品經(jīng)理可以了解。

性能測(cè)試：通過(guò)自動(dòng)化的測(cè)試工具模擬多種正常、峰值以及異常負(fù)載條件來(lái)對(duì)系統(tǒng)的各項(xiàng)性能指標(biāo)進(jìn)行測(cè)試。負(fù)載測(cè)試和壓力測(cè)試都屬于性能測(cè)試，兩者可以結(jié)合進(jìn)行。通過(guò)負(fù)載測(cè)試，確定在各種工作負(fù)載下系統(tǒng)的性能，目標(biāo)是測(cè)試當(dāng)負(fù)載逐漸增加時(shí)，系統(tǒng)各項(xiàng)性能指標(biāo)的變化情況。壓力測(cè)試是通過(guò)確定一個(gè)系統(tǒng)的瓶頸或者不能接受的性能點(diǎn)，來(lái)獲得系統(tǒng)能提供的最大服務(wù)級(jí)別的測(cè)試。

性能測(cè)試主要分為：

• 應(yīng)用在客戶端性能的測(cè)試：主要并發(fā)性能測(cè)試，利用自動(dòng)化工具通過(guò)模擬成百上千用戶重復(fù)執(zhí)行和運(yùn)行應(yīng)用進(jìn)行黑盒測(cè)試，比如loadrunner。一般測(cè)試人員進(jìn)行性能測(cè)試就是應(yīng)用在客戶端性能的測(cè)試。
• 應(yīng)用在網(wǎng)絡(luò)上性能的測(cè)試：主要網(wǎng)絡(luò)應(yīng)用性能監(jiān)控、網(wǎng)絡(luò)應(yīng)用性能分析和網(wǎng)絡(luò)預(yù)測(cè)的測(cè)試，目的是準(zhǔn)確展示網(wǎng)絡(luò)帶寬、延遲、負(fù)載和TCP端口的變化是如何影響用戶的響應(yīng)時(shí)間的，性能的問(wèn)題根源位置，會(huì)借助一些工具，比如Application Expert。
• 應(yīng)用在服務(wù)器性能的測(cè)試：目的是實(shí)現(xiàn)服務(wù)器設(shè)備、服務(wù)器操作系統(tǒng)、數(shù)據(jù)庫(kù)系統(tǒng)、應(yīng)用在服務(wù)器上性能的全面監(jiān)控。

性能測(cè)試目的是驗(yàn)證軟件系統(tǒng)是否能夠達(dá)到用戶提出的性能指標(biāo)，同時(shí)發(fā)現(xiàn)軟件系統(tǒng)中存在的性能瓶頸，優(yōu)化軟件，最后起到優(yōu)化系統(tǒng)的目的。

補(bǔ)充說(shuō)明：兩個(gè)插件YSlow、page speed，靜態(tài)評(píng)估網(wǎng)頁(yè)性能的插件，可以評(píng)估網(wǎng)頁(yè)性能并獲得有關(guān)如何改進(jìn)性能的建議，有興趣的產(chǎn)品經(jīng)理可以了解，后期優(yōu)化產(chǎn)品時(shí)可以有底氣地和開(kāi)發(fā)人員溝通。當(dāng)然也有APM（應(yīng)用性能管理）對(duì)企業(yè)系統(tǒng)即時(shí)監(jiān)控以實(shí)現(xiàn)對(duì)應(yīng)用程序性能管理和故障管理的系統(tǒng)化的解決方案，比如聽(tīng)云官網(wǎng)。

軟件經(jīng)過(guò)上述主要的測(cè)試后提交bug修改bug后，需要再次測(cè)試檢驗(yàn)軟件是否能正常運(yùn)行，也就是所謂的回歸測(cè)試。

回歸測(cè)試：修改了舊代碼后，重新進(jìn)行測(cè)試以確認(rèn)修改沒(méi)有引入新的錯(cuò)誤或?qū)е缕渌a產(chǎn)生錯(cuò)誤。在整個(gè)軟件測(cè)試過(guò)程中占有很大的工作量比重，軟件開(kāi)發(fā)的各個(gè)階段都會(huì)進(jìn)行多次回歸測(cè)試，且盡量實(shí)現(xiàn)自動(dòng)化，作為自動(dòng)化測(cè)試的優(yōu)先級(jí)。測(cè)試重心在關(guān)鍵模塊和重點(diǎn)功能模塊上。

產(chǎn)品經(jīng)理測(cè)試驗(yàn)收產(chǎn)品時(shí)，主要是采用手工測(cè)試以用戶視角來(lái)測(cè)試產(chǎn)品，根據(jù)用戶需求，采用事件驅(qū)動(dòng)，輸入和輸出，測(cè)試軟件系統(tǒng)的界面和功能，主要測(cè)試方向?yàn)楣δ堋⒖捎眯浴⒂脩趔w驗(yàn)，所以主要是進(jìn)行系統(tǒng)測(cè)試的功能測(cè)試、界面測(cè)試、可靠性測(cè)試、易用性測(cè)試、兼容性測(cè)試。而性能測(cè)試、安全測(cè)試等自動(dòng)化測(cè)試由專門(mén)的測(cè)試人員實(shí)施。

另外，應(yīng)該知道測(cè)試原則的幾個(gè)主要特點(diǎn)：軟件測(cè)試不能保證百分百?zèng)]有缺陷，缺陷具有群集特性（即缺陷主要出現(xiàn)在有缺陷的模塊，重點(diǎn)關(guān)注），測(cè)試的二八原則（80%時(shí)間用在20%的重點(diǎn)模塊上，提升效率和資源使用率），測(cè)試活動(dòng)依賴測(cè)試背景（依賴軟件的應(yīng)用背景，比如銀行金融軟件，側(cè)重安全，所以更偏向于安全性測(cè)試）。

補(bǔ)充說(shuō)明：目前互聯(lián)網(wǎng)公司大多強(qiáng)調(diào)敏捷開(kāi)發(fā)，所以我們講講敏捷開(kāi)發(fā)及敏捷測(cè)試的知識(shí)。

敏捷開(kāi)發(fā)：以用戶的需求進(jìn)化為核心，采用迭代、循序漸進(jìn)的方法進(jìn)行軟件開(kāi)發(fā)。也就是需求一直在變更，我們需要擁抱變更。主張的價(jià)值觀：溝通、簡(jiǎn)單、反饋、勇氣、謙遜。

敏捷宣言：個(gè)體和交互 勝過(guò) 過(guò)程和工具；可以工作的軟件 勝過(guò) 面面俱到的文檔；客戶合作 勝過(guò) 合同談判；響應(yīng)變化 勝過(guò) 遵循計(jì)劃。每項(xiàng)對(duì)比中，雖然后者也有價(jià)值，但我們認(rèn)為前者更有價(jià)值。

敏捷測(cè)試是遵循敏捷宣言的一種測(cè)試實(shí)踐：

• 強(qiáng)調(diào)從客戶的角度，即從使用系統(tǒng)的用戶角度，來(lái)測(cè)試系統(tǒng)。
• 重點(diǎn)關(guān)注持續(xù)迭代地測(cè)試新開(kāi)發(fā)的功能，而不再?gòu)?qiáng)調(diào)傳統(tǒng)測(cè)試過(guò)程中嚴(yán)格的測(cè)試階段。
• 建議盡早開(kāi)始測(cè)試，一旦系統(tǒng)某個(gè)層面可測(cè)，比如提供了模塊功能，就要開(kāi)始模塊層面的單元測(cè)試，同時(shí)隨著測(cè)試深入，持續(xù)進(jìn)行回歸測(cè)試保證之前測(cè)試過(guò)內(nèi)容的正確性。
• 強(qiáng)調(diào)持續(xù)反饋，預(yù)防缺陷勝過(guò)發(fā)現(xiàn)缺陷。

敏捷開(kāi)發(fā)的好處：開(kāi)發(fā)和測(cè)試人員是緊密合作，大家都有責(zé)任對(duì)軟件負(fù)責(zé)，所以產(chǎn)品更能符合需求文檔的要求。核心系統(tǒng)集成和高頻集成是敏捷開(kāi)發(fā)的比較常用的測(cè)試方法。

6、產(chǎn)品經(jīng)理如何測(cè)試驗(yàn)收產(chǎn)品

講完測(cè)試概念，就應(yīng)該到實(shí)踐了，即如何測(cè)試驗(yàn)收產(chǎn)品。

產(chǎn)品經(jīng)理測(cè)試一個(gè)產(chǎn)品，不能用產(chǎn)品思維去測(cè)試一個(gè)產(chǎn)品，因?yàn)楫a(chǎn)品經(jīng)理是最熟悉產(chǎn)品的人，產(chǎn)品每一功能每一個(gè)步都知道操作流程，所以往往只能發(fā)現(xiàn)一些不符合產(chǎn)品需求功能上的bug，而會(huì)忽略真實(shí)用戶去使用的問(wèn)題，比如某個(gè)功能點(diǎn)的使用路徑過(guò)深，導(dǎo)致用戶找不到，用戶產(chǎn)生挫敗感。

所以產(chǎn)品經(jīng)理測(cè)試驗(yàn)收產(chǎn)品，除了驗(yàn)收是否符合產(chǎn)品需求外，還需要發(fā)現(xiàn)產(chǎn)品的可用性、可行性、情感化設(shè)計(jì)的用戶體驗(yàn)問(wèn)題。因此，測(cè)試產(chǎn)品過(guò)程中，產(chǎn)品經(jīng)理需要跳出產(chǎn)品思維，轉(zhuǎn)為用戶思維，甚至轉(zhuǎn)為測(cè)試人員的思維，更廣度和深度的測(cè)試驗(yàn)收。

那么如何轉(zhuǎn)為測(cè)試人員的思維呢？首先需要了解測(cè)試人員的職責(zé)及工作，這樣才能更好地了解到測(cè)試人員使用到的測(cè)試思維，才能更好地轉(zhuǎn)為測(cè)試人員的思維。

下面來(lái)看看拉勾的騰訊的測(cè)試工程師的招聘的職位要求，如下圖所示：

拋開(kāi)技術(shù)層面，只從測(cè)試思維考慮，從職位要求可以看出，所以測(cè)試工程師的核心能力在于有耐心地提出挑戰(zhàn)性的相關(guān)問(wèn)題，從不同的角度，驗(yàn)證產(chǎn)品的可行性，善于找出錯(cuò)誤讓程序不能正常運(yùn)行的問(wèn)題。因?yàn)閹е鴨?wèn)題，才能發(fā)現(xiàn)問(wèn)題，比如他們會(huì)問(wèn)，產(chǎn)品的目的，產(chǎn)品主要在什么平臺(tái)上使用，如果不符合的數(shù)據(jù)輸入會(huì)不會(huì)發(fā)生程序崩潰，會(huì)從各種實(shí)用場(chǎng)景中發(fā)現(xiàn)問(wèn)題。

從各種場(chǎng)景發(fā)現(xiàn)問(wèn)題，也就是要求我們要多使用，多問(wèn)“如果…會(huì)怎么樣“”為什么”的問(wèn)題，畢竟找到關(guān)鍵問(wèn)題的最好辦法就是提問(wèn)。因?yàn)槎鄦?wèn)為什么，發(fā)散思維，也使得測(cè)試人員會(huì)從不同的用戶角度（交叉測(cè)試）去思考問(wèn)題，包括毫無(wú)經(jīng)驗(yàn)的用戶、很有經(jīng)驗(yàn)的用戶、愛(ài)好者、黑客、競(jìng)爭(zhēng)對(duì)手等等，產(chǎn)品的受眾越多，不同類型的用戶就越多，就需要從更多的用戶去思考問(wèn)題，當(dāng)然，用戶越多，其操作行為和工作流程就越多，比如隨意輸入、隨意點(diǎn)擊。

隨意輸入、隨意點(diǎn)擊，不斷和系統(tǒng)交互，帶著問(wèn)題測(cè)試，也就是所謂的探索性測(cè)試，探索產(chǎn)品未被發(fā)現(xiàn)的bug的存在隱患。探索性測(cè)試，完全拋開(kāi)測(cè)試腳本的測(cè)試，是一種測(cè)試風(fēng)格、思維而不是一種測(cè)試技術(shù)，分為局部性測(cè)試和全局性測(cè)試，局部性測(cè)試主要是對(duì)某個(gè)模塊進(jìn)行輸入輸出的測(cè)試，全局性測(cè)試主要是像游客一樣使用軟件系統(tǒng)。

探索性測(cè)試，自由靈活會(huì)增加發(fā)現(xiàn)新的bug的可能性，執(zhí)行與設(shè)計(jì)（思考）并行，減少在簡(jiǎn)單、繁復(fù)上用例的無(wú)謂編寫(xiě)時(shí)間，不斷和系統(tǒng)交互，帶著問(wèn)題測(cè)試，但更依賴系統(tǒng)完成可用的情況下才能交互使用探索，且難協(xié)調(diào)和控制，所以一般都是測(cè)試工程師采用monkey自動(dòng)化測(cè)試進(jìn)行探索性測(cè)試。

從上面的職責(zé)和測(cè)試人員的測(cè)試工作，我們不難看出，測(cè)試的主要思維就是帶著問(wèn)題以不同用戶的不同操作流程去使用產(chǎn)品達(dá)到發(fā)現(xiàn)bug。

了解了測(cè)試思維，那么還需要了解測(cè)試的流程是怎樣的，畢竟流程是規(guī)范性的要求，保證測(cè)試能有序有目的的進(jìn)行。測(cè)試的流程主要為測(cè)試計(jì)劃-測(cè)試用例-測(cè)試執(zhí)行-測(cè)試報(bào)告。

測(cè)試用例主要是測(cè)試人員根據(jù)PRD、流程圖、原型圖、UI、收集的資料來(lái)編寫(xiě)，通過(guò)需求文檔了解需求背景，用戶畫(huà)像、使用場(chǎng)景、用戶故事，通過(guò)流程圖、原型圖了解功能需求，站在用戶角度和項(xiàng)目實(shí)情去思考，盡可能地覆蓋全面使用路徑。測(cè)試用例編寫(xiě)之前，產(chǎn)品經(jīng)理都是最熟悉產(chǎn)品，知道產(chǎn)品的目的，即用戶故事同理心，知道產(chǎn)品主要是在什么系統(tǒng)、平臺(tái)運(yùn)行，知道數(shù)據(jù)是什么類型，知道調(diào)用哪些外部的接口，知道哪些是關(guān)鍵模塊，知道產(chǎn)品的規(guī)劃，可以更快速地測(cè)試是否符合產(chǎn)品需求文檔的要求，所以產(chǎn)品經(jīng)理應(yīng)該和測(cè)試人員詳細(xì)地宣講產(chǎn)品，也就是所謂的必須進(jìn)行的產(chǎn)品宣講，這樣測(cè)試人員能好地理解編寫(xiě)測(cè)試用例，產(chǎn)品經(jīng)理也能借助測(cè)試人員的經(jīng)驗(yàn)更好地進(jìn)行測(cè)試驗(yàn)收產(chǎn)品。

編寫(xiě)好測(cè)試用例時(shí)，根據(jù)需求文檔的需求優(yōu)先級(jí)和風(fēng)險(xiǎn)級(jí)別定義測(cè)試優(yōu)先級(jí)別，重點(diǎn)測(cè)試核心模塊，比如電商網(wǎng)站的搜索瀏覽商品和下單的完整流程是優(yōu)先級(jí)別的測(cè)試模塊。開(kāi)始測(cè)試產(chǎn)品過(guò)程中，詳細(xì)寫(xiě)好步驟和具體問(wèn)題，問(wèn)題很多類型，所以記好問(wèn)題類型，當(dāng)然很多問(wèn)題是可以被預(yù)先確定和測(cè)試的，所以注意操作步驟及操作環(huán)境，比如是否按照正常流程操作，用戶是否打開(kāi)數(shù)據(jù)網(wǎng)絡(luò)。

產(chǎn)品經(jīng)理一般是根據(jù)測(cè)試用例來(lái)測(cè)試驗(yàn)收產(chǎn)品，符合驗(yàn)收標(biāo)準(zhǔn)即可。測(cè)試用例可以從測(cè)試人員那里要，或者自己根據(jù)誰(shuí)、怎么做、結(jié)果的用戶操作流程編寫(xiě)一個(gè)符合規(guī)則的測(cè)試用例去測(cè)試，最后去思考問(wèn)題的原因和解決方案，以及把測(cè)試的問(wèn)題反饋給測(cè)試人員跟進(jìn)和開(kāi)發(fā)人員解決。測(cè)試模塊盡量獨(dú)立，覆蓋全面，減少耦合。

這里我們以微信手機(jī)號(hào)登錄功能模塊的功能測(cè)試為測(cè)試案例，講講測(cè)試步驟和測(cè)試用例。當(dāng)然，不同公司的測(cè)試步驟和測(cè)試用例會(huì)有些不一樣，不過(guò)相差不大。

測(cè)試前需要準(zhǔn)備一些測(cè)試的硬性需求，比如測(cè)試的相關(guān)數(shù)據(jù)（比如是否后臺(tái)創(chuàng)建測(cè)試賬號(hào)）、測(cè)試設(shè)備（比如iphone5、6、7）、測(cè)試需要的軟件（比如操作系統(tǒng)，瀏覽器）。

這里微信登錄功能測(cè)試的需求：數(shù)據(jù)（一個(gè)已注冊(cè)的用戶賬號(hào)密碼，一個(gè)未注冊(cè)的手機(jī)號(hào)碼），設(shè)備（一部手機(jī)），需要的軟件（android/ios）。

根據(jù)帶著問(wèn)題以不同用戶的不同操作流程去使用產(chǎn)品達(dá)到發(fā)現(xiàn)bug的測(cè)試思維，編寫(xiě)測(cè)試用例。

首先用腦圖列出模塊的不同用戶的不同操作流程，這樣可以覆蓋功能全面路徑。這里只列舉主要使用場(chǎng)景，如下圖所示：

根據(jù)PRD的用戶故事或者原型圖的規(guī)則說(shuō)明列出每個(gè)功能點(diǎn)的驗(yàn)收標(biāo)準(zhǔn)，列出每個(gè)操作流程的驗(yàn)收標(biāo)準(zhǔn)，即預(yù)期結(jié)果（預(yù)期結(jié)果以微信實(shí)操的結(jié)果模擬，吐槽一下微信手機(jī)號(hào)碼輸入框沒(méi)限制號(hào)碼長(zhǎng)度的等一系列的低級(jí)體驗(yàn)問(wèn)題）。在操作流程的腦圖基礎(chǔ)上補(bǔ)上每個(gè)故事點(diǎn)的驗(yàn)收標(biāo)準(zhǔn)，如下圖所示：

最后根據(jù)上述的腦圖，我們可以寫(xiě)出大概的測(cè)試用例列表，當(dāng)然，測(cè)試列表需要補(bǔ)充說(shuō)明一些相關(guān)信息。如下圖所示：

編寫(xiě)完測(cè)試用例后，我們就可以根據(jù)測(cè)試用例逐項(xiàng)測(cè)試產(chǎn)品，并根據(jù)測(cè)試結(jié)果填寫(xiě)測(cè)試用例列表中的測(cè)試結(jié)果，并根據(jù)預(yù)期結(jié)果和測(cè)試結(jié)果的差異，填寫(xiě)是否存在缺陷，并反饋給測(cè)試人員和開(kāi)發(fā)人員進(jìn)行跟進(jìn)和修改缺陷。至此，一個(gè)模塊功能測(cè)試就完整了，當(dāng)然，修改缺陷后跟進(jìn)還需要回歸測(cè)試。

補(bǔ)充說(shuō)明：上述的基礎(chǔ)測(cè)試知識(shí)只是產(chǎn)品經(jīng)理經(jīng)常涉及到的測(cè)試知識(shí)，測(cè)試還有很多概念，比如冒煙測(cè)試、AB測(cè)試、自動(dòng)化測(cè)試，測(cè)試的未來(lái)會(huì)自動(dòng)化，對(duì)技術(shù)要求越來(lái)越高，所以測(cè)試是一門(mén)大學(xué)問(wèn)，如果有興趣學(xué)習(xí)的產(chǎn)品經(jīng)理，可以找套教程學(xué)學(xué)。

作者：鉛筆小葵（微信號(hào)：gaokaikui 知乎專欄：鉛筆小葵），待業(yè)中，2年多工作經(jīng)驗(yàn)，現(xiàn)產(chǎn)品經(jīng)理，全權(quán)負(fù)責(zé)從0到1的產(chǎn)品開(kāi)發(fā)，曾任Java工程師，參與后臺(tái)開(kāi)發(fā)。歡迎大家互相交流關(guān)注。

本文由 @鉛筆小葵 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。