溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
無規矩不成方圓，做好項目就是做正確的事情，而正確地處理事情才能更好地提高效率。測試部門在接到一個新的項目后，需要按照以下五個流程逐步開展測試工作，該流程在實際的工作中，可根據實際情況進行補充和完善。
在測試人員開展工作之后，需要借助產品人員和開發人員提供的文檔，形式的文檔可以給測試工作帶來依據。具體參考文檔包括：產品需求說明書、產品設計原型、數據庫設計方案、開發部門代碼規范說明、開發人員（前端和后臺）任務分配表等。
測試工作的基本流程圖如下圖所示：
根據項目需要，目前主要進行的有功能測試和性能測試。現階段以功能測試為主，而功能測試目前使用最多的測試方法有等價類劃分法、邊界值分析法和錯誤推測法。這三種都屬于最常用、最典型、也是最重要的黑盒測試方法。 其他的方法還會涉及到因果圖法、判定表法、正交分析法、場景法等。
選取輸入、輸出的邊界值進行測試。因為通常大量的軟件錯誤是發生在輸入或輸出范圍的邊界上，所以需要對邊界值進行重點測試，通常選取正好等于、剛剛大于或剛剛小于邊界的值作為測試數據。從方法論上可以看出來，邊界值分析是對等價類劃分的補充，所以這兩種測試方法經常結合起來使用。
在很大程度上是憑經驗進行的，是憑人們對過去所作的測試工作結果的分析，對所揭示的缺陷的規律性作直覺的推測來發現缺陷的。
示例：針對“用戶登錄”功能，基于等價類劃分和邊界值分析方法，我們設計的測試用例包括：
1. 輸入已注冊的用戶名和正確的密碼，驗證是否登錄成功；
2. 輸入已注冊的用戶名和不正確的密碼，驗證是否登錄失敗，并且提示信息正確；
3. 輸入未注冊的用戶名和任意密碼，驗證是否登錄失敗，并且提示信息正確；
4. 用戶名和密碼兩者都為空，驗證是否登錄失敗，并且提示信息正確；
5. 用戶名和密碼兩者之一為空，驗證是否登錄失敗，并且提示信息正確；
6. 如果登錄功能啟用了驗證碼功能，在用戶名和密碼正確的前提下，輸入正確的驗證碼，驗證是否登 錄成功；
7. 如果登錄功能啟用了驗證碼功能，在用戶名和密碼正確的前提下，輸入錯誤的驗證碼，驗證是否登 錄失敗，并且提示信息正確。
如果再加上錯誤推測法（因人而異），會再增加以下的測試用例：
1. 用戶名和密碼是否大小寫敏感；
2. 頁面上的密碼框是否加密顯示；
3. 后臺系統創建的用戶第一次登錄成功時，是否提示修改密碼；
4. 忘記用戶名和忘記密碼的功能是否可用；
5. 前端頁面是否根據設計要求限制用戶名和密碼長度；
6. 如果登錄功能需要驗證碼，點擊驗證碼圖片是否可以更換驗證碼，更換后的驗證碼是否可用；
7. 刷新頁面是否會刷新驗證碼；
8. 如果驗證碼具有時效性，需要分別驗證時效內和時效外驗證碼的有效性；
9. 用戶登錄成功但是會話超時后，繼續操作是否會重定向到用戶登錄界面；
10. 不同級別的用戶，比如管理員用戶和普通用戶，登錄系統后的權限是否正確；
11. 頁面默認焦點是否定位在用戶名的輸入框中；
12. 快捷鍵 Tab 和 Enter 等，是否可以正常使用。
一個質量過硬的軟件系統，除了顯式功能性需求以外，其他的非功能性需求即隱式功能性需求也是極其關鍵的。顯式功能性需求的含義從字面上就可以很好地理解，指的是軟件本身需要實現的具體功能。比如“正常用戶使用正確的用戶名和密碼可以成功登錄”、“非注冊用戶無法登錄”等，這都是屬于典型的顯式功能性需求描述。從軟件測試的維度來看，非功能性需求主要涉及安全性、性能以及兼容性三大方面。 在上面所有的測試用例設計中，我們完全沒有考慮對非功能性需求的測試，但這些往往是決定軟件質量的關鍵因素。
示例：我們來繼續完善“用戶登錄”的測試用例。
在安全性方面補充的測試用例包括：
1. 用戶密碼后臺存儲是否加密；
2. 用戶密碼在網絡傳輸過程中是否加密；
3. 密碼是否具有有效期，密碼有效期到期后，是否提示需要修改密碼；
4. 不登錄的情況下，在瀏覽器中直接輸入登錄后的URL地址，驗證是否會重新定向到用戶登錄界面；
5. 密碼輸入框是否不支持復制和粘貼；
6. 密碼輸入框內輸入的密碼是否都可以在頁面源碼模式下被查看；
7. 用戶名和密碼的輸入框中分別輸入典型的“SQL 注入***”字符串，驗證系統的返回頁面；
8. 用戶名和密碼的輸入框中分別輸入典型的“XSS 跨站腳本***”字符串，驗證系統行為是否被篡 改；
9. 連續多次登錄失敗情況下，系統是否會阻止后續的嘗試以應對暴力破解；
10. 同一用戶在同一終端的多種瀏覽器上登錄，驗證登錄功能的互斥性是否符合設計預期；
11. 同一用戶先后在多臺終端的瀏覽器上登錄，驗證登錄是否具有互斥性。
站在性能壓力測試的角度測試用例包括:
1. 單用戶登錄的響應時間是否小于 3 秒；
2. 單用戶登錄時，后臺請求數量是否過多；
3. 高并發場景下用戶登錄的響應時間是否小于 5 秒；
4. 高并發場景下服務端的監控指標是否符合預期；
5. 高集合點并發場景下，是否存在資源死鎖和不合理的資源等待；
6. 長時間大量用戶連續登錄和登出，服務器端是否存在內存泄漏。
站在兼容性測試角度測試用例補充包括：
1. 不同瀏覽器下，驗證登錄頁面的顯示以及功能正確性；
2. 相同瀏覽器的不同版本下，驗證登錄頁面的顯示以及功能正確性；
3. 不同移動設備終端的不同瀏覽器下，驗證登錄頁面的顯示以及功能正確性；
4. 不同分辨率的界面下，驗證登錄頁面的顯示以及功能正確性。
對于高質量的軟件測試，用例設計不僅需要考慮明確的顯式功能性需求，還要涉及兼容性、安全性和性能等一系列的非功能性需求，這些非功能性需求對軟件系統的質量有著舉足輕重的作用。但軟件測試的用例設計是不可窮盡的，工程實踐中難免受制于時間成本和經濟成本，所以測試部門需要兼顧缺陷風險和研發成本之間的平衡。
根據缺陷的定義，將缺陷分為如下4類:
指對文檔的靜態檢查過程中發現的缺陷。檢查活動包括同行評審、產品審計等。評審的缺陷要根據被評審對象的類型來確定，被評審的對象包括最終出產出物和中間過程產出物。比如產品需求文檔、原型設計文檔、測試計劃、測試用例等。
指對代碼進行同行評審、審計或代碼走查過程中發現的缺陷。
指由測試活動發現的測試對象的缺陷，被測對象一般是指可運行的代碼、系統，不包括靜態測試發現的問題。
又叫做不符合項問題，是指通過過程審計、過程分析、管理評審、質量評估、質量審核等活動發現的關于過程的缺陷和問題。過程缺陷的發現者一般是測試人員、項目經理等。
根據所提交bug的嚴重性，本規范定義以下五個級別。
A類：嚴重錯誤，包括以下各種錯誤：
（1）由于程序所引起的死機，非法退出。
（2）死循環
（3）數據庫發生死鎖
（4）因錯誤操作導致的程序中斷
（5）功能錯誤
（6）與數據庫連接錯誤
（7）數據通訊錯誤
B類：較嚴重錯誤，包括以下各種錯誤：
（1）程序錯誤
（2）程序接口錯誤
（3）數據庫的表、業務規則、缺省值未加完整性等約束條件
C類：一般性錯誤，包括以下各種錯誤：
（1）操作界面錯誤（包括數據窗口內列名定義、含義是否一致）
（2）打印內容、格式錯誤
（3）簡單的輸入限制未放在前臺進行控制
（4）刪除操作未給出提示
（5）數據庫表中有過多的空字段
D類：較小錯誤，包括以下各種錯誤：
（1）界面不規范
（2）輔助說明描述不清楚
（3）輸入輸出不規范
（4）長操作未給用戶提示
（5）提示窗口文字未采用行業術語
（6）可輸入區域和只讀區域沒有明顯的區分標志
E類：測試建議
根據所提交bug的優先級，本規范定義以下五個級別。
1. Highest ：表示問題必須馬上解決，否則系統根本無法達到預定的需求。
2. High：表示問題的修復很緊要，很急迫，關系到系統的主要功能模塊能否正常。
3. Medium：表示有時間就要馬上解決，否則系統偏離需求較大或預定功能不能正常實現。
4. Low：表示計劃解決，表示問題不影響需求的實現，但是影響其他使用方面，比如頁面調用出錯，調用了錯誤的等。
5. Lowest：即問題在系統發布以前必須確認解決或確認可以不予解決。
功能測試的通過準則一般有：
（1）單元功能同設計需求一致；
（2）規定的路徑覆蓋率及覆蓋類達到要求，且執行正確；
（3）所規定的黑盒測試手段被使用，且執行正確；
（4）對殘留錯誤有合法解釋或被認可暫留；
（5）雖然路徑覆蓋率不能達到，但其他各測試的錯誤查出率趨產0或穩定(時間的長短視情況而定)。
各類軟件測試合格須符合以下標準。
A類錯誤 | B類錯誤 | C類錯誤 | D類錯誤 | E類建議 |
無 | 無 | <1% | <5% | 暫不作要求 |
以上比例為錯誤占總測試模塊的比例。
軟件產品未經測試合格，不允許上線發布。
更多精彩都在洋哥視頻課程學習地址：http://edu.51cto.com/lecturer/5811414.html
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
