测试及验收方案Word下载.doc
- 文档编号:13049483
- 上传时间:2022-10-03
- 格式:DOC
- 页数:24
- 大小:207.83KB
测试及验收方案Word下载.doc
《测试及验收方案Word下载.doc》由会员分享,可在线阅读,更多相关《测试及验收方案Word下载.doc(24页珍藏版)》请在冰豆网上搜索。
编写测试报告
评价测试工作和被测软件,编写测试报告,测试报告包括代码审查报告、单元测试、集成测试、功能测试和性能测试的测试报告。
评审测试结果
各测试阶段均应编制测试计划和测试报告两个测试文档,测试文档应经过相应评审,其中,代码审查、单元测试和集成测试的测试文档由开发组内部组织评审,项目经理参与各阶段文档的审核,评审过的文档由时纳入配置管理。
1.1.1.3.测试用模板
测试过程要用到多个文档模板,包括评审问题记录单、评审总结报告、软件问题报告、软件修改报告等。
表Error!
Notextofspecifiedstyleindocument.1 评审问题记录单
评审问题记录
登记号
评审日期
年月日
评审性质
评审□复审□
项目名
子项目名
实施部门
编号
问题摘要
问题类型
是否解决
1
2
3
4
5
6
7
8
9
10
11
12
13
14
Notextofspecifiedstyleindocument.2 评审总结报告
评审总结报告
阶段名
软件定义
□
需求分析
概要设计
详细设计
编码测试
集成测试
确认测试及验收□
项目负责人
姓名
电话
评
审
任
务
材
料
结
论
通过
结论概述
不通过
备注
Notextofspecifiedstyleindocument.3 评审成员签字表
小
组
成
员
职务姓名职称
部门
签字
组长
副组长
成员
注:
可以不设副组长;
此外,项目负责人或项目组人员可以作为评审组的成员,但不能担任评审组的组长或副组长。
软件问题报告(第1页,共页)
软件问题报告
登记日期
年月日
系统名
报告提出部门
报告人
需求分析□
概要设计□
详细设计□
编码测试□
集成测试□
确认测试□
运行维护□
问
题
程序□
子系统名1
运行的硬件平台
子系统名2
子系统名N
版本号
媒体编号
文档□
文档1
文档编号
文档2
文档3
问题描述/影响:
附注:
部门负责人批准
总师办负责人批准
软件修改报告(第1页,共页)
软件修改报告
修改时间
申请修改部门
修改部门
修改人
修改类型
修改□
升级□
修
改
程序□
修改已通过测试否
测试部门
老程序版本号
新程序版本号
程序媒体编号
文档□
文档1
新文档编号
文档2
文档3
修改描述:
项目审查意见
总体组审查意见
1.1.1.4.单元测试
单元测试主要采用白盒测试技术,用控制流覆盖和数据流覆盖等测试方法设计测试用例;
主要测试内容包括单元功能测试、单元性能测试和异常处理测试等。
单元测试流程分为单元测试设计、单元测试准备、单元测试实施和记录、单元测试错误跟踪。
单元测试设计即单元测试用例设计,由系统设计人员在详细设计的同时完成。
单元测试准备为按照测试用例的要求,准备单元测试驱动数据和驱动模块,由开发人员在开发过程中完成。
单元测试实施和记录由开发人员在编码完成以后进行。
单元测试问题跟踪由开发人员和系统设计人员共同完成,根据引起问题的不同原因进行不同处理。
如果测试问题为编码错误,则由开发人员完成纠错后重新测试。
如果测试问题为设计阶段引起的问题,则需要进行设计变更。
1.1.1.5.代码评审
编程组组长组织人员进行代码检查。
若所写的代码不符合编码规范,即便已实现了系统功能,仍然认为不合格的,需要重写。
代码检查的意义
保证代码编写的规范
保证代码编写的过程不产生BUG
代码检查的依据
检查代码是否有更新
检查存在问题是否有更新
检查存在问题是否已解决
问题已解决,则填写《代码检查记录》
1.1.1.6.集成测试
集成测试采用白盒测试和黑盒测试相结合的测试技术和渐增式的测试策略,用数据流等测试方法设计测试用例。
主要测试内容包括单元之间的接口测试、全局数据结构测试等。
集成测试包括集成测试设计、集成测试准备、集成测试实施和测试记录、集成测试问题跟踪和结束测试等阶段。
集成测试设计由测试组组长根据项目计划和开发计划编制《集成测试计划》,设计《测试用例》。
测试计划和测试用例应当通过项目经理的审查。
集成测试准备需要系统测试组组长建立独立的测试环境。
测试环境包括测试硬件环境、网络、数据库、应用服务器等以及测试对象(程序)的安装和初始化工作。
集成测试实施和测试记录是由系统测试组组长组织人员按照测试计划和测试用例要求进行测试,并且记录测试过程和测试结果。
集成测试问题跟踪是在测试过程中发现的问题由系统测试组组长根据测试记录提交测试问题报告,并由系统设计人员和开发人员解决每一个问题的过程。
测试结束指测试问题报告中的问题解决后,进行回归测试。
当测试问题降低到一定程度并通过测试通过准则时,系统测试组组长提交测试总结报告结束测试。
1.1.1.7.功能测试
功能测试包括两大部分,一是包括基本业务功能、业务测试、接口测试和可用性测试等方面的功能测试,二是包括:
安全性测试、故障恢复测试、数据库测试、配置测试、安装测试的产品化测试。
验收测试主要从系统的实用性、稳定性、可维护性、灵活性、可操作性、和安全性方面进行测试。
(1)测试目标
在整个的软件开发过程中,由于各种原因应用系统会有不完善的问题,这些问题会体现在开发后发布的软件产品中,并在产品中极大的影响着产品的使用,对于用户,这些缺陷阻碍着完成他们的既定目标和工作。
所以我们要组织并执行测试,以降低软件产品中存在的缺陷,保证产品的质量和可用性,测试工作的目标就是降低BUG率,从各个方面提高软件产品的质量和可用性,为用户提供优质的解决方案。
计划进度表和测试计划对业务系统测试进行了时间和内容上的定义与约束。
(2)测试流程
下图是功能测试的流程,概要描述了测试过程中所涉及的角色,测试阶段,以及各阶段不同角色需要完成的任务。
图Error!
Notextofspecifiedstyleindocument.1业务测试流程
在准备测试用例这一活动中,我们所执行的具体任务如图所示,在确定具体的测试范围及内容后,进行测试分类,并根据分类的结果确定需要设计的测试用例。
测试用例是测试工作中重要的指导性文件,测试需求的输入是《系统需求规格说明》。
在整个测试过程中,我们将用IBMRational缺陷管理工具ClearRequest对测试大纲、测试用例、测试问题等进行管理,并可对问题进行统计。
(3)测试完成标准
l实现功能完全符合功能列表。
l所有的功能页面均可达。
l问题得到妥善处理,不含有A,B,C类问题。
l定义的测试项目完成。
l产品化测试的约束达成。
(4)缺陷管理追踪工具
描述中提到的ClearRequest,可以应用于测试的全过程,也可以用于管理各类评审的缺陷等。
还提供一些模板,例如测试计划、测试总结、测试大纲、测试问题卡,因此可以实现从测试计划到总结的各测试活动管理。
我们以需求说明书、软件需求规格说明为输入编写测试大纲,对应测试大纲中的内容和测试需求编写测试用例,测试人员可以根据测试大纲和用例执行测试,发现问题后,记录在ClearRequest中,测试负责人通过查看缺陷问题列表将问题分配给对应的开发人员,开发人员通过查看问题列表修改问题,ClearRequest还提供了各种统计功能,例如根据问题的发现日期、问题等级、问题的分布、问题引入阶段等进行统计,这些统计结果可用来进行分析和总结。
测试过程中使用ClearRequest管理工具的益处在于:
n提高了测试的生产率
n工具自动进行统计和分析
n能够将问题卡输出到Excel文件中,便于与相关人员进行交流和确认。
1.1.1.8.性能测试
性能测试总体流程与业务系统测试的流程基本相同。
性能测试的内容源于南水北调中线管理局对系统的性能要求,此外就是针对南水北调中线干线工程安防综合监控与信息服务系统业务多、范围广、层次多、用户量大的特点,对关键业务、关键流程进行性能测试。
性能测试的目标是在整个系统或一个系统的特定组件上定义、建立和执行性能测试。
验证系统是否满足性能要求,如不能满足,要进行相应的优化。
根据系统的性能要求,我们首先对性能测试进行策划,确定性能测试的类别和测试方法。
然后开发性能测试的用例,确定测试环境并准备就绪后执行性能测试,确定测试中的系统或组件的性能,并使用其结果决定性能是否可以被业务
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 测试 验收 方案