第一篇：黑盒測試的測試流程簡單介紹

黑盒測試的測試流程簡單介紹

話說我們一直在做黑盒自動化測試，那我們究竟處于測試中的哪個位置呢？

其實我們更多的是在執行測試提交報告和發現的軟件Error，測試用例是如何設計的，為什么要這樣設計又有多少人想過呢？黑盒測試中的測試用例設計的簡單方法又有多少了解呢？我們常做的測試中哪些地方用到了例如等價類劃分法？

下面僅僅對黑盒測試的簡單的測試流程進行下說明關于黑盒測試的其他內容會在以后的帖子中說明。

首先來了解兩個名詞：

Statement of Work（SOW）軟件使用說明書

Software Requirement Specification(SRS)軟件需求規格說明書

1.需求分析階段：對業務的學習，分析需求點。

2.測試計劃階段：測試組長就要根據SOW開始編寫《測試計劃》，其中包括人員，軟件硬件資源，測試點，集成順序，進度安排和風險識別等內容。

3.測試設計階段：測試方案一般由對需求很熟的高資深的測試工程師設計，測試方案要求根據《SRS》上的每個需求點設計出包括需求點簡介，測試思路和詳細測試方法三部分的方案。《測試方案》編寫完成后也需要進行評審。

4.測試方案階段：主要是對測試用例和規程的設計。測試用例是根據《測試方案》來編寫的，通過《測試方案》階段，測試人員對整個系統需求有了詳細的理解。這時開始編寫用例才能保證用例的可執行和對需求的覆蓋。測試用例需要包括測試項，用例級別，預置條件，操作步驟和預期結果。其中操作步驟和預期結果需要編寫詳細和明確。測試用例應該覆蓋測試方案，而測試方案又覆蓋了測試需求點，這樣才能保證客戶需求不遺漏。同樣，測試用例也需要評審。

5.測試執行階段：執行測試用例，及時提交Error和測試報告等相關文檔。

第二篇：黑盒測試心得

“黑盒”測“外”不測“內”

“黑盒”測的是功能

黑盒測試也稱功能測試或數據驅動測試。它在已知產品應具有的功能的條件下，通過測試來檢測每個功能是否都能正常使用。在測試時，把程序看作一個不能打 開的黑盒子，在完全不考慮程序內部結構和內部特性的情況下，測試者在程序接口進行測試，它只檢查程序功能是否按照需求規格說明書的規定正常使用，程序是否 能適當地接收輸入數據而產生正確的輸出信息，并且保持外部信息（如數據庫或文件）的完整性。

“黑盒”法著眼于程序外部結構、不考慮內部邏輯結構、針對軟件界面和軟件功能進行測試。“黑盒”法是窮舉輸入測試，只有把所有可能的輸入都作為測試情況使 用，才能以這種方法查出程序中所有的錯誤。實際上測試情況有無窮多個，人們不僅要測試所有合法的輸入，而且還要對那些不合法但是可能的輸入進行測試。

“黑盒”的兩種基本方法

黑盒測試有兩種基本方法，即通過測試和失敗測試。

在進行通過測試時，實際上是確認軟件能做什么，而不會去考驗其能力如何。軟件測試員只運用最簡單，最直觀的測試案例。

在設計和執行測試案例時，總是先要進行通過測試。在進行破壞性試驗之前，看一看軟件基本功能是否能夠實現。這一點很重要，否則在正常使用軟件時就會奇怪地發現，為什么會有那么多的軟件缺陷出現？

在確信了軟件正確運行之后，就可以采取各種手段通過搞“垮”軟件來找出缺陷。純粹為了破壞軟件而設計和執行的測試案例，被稱為失敗測試或迫使出錯測試。

黑盒測試的設計方法

黑盒測試是以用戶的觀點，從輸入數據與輸出數據的對應關系出發進行測試的，它不涉及到程序的內部結構。很明顯，如果外部特性本身有問題或規格說明的規 定有誤，用黑盒測試方法是發現不了的。黑盒測試法注重于測試軟件的功能需求，主要試圖發現幾類錯誤：功能不對或遺漏、界面錯誤、數據結構或外部數據庫訪問 錯誤、性能錯誤、初始化和終止錯誤。

具體的黑盒測試方法包括等價類劃分、因果圖、正交實驗設計法、邊值分析、判定表驅動法、功能測試等。在使用時，自然要針對開發項目的特點對方法加以適當的選擇。

◆ 等價類劃分

等價類劃分是一種典型的黑盒測試方法，用這一方法設計測試用例可以不用考慮程序的內部結構，只以對程序的要求和說明，即需求規格說明書為依據，仔細分析和推敲說明書的各項需求，特別是功能需求，把說明中對輸入的要求和輸出的要求區別開來并加以分解。

由于窮舉測試的數量太大，以致于無法實際完成，促使我們在大量的可能數據中選取其中的一部分作為測試用例。例如，在不了解等價分配技術的前提下，測試 了1+1、1+2、1+3和1+4之后，還有必要測試1+5和1+6嗎?能否放心地認為它們正確嗎?那么1+999…（可以

輸入的最大數值）呢？這個測試 用例是否與其他用例不同？是否屬于另外一種類別？另外一個等價區間？這是軟件測試員必須考慮到的問題。

等價類別或者等價區間是指測試相同目標或者暴露相同軟件缺陷的一組測試案例。1+999…和1+13有什么區別呢？至于1+13，就像一個普通的加法，與1+5或者1+392沒有什么兩樣，而1+999…則屬于鄰界的極端情況。假 如輸入最大允許數值，然后加1，就會出現問題——也許就是軟件的缺陷。這個極端案例屬于一個單獨的區間，與常規數字的普通區間不同。

等價類劃分的辦法是把程序的輸入域劃分成若干部分，然后從每個部分中選取少數代表性數據當作測試用例。每一類的代表性數據在測試中的作用等價于這一類 中的其他值，也就是說，如果某一類中的一個例子發現了錯誤，這一等價類中的其他例子也能出現同樣的錯誤。使用這一方法設計測試用例，首先必須在分析需求規 格說明的基礎上劃分等價類，列出等價類表。

在考慮等價類劃分時，先從程序的功能說明中找出每個輸入條件，然后為每個輸入條件劃分兩個或更多個等價類。等價類可分兩種情況：有效等價類和無效等價 類。有效等價類是指對程序的規格說明是有意義的、合理的輸人數據所構成的集合；無效等價類是指對程序的規格說明是不合理的或無意義的輸人數據所構成的集 合。

◆ 邊界值分析

軟件測試常用的一個方法是把測試工作按同樣的形式劃分。對數據進行軟件測試，就是檢查用戶輸入的信息、返回結果以及中間計算結果是否正確。

即使是最簡單的程序，要處理的數據也可能數量極大。還記得在計算器上簡單加法的全部可能性嗎？再想一想字處理程序、導航系統和證券交易程序。使這些數 據得以測試的技巧（如果稱得上的話）是，根據下列主要原則進行等價分配，以合理的方式減少測試案列：邊界條件、次邊界條件、空值和無效數據。

邊界值分析（Boundary Value Analysis，BVA）是一種補充等價劃分的測試用例設計技術，它不是選擇等價類的任意元素，而是選擇等價類邊界的測試用例。實踐證明，在設計測試用 例時，對邊界附近的處理必須給予足夠的重視，為檢驗邊界附近的處理專門設計測試用例，常常可以取得良好的測試效果。BVA不僅重視輸人條件邊界，而且也從 輸出域導出測試用例。

第三篇：黑盒測試技術實驗報告

黑盒測試技術 — 三角形問題 實驗報告 一、問題描述 輸入三個整數 a、b、c，分別作為三角形的三條邊，通過程序判斷這三條邊是否能構成三角形？如果能構成三角形，則判斷三角形的類型并輸出（等邊三角形、等腰三角形、一般三角形），如果不構成三角形輸出不能構成三角形。

要求:(1)輸入三個整數 a、b、c，必須滿足以下條件：1≤a≤200；1≤b≤200；1≤c≤200。

(2)容錯處理：輸入空值的提示；輸入的值滿足類型的提示；(3)不限制開發環境，不限制開發語言；(4)盡可能不對自己的程序進行測試設計。

(5)請分別采用邊界值分析法、等價類分析法、決策表分析法、基于場景分析法設計測試用例；(6)正文格式（除源代碼用小五號單倍行距），其他行距固定值 20，字號小四。

二、程序主要源代碼 (標注：測試的源代碼是哪位同學（學號姓名）編寫的。)

三、程序界面（截圖）

四、設計測試用例

1.用邊界值測試方法設計測試用例

用邊界值分析法設計測試用例，按照下列步驟進行：

（（1）

分析各變量取值 三角形三條邊的取值范圍都是 1-200，所以邊長 A 的邊界點為 1 和 200，邊長 B的邊界點為 1 和 200，邊長 C 的邊界點為 1 和 200。

（（2）

測試用例數 輸入條件 邊界值 測試數據 A 1,200 0,1,2,199,200,201 B 1,200 0,1,2,199,200,201 C 1,200 0,1,2,199,200,201

設計測試用例（給出所有測試用例）

三角形問題的測試用例 測試用例 編號 輸入數據 預期輸出 測試結果 a b c 1 0 100 100 邊長 A 不合法

邊長 A 不合法1 100 100 等腰三角形 等腰三角形 3 2 100 100 等腰三角形 等腰三角形 4 199 100 100 等腰三角形 等腰三角形 5 200 100 100 不是三角形 不是三角形 6 201 100 100 邊長 A 不合法

邊長 A 不合法100 0 100 邊長 B 不合法

邊長 B 不合法100 1 100 等腰三角形 等腰三角形 9 100 2 100 等腰三角形 等腰三角形 10 100 199 100 等腰三角形 等腰三角形 11 100 200 100 不是三角形 不是三角形 12 100 201 100 邊長 B 不合法

邊長 B 不合法100 100 0 邊長 C 不合法

邊長 C 不合法100 100 1 等腰三角形 等腰三角形 15 100 100 2 等腰三角形 等腰三角形 16 100 100 199 等腰三角形 等腰三角形 17 100 100 200 不是三角形 不是三角形 18 100 100 201 邊長 C 不合法

邊長 C 不合法

2.用等價類測試方法設計測試用例

（（1）首先分析題目中給出的條件和隱含的輸入要求，輸入條件如下：

條件：1<=邊長 A<=200,1<=邊長 B<=200,1<=邊長 C<=200

隱含條件:A

輸入條件 有效等價類 無效等價類 是否是三角形 1.1<=A<=200 2.1<=B<=200 3.1<=C<=200 4.A200 8.B<1 || B>200 9.C<1 || C>200 10.A>=B+C 11.B>=A+C 12.C>=A+B 等腰三角形 13.A=B&&B!=C 14.A=C&&C!=B 15.B=C&&C!=A 16.A!=B&&A!=C&&B!=C 等邊三角形 17.A=B=C 18.A!=B 19.A!=C 20.B!=C

(3)設計測試用例，覆蓋上表中的等價類，如表 1-3 表所示。（至少 20 條）

表 表 1-3 三角形問題的測試用例 測試用例 編號 輸入數據 預期輸出 覆蓋等價類 測試結果 a b c 1 100 100 100 等邊三角形 1,2,3,4,5,6,17 等邊三角形 2 50 50 50 等邊三角形 1,2,3,4,5,6,17 等邊三角形 3 150 150 150 等邊三角形 1,2,3,4,5,6,17 等邊三角形 4 50 100 100 等腰三角形 1,2,3,4,5,6,15 等腰三角形 5 100 50 100 等腰三角形 1,2,3,4,5,6,14 等腰三角形 6 100 100 50 等腰三角形 1,2,3,4,5,6,13 等腰三角形 0 2 3 邊長 A 不合法 7 邊長 A 不合法 8 2 1 3 不是三角形 12 不是三角形 9 3 0 1 邊長 B 不合法 8 邊長 B 不合法 10 3 1 2 不是三角形 10 不是三角形 11 1 3 0 邊長 C 不合法 9 邊長 C 不合法 12 2 3 1 不是三角形 11 不是三角形 13 50 51 52 不是等腰三角形

1,2,3,4,5,6,16 一般三角形 14 51 52 50 不是等腰三角形

1,2,3,4,5,6,16 一般三角形 15 52 50 51 不是等腰三角形

1,2,3,4,5,6,16 一般三角形 16 100 100 101 不是等邊三角形

1,2,3,4,5,6,19,20 等腰三角形 17 100 101 100 不是等邊三角形

1,2,3,4,5,6,18,20 等腰三角形 18 101 100 100 不是等邊三角形

1,2,3,4,5,6,18,19 等腰三角形 19 50 50 51 不是等邊三角形

1,2,3,4,5,6,19,20 等腰三角形 20 50 51 50 不是等邊三角形

1,2,3,4,5,6,18,20 等腰三角形 21 51 50 50 不是等邊三角形

1,2,3,4,5,6,18,19 等腰三角形

3.用決策表測試方法設計測試用例

（（1）構建決策表

（（2）化簡 測試用例 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 輸入條件 是三角形 Y Y Y Y Y Y Y Y N N N N N N N N A=B Y Y N Y N Y N N N Y Y Y N N Y N A=C Y N Y Y Y N N N N Y Y N Y N N Y B=C Y Y Y N N N Y N N Y N Y Y Y N N 預期輸出 不是三角形

等腰三角形

等邊三角形

一般三角形

出錯提示

測試用例 1 2,3,4 5,6,7 8 9-16 輸入條件 是三角形

A=B

A=C

B=C

預期輸出 不是三角形

Y 等腰三角形

Y

等邊三角形

Y

一般三角形

Y

出錯提示

Y

（（3）化簡后的測試用例設計 測試用例 編號 輸入數據 預期輸出 覆蓋等價類 測試結果 a b c 1 50 50 50 等邊三角形 1,2,3,4,5,6,17 等邊三角形 2 50 50 51 等腰三角形 1,2,3,4,5,6,13 等腰三角形 3 51 50 50 等腰三角形 1,2,3,4,5,6,15 等腰三角形 4 50 51 50 等腰三角形 1,2,3,4,5,6,14 等腰三角形 5 1 2 3 不是三角形 12 不是三角形 6 1 3 2 不是三角形 11 不是三角形 7 3 2 1 不是三角形 10 不是三角形 8 2 3 4 一般三角形 1,2,3,4,5,6 一般三角形 9 3 2 4 一般三角形 1,2,3,4,5,6 一般三角形 10 4 3 2 一般三角形 1,2,3,4,5,6 一般三角形

4.基于場景的測試

（1 1）基本流和備選流圖

（2 2）場景設計

場景 1 1 ：基本流

場景 2 2 ：基本流+ + 備選流 1 1

場景 3 3 ：基本流+ + 備選流 2 2

場景 4 4 ：基本流+ + 備選流 3 3

場景 5 5 ：基本流+ + 備選流 4 4

（3 3））

測試用例設計

開始輸入 輸入 A,B,C 判斷各邊邊長是否是在 1-200 A+B>C && A+C>B && B+C>A 備選流 1:邊長不符合條件 備選流 2:不是三角形 是三角形 備選流 3:是等腰三角形 備選流 4:是等邊三角形 一般三角形 結束

場景

A A

B B

C C

預期輸出

測試結果1234

一般三角形

一般三角形2

0 0

0 0

0 0

邊長錯誤

邊長錯誤3247

不是三角形

不是三角形4

等腰三角形

等腰三角形5

等邊三角形

等邊三角形

5.測試結果分析與總結（至少 0 150 字，對測試過程中失敗用例的原因進行分析，對學習了黑盒測試技術的學習總結）

在用等價類測試方法時，在測試無效等價類的結果和預期結果不一致，其原因是在設計程序時沒有考慮無效等價類的這些測試用例的輸出語句，黑盒測試技術是我們常使用的軟件測試的方法，在測試中，我們需要將邊界值測試，等價類測試，決策表測試，基于場景測試聯合使用。任何一款軟件都不可能做到完全測試，所以我們需要做的就是將黑盒測試中的方法盡可能結合使用，爭取讓軟件少一些 bug。

第四篇：測試流程參考資料

工作兩年了，我一直希望讓自己每年對測試的理解更深入一層。工作一年的時候我寫了《談軟件測試---一年工作總結》，談輪了自己對各種測試的理解，這一年來，雖然對那些理概念的有所加強，自我感覺沒有什么質的變化。前些天聽我們公司的一位測試經理講《敏捷測試》豁然開朗。他在學造飛機，而我一直在學造飛機里的一個發動機。我從來沒想過，一個完整飛機的架構應該是怎樣的。

如果想讓測試在公司的項目中發揮出它最大的價值，并不是招兩個測試技術高手，或引入幾個測試技術，而是測試技術對項目流程的滲透，以及測試流程的改進與完善。雖然，當然測試行業前景樂觀，許多中小企業也都在引入測試，但一百個公司就有一百種測試，每個公司對測試的看法不同，公司對測試的定位也不完全一樣。本人前后經歷兩個公司，以自己的拙見淺談一下對測試流程的看法。

這幾天整理思路，回顧了前兩份測試工作的流程與架構。

簡陋的測試流程

先說筆者入職的第一個家公司，筆者是第一個入職的專職測試人員，相信一兩個測試的公司還是不少的，入職后各種項目都在進行當中，上面給我的定位是并沒完全融入到項目中去。而通過指派任務的方式。下面是簡陋的流程圖：

需求分析與架構設計：

我們做的是某一移動公司內部使用的項目，需求分析與架構全部由項目經理完成，之后由項目經理給具體某個開發人員分配任務，具體對某個功能模塊的實現。這個對項目經理的經驗與技術要求很高，他既然擔任了需求分析師，又擔任架構師的角色。程序員編碼：

因為我們開發語言用的是JAVA 語言，IDE用myeclipse 中自帶的CVS版本管理工具，開發人員完成代碼后，提交到版本庫中。測試：

筆者入職后的第一個任務是搭建缺陷管理工具，禪道項目管理，通過推廣對發現的問題進行跟蹤。后來正明效果并不好，因為對于一個六七人的開發團隊項目，開發人員更喜歡測試人員能當面反饋，這樣更能提高效率。對一個小bug 通過當面交流的方式就可以將問題修復。

對于當時的環境，并沒有測試線。開發人員在本機上將項目進行部署運行。測試人員通過局域網訪問開發人員的機子進行訪問。或在測試人員本機上進行部署測試。這也是一個致命的缺點。因為開發人員測試人員使用的電腦存在太多不穩定性，這些都會造成問題的出現，有時候難以判定是系統問題還是環境問題。上線：

經過測試人員測試通過后，開發人員部署上線。A程序員流程

你會發現在流程圖中，A程序員是先發上線之后，再進行測試。這是我們一個面向大眾用戶的網站，上面給于測試人員的定位是測試員兼用戶體驗員，測試員將發現的bug和體驗問題提交到缺陷管理系統，由經理對問題進行分析，指派開發人員解決。定期對系統進行更新。

流程分析：

這個流程唯一的優點，就是能快速的發現并修復問題。

缺點就非常多了，相信許多小軟件公司也有類似的流程。

這個流程中，項目經理是核心，項目經理也確實是有多年開發與項目經驗的牛人，他喜歡不定期分享上些前沿的技術。我很崇拜他。

對于測試來說，需求很不明確，測試文檔與用例也是可有可無的產物，沒有需求文檔，或非常簡陋，根據需求文檔根本無法編寫用例。筆者只能收集一些通用的測試用例，如登錄、文件上傳下載、列表翻頁、日期選擇、輸入框驗證、搜索等有一些“通用型”用例，以便在測試過程中做參考。功能測試的多了，拿到一個功能，測試思路也就出來了。

規范的測試流程

放棄上份悠閑的工作，感謝那個帶我入行公司，我想了解真正的測試在公作中如何進行的。所以，來到了現在這家公司。我很欣喜的是這測試有自己的團隊，專業（對當時的我來說）的流程，以及與開發等同的地位。現在的測試流程：

需求分析：

需求分析由產品人員制定，他們要做的不是一份簡單的文檔，而是細化每一個功能的細節，每一個按鈕的位置，對于稍大或復雜一點的需求都進行建模。需求評審：

這里會叫上所有參與項目人員進行，開發人員、測試人員、QA人員。測試人員提出需求，開發人員考慮功能實現的方案與可行性、當然開發負責也是要參與的。測試人員主要是對需求的理解提出疑問，以便才能根據需求寫用例。QA人員是最終對軟件質量進行驗證的人，所以也需求了解需求 開發人員編寫排期：

開發人員需求根據需求功能點進行排期。然后將開計劃轉交給測試人員。測試計劃排期：

測試人員根據開發計劃，對測試具體測試時間，也就是開發功能完成后的時間，進行幾輪測試等。然后，把項目的開發與測試計劃發送給各部門負責人及參與項目的所有人員。編寫測試用例：

根據詳細的需求分檔，開始進行用例的編寫。用例評審：

在用例進行評審之間，先以郵件形式將用例發送給相關人員，以便他們事先了解用例對哪些功能進行驗證以及驗證的細節。

然后，測試人員組進行用例評審，開發人員對用例與實際功能不符合有哪些，產品人員對會通過用例對功能的具體實現進行把握等等。提交基線：

開發人員完成所有功能后，會對自己的功能進行一個自測。自測完成后提交測試人員進行基線。

具體測試流程：

開發人員對于基到測試線的功能進行測式，發現的問題通過缺陷管理工具進行反饋，開發人員對問題進行修復，然后，準備第二輪基。

測試人員完成第一輪測試后，需要寫測試結論，發到相關人員。然后對基線后的第二輪進行測試，第二輪會對第一輪中發現的問題進行重點回歸。測試通過：

經過兩到三輪或四輪的測試后，直到沒發現新的問題，或暫時無法解決，或不緊急的問題。通過上級確認，可以通過。編寫測試報告與驗收方案。

驗收方案是交由QA進行驗證的。在現公司的流程中是將測試與QA分開的，測試人員重點關注的是功能是否可以正常運行。QA關注的是整個流程的質量以及最終用戶的質量。有些公司QA與測試是不區分的，但這對測試的要求會更高，除了關心功能，還需要關心整體流程與質量。

流程分析：

對于剛接觸這個流程的我來說，這個流程是規范的，測試真正融入了整個流程，而且還擔任了很重的角色，從而也有效的保證了軟件產品的整體質量。

那么這個流程是不是完美的呢？不，這個項目流程太強化各種文檔。我們來看測試的工作內容，測試計劃、測試用例、測試結論、測試報告、驗收方案、問題的提交跟蹤。其實，我們真用于測試的時間是非常少的，在一周的時間，也許只有一天或不到一天的時間是在進行測試的。測試人員只有在測試的時候才會體現出他的價值。而大部分工作卻不能體現他的價值。

當然，我這里會省略與測試主流程無關的東西，真正的測試工作中瑣事很多。

敏捷測試流程

下面來看敏捷測試，本人并沒有接觸過敏捷，對敏捷也沒花時間學習與研究。唯一接觸就是聽我們測試經理對測度流程講了兩個半小時，聽講的人很多，我站著聽的。受益匪淺，憑著記憶也簡單談談。

前面講的第一種流程，還是第二種流程都是瀑布式的，嚴格來說第一種簡陋的都不能稱為瀑布式，對于一個三個月的項目說，產品把需求分析完了給開發，然后產品就沒事兒了；開發開發完成之后給測試，然后開發人員也不忙了。測試完成之后上線。那么在產品分析的階段，開發和測試都是沒事干的（這里只對單一項目）。開發階段，產品和測試也基本沒事兒。同樣在測試階段，產品與開發也是沒什么事兒的。

敏捷測試的一個核心是迭代，在每個時間點上，所有項目人員都是有事可做的。

1、下面是我理解中的敏捷測試流程圖：

第一階段：

通過上面的流程圖，對于一個月的需求分析，在敏捷中，可能三五天就確定下來。這個需求定得會很模糊，但整體框架確定。產品對其中某一模塊功能確認，開發人員開始對確認的功能編碼，開發人員編碼的過程中，測試進行功能分解，因為根據模糊的需求很難寫出具體的用例，所以，只能盡量對功能進行分析得細些，標注需要驗證的內容。第二階段：

開發完成后交給測試人員進行測試，開發人員繼續開發新的功能。那么測試人員發現的問題怎么辦呢？會從開發團隊中抽出一個人員來用于解決測試發現的問題。但開發進度并沒有因為測試而停止。

流程分析：

在這個流程中弱化了文檔，強調了各個人員的溝通，通過這種迭代的方式，三個月的項目，可以能兩個月和兩個半月就會完成。

但這種流程并非完美，加入一個功能在需求分析階段就是錯誤的，因為它是一個迭代漸進的過程。也只能一路錯下去。

2、對測試問題的處理

上面的圖更能清晰看出對問題的處理過程。

第一塊面板中是開發人員未實現的功能，第二塊面板中是開發完成功能，測試人員對其進行測試，發現不通過的就放回未開發的面板中，測試通過的將放到第三塊面板中。

需要說明的是，敏捷測試在國外很流行，在內容，雷聲大雨點小，推行的人很多，真正有公司引入的不多。我們所在公司千差萬別，測試流程也可能有很大的不同。對于已經工作兩年一個測試員來說，從來沒關注過測試流程與結構應該是個悲劇。我希望不被思想局限，所以，努力沖破一個又一個的局限。

第五篇：測試流程及費用

測試流程及費用

一、測試流程

測試流程支撐系統供應商開始備案并通知測試單位測試機構信息化協會測試申請補充材料材料審核及環境準備準備就緒下一輪重新申請測試修改軟件回歸測試測試確認缺陷是否回歸測試編制測試報告審核不通過提交測試報告審核審核通過向各委辦局、區縣推薦結束

第一步：申請單位對照《北京市電子政務IT運維服務支撐系統規范》決定本單位申請測試的軟件測試項。

第二步：申請單位向北京信息化協會提交《北京市電子政務IT運維服務支撐系統測試申請表》，并在協會公布的測試機構中選擇一家，同時準備測試相關材料。

第三步：信息化協會根據申請單位的申請決定是否受理，并通知測試機構。

第四步：測試機構在收到完整的申報材料后一個工作日內要與申請單位建立聯系，接洽關于測試的相關事宜，開展測試的相關業務。

第五步：測試機構組織測試團隊對申請單位提交的軟件進行測試，軟件缺陷由測試團隊成員與申請單位代表共同簽字確認。第六步：測試機構在測試結束后五個工作日內出具“測試報告”。

第七步：測試機構向北京信息化協會提交“測試報告”，協會根據“北京市電子政務IT運維服務支撐系統規范”對測試報告進行評估。

第八步：通過評估的支撐系統，由北京信息化協會向各委辦局、區縣推薦；未通過評估的支撐系統，由申請單位修改缺陷完善功能，并決定是否進行回歸測試，或進入下一批申請。

二、費用

1.北京信息化協會建議測試費用不超過五萬元。2.每次回歸測試費用不超過原費用的60%。

三、需要向測試機構提供的相關文檔

提交測試申請時申請單位應同時準備以下文檔：

（一）《軟件功能一致性聲明》

申請單位聲明待測的測試項。未聲明的測試項不測試。軟件功能一致性聲明.xls模板如下：

（二）《軟件使用說明書》

申請被測試軟件的使用說明書或用戶手冊。

（三）《安裝配置手冊》

申請被測試軟件的安裝、配置手冊。

（四）《測試用例》

建議申請單位提供內部測試使用的《測試用例》供測試機構參考。

（五）被測單位自行提供的其他特性化文檔 其他有助于測試人員了解被測軟件優點的資料。