背景
　　· 我厂提供的客户端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，封装了针对各个数据点的测试用例；