测试基础总结

Posted 2023-04-02 peace and lovey

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

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

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

缺陷报告编写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模型还定义了探索性测试，这样可以帮助测试人员额外在发现更多的软件错误

四.软件测试过程理念

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

UE4基础知识总结（四）

参考技术A 六、自动测试技术

1.自动测试分为简单测试和复杂测试，简单测试用来描述单个原子测试，复杂测试用来运行基于多个输入的相同代码。

2.简单测试可用来确认特定功能如预期般可操作。一般都是单元测试或功能测试。

3.复杂测试可被用来对一系列物品迭代并对每个物品运行相同的功能。一般就是内容压力测试。例如载入所有地图或编译所有蓝本。

4.当前的规则是将所有的自动测试放置到相关模块内的PrivateTests目录。测试文件命名为[ClassFilename]Test.cpp

5.这些测试通过应用RunTest()函数来单独定义其功能，而且Parameters字符串将保持为空字符串。

IMPLEMENT_SIMPLE_AUTOMATION_TEST( TClass, PrettyName, TFlags )

IMPLEMENT_COMPLEX_AUTOMATION_TEST( TClass, PrettyName, TFlags )

七、编码规范

1.编码规范对于程序员来说非常重要，原因如下：

a.一套软件80%的生命周期都是维护。

b.在软件的整个生命周期中，几乎不可能一直是软件的原始作者来对其进行维护。

c.编码规范可以改进软件的可读性，从而使得工程师可以快速并透彻地理解新的代码。

d.如果我们决定将源代码公布到 MOD 开发者社区，那么我们想让它通俗易懂。

e.大部分编码规范实际上是交叉编译器兼容性所要求的。

2.变量、方法及类的名称应该清晰、明确且具有描述性。

3.注释应该是辅助加强代码的，代码是功能实现，注释表明了代码的目的。

八、对象

1.虚幻引擎中的对象基础类为UObject。UCLASS宏可用于标记从UObject派生的类，使UObject处理系统识别到它们。

2.UCLASS宏为UObject提供一个对UCLASS的引用，描述其基于虚幻引擎的类型。

3.每个UCLASS保留一个称作“类默认对象（Class Default Object）”的对象，简称CDO。

4.新建UObject示例的函数有：

a.NewObject () 创建一个自动生成命名的新实例。在简单情况下使用最佳。

b.NewNamedObject () 使用特定命名以及其他几项任选参数创建一个新实例。将判断新实例的Outer中是否存在命名冲突。

c.ConstructObject () 创建一个提供所有可用创建选项的新实例。仅限需要灵活性时使用。

d.new 用于在特定低层情况下构建对象，如构建函数需要参数时。

5.UObjects提供的功能有：

a.垃圾回收：虚幻引擎实现了一个垃圾回收方案，定期清理不再被引用或被显式标记为待销毁的 UObject。

b.引用更新：对象被垃圾回收清理时，对它的UPROPERTY引用将自动被更新为 NULL。

c.映象

d.序列化：当一个 UObject 被序列化时，所有 UProperty 数值将被自动书写或读取。

e.默认属性变化自动更新：UClass 的CDO发生变化时，引擎将尝试把这些变化智能应用到类的所有实例上（在它们被加载时）。

f.自动属性初始化：初始化时，在构建函数被调用之前，UObject 将被自动清零。

g.自动编辑器整合：编辑器理解 UObjects 和 UProperties，还可将这些数值自动公开进行编辑，而无需编写特殊代码。

h.运行时类型信息可用：UObject 明确其为何种 UClass，运行时可作出类型相关的决定。

i.网络复制：UObject 系统包括一个稳定的功能集，实现网络通讯和多人 游戏 。

6.UObjects的头文件格式：

#include 'Object.h'

#include 'MyObject.generated.h'

UCLASS() //UCLASS 宏使虚幻引擎 4 能识别 UMyObject。

class MYPROJECT_API UMyObject : public UObject //如 MyProject 希望将 UMyObject 类公开到其他模块，则需要指定 MYPROJECT_API。



GENERATED_BODY() //对类进行设置，以支持引擎要求的基础结构。

;