來人人都是產品經理【起點學院】，BAT實戰(zhàn)派產品總監(jiān)手把手系統(tǒng)帶你學產品、學運營。

首先說下，我們團隊沒有測試人員，所以測試任務由產品助理來負責。在互聯(lián)網(wǎng)行業(yè)，規(guī)模比較小的公司團隊，測試任務也多是由產品人員負責的，因為他們對做的出來的東西比較了解?；ヂ?lián)網(wǎng)項目一定不能少了測試這一環(huán)境，無論是內部項目還是對外項目。人總是要求自己安心，還有別人放心。

互聯(lián)網(wǎng)產品的測試較之軟件行業(yè)的測試技術上沒有那么復雜，但是變化性和更新迭代性比較其略有增加。我們主要實現(xiàn)的是對其產品功能的測試，目的就是為了檢驗最后工程師與設計師做出來的產品與我們最初確立的需求和預期是否吻合，還有就是發(fā)現(xiàn)其中明顯的使用缺陷和實施錯誤。測試的結果是一個產品是否完成的標準，也是一個產品成功迭代更新的保障。

了解需求文檔和項目原型

很多公司沒有專門的需求文檔，在此我們可以把市場客戶調研問卷，產品立項會議記錄，策劃人員產出的ppt等等作為需求文檔，我覺得所有和這個項目有關的文檔都是需求文檔。然后是項目原型，因為項目原型是通過需求討論而產生的，在一定程度上已經相當全面的體現(xiàn)了需求。原型通常由產品經理和助理負責，所以他們也是最清楚需求的人。

對于對產品了解的人來說其實需求文檔就在你的腦子里。

舉例說一下產品需求文檔，下面是一個文章信息發(fā)布模塊的需求文檔：

信息發(fā)布的需求

1. 可分類顯示信息，可刪除、添加、修改新聞信息的類別。
2. 可按照信息類別查詢、添加、刪除、修改某一條新聞信息。
3. 新聞能夠顯示圖片和文字，允許且只可以上傳圖片及壓縮格式文件，新聞信息可以附帶其他下載資料，如新商品的使用說明書等。
4. 可以讓某條重要信息固定出現(xiàn)在所有信息的最前面，也可讓某條信息固定在某一類別信息的最前面。
5. 可以顯示瀏覽者對某條新聞信息的閱讀次數(shù)。

…………

然后是產品原型，他更直觀的表現(xiàn)了我們要做的東西，對測試來說，需要清楚地認知他的各部分模塊功能還有內容是什么。而一些細節(jié)和可能出現(xiàn)的問題都想用下面的東西來解決，它就是測試用例。

寫測試用例

在工程師開始進行開發(fā)時我們就可以寫測試用例了，我的測試用例一般就是兩種，一種是用MindManager思維導圖，一種是用EXCEL表格，由于自己感覺表做起來好頭疼，所以有時就用Word文檔。

用思維導圖能起到梳理思路的作用，從整體到每個分支，每個技術點都有他需要注意和測試的內容，當然你不必寫的太詳細，只要把綱列出來就差不多了，而其中的細節(jié)通過大腦的聯(lián)想也會基本概括了。而文檔寫測試用例的作用是可以給工程師看作為他的輔助，還可以用來記錄測試結果。

測試用例一定要拿出單獨的時間來完成，最好不要與其他工作交織著進行，是為了更安靜的總結你自己的思路。

下圖是某項目思維導圖的一部分，在此把此模塊各個分支都列出來了，但是并沒有詳細預測列出測試點，因為第一太費時間，第二具體實踐過程中會出現(xiàn)各種情況，包括以下問題但不限于以下問題。

下面這張圖是測試用例文檔，可以根據(jù)具體事宜設計具體文檔，測試用例文檔應該是沒有固定格式的，其中的幾個欄目要點也是有的可以省略，有的可以添加。如果最后需要領導看的話，最好把測試結果寫清楚。

測試的實施與管理

我們知道有BugFree，Bugzilla等bug管理系統(tǒng)，他們能讓我們更高效的提出bug和管理bug，對測試出的bug有分級和指派等功能。但是總是覺得這些管理系統(tǒng)，從安裝，維護，到管理對互聯(lián)網(wǎng)行業(yè)來說有些局限性。由于互聯(lián)網(wǎng)更新速度塊，講究速度與創(chuàng)新，所以在bug管理這方面，最好也用互聯(lián)網(wǎng)思維去解決。在這里，用一個在線項目協(xié)作管理工具就挺好，Tower。

在使用它的過程中，我們每開展一個項目，就為它創(chuàng)建一個項目測試專題模塊。然后把測試中的問題提到這個模塊。怎么表述和提交就不細說了，按照自己和程序人員的習慣就行。我們把每個問題指派給負責他的人，他也可以又不懂的在上面進行回復溝通。對于重要的問題，可以對題目進行標注，加急處理。也可以把問題當做任務指派給某個人，最后勾選完成就可以了。

當然已經完成的任務也是可以再打開的，因為可能由于后期某些修改更新出現(xiàn)新的問題。使得其不得不進行回歸測試。

這樣既起到了提交作用，又起到了紀錄作用，還一定程度上完善了遠程溝通。最重要的的是，Tower有時效性，更新速度塊，一個程序和網(wǎng)站可能有多個版本。有針對性，指派任務明確，大家都有責任感。不死板，系統(tǒng)界面生動，溝通人性化，工作有熱情。

在進行一般兩輪測試提交和修改之后，等到上面的任務都完成，測試也就接近尾聲了。

團隊協(xié)作，交給用戶

有時候由于時間緊迫或者項目工作量大等，需要團隊其他人員的協(xié)助。對于一些客戶端產品，需要很多類型的手機或者平板等，也需要動用公司的所有人來進行測試。比如各個手機上的現(xiàn)實問題，兼容問題，不同瀏覽器的兼容問題等。

也可以吸取其他公司的經驗，就是有獎測試。在進行完常規(guī)測試后把項目版本發(fā)給每一個公司人員，隨測出來新的問題或者提出新的解決方法就給予他們獎勵，這樣就更好的完善了產品。

交給用戶，最終的使用者是用戶。

在我們把它交給用戶之前，我們已經做了上面的團隊測試。基本不會出現(xiàn)特別大的失誤和低級錯誤，甚至已經趨于完善。接下來就讓用戶去內測吧，來看看他們的智慧吧。而對于針對企業(yè)客戶的項目，可以讓他們自己或者他們的幾個客戶先體驗一下。

關于自動化與工具

其中包括回歸測試工具，性能測試工具，瀏覽器兼容測試工具等。根據(jù)項目的不同需求會需要不同的自動化工具輔助進行測試。

比如回歸測試。它是根據(jù)修復好了的缺陷再重新進行測試。目的在于驗證以前出現(xiàn)過但已經修復好的缺陷不再重新出現(xiàn)。一般指對某已知修正的缺陷再次圍繞它原來出現(xiàn)時的步驟重新測試。通常確定所需的再測試的范圍時是比較困難的，特別當臨近產品發(fā)布日期時。因為為了修正某缺陷時必需更改源代碼，因而就有可能影響這部分源代碼所控制的功能。所以在驗證修好的缺陷時不僅要服從缺陷原來出現(xiàn)時的步驟重新測試，而且還要測試有可能受影響的所有功能。因此應當鼓勵對所有回歸測試用例進行自動化測試。工具如Selenium等。

使用的目的是為了節(jié)約時間與人力，這樣的前提下，如果它們提高了我們的效率會讓事情更完美。

附件：一個簡單的思維導圖