本文不是教產(chǎn)品經(jīng)理如何轉(zhuǎn)行做測試，而是在團(tuán)隊(duì)沒有測試人員的情況下植捎，如何快速承擔(dān)起測試的工作衙解，以下是正文：
大公司有明確的職位分工：工程師、測試焰枢、設(shè)計(jì)蚓峦、運(yùn)營都由不同的人負(fù)責(zé)，測試自然就是測試工程師的事济锄，而在中小型創(chuàng)業(yè)公司暑椰，人員匱乏，很多團(tuán)隊(duì)只有工程師和產(chǎn)品經(jīng)理荐绝，工程師負(fù)責(zé)開發(fā)一汽，開發(fā)以外的事情全都由產(chǎn)品經(jīng)理承包，這其中自然包括測試低滩。測試是產(chǎn)品上線前的質(zhì)量檢驗(yàn)召夹，只有通過測試岩喷，產(chǎn)品才能放心的呈現(xiàn)到用戶面前，本文就詳細(xì)說說监憎，產(chǎn)品經(jīng)理該如何做測試纱意。
我們不探討測試究竟分多少種，每種類型又是如何定義枫虏，產(chǎn)品經(jīng)理的測試任務(wù)基本只涉及一種：功能測試妇穴，測試的內(nèi)容就是：工程師實(shí)現(xiàn)的產(chǎn)品，和 PM 最初定義的產(chǎn)品是否一致隶债，如果一致腾它，則測試通過，如果不一致死讹，則測試不通過瞒滴。
需求文檔——測試的基礎(chǔ)
需求文檔定義了產(chǎn)品要實(shí)現(xiàn)的功能和具體的細(xì)節(jié)，工程師依據(jù)它進(jìn)行開發(fā)赞警，測試當(dāng)然要依據(jù)相同的標(biāo)準(zhǔn)進(jìn)行測試妓忍，如果缺少需求文檔，測試就沒了依據(jù)愧旦，就很難往下進(jìn)行世剖。比如有以下需求文檔：
XX 博客系統(tǒng)發(fā)布文章頁需求清單
- 文章標(biāo)題為必填，最長 80 個(gè)字符笤虫，支持中英文和特殊符號旁瘫，超出時(shí)即時(shí)提示 “標(biāo)題不能超出 80 個(gè)字符”（原型見附件）
- 文章內(nèi)容為選填，最長 8000 個(gè)字符琼蚯，支持中英文和特殊符號酬凳，超出時(shí)即時(shí)提示 “文章內(nèi)容不能超出 8000 個(gè)字符”
- ...
進(jìn)行測試時(shí)，除了要考慮產(chǎn)品的常規(guī)使用流程遭庶，還要重點(diǎn)考慮產(chǎn)品中的邊界問題宁仔，比如以上例子中標(biāo)題和內(nèi)容的字?jǐn)?shù)限制。
測試用例
了解清楚需求之后就要設(shè)計(jì)測試用例了峦睡，測試用例就是一個(gè)個(gè)用戶實(shí)際的使用場景翎苫，要求有設(shè)定好的輸入條件和預(yù)期結(jié)果，比如針對上面的文章發(fā)布頁設(shè)計(jì)以下用例：
| 編號 | 標(biāo)題 | 內(nèi)容 | 預(yù)期結(jié)果 | 測試結(jié)果 |
|---|---|---|---|---|
| 1 | “測試標(biāo)題” | “測試內(nèi)容” | 無錯誤提示赐俗，正常發(fā)布文章 | |
| 2 | “測試標(biāo)題” | 空 | 無錯誤提示拉队，正常發(fā)布文章 | |
| 3 | 80個(gè)字符的標(biāo)題 | 8000 個(gè)字符的內(nèi)容 | 無錯誤提示，正常發(fā)布文章 | |
| 4 | 空 | 空 | 錯誤提示阻逮，不能正常發(fā)布文章 |
上面的 4 個(gè)用例覆蓋了常見的用戶場景粱快，如果實(shí)際測試結(jié)果符合預(yù)期，產(chǎn)品基本上是合格的，但不要忘記一些隱藏的陷阱：
- 標(biāo)題或文章內(nèi)容包含 html 標(biāo)簽等特殊字符時(shí)事哭，系統(tǒng)能否正確保存漫雷？
- 文章內(nèi)容為富文本編輯器，如果錄入的有 8000 個(gè)字符鳍咱，插入圖片降盹、添加格式后是否還能保存成功？
- ...
根據(jù)需求文檔可以定義大多數(shù)情況的測試用例谤辜，還有很多特殊情況的用例蓄坏，需要經(jīng)驗(yàn)的積累來完善。還有一些特殊情況只有實(shí)際遇到才會想到丑念，這時(shí)就需要把這種場景及時(shí)補(bǔ)充到用例中涡戳。
回歸測試
在產(chǎn)品的正常迭代中，一般是新開發(fā)了什么功能脯倚，就重點(diǎn)測試什么功能渔彰，但也經(jīng)常會遇到這種情況：這次項(xiàng)目的目的是開發(fā) A 功能，但是在開發(fā) A 功能的過程中導(dǎo)致了 B 模塊出現(xiàn)了 bug推正，這就需要將和 A 功能相關(guān)的所有模塊再測試一遍——即使之前這些模塊都是測試通過的恍涂，這就是回歸測試。在測試相對復(fù)雜系統(tǒng)的時(shí)候植榕，測試的工作量會大很多再沧，之前做過的用例還要重復(fù)測試一遍，這樣測試的很大部分就變成了體力活尊残。
如何避免重復(fù)勞動呢产园？ 答案就是將重復(fù)勞動交給程序來實(shí)現(xiàn)，這就是自動化測試夜郁。
自動化測試
自動化測試通過寫程序的方式，把人在重復(fù)勞動中解脫出來粘勒。前文中提到的 4 種測試用例竞端，假設(shè)每次程序有改動都要再測一遍，那么我就可以把預(yù)設(shè)的表單內(nèi)容寫在測試腳本中庙睡，通過指定元素的內(nèi)容來判斷是否符合預(yù)期事富，寫好腳本后，測試框架會幫你自動完成那些操作乘陪。甚至可以自動生成測試報(bào)告统台。這些操作需要一定的編程基礎(chǔ)，如果有困難啡邑，可以找工程師幫忙贱勃。自動化測試工具筆者目前只使用過 Selenium，大大解放過我的生產(chǎn)力。
有獎眾測
畢竟個(gè)人的精力是有限的贵扰，即使有專門的測試團(tuán)隊(duì)仇穗，也很難發(fā)現(xiàn)產(chǎn)品中所有的問題。在正式發(fā)布前戚绕，可以將內(nèi)測中的產(chǎn)品發(fā)給公司同事試用纹坐，采用 ”提 bug 有獎“ 的策略調(diào)動大家的積極性，只需花可樂舞丛、零食的錢就能獲取很多有價(jià)值的反饋耘子。
筆者參與過的一個(gè) Android APP 的項(xiàng)目，項(xiàng)目初期 Android 測試機(jī)只有 3 臺球切，項(xiàng)目又要趕著上線谷誓，我們采取這種方式把公司使用 Android 手機(jī)的同事調(diào)動起來，在正式發(fā)布前修正了一些重要的兼容性問題欧聘。
測試報(bào)告
測試結(jié)束后片林，要將測試結(jié)果發(fā)布出來，讓團(tuán)隊(duì)內(nèi)所有人了解產(chǎn)品目前的狀態(tài)怀骤，同時(shí)將 bug 分級费封，為它們排優(yōu)先級，將修正 bug 的工作排到接下來的工作計(jì)劃中蒋伦。
功能測試是合格產(chǎn)品經(jīng)理的必備素質(zhì)弓摘，要求能夠撰寫完整的測試用例并實(shí)踐，完成測試報(bào)告并敦促工程師團(tuán)隊(duì)改進(jìn)產(chǎn)品痕届，在這個(gè)過程中不斷打磨改進(jìn)產(chǎn)品韧献。測試只是手段，打造用戶喜愛的產(chǎn)品才是目的研叫。
