兩年手機軟體測試工作總結

轉自：http://blog.sina.com.cn/s/blog_48f5a98701000ajc.html

以下是我對測試工作的認識，並做了些闡述：

一、前提條件

1.培養個人素質：

A對工作一絲不苟的謹慎態度和一如既往的高昂熱情。

B探索精神，打破沙鍋問到底。

C追求完美，創造性思維，想出富有創意甚至超常的手段來尋找缺陷。

D善於表達觀點，並組織好語言，描述操作過程應做到通俗易懂。

2.認識職責所在：

A測試案例、測試計劃的編寫，測試資源、測試品質的協調保證。

B測試執行，部分自動化測試、效能測試。

C國外、國內，外場測試的支援。

二、測試目的

測試的目的是為了發現儘可能多的缺陷，這個觀念很容易讓人接受，但是卻很難落實到實際工作中，因為測試的目的常常被定位為“證明軟體沒有問題”。軟體品質是否優良在投產後才能有所體現。

正確理解測試的目的十分重要。如果認為測試的目的是為了說明程式中沒有缺陷，那麼測試人員就會向這個目標靠攏，因而下意識地設計很多不易暴露錯誤的測試樣本，這些測試案例恰恰證明軟體實現了預期功能，這樣的測試是不真實的。成功的測試在於發現了迄今尚未發現的缺陷。

三、測試流程

1.項目需求評審：

A評審原則：檢查需求的正確性，無歧義性，完整性，一致性，可執行性，可驗證性，可修複性，可追溯性。不要只檢查文檔的表面文字和介面，要深入思考，該功能是否符合邏輯，敢於提出問題。

B評審要點：是否描述可輸入/輸出值的屬性，如邊界值，度量單位，時序要求等。是否描述清楚軟體模組與模組間銜接處的處理情況及傳回值。專用名詞是否一致性等等。

2.制定測試計劃

A.對測試專案進行劃分進程，明晰在某個時間應該完成某個測試工作。盡量細分測試階段及人員分配。

B.瞭解、收集並整理測試所需的資源。

C.制定可用度量指標定義的測試成功條件。

3.設計測試案例：

A基本要素：測試目的、前提條件、輸入資料或操作過程、期望的響應。

B不同的測試例其用途應當不同，不要冗餘。

C設計測試案例在除了常用資料外，還需要考慮極限值、邊界值、重複值、0值及負值，即不同的測試案例需要不同類型的資料值來進行測試。

D設計測試案例時需要注意的是，除了對整體流程及功能注意外，還要注意強度測試、效能測試、壓力測試、邊界值測試、穩定性測試、安全性測試等多方面。

4.測試過程

A整合測試：將一些程式模組整合在一起時，測試它們能否正常運行。

B系統測試：指在於模組測試與單元測試的基礎上進行測試。瞭解系統功能與效能，根據測試案例進行全面的測試。目的在於測試軟體是否符合所有需求（包括功能性需求與非功能性需求）。

C效能測試：測試軟體的已耗用時間，回應時間，函數調用頻度及嵌套，CPU佔用率，資料輸送量，輔助儲存區，處理精度等。

D相容對比測試：比如SIM卡、T卡、音頻、視頻等的相容對比測試。

E待機電流測試：目的是測試電池的使用時間，待機電流圖示也能體現出內部軟體的穩定性。

F自動化測試：利用儀器來類比使用者使用過程，手機正常操作狀態進行實驗。實際上自動化的測試是將大量的重複性工作交給電腦來完成，可以節省大量的時間、成本、人員和資源。

G場地測試：主要是進行通訊網路測試，如：通話、資訊、上網等，在不同的網路環境下進行測試，檢驗其通訊效能。

H CTA、FTA、GCF預測：

CTA預測：主要是測手機的射頻特性，也叫RF指標。通俗的講，CTA就是通訊裝置的入網認證。

FTA預測：全面型號認證（FULL TYPE APPROVAL）。GSM認證預測試。

GCF預測：GSM和WCDMA認證預測試。

I 迴歸測試：當缺陷被修正後或軟體功能、環境發生變化後進行的重新測試。測試的困痛點在於不好確定哪些內容應當重新測試。

J出廠測試：根據出廠的標準指標設計的測試例來進行各項測試。其中只要有一項指標沒通過，則不能通過出廠測試。出廠測試例包括開關機、通話功能、特殊按鍵功能、菜單功能、附件功能、待機電流。

（測試重點：針對本項目的重點，如是音樂手機、電影手機、拍照手機、智能手機、遊戲手機等。從使用者的使用點來測試。根據使用者購買想法來進行重點模組的測試。在測試過程中，也要進行負載測試，壓力測試，易用性測試，安裝與升級卸載測試，安全性測試等等。）

5.缺陷描述

A基本要求：準確、簡潔、完整、規範。

B描述要點：標題應明確指明錯誤要點；操作過程應描述出測試的整個過程，包括工作環境，測試機器的運行條件，盡量多的提供一些相關的資訊；還應相應的寫明實際的運行結果和預期期望實現的結果。最好能即時儲存trace或log資訊。

6.測試報告及評估

A模式要點：標題、版本號碼、測試員、統計資料、機率性、及個人對此次版本測試的評估等。

B現在測試報告基本上都有模板，如果是沒有的話，應注意以上幾點要點。

7.溝通

有些問題會與程式員所設計的相出路，甚至是一些小問題，那更應該發揮我們的溝通能力，要善於表達觀點，表明軟體缺陷為何必須修複，並通過實際示範求證觀點。

8.小結

總之在這測試過程中，應儘可能做到“80-20”原則，在分析、設計、實現階段的複審和測試工作能夠發現和避免80%的Bug，而系統測試又能找出其餘Bug中的80%，最後的5%的Bug可能只有在使用者的大範圍、長時間使用後才會暴露出來。因為測試只能夠保證儘可能多地發現錯誤，無法保證能夠發現所有的錯誤。還有就是一般情況下80％的缺陷聚集在20％的關鍵核心業務模組中。

四、測試遺漏的後果

如果軟體缺陷被遺落併流落到客戶那裡，結果就是代價高昂的電話或者現場支援費用，還可能需要修複、重新測試和發布新的產品，更糟糕的情況是產品要被召回甚至被客戶起訴。這種成本付出非常高，幾乎是在內部修改缺陷的幾何級數倍。

品質之父PhilipCrosby把品質的費用分為整合費用和非整合費用兩類，整合費用是指與一次性計劃和執行測試相關的全部費用，用於保證軟體按照預期方式進行。如果發現缺陷，經過一系列的缺陷處理流程而解決缺陷，這種費用就是非整合費用。PhilipCrosby在自己的作品中詳細論述了內部的整合費用和內部的非整合費用之和遠遠小於外部也就是客戶引起的非整合費用。

總之，軟體缺陷一定要儘可能的在內部解決，這對節約成本、提高產品知名度都大有裨益。

以下是本人對現今測試存在的問題及部門管理上的一些看法：

1沒按照測試例進行測試，因為測試例條目實在太多，況且測試時間短，人力資源少，所以只是對基本測試例過一遍而已。這樣對於撰寫測試例來說純屬浪費，這點我覺得既然實行了走測試例就要嚴格執行，統一管理，執行結果應總結，並進行對該次測試給個評分。每個測試階段應有一定的改善。

2測試例應有兩種版本，一種是給程式員執行的，（一般在20條測試例之內，並且是基本的，不會耗很多時間。保證版本的有效率，降低出版本次數。）在每次編譯器之前，程式員都應先自己執行一遍。另一種是給測試員執行的，測試例要詳細，平常要及時更新，一人分兩個模組，測試一周左右，對測試例進行交叉測試。並在一定時間內測試工作也要替換，避免反覆測試的煩惱。有任務則有效制約了閒置測試人員，增強時間性及工作氛圍。在最後一次迴歸測試應對測試例全部過一遍，這將是必要的。

3建議增加測試人員，一個成功的項目，它的開發人員與測試人員比例應為1：2。在當前我們比例都少於1：1/2，這樣對於一個項目的開發進程及品質是起抑製作用的。

4開發人員會逐漸影響測試人員的思維和對缺陷的判斷能力，尤其是針對同一平台，同一組開發人員和同一組測試人員共同配合了很長時間，很多本來是缺陷的問題，由於測試人員對軟體“習慣成自然”的使用，會不被當成缺陷，尤其是在開發人員的解釋和說服下。同化現象發生可能意味著“惡性迴圈”的開始：測試人員會幫著開發人員解釋一個個缺陷的合理性，一輪有一輪的測試都不會發現問題。招聘新的人員，不同的測試專案組輪換去測試不同的產品，就可以避免。同時建議產品發行就緒測試版，更多的人對其進行測試，就可以發現更多的問題。

5在系統測試階段，有時會碰到很多低級缺陷，說明測試對象是不合格的，沒有達到測試標準。如果系統階段發現的簡單缺陷（也就是不應該有的缺陷）較多，最好停止測試，轉由開發人員進行測試，發現問題立刻修改，因為這種由測試人員進行的成本較高，反覆互動還會耽誤進度。建議建立預測試製度：系統測試前對核心模組進行抽查測試，如果問題較多（例如平均每個核心模組發現10個以上缺陷），就可以停止本次測試，直到抽測後發現問題較少才可以啟動系統測試。

6對測試人員的培訓少，建議設立一個日常培訓機構，並分別由各組來組織，時間為每天下班前半個小時（這段時間總是沒心情測試的），利用這時，來對各組進行總結每天的測試成果，並開展組與組的座談交流，有利於提高測試技能。

7避免特有技能在單人手中掌握，主要有兩種方法：第一種是在測試人員內部建立一個良好的學習環境，大家互相學習，這樣某些特有技術不會被某一個人所掌握，而互相學習和提高自身，也是大多數成員願意做的；第二種就是在組織中進行知識管理，把技術作為知識沉澱下來，這樣新的員工在接手工作時容易上手，通過學習快速適應環境。此外，日常還要注意工作正常化，例如形成儘可能多的文檔，都可以降低員工離職帶來的損失。

自己的缺點：

我喜歡測試新平台新項目，因為能發現很多問題，有一種快感，越測也有激情，總會回味無窮。但這就是我的缺點所在，這就意味著當我碰到穩定的項目的時候，我卻不能發揮那種測試激情，反而感到無從下手，覺得軟體穩定，沒什麼問題。就會下意識的向這個目標靠攏，測試不出問題來，結果不能很好的完成測試工作