[测试用例设计]
目錄
登錄界面測試
微信紅包測試
微信朋友圈測試用例
測試一個輸入框(計數)
測試百度搜索
BUG描述、評級
一條bug記錄的組成
登錄界面測試
以用戶登錄為例,一般的小白可能只能夠想到一些功能性測試(如下)。
現在,針對“用戶登錄”功能,基于等價類劃分和邊界值分析方法,我們設計的測試用例包括:
- 輸入已注冊的用戶名和正確的密碼,驗證是否登錄成功;
- 輸入已注冊的用戶名和不正確的密碼,驗證是否登錄失敗,并且提示信息正確;
- 輸入未注冊的用戶名和任意密碼,驗證是否登錄失敗,并且提示信息正確;
- 用戶名和密碼兩者都為空,驗證是否登錄失敗,并且提示信息正確;
- 用戶名和密碼兩者之一為空,驗證是否登錄失敗,并且提示信息正確;
- 如果登錄功能啟用了驗證碼功能,在用戶名和密碼正確的前提下,輸入正確的驗證碼,驗證是否登錄成功;
- 如果登錄功能啟用了驗證碼功能,在用戶名和密碼正確的前提下,輸入錯誤的驗證碼,驗證是否登錄失敗,并且提示信息正確。
乍一看,感覺測試案例已經夠多了,不過對于一個稍微有點經驗的工程師,可能會加上下面部分
- 用戶名和密碼是否大小寫敏感;
- 頁面上的密碼框是否加密顯示;
- 后臺系統創建的用戶第一次登錄成功時,是否提示修改密碼;
- 忘記用戶名和忘記密碼的功能是否可用;
- 前端頁面是否根據設計要求限制用戶名和密碼長度;
- 如果登錄功能需要驗證碼,點擊驗證碼圖片是否可以更換驗證碼,更換后的驗證碼是否可用;
- 刷新頁面是否會刷新驗證碼;
- 如果驗證碼具有時效性,需要分別驗證時效內和時效外驗證碼的有效性;
- 用戶登錄成功但是會話超時后,繼續操作是否會重定向到用戶登錄界面;
- 不同級別的用戶,比如管理員用戶和普通用戶,登錄系統后的權限是否正確;
- 頁面默認焦點是否定位在用戶名的輸入框中;
- 快捷鍵Tab 和Enter等,是否可以正常使用。
上述還僅僅只是功能測試,你還可以從其他的角度比如安全性、性能以及兼容性三大方面。 在上面所有的測試用例設計中,我們完全沒有考慮對非功能性需求的測試,但這些往往是決定軟件質量的關鍵因素。>
安全性測試用例包括
- 用戶密碼后臺存儲是否加密;
- 用戶密碼在網絡傳輸過程中是否加密;
- 密碼是否具有有效期,密碼有效期到期后,是否提示需要修改密碼;
- 不登錄的情況下,在瀏覽器中直接輸入登錄后的URL地址,驗證是否會重新定向到用戶登錄界面;
- 密碼輸入框是否不支持復制和粘貼;
- 密碼輸入框內輸入的密碼是否都可以在頁面源碼模式下被查看;
- 用戶名和密碼的輸入框中分別輸入典型的“SQL注入攻擊”字符串,驗證系統的返回頁面;
- 用戶名和密碼的輸入框中分別輸入典型的“XSS跨站腳本攻擊”字符串,驗證系統行為是否被篡改;
- 連續多次登錄失敗情況下,系統是否會阻止后續的嘗試以應對暴力破解;
- 同一用戶在同一終端的多種瀏覽器上登錄,驗證登錄功能的互斥性是否符合設計預期;
- 同一用戶先后在多臺終端的瀏覽器上登錄,驗證登錄是否具有互斥性。
性能壓力測試用例包括:
- 單用戶登錄的響應時間是否小于3秒;
- 單用戶登錄時,后臺請求數量是否過多;
- 高并發場景下用戶登錄的響應時間是否小于5秒;
- 高并發場景下服務端的監控指標是否符合預期;
- 高集合點并發場景下,是否存在資源死鎖和不合理的資源等待;
- 長時間大量用戶連續登錄和登出,服務器端是否存在內存泄漏。
兼容性測試用例包括:
- 不同瀏覽器下,驗證登錄頁面的顯示以及功能正確性;
- 相同瀏覽器的不同版本下,驗證登錄頁面的顯示以及功能正確性;
- 不同移動設備終端的不同瀏覽器下,驗證登錄頁面的顯示以及功能正確性;
- 不同分辨率的界面下,驗證登錄頁面的顯示以及功能正確性。
微信紅包測試
單個紅包:
- 紅包金額為空、0、0.01、200.00、200.01、199.99、200
- 留言輸入數字、字母、漢字、特殊字符
- 留言長度
- 留言復制粘貼
- 表情選擇、收藏表情、其他表情
- 刪除表情、重新選擇表情
- 選擇支付方式零錢、銀行卡、添加新卡支付。其中錢數<紅包錢數、其中錢數=紅包錢數、其中錢數>紅包錢數
- 使用指紋確認付款(正確的、錯誤的指紋)
- 使用密碼確認付款(正確的、錯誤的密碼)
- 紅包成功發送后 相應支付方式中錢數減少(減少金額與紅包金額一致)
- 接受者能看到紅包具體信息,紅包金額、留言、表情均能正確顯示
- 紅包被拆開后顯示已領取,領取者零錢中增加正確金額,再次領取只能查看紅包信息
- 發紅包者自己領紅包
- 紅包24小時未被領取提示紅包被退回,相應支付方式中錢數增加(增加金額與紅包金額一致),對方不能領紅包
群發紅包-普通紅包: (只寫了與單個紅包不同的地方)
- 紅包個數 為空、0、001、100、99、101
- 紅包拆開每個金額一樣 均為發紅包時設置的單個金額對應的錢數
- 紅包被拆時,有相應提示
- 發紅包者自己領紅包
- 紅包24小時內未被拆完,剩余錢被退回,相應支付方式中錢數增加
群發紅包-拼手氣紅包:
- 紅包每個人拆開金額不同,總金額與發紅包設置的總額一致
- 紅包24小時內拆完后顯示最佳手氣
- 紅包24小時內未被拆完不顯示最佳手氣
兼容性測試
兼容性: 安卓、蘋果 不同型號版本手機
UI測試: 界面無錯別字,風格統一
中斷測試: 不同應用之間切換、斷網、來電、短信、低電量、手機沒電
網絡測試: 2g/3g/4g WiFi 移動聯通電信 弱網 無網
微信朋友圈測試用例
朋友圈發送功能
- 只發送文本
? a、考慮文本長度:1-1500字符(該數據為百度數據)、超出最大字符長度
? b、文本是否支持復制粘貼
? c、為空驗證
- 只發送圖片
? a、本地相冊選擇/拍攝
? b、圖片數量驗證:1-9張圖片、超出9張
? c、為空驗證
- 只發送視頻
? a、本地相冊選擇/拍攝
? b、視頻秒數驗證:1-10s,超出10s
? c、視頻個數驗證:1個,超出1個
? d、視頻格式驗證:支持的視頻格式,例mp4、不支持的視頻格式
? e、視頻大小驗證:蘋果400kb以內、Android200-300kb(此為百度數據)、超出規定大小
? f、視頻預覽增刪改操作
? g、為空驗證
- 發送文本+圖片:輸入滿足要求的文本、圖片進行一次驗證
- 發送圖片+視頻:不支持發送
- 朋友圈發送內容是否有限制,例如涉及黃賭毒等敏感字
- 所在位置
? a、不顯示位置:發送到朋友圈動態不顯示位置
? b、選擇對應位置:搜索支持、自動定位、手動編輯
? C、點擊取消,返回上一級頁面
- 誰可以看
? a、設置公開:所有朋友可見
? b、設置私密(僅自己可見):自己查看朋友圈-可見、好友查看朋友圈-不可見
? c、設置部分可見(部分朋友可見):選擇的部分好友-可見、不被選擇的好友-不可見、是否有人數上限
? d、設置不給誰看(選中的朋友不可見):不被選中的朋友-可見、被選中的朋友-不可見、是否有人數上限
? e、點擊取消,返回發送頁面
- 提醒誰看
? a、提醒單人/提醒多人:被提醒的朋友-收到消息提醒、未被提醒-未有消息提醒
? b、是否有人數上限
? c、點擊取消,返回發送頁面
-
同步QQ空間:默認不同步、同步到QQ空間
-
取消發送朋友圈操作
? a、選擇相機,點擊取消,返回朋友圈頁面
? b、進入朋友圈發送頁面,選擇文本圖片,點擊取消
? 13)朋友圈當天發送次數是否有上限限制
朋友圈瀏覽功能
- 文本查看:
? a、過長文本內容是否隱藏,并支持查看全文
? b、右鍵選擇復制、收藏、翻譯
? c、url鏈接是否支持點擊跳轉網頁
- 圖片查看
? a、小圖右鍵支持收藏/編輯
? b、點擊支持大圖瀏覽
? c、選擇發送給朋友、收藏、保存圖片、編輯
? d、多張圖片支持左右滑動瀏覽
- 視頻查看
? a、右鍵視頻支持靜音播放/搜藏
? b、點擊視頻播放按鍵支持播放視頻
? c、選擇發送給朋友、收藏、保存視頻、編輯
-
分享動態瀏覽:QQ空間/公眾號文章/非騰訊產品分享后朋友圈是否正常顯示
-
贊:點贊、取消點贊
-
評論
? a、評論長度:評論字數合理長度、評論超過字數上限
? b、評論類型:純中文、純數字、純字母、純字符、純表情(微信表情/手機自帶表情)、混合類型、包含url鏈接;
? c、評論是否支持復制粘貼
? d、為空驗證
? e、發表評論后刪除
? f、評論回復操作
-
刪除朋友圈動態
-
更換相冊封面
-
刷新是否正常獲取新動態
-
上滑是否加載更多
界面/易用性測試
? 1、技術人員角度:頁面布局設計是否跟產品原型圖/ui效果圖一致
? 2、但除了考慮1之外,我們同樣要考慮到用戶使用:功能操作是否簡便,頁面布局排版風格是否美觀合理,提示語相關信息是否易于理解
中斷測試
? 1、主要考慮:a)核心功能 b)當前功能存在實時數據交換,例發朋友圈、瀏覽朋友圈進行中斷,是否容易出現崩潰
? 2、中斷包括:前后臺切換、鎖屏解鎖、斷網重連、app切換、來電話/來短信中斷、插拔耳機線/數據線
網絡測試
? 1、三大運營商不同網絡制式測試
? 2、網絡切換測試:WIFI/4G/3G/2G
? 3、無網測試:對于緩存在本地的數據,部分朋友圈信息是否支持瀏覽
? 4、弱網測試:
? a、延時:頁面響應時間是否可接受、不同網絡制式是否區分超時時長、出現請求超時,是否給予相應的提示
? b、丟包:有無超時重連機制、如果未響應,是否給予相應提示
? c、頁面呈現的完整性驗證
兼容性測試
? 1、Android手機端、蘋果手機端、pad版(主流)功能界面顯示是否正常
? 2、各平臺朋友圈展示數據是否一致
安全測試
? 發送朋友圈時,文本輸入腳本代碼,是否出現異常
性能測試
? 1、服務器性能測試
? 可通過loadrunner/jmeter工具實現,主要關注TPS、響應時間、吞吐量、CPU、內存等
? 2、app客戶端性能測試
? 可通過GT工具實現,運行時關注cpu、內存、流量、電量等占用率
? 3、app壓力穩定性測試
? 通過monkey工具實現,頻繁發送朋友圈,瀏覽朋友圈請求,是否容易發生崩潰
測試一個輸入框(計數)
通常說來,我們考慮一個測試對象的時候至少從以下六方面來考慮。
- 功能性
- 易用性
- 可靠性
- 性能
- 安全
- 兼容性
? 如果你是一個測試菜鳥,從功能性出發,你可能會列出以下一個典型的列表:
- “banana”:3(一個合法的英文字)。
- “A” 和“a”:1(一個簡單有正常結果的合法輸入)。
- “”:0(一個簡單的結果為0的合法輸入)。
- Null:0(簡單的錯誤輸入)。
- “AA” 和“aa”:2(個數大于1并且所有字符都為a/A的輸入)。
- “b”:0(一個簡單的非空合法輸入,結果為0)。
- “aba”:2(目標字符出現在開頭和結尾,以尋找循環邊界錯誤)。
- “bab”:1(目標字符出現在中間)。
- space/tabs:N(空白字符與N個a的混合)。
- 不包含a的長字符串:N(N大于0)。
- 包含a的長字符串:N(N是a的倍數,試試龍媽的名字)。
? {java/C/HTML/JavaScript}:N是a出現的個數(可執行字符,或錯誤,或代碼解釋)。
更優秀的測試工程師,會開始考慮后面五個方面,設計以下用例。
- 質疑界面的外觀、調色板和對比度(這與相關應用風格一致么?)
- 文本框太小了,建議加長以便顯示更長的輸入字符串
- 這個應用能否在同一臺服務器上運行多個實例,多個用戶同時使用是否會有問題。
- 是否會根據用戶的輸入自動匹配內容?
- 建議使用真實的數據,如從詞典或書中選擇輸入內容。
- 提出疑問:“輸入的數據是否會被保存”,輸入字符串可能包含地址或其他身份信息。
- 輸入HTML和JavaScrip,看是否會破壞頁面渲染。
- 嘗試復制/粘貼字符串。
- 提出疑問:“計算足夠快么?在大并發下使用”。
- 提出疑問:“用戶怎么找到該頁面?”
- 提出疑問:“有快捷鍵的設置么?比如輸完字符后敲入回車鍵而不是點擊提交按鈕”
? 還有一些測試點,只有經驗豐富的測試工程師才會想到。
- 意識到計算會通過URL-encodedHTTP GET請求傳遞到服務器,字符串可能會在網絡傳輸時被截斷,因此,無法保證支持多長的URL。
- 建議將此功能參數化,為什么只對字母a計算呢?
- 考慮計算其它語言中的a(α,Alpha)。
- 考慮到該應用是否應該國際化。
- 考慮到輸入法全角輸入和半角輸入是否相同。
- 考慮編寫腳本或者手工采樣來探知字符串長度的上限,然后確保在此區間內功能正常。
- 考慮背后的實現和代碼。也許已經有一個計數器遍歷該字符串。
- 提出疑問:“HTTP POST方法和參數會被黑掉碼?也許有安全漏洞?”
測試百度搜索
我們可以從以下幾個角度進行測試。
功能測試:
輸入搜索信息,點擊搜索按鈕是否能獲取搜索結果,跳到結果界面; 搜索結果界面彈出的信息是不是符合我輸入的信息 , 沒有輸入信息,按搜索看會有什么結果 ,對輸入框能輸入的最大字符數進行邊界測試,(假設限制是30個字符),那么分別輸入20,30,31個字符的文本進行測試,測試超出輸入限制會出現的結果
測試輸入敏感詞時的搜索結果,輸入不同國家語言的搜索結果 ,查詢不到搜索結果的情況顯示的結果,從搜索結果界面返回的按鈕能不能正常返回
點擊百度的標簽能不能跳到相關的熱搜界面
測試百度的圖片搜索能不能正常使用
圖片拖曳和上傳的功能是否均能實現,粘貼圖片網址能不能用
如果粘貼的圖片網址不存在是否能給出正確的提示反饋
輸入特別大的圖會發生什么現象
性能測試:
測試搜索時的響應時間能否符合需求
網速慢的條件下還能不能正常搜索
多用戶同時訪問,或者一個時間點訪問量突然增大的情況,對這些特殊情況進行模擬,測試還能不能進行正常搜索
易用性測試:
使用操作是否簡單,是不是輸入查詢信息之后點擊搜索按鈕就行了;
在輸入框輸入搜索詞的過程中下拉框能否彈出相關的聯想搜索(你可能要搜)
輸入框有沒有保存最近搜索的信息的記錄
除了點擊搜索按鈕進行搜索,測試按回車進行檢索的功能
兼容性測試:
多種系統下的多種不同的瀏覽器下是否能正常顯示、正常使用;
在不同的手機瀏覽器中打開是否能正常顯示、正常使用;
各種語言平臺下是否都能正常使用
安全性測試:
能不能防止搜索時對數據庫的惡意攻擊的情況,如SQL注入
UI
界面設計是否簡介,是否符合用戶審美
圖標能不能正常顯示,界面有無錯別字
BUG描述、評級
對bug的描述盡量簡短但要求清晰,對bug出現的條件進行詳細的描述,包括輸入的測試用例、使用的環境、有沒有和其他軟件同時運行,以及需要寫清bug出現的位置,幫助開發更好定位。
按照用戶體驗(bug是否很嚴重的影響用戶體驗)、影響系統的程度進行評級
一條bug記錄的組成
- bug內容
- bug發現時間
- 測試條件(系統配置信息、環境、軟件版本、瀏覽器版本…)
- 預期結果和實際結果的對比,相關的分析
- 如何重現這個bug的步驟
- 這個bug的嚴重性(會多大程度的影響系統或用戶使用)
- bug發生的位置
總結
- 上一篇: 测试知识汇总
- 下一篇: [leetcode]160.相交链表