驗收測試

  • 驗收測試(Acceptance Test):在軟件產品完成了功能測試和系統測試之後、產品發佈之前所進行的軟件測試活動。它是技術測試的最後一個階段,也稱爲交付測試。
  • 驗收測試的目的:確保軟件準備就緒,並且可以讓最終用戶將其用於執行軟件的既定功能和任務。
  • 驗收測試的參與者:用戶,還可能有軟測工程師等。

1 、驗收測試的過程和主要內容

前提:     系統或軟件產品已通過了系統測試的軟件系統。

測試內容:     驗證系統是否達到了用戶需求規格說明書(可能包括項目或產品驗收準則)中的要求,測試試圖儘可能地發現軟件中存留的缺陷,從而爲軟件進一步改善提供幫助,並保證系統或軟件產品最終被用戶接受。主要包括易用性測試、兼容性測試、安裝測試、文檔(如用戶手冊、操作手冊等)測試等幾個方面的內容。

任務:     驗證軟件的功能和性能符合用戶期待。

測試步驟:

  1. 制定測試計劃,測試項,測試策略及驗收通過準則,並經過客戶參與的計劃評審。
  2. 建立測試環境,設計測試用例,並經過評審。
  3. 準備測試數據,執行測試用例,記錄測試結果。
  4. 分析測試結果,根據驗收通過準則分析測試結果,作出驗收是否通過及測試評價。 測試項目通過; 測試項目沒有通過,並且不存在變通方法,需要很大的修改; 測試項目沒有通過,但存在變通方法,在維護後期或下一個版本改進; 測試項目無法評估或者無法給出完整的評估。此時必須給出原因。如果是因爲該測試項目沒有說明清楚,應該修改測試計劃。
  5. 提交測試報告。

驗收標準和注意事項:

  • 驗收測試完成標準: 完全執行了驗收測試計劃中的每個測試用例。
  • 在驗收測試中發現的錯誤已經得到修改並且通過了測試或者經過評估留待下一版本中修改。
  • 完成軟件驗收測試報告。

注意事項:

  • 必須編寫正式的、單獨的驗收測試報告
  • 驗收測試必須在實際用戶運行環境中進行 由用戶和測試部門共同執行。
  • 如公司自開發產品,應由測試人員,產品設計部門,市場部門等共同進行。

α測試和β測試

  • α測試是指軟件開發公司組織內部人員模擬各類用戶對即將面市軟件產品(稱爲α版本)進行測試,試圖發現錯誤並修正。α測試的關鍵在於儘可能逼真地模擬實際運行環境和用戶對軟件產品的操作並盡最大努力涵蓋所有可能的用戶操作方式。
  • 經過α測試調整的軟件產品稱爲β版本。β測試是指軟件開發公司組織各方面的典型用戶在日常工作中實際使用β版本,並要求用戶報告異常情況、提出批評意見

2 、產品規格說明書的驗證

產品規格說明書(Specification)

  • 基於用戶需求的定義,詳細描述將要開發出一個什麼樣的產品,包括產品的用途、有哪些功能、用戶界面的表現形式及其交互特性等。
  • 遵守公司內部約定的模板或其他要求。
  • 採用Word、PDF、Visio或HTML等文檔格式,包括文字、表格、圖形甚至動畫等內容。

產品規格說明書決定了最終需要開發出的產品,對產品規格說明書的充分評審,可以排除約60%的錯誤,爲項目節約大量成本。

評審方法包括

  • 同行評審(Peer-to-peer Review)
  • 走查(Walkthrough)
  • 正式會議審查(Inspection)

  • 屬於功能性測試範疇
  • 測試人員不僅要根據產品說明書的每一個特性導出測試用例,而且針對上述的變動,及時更新測試用例,確保產品規格說明書和測試用例保持一致
  • 提交基於產品規格說明書的驗收報告

      可以正式的,也可以非正式的

      包括所有特徵的清單:

  •             已經實現的特性標識爲通過。
  •             特性沒有實現的,報告缺陷並在報告中體現。
  •             特性基本實現,但與產品說明書中內容不相一致。
  •             報告缺陷並在報告中體現。 特性基本實現,但存在一些問題或錯誤。

3、 用戶界面和可用性測試

用戶界面的7個要素:  符合標準和規範。  直觀性。  一致性。  靈活性。  舒適性。  正確性。  實用性。

易用性測試沒有具體量化的指標,主觀性較強。

3.1 符合標準和規範:

  • 何時使用複選框,何時使用單選按鈕
  • 何時使用提示信息、警告信息或者嚴重警告信息等

3.2  直觀性

  • 首先確定功能操作界面、提示或期待的結果是否直觀、顯著,並是否在預期的地方或時間出現
  • 其次,考慮用戶界面的組織和佈局是否合理,界面是否整潔、不擁擠、以及是否有多餘的功能,是否複雜難以掌握

3.3  一致性

  • 軟件本身的一致性
  • 與公司其他軟件、第三方軟件的一致性
  • 字體是否一致
  • 界面的各元素風格是否一致
  • 平臺的標準和規範是否一致

3.4  靈活性

用戶喜歡可以靈活選擇的軟件,軟件可以選擇不同的狀態和方式,完成相應的功能。

  • 但靈活性也可能發展爲複雜性,太多的狀態和方式的選擇增加的不僅僅是用戶理解和掌握的困難程度。
  • 多種狀態之間的轉換,增加了編程的難度,更增加了軟件測試人員的工作量。

3.5   舒適性

恰當的表現、合理的安排、必要的提示或更正能力等是要考慮的因素,包括容錯處理和性能。

例如蘋果公司推出的一系列產品。

3.6  正確性

  • 正確性的問題一般都很明顯,比較容易發現。
  • 是否有多餘或遺漏的功能
  • 功能是否被正確實現
  • 語言拼寫是否無誤
  • 在不同媒介上的表現是否一致
  • 所有界面元素的狀態是否都準確無誤

3. 7 實用性

  • 指軟件產品的各個功能是否實用 (無用的功能會增加程序的複雜度,產生不必要的缺陷)。
  • 軟件開發和維護過程中,隨着軟件演化會產生一些沒有實用價值的功能。
  • 沒有一個具體量化的指標,主觀性較強。

3.8  簡單性

4 、兼容性測試

兼容性包括:  硬件兼容、 軟件之間兼容、 數據之間兼容。

4.1  軟件兼容性

軟件兼容性測試是指驗證軟件之間是否能夠正確的交互和共享信息,包括同步共享、異步共享,還包括本地交互、遠程通信交互。

1、向前和向後兼容

  • 向後兼容是指可以使用以前版本的軟件
  • 向前兼容是指可以使用未來版本的軟件
  • 向後兼容是必要的
  • 向前兼容雖然並不是必須的,但是需要努力做到 

4.2  多版本的測試

  • 驗證操作系統新版本是否兼容數百萬個應用程序
  • 需要採取有效的測試策略,例如對所有可能的組合進行等價劃分、優化,獲得最少的有效測試集合。通常做法包括:

                將軟件分類,如字處理、電子表格、數據庫、圖形處理和遊戲等,從每種類型中選擇部分測試軟件

                按照軟件的流行程度選擇較流行的軟件

                按照軟件發佈的時間,選擇最近年份內的程序和版本

例: 設計測試矩陣表

每一個瀏覽器和版本支持的特性上都有細微的差別,在不同的操作系統上表現也有所不同。

針對一個網站的兼容性測試:

數據共享兼容性測試表現的方面

  • 剪切、複製和粘貼
  • 文件的存取 (文件的數據格式必須符合標準,能被其他應用軟件讀取)
  • 文件的導入和導出

4.3  硬件兼容性測試

配置測試的必要性( 計算機配置的複雜多樣性)

配置測試的基本方法

  • 配置測試的主要任務是發現硬件配置缺陷
  • 判斷一個缺陷是否是配置缺陷,常用方法是在另一臺不同配置的計算機上執行相同操作,如果缺陷沒有出現,就可以是配置缺陷
  • 存在組合爆炸問題,可以考慮採用等價類劃分、組合測試等技術進行劃分和優化

4.4  可安裝性和可恢復性測試

軟件測試中容易忽略的一個環節

可安裝性測試:   系統軟件安裝、應用軟件安裝、服務器的安裝、客戶端的安裝、產品升級安裝等

安裝與卸載測試

  • 軟件安裝方式多樣化:有客戶端軟件安裝、有通過瀏覽器下載安裝、服務器端的系統部署、雲服務平臺等
  • 客戶端安裝測試時: 驗證能否正確安裝成功、安裝步驟是否清晰、中途是否退出、安裝完之後能否順利卸載、卸載時是否破壞用戶數據、是否能夠正常升級等

安裝測試需要注意的事項

  • 嚴格按照安裝文檔的說明,一步一步進行操作
  • 軟件的安裝說明書是否對安裝環境做限制和要求
  • 安裝過程是否簡單、容易掌握
  • 安裝過程是否有明顯的、合理的提示信息
  • 卸載測試也是安裝測試的一部分
  • 安裝過程中是否會出現不可預見的或不可修復的錯誤
  • 安裝過程是否佔用太多系統資源
  • 軟件安裝的完整性和靈活性
  • 軟件使用的註冊號碼驗證

可恢復性測試

  • 恢復測試主要檢查系統的容錯能力。當系統出錯時,能否在指定時間間隔內修正錯誤或重新啓動系統。  
  • 運行過程中出現的錯誤對局部有影響,但不能造成整個系統的崩潰。  
  • 在某些情況下,一旦某個子系統出現問題,有一個備份子系統將服務接替過來,從而不會影響這個系統
  • 恢復測試首先要通過各種手段,讓軟件強制性地發生故障,然後驗證系統是否能儘快恢復。

                  對於自動恢復需驗證重新初始化、檢查點、數據恢復和重新啓動等機制的正確性;  

                  對於人工干預的恢復系統,還需估測平均修復時間,確定其是否在可接受的範圍內。

6、文檔測試

軟件文檔已成爲軟件的一個重要組成部分,而且種類繁多,對文檔的測試也變得必不可少。

  • 文檔是軟件重要組成部分,所以文檔的錯誤也是缺陷
  • 文檔的重要性

               用戶通過文檔可以掌握具體的使用方法,提高易用性

               用戶使用軟件時遇到問題,通過幫助文檔可以有效解決問題,減少企業技術支持費用

文檔的種類

  • 聯機幫助文檔或用戶手冊;
  • 指南和嚮導; 安裝、設置指南;
  • 示例及模板;
  • 錯誤提示信息;
  • 用於演示的圖像和聲音;
  • 授權/註冊登記表及用戶許可協議;
  • 軟件的包裝、廣告宣傳材料。

怎樣進行文檔測試

好的文檔能達到提高易用性、提高可靠性、降低技術支持的費用的目的,從而提高了產品的整體質量。

軟件驅動的文檔還得像程序一樣運行起來測試。

主要檢查文檔的

  • 正確性:不要把軟件的功能和操作寫錯,也不允許文檔內容前後矛盾
  • 完備性:不能漏掉關鍵內容
  • 易理解性:文檔不能含糊,要清晰,要讓大衆用戶看得懂,容易理解
  • 一致性:例如檢查產品功能描述是否自相矛盾,與其他功能有沒有衝突

eg:人工測試實訓案例

  • 以手機信息管理系統爲例,進行人工系統測試實訓的操作,如下僅進行安裝測試、界面測試及易用性測試、修改用戶名和密碼模塊的測試。
  • 對於手機信息管理系統來說,修改用戶名和密碼以及成功登錄系統是整個信息管理系統的一個側重點,這涉及到用戶權限的變更和系統的安全性等問題。

1.安裝測試

 

2.界面測試

(1)美觀性與協調性 

(2)窗體測試 

(3)獨特性測試 

3.易用性測試 

4修改用戶名和密碼模塊的測試

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章