(完整word版)測試流程及測試理論方法

1、實用標準文案測試流程及測試理論方法、 測試流程1. 軟件開發(fā)流程：需求分析 概要設(shè)計 詳細設(shè)計 編碼開發(fā) 測試 維護2. 測試流程為 ：單元測試 /集成測試 系統(tǒng)測試 / 自動化測試 性能測試 驗收測試3. 目標：3.1 制定完整且具體的測試路線和流程，為快速、高效和高質(zhì)量的軟件測試提供基 礎(chǔ)流程框架。3.2 最終目標是實現(xiàn)軟件測試規(guī)范化、標準化、自動化。4. 測試流程說明：5. 測試需求分析 測試需求是整個測試過程的基礎(chǔ)；確定測試對象以及測試工作的范圍和作用。用 來確定整個測試工作 （如安排時間表、測試設(shè)計等）并作為測試覆蓋的基礎(chǔ)。而且被確定的 測試需求項必須是可核實的。即，它們必須有一個可

2、觀察、可評測的結(jié)果。 無法核實的需求 不是測試需求。 所以我現(xiàn)在的理解是測試需求是一個比較大的概念， 它是在整個測試計劃文 檔中體現(xiàn)出來的，不是類似的一個用例或者其他 .·測試需求是制訂測試計劃的基本依據(jù)，確定了測試需求能夠為測試計劃提供客觀依據(jù)； ·測試需求是設(shè)計測試用例的指導， 確定了要測什么、 測哪些方面后才能有針對性的設(shè)計測 試用例；·測試需求是計算測試覆蓋的分母，沒有測試需求就無法有效地進行測試覆蓋。5.1 測試方法與規(guī)范5.1.1 測試方法隨著軟件技術(shù)發(fā)展， 項目類型越來越多樣化。 根據(jù)項目類型應(yīng)選用針對性強的 測試方法， 合適的測試方法可以讓我們事半

3、功倍。 以下是針對目前項目工程可以參考的測試 方法：? 測試 （ beta 測試） - 非程序員、測試人員 測試，英文是 Beta testing 。又稱 Beta 測試，用戶驗收測試（ UAT）。 測試是軟件的多個用戶在一個或多個用戶的實際使用環(huán)境下進行的測試。 開發(fā)者通常 不在測試現(xiàn)場， Beta 測試不能由程序員或測試員完成。當開發(fā)和測試根本完成時所做的測試，而最終的錯誤和問題需要在最終發(fā)行前找到。 這種測試一般由最終用戶或其他人員完成，不能由程序員或測試員完成。? 測試（ Alpha 測試） - 非程序員、測試人員 測試，英文是 Alpha testing 。又稱 Alpha 測試 .

4、 Alpha 測試是由一個用戶在開發(fā)環(huán)境下進行的測試， 也可以是公司內(nèi)部的用戶在模擬實 際操作環(huán)境下進行的受控測試， Alpha 測試不能由該系統(tǒng)的程序員或測試員完成。在系統(tǒng)開發(fā)接近完成時對應(yīng)用系統(tǒng)的測試 ;測試后， 仍然會有少量的設(shè)計變更。這種測 試一般由最終用戶或其他人員來完成，不能由程序員或測試員完成。? 兼容性測試 - 測試人員 兼容性測試是指測試軟件是否可以成功移植到指定的硬件或者軟件環(huán)境中， 例如在 B/S 項目中各個不同瀏覽器之間的測試。? 用戶界面測試 -UI 測試 - 測試人員 用戶界面測試，英文是 User interface testing 。又稱 UI 測試。 用戶界面

5、，英文是 User interface 。是指軟件中的可見外觀及其底層與用戶交互的部 分（菜單、對話框、窗口和其它控件）。用戶界面測試是指測試用戶界面的風格是否滿足客戶要求， 文字是否正確， 頁面是否美 觀，文字， 圖 片組合是否完美， 操作是否友好等等。 UI 測試的目標是確保用戶界面會通過 測試對象的功能來為用戶提供相應(yīng)的訪問或瀏覽功能。 確保用戶界面符合公司或行業(yè)的標準。 包括用戶友好性、人性化、易操作性 測試。用戶界面測試用戶分析軟件用戶界面的設(shè)計是否合乎用戶期望或要求。 它常常包括 菜單，對話框及對 話框上所有按鈕，文字，出錯提示，幫助信息 （Menu 和 Help content）

6、 等方面的測試。比如，測試 Microsoft Excel 中插入符號功能所用的對話框的大小，所有按 鈕是否對齊，字符串字體大小，出錯信息內(nèi)容和字體大小，工具欄位置 / 圖標等等。? 冒煙測試 - 版本編譯者 冒煙測試，英文是 Smoke testing 。 冒煙測試的名稱可以理解為該種測試耗時短， 僅用一袋煙功夫足夠了。 也有人認為是形 象地類比新電路板功基本功能檢查。 任何新電路板焊好后， 先通電檢查， 如果存在設(shè)計缺陷， 電路板可能會短路，板子冒煙了。冒煙測試的對象是每一個新編譯的需要正式測試的軟件版本， 目的是確認軟件基本功能 正常，可以進行后續(xù)的正式測試工作。冒煙測試的執(zhí)行者是版本編

7、譯人員。? 隨機測試 - 測試人員 隨機測試，英文是 Ad hoc testing 。隨機測試沒有書面測試用例、記錄期望結(jié)果、 檢查列表、 腳本或指令的測試。 主要是根 據(jù)測試者的經(jīng)驗對軟件進行功能和性能抽查。 隨機測試是根據(jù)測試說明書執(zhí)行用例測試的重 要補充手段，是保證測試覆蓋完整性的有效方式和過程。隨機測試主要是對被測軟件的一些重要功能進行復測， 也包括測試那些當前的測試樣例 (TestCase) 沒有覆蓋到的部分。 另外， 對于軟件更新和新增加的功能要重點測試。重點對一些特殊點情況點、 特殊的使用環(huán)境、 并發(fā)性、 進行檢查。 尤其 對以前測試發(fā)現(xiàn)的重大 Bug， 進行再次測試，可以結(jié)合回

8、歸測試 (Regressive testing)一起進行。? 黑盒測試(功能測試) - 測試人員黑盒測試，英文是 Black Box Testing 。又稱功能測試或者數(shù)據(jù)驅(qū)動測試。黑盒測試是根據(jù)軟件的規(guī)格對軟件進行的測試，這類測試不考慮軟件內(nèi)部的運作原理， 因此軟件對用戶來說就像一個黑盒子。在完全不考慮程序內(nèi)部結(jié)構(gòu)和特性的情況下， 測試軟件的外部特性。 根據(jù)軟件的需求規(guī) 格說明書設(shè)計測試用例， 從程序輸入和輸出特性上檢查程序是否滿足設(shè)定的功能。 黑盒測試 常采用的方法是設(shè)計適量有效和無效的輸入數(shù)據(jù)進行測試， 以期用最小的代價發(fā)現(xiàn)最多的錯 誤。軟件測試人員以用戶的角度， 通過各種輸入和觀察軟件

9、的各種輸出結(jié)果來發(fā)現(xiàn)軟件存在 的缺陷，而不關(guān)心程序具體如何實現(xiàn)的一種軟件測試方法。個人復查 個人復查是指程序員自行設(shè)計 測試用例 ，對源代碼、 詳細設(shè)計進行仔細檢查， 并記錄錯 誤、不足之處等。個人復查主要包括檢查變量的正確性、檢查標號的正確性、檢查子程序、 宏、函數(shù)、常量檢查、標準檢查、風格檢查、比較控制流、選擇、激活路徑、對照詳細說明 書，閱讀源代碼和補充文檔等方面的測試內(nèi)容。走查 走查是指測試人員先閱讀相應(yīng)的文檔和源代碼，然后人工將測試數(shù)據(jù)輸入被測試程序， 并在紙上跟蹤監(jiān)視程序的執(zhí)行情況， 人工沿著程序的邏輯走查運行一遍， 跟蹤走查運行的進 程來發(fā)現(xiàn)程序的錯誤。 走查的具體測試內(nèi)容包括模

10、塊特性、 模塊接口、 模塊的對外輸入或輸 出、局部數(shù)據(jù)結(jié)構(gòu)、數(shù)據(jù)計算錯誤、控制流錯誤、處理出錯和邊界測試等方面。會審 會審是指測試人員在會審前仔細閱讀軟件的有關(guān)資料， 根據(jù)錯誤類型清單 (根據(jù)以往的 經(jīng)驗、 對源程序的估計等，并在以后測試中給以豐富補充)填寫檢測表，提出根據(jù)錯誤類型 要提出的問題。 會審時， 由程序設(shè)計人員講解程序的設(shè)計方法， 由程序編寫人員逐個講解程 序代碼的編寫，測試人員需要逐個審查，提問，討論可能出現(xiàn)的問題。會審對程序的功能、 結(jié)構(gòu)、邏輯和風格都要進行審定。會審的測試內(nèi)容與“走查”的內(nèi)容相同。白盒測試白盒也稱結(jié)構(gòu)測試， 這是將軟件看成一個透明的白盒子， 按照程序的內(nèi)部結(jié)構(gòu)

11、和處理邏 輯來選定測試用例，對軟件的邏輯路徑及過程進行測試，檢查它與設(shè)計是否相符。性能測試性能測試，英文是 Performance Testing 。 性能測試是在交替進行負荷和強迫測試時常用的術(shù)語。理想的“性能測試” （ 和其他類 型的測試 ） 應(yīng)在需求文檔或質(zhì)量保證、測試計劃中定義。性能測試一般包括負載測試和壓力 測試。通常驗證軟件的性能在正常環(huán)境和系統(tǒng)條件下重復使用是否還能滿足性能指標。 或 者執(zhí)行同樣任務(wù)時新版本不比舊版本慢。 一般還檢查系統(tǒng)記憶容量在運行程序時會不會流失 （memory leak） 。比如，驗證程序保存一個巨大的文件新版本不比舊版本慢。5.1.2 測試規(guī)范測試規(guī)范是根

12、據(jù)開發(fā)規(guī)范而制定的測試標準， 測試規(guī)范也是后期測試用例編寫的重 要依據(jù)。 因為開發(fā)規(guī)范因公司而異， 因產(chǎn)品而異， 所以測試規(guī)范的標準程度每個公司都不一 樣。從理論到方法到各類流程到各類報告模版， 都屬于測試規(guī)范的范疇， 當一整套規(guī)范形成 之后，可使得測試工作進行更加穩(wěn)健，所有問題有據(jù)可查。5.2 軟件需求規(guī)格說明書 軟件需求規(guī)格說明書是軟件達到的各項功能的目標。是測試人員各項工作的依據(jù)， 沒有需求就無法判斷測試結(jié)果是正確的。5.3 軟件設(shè)計說明（概要與詳細設(shè)計）設(shè)計說明書包含軟件的一些框架、 字段、 數(shù)據(jù)庫設(shè)計等。 軟件設(shè)計說明對測試工作 開展有很大影響， 沒有軟件設(shè)計說明很多問題將無法溯源，

13、 測試準備的前期工作也是根據(jù)軟 件設(shè)計說明來制定的。5.4 頁面原型（ demo）頁面原型是項目人員快速熟悉項目的最佳路徑。 在需求不夠明確， 設(shè)計說明書不夠全面的情況下，頁面原型也是后期測試用例編寫思想的重要根據(jù)6. 測試過程設(shè)計明確測試目的，最終達成目的并驗證結(jié)果是測試要做的事情。包括：1. 測試范圍：描述本次測試中的測試范圍，如：測試軟件功能范圍、測試種類等。2. 簡單的描述如何搭建測試平臺以及測試的潛在的風險。3. 項目信息：說明要測試的項目的相關(guān)資料，如：輸入輸出文檔，產(chǎn)品描述，軟件主 要功能。4. 人力資源的分配。5. 測試需求：籠統(tǒng)說，就是測試中的所有設(shè)計和需求文檔。作為本次測試

14、的依據(jù)6.1 測試策略制定 這一階段在于需求、詳細設(shè)計、測試計劃完成之后，主要是本次測試的策略階段。 很多公司缺少這個階段， 需要有計劃性的分出產(chǎn)品的功能扣出測試的功能點， 現(xiàn)階 段大多公司都是直接拿著文檔就開始做用例設(shè)計。對需求進行分析，列出具體的功能列表。 （一般根據(jù)功能交互文檔就能明確出此功 能的大體功能， 一層層的分下去， 一直到每個功能表單。 然后考慮到使用哪些測試 方法？工作一旦做到執(zhí)行階段，我們可以更好的根據(jù)這些功能表一點一點的覆蓋。 也能讓我們在用例評審時， 充分的證實我們的工作是有效的能夠保證產(chǎn)品的質(zhì)量。 ） 一般在此之前， 一些業(yè)務(wù)培訓和需求評審是有必要是聽一下的。 這樣能

15、夠更早更熟 練的理解需求，也能保證產(chǎn)品設(shè)計中出現(xiàn)的一些誤區(qū)。對于一個個測試該如何進行測試？如下：a）功能測試? 功能范圍（劃分出各自負責的功能模塊）? 使用測試方法（等價類、邊界值等測試方法）? 測試標準（符合設(shè)計、需求和規(guī)范文檔對該功能的描述）b）界面測試c）兼容性測試d）性能測試6.2 測試計劃精彩文檔1) 要充分考慮測試計劃的實用性， 即測試計劃與實際之間的接近程度和可操作性。 編 寫測試計劃的目的在于充分考慮執(zhí)行測試時 的各種資源，包括測試內(nèi)容、測試標 準、時間資源、 人力資源等等， 準確地說是要分析執(zhí)行時所能夠調(diào)用的一切資源以 及受各種條件限制，可能受到的各種影響。a) 測試內(nèi)容：對

16、一個軟件來說測試計劃中會明確本次測試做哪些測試？ 如：系統(tǒng)測試：在整個系統(tǒng)測試中會有(界面測試、功能測試、性能測試、兼 容性測試、安裝卸載測試、可靠性測試等測試) 。b) 測試目的： 一般多為保證產(chǎn)品質(zhì)量是否達到預期的指標。 這個指標也就是在測 試中定義的結(jié)束標準。c) 測試標準： 需要考慮本次測試需要輸入那些文檔， 該項目結(jié)束標準定義、 測試 結(jié)束標準的定義？ bug 級別定義、優(yōu)先級定義、 bug 管理流程定義。這個都需 要在執(zhí)行測試時明確。計劃中應(yīng)該包含這些內(nèi)容。d) 資源分配： 這里分為人力資源、 軟硬件資源等劃分。 一般會把人力資源的利用 寫入一個測試人員任務(wù)分配表里， 按照不同的階

17、段， 每個階段提交相應(yīng)的成果 (難度很大) 。軟硬件資源中主要是在做計劃時考慮到需要多少電腦或別的工 具，列出清單。e) 測試風險： 大多考慮到的就是項目開發(fā)延期、 測試人員不足用例無法全面覆蓋 測試點、時間不足用例無法全部執(zhí)行、 bug 無法及時修改導致無法驗證、測試 人員技能不足導致測試進度拉長。f) 軟件測試策略一般都是分開來做相關(guān)測試方案。6.3 測試附件用例模板、缺陷報告模板 測試環(huán)境的搭建 缺陷管理流程和缺陷級別定義缺陷狀態(tài)一般分為：新建、打開、已分配、已修復、關(guān)閉、重新打開中間會有：延期、重復、拒絕等狀態(tài)缺陷管理流程：1. 測試人員或開發(fā)人員發(fā)現(xiàn) bug 后，判斷輸入哪個模塊的問

18、題，填寫 bug 報告后，系 統(tǒng)會自動通過 Email 通知開發(fā)組長和該模塊開發(fā)者。2. 開發(fā)組長根據(jù)具體情況，重新 reassigned 分配給 bug 所屬的開發(fā)者。3. 開發(fā)者收到 email 信息后，判斷是否為自己的修改范圍。 若不是，重新 reassigned 分配給開發(fā)組長或應(yīng)該分配的開發(fā)者。 若是，進行處理， resolved 并給出解決方法。 （可創(chuàng)建補丁附件及補充說明）4. 測試人員查詢開發(fā)者已修改的 bug ，進行回歸測試。 經(jīng)驗證無誤后，修改狀態(tài)為 verified 。待整個產(chǎn)品發(fā)布后，修改為 closed 。 還有問題， reopened ，狀態(tài)重新變?yōu)椤?new”，并

19、發(fā)送郵件通知。5. 如果這個 bug 一周內(nèi)一直沒被處理過。 Bugzilla 就會一直用 email 騷擾它的屬主， 直接采取行動。管理員可以設(shè)定最遲采取行動的期限，比如 3 天，系統(tǒng)默認 7 天。缺陷等級劃分：分級Bug等級Bug等級說明分類說明致命問題Blocker導致整個產(chǎn)品無法進行 模塊無法啟動或異常退出Critical測試。修改優(yōu)先級為最 高，該級別需要程序員 立即修改死機，數(shù)據(jù)丟失，主要 功能完全喪失，系統(tǒng)懸 掛等錯誤。修改優(yōu)先級 為最高，該級別需要程 序員立即修改 其它導致無法測試的錯誤 運行過程中系統(tǒng)崩潰 / 死機 / 重啟 功能設(shè)計與需求嚴重不符 嚴重花屏 內(nèi)存泄漏 影響手

20、機語音或數(shù)據(jù)通訊等 嚴重的數(shù)值計算錯誤嚴重問題Major主要功能喪失，導致嚴 重的問題，或致命的錯 誤聲明。修改優(yōu)先級為 高，該級別需要程序員 盡快修改Normal次要功能喪失， 不太嚴 重，如提示信息不太準 確。修改優(yōu)先級為中， 該級別需要程序員修改一般問題Minor微小的問題，對功能幾 乎沒有影響，產(chǎn)品及屬 性仍可使用。修改優(yōu)先 級為低，該級別需要程 序員修改或不修改 功能未實現(xiàn)或者存在錯誤 輕微的數(shù)值計算錯誤 系統(tǒng)所提供的功能或服務(wù)受明顯的影響 用戶數(shù)據(jù)丟失或破壞 操作界面錯誤（包括數(shù)據(jù)窗口內(nèi)列名定義、 含義是否一致） 邊界條件下錯誤 功能存在錯誤，但出現(xiàn)概率很低 提示信息錯誤（包括未給

21、出信息、信息提示錯誤等） 長時間操作無進度提示 系統(tǒng)未優(yōu)化（性能問題） 界面格式等不規(guī)范 操作時未給用戶提示 文字排列不整齊等一些小問題 光標跳轉(zhuǎn)設(shè)置不好，鼠標（光標）定位錯誤Trivial輕微問題Enhancement提示信息格式不符合要 求 , 違背正常習俗習慣 的，界面不美觀，控件 排列、格式不統(tǒng)一 功能性建議，功能使用 性、方便性、易用性不 輔助說明描述不清楚 個別不影響產(chǎn)品理解的錯別字 可輸入?yún)^(qū)域和只讀區(qū)域沒有明顯的區(qū)分標志 建議7. 測試實施7.1 執(zhí)行開發(fā)就會轉(zhuǎn)版本給我們測試部門進行系統(tǒng)測試了。 拿到版本我們首先搭建測試環(huán)境 做一個預測試， 目的是來評斷這個版本是不是可測試的。 如果預測試不通過， 打回 開發(fā)部返工，如果通過了，就開始我們第一輪的系統(tǒng)測試。第一輪系統(tǒng)測試我們會執(zhí)行我們所編寫的所有測試用例， 做好測試結(jié)果的記錄， 發(fā) 現(xiàn)缺陷了提交缺陷報告。 當?shù)谝惠啘y試結(jié)束后， 我們把所有的 b