在這裡和大家聊聊測試用例編寫的問題。
做一名測試人員，最基本的就是測試用例的編寫。文件功底一定要有。我們來說說用例的編寫需要的東西。
首先，用例的模板網上有很多。這些都是根據個人習慣的，但是再變，其核心內容是不變的。
乙份測試用例一定會包含的東西有『測試模組』、『測試標題』、『前置條件』、『執行步驟』、『預期結果』、『實際結果』；在這裡就不詳細和大家講這幾個模組了。今天我們要說的是，怎樣才能算是乙份合格的測試用例。
1、邏輯性
ui介面與功能點之爭，能不能按照ui介面或者功能點來寫用例。我覺得都是可以的。我之所以按照功能點來寫測試用例，無非就是想保證功能的邏輯貫通，易於測試的執行和理解。如果我們通過ui介面還能保證業務的邏輯、流程貫通的話，也是可以的。
如果我按照功能點和ui介面去寫用例。就拿登入這個功能來說，可能寫出來的用例會有所不一樣，但是這並不會影響到測試人員對它的理解和執行。但是如果我毫無邏輯可言的寫的用例，那麼測試人員可能就一臉懵逼，不知如何是好了。
2、條理性
一定要循序漸進，有條理，清晰。什麼叫有條理呢？就是能夠有規律、有順序、知輕重的去工作。如果沒有條理性的話，那麼測試人員可能會在乙個小東西上，浪費很多時間，從而導致重要的東西沒有時間完成測試。或者說導致專案的延期。如果說，邏輯性是告訴測試人員是按什麼順序去做的話。那麼條理性就是告訴測試人員，你需要先做什麼在做什麼。
3、易用性
用例不僅僅需要有邏輯，有條理。更要別人能夠看懂，容易看懂。你的用例寫的很好，邏輯完美，條理清晰，但是我看不懂，那也沒有什麼作用。不要抱著用例是給測試內部看的這種想法，這種想法很危險。
4、可執行性
ok，我能夠看懂你的用例。那麼接下來就要開始run case了。這個時候，我能否依據乙份用例，完成對這個專案的測試，就是衡量用例是否合格的標準之一。因為測試員，在進行run case的時候，可能不是他自己寫的用例，可能他沒看過需求。可能的情況有很多。所以我們盡量去保證，就算是乙個完全沒看過需求的人，也能夠按照我的用例完整的執行一遍測試。
如果出現不知道怎麼寫的時候。一定要明確需求。不知道怎麼寫無非就是需求不明確或者是需求理解不透徹，在這個時候就要用到我們的產品了。
測試用例（四）測試用例編寫
一.測試用例編寫方法 1.等價類劃分 如何選擇適當的資料子集，來代表整個資料集。通過降低測試的資料去實現 合理的 覆蓋，覆蓋了更多的可能資料，以發現更多的軟體缺陷 邊界值分析法 2.邊界值分析 使用邊界值分析方法設計測試用例時一般與等價類劃分結合起來，但它不是從乙個等價類中任選乙個例子作為代表，而是...
測試用例編寫
一 測試用例編寫準備 從配置管理員處申請軟體配置 需求規格說明書 和 設計說明書 根據需求規格說明書和設計說明書，詳細理解使用者的真正需求，並且對軟體所實現的功能已經準確理解，然後著手制訂測試用例。二 測試用例制定的原則 測試用例要包括欲測試的功能 應輸入的資料和預期的輸出結果。測試資料應該選用少量...
測試用例編寫
一 測試 用例編寫準備 從配置管理員處申請軟體配置 需求規格說明書 和 設計說明書 根據 需求規格說明書和設計說明書，詳細理解使用者的真正需求，並且對軟體所實現的功能已經準確理解，然後著手制訂 測試用例。二 測試用例制定的原則 測試用例要包括欲測試的功能 應輸入的資料和預期的輸出結果。測試資料應該選...