如何正確的書寫測試用例? 本人由於學業不精,有大佬幫助我一下嗎 以ECShop前臺應用中用戶註冊、用戶登陸、商品搜索等功能為例介紹測試用例設計活動。4.2.1用戶註冊 用戶註冊功能需求如圖4- 4所示。 圖4- 4用戶註冊需求用戶註冊需求共涉及4個輸入項和1個選擇項。針對於輸入項,利用等價類及邊界值用例設計方法進行設計,選擇項則無須設計在步驟中,在測試執行時分別執行勾選與不勾選即可。01.用戶名用戶名共有三個條件:必填、不少於3個字元、不能重複,分別構造有效等價類及無效等價類,具體如表4- 1所示。 敏捷測試用例根據實際測試需要,不一定寫的非常細緻,如「用戶名」包含字元類型,此處無須再劃分純字母、純漢字、特殊符號等,構造數據時可混搭。02.email email有兩個條件:必填、符合規定格式,分別構造有效等價類及無效等價類,如表4- 2所示。 03.密碼密碼有兩個條件:必填、不少於6個字元,分別構造有效等價類及無效等價類,如表4- 3所示。 04.確認密碼確認密碼有兩個條件:必填、與密碼一致,分別構造有效等價類及無效等價類,如表4- 4所示。 測試工程師利用禪道設計用例,如圖4- 5所示。 圖4- 5用戶註冊功能測試用例4.2.2 用戶登錄用戶登陸需求如圖4- 6所示。 圖4- 6用戶登陸需求用戶登陸共有三個欄位:用戶名、密碼、保存登陸信息,其中用戶名、密碼為輸入框,保存登陸信息為選擇框。因該需求比較簡單,故無須分析過程,直接進行用例設計,如圖4- 7所示。 圖4- 7用戶登陸功能測試用例4.2.3 商品搜索商品搜索需求如圖4- 8所示。 圖4- 8商品搜索需求通過需求分析,商品搜索功能較為簡單,測試用例設計時只需考慮一個搜索條件的測試,測試工程師從搜索功能開發角度考慮。對於系統而言,如果資料庫中存在某個關鍵字的商品,則應該顯示,否則應當提示沒有匹配的商品,故搜索用例設計不需要使用複雜的用例設計方法,測試工程師只需根據經驗設計用例即可。對於顯示方式,存在顯示方式、排序條件、排序方式三種,顯示方式又分為小圖列表、大圖列表、文字,排序條件有按上架時間、按價格、按更新時間,排序方式有升序與降序,如果完全組合則有3*3*2=18種組合,測試工程師可利用正交試驗用例設計方法進行設計。通過分析,共有3個參數,每個參數分別有3、3、2個取值,因此需選擇因子數、水平數都3,且試驗次數最少的正交表。查詢正交表,4因子3水平正交表符合條件,如表4- 5所示。 替換參數,得到表4- 6。 多餘因子4捨棄不用,排序方式中的3,可使用升序或降序任意填充,由於4因子3水平表中沒有全部取2與3的情況,因此根據經驗再補充兩條,最終得到表4- 7所示的正交表。 表4- 7優化後的商品顯示測試組合結合搜索條件,利用禪道設計用例如圖4- 9所示。 圖4- 9商品搜索功能測試用例 上述測試用例案例讀者可參考《附錄二 ECShop測試用例案例列表》。通過上述過程,測試工程師完成測試用例的設計工作,評審通過後等待測試版本發布,然後進行測試用例執行、跟蹤處理缺陷等活動。Tips:作為一名軟體測試工程師,本人日常也會分享一些關於軟測的乾貨專欄文章(如下方的app自動化測試),感興趣的話不妨關注一波哈?匯智動力IT學院:App自動化測試用例格式和App的啟動與關閉?zhuanlan.zhihu.com 我是匯智妹,一枚軟體測試工程師萌妹紙,每天除分享IT技術乾貨之外,也會聊聊IT圈熱議的那些事兒;公號【匯智動力】——職場技能提升、助你加薪升職,有對IT行業感興趣的小夥伴記得關注/私信我吧~比心? 注意以下幾點,測試用例規範,小白也能搞定! 測試用例編寫規範 主要分為三大部分:基本信息、主體信息、執行結果用例的基本信息:功能模塊、編寫人、編寫時間用例的主體信息:編號,測試對象,測試點,預置條件,測試步驟,測試數據,預期結果,用例優先順序用例的執行結果:執行通過/不通過/未執行/無法執行 測試用例的原則 百分之百的覆蓋需求(儘可能的覆蓋需求) 測試用例的編寫方法 等價類:根據需求,將所有的輸入數據合理的劃分等價類。邊界值:一般是用最大值,最小值,最小值-1,最大值+1作為邊界值。場景法:通過對每個用例的場景進行場景分析,逐步實現測試用例的構造,通常採用思維導圖工具梳理業務流程圖一般準則:至少覆蓋所有狀態一次,至少覆蓋所有事件一次,至少覆蓋所有路徑一次。 錯誤推斷法:是根據經驗或直覺推測可能存在的各種錯誤。正則表達式:通常被用來檢索、替換哪些符號某個規則的文本(如手機號碼、郵箱)因果圖:適合檢查程序輸入各個條件的各種組合情況。因果圖轉為判定表。一般使用在輸入條件的的各種組合判定表:與因果圖結合使用 大綱法:拆分系統模塊(一般原型圖已經拆分) 主要用在測試計劃正交法:一般不用這種方式測試(因為太過繁瑣,需要將所有輸入和結果進行組合) 方法選擇(借鑒別人的打油詩,僅供參考)所有輸入選等價給定範圍加邊界條件孤立想判定指定常量取正交跨界操作流程法 多種狀態遷移圖條件組合出因果測試充分全覆蓋多種方法不唯一 測試用例優先順序劃分 高 :用戶經常執行的業務邏輯操作,涉及金錢的功能等中 :用例多數包括邊界值、逆向邏輯等低 :很少被用戶執行的操作 下面是目錄,可以根據自己的需求來選擇性閱讀哈→→測試用例是什麼?→→測試用例有什麼必備的方面?→→寫測試用例的方法有哪些?→→測試用例怎麼寫?→→測試用例用什麼寫? 1.測試用例是什麼? 測試用例是指對一項特定的軟體產品進行測試任務的描述,體現測試方案、方法、技術和策略。簡單地認為,測試用例是為某個特殊目標而編製的一組測試輸入、執行條件以及預期結果,用於核實是否滿足某個特定軟體需求 2.測試用例有什麼必備的方面? 編寫測試用例的八大要素有:用例編號,所屬模塊,測試標題,重要級別,前置條件,測試輸入,操作步驟,預期結果 3.寫測試用例的方法有哪些? 知道了什麼是測試用例,那該怎麼寫測試用例呢?不著急,先來學習一下測試用例的方法有哪些 (1) 等價類劃分 原作者:xuping511_to原文鏈接:https://wenku.baidu.com/view/f7684221bcd126fff7050bef.html#來源:百度文庫 將測試中所有可能的輸入數據(有效的和無效的)劃分成若干個等價類。然後從每個部分中選取具有代表性的數據當做測試用例進行合理的分類,測試用例由有效等價類和無效等價類的代表組成,從而保證測試用例具有完整性和代表性 舉個栗子:輸入框要求輸入1-100的數有效等價類:可以輸入1-100之間的數來驗證,如:2、6……99無效等價類:可以輸入1-100之外的任意字元驗證,如:250、字母、下劃線、特殊符號、空格、回車..... (2) 邊界值 原作者:xuping511_to原文鏈接:https://wenku.baidu.com/view/f7684221bcd126fff7050bef.html#來源:百度文庫 邊界值分析法就是對輸入或輸出的邊界值進行測試的一種黑盒測試方法。通常邊界值分析法是作為對等價類劃分法的補充,這種情況下,其測試用例來自等價類的邊界。 實踐告訴我們:大量的錯誤是出在輸入輸出的邊界價上。我們還拿上面的例子,一個輸入框要求輸入1-100之間的數。我們要測它有沒有超出這個範圍,如:0、-1、-2、10、101.....等等,來判定是否超出了我們的範圍。 (3)因果圖 用圖解的方法表示輸入的各種組合關係,寫出判定表,從而設計相應的測試用例。最終生成的就是判定表,它適合於檢查程序輸入條件的各種組合情況。原文鏈接:https://www.docin.com/p-2173458956.html原作者:邊雄剛原文出處:豆丁 例子:有一個處理單價為5角錢的飲料的自動售貨機軟體測試用例的設計。其規格說明如下:若投入5角錢或1元錢的硬幣,押下〖橙汁〗或〖啤酒〗的按鈕,則相應的飲料就送出來。若售貨機沒有零錢找,則一個顯示〖零錢找完〗的紅燈亮,這時在投入1元硬幣並押下按鈕後,飲料不送出來而且1元硬幣也退出來;若有零錢找,則顯示〖零錢找完〗的紅燈滅,在送出飲料的同時退還5角硬幣。 解析:如題可知,可分析出原因和結果原因:1. 售貨機有零錢找2. 投入1元硬幣3. 投入5角硬幣4. 按下橙汁按鈕5. 按下啤酒按鈕結果:10.售貨機【零錢找完】燈亮11.退還1元硬幣12.退還5角硬幣13.送出橙汁飲料14.送出啤酒飲料中間結點:6.選商品7.應該找零錢8.能夠找零錢9.錢已付清如下所示↓:畫出因果圖(原因結點列在左邊,所有結果結點列在右邊,中間節點表示處理的中間狀態) 自動售貨機的因果分析圖 (4) 錯誤推測法 基於經驗和直覺推測出系統可能存在的錯誤,從而有針對性的設計測試用例的方法 (5) 其它方法 除了上面幾種常用的,其它的方法還有:狀態遷移圖、流程分析法、正交驗證法等等我在逛博客園的時候看到一首打油詩,我覺得非常合適: 所有輸入選等價 給定範圍加邊界 條件孤立想判定 指定常量取正交 跨界操作流程法 多種狀態遷移圖 條件組合出因果 4.測試用例怎麼寫? 當~當~當~終於來到重頭戲了,讓我們來看看怎麼寫一個合格的測試用例吧 我在百度上隨便找的一個登錄頁面,下面我們就根據這個圖片來寫測試用例吧用例編號:唯一標識用例的序號。一般是數字或者模塊字母+數字組合。如:L001,L表示登錄,001表示用例序號所屬模塊:所測功能模塊的名稱,如:登錄模塊用例名稱:就是這個用例是什麼意思。如:輸入賬號前置條件:前置條件可以保障後面的測試步驟正常進行,可以理解為執行當前用例的前提條件。比如:只有註冊過的用戶才能登錄測試輸入:用例執行期間輸入的外部信息。根據用例的種類不同,測試輸入也有所不同。包括數據、圖片、手工操作、文件、資料庫記錄等類型測試步驟:詳細完整的把你測試的過程描述出來預期結果:對當前用例的輸出做一個預期值。預期結果是根據軟體需求所得出的,相當於一個衡量標準。在實際測試過程中,得到的實際測試結果與預期結果不符,那麼測試不通過;反之則測試通過。實際結果:實際測出來的結果(可能會和預期結果不符)另外,有些公司可能會要求在用例後面添加優先順序、用例人員姓名、測試日期、用例修改日期、測試結果(Pass、Fail、Block)等等,這個得根據公司的會實際情況來看我根據上面的登錄頁面寫了一個登錄模塊的測試用例,如下表所示,你們可以參考一下: 登錄模塊的測試用例PS:都看到這裡了,真的不考慮給這麼用心的我 @可樂豆一個點贊、關注嗎?(*?▽?*) 5.測試用例用什麼寫? 測試用例可以以Word或者Excel的方式呈現,主要用到的工具有禪道、testlink等等 另外,網上有很多軟體測試的模板。(本來這裡有一個博客園模板的鏈接,知乎告訴我違規了,想要的可以私我,當然你們也可以去博客園自己找)對了,關於軟體測試的學習路線,可以看一下我之前寫的文章,裡面非常詳細的寫了軟體測試的技術學習路線和每個階段該具體該學什麼:2020最全軟體測試學習路線和資料分享好了,終於寫完了這篇文章。如果你喜歡這篇文章就請點贊關注一下@可樂豆吧。總之,關注可樂,入股不虧~(筆芯)後續,可樂也會發布關於軟體測試的相關文章 安裝卸載測試?安裝程序是第三方的還是自己寫的?第三方的簡單,好的情況他都處理好了,只要確保調用正常就可以。案例檢查配置文件需要修改的地方是不是配置正確。自己寫的要測的就多了。一 界面一共幾個界面,界面元素,位置,文字,是否有效二 安裝1.預設安裝安裝完成後啟動成功拷貝的文件位置正確,數量正確,文件完整,許可權正確創建文件成功,位置正確,內容正確,許可權正確鏈接文件創建成功,鏈接正確,許可權正確註冊表修改成功,內容正確安裝日誌無報錯2.自定義安裝安裝路徑創建成功自定義配置正確3.安裝失敗錯誤處理:許可權不足,空間不足,文件拷貝不全……安裝日誌內容正確手動取消,退回上一步,退出安裝程序,清除已安裝文件4.再次安裝,覆蓋已有文件或升級已有文件三 卸載目標文件已刪除註冊表內容修改成功卸載日誌內容正確另外,如圖,存在幫助,調用幫助成功就測試案例來說,明確測試目的,測試點是否已覆蓋,測試步驟明確可操作,測試結果明確可驗證,必要時輔助測試數據再複雜一些,說明所使用的測試方法,測試工具,自製腳步……最終目的,使其他測試人員能復現整個測試過程,查找沒有覆蓋的測試點,優化測試數據,測試方法,測試工具,更有效的保證軟體質量 哈嘍我來了 感謝邀請!! 在企業的實際工作當中,為了提高測試的覆蓋率,提高測試過程的可追溯性,我們往往需要通過需求分析從而編寫大量的測試用例,看似簡單的測試用例其實隱藏著眾多邏輯和技巧在內,寫出一份優質的測試用例能夠大大的提高測試質量,從而發現更多的BUG,寫好測試用例其實並不容易!下面我來說說到底如何編寫一個測試用例呢?步驟是怎麼樣的?作為測試新人,如何實現測試用例的設計一直是大家共同的困惑,在工作中我們該如何展開測試用例的編寫工作呢?我們先來梳理一個測試用例的設計步驟。 前提: 再去編寫測試用例之前我們要對我們的項目需求進行了解,按照什麼順序測試,去測什麼?覆蓋哪些內容和需求都要自己心裡有數,作為測試用例的編寫者不僅瞭解要有工作當中常見的測試用例編寫方法,同時需要了解被測軟體的設計、功能規格說明、用戶試用場景以及程序/模塊的結構。 步驟: 1、測試需求分析需求分析就是要弄清楚用戶需要的是什麼功能,用戶會怎樣使用系統。這樣我們測試的時候才能更加清楚的知道系統該怎麼樣運行,才能更好的設計測試用例,才能更好的測試。測試需求分析是測試工作的第一步,經過需求分析,對原始需求列表中列出的每一個需求點,找到我們需要測試的測試要點;針對所確定的測試要點,分析測試執行時對應的測試方案/方法。 2、業務流程分析 分析完需求後,明確每一個功能的業務處理流程,不同的功能點作業務的組合,以及項目的隱式需求。如遇複雜的測試用例設計前,先畫出軟體的業務流程。 從業務流程上,應得到以下信息: A、 主流程是什麼? B、 條件備選流程是什麼? C、 數據流向是什麼? D、 關鍵的判斷條件是什麼?例如:app測試流程及業務流程 3、測試用例設計 完成以上兩步則可進行測試用例設計,功能測試用例,應盡量考慮邊界、異常、性能的情況,以便發現更多的隱藏問題。4.編寫完成後自我檢查以及部門內部評審 5.測試用例更新完善 測試用例編寫完成之後需要不斷完善,如遇需求更改或功能新增時,測試用例必須配套修改更新,同時在測試過程中發現設計測試用例時考慮不周,需要對測試用例進行修改完善;在軟體交付使用後客戶反饋的軟體缺陷,而缺陷又是因測試用例存在漏洞造成,也需要對測試用例進行完善。好的測試用例是怎麼樣的? 一.質量屬性 1.正確性:確保測試標題描述部分的內容正確性。 2.經濟性:只為確定需要的目的設計相應的測試步驟 3.適應性:既能適應短期需要,又能考慮長遠需要。 4.可追蹤性:用例能追蹤到一個具體的需求。 5.自我清理性:單個用例不會影響整個測試環境,即用例執行完了可以恢復原有的測試環境。 二.結構化和可測試性 1.含有規範的測試標題和編號。 2.含有一個確定的測試某一個特定需求的目的。 3.含有關於測試方法的描述。 4.指定條件信息-環境、數據、預置的條件測試、安全入口等。 5.含有操作步驟和預期結果。 6.陳述任何輔助證據,例如截圖報告並確保這些東西妥善保存。 7.確保測試環境的乾淨(即用例不會影響整個環境)。 8.描述時使用主動語氣結構。 9.操作步驟不要超過15步 10.確保單個用例測試執行時用時不超過20分鐘。 11.自動化腳本用例添加必要的注釋,比如目的、輸入和期望結果。 12.如果可能,建議提供可選擇性的預置條件測試。 13.用例之間的先後順序是否跟業務流程一致,即用例在業務流程中的彼此順序關係是否合理。 三.配置管理 1.採用命名和編號規範歸檔。 2.保存為特定的格式,文件類型。 3.用例版本是否與當前被測試軟體版本一致(對應)。 4.包含用例需要的相應測試對象,如特定資料庫。 5.存檔閱讀。 6.存檔時按角色控制訪問方式希望可以幫到題主有什麼問題私信我,還有免費資料可以領取! 測試用例組成部分一般是:前置條件,測試步驟,期望結果,用例等級,用例類型等等。具體要怎麼寫就太寬泛了,一般是根據需求點去寫,靈活運用等價類劃分、邊界值分析、組合覆蓋、邏輯推斷、業務路徑覆蓋等等設計方法,並在測試中不斷完善和新增…… 推薦閱讀: 相關文章 {{#data}} {{title}} {{/data}}