自动化测试与自动化测试介入时机

转自：http://blog.sina.com.cn/s/blog_6c9670bb0101sl97.html

先mark下，关注：

1、各类测试理论定义，相应工具

2、现在，在阿里不管是接口测试还是UI自动化，基本上都是在与开发同步进行，我们需要将自动化的作用最大化，提高测试的效率。

所有，我最终的建议是尽量提前来做，将自动化的价值最大化。

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

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.持续集成与构建

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

自动化测试是在开发阶段就介入呢，还是等手工测试结束之后，系统功能稳定后，介入？

当时没时间去回答，就找了以前在淘测试上看到的一篇文章发给他了。回到家之后，我在跑步机上想了下这个问题，现在我在做的自动化测试，会怎么去判断准入条件呢？

首先，搞清楚自动化的目的是什么？

提供工作效率，运行自动化测试用例可以同时做其他的工作，而且测试效率有了提升，大量case可同时运行
提供运行的准确性和稳定性，避免外界因素的影响
避免重复劳动，防止大量的手工回归测试，节省成本
对测试人员而言，也是提高技能的一种手段

上面的4点，是我对自动化测试目的一个总结，我对自动化是否有意义的判断也是基于上面的认知。当然你也可能会有其它一些想法。

对于上面提到的那个问题, 我觉得还是不好解释，毕竟场景不同，其对应的方案也会不一样。从我现在所在的团队来看，这样的问题，我会从整个项目的周期来判断，下面是目前我们的一个做法，当然并不是很完整，我简单说一下过程。

软件开发流程，大家比较清楚的可能是瀑布流程，敏捷开发这些。不管采用什么样的流程，测试的工作如何接入配合到开发流程中才是最重要的，最关键的。而不是去考虑什么时间去做自动化测试，自动化测试应该是在合适的时间就得开展。

现在，我们不会去区分角色，功能测试人员和自动化测试人员应该就是一个人，测试人员应该对应于一个产品，而不是一种技能。

项目前期，kickoff结束，测试同学就应该参与到项目中，对项目的需求进行一定的把握。下面的流程是我们测试的一些关键时间点：

1. 需求评审

这个阶段可以了解项目的背景，并开始和开发，PD沟通一些功能上的设计问题。为后面设计case提供一些思路。

2. 开发设计&&测试用例设计

有些工作并不一定要等到开发全部完成再进行，紧密沟通合作，保证项目向前推进。在开发设计阶段就可以参与进来，并在开发设计完成后，对应完成测试用例的设计，明确哪些case可以实现自动化，并选择好测试框架和工具。

3. 分层测试&&可自动化的部分先行

在未得到稳定的测试版本之前，可以准备测试数据，一键部署的脚本，已经对应测试框架，测试代码的编写。不一定要全部完成，但至少准备工作都得做好。

4. 冒烟&&测试执行

提测之前，对部分重点功能进行常规冒烟测试。达到预期后，进行功能测试。这个测试工程中，即可以对一些自动化测试的case进行编码调试，后面这些功能可以在回归执行中有非常大的作用。

5. bugfix版本，自动化回归

对应一些bugfix的版本，除了验证bug之外，还得将之前的功能进行回归，这个阶段，自动化的case将节省不少的精力。

6. 稳定版本，自动化回归，预发环境自动化验证

在发布上线之前，会准备一个稳定的环境，做一次全量的测试执行，当然自动化case也是这个时候的重点。

7. 发布上线，冒烟

待上述测试执行都结束了，意味着项目也就安心上线发布了。这个时候需要简单的冒烟测试即可。

经历这么一个项目的过程，自动化的case肯定是需要占有一定的比例。当然，大家肯定还是存在下面的一些疑问

开发还未提交测试，或者功能也未稳到，如何进行自动化的测试？

这个问题，我从下面的2点进行解释，其实前面我也有提到这些。

a. 接口测试，待测的接口肯定需要事先定义好，这里更多的应该是测试数据的准备，已经测试类的编写，case的逻辑可以体现出来，当然调试case需要放到功能开发出来，但是我们的准备工作要都搞定。

b. UI自动化，大家都会说页面还没出来，怎么写？道理是一样的，设计出来的场景是事先通过需求文档，交互PRD这些进行确认过的，同样，需要的测试数据可以先准备出来，代码的逻辑也可以写出一部分，这个时候缺的应该就是页面元素。

如果设计的合理，我们的case应该做到测试数据和测试代码进行分离，这样你需要的部分可以配置为参数的形式，后期传入

现在，在阿里不管是接口测试还是UI自动化，基本上都是在与开发同步进行，我们需要将自动化的作用最大化，提高测试的效率。

所有，我最终的建议是尽量提前来做，将自动化的价值最大化。