可能你會說，“用戶登錄”這個測驗物件也有點太簡單了吧，我只要找一個用戶，讓他在界面上輸入用戶名和密碼，然后點擊“確認”按鈕，驗證一下是否登錄成功就可以了。的確，這構成了一個最基本、最典型的測驗用例，這也是終端用戶在使用系統時最典型的Happy Pass場景。
但是作為測驗工程師，你的目標是要保證系統在各種應用場景下的功能是符合設計要求的，所以你需要考慮的測驗用例就需要更多、更全面，于是你可能會根據“用戶登錄”功能的需求描述，結合等價類劃分和邊界值分析方法來設計一系列的測驗用例。
那什么是等價類劃分和邊界值分析方法呢？首先，這二者都隸屬于最常用、最典型、也是最重要的黑盒測驗方法。
等價類劃分方法，是將所有可能的輸入資料劃分成若干個子集，在每個子集中，如果任意一個輸入資料對于揭露程式中潛在錯誤都具有同等效果，那么這樣的子集就構成了一個等價類。后續只要從每個等價類中任意選取一個值進行測驗，就可以用少量具有代表性的測驗輸入取得較好的測驗覆寫結果。
邊界值分析方法，是選取輸入、輸出的邊界值進行測驗。因為通常大量的軟體錯誤是發生在輸入或輸出范圍的邊界上，所以需要對邊界值進行重點測驗，通常選取正好等于、剛剛大于或剛剛小于邊界的值作為測驗資料。
從方法論上可以看出來，邊界值分析是對等價類劃分的補充，所以這兩種測驗方法經常結合起來使用。
現在，針對“用戶登錄”功能，基于等價類劃分和邊界值分析方法，我們設計的測驗用例包括：
輸入已注冊的用戶名和正確的密碼，驗證是否登錄成功；
輸入已注冊的用戶名和不正確的密碼，驗證是否登錄失敗，并且提示資訊正確；
輸入未注冊的用戶名和任意密碼，驗證是否登錄失敗，并且提示資訊正確；
用戶名和密碼兩者都為空，驗證是否登錄失敗，并且提示資訊正確；
用戶名和密碼兩者之一為空，驗證是否登錄失敗，并且提示資訊正確；
如果登錄功能啟用了驗證碼功能，在用戶名和密碼正確的前提下，輸入正確的驗證碼，驗證是否登錄成功；
如果登錄功能啟用了驗證碼功能，在用戶名和密碼正確的前提下，輸入錯誤的驗證碼，驗證是否登錄失敗，并且提示資訊正確。
列出這些測驗用例后，你可能已經覺得比較滿意了，因為你感覺已經把自己的測驗知識都用在這些用例設計中了。的確，上面的測驗用例集已經涵蓋了主要的功能測驗場景。但是在一個優秀的測驗工程師眼中，這些用例只能達到勉強及格的標準。
什么？才剛剛及格？如果你有這個想法，那我建議你在繼續看下面的內容前，先仔細思考一下，這些測驗用例是否真的還需要擴充。
現在，我跟你分享一下有經驗的測驗工程師會再增加的測驗用例：
用戶名和密碼是否大小寫敏感；
頁面上的密碼框是否加密顯示；
后臺系統創建的用戶第一次登錄成功時，是否提示修改密碼；
忘記用戶名和忘記密碼的功能是否可用；
前端頁面是否根據設計要求限制用戶名和密碼長度；
如果登錄功能需要驗證碼，點擊驗證碼圖片是否可以更換驗證碼，更換后的驗證碼是否可用；
重繪頁面是否會重繪驗證碼；
如果驗證碼具有時效性，需要分別驗證時效內和時效外驗證碼的有效性；
用戶登錄成功但是會話超時后，繼續操作是否會重定向到用戶登錄界面；
不同級別的用戶，比如管理員用戶和普通用戶，登錄系統后的權限是否正確；
頁面默認焦點是否定位在用戶名的輸入框中；
快捷鍵Tab和Enter等，是否可以正常使用。
看完這些用例，你可能會說：“哇塞，原來一個簡簡單單的登錄功能居然有這么多需要測驗的點”。但是，你別高興得太早，“用戶登錄”功能的測驗還沒結束。
雖然改進后的測驗用例集相比之前的測驗覆寫率的確已經提高了很多，但是站在資深測驗人員的角度來看，還有很多用例需要設計。
經我這么一說，你可能已經發現，上面所有的測驗用例設計都是圍繞顯式功能性需求的驗證展開的，換句話說，這些用例都是直接針對“用戶登錄”功能的功能性進行驗證和測驗的。但是，一個質量過硬的軟體系統，除了顯式功能性需求以外，其他的非功能性需求即隱式功能性需求也是極其關鍵的。
顯式功能性需求（Functional requirement）的含義從字面上就可以很好地理解，指的是軟體本身需要實作的具體功能，比如“正常用戶使用正確的用戶名和密碼可以成功登錄”、“非注冊用戶無法登錄”等，這都是屬于典型的顯式功能性需求描述。
那什么是非功能性需求（Non-functional requirement）呢？從軟體測驗的維度來看，非功能性需求主要涉及安全性、性能以及兼容性三大方面。在上面所有的測驗用例設計中，我們完全沒有考慮對非功能性需求的測驗，但這些往往是決定軟體質量的關鍵因素。
明白了非功能性需求測驗的重要性后，你可以先思考一下還需要設計哪些測驗用例，然后再來看看我會給出哪些用例，相信這種方式對你的幫助會更大。
安全性測驗用例包括：
用戶密碼后臺存盤是否加密；
用戶密碼在網路傳輸程序中是否加密；
密碼是否具有有效期，密碼有效期到期后，是否提示需要修改密碼；
不登錄的情況下，在瀏覽器中直接輸入登錄后的URL地址，驗證是否會重新定向到用戶登錄界面；
密碼輸入框是否不支持復制和粘貼；
密碼輸入框內輸入的密碼是否都可以在頁面原始碼模式下被查看；
用戶名和密碼的輸入框中分別輸入典型的“SQL注入攻擊”字串，驗證系統的回傳頁面；
用戶名和密碼的輸入框中分別輸入典型的“XSS跨站腳本攻擊”字串，驗證系統行為是否被篡改；
連續多次登錄失敗情況下，系統是否會阻止后續的嘗試以應對暴力破解；
同一用戶在同一終端的多種瀏覽器上登錄，驗證登錄功能的互斥性是否符合設計預期；
同一用戶先后在多臺終端的瀏覽器上登錄，驗證登錄是否具有互斥性。
性能壓力測驗用例包括:
單用戶登錄的回應時間是否小于3秒；
單用戶登錄時，后臺請求數量是否過多；
高并發場景下用戶登錄的回應時間是否小于5秒；
高并發場景下服務端的監控指標是否符合預期；
高集合點并發場景下，是否存在資源死鎖和不合理的資源等待；
長時間大量用戶連續登錄和登出，服務器端是否存在記憶體泄漏。
兼容性測驗用例包括：
不同瀏覽器下，驗證登錄頁面的顯示以及功能正確性；
相同瀏覽器的不同版本下，驗證登錄頁面的顯示以及功能正確性；
不同移動設備終端的不同瀏覽器下，驗證登錄頁面的顯示以及功能正確性；
不同解析度的界面下，驗證登錄頁面的顯示以及功能正確性。
說到這里，你還會覺得“用戶登錄”功能的測驗非常簡單、不值一提么？一個看似簡單的功能測驗，居然涵蓋了如此多的測驗用例，除了要覆寫明確的功能性需求，還需要考慮其他諸多的非功能性需求。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/75070.html
標籤：軟件測試
下一篇：求容器中最大值