CCPS测试报告.docx
《CCPS测试报告.docx》由会员分享，可在线阅读，更多相关《CCPS测试报告.docx（10页珍藏版）》请在冰豆网上搜索。
CCPS测试报告
中科金证<社区健康服务整体绩效管理系统>
测试报告
公司名称
深圳中科金证科技有限公司
文档编号
文档名称
绩效系统测试报告
文档版本
1.0
起草
李涛
起草日期
2013/08/06
审批
审批日期
公司名称
深圳中科金证科技有限公司
文档编号
修订历史
版本号
日期
状态
修订人
摘要
1.0
2013/08/06
C
李涛
建立
状态标识：
C–CreatedA-AddedM-ModifiedD-Deleted
目录
1产品质量评价4
1.1通过准则分析满足程度以及结论4
1.2质量目标和总体评价4
1.3实际测试环境以及差异分析5
2测试结果分析5
2.1测试内容结果分析5
2.2缺陷分析6
3.2测试过程分析9
3.3其他分析9
1产品质量评价
1.1通过准则分析满足程度以及结论
测试结论
√
通过
不通过
1.2质量目标和总体评价
测试范围
绩效管理系统项目的测试目的是：
检测此次项目中系统的错误和漏洞，尽可能多地发现并排除软件中潜藏的错误，保证整个软件开发过程是高质量的，最终把高质量的软件系统交给用户；
绩效管理系统项目的测试范围是：
1）人员的管理和赋予权限、
2）报表的填写和审核、
3）评估的操作填写和提交。
4）评估结果的展示、修改。
绩效管理系统项目的测试预期达到的目标是：
各个功能点能正常运行，无异常，升级验证基本功能点验收无异常。
产品质量目标
功能：
各个功能运行无异常
性能：
达到需求说明书的性能要求
其他：
系统部署简单用户操作容易
测试通过准则情况
准则项
达标情况
1.选定的测试类型都要完成
本次测试主要以功能测试为主
2.测试案例覆盖要求达到100%
达到90%以上
3.所有用例都要执行
达到标准，执行了测试用例
4.所有测试用例通过率达到80%，测试用例级别大于C级以上的通过率达100%，不通过的测试用例要经过项目经理同意后才算达到目标。
达到标准，开发工程师对测试过程中发现的BUG进行了修复，目前缺陷状态均为关闭
项目总体评价：
1.经过项目组成员的共同努力，本次测试出的BUG均已关闭，本系统从整体来看，达到了本次项目立项时的预期目标，但是在界面交互性上还需要进一步改观；
2.本次各项功能都已经经过测试，开发人员也已经对测试出来的BUG进行了修复，并通过再次测试。
3.总体来说，本次测试基本上按计划要求执行，并完全实现测试计划中规定的所有目标；
4.通过测试及早发现问题，降低了项目的风险，经过开发工程师的及时修改完善，软件质量有了比较明显的提高；
5.系统的设计基本符合需求规格说明书的要求和思路，但当前提交的系统还需得到实际的应用，从而确保项目质量达到总体要求。
1.3实际测试环境以及差异分析
硬件环境
描述测试的硬件配置情况。
序号
名称
型号
配置
用途
1
联想
E420
CPU主频：
2.5GHz
内存：
4G
硬盘：
450G
其它：
系统服务器
软件环境
描述测试的软件配置情况。
序号
名称
版本号
用途
1
Oracle
10g
数据库
2
Jboss
4.2.2
中间件
3
apache-tomcat
7.0.26
中间件
4
IE
8
浏览器
5
Win7
操作系统
环境差异及影响说明：
实际测试环境和计划测试环境无差异。
2测试结果分析
2.1测试内容结果分析
序号
功能项目
功能描述
测试结果
1
系统设置
1）主要完成系统基础数据的配置。
通过
2
用户管理
2）主要完成：
1、用户信息管理，包括维护用户信息（增加、删除、查询、修改用户信息）；2、评估专家信息管理（用户申请成为评估专家、管理员审批评估专家信息）
通过
3
机构管理
3）主要完成维护辖区内的机构信息（包括增加、删除、查询、修改机构信息（包括社康、医院、管理机构、所在机关、第三方机构的信息））
通过
4
报表管理
4）主要完成：
5）填写各级报表的计划
6）各个年度社康、医院、区级、市级报表模版的编辑工作
7）各级报表完成填写工作后，相关管理人员对报表的审核；
8）报表的查看与导出
9）未完成报表填写工作的社康
通过
5
报表填写
10）完成各级报表的填写与提交
通过
6
评估操作
11）完成评估专家对社康的评估工作。
通过
7
评估管理
12）主要完成：
13）各级评估计划的制定；
14）区级评估、市级评估时对评估专家进行分组
15）在区级评估、市级评估前对各个行政区的社康进行抽样，并提供抽样到的社康进行展示
16）编辑评估时的版本、评估项目、各个评估项目的计算公式
17）制定评估日程；
18）在评估时可以查看评估进度
19）提供结论条件的设置
20）手工录入功能
通过
8
评估结果
21）提供对评估结果的汇总、评估结论的展示、结论的修改，以及平衡系数展示功能
通过
2.2缺陷分析
2.2.1缺陷统计数据
数据获取的时刻：
截至到2013-08-05
注意：
下面的每个阶段同测试计划文档中的工作任务是对应的，下面附件中也带有测试计划文档
阶段或时间
缺陷数量
总数
严重度
状态
A（致命）
B（严重）
C（一般）
D（轻微）
未解决
已解决
2013/04/20--2013/05/21
34
0
2
20
12
0
34
2013/05/22—2013/08/05
29
2
3
17
7
0
29
合计
63
2
5
37
19
0
63
3总体缺陷统计如下：
图一：
缺陷按阶段、时间（或版本）统计
图二：
缺陷按测试类型分布情况
图三：
缺陷按严重度分布情况：
图四：
缺陷按模块分布情况
3.1.1问题倾向及数据分析
描述统计图表中重点要关注的问题，提出有针对性的倾向分析和说明。
可以包括问题的原因分析和建议改进意见。
1.按照BUG类型统计情况来看，代码错误占主要因素以上，原因是开发时没有先做严谨的单元测试，BUG的发现落在了集成测试和确认测试环节上。
2.按照BUG严重程度来看，最严重的1级BUG出现了2个，是使系统无法运行出现的情况是比较少的，一般都是由于开始的集成环境不稳定造成的；严重程序是2的出现了5个，一般是由于修改了某个模块的代码影响了另一个模块的功能造成的，或增加的功能没有把所需要的组件加到环境里面导致的，或对需求理解不正确导致的；但是多数的BUG严重程度是3级和4级，这是在正常的估计范围内。
3.经过项目组成员的共同努力，本次测试出的BUG均已关闭，本系统从整体来看，达到了本次项目立项时的预期目标，但是在界面交互性上还需要进一步改观。
3.2测试过程分析
3.2.1人员投入
工作类型
测试周期
测试人员
工作量统计
测试用例编写
2013/05/02—2013/05/10
吴和楷
8人日
测试计划编写
2013/04/20--2013/04/28
吴和楷
8人日
测试报告与分析
2013/8/6
李涛
1人日
..
3.2.2人员效率
测试人员姓名
设计多少个用例
发现多少个BUG
人员效率分析
吴和楷
75
63
该员工为新培养测试工程师，测试经验不足，编写测试用例不够周到，后由于合同到期离职。
3.2.3人员效果
3.3其他分析
升级会员 