1、目標
　　制定完整且具體的測試路線和流程，為快速、高效和高質量的軟體測試提供基礎流程框架。
　　最終目標是實現軟體測試規範化，標準化。
　　2、測試流程說明

　　3、測試需求分析
　　測試需求是整個測試過程的基礎；確定測試物件以及測試工作的範圍和作用。用來確定整個測試工作（如安排時間表、測試設計等）並作為測試覆蓋的基礎。而且被確定的測試需求項必須是可核實的。即，它們必須有一個可觀察、可評測的結果。無法核實的需求不是測試需求。所以我現在的理解是測試需求是一個比較大的概念，它是在整個測試計劃文件中體現出來的，不是類似的一個用例或者其他.
　　·測試需求是制訂測試計劃的基本依據，確定了測試需求能夠為測試計劃提供客觀依據；
　　·測試需求是設計測試用例的指導，確定了要測什麼、測哪些方面後才能有針對性的設計測試用例；
　　·測試需求是計算測試覆蓋的分母，沒有測試需求就無法有效地進行測試覆蓋；
　　3.1、測試方法與規範
　　3.1.1、測試方法
　　隨著軟體技術發展，專案型別越來越多樣化。根據專案型別應選用針對性強的測試方法，合適的測試方法可以讓我們事半功倍。以下是針對目前專案工程可以參考的測試方法：
　　--β測試（beta測試）--非程式設計師、測試人員
　　β測試，英文是Betatesting。又稱Beta測試，使用者驗收測試（UAT）。
　　β測試是軟體的多個使用者在一個或多個使用者的實際使用環境下進行的測試。開發者通常不在測試現場，Beta測試不能由程式設計師或測試員完成。
　　當開發和測試根本完成時所做的測試，而最終的錯誤和問題需要在最終發行前找到。這種測試一般由終端使用者或其他人員完成，不能由程式設計師或測試員完成。
　　--α測試（Alpha測試）--非程式設計師、測試人員
　　α測試，英文是Alphatesting。又稱Alpha測試.
　　Alpha測試是由一個使用者在開發環境下進行的測試，也可以是公司內部的使用者在模擬實際操作環境下進行的受控測試，Alpha測試不能由該系統的程式設計師或測試員完成。
　　在系統開發接近完成時對應用系統的測試；測試後，仍然會有少量的設計變更。這種測試一般由終端使用者或其他人員來完成，不能由程式設計師或測試員完成。
　　--相容性測試--測試人員
　　相容性測試是指測試軟體是否可以成功移植到指定的硬體或者軟體環境中，例如在B/S專案中各個不同瀏覽器之間的測試。
　　--使用者介面測試-UI測試 --測試人員
　　使用者介面測試，英文是User interface testing。又稱UI測試。
　　使用者介面，英文是User interface。是指軟體中的可見外觀及其底層與使用者互動的部分（選單、對話方塊、視窗和其它控制元件）。
　　使用者介面測試是指測試使用者介面的風格是否滿足客戶要求，文字是否正確，頁面是否美觀，文字，圖 片組合是否完美，操作是否友好等等。UI 測試的目標是確保使用者介面會通過測試物件的功能來為使用者提供相應的訪問或瀏覽功能。確保使用者介面符合公司或行業的標準。包括使用者友好性、人性化、易操作性 測試。
　　使用者介面測試使用者分析軟體使用者介面的設計是否合乎使用者期望或要求。它常常包括選單，對話方塊及對 話框上所有按鈕，文字，出錯提示，幫助資訊 (Menu 和Help content)等方面的測試。比如，測試Microsoft Excel中插入符號功能所用的對話方塊的大小，所有按鈕是否對齊，字串字型大小，出錯資訊內容和字型大小，工具欄位置/圖示等等。
　　--冒煙測試--版本編譯者
　　冒煙測試，英文是Smoketesting。
　　冒煙測試的名稱可以理解為該種測試耗時短，僅用一袋煙功夫足夠了。也有人認為是形象地類比新電路板功基本功能檢查。任何新電路板焊好後，先通電檢查，如果存在設計缺陷，電路板可能會短路，板子冒煙了。
　　冒煙測試的物件是每一個新編譯的需要正式測試的軟體版本，目的是確認軟體基本功能正常，可以進行後續的正式測試工作。冒煙測試的執行者是版本編譯人員。
　　--隨機測試--測試人員
　　隨機測試，英文是Adhoctesting。
　　隨機測試沒有書面測試用例、記錄期望結果、檢查列表、指令碼或指令的測試。主要是根據測試者的經驗對軟體進行功能和效能抽查。隨機測試是根據測試說明書執行用例測試的重要補充手段，是保證測試覆蓋完整性的有效方式和過程。
　　隨機測試主要是對被測軟體的一些重要功能進行復測，也包括測試那些當前的測試樣例(TestCase)沒有覆蓋到的部分。另外，對於軟體更新和新增加的功能要重點測試。重點對一些特殊點情況點、特殊的使用環境、併發性、進行檢查。尤其對以前測試發現的重大Bug，進行再次測試，可以結合迴歸測試(Regressivetesting)一起進行。
　　--黑盒測試（功能測試）--測試人員
　　黑盒測試，英文是BlackBoxTesting。又稱功能測試或者資料驅動測試。
　　黑盒測試是根據軟體的規格對軟體進行的測試，這類測試不考慮軟體內部的運作原理，因此軟體對使用者來說就像一個黑盒子。
　　軟體測試人員以使用者的角度，通過各種輸入和觀察軟體的各種輸出結果來發現軟體存在的缺陷，而不關心程式具體如何實現的一種軟體測試方法。
　　--效能測試
　　效能測試，英文是PerformanceTesting。
　　效能測試是在交替進行負荷和強迫測試時常用的術語。理想的"效能測試"(和其他型別的測試)應在需求文件或質量保證、測試計劃中定義。效能測試一般包括負載測試和壓力測試。
　　通常驗證軟體的效能在正常環境和系統條件下重複使用是否還能滿足效能指標。或者執行同樣任務時新版本不比舊版本慢。一般還檢查系統記憶容量在執行程式時會不會流失(memoryleak)。比如，驗證程式儲存一個巨大的檔案新版本不比舊版本慢。
　　3.1.2、測試規範
　　測試規範是根據開發規範而制定的測試標準，測試規範也是後期測試用例編寫的重要依據。因為開發規範因公司而異，因產品而異，所以測試規範的標準程度每個公司都不一樣。
　　從理論到方法到各類流程到各類報告模版，都屬於測試規範的範疇，當一整套規範形成之後，可使得測試工作進行更加穩健，所有問題有據可查。
　　3.2、軟體需求規格說明書
　　軟體需求規格說明書是軟體達到的各項功能的目標。是測試人員各項工作的依據，沒有需求就無法判斷測試結果是正確的。
　　3.3、軟體設計說明（概要與詳細設計）
　　設計說明書包含軟體的一些框架、欄位、資料庫設計等。軟體設計說明對測試工作開展有很大影響，沒有軟體設計說明很多問題將無法溯源，測試準備的前期工作也是根據軟體設計說明來制定的。
　　3.4、頁面原型（demo）
　　頁面原型是專案人員快速熟悉專案的最佳路徑。在需求不夠明確，設計說明書不夠全面的情況下，頁面原型也是後期測試用例編寫思想的重要根據。
　　4、測試過程設計
　　明確測試目的，最終達成目的並驗證結果是測試要做的事情。包括：
　　1.測試範圍：描述本次測試中的測試範圍，如：測試軟體功能範圍、測試種類等。
　　2.簡單的描述如何搭建測試平臺以及測試的潛在的風險。
　　3.專案資訊：說明要測試的專案的相關資料，如：輸入輸出文件，產品描述，軟體主要功能。
　　4.人力資源的分配。
　　5.測試需求：籠統說，就是測試中的所有設計和需求文件。作為本次測試的依據
　　4.1、測試策略制定
　　這一階段在於需求、詳細設計、測試計劃完成之後，主要是本次測試的策略階段。很多公司少這個一個階段，需要有計劃性的分出產品的功能扣出測試的功能點，現階段大多公司都是直接拿著文件就開始做用例設計。
　　對需求進行分析，列出具體的功能列表。（一般根據功能互動文件就能明確出此功能的大體功能，一層層的分下去，一直到沒個功能表單。然後考慮到使用那些測試方法？工作一旦做到執行階段，我們可以更好的根據這些功能表一點一點的覆蓋。也能讓我們在用例評審時，充分的證實我們的工作是有效的能夠保證產品的質量。）一般在此之前，一些業務培訓和需求評審是有必要是聽一下的。這樣能夠更早更熟練的理解需求，也能保證產品設計中出現的一些誤區。
　　對於一個個測試該如何進行測試？如下：
　　a)功能測試
　　---功能範圍（劃分出各自負責的功能模組）
　　---使用測試方法（等價類、邊界值等測試方法方法）
　　---測試標準（符合設計、需求和規範文件對該功能的描述）
　　b)介面測試
　　c)相容性測試
　　4.2、測試計劃
　　1)要充分考慮測試計劃的實用性，即測試計劃與實際之間的接近程度和可操作性。編寫測試計劃的目的在於充分考慮執行測試時的各種資源，包括測試內容、測試標準、時間資源、人力資源等等，準確地說是要分析執行時所能夠呼叫的一切資源以及受各種條件限制，可能受到的各種影響。
　　a)測試內容：對一個軟體來說測試計劃中會明確本次測試做哪些測試？
　　如：系統測試：在整個系統測試中會有（介面測試、功能測試、效能測試、兼
　　容性測試、安裝解除安裝測試、可靠性測試等測試）。
　　b)測試目的：一般多為保證產品質量是否達到預期的指標。這個指標也就是在測試中定義的結束標準。
　　c)測試標準：需要考慮本次測試需要輸入那些文件，該專案結束標準定義、測試結束標準的定義？bug級別定義、優先順序定義、bug管理流程定義。這個都需要在執行測試事明確。計劃中應該包含這些內容。
　　d)資源分配：這裡分為人力資源、軟硬體資源等劃分。一般會把人力資源的利用寫入一個測試人員任務分配表裡，按照不同的階段，每個階段提交相應的成果（難度很大）。軟硬體資源中主要是在做計劃時考慮到需要多少電腦或別的工具，列出清單。
　　e)測試風險：大多考慮到的就是專案開發延期、測試人員不足用例無法全面覆蓋測試點、時間不足用例無法全部執行、bug無法及時修改導致無法驗證、測試人員技能不足導致測試進度拉長。
　　f)軟體測試策略一般都是分開來做相關測試方案。
　　4.3、測試附件
　　用例模板、缺陷報告模板
　　測試環境的搭建
　　缺陷管理流程和缺陷級別定義
　　缺陷狀態一般分為：新建、開啟、已分配、已修復、關閉、重新開啟，中間會有：延期、重複、拒絕等狀態
缺陷管理流程：
　　1.測試人員或開發人員發現bug後，判斷輸入哪個模組的問題，填寫bug報告後，系統會自動通過Email通知開發組長和該模組開發者。
　　2.開發組長根據具體情況，重新reassigned分配給bug所屬的開發者。
　　3.開發者收到email資訊後，判斷是否為自己的修改範圍。
　　若不是，重新reassigned分配給開發組長或應該分配的開發者。
　　若是，進行處理，resolved並給出解決方法。（可建立補丁附件及補充說明）
　　4.測試人員查詢開發者已修改的bug，進行迴歸測試。
　　經驗證無誤後，修改狀態為verified。待整個產品釋出後，修改為closed。
　　還有問題，reopened，狀態重新變為"new"，併發送郵件通知。
　　5.如果這個bug一週內一致沒被處理過。Bugzilla就會一直用email騷擾它的屬主，直接採取行動。管理員可以設定最遲採取行動的期限，比如3天，系統預設7天。
　　5、測試實施
　　5.1、執行
　　開發就會轉版本給我們測試部門進行系統測試了。拿到版本我們首先搭建測試環境
　　做一個預測試，目的是來評斷這個版本是不是可測試的。如果預測試不通過，打回開發部返工，如果通過了，就開始我們第一輪的系統測試。
　　第一輪系統測試我們會執行我們所編寫的所有測試用例，做好測試結果的記錄，發現缺陷了提交缺陷報告。當第一輪測試結束後，我們把所有的bug單提交給開發人員，由他們進行修改。
　　在他們修復bug期間，我們會對第一輪系統測試做一個測試評估，出一個測試報告。還要根據實際情況，對我們寫的測試用例進行修改和增加。開發改bug結束，提交一個新的版本給我們，我們重新搭建測試環境開始第二輪系統測試。首先是迴歸我們提交的缺陷報告，然後會在用例中挑選一些優先級別比較高的用例來進行測試，發現問題了繼續提交缺陷報告，只到缺陷率低於使用者要求了，我們就進行最後一輪的迴歸測試，結束系統測試。具體測試輪次是根據版本質量和專案複雜度而決定的。
　　6、測試評估
　　---執行階段結束了進入測試評估階段，我們會出一個總的測試報告對我們測試的這個過程和版本的質量做一個詳細的評估
　　1)需求需要評審那些？
　　2)用例需要評審那些？
　　3)計劃應該評審那些？
　　4)缺陷評審那些？
　　5)bug評估？
　　測試總結報告文件的輸出：
　　1、可以讓具體的任務負責人對該本次測試中個人負責的模快進行評價，提出相關建議。給出總體的評估
　　2、整體上的bug按照不同等級統計出來、用例數量、用例執行數量
　　3、對專案中測試人力資源的統計。（單位：人/天）
　　4、專案中軟硬體資源統計。
　　5、提出軟體總體的評價。
　　6.1、測試報告
　　測試報告包括對軟體功能的結論，說明為滿足此項功能而設計的軟體能力以及經過一項或多項測試已證實的能力。
　　說明該專案軟體的開發是否達到預定目標，是否可以交付使用。
　　總結測試工作的資源消耗資料，如工作人員的水平級別數量、機時消耗等。
　　記錄測試結果與發現及本專案測試工作所得到的各項輸出的承載體，根據輸入與計劃、要求的對比來總結此次專案所或得的經驗.