欢迎光临
梦想从学习开始!

小解歪果同行对SDK实现自动化测试用例| 小熊测试

本文主要介绍 小解歪果同行对SDK实现自动化测试用例| 小熊测试,小熊希望对大家的学习或者工作具有一定的参考学习价值,在测试领域有所提升和发展。


您现在正在阅读的是由小熊分享邦为您整理的 小解歪果同行对SDK实现自动化测试用例| 小熊测试

  背景

  · 我厂提供的客户端SDK封装了android端对服务端/嵌入式模块端的通信接口;

  · 客户根据自己的功能需求,定制嵌入式端的数据点,利用我们提供的SDK实现跟服务端/嵌入式模块的通信;

  · 客户工程师希望有测试程序来检测/保证SDK与嵌入式端的通信是正常的,方便双方排查问题;

  · 简单来说,该测试程序要拥有调用SDK接口给嵌入式端的发数据并检查其返回数据是否正确的能力,具体发送哪些数据根据客户定制的数据点来决定。

  当那个老外工程师信誓旦旦的说他需要一些测试用例的时候,能够感觉到小伙伴们的状态是懵圈的。因为之前遇到的一般状态是,使用我们SDK开发的客户不管不顾的把功能集成到他们的应用中,最后在调试过程中不停召唤我们帮忙改BUG,最离谱的一次是同事出差到客户那发现是APK打包分包配置不当导致的问题。“测试用例”这种高端词汇,似乎是一个正规军和游击队的分界线。

  实现

  很遗憾到最后我们都没能提供一份测试用例,在我看来主要是没有足够的时间资源导致的。好在那位外国同行表示他已经实现了用例,现在是你们解决问题的时候了。好吧,解决问题没什么——自己写的BUG自己改掉这不算什么,关键是这种白盒测试的工作方式值得学习和借鉴,这里就对客户的实现稍作分析,权做思考和记录。

  分析

  非要下个定义来区分的话,从测试需求来讲,这不是单元测试,虽然可能使用的测试框架是同一个。它是一个白盒的自动化测试用例,和很久以前玩过的界面自动化测试又不大一样,通过模拟页面操作(点击、长按、拖动)来让应用按照测试程序跑起来主要是针对UI的测试,类似于用程序模拟一个测试人员。这里的需求是针对接口的自动化测试,那么可以想象的是,除了正常的功能覆盖之外还可以实现类似压力测试的场景。

  按照开发的习惯,要在实现之前要尽可能的考虑到这之间会遇到什么问题。

  · 站在客户使用SDK的角度而言,SDK是一个黑盒子,我们只知道一些接口和调用限制。具体一些,以发送指令为例,接口初始化实例需要context参数、SDK中必须要包含登陆过的信息、发送指令调用TuyaSmartPanel类的send函数。那么在跑用例之前,如何保证前期准备都是完善的?

  · SDK提供给嵌入式端发送命令信息的接口,不言而喻一定是异步的,那么如何处理嵌入式端返回的数据断言?

  · 自动化测试不像单元测试那样只依赖于被测试代码本身,由于它需要知道真正嵌入式端返回的数据是否正确,所以用例是否能够正确跑起来,还需要硬件、网络环境、测试机器等的支持。那么,如果测试用例作为SDK提供者和使用者两端沟通和认可的交付方式的话,一些必要的准备工作的说明也是不可或缺的。

  类图

  老外实现是这个样子的:

  SDK无论如何都需要一个context,如果是单元测试我们可以考虑mock一个假货传进去,自动化测试就不行。IntegrationService是一个Service子类,所有的SDK相关操作都被封装到这个服务中;

  IntegrationServiceTest是一个抽象类,看到熟悉的setUp和tearDown就知道,这个抽象类封装了测试用例在运行前后的操作,也就是跑用例的环境初始化和跑过之后的清理,更重要的是,它拥有绑定服务获取的实例,调用服务中的接口间接的调用SDK接口;

  其他所有类就是真实的测试用例类,他们是都继承实现于IntegrationServiceTest,封装了针对各个数据点的测试用例;

  异步接口的处理

  异步接口分两步处理,第一步在服务中对接口调用的封装,增加了CountDownLatch限制来等待数据返回;第二步是测试用例定义时增加超时限制。

@Test(timeout=10000)

public void testSwitch_on() throws TimeoutException, InterruptedException {

if((Boolean)mService.getCachedDp("1")){

mService.send("1", "false");

}

dpUpdateReply = mService.send("1", "true");

Log.i(TAG, "testSwitch_on() – dpUpdate dp[1][" + dpUpdateReply.get("1") + "]");

assertEquals("testSwitch_on() – dpUpdate dp[1]", true, dpUpdateReply.get("1"));

}

  服务的send函数,对于用例而言是同步的,传进去输入、拿到输出判断结果即可;在真正的执行过程如果没有返回的话,10秒超时后用例会自动报异常。

  文档对接

  The test suite setup assumes:

  A TuyaSmart e-mail type account is available. If you want to use another account type, you can add the login code for this in class srcandroidTestjavacomextapp uyatestIntegrationService.java .

  Exactly one radiator is already connected to the account.

  外国工程师对文档的描述很详尽,也不?嗦,总之很专业。他会把每一步该做什么、怎么做描述的很清楚。这一点十分值得学习。

  一些细节

  CountDownLatch 类,在这个测试场景下尤为好用,国际友人还专门提了一句:

  java.util.concurrent.CountDownLatch is used for awaiting listeners being triggered and return result to test call. We avoid using Thread.sleep().

  用例设置超时的方法大概有 两种 的样子,除了本例的注解实现意外还可以通过Rules来实现的样子:

  @Rule

  public Timeout globalTimeout= new Timeout(10);

  统一的日志关键字。代码中很少出现注释,易懂的函数/变量命名和统一整齐格式的日志。

  针对SDK的测试用例工程开源到github上,一些敏感信息(如SDK要求的产品key、测试需要的账号/密码等)采用XML配置的方式实现;并且在开源工程中没有放置我们提供的SDK包——保证了对外公布SDK渠道的唯一性。这些信息都做成了可配置的、并且在readMe中做了说明,优雅而专业。

 
 思考

  这位外国同行的解决问题的思路显然更加程式化,更加偏向于用固有宜用的流程来思考,这就显得更加专业。代码实现上也有不少值得借鉴的地方,有此一例照猫画虎,之后针对硬件的命令传输用例的实现就非常方便,甚至可以考虑根据不同的数据点数据类型自动化生成用例代码。并且这种用例工程作为SDK的提供方和使用方的沟通工具也是不错的,能够解决一些使用问题上的误解——使用一方可以提供不通过的用例让提供方修改SDK源码/提供一方也可以通过用例证明SDK本身并无问题。

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持小熊分享邦(www.xxfxb.com),希望大家能坚持软件测试之路,谢谢。

赞(0) 打赏
未经允许不得转载:小熊分享邦 » 小解歪果同行对SDK实现自动化测试用例| 小熊测试

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏