测试报告 订阅
测试报告是指把测试的过程和结果写成文档,对发现的问题和缺陷进行分析,为纠正软件的存在的质量问题提供依据,同时为软件验收和交付打下基础。 展开全文
测试报告是指把测试的过程和结果写成文档,对发现的问题和缺陷进行分析,为纠正软件的存在的质量问题提供依据,同时为软件验收和交付打下基础。
信息
编    号
BUG号
缺陷概要
该缺陷描述的事实
硬    盘
可用空间大小
中文名
测试报告
外文名
test report
测试报告介绍
测试报告是测试阶段最后的文档产出物。优秀的测试经理或测试人员应该具备良好的文档编写能力;一份详细的测试报告包含足够的信息,包括产品质量和测试过程的评价,测试报告基于测试中的数据采集以及对最终的测试结果分析。
收起全文
精华内容
参与话题
问答
  • 软件测试报告模板_详细版

    万次阅读 2019-04-01 16:31:28
    本文档用于记录测试过程,总结各轮次的测试情况,分析测试数据,归纳测试工作进行过程中暴露的问题与遗留的风险,给出相应的测试建议以供后续项目参考。 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日上线止,期间各阶段工作情况如下:

     

     

     

    2.2 测试范围

     

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

     

    功能测试

     

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

    数据迁移测试

    接口测试

    兼容性测试

     

    性能测试

     

    参见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测试过程中发现缺陷在各模块中的分布情况

     

     

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

     

    从以上缺陷分布情况看,所有缺陷中有近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. 项目管理。主要是建议加强项目的计划性,诸如:进度计划、人力资源计划、风险预防机制等,这也将更利于项目成员间高效的配合:大家能更适时的、更合理的制定各自工作计划,也更清楚到什么时候我会输出什么、我将配合他人做些什么。减少项目进行过程中的紧张和慌乱、项目也变得更加易控和可控。

    ---------------------

     

    展开全文
  • 测试报告(包括测试总结)

    万次阅读 2017-12-12 14:45:25
    其他的后续再添加,这次主要写下测试总结要注意的点。 测试总结: 1.总体情况 2.缺少设备或资源导致测不到的地方(在测试计划完成后,一定要向项目经理或需求提出要这些资源) 3.某些模块,开发不进行修改的理由...

    其他的后续再添加,这次主要写下测试总结要注意的点。

    测试总结:

    1.总体情况

    2.缺少设备或资源导致测不到的地方(在测试计划完成后,一定要向项目经理或需求提出要这些资源)

    3.某些模块,开发不进行修改的理由(自己也同意的部分,这个部分可以提请项目经理或需求意见)

    4.哪些模块还存有问题

    5.按重要程度进行排序,重要的问题排在前面

    6.bug验证,如果再进入这个项目前有bug,也可以写出bug验证情况

    展开全文
  • 功能测试报告总结

    万次阅读 多人点赞 2016-07-08 13:43:14
    测试报告测试人员在测试过程中用于反映测试状况的文档,其重要性通过网上哀求、跪求、旋转360度冰天雪地各种求测试报告模块的帖子中就可见一斑。其实测试报告的内容基本都是模板的那些,只是在实际测试过程中,...

    转自http://www.cnblogs.com/xunmi/archive/2011/08/18/2144745.html

    测试报告是测试人员在测试过程中用于反映测试状况的文档,其重要性通过网上哀求、跪求、旋转360度冰天雪地各种求测试报告模块的帖子中就可见一斑。其实测试报告的内容基本都是模板的那些,只是在实际测试过程中,如何去整理内容结构,使得报告的通常阅读者:开发人员、测试经理、产品经理、项目负责人能够一目了然地查看想要了解的内容才是测试报告最值得注意的地方。

    产品要想有广阔的市场,得需要切实了解用户的需求及感受,同理测试报告要想能够让阅读者能够满意,也需要能将质量情况条理性地列出。通常来说,开发人员往往希望能从报告中了解缺陷的情况,而测试经理还关心用例的执行情况及覆盖率、项目责任人则最关心还有多少问题,此次版本是否测试通过。因此测试报告根据内容的侧重点,分为『版本测试报告』和『总结测试报告』,目的也是希望不将所有内容列举在一个报告中,造成内容臃肿繁杂。

    〖版本测试报告〗

    ü  主要反映开发人员提交的测试版本的质量状况。

    ü  测试用例设计与执行、缺陷概况及问题概要是版本测试报告中的主要内容。

    ü  测试人员在每个轮次测试结束时编写提交。

    其内容结构如下:

     


     

    对版本测试报告的每个章节的编写内容进行说明:

     

    大纲

    子章节

    详细内容

    测试简介

    测试目的

    本次测试的背景及主要内容

    测试资源

    测试人员、本次测试开始和截止日期、花费工作日

    测试环境

    硬件环境

    实际情况的详细列举,过低的配置、软件版本的不匹配、网络拓扑的错误都会让提交的缺陷缺乏说服力,也会让开发人员对于某些缺陷是否由于环境因素导致而产生疑惑。

    软件版本

    网络拓扑图

    测试方法

    本次测试的功能点、各功能点对应的测试用例设计、测试用到的测试工具

    测试用例

    用例分析

    测试用例维护记录

    用例执行情况

    用例执行总数、通过用例数、未通过用例数、阻塞用例数

    测试执行率=(已执行的用例数)/用例总数

    测试用例效率=发现的缺陷总数/测试用例的数量

    测试过程

    缺陷统计

    新建bug数、修复bug数、未修复bug数、bug总数

    问题摘要

    遗留问题、拒绝问题、挂起问题、长期验证问题、待评估问题

    测试结果

    资源占用

    测试项目的启动、退出时间

    测试项目的CPU占用率初始值、峰值(如果项目启动会有多个进程,则分多个进程进行统计)

    测试项目的内存占用初始值、峰值

    测试结论

    测试结论不论仅仅只是测试通过或不通过,应该使用详细的数据来支持测试结论,需要列举的数据有:

    『测试用例通过率』

    总用例

    未通过用例

    未通过比率

     

     

     

    『遗留bug情况』

    总bug数

    未修复bug

    遗留bug率

     

     

     

     

    备注

    用例执行记录

    插入测试用例的详细执行结果文档

    资源监控记录

    说明资源占用监控的场景,详细列举各场景的监控时长、监控内容,场景操作

     

     

     

    〖总结测试报告〗

     

    ü  主要偏重于各已测试版本的缺陷变化分析,风险预估。

     

    ü  各测试版本质量情况概况统计、缺陷分布统计、风险分析是总结测试报告中的主要内容。

     

    ü  测试人员在项目发布上线前编写提交。

     

    其内容结构如下:

     


     

    对总结测试报告的每个章节的编写内容进行说明:

     

    标题

    子章节

    详细内容

    测试简介

    测试目的

    本次测试的背景及主要内容

    测试资源

    测试人员、第一轮测试的开始日期和最后一轮测试的截止日期、总共花费工作日统计

    测试环境

    硬件环境

    实际情况的详细列举,过低的配置、软件版本的不匹配、网络拓扑的错误都会让提交的缺陷缺乏说服力,也会让开发人员对于某些缺陷是否由于环境因素导致而产生疑惑。

    软件版本

    网络拓扑图

    测试过程

    各版本测试状况

    各测试版本的计划提交日期、实际提交日期、测试类型(回归或全量)、测试耗时、备注(被打回或提交补丁次数)

    各版本bug统计

    各测试版本的新建bug数、修复bug数、遗留bug数,表格统计、线形图或饼状图辅助表示

    测试分析

    缺陷分析

    缺陷的总体分布情况,以线形图或饼状图辅助表示

    ²  根据功能模块进行划分

    ²  根据严重、较严重、普通、轻微级别进行划分

    遗留问题

    打开状态bug、长期验证bug、用户体验问题

    测试小结

    资源占用

    测试项目的启动、退出时间

    测试项目的CPU占用率初始值、峰值(如果项目启动会有多个进程,则分多个进程进行统计)

    测试项目的内存占用初始值、峰值

    风险分析

    测试进度、人员安排导致的风险

    测试内容考虑范围之外导致的风险

    测试环境不全面导致的风险

    其他因素导致的风险

             以上是对功能测试报告编写的总结,性能测试报告、兼容性测试报告因为内容的不同是不能套用以上测试报告的结构进行编写,功能测试报告的编写就是要做到简约而不简单。

     

    展开全文
  • 测试报告模板

    万次阅读 多人点赞 2018-01-04 23:03:05
    本文档用于记录测试过程,总结各轮次的测试情况,分析测试数据,归纳测试工作进行过程中暴露的问题与遗留的风险,给出相应的测试建议以供后续项目参考。 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-10-11 09:45:05
    网站软件测试报告,包括系统功能及性能测试的系统测试报告模板,内容比较完整,仅供参考,希望能够帮到大家。
  • 功能测试报告

    万次阅读 2019-02-14 20:11:00
    2019独角兽企业重金招聘Python工程师标准>>> ...
  • 软件测试报告 珍藏版。好用记得回复推荐哦 目 录 1. 测试概述 3 1.1. 编写目的 3 1.2. 测试范围 3 1.3. 参考资料 3 2. 测试计划执行情况 3 2.1. 测试类型 3 2.2. 测试环境与配置 4 2.3. 测试人员 4 2.4. ...
  • 软件测试报告为软件测试工程师必须掌握的技能之一,此文档为公司内部规范文档,希望对大家有所帮助
  • 软件测试报告模板

    2018-07-11 09:37:48
    项目测试总结报告 1 1. 引言 4 1.1 编写目的 4 1.2 项目背景 4 1.3 系统简介 4 1.4 参考文档 4 2. 测试设计简介 4 2.1 测试用例设计 4 2.2 测试环境与配置 5 2.3 测试方法和工具 5 3. 测试结果及其分析 5 3.1 测试...
  • 测试报告模板范例

    万次阅读 多人点赞 2018-01-04 23:00:40
    1. 简介1.1 编写目的本文档用于记录测试过程,总结各轮次的测试情况,分析测试数据,归纳测试工作进行过程中暴露的问题与遗留的风险,给出相应的测试建议以供后续项目参考。1.2 项目背景xx需要一个拥有真实用户的...
  • 非常用实型的硬件产品故障检测报告!可填写详细的产品故障、检修内容及所涉及的配件更换费用,信息一目了然!
  • 安全测试报告模板

    2018-07-17 15:33:38
    安全测试报告模板 安全测试报告模板安全测试报告模板安全测试报告模板
  • 测试报告模板.docx

    2019-05-27 15:23:05
    简单实用的测试报告模板,如果有兴趣,可以回复,提供各类测试报告,都是实际项目经验
  • 性能测试报告模板

    千次阅读 2019-03-06 09:56:30
    xxxx项目性能测试报告模板VERSION 1.0目 录1.................................................................................................................. 概述... 21.1...................................
  • 电脑硬件测试报告模板

    热门讨论 2010-05-11 20:55:02
    BIOS TEST REPORT FUNCTION TEST REPORT VIDEO TEST REPORT MOTHERBOARD TEST REPORT
  • HTML测试报告模板

    2019-07-17 11:59:11
    HTML测试报告模板 报告截图展示: 目录结构: --- BeautifulReport --------------- 程序主目录 --- report --------------- HTML报告存放路径 --- Report.html --------------- HTML报告文件 --- ...
  • 测试报告-模板

    2018-01-04 10:40:42
    1.需要有web测试经验,可以独立跟进项目 2.app+web测试以功能为主,了解app与web测试差异性 3.有一定环境搭建能力 4.熟悉兼容性测试目的、方法、测试点 5.掌握抓包工具,能够抓包查看数据,简单定位问题 6沟通能力好...
  • 渗透测试报告模板

    千次阅读 2020-01-14 14:18:18
    XXXX 渗透测试服务的主要流程如下: (一)信息收集 信息收集是指渗透实施前尽可能多地获取目标信息系统相关信息,例如网站 注册信息、共享资源、系统版本信息、已知漏洞及弱口令等等。通过对以上信息 的收集,发现...
  • 这是一个软件测试报告模板。 献给要撰写而又不知如何撰写的工友们。
  • 软件系统测试报告 模板 测试 报告 软件系统测试报告 模板 测试 报告

空空如也

1 2 3 4 5 ... 20
收藏数 440,037
精华内容 176,014
关键字:

测试报告