軟件測試用例怎么寫
1.測試用例的定義
測試用例就是設計一種情況，軟件程序在這種情況下，能夠正常運行且達到程序所設計的運行結果。如果軟件程序在這種情況下不能正常運行且反復出現這種問題，則可以判定軟件有缺陷，可以記錄在缺陷跟蹤系統中，待問題修復，新版本部署，軟件測試工程師利用同一個用例來回歸測試這個問題，確保問題被修復。
2.測試用例設計方法
（1）等價類劃分法
（2）邊界值分析法
（3）因果圖法
（4）錯誤推薦法
（5）判定表法
（6）正交試驗法
（7）功能圖法
（8）場景法
3.測試用例編寫
測試用例格式：用例編號、所屬模塊、用例名稱、前置條件、用例步驟、預期結果、實際結果、編寫人員、編寫時間
如何寫測試用例
問題一：如何才能寫好一個軟件的測試用例 寫好一個軟件的測試用例的建議有：
1、測試用例名稱，也叫測試用例標題，一定要寫得簡潔、明了，需要用概括的語言描述該用例的出發點和關注點，使得測試人員第一眼看到測試用例名稱就能夠明白測試用例的目的。用例名稱中一般要求不能存在假設性的語句，并且原則上每個用例的名稱不能重復。
2、預置條件要明確，包括測試環境、測試數據、測試場景。因為許多BUG只有在特定的環境、特定的場景下才可以重現。沒有正確的前提條件，就無法進行后面的測試步驟或無法得到預期的結果。
3、測試步驟描述要簡單、清晰，并且要清楚每一個步驟的描述，比如：第一步，輸入用戶姓名；第二步，輸入登錄密碼；第三步，用戶點擊登錄。步驟寫的明確時就利于提高用例的可操作性。
4、用例的預期結果要完整而且清晰，并且要將各個輸出的結果寫出來，包括：返回值的內容、數據庫相關字段的記錄、界面的響應結果、輸出結果的規則符合度、日志的檢查和對其它業務影響的檢查。
5、測試用例級別要劃分清楚，這樣在測試執行時有主次之分。
6、測試用例的劃分也要單一，一個測試用例只檢查功能點的一種情況。一個用例檢查的情況太多，會導致用例的目的不明確。而且這樣組織用例，有利于需求覆蓋率的統計。一個功能點我們測試了哪些情況，以及哪些功能點我們在重點測試，一目了然。
問題二：如何寫好一份測試用例 寫好一個軟件的測試用例的建議有： 1、測試用例名稱，也叫測試用例標題，一定要寫得簡潔、明了，需要用概括的語言描述該用例的出發點和關注點，使得測試人員第一眼看到測試用例名稱就能夠明白測試用例的目的。
問題三：寫測試用例應該怎么寫？我想知道具體的模式。謝謝！ 假設一下吧。現在要求你測試一下百度知道的提交回答功能。
用例編號：提交問題001（編號通常會根據功能或模塊編寫）
測試目的：驗證當用戶回答完問題后，可以正常提交答案。（多數是會寫需求規格的說明，總之要讓人看明白你這條用例是想測什么）
測試標題：這個有時候就包含了測試目的，目的是可以不寫的，但測試用例標題是必須的。
重要級別：像提交回答這條用例，多數會被列為最高級別用例，因為是最基本的功能。往往越是基本的，級別越高。原因在于，如果基本功能都有缺陷，那根本不用測別的功能，版本直接打回。預制條件：1、百度知道運轉正常。2、用戶已登陸。3、進入了自己想要回答的問題頁面。（也就是你做這條測試前必須要有的前提條件）
操作步驟：1、將光標點入“我來幫他解答”下的輸入欄。
2、輸入想提交的答案
3、點擊提交回答
4、驗證提交后答案是否能顯示到當前問題下
（輸入數據多數時候是合并到操作步驟中的，比如這條里的輸入數據就是“答案”）
預期結果：1點擊提交回答后，頁面提示回答成功。2再次查看該問題時,剛剛的答案可以正確顯示……
問題四：編寫測試用例有哪些方法？ 你好！
1.等價類
2.邊界值
3.錯誤推測
4.因果圖
5.判定表
6.正交實驗
7.功能圖
等等，個人感覺前三個最常用了，正交表偶爾用下！
復雜業務可能會用到因果圖！
你可以參考： 360doc/....shtml
問題五：如何高效編寫測試用例 測試用例設計和執行是測試工作的核心，也是工作量最大的任務之一。
測試用例(Test Ca)目前沒有經典的定義。比較通常的說法是：指對一項特定的軟件產品進行測試任務的描述，體現測試方案、方法、技術和策略。內容包括測試目標、測試環境、輸入數據、測試步驟、預期結果、測試腳本等，并形成文檔。
測試用例編寫準備
1
從配置管理員處申請軟件配置：《需求規格說明書》和《設計說明書》；
2
根據需求規格說明書和設計說明書，詳細理解用戶的真正需求，并且對軟件所實現的功能已經準確理解，然后著手制訂測試用例。
測試用例制定的原則
1測試用例要包括欲測試的功能、應輸入的數據和預期的輸出結果。
2測試數據應該選用少量、高效的測試數據進行盡可能完備的測試。
用例覆蓋
1正確性測試：輸入用戶實際數據以驗證系統是滿足需求規格說明書的要求；測試用 例中的測試點應首先保證要至少覆蓋需求規格說明書中的各項功能，并且正常。
2容錯性（健壯性）測試：程序能夠接收正確數據輸入并且產生正確（預期）的輸出， 輸入非法數據（非法類型、不符合要求的數據、溢出數據等），程序應能給出提示 并進行相應處理。把自己想象成一名對產品操作一點也不懂的客戶，在進行任意操作。
3完整（安全）性測試：對未經授權的人使用軟件系統或數據的企圖，系統能夠控制的程度，程序的數據處理能夠保持外部信息（數據庫或文件）的完整。
4接口間測試：測試各個模塊相互間的協調和通信情況，數據輸入輸出的一致性和正確性。
5壓力測試：輸入10條記錄運行各個功能，輸入30條記錄運行，輸入50條記錄進行測試。
6性能：完成預定的功能，系統的運行時間（主要是針對數據庫而言）。
7可理解（操作）性：理解和使用該系統的難易程度（界面友好性）。
8可移植性：在不同操作系統及硬件配置情況下的運行性。
測試方法
1邊界值分析法：確定邊界情況（剛好等于、稍小于和稍大于和剛剛大于等價類邊界值），針對我們的系統在測試過程中主要輸入一些合法數據/非法數據，主要在邊界值附近選取。
2等價劃分：將所有可能的輸入數據（有效的和無效的）劃分成若干個等價類。
3錯誤推測：主要是根據測試經驗和直覺，參照以往的軟件系統出現錯誤之處。
測試用例的填寫
1一個軟件系統或項目共用一套完整的測試用例，整個系統測試過程測試完畢，將實際測試結果填寫到測試用例中，操作步驟應盡可能的詳細，測試結論是指最終的測試結果（結論為：通過或不通過）。
問題六：如何編寫一個完整全面的測試用例 一、編寫測試用例的原則
測試用例的重要性是毋庸置疑的，它是軟件測試全部過程的核心，是測試執行環節的基本依據。測試用例編寫應該遵循的原則：
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 el
12 {
13 if (1 == i_flag)
14 {
15 i_temp = i_temp + 10;
16 }
17 el
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，輸入錯誤的手機號碼，點擊獲取驗證碼 預期結果：提示輸入正確的手機號碼
用例3，輸入英文字母，點擊獲取驗證碼 預期結果：提示輸入正確的手機號碼
用例4，輸入特殊字符，點擊獲取驗證碼 預期結果：提示輸入正確的手機號碼
用例5，輸入超長字符，點擊獲取驗證碼 預期結果：提示輸入正確的手機號碼
用例6，輸入正確的驗證碼，點擊確定 預期結果：驗證通過
用例7，輸入錯誤的驗證碼，點擊確定 預期結果：驗證不通過，提示驗證碼錯誤
用例8，輸入特殊字符的驗證碼，點擊確定 預期結果：驗證不通過，提示驗證碼錯誤
用例8，輸入超長的驗證碼，點擊確定 預期結果：驗證不通過，提示驗證碼錯誤
純手打，忘采納，可以聯系854155141繼續溝通。
測試用例是怎么寫的?
測試用例可以分為基本事件、備選事件和異常事件。設計基本事件的用例，應該參照用例規約（或設計規格說明書），根據關聯的功能、操作按路徑分析法設計測試用例。而對孤立的功能則直接按功能設計測試用例。基本事件的測試用例應包含所有需要實現的需求功能，覆蓋率達100%。
設計備選事件和異常事件的用例，則要復雜和困難得多。例如，字典的代碼是唯一的，不允許重復。測試需要驗證：字典新增程序中已存在有關字典代碼的約束，若出現代碼重復必須報錯，并且報錯文字正確。
往往在設計編碼階段形成的文檔對備選事件和異常事件分析描述不夠詳盡。而測試本身則要求驗證全部非基本事件，并同時盡量發現其中的軟件缺陷。
可以采用軟件測試常用的基該方法：等價類劃分法、邊界值分析法、錯誤推測法、因果圖法、邏輯覆蓋法等設計測試用例。視軟件的不同性質采用不同的方法。如何靈活運用各種基該方法來設計完整的測試用例，并最終實現暴露隱藏的缺陷，全憑測試設計人員的豐富經驗和精心設計。
設計原則
測試用例是一個文檔，是執行的最小實體。測試用例包括輸入、動作、時間和一個期望的結果，其目的是確定應用程序的某個特性是否可正常工作，并且達到程序所設計的結果。
以便測試某個程序路徑或核實是否滿足某個特定需求般在進行測試用例設計前要全面了解被測試產品的功能、明確測試范圍(特別是要明確哪些是不需要測試的)、具備基本的測試技術與方法等。測試用例設計一般遵循以下原則:
(1)正確性。輸入用戶實際數據以驗證系統是否滿足需求規格說明書的要求;測試用例中的測試點應首先保證要至少覆蓋需求規格說明書中的各項功能，并且正常。
(2)全面性。覆蓋所有的需求功能項;設計的用例除對測試點本身的測試外，還需考慮用戶實際使用的情況、與其他部分關聯使用的情況、非正常情況(不合理、非法、越界以及極限輸入數據)操作和環境設置等。
(3)連貫性。用例組織有條理、主次分明，尤其體現在業務測試用例上;用例執行粒度盡量保持每個用例都有測點，不能同時覆蓋很多功能點，否則執行起來牽連太大，所以每個用例間保持連貫性很重要。
(4)可判定性。測試執行結果的正確性是可判定的，每一個測試用例都有相應的期望結果。
(5)可操作性。測試用例中要寫清楚測試的操作步驟，以及與不同的操作步驟相對應的測試結果。
軟件測試的測試用例怎么寫？
●
測試用例編號
◇
規則：編號具有唯一性、易識別性，由數字和字符組合成的字符串
◇
約定：
系統測試用例：產品編號-ST-系統測試項名-系統測試子項名-XXX
集成測試用例：產品編號-IT-集成測試項名-集成測試子項名-XXX
單元測試用例：產品編號-UT-單元測試項名-單元測試子項名-XXX
●
測試項目
◇
規則：當前測試用例所屬測試大類、被測需求、被測模塊、被測單元等
◇
約定：
系統測試用例測試項目：軟件需求項
如：測試手機在沒有SIM卡的情況下，可以撥打緊急電話
集成測試用例測試項目：集成后的模塊名或接口名
如：測試模塊A提供的文件接口
單元測試用例測試項目：被測試的函數名
如：測試函數int
ReadFile(char
*pszFileName)
●
測試標題
規則：測試用例的概括簡單的描述用例的出發點、關注點，原則上不能重復。
●
重要級別
規則
高：保證系統基本功能、核心業務、重要特性、實際使用頻率高的測試用例；
中：重要程度介于高和低之間的測試用例；
低：實際使用頻率不高、對系統業務功能影響不大的模塊或功能的測試用例。
●
預置條件
規則：執行當前測試用例需要的前提條件，是后續步驟的先決條件
●
輸入
規則：用例執行過程中需要加工的外部信息，輸入、文件、數據庫等
●
操作步驟
規則：執行當前測試用例需要經過的操作步驟，保證操作步驟的完整性。
●
預期輸出
規則：當前測試用例的預期輸出結果，包括返回值的內容、界面的響應結果、輸出結果的規則符合度等
測試用例編寫
1.用例編號
從1開始，按順序排列下去
2.測試項目
當前編寫的用例的項目名，可以是測試用例所屬大類，被測需求、被測模塊、或被測單元。如：編寫登錄功能的用例時，此處可以填 “登錄”
*當前測試用例所屬項目，可以區分的更細
3.用例標題
對測試用例的簡單描述
4.重要級別
劃分三個等級，高、中、低
*一般重要級別高的用例，在一個測試項里不宜出現太多
5.預置條件
執行當前用例的需要滿足的前提條件。如：修改用戶信息，預置條件是：當前用戶處于登錄狀態
6.測試輸入
用例執行時，需要外部的輸入信息
7.操作步驟
用例執行時的具體步驟，要求每一步都描寫詳細，保證測試人員可以按照此步驟，順利的執行用例
8.預期結果
指按操作步驟執行時，預期應該出現的結果，用來與測試結果作比對
9.測試結果
指按操作步驟，在實際的產品環境（一般是測試環境）中，執行用例時出現的結果與預期結果的對比，若一致，則寫OK，否則NG
10.測試人員
測試用例的執行人員
11.bugID
用例在實際的產品環境（一般是測試環境）執行時，出現的bug，在bug跟蹤系統上記錄后，記錄在此，便于以后重點測試
1.等價類劃分法
將測試的范圍劃分為幾個互不相交的子集，這幾個子集的并集是全集。再分別從每個子集里選取若干的代表作為測試的輸入
如：測試商品的價格輸入是否有效，限制為不大于9位的全數字。可以用等價類劃分為空、輸入1到9位數字、輸入大于9位數字、輸入1到9位的非數字
輸入為空：“”（無效等價類）
輸入1-9位數字：“0”（有效等價類），“2300”（有效等價類），“000000000”（有效等價類），“120333520”（有效等價類）
輸入大于9位數字：“00000000000”（無效等價類）
輸入1到9位非數字：“aaa!”（無效等價類）
上面抽取的7個值就是通過等價類劃分選出的測試用例。在輸入1-9位數字中，選取了多個輸入值，因為“0”作為價格有特定的含義。“2300”和“120333520”本質上是一樣的，在時間緊的情況下，可只選其一
2.邊界值分析法
邊界值分析法一般作為對等價類劃分法的補充，邊界值來源等價類劃分的邊界。處于邊界附近很容易發生錯誤，用邊界值分析法設計測試用例，對比處于中間范圍的值，可以發現更多的問題。
邊界值分析法，測試用例的選取為：等于邊界值，剛剛大于邊界值，剛剛小于邊界值，作為完整的測試，還應選取一個中間的值作為測試用例。
如：某項值的輸入范圍為1≤X≤10，可選取1，2，4，9，10作為測試用例
*用邊界值分析法可以對等價類劃分法進行補充，在這種情況下，邊界值來源等價類劃分的邊界
3.錯誤推測法
指基于經驗或直覺推測出的程序中可能出現的錯誤，從而有針對性的設計用例
如：可以根據經驗推測，支付時，一些支付失敗的情況。1.支付時，網絡中斷 2.支付時，賬戶余額不足 3.支付時，超過支付時限
4.判定表法
該方法適用于邏輯判斷復雜的場景，通過窮舉法列舉所有條件組合下可能出現的結果，再對結果進行優化整合
條件樁：列出問題所有條件，不受次序的影響
動作樁：列出所有的可能動作
條件項：列出針對它左列條件的取值。在所有可能情況下的真假值
動作項：列出在條件項的各種取值情況下應該采取的動作
判定表法的一般設計步驟：
1. 確定規則的個數。假如有n個條件，每個條件有兩個取值（0，1），故2^n種規則。
2. 列出所有的條件樁和動作樁
3. 填入條件項
4. 填入動作項，得到初始判定表
5. 簡化，合并相似規則（相同動作）
如：功率大于50馬力且維修記錄不全的機器，或已運行10年以上的機器，應給予優先的維修處理。假定，“維修記錄不全”和“優先維修處理”均已在別處有更嚴格的定義，建立判定表
*根據給出的例題進行仿寫，可加深理解
5.正交試驗法
在一項試驗中，把影響試驗結果的量稱為試驗因素(因子)，簡稱因素。因素可以理解為試驗過程中的自變量，試驗結果可以看成因素的函數。在試驗過程中，每一個因素可以處于不同的狀態或狀況，把因素所處的狀態或狀況，稱為因素的水平，簡稱水平。
正交試驗法適用于多因素、多水平試驗，是一種高效率的試驗設計方法。
用正交試驗設計方法設計測試用例時主要包括以下步驟：
1. 確定因素
因素是指對待測功能點有影響的變量。如：判定表法中的條件樁。
2. 確定因素的取值范圍或集合(該步是為步驟3做準備的)
因素的取值范圍是指確定每個因素的可能取值，為每個因素的水平數確定作準備。
3. 確定每個因素的水平
根據因素的取值范圍或集合，采用等價類劃分、邊界值分析以及其他軟件測試技術，在每個因素的取值范圍或集合內挑選出有有代表性的測試值。
(4) 選擇正交表
根據確定的因素k和水平m ，計算出行數L，再選擇適合的正交表。
行數的計算：
（1）各因素的水平數相等 ，稱作單一水平正交表 L=K*（m-1）+1，如3因素，2水平，L=4，表示為：L4（2^3）
（2）因素有多種水平數，稱作混合水平正交表 L＝∑（m－1）＋1，如3因素3水平，2因素2水平，L=3*（3-1）+2*（2-1）+1=9，表示為：L9（3^3*2^2）
正交表的選擇：
（1）單一水平正交表：
如果存在試驗次數等于L，并且水平數大于等于m、因素數大于等于k的正交表，那剛好可以套用現有的正交表。如果不存在試驗次數等于L的正交表，那就得找出滿足試驗次數大于L，并且水平數大于等于m、因素數大于等于k的正交表。如：行數（1）的計算，可選擇L4（3因素2水平）
（2）混合水平正交表：
如果存在試驗次數等于L，并且水平數大于等于max(m1，m2，m3…)、因素數大于等于(k1+k2+k3+…)的正交表，剛好也可以套用現有的正交表
如果不存在試驗次數等于L的正交表，就要找出滿足試驗次數大于L，并且水平數大于等于max(m1，m2，m3…)、因素數大于等于(k1+k2+k3+…)的正交表。如：行數（2）的計算，可選擇L16b（5因素4水平）
當有2個或2個以上正交表可以被選擇時，選取原則是選試驗次數最少的那個正交表。
練習：
Dr. Genichi Taguchi 設計的正交表： Orthogonal Arrays
測試用例的幾種常見設計方法 - 51Testing軟件測試網
測試用例設計方法
測試用例設計方法--正交試驗法詳解（三） - cmriqa的個人空間
測試用例設計之正交法 - CSDN博客
測試用例設計方法 - Molrang - 博客園
編寫測試用例
軟件測試用例就是指導你執行測試，幫助你證明軟件功能或發現軟件缺陷的一種說明。
可以總結為 ：每一個測試點的數據設計的步驟設計。
微信紅包用例？
用例編號：HB_001
功能模塊：發送紅包
測試標題：輸入正確的金額和密碼后，能否正常發送紅包
前提條件：1、網絡正常和錢包有錢
操作步驟：
1、進入紅包發送頁面
2、輸入正確的金額和密碼（）
3、點擊發送按鈕期望結果:發送成功
實際結果：
1測試標題描述一定要包含具體測試點
2.測試步驟一定要包含
3.預期結果一定為唯一，不能出現“發送成功或發送失敗”
測試用例的重要性：
1.便于測試計劃的實施
2.規劃測試數據的準備
3編寫測試腳本的根本
4.評估測試結果的基準
5分析缺陷的標準
1、組成：測試用例文檔由簡介和測試用例兩部分組成。
簡介部分編制測試目的、測試范圍、定義術語、參考文檔、概述等。
測試用例包括 ：用例編號、功能模塊、用例名稱、前提條件、操作步驟、期望結果、實際結果、備注。
2、編寫方式：一般是按照功能+業務邏輯
1）首先保證功能是正常的 2）然后才是功能聯合起來的業務邏輯是對的。比如說：登錄、充值、體現功能分別都是好的，業務邏輯，就是要把所有的功能聯合起來走一遍，看是否好的。
3、用例覆蓋：測試用例旅游分為正常事件和異常事件。
1用例需要評審么？緊急情況用例也需要評審么？
2.一天能夠寫多少用例？執行多條用例？
3.自己寫的用例可以打多少分？
4.如果被測項目很緊急。來不及寫用例，怎么辦
5電梯、雨傘、杯子、筆寫測試點
6遇到隱性需求如何寫用例（需求不明確）
7用例有沒有優先級？如果一定要有優先級，依據什么來確定呢?
8如何編寫測試用例？
