互聯網產品的測試

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

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

了解需求文檔和項目原型

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

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

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

信息發布的需求

1.可分類顯示信息，可刪除、添加、修改新聞信息的類別。

2.可按照信息類別查詢、添加、刪除、修改某一條新聞信息。

3.新聞能夠顯示圖片和文字，允許且只可以上傳圖片及壓縮格式文件，新聞信息可以附帶其他下載資料，如新商品的使用說明書等。

4.可以讓某條重要信息固定出現在所有信息的最前面，也可讓某條信息固定在某一類別信息的最前面。

5.可以顯示瀏覽者對某條新聞信息的閱讀次數。

…………

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

寫測試用例

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

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

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

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

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

測試的實施與管理

我們知道有BugFree，Bugzilla等bug管理系統，他們能讓我們更高效的提出bug和管理bug，對測試出的bug有分級和指派等功 能。但是總是覺得這些管理系統，從安裝，維護，到管理對互聯網行業來說有些局限性。由于互聯網更新速度塊，講究速度與創新，所以在bug管理這方面，最好 也用互聯網思維去解決。在這里，有一個在線項目協作管理工具就挺好，它就是Tower，很多人都知道它，現在很多創業公司都是使用的它，這是一個趨勢吧。

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

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

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

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

團隊協作，交給用戶

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

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

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

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

關于自動化與工具

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

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

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

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

這就是 互聯網產品的測試總結，或者說一個小的互聯網團隊的測試總結，寫的時候也借鑒了其他兩篇網上的文章，與其還是有很多相通之處。我只是大致的描繪，應該有人有其他更好的全面細致的經驗。