报告模板_测试报告模板 - CSDN
精华内容
参与话题
  • 自主开发类项目技术报告,分五部分。1、国内外情况和发展方向;2、项目目标和内容;3、系统功能设定;等等
  • 测试报告模板范例

    万次阅读 2018-12-18 16:47:01
    1. 简介1.1 编写目的本文档用于记录测试过程,总结各轮次的测试情况,分析测试数据,归纳测试工作进行过程中暴露的问题与遗留的风险,给出相应的测试建议以供后续项目参考。1.2 项目背景xx需要一个拥有真实用户的...

    1. 简介

    1.1 编写目的

    本文档用于记录测试过程,总结各轮次的测试情况,分析测试数据,归纳测试工作进行过程中暴露的问题与遗留的风险,给出相应的测试建议以供后续项目参考。

    1.2 项目背景

    xx需要一个拥有真实用户的社区化产品,通过真实高信任度用户关系的建立,提高用户粘性,提升活跃会员数,带来长效的增长。在此背景下,以真实用户为基础的社区应运而生。主要具有以下5点意义:

    1. 提高社区活跃会员数

    2. 提高用户粘度

    3. 建立真实(和用户的社区身份相一致)的多维用户信息

    4. 建立高信任度的用户关系

    5. 达到真实可信用户关系中的用户之间的传播效应

    1.3 定义、首字母缩写词和缩略语

    1.4 参考资料

    各轮系统测试阶段总结

    2. 测试概要

    整个xx项目的测试经历了xx-1.0与xx-1.1两个阶段,共经历了1轮集成测试、6轮冒烟测试和7轮系统测试和1轮上线跟踪测试。整个测试过程中累计执行用例8100条,发现缺陷1026个。截至xx-1.1第四系统测试结束,所发现的高权重问题已得到修复和验证。

    2.1 测试时间

    整个xx项目的测试时间从xx年2月18日开始,到xx年3月27日上线止,期间各阶段工作情况如下:

    工作阶段

    开始时间

    结束时间

    工作量

    (人日)


    xx-1.0

    xx-1.0需求确认、评审、测试用例编写&评审

    2008年2月18日

    2008年2月25日

    30

    xx-1.0集成测试

    2008年2月22日19:30

    2008年2月23日 1:00

    4


    xx-1.0第一轮系统测试之冒烟测试一

    2008年2月26日 10:30

    2008年2月26日 17:00

    5


    xx-1.0第一轮系统测试之冒烟测试二

    2008年2月29日 13:00

    2008年2月29日 19:00

    4.5


    xx-1.0第一轮系统测试之冒烟测试三

    2008年3月3日 10:00

    2008年3月3日 16:00

    4.5


    xx-1.0第一轮系统测试

    2008年3月5日 15:00

    2008年3月8日 16:30

    36


    xx-1.0第二轮系统测试

    2008年3月10日 10:30

    2008年3月11日 19:00

    20


    xx-1.0第三轮系统测试

    2008年3月11日 21:00

    2008年3月11日 22:00

    1


    xx-1.1

    xx-1.1需求评审、测试用例编写&评审

    2008年3月12日

    2008年3月17日

    15

    xx-1.1第一轮系统测试之冒烟测试

    2008年3月18日 10:00

    2008年3月18日 15:30

    4


    xx-1.1第一轮系统测试

    2008年3月19日 10:00

    2008年3月21日 18:00

    20


    xx-1.1第二轮系统测试之冒烟测试

    2008年3月22日 16:00

    2008年3月22日 18:30

    1.5


    xx-1.1第二轮系统测试

    2008年3月22日 16:00

    2008年3月24日 16:00

    18


    xx-1.1第三轮系统测试

    2008年3月25日 10:00

    2008年3月25日 17:00

    6.25


    xx-1.1第四轮系统测试

    2008年3月25日 21:30

    2008年3月26日 1:30

    4


    xx-1.1上线跟踪测试

    2008年3月27日6:30

    2008年3月27日12:00

    4.5


    合计

    178




    2.2 测试范围

    本次测试覆盖的范围包括:功能测试、兼容性测试、接口测试、数据迁移测试、性能测试、安全性测试和品质监控。以下分别对功能测试、兼容性测试、接口测试、数据迁移测试、性能测试和安全性测试进行说明。

    功能测试

    xx-1.1在xx-1.0基础上更新的主要功能如下:

    No.

    模块

    权重

    1

    通行证注册、登录,及个人社区产品的开通

    A

    2

    系统消息

    A

    3

    订阅

    A

    4

    即时聊天

    B

    5

    名片

    B

    6

    更新提示

    B

    7

    Feed改造

    B

    8

    UIC 改造

    B

    9

    报错页

    B

    10

    xx-1.0遗留到xx-1.1的缺陷

    C

    11

    各个产品针对xx-1.1的改造

    C

    xx-1.0 包括的主要功能如下:

    No.

    模块

    权重

    1

    登录注册开通

    C

    2

    导航

    C

    3

    Profile

    A

    4

    Account帐户管理

    B

    5

    Privac隐私设置

    B

    6

    Feed

    A

    7

    个人资料

    B

    8

    Space-q

    B

    9

    Space-bbs

    B

    10

    Space-bar

    B

    11

    Firend好友

    A

    12

    Vistor访客

    A

    13

    纸条箱

    A

    14

    留言

    A

    15

    UIC(头像、昵称)

    A

    16

    帮助

    C

    17

    各个产品针对xx-1.0的改造

    C

    数据迁移测试

    No.

    关注项

    权重

    1

    博客播客相册圈子论坛与Space的用户头像切换

    A

    2

    博客老用户访客数据为Space的提供

    A

    3

    博客播客相册圈子论坛老用户好友数据与Space的整合

    A

    4

    博客播客相册圈子论坛老用户纸条箱数据与Space的整合

    A

    5

    圈子老用户个人资料数据与Space的整合

    A

    6

    博客播客圈子老用户留言数据与Space的整合

    A

    接口测试

    No.

    关注项

    权重

    1

    各产品与Space的feed功能的接口测试

    A

    兼容性测试

    No.

    关注项

    权重

    1

    IE6

    A

    2

    IE7

    B

    3

    Firefox2.0

    C

    性能测试

    参见SVN中的性能测试报告。

    安全性测试

    整个xx测试过程中先后进行了三轮安全性测试,发现了2个影响较严重的安全性问题,且都已得到修复和验证。

    2.3 测试版本

    下表显示了各轮次测试版本和对应测试范围的分配情况:

    2.4 测试用例

    根据需求文档,测试人员编写和内审了测试用例,为xx项目共计编写用例3558条,累计执行用例8100条。

    2.5 测试策略

    xx-1.0测试策略

    1. 测试类型:按阶段划分定义为集成测试和系统测试。

    2. 集成测试阶段进行了一轮集成测试,主要以需求挖掘、分析、确认和寻找实现与需求不一致为主要目标

    3. 系统测试阶段分三轮进行,基本策略如下:

    第一轮为覆盖性测试,测试范围覆盖以上描述的所有范围,关注所有级别的bug;

    第二轮对权重为A、B的模块进行功能测试、兼容性测试,权重为C的模块进行冒烟测试,回归测试所有已修复的bug;

    第三轮对权重为A的模块进行功能测试、兼容性测试,对权重为B、C的模块进行冒烟测试,回归测试所有待解决的bug,及已关闭的高优先级bug。

    每轮测试开始前都进行快速的冒烟测试,通过冒烟确信系统可测时进入下一轮系统测试。

    数据迁移测试、接口测试只在第一轮进行。

    4. 缺陷评估:每轮测试结束后都组织开发工程师、测试工程师、产品工程师等共同评估产品缺陷,评估内容包括缺陷解决方案、是否涉及需求变更、下一轮开始时间及是否可以结束测试等。

    xx-1.1测试策略

    1. 测试类型:按阶段划分定义为系统测试。

    2. 系统测试分四个轮次进行,基本策略如下:

    第一轮为覆盖性测试,测试范围覆盖以上描述的所有范围,关注所有级别的bug;

    第二轮对权重为A、B的模块进行功能测试、兼容性测试,权重为C的模块进行冒烟测试,回归测试所有已修复的bug;对系统进行性能测试。

    第三、四轮对权重为A的模块进行功能测试、兼容性测试,对权重为B、C的模块进行冒烟测试,回归测试所有待解决的bug,及已关闭的高优先级bug;

    每轮测试开始前都进行快速的冒烟测试,通过冒烟确信系统可测时进入下一轮系统测试。

    数据迁移测试、接口测试只在第一轮进行。

    3. 缺陷评估:每轮测试结束后都组织开发工程师、测试工程师、产品工程师、QA等共同评估产品缺陷,评估内容包括缺陷解决方案、是否涉及需求变更、下一轮开始时间及是否可以结束测试等。

    3. 结果分析

    整个xx测试过程中累计发现有效缺陷1026个,其中A级缺陷3个,B级21个,C级800个,D级169个,E级33个。经项目组成员评估,到xx-1.1发布止遗留缺陷51个,其余975个缺陷均已修复且全部验证通过。下面分别从xx-1.0和xx-1.1两个阶段、从不同角度对缺陷进行分析。

    3.1 缺陷趋势

    xx-1.0

    整个测试过程中累计发现缺陷734个,各轮次缺陷分布情况如下表。

    下图显示了xx-1.0测试过程中缺陷的发展趋势:

    项目测试报告模板

    xx-1.1

    整个测试过程中累计发现缺陷292个,各轮次缺陷分布情况如下表。

    下图显示了xx-1.1测试过程中缺陷的发展趋势:

    项目测试报告模板

    从缺陷趋势图中可以看出,xx-1.0和xx-1.1两个测试阶段,缺陷均随着测试过程的推进呈现收敛趋势,这符合测试缺陷的发展规律,证明测试计划和策略是可靠有效的。

    3.2 缺陷优先级分布

    xx-1.0

    每轮次各级别缺陷分布情况如下:

    项目测试报告模板

    xx-1.1

    每轮次各级别缺陷分布情况如下:

    项目测试报告模板

    整个xx项目测试过程种中发现的C级以上(包括C级)缺陷824个,占总缺陷数的80.31%,这说明系统在测试过程中处于不稳定状态,存在大量较为严重的问题,但随着测试过程的推进,高优先级问题又逐渐减少,整个系统趋于稳定。

    3.3 缺陷按模块分布

    下表显示了整个xx测试过程中发现缺陷在各模块中的分布情况

    模块

    缺陷数

    %

    需求0221

    223

    21.73%

    好友

    101

    9.84%

    个人资料

    75

    7.31%

    Feed

    74

    7.21%

    登录 注册 开通

    61

    5.95%

    Space-blog

    54

    5.26%

    纸条

    53

    5.17%

    Space-q

    52

    5.07%

    帐户管理

    38

    3.70%

    Space-bbs

    35

    3.41%

    Space-gallery

    31

    3.02%

    UIC

    31

    3.02%

    留言

    31

    3.02%

    Space-bar

    25

    2.44%

    系统消息

    25

    2.44%

    其它

    21

    2.05%

    Space-vblog

    20

    1.95%

    名片

    17

    1.66%

    订阅

    17

    1.66%

    访客

    15

    1.46%

    导航

    11

    1.07%

    隐私设置

    10

    0.97%

    Space管理后台

    4

    0.39%

    安全

    2

    0.19%

    合计

    1026


    从下图中可以看出各模块缺陷的分布趋势:

    项目测试报告模板

    从以上缺陷分布情况看,所有缺陷中有近30%是和产品需求相关的,诸如需求定义欠明确、需求描述有歧义、需求没有定义、实现和需求不一致等。

    3.4 重开缺陷情况

    从上表可以看出整个Space测试过程中,各轮验证缺陷的重开比率都偏高,这是我们后续项目中需要关注和提高的地方。

    3.5 遗留缺陷情况

    到xx-1.1发布止,整个Space项目遗留缺陷51个,且这些缺陷均通过PDT相关成员评估后确信可以遗留,待后续版本规划处理。具体缺陷信息此处略去。

    3.6 上线跟踪测试结果

    xx-1.1于3月27日7:00上线后,我们在当日的7:00-12:00进行了集中跟踪测试,且在此之后安排有2名测试工程师,每天用一些时间跟踪上线情况、客服反馈问题的最新动态。截止4月2日上午11:00上线跟踪测试结果是:累计缺陷40个,且都是C级以下。其中属需求相关问题5个,因上线后环境差异导致问题35个,开放中缺陷4个,已关闭缺陷16个,已解决待验证缺陷20个。

    4. 结论&问题&建议

    4.1 测试结论

    1. 经过前后两个阶段的多轮测试,虽遗留了一些缺陷没有解决,但系统功能已趋于稳定,且项目确定的范围、策略和计划均已实现,项目测试可以结束、xx-1.1可以上线。

    2. 通过测试觉得产品在用户体验方面有待后续版本进一步改进,不排除用户在使用该产品时有“晕”的感觉。

    4.2 呈现的问题

    1. 需求问题。特别是xx-1.0项目需求,虽然陆续看到了好多需求文档,但这些文档给人的感觉是:需求分析不完整、需求描述不清晰,需求文档的逻辑性、可读性、可实现性、可测试性比较差,需求的歧义性较大。从而感觉在整个xx-1.0测试过程中不断地在挖掘需求、确认需求、变更需求和评审需求。xx-1.1的项目需求有了很大改观,xx本身需求经过和收集、分析、确认和评审的过程,但对各接口产品的需求仍然没有进行统一的分析、确认和评审,这部分需求的歧义性较大且变更较多,整个需求文档的可读性、可测试性、完整性和清晰性仍然较差。

    2. 变更控制问题。这在xx-1.0的测试过程中体现的比较明显,如项目需求的变更、项目责任人的变更、项目计划的变更等。xx-1.0整个测试过程中一直在确认和变更需求,且需求变更的机制没有规约,一个会议、一封mail或是一个口头传达就可能变更需求。xx-1.1测试过程中这一问题得到了较好的改进,但变更控制规约的实施欠佳。所有的需求变更均没有及时很好的更新至需求文档,xx-1.0体现的更为明显。

    3. 版本控制问题。xx-1.0测试过程中没能进行版本管理;xx-1.1测试过程中对xx本身的代码进行了版本管理,各接口产品的代码均由各技术负责人进行管理,在这期间出现过代码覆盖的情况、代码忘记上传或遗漏部署的情况。难以保证每轮测试版本的清晰、和发布版本与测试版本的一致性。

    4. 测试环境问题。xx-1.1测试期间测试环境和开发环境没能很好的分离,导致测试和开发修复缺陷不能并行;测试期间有开发工程师直接在测试环境上修复缺陷和修改测试环境的情况;测试环境不稳定,如hosts设置不正确等。

    5. 项目计划欠明确、人员职责欠清晰。

    4.3 测试建议

    1. 遗留缺陷。建议在xx-1.1上线后以patch方式,或在后续版本中解决遗留缺陷,以提升产品的稳定性和用户体验。

    2. 需求建议。不论是xx本身还是各接口产品,建议进一步加强需求收集、分析、确认和评审过程,进一步提升需求文档的质量:减少需求的歧义性,提升需求的完整性、描述的清晰性、一致性、可读性、可实现性和可测试性。同时建议在后续项目中能对设计文档(如UI/UE等)进行评审,以增强产品的使用性、提升用户体验。

    3. 变更控制。建议在后续项目中进一步加强变更控制策略和规约制定,并强化变更控制规约的执行。不怕变更,关键要控制好变更的时机和策略。

    4. 版本控制。加强xx本身,特别是各接口产品的版本控制策略,以保证测试版本的清晰性、发布/上线版本和最终测试版本的一致性。

    5. 测试环境。期望在后续项目中xx及各接口产品的测试环境和开发环境完全分开,或阶段性完全独立,且各部分环境有专门的接口人负责,在测试期间严格禁止在测试环境上修复缺陷或更改环境配置(如确实需要更改配置,请提前通知测试及其它相关负责人)。以减少因此带来的沟通、反复侦测的成本。

    6. 项目管理。主要是建议加强项目的计划性,诸如:进度计划、人力资源计划、风险预防机制等,这也将更利于项目成员间高效的配合:大家能更适时的、更合理的制定各自工作计划,也更清楚到什么时候我会输出什么、我将配合他人做些什么。减少项目进行过程中的紧张和慌乱、项目也变得更加易控和可控。


    展开全文
  • 测试报告模板

    万次阅读 多人点赞 2018-01-04 23:04:08
    1. 简介 1.1 编写目的 本文档用于记录测试过程,总结各轮次的测试情况,分析测试数据,归纳测试工作进行过程中暴露的问题与遗留的风险,给出相应的测试建议以供后续项目参考。 1.2 项目背景 ...

    1. 简介

    1.1 编写目的

    本文档用于记录测试过程,总结各轮次的测试情况,分析测试数据,归纳测试工作进行过程中暴露的问题与遗留的风险,给出相应的测试建议以供后续项目参考。

    1.2 项目背景

    xx需要一个拥有真实用户的社区化产品,通过真实高信任度用户关系的建立,提高用户粘性,提升活跃会员数,带来长效的增长。在此背景下,以真实用户为基础的社区应运而生。主要具有以下5点意义:

    1. 提高社区活跃会员数

    2. 提高用户粘度

    3. 建立真实(和用户的社区身份相一致)的多维用户信息

    4. 建立高信任度的用户关系

    5. 达到真实可信用户关系中的用户之间的传播效应

    1.3 定义、首字母缩写词和缩略语

    1.4 参考资料

    各轮系统测试阶段总结

    2. 测试概要

    整个xx项目的测试经历了xx-1.0与xx-1.1两个阶段,共经历了1轮集成测试、6轮冒烟测试和7轮系统测试和1轮上线跟踪测试。整个测试过程中累计执行用例8100条,发现缺陷1026个。截至xx-1.1第四系统测试结束,所发现的高权重问题已得到修复和验证。

    2.1 测试时间

    整个xx项目的测试时间从xx年2月18日开始,到xx年3月27日上线止,期间各阶段工作情况如下:

    工作阶段

    开始时间

    结束时间

    工作量

    (人日)


    xx-1.0

    xx-1.0需求确认、评审、测试用例编写&评审

    2008年2月18日

    2008年2月25日

    30

    xx-1.0集成测试

    2008年2月22日19:30

    2008年2月23日 1:00

    4


    xx-1.0第一轮系统测试之冒烟测试一

    2008年2月26日 10:30

    2008年2月26日 17:00

    5


    xx-1.0第一轮系统测试之冒烟测试二

    2008年2月29日 13:00

    2008年2月29日 19:00

    4.5


    xx-1.0第一轮系统测试之冒烟测试三

    2008年3月3日 10:00

    2008年3月3日 16:00

    4.5


    xx-1.0第一轮系统测试

    2008年3月5日 15:00

    2008年3月8日 16:30

    36


    xx-1.0第二轮系统测试

    2008年3月10日 10:30

    2008年3月11日 19:00

    20


    xx-1.0第三轮系统测试

    2008年3月11日 21:00

    2008年3月11日 22:00

    1


    xx-1.1

    xx-1.1需求评审、测试用例编写&评审

    2008年3月12日

    2008年3月17日

    15

    xx-1.1第一轮系统测试之冒烟测试

    2008年3月18日 10:00

    2008年3月18日 15:30

    4


    xx-1.1第一轮系统测试

    2008年3月19日 10:00

    2008年3月21日 18:00

    20


    xx-1.1第二轮系统测试之冒烟测试

    2008年3月22日 16:00

    2008年3月22日 18:30

    1.5


    xx-1.1第二轮系统测试

    2008年3月22日 16:00

    2008年3月24日 16:00

    18


    xx-1.1第三轮系统测试

    2008年3月25日 10:00

    2008年3月25日 17:00

    6.25


    xx-1.1第四轮系统测试

    2008年3月25日 21:30

    2008年3月26日 1:30

    4


    xx-1.1上线跟踪测试

    2008年3月27日6:30

    2008年3月27日12:00

    4.5


    合计

    178




    2.2 测试范围

    本次测试覆盖的范围包括:功能测试、兼容性测试、接口测试、数据迁移测试、性能测试、安全性测试和品质监控。以下分别对功能测试、兼容性测试、接口测试、数据迁移测试、性能测试和安全性测试进行说明。

    功能测试

    xx-1.1在xx-1.0基础上更新的主要功能如下:

    No.

    模块

    权重

    1

    通行证注册、登录,及个人社区产品的开通

    A

    2

    系统消息

    A

    3

    订阅

    A

    4

    即时聊天

    B

    5

    名片

    B

    6

    更新提示

    B

    7

    Feed改造

    B

    8

    UIC 改造

    B

    9

    报错页

    B

    10

    xx-1.0遗留到xx-1.1的缺陷

    C

    11

    各个产品针对xx-1.1的改造

    C

    xx-1.0 包括的主要功能如下:

    No.

    模块

    权重

    1

    登录注册开通

    C

    2

    导航

    C

    3

    Profile

    A

    4

    Account帐户管理

    B

    5

    Privac隐私设置

    B

    6

    Feed

    A

    7

    个人资料

    B

    8

    Space-q

    B

    9

    Space-bbs

    B

    10

    Space-bar

    B

    11

    Firend好友

    A

    12

    Vistor访客

    A

    13

    纸条箱

    A

    14

    留言

    A

    15

    UIC(头像、昵称)

    A

    16

    帮助

    C

    17

    各个产品针对xx-1.0的改造

    C

    数据迁移测试

    No.

    关注项

    权重

    1

    博客播客相册圈子论坛与Space的用户头像切换

    A

    2

    博客老用户访客数据为Space的提供

    A

    3

    博客播客相册圈子论坛老用户好友数据与Space的整合

    A

    4

    博客播客相册圈子论坛老用户纸条箱数据与Space的整合

    A

    5

    圈子老用户个人资料数据与Space的整合

    A

    6

    博客播客圈子老用户留言数据与Space的整合

    A

    接口测试

    No.

    关注项

    权重

    1

    各产品与Space的feed功能的接口测试

    A

    兼容性测试

    No.

    关注项

    权重

    1

    IE6

    A

    2

    IE7

    B

    3

    Firefox2.0

    C

    性能测试

    参见SVN中的性能测试报告。

    安全性测试

    整个xx测试过程中先后进行了三轮安全性测试,发现了2个影响较严重的安全性问题,且都已得到修复和验证。

    2.3 测试版本

    下表显示了各轮次测试版本和对应测试范围的分配情况:

    2.4 测试用例

    根据需求文档,测试人员编写和内审了测试用例,为xx项目共计编写用例3558条,累计执行用例8100条。

    2.5 测试策略

    xx-1.0测试策略

    1. 测试类型:按阶段划分定义为集成测试和系统测试。

    2. 集成测试阶段进行了一轮集成测试,主要以需求挖掘、分析、确认和寻找实现与需求不一致为主要目标

    3. 系统测试阶段分三轮进行,基本策略如下:

    第一轮为覆盖性测试,测试范围覆盖以上描述的所有范围,关注所有级别的bug;

    第二轮对权重为A、B的模块进行功能测试、兼容性测试,权重为C的模块进行冒烟测试,回归测试所有已修复的bug;

    第三轮对权重为A的模块进行功能测试、兼容性测试,对权重为B、C的模块进行冒烟测试,回归测试所有待解决的bug,及已关闭的高优先级bug。

    每轮测试开始前都进行快速的冒烟测试,通过冒烟确信系统可测时进入下一轮系统测试。

    数据迁移测试、接口测试只在第一轮进行。

    4. 缺陷评估:每轮测试结束后都组织开发工程师、测试工程师、产品工程师等共同评估产品缺陷,评估内容包括缺陷解决方案、是否涉及需求变更、下一轮开始时间及是否可以结束测试等。

    xx-1.1测试策略

    1. 测试类型:按阶段划分定义为系统测试。

    2. 系统测试分四个轮次进行,基本策略如下:

    第一轮为覆盖性测试,测试范围覆盖以上描述的所有范围,关注所有级别的bug;

    第二轮对权重为A、B的模块进行功能测试、兼容性测试,权重为C的模块进行冒烟测试,回归测试所有已修复的bug;对系统进行性能测试。

    第三、四轮对权重为A的模块进行功能测试、兼容性测试,对权重为B、C的模块进行冒烟测试,回归测试所有待解决的bug,及已关闭的高优先级bug;

    每轮测试开始前都进行快速的冒烟测试,通过冒烟确信系统可测时进入下一轮系统测试。

    数据迁移测试、接口测试只在第一轮进行。

    3. 缺陷评估:每轮测试结束后都组织开发工程师、测试工程师、产品工程师、QA等共同评估产品缺陷,评估内容包括缺陷解决方案、是否涉及需求变更、下一轮开始时间及是否可以结束测试等。

    3. 结果分析

    整个xx测试过程中累计发现有效缺陷1026个,其中A级缺陷3个,B级21个,C级800个,D级169个,E级33个。经项目组成员评估,到xx-1.1发布止遗留缺陷51个,其余975个缺陷均已修复且全部验证通过。下面分别从xx-1.0和xx-1.1两个阶段、从不同角度对缺陷进行分析。

    3.1 缺陷趋势

    xx-1.0

    整个测试过程中累计发现缺陷734个,各轮次缺陷分布情况如下表。

    下图显示了xx-1.0测试过程中缺陷的发展趋势:

    项目测试报告模板

    xx-1.1

    整个测试过程中累计发现缺陷292个,各轮次缺陷分布情况如下表。

    下图显示了xx-1.1测试过程中缺陷的发展趋势:

    项目测试报告模板

    从缺陷趋势图中可以看出,xx-1.0和xx-1.1两个测试阶段,缺陷均随着测试过程的推进呈现收敛趋势,这符合测试缺陷的发展规律,证明测试计划和策略是可靠有效的。

    3.2 缺陷优先级分布

    xx-1.0

    每轮次各级别缺陷分布情况如下:

    项目测试报告模板

    xx-1.1

    每轮次各级别缺陷分布情况如下:

    项目测试报告模板

    整个xx项目测试过程种中发现的C级以上(包括C级)缺陷824个,占总缺陷数的80.31%,这说明系统在测试过程中处于不稳定状态,存在大量较为严重的问题,但随着测试过程的推进,高优先级问题又逐渐减少,整个系统趋于稳定。

    3.3 缺陷按模块分布

    下表显示了整个xx测试过程中发现缺陷在各模块中的分布情况

    模块

    缺陷数

    %

    需求0221

    223

    21.73%

    好友

    101

    9.84%

    个人资料

    75

    7.31%

    Feed

    74

    7.21%

    登录 注册 开通

    61

    5.95%

    Space-blog

    54

    5.26%

    纸条

    53

    5.17%

    Space-q

    52

    5.07%

    帐户管理

    38

    3.70%

    Space-bbs

    35

    3.41%

    Space-gallery

    31

    3.02%

    UIC

    31

    3.02%

    留言

    31

    3.02%

    Space-bar

    25

    2.44%

    系统消息

    25

    2.44%

    其它

    21

    2.05%

    Space-vblog

    20

    1.95%

    名片

    17

    1.66%

    订阅

    17

    1.66%

    访客

    15

    1.46%

    导航

    11

    1.07%

    隐私设置

    10

    0.97%

    Space管理后台

    4

    0.39%

    安全

    2

    0.19%

    合计

    1026

     

    从下图中可以看出各模块缺陷的分布趋势:

    项目测试报告模板

    从以上缺陷分布情况看,所有缺陷中有近30%是和产品需求相关的,诸如需求定义欠明确、需求描述有歧义、需求没有定义、实现和需求不一致等。

    3.4 重开缺陷情况

    从上表可以看出整个Space测试过程中,各轮验证缺陷的重开比率都偏高,这是我们后续项目中需要关注和提高的地方。

    3.5 遗留缺陷情况

    到xx-1.1发布止,整个Space项目遗留缺陷51个,且这些缺陷均通过PDT相关成员评估后确信可以遗留,待后续版本规划处理。具体缺陷信息此处略去。

    3.6 上线跟踪测试结果

    xx-1.1于3月27日7:00上线后,我们在当日的7:00-12:00进行了集中跟踪测试,且在此之后安排有2名测试工程师,每天用一些时间跟踪上线情况、客服反馈问题的最新动态。截止4月2日上午11:00上线跟踪测试结果是:累计缺陷40个,且都是C级以下。其中属需求相关问题5个,因上线后环境差异导致问题35个,开放中缺陷4个,已关闭缺陷16个,已解决待验证缺陷20个。

    4. 结论&问题&建议

    4.1 测试结论

    1. 经过前后两个阶段的多轮测试,虽遗留了一些缺陷没有解决,但系统功能已趋于稳定,且项目确定的范围、策略和计划均已实现,项目测试可以结束、xx-1.1可以上线。

    2. 通过测试觉得产品在用户体验方面有待后续版本进一步改进,不排除用户在使用该产品时有“晕”的感觉。

    4.2 呈现的问题

    1. 需求问题。特别是xx-1.0项目需求,虽然陆续看到了好多需求文档,但这些文档给人的感觉是:需求分析不完整、需求描述不清晰,需求文档的逻辑性、可读性、可实现性、可测试性比较差,需求的歧义性较大。从而感觉在整个xx-1.0测试过程中不断地在挖掘需求、确认需求、变更需求和评审需求。xx-1.1的项目需求有了很大改观,xx本身需求经过和收集、分析、确认和评审的过程,但对各接口产品的需求仍然没有进行统一的分析、确认和评审,这部分需求的歧义性较大且变更较多,整个需求文档的可读性、可测试性、完整性和清晰性仍然较差。

    2. 变更控制问题。这在xx-1.0的测试过程中体现的比较明显,如项目需求的变更、项目责任人的变更、项目计划的变更等。xx-1.0整个测试过程中一直在确认和变更需求,且需求变更的机制没有规约,一个会议、一封mail或是一个口头传达就可能变更需求。xx-1.1测试过程中这一问题得到了较好的改进,但变更控制规约的实施欠佳。所有的需求变更均没有及时很好的更新至需求文档,xx-1.0体现的更为明显。

    3. 版本控制问题。xx-1.0测试过程中没能进行版本管理;xx-1.1测试过程中对xx本身的代码进行了版本管理,各接口产品的代码均由各技术负责人进行管理,在这期间出现过代码覆盖的情况、代码忘记上传或遗漏部署的情况。难以保证每轮测试版本的清晰、和发布版本与测试版本的一致性。

    4. 测试环境问题。xx-1.1测试期间测试环境和开发环境没能很好的分离,导致测试和开发修复缺陷不能并行;测试期间有开发工程师直接在测试环境上修复缺陷和修改测试环境的情况;测试环境不稳定,如hosts设置不正确等。

    5. 项目计划欠明确、人员职责欠清晰。

    4.3 测试建议

    1. 遗留缺陷。建议在xx-1.1上线后以patch方式,或在后续版本中解决遗留缺陷,以提升产品的稳定性和用户体验。

    2. 需求建议。不论是xx本身还是各接口产品,建议进一步加强需求收集、分析、确认和评审过程,进一步提升需求文档的质量:减少需求的歧义性,提升需求的完整性、描述的清晰性、一致性、可读性、可实现性和可测试性。同时建议在后续项目中能对设计文档(如UI/UE等)进行评审,以增强产品的使用性、提升用户体验。

    3. 变更控制。建议在后续项目中进一步加强变更控制策略和规约制定,并强化变更控制规约的执行。不怕变更,关键要控制好变更的时机和策略。

    4. 版本控制。加强xx本身,特别是各接口产品的版本控制策略,以保证测试版本的清晰性、发布/上线版本和最终测试版本的一致性。

    5. 测试环境。期望在后续项目中xx及各接口产品的测试环境和开发环境完全分开,或阶段性完全独立,且各部分环境有专门的接口人负责,在测试期间严格禁止在测试环境上修复缺陷或更改环境配置(如确实需要更改配置,请提前通知测试及其它相关负责人)。以减少因此带来的沟通、反复侦测的成本。

    6. 项目管理。主要是建议加强项目的计划性,诸如:进度计划、人力资源计划、风险预防机制等,这也将更利于项目成员间高效的配合:大家能更适时的、更合理的制定各自工作计划,也更清楚到什么时候我会输出什么、我将配合他人做些什么。减少项目进行过程中的紧张和慌乱、项目也变得更加易控和可控。


    展开全文
  • 软件项目需求分析报告模板

    万次阅读 多人点赞 2018-12-25 09:42:56
    项目组讨论总结了一套需求报告模板,分享一下。 除了标题、修订记录、目录以外,报告主体分为六个章节,分别是引言、需求概述、分析场景、功能实例化、其它说明以及附录。 下面具体描述各部分的写法。 详述 引言 ...

    简述

    项目组讨论总结了一套需求报告的模板,分享一下。
    除了标题、修订记录、目录以外,报告主体分为六个章节,分别是引言、需求概述、分析场景、功能实例化、其它说明以及附录。
    下面具体描述各部分的写法。

    详述

    1. 引言
      1.1 编写目的
      对产品或项目进行定义。如果这个软件需求规格说明只与整个系统的一部分有关系,那么只定义文档中要说明的部分或子系统。
      1.2 预期读者和阅读建议
      预期参考人员包括开发人员、测试人员、项目管理人员、质量管理人员、研发部门经理和需要阅读本报告的高层经理。
      1.3 术语定义
      中英文数据及简写。
      1.4 参考资料
    2. 需求概述
      2.1 原始需求
      需求最原始的描述、表达或定义,划定系统的边界。
      2.2 找用户
      找到系统之外,透过系统边界,与系统进行有意义交互的任何事物(可以是人、设备、系统),是系统行为和流程的触发者,并分析用户需要该系统解决的问题或达到的具体的能力,确认用户对该系统的AC(验收准则)和IFD(接口定义)。
      2.3 问目的
      思考用户提出该诉求的隐藏目的和动机,可深度理解需求,有效减少因用户表述不准确而不断变更需求,从而给需求开发带来巨大的资源浪费。
    3. 分析场景
      3.1 原系统分析
      对现有系统(包括自动或人工)进行简要分析,如果是全新开发的模块,可以直接写全新开发等。
      3.2 业务流程图
      描述实际业务的过程和特点,即业务建模,可以通过简易流程图,时序图等表达。
    4. 功能实例化
      依照面对的需求,经过以上的分析,拆成一个或几个相对独立的功能(主要目的是为了开发和测试形成条理性),并尽可能总结各个功能的验收准则。
      4.1 子模块名称
      4.1.1 子模块功能描述
      4.1.2 子模块验收准则
    5. 其它说明
      性能、权限、安全以及一些特殊的情况。
    6. 附录
      对本需求有说明意义的资料:协议、文档、数据、表格、样张等。

    写在最后

    软件项目的需求文档根据项目的甲方有不同的格式和变化,上文的模板主要是内部协助开发测试的模板,希望可以有一定的借鉴意义。

    展开全文
  • 用户体验报告模板

    千次阅读 2015-09-23 16:52:22
    先把用户体验报告模板准备好。 概览: 体验环境 硬件操作系统产品版本 产品目标和背景 产品产生的背景产品的目标和用户群 用户特征(通过百度指数、媒体等获取) 年龄段性别地域职业等(根据产品...
           由于工作中涉及的工作大多是小功能以及一些产品的修修补补,所以从今天起,尽量每天都写点其他产品的用户体验、竞品分析,画点原型,学点技术。先把用户体验报告的模板准备好。

    概览:
    1. 体验环境
      • 硬件
      • 操作系统
      • 产品版本
    2. 产品目标和背景
      • 产品产生的背景
      • 产品的目标和用户群
    3. 用户特征(通过百度指数、媒体等获取)
      • 年龄段
      • 性别
      • 地域
      • 职业等(根据产品特征选择)
    4. 信息架构
              范围层:产品的功能,可以用思维导图来展示。
    功能模块
    1. 模块一
      • 功能细分
      • 优势
      • 劣势
      • 竞品情况
      • 改进的方案
    2. 模块二
      • 功能细分
         ...
    UI体验
         可以挑些有特色的页面讲一下视觉和交互。
    总结
         分析一下行业发展前景,公司前景,竞品生存情况。最好能给出一些发展的方向。
    展开全文
  • 项目复盘/总结模板

    千次阅读 2018-12-04 17:46:45
  • 测试用例和缺陷报告(项目实例)

    万次阅读 多人点赞 2020-06-13 17:27:21
    测试用例和缺陷报告模板 对于测试工程师,必备技能之一便是测试用例的编写和软件缺陷报告的编写啦~下面提供一些模板还有项目实战样例供大家参考参考, 通过Excel表格编写测试用例 缺陷报告模板 下面来个实战案例 ...
  • 【性能测试】一份完整的性能测试报告模板 本性能测试报告模板是结合工作经验及其他前辈的模板所总结的。
  • 软件测试报告模板

    千次阅读 2019-07-24 17:28:03
    模板 封面 包含项目名称、软件模块、软件版本、测试执行人、测试时间等。 目录 1. 引言 1.1 目的 1.2 适应范围 预期参考人员包括测试人员、开发人员、项目管理人员、质量管理人员、研发部门经理和需要阅读本报告的...
  • 事故报告模板

    千次阅读 2018-12-02 18:33:23
    没有写过事故报告的程序员不是好程序员(捂脸)。 事故报告需要包含以下内容: 事故概述 事故过程回顾(从发现问题到解决问题) 事故责任人、影响范围和损失情况,严重程度评级 事故原因分析 处理措施 后续跟进...
  • 通常呢,测试人员每周需要与组长汇报工作一次,那么如何是汇报变得简单有效,首先就要使用我们的表格和数据来...好了,下面我们来看看我们的测试报告模板。周测试报告模板项目版本测试日期项目经理开发人员测试人...
  • 我的Latex中文报告模板

    万次阅读 2016-09-27 18:25:41
    哈哈  终于有了自己latex的汇报模板了。以后汇报都用这个了
  • LaTeX模板:实验报告封面样式

    万次阅读 2016-06-15 10:57:10
    今天将自己用过的实验报告的封面样式在这里做一下分享,代码很简单,很容易看懂,可以直接用在自己的报告中如果你使用LaTex写报告的话。样式1 样式2 下载样式1 样式2
  • 报告星”自动报告生成系统介绍

    千次阅读 2018-06-12 15:59:48
    报告星”报告自动生成系统介绍一、 使用场景在生产或工作环境中我们经常会遇到这样的一个场景:出于业务或者管理的要求,针对每个对象需要重复大量出具一个格式基本固定Word报告,但是这个word报告每次都需要针对...
  • 之前说道测试报告,是一周的总结报告,那么如果在整个项目测试结束或者说,一个客户新的需求开发完成-测试完成后,上线,这个时候我们需要做的是什么呢?是更新测试用例,更新测试报告,这两者主要针对的是更新的...
  • 测试用例模板(通用)

    万次阅读 2019-03-26 13:52:52
    测试用例模板(通用) posted @ 2019-03-26 10:40 爱穿衬衫 阅读(...) 评论(...) 编辑 收藏
  • 一些有用的Latex模板(持续更新)

    万次阅读 2015-02-01 11:10:00
    最近搜集的一些Latex模板,希望各位写作的时候能派上用场。
  • latex常用中文模板,拿走直接很使用

    万次阅读 2018-08-29 11:40:13
    最近一直想要使用latex写中文文档,但是有时候我再网上找到的中文模板无法使用,就在网上收集latex的资料,制作了一个可以直接使用模板,如果有需要的小伙伴直接拿走。 \documentclass{article} \usepackage{CJK} ...
  • 几个咨询公司风格的PPT模板

    万次阅读 2015-08-20 11:51:42
    收藏的主要为咨询公司风格(日常工作主要写这类PPT),站在巨人的肩膀上再前行台湾PPT演示大师韩明文PPT图示800张罗兰贝格PPT模板普华永道北京锡恩图标样式PPT模板埃森哲专业PPT模板新华信咨询公司PPT模板及图库
  • Jmeter测试报告生成(jmete模板3)

    千次阅读 2017-07-21 10:12:54
    1. 命令行模式将 jtl 文件转成测试...1.1 在测试的过程中将 jtl 转换成测试报告 可以执行如下命令: jmeter -n -t test_request.jmx -l test_result.jtl -e -o /home/csmijo/resultReport 参数说明: -n : 非GUI
1 2 3 4 5 ... 20
收藏数 77,377
精华内容 30,950
关键字:

报告模板