一個(gè)不會(huì)測(cè)試的產(chǎn)品不是好開(kāi)發(fā)

在初創(chuàng)公司，大部分都沒(méi)有專(zhuān)門(mén)的QA（質(zhì)量保證）人員，此時(shí)測(cè)試的活兒基本上就是產(chǎn)品做了。

實(shí)際上這活兒也挺適合產(chǎn)品做的，畢竟沒(méi)有誰(shuí)能比寫(xiě)PRD的那個(gè)人更了解產(chǎn)品細(xì)節(jié)了。

這半個(gè)月經(jīng)歷了兩次較大的網(wǎng)站架構(gòu)更新。時(shí)間緊，資源少，沒(méi)時(shí)間系統(tǒng)的搞沙盤(pán)測(cè)試，依然像往常一樣，全員大幫哄，做了一夜黑盒就完事兒了。

結(jié)果上線(xiàn)之后各種Bug，用戶(hù)反饋壓爆客服。還好技術(shù)團(tuán)隊(duì)比較牛掰，嚴(yán)重的缺陷當(dāng)天基本都解決掉，才沒(méi)造成過(guò)大的損失。

之前一直沒(méi)系統(tǒng)的去思考過(guò)測(cè)試方面的事情，親身經(jīng)歷才感覺(jué)到后果的嚴(yán)重性。

于是重新看了下項(xiàng)目管理的書(shū)，找了些測(cè)試方面的文章，在這兒小結(jié)一下分享，希望大家在留言一起多交流碰撞。

先聊聊項(xiàng)目管理：

從項(xiàng)目管理的角度，測(cè)試嚴(yán)格來(lái)說(shuō)屬于項(xiàng)目質(zhì)量管理中的質(zhì)量計(jì)劃，質(zhì)量保證，質(zhì)量控制三個(gè)環(huán)節(jié)中的最后一環(huán)，是驗(yàn)收整個(gè)項(xiàng)目質(zhì)量的關(guān)鍵環(huán)節(jié)。

而現(xiàn)在的創(chuàng)業(yè)團(tuán)隊(duì)大都是敏捷型開(kāi)發(fā)團(tuán)隊(duì)，也就是一些文章里經(jīng)常說(shuō)的“小作坊”~沒(méi)有繁重的工作流程和復(fù)雜的層級(jí)關(guān)系，溝通和執(zhí)行的效率都很高。

所以傳統(tǒng)的項(xiàng)目管理理論中大部分是不適用于初創(chuàng)階段的，這時(shí)候就得結(jié)合自身情況，用合適的方法具體分析了。

就測(cè)試而言，系統(tǒng)的軟件測(cè)試方法非常多，單元測(cè)試，集成測(cè)試，系統(tǒng)測(cè)試，α測(cè)試，β測(cè)試，回歸測(cè)試，模糊測(cè)試等等……

最常見(jiàn)的三種是：

• 黑盒測(cè)試——不考慮程序的內(nèi)部結(jié)構(gòu)，直接在程序接口上進(jìn)行測(cè)試。通俗的講就是把產(chǎn)品拿過(guò)來(lái)直接用找Bug。
• 白盒測(cè)試——把測(cè)試的對(duì)象看成一個(gè)透明的盒子，對(duì)程序的所有邏輯路徑進(jìn)行測(cè)試。常用的有語(yǔ)句覆蓋，條件覆蓋，判斷覆蓋，條件組合覆蓋，路徑覆蓋這幾種。（這個(gè)都是開(kāi)發(fā)的活兒，產(chǎn)品們了解下就好
• 沙盤(pán)測(cè)試——模擬用戶(hù)在實(shí)際環(huán)境中的測(cè)試，也就是把一個(gè)個(gè)用戶(hù)場(chǎng)景都走通一遍。這樣就把粒度較大，也十分重要的邏輯漏洞過(guò)濾掉了。

而實(shí)際操作中，測(cè)試要如何規(guī)劃呢？

下面分別再?gòu)?個(gè)維度重新歸納一下。

首先，測(cè)試人員的核心能力在于提出具有價(jià)值的問(wèn)題。這需要結(jié)合技術(shù)和產(chǎn)品的角度來(lái)思考。

了解已有信息

測(cè)試開(kāi)始之前，我們要先知道從哪開(kāi)始測(cè)試：

• 目前已經(jīng)有哪些可供參考的信息：產(chǎn)品規(guī)格？需求文檔？用戶(hù)文檔？已有的Bug記錄等等。（理想情況下，測(cè)試人員應(yīng)該掌握產(chǎn)品應(yīng)有的所有細(xì)節(jié)資料。然而事實(shí)上這些文檔很有限，多問(wèn)多積累吧…）
• 產(chǎn)品支持在什么系統(tǒng)、平臺(tái)和設(shè)備上運(yùn)行？
• 產(chǎn)品都處理哪些數(shù)據(jù)類(lèi)型？（如聊天信息，消費(fèi)信息等）
• 產(chǎn)品有接入外部產(chǎn)品嗎？（如其它API或數(shù)據(jù)）
• 多少時(shí)間用來(lái)測(cè)試？
• 測(cè)試的優(yōu)先級(jí)如何排列？
• 測(cè)試的風(fēng)險(xiǎn)如何判斷？
• 發(fā)布和更新的流程如何？

基本上，了解好上面的信息就可以開(kāi)始制定相應(yīng)的測(cè)試計(jì)劃了。在時(shí)間允許的情況下，一定要記得：（這次就是沒(méi)寫(xiě)吃了大虧）

寫(xiě)測(cè)試用例！

寫(xiě)測(cè)試用例！

寫(xiě)測(cè)試用例！

從用戶(hù)場(chǎng)景測(cè)試：

自己做的產(chǎn)品，我們一定有自己的理解，而用戶(hù)實(shí)際上是如何使用的？在什么樣的情景下使用？都是我們需要慢慢的通過(guò)與用戶(hù)的交流，產(chǎn)品的數(shù)據(jù)積累，用戶(hù)研究得來(lái)的，測(cè)試的時(shí)候當(dāng)然也不能漏掉。

用戶(hù)的使用經(jīng)驗(yàn)：

• 毫無(wú)經(jīng)驗(yàn)
• 有些經(jīng)驗(yàn)
• 很有經(jīng)驗(yàn)
• 技術(shù)狂
• 競(jìng)爭(zhēng)對(duì)手
• 黑客

……

當(dāng)然，角色要多少有多少，具體看我們產(chǎn)品有什么需要了。

用戶(hù)的操作行為：

• 在不該返回的時(shí)候返回
• 不耐心多次點(diǎn)擊按鈕
• 輸入錯(cuò)誤數(shù)據(jù)
• 不理解如何使用
• 沒(méi)按照產(chǎn)品規(guī)則進(jìn)行設(shè)置
• 隨便亂點(diǎn)

……

意料之外的Bug常常就會(huì)在這里出現(xiàn)，不過(guò)一般都是小Bug，但更深入的想想，其實(shí)會(huì)有更多產(chǎn)品本身的問(wèn)題。

產(chǎn)品性能問(wèn)題：

• 開(kāi)發(fā)時(shí)是否完全按照產(chǎn)品設(shè)計(jì)交付？
• 是否按照計(jì)劃完成了既定要開(kāi)發(fā)的功能？
• 超負(fù)荷使用的情況下，產(chǎn)品狀況會(huì)怎么樣？加載速度會(huì)變慢嗎？會(huì)崩潰閃退嗎？出錯(cuò)有給用戶(hù)反饋嗎？
• 閃退后數(shù)據(jù)是否會(huì)丟失？
• 用戶(hù)數(shù)據(jù)的安全如何？
• 運(yùn)行過(guò)程中程序中斷會(huì)發(fā)生什么情況？
• 是否需要調(diào)用的硬件服務(wù)？（如GPS，Wifi）打開(kāi)會(huì)如何？沒(méi)打開(kāi)會(huì)如何？
• 用戶(hù)是否按照既定的產(chǎn)品路徑完成了我們期望的引導(dǎo)？
• 跳轉(zhuǎn)到網(wǎng)頁(yè)，瀏覽器，或其它App時(shí)會(huì)出現(xiàn)Bug嗎？
• 是否整合了第三方登陸？（如QQ、微信登陸）
• 用戶(hù)反饋是都符合我們的產(chǎn)品定位？

……

從數(shù)據(jù)發(fā)現(xiàn)問(wèn)題：

數(shù)據(jù)對(duì)于產(chǎn)品的意義咱們就不多提了，往往經(jīng)得住考驗(yàn)的功能點(diǎn)都是基于數(shù)據(jù)做出的。

然而，數(shù)據(jù)多了也同樣愁人，不管是用戶(hù)還是我們自己開(kāi)發(fā)，數(shù)據(jù)一多，出現(xiàn)錯(cuò)誤的概率也隨之增加。

• 跨平臺(tái)的數(shù)據(jù)同步問(wèn)題
• 數(shù)據(jù)存儲(chǔ)的極限
• 數(shù)據(jù)被移除時(shí)會(huì)發(fā)生的情況
• 刪除App或卸載軟件時(shí)，數(shù)據(jù)如何處理？
• 刪除并重新安裝時(shí)，數(shù)據(jù)如何處理？
• 是否會(huì)因過(guò)多或過(guò)少的數(shù)據(jù)需求導(dǎo)致布局和UI的改變？
• 在不同時(shí)段和時(shí)區(qū)時(shí)使用會(huì)如何？
• 數(shù)據(jù)同步時(shí)被打斷
• 數(shù)據(jù)或網(wǎng)站數(shù)據(jù)架構(gòu)更新時(shí)會(huì)造成的影響
• 如何快速處理大量數(shù)據(jù)？
• 無(wú)效的數(shù)據(jù)如何處理？

根據(jù)不同的用戶(hù)類(lèi)型和用戶(hù)場(chǎng)景，出現(xiàn)極限數(shù)據(jù)時(shí)的測(cè)試也不可忽視

• 測(cè)試用戶(hù)可輸入的極限值
• 用重復(fù)數(shù)據(jù)反復(fù)測(cè)試
• 在無(wú)任何數(shù)據(jù)的手機(jī)上測(cè)試
• 在老舊手機(jī)上測(cè)試
• 預(yù)裝多種不同類(lèi)型的數(shù)據(jù)
• 使用超出預(yù)期的數(shù)據(jù)測(cè)試，看程序如何處理
• 分析數(shù)據(jù)是如何影響UE的

寫(xiě)一些小的腳本讓測(cè)試自動(dòng)化也是非常高效的~

出錯(cuò)時(shí)的提醒和消息

這時(shí)就完全從用戶(hù)和測(cè)試者本身的角度來(lái)思考問(wèn)題了，錯(cuò)誤提醒和消息是經(jīng)常出現(xiàn)問(wèn)題的地方。

• 錯(cuò)誤提醒的UI是否易于接受？
• 錯(cuò)誤信息內(nèi)容是否易于理解？
• 錯(cuò)誤信息格式是否一致？
• 錯(cuò)誤提醒有沒(méi)有用？
• 信息內(nèi)容是否合適？
• 錯(cuò)誤是否符合慣例和標(biāo)準(zhǔn)？
• 錯(cuò)誤信息本身是否正確？
• 產(chǎn)品是否能獲得錯(cuò)誤和崩潰信息？
• 是否所有的錯(cuò)誤都測(cè)試過(guò)？
• 用戶(hù)處理完錯(cuò)誤信息后，將處于什么狀態(tài)？
• 是否在用戶(hù)應(yīng)該接受錯(cuò)誤信息時(shí)，卻沒(méi)有錯(cuò)誤信息彈出？

錯(cuò)誤信息的確會(huì)影響用戶(hù)體驗(yàn)。然而，錯(cuò)誤始終是不可避免的，就像我們永遠(yuǎn)寫(xiě)不出沒(méi)有任何Bug的程序一樣。

雖然最理想的狀態(tài)是避免用戶(hù)遇見(jiàn)錯(cuò)誤信息，但這幾乎不可能。

對(duì)于出錯(cuò)情況的設(shè)計(jì)、實(shí)現(xiàn)和確認(rèn)很可能與預(yù)期相反，但只要測(cè)試時(shí)善于發(fā)現(xiàn)這些意料外的Bug，改進(jìn)它們就更有頭緒了。

特定平臺(tái)的注意事項(xiàng)

每個(gè)平臺(tái)上的技術(shù)標(biāo)準(zhǔn)和設(shè)計(jì)規(guī)范都有很大差異，考慮產(chǎn)品在不同平臺(tái)上的限制都是至關(guān)重要的。我們可以從一下一些方面入手：

• 是否遵循該平臺(tái)的設(shè)計(jì)規(guī)范？
• 轉(zhuǎn)動(dòng)設(shè)備的方向時(shí)，有什么變化？
• 平臺(tái)支持哪種設(shè)備？
• 觸摸屏在不同情況下支持何種手勢(shì)，如：雙擊、長(zhǎng)按、拖動(dòng)、搖晃、左右滑動(dòng)等
• 是否需要調(diào)用GPS？
• 分享或轉(zhuǎn)發(fā)郵件時(shí)是否足夠流暢？是否接入其它社交產(chǎn)品？
• 用戶(hù)進(jìn)行多個(gè)任務(wù)，并在不同App間切換時(shí)，產(chǎn)品是否正常運(yùn)行？
• 用戶(hù)進(jìn)行更新或上傳操作時(shí)，是否會(huì)顯示進(jìn)度？
• 默認(rèn)設(shè)置如何？是否可調(diào)整？

網(wǎng)絡(luò)中斷或其它原因打斷時(shí)的情況

當(dāng)連接斷斷續(xù)續(xù)或意外中斷時(shí)，很多場(chǎng)景我們都要重新考慮：

• 用戶(hù)運(yùn)動(dòng)，走動(dòng)環(huán)境下
• WiFi連接下
• 無(wú)WiFi連接時(shí)
• 3、4G模式下
• 手機(jī)和WiFi網(wǎng)絡(luò)切換時(shí)
• 飛行模式時(shí)
• 有電話(huà)打來(lái)時(shí)
• 收到信息時(shí)
• 收到消息提醒時(shí)
• 電量過(guò)低，甚至自動(dòng)關(guān)機(jī)時(shí)

……

這類(lèi)測(cè)試最容易發(fā)現(xiàn)錯(cuò)誤和Bug。不僅是開(kāi)關(guān)機(jī)，確認(rèn)設(shè)備是否正常工作，嘗試用戶(hù)使用的整個(gè)流程也至關(guān)重要。

測(cè)試遠(yuǎn)非對(duì)與錯(cuò)的判斷

以上是重新歸納后的8個(gè)維度，肯定不是面面俱到，但多少提醒我們：

帶著問(wèn)題，才能發(fā)現(xiàn)問(wèn)題

測(cè)試往往大家被認(rèn)為是完全按照邏輯的、可計(jì)劃和預(yù)測(cè)的，然而只有在真正編寫(xiě)測(cè)試腳本，實(shí)施測(cè)試計(jì)劃，在通過(guò)和失敗，正確和錯(cuò)誤的反饋中不斷總結(jié)，我們才能越來(lái)越接近上線(xiàn)后的真實(shí)狀態(tài)。

Stay hungry，stay foolish

#專(zhuān)欄作家#

楊柳，微信公眾號(hào)：楊柳（PMYANGLIU），人人都是產(chǎn)品經(jīng)理專(zhuān)欄作家。toB產(chǎn)品經(jīng)理。主攻SaaS領(lǐng)域的UI/UE，用戶(hù)研究及數(shù)據(jù)分析。90后創(chuàng)客，坐標(biāo)帝都，歡迎線(xiàn)下交流。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，不得轉(zhuǎn)載。