arnold：大話軟體測試用例要素zhuanlan.zhihu.com
我們經常都知道乙個測試用例裡面包含以下幾個要素：
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」哪個好？必須第二個好，我連資料都不用動腦子直接粘進去測試了，能不好？不服來戰！！！
預期結果（需求中要求的結果）：
佛說：萬事萬物，有因就有果。
刀哥說：軟體測試，有操作就有結果，只不過，在軟體沒出來之前，我們心裡得有個預期吧，所以就有了預期結果，要不你怎麼知道對錯？實際結果：
醜媳婦總要見公婆的吧。
哪怕你的軟體寫的再爛，你也得有個實際結果，哪怕與預期不符呢，我提單你改不就完了。所以軟體測試還是蠻友好的，至少錯了還能改，要是真的取個媳婦，你就不管醜與美，都得負責了。。。
建立日期：古人有云：天時地利與人和。
天時說的就是時間，你寫個用例，好歹給人家個出生日期吧，你說刀哥說的對不。。。
是否通過：事情總有個對與錯，軟體測試也是一樣，總有過關和不過關
不過關咋辦，那就是問題，提單吧，但是你也得記錄下這個用例未通過吧。
軟體測試 用例
三 什麼是測試用例的有效性 四 測試用例的粒度和評價 軟體測試 用例 本節重點 1.測試用例的基本要素 2.測試用例的設計方法 3.測試用例的有效性 4.測試用例的粒度和評價 測試用例就是向被測試系統發起的一組集合，包含測試資料，測試環境，操作步驟，預期結果 要素 測試前期 測試版本 功能模組 重要...
軟體測試 測試用例的經典例子
一 等價類劃分 問 某程式規定 輸入三個整數 a b c分別作為三邊的邊長構成三角形。通過程式判定所構成的三角形的型別，當此三角形為一般三角形 等腰三角形及等邊三角形時，分別作計算 用等價類劃分方法為該程式進行測試用例設計。三角形問題的複雜之處在於輸入與輸出之間的關係比較複雜。解 分析題目中給出和隱...
軟體測試 測試用例的經典例子
一 等價類劃分 問 某程式規定 輸入三個整數 a b c分別作為三邊的邊長構成三角形。通過程式判定所構成的三角形的型別，當此三角形為一般三角形 等腰三角形及等邊三角形時，分別作計算 用等價類劃分方法為該程式進行測試用例設計。三角形問題的複雜之處在於輸入與輸出之間的關係比較複雜。解 分析題目中給出和隱...