測試方法有多重，最終目的是在有限的時間內(nèi)發(fā)現(xiàn)最多的問題并解決，最大程度降低產(chǎn)品錯誤帶來的負面影響。

新版產(chǎn)品上線是團隊多日加班加點的奮斗成果，對于產(chǎn)品經(jīng)理來說，上線前夕要面臨無窮無盡的測試工作，仿佛測試也是萬能的產(chǎn)品經(jīng)理與生俱來的天職。但是我想說，這鍋咱們不能背！

那么問題來了，測試到底歸誰管？對于大團隊預(yù)算充足會有專門的測試崗，而小團隊往往需要產(chǎn)品經(jīng)理和程序員共同參與到其中。不管哪種情況，測試是控制產(chǎn)品質(zhì)量的最重要一道關(guān)，都應(yīng)該由產(chǎn)品經(jīng)理來組織測試工作。確保產(chǎn)品層層把關(guān)的原則，測試步驟分為技術(shù)測試、內(nèi)部測試、用戶測試。但并不需要凡是親力親為，要善于分配人力資源，一個好的測試機制可以事半功倍，否則產(chǎn)品經(jīng)理最終淪落成測試員磚家，累個半死還誤了進度。東東醬以下就此話題展開討論。

技術(shù)測試

技術(shù)測試主要由程序員（或測試員）對編碼進行邏輯覆蓋測試，遍歷程序遇到的所有情況，捕獲異常進行處理，模擬訪問做高并發(fā)的壓力測試。該階段可以發(fā)現(xiàn)產(chǎn)品需求中的疏漏或邏輯錯誤，排除程序員粗心編程而出現(xiàn)的算法、邏輯錯誤。該階段可以排除大量Bug，特別是后臺或邏輯性很強的工具性產(chǎn)品，把控的好，產(chǎn)品經(jīng)理后期測試工作量會大大降低，Bug在技術(shù)內(nèi)部進行修改，反復(fù)測試無Bug后，可打包提交給產(chǎn)品經(jīng)理，進入下一階段測試。

內(nèi)部測試

內(nèi)部測試主要由產(chǎn)品經(jīng)理主導(dǎo)在公司內(nèi)部進行，設(shè)計師可以驗收UI效果是否符合預(yù)期，產(chǎn)品經(jīng)理模擬多套用戶數(shù)據(jù)按照流程圖對其進行操作測試，確認所有功能都與產(chǎn)品文檔中的需求一一對應(yīng)，測試方法可以參看文末的黑盒測試。另外可以邀請其他部門的同事來充當小白用戶進行產(chǎn)品體驗。此階段開始要收集所有人的整改意見，進行歸類和排序。對于基礎(chǔ)性的Bug可以馬上責(zé)令技術(shù)進行修改，有爭議性的修改意見或非重要Bug可待下一階段的用戶測試完后集中修改。

用戶測試

用戶測試由產(chǎn)品經(jīng)理（策劃/運營共同配合）主導(dǎo)，用戶測試分為兩個階段。

第一階段

尋找固定的用戶群體進行測試（即每個版本邀請同一批用戶來測試），以問卷或者一對一聊天的方式，獲得他們對比新舊版本來直觀感受產(chǎn)品好壞。如果無章可循，今天找個路人甲測試，明天找個路人乙測試，面向不同品味的用戶，難免會出現(xiàn)下圖尷尬情況。

第二階段

灰度測試，向用戶群中的1000人，10000人…依次遞增推送測試版本，利用自建數(shù)據(jù)后臺或友盟tlakingdata觀察埋點數(shù)據(jù)的功能使用情況和程序crash崩潰報錯信息，如發(fā)現(xiàn)數(shù)據(jù)異動及時下架處理。

以上三步循環(huán)進行，直至無Bug方可正式發(fā)行新版本。下面東東醬順帶介紹測試過程中常見的問題。

版本管理

產(chǎn)品版本用V2.1.3編號管理可以嗎？那僅僅是面向用戶的，在軟件工程中對軟件版本管理，分為Alpha、Beta、Rlease Candidate、Release版。

1. Alpha是開發(fā)人員的內(nèi)部測試版，一般不向外部發(fā)布，會有很多Bug，只有程序員和測試員使用。
2. Beta：這是供公司內(nèi)部測試的版本，這個階段版本仍可適當加入新的功能。
3. Rlease Candidate：RC是發(fā)行候選版本，幾乎不會加入新的功能，主要著重于出錯，可開放給部分用戶體驗。
4. Release：這就是“真的打死不改(6).doc”版本了,交付給用戶的最終版本，如果仍出現(xiàn)Bug，那就啟動下一版本開發(fā)周期了，也就是常見的“v2.1.3”版本迭代了。

因此產(chǎn)品經(jīng)理在管理安裝包的時候，最好把不同階段的名稱設(shè)為包名前綴，避免出現(xiàn)錯亂。

灰度測試

灰度值是不飽和的黑色，是白色向黑色過渡的一種表現(xiàn)。比如突然熄燈看手機，屏幕亮度逐漸變暗；歌曲由暫停開始播放，音量逐漸提高。這樣做的好處不言而喻，灰度是一種思想，應(yīng)用在項目管理中，為避免辛苦開發(fā)出來的產(chǎn)品與用戶所期待的相差甚大，摒棄傳統(tǒng)冗長的開發(fā)流程， 將項目按照功能優(yōu)先級排序，對產(chǎn)品實行分階段，分版本開發(fā)，第一個版本滿足用戶基礎(chǔ)需求，后續(xù)版本在原基礎(chǔ)上反復(fù)迭代，這樣試錯成本最低。對于某一版本內(nèi)的測試，也可以實行灰度機制，測試版本先邀請100名用戶進行測試，反饋問題修改Bug，如此類推放量1000人再測試。最終發(fā)行版的用戶滿意度會提高很多，項目成員也不會上線Bug頻頻出現(xiàn)而壓力山大。

A/B測試其實是灰度測試的一種。如果產(chǎn)品方案發(fā)生了分歧，可以針對多個方案進行等量推送，查看數(shù)據(jù)從中擇優(yōu)。Tlakingdata的運營平臺就能提供此類方法。

測試用例

白盒測試

白盒測試顧名思義內(nèi)部是透明可見的，是通過檢查軟件內(nèi)部的邏輯結(jié)構(gòu)，對軟件中的邏輯路徑進行覆蓋測試，在程序不同地方設(shè)立檢查點，檢查程序的狀態(tài)，以確定實際運行狀體與預(yù)期是否一致。

測試方法包含：邏輯覆蓋測試（語句，判定，條件，判定條件，條件組合，路徑），循環(huán)覆蓋，基本路徑測試。

看不懂沒關(guān)系，產(chǎn)品經(jīng)理只需督促程序員或測試員完成這一流程即可，感興趣的自行搜索。

黑盒測試

黑盒測試也稱為功能測試，測試者在看不到程序內(nèi)部代碼情況下采用窮舉輸入測試，主要用于發(fā)現(xiàn)：功能不正確或遺漏；界面錯誤；輸入和輸出錯誤；數(shù)據(jù)庫訪問錯誤；性能錯誤；初始化和終止錯誤。

該部分可由產(chǎn)品經(jīng)理或測試員來負責(zé)。

黑白盒測試是專業(yè)測試知識，如需詳解要另開篇章。產(chǎn)品經(jīng)理只需確保做到如下幾點：

1. 產(chǎn)品功能與需求文檔保持一致。
2. 對所有用戶輸入值的合法范圍內(nèi)，非法范圍，邊界值進行抽樣取值測試，確保程序在合法和非法輸入值情況下都能正常運行。
3. 憑借測試經(jīng)驗，推測有可能出現(xiàn)錯誤的地方。
4. 準備多種測試數(shù)據(jù)，判斷輸入和輸出結(jié)果之間的因果關(guān)系是否一致。

寫在最后

測試是產(chǎn)品輸出的最關(guān)鍵也是最后一步，在實際項目中，因為項目進度緊等諸多原因，可以適當省去灰度發(fā)布過程，但是技術(shù)測試和產(chǎn)品經(jīng)理內(nèi)測工作不能省，不然功虧一簣。測試方法有多重，最終目的是在有限的時間內(nèi)發(fā)現(xiàn)最多的問題并解決，最大程度降低產(chǎn)品錯誤帶來的負面影響。如有更多測試好方法，歡迎留言交流。

文章內(nèi)容均來自于項目實踐經(jīng)驗，拒絕盲目照搬。

作者：東東醬，眼蜜-產(chǎn)品經(jīng)理。微信號：pengoneeast

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