自动化测试

二 23rd, 2014

很长时间,一直都在做自动化相关的事情,包括测试框架,测试平台,以及持续集成等等。但是这些的基础还是依靠优秀的自动化测试代码,下面的内容就是自动化测试的相关知识点,相信大家可以从这些点中可以找到很多的共鸣,然后扩展,方便大家更好的深入学习。

01 一些测试理论

1. 测试分类的三维模型:

  • 以时间趋势为基线的分类,如系统测试,集成测试…
  • 以测试方法为基线的分类,这种分类是面向质量体系的,如功能测试、性能测试、安全测试…
  • 以测试目标为基线的分类,如白盒测试、黑盒测试、灰盒测试。
2. 白盒测试、黑盒测试以及灰盒测试的区别:

  • 黑盒测试是验证应用程序行为准确性的测试;
  • 白盒测试是验证应用程序结构准确性的测试;
  • 灰盒测试介于黑盒测试和白盒测试之间;
  • 黑盒测试和白盒测试,与是否需要写代码无关。
3. 自动化测试的特点、目标

  • 特点:使用机器和程序的能力
  • 目标:减少资源消耗;扩大测试范围;充分发挥人和机器的能力;
4. 测试策略安排:

  • 风险优先;
  • 成本优先;
5. 代码评审的内容:

  • 检查风格
  • 检查设计
  • 发现代码缺陷
6. 关于测试覆盖率:

  • 要被测试的代码都需要被覆盖到

02 UI自动化测试

1. UI自动化的应用:

  • 一般用于测试回归;
  • 覆盖越多的业务越好;
  • 衡量成本和收益:人工回归与自动化方式的投入和效率对比

2. UI自动化的缺陷:
     非视觉,即无法模拟人眼睛能够看到的内容,如长度超出、不适当的留白或换行。

3. UI自动化的方案:
3.1 基于Javascript的方案
       优点:跨浏览器; 缺点:无法操作浏览器本身;
       selenium core : 脚本必须与被测应用放在同一域名下;
       selenium RC : 请求发送到seleniumServer,seleniumServer转换请求客户端的域名为被测应用的域名,被测应用响应后,seleniumServer再转换被测应用的域名为请求客户端的域名;

3.2 基于浏览器的方案
      优点:对浏览器操作性好; 缺点: 浏览器兼容性差;
      方案实现工具: webDriver 、watir 、pamIe

4. 工具简介:
     webDriver : 支持非标准组件; 容易捕获模式窗口; 可以设置代理服务器;
     selenium 2.0 : 集成了Javascript和webDriver两种方式;

5. UI自动化测试的级别:
5.1 Dom级别
     操作方式:parse页面获取dom属性;
     访问dom对象的方法:根据xpath访问;根据id属性访问;根据name属性访问;
     IE6对xpath的访问方式支持性极差;
     dom级别的缺点:不能校验用户体验细节,如重叠、超出范围、不合适的留白等;
5.2 基于图像的级别
    限制条件:使用模板针对页面布局的校验;人工判断图像差异性;页面上需要保持固定的数据;针对页面上的固定区域;提供灵活的图片解析算法;
    基于mask的图片比较:将不需要比较的图片区域用黑色覆盖;
    判断图片是否存在于页面的某个位置;
    排除字体和显示差异:允许图片缩放、用ocr识别文本、设计和实现字体识别;
    镂空文字保留图像以便比较布局;提取页面文字以便校验数据;

6. Diff技术:
6.1 Diff技术的应用
      发现变化;
          基于人工判断该变化是否是预期的变化;
          根据diff结果,决定变化的技术和方法;
6.2 Diff的工作原理
     通过同时发送相同请求到不同版本的同一个应用,对比发现两者之间的变化,确定测试范围;
     对比时屏蔽一些已知的、明显的不同;
     对比时屏蔽噪音(即无用的信息);

7. 支持多浏览器的手工测试:
    在不同的浏览器中展示相同的页面,发现不同;
    在其它浏览器上重现操作;
    基于实时交互的方案:多台机器各安装不同的浏览器,并安装seleniumServer;另外一台seleniumClient分别发送请求到各server;使用VNC等多屏幕方式观察server运行结果;

8. UI自动化测试的执行测略:
     不依赖IDE;
     和持续集成、构建脚本一起工作;
     运行失败时截图,直接查看失败细节;
     使用selenium集群,通过统一接口访问多台server.
     专门的图片比较服务器;
     避免内外有别:测试结果尽量和用户结果一致;测试可以从线上发起,在线上建立proxy server,根据规则决定访问线上还是测试环境;
9. 经验分享:
     识别应用特点:用了哪些技术,哪些是易变的,哪些是稳定的,哪些可以使用自动化方法;
     在设计时考虑测试,设计评审时的可测性考虑,良好的应用隔离,清晰的分层结构,易于控制,具备标识;
     图片比较方式经验谈,图像比较测试、基于图像diff发现改变,在发生异常时截屏,以图像记录结果。

03 单元测试

1.自动化测试的哲学:

  • 事先测试(TDD)与事后测试
  • 针对状态的测试和针对行为的测试;
  • 状态测试: 校验应用起始和结束的正确性;
  • 行为测试: 校验所依赖的对象行为是否正确;
2.单元测试基础知识:
2.1 测试对象
       类的公有方法;
2.2 单元测试中的白盒测试和黑盒测试
      参看01 一些测试理论
2.3 桩模块和驱动模块

  •  桩模块: 为了让目标类正确运行而设计的支持类;
  •  驱动模块: 驱动目标类运行起来的类,比如junit。
2.4 单元测试工具
      junit 、testng

2.5 控制点和检查点

  • 控制点:直接输入(参数); 间接输入(控制返回值和状态);
  • 检查点: 直接输出(值和状态); 间接输出(行为);
2.6 测试替身(Test Double)
      类型: Dummy Objects、Test Stubs; Test Spies、 Mock Objects 、Fake Objects

  • Dummy Objects : 测试时用于填充且不做任何事情的对象。
  • Test Stubs: 替换被测代码内部依赖的方法;
  • Test Spies: 记录测试运行的日志,比如记录次数;
  • Mock Objects : 充当Stub;和充当spies;
  • Fake Objects : 生成一个专用于测试的类,实现测试中需要的方法; 应用场合: 对象所依赖的对象还未实现; 对象所依赖的对象过于复杂;
 
2.7 Mock使用场合

  • 控制点: 被测对象依赖的某个类和方法需要实现;
  • 检查点: 生成的结果依赖的某个类和方法需要实现;
3.可测试性设计:

  • 依赖注入(Dependency Inject):将内部依赖改为外部传入(参数注入、构造注入、设置函数注入),设置缺省值;
  • 依赖查找(Dependency Look): 在不改动原代码的情况实现注入, 使用factory模式,使用服务定位器(service locator),使用Factory生成测试替身;
  • Humble Object:在被测对象之上再封装一层,将所有被测对象的依赖全部放入封装对象里,即Humble Object,
  • 测试钩子(test hood) :在被测对象中写一段利于测试的代码,如条件判断是否走生产代码还是测试代码;
4.如何让代码可测试:

  • 感知: 感知某些方法调用产生的效果和影响,主要工具:fake object 和 mock object;
  • 分离: 将应用其它部分分离并单独运行,解依赖技术(代码重构):参数适配、提取并重写工厂方法、封装全局应用、接口提取、实现提取;
5.数据库单元测试:

  • 测试存储过程: 使用SQLUnit、utPLSQL;
  • 数据库存取测试:仅针对存和取进行测试,用Fake Object模拟数据库;
6.组织和管理单元测试:
6.1 几种可行的单元测试管理方式:

  • 一个生产类一个测试类;
  • 一个功能一个测试类;
  • 一个fixture一个测试类;
6.2 测试类命名方式:
      test+方法名+期望值
6.3 测试执行分组:

  • 使用Test Suite: 分组: 基于功能分组、基于类型分组;
  • 使用Annotation分组(junit4或testng);
6.4 测试文件组织:

  • 测试代码和生产代码放在一起;
  • 使用测试包;
  • 测试依赖的数据文件:使用相对路径; 
7.单元测试质量:
7.1 度量纬度:

  • 对业务的代码行覆盖率;
  • 测试执行的稳定性;
  • 测试运行速度(不超过30秒);
 
7.2 带来的产品质量提升:

  • 缩短产品发布周期;
  • 和系统测试阶段对比发现缺陷的数量;
 

04 接口测试

 
1.API测试
1.1 方法分类:

  • 黑盒测试方法: 验证每个API的功能正确性;
  • 白盒测试方法: 考虑各个API之间的关联性;
  • 场景测试: 场景是应用运行的剖面; API组合方式的测试;
1.2 API接口的解依赖
      stub、mock、fake

2.Http接口的web测试
    使用WebDriver的htmlDriver、htmlUnit;

3.基础项目(支撑其它应用,不直接面向用户)的接口测试

  • 建立接口级别的测试集;
  • 设立可被其它应用访问的最新版本的测试环境;
  • 建立测试环境的持续集成环境;
4.持续集成与构建

  • 对测试进行持续集成和持续构建,监控应用的变化,确定测试范围;
  • 完成系统测试和集成测试后,才进行持续集成。
 





除非注明,本站文章均为原创。本文基于 BY-NC-SA 协议进行授权,欢迎转载,演绎或用于商业目的,但是必须保留本文的署名 metaboy(包含链接).

本文链接地址: http://blog.wangyuxiong.com/archives/52292

订阅本站:http://www.wangyuxiong.com/feed

  1. metaboy
    二 26th, 201400:04

    11年的时候,我做过一件事情,对php unit做过一些封装(http://phpunit.de/),在项目中使用的还不错,后面我找出来可以给你参考下。

    你对自动化测试对你们小团队有没有用处,这个肯定是有用处的。但是我可以感觉为你对测试的目的或者说是测试的对象有些迷惑, 或许你认为代码都是自己写的,有没有问题自己很清楚,又没有用到别人的代码或者将自己代码给别人调用,写这些测试就是在浪费时间?
    这些疑问,其实就是搞乱了自动化测试的本质。我觉得自动化测试最主要的目的其实是保护已有代码的正确性、我们写出来的代码,随着积累,会不断的被修改,增加新的逻辑。如果没有测试代码,我们无法保证这些改动对现有逻辑不会产生大的影响。

    当然从成本上来说,你们需要的不是什么大的测试框架或工具,使用现有的phpunit写一些单元测试,通过一些脚本来做build或者执行的工作即可。

  2. 另一个自由职业者
    二 23rd, 201420:07

    请问博主有没有关于php自动化测试和持续集成的一些资料和工具。能不能写博客介绍一下,我是做wordpress主题和插件的,现在自由职业,不知道自动化测试和持续集成对我这种个人或者2人团队有没有用呢。

无觅相关文章插件,快速提升流量