xxx
系统测试报告
xxx公司
xxxx年xx月
变更记录
版本 | 类型 | 说明 | 编制人/日期 | 审核人/日期 | 批准人/日期 |
1.概述
测试是质量保证的重要手段。相关统计资料表明,优秀软件开发机构40%的工作量花在软件测试上,软件测试费用占软件开发总费用的30%至50%。对于一些要求高可靠、高安全的软件,测试费用可能相当于整个软件项目开发所有费用的3至5倍。由此可见,要成功开发出高质量的应用信息系统,必须重视并加强测试工作。
xxx公司有严格的测试管理体系,遵循国际最先进的面向对象软件测试标准,采用先进的自动测试软件,拥有一批专业的测试工程师,对软件产品进行“苛刻”的测试。
本次测试为系统试运行前的系统测试,通过手工和测试工具相结合的方式在公司内部测试环境上从 “模块功能”、“整体业务流程”、“界面UI”、 “兼容性”等方面对程序进行全面的检验、评估,目的在于验证系统已经符合用户方验收标准,同时提供客观、真实、详尽的测试数据供用户方进行评判。
2.阅读人群
项目相关人员;
系统最终用户;
3.测试目的
从 “模块功能”、“整体业务流程”、“界面UI”、“兼容性”等多方面对“xxx系统”软件进行测试,验证系统功能上符合需求设计标准且满足用户的实际业务需求。
4.测试需求
4.1.文档需求
软件需求说明书、软件概要设计说明书、软件详细设计说明书、系统操作手册
4.2.软硬件资源需求
软件环境 | |||||
设备用途 | 操作系统 | IP地址 | 服务软件 | 测试软件 | 硬件参数 |
硬件环境 | |||||
4.3.测试数据需求
在测试设计活动中,如果没有测试数据,测试过程和测试用例将无法实施和执行。本次测试数据由产品部各项目提供业务数据,例如Oracle数据,MySQL数据等,即xxx平台将会接入xxx部现有项目中的数据资源。确定实际的测试数据后,我们将围绕测试数据的以下四个属性来进行准备:
1、深度——测试数据中数据的容量或数量
深度是一个需要考虑的重要事项,在测试过程中,我们将首先使用一个较小的支持关键测试用例的数据集(即正面测试用例)。随着测试过程的不断持续,逐步增加测试数据,直到数据深度完全体现出实际环境为止。
2、宽度——测试数据中数据的变化程度
宽度是指测试数据值变化的程度。创建更多的记录就可以增加测试数据的深度。但是它无法解决我们期望在实际数据中看到的数据真实变化的问题。因此我们会首先生成一版基础测试数据,并在实际测试过程当中通过手工测试以及利用自动化工具的方式使基础数据产生不同范围的变化,以此来模拟实际生产环境中的数据变化。
3、范围——测试数据与测试目标的相关性
范围和测试深度和测试宽度相关。具有许多数据并不意味着其数据一定正确。与处理测试数据的宽度一样,我们会确保测试数据和测试目标相关,也就是说,能够保证支持特定测试目标的测试数据。
4、构架——测试数据的物理结构
本次测试将需要在迭代中以及各个迭代之间重复执行。为统一、有效、可控地执行测试,测试数据应在测试执行前返回其初始状态。在自动执行测试时,这一点尤其重要。
因此,为了确保测试的完整性、把握性和有效性,测试数据不受外部的任何影响,并且了解测试执行在开始、期间和结束阶段的状态,这两点异常重要。为了达到测试目标,我们将在整体测试开始前将测试数据进行备份,在每一轮迭代测试完成后恢复数据。
5.测试时间及人员安排
测试类型 | 测试时间 | 参与测试人员 |
6.测试人员构成
为了保证软件的开发质量,软件测试应贯穿于软件定义与开发的整个过程。因此,对分析、设计和实现等各阶段所得到的结果,包括需求规格说明、设计规格说明及源程序都应进行软件测试。基于此,从广义上,我们将需求评审组、设计评审组也视为测试人员组织,因此我们将不同阶段的测试组织分为:
1、需求评审小组
需求分析规格说明是否完整、正确、清晰是软件开发成败的关键。为了保证需求定义的质量,应对其进行严格的审查。审查小组由下列人员组成:
组长:1人,项目技术总监兼任;
成员:技术委员会所有成员、开发组组长、测试组组长、系统分析员、软件架构师、用户及其它相关人员等。
2、设计评审小组
软件设计是将软件需求转换成软件表示的过程。主要描绘出系统结构、详细的处理过程和数据库模式。按照需求的规格说明对系统结构的合理性、处理过程的正确性进行评价,同时利用关系数据库的规范化理论对数据库模式进行审查。评审小组由下列人员组成:
组长:1人,由项目技术总监兼任;
成员:技术委员会所有成员、测试组组长、开发组组长、高级系统分析师、软件架构师、测试工程师、用户及其它相关人员等。。
3、程序功能测试组
软件测试在软件生存周期中横跨两个阶段:在编写出每一个模块之后,就对它进行单元测试。该阶段的测试工作,由编程组内部人员进行交叉测试(避免编程人员测试自己的程序)。这一阶段结束后,进入软件生存周期的测试阶段,由专门的测试人员对软件系统进行各种综合测试。
组长:1人
成员:测试工程师、需求人员等。
7.测试步骤
各种测试的工作步骤如图所示:
1、制定测试计划
不管是单元测试、集成测试、系统测试、还是压力测试,验收测试,都需要制定详细的测试计划,对测试的目的和内容、测试的环境、人员、时间、方法和步骤,以及测试的准则等作出具体安排。
2、设计和实现测试用例
测试用例是测试的具体指导方案。一般包括白盒测试和黑盒测试两种。
白盒测试的进入前提是在测试人员已经对被测试对象有了一定的了解,基本上明确了被测软件的逻辑结构。通过针对程序的逻辑结构设计和加载测试用例,驱动程序执行,检查在不同点程序的状态,以确定实际状态是否与预期状态一致。
白盒测试主要测试以下项目:
对程序模块的所有独立的执行路径至少覆盖一次。
对所有的逻辑判定,真假两种情况都至少覆盖一次。
在循环的边界和运行界限内执行循环体。
测试内部数据结构的有效性。
白盒测试要达到的目标:语句覆盖率达到100%,分支覆盖率达到100%,覆盖程序中主要的路径(主要路径指完成需求和设计功能的代码所在的路径和程序异常处理执行到的路径)。
黑盒测试要根据系统的功能和性能需求来设计测试用例,以验证程序内部活动是否符合客户要求的活动。
黑盒测试主要测试以下项目:
被测单元的功能是否实现。
被测单元的性能是否满足要求。
可选的其他测试项,如边界、安全性、可靠性、强度测试、人机交互界面测试等。
黑盒测试要达到的目标:系统正确的实现了需求和设计上要求的功能,满足性能要求,同时程序可靠和安全。
3、测试执行
根据测试用例执行测试,并记录测试结果。
4、测试报告与总结
对测试结果进行整理、分析,形成报告
8.缺陷等级划分
A类--严重错误,包括以下各种错误:
-
由于程序所引起的死机,非法退出
-
死循环
-
数据库发生死锁
-
因错误操作导致的程序中断
-
功能错误
-
与数据库链接错误
-
数据库通讯错误
B类--较严重错误,包括以下错误:
-
程序错误
-
程序接口错误
-
数据库的表、业务规则、缺省值未加完整性等约束条件
C类--一般性错误,包括以下各种错误:
-
操作界面错误(包括数据窗口内列名定义、含义是否一致)
-
打印内容、格式错误
-
简单的输入显示未放在前台进行控制
-
删除操作未给出提示
-
数据库表中有过多的空字段
D类--较小错误,包括以下各种错误:
-
界面不规范
-
辅助说明描述不清楚
-
输入输出不规范
-
长操作未给用户提示
-
提示窗口文字未采用行业术语
-
可输入区域和只读区域没有明显的区分标志
9.测试通过标准
功能上无业务逻辑错误和A、B、C类缺陷,所有业务流程均测试通过且不存在功能缺陷。性能上满足用户方实际业务要求。
10测试内容
10.1.模块测试
模块测试的目的是保证每个模块作为一个单元能正确运行,在这个测试步骤中所发现的往往是编码和详细设计的错误。本次通过对“xxx系统”软件提供的所有模块进行测试,目标是核实被测试模块是否满足开发要求,是否能够提供设计所描述的功能,用户的需求是否都能够得到满足。
10.1.1测试范围
“xxx系统”软件提供的所有功能模块,不包含接口相关的功能
10.1.2.测试目标
验证被测试模块是否符合用户实际需求且测试优先级为“高”、“中”的关键项没有任何缺陷,测试优先级为“低”的关键项缺陷率低于5%。
10.1.3.测试方法
主要采取手工执行测试用例的方法来进行测试,对于大量的重复性的操作以测试工具代替手工执行。
10.1.4.测试结果
编号 | 模块名称 | 关键项 | 测试结果 |
10.2.业务流程测试
10.2.1.测试范围
“xxx系统”软件提供的全部功能模块对应的所有流程,不包含接口相关的功能对应的交互流程。
10.2.2.测试目标
验证系统的业务流程能够正确执行且满足用户的实际业务需求。
10.2.3.测试方法
手工测试
10.2.4.测试结果
编号 | 业务流程 | 关键项 | 测试结果 |
10.3.界面UI测试
界面是软件与用户交互的最直接的层,界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作,起到向导的作用。同时界面如同人的面孔,具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉,相反由于界面设计的失败,让用户有挫败感,再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。
界面测试的目标在于确保用户界面向用户提供了适当的访问和浏览测试对象功能的操作。除此之外,界面测试还要确保 界面功能内部的对象符合预期要求,并遵循公司或行业的标准。
10.3.1.测试范围
“xxx系统”软件提供的全部功能模块
10.3.2.测试目标
各模块风格(包括颜色、字体、提示信息、图标、TITLE等)应保持一致,或符合可接受标准,能够保证用户界面的友好性、易操作性,而且符合用户操作习惯。
10.3.3.测试方法
手工测试
10.3.4.测试结果
编号 | 关键项 | 检验内容 | 测试结果 |
10.4.兼容性测试
兼容性测试是指待测试项目在特定的硬件平台上,不同的应用软件之间,不同的操作系统平台上,在不同的网络等环境中能正常的运行的测试。
兼容性测试的目的:待测试项目在不同的操作系统平台上正常运行,包括待测试项目能在同一操作系统平台的不同版本上正常运行;待测试项目能与相关的其他软件或系统的“和平共处”;待测试项目能在指定的硬件环境中正常运行;待测试项目能在不同的网络环境中正常运行。
Web兼容性测试主要是针对不同的操作系统平台,浏览器,以及分辨率进行的测试。
操作系统兼容性测试:
用户使用的操作系统有windows-7、Windows-8、Windows-10等等。用户使用操作系统的类型,直接决定了我们操作系统平台兼容性测试的操作系统平台数量,进行操作系统平台的兼容性测试的主要目的就是保证我们的待测试项目在该操作系统平台下能正常运行。
浏览器兼容性测试:
浏览器是Web系统中对核心的组成构件,来自不同厂家的浏览器对Javascrīpt、 ActiveX或不同的HTML规格有不同的支持,即使是同一厂家的浏览器,也存在不同的版本的问题。不同的浏览器对安全性和JAVA的设置也不一样。
分辨率兼容性测试:
分辨率的测试是为了页面版式在不同的分辨率模式下能正常显示,字体符合要求而进行的测试。
10.4.1.测试范围
“xxx系统”软件提供的所有功能模块,不包含接口相关的功能
10.4.2.测试目标
验证系统在不同的终端操作系统、浏览器版本的组合下能够正确运行
10.4.3.测试方法
手工测试
10.4.4.测试结果
序号 | 方案 | 条件组合 | 测试结果 |
11.测试总结
序号 | 测试类别 | 测试说明 | 测试结果 |
12.缺陷列表
本次整体测试过程中共发现缺陷xx个,其中严重程度为“高”的xx个,严重程度为“中”的xx个,严重程度为“低”的xx个,截止到目前已全部修改完毕并通过了回归验证测试。下面给出的是缺陷列表:
序号 | 描述 | 严重程度 |