我們經常都知道一個測試用例里面包含以下幾個要素：

1，用例編號
2，模塊
3，場景
4，用例名稱
5，前置條件
6，測試等級
7，操作步驟
8，預期結果(需求要求的結果)
9，實際結果
10，創建日期
11，是否通過

我們分析下，這些要素到底是有什么用？

用例編號：

工作場景一沒有用例編號：

測試A：開發你的軟件出了bug！

開發B:什么bug？

測試A：就是那個執行@#￥%……&用例出現的bug

開發B：什么？

測試A：就是那個#￥%……&

開發B；你到底說了個what？

測試A：你讓我怎么給你說，你才明白

開發B：世界上最遠的距離不是我站在你身邊你不認識我，而是你占我身邊連個問題都給我表述不清楚。。。

工作場景二有用例編號：
測試A：開發你的軟件出了bug！
開發B:什么bug？
測試A：就是那個編號為BCBX-007的用例出現測試不通過
開發B：好，我去看看
測試A：好的
開發B；剛看了，按照用例執行確實有問題，我改下。
測試A：嗯嗯，謝謝
開發B：不謝，世界上最幸福的事情不是貓吃魚，奧特曼打怪獸，而是我跟你配合，一個開發一個測試
測試A：基情無限。。。。

模塊：

在軟件的世界里，有不同的功能，那么如何在龐大而又復雜的系統中，梳理出一條有序的目錄或者test checklist

我個人認為我們只有劃分出對應的模塊，然后逐一攻破！！！

場景：

很多人把場景和模塊可能歸為一類，也對，也不對，其實獨立出一個場景，我個人認為更多的是為了 細化模塊，舉個例子：

一個大型的門戶網站，可能有生活，工作不同的模塊

但是工作模塊下可能會有兼職，全職，包括不同工作類型的場景，甚至對于測試來說還有正常的和異常的場景

用例名稱：

人不可無名！！！同樣我們的測試用例也得有個名字叫用例名稱，要不你都不知道叫個啥！！！

前提條件：

古人有云：完事具備，只欠東風！！！
我個人認為一個好的前提條件就是一股東風，祝你成功，并且我們在測試軟件的過程中，往往會遇到業務邏輯較復雜的軟件，如果能夠很好的利用好前提條件，你的用例會非常的beautiful

測試等級：

一件事都用重要不重要之分，軟件測試也是一樣
在我們測試的過程中，一個功能如果出問題，會影響其他功能的使用，并且這個功能是用戶的高頻操作，那么你說他重不重要？
至少和刀鋒老師在你們的心里一樣重要吧（自戀一下，嘻嘻！！！）

操作步驟：

我們做任何事情都有個step1，step2，step3.。。。何況軟件呢？

誰要說用例里面測試步驟可有可無，下課別走！！！

那么一個好的操作步驟，是需要很多的積累和沉淀的，舉個例子你的操作步驟里面說“輸入一個正常的手機號”，與“在手機號欄位輸入手機號：15991710589”哪個好？

必須第二個好，我連數據都不用動腦子直接粘進去測試了，能不好？不服來戰！！！

預期結果（需求中要求的結果）：

佛說：萬事萬物，有因就有果。
刀哥說：軟件測試，有操作就有結果，只不過，在軟件沒出來之前，我們心里得有個預期吧，所以就有了預期結果，要不你怎么知道對錯？

實際結果：

丑媳婦總要見公婆的吧。
哪怕你的軟件寫的再爛，你也得有個實際結果，哪怕與預期不符呢，我提單你改不就完了。所以軟件測試還是蠻友好的，至少錯了還能改，要是真的取個媳婦，你就不管丑與美，都得負責了。。。

創建日期：

古人有云：天時地利與人和。
天時說的就是時間，你寫個用例，好歹給人家個出生日期吧，你說刀哥說的對不。。。

是否通過：

事情總有個對與錯，軟件測試也是一樣，總有過關和不過關
不過關咋辦，那就是問題，提單吧，但是你也得記錄下這個用例未通過吧。

總結

以上是生活随笔為你收集整理的软件测试用例_大话软件测试用例要素的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。