1、軟件測試基本流程與要求（提綱）1目標制定完整且具體的測試路線和流程，為快速、高效和高質量的軟件測試提供基礎流程框架。最終目標是實現軟件測試規范化，標準化。2測試流程說明3測試需求分析測試需求是整個測試過程的基礎；確定測試對象以及測試工作的范圍和作 用。用來確定整個測試工作（如安排時間表、測試設計等）并作為測試覆蓋的基 礎。而且被確定的測試需求項必須是可核實的。即，它們必須有一個可觀察、可 評測的結果。無法核實的需求不是測試需求。所以我現在的理解是測試需求是一 個比較大的概念，它是在整個測試計劃文檔中體現出來的， 不是類似的一個用例 或者其他.測試需求是制訂測試計劃的基本依據，確定了測試需求能夠

2、為測試計劃提供客 觀依據；測試需求是設計測試用例的指導，確定了要測什么、測哪些方面后才能有針對 性的設計測試用例；測試需求是計算測試覆蓋的分母，沒有測試需求就無法有效地進行測試覆蓋；3.1測試方法與規范3.1.1測試方法隨著軟件技術發展，項目類型越來越多樣化。根據項目類型應選用針對性強 的測試方法，合適的測試方法可以讓我們事半功倍。 以下是針對目前項目工程可 以參考的測試方法：? B測試（beta測試）-非程序員、測試人員B測試，英文是Beta testing。又稱Beta測試，用戶驗收測試（UAT）。B測試是軟件的多個用戶在一個或多個用戶的實際使用環境下進行的測試。 開發者通常不在測試現場，

3、Beta測試不能由程序員或測試員完成。當開發和測試根本完成時所做的測試，而最終的錯誤和問題需要在最終發行 前找到。這種測試一般由最終用戶或其他人員完成，不能由程序員或測試員完成。 ? a測試（Alpha測試）-非程序員、測試人員a測試，英文是Alpha testing 。又稱Alpha測試.Alpha測試是由一個用戶在開發環境下進行的測試， 也可以是公司內部的用 戶在模擬實際操作環境下進行的受控測試，Alpha測試不能由該系統的程序員或 測試員完成。在系統開發接近完成時對應用系統的測試；測試后，仍然會有少量的設計變 更。這種測試一般由最終用戶或其他人員來完成，不能由程序員或測試員完成。 ? 兼

4、容性測試-測試人員兼容性測試是指測試軟件是否可以成功移植到指定的硬件或者軟件環境中， 例如在B/S項目中各個不同瀏覽器之間的測試。? 用戶界面測試-UI測試-測試人員用戶界面測試，英文是 User in terface testi ng 。又稱UI測試。用戶界面，英文是User in terface。是指軟件中的可見外觀及其底層與用戶 交互的部分(菜單、對話框、窗口和其它控件)。用戶界面測試是指測試用戶界面的風格是否滿足客戶要求，文字是否正確， 頁面是否美觀，文字，圖 片組合是否完美，操作是否友好等等。UI測試的目標 是確保用戶界面會通過測試對象的功能來為用戶提供相應的訪問或瀏覽功能。確保用戶

5、界面符合公司或行業的標準。包括用戶友好性、人性化、易操作性 測試。用戶界面測試用戶分析軟件用戶界面的設計是否合乎用戶期望或要求。它常常包括菜單，對話框及對 話框上所有按鈕，文字，出錯提示，幫助信息(Menu 和Help content) 等方面的測試。比如，測試 Microsoft Excel 中插入 符號功能所用的對話框的大小，所有按鈕是否對齊，字符串字體大小，出錯信息 內容和字體大小，工具欄位置/圖標等等。? 冒煙測試-版本編譯者冒煙測試，英文是Smoke testing 。冒煙測試的名稱可以理解為該種測試耗時短， 僅用一袋煙功夫足夠了。也有 人認為是形象地類比新電路板功基本功能檢查。 任

6、何新電路板焊好后，先通電檢 查，如果存在設計缺陷，電路板可能會短路，板子冒煙了。冒煙測試的對象是每一個新編譯的需要正式測試的軟件版本， 目的是確認軟 件基本功能正常，可以進行后續的正式測試工作。冒煙測試的執行者是版本編譯 人員。? 隨機測試-測試人員隨機測試，英文是Ad hoc testing 。隨機測試沒有書面測試用例、記錄期望結果、檢查列表、腳本或指令的測試。 主要是根據測試者的經驗對軟件進行功能和性能抽查。隨機測試是根據測試說明 書執行用例測試的重要補充手段，是保證測試覆蓋完整性的有效方式和過程。隨機測試主要是對被測軟件的一些重要功能進行復測，也包括測試那些當前 的測試樣例(TestCa

7、se)沒有覆蓋到的部分。另外，對于軟件更新和新增加的功 能要重點測試。重點對一些特殊點情況點、特殊的使用環境、并發性、進行檢查。 尤其對以前測試發現的重大Bug，進行再次測試，可以結合回歸測試 (Regressive testi ng) 起進行。? 黑盒測試(功能測試)-測試人員黑盒測試，英文是Black Box Testi ng。又稱功能測試或者數據驅動測試。黑盒測試是根據軟件的規格對軟件進行的測試，這類測試不考慮軟件內部的運作原理，因此軟件對用戶來說就像一個黑盒子。軟件測試人員以用戶的角度，通過各種輸入和觀察軟件的各種輸出結果來發 現軟件存在的缺陷，而不關心程序具體如何實現的一種軟件測試方

8、法。? 性能測試性能測試，英文是 Performa nee Testi ng 。性能測試是在交替進行負荷和強迫測試時常用的術語。理想的“性能測試” (和其他類型的測試)應在需求文檔或質量保證、測試計劃中定義。性能測試一般 包括負載測試和壓力測試。通常驗證軟件的性能在正常環境和系統條件下重復使用是否還能滿足 性能指標?；蛘邎绦型瑯尤蝿諘r新版本不比舊版本慢。一般還檢查系統記憶容量 在運行程序時會不會流失(memory leak)。比如，驗證程序保存一個巨大的文件 新版本不比舊版本慢。3.1.2測試規范測試規范是根據開發規范而制定的測試標準，測試規范也是后期測試用例編 寫的重要依據。因為開發規范因公

9、司而異，因產品而異，所以測試規范的標準程 度每個公司都不一樣。從理論到方法到各類流程到各類報告模版，都屬于測試規范的范疇，當一整 套規范形成之后，可使得測試工作進行更加穩健，所有問題有據可查。3.2軟件需求規格說明書軟件需求規格說明書是軟件達到的各項功能的目標。是測試人員各項工作的依據，沒有需求就無法判斷測試結果是正確的。3.3軟件設計說明（概要與詳細設計）設計說明書包含軟件的一些框架、 字段、數據庫設計等。軟件設計說明對測試工作開展 有很大影響，沒有軟件設計說明很多問題將無法溯源， 測試準備的前期工作也是根據軟件設 計說明來制定的。3.4頁面原型（demo ）頁面原型是項目人員快速熟悉項目的

10、最佳路徑。在需求不夠明確，設計說明書不夠全面的情況下，頁面原型也是后期測試用例編寫思想的重要根據。4測試過程設計明確測試目的，最終達成目的并驗證結果是測試要做的事情。包括：1. 測試范圍：描述本次測試中的測試范圍，如：測試軟件功能范圍、測試種類等。2. 簡單的描述如何搭建測試平臺以及測試的潛在的風險。3. 項目信息：說明要測試的項目的相關資料，如：輸入輸出文檔，產品描述，軟件主要功能。4. 人力資源的分配。5. 測試需求：籠統說，就是測試中的所有設計和需求文檔。作為本次測試的依據4.1測試策略制定這一階段在于需求、詳細設計、測試計劃完成之后，主要是本次測試的策略階段。很多公司少這個一個階段，需

11、要有計劃性的分出產品的功能扣出測試的功能點，現階段大多公司都是直接拿著文檔就開始做用例設計。對需求進行分析，列出具體的功能列表。（一般根據功能交互文檔就能明確出此功能的大體功能，一層層的分下去，一直到沒個功能表單。然后考慮到使用那些測試 方法？工作一旦做到執行階段，我們可以更好的根據這些功能表一點一點的覆蓋。也能讓我們在用例評審時， 充分的證實我們的工作是有效的能夠保證產品的質量。）一般在此之前，一些業務培訓和需求評審是有必要是聽一下的。這樣能夠更早更熟練的理解需求，也能保證產品設計中出現的一些誤區。對于一個個測試該如何進行測試？如下：a）功能測試? 功能范圍（劃分出各自負責的功能模塊）? 使

12、用測試方法（等價類、邊界值等測試方法方法）? 測試標準（符合設計、需求和規范文檔對該功能的描述）b）界面測試c）兼容性測試4.2測試計劃1）要充分考慮測試計劃的實用性，即測試計劃與實際之間的接近程度和可操作性。編寫測試計劃的目的在于充分考慮執行測試時的各種資源，包括測試內容、測試標準、時間資源、人力資源等等，準確地說是要分析執行時所能夠調用的一切資源以 及受各種條件限制，可能受到的各種影響。a）測試內容：對一個軟件來說測試計劃中會明確本次測試做哪些測試？女口：系統測試：在整個系統測試中會有（界面測試、功能測試、性能測試、兼 容性測試、安裝卸載測試、可靠性測試等測試）。b）測試目的：一般多為保證

13、產品質量是否達到預期的指標。這個指標也就是在測試中定義的結束標準。c）測試標準：需要考慮本次測試需要輸入那些文檔，該項目結束標準定義、 測試結束標準的定義？ bug級別定義、優先級定義、bug管理流程定義。這個都需要在執行測試事明確。計劃中應該包含這些內容。d）資源分配：這里分為人力資源、軟硬件資源等劃分。一般會把人力資源的利用寫入一個測試人員任務分配表里，按照不同的階段，每個階段提交相應的成果（難度很大）。軟硬件資源中主要是在做計劃時考慮到需要多少電腦或別的工 具，列出清單。e）測試風險：大多考慮到的就是項目開發延期、測試人員不足用例無法全面覆蓋測試點、時間不足用例無法全部執行、bug無法及

14、時修改導致無法驗證、測試人員技能不足導致測試進度拉長。f）軟件測試策略一般都是分開來做相關測試方案。4.3測試附件用例模板、缺陷報告模板測試環境的搭建缺陷管理流程和缺陷級別定義缺陷狀態一般分為：新建、打開、已分配、已修復、關閉、重新打開中間會有：延期、重復、拒絕等狀態缺陷管理流程：1. 測試人員或開發人員發現bug后，判斷輸入哪個模塊的問題，填寫bug報告后，系統會自動通過 Email通知開發組長和該模塊開發者。2. 開發組長根據具體情況，重新reassigned分配給bug所屬的開發者。3. 開發者收到email信息后，判斷是否為自己的修改范圍。若不是，重新reassigned 分配給開發組

15、長或應該分配的開發者。若是，進行處理，resolved并給出解決方法。（可創建補丁附件及補充說明）4. 測試人員查詢開發者已修改的bug，進行回歸測試。經驗證無誤后，修改狀態為verified。待整個產品發布后，修改為closed。還有問題，reopened ，狀態重新變為"new ”，并發送郵件通知。5. 如果這個bug 一周內一致沒被處理過。Bugzilla就會一直用email騷擾它的屬主，直接采取行動。管理員可以設定最遲采取行動的期限，比如3天，系統默認7天。缺陷等級劃分:分級Bug等級Bug等級說明分類說明導致整個產品無法進行O模塊無法啟動或異常退岀Blocker測試。修改優

16、先級為最高，該級別需要程序員立即修改O其它導致無法測試的錯誤致命問題死機，數據丟失，主要O運行過程中系統崩潰/死機/重啟功能完全喪失，系統懸 掛等錯誤。修改優先級 為最高，該級別需要程 序員立即修改O功能設計與需求嚴重不符CriticalO嚴重花屏O內存泄漏O影響手機語音或數據通訊等O嚴重的數值計算錯誤主要功能喪失，導致嚴O功能未實現或者存在錯誤重的問題，或致命的錯O輕微的數值計算錯誤嚴重問題Major誤聲明。修改優先級為O系統所提供的功能或服務受明顯的影響高，該級別需要程序員盡快修改O用戶數據丟失或破壞次要功能喪失，不太嚴O操作界面錯誤（包括數據窗口內列名定義、一般問題Normal重，如提示

17、信息不太準含義是否一致）確。修改優先級為中，O邊界條件下錯誤該級別需要程序員修改O功能存在錯誤，但岀現概率很低輕微問題Mi nor微小的問題，對功能幾 乎沒有影響，產品及屬 性仍可使用。修改優先 級為低，該級別需要程 序員修改或不修改O提示信息錯誤（包括未給出信息、信息提示錯誤等）O長時間操作無進度提示O系統未優化（性能問題）O界面格式等不規范O操作時未給用戶提示O文字排列不整齊等一些小問題O光標跳轉設置不好，鼠標（光標）定位錯誤提示信息格式不符合要O輔助說明描述不清楚Trivial求，違背正常習俗習慣O個別不影響產品理解的錯別字的，界面不美觀，控件排列、格式不統一O可輸入區域和只讀區域沒有明

18、顯的區分標志Enhan cement功能性建議，功能使用性、方便性、易用性不夠O建議5測試實施5.1執行開發就會轉版本給我們測試部門進行系統測試了。拿到版本我們首先搭建測試環境做一個預測試，目的是來評斷這個版本是不是可測試的。如果預測試不通過， 打回開發部返工，如果通過了，就開始我們第一輪的系統測試。第一輪系統測試我們會執行我們所編寫的所有測試用例，做好測試結果的記錄，發現缺陷了提交缺陷報告。當第一輪測試結束后，我們把所有的bug單提交給開發人員，由他們進行修改。在他們修復bug期間，我們會對第一輪系統測試做一個測試評估，出一個測試報告。還要根據實際情況， 對我們寫的測試用例進行修改和增加。開發改 bug結束， 提交一個新的版本給我們，我們重新搭建測試環境開始第二輪系統測試。首先是回歸我們提交的缺陷報告，然后會在用例中挑選一些優先級別比較高的用例來進行測 試，發現問 題了繼續提交缺陷報告，只到缺陷率低于用戶要求了，我們就進行最 后一輪的回歸測試，結束系統測試。具體測試輪次是根據版本質量和項目復雜度而 決定的。6測試評估? 執行階段結束了進入測試評估階段，我們會出一個總的測試報告對我們測試的這個過程和版本的質量做一個詳細的評估1) 需求需要評審那些？2) 用例需要評審那些？3) 計劃應該評審那些？4) 缺陷評審那些？5) bug評估？測試總結報告文檔的輸出：1、可以讓具體的任務負責