质量分析报告(模板).doc

-<项目名称><项目名称>的一个版本内的质量情况。包含该版本经开发部发布后测试组的接受结果与原因、存在的问题描述与分析。(参照功能说明书)。。对于技术相关的名词和与多义词一定要注明清楚,以便阅读时不会产生歧义。、设计、测试用例、手册以及其他项目文档都是范围内可参考的文档。、行业指标、公司规范和质量手册等等。,包括测试的一些声明、测试范围、测试目的等等,主要是测试情况简介。(其他测试经理和质量人员关注部分)。归纳对测试项的评价,指明被测试项及其版本修订级别指出测试活动的发生环境,对于每个测试项如果存在测试计,划测试设计说明,测试规程说明,测试项传递报告,测试日志和测试事件报告等文件则可以引用它们。。例如:等价类划分、边界值、因果图,以及用这类方法提示:主要是黑盒测试,测试方法可以写上测试的重点和采用的测试模式,这样可以一目了然的知道是否遗漏了重要的测试点和关键块。工具为可选项,当使用到测试工具和相关工具时,要说明。注意要注明是自产还是厂商,版本号多少,在测试报告发布后要避免大多工具的版权问题。重点测试部分一定要保证有两种以上不同的用例设计方法。。提示:清单如下,如果系统/项目比较大,,。。,最好区分测试文档和活动的时间。数据可供过程度量使用。例如对XXX子系统/子功能子系统/子模块实际开始时间实际结束时间总工时/,属于问题数量(包含确认通过问题数量、确认未通过问题数量、以后版本修改数量、需求问题数量、不修改问题数量),不属于问题数量。a、合格率(以案例数)=测试通过案例数/使用测试案例总数;b、合格率(以联机交易数)=测试通过联机交易数/需要测试联机交易总数;c、合格率(以批量报表数)=测试通过报表数/需要测试报表总数;d、测试完成率=使用案例数/设计案例总数;若测试完成率≠100%时,须文字加以说明e、问题更正率=问题修改确认通过数/出现问题案例总数;描述系统的实现能力、缺陷和限制、建议和评价;,通常情况下要达到100%的目标。指出需求/功能(或编号)测试类型是否通过备注根