测试基础总结

用例设计完成，一旦拿到开发给的软件时，可以执行用例，发现缺陷，对缺陷进行提交。

缺陷的生命周期：---->体现的也是一个缺陷被跟踪修复的过程

发现缺陷-->提交缺陷-->确认缺陷-->分配缺陷-->修复缺陷-->验证缺陷-->关闭缺陷

缺陷报告编写5C准则

软件测试流程：

提取测试需求-->编写测试计划和制定测试方案-->用例设计-->执行用例-->提交缺陷-->测试分析与评审-->提交测试报告-->准备下一个版本的测试

测试流程最后一个环节：测试报告的编写

一.测试报告的描述

1.概述：测试报告是指把测试的过程和结果写成文档，对发现的问题和缺陷进行分析，为纠正软件存在的质量问题提供依据，同时也为软件验收和交付打下基础。

2.测试报告是测试阶段最后的产出物文档，一份详细的测试报告总结，应该包含产品质量和测试过程的评价，测试报告基于测试中的数据采集以及对最终的测试结果的分析。

二.编写测试报告

1.编写测试报告的分析方向：

1.1测试的资源使用情况

1.2投入了多少测试人员，多少时间

1.3执行的用例数

1.4覆盖的功能模块

1.5风险管理分析

1.6对测试对象的缺陷分析：共发现了多少个缺陷，缺陷的类型主要有哪些，缺陷集中在哪些模块，以及缺陷严重程度的划分.....

2.测试报告细化分析：

(1)测试概述

1.1编写目的：该文档是用来做什么的，出具该文档可以起到什么结果

1.2测试项目的简述：描述被测项目的版本，测试范围(在该版本中测试了哪些模块)进行阐述

1.3名词解释(专业术语)：在测试过程中用到专业话术

1.4阅读对象：该文档主要面向的对象

例：产品经理，项目经理，测试组长，项目相关的人员....

1.5参考文档：总结出这一轮测试中用到的文档

(2)测试环境与配置

介绍测试时的硬件环境，软件环境，网络环境，以及相关的配置参数。

(3)测试目标与范围

3.1测试版本情况：详细描述测试版本情况，比如：什么时候接收到该版本，什么时间部署完该版本，测试的过程中是否有新版本的发布，发布的新版本是否对测试产生影响，以及拿到新版本之后，冒烟测试能否通过...

3.2测试范围：主要描述本次测试任务覆盖的功能，模块，以及任务的分配范围。

(4)测试情况安排：主要描述本次测试任务执行整体情况，测试时间安排，测试人员参与情况，任务分工，角色参与.....

4.1进度安排：在什么时间节点，完成什么样的任务安排(在不同阶段要完成对应的工作安排)

4.2角色以及职责：有哪些参与者，参与者的身份是什么，以及要完成的职责任务(不同角色的人，安排的任务也是不一样的)

(5)测试结果与分析：总结测试的结果，指出已经解决的事件，并总结解决方法，同时还要指出尚未解决的事件。（重点关注）

5.1测试用例需求覆盖分析

a.需求覆盖率：达到100%

b.测试覆盖率：执行测试用例数量(通过+失败)/用例总数量*100%

例：用例设计了100条，通过88条，失败5条，阻塞7条，测试覆盖率：93%

c.测试通过率：通过的用例数量/用例总数量*100%

例：测试通过率：88%

在该部分要描述出，软件的每个模块，设计的用例总数，需求覆盖率，测试覆盖率，用例通过的数量，失败的数量，阻塞的数量，测试的通过率

5.2缺陷的统计与分析：通过缺陷的统计可以反应出被测系统的质量

a.缺陷的汇总：

把本轮测试中发现的所有缺陷进行整合，找到的缺陷可以按照功能模块，严重程度，优先级，缺陷类型进行分析汇总。

例：每个功能模块，产生的缺陷：致命，严重，一般，较小各自有多少个，划分的优先级是什么，这些缺陷的类别属于哪些方面

b.缺陷分析(推荐以图表形式来展示--折线图，饼状图，柱形图...)

b.1可以从软件已发布的版本中分析缺陷：

通过折线图的形式，来体现出每个版本中缺陷的数量

b.2可以从缺陷的严重程度来分析缺陷：

通过柱形图的形式，按照严重程度来体现缺陷数量，比如：本轮测试中，致命缺陷的总数量，严重缺陷总数量，一般缺陷总数，较少缺陷的总数量

b.3可以从缺陷类型(BUG引入的原因)角度来分析缺陷：

通过饼状图的形式，根据缺陷类型来体现缺陷数量分布，比如：功能错误缺陷占比数据，设计缺陷占比数据....

(6)遗留缺陷与未解决的问题

方式：可以生成一个BUG遗留清单，描述出在本次测试中未解决的缺陷，以及原因，还要写出遗留缺陷的预计解决时间

(7)测试总结与风险分析

首选要体现出通过测试的过程，最终产品到达的标准，比如：以产品是否可以上线为例，测试总结就要给出是可以上线，还是达不到上线标准的结果；

其次，要对整个测试过程中，遇到的风险进行分析描述，并整合出解决的方案

(8)测试报告的批准

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

3.为什么要做测试报告？

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

三.软件测试过程模型

1.概述：如同软件开发过程一样，软件测试也有自己的过程模型，用于定义软件测试的流程和方法。因为测试过程的质量，会直接影响测试结果的准确性和有效性，所以测试如同开发一样，也是需要遵循软件工程的原理以及管理学原理。

2.V模型：揭示了开发过程和测试过程的各阶段的对应关系

不足：V模型仅仅是把测试看成是编码之后的工作，忽略了对于需求以及设计文档的验证操作，需求的满足情况只能到后期的验收测试阶段才能给被验证，没有体现出"尽早的和不断地进行软件测试"原则，大部分情况下也只是针对代码进行测试。

3.W模型

优点：是由两个V构成，分别代表的是开发与测试过程，表示了测试和开发是并行的关系(同步进行)；测试对象不仅仅是程序，还包含需求和设计文档；尽早的进行测试发现缺陷可降低后期的修复成本

缺点：w模型中不管是开发还是测试的工作流程都是线性开展的，上一阶段工作的完成，才能开始下个阶段的工作，无法支持灵活的迭代

4.H模型

优点：H模型将测试活动完全独立出来，形成了一个独立的工作流程；整个测试工作流程变得更为灵活一些，一旦达到了测试就绪点，测试的工作就可以进行了；所以就要求测试人员前期的测试准备工作一定要提前准备；

缺点：对于测试人员的能力要求会更高一些，因为要设置好测试就绪点

注意：为了更好的对开发进行测试，工作中一般采用W+H模型

5.X模型

X模型是针对每个程序片段都会经历编码+测试环节，此后通过频繁的交接，最终集成出可执行的程序；X模型还定义了探索性测试，这样可以帮助测试人员额外在发现更多的软件错误

四.软件测试过程理念

尽早测试；全面测试；全过程测试；独立的，迭代的测试