摘要: 分层是复杂软件系统常见的设计思路。比如互联网的七层/五层模型，Android系统的APP/FWK/JNI/Kernel等，都是通过分层、解耦，达到简化问题，易于维护，便于扩展的效果。 传统的黑盒测试主要关注客户需求，白盒 ...
| 分层是复杂软件系统常见的设计思路。比如互联网的七层/五层模型，Android系统的APP/FWK/JNI/Kernel等，都是通过分层、解耦，达到简化问题，易于维护，便于扩展的效果。 传统的黑盒测试主要关注客户需求，白盒测试比较灵活，但实际应用中以验证编码实现为主，两者都忽略了设计这个开发过程中承上启下的环节。分层测试的核心思想是：针对有明确分层设计的软件系统，采用白盒测试的技术，在层与层之间验证接口的正确性。分层测试以调用接口驱动被测系统，尽量不依赖于打桩（具体原因后面会提到）。去年下半年开始我们在Android测试中尝试分层测试，取得了很好的效果。 1、精准。我们都知道，离问题产生的地方越近，就越容易触发问题。如果问题发生在底层，以白盒测试的方法，很难精确打击，特别是一些复杂场景或异常流程，可能无法构造。而分层测试的切入点就是层与层之间的接口，从机制上更接近出问题的地方，因此也更容易命中目标。 2、低成本。这个优势源于可测试性。举例来说：我们要测试Android系统下拨号的性能，黑盒怎么测呢？测试人员需要打开秒表，同时进行拨号的操作，并观测电话是否拨通。操作麻烦不说，误差也很大。如果用分层测试的方式，只要提供拨号和检查是否拨通两个对外开放的接口，通过用例脚本调用，并记录两者的时间，就可以方便准确地得到耗时。更进一步，我们还可以在不同层次的接口调用时均记录下时间，在脚本中直接对各个环节的耗时进行分析，从而自动分析流程的瓶颈，找到影响性能的关键环节。 再回过头来看前面提到的尽量避免打桩的建议，也是考虑到成本。打桩是白盒测试最困难的部分，特别是涉及到复杂的数据类型或者系统内部状态。因此很多开发同事不愿意使用UT。分层测试重驱动弱打桩，测试脚本主要还是运行在真实的测试环境中，这样就避免了打桩上的投入，也更接近开发的调试手段。 3、高效。这里是指用例执行速度快。首先自动化测试的速度就明显优于手工测试，基于API调用的自动化又比UI自动化要快，分层测试的高效就建立在API调用高效的基础上。从我们收集的数据来看，相同的用例，手工执行的耗时平均在5-8分钟，UI自动化一般也需要1-2分钟，而分层测试通常10-20秒就完成了，效率提升达10倍。 4、易定位。易定位其实是和精准对应的。在用例设计的时候就考虑到用例所针对的代码，一旦出现问题，自然就容易定位了。 5、稳定。客户需求是易变的，内部实现也是易变的，但是层与层之间的接口是不同开发人员之间的约定，通常会尽量保持稳定。这里也有一组数据：从Android 4.2到Android 4.4，我们设计的JNI层用例变更不到10%，而针对APP界面开发的用例，变更率高达40%。 6、尽早测试。尽早测试是敏捷所提倡的，目的是把问题拦截在前端，降低问题修复成本。由于分层测试不依赖于完整系统，可以通过直接调用底层接口进行测试，就不需要等到整个系统开发完成。其实分层测试的思想和自底向上的系统开发模式也是不谋而合的。 介绍了这么多分层测试的优势，那么它是万能的银弹吗？首先，分层测试不是端到端的测试，接口之上的部分无法覆盖，因此无法替代验收测试。另外，分层测试依赖于被测系统良好的分层设计，如果被测系统的结构不清晰，耦合严重，分层测试就不合适了。版权声明：本文出自 joe@test 的51Testing软件测试博客：http://www.51testing.com/?15027431原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。 |
