測試用例的設計基本原則
1、測試用例的代表性:能夠代表並覆蓋各種合理的和不合理、合法的和非法的、邊界的和越界的、以及極限的輸入資料、操作和環境設定等。
2、測試結果的可判定性:即測試執行結果的正確性是可判定的,每一個測試用例都應有相應的期望結果。
3、測試結果的可再現性:即對同樣的測試用例,系統的執行結果應當是相同的。
不管是從個人角度還是從公司角度,根據我這幾年的經驗我覺得case的設計應該符合以下幾點:
1、一個case一個功能點:每個case都要有個測點,找準一個測點則可,不能同時覆蓋很多功能點,否則執行起來牽連太大;
2、case的易讀:從執行者的角度去寫case,最好不要有太多的術語在裡面,如果要有最好指明具體位置;
3、case的執行粒度:粒度越小越好;
4、步驟清晰:一個case多個步驟,可一個重點,步驟指名人們怎麼去操作,expect則指明這樣操作之後應該看到什麼結果---最好不要用正確,正常,錯誤之類的含糊主觀的字眼。
5、總體設計:先正常,後異常,這樣可以確保正常情況下功能能夠走通。
總之:對於一個新來的tester,給他個case和我們的軟體,他就能順利取執行case.
相關推薦
自動化測試用例設計的原則
自動化 多少 target 刪除 問題 正是 測試工具 例子 解決方案 自動化測試用例設計的原則 很多公司在實施自動化測試的過程中,往往會把所有的手工測試用例作為自動化測試用例,並且直接進行腳本的開發工作,甚至有些公司不寫自動化測試用例,直接想當然地開發測試腳本,這些都是
自動化測試用例設計三原則
命令 進行 test 服務 更換 打印 抽取 自動 持續集成 今天總結一下在做自動化測試中測試用例設計的一些建議,總結為三原則: 1. 保持Case之間的獨立性 case獨立性就是能夠獨立運行,當我們有隨機的跑其中某個Case或亂序的跑這些Cases時,測試的結果都應該是準
黑盒測試用例設計-錯誤推測和因果圖方法
9.png sub png str 二義性 生成 當前 其中 關系 3.錯誤推測方法 基於經驗和直覺,找出程序中你認為可能出現的錯誤,有針對性地設計測試用例。經驗可能來自於在對某項業務的測試較多,也可以來自於售後用戶的反饋意見,或者從故障管理庫中整理bug。梳
黑盒測試用例設計-判定表驅動方法
組成 出了 mage 條件 技術分享 .cn 動作 align 轉換成 5.判定表驅動方法 前面因果圖方法中已經用到了判定表。判定表是分析和表達多邏輯條件下執行不同操作的情況的工具。在程序設計中可作為編寫程序的輔助工具。把復雜的邏輯關系和多種條件組合的情況表達
黑盒測試用例設計-正交試驗方法(七)
nbsp 出現 logs 因果圖 設計 步驟 引入 常用 因子和 6.正交試驗方法 第4節結尾提到,因果關系非常龐大,導致由此得到的測試用例數目多大。因而引入正交試驗法,從大量的試驗數據中挑選適量的、有代表性的點安排測試,來有效地、合理地減少測試的工時。 (1
黑盒測試用例設計-功能圖法和場景法(八)
重新 感覺 結果 軟件 簡單 可能 遷移 面向 通話 7.功能圖法 一個程序的功能包括靜態和動態說明。動態說明描述輸入數據的次序或轉移的次序,和業務流程緊密對應。靜態說明描述了輸入輸出條件之間的對應關系。對於面向市場的產品,其邏輯復雜、組合龐大,必須用動態說明
黑盒測試用例設計-用例維護(十二)
叠代 測試的 部分 開發 用例設計 來源 nbsp 延伸 不同的 六、用例維護—經驗用例 當進入執行測試階段時, 我們總是能發現一些缺陷的出現是出乎我們意料的, 或者說是已有的測試需求和測試用例未能覆蓋的。那麽,對於這部分缺陷,也應當在分析整理後添加到測試需求
測試用例設計方法:判定表
工具 理解 關系 輸入數據 可能 只有一個 輸入 技術 用戶 測試用例設計方法 判定表 定義 分析和表述若幹輸入條件下被測對象針對這些輸入做出的響應的一種工具; 遇到復雜業務邏輯是可以利用該表理清業務關系; 重要概念 條件 l 條件樁:需求規格說明書定義的被測對象的所有輸
軟件測試 —— 用例設計2(邊界值)
本場 幾歲 新建 也會 出現 點擊 自己 輸入輸出 無限 在現實生活中,無論做什麽,都會有一個“度”的概念。比如,我們知道在NBA總決賽的時候,很多運動員會特意在剛開始比賽不久就增加身體對抗去試探裁判員本場的尺度怎麽樣;還有MMA比賽的時候,一些有經驗的運動員也會有意去
服務端測試之接口測試用例設計
key 文檔 取數據 正常 驗證 性能測試 通過 工具使用 兩個 小夥伴們大家好,上一次和大家分享了《服務端測試之接口測試初探》,講了一些接口測試的基本概念和理論知識。在上次的分享中,簡單提到了接口測試用例設計包含的幾個方面。本期我將在上次分享的基礎上,和各位小夥伴一起具體
測試用例設計
環境 origin 測試用例 自然 nal 遍歷 工具 測試執行 用戶登錄 一、為什麽要使用測試用例 1、理清思路,避免遺漏 如果我們測試的項目大而復雜,我們可以把項目功能細分,根據每一個功能通過編寫用例的方式來整理我們測試系統的思路,避免遺漏掉要測試的功能點。 2、跟蹤測
我的測試用例設計-01測試用例的個人見解
資源管理 管理 鍛煉 百度百科 多公司 十年 關於 所有 操作 剛入行的時候,看了很多關於測試相關的文章,記得有一篇說到測試用例是測試靈魂讓我印象深刻。如今,我入行幾年了,越發深感測試用例的設計重要性,可以這麽說,測試用例的設計與管理是測試工程師的核心技能。我發現很多測試的
我的測試用例設計-02用例組成元素(用例模板)
關於 基礎 工具 使用 display 靈活 ges 模塊 技術 可以這麽說,每一家公司對於測試用例的設計規範、風格和用例的組成元素(填寫的字段)都一樣,但都大同小異,不同只是來源於公司對於某些實際需求來帶來的差異。 一般基本的測試用例都具有以下基礎的組成元素:用例編號、
測試用例設計和測試環境搭建
返回 保存 srs spa 文件中 開發 需求規格說明書 溝通 方式 等價類 定義:1.等價:如果多個輸入在程序中處理方式相同,則認為這些輸入時等價的,測是一個即可。 2。輸入:分為兩類,有效輸入(可以保存)、無效輸入(不可保存) 3結合:有效等價類、無效等價類
測試用例設計--場景法
繼續 輸入 說明書 並且 測試用例設計 字符串 分析 調整 office 定義 現在的軟件幾乎都是用事件觸發來控制流程的,事件觸發時的情景便形成了場景,而同一事件不同的觸發順序和處理結果就形成事件流。這種在軟件設計方面的思想也可引入到軟件測試中,可以比較生動地描
功能測試用例設計思路
搜索 post 字符串 測試用例 json字符串 功能測試 試用 探索性測試 頁面跳轉 1、輸入框中輸入最大允許值造成頁面跳轉溢出 2的32次冪 驗證點:邊界值、特殊字符、0、null、負值、超長字符、空字符串、英文字符、中文字符、全角符號 2、搜索框探索性測試: 探索性測
判定表法測試用例設計
info bsp 機器 inf 多條 就是 size pan -s 判定表也稱我決策表,能表示輸入條件的組合,以及與每一輸入組合對應的動作組合。與因果圖法相似判定表法主要側重輸入條件之間的邏輯關系。 1.判定表主要包含以下五部分: 條件樁:列出所有可能的條件 條件項:列出
接口測試用例設計
ges software 邏輯 外部 In orm 算法 處理 維護 接口測試概述 定義 API testing is a type of software testing that involves testing application programming inte
測試用例設計——如何提高測試覆蓋率
寫入 獲取 層次 比較 所在 內部 實時 出現 依賴性 前言 說到測試用例的設計,我想每個有過測試經歷的測試工程師都會認為很簡單,不就是:按需求或概要設計,得到軟件功能劃分圖,然後據此按每個功能,采用等價類劃分、臨界值、因果圖等方法來設計用例就行了。 但事實上撇開
測試用例設計:測試用例格式
style 單元 ron 編寫 無法 xxxx 性能 結果 系統測試 一、什麽是測試用例? 通俗的講:就是把我們測試系統的操作步驟用按照一定的格式用文字描述出來。 二、寫測試用例有什麽好處? 理清思路,避免遺漏 這裏是我們認為最重要的一點,假如我們測試的項目