归档文章: Functional Testing

将本地的http请求转发到fiddler或其他的代理服务器上

服务器间请求时的debug, 通常通过日志分析。 日志量大, 以及日志不完全,非常不利于debug分析定位问题。  通常我们使用抓包工具进行。 但如果我们的服务器之间的协议主要是http 应用层, 则可以使用更灵活的方式。

如果使用tcpdump wireshark等抓包工具, 虽然也可以将所需要的数据抓取并分析。 而且可以抓到更底层的数据。 唯一不方便的是,无法进行mock数据进行返回。 抓包是将网络中的包抓取并拷贝一份, 不同于代理服务,则可以进行man in the middle  工具。 同时也可以利于我们debug和方便的mock测试数据,用于测试工作。  更多…

appium简单总结(一)

从最早做过一些instrumentation的android 白盒测试后,熟悉过一些robotium , monkeyrunner自动化后, 一直对android自动化没有再关注。这些日子抽空研究了下appium。 更多…

安桌自动化测试(robotium)

it’s like Selenium, but for Android™.
转自 http://blog.csdn.net/zhangren07/article/details/6365545

刚好前段时间也研究了一下Android的自动化测试框架。感觉用起来还是比较方便的。
几点体会也一起和大家交流下,有一些内容还在慢慢学习中:
1.Java5(2004-10)开始推出了Instrumentation,这是一个可以在main之前Java虚拟机加载类时改变Java类字节码或类classpath等内容的工具,同时JDK1.6还提供了运行过程中的动态改变,如在方法执行前后加入度量时间的代码,使Java代码可度量就是一个很典型的应用。不过这需要涉及到Java字节码有较深入的理解进行字节码直接编辑改写,或者需要借助开源字节码项目如bcel,ASM或javassist等,以简化对字节码的操作。
2.Instrumentation与Btrace。Btrace是基于Instrumentation和ASM的,只要理解了Instrumentation的原理和ASM对字节码的操作原理,了解Btrace就不困难了。
3.Android的测试框架robotium框架,使用的类也是Instrumentation,其原理应该也类似。为某工程新建了一个测试工程,在安装原有工程项目时,也将测试的工程项目安装到AVD(模拟器)上面,同时通过测试的工程项目来与运行时的项目交互,触发其组件的动作等。这种方法的缺点是要求两个项目同时安装到AVD上面。Google将会考虑采取Remote Control的方式实现自动化测试框架,类似于selenium的Remote Control,即在AVD上运行一个监控程序,而测试项目只需要连接这个监控程序,并发送相应的指令即可与程序进行交互,进行测试。希望早日实现这种方式~,目前的自动化测试使用前种方法也可。Robotium其底层仍是采用Android的Instrumentation!
4.Android的Instrumentation对某个监控程序进行交互时,其大致采用如下步骤:
1)启动时将项目配置文件AndroidManifest.xml文件中的instrumentation标签中的内容进行初始化,其中标明了所使用的测试运行类,目标项目的包名等
2)执行测试时(可用adb命令触发),将启动目标应用的Activity,同时将待测试ActivityThread作为一个引用进行初始化,如果找不到目标应用则会报错
3)在测试时测试项目的任何对目标项目进行的操作,都会用异步的方式,将消息体放在目标程序的MessageQueue里面,这样目标程序在看到自己的MessageQueue里有内容时,就会执行之。
整个初始化过程还有待研究,关键应该是在于AndroidManifest.xml文件中内容的标识

软件自动化测试

测试在软件周期中,起着至关重要的作用。 自动化测试可以进行单元测试,功能测试,性能测试。

自动化测试可以节省人力、时间或硬件资源,提高测试效率。但自动化测试必须有一些前提条件。

 1) 软件需求变动不频繁。
  测试脚本的稳定性决定了自动化测试的维护成本。如果软件需求变动过于频繁,测试人员需要根据变动的需求来更新测试用例以及相关的测试脚本,而脚本的维护本身就是一个代码开发的过程,需要修改、调试,必要的时候还要修改自动化测试的框架,如果所花费的成本不低于利用其节省的测试成本,那么自动化测试便是失败的。
  项目中的某些模块相对稳定,而某些模块需求变动性很大。我们便可对相对稳定的模块进行自动化测试,而变动较大的仍是用手工测试。

 2) 项目周期足够长。
  自动化测试需求的确定、自动化测试框架的设计、测试脚本的编写与调试均需要相当长的时间来完成,这样的过程本身就是一个测试软件的开发过程,需要较长的时间来完成。如果项目的周期比较短,没有足够的时间去支持这样一个过程,那么自动化测试便成为笑谈。

 3) 自动化测试脚本可重复使用。
  如果费尽心思开发了一套近乎完美的自动化测试脚本,但是脚本的重复使用率很低,致使其间所耗费的成本大于所创造的经济价值,自动化测试便成为了测试人员的练手之作,而并非是真正可产生效益的测试手段了。
  另外,在手工测试无法完成,需要投入大量时间与人力时也需要考虑引入自动化测试。比如性能测试、配置测试、大数据量输入测试等。