qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

分层设计与分层测试

 分层是复杂软件系统常见的设计思路。比如互联网的七层/五层模型,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、尽早测试。尽早测试是敏捷所提倡的,目的是把问题拦截在前端,降低问题修复成本。由于分层测试不依赖于完整系统,可以通过直接调用底层接口进行测试,就不需要等到整个系统开发完成。其实分层测试的思想和自底向上的系统开发模式也是不谋而合的。
  介绍了这么多分层测试的优势,那么它是万能的银弹吗?首先,分层测试不是端到端的测试,接口之上的部分无法覆盖,因此无法替代验收测试。另外,分层测试依赖于被测系统良好的分层设计,如果被测系统的结构不清晰,耦合严重,分层测试就不合适了。

posted on 2014-04-16 11:01 顺其自然EVO 阅读(578) 评论(0)  编辑  收藏 所属分类: 测试学习专栏


只有注册用户登录后才能发表评论。


网站导航:
 
<2014年4月>
303112345
6789101112
13141516171819
20212223242526
27282930123
45678910

导航

统计

常用链接

留言簿(55)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜