軟件
系統測試意味著將軟件系統或者應用程序做為一個整體進行測試。應用程序的系統測試從整體上檢測軟件大致的業務,操作以及最終用戶需求的一致性。系統測試被歸類為
黑盒測試。
這就是為什么內部設計,架構或者代碼對于這種測試來說完全不重要。
當執行一個軟件測試時,專業軟件測試員傾向于區分是接口里面的,還是整個軟件里面的錯誤或者缺陷。然而,當執行軟件或者應用程序的內建(build-in)測試的時候,專業的軟件測試員會傾向于,把已經合并起來的單獨模塊之間的缺陷或者錯誤區分開來。
系統測試過程中,主要的問題是軟件的設計,行為以及客戶的期望。因此軟件的系統測試階段也可以被稱為軟件開發生命周期的審查測試階段。
什么時候系統測試會變得重要起來?
當軟件的所有功能開發完成時,整個軟件系統就應徹底的被測試,保證業務,功能和非功能的要求。系統測試基于單元測試和集成測試標準。絕大多數情況下由一個特別,獨立,并且值得托付的小組來負責系統測試。系統測試在開發用服務器(staging server)上完成。
系統測試的理由
● 系統測試是把軟件或者應用程序首次做為一個整體進行測試
● 執行系統測試是為了檢查和改進技術,業務,功能和非功能的軟件需求,審查和改進軟件程序架構也是這個階段一部分內容。
● 系統測試執行在模擬環境(staging environment)里,與最終軟件安裝所需的環境非常類似。(譯者注:staging environment,即在軟件最終發布前,開發或者設計人員對軟件進行調整后可以及時預覽改變的測試環境,這個環境更接近于產品最終發布后的運行環 境)
系統測試完成的標準:
● 完成單元測
● 完成集成測試
● 軟件系統開發徹底完成
● 模擬產品環境的測試環境準備完成。例如,模擬環境(staging environment:同上注) 存在
系統測試7個階段:
● 開發系統測試設計
http://wenku.baidu.com/view/f4c904da50e2524de5187edd.html
● 開發系統測試用例
http://wenku.baidu.com/view/5cfc4cf80242a8956bece4d6.html
● 選擇或者開發一些用于系統測試的數據
● 必要的話,將系統測試用例自動化
● 執行測試用例
● 修復缺陷和回歸測試
● 如果需要,在不同的測試環境下,再次完成一個測試周期
軟件測試計劃的內容可以在公司與公司,或者項目與項目之間替換使用,這取決于軟件測試的策略,項目計劃的建立以及理解項目測試計劃的程度。軟件系統測試計劃的主要內容包括:
● 范圍
● 目標及目的
● 主要區域/關鍵區域
● 可交付物
● 系統測試計劃
● 進度計劃
● 進入和完成標準
● 軟件測試的延遲和更新標準
● 測試環境
● 可交付標準
● 人員與培訓計劃
● 角色與職責
● 字典
如何創建系統測試用例
系統測試用例的編寫,用跟寫功能測試用例一樣。不過,當編寫系統測試用例的時候,應該考慮2個關鍵點:
1、系統測試用例應該附上用例和場景
2、測試用例必須滿足全部要求,例如,技術上,用戶界面,功能性,非功能性你,性能和其他方面。
在維基百科上,當執行系統測試時,要考慮24中不同的測試類型,他們是:用戶界面測試,可用性測試,性能測試,兼容性測試,錯誤處理測試,大容 量用戶測試,大容量數據測試,壓力測試,用戶幫助測試,安全測試,可擴展性測試,容積測試,健全測試,冒煙測試,探索性測試,隨機測試,回歸測試,可靠性 測試,恢復性測試,安裝測試,效力測試,維護測試,恢復與故障轉移測試,業務功能測試。
系統測試用例計劃:
● 給測試用例一個ID(唯一數字)
● 測試套件(test suit)的命名
● 測試者 – 編寫測試用例的測試者名字
● 功能的簡短描述或者需求環境的ID
● 測試執行時的步驟
● 測試數據-輸入數據
● 預期的結果
● 肯定的結果
● 通過/失敗
● 測試評審
測試類型 | 測試關注點 | 完成情況 | 用戶層 | | | 用戶支持測試 | 用戶手冊、使用幫助、支持客戶的其他產品技術手冊是否正確、是否易于理解、是否人性化。 | | 用戶界面測試 | 測試對象控件或訪問入口正確,符合用戶需求 | | 界面風格統一,界面美觀、直觀 | | 操作友好、人性化 | | 易操作性 | | 可維護性測試 | 系統軟、硬件實施和維護功能的方便性 | | 安全性測試 | 操作安全性 (注:核實只有具備系統和應用程序訪問權限的主角才能訪問系統和應用程序;核實主角只能訪問其所屬用戶類型已被授權使用的那些功能操作) | | 數據安全性 (注:關注數據訪問的安全性,防止交易敏感數據不被第三方截獲、竊取、篡改和偽造。測試內容為:數據加密,安全通訊,安全存儲) | | 網絡安全測試 (注:該層次的測試主要是為了防止黑客的惡意攻擊和破壞,如:病毒,DDOS攻擊等。測試的方式主要是模擬黑客對系統進行入侵攻擊,然后對攻擊的結果進行分析,并逐步完善系統的安全性能) | | 安全認證測試 (注:確保交易雙方不被其他人冒名頂替。測試內容為安全認證) | | 安全交易協議測試 (注:有效避免交易雙方出現互相抵賴的情況) | | 應用層 | | | 性能測試 | 并發性能測試 (注:并發用戶操作下,不斷增加并發用戶數量,分析系統性能指標、資源狀況。主要關注點:交易結果、每分鐘交易數、交易響應時間(最小服務器響應時間、平均服務器響應時間、最大服務器響應時間) | | 壓力測試 (注:不斷對系統施壓,通過確定一個系統的瓶頸或者不能接收的性能點,來獲得系統能提供的最大服務級別的測試) | | 強度測試 (注:系統在極限或異常資源情況下,即系統資源處于特別低的狀況下,軟件系統運行情況確定系統綜合交易指標和資源監控指標,保證系統能否按規格強度下運行) | | 負載測試 (注:關注各種工作負載情況下的性能指標,測試當負載逐漸增加到超負荷狀態時,系統組成部分的相應輸出項,例如通過量、響應時間、CPU負載、內存使用等來決定系統的性能) | | 疲勞測試 (注:采用系統穩定運行情況下能夠支持的最大并發用戶數,持續執行一段時間業務,通過綜合分析交易執行指標和資源監控指標來確定系統處理最大工作量強度性能的過程) | | 大數據量測試 (注:針對某些系統存儲、傳輸、統計、查詢等業務進行大數據量的獨立數據量測試) | | 容量測試 (注:確定系統可處理同時在線的最大用戶數) | | 破壞性測試 (注:超出系統能承受的壓力點后,系統出現錯誤狀態、出現錯誤比率及恢復能力;對軟件進行異常的操作,如:刪除配置文件) | | 系統可靠性、穩定性測試 | 可靠性測試 (注:主要測試系統在負載壓力下系統運行是否正常) | | 穩定性測試 (注:確保系統在長期使用周期內能夠在要求的性能指標下正常工作) | | 系統兼容性測試 | 操作系統兼容性 (注:win 9x / win2k / winXP / Unix / Linux ... ...) | | 瀏覽器兼容性 (注:IE4 / IE5 / IE6 / Firefox / My IE / TT ... ...) | | 其他支持軟件/平臺/文件/數據/接口的兼容性 | | 系統組網測試 | | | 系統安裝升級測試 | 初次安裝 | | 更新(注:以前安裝過相同版本) | | 升級(注:以前安裝過較早版本) | | 功能層 | | | 功能性測試 | 初驗測試 (注:系統核心功能、基本業務流程的驗證) | | 業務場景測試 (注:模擬用戶實際操作的業務場景,遍歷主要業務流程和業務規則) | | 業務功能的覆蓋 (注:關注需求規格定義的所有功能系統是否都已實現) | | 業務功能的分解 (注:將每個功能分解成測試項。關注每個測試項的測試類型都被測試通過) | | 業務功能的組合 (注:相關聯的功能項的組合功能的都被正確實現) | | 業務功能的沖突 (注:業務功能間存在的功能沖突情況,均測試通過。例如:共享資源訪問等) | | 異常處理及容錯性 (輸入異常數據、或執行異常操作后,系統容錯性及錯誤處理機制的健壯性。例如:重復點擊“提交”按鈕,提交申請單) | | 子系統層 | | | | 單個子系統的性能 (注:應用層關注的是整個系統各種軟、硬件、接口配合情況下的整體性能,這里關注單個系統。) | | | 子系統間的接口瓶頸 (例如:子系統間通訊請求包的并發瓶頸) | | | 子系統間的相互影響 (注:子系統的工作狀態變化對其他子系統的影響) | | 協議/指標層 | | | | 協議一致性測試 | | | 協議互通測試 | | 其他測試類型 | | | BVT | 構建驗證測試 | | Ad hoc Test | 隨機測試 | | Exploratory Test | 探索性測試c | | 回歸測試 | | | |
|
|
|