测试理论与方法----测试流程第五个步骤：测试总结报告

10、通用测试技术

1、测试总结报告概述

定义：把测试过程和结果整理成文档，对发现的问题和缺陷进行分析，为纠正软件的质量提供依据，同时为后续的验收和交付打下基础。
测试报告是测试阶段最后的产出，一份详细的测试报告，应该包含【产品质量】和【测试过程】的评价，测试报告基于【测试中数据的采集】以及对【最终测试结果的分析】
一份合格的测试报告包含的内容：
- 测试资源的使用情况
- 投入的测试人员，时间分配
- 执行的用例数(用例的设计与执行情况)
- 覆盖的功能模块
- 风险管理分析
- 对测试对象的缺陷进行分析：总共发现的缺陷总数量，缺陷类型有哪些，缺陷的严重程度，缺陷主要集中在哪些模块…

2、测试报告的编写

测试概述
1. 编写目的：说明该文档是做什么的，能够起到的作用
2. 测试项目简介：描述被测项目的模块，被测项目的版本(从大范围描述测试的模块，对这些模块进行介绍)
3. 名词定义：专业术语——>测试过程出现的
4. 阅读对象：该文档面向的阅读对象，比如：产品，客户，开发，管理….
5. 参考文档：总结出这一轮测试过程中使用到的文档
测试环境与配置

介绍测试过程中使用到的硬件资源环境，软件资源环境，网络环境，以及和他们相关的配置参数
测试目标与范围
1. 测试版本情况：详细说明版本信息，比如：什么时候接收到该版本，需不需要进行环境部署，什么时间完成部署操作，测试过程中是否有新版本的发布，新版本的发布是否对测试的工作产生影响，以及拿到新版本后，冒烟测试是否能够通过….
2. 测试范围：主要描述本次测试覆盖的功能模块
测试情况安排
1. 进度安排：在什么时间节点，需要完成什么样的任务安排，不同的阶段要完成对应的任务工作
2. 角色和职责：有哪些参与者，参与者的身份是什么，以及要完成的职责任务(不同角色的人，分配的任务也是不一样)
测试结果与分析(最核心)
1. 测试用例需求覆盖分析
  
  ①需求覆盖率：达到100%
  
  ②测试的覆盖率：执行用例的数量(成功+失败)/用例的总数量*100%
  
  例：设计100条测试用例，通过80条，未通过5条，阻塞15条，测试覆盖率：85%，测试通过率：80%
  
  ③测试的通过率：执行用例通过的数量/用例总数量*100%
  
  参考写法：
  
  可以按照【功能模块】来进行数据统计：每个模块设计的用例总数量，需求覆盖率，执行用例通过数量，失败数量，阻塞的数量，测试覆盖率，测试通过率
2. 缺陷的统计与分析：可以反应出被测系统软件的质量
  
  （1）缺陷汇总：
  
  把本轮测试过程中发现的【所有缺陷】进行整合，可以按照【功能模块，严重程度，优先级，缺陷类型】来进行分类汇总。
  
  例：每个功能模块，产生的缺陷：致命，严重，一般，较小的各自的数量，划分的优先级是什么，这些缺陷的类别属于哪些方面
  
  （2）缺陷分析：以图表的形式来进行展示：折线图，柱形图，饼状图….
  
  ①可以从软件【已发布的版本】来分析缺陷：通过折线图的形式，体现出【每个版本中缺陷的总数量】
  
  ②可以从【缺陷的严重程度】来分析缺陷：通过柱形图的形式，按照严重程度体现缺陷的数量，比如：致命缺陷总数，严重缺陷总数，一般缺陷总数，较小缺陷总数
  
  ③可以从【缺陷类型(BUG引入原因)】角度来分析缺陷：通过饼状图的形式，根据缺陷类型体现缺陷的数量，比如：功能缺陷占比数据，性能缺陷占比数据
遗留的缺陷和未解决的问题

如果没有，就写无；

如果有，生成一个BUG清单(表)，描述出未解决的缺陷，原因，预计解决的时间
测试总结与风险分析
1. 体现出测试的过程最终产品达到的标准，比如：以产品是否可以发布上线为例：一定要给出一个明确的结果：可以上线，或未达到上线的标准；以产品是否可以交付验收为例：可以交付，或不能进行交付…
2. 风险分析：如果没有，就写无；如果有，描述出遇到的风险，以及解决的方案
测试报告的批准

规定出相关人员的审批，进行签名和签署日期

回顾

WEB端应用程序测试分析点：功能测试+性能测试+安全测试+配置兼容性测试+易用性测试
测试报告

为什么要做测试报告？（目的，意义）

测试阶段结束的标识
总结当前测试阶段发现的问题
审核当前项目是否可以发布
产品质量的评估
为后续的测试工作开展提供依据

3、软件测试过程理念

软件测试过程理念：尽早测试全面测试全过程测试测试是独立，迭代的

11、测试过程模型

1、软件开发过程模型

概述：体现的是一个软件开发的全过程，软件从无到有的过程。
瀑布模型(掌握)
1. 优点：为项目提供了按阶段划分的检查点，每个阶段的工作都需要进行评审，只有评审通过的情况下，才会进行下一个阶段工作的开展；当前阶段工作的完成，只需要关注后期阶段工作推进即可
2. 缺点：各阶段的工作是完全固定的，每个阶段都会产生大量的文档，反而增加了工作量；直到末期才能看到软件产品，极大增加了开发风险
3. 适用项目：适用于需求比较明确且变更较少的项目
螺旋模型
1. 概述：是一种渐进式的开发模型，以产品原型作为旋转点，每转一圈就会经过【制定计划，风险分析，实施工程，客户评估】四个环节，经过若干次旋转得到最终的产品
2. 四个环节：
  
  制定计划：确定软件的目标，选定实施方案，确定项目开发的限制条件
  
  风险分析：分析实施方案，评估风险，消除风险
  
  实施工程：设计+编码+测试
  
  客户评估：评价开发的工作是否按之前的计划进行，提出修改的意见，制定下一步的计划
3. 适用项目：对于新开发的，需求不明确的项目，便于进行风险分析和管理把控
4. 缺点：因为有风险分析的过程，所以会投入大量的成本进行风险分析讨论，甚至因为风险过大，导致项目没办法继续推进
增量模型(理解)
1. 概述：把待开发的软件进行模块化的操作，每一个模块作为一个增量组件，从而分批次进行【分析，设计，编码，测试】，直到完全融合在项目中
2. 优点：采用增量模型，开发不需要一次性把整个产品交付给客户，可以进行分批次开发交付；抢占市场先机
3. 缺点：要求待开发的软件是能够进行模块化的开发；要求技术管理人员把握全局水平较高的
4. 适用项目：需求经常发生改变的项目
迭代模型(了解)
1. 概述：项目的每一次迭代更新都是一个完整的软件开发过程：需求分析，设计，编码，测试，评估等工作流程。一次迭代都会产生一个可发布的产品，该产品是最终产品的子集。
2. 适用项目：事先不能完整定义软件的所有需求，计划多期开发的项目
敏捷开发(理解)
1. 概述：是一种轻量，高效，低风险，更强调的是团队协作和沟通的开发方式，适用于中小型开发团队，客户需求多变或模糊，以人为中心的开发方式。
2. 开发过程：强化：人与人之间的沟通，客户全程参与，需求多变；弱化：流程和工具，详尽的文档，合同谈判，遵循计划，追求的是开发速度
3. 思想：产品拿到需求后，召开会议，提出需求，把明确的需求提给开发团队，确定短期开发目标；开发团队拿到任务，内部召开会议进行任务的分工；任务分配完成后，就进入1-4周的开发周期，每日都会举行站立会议，汇报每天任务的推进情况；经过1-4周时间后，短期的目标已实现，举行演示会议，演示成果；通过后，进入回顾会议，所有的项目人员都会参与，提供可交付的产品，并进行复盘和总结。

2、软件测试过程模型

概述：如同开发过程一样，软件测试也有自己的过程模型，用于【定义软件测试的流程和方法】，因为测试过程的质量，也会直接影响测试结果的正确性和有效性，所以测试的过程也要遵循原理模型
V模型
1. 概述：揭示了开发过程和测试过程的各阶段之间对应的关系
2. 不足：V模型仅仅是把测试看成是编码之后的工作，忽略了前期对于需求和设计文档的确认，验证操作，没有体现出“尽早测试”的原则，大部分情况下只是对代码进行测试，需求的满足情况只能到后期的验收测试阶段才能被验证。
W模型(理解)
1. 优点：是由两个V构成，分别代表的是开发与测试的过程，表示测试与开发是并行的关系(同步进行)；测试对象不仅仅是程序，还有需求与设计文档，尽早进行测试可降低后期的修复成本
2. 缺点：W模型不管是开发流程，还是测试流程，都是线性开展的，上一个阶段工作的完成，才能进行下一个阶段工作的开展，无法支持灵活的迭代工作
H模型(理解)
1. 优点：H模型将测试工作完全独立出来，形成了一个独立的工作流程，整个测试过程就变得很灵活，测试人员会设置测试就绪点，一旦达到就绪点，测试的工作就可以进行了，所以要求测试人员前期的准备工作一定要充分，提前准备好
2. 缺点：前期准备工作压力比较大，个人能力要求比较高，因为要设置好就绪点
  
  工作中一般采用测试流程：W+H
X模型(了解)
1. 思想：X模型是针对每个程序片段都会经历【编码+测试】环节，在此之后通过频繁的交接，最终【集成】为可执行的程序；X模型还定义了探索性测试，这样可以帮助有经验的测试人员额外发现更多的错误。