项目-测试总结.doc

项目全称测试总结

项目全称
测试总结

承建方全称
2013年7月

目录

1. 简介 - 1 -
1.1 编写目的 - 1 -
1.2 项目背景 - 1 -
1.3 系统简介 - 1 -
1.4 术语和缩写词 - 2 -
1.5 参考资料 - 2 -
2. 测试概要 - 3 -
2.1 测试用例设计 - 3 -
2.1.1 系统功能测试 - 3 -
2.1.2 系统性能测试 - 3 -
2.2测试环境配置 - 3 -
2.2.1 软件环境 3 -
2.2.2 硬件环境 - 4 -
2.3 测试工具 - 4 -
2.4 测试方法 - 4 -
2.5 测试工作记录 - 5 -
2.5.1 测试人员 - 5 -
2.5.2 测试时间 - 6 -
2.5.3 测试内容 - 6 -
3. 测试结果及缺陷分析 - 7 -
3.1 系统功能测试 - 7 -
3.1.1 缺陷按严重级别汇总 - 7 -
3.1.2 缺陷按优先级汇总 - 8 -
3.1.3 缺陷按模块汇总 - 8 -
3.1.3 缺陷按开发工程师汇总 - 9 -
3.1.5 缺陷按测试工程师汇总 - 9 -
3.2 系统性能测试 - 10 -
3.2.1 负载测试结果与分析 - 10 -
3.2.2 压力测试结果与分析 - 10 -
3.3 覆盖分析 - 11 -
4. 典型缺陷引入原因分析 - 12 -
5. 结论 - 12 -

1. 简介
1.1 编写目的
本测试报告为项目全称的测试报告，目的在于总结测试阶段的测试以及分析测试结果，描述系统是否符合需求。预期参考人员包括用户、测试人员、开发人员、项目管理者、其他质量管理人员和需要阅读本报告的高层经理。
1.2 项目背景
“数字化校园”指学校在开展教学、科研和管理及对外通讯工作全过程中运用宽带、交互性和专业性的局域网络实现学校办学教学的数字化、信息化和智能化。数字化校园是我国校园信息化发展的趋势，数字化校园将把学校的管理和教学带入一个全新的网络信息化时代，以数字化的方式来体现我们的工作、学习、交流与管理，是一种全新的生活学习和管理模式。它的目标是将校园内的各种信息数字化，增进交流，改变教师的授课方式与学生的学习方式，增进学校与社会、学校与家长的沟通，做到社会、家庭与学校共同教育孩子的目的；此外，数字化校园还提供强有力的数字化分析工具，使学校各方面的信息可以直观、便捷地反映到管理者面前，从而保证决策的科学性和及时性，最终达到提高学校教育质量和社会影响力的目的。一句话，最终实现以数据资料数字化为基础、以沟通交流数字化为纽带、以教育教学数字化为核心、以行政管理数字化为支撑的数字化校园。
“十五”期间，北京市委、市政府高度重视中小学信息化建设，确立了“高标准、高质量实现首都信息化，推动基础教育跨越式发展”的目标。几年来，北京市业主简称通过政策倾斜和经费投入，使北京市中小学信息化在基础设施建设、教师培训、普及信息技术教育、提高信息化管理水平等方面取得了快速进展。
1.3 系统简介
项目全称是建设中小学的数字化校园项目，目标是将校园内的各种信息数字化，增进交流，改变教师的授课方式与学生的学习方式，增进学校与社会、学校与家长的沟通，做到社会、家庭与学校共同教育孩子的目的；此外，数字化校园系统还提供强有力的数字化分析工具，使学校各方面的信息可以直观、便捷地反映到管理者面前，从而保证决策的科学性和及时性，最终达到提高学校教育质量和社会影响力的目的。一句话，最终实现以数据资料数字化为基础、以沟通交流数字化为纽带、以教育教学数字化为核心、以行政管理数字化为支撑的数字化校园。
1.4 术语和缩写词
Bug状态(Status)：指缺陷通过一个跟踪修复过程的进展情况。包括New、Open、Reopen、Fixed、Closed及Rejected等
Bug严重级别(Severity，Bug级别)：是指因缺陷引起的故障对软件产品的影响程度。由测试人员指定。
Bug优先级(Priority)：指缺陷必须被修复的紧急程度。由Bug分配者（开发组长/经理）指定。
1.5 参考资料
Ø GB/T 11457 软件工程术语
Ø GB 8566 计算机软件开发规范
Ø GB 8567 计算机软件产品开发文件编制指南
Ø GB/T 12505 计算机软件配置管理计划规范
Ø ISO9001:2008 质量管理体系要求
Ø 项目全称招标文件
Ø 项目全称合同
Ø 项目全称-需求规格说明书

2. 测试概要
2.1 测试用例设计
针对测试目的的不同，本次测试分为系统功能测试和系统性能测试。
2.1.1 系统功能测试
系统功能测试用例的设计主要采用等价类划分、边界值、因果图等方法，先设计出测试用例的框架，然后根据框架来设计测试用例，同时,根据自由测试中发现的Bug，对测试用例做进一步完善、优化，形成最终的版本。测试用例遵循以下规则：
Ø 测试用例的代表性：能够代表并覆盖各种合理的和不合理的、合法的和非法的、边界的和越界的以及极限的输入数据、操作和环境设置等。
Ø 测试结果的可判定性：即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果。
Ø 测试结果的可再现性：即对同样的测试用例，系统的执行结果应当是相同的。
2.1.2 系统性能测试
系统性能测试包含并发测试、压力测试、强度测试。重点测试10-50用户并发访问的系统性能，500用户以上并发访问对系统负压情况，以及对大批量数据录入、查询的系统强度的测试。
2.2测试环境配置
2.2.1 软件环境
终端类别
操作系统
相关应用软件
客户端
Windows XP professional
IE6或IE7 或IE8
服务器
Windows server 2008 R2
Sun Jdk1.6、Apache Tomcat6.0、Microsoft Windows SQL server 2008 R2、

2.2.2 硬件环境
终端类别
机器型号
配置说明
客户端
DELL OptiPlex 380
处理器：Intel 奔腾双核 E5300
内存大小：2048M
服务器
DELL PowerEdge T410
处理器：Intel Xeon E5504
内存大小：4096M

2.3 测试工具
Ø TestDirector（测试管理工具）
TestDirector是全球最大的软件测试工具提供商Mercury Interactive公司生产的企业级测试管理工具，也是业界第一个基于Web的测试管理系统,它可以在您公司内部或外部进行全球范围内测试的管理。通过在一个整体的应用系统中集成了测试管理的各个部分，包括需求管理，测试计划，测试执行以及错误跟踪等功能，TestDirector极大地加速了测试过程。
2.4 测试方法
Ø 等价类划分方法是把所有可能的输入数据划分成若干部分（子集），然后从每一个子集中选取少量具有代表性的数据作为测试用例，测试某等价类的代表值就等于对这一类其他值的测试。
Ø 边界值分析方法：是输入和输入等价类中刚好处于边界、或超过边界或小于边界的状态，使用边界值分析方法设计测试用例应先确定边界情况，然后选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据。
Ø 错误推测方法：是根据经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例的方法。
Ø 因果图方法：前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件，但未考虑输入条件之间的联系，相互组合等，考虑输入条件之间的相互组合可能会产生一些新的情况，但要检查输入条件的组合不是一件容易的事情， 即使把所有输入条件划分成等价类，他们之间的组合情况也相当多，因此必须考虑采用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来考虑设计测试用例，这就需要利用因果图（逻辑模型）。
Ø 判定表法：是分析和表达多逻辑条件下执行不同操作的情况下的工具，在程序设计发展的初期，判定表就已被当作编写程序的辅助工具了，由于它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确。
Ø 正交实验设计方法：从大量的测试数据中挑选出适量的、有代表性的测试数据，依据伽罗瓦（Galois）理论导出的“正交表”，从而合理地安排测试的一种科学实验设计方法。

2.5 测试工作记录
2.5.1 测试人员
角色
人员
职责
项目经理
项目经理姓名
评审并批准项目计划及有关报告；
组织并确保团队工作；
控制项目执行；
评估项目绩效；
与有关人员进行沟通。
测试经理
张明利
项目计划编制；
协调并实施项目计划中确定的活动；
识别测试环境需求；
负责设计测试用例；
为其他人员提供技术支持。
测试人员
郑海艳、秦建青
王大伟、吕波、崔延、陈芳
执行测试活动；
在项目计划制订阶段，识别项目活动，估计每项活动所需的时间。
环境准备人员
王大伟
秦建青
提供资源保障；
建立并维护测试环境。
质量保证人员
QA姓名
确定项目质量目标；
制订并实施质量计划；
监督、指导项目活动的执行过程。

2.5.2 测试时间
事件
开始时间
结束时间
编制测试计划
2013.5.5
2013.5.9
测试计划评审、修改
2013.5.10
2013.5.11
编制测试用例
2013.5.11
2013.5.19
测试用例评审（内部）
2013.5.20
2013.5.22
测试用例修改
2013.5.23
2013.5.28
第一轮功能测试
2013.5.29
2013.6.18
第一轮测试总结评审（内部）
2013.6.19
2013.6.20
第二轮功能测试
2013.6.21
2013.7.8
联调测试、压力测试
2013.7.9
2013.7.13
第二轮测试后总结评审（内部）
2013.7.15
2013.7.16
系统回归测试
2013.7.17
2013.7.26
编制测试报告
2013.7.27
2013.7.29
提交测试文档
2013.7.30
2013.8.4

由于严格控制测试进度，测试执行基本按计划时间执行，由于项目周期比较紧，在第一轮功能测试时通过加班提前两天完成测试任务。
2.5.3 测试内容
系统功能测试对系统中的所有的模块进行测试，系统性能测试对系统中教师角色的模块进行测试。

3. 测试结果及缺陷分析
3.1 系统功能测试
此次测试严格按照项目计划和测试计划执行，按时完成了测试计划规定的测试对象的测试。针对测试计划规定的测试策略，在测试执行中都有体现，在测试执行过程中，依据测试计划和测试用例，对系统进行了完整的测试，测试中共发现 1969个 bug。
3.1.1 缺陷按严重级别汇总

测试发现的 bug主要集中在 Minor和 Trivial阶段，属于一般性的缺陷，但是测试的时候，出现了 一些严重级别为Major的缺陷，出现严重级别的 bug主要表现在以下几个方面：
Ø 系统无响应，处于死机状态，需要其他人工修复系统才可复原
Ø 点击某个菜单后返回异常错误
Ø 进行某个操作（增加、修改、删除等）后，系统返回异常错误
Ø 输入超长字符时，系统返回异常错误
Ø 对必填字段进行校验时，未输入必输字段，系统返回异常错误
Ø 系统定义不能重复的字段输入重复数据后，系统返回异常错误

3.1.2 缺陷按优先级汇总
测试发现的 bug主要集中在 High和 Medium阶段，属于一般性的缺陷，但是测试的时候，出现了几个Very High的bug，要求开发人员马上解决，出现这种的 bug主要是影响测试进度的，不解决就无法进行下一步测试。
3.1.3 缺陷按开发工程师汇总

此图可以看见每个开发工程师发现bug的数量，并且可以看到发现bug的严重程度的分布图。
3.1.5 缺陷按测试工程师汇总

此图可以看见每个测试工程师发现bug的数量，并且可以看到发现bug的严重程度的分布图。

3.2 系统性能测试
3.2.1 负载测试结果与分析

从此图可以看出在500个用户并发的情况下，长时间运行，系统响应时间出在平稳状态，响应时间在1.4s-1.6s，满足需求中的要求。
3.2.2 压力测试结果与分析

从此图可以看出系统在用户不断增加的情况下，系统基本处于平稳状态，达到1000用户，响应时间为3s左右，满足需求中的要求。

3.3 覆盖分析

此次测试，测试用例覆盖率总体达到了预期目的。根据需求规格说明书和需求人员的沟通，对系统中的功能进行了全面测试；可靠性方面针对主要模块进行测试；兼容性方面保证在IE6、IE7和IE8下能正常运行；安全性只针对个别模块进行测试；易用性方面进行了比较全面的测试；数据方面进行了比较严密的测试；本系统都是在汉语环境下运行，没有进行外国语测试；对主要功能进行了性能测试和负载测试；还对可移植性和可维护性等进行一些测试。

4. 典型缺陷引入原因分析
测试过程中发现的缺陷主要有以下几个方面：
1．需求定义不明确
需求文档中，存在功能定义错误，输入输出字段描述错误，输入输出字段限制定义错误，输入输出限制定义缺失这几种类型的缺陷。使得开发人员根据需求进行设计时，没有考虑相关功能的关联性，以及需求错误的地方，在测试过程中，需求相关的问题表现出来。需求做改正，设计必须跟着做改动，浪费时间和影响开发人员的积极性，降低开发人员对需求的信任，可能会导致开发人员不按照需求进行设计而根据自己的经验来进行设计。
2．功能性错误
功能没有实现，导致无法进行需求规定的功能的测试。
功能实现错误，实现了需求未定义的功能，执行需求定义的功能时系统出现错误。
3．页面设计和需求不一致
页面设计没有根据需求进行，输入、输出字段文字错误，用户无法理解字段含义。
页面设计没有完成需求规定的输入限制验证，导致用户可以输入错误的或者无效的数据，这些数据有可能会引起功能性错误。
5. 结论
通过大家共同努力，完成了用户文档、功能性、可靠性、易用性、可维护性、可移植性、性能和安全性八个方面进行测试，将所有测试发现的缺陷提交入Bug库中，在系统测试中发现1879个bug，经过多轮测试，最后验证所有的bug都被修改成功，所有bug都被关闭，达成既定目标，完成测试总结的制定。

- 11 -