第三方软件测试报告(暂定)
1. 引言
1.1. 编写目的
本文档作为该系统测试的测试标准,内容关系到本次系统测试可能涉及到的测试内容和测试技术解决方案。
1.2. 系统概述
? 略
2. 测试描述
2.1. 测试范围与内容
我方(北京圆规创新公司)对XX公司“XX”项目进行测试,保证使用方的功能正确,保证系统核心模块的稳定和安全,为项目的验收提供参考。以此,本计划列出了在此次功能测试过程中所要进行的内容和实施的方案及测试资源的安排,作为测试活动的依据和参考。
本次测试的对象为XX公司“XX”项目,测试范围为:略。
本次测试的主要内容有功能测试(含容错测试)、易用性测试。
2.2. 测试依据
本次测试所依据的文档包含开发方提供的《需求规格说明书》、《操作手册》、《用户手册》,《维护手册》,《设计文档》等相关开发文档。
并依据IT行业项目的通用标准,包括功能测试标准、缺陷标准、易用性标准。
对于项目的易用性标准,原则上由测试方提出易用性问题修改的建议,由开发方对测试方提交的问题进行确认。
3. 测试解决方案
我公司针对用户方提出的测试要求,根据以往项目的实际经验,撰写测试技术解决方案。该解决方案包含了本次系统测试可能涉及到的测试类型,并分别介绍不同测试类型的内容和相关标准。
3.1. 系统功能测试
实施系统功能测试,完成对被测系统的功能确认。
采用黑盒测试方法,根据需求规格说明书和用户手册,将功能点转换为功能测试需求,根据测试需求编写测试用例,保证所有功能点必须被测试用例覆盖。
测试用例的编写采用基于场景的测试用例编写原则,便于以使用者的角度进行测试。用例设计上兼顾正常业务逻辑和异常业务逻辑。测试数据的选取可采用GUI测试,等价类划分、边界值分析、错误推测、比较测试等测试方法中的一种或者几种数据的组合,一般以等价类划分和边界值法为主。
3.1.1. 系统功能项测试
对《软件需求规格说明书》中的所有功能项进行测试(列表);
3.1.2. 系统业务流程测试
对《软件需求规格说明书》中的典型业务流程进行测试(列表);
3.1.3. 系统功能测试标准
Ø 可测试的功能点100%作为测试需求(如未作为测试需求,必须在测试计划中标注原因并通知用户方负责人);
Ø 测试需求100%被测试用例覆盖;
Ø 测试用例100%被实施(如未实施,在测试报告中标注未测试的原因并通知用户方负责人);
Ø 含有一类缺陷的系统不建议上线发布(缺陷严重等级见附录,需确认);
Ø 含有二类缺陷的系统不建议上线发布(缺陷严重等级见附录,需确认);
Ø 含有三类缺陷10个以上不建议上线发布(缺陷严重等级见附录,需确认);
Ø 权限矩阵测试覆盖率100%。
3.2. 易用性测试
本系统的易用性测试不是本次测试的重点。我方的原则是在测试过程中如果发现有完全不符合IT行业习惯的操作、完成一次业务过多操作步骤和弹出窗口、界面颜色严重影响阅读、提示信息过于复杂或者简单、业务逻辑完全不符合思维逻辑的情况下,我方测试人员会提出易用性类型的缺陷,此类缺陷由用户方最终确认。
易用性测试的内容包括:
软件的用户界面是否友好,是否出现中英文混杂的界面;
软件中的提示信息是否清楚、易理解,是否存在原始的英文提示;
软件中各个模块的界面风格是否一致;
软件中的查询结果的输出方式是否比较直观、合理。
3.3. 容错测试
本系统的容错测试不是本次测试的重点。我方的原则是在测试的过程中检查对系统对非常规操作或业务流程的容错性处理,是否影响系统的正常运行,是否给与用户明确的提示信息等,此类缺陷由用户方最终确认。
容错测试的检查内容包括:
软件对用户常见的误操作是否能进行提示;
软件对用户的的操作错误和软件错误,是否有准确、清晰的提示;
软件对重要数据的删除是否有警告和确认提示;
软件是否能判断数据的有效性,屏蔽用户的错误输入,识别非法值,并有相应的错误提示。
3.4. 安全性测试
如用户方有明确的安全测试需求,可根据用户实际情况,进行安全性测试。
安全性测试的检查内容包括:
软件中的密钥是否以密文方式存储;
软件是否有留痕功能, 即是否保存有用户的操作日志;
软件中各种用户的权限分配是否合理;
3.5. 性能测试
对软件需求规格说明书中明确的软件性能进行测试。测试的准则是要满足规格说明书中的各项性能指标(需明确说明)。
3.6. 适应性测试
参照用户的软、硬件使用环境和需求规格说明书中的规定,列出开发的软件需要满足的软、硬件环境(包括服务器环境、客户端环境)。对部署环境进行测试(需明确说明)。
3.7. 文档测试
用户文档包括: 安装手册、操作手册和维护手册(需明确说明)。对用户文档测试的内容包括:
操作、维护文档是否齐全、是否包含产品使用所需的信息和所有的功能模块;
用户文档描述的信息是否正确, 是否没有歧义和错误的表达;
用户文档是否容易理解, 是否通过使用适当的术语、图形表示、详细的解释来表达;
用户文档对主要功能和关键操作是否提供应用实例;
用户文档是否有详细的目录表和索引表;
文档描述与程序当前版本符合
3.8. 用户有特别要求的测试
用户对于系统是否有特别的要求(需明确说明)
4. 预期提交文档
本次系统测试可能提交的文档包括《测试需求》、《测试计划》、《测试用例》、《测试报告》等。其中测试计划、报告等根据测试回归次数而产生多份。
4.1. 测试需求文档
首先完成测试需求的整理,阅读项目功能性说明的相关文档,挑选出可以测试的功能点,完成测试需求的整理。
4.2. 测试用例文档
测试需求作为今后测试活动的指导和目标,且为测试工作量的估算提供可计算的依据。我方制定测试需求后将测试需求提交相关人员进行审查。通过之后,将根据测试需求完成功能性测试用例的编写。
4.3. 测试日志文档
测试用例设计完成之后,我方将测试用例提交给相关各方评审。评审通过后测试人员按照测试用例实施测试。测试人员在实施测试的时候,将每日填写测试日志。
4.4. 测试报告
完成一次完整的功能测试之后,我方将汇总缺陷,完成测试报告。
5. 测试工作流程
5.1. 测试启动
开发方提供项目相关文档,包括《需求规格说明书》、《设计文档》、《用户手册》等相关文档;
开发方搭建测试环境,提供必要的软、硬件;
开发方进行系统讲解,完成对测试方的培训;
测试方阅读相关文档并学习使用被测系统;
测试方对依据的文档中的不足提出意见,由开发方补充完善文档。
5.2. 测试准备
测试方制定必要的标准,提交开发方和用户方审阅;
测试方整理测试需求,提交开发方和用户方审阅;
测试方书写测试计划,提交开发方和用户方审阅;
测试方编写测试用例,开发测试脚本,可提交开发方和用户方审阅;
5.3. 测试实施
测试方按照测试计划,按照设计的测试用例实施测试,记录测试过程中的问题。测试方每日完成测试日志,并将测试日志提交开发方和用户方。
5.4. 测试总结
测试方对每次回归测试提交缺陷列表,编写测试报告。
6. 三方职责分工
测试过程中需要开发方精悍有素的人员的大力支持与配合,并且为测试方提供现场技术支持。开发方有义务配合测试方完成本次的系统测试,并提供必要的支持工作。
由于测试阶段的根本目标是尽可能多发现并排除软件中潜藏的错误,最终把一个高质量的软件系统交给用户使用,因此用户方在测试阶段的直接参与、指正和确认起着十分重要的作用。开发方需要有专人负责本次系统测试工作,组织测试现场和相关硬件设备,沟通和协调各方关系。
测试方严格按照软件工程理论进行测试,提供专业测试人员和必要的测试工具,并以用户方的根本利益为工作原则指导。
7. 附录
7.1. 软件错误的严重性等级
7.1.1. Critical:1级错误
这一级别的错误一般包括以下内容:
ü 没有实现或错误地实现重要的功能;
ü 业务流程存在重大隐患;
ü 软件在操作过程中由于软件自身的原因自动退出系统或出现死机的情况;
ü 软件在操作过程中由于软件自身的原因对系统或数据造成破坏;
ü 在现有的软、硬建设环境下不能实现应有的功能;
ü 特殊软件在操作过程中可能危及系统和人身安全等。
7.1.2. Major:2级错误
这一级别的错误一般包括以下内容:
ü 没有实现基本功能,并且不存在替代办法;
ü 没有实现重要功能中的部分功能,并且不存在替代办法;
ü 业务流程衔接错误;
ü 用户的权限分配不合理;
ü 不可继续使用的异常错误;
ü 系统不明原因资源占用增大,导致性能不断下降;
ü 界面与需求不符;
7.1.3. Averagte:3级错误
这一级别的错误一般包括以下内容:
ü 没有实现基本功能,但存在替代办法;
ü 没有实现重要功能中的部分功能,但存在替代办法;
ü 可继续使用的异常错误;
ü 提示信息存在错误
7.1.4. Minor:4级错误
这一级别的错误通常为易用性方面的错误:
ü 界面不友好、前后风格不一;
ü 中英文混杂;
ü 查询结果输出不直观;
ü 错别字,提示信息轻微错误;
ü 界面控件缺陷;
ü 快捷键错误;
7.1.5. Enhancement:5级错误
通常为不影响正常使用下的用户方提出的改进性建议,或者文档方面的错误。
ü 界面调整
ü 功能改进调整建议
ü 颜色,字体,图像等不合适
ü 基本操作过于复杂
ü 使用手册与功能不符(功能使用正常)
第二篇:软件测试计划模板_20xx1126
组长: xxx
组员:xxx
20##-1-5
目录
1. 测试计划标识符... 3
2. 简要介绍... 3
2.1测试软件基本情况:... 3
2.2.测试范围的描述:... 3
2.3.与测试相关的参考文档:... 4
系统设计说明书... 4
2.4.测试环境:... 4
3. 测试项目... 5
3.1. 测试项目说明:... 5
3.2. 测试项目功能:... 5
3.3.测试项目外部条件:... 6
4. 测试对象... 6
4.1.测试对象说明:... 6
4.2测试对象的单项功能... 7
5. 不需要测试对象... 8
6. 测试方法(策略)... 8
7. 测试项通过/失败的标准... 9
8. 中断测试和恢复测试的判断标准... 10
9.测试完成所提交的材料... 11
10.测试任务... 11
11.测试所需的资源... 11
12.测试人员的工作职责... 12
13.人员安排与培训与需求... 13
14.测试进度表... 13
15.风险及应急措施... 14
16.审批... 14
1. 测试计划标识符
2. 简要介绍
2.1测试软件基本情况:
产品规格: 产品描述: 一个用于管理图书管图书的软件系统。
产品大小:3.08MB
产品功能:1.读者信息管理,2.图书类别管理,3.图书信息添加,4.图书信息修改,5.新书订购管理
产品定位: 应用软件
软件运行的平台: Java虚拟机,Eclipse
运行的工具: Eclipse
应用领域: 本图书馆管理系统适应于中小规模公共图书馆、中小学及各院校图书馆
2.2.测试范围的描述:
采用黑盒测试方法,整个过程采用自底向上,逐个集成的的办法,依次进行单元测试,组装测试,测试用例的设计应包括合理的和不合理的输入条件。
2.3.与测试相关的参考文档:
2.4.测试环境:
测试环境要求:
3. 测试项目
3.1.测试项目说明:
3.2.测试项目功能:
1. 功能测试:
登陆功能的测试
管理功能的测试
图书信息查询功能的测试
学生信息查询功能的测试
入库管理功能的测试
学生借书功能的测试
学生还书功能的测试
图书注销功能的测试
基础信息设置功能的测试
2. 设计测试:
运行界面的测试
菜单结构是否合理测试
窗体布局是否合理测试
3. 整体测试:
整体功能的实现测试
图书管理系统中每个类转换的正确性测试
3.3.测试项目外部条件:
本次测试主要针对JAVA类程序作底层测试,主要包括包黑盒测试中的功能测试,设计测试以及整体测试。
4. 测试对象
4.1.测试对象说明:
4.2测试对象的单项功能
5. 不需要测试对象
6. 测试方法(策略)
6.1测试策略
本次测试将使用以下三种测试方法
6.2测试记录文档
1.公正性声明
2.测试用例
3.设想
7. 测试项通过/失败的标准
7.1通过的测试用例占所有测试用例的比例
占比例:达到80%
7.2缺陷的数量,严重程度和分布情况
缺陷的数量:少于5个,功能测试部分除外。
7.3测试用例覆盖情况
本测试用例覆盖图书管理系统的代码,菜单,功能,设计界面,360度全方位,无死角。此测试可将系统最主要的功能模块进行逐一的检测,对说明书中列举的功能进行排查,对系统实现各功能的正常运行做充分的测试,输入合理及不合理的测试数据检验功能的运行及出错处理情况。但由于功能模块比较多,采用功能测试设计的测试用例相对比较多,测试需花费一定的时间。
7.4用户对测试的成功结论
基本图书馆管理系统功能的实现,能流畅运行。
7.5文档的完整性
要具有:
1.图书馆管理系统测试用例
2.图书馆管理系统测试数据
3.图书馆管理系统测试缺陷报告
4.图书馆管理系统测试总结报告
5.图书馆管理系统软件测试计划
7.6是否达到性到标准
登陆功能是否实现
管理功能是否实现
图书信息查询功能是否实现
学生信息查询功能是否实现
入库管理功能是否实现
学生借书功能是否实现
学生还书功能是否实现
图书注销功能是否实现
基础信息设置功能是否实现
8. 中断测试和恢复测试的判断标准
8.1关键路径上存在未完成的任务
8.2大量的缺陷
8.3测试环境不完整
8.4资源短缺
9.测试完成所提交的材料
1图书馆管理系统测试工具
2图书馆管理系统测试用例
3图书馆管理系统测试数据
4图书馆管理系统测试缺陷报告
5图书馆管理系统测试总结报告
10.测试任务
10.1测试前的准备工作
1.运行工具:Eclipse
2.人员分配::人员的调配,总结报告,系统开源的查找,
:查找资料,软件测试计划,软件测试总结报告
:查找资料,软件实施总结报告
:查找资料,软件测试总结报告
3.测试工具:电脑一台
10.2测试工作所需完成的一系列任务
1.测试计划的编写
2.测试文档的编写
3.测试计划的实施
4.测试人员的分配
5.通过审核
11.测试所需的资源
11.1测试人员
测试人:
11.2设备
测试设备:机房电脑和宿舍电脑
11.3测试软件
测试软件:Eclipse、 mysql
11.4参考书
《软件测试设计与实施》—作者:蒋方纯
12.测试人员的工作职责
13.人员安排与培训与需求
13.1人员安排
测试人:
13.2培训与需求
学会使用Eclipse,mysql数据库,了解图书馆管理系统的功能与实现,了解图书馆管理系统的布局
14.测试进度表
15.风险及应急措施
15.1测试过程中的风险
1.设备出现故障,网络不通
2.测试工作不全面
3测试工作不充分
4.测试进度发出现危机
5.软件极其复杂
15.2应急措施
1.准备多一台电脑,去学校机房测试
2.编写完整的测试计划
3.预算进度时留下周旋时间
16.审批
审批人: