软件验收测试

软件项目测试验收流程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)回?#23548;?#26080;法进入、Tab键无法切输入框等

(8)必填项和非必填项需加以区别

4、jira「次要」

(1)辅助说明描述不清楚

(2)界面字段、按钮、提示语的文字未采用行业术语

(3)可输入区域和只读区域没有明显的区分标志

(4)其他建议性问题

二、验收流程:

(一)验收流程图:

验收时,一旦发现0类bug和1类bug就立马打回,由此造成项目延期由外包方负责。 从此阶段开始算起,截止到产品正式发布后三个月内,在这期间被乐视方发现的bug

数总和?#36864;?#28431;测bug数,咱们命名Z=漏测数/总的bug数,如果Z<5%,需赔付甲方__%的赔偿金。如果5%

验收中每个阶段都需完成才能进入下一阶段,否则都是验收失败,由PM提交给外包方修改后重新启动验收:

(二)启动验收

外包方提交正式验收版本时,需要给出完整的验收标?#24613;?#21578;,验收报告各项指标全?#30475;?#26631;(100%按照验收标准,如有不符合,须经PM同意)才预示可以进入验收阶段,否则将直接打回,通知PM和相关人员。外包方再次提交验收报告经检查无误后再介入。

1、冒烟验收

类似于smoke test,PM对站点或者app进行30分钟~1小时的功能确认,工作重点在核心功能、逻辑和异常情况。验收流程如下:

(1)进行30分钟~1小时的功能确认,如通过则进入5,否则进入2

(2)验收失败,打回给外包方修?#27169;?#36890;报给相关邮件组,暂停验收,要求外包方给出自测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」

新功能或者优化的,主要模块无更?#27169;?只进行变更部分的功能、UI、用户体验的

测试

详见「准入质量标准V5 - 外包验收(功能优化或新增).xlsx」

BUG修复: 只做BUG的验证和回归测试

软件测试验收报告

软件测试、验收报告

1引言

1.1目的

说明编制本测试验收报告的主要目的。

1.2背景

列出本项目的委托单位、承办单位及其主管部门。

1.3参考资料

a)本项目经核准的计划任务书、合同或上级机关批文;

b)项目开发计划;

c)分析设计说明书;

d)本文档中引用的文件、资料(包括软件开发规范)。

列出这些资料的作者、标题、编号、发表日期和出版单位。

1.4定义

列出本文档中用到的可能会引起混淆的专门术语的定义、缩写词的原文。

2软件测试

2.1动态、静态数据特性

把本项测试中得到的动态、静态的输入/输出数据的结果同动态/静态的输入/输出的期望结果进行比较,列出发现的问题。

2 .2软件功能结论及建议

简述被测试软件的功能,说明为满足此功能而设计的软件所具有?#21738;?#21147;及经过测试已证实?#21738;?#21147;;经过测试证实的本软件存在的缺陷和限制,指出对缺陷如何进行改进。

3评价

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

说明本软件具有的各项功能及性能,说明原定?#30446;?#21457;目标是否达到。

3 .2进度与费用

给出原定计划的进度与?#23548;式?#24230;的?#21592;齲?#21407;定计划的费用与?#23548;手?#20986;费用的?#21592;取?/p>

3 .3对开发工作的评价

对开发工作的生产效率、技术方法、产?#20998;?#37327;等给出评价。

4经验与教训

列出从本项目?#30446;?#21457;中得到的最主要的经验与教?#25285;?#20197;及对今后的软件项目开发工作的建议。

软件项目验收测试研究

摘要摘要:验收测试的重点就是客户。在一个软件项目中,通常多个客户有着不同的观点,这在测试中必须予以考虑。使用验收测试,其目的不仅是确保系统正常工作,而且是确保该应用程序能够满足客户的需求。?#25945;?#23454;现验收测试的方法,以及可以在验收测试中引入的各种技术。

  关键词:软件测试;验收测试;自动化测试

  中图分类号:TP306文献标识码:A文章编号文章编号:16727800(2013)0010003602

  作者简介:董宁(1982-),男,硕士,武汉软件工程职业学?#33322;?#24072;,研究方向为软件技术和职业教育。

  0引言

  良好的软件测试方法可以确保软件项目正确运作,然而,除了软件之外,还有一个重要的却往往被忽视的角色——客户。在软件项目开发的每个阶段考虑客户需求是系统获得成功非常重要的一点。

  1软件项目验收测试概述

  验收测试一直以来被用于不同的技术和方法中,有时指的是同一个概念,有时也可能指不同的测试?#38382;健?#25152;以必须给本文?#25945;?#30340;验收测试相关概念一个明确的定义:①验收测试:包括客户验收测试、用户验收测试和功能测试;②可执?#27844;?#33539;:即验收测试规范,可运行测试来验证项目实现是否与所定义的规?#26029;?#21305;配;③客户:系统的最终用户;④系统?#26680;?#24320;发的软件项目;⑤验收:满足功能和非功能需求;⑥功能需求:该系统必须执行的功能和动作,如显示条目、用户身份验证等;⑦非功能需求:系统的相关因素,如性能、可扩展性和安全性;⑧黑盒:不依赖于系统内部细节的测试过程,如输入数据、检测输出结果。

  这些术语并不足以对如何将验收测试应用于软件项目开发生命周期进行一个准确的描述。验收测试并不?#20999;?#27010;念,但它像测试驱动开发TDD(Test Driven Development)一样,近?#25913;?#26469;才得到关注和广泛使用,并出现了一些相关的测试工具和架构。接下来看一下验收测试是如何应用于软件开发生命周期的。

  验收测试往往被用于由极限编程、敏捷原则和Scrum迭代模型指导开发的软件项目中。出现这样的情况主要有两个原因。一是验收测试侧重于客户和软件所实现的功能向客户提供的价?#25285;?#36825;与敏捷开发原则相一致,后者也是侧重于交付?#23548;?#28385;足客户需求的软件。二是通过一套自动化验收测试,就可以确保该软件能够满足客户需求、确保在实现新功能的时候没有破?#31561;?#20309;旧功能。这意味着,可以将重点放在确保正在开发的功能是否与期望的相一致上面。

  验收测试与敏捷开发过程结合是最有效的。在每一个迭代过程中,验收测试将保证整个团队集中于应用程序的具体部分,确保在单个迭代中软件?#30001;?#35745;到测试都是完整的。

  2软件项目验收测试方法

  验收测试的编写和实现应该贯穿在软件项目开发的每个迭代过程中。下面将基于Scrum迭代模?#20572;?#23454;现一个包含验收测试的软件项目迭代过程。

  在一个标准的Scrum迭代过程开始的时候,开发团队接受了具有最高优先级的待完成的产品需求列表,该产品需求应当分解为多个用户使用情景,每个用户使用情景定义一个系统需求。一个用户使用情景通常由两部分组成,用来描述用户需要的系统部分。如一个典型的用户使用情景可以被描述为“作为一名销售管理员,我想要能够查看信用卡信息,从而能够在本地处理付款。?#38381;?#20010;用户使用情景描述了操作和与操作相关的用户,对要求实现?#21738;?#23481;给出清晰的说明。

  一旦选定一个用户使用情景后,开发团队就应当对他们要实现?#21738;?#23481;有一个很好的认识,这一阶段应该与客户和产品所有者进行交谈,确定?#23548;?#38656;要什么并扩展初始用户使用情景,并基于这一信息和团队内部的其他技术人员?#33268;?#26469;创建任务,在这一阶段,就应当编写验收测试了。了解试图实现的用户使用情景,就可以清楚地认识到完成这些实现所需的任务,也能够知道如何验证这一应用程序是否满足客户需求。验收测试并不是低层次的单元测试,而是侧重于验证基于用户使用情景?#30446;?#25143;需求是否正确实现的高层次测试。确定了用户使用情景后,在将其分解为任务之前,定义验收测试是非常必要的。当所有的验收测试都通过的时候,就完成了系统。这使得任务分解更加侧重于需要完成的事。在这一阶段,客户和产品所有者应当协助开发团队定义验收测试,确保软件需求满足客户的期望。

  良好验收测试可以?#27599;?#25143;在开?#24613;?#30721;之前清楚地知?#36182;?#21069;阶段软件项目将实现的功能。客户清楚地定义了需求,开发团队可以在?#23548;时?#30721;前,提出任何与需求相关的问题并与客户敲定细节。使用验收测试指导和验证,可以使客户清楚地知道他们想要什么,也可以使软件项目开发团队清楚地知道他们计划交付什么。

  但是,客户往往不懂技术,无法理解任何为验证需求所开发的测试代码。因此,验收测试在编写时,不要向客户展示代码,而是使用语言描述验证测试,也就是以几句话定义高层次观点。验收测试有多?#30452;?#20889;?#38382;劍?#22914;Given、When、Then的语法就是一种现在较为流行的验收测试编写语法,具体测试用例编写如下所示:

  假定有一个新用户账号(Given)

  当其在系统中创建时(When)

  那么默认密码应当是[email protected](Then)

  在测试解决具体问题的时候,根据需要,测试表述可以更为复杂:

  假定有一个超支账户(Given)和一个有效的借记卡

  当客户从ATM机上取现金时(When)

  那么显示一条错误信息(Then),没有现金返回,将卡退回给?#27599;?#25143;

  这?#20013;问?#30340;测试将促使客户与开发团队更好地交流并定义验证测试,验证和敲定各个细节。这种测试定义?#38382;讲?#27809;?#27844;?#22810;地使用专业术语,如果测试用例以这种方式定义,客户将对测试更加热心。因为客户在项目开始的时候就表明希望交付软件的实现什么功能,并且在软件交付后能看到参与编写的所有测试都能有效通过。

  验收测试应当将注意力放在业务问题和场景上,使用与业务相同的语言来描述测试。其优势在于?#22351;?#19968;,不需要技术背景就能够理解场景和预期结果?#22351;?#20108;,如果软件底层发生变更,不需要退回并更新这些测试来?#20174;?#36825;一变更。因为验收测试是高层次的,可能涵盖了代码库中的许多不同组建。验收测试不应该依赖于具体的细节,因为随时间的推移,这些细节会发生变更。如果由于丢弃或以某种方式进行变更而使用户使用情景不再有效,应该更新测试来?#20174;?#36825;一点。

  闲置的验收测试和不再使用的测试对于项目和测试套件来说是有害的。测试套件应?#26412;?#21487;能地精简和集中,拥有足够的测试来提供较高层次的保?#24076;?#20294;不应冗余和重复。

  执行验收测试可以手动或自动。尽管手动测试看起来是更快的选择,但从长久看来更加耗时,因为?#30475;?#20462;改系统某个部分,都需要重新运?#23567;?#38543;着系统的增长,手动测试将变得更加耗时,并导致更多错误,可见手动执行这些测试并不像想象?#21738;?#20040;简单。除了手动完成验收测试,也可以利用工具自动完成。

  3自动化验收测试工具

  目前,最流行的自动化验收测试工具是FitNesses。该工具是基于Fit(Framework for Integrated)的。FitNesses提供了一个Wiki前端,可用来管理测试用例和脚本,使得整个团队和客户能够合作创建验收测试用例。除了Wiki前端之外,FitNesses还提供了一个基础代码库用于处理Wiki和测试系统之间的通信。这提供了一个与系统进行交互的抽象试图,能够更方便地编写验证测试。

  除了FitNesses,也可以使用Cucumber来实现自动化验收测试。Cucumber 是一个能够理解用普通语言描述的测试用例的支?#20013;?#20026;驱动开发(BDD)的自动化测试工具,用Ruby编写,支持Java和.Net等多种开发语言。

  4结语

  相比单元测试,验收测试最大的优势是更容易应用于遗留代码。遵循验收测试方法,可以立?#27425;?#32469;项目添加客户验收测试,并提供一定层次的自动化测试,不必对项目和测试方法进行大规模重构。验收测试?#23548;?#19978;为遗留代码提供了增值收益,通过一?#20934;?#23454;?#30446;?#25143;验收测试,就可以在后台重构代码,并添加单元测试,验收测试将提供额外的安全网,确保在重构阶段没?#24615;斐善?#22351;。验收测试提供了一个良好的端对端安全网。

  软件项目验收测试非常重要和有价?#25285;?#23427;可以确保软件系统满足客户?#23548;?#38656;求。

  参考文献:

  [1]李志刚.第三方软件系统验收测试?#23548;鵞J].信息技术,2010 (1).

  [2]郝建营,晏海华,刘超,等.一种有效的Web性能测试方法及其应用[J].计算机应用研究,2007(7).

  责任编辑(责任编辑:张悦)

软件验收测试标准

软件质量与测试效果评估标准

1编写目的

本文档是对独立测试效果及软件质?#30475;?#32570;陷方面进行考核的依据,该标准仅作为整体考核标准中的一个组成部分即:缺陷考核部分。

2适用?#27573;?/p>

本标准适用于软件质量与软件测试质量?#30446;?#26680;。

3 评价基准

软件质量考核基准: 以最后测试组递交的测试总结报告中所提交的有效缺陷为考核指标。 测试质量考核基准: 以软件试运行阶段用户发现的有效缺陷和非测试人员发现的有效缺陷为

考核指标。

有效缺陷: 经过评审确定为影响软件质量或发布的缺陷(包括:确定修改、暂缓修改的)建

议性的E类缺陷不算有效缺陷。

4 验收测试进入准则

1) 软件产品通过单元测试、集成测试和系统测试。

2) 测试组提交以下测试工件:测试计划、测试任务书、测试用例、测试报告、测试分析总结。

5软件验收测试工作程序

测试完成后按项目管理规定,成立测试(项目)验收小组,启动测试验收总结会 5.1根据测试任务书进行测试质量前期评审。 5.2根据测试总结报告进行软件质量评审。(测试角度)

6 软件验收测试合格通过准则

1 软件需求分析说明书中定义的所有功能已全部实现,性能指标全?#30475;?#21040;要求 2 所有测试项没有残余一级、二级错误

3 立项审批表、需求分析文档、设计文档和编码实现一致 4 验收测试工件齐全(见验收测试进入准则)

1)以上比例为错误占总测试模块(不包括E类)的比例。 2)软件产品未经测试合格,不允许?#23545;恕?/p>

6 测试质量合格须符合以下标准

1)以上为用户或非测试人员发现的有效缺陷,且改缺陷不是由需求、功能的变更引起的且在测试任务书规定的测试内容?#27573;?#20869;的缺陷。

2) A类错误、B类错误为独立条件,C类错误、D类错误为组合条件 3)用户或非测试人员发现的有效缺陷的总数不得大于一定的比例:(10%)

用户或非测试人员发现的有效缺陷的总数/测试总结报告提交有效缺陷总数×100% 举例:满足以下任何一条即视为测试质量不合格

用户或非测试人员发现的有效A类错误>2 用户或非测试人员发现的有效A类错误>4

用户或非测试人员发现的有效缺陷的总数与测试发现的有效缺陷总数的比例>10% 用户或非测试人员发现的有效C类错误、D类错误均>5

第2/2页

软件验收测试报告-模版

惠?#23637;?#38469;人才中心 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 核实文档版本

使用本文档前,文档使用者?#24615;?#20219;核实当前版本的有效性

1.2 修改记录

对本文档所有修改都应按修改时间顺序记录在此。

1.3 文档批准

您本人或您本人指定的代表的签字表明 您批准了本文?#30340;?#23481;。 它也表明您已经仔细地阅读、审查和考虑到了本文档对您的部门?#24615;?#26679;的影响以及它是否符合公司的指导方向。

批准签字

1.4 分发

<列出本文?#30340;?#20998;发往的部门或个人名单>

● ●

2 引言

2.1 编写目的

{阐明编写软件验收测试报告?#21738;?#30340;并指明读者对象。}

2.2 项目背景

{说明项目的来?#30784;?#22996;托单位及主管部门。}

2.3 定义

2.4 参考资料

{列出?#27844;?#36164;料的作者、标题、编号、发表日期、出版单位或资料来源,可包括: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

测试环?#24120;?/p>

测试案例及测试结果:

4 软件需求测试结论

{按顺序给出每一项需求测试的结论。包括:a.正式的软件能力;b.局限性(即此项需求为得到充

分测试的情况及原因)。}

5 评价

5.1 软件能力

{经过测试所表明的软件能力}

5.2 缺陷和限制

{说明测试所揭露的软件缺陷和不足,以及可能给软件运行带来的影响。}

5.3 建议

{提出为弥补上述缺陷的建议。}

5.4 测试结论

{说明能否通过。}

6 词条解释

无。

7 参考文献

扫一扫手机访问

发表评论