1 概述
1.1项目概述
讲述项目的基本信息
1.2参考与引用文献
*****V1.0版本测试用例
1.3测试工具
禅道
2.测试基本情况
2.1测试人员
负责人：**
测试人员：**，**
2.2测试时间
测试时间：*******
2.3测试环境
|
服务器类型 |
数量(台) |
CPU Count |
内存 |
操作系统 |
服务器软件 |
|
服务器 |
1 |
16 |
64 |
CentOS-7.2 |
Kubernetes,nginx,graphite,docker,mysql，docker zookeeper,redis,ffmpegmongodb |
2.4测试进度回顾
|
测试阶段 |
计划开始时间 |
计划结束时间 |
计划投入人员 |
计划完成天数 |
完成情况 |
备注 |
|
测试设计 |
|
|
||||
|
第一轮测试 |
|
|
|
|||
|
第二轮测试 |
|
|
|
2.5测试评价标准
测试用例在执行完毕产生通过和不通过两种结果，未通过的测试用例通常会生成一个缺陷，缺陷严重程度有5个等级：
² 致命缺陷：阻碍开发、测试工作；造成系统崩溃、死机、数据丢失；主要功能、基本模块丢失、一级菜单不能使用；系统悬挂无法操作
² 严重缺陷：功能未实现或功能设计与需求严重不符；数据数值计算出错；数据不能保存；程序接口调用出错等
² 普通缺陷：次要功能没有完全实现但不影响使用。如提示信息不太正确，用户界面差，模块功能部分失效，打印内容、格式错误等，错误导致了一个特性不能运行但可有一个替代方案
² 较小缺陷：表面化或微小的（提示信息不太准确友好、错别字、UI布局或罕见故障等），对功能几乎没有影响，对产品及属性仍可试用
² 建议：建设性的意见或建议
3.主要结论和关键风险
3.1测试总体结论
总体质量评估：中
是否建议上线：建议上线但有风险
详细说明：
该版本在本迭代测试阶段完成了********的系统测试、兼容测试，以及当前已解决bug的回归测试工作。
从版本的功能测试的总体情况来看，由于版本需求量较多，每一轮需求完成提测时，大部分没有执行冒烟用例，测试测出的问题多，并且有些会影响模块原有的功能，开发在修改bug过程中因项目需求多，时间紧张，未对bug进行影响分析，导致bug激活率高，整体提测质量不高。
由于整体的功能交付接近完成，最后一个版本开展了试用，同时开展了较大规模的公司内部测试，版本到目前为止，所有功能的累计执行覆盖率达到100%（所有已交付功能已完成覆盖验证），本版本中新增的bug相对较多，共计新增bug数**个，有效bug数**个，其中严重及以上的bug数***个；已关闭延期处理bug数***的，包括样式微调、样式兼容，有概率性问题（环境因素导致），目前经项目经理整体评估后对系统的影响相对较小，不影响产品功能正常使用，暂时延期后期优化。
从版本中发现bug所属的模块来看，本版本中新增问题大多集中在**和**模块，主要体现在功能模块的复杂性，需求多次变更，重复bug出现几率较高，需求传达理解上有偏差，很多功能场景依赖系统服务较高，服务有问题就会导致状态的同步，以及***数据的偏差，后期性能测试和安全测试后，优化不少功能点，已经稳定的功能模块会出现异常，导致模块问题数居高。
从回归问题的整体情况来看，本迭代中共回归bug数**个，其中存在***个延期处理的问题， bug回归过程，激活率高，解决一个bug会影响相关联功能，或者解决bug时只修改了部分功能，界面样式也有可能受影响，导致存在一定激活的问题，到目前为止，延期处理问题基本都是偶现性问题，或者建议、优化性的问题。
从目前版本的整体情况来看，遗留部分的问题对于系统的影响相对较小（问题本身影响小或出现几率非常小），但是部分问题一旦出现以后（如文档转换服务挂了，系统所有文档都转换不成功；异步处理的服务挂了，会导致很多依赖异步操作的功能失效，系统页面缓存每次发版需要手动清空页面缓存），将导致系统中功能出现异常，且影响范围较大，同时缺少有效的规避和提前识别措施，APP端延期处理bug很多都是非主流机型出现的一些界面样式问题，其中也会存在一定功能层面上的兼容问题，其他机型无法重现的问题，将导部分用非主流机型的用户，满意度会降低经综合评估，版本整体质量一般，建议持续优化这几项功能。
3.2遗留bug及风险
3.2.1 延期处理bug风险分析
Bug延期总数***个，其中严重**个 3.8%，普通**个 90.2% ，建议/优化**个 6%
风险分析：其中大多数界面样式、兼容、优化、偶现性等问题，经多方衡量确定，问题均不影响使用
4.测试执行情况分析
4.1测试执行情况
从需求理解到用例设计，需求理解后每个人进行业务反讲，避免理解不到位；用例规范编写方式统一，用例设计严格根据需求文档进行用例设计，有歧义的功能点，会逐一跟需求人员进行沟通确认，整个版本共进行了2个阶段性的系统功能测试，测试用例模块负责人进行执行。
4.2测试用例执行情况表格
根据项目实际情况和选用以下两种表格填写执行情况
|
测试模块 |
执行用例总数 |
通过用例总数 |
发现bug数 |
通过率 |
备注 |
|
** |
1119 |
1115 |
221 |
99.64% |
有延期解决不影响系统正常使用的功能； |
|
** |
|
||||
|
** |
|
||||
|
** |
|
||||
|
** |
|
||||
|
** |
|
||||
|
** |
|
|
|||
|
** |
|
|
|||
|
** |
|
|
|||
|
** |
|
|
|||
|
** |
|
|
|||
|
其他 |
/ |
/ |
102 |
|
|
|
总计 |
16362 |
16128 |
5939 |
98.57% |
|
测试阶段 |
总共bug数 |
有效bug数 |
严重及以上bug数 |
总共用例数 |
执行通过率 |
|
第一阶段 |
96 |
77 |
26 |
327 |
76% |
|
第二阶段 |
18 |
14 |
4 |
327 |
96% |
5.项目bug统计
5.1测试统计表
|
表格名称 |
测试统计表 |
表格编号 |
|||||||
|
项目名称 |
项目类别 |
||||||||
|
测试问题统计 |
|||||||||
|
自动生成数据 |
问题严重性 |
问题类型 |
问题状态 |
||||||
|
严重 |
|
代码错误 |
|
已解决 |
|
||||
|
致命 |
|
优化 |
|
不予解决 |
0 |
||||
|
普通 |
|
功能失效 |
0 |
设计如此 |
|
||||
|
较小 |
|
界面异常 |
0 |
外部原因 |
|
||||
|
建议 |
|
设计缺陷 |
|
无法重现 |
5 |
||||
|
|
需求分类 |
0 |
重复Bug |
0 |
|||||
|
数据异常 |
|
延期处理 |
8 |
||||||
|
其他 |
0 |
|
|||||||
|
总计 |
114 |
114 |
114 |
||||||
5.2测试统计图
版本Bug数量统计图
模块Bug数量统计图
Bug解决方案统计图
Bug严重程度统计图
Bug状态统计图
Bug类型统计图