測試用例生成方法(測試用例是幹什麼的)

一：熟悉的測試用例設計方法皆有哪些?

1、 等價類劃分

常常見到的軟件測試面試題劃分等價類: 等價類是指某個輸入域的子集合。在該子集合中，各個輸入數據對於揭露流程中的錯誤都是等效的。並合理地假定:測試某等價類的代表值就等於對這一類其它值的測試。因此，可以把全部輸入數據合理劃分為若幹等價類，在每一個等價類中取一個數據作為測試的輸入條件，就能夠用少量表現性的測試數據。取得較好的測試結果。等價類劃分可有兩種不一樣的情形:有效等價類和無效等價類。

2、 邊界值剖析法

邊界值剖析方法是對等價類劃分方法的補充。測試工作經驗告知我，大量的錯誤是發生在輸入或輸出范圍的邊界上，並不是發生在輸入輸出范圍的內部。因此針對各式邊界情況設計測試用例，可以查出更加的多的錯誤。

使用邊界值剖析方法設計測試用例，first of all應確定邊界情況。通常輸入和輸出等價類的邊界，就是應著重測試的邊界情況。應當選取正好等於，剛剛大於或剛剛小於邊界的值作為測試數據，並不是選取等價類中的典型值或任意值作為測試數據。

二：測試用例的幾種常見設計方法

一、等價類劃分

         定義： 把全部輸入數據合理劃分為若幹等價類，在每一個等價類中取一個數據作為測試的輸入條件，用少量表現性的測試數據，取得較好的測試結果。等價類劃分可有兩種不一樣的情形：有效等價類和無效等價類。

1）確定等價類

             有效等價類：     滿足輸入條件的

             無效等價類：     不能滿足輸入條件的     超出范圍的數值  

            空值   

            特殊字符   

            有空格（前、中、後）

2）生成測試用例

每個等價類編寫一個測試用例；

設計一條測試用例，盡可能多地覆蓋所有還未被覆蓋的有效等價類；

設計一條測試用例，覆蓋一條還未被覆蓋到的無效等價類。

等價類劃分的六大原則：

1）輸入條件規定瞭取值范圍或值的個數的情形下，那麼可以確立一個有效等價類和兩個無效等價類。

比如：手機號碼由11位數字組成

有效：11位符合電話號碼規則的數字

無效：1。小於11位數字；2。大於11位數字

2）在輸入條件規定瞭輸入值的集合或者規定瞭“必須怎樣”的條件的情形下，可以確立一個有效等價類和一個無效等價類。

3）在輸入條件是一個佈爾量的情形下，可確定一個有效等價類和一個無效等價類。佈爾量是一個二值枚舉類型，一個佈爾量具有兩種狀態：true和false

4）在規定瞭輸入數據的一組值（假定n個），並且流程要對每一個輸入值分別處理的情形下，可確立n個有效等價類和一個無效等價類。

比如：

輸入條件說明輸入為：中文、英文、數字三種之一，則分別取這三種值作為三個有效等價類，另外把這三種字符以外的任何字符作為無效等價類

5）在規定瞭輸入數據必須遵守的規則的情形下，可確立一個有效等價類（符合規則）和若幹個無效等價類（從不同角度違反規則）

比如：輸入條件說明每個學生可選修1~3門課程

有效：選修1~3門課程

無效：1。未選修課程

            2。選修課程超過3門

6）在確知已劃分的等價類中各元素在流程處理中的方式不同的情形下，則應再將該等價類進一步的劃分為更小的等價類。

等價類劃分法要點：長度、類型、字母、漢字、特殊字符、空、空格

二、邊界值剖析法

邊界值剖析方法是對等價類劃分方法的補充。

使用邊界值剖析方法設計測試用例，first of all應確定邊界情況。通常輸入和輸出等價類的邊界，就是著重測試邊界的情形。選取正好等於，剛剛大於或剛剛小於邊界值的值作為測試數據，並不是選取等價類中的典型值或任意值作為測試數據。

1）假如輸入條件規定瞭一個輸入值范圍，那麼應針對范圍的邊界設計測試用例，針對剛剛越界的情形設計無效輸入測試用例；

打比方說：需求規定輸入的數字在0~100范圍內，此時測試數據應該有一下幾類：

a。剛剛等於邊界：0、100；

b。剛剛超出邊界范圍：-1。101:；

c。剛剛在范圍內：1。99

2）假如輸入條件規定瞭輸入值的數量，那麼應針對最小數量輸入值、最大數量輸入值，以及比最小數量少一個、比最大數量多一個的情形設計測試用例；

例1：輸入手機號碼有：

a 輸入11位合法數字；b 輸入10 位合法數字；c 輸入12位合法數字

例2：輸入6~8位數字密碼：

a 輸入6位數字；b 輸入8位數字c 輸入5位數字；d 輸入9位數字

3）假如流程輸入或輸出是一個有序序列，則應該特別註意和提防該序列的第1個和最後一個元素。

三、錯誤推測法

錯誤推測法是基於經驗和直覺推測流程中所有可能存在的各式錯誤，從而有針對性的設計測試用例的方式方法。需要多實踐，且在實踐時多積累常見問題。

      錯誤推測方法的基本思想： 列舉出流程中所有也許有的錯誤和容易發生錯誤的特殊情況，依據他們選擇測試用例-例如， 在單元測試時曾列出的很多在模塊中常常見到的錯誤-以前產品測試中曾經發現的錯誤等， 這幾個就是經驗的匯總。還有， 輸入數據和輸出數據為0的情形。輸入表格為空格或輸入表格僅有一行-這幾個都是容易發生錯誤的情形。可選擇這幾個情況下的例子作為測試用例。

四、因果圖法

        因果圖法適合使用於描述對於多種輸入條件組合的測試方法。（有多步輸入操作）

        依據輸入條件的組合、管束條件和輸出條件的因果關系，剖析輸入條件的各式組合情況，從而設計測試用例的方式方法，它適合使用於檢查流程輸入條件涉及的各式組合情況。

例題：有一個處理單價為1元5角錢的盒裝飲料的自動售貨機軟件。若投入1元5角硬幣，按下“可樂”、“雪碧”、“紅茶”按鈕，對應的飲料就送出來。若投入的是兩元硬幣，在送出飲料的同時退還5角硬幣。

剖析：

輸入條件：a  投入1元5角硬幣      b  投入2元硬幣

1  按“可樂”按鈕        2  按“雪碧”按鈕      3  按“紅茶”按鈕

中間狀態：1  已投幣      2  已按按鈕

輸出結果：A  送出可樂  B  送出雪碧    C  送出紅茶    D  退還5角硬幣

測試用例：

1）投幣1元5角，按“可樂”按鈕，送出可樂

2）投幣1元5角，按“雪碧”按鈕，送出雪碧

3）投幣1元5角，按“紅茶”按鈕，送出紅茶

4）投幣2元，按“可樂”按鈕，送出可樂，退5角硬幣

5）投幣2元，按“雪碧”按鈕，送出雪碧，退5角硬幣

6）投幣2元，按“紅茶”按鈕，送出紅茶，退5角硬幣

輸入組合：投硬幣+按按鈕

結果組合：送出飲料+退錢

三：測試用例設計方法

一、用例介紹

1、定義

為某個業務目標，而編制的一組由測試輸入，執行條件以及預期結果組成的案例

2、為啥要學習測試用例？

在開始實施測試之前規劃好測試用例，可以避開盲目測試並提高測試效率。

測試用例的使用令軟件測試的實施重點突出、目的明確。

在軟件版本更新後僅需修正少部分的測試用例便可展開測試工作，降低工作強度、縮短項目周期。

檢驗軟件是否滿足客戶需求、展現一個測試人員的工作量、體現測試用例的設計思路。

3、用例核心要素（16個）

3、1  必須掌握：

用例編號(怎樣命名)、所屬模塊、用例標題（驗證誰在怎麼回事下，去做什麼，最終結果是什麼）、優先級、前置條件、方法步驟、測試數據、預期結果、實際結果

3、2  瞭解內容：

通過否、bugID、編寫人員、編寫時間、測試人員、測試時間、備註

3、3  接口測試三大要素：

路由、參數、類型

3、4 何謂高質量的測試用例

1、測試用例覆蓋所有的用戶需求

2、測試用例要簡單並且明瞭

3、各類型的測試用例要齊全

4、用最少的用例覆蓋最多的需求

二、等價類劃分法

1、定義

等價類劃分 是把所有可能輸入的數據分為若幹個區域，緊接著從每個區域中取少量有表現性的數據進行測試即可。

等價類 ：何為等價類，某個輸入域的集合，在這個集合中每個輸入條件都是等效的。

2、分類

一般可分為 有效等價類 和 無效等價類 。

有效等價類：指符合《需求規格說明書》，輸入合理的數據集合

無效等價類：指不符合《需求規格說明書》，輸入不合理的數據集合

3、案例

3、1郵箱登錄

3、2  QQ號註冊

三、邊界值法

1、定義：

邊界值法設計測試用例，是對輸入或輸出的邊界值（有效等價類和無效等價類的界限）進行測試的一種黑盒測試方法。

2、邊界值法存在的意義：

測試研究表明錯誤常常會發生在輸入或輸出范圍的邊界上，所以邊界值法是對這幾個邊界進行測試，是對劃分等價類法的一種補充。

3、確定邊界值的方式方法

上點： 邊界上的點（符合條件的邊界點），不管此時的域是開區間還是閉區間，開區間的話，上點就是在域外，閉區間的話，上點就是在域內。

內點： 邊界內的任意點。

離點： 是指離上點近日的左右兩點。這裡就跟是閉區間還是開區間就有關系瞭，假如是開區間，那麼離點就在域內，假如是閉區間，那麼離點就在域外。(開內閉外)

遵循的原則：開內閉外 開區間往中間找，閉區間往外找

 （如下圖）

4、案例

5、邊界值剖析法拓展

鏈接：https://www。jianshu。com/p/3ce340fe6b95

四：軟件測試用例的幾種設計方法

1、 邊界值剖析法：

指對輸入的邊界條件進行剖析，設計出針對邊界值的測試用例。

數值的邊界值檢驗

字符的邊界值檢驗

如： ASCII和 Unicode編碼方式

其他邊界值檢驗

選上所有選項(最大值)

不選上任何一項(空，零)

隻選一項 (最小值)

2、 等價類劃分法：

有效等價類：指輸入完全滿足流程輸入的規格說明，是由有效且有意義的輸入數據所構成的集合，利用有效等價類可以檢驗流程是否滿足規格說明所規定的功能和 性能 。

無效等價類：和有效等價類相反，即不滿足流程輸入要求或者由無效的輸入數據構成的集合。

3、 因果圖法：

就是利用圖解法剖析軟件輸入(原因)和輸出條件(結果)之間的聯系，以設計測試用例的方式方法。因果圖法適合於檢查流程輸入條件的多種情況的組合，並最終生成判定表，來獲得相應的測試用例。

4、 功能圖法

功能圖是描述流程狀態變化、轉移的過程，由於軟件運行或操作的過程可以看作是其狀態不斷發生變化的過程。測試用例的設計就是怎樣覆蓋所有軟件展現出來的狀態，即在滿足輸入/輸出的一組條件下，軟件運行是一系列有一次序的、受控制的狀態變化過程。

5、 錯誤推測法：

推測法主要依賴經驗、直覺來作出簡單容易的判斷甚至是猜測，給出可能存在 缺陷 的條件、場景等，在找到缺陷後，設計出對應的測試用例。

6、 正交實驗設計方法：

主要步驟是：

(1) 對軟件 需求 規格說明中的功能要求進行劃分(層層分解與展開)，分解成具體的、相對單獨的基本功能。

(2) 依據基本功能的 質量 需求，找出作用與影響其功能實現的操作對象和外部因素，每個因素的取值可以看作水平，多個取值就存在多個水平。

(3) 確定待測試軟件中所有因素及其權值，這是 測試用例設計 的關鍵，確保全面、準確。

權值是根據各因素的作用與影響范圍、發生的頻率和質量的需求來核實確定的。

(4) 加權篩選，生成因素剖析表。

(5) 利用正交表構造測試數據集，正交表的每一行，就是一條測試用例。考慮交互作用不可忽視的處理因素和不可混雜的原則，有交互作用的組合優先安排。

五：怎樣寫測試用例

提問一：怎樣才能寫好一個軟件的測試用例 寫好一個軟件的測試用例的意見有：

1。測試用例名稱，亦稱測試用例標題，務必要寫得簡潔、明瞭，需要用概括的語言描述該用例的出發點和關註點，使得測試人員第1眼看見測試用例名稱就可以清楚明白測試用例的目的。用例名稱中一般要求不能存在假設性的語句，並且原則上每個用例的名稱不能重復。

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

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

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

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

6。測試用例的劃分也要單一，一個測試用例隻檢查功能點的一種情況。一個用例檢查的情形太多，會致使用例的目的不明確。而且這樣組織用例，能夠起到好作用的需求覆蓋率的統計。一個功能點我們測試瞭哪些情況，以及哪些功能點我們在重點測試，一目瞭然。

提問二：怎樣寫好一份測試用例 寫好一個軟件的測試用例的意見有： 1。測試用例名稱，亦稱測試用例標題，務必要寫得簡潔、明瞭，需要用概括的語言描述該用例的出發點和關註點，使得測試人員第1眼看見測試用例名稱就可以清楚明白測試用例的目的。

提問三：寫測試用例應該怎麼寫？我想瞭解具體的模式。謝謝！ 假設一下吧。此刻要求你測試一下百度知道的提交回答功能。

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

測試目的：驗證當用戶回答完問題後，可以正常提交答案。（大部分是會寫需求規格的說明，也就是說要使人看清楚明白你這條用例是想測什麼）

測試標題：這個偶爾就蘊含瞭測試目的，目的是可以不寫的，但測試用例標題是必須的。

重要級別：像提交回答這條用例，大部分會被列為最高檔別用例，由於是最基本的功能。常常越是基本的，級別越高。原因就是，假如基本功能皆有缺陷，那根本不用測別的功能，版本直接打回。預制條件：1。百度知道運轉正常。2。用戶已登陸。3。進入瞭自己想要回答的問題頁面。（亦即你做這條測試前務 必要有的前提條件）

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

2。輸入想提交的答案

3。點擊提交回答

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

（輸入數據大部分時候是合並到方法步驟中的，打比方說這條裡的輸入數據就是“答案”）

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

提問四：編寫測試用例有什麼樣的方法？ 你好！

1、等價類

2、邊界值

3、錯誤推測

4、因果圖

5、判定表

6、正交實驗

7、功能圖

等等，個人感覺前三個最常用瞭，正交表有時候用下！

復雜業務也許會用到因果圖！

你不妨參考： 360doc/。。。。shtml

提問五：怎樣高效編寫測試用例 測試用例設計和執行是測試工作的核心，也是工作量最大的任務之一。

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

測試用例編寫準備

1

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

2

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

測試用例制定的原則

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

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

用例覆蓋

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

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

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

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

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

6性能：完成預定的功能，系統的運行時間（著重是針對數據庫來講）。

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

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

測試方法

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

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

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

測試用例的填寫

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

問題六：怎樣編寫一個完整全面的測試用例 一、編寫測試用例的原則

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

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

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

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

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

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

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

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

3。測試是“最佳類別”

4。既不太簡單也不太復雜

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

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

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

二、怎樣編寫測試用例

測試用例的信息有許多，可以依據實際的情形進行增刪，一般而講一個出色的測試用例應該蘊含以下信息：

1。產品有關信息

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

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

（三）功能模塊名

（四）功能描述

（五）測試平臺

這幾個信息建議能在測試案例手工選擇。

2。基本記錄信息

（一）測試用例入庫者

（二）測試用例入庫時間

（三）測試用例更新者

（四）測試用例更新時間

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

3。測試用例的屬性

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

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

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

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

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

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

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

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

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

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

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

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

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

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

三、測試用例設計過程

對一個全新的產品來說，first of all需要明白的是產品需求文檔和產品模塊之間的聯系。緊接著需要從需求文檔中書寫與所有需要相相應的主路徑測試案例和煙霧測試案例，這個時。。。。。。>>

問題七：怎樣編寫單元測試用例 一、 單元測試的概念

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

測試的覆蓋種類

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 }

二十四 return i_temp;

25 }

1、畫出流程控制程序圖

圈中的數字代表的是語句的行號，可能有人問為啥選4，6，13，8、。。。。。作為結點，第二行，第三行為啥不是結點，由於選擇結點是有規律的。使俺們看流程中；第二行，第三行是按順序執行下來的。直到第四行才顯現瞭循環操作。而2，3行沒有啥判斷，選擇等分支操作，因此我們把2，3，4全部合並成一個結點。其他別的也是照這個原則合並，緊接著就有瞭上面的程序圖。

2、計算圈復雜度

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

這裡有有瞭一個新概念――圈復雜度

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

問題八：怎樣寫好測試用例的設計心得 先分測試類型，再依據數據流設計測試模塊，整理好測試檢查點，最後設計點詭異的測試用例

問題九：測試用例怎樣寫 用例1，輸入正確的手機號碼，點擊獲取驗證碼 預期結果：手機收到驗證碼

用例2，輸入錯誤的手機號碼，點擊獲取驗證碼 預期結果：提示輸入正確的手機號碼

用例3，輸入英文字母，點擊獲取驗證碼 預期結果：提示輸入正確的手機號碼

用例4，輸入特殊字符，點擊獲取驗證碼 預期結果：提示輸入正確的手機號碼

用例5，輸入超長字符，點擊獲取驗證碼 預期結果：提示輸入正確的手機號碼

用例6，輸入正確的驗證碼，點擊確定 預期結果：驗證通過

用例7，輸入錯誤的驗證碼，點擊確定 預期結果：驗證不通過，提示驗證碼錯誤

用例8，輸入特殊字符的驗證碼，點擊確定 預期結果：驗證不通過，提示驗證碼錯誤

用例8，輸入超長的驗證碼，點擊確定 預期結果：驗證不通過，提示驗證碼錯誤

純手打，忘采納，可以聯系854155141繼續溝通。

六：測試用例是怎麼寫的?

測試用例可以分為基本事件、備選事件和異常事件。設計基本事件的用例，應該參照用例規約（或設計規格說明書），依據關聯的功能、操作按路徑剖析法設計測試用例。而對孤立的功能則直接按功能設計測試用例。基本事件的測試用例應蘊含所有需求實現的需求功能，覆蓋率達100%。

設計備選事件和異常事件的用例，則要復雜和困難得多。例如，字典的代碼是唯一的，不允許重復。測試需要驗證：字典新增流程中已存在有關字典代碼的管束，如果出現代碼重復必須報錯，並且報錯文字正確。

常常在設計編碼階段形成的文檔對備選事件和異常事件剖析描述不夠詳盡。而測試本身則要求驗證全部非基本事件，並同時盡最大力量發現裡邊 的軟件缺陷。

可以采用軟件測試常用的基該方法：等價類劃分法、邊界值剖析法、錯誤推測法、因果圖法、邏輯覆蓋法等設計測試用例。視軟件的區別性質采用不同的方式方法。怎樣靈活運用各式基該方法來設計完整的測試用例，並最終實現暴露隱藏的缺陷，全憑測試設計人員的豐富經驗和精心設計。

設計原則

測試用例是一個文檔，是執行的最小實體。測試用例包括輸入、動作、時間和一個期望的最終，其目的是確定應用流程的某個特性是否可正常工作，並且達到流程所設計的結果。

以便測試某個流程路徑或核實是否滿足某個特定需求般在進行測試用例設計前要全面瞭解被測試產品的功能、明確測試范圍(尤其是要確定哪些是不需要測試的)、具備基本的測試技術與方法等。測試用例設計一般遵循以下原則:

(1)正確性。輸入用戶實際數據以驗證系統是否達到要求規格說明書的要求;測試用例中的測試點應first of all保證要至少覆蓋需求規格說明書中的各項功能，並且正常。

(2)全面性。覆蓋所有的需求功能項;設計的用例除對測試點本身的測試外，還需考慮用戶實際使用的情形、和其它部分關聯使用的情形、非多數情況(不合理、非法、越界以及極限輸入數據)操作和環境設置等。

(3)連貫性。用例組織有條理、主次分明，尤其展現在業務測試用例上;用例執行粒度盡最大力量保持每個用例皆有測點，不可以同時覆蓋許多功能點，否則執行起來牽連太大，所以每個用例間保持連貫性特別重要。

(4)可判定性。測試執行結果的正確性是可判定的，每一個測試用例皆有對應的期望結果。

(5)可操作性。測試用例中要寫清楚測試的方法步驟，以及與不同的方法步驟相相應的測試結果。