測試用例名稱命名規范(測試用例名稱怎麼寫)

測試用例設計方法有哪些?

1。等價類劃分

為每個輸入劃分等價類，得到等價類表，為每個等價類規定一個唯一編號。設計一個測試用例，使其盡可能多的覆蓋所有尚未覆蓋的有效等價類。重復這一步驟，使得有效等價類均被測試用例所覆蓋設計一個測試用例，使其隻覆蓋一個無效等價類。重復這一步驟使得所有無效等價類均被覆蓋。

2。邊界值分析

從測試規格中分析得到輸入參數類型，對於輸入等價類劃分方法進行等價類的劃分，運用域測試分析方法確定域范圍的邊界（上點、離點與內點）。假如存在多個輸入域，則需要運用因果圖、判定表方法這幾個輸入域邊界值的組合情況進行進一步分析，選擇這幾個上點、離點與內點或者這幾個點的組合形成測試項。

3。判定表

判定表是分析和表達多種輸入條件下系統執行不同動作的工具，它真的可以把復雜的邏輯關系和多種條件組合的情況表達得既具體又明確。

列出所有的條件樁和動作樁，填入條件樁、條件項和動作樁、動作項，化簡，合並相似規則，將每條規則轉化為用例。

基本格式

1。用例編號

測試用例的編號有一定的規則，打比方說系統測試用例的編號這樣定義規則：PROJECT1-ST-001，命名規則是項目名稱＋測試階段類型（系統測試階段）＋編號。定義測試用例編號，便於查找測試用例，便於測試用例的跟蹤。

2。測試標題

對測試用例的描述，測試用例標題應該清楚表達測試用例的用途。打比方說“測試用戶登錄時輸入錯誤密碼時，軟件的響應情況”。

3。重要級別

定義測試用例的優先級別，可以籠統的分為四個不同的等級。

4。輸入限制

提供測試執行中的各種輸入條件。依據需求中的輸入條件，確定測試用例的輸入。測試用例的輸入對軟件需求之中的輸入有很大的依賴性，假如軟件需求中沒有非常好的定義需求的輸入，那麼測試用例設計中會遇見很大的障礙。

5。方法步驟

提供測試執行過程的步驟。對於復雜的測試用例，測試用例的輸入需要分為幾個步驟完成，這部分內容在方法步驟中詳細列出。

6。預期結果

提供測試執行的預期結果，預期結果應該依據軟件需求中的輸出得出。假如在實際測試過程中，得到的實際測試結果與預期結果不符，那麼測試不通過；反之則測試通過。

一、測試用例的基本要素

1。用例編號：測試用例的編號有一定的規則，打比方說系統測試用例的編號定義規則：MS-ST-001，命名規則是項目名稱+測試階段類型(系統測試階段)+編號。編號是為瞭查找測試用例，便於測試用例的跟蹤。

2。測試項目：要測試項目的名稱，可以是測試用例歸屬的大類，被測需求，被測模塊或者是被測的單元。

3。測試標題：對測試用例的描述，測試用例標題應該清楚表達測試用例的用途。打比方說”測試用戶登錄時輸入錯誤密碼時，軟件的響應情況“。

4。重要級別：定義測試用例的優先級別，可以分為”高“、”中“、”低“三個級別。

    高：保證系統基本功能、重要特性、實際使用頻率有些高的用例；

    中：重要性介於高和低之間的測試用例；

    低：實際使用頻率不高，對系統業務功能作用與影響不大的模塊或功能的測試用例。

一般假如軟件需求的優先級是”高“，那麼針對該需求的測試用例優先級也是”高“；反過來也是一樣。

5。預置條件：就是執行當前測試用例的前提描述，假如不滿足這幾個條件，則無法進行測試。

6。測試輸入：測試用例執行時，需要輸入的外部信息。

7。方法步驟：執行當前測試用例所要經過的方法步驟，需要給出每一步操作的詳細描述，測試人員依據測試用例方法步驟，完成測試用例的執行。

8。預期結果：當前測試用例的預期輸出結果，用來與實際結果比較，假如相同則該測試用例通過，否則該測試用例失敗。

以上八個要素是最重要的，下面這幾個選寫：

10。創建時間：寫用例的日期

11。修改日期：最後一個修改用例的日期

12。測試結果：執行用例後的結果：pass、fail、block

【經驗共享】軟件測試用例管理

本文涉及到測試用例的編寫規范，以及用例管理的共享，因此，不管是對於初級測試工程師，還是質量團隊的管理者，皆有一定的參考意義。文中涉及到的方法和工具並不是唯一處理方案，希望大傢收獲到的不但僅是文字表面，而是文核心享的一些思路。

有人說：測試用例還不知道？不就是描述測試步驟嗎？

這麼回答確實沒什麼錯，隻是假如內心上也僅僅這麼認為的話，隻能說並未理解測試用例。

測試用例除瞭作為測試行為的描述，更加的多的是作為被測目標是否達到需求的驗證，關鍵還是考驗瞭一個測試工程師的組織歸納能力，其輸入來源多數是承諾書、用例(Use Case) 以及自己一身對業務范疇知識的經驗，一個軟件測試工程師的專業度常常展現在他設計的測試用例上。

專業的工程師設計出的測試用例集，不但能夠描述本人的行為，還能指導別人實施，不但強調深度，還具有優秀的用戶思維。

固然從格式上來說，基本就定型瞭：

關於這部分，網絡上的教程隻多不少，就不贅述瞭。

不過呢要強調的重點是， 格式隻能保證測試用例明晰，並不能提升測試用例的設計能力 。因此，測試用例該怎麼寫？還是要從結構化設計開始。這裡需要提到一個概念 HLTD [ High Level Test Design ]，可以簡單粗暴的理解為測試大綱的設計。

就如同我們寫文章一般，提筆正文之前，會先擬個草稿，列出中心思想及段落提綱，緊接著再攥寫潤色。

寫測試用例也是類似的套路，先列出測試點作為大綱，並且具有結構化佈陣與佈局。通常以大的功能或模塊進行分類，再細化二級甚至三級類別，最終列出具體的測試點。該階段的設計，筆者傾向於利用思維導圖（腦圖），相較於傳統的文檔軟件工具，思維導圖的體現更直觀。

因為最終會是一張大圖，所以硬傷也隨之展現，隻適合用於思路梳理，不太適宜用於文檔化管理。

把這幾個結構化好的測試點文檔化，就是我們所說的測試用例瞭。

所以從這裡我們可以看出，每一條測試用例的目的很明確，是驗證一個或一類測試點，顆粒度需要依據公司實際情況權衡，太粗不利於對於測試點覆蓋的匯總，拆太細會消耗更加的多的精力。

測試用例其實也就是說是一個非常詳盡的文檔，必然會消耗測試工程師相當一部分的精力。在傳統軟件開發時代，甚至作為 KPI 的一項指標。

不過伴隨著敏捷時代的興起，有一種聲音開始沖擊這種認知。

早期的敏捷實踐者，對敏捷宣言的解讀僅僅停留在瞭文字表面，認為“僅需要軟件，不需要文檔”。這直接致使瞭這一時期，大量的團隊缺失瞭詳盡的文檔，甚至連一些基本的文檔都沒有。

如今，愈來愈多的敏捷實踐者認識到，敏捷宣言所宣揚的並不是“不用詳盡的文檔”，恰恰相反， 敏捷宣言認同瞭“詳盡的文檔很重要”這件事，並且提出瞭更高的要求 —— “工作的軟件更加的重要”

對於測試用例文檔化工具的選擇，許多團隊仍然停留在傳統的辦公軟件，如 Word、Excel

但如今凡事比快的市場環境下，團隊成員高效協作、團隊信息實時分享的需求愈來愈高，測試用例平臺化管理必然還是最終歸屬，除瞭文檔化，還利用平臺制定計劃，展示進度和結果。

實際上，在傳統時代，大一些的軟件公司就已經使用平臺來管理測試用例瞭，這再一次證明瞭敏捷時代並不象征著推翻過去的經驗和成果，而是提出瞭更高的要求。

如今，相對知名的管理平臺有基於 Jira 做插件的，如：Zephyr、Xray、synapseRT、TM4J，也有單獨的開源平臺: 如：TestLink，或收費的單獨平臺: 如：TestRail

我們主要從其生態、推行成本、可擴展、費用角度去綜合考慮。

Zephyr 的名氣一直都很大，但事實上並不太符合國人使用的習慣，使用起來諸多不便。用例直接使用 Jira issue，功能比較簡單，用例管理主要在計劃和循環的關聯上。因為其是 Jira 插件，因此能非常好的跟 Jira 上其他 issue (需求、任務、缺陷) 進行關聯。但其用例管理的可視化不是很好，沒有用例集的概念。遷移方面，數據導入支持類型有限。擴展方面，若要使以其 API，還need另外裝一個插件。其費用中等。

Xray 算中規中矩，也是使用 Jira 的 issue 來創建測試用例。但其新增的 issue 類型多達 5 類，顯得極為復雜。關聯能力與 Zephyr 相同，數據導入支持類型有限，本身有 API 可供使用。其費用中等。

synapseRT 是國人開發，漢化效果最好，功能強大。有用例集的概念，用例也是用的 Jira issue 來擴展。數據導入支持瞭 TestLink、Zephyr 如此的其他平臺。關聯能力同 Zephyr，數據導入支持類型依舊有限，其本身也有 API 可使用。而費用相對較低。

TM4J 使用單獨頁面管理測試用例，脫離復雜的 Jira issue 頁面，上手難度低。數據導入功能強大，覆蓋許多類型及一些知名平臺。關聯能力與上述插件一致，本身也有 API 可使用。但費用相對較高。

TestLink 作為單獨的測試管理平臺，功能全面，開源免費。可以關聯 Jira 如此的知名平臺，但因為不是 Atlassian 體系，因此生態體驗不高。硬傷是界面醜陋，容易作用與影響工程師的心情。筆者曾經使以其本身的 API 進行 UI 美化。

TestRail 是一個強大的商業平臺，筆者接觸不多，不亂作評論。

綜合考慮，固然 TestLink 作為免費開源用例管理平臺中的 TOP，在用例管理上做得非常科學，一直值得學習，但筆者所在公司已經在使用 Jira，並在落地 DevOps，外加筆者常受 Atlassian 中國社區研究院副院長的支持，TM4J 成為最終選擇：

出品方還是挺強的，除瞭 TM4J，Zephyr 其實也就是說也是其下產品，Swagger 也已經是目前認知度相當高的產品瞭。

從官網介紹上可以看出，TM4J 還是比較現代化的：

first of all我們看看利用 TM4J 怎樣來編寫測試用例。

層級結構上，我們依據 HLTD 來創建目錄以及子目錄，以方便所有人理解和閱讀，最後的測試點則實際案例化為一個測試用例，它擁有全局唯一的 Key。

點擊 New 按鈕創建新測試用例，默認在 Details 標簽頁，在這裡定義用例名稱、目的、前提條件，詳情中可以設置狀態、優先級、所屬組件，還能夠添加一些便於管理的標簽。

切換到 Test Scripts 標簽頁，默認是 Step-by-Step 類型，依照 STEP - TEST DATA - EXPECTED RESULT 添加每一個測試步驟。

另外值得一提的是，在 Traceability 標簽頁，可以關聯 Jira issue、Confluence page

通常我們針對每次產品發佈交付，需要制定范圍，因此計劃管理是必不可少的。

計劃管理推薦依照發佈版本來制定頂層目錄，緊接著針對測試類型創建二級目錄，如回歸、新功能、端到端、接口、性能等等。

測試計劃的創建本身操作倒並不復雜，除瞭定義計劃名稱、目的、狀態、責任人，外加一些標簽。

還need關聯一下需求或者 Confluence 頁面。測試周期在剛創建測試計劃的時刻可能並不存在，可以在之後創建測試周期的時刻，會雙向關聯。

測試周期是一個承上啟下的關鍵，往上關聯測試計劃，往下關聯具體的測試用例。

通常一次發佈交付會經歷 3-5 次沖刺，每輪沖刺的范疇不一定完全相同。

在新建完測試周期名稱、描述以及詳情之後。

進入 Test Cases 標簽頁，點擊 + Add test cases 添加已經編寫好的測試用例。

這一步操作使得測試用例具備瞭項目屬性。

最後在測試周期的 Traceability 標簽頁點擊 Test Plans 後面的放大鏡。

通過查找來關聯已經做好的測試計劃。

創建完測試周期，就能夠進入該周期瀏覽到分配到自己名下的測試用例瞭，這是所有測試執行者都需要用到的界面，還不錯通過 Group by 依據不同規則進行歸類，打比方說依據測試周期中制定的區別目錄。

對於用例步驟的執行，TM4J 提供瞭一些快捷按鈕，可以直接標記通過、失敗、阻塞，並且可以點擊齒輪按鈕，快速創建、查找 Jira issue 進行關聯，當然，除瞭對於步驟關聯 issue，也可以針對該用例標記 issue，點擊 Issues 後面的 + ▼ 可進行操作。統一平臺的有益之處便是在此瞭。

固然我們在查看測試周期列表的時刻可以看到測試的進度，但更加的多數據展示可Yi經過測試報告來展現。

TM4J 的 Reports 功能給我們提供瞭富饒的模板，方便一些經驗不足的測試質量管理者。

最後，筆者想說， 測試工作不能作為一個單獨的業務，應該更加的多的和其它角色協作 ，尤其是在如今的敏捷時代，測試用例的執行可以要求開發工程師關註，測試的狀況可以要求產品經理隨時介入，因此，強烈建議我們軟件測試工作者盡最大力量選擇一些跨職能協作平臺。

測試用例註意和提防問題與事項?

1）測試用例是否依照公司定義的模板進行創作的；

2）測試用例的本身的描述是否清晰，是否存在二義性；

3）測試用例內容是否正確，是否與需求目標相一致；

4）測試用例的期許結果是否確定、唯一的；

5）方法步驟應與描述是否相一致；

6）測試用例是否覆蓋瞭所有的需求；

7）測試設計是否存在冗餘性；

8）測試用例是否具有可執行性；

9）是否從用戶層面來設計用戶使用場景和業務程序的測試用例；

10）場景測試用例是否覆蓋最復雜的業務程序；

11）用例設計是否蘊含瞭正面、反面的用例；

12）對於由系統自動生成的輸出項是否註明瞭生成規則；

13）測試用例應蘊含對中間和後臺數據的檢查；

14）測試用例應有正確的名稱和編號；

15）測試用例應標註有執行的優先級；

16）測試用例蘊含相關的配置信息：測試環境、數據、前置測試用例、用戶授權等；

17）每個測試用例步驟應<=15 Step；

18）自動化測試腳本必須帶有註釋（註釋應包括：目的、輸入、期望結果等）；

19）非功能測試需求或不可測試需求是否在用例中列出並說明？

請教功能測試用例怎麼寫???

【不在於測試用例該怎麼寫，而在於想怎麼測。】【對用例的理解表達出來，格式自然出來瞭】呵呵，偶要頂一下，偶不是完全贊同這兩句話。用例的理解跟格式沒有必然的聯系。也沒有主次輕重之分。【先保證自己對業務程序和業務規則的理解和熟悉，緊接著可以對這部分先思考一下，什麼地方需要測試，需要如何的測試？怎樣來施行這幾個測試？之後再增添對系統中其他規則、特性和算法的熟悉，繼續增添測試的深度和廣度。】——這句說的很對。有這麼一個公式， 數據結構＋算法＝流程。這裡類比一下用例設計，jackei和skinapi版主強調的是用例的“算法”，而文檔格式是用例的“結構”。兩者的關系是相輔相成，而不是矛盾的（似乎在上課哈）。至於說“對用例的理解表達出來，格式自然出來瞭”，這個境界太高瞭，不是普通人能夠做到的。面對現實的企業應用，做項目的話你會遇見各種各樣的情況，要做到“格式自然出來”實在是太……厲害瞭呵呵。是如此的：用例格式相當於一個規范，給你一個結構，一個框架（framework），唯此而已，並不由於你的用例模板而能展現用例的好賴。所以， “用例怎麼寫”其實也就是說分兩個：用例的“算法”＋用例的“結構” （也就是模板）瞭。 查看原帖>>

怎樣設計一個完整的測試用例

測試用例的設計一般從分析需求設計說明書開始，瞭解開發人員設計這個項目的思路、設計的要求、實現的功能等（最好有use case，這樣看起來更清晰）。軟件測試的W模型，就要求測試與開發同步，在開發設計需求設計說明書的時刻就開始測試程序，通常情況下，討論需求設計的時刻需要測試主管或者組員的參與，瞭解這個項目設計的總體情況。實際上，測試用例的編寫通常是在需求設計說明書定下來之後才名符其實的開始的。由於測試用例的內容要以需求設計說明書為根據，設計說明書上沒展現的功能，不需要在測試用例中展現。編寫測試用例（這裡指功能測試用例的編寫），first of all要做的就是設計測試用例的模板。各個公司皆有適合自己公司用例創作的模板，各有各的特征。測試用例的格式包括，測試用例摘要、測試用例需求編號（一個需求設計說明書可以分好幾個用例編寫）、編寫用例的日期、編寫人員、編寫日期、前置條件、準備數據等等。格式沒有固定的要求，可以依據自己測試用例設計的思路，對測試用例的格式作對應的改變。下面以一個登陸窗口為例，說說我設計登陸界面的思路和方法。我把這個測試用例分為三層結構，表單測試、邏輯判斷、業務程序。第一層，表單測試為最底層（最基礎的）。這部分的測試用例是對登陸窗口這個界面的輸入框、按鈕功能、界面等最基本功能的測試。一般而講登陸用戶名和登陸用戶密碼是輸入框的形式展現，那麼，我們需要的是針對這兩個輸入框進行功能的測試。這時，我們隻要慎重考慮這個輸入框的功能，而不需要慎重考慮業務方面的內容。這樣，我們考慮就是這個輸入框的長度限制是多少？能否輸入特殊字符？能否輸入全角字符？當然，登陸窗口還有其他按鈕，例如登陸按鈕、退出按鈕、界面設計等，這一層的測試用例隻對他們最簡單容易的功能的測試。我認為這一層的測試用例對新開發項目很重要，也必須執行，由於這幾個是最基本的功能保證，當項目進入維護階段後，假如沒有修改就不需要執行這部分的測試瞭或者說把這層的用例優先級置為最低，時間不充足的情況就不用去執行。第二層，邏輯判斷層。依據需求的設計，各功能之間的簡單邏輯聯系。以登陸窗口為例，賬號登錄，賬號和密碼必須對應才能登錄，否則登錄失敗。依據這一點，我們就能夠從這種呢要求設計這一層測試用例。例如，賬號和密碼不一致時；賬號為空時；密碼為空時；賬號密碼對應時等等情形狀況。輸入這幾個情況時，流程是作怎麼樣的邏輯控制的？控制是否正確？是不是有對應的提示信息？我認為，這一層的用例時最常規的一層，平時使用這個軟件用經常碰到的一些情況，在常規測試或修改這部分的功能之後，這一部分的測試用例也必須執行。第三層，業務程序層。這部分不關心軟件的本身的基本功能，而是關心這個軟件的業務有還是沒有實現，不同的需求就有不同的業務需求。以登陸窗口為例，就也許有不同的需求，可能用戶要求停用的賬號能夠登錄系統（可能要求登錄後不允許進行其他操作），也可能用戶直接要求停用的用戶賬號不準登錄系統。依據不同的業務需求，就有不同的業務程序。這樣這層的測試用例，我們就隻要慎重考慮業務需求，仍然以登錄窗口為例，我們就隻要慎重考慮刪除的用戶能否登錄？停用的用戶能否登錄？超級用戶是怎樣登錄的？普通用戶是何種方式登錄的？簡單容易的說，這層的用例隻描述業務程序，不關心具體這個業務是如何實現的，執行這部分用例時，不要慎重考慮哪個輸入框控制瞭多少長度，能否輸入空格等其他功能，由於這部分的測試需要基於上面兩層的測試用例都已經測試通過瞭，因此在項目維護階段或者說時間很緊迫的階段，我們僅需要執行這部分的用例，保證業務能夠通暢的完成。其實也就是說個人覺得在實施這部分用例時，對蘊含瞭對基本功能的測試，一些明顯的問題應該能被發現，固然嚴格來說測試覆蓋率很低，但是基本能滿足需求。這三層的組合起來才是一個完整的測試用例。這是我本人對測試用例設計的一個思路和方法。真正設計這個測試用例的時刻，也許會使用到黑盒測試用例的方法，例如等價類劃分、邊界值分析、錯誤猜測法（著重是個人經驗）、正交分解等方法針對具體情況設計測試用例。分層測試用例的思路主要來自對自動測試實現的考慮。由於我認為，假如需要實現自動化測試就必須對測試用例進行細分，劃分得越細就越能夠起到好作用的自動化的實現。以上三層的劃分也並不是很全面，需要在實踐中不斷完善，例如可以增添對數據庫的部分功能的數據校驗的分析。也就是說，測試用例寫的細致、全面、步驟清晰，那麼不管是用手工測試的方法還是用自動化測試的方法實現，隻要能完整的跑完整個測試用例，就達到瞭測試的目標瞭。