1、家庭医生二期开发系统-测试报告.docx

1、初稿V发布修订编撰：EPG编撰日期：2013/3/21保密级别：机密文档版本：2.0.文件编号：Q/BS-QH-3-22GP医生二期开发系统系统测试报告经完成，测试可以通过。创业软件股份有限公司项目组版本历史日期版本说明作者2013-03-211.0初稿李坤龄2013-04-032.0修订版李坤吟2013-4-183.0修订版李坤睑2013-5-174.0修订版李坤龄1. 引言41. 1编写目的41.2 项目背景41.3 参考资料4测试环境42. 1硬件配置42.2 软件配置42. 3网络环境4测试概要53. 1测试时间53.2 测试人员53.3 测试方法5测试结果53. 1缺陷汇总54.1.

2、1 缺陷严重程度统计54.1.2缺K各类型分布64.1.3缺陷修复率统计74.1.4缺陷过程统计74.2 缺陷的分析84.2.1 缺陷严重程度分析84.2.2 缺陷类型分布分析84.2.3 缺陷修复率分析84.2.4 缺陷过程分析9测试结论与建议93.1 测试结论93.2 测试建议9项目经理意见91.引言1.1编写目的本测试报告为GP医生二期开发系统的测试报告，目的在于总结测试阶段的测试以及分析测试结果,描述系统是否达到功能目标。给客户及项目组相关成员提供参考。1.2项目背景每个“家庭责任医生”都绑定了一定数据的家庭，可以看成是这些家庭的“家庭医生二通过家庭责任医生与居民的良好互动建立信任关系

3、，从而让每户家庭找自己的家庭医生看病。为了实现“家庭责任医生”对管辖家庭的良好互动服务：诊疗，随访，健康教育，健康咨询等。主要包括三大平台：家庭责任医生平台、外包工作平台、医生助理平台；六个支持中心：护理中心、医疗支持中心、社区公共卫生服务中心、社区康复中心、妇幼保健中心、后勤保障中心；并且为医生助理建立助理操作平台。家庭责任医生在这六大支持中心的支持下，在助理医生的协助下，完成诊疗、随访、健康教育等工作1.3参考资料GP医生二期开发系统一用户需求说明书GP医生二期开发系统一数据库设计说明书2. 测试环境2.1硬件配置硬件CPU内存IP操作系统开发库服务器Intel(R)Core(TM)i3-

4、21OOM3G07WindowsXP2.2软件配置类型名称操作系统MicrosoftWindowsXP数据库软件SqlServer2008>PowerDesignerl2.5应用软件MyEclipse8.5测试管理软件TestDirector8.0配置工具Tomcat7.02.3网络环境测试阶段网络环境链接第一阶段公司内部环境测试51:8089/cdccommon/GPZL.html?UTP=gpitvs&UID=1205353&URR=1&GID=12051结论基本功能都己实现，测试目标己经完成。3. 测试概要

5、3.1测试时间2012年11月20日-一2013年5月16日3.2测试人员姓名角色职责李坤龄测试工程师编写测试用例、执行测试、编写测试报告和用户手册3.3测试方法黑盒测试根据测试过程的实际情况我们将测试分两阶段：第一阶段为单元测试，要求系统满足基本的功能需求；第二阶段为系统测试，要求模块与模块之间数据传递无误，数据正确，多机构与单机构间数据正确性，私有变量和公有变量测试，满足用户需求和项目的任务书中的内容。4, 测试结果4.1缺陷汇总4.1.1缺陷严重程度统计Defects-SummaryGraph图1缺陷严重程度严重缺陷中等缺陷轻微缺陷128168814.1.2缺陷类型分布Defects-S

6、ummaryGraph图2缺陷类型分布功能错误界面数据201135414.1.3缺陷修复率统计Defects-SummaryGraph图3缺陷修复率未修正修正修正后待确认27299494.1.4缺陷过程统计Defects-ProgressGraph Closed Delay Fixed0NewIOpenIReopen图4缺陷过程图各时间段产生的缺陷:DefectsSummaryGraph<5-单元刻试A：366(97%)需求评审单元测试系统测试236694.2缺陷的分析4.2.1缺陷严重程度分析上述图1显示的是缺陷严重程度分布图，从图中我们看到低级缺陷占了21%,中等缺陷占据了45%,高

7、等缺陷占了34%。中等的缺陷比例相对较多，BUG主要分布在中级缺陷上，其中缺陷较多是基本功能的实现上，因为客户需求变更或者某些模块实现较为复杂导致bug集中出现。ClosedFixedOpenReopen<total>|<1T氐754281W>1381810168862715128|<total>299492723774.2.2缺陷类型分布分析图2显示的是缺陷类型分布图。从图中我们可以看出测试过程中主要缺陷类型是功能缺陷，占据了53%。就缺陷类型而言，上述图中显示的比例并不正常，产生这种情况的主要原因有几点：1、因为项目进度的原因，测试人员对系统功能需求不够

8、了解，测试时间和力度还不够大；2、开发人员在提交测试前未做好走查工作；4.2.3缺陷修复率分析图3显示的是缺陷修复分析图，从图中我们可以看出该系统的缺陷修复率有79%,测试人员提出的bug都己被修改，极少数未修改和推迟的BUG。因该项目的客户需求变更，还没确定某些模块功能是否需要，需求正在调研中会导致一些bug延迟修改。4.2.4缺陷过程分析图4显示的是缺陷过程统计图。单元测试中产生了366个缺陷。该系统涉及到众多其他系统的业务所以接口也很多，业务及维护也比较复杂，所以在系统测试过程中产生了9个缺陷。4. 测试结论与建议5.1测试结论1. 测试执行充分，能保证基本功能实现。2. 测试目标已经完

9、成。3. 测试可以通过。5.2测试建议1、应给予充分的测试时间和资源。2、建议在提交测试之前，开发人员一定要进行代码走查工作，以减少单元测试中出现较多的功能性BUGo3、开发人员某些时段BUG堆积过多，建议今后项目中开发人员能尽快处理BUG,以避免影响测试人员的的测试进度的情况，测试人员也应合理安排测试和BUG确认的工作，避免BUG较长时间处于Fixed状态。5. 项目经理意见总体来说本项目的测试工作还算进行的比较顺利，测试人员认真负责，测试工作达到了系统验证和质量改进的目的。与其它项目比较而言我们的这个项目和测试组之间的磨合和协作也相对较好，大家都能够遵循对系统有益的目的而共同协调工作。好的测试需要建立在对系统的深入理解之上，测试人员要充分了解系统业务、理解系统需求读懂系统设计，本项目中测试人员对系统及业务从不了解到了解，从只能单纯运行单一功能到了解系统过程，测试人员对系统逐步加深理解之后的测试工作对项目的帮助逐步得以体现。由于测试资源匮乏，测试人员都