基本功能的用例設計
新增
- 所有輸入項錄入正確提交,驗證錄入的資料是否正常出現在表裡
- 必填項都正確輸入,非必填項為空,檢視是否可以提交(一般情況介面和前端都需要對必填項做驗證)
- 必填項逐個為空提交
- 輸入項的字元限制,按照邊界值設計輸入字元
- 輸入的字元不符合要求,在輸入時或提交時是否有提示
- Web端新增功能,要注意按tab鍵是否能換行,enter鍵是否能提交
- 新增失敗,查看錶裡是否寫入資料(可能存在需要寫入多個表,在寫入最後一個表時失敗)
刪除
1.正常操作刪除,查看錶裡該資料是否為刪除狀態
修改
修改頁面基本與新增頁面一致,修改功能開發會做兩種:
- 在已存在資料上修改,注意修改是否完全
- 刪除已存在資料,新增新資料,需要注意刪除是否完全,有沒有多刪資料
查詢
- 搜尋框搜尋:
a) 模糊搜尋
b) 精確搜尋
c) 分詞搜尋(有該需求再考慮)
d) 不輸入任何記錄,搜尋出來是不是全部資料
- 資料展示
a) 展示需求定義的資料,資料無缺少
b) 展示正常狀態的資料(一般刪除狀態的資料不展示)
相關推薦
軟體測試面試過程中常見的問題-論登入功能用例設計
測試用例設計:考察測試人員在用例設計方面考慮是否全面,以及對測試需求的分析能力; 最常被問到的,現在軟體有一個登入模組,有使用者名稱和密碼,以及登入按鈕,請你來設計測試用例; 首先說一下我的經歷: 目前參加了5場面試,沒有收到一個offer, 幾乎每一場面試都會
基於需求文件(PRD)的功能用例設計
上一篇我講了在專案執行過程中,用例是需要動態更新的。接下來我將結合例項(移動app)講解在不同的階段如何設計用例。 需求文件(PRD)主要講述app的某個模組有什麼功能,每一項功能的頁面展示、頁面操作有哪些,不同操作之間的關係是什麼。基於PR
基本功能的用例設計
新增 所有輸入項錄入正確提交,驗證錄入的資料是否正常出現在表裡 必填項都正確輸入,非必填項為空,檢視是否可以提交(一般情況介面和前端都需要對必填項做驗證) 必填項逐個為空提交 輸入項的字元限制,按照邊界值設計輸入字元 輸入的字元不符合要求,在輸入時或提交時是否有提示
黑盒測試用例設計-功能圖法和場景法(八)
重新 感覺 結果 軟件 簡單 可能 遷移 面向 通話 7.功能圖法 一個程序的功能包括靜態和動態說明。動態說明描述輸入數據的次序或轉移的次序,和業務流程緊密對應。靜態說明描述了輸入輸出條件之間的對應關系。對於面向市場的產品,其邏輯復雜、組合龐大,必須用動態說明
功能測試用例設計思路
搜索 post 字符串 測試用例 json字符串 功能測試 試用 探索性測試 頁面跳轉 1、輸入框中輸入最大允許值造成頁面跳轉溢出 2的32次冪 驗證點:邊界值、特殊字符、0、null、負值、超長字符、空字符串、英文字符、中文字符、全角符號 2、搜索框探索性測試: 探索性測
XX系統功能用例整體設計思路
進入新的部門,首先面臨的是熟悉業務以及如何設計用例,如果是新人的話,因為可能會涉及到思考的角度比較多會遇到不知道如何下手開始寫用例的情況,鑑於一些經驗總結,可以在寫用例的時候整體設計參考如下: 系統切入點 目的:將大的功能模組切小的完整的功能模組,將不
常用功能測試用例設計
登入 1.輸入已註冊的使用者名稱和正確的密碼,驗證是否登入成功; 2.輸入已註冊的使用者名稱和不正確的密碼,驗證是否登入失敗,並且提示資訊正確; 3.輸入未註冊的使用者名稱和任意密碼,驗證是否登入失敗,並且提示資訊正確; 4.使用者名稱和密碼兩者都為空,驗證是否登入失敗,並且提示資訊正確; 5.
公租房搖號系統功能測試用例設計
最近做了搖號系統功能測試的專案,特來總結一下。 搖號系統簡單介紹: 1、登入介面中,需要驗證身份證號、手機號、驗證碼 2、房源關聯屬性:房源ID,專案名稱,戶型(一室戶、二室戶、三室戶),分類,是否變更 3、人源關聯屬性:人源ID,身份證號,手機號,評分,專案名稱,戶型(一室戶、二室戶、三室
搜尋功能、翻頁功能、輸入框的測試用例設計及知識
搜尋功能測試用例設計 搜尋功能點進行分解,把測試用例分解為多個測試場景 場景編號 場景描述 預期結果 場景一 頁面檢查 正確
轉-登入功能通用測試用例設計
https://www.cnblogs.com/jpr-ok/p/6418492.html 登入功能通用測試用例 具體需求: 有一個登入頁面,有一個賬號和一個密碼輸入框, 一個提交按鈕。 請針對這個頁面設計Test Case。 此題的考察目的: 1、瞭解需求(測什麼都是從瞭解需求開始); 2、是否
黑盒(功能)測試以及測試用例設計
概念:黑盒測試是把測試物件看做一個黑盒子,利用黑盒測試法進行動態測試時,需要測試軟體產品已經實現的功能是否符合功能設計要求,不需測試軟體產品的內部結構和處理過程。黑盒測試注重於測試軟體的功能性需求,也即黑盒測試使軟體工程師派生出執行程式所有功能需求的輸入條件。黑盒測試並不是白
接口用例設計
要求 實習 增加 字符 字符串 不能 失敗 必須 bsp 1.通過性測試(正向用例) 保證這個接口功能是好的,正常傳入,是否可以返回正確結果 2.參數組合 多個參數的時候 3.接口安全 1、繞過驗證,比如說購買了一個商品,它的價格是300元,那我在提交訂單時候,我把
黑盒測試用例設計-錯誤推測和因果圖方法
9.png sub png str 二義性 生成 當前 其中 關系 3.錯誤推測方法 基於經驗和直覺,找出程序中你認為可能出現的錯誤,有針對性地設計測試用例。經驗可能來自於在對某項業務的測試較多,也可以來自於售後用戶的反饋意見,或者從故障管理庫中整理bug。梳
黑盒測試用例設計-判定表驅動方法
組成 出了 mage 條件 技術分享 .cn 動作 align 轉換成 5.判定表驅動方法 前面因果圖方法中已經用到了判定表。判定表是分析和表達多邏輯條件下執行不同操作的情況的工具。在程序設計中可作為編寫程序的輔助工具。把復雜的邏輯關系和多種條件組合的情況表達
黑盒測試用例設計-正交試驗方法(七)
nbsp 出現 logs 因果圖 設計 步驟 引入 常用 因子和 6.正交試驗方法 第4節結尾提到,因果關系非常龐大,導致由此得到的測試用例數目多大。因而引入正交試驗法,從大量的試驗數據中挑選適量的、有代表性的點安排測試,來有效地、合理地減少測試的工時。 (1
黑盒測試用例設計-用例維護(十二)
叠代 測試的 部分 開發 用例設計 來源 nbsp 延伸 不同的 六、用例維護—經驗用例 當進入執行測試階段時, 我們總是能發現一些缺陷的出現是出乎我們意料的, 或者說是已有的測試需求和測試用例未能覆蓋的。那麽,對於這部分缺陷,也應當在分析整理後添加到測試需求
測試用例設計方法:判定表
工具 理解 關系 輸入數據 可能 只有一個 輸入 技術 用戶 測試用例設計方法 判定表 定義 分析和表述若幹輸入條件下被測對象針對這些輸入做出的響應的一種工具; 遇到復雜業務邏輯是可以利用該表理清業務關系; 重要概念 條件 l 條件樁:需求規格說明書定義的被測對象的所有輸
軟件測試 —— 用例設計2(邊界值)
本場 幾歲 新建 也會 出現 點擊 自己 輸入輸出 無限 在現實生活中,無論做什麽,都會有一個“度”的概念。比如,我們知道在NBA總決賽的時候,很多運動員會特意在剛開始比賽不久就增加身體對抗去試探裁判員本場的尺度怎麽樣;還有MMA比賽的時候,一些有經驗的運動員也會有意去
服務端測試之接口測試用例設計
key 文檔 取數據 正常 驗證 性能測試 通過 工具使用 兩個 小夥伴們大家好,上一次和大家分享了《服務端測試之接口測試初探》,講了一些接口測試的基本概念和理論知識。在上次的分享中,簡單提到了接口測試用例設計包含的幾個方面。本期我將在上次分享的基礎上,和各位小夥伴一起具體
測試用例設計
環境 origin 測試用例 自然 nal 遍歷 工具 測試執行 用戶登錄 一、為什麽要使用測試用例 1、理清思路,避免遺漏 如果我們測試的項目大而復雜,我們可以把項目功能細分,根據每一個功能通過編寫用例的方式來整理我們測試系統的思路,避免遺漏掉要測試的功能點。 2、跟蹤測