【腾讯TMQ】测试分析？就这么简单！

作者：段超

什么是测试分析？

在软件测试过程中，以最小的成本将软件质量风险降至最低，这就是精准测试。宏观上，测试分析是响应精准测试的实践，贯穿整个测试过程，并对整个测试过程起指导作用；实践中，测试分析在测试阶段中的位置如图所示:

图测试分析在测试流程中的位置

在项目中，我们往往根据需求和代码来进行分析，最后得到一个包含需求背景、开发实现分析、测试纬度等内容的xmind格式的简版分析报告。

图测试分析xmind模版

这里结合实践说明一下分析的过程以及分析侧重点。本文主要针对于增量的需求进行测试分析，对于全量的新项目，侧重点可能并不适用。

基于需求的测试分析

互联网项目一般都追求快节奏，所以需求描述得比较简单，甚至可能会有一些重要逻辑未考虑的情况，对这样的需求进行分析时，推荐使用NLP模型来进行需求分析，理解需求、消除歧义。关于NLP模型可参见这里。NLP模型帮助测试同学理清需求，借助传统的用例设计的方法(正交分解、判定表、边界值、等价类、场景法等等)，可以设计出一些基于需求的用例。对需求进行测试分析，可以得到黑盒的测试策略，这一步可以在需求提出即可立即开展。

基于实现的测试分析

通过查看开发的提交，分析开发实现，进而得到测试策略。下面重点说明一下基于实现的测试分析，也正是有别于传统基于需求的用例设计的分析方法。

一、查看代码提交

SVN的提交是进行代码测试分析的输入，根据开发的提交Reversion来进行实现分析，进而得到最终的测试策略。

代码提交要求：

1、减少提交次数量：提交次数过多，Review人员容易被中间版本误导，影响review效率，提高review的成本。

2、提交与需求(bug)关联：提交必须与需求关联，并且一次提交必须仅与一个需求关联。

3、不提交无关代码：开发提交的代码中往往包含一些与需求无关的代码，可能是预埋逻辑，可能是备选方案。这些代码会影响Review人员的注意力，甚至会引起漏分析（预埋逻辑时未分析、真正使用该逻辑时也未分析）。

项目中测试人员应提醒开发注意养成良好的提交习惯。目前电脑管家全面推行使用公司组件Rain，规范化提交。

拿到与需求关联的提交后，我们可按照以下步骤进行分析：

二、理清类关系（可选）

对于一般业务来说，一次迭代涉及的类不会太多，通过一些分析软件如understand可以立即生成类图供查看。类图虽然不能直接反应出业务逻辑，但对于理解开发实现的大致结构很有作用。通过类图可获取到一次迭代涉及哪些类以及类之间的继承关系，了解类大致成员有哪些。

understand生成的类图

三、寻找核心业务入口

一般来说业务总会有一个入口点，找到入口点才能顺藤摸瓜。例如一个Button点击之后的很有可能是触发类似OnButtonClick的回调函数，那么这个函数即是我们的入口函数。有的业务有多条业务线，可能有多个入口，列出每个入口，后面一条条进行分析。

四、查找函数调用链

从入口函数出发，找到所有业务函数调用链。这一步骤是整个测试分析的核心，直接关系到测试分析的质量。在查找业务函数调用链的过程中，注意核心函数的逻辑结构，如果非常复杂，可以借助控制流图来单独对函数内部结构进行分析，检查每个分支是否符合需求逻辑。

understand生成的控制流图

五、寻找测试点

和开发Review有点不同，我们是带着测试分析的目的去Review的，即根据代码来找寻测试点。面对大量的代码提交，不要被代码带进去，深究一些非核心的细节往往会本末倒置，始终保持怀疑的态度去找寻测试点。对于一般windows程序，这里总结几个侧重点，可能并不正确，请大家拍砖。

重逻辑

UI往往在测试执行中容易发现问题，而逻辑的触发可能比较隐蔽，测试执行中不易触发。在项目时间紧张的情况下，把时间花在理清逻辑上更重要，也容易发现问题。当然一些逻辑触发意味着UI的变化，这样可以借UI印证逻辑的变化，是更好不过了。

重逻辑

UI往往在测试执行中容易发现问题，而逻辑的触发可能比较隐蔽，测试执行中不易触发。在项目时间紧张的情况下，把时间花在理清逻辑上更重要，也容易发现问题。当然一些逻辑触发意味着UI的变化，这样可以借UI印证逻辑的变化，是更好不过了。

重异常

70%以上比例的异常用例是我们的目标。可以说异常用例的设计直接体现了一个测试人员的分析能力。在平时的工作中多注意总结和收集，逐步积累。比如对于任意一个关于设置本地路径的业务，都可以思考如下测试点：

• 超长路径
• 带空格的路径
• 带中文的路径
• 磁盘空间不足
• ...

他山之石，可以攻玉。和开发一样，测试同学遇到的99%的问题都是别人遇到过的。所以我们可以从如下几个方面汇总他人的经验教训：

• 业界开发规范
• 部门开发规范
• 异常用例
• 线上/下bug分析

关于异常用例方面的总结，笔者也在总结和收集中，期待与大家的交流。

重动态

C++里面有很多状态变化、事件响应、消息传递等动态的内容，理清这些动态内容对于我们理解业务非常重要，同时很多bug来源也在此。

• 事件Event
• 定时器Timer
• 线程Thread
• 互斥量Mutex
• 信号量Semaphore
• 临界区Critical_section

在遇到这些关键字时，我们不妨Find References检查所有用到这些对象的使用是否有问题。具体包括：

• 创建和销毁是否对应
• 状态改变是否符合逻辑
• 销毁时机是否合理，销毁逻辑是否正确
• 销毁后是否仍可能使用

同时，业务上一些核心的状态status、标识flag、模块间通讯的数据等也属于动态内容，也可以加强对这些内容的检查及用例设计。

重第三方

如果对某次迭代进行分析时，发现引入了第三方的库，我们需要特别关注对第三方库接口的使用情况。从功能、性能、稳定性、安全性等各个维度对接口进行评估，特别是频繁调用的接口，更应保持谨慎的态度，评估影响、输出风险点。对于第三方接口，一般都需要考虑兼容性，尤其是不同系统的兼容性。

###六、分析耦合

在查找函数调用链中，我们在梳理核心业务逻辑时，就会找到第三方库的使用。C++中，在变更的代码中搜索Loadlibrary关键字，也可以找到装载的DLL模块。DLL库如果是非微软提供，我们更需要小心。如果有使用第三方库的情况，通常会专门将其列出进行分析。

另外耦合还包括内部模块与模块之间的关系。这里笔者采用需求矩阵的方式来进行思考。

七、脑暴异常

异常的思考作为剧本式分析方法的一个补充，可以起完善测试策略的作用。通常也会在xmind中专门列出来。异常种类各式各样，非正常环境、非正常操作、非正常输入都是我们可以考虑的异常点。比如某个业务流程中直接退出窗口或者取消任务，连续快速点击某个按钮、在精简版的操作系统中运行程序等等。

结束语

本文为业务测试人员提供一个测试分析的思路，特别适用于快速迭代的业务测试，对于专项测试本文介绍的思路并不完全适用。限于水平有限，很多内容可能并不正确或者完整，请斧正。

本章完~