对软件系统分层测试的初探

何伟文

(广州南洋理工职业学院，广东 广州 510510)

一、分层测试_基本思想

分层是复杂软件系统常见的设计思路。比如互联网的七层/五层模型，Android系统的APP/FWK/JNI/Kernel等，都是通过分层、解耦，达到简化问题，易于维护，便于扩展的效果。分层测试以调用接口驱动被测系统，尽量不依赖于打桩。

按照V模型进行划分层次：单元测试；集成测试；系统测试；

unit层的测试对象是函数或方法；service层的测试对象是模块和接口；UI层的主要测试对象是展示和交互。

unit层的测试策略：

1、代码走查：开发人员自己检查自己的代码

2、代码评审code review：开发团队组织评审会，应避免走马观花，应注重效率

3、单元测试：自动化单元测试，编写测试代码或使用测试工具，缺点：入门门槛高，没有好的实践方法（覆盖率和编写标准），则可能无法推行，最终沦为鸡肋或是诟病。优点能尽快的执行，降低测试成本，复用性好，可反复执行。

我们需要规范的来做单元测试同样需要相应的单元测试框架，如java的Junit、testNG，C#的NUint，Python的unittest、pytest等，几乎所有的主流语言，都会有其对应的单元测试框架。

service层的测试策略：自动化的组件测试；自动化的集成测试；自动化的API测试与单元测试比较：运行速度慢，测试环境搭建困难，case数量较少。

UI层的测试：大部分测试人员的大部分工作都是对UI层的功能进行测试。例如，我们不断重复对一个表单提交，结果查询等功能进行测试，我们可以通过相应的自动化测试工具来模拟这些操作，从而解放重复的劳动。

UI层的测试策略：

手工测试：纯手工测试执行速度慢，无法重复使用；

自动化测试：稳定模块，与其它层面的测试比较：自动化开发难度大，运行速度慢，测试环境搭建困难。

这样我们可以做到单元测试尽量多做，UI级的测试可以少做一点；因为UI测试难度相对较大；UI测试更接近于真实用户；手工UI测试只占据了塔顶一点点的位置，而大部分的测试工作是手工测试人员所难以介入的，这让只会手工测试的人有一定的危机感；

开发人员是质量保障的最关键因素，因为测试金字塔的大部分测试工作都需要开发或者是具备开发技能的技术员去完成；

测试金字塔是稳固的，如果按照测试金字塔的模型去组织测试工作的话，在一切相对正常的情况下，产品/项目/系统的质量是处在可控的状态下的。

现实生活中能做到测试金字塔的团队往往是少数，大部分测试技术员接触到的团队应该是倒三角的，也就是没有或只有少量的单元测试，随心所欲做一些接口测试，把大量的人力集中在UI测试。这样的产品质量往往难以控制或者需要花费大量的时间和人力成本才能控制。

有一些的产品刚横空出世的时候往往是没有单元测试和UI自动化测试的，但这些产品刚发布时的质量却是可以接受的或者甚至是优秀的，这是为什么呢？这是因为这些产品往往由天才的开发者创建或实现，天才的代码在不做单元测试的情况下也是质量可期的，这就等于是测试金字塔的最底层相当牢固，整个产品质量就自然由保障了；另外这些产品发布的初期规模也相对较小，也比较难出现一些在频繁协作过程中会出现的问题（比如修改了不是自己写的代码而造成了缺陷），规模小质量控制起来也相对容易些。

总而言之，如果你的产品/项目/系统的开发团队大部分人都不是天才而且需要进行频繁协作的话，按照测试金字塔模型去做可能是一个比较好的方式。

二、分层测试的好处

（一）精准。我们都知道，离问题产生的地方越近，就越容易触发问题。如果问题发生在底层，以白盒测试的方法，很难精确打击，特别是一些复杂场景或异常流程，可能无法构造。而分层测试的切入点就是层与层之间的接口，从机制上更接近出问题的地方，因此也更容易命中目标。

（二）低成本。这个优势源于可测试性。举例来说：我们要测试Android系统下拨号的性能，黑盒怎么测呢？测试人员需要打开秒表，同时进行拨号的操作，并观测电话是否拨通。操作麻烦不说，误差也很大。如果用分层测试的方式，只要提供拨号和检查是否拨通两个对外开放的接口，通过用例脚本调用，并记录两者的时间，就可以方便准确地得到耗时。更进一步，我们还可以在不同层次的接口调用时均记录下时间，在脚本中直接对各个环节的耗时进行分析，从而自动分析流程的瓶颈，找到影响性能的关键环节。

（三）高效。这里是指用例执行速度快。首先自动化测试的速度就明显优于手工测试，基于API调用的自动化又比UI自动化要快，分层测试的高效就建立在API调用高效的基础上。从我们收集的数据来看，相同的用例，手工执行的耗时平均在5-8分钟，UI自动化一般也需要1-2分钟，而分层测试通常10-20秒就完成了，效率提升达10倍。

（四）易定位。易定位其实是和精准对应的。在用例设计的时候就考虑到用例所针对的代码，一旦出现问题，自然就容易定位了。

（五）稳定。客户需求是易变的，内部实现也是易变的，但是层与层之间的接口是不同开发人员之间的约定，通常会尽量保持稳定。这里也有一组数据：从Android 4.0到Android 5.0，我们设计的JNI层用例变更不到10%，而针对APP界面开发的用例，变更率高达40%。