軟件驗收測試

軟件項目測試驗收流程V3

軟件項目測試驗收流程

一、Bug分類的界定:

(一)bug嚴重程度分類:

緊急---重大功能bug、block核心功能的bug, 嚴重性能問題,內存泄露;阻礙開發或測試工作的問題;

嚴重---導致程序模塊未實現;用戶需求未實現;

一般---發現影響被測功能正確實現的問題,或一般性錯誤或者功能實現不完善等; 次要---一些建議性和界面的問題。

(二)嚴重程度具體分類:

1、jira「緊急」

(1)系統崩潰

(2)導致程序重啟,死機或非法退出

(3)死循環

(4)數據丟失或異常

(5)安全問題

(6)響應時間過長

2、jira「嚴重」

(1)功能不符合用戶需求

(2)因錯誤操作迫使程序中斷

(3)功能實現不完整,如刪除時沒有考慮數據關聯

(4)程序接口錯誤

(5)業務流程、審批流轉錯誤

(6)數據計算錯誤

3、jira「一般」

(1)存在與系統無關的logo或文字標題

(2)內容或格式錯誤

(3)提示信息不準確

(4)兼容性問題

(5)功能性建議

(6)光標定位、鼠標變小手等

(7)回車鍵無法進入、Tab鍵無法切輸入框等

(8)必填項和非必填項需加以區別

4、jira「次要」

(1)輔助說明描述不清楚

(2)界面字段、按鈕、提示語的文字未采用行業術語

(3)可輸入區域和只讀區域沒有明顯的區分標志

(4)其他建議性問題

二、驗收流程:

(一)驗收流程圖:

驗收時,一旦發現0類bug和1類bug就立馬打回,由此造成項目延期由外包方負責。 從此階段開始算起,截止到產品正式發布后三個月內,在這期間被樂視方發現的bug

數總和就算漏測bug數,咱們命名Z=漏測數/總的bug數,如果Z<5%,需賠付甲方__%的賠償金。如果5%

驗收中每個階段都需完成才能進入下一階段,否則都是驗收失敗,由PM提交給外包方修改后重新啟動驗收:

(二)啟動驗收

外包方提交正式驗收版本時,需要給出完整的驗收標準報告,驗收報告各項指標全部達標(100%按照驗收標準,如有不符合,須經PM同意)才預示可以進入驗收階段,否則將直接打回,通知PM和相關人員。外包方再次提交驗收報告經檢查無誤后再介入。

1、冒煙驗收

類似于smoke test,PM對站點或者app進行30分鐘~1小時的功能確認,工作重點在核心功能、邏輯和異常情況。驗收流程如下:

(1)進行30分鐘~1小時的功能確認,如通過則進入5,否則進入2

(2)驗收失敗,打回給外包方修改,通報給相關郵件組,暫停驗收,要求外包方給出自測list和修復時間,由此帶來的項目延期由外包方承擔,如有必要,我方可提供自測list。

(3)外包方修改后再次提交版本,需要提供自測報告,標注bug產生的原因、修復方法以及修復帶來的功能影響;

(4)再次冒煙驗收,如通過進入5,否則進入2

(5)正式驗收

2、正式驗收

驗收主要進行如下幾方面:

● PM執行功能驗收中“正常功能確認”部分

● QA執行:

(1)功能性驗收測試

(2)兼容性驗收測試

(3)穩定性驗收測試

(4)性能驗收測試

(5)安全性驗收測試

(6)本地化驗收測試

3、驗收通過

驗收通過后,QA通知PM和外包方,然后由PM發起上線流程。產品的質量由QA提供驗收結果,PM決策用戶影響,最終確定是否可以上線。

4、驗收失敗打回

驗收過程中任一環節失敗,都進入驗收失敗打回階段。為了控制項目周期和再次提交的版本質量,針對驗收失敗以及提交新版本做了如下規范:

5、項目驗收分級

全新項目或者2.0大版本更新: 進行全流程測試

詳見「準入質量標準V5 -外包驗收(新項目).xlsx」

新功能或者優化的,主要模塊無更改: 只進行變更部分的功能、UI、用戶體驗的

測試

詳見「準入質量標準V5 - 外包驗收(功能優化或新增).xlsx」

BUG修復: 只做BUG的驗證和回歸測試

軟件測試驗收報告

軟件測試、驗收報告

1引言

1.1目的

說明編制本測試驗收報告的主要目的。

1.2背景

列出本項目的委托單位、承辦單位及其主管部門。

1.3參考資料

a)本項目經核準的計劃任務書、合同或上級機關批文;

b)項目開發計劃;

c)分析設計說明書;

d)本文檔中引用的文件、資料(包括軟件開發規范)。

列出這些資料的作者、標題、編號、發表日期和出版單位。

1.4定義

列出本文檔中用到的可能會引起混淆的專門術語的定義、縮寫詞的原文。

2軟件測試

2.1動態、靜態數據特性

把本項測試中得到的動態、靜態的輸入/輸出數據的結果同動態/靜態的輸入/輸出的期望結果進行比較,列出發現的問題。

2 .2軟件功能結論及建議

簡述被測試軟件的功能,說明為滿足此功能而設計的軟件所具有的能力及經過測試已證實的能力;經過測試證實的本軟件存在的缺陷和限制,指出對缺陷如何進行改進。

3評價

3 .1軟件的主要功能和性能

說明本軟件具有的各項功能及性能,說明原定的開發目標是否達到。

3 .2進度與費用

給出原定計劃的進度與實際進度的對比;原定計劃的費用與實際支出費用的對比。

3 .3對開發工作的評價

對開發工作的生產效率、技術方法、產品質量等給出評價。

4經驗與教訓

列出從本項目的開發中得到的最主要的經驗與教訓,以及對今后的軟件項目開發工作的建議。

軟件項目驗收測試研究

摘要摘要:驗收測試的重點就是客戶。在一個軟件項目中,通常多個客戶有著不同的觀點,這在測試中必須予以考慮。使用驗收測試,其目的不僅是確保系統正常工作,而且是確保該應用程序能夠滿足客戶的需求。探討實現驗收測試的方法,以及可以在驗收測試中引入的各種技術。

  關鍵詞:軟件測試;驗收測試;自動化測試

  中圖分類號:TP306文獻標識碼:A文章編號文章編號:16727800(2013)0010003602

  作者簡介:董寧(1982-),男,碩士,武漢軟件工程職業學院講師,研究方向為軟件技術和職業教育。

  0引言

  良好的軟件測試方法可以確保軟件項目正確運作,然而,除了軟件之外,還有一個重要的卻往往被忽視的角色——客戶。在軟件項目開發的每個階段考慮客戶需求是系統獲得成功非常重要的一點。

  1軟件項目驗收測試概述

  驗收測試一直以來被用于不同的技術和方法中,有時指的是同一個概念,有時也可能指不同的測試形式。所以必須給本文探討的驗收測試相關概念一個明確的定義:①驗收測試:包括客戶驗收測試、用戶驗收測試和功能測試;②可執行規范:即驗收測試規范,可運行測試來驗證項目實現是否與所定義的規范相匹配;③客戶:系統的最終用戶;④系統:所開發的軟件項目;⑤驗收:滿足功能和非功能需求;⑥功能需求:該系統必須執行的功能和動作,如顯示條目、用戶身份驗證等;⑦非功能需求:系統的相關因素,如性能、可擴展性和安全性;⑧黑盒:不依賴于系統內部細節的測試過程,如輸入數據、檢測輸出結果。

  這些術語并不足以對如何將驗收測試應用于軟件項目開發生命周期進行一個準確的描述。驗收測試并不是新概念,但它像測試驅動開發TDD(Test Driven Development)一樣,近幾年來才得到關注和廣泛使用,并出現了一些相關的測試工具和架構。接下來看一下驗收測試是如何應用于軟件開發生命周期的。

  驗收測試往往被用于由極限編程、敏捷原則和Scrum迭代模型指導開發的軟件項目中。出現這樣的情況主要有兩個原因。一是驗收測試側重于客戶和軟件所實現的功能向客戶提供的價值,這與敏捷開發原則相一致,后者也是側重于交付實際滿足客戶需求的軟件。二是通過一套自動化驗收測試,就可以確保該軟件能夠滿足客戶需求、確保在實現新功能的時候沒有破壞任何舊功能。這意味著,可以將重點放在確保正在開發的功能是否與期望的相一致上面。

  驗收測試與敏捷開發過程結合是最有效的。在每一個迭代過程中,驗收測試將保證整個團隊集中于應用程序的具體部分,確保在單個迭代中軟件從設計到測試都是完整的。

  2軟件項目驗收測試方法

  驗收測試的編寫和實現應該貫穿在軟件項目開發的每個迭代過程中。下面將基于Scrum迭代模型,實現一個包含驗收測試的軟件項目迭代過程。

  在一個標準的Scrum迭代過程開始的時候,開發團隊接受了具有最高優先級的待完成的產品需求列表,該產品需求應當分解為多個用戶使用情景,每個用戶使用情景定義一個系統需求。一個用戶使用情景通常由兩部分組成,用來描述用戶需要的系統部分。如一個典型的用戶使用情景可以被描述為“作為一名銷售管理員,我想要能夠查看信用卡信息,從而能夠在本地處理付款。”這個用戶使用情景描述了操作和與操作相關的用戶,對要求實現的內容給出清晰的說明。

  一旦選定一個用戶使用情景后,開發團隊就應當對他們要實現的內容有一個很好的認識,這一階段應該與客戶和產品所有者進行交談,確定實際需要什么并擴展初始用戶使用情景,并基于這一信息和團隊內部的其他技術人員討論來創建任務,在這一階段,就應當編寫驗收測試了。了解試圖實現的用戶使用情景,就可以清楚地認識到完成這些實現所需的任務,也能夠知道如何驗證這一應用程序是否滿足客戶需求。驗收測試并不是低層次的單元測試,而是側重于驗證基于用戶使用情景的客戶需求是否正確實現的高層次測試。確定了用戶使用情景后,在將其分解為任務之前,定義驗收測試是非常必要的。當所有的驗收測試都通過的時候,就完成了系統。這使得任務分解更加側重于需要完成的事。在這一階段,客戶和產品所有者應當協助開發團隊定義驗收測試,確保軟件需求滿足客戶的期望。

  良好驗收測試可以讓客戶在開始編碼之前清楚地知道當前階段軟件項目將實現的功能。客戶清楚地定義了需求,開發團隊可以在實際編碼前,提出任何與需求相關的問題并與客戶敲定細節。使用驗收測試指導和驗證,可以使客戶清楚地知道他們想要什么,也可以使軟件項目開發團隊清楚地知道他們計劃交付什么。

  但是,客戶往往不懂技術,無法理解任何為驗證需求所開發的測試代碼。因此,驗收測試在編寫時,不要向客戶展示代碼,而是使用語言描述驗證測試,也就是以幾句話定義高層次觀點。驗收測試有多種編寫形式,如Given、When、Then的語法就是一種現在較為流行的驗收測試編寫語法,具體測試用例編寫如下所示:

  假定有一個新用戶賬號(Given)

  當其在系統中創建時(When)

  那么默認密碼應當是P@ssw0rd(Then)

  在測試解決具體問題的時候,根據需要,測試表述可以更為復雜:

  假定有一個超支賬戶(Given)和一個有效的借記卡

  當客戶從ATM機上取現金時(When)

  那么顯示一條錯誤信息(Then),沒有現金返回,將卡退回給該客戶

  這種形式的測試將促使客戶與開發團隊更好地交流并定義驗證測試,驗證和敲定各個細節。這種測試定義形式并沒有過多地使用專業術語,如果測試用例以這種方式定義,客戶將對測試更加熱心。因為客戶在項目開始的時候就表明希望交付軟件的實現什么功能,并且在軟件交付后能看到參與編寫的所有測試都能有效通過。

  驗收測試應當將注意力放在業務問題和場景上,使用與業務相同的語言來描述測試。其優勢在于;第一,不需要技術背景就能夠理解場景和預期結果;第二,如果軟件底層發生變更,不需要退回并更新這些測試來反映這一變更。因為驗收測試是高層次的,可能涵蓋了代碼庫中的許多不同組建。驗收測試不應該依賴于具體的細節,因為隨時間的推移,這些細節會發生變更。如果由于丟棄或以某種方式進行變更而使用戶使用情景不再有效,應該更新測試來反映這一點。

  閑置的驗收測試和不再使用的測試對于項目和測試套件來說是有害的。測試套件應當盡可能地精簡和集中,擁有足夠的測試來提供較高層次的保障,但不應冗余和重復。

  執行驗收測試可以手動或自動。盡管手動測試看起來是更快的選擇,但從長久看來更加耗時,因為每次修改系統某個部分,都需要重新運行。隨著系統的增長,手動測試將變得更加耗時,并導致更多錯誤,可見手動執行這些測試并不像想象的那么簡單。除了手動完成驗收測試,也可以利用工具自動完成。

  3自動化驗收測試工具

  目前,最流行的自動化驗收測試工具是FitNesses。該工具是基于Fit(Framework for Integrated)的。FitNesses提供了一個Wiki前端,可用來管理測試用例和腳本,使得整個團隊和客戶能夠合作創建驗收測試用例。除了Wiki前端之外,FitNesses還提供了一個基礎代碼庫用于處理Wiki和測試系統之間的通信。這提供了一個與系統進行交互的抽象試圖,能夠更方便地編寫驗證測試。

  除了FitNesses,也可以使用Cucumber來實現自動化驗收測試。Cucumber 是一個能夠理解用普通語言描述的測試用例的支持行為驅動開發(BDD)的自動化測試工具,用Ruby編寫,支持Java和.Net等多種開發語言。

  4結語

  相比單元測試,驗收測試最大的優勢是更容易應用于遺留代碼。遵循驗收測試方法,可以立即圍繞項目添加客戶驗收測試,并提供一定層次的自動化測試,不必對項目和測試方法進行大規模重構。驗收測試實際上為遺留代碼提供了增值收益,通過一套堅實的客戶驗收測試,就可以在后臺重構代碼,并添加單元測試,驗收測試將提供額外的安全網,確保在重構階段沒有造成破壞。驗收測試提供了一個良好的端對端安全網。

  軟件項目驗收測試非常重要和有價值,它可以確保軟件系統滿足客戶實際需求。

  參考文獻:

  [1]李志剛.第三方軟件系統驗收測試實踐[J].信息技術,2010 (1).

  [2]郝建營,晏海華,劉超,等.一種有效的Web性能測試方法及其應用[J].計算機應用研究,2007(7).

  責任編輯(責任編輯:張悅)

軟件驗收測試標準

軟件質量與測試效果評估標準

1編寫目的

本文檔是對獨立測試效果及軟件質量從缺陷方面進行考核的依據,該標準僅作為整體考核標準中的一個組成部分即:缺陷考核部分。

2適用范圍

本標準適用于軟件質量與軟件測試質量的考核。

3 評價基準

軟件質量考核基準: 以最后測試組遞交的測試總結報告中所提交的有效缺陷為考核指標。 測試質量考核基準: 以軟件試運行階段用戶發現的有效缺陷和非測試人員發現的有效缺陷為

考核指標。

有效缺陷: 經過評審確定為影響軟件質量或發布的缺陷(包括:確定修改、暫緩修改的)建

議性的E類缺陷不算有效缺陷。

4 驗收測試進入準則

1) 軟件產品通過單元測試、集成測試和系統測試。

2) 測試組提交以下測試工件:測試計劃、測試任務書、測試用例、測試報告、測試分析總結。

5軟件驗收測試工作程序

測試完成后按項目管理規定,成立測試(項目)驗收小組,啟動測試驗收總結會 5.1根據測試任務書進行測試質量前期評審。 5.2根據測試總結報告進行軟件質量評審。(測試角度)

6 軟件驗收測試合格通過準則

1 軟件需求分析說明書中定義的所有功能已全部實現,性能指標全部達到要求 2 所有測試項沒有殘余一級、二級錯誤

3 立項審批表、需求分析文檔、設計文檔和編碼實現一致 4 驗收測試工件齊全(見驗收測試進入準則)

1)以上比例為錯誤占總測試模塊(不包括E類)的比例。 2)軟件產品未經測試合格,不允許投運。

6 測試質量合格須符合以下標準

1)以上為用戶或非測試人員發現的有效缺陷,且改缺陷不是由需求、功能的變更引起的且在測試任務書規定的測試內容范圍內的缺陷。

2) A類錯誤、B類錯誤為獨立條件,C類錯誤、D類錯誤為組合條件 3)用戶或非測試人員發現的有效缺陷的總數不得大于一定的比例:(10%)

用戶或非測試人員發現的有效缺陷的總數/測試總結報告提交有效缺陷總數×100% 舉例:滿足以下任何一條即視為測試質量不合格

用戶或非測試人員發現的有效A類錯誤>2 用戶或非測試人員發現的有效A類錯誤>4

用戶或非測試人員發現的有效缺陷的總數與測試發現的有效缺陷總數的比例>10% 用戶或非測試人員發現的有效C類錯誤、D類錯誤均>5

第2/2頁

軟件驗收測試報告-模版

惠普國際人才中心 CRM測試項目

作者

XXX

軟件驗收測試報告

目錄

1

文檔信息 .......................................................................................................................................... 3 1.1 1.2 1.3 1.4 2

核實文檔版本 .......................................................................................................................... 3 修改記錄 .................................................................................................................................. 3 文檔批準 .................................................................................................................................. 3 分發 .......................................................................................................................................... 3

引言 .................................................................................................................................................. 4 2.1 2.2 2.3 2.4

編寫目的 .................................................................................................................................. 4 項目背景 .................................................................................................................................. 4 定義 .......................................................................................................................................... 4 參考資料 .................................................................................................................................. 4

3 測試計劃執行情況 .......................................................................................................................... 4 3.1 3.2 3.3

測試項目 .................................................................................................................................. 4 測試機構及人員 ...................................................................................................................... 4 測試結果 .................................................................................................................................. 4

4 5

軟件需求測試結論 .......................................................................................................................... 5 評價 .................................................................................................................................................. 5 5.1 5.2 5.3 5.4

軟件能力 .................................................................................................................................. 5 缺陷和限制 .............................................................................................................................. 5 建議 .......................................................................................................................................... 5 測試結論 .................................................................................................................................. 5

6 7

詞條解釋 .......................................................................................................................................... 5 參考文獻 .......................................................................................................................................... 5

1 文檔信息

1.1 核實文檔版本

使用本文檔前,文檔使用者有責任核實當前版本的有效性

1.2 修改記錄

對本文檔所有修改都應按修改時間順序記錄在此。

1.3 文檔批準

您本人或您本人指定的代表的簽字表明 您批準了本文檔內容。 它也表明您已經仔細地閱讀、審查和考慮到了本文檔對您的部門有怎樣的影響以及它是否符合公司的指導方向。

批準簽字

1.4 分發

<列出本文檔擬分發往的部門或個人名單>

● ●

2 引言

2.1 編寫目的

{闡明編寫軟件驗收測試報告的目的并指明讀者對象。}

2.2 項目背景

{說明項目的來源、委托單位及主管部門。}

2.3 定義

2.4 參考資料

{列出有關資料的作者、標題、編號、發表日期、出版單位或資料來源,可包括:a.項目的計劃

任務書、合同或批文;b.項目開發計劃;c.需求規格說明書;d.概要設計說明書;e.詳細設計說明書;f.用戶操作手冊;g.測試計劃;h.軟件驗收測試報告所引用的其他資料、采用的軟件工程標準或軟件工程規范。}

3 測試計劃執行情況

3.1 測試項目

{列出每一測試項目的名稱、內容和目的。}

3.2 測試機構及人員

{給出測試機構名稱、負責人和參與測試人員名單。}

3.3 測試結果

{按順序給出每一測試項目的:a.實測結果數據;b.與預期結果數據的偏差;c.該項測試表明的事

實;d.該項測試發現的問題。}

3.3.1 3.3.2

測試環境:

測試案例及測試結果:

4 軟件需求測試結論

{按順序給出每一項需求測試的結論。包括:a.正式的軟件能力;b.局限性(即此項需求為得到充

分測試的情況及原因)。}

5 評價

5.1 軟件能力

{經過測試所表明的軟件能力}

5.2 缺陷和限制

{說明測試所揭露的軟件缺陷和不足,以及可能給軟件運行帶來的影響。}

5.3 建議

{提出為彌補上述缺陷的建議。}

5.4 測試結論

{說明能否通過。}

6 詞條解釋

無。

7 參考文獻

掃一掃手機訪問

發表評論