一、可用性測試
1、表現形式
①.產品的基本自然屬性，使用者體驗的一種衡量程度
②.依照原型圖對gui的評估
③.體現在產品和使用者的互動友好性
④.評價指標：效率、滿意、安全（容錯、無錯）
2、測試方法
①.對同一測試內容同時採取多指標測試
②.對同一測試內容在不同時間採用多指標測試
3、目的
①.確認使用者介面設計在概念和詳細設計2個不同層面的問題
②.概念層面和導航：使用者定位和ui一致性
③.詳細設計介面：遵循gui設計介面標準，使用的術語等
二、壓力測試
定義：對系統不斷施加壓力，通過確認乙個系統瓶頸或不能接受的效能點，獲得系統能提供最大級別服務的測試
1、什麼是壓力測試
即強度測試，模擬巨大工作負荷來測試應用程式在峰值情況下的服務處理能力
2、表現形式
①.短時間的極端負荷測試
②.高併發下的負載測試
③.持續一段時間的操作執行能力測試
3、特點
①.增加訪問量，使應用系統資源使用保持在一定水平，檢驗應用的表現（重點：有誤錯誤資訊產生，系統的響應時間等）
②.通過壓力測試使系統資源使用率達到較高水平（一般情況：cpu使用率佔比75％，記憶體使用率佔比70％）
4、壓力測試與負載測試區別
壓力測試：超常規負荷條件下，長時間連續執行系統，檢驗應用程式的各種效能表現
負載測試：應用程式在常規負荷下，確認響應時間和其他效能的表現
5、壓力測試的目標
①.檢查最終響應時間（完成乙個業務流程所需要的時間）
②.可靠性（功能和效能是否有錯誤？大資料量下系統執行是否有錯誤？）
③.硬體和軟體的可靠性
④.硬體配置是否合理
⑤.系統容量（沒有顯著效能下降情況下，系統能處理的最大負荷）
三、確認測試
定義：有效性測試；在模擬環境下，用黑盒測試方法，驗證被測軟體是否滿足需求
1、目的
向使用者表明系統能像預定的要求那樣工作
2、內容
主要包括功能和效能兩部分
四、容錯性測試
定義：一種對抗性的測試過程；指軟體執行出現故障，如何進行故障轉移和恢復當前系統的實時資料
1、概念
檢查軟體在異常條件下自身是否具有防護性的措施或某種災難性恢復的手段
當系統出現重大錯誤時，能否在指定時間間隔內修正錯誤並重啟系統
當系統出現非關鍵錯誤時能否保證系統繼續執行
2、內容
包括2個方面：
異常測試：輸入異常資料或進行異常操作，驗證系統的保護性；
災難恢復性測試：通過各種手段，讓軟體強制發生故障，然後驗證系統已儲存的使用者資料是否丟失，系統和資料是否能盡快恢復
3、注意事項
故障發生時資料的轉移和恢復
故障表現：
①.伺服器斷電
②.網路裝置斷電
③.資料庫系統發生故障
④.應用系統檔案發生故障
⑤.系統軟體發生故障
五、易用性測試
1、易用性測試定義
①.是互動的適應性、功能性和有效性的集中體現
②.分2個層次：使用者介面易用性和作業系統易用性
③.易用性測試包括：針對應用程式的測試、對使用者手冊系統文件的測試（通常採用質量外部模型來評價易用性）
2、內容
①.使用者介面測試
②.作業系統有內建支援
六、安全性測試
1、定義
驗證應用程式的安全級別和識別潛在安全性缺陷的過程；一般在單元測試、整合測試階段進行，以便在破壞之前預防並識別軟體安全問題
2、表現
表現在2個方面
①.應用程式的安全性
②.作業系統的安全性
七、需求分析測試
定義：需求分析是說明軟體應有的功能和效能，使分析人員能夠清晰的了解使用者需求能否實現
1、內容
①.功能需求的分析
②.介面需求的分析
③.效能需求的分析
④.分析約束條件
2、需求分析的關鍵點
①.功能能否滿足使用者需求
②.效能能否滿足使用者需求
③.需求說明書所討論的內容是否得到使用者認可
八、可靠性測試
定義：為了保證和驗收軟體的可靠性而進行的測試
1、概述
①.有效的發現程式中影響軟體可靠性的缺陷，從而實現可靠性增長
②.驗證軟體可靠性滿足一定的要求
③.估計、預計軟體可靠性水平
2、注意事項
①.功能識別
②.可靠性對時間的要求
③.可靠性對環境條件的要求
3、測試流程
①.測試資料收集和準備
②.測試環境的準備
③.測試執行
④.可靠性測試資料分析
九、風險測試
定義：風險指的是軟體開發過程中遇到的預算、進度、開發遇到的問題等引起的損失的可能性
1、表現形式
①.模組設計：所有模組開發沒有統一設計，開發人員獨立的設計測試模組
②.需求變更開發：需求變更沒有及時告知測試人員所造成的的風險
③.人力資源：測試人員沒有及時到位或者人員流失
④.硬體資源：各種硬體資源對測試工作的影響
2、解決策略
①.增加資源
②.縮小範圍
③.制定標準文件
3、測試步驟
①.風險分析
②.風險評估
③.執行風險
④.風險總結
十、缺陷測試
定義：對開發的軟體是否存在缺陷進行的測試
1、問題表現
①.軟體是否達到產品說明書表明的功能
②.是否出現了產品說明書中不一致的表現
③.是否超出了產品說明書的範圍
④.能否達到使用者期望的目標
⑤.軟體的易用性
2、注意事項
①.由於客觀因素（市場壓力、運營狀況等）造成的產品上線時間限制
②.因測試人員不正當操作或理解錯誤導致的缺陷
③.錯誤的修改影響的模組較多，帶來的風險較大
④.很難被重現的缺陷
⑤.修改很耗時或對產品使用影響很小的，修改價效比很低的缺陷
3、缺陷分級
①.致命（軟體產品不能啟動、執行使用）
②.崩潰（產品重要模組不能正常使用，驗證影響了系統要求或基本功能實現）
③.嚴重（產品功能模組不能正常使用，影響其他相關模組功能實現等）
④.一般（暫時不影響基本功能模組正常使用等）
⑤.優化（介面不美觀，文字爆框超出，但不影響使用）
十一、介面測試
定義：為了驗證軟體對外的介面服務可以正常提供服務及軟體在不同場景中執行路徑的安全可操作性
1、介面測試的目的
①.模組介面的測試
②.系統介面的測試
2、主要內容
①.介面邏輯測試
②.模組介面測試
3、關鍵點
①.資料型別問題
②.變數值問題
③.邏輯判斷問題
④.檔案i/o問題
常見軟體測試
軟體測試 英語 software testing 描述一種用來促進鑑定軟體的正確性 完整性 安全性和質量的過程。換句話說，軟體測試是一種實際輸出與預期輸出之間的審核或者比較過程。1 單元測試 單元測試即為將整個軟體分解為各個功能，隨後對單元進行測試。此類測試策略的優點在於所需分析資料較少，且針對性較...
常見測試型別
測試型別 單元測試，sit和uat sit是整合測試 uat是驗收測試 從時間上看，uat要在sit後面，uat測試要在系統測試完成後才開始。sit system integration testing 系統整合測試，也叫做整合測試，是軟體測試的乙個術語，在其中單獨的軟體模組被合併和作為乙個組測試。...
軟體測試的型別
1 正常測試 測試某個功能是否滿足需求的定義，功能是否正確，完備。2 邊界測試 對某個功能的邊界情況進行測試。3 異常測試 對某些功能來說，其邊界情況無法簡單的了解或某些操作不完全是正確的但又是可能發生的，類似這樣的情況需要書寫相關的異常測試 4 效能測試 檢查系統是否滿足在需求中所規定達到的效能，...