[测试用例设计]
目錄
登錄界面測試
微信紅包測試
微信朋友圈測試用例
測試一個輸入框(計數)
測試百度搜索
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.相交链表