测试分析?就这么简单!

什么是测试分析?

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

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

在项目中,我们往往根据需求和代码来进行分析,最后得到一个包含需求背景、开发实现分析、测试纬度等内容的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印证逻辑的变化,是更好不过了。

重边界

黑盒测试中有专门说到边界值的用例设计方法,这里同样也需要关注边界相关的内容。比如一个循环的第一次和最后一次,一个字符串的最后一个字符,对象的初始化与反初始化等等,这些都是bug产生的重灾区,需要我们重点关注。

重异常

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

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

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

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

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

重动态

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

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

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

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

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

重第三方

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

六、分析耦合

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

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

历史需求A 历史需求B 历史需求C
新需求1
新需求2 ×
新需求3 × ×

七、脑暴异常

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

结束语

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

 

版权所属,禁止转载