嗨，大家好，我是葉子
關於測試用例設計，根據業務不同，能力不同，設計的測試用例也完全不同，以下是關於一個老掉牙的案例，“登錄”功能。
需求：做為用戶，我想輸入賬號、密碼及驗證碼，以便我能正常登錄系統
根據以上需求，不同的測試人員，可能會設計出來不同的測試用例來進行登錄功能的測試，有興趣的小伙伴，可以看一下自己有哪些沒有想到，也歡迎小伙伴繼續補充：
登錄用例設計-1
- 輸入已注冊的用戶名和正確的密碼，驗證是否登錄成功
- 輸入已注冊的用戶名和不正確的密碼，驗證是否登錄失敗，並且提示信息正確
- 輸入未注冊的用戶名和任意密碼，驗證是否登錄失敗，並且提示信息正確
- 用戶名和密碼兩者都為空，驗證是否登錄失敗，並且提示信息正確
- 用戶名和密碼兩者之一為空，驗證是否登錄失敗，並且提示信息正確
- 如果登錄功能啟用了驗證碼功能，在用戶名和密碼正確的前提下，輸正確的驗證碼，驗證是否登錄成功
- 如果登錄功能啟用了驗證碼功能，在用戶名和密碼正確的前提下，輸不正確的驗證碼，驗證是否登錄失敗，並且提示信息正確
- 是否支持第三方登錄
設計出以上用例，你可能覺得比較滿意了，因為看上去這些用例已經覆蓋了需求點。不錯，上面的用例確實覆蓋了需求的主要的測試場景，可是對於一個更為優秀的測試工程師，可能這只是滿足了基礎測試，那么有經驗的測試工程師會如何設計測試用例，又會增加哪些測試用例：
登錄用例設計-2
- 用戶名、密碼、驗證碼是否大小寫敏感
- 頁面上的密碼框是否加密顯示
- 后台系統創建的用戶第一次登錄成功時，是否提示修改密碼
- 忘記用戶名和忘記密碼的功能是否可用
- 前端頁面是否根據設計要求限制用戶名和密碼長度
- 點擊驗證碼圖片是否可以更換驗證碼，更換后的驗證碼是否可用
- 刷新頁面是否刷新驗證碼
- 如果驗證碼有時效性，需要分別驗證時效內和時效外驗證碼的有效性
- 不同級別的用戶，登錄系統后權限是否正確
- 用戶登錄超時后，繼續操作是否會重定向到用戶登錄界面
- 頁面默認焦點是否定位在用戶名的輸入框中
- 網絡環境之間切換，驗證登錄功能是否正常
- 快捷鍵Tab和Enter等，是否可以正常使用
- 是否可以利用抓包工具抓到請求直接登錄
- 除了前端驗證格式及長度，后端是否也校驗？
- 已登錄的用戶，殺死APP進程后，再次打開APP是否依然為已登錄狀態
- 登錄成功后，session的時效性設置
到了這里，是不是這里有點兒吃驚，一個簡單的登錄需求，居然能設計出這么多的測試點，不用驚訝，淡定~~~對於一位資深的測試人員來說，上面這些遠遠還不夠，可能還需要一些安全性相關的測試，那么還會有哪些測試用例吶~~，別急，跟我來~~~
登錄用例設計-3
性能測試設計點：
- 單用戶登錄的響應時間是否小於3秒
- 單用戶登錄時，后台請求數量是否過多
- 高並發場景下，用戶登錄的響應時間是否小於5秒
- 高並發場景下，服務器的監控指標是否符合預期
- 高集合點並發場景下，是否存在資源死鎖和不合理資源等待
- 長時間大量用戶連續登錄和登出，服務器端是否存在內存泄漏
安全測試測試點：
- 用戶密碼后台存儲是否加密
- 用戶密碼在網絡傳輸過程中是否加密
- 密碼是否有有效期，到期后，是否提示需要修改密碼
- 不登錄的情況下，在瀏覽器中直接輸入登錄后的URL地址，驗證是否會重新定向到用戶登錄界面
- 密碼輸入框是否支持復制和粘貼
- 用戶名和密碼輸入框 中分別輸入典型SQL注入攻擊字符串，驗證系統行為是否被篡改
- 連續多次登錄失敗情況下，系統是否會阻止后續的嘗試，以應對暴力破解
- 同一用戶在同一終端的多種瀏覽器上登錄，驗證登錄功能的互斥性是否符合設計預期
- 同一用戶先后在多台終端的瀏覽器上登錄，驗證登錄是否具有互斥性
- 異地登錄的校驗，更換設備的校驗，登錄異常是否考慮賬號凍結
看到這里，你可能覺得，這下全了吧，不不不，我們是不是忘記了點兒什么?兼容性測試去了哪里？來來來~~~下面就增加兼容性測試點：
登錄測試設計-4
兼容性測試：
- 不同平台下，驗證登錄頁面的顯示及功能的正確性
- 不同設備下，驗證登錄頁面的顯示及功能的正確性
- 不同瀏覽器下，驗證登錄頁面的顯示及功能的正確性
- 不同分辨率下，驗證登錄頁面顯示及功能的正確性
- 同一瀏覽器，不同版本下，驗證登錄頁面顯示及功能正確性
看完上面登錄功能的測試點設計，你還認為登錄功能很簡單嗎？在任何時候，我們接到一個功能的需求時，除了考慮覆蓋需求功能的測試點以外，也需要考慮非功能測試點設計，這樣才能更好的保證功能的完整性。
以上信息傳達的是一種設計思路，當然針對登錄功能還會有更多的測試點，這個就需要根據項目開發過程中，測試的時間成本和經濟成本，基於風險驅動的模式下，有所側重地選擇測試范圍和設計測試用例，以尋求缺陷風險和研發成本之間的平衡。
注：以上資料參考茹老師（茹炳晟）的極客時間里的《軟件測試52講》