１。基本概念

１。１軟件

軟件就是可以在計算機上運行的計算機程序，如操作系統Windows、辦公軟件Office、聊天ＱＱ、手機游戲等。軟件和我們的生活和工作之間的聯系越來越密切。

１。２軟件測試

軟件測試的經典定義是：在規定的條件下對程序進行操作，以發現程序錯誤，衡量軟件品質，并對其是否能滿足設計要求進行評估的過程。

軟件測試的現實定義是：軟件測試是貫穿整個軟件開發生命周期、對軟件產品（包括階段性產品）進行驗證和確認的活動過程，其目的是盡快盡早地發現在軟件產品中所存在的各種問題——與用戶需求、預先定義的不一致性。

１。３測試的方法

軟件測試一般分為白盒測試和黑盒測試。

黑盒測試

黑盒測試，軟件測試的主要方法之一，也可以稱為功能測試、數據驅動測試或基于規格說明的測試。測試應用程序的功能，而不是其內部結構或運作。測試者不需具備應用程序的代碼、內部結構和編程語言的專門知識。測試者只需知道什么是系統應該做的事，即當鍵入一個特定的輸入，可得到一定的輸出，這是從用戶的角度針對軟件界面、功能及外部結構進行測試，而不考慮程序內部邏輯結構。測試用例是應用系統應該做的功能，照規范、規格或要求等設計。測試者選擇有效輸入和無效輸入來驗證是否正確的輸出。此測試方法可適合大部分的軟件測試，例如單元測試（unit testing）、集成測試（integration testing）以及系統測試（system testing）。

白盒測試

白盒測試（又稱透明盒測試、結構測試等）是一個測試軟件的方法，測試應用程序的內部結構或運作，而不是測試應用程序的功能（即黑盒測試）。在白箱測試時，以編程語言的角度來設計測試案例。測試者輸入數據驗證數據流在程序中的移動路徑，并確定適當的輸出，類似測試電路中的節點。

白箱測試可以應用于單元測試、集成測試和系統的軟件測試流程，可測試在集成過程中每一單元之間的路徑，或者主系統跟子系統中的測試。盡管這種測試的方法可以發現許多的錯誤或問題，它可能無法檢測未使用部分的規范。

１。４測試的類型

功能測試

按照測試軟件的各個功能劃分進行有條理的測試，在功能測試部分要保證測試項覆蓋所有功能和各種功能條件組合。

更詳細的描述請參見“黑盒測試”。

系統測試

對一個完整的軟件以用戶的角度來進行測試，系統測試和功能測試的區別是，系統測試利用的所有測試數據和測試的方法都要模擬成和用戶的實際使用環境完全一樣，測試的軟件也是經過系統集成以后的完整軟件系統，而不是在功能測試階段利用的每個功能模塊單獨編譯后生成的可執行程序。

極限值測試

對軟件在各種特殊條件，特殊環境下能否正常運行和軟件的性能進行測試。

特殊條件一般指的是軟件規定的最大值，最小值，以及在超過最大，小值條件下的測試。

特殊環境一般指的是軟件運行的機器處于CPU高負荷，或是網絡高負荷狀態下的測試，根據軟件的不同，特殊環境也有過不同。

性能測試

性能測試是對軟件性能的評價。簡單的說，軟件性能衡量的是軟件具有的響應及時度能力。因此，性能測試是采用測試手段對軟件的響應及時性進行評價的一種方式。根據軟件的不同類型，性能測試的側重點也不同。

壓力測試

壓力測試，確立系統穩定性的一種測試方法，在軟件工程、金融風險管理等領域應用比較普遍。通常在系統正常運作范圍之外進行，以考察其功能極限和隱患。

壓力測試與性能測試的區別

壓力測試常常和性能測試相混淆。它們主要不同點是，壓力測試要求進行超過規定性能指標的測試。例如一個網站設計容量是100個人同時點擊，壓力測試就要是采用120個同時點擊的條件測試。

１。５測試的階段

單元測試

單元測試是對軟件組成單元進行測試，其目的是檢驗軟件基本組成單位的正確性，測試的對象是軟件設計的最小單位---模塊。單元測試一般由開發人員完成。

集成測試

集成測試又稱組裝測試，是將程序模塊采用適當的集成策略組裝起來，對系統的接口及集成后的功能進行正確性檢測的測試工作。其主要目的是檢查軟件單位之間的接口是否正確，集成測試的對象是已經經過單元測試的模塊。

實踐表明，有時模塊雖然可以單獨工作，但是并不能保證組裝起來也可以同時工作。

系統測試

系統測試主要包括功能測試、界面測試、可靠性測試、易用性測試、性能測試。 功能測試主要針對包括功能可用性、功能實現程度（功能流程&業務流程、數據處理&業務數據處理）方面測試。

回歸測試

回歸測試是為了檢測代碼修改而引入的錯誤所進行的測試活動。回歸測試是軟件測試階段的重要工作，有研究表明，回歸測試帶來的耗費占軟件生命周期的1/3總費用以上。

與普通的測試不同，在回歸測試過程開始的時候，測試者有一個完整的測試用例集可供使用，因此，如何根據代碼的修改情況對已有測試用例集進行有效的復用是回歸測試研究的重要方向，此外，回歸測試的研究方向還涉及自動化工具，面向對象回歸測試，測試用例優先級，回歸測試用例補充生成等。

Alpha測試

α測試通常是階段性的開發完成后所開始進行，一直持續到進入Beta測試階段前的階段。α測試是一種驗證測試，在模擬的環境中以模擬的數據來運行。

在這個階段中，通常是在開發單位由開發人員與測試的測試人員，以模擬或實際操作性的方式進行驗證測試。

Beta測試

在系統測試中通常先進行α測試以驗證信息系統符合用戶以及設計需求所期望的功能。當α階段完成后，開發過程進入到β階段；由公眾參與的測試的階段。β測試可稱為確認測試，在一個真實的環境中以實際的數據來運行測試，以確認性能、系統運行有效率，系統撤消與備份作業正常，通過測試讓信息系統日后可以

Beta測試和黑盒測試的區別

對Alpha和Beta測試常見的一個認識誤區是“Beta測試＝黑盒測試”。實際上，Alpha和Beta測試對應在軟件產品發布之前的Alpha和Beta階段，而白盒、黑盒和灰盒測試技術是從技術和方法層面對測試的描述，不應該將這兩部分概念混淆。

驗收測試

驗收測試是系統部署到用戶環境后，用戶運行系統，考察系統是否滿足用戶需求的過程。驗收測試是用戶主導的，用戶可能聘請專家幫助驗收測試。

１。６軟件測試的作用

1.對產品質量完成全面的評估，為軟件產品發布（如驗收測試）、軟件系統部署（如性能規劃測試）、軟件產品鑒定（第三方獨立測試）委托方和被委托方糾紛仲裁（第三方獨立測試）和其它決策提供信息；

2.通過持續的測試（包括需求評審、設計評審、代碼評審等）可以對產品質量提供持續的、快速的反饋，從而在整個開發過程中不斷地、及時地改進產品的質量，并減少各種返工，降低軟件開發的成本；

3.通過測試發現所要交付產品的缺陷，特別是盡可能地發現各種嚴重的缺陷，降低或消除產品質量風險，提高客戶的滿意度，擴大市場份額，提高客戶的忠誠度。

4.通過對缺陷進行分析，找出缺陷發生的根本原因（軟件過程中的問題，包括錯誤的行為方式）或總結出軟件產品的缺陷模式，避免將來犯同樣的錯誤或產生類似的產品問題，達到缺陷預防的目的

２。初級軟件測試工程師主要工作

２。１編寫功能測試用例

１）測試用例設計步驟

設計測試案例的時候，需要有清晰的測試思路，對要測試什么，按照什么順序測試，覆蓋哪些需求做到心中有數。測試用例編寫者不僅要掌握軟件測試的技術和流程，而且要對被測軟件的設計、功能規格說明、用戶試用場景以及程序/模塊的結構都有比較透徹的理解。測試用例設計一般包括以下幾個步驟：

1、測試需求分析

從軟件需求文檔中，找出待測試軟件/模塊的需求，通過自己的分析、理解，整理成為測試需求，清楚被測試對象具有哪些功能。測試需求的特點是：包含軟件需求，具有可測試性。

測試需求應該在軟件需求基礎上進行歸納、分類或細分，方便測試用例設計。測試用例中的測試集與測試需求的關系是多對一的關系，即一個或多個測試用例集對應一個測試需求。

2、業務流程分析

軟件測試，不單純是基于功能的黑盒測試，還需要對軟件的內部處理邏輯進行測試。為了不遺漏測試點，需要清楚的了解軟件產品的業務流程。建議在做復雜的測試用例設計前，先畫出軟件的業務流程。如果設計文檔中已經有業務流程設計，可以從測試角度對現有流程進行補充。如果無法從設計中得到業務流程，測試工程師應通過閱讀設計文檔，與開發人員交流，最終畫出業務流程圖。業務流程圖可以幫助理解軟件的處理邏輯和數據流向，從而指導測試用例的設計。

從業務流程上，應得到以下信息：

A、 主流程是什么

B、 條件備選流程是什么

C、 數據流向是什么

D、 關鍵的判斷條件是什么

3、測試用例設計

完成了測試需求分析和軟件流程分析后，開始著手設計測試用例。測試用例設計的類型包括功能測試，邊界測試，異常測試，性能測試，壓力測試等。在用例設計中，除了功能測試用例外，應盡量考慮邊界、異常、性能的情況，以便發現更多的隱藏問題。

黑盒測試的測試用例設計方法有：等價類劃分、邊界值劃分、因果圖分析和錯誤猜測，白盒測試的測試用例設計方法有：語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、多重條件覆蓋。在這里主要討論黑盒測試。在設計測試用例的時候可以使用軟件測試用例設計方法，結合前面的需求分析和軟件流程分析進行設計：

功能測試：測試某個功能是否滿足需求的定義，功能是否正確，完備。

適合的技術：由業務需求和設計說明導出的功能測試、等價類劃分

邊界測試：對某個功能的邊界情況進行測試。

適合的技術：邊界值劃分

異常測試：對某些功能來說，其邊界情況無法簡單的了解或某些操作不完全是正確的但又是可能發生的，類似這樣的情況需要書寫相關的異常測試。

適合的技術：由業務需求和設計說明導出的特殊業務流程、錯誤猜測法、邊界值分析、內部邊界值測試、

性能測試：檢查系統是否滿足在需求中所規定達到的性能，性能主要包括了解程序的內外部性能因素。內部性能因素包括測試環境的配置，系統資源使用狀況；外部因素包括響應時間，吞吐量等。

適合的技術：業務需求和設計說明導出的測試

壓力測試：壓力測試又稱強度測試，主要是檢查系統運行環境在極限情況下軟件運行的能力，比如說給一個相當大的負荷或網絡流量給應用軟件兼容測試：測試軟件產品在不同的平臺，不同的工具，相同工具的不同版本下功能的兼容性。

4、測試用例評審

測試用例設計完成后，為了確認測試過程和方法是否正確，是否有遺漏的測試點，需要進行測試用例的評審。

測試用例評審一般是由測試leader安排，參加的人員包括：測試用例設計者、測試leader、項目經理、開發工程師、其它相關開發測試工程師。測試用例評審完畢，測試工程師根據評審結果，對測試用例進行修改，并記錄修改日志。

5、測試用例更新完善

測試用例編寫完成之后需要不斷完善，軟件產品新增功能或更新需求后，測試用例必須配套修改更新；在測試過程中發現設計測試用例時考慮不周，需要對測試用例進行修改完善；在軟件交付使用后客戶反饋的軟件缺陷，而缺陷又是因測試用例存在漏洞造成，也需要對測試用例進行完善。一般小的修改完善可在原測試用例文檔上修改，但文檔要有更改記錄。軟件的版本升級更新，測試用例一般也應隨之編制升級更新版本。測試用例是“活”的，在軟件的生命周期中不斷更新與完善。

２）測試用例設計方法

黑盒測試的測試用例設計方法有：等價類劃分、邊界值劃分、因果圖分析和錯誤猜測，白盒測試的測試用例設計方法有：語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、多重條件覆蓋。在這里，主要討論的是黑盒測試的測試用例的設計方法。

一、等價類劃分

等價列劃分設計方法是把所有可能的輸入數據劃分成若干部分（子集），然后從每一個子集中選取少量具有代表性的數據作為測試用例，測試某等價類的代表值就等于對這一類其他值的測試。

使用等價類劃分方法設計測試用例主要有兩個步驟：（1）確定等價類；（2）生成測試用例。

1、劃分等價類

等價類劃分有兩種不同的情況：有效等價類代表對程序的有效輸入和無效等價類代表不正確的輸入值，設計時要同時考慮這兩種等價類。下面是確定等價類的原則：

（1）在輸入條件規定了取值范圍的情況下，則可以確立一個有效等價類（在取值范圍之內）和兩個無效等價類（小于取值范圍和大于取值范圍）。 例如：使用手機發送短信的時候，短信內容長度必須在70個字符之內，則有效等價類：短信內容長度在70個字符之內，無效等價類：短信內容長度為0、短信內容長度大于70。

（2）在輸入條件規定了取值的個數的情況下，則可以確立一個有效等價類（在取值個數范圍之內）和兩個無效等價類（小于取值個數和大于取值個數）。例如：一名學生一個學期可以選修一至五門課程，則有效等價類為：1《=學生選修課程《=5，無效等價類為：沒有選修課程、選修課程大于5

（3）在輸入條件規定了輸入值的集合的情況下，則可以確立一個有效等價類和一個無效等價類。 比如：發送短信的編碼的取值范圍是0、3、4、8、15或16，則有效等價類是：短信編碼為0或3或4或8或15或16，無效等價類是：短信編碼不是0或3或4或8或15或16其中任何一種。

（4）在輸入條件規定了 “必須如何”的條件的情況下，則可以確立一個有效等價類和一個無效等價類。 例如：變量的命名比如以大寫字母開頭，則有效等價類為：變量命名以大寫字母開頭，無效等價類為：變量開頭非答寫字母開頭。

（5）在輸入條件是一個布爾量的情況下，可以確立一個有效等價類和一個無效等價類。 例如：在神州行手機號碼預扣費成功的情況下，允許該用戶發送短信，則有效等價類為：神州行預扣費成功，無效等價類為神州行預扣費失敗。

（6）在規定了輸入數據的一組值（假定n個），并且程序要對每一個輸入值分別處理的情況下，可以確立n個有效等價類和一個無效等價類。

（7）在規定了輸入數據必須遵守的規則的情況下，可以確立一個有效等價類（符合規則）和若干個無效等價類（從不同角度違反規則）。

（8） 在確知已劃分的等價類中各元素在程序處理中的方式不同的情況下，則應再將該等價類進一步的劃分為更小的等價類。

2、生成測試用例

在確立了等價類后，可建立等價類表，列出所有劃分出的等價類，過程為：

（1）為每一個等價類規定一個唯一的編號。

（2）設計一個新的測試用例，使其盡可能多的覆蓋尚未被覆蓋的有效等價類，重復這一步，直到所有的有效等價類都被覆蓋為止。

（3）設計一個新的測試用例，使其僅覆蓋一個尚未被覆蓋的無效等價類，重復這一步，直到所有的無效等價類都被覆蓋為止。

二、邊界值分析法

邊界條件指的是輸入和輸入等價類中剛好處于邊界、或超過邊界或小于邊界的狀態，使用邊界值分析方法設計測試用例應先確定邊界情況，然后選取正好等于、剛剛大于或剛剛小于邊界的值作為測試數據。

基于邊界值分析方法選擇測試用例的原則：

（1）如果輸入條件規定了值的范圍，則應取剛達到這個范圍的邊界值設計有效測試用例，以及剛剛超過這個范圍的邊界值作設計無效測試用例。比如：短信內容的有效長度為70個漢字以內，則有效測試用例：短信內容長度為1，短信內容長度為70個漢字，無效測試用例：短信內容長度為0，短信內容長度為71個漢字。

（2）如果輸入條件規定了值的數量，則應取最大個數、最小個數、比最小個數少一、比最大個數多一的數作為測試輸入的數據。 例如：短信的有效編碼為1~255，則應取0、1、255、256設計邊界值測試用例。

（3）根據規格說明的每個輸出條件，使用前面的原則1。

（4）根據規格說明的每個輸出條件，使用前面的原則2。

（5）如果程序的輸入或輸出是一個有序集合，則應選取集合的第一個元素和最后一個元素設計測試用例。

（6）如果程序中使用了一個內部數據結構，應當選擇這個內部數據結構邊界上的值設計測試用例。

（7）分析規格說明書，找出其他可能的邊界條件。

三、因果圖法

因果圖法是一種適合于描述對于多種條件的組合、相應產生多個動作的形式的測試用例設計方法。

利用因果圖生成測試用例的步驟為：

（1）將規范說明書分解成可執行的片段。

（2）確定規格說明書中的因果關系。分析軟件規格說明描述中那些是原因，那些是結果，并給每個原因和結果賦予一個標識符。

（3）分析軟件規格說明描述的語義，找出原因和結果之間、原因和原因之間的關系，并將其轉換成因果圖。

（4）在因果圖上加上注解符號，用一些記號表明約束或限制條件。

（5）跟蹤圖中的狀態變化情況，把因果圖轉換為判定表。

（6）把判定表的每一列拿出來作為依據，設計測試用例。

四、錯誤推測法

錯誤推測法就是根據經驗和直覺推測程序中所有可能存在的各種錯誤，從而有針對性地設計測試用例的方法。

錯誤推測法的基本思路是列舉出程序中所有可能有的錯誤和容易發生錯誤的清單，根據清單設計測試用例；另一個思路就是在閱讀規格說明時有哪些容易被程序員忽略的內容來設計測試用例。

錯誤推測法是一種非常有效的測試用例設計方法，這要求測試人員有豐富的測試經驗和對業務的處理非常熟悉。比如，在短信發送的時候，如果發送短信之后，對方網關沒有響應或者超時響應或者沒有回復狀態報告，那程序怎樣處理呢？

進階參考：

測試用例設計

http://www.cnblogs.com/mayingbao/category/82529.html

如何編寫有效測試用例

http://blog.csdn.net/smilings/article/details/840917

２。２執行功能測試

根據測試計劃和測試用例進行測試，在測試過程中記錄測試結果和提交發現的Bug。下班前將當天的測試情況匯報給測試組長或測試經理。

２。３提交Bug

２。２.１Bug基本概念

１）BUG的定義

BUG：（小錯誤，缺陷，不足，過失 …） 一個計算機bug指在計算機程序中存在的一個錯誤（error）、缺陷（flaw）、疏忽（mistake）或者故障（fault），這些bug使程序無法正確的運行。Bug產生于程序的源代碼或者程序設計階段的疏忽或者錯誤。

Defect：（缺陷） 在軟件工程（Software Engineering）中，軟件與它的需求（requirements）不一致，常常指軟件無法正確完成需求所要求的功能，也稱之為bug。

２）BUG分級－嚴重性

我們一般把發現的錯誤（Bug）/缺陷（Defect）按嚴重性分為4類：

1.嚴重：系統崩潰或掛起等導致系統不能繼續運行；

2.主要：使系統不穩定、或破壞數據、或產生錯誤結果，而且是常規操作中經常發生或非常規操作中不可避免的主要問題；

3.次要：系統性能或響應時間變慢、產生錯誤的中間結果但不影響最終結果等影響有限的問題，如：顯示不正確但輸出正確；

4.輕微：界面拼寫錯誤或用戶使用不方便等小問題或需要完善的問題；

３）BUG分級－優先級

我們也把發現的錯誤按優先級分為三種：

1.高：立即修改；

2.中：必須修改，但不一定馬上修改；

3.低：允許不修改；

一般來說是越影響用戶接受或使用該產品的錯誤優先級越高。

２。２.２怎樣提交Bug

首先，確保你所發現的問題是確實是一個bug，不要出現因為測試人員操作錯誤或配置錯誤所引起的“bug”，這樣會降低你在開發人員心中的可信度。在測試的時候，如果發現測試的實際結果與預期測試結果不符時，不要著急馬上報bug，先想想為什么會出現錯誤。作為專業的測試人員，應該能夠對出現的問題進行跟蹤，確認了在配置、操作沒有錯誤的前提下，通過追蹤分析確認所測試的業務流程確實是存在bug，并能大概對bug的產生原因進行定位。測試人員，需要做到專業，盡量少給開發找麻煩，不要制造實際上并不存在的bug。

確認了所發現的問題是一個bug之后，按照測試步驟再執行一次，確保bug是可重現的而不是隨機的。如果bug不能重現，應該盡量找到bug重現的規律，在一些比較難重現的問題可以找開發配合一起查找原因，如果還是無法重現則需要在bug report中對出現的問題描述清楚并說明出現的隨機性。

接下來就是填寫bug report了，在填寫bug report的時候，最重要的是bug的標題和bug描述。在bug報告中，首先用一句話對bug進行簡要精確的描述作為bug的標題，讓開發或項目經理一看就知道存在什么問題，比如“XX模塊在壓力測試2小時后出現內存泄露”。而在bug的描述中，需要使用簡明準確的語言描寫出現bug的測試步驟、實際的測試結果、預期的測試結果和結論；也就是說描述導致出現bug的操作步驟是怎樣，由測試步驟所做的操作引起的測試結果是什么，而預期的結果應該是怎樣，并由實際結果與預期結果相對比說明問題所在。比如：“在管理網頁新增用戶，當新增的用戶登錄名名稱很長（例如登錄名長度為輸入框允許的最大長度），按‘新增’按紐新增后系統提示已經有該用戶存在，而事實上該用戶并不存在，建議對超長的用戶名進行處理。”

在測試人員發現了一個已隔離的，可重現的問題后，應該對問題進行歸納。同一個問題是否出現在其他的模塊或其他的流程？同一個故障是否會引起更加嚴重的問題？如果存在，也需要提出來讓開發一并處理。

在開發對bug進行修改之后，測試需要報著懷疑的態度認真地對問題進行驗證，需要嚴格按照測試步驟來進行測試，檢查開發是否已經正確修改了所出現的問題，以及開發對bug進行了修復之后是否會引進新的問題。不要相信開發說“已經修改好了，肯定沒問題了”就不對問題進行細致的檢查了，如果開發修改得不徹底，問題仍然會存在的，或者可能會由于開發在修改bug的時候忽略了另一些細節導致了新bug的出現。盡量不要在關閉bug之后，才發現這個問題還沒有修改徹底；也不要出現bug關閉之后，出現了新的bug。

測試對bug進行驗證確認已經修改ok之后，關閉bug。在關閉的時候，應該對Bug最終修改結果進行簡要描述，如果bug的修改引起配置或數據庫或業務流程的變更，也需要在bug關閉描述中進行說明。

進階參考：

如何編寫有效bug報告

http://blog.csdn.net/smilings/article/details/840840

準確報告軟件缺陷

http://blog.csdn.net/kerryzhu/article/details/1436398

２。３編寫功能測試報告

測試報告是測試人員在測試過程中用于反映測試狀況的文檔。其實測試報告的內容基本都是模板的那些，只是在實際測試過程中，如何去整理內容結構，使得報告的通常閱讀者：開發人員、測試經理、產品經理、項目負責人能夠一目了然地查看想要了解的內容才是測試報告最值得注意的地方。

產品要想有廣闊的市場，得需要切實了解用戶的需求及感受，同理測試報告要想能夠讓閱讀者能夠滿意，也需要能將質量情況條理性地列出。通常來說，開發人員往往希望能從報告中了解缺陷的情況，而測試經理還關心用例的執行情況及覆蓋率、項目責任人則最關心還有多少問題，此次版本是否測試通過。因此測試報告根據內容的側重點，分為『版本測試報告』和『總結測試報告』，目的也是希望不將所有內容列舉在一個報告中，造成內容臃腫繁雜。

總體來說，功能測試報告的編寫就是要做到簡約而不簡單。

版本測試報告

ü 主要反映開發人員提交的測試版本的質量狀況。

ü 測試用例設計與執行、缺陷概況及問題概要是版本測試報告中的主要內容。

ü 測試人員在每個輪次測試結束時編寫提交。

其內容結構和每個章節的編寫內容說明如下：

大綱

子章節

詳細內容

測試簡介

測試目的

本次測試的背景及主要內容

測試資源

測試人員、本次測試開始和截止日期、花費工作日

測試環境

硬件環境

實際情況的詳細列舉，過低的配置、軟件版本的不匹配、網絡拓撲的錯誤都會讓提交的缺陷缺乏說服力，也會讓開發人員對于某些缺陷是否由于環境因素導致而產生疑惑。

軟件版本

網絡拓撲圖

測試方法

無

本次測試的功能點、各功能點對應的測試用例設計、測試用到的測試工具

測試用例

用例分析

測試用例維護記錄

用例執行情況

用例執行總數、通過用例數、未通過用例數、阻塞用例數

測試執行率=（已執行的用例數）/用例總數

測試用例效率=發現的缺陷總數/測試用例的數量

測試過程

缺陷統計

新建bug數、修復bug數、未修復bug數、bug總數

問題摘要

遺留問題、拒絕問題、掛起問題、長期驗證問題、待評估問題

測試結果

資源占用

測試項目的啟動、退出時間

測試項目的CPU占用率初始值、峰值（如果項目啟動會有多個進程，則分多個進程進行統計）

測試項目的內存占用初始值、峰值

測試結論

測試結論不論僅僅只是測試通過或不通過，應該使用詳細的數據來支持測試結論，需要列舉的數據有：

『測試用例通過率』

總用例

未通過用例

未通過比率

『遺留bug情況』

總bug數

未修復bug

遺留bug率

備注

用例執行記錄

插入測試用例的詳細執行結果文檔

資源監控記錄

說明資源占用監控的場景，詳細列舉各場景的監控時長、監控內容，場景操作

總結測試報告

ü 主要偏重于各已測試版本的缺陷變化分析，風險預估。

ü 各測試版本質量情況概況統計、缺陷分布統計、風險分析是總結測試報告中的主要內容。

ü 測試人員在項目發布上線前編寫提交。

其內容結構和每個章節的編寫內容進行說明如下：

標題

子章節

詳細內容

測試簡介

測試目的

本次測試的背景及主要內容

測試資源

測試人員、第一輪測試的開始日期和最后一輪測試的截止日期、總共花費工作日統計

測試環境

硬件環境

實際情況的詳細列舉，過低的配置、軟件版本的不匹配、網絡拓撲的錯誤都會讓提交的缺陷缺乏說服力，也會讓開發人員對于某些缺陷是否由于環境因素導致而產生疑惑。

軟件版本

網絡拓撲圖

測試過程

各版本測試狀況

各測試版本的計劃提交日期、實際提交日期、測試類型（回歸或全量）、測試耗時、備注（被打回或提交補丁次數）

各版本bug統計

各測試版本的新建bug數、修復bug數、遺留bug數，表格統計、線形圖或餅狀圖輔助表示

測試分析

缺陷分析

缺陷的總體分布情況，以線形圖或餅狀圖輔助表示

2 根據功能模塊進行劃分

2 根據嚴重、較嚴重、普通、輕微級別進行劃分

遺留問題

打開狀態bug、長期驗證bug、用戶體驗問題

測試小結

資源占用

測試項目的啟動、退出時間

測試項目的CPU占用率初始值、峰值（如果項目啟動會有多個進程，則分多個進程進行統計）

測試項目的內存占用初始值、峰值

風險分析

測試進度、人員安排導致的風險

測試內容考慮范圍之外導致的風險

測試環境不全面導致的風險

其他因素導致的風險

進階參考：

軟件測試階段報告編寫指南

http://blog.csdn.net/smilings/article/details/1032221

軟件測試報告編寫指南

http://blog.csdn.net/smilings/article/details/1032246

３。測試牛人Randall W.Rice給測試新手的話

前言

因為已經帶領和訓練測試團隊多年，所以按慣例我總有些東西確定需要傳達給測試新手。不管你是一個測試新手還是一個經驗豐富的測試專家，都有不少有益的東西需要牢記在心。

1、你是一個檢查者，你不需要為質量負責

很多測試人員誤入歧途，不明白他們是評測產品的而不是控制產品的。這兩者之間有著天壤之別。例如，一個測試團隊花費好幾周時間測試并發現很多缺陷，只是為了看著管理層決定發布一個有已知嚴重缺陷的產品。測試團隊經常會感到士氣受挫，置疑他們測試的目的。

我詢問團隊中的成員他們是否被支付薪水了，通常得到的回答都是“是”。我又詢問他們是否盡力去做工作了，再一次，通常得到的回答都是“是”。我于是告訴他們，“你們做了你們的工作。你們盡力測試，發現了缺陷并進行了上報。那么現在可以回家休息了。實際上，作為一名測試人員唯一失敗的地方是不上報一個已知的缺陷。”

這不會提高士氣，但卻有助于事情向正確的方向發展，特別是能讓人不用每天晚上都在家接著辦公。

很多測試人員，包括我，當我們剛開始測試工作時，似乎會覺得自己對我們所測試的系統應用的質量負責。盡管這個工作的出發點是讓人欽佩的，可實際上我們測試人員對于產品的質量基本沒有控制能力。也是由于這個原因，測試人員不為質量負責。現在問題是管理層并不總是能看到這種區別。所以經常看見管理層提出類似于“我們付錢給這些人不是為了獲得高質量的軟件嗎？”的問題。

2、缺陷都是有價值的

每一個缺陷都是深入了解和提高的機會。我們可能只有一次機會觀察到一個缺陷，所以我總是告訴測試人員始終保持高度注意力，不要為測試的乏味所折磨。

缺陷信息可能是可獲取的項目數據中最有效的資源之一。但是這都取決于我們能多好的捕捉和傳達我們所發現的缺陷的相關信息。

每個缺陷都會花費整個組織的金錢。如果我們不能從中更進一步了解產品，我們會浪費大量時間和金錢。當我們把一個錯誤轉換成一次深入了解的機會時杠桿作用就出現了。讓我們面對它――有些教訓只能通過經歷來學習的。

由于一個缺陷而責備誰不會有任何好的作用。責備只會讓士氣低落、溝通中斷。這就像不斷鞭打一匹死馬希望它能活過來一樣。

3、你報告第一個問題之前一切都是美好的

這就是一個測試人員所面對的現實。你可以計劃測試，獲取所需要的資源，看起來所有人都站在你這邊。可當你報告第一個問題之后，事情就開始變得緊張了。

出現這種態度上的突然變化的原因是現在你在批評某些人的工作了。自尊心使得自我收到傷害，關系變得緊張。有些情況下自尊心是值得期盼的，只要知道當你開始發現問題的時候態度有可能變化就可以了。

我經常建議測試人員做的一件事是讀一讀一些你過去寫的缺陷報告，假設自己是接收缺陷報告的人。你會發現自己需要更老練一些。寫一個沒有任何挖苦語句的缺陷報告可能沒什么樂趣，但它的確有助于和開發人員之間保持一個好的關系。

4、只能測試你能觀察的

你可能總想測試一些真正有創造性的用例，但如果你沒有辦法觀察到結果，那有什么意義？盡管有些應用讓你能觀察到很多，但仍然有你沒辦法接近的，例如結構、隱藏的對象、后臺進程等。

5、別忘記你是怎樣到一個地方的

我不是在談論知道為什么你走進一個房間，而是在測試時執行的步驟。對于測試新手常見的是發現了一個重大的缺陷，但卻無法復現它以便定位解決。這樣你只會覺得不舒服，不知道自己到底是真發現了一個缺陷，還是說僅僅是錯誤的使用了應用。

你能用來跟蹤你的測試步驟的方法有測試腳本、測試記錄、敲鍵記錄器如Spector和屏幕視頻捕捉工具如Hypercam。

6、標準和流程是你的朋友

盡管標準和流程讓一些人覺得受限，但它們為你的工作提供了有價值的指導。不要拒絕標準因為它們是詳細的、具體的。因此用它們指導自己更快、更一致的完成自己的工作。

7、沒有足夠的時間用于測試

幾乎每一個測試人員都抱怨沒有足夠的時間用于測試，但實際情況是測試任何東西到完整的程度都是不可能有充足時間的。當你充分考慮軟件的特性如可用性、安全性、兼容性、互操作性等時這一點尤其正確。

不要再抱怨缺少時間，學會根據風險來進行優先級排序，把注意力都放在對管理層很重要的應用目標上。有時候我們測試的內容超出了我們需要測試的，因為我們的目標偏離了產品的價值。

8、你不可能發現所有的缺陷

如果你測試的東西后來有缺陷被發現，不要變得氣餒。你可能已經做了非常全面的工作，獲得了高水平的缺陷移除，但100%都是不可能的目標。

9、保持幽默感和對前景充滿信心

經常微笑、保持健康可能是你最好的生存方式。如果你正處在困難條件下，請相信，這一切都將過去。

10、爭取做到最好而不是完美

測試新手經常會陷入追求完美的過程中，認為100%的正確才是標準。我曾經也是受害者之一，但要為自己辯護的是，我以前深受80年代后期類似于“99.9%還不夠好”的TQM帖子和文章的影響。

追求完美的問題在于它會讓測試進程變慢，將擔心引入你所做的一切，使得你對別人更挑剔，而且通常會讓你的朋友和家人感到失望。

當然，沒人愿意犯錯誤，但他們稍不注意就出現了。想不犯錯誤就是否認現實。爭取做到最好是一種好的習慣，表明你對工作的態度和投入程度。如果你想努力做到最好，你就會往前再多走一點。

根據我的觀察，大多數人看到錯誤或者經歷失誤時都是很寬容的。人們最關心的是你對待問題的反應。

11、開發人員不是敵人

需要整個項目團隊的努力才能遞交高質量的產品。有時候似乎開發人員不太關心質量，這個時候事情背后可能存在隱情。這時候你需要更好的和開發人員合作而不是反對他們。要始終牢記良好的交流是一個項目成功的關鍵因素。當你和開發人員站到對立面時，交流就停止了，你測試所需的很多信息也無法獲取了。

12、建立和維護一個私人的交際網

你的私人工作關系是一個很重要的資產。無論時當你有工作時還是當你沒工作時他們都是一個很好的支持系統。找一個好的指導者，而當你學到足夠的東西時成為別人的指導者。

13、持續鍛煉自己的技能

你的技能把你和別人區分開。始終通過參加專業會議、獲取認證、閱讀專業資料等來不斷學習。我給自己制定的目標是每周至少讀一本和個人發展以及職業發展相關的書（測試、領導藝術、商業、IT等）。

一個個人發展方面的專家說過如果你每天在任何特定的主題上花費30分鐘進行閱讀，五年之內你肯定能成為這個主題方面的專家。這一點對我是起作用的――你也可以試試。

另一種讓自己始終內行并建立網絡的好的方式是活躍在一些QA或者測試論壇上。

14、當前進變得困難，懶惰就需要創造力了

當我第一次成為一個測試團隊負責人時，我用這句話做了一個字條掛在我的桌上。它不斷提醒我把創造力作為我解決問題的一個杠桿。

學著從一個新的有創造性的方式來看待問題。你可能有一個好的測試計劃，但你如何應付各種變化呢？彈性是一個優秀的問題解決負責人的關鍵特性。

15、簡單并不總是很容易

我們測試中做的很多工作看起來都很簡單。但是，挑戰在于保持努力的連貫性。

有些解決問題的方式剛開始看起來很簡單，但不要由于它簡單和明顯就丟棄任何一種想法。同樣，不要低估實現一個簡單想法所需要付出的努力。

一些看過我和William E.Perry合著的書“Surviving the Top Ten Challenges of Software Testing”評論說這些挑戰都很簡單且很容易解決。這就讓我奇怪為什么人們還在年復一年的提出“人的問題”。我認為在大腦中產生想法比實際實現出來要簡單的多。

結論

智慧比知識更重要。你可能已經學習了大量測試技術，但如果你沒有足夠的智慧判斷什么時候采用它們，沒有從整體上理解它們，你應用它們的能力將受到很大限制。對任何都有涉獵的你存在的一個問題是“你不知道什么你不知道”。智慧幫助你明白你需要知道哪些東西才能成功。

４。軟件測試工作求職

４。１測試人員面試時常見問題及問題背后的考核內容分析

1）你最近3-5年的職業規劃是什么？

重點考察測試人員的職業發展方向是否與當前職位招聘相符？ 從其中可以側面看出來其員工穩定性。

2）一個項目測試結束，有沒什么經驗總結？如果有，具體是如何開展的？

重點考察測試人員對自己能力提升方面，有沒有提高總結的地方，從項目中吸取的經驗與教訓。從中可以看出來，測試人員是否屬行自我驅動型人才！

3）為什么會選擇做測試這份工作？

重點考察測試人員對待測試工作的態度及是否有發展潛力？面試過很多測試人員，經常見到的回答，自己是女孩子，做測試細心，各位你認為這樣回答你會滿意嗎？其碼不是我想要的答案！

4）請說出一個你以前參與項目，對你測試經驗提升很高的，具體是哪方面？

重點考察測試人員在以往的測試工作中能力提升方面，有哪些？然后重點詢問此部分內容，是否測試經驗增長，具備一定的深度？

5）通常做測試時會碰到，提交的某個bug開發人員不認同你的觀點？這時你如何辦？

重點考察測試人員是否堅持自已的價值觀？是否具備協調溝通處理問題能力？

6）有沒有看過什么測試書，具體是哪本？帶給你的收獲是？

重點考察測試人員是否為測試這個職業肯付出多少？從中也可以看出這個測試人員是否上進心？是否有求知心？我的定義是如果哪個應聘者來面試時，都沒系統的看過一本測試書籍，基本上不會錄取！

7）如果安排一項測試技術研究工作，你如何應對？

重點考察測試人員是否具體測試技術專研精神？是否喜歡接受挑戰？是否屬于以后培養骨干對象？

8）某個項目上線后，出現問題，恰巧你是負責的，你如何應對這突如其來的事件？

重點考察測試人員應對問題的壓力，責任感，及如何處理項目上線后的技術問題及應對解決能力。

9）周末放假有什么業余愛好？

重點考察面試測試人員性格特質，測試工作本身就是復雜且富有技術性的工作，而且不同的職位所需要的測試人員性格品質差異性很大。

10）公司產品，具體應用什么編程技術？具體的架構是？具體的應用場景有哪些？

重點考察測試人員對以往的工作所負責的產品測試，是否具備一定的深度！通常我都是讓面試者自己講述或是在紙上畫出具體系統架構的圖！

11）公司測試團隊的規模如何，具體你所處的角色是什么？

重點考察測試人員在以往的公司測試團隊中，具體的工作職責，評判其工作是否與當要求職位是否符合？是否有哪些優缺點？

12）特定測試技術考察：性能測試，安全性測試，自動化測試等以前有開展過沒？如果有，具體是如何實施的？

重點考察測試人員技術能力，是否在各方面都有所涉及？或是在各方面技術上都有一定深度？當然從中也能看出一個測試人員是否屬于是技術路線發展方向！

13）你自己所期待加入的測試團隊是什么樣的？

重點考察測試人員在以前測試團隊中有哪些不協調？當然最重要的是也能提供給你一些信息，這個員工以后如何更好的管理與溝通！

５。軟件測試職業發展

1）技術方向

在技術方向上面，通常是初級測試工程師，中級測試工程師，高級測試工程師，資深測試工程師，專家等方向發展；當然像國外技術分工比較細如：通常有白盒測試，黑盒測試，自動化測試，性能測試，安全測試，易用性測試等。

2）管理方向

在管理方向上面，通常是測試組長，測試主管，測試經理，測試總監等方向發展。

3）業務領域方向

在業務領域則取決于各測試人員所處行業，通常像金融，銀行，證券，ERP類的，通常有初級業務測試，中級業務測試，高級業務測試等。

４）其他方向

配置管理、質量保證（QA）等