測試用例怎麼編寫?

如何編寫一個好的測試用例

我一直在想，作為測試人員應該用腦袋去測試，也就是說應該在工作中不斷的總結經驗，把自己的發現應用到測試中去，這樣你才能有真正的提高，你所具備的理論和能力才有競爭力。　　回到測試用例中來，我覺得做好以下三點就是一個好的用例。　　第一：依據分明　　眾所周知，一個項目首先立項，然後經過一系列的動作到了需求分析，昨晚需求分析後，測試就可以做測試需求，然後就可以寫測試用例了。所以寫測試用例的依據就是需求。這麼說太籠統，舉一個例子。一個系統經過前期的需求分析，詳細設計，模塊設計等一系列的動作，最後生成了詳細的需求說明和詳細設計文檔等等，在這些文檔中，已經很詳細的描述了所有的需求點和功能點，也有較詳細的技術說明，接下來的工作就是怎麼把這些功能點和需求點變成測試點，這就需要做好測試需求分析和測試方案工作，生成一個個可測試的測試點。這也是需求必須可測的一個體現。　　假設經過上一步工作，分析出這個系統有5個模塊，50個大的功能點，500個具體需求點，最後生成了5000個測試點。那麼 ok，我們就要寫5000個測試用例。還是那句話，一個測試用例只能對應一個測試點，測試點和用例是1對1的關係；一個需求點可以對應多個用例，需求點和用例是1對多的關係。這樣做的目的在統計中講。　　第二：目的明確　　用例都有個測試目的，這就是要目的明確，並且也只能有一個目的。前面無論多少步驟，都是為了找到這個目的途徑。功能從大到小有層次的劃分，我們做測試用例也是有層次的，不然你怎麼定義用例的優先級呢？等到測試最小的功能點是，支持這個功能點的其他上層功能點，我們都默認正確就可以了，這就是我們的預期，所以在測試步驟中不用對上層的功能專門考慮測試數據，只把他當成一個正確的找到目前的功能點的途徑就行。換句話說，你要測試的功能點需要點10個連接才能找到，那麼前9個連接我們再以前就應該設計了用例，在第10個連接中默認他們正確就ok，這個用例的前9步，只是告訴你如何找到第10步。就是這樣。　　第三：便於統計　　測試用例對整個測試過程的質量控制和評估有很重要的意義。　　一，可以做測試需求覆蓋分析。這樣如果一個用例寫幾個測試點，那麼就無法完成需求覆蓋分析工作，至少是不符合規則的。　　你還可以通過模塊劃分，來分析哪個模塊存在的問題較多，還有可能存在更多的問題（應為程序員不同，能力就不同，缺陷喜歡扎堆分佈，這個大家都知道），存在問題較多的模塊需要做進一步的測試或者下一次作為測試重點。如果你統計的數據不準確，會誤導結果的。　　三，做缺陷分析。用例失敗了，就生成一個缺陷。

如何高效編寫測試用例

測試用例設計和執行是測試工作的核心，也是工作量最大的任務之一。

測試用例(Test Case)目前沒有經典的定義。比較通常的說法是：指對一項特定的軟件產品進行測試任務的描述，體現測試方案、方法、技術和策略。內容包括測試目標、測試環境、輸入數據、測試步驟、預期結果、測試腳本等，並形成文檔。

測試用例編寫準備

1

從配置管理員處申請軟件配置：《需求規格說明書》和《設計說明書》；

2

根據需求規格說明書和設計說明書，詳細理解用戶的真正需求，並且對軟件所實現的功能已經準確理解，然後著手製訂測試用例。

測試用例制定的原則

1測試用例要包括欲測試的功能、應輸入的數據和預期的輸出結果。

2測試數據應該選用少量、高效的測試數據進行儘可能完備的測試。

用例覆蓋

1正確性測試：輸入用戶實際數據以驗證系統是滿足需求規格說明書的要求；測試用 例中的測試點應首先保證要至少覆蓋需求規格說明書中的各項功能，並且正常。

2容錯性（健壯性）測試：程序能夠接收正確數據輸入並且產生正確（預期）的輸出， 輸入非法數據（非法類型、不符合要求的數據、溢出數據等），程序應能給出提示 並進行相應處理。把自己想象成一名對產品操作一點也不懂的客戶，在進行任意操作。

3完整（安全）性測試：對未經授權的人使用軟件系統或數據的企圖，系統能夠控制的程度，程序的數據處理能夠保持外部信息（數據庫或文件）的完整。

4接口間測試：測試各個模塊相互間的協調和通信情況，數據輸入輸出的一致性和正確性。

5壓力測試：輸入10條記錄運行各個功能，輸入30條記錄運行，輸入50條記錄進行測試。

6性能：完成預定的功能，系統的運行時間（主要是針對數據庫而言）。

7可理解（操作）性：理解和使用該系統的難易程度（界面友好性）。

8可移植性：在不同操作系統及硬件配置情況下的運行性。

測試方法

1邊界值分析法：確定邊界情況（剛好等於、稍小於和稍大於和剛剛大於等價類邊界值），針對我們的系統在測試過程中主要輸入一些合法數據/非法數據，主要在邊界值附近選取。

2等價劃分：將所有可能的輸入數據（有效的和無效的）劃分成若干個等價類。

3錯誤推測：主要是根據測試經驗和直覺，參照以往的軟件系統出現錯誤之處。

測試用例的填寫

1一個軟件系統或項目共用一套完整的測試用例，整個系統測試過程測試完畢，將實際測試結果填寫到測試用例中，操作步驟應儘可能的詳細，測試結論是指最終的測試結果（結論為：通過或不通過）。

寫測試用例應該怎麼寫？我想知道具體的模式。謝謝！

假設一下吧。現在要求你測試一下百度知道的提交回答功能。

用例編號：提交問題001（編號通常會根據功能或模塊編寫）

測試目的：驗證當用戶回答完問題後，可以正常提交答案。（多數是會寫需求規格的說明，總之要讓人看明白你這條用例是想測什麼）

測試標題：這個有時候就包含了測試目的，目的是可以不寫的，但測試用例標題是必須的。

重要級別：像提交回答這條用例，多數會被列為最高級別用例，因為是最基本的功能。往往越是基本的，級別越高。原因在於，如果基本功能都有缺陷，那根本不用測別的功能，版本直接打回。預製條件：1、百度知道運轉正常。2、用戶已登陸。3、進入了自己想要回答的問題頁面。（也就是你做這條測試前必須要有的前提條件）

操作步驟：1、將光標點入“我來幫他解答”下的輸入欄。

2、輸入想提交的答案

3、點擊提交回答

4、驗證提交後答案是否能顯示到當前問題下

（輸入數據多數時候是合併到操作步驟中的，比如這條裡的輸入數據就是“答案”）

預期結果：1點擊提交回答後，頁面提示回答成功。2再次查看該問題時,剛剛的答案可以正確顯示……

如何編寫一個完整全面的測試用例

一、編寫測試用例的原則

測試用例的重要性是毋庸置疑的，它是軟件測試全部過程的核心，是測試執行環節的基本依據。測試用例編寫應該遵循的原則：

1、測試用例要達到最大覆蓋軟件系統的功能點。測試工程師應該測試計劃編寫完成之後，在開發階段編寫測試用例，參考需求規格說明書和軟件功能點對每個功能點進行操作上的細化，儘可能趨向最大需求覆蓋率。

2、測試用例對測試功能點、測試條件、測試步驟、輸入值和預期結果應該有準確的定義。

3、 測試用例的設計應包括各種類型的測試用例。在設計測試用例的時候，除了滿足系統基本功能需求外，還應該考慮各種異常情況、邊界情況和承受壓力的能力等。

4、 測試用例的管理。使用測試用例管理系統對測試用例進行管理。

一個好的測試用例應該具有較高的發現某個尚未發現的錯誤的可能性，而一個成功的測試案例能夠發現某個尚未發現的錯誤，通常一個好的測試案例有以下特性：

1、具有高的發現錯誤的概率

2、沒有冗餘測試和冗餘的步驟

3、測試是“最佳類別”

4、既不太簡單也不太複雜

5、案例是可重用和易於跟蹤的.

6、確保系統能夠滿足功能需求

測試用例不可能設計得天衣無縫，也不可能完全滿足軟件需求的覆蓋率，測試執行過程裡肯定會發現有些測試路徑或數據在用例裡沒有體現，那麼事後該將其補充到用例庫裡，以方便他人和後續版本的測試。

二、如何編寫測試用例

測試用例的信息有很多，可以根據實際的情況進行增刪，一般來說一個優秀的測試用例應該包含以下信息：

1、產品相關信息

（1）軟件產品或項目的名稱

（2）軟件產品或項目的版本

（3）功能模塊名

（4）功能描述

（5）測試平臺

這些信息建議可以在測試案例手工選擇。

2、基本記錄信息

（1）測試用例入庫者

（2）測試用例入庫時間

（3）測試用例更新者

（4）測試用例更新時間

這些信息建議可以由測試案例自動生成。

3、測試用例的屬性

（1）測試用例ID：測試用例的ID（由案例管理系統自動生成，方便跟蹤管理）

（2）測試用例名稱：測試用例的名稱

（3）測試功能點：測試的功能檢查點

（4）測試目的：該測試功能點的測試目的

（5）測試級別：主路徑測試、煙霧測試、基本功能測試、詳細功能測試。

下面對這幾個測試級別進行說明：

A、主路徑測試：對照需求中重要模塊和功能的最主要功能路徑，主路徑測試為設計探針模塊，快速檢查程序的可測試性（可測試性還包括安裝測試是否成功）的主要依據的測試案例

B、煙霧測試：對照需求中所有模塊的主要功能路徑，主路徑測試案例為煙霧測試案例的子集，煙霧測試為做迴歸測試的主要依據的測試案例。

C、基本功能測試：對照需求和總體設計中所有模塊和功能的基本功能路徑，基本功能測試為測試軟件產品的非重要級別模塊，書寫完全的自動測試腳本的主要依據。

D、詳細功能測試：對照總體設計中所有模塊和功能的功能路徑，測試各個模塊及功能各個層次，各種類型。詳細功能測試案例為對重點模塊，易發生錯誤的模塊的主要依據。

（6）測試類型：功能測試、邊界測試、異常測試、性能測試、壓力測試、兼容測試、安全測試、恢復測試、安裝測試、界面測試、啟動/停止測試、文檔測試、配置測試、可靠性測試、易用性測試、多語言測試。

（7）預置條件：對測試的特殊條件或配置進行說明

（8）測試步驟：詳細描述測試過程，案例的操作步驟建議少於15個。

（9）預期結果：預期的測試結果

三、測試用例設計過程

對一個全新的產品來說，首先需要了解的是產品需求文檔和產品模塊之間的關係。然後需要從需求文檔中書寫與所有需求相對應的主路徑測試案例和煙霧測試案例，這個時......

如何編寫單元測試用例

一、 單元測試的概念

單元通俗的說就是指一個實現簡單功能的函數。單元測試就是隻用一組特定的輸入(測試用例)測試函數是否功能正常，並且返回了正確的輸出。

測試的覆蓋種類

1.語句覆蓋：語句覆蓋就是設計若干個測試用例，運行被測試程序，使得每一條可執行語句至少執行一次。

2.判定覆蓋（也叫分支覆蓋）：設計若干個測試用例，運行所測程序，使程序中每個判斷的取真分支和取假分支至少執行一次。

3.條件覆蓋：設計足夠的測試用例，運行所測程序，使程序中每個判斷的每個條件的每個可能取值至少執行一次。

4.判定——條件覆蓋：設計足夠的測試用例，運行所測程序，使程序中每個判斷的每個條件的每個可能取值至少執行一次，並且每個可能的判斷結果也至少執行一次。

5.條件組合測試：設計足夠的測試用例，運行所測程序，使程序中每個判斷的所有條件取值組合至少執行一次。

6.路徑測試：設計足夠的測試用例，運行所測程序，要覆蓋程序中所有可能的路徑。

用例的設計方案主要的有下面幾種：條件測試，基本路徑測試，循環測試。通過上面的方法可以實現測試用例對程序的邏輯覆蓋，和路徑覆蓋。

二、開始測試前的準備

在開始測試時，要先聲明一下，無論你設計多少測試用例，無論你的測試方案多麼完美，都不可能完全100%的發現所有BUG，我們所需要做的是用最少的資源，做最多測試檢查，尋找一個平衡點保證程序的正確性。窮舉測試是不可能的。所以現在進行單元測試我選用的是現在一般用的比較多的基本路徑測試法。

三、開始測試

基本路徑測試法：設計出的測試用例要保證每一個基本獨立路徑至少要執行一次。

函數說明 ：當i_flag=0；返回 i_count+100

當i_flag=1；返回 i_count *10

否則 返回 i_count *20

輸入參數：int i_count ，

int i_flag

輸出參數： int i_return;

代碼：

1 int Test(int i_count, int i_flag)

2 {

3 int i_temp = 0;

4 while (i_count>0)

5 {

6 if (0 == i_flag)

7 {

8 i_temp = i_count + 100;

9 break;

10 }

11 else

12 {

13 if (1 == i_flag)

14 {

15 i_temp = i_temp + 10;

16 }

17 else

18 {

19 i_temp = i_temp + 20;

20 }

21 }

22 i_count--;

23 }

21 }

22 i_count--;

23 }

24 return i_temp;

25 }

1.畫出程序控制流程圖

圈中的數字代表的是語句的行號，也許有人問為什麼選4,6,13,8......作為結點，第2行，第3行為什麼不是結點，因為選擇結點是有規律的。讓我們看程序中；第2行，第3行是按順序執行下來的。直到第4行才出現了循環操作。而2，3行沒有什麼判斷，選擇等分支操作，所以我們把2，3，4全部合併成一個結點。其他的也是照這個規則合併，然後就有了上面的流程圖。

2.計算圈複雜度

有了圖以後我們要知道到底我們有寫多少個測試用例，才能滿足基本路徑測試。

這裡有有了一個新概念——圈複雜度

圈複雜度是一種為程序邏輯複雜性提供定量測試的軟件度量。將該度量用於計算程序的基本獨立路徑數目。為確保所有語句至少......

軟件測試中，測試用例怎麼寫，想要一個簡單

你好，可以參考：

測試也很累的喔，還有你可以找找：史上最全測試用例設計方法

一、界面規範

1.是否整個軟件的字段的字體、大小、顏色、排列一致

2.是否整個軟件的字段後都有冒號（如果有，是否都屬於同一種字體）

二、用例編寫粒度準則

1.對於不作為一個完整業務流的操作，如增、刪、改等，每個操作（比如增加）作為一個用例。

2.對於完整的業務功能實現的操作，把實現一個業務功能的目的作為一個用例。

3.對於緊密關聯的業務功能，把關聯的業務功能實現作為一個用例。

4.對於異常情況下的操作，作為一個用例。

5.對於在異常情況下的操作的數據處理，作為一個用例。

編寫測試用例有哪些方法

1. 等價類劃分 如下圖所示

2. 邊界值：應選取正好等於、剛剛大於、剛剛小於邊界值作為測試數據

3. 錯誤推測法：進行錯誤的操作，驗證程序是否對出錯的場 景和情況有應對能力。4. 因果圖法/判定表法：適合於檢查程序輸入條件的各種組合情況。5. 場景法：場景描述的業務流程 基本流：主要是功能的正常操作流程 分支流：需要程序做非法判斷處理

如何才能寫好一個軟件的測試用例

寫好一個軟件的測試用例的建議有：

1、測試用例名稱，也叫測試用例標題，一定要寫得簡潔、明瞭，需要用概括的語言描述該用例的出發點和關注點，使得測試人員第一眼看到測試用例名稱就能夠明白測試用例的目的。用例名稱中一般要求不能存在假設性的語句，並且原則上每個用例的名稱不能重複。

2、預置條件要明確，包括測試環境、測試數據、測試場景。因為許多BUG只有在特定的環境、特定的場景下才可以重現。沒有正確的前提條件，就無法進行後面的測試步驟或無法得到預期的結果。

3、測試步驟描述要簡單、清晰，並且要清楚每一個步驟的描述，比如：第一步，輸入用戶姓名；第二步，輸入登錄密碼；第三步，用戶點擊登錄。步驟寫的明確時就利於提高用例的可操作性。

4、用例的預期結果要完整而且清晰，並且要將各個輸出的結果寫出來，包括：返回值的內容、數據庫相關字段的記錄、界面的響應結果、輸出結果的規則符合度、日誌的檢查和對其它業務影響的檢查。

5、測試用例級別要劃分清楚，這樣在測試執行時有主次之分。

6、測試用例的劃分也要單一，一個測試用例只檢查功能點的一種情況。一個用例檢查的情況太多，會導致用例的目的不明確。而且這樣組織用例，有利於需求覆蓋率的統計。一個功能點我們測試了哪些情況，以及哪些功能點我們在重點測試，一目瞭然。

如何編寫測試用例？

隨著中國軟件業的日益壯大和逐步走向成熟，軟件測試也在不斷髮展。從最初的由軟件編程人員兼職測試到軟件公司組建獨立專職測試部門。測試工作也從簡單測試演變為包括：編制測試計劃、編寫測試用例、準備測試數據、編寫測試腳本、實施測試、測試評估等多項內容的正規測試。我們公司一直使用日事清來完成軟件測試的編寫、執行等工作。通過日事清看板按照項目、部門、時間等維度組織團隊工作清單，梳理團隊任務，創建團隊工作計劃，讓團隊工作可視化。建立在看板的任務會落實到人，這些任務會自動分解至團隊相關成員的個人日程中去，讓個人的日程和團隊的工作安排打通，實時跟進。通過這樣的方式，使團隊有計劃、有反饋、有總結、有調整，基於此就形成一個完整的“戴明環”，保證了測試團隊的效率和質量。

軟件測試的重要性是毋庸置疑的。但如何以最少的人力、資源投入，在最短的時間內完成測試，發現軟件系統的缺陷，保證軟件的優良品質，則是軟件公司探索和追求的目標。每個軟件產品或軟件開發項目都需要有一套優秀的測試方案和測試方法。

影響軟件測試的因素很多，例如軟件本身的複雜程度、開發人員（包括分析、設計、編程和測試的人員）的素質、測試方法和技術的運用等等。因為有些因素是客觀存在的，無法避免。有些因素則是波動的、不穩定的，例如開發隊伍是流動的，有經驗的走了，新人不斷補充進來；一個具體的人工作也受情緒等影響，等等。如何保障軟件測試質量的穩定？有了測試用例，無論是誰來測試，參照測試用例實施，都能保障測試的質量。可以把人為因素的影響減少到最小。即便最初的測試用例考慮不周全，隨著測試的進行和軟件版本更新，也將日趨完善。

因此測試用例的設計和編制是軟件測試活動中最重要的。測試用例是測試工作的指導，是軟件測試的必須遵守的準則。更是軟件測試質量穩定的根本保障。

軟件測試用例怎麼編寫

你好，可以參考：

測試也很累的喔，還有你可以找找：史上最全測試用例設計方法

一、界面規範

1.是否整個軟件的字段的字體、大小、顏色、排列一致

2.是否整個軟件的字段後都有冒號（如果有，是否都屬於同一種字體）

二、用例編寫粒度準則

1.對於不作為一個完整業務流的操作，如增、刪、改等，每個操作（比如增加）作為一個用例。

2.對於完整的業務功能實現的操作，把實現一個業務功能的目的作為一個用例。

3.對於緊密關聯的業務功能，把關聯的業務功能實現作為一個用例。

4.對於異常情況下的操作，作為一個用例。

5.對於在異常情況下的操作的數據處理，作為一個用例。