系统测试报告模板.doc

.XX系统项目HeYingHong系统测试报告招标代号;.目录1.引言11.1.编写目的、内容、读者11.2.项目背景11.3.用户群11.4.基本定义11.5.测试对象11.6.测试阶段11.7.术语和缩写词11.8.测试工具11.9.参考资料12.测试概要12.1.测试环境12.1.1.软硬件配置12.1.2.网络拓扑图12.2.测试计划12.3.测试执行12.4.测试用例12.4.1.功能性12.4.2.易用性12.5.版本定义12.6.覆盖分析12.6.1.需求覆盖12.6.2.测试覆盖13.测试用例13.1.功能测试13.1.1.审批业务管理13.2.性能测试13.3.压力测试14.测试结果14.1.Bug趋势图14.2.Bug严重程度14.3.Bug状态分布15.测试结论15.1.功能性15.2.易用性15.3.可靠性15.4.兼容性15.5.安全性16.分析摘要16.1.覆盖率1遗留缺陷的影响16.2.建议17.度量17.1.资源消耗17.2.缺陷密度18.典型缺陷引入原因分析18.1.需求定义不明确18.2.功能性错误18.3.界面设计易用性缺陷18.4.开发人员疏忽引起的缺陷1;.1. 引言1.1. 编写目的、内容、读者编写本测试报告主要有以下几个目的：1. 通过对测试结果的分析，得到对软件质量的评价；2. 分析测试的过程，产品，资源，信息，为以后制定测试计划提供参考；3. 评估测试测试执行和测试计划是否符合；4. 分析系统存在的缺陷，为修复和预防bug提供建议测试包括以下具体内容：1. 用户测试：主要测试系统的功能，操作性，性能，人机对话，系统界面，安全性等，主要参考对象为业主用户。需要了解此部分情况请参祥测试结论；2. 功能测试：主要测试系统是否实现预计结果，此测试为软件的基本测试，主要参考对象为业主用户，开发人员，测试人员等。需要了解此部分情况请参祥测试用例。3. 压力测试：压力测试用来评估在超越最大负载的情况下系统将如何运行。主要参考对象为项目经理，开发经理，测试人员。需要了解此部分情况请参祥压力测试。4. 性能测试：性能测试主反应系统反应时间，CPU使用率，占用内存大小，系统反应速度等硬性指标。主要参考对象为业主用户，开发经理，开发人员，测试人员等。需要了解此部分情况请参祥性能测试。5. 连接数测试：连接数测试主要测试系统服务器同时可以支持多少个用户使用，最大并发连接数是多少。主要参生对象为开发经理，开发人员，测试人员等。需要了解此部分情况请参祥压力测试。实例：本测试报告为XXX项目的测试报告，目的在于总结测试阶段的测试以及分析测试结果，描述系统是否符合需求（或达到XXX功能目标）。预期参考人员包括用户、测试人员、开发人员、项目管理者、其他质量管理人员和需要阅读本报告的高层经理。1.2. 项目背景对项目目标和目的进行简要说明。必要时包括简史，这部分不需要脑力劳动，直接从需求或者招标文件中拷贝即可。1.3. 用户群1. 主要读者：项目管理人员，项目测试经理，业主相关人员；2. 其他读者：项目其他相关人员。1.4. 基本定义严重bug：出现以下缺陷，测试定义为严重bug：3. 系统无响应，处于死机状态，需要其他人工修复系统才可复原。4. 点击某个菜单后返回异常错误。5. 进行某个操作（增加、修改、删除等）后，返回异常错误。6. 当对必填字段进行校验时，未输入必输字段，返回异常错误。7. 系统定义不能重复的字段输入重复数据后，返回异常错误。1.5. 测试对象根据软件定义，软件包括程序、数据和文档，所以软件测试并不仅仅是程序测试。软件测试应贯穿于整个软件生命周期中。在整个软件生命周期中，各阶段有不同的测试对象，形成了不同开发阶段的不同类型的测试。需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都应成为“软件测试”的对象。在软件编码结束后，对编写的每一个程序模块进行测试，称为“模块测试”或“单元测试”；在模块集成后，对集成在一起的模块组件，有时也可称为“部 件”，进行测试，称为“集成测试”；在集成测试后，需要检测与证实软件是否满足软件需求说明书中规定的要求，这就称为“确认测试”。将整个程序模块集成为 软件系统，安装在运行环境下，对硬件、网络、操作系统及支撑平台构成的整体系统进行测试，称为“系统测试”。为了把握各个环节的正确性，需要进行各种验证和确认工作。验证是保证软件正确实现特定功能的一系列活动和过程，目的是保证软件生命周期中的每一个阶段的成果满足上一个阶段所设定的目标。确认是保证软件满足用户需求的一系列的活动和过程，目的是在软件开发完成后保证软件与用户需求相符合。验证与确认都属于软件测试，它包括对软件分析、设计以及程序的验证和确认。在测试过程中，我们将充分考虑以上表述的相关对象，有针对性的加强一些内容的参考，保证做到一个全面、完整的测试。1.6. 测试阶段阶段内容开始日期结束日期负责人阶段一模块测试阶段二功能测试阶段三性能测试阶段四压力测试阶段五连接数测试1.7. 术语和缩写词l 在本文件中出现的“系统”一词，除非特别说明，均指“XXXXX系统”。l MTBF：平均无故障时间。l MTTR：平均维修时间。l SMS（Short Message Service）：短消息业务。l 结构化查询语言：是关系数据库中使用的标准数据查询语言。l 系 统：子系统的集合。l 子 系 统： 模块的集合。l 模 块：功能的集合。l 功 能：处理任务的最小单元。l 系统参数：控制系统的行为及流程的参数，内容存贮在系统数据库中，一般只由系统管理员维护。l 用户参数：控制各工作站的界面、输入法等参数，内容存贮在各工作站软件安装目录下，用户可以修改。l 运行参数：控制程序的启动以及与数据库的连接等，内容存贮在Windows系统的注册表中，第一次使用程序时系统会自动提示输入各种参数。l 角 色：一组具有相同权限的用户集合。l 权 限：执行某个功能，或操作某个模块、某个子系统的钥匙。l 用 户：操作系统的人。1.8. 测试工具测试管理工具：Bugfree性能自动化测试工具：Jmeter；功能自动化测试工具：Watir1.9. 参考资料1. 中华人民共和国标准化法2. 信息技术 软件包 质量要求和测试（GB/T17544-1998）3. 信息技术 软件产品评价 质量特性及其使用指南（GB/T16260-1996）4. 软件工程 产品评价（GB/T18905-2002）5. 软件产品管理办法6. XX需求和设计说明书7. XX数据字典8. XX后台管理系统测试计划9. XX后台管理系统测试用例10. XX项目计划11. XX祥细设计12. XX数据库设计2. 测试概要测试开始日期测试结束日期测试天数测试功能个数执行测试用例数BUG数（用例）XX管理系统测试从xxxx年xx月xx日开始到xxxx年xx月xx日结束，共持续xx天，测试功能点xxx个，执行xxx个测试用例，平均每个功能点执行测试用例xx个，测试共发现xxx个bug，其中严重级别的bug xx个，无效bug xx个，平均每个测试功能点xx个bug。本次测试总共发布11个测试版本，其中xxxx为计划内迭代开发版本（针对项目计划的基线标识），xxxxx为回归测试版本。计划内测试版本，xxx测试进度依项目计划时间准时完成测试并提交报告，其中B4版本推迟一天发布版本，测试通过增加一个人日，准时完成测试。B5版本推迟发布2天，测试增加2个人日，准时完成测试。B6B11为计划外回归测试版本，测试增加5个工作人日的资源，准时完成测试。XX测试通过Bugzilla缺陷管理工具进行缺陷跟踪管理，B1-B4测试阶段都有详细的bug分析表和阶段测试报告。2.1. 测试环境2.1.1. 软硬件配置硬件环境应用服务器数据库服务器客户端环境应用服务器数据库服务器客户端硬件配置CPUIntel(R) Celeron(R) CPU 2.40GHz stepping 01Memory 1048256k HDST380817AS 80G SATA CPUIntel(R) Celeron(R) CPU 2.40GHz stepping 01Memory 1048256k HDST380817AS 80G SATACPUIntel(R) Celeron(R) CPU 2.40GHz stepping 01Memory 1048256k HDST380817AS 80G SATA软件配置Window 2000Professional SP2 IE6.0.2900.2180.xpsp_sp2Window 2000Professional SP2 IE6.0.2900.2180.xpsp_sp2Window 2000Professional SP2 IE6.0.2900.2180.xpsp_sp2网络配置10M LAN10M LAN10M LAN2.1.2. 网络拓扑图（提供相关网络拓扑图，下面是示例图）2.2. 测试计划版本/时间计划开始实际开始计划完成实际完成加班增加资源：版本/时间计划开始时间实际开始时间计划结束时间实际结束时间加班增加资源B1否否B21人1天否B32个人日计划任务祥细分解情况表：任 务开始时间结束时间总 计（天）企业开业2010-03-152010-03-184企业变更2010-03-152010-03-173企业业停歇业2010-03-182010-03-192设立分支机构2010-03-192010-03-191企业基本资料2010-03-162010-03-183分支机构管理2010-03-222010-03-232业务资格管理2010-03-232010-03-2312.3. 测试执行此次测试严格按项目计划和测试计划执行，按时完成了测试计划规定的测试对象的测试。针对测试计划规定的测试策略，在测试执行中都有体现，在测试执行过程中，依据测试计划和测试用例，对系统进行了完整的测试。2.4. 测试用例2.4.1. 功能性u 系统实现的主要功能，包括查询，添加，修改，删除。u 系统实现的次要功能，包括为用户分配，为用户分配权限，渠道绑定，渠道RATE绑定，权限控制菜单按钮。u 需求规定的输入输出字段，以及需求规定的输入限制2.4.2. 易用性u 操作按钮提示信息正确性，一致性，可理解性。u 限制条件提示信息正确性，一致性，可理解性。u 必填项标识。u 输入方式可理解性。2.5. 版本定义给出测试版本，分为三个主要版本：0字头为初稿，定好文档格式和测试方向和测试组织机构人员。1.0版本完成全部功能测试，未经正式发布，未经审核；2.0版整合所有测试人员的测试文档，完成所有测试，几经修改，经过测试经理，项目经理审核，达到正式发布的要求。其中小数点后面的数字为修正了其中内容达到3个模块以上时相应增加0.1。2.6. 覆盖分析2.6.1. 需求覆盖需求覆盖率是指经过测试的需求/功能和需求规格说明书中所有需求/功能的比值，通常情况下要达到100的目标。需求 /功能测试类型是否通过备注企业开业功能测试、业务测试Y企业变更功能测试、业务测试Y企业业停歇业功能测试、业务测试Y设立分支机构功能测试、业务测试Y企业基本资料功能测试、业务测试Y表格中“是否通过”的四种状态：Y：全部通过P：部分通过N：不通过N/A ：不可测试或者用例不适用2.6.2. 测试覆盖需求/功能用例个数执行总数未执行企业开业550企业变更541企业业停歇业550设立分支机构550企业基本资料5413. 测试用例3.1. 功能测试3.1.1. 审批业务管理测试编号A001模块名称企业开业申请建立日期2010-09-13建立人员HYH修改日期2010-09-13状态 草稿 正在修改 正式发布定义驾培企业新开业提交相关证明资料并输入系统，并对此材料做基本的条件判断，根据条件作出相应提示。如：企业训练场地必须达到2000平方米，若未到此条件，系统提示：训练场地未达要求。用例预期情况1234实际结果结论测试编号A002模块名称企业开业受理建立日期2010-09-13建立人员HYH修改日期2010-09-13状态 草稿 正在修改 正式发布定义驾培企业新开业提交相关证明资料并输入系统，并对此材料做基本的条件判断，根据条件作出相应提示。如：企业训练场地必须达到2000平方米，若未到此条件，系统提示：训练场地未达要求。用例预期情况1234实际结果结论3.2. 性能测试1测试对象介绍2测试范围与目的3测试环境与测试工具描述4测试驱动程序的设计5性能测试用例列表性能A描述用例目的前提条件输入数据期望性能（平均值）实际性能（平均值）性能B描述用例目的前提条件输入数据期望性能（平均值）实际性能（平均值）3.3. 压力测试1被测试对象的介绍2测试范围与目的3测试环境与测试辅助工具的描述4测试驱动程序的设计5压力测试用例极限名称A前提条件输入/动作输出响应是否能正常运行20个用户并发操作50个用户并发操作100个用户并发操作200个用户并发操作4. 测试结果4.1. Bug趋势图（提供分析图）此次黑盒测试总共发布11个版本，B1-B5为计划内迭代开发版本（针对项目计划的基线标识），B6-B11为进行的回归测试版本，bug版本趋势图如下图所示：第一阶段，增量确认测试。时间从2007年7月2日到2007年8月3日。从Bug趋势图中可以看出，每个版本的bug数基本维持在60个左右。B1：从图中看到B1共有33个BUG，因为B1版本有一个功能模块在B2版本才开始测试，B1测试模块相对较少，所以B1版本bug相对较少。B2：由于B1中的一个功能模块增加到Build2中进行测试，这一版本除了对B1中的BUG进行验证时对B1进行了回归测试，所以B2中的bug数相对B1出现了明显的增长趋势，B3：B3版本因为有B2版本的bug验收测试，以及B1,B2的回归测试，共发现67个bug，和B2基本保持一致。B4：B4版本bug数有一个下降的趋势，是因为B4版本推迟发布，新增加了测试人员参与测试，对系统不够熟悉，以及测试时间紧张，部分测试用例没有执行，测试覆盖度不够，所以发现bug数呈下降趋势。B5：B5版本bug数又有一个增加的趋势，主要是由于开发功能模块多，该版本需求定义不明确。第二阶段，BUG验证和功能回归确认测试。时间从2007年8月4日到2007年8月14日。B6和B7进行了回归测试，B8没有进行回归测试，只验证了B1B7的bug。B6：进行第一轮回归测试，发现的bug数为33个，遗留一个问题，为数据字典种类默认值问题B7：进行第二轮回归测试，第一次回归测试没有涉及到权限控制菜单按钮的测试，在本次回归测试的时候，重点进行了这个方面的测试，又发现了大量的权限相关的bug。B8：B8没有进行全面的回归测试，只验证了B1B7未通过验证的bug，所以该版本的bug数明显比较少。B9：B9版本进行了全面的回归测试，时重点测试了权限控制，所以发先的bug数又呈现上升的趋势。测试发现44个bug，严重级别的bug为14个，严重级别的bug集中在权限控制上，功能性严重bug没有发现，说明权限控制依旧不稳定，但是系统功能已经稳定。B10：B10版本验证了B9版本发现得bug，没有进行全面的回归测试。B10版本在验证bug的时候，重现打开Bug6个，新增bug2个，重新打开bug有5个为严重级别bug，是关于权限控制的bug，而新发现的bug，1个为严重级别的bug，也是属于权限控制的。说明，权限控制还存在着问题，需要修改权限管理bug，重新发布版本后进行全面的回归测试。B10版本新发现的bug详细分析见遗留bug分析。B11：B11中验证了B1B10未验证的bug，重点测试了权限控制，时进行了查询，添加，删除，修改的功能测试，测试过程中未发现bug。4.2. Bug严重程度（提供几个分析图）测试发现的bug主要集中在normal和minor阶段，属于一般性的缺陷，但是测试的时候，出现了68个严重级别的bug，出现严重级别的bug主要表现在以下几个方面1. 系统主要功能没有实现2. 添加数据代码重复后，出现的找不到页面的错误3. 多语言处理，未考虑非语种代码的情况4. 数据库设计未考虑系统管理员角色，导致用系统管理员进行操作的时候出现找不到页面错误5. 权限控制异常严重级别bug按版本分布如下：由严重bug版本分布图可以看出，严重级别的bug版本趋势和bug版本趋势基本是一致的，但是，在B7和B9版本中年，严重级别的bug明显增多，主要原因是B7和B9版本测试了权限控制按钮功能，权限问题出现的严重级别的bug比较多。权限bug主要表现：1. 具有相应按钮操作的权限，页面无相应按钮，无法执行该功能2. 无相应按钮操作权限，页面有相应按钮，点击按钮能出现权限异常错误Bug引入阶段有相应按钮操作权限，有相应按钮，执行该功能出现权限异常错误Bug引入原因4.3. Bug状态分布（提供分析图）由bug状态图可以看出，未解决的bug有4个，主要是B8中新提交的bug，是关于用户管理的bug，因为用户权限管理需要重新设计所以，该部分的bug暂时没有解决。5. 测试结论5.1. 功能性系统正确实现了通过数据字典管理基础数据的功能，实现了数据内容的多语言功能，实现了中英文界面。实现了基础数据管理，集团管理，基础信息管理，渠道管理，代理管理，用户管理的查询，添加，修改，删除的功能，系统还实现了将权限控制细化到菜单按钮的功能。系统在实现用户管理下的权限管理功能时，存在重大的缺陷，权限控制不严密，权限设计有遗漏。5.2. 易用性现有系统实现了如下易用性：1. 查询，添加，删除，修改操作相关提示信息的一致性，可理解性2. 输入限制的正确性3. 输入限制提示信息的正确性，可理解性，一致性现有系统存在如下易用性缺陷：1. 界面排版不美观2. 输入，输出字段的可理解性差3. 输入缺少解释性说明4. 中英文对应的正确性5. 中英文混排5.3. 可靠性现有系统的可靠性控制不够严密，很多控制是通过页面控制实现的，如果页面控制失效，可以向数据库插入数据，引发错误。现有系统的容错性不高，如果系统出现错误，返回错误类型为找不到页面错误，无法回复到出错前的状态。5.4. 兼容性现有系统未进行其他兼容性测试5.5. 安全性现有系统控制了以下安全性问题：1. 把某一个登录后的页面保存下来，不能单独对其进行操作不进行登录2. 直接输入某一页面的Url能否打开页面并进行操作不应该允许。现有系统未控制以下安全性问题：1. 用户名和密码应对大小写敏感2. 登陆错误次数限制6. 分析摘要6.1. 覆盖率测试用例覆盖率分析图：此次测试，所有测试用例都是在中文界面下执行，测试不包括英文界面下的测试，也不包括正对英文翻译的测试。此次测试，部分页面需求描述无明确的定义，对输入限制无详细定义，无明确的测试依据，在测试过程中，测试是根据输入字段含义，测试人员理解，以及和项目经理，开发人员沟通获得测试依据，无法保证测试依据的正确性和完整性，因此，没有进行完整的，正确的无效数据的测试，测试覆盖率不够，无法保证测试的有效性和正确性。遗留缺陷的影响1 缺陷描述：xx项添加页面，“距离”字段无单位，建议增加单位。缺陷影响：距离字段无单位说明，无衡量标准，用户易用性不好。推迟原因：需求定义无单位定义，统一在升级版本中解决2 缺陷描述：基础信息管理模块，默认语言设置不一致。缺陷影响：相功能模块默认语言设置不一致，一致性不好。推迟原因：默认语言设置，目前无统一标准，升级版本中统一3 缺陷描述：tomcat日志有乱码，日志无项目名称，查看不方便。缺陷影响：其他项目日志都有项目名称，日志无项目名称，查看不方便。推迟原因：目前的日志为了调试方便，显示了很多其它信息，在项目正式发布时会统一处理的。6.2. 建议在项目开始的时候应该制定码标准，数据库标准，需求变更标准，开发和测试人员都严格按标准进行，可以在后期减少因为开发，测试不一致而导致的问题，有时也可以降低沟通成本。发布版本的时候，正确布置测试环境，减少因为测试环境，测试数据库数据的问题而出现的无效bug。开发人员解决bug的时候，填写bug原因以及解决方式，方便bug的跟踪