Android测试QQ群讨论交流内容-自动化测试Case粒度、Case耦合性、robotium和robolectric看法

作者 喜力

 

Topic1 Case粒度问题:

Android UI 自动化测试过程中， Case的粒度如何把握？

Case直接的耦合性如何把握？

=============================================

喜力：

根据Case的业务，Ui测试本意不就是模拟用户嘛、所以把每一步都分解，根据Activity，一般相近的功能都会放一起，每个Case中能够单独拎出来的方法都单独拿出来

===========================================

深圳-卡斯

case 保持KISS原则即可

case一般分为四类  线性  结构化  数据驱动  关键字驱动

结构化也就是在线性的基础上增加条件

控制语句

可以让线性case重复执行

提高了容错性能

测试方法黑盒的那套拿来用就好了  具体情况具体套用

用的多的自然是等价类加边界值  以及流程图

自动化测试框架分为三代

第一代 录制回放

第二代 脚本为中心的自动测试

第三代 就是aw为界面的

跟你们说几家公司的自动化产品 去看看 玩玩 就比较懂了

SPIRENT

Compuware

Mercury

Device Anywhere

======================================

上海-imp

KISS原则，keep it simple and stupid ，简单的理解这句话就是，要把一个系统做的连白痴都会用。这就是用户体验的高层境界了，好听的说法也是有的，简单就是美

======================================

北京-承诺

我分三层 ：第一层 常用的方法 例如通过id点击，第二层业务，第三层，脚本调用

Topic2:Ui自动化Case之间的耦合

 

喜力

目前我们做的是Case之间耦合无法避免，因为客户端很多数据依赖，数据不能从Server生产，这样自动化的成本过高。

但是规则是尽量避免~

为何要降低case之间的耦合，不就是为了保证脚本健壮性和可靠性。

我是举个例子，刚刚我说了客户端很多测试，数据是从Server来的，打通Server成本太高。

Mock就又是一个概念了

=================================================

卡斯

流程测试中就会有很多喜力的那种情况

尤其是集成测试

全流程覆盖

必然出现

只要一步错 步步错

Topic3: robotium和robolectric看法

问：你怎么看待robotium和robolectric的优劣啊。。或者针对性上你这方面用的比较多～

喜力 15:58:46

Robotium是通过ui线程进行测试，一般用于对应传统的集成或系统测试；

喜力 15:59:39

Robolectric 是单元测试框架，好处是第一运行在JVM上，速度、性能高；

解决了Android自身因为环境问题的缺点以及减少了许多用Mock的地方~

喜力 15:59:50

两者用处不一样，不好直接比较~

问：恩，对。但我有一个疑问，就是robolectric这个东西，他虽然是一个UT，但是Mock了很多操作，或者业务。而这些东西貌似和功能测试，或者实际的业务更加贴近。但并非真实的象robotium这样，或者说象instrumentation这样去做实际的模拟，但测试的结果和实际的结果差异你觉得大不大

喜力 16:04:52

yes，因为它毕竟是从代码本身去入口测试。打个比方，可能我们用robotium去测试Add contact，1、点击控件、输入内容，断言.但是robolectric,我肯定是直接给一个内容，然后运行方法，断言~

问：恩。。好吧。。。不过robolectric更多的能够从业务的流程角度去做UT，这个还是不错的毕竟服务器，或者说CI上去起模拟器，run test。我这边没有可能实现。。＝ ＝

喜力 16:09:06

我的感官是：第一速度快，CI跑ui test ，我计算过，100条（可能业务还不复杂）也许要1个小时，但是robolectric来搞ut的话 估计能降低几百倍的效率~  ~第二个UI自动化 确定做的太多没意义  少量就行

总结：参与讨论的人太少，或是选择时机不对，讨论深入度不够。