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

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

转自：.html

先mark下，关注：

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

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

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

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

01 一些测试理论

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

 

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

2. 白盒测试、黑盒测试以及灰盒测试的区别:

 

• 黑盒测试是验证应用程序行为准确性的测试;
• 白盒测试是验证应用程序结构准确性的测试;
• 灰盒测试介于黑盒测试和白盒测试之间;
• 黑盒测试和白盒测试，与是否需要写代码无关。

. 自动化测试的特点、目标

 

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

4. 测试策略安排：

 

• 风险优先;
• 成本优先;

5. 代码评审的内容：

 

• 检查风格
• 检查设计
• 发现代码缺陷

6. 关于测试覆盖率：

 

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

---

02 UI自动化测试

1. UI自动化的应用：

 

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

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

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

 

.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;使用VC等多屏幕方式观察server运行结果;

 

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

---

0 单元测试

1.自动化测试的哲学：

 

• 事先测试(TDD)与事后测试
• 针对状态的测试和针对行为的测试;
• 状态测试： 校验应用起始和结束的正确性;
• 行为测试： 校验所依赖的对象行为是否正确;

2.单元测试基础知识：
2.1 测试对象
       类的公有方法; 2.2 单元测试中的白盒测试和黑盒测试
      参看01 一些测试理论 2. 桩模块和驱动模块

 

•  桩模块： 为了让目标类正确运行而设计的支持类;
•  驱动模块： 驱动目标类运行起来的类，比如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使用场合

 

• 控制点： 被测对象依赖的某个类和方法需要实现;
• 检查点： 生成的结果依赖的某个类和方法需要实现;

.可测试性设计：

 

• 依赖注入(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. 测试执行分组：

 

• 使用Test Suite: 分组： 基于功能分组、基于类型分组;
• 使用Annotation分组(junit4或testng);

6.4 测试文件组织：

 

• 测试代码和生产代码放在一起;
• 使用测试包;
• 测试依赖的数据文件：使用相对路径; 

7.单元测试质量：
7.1 度量纬度:

 

• 对业务的代码行覆盖率;
• 测试执行的稳定性;
• 测试运行速度(不超过0秒);

7.2 带来的产品质量提升：

 

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

---

04 接口测试

1.API测试
1.1 方法分类：

 

• 黑盒测试方法： 验证每个API的功能正确性;
• 白盒测试方法： 考虑各个API之间的关联性;
• 场景测试： 场景是应用运行的剖面; API组合方式的测试;

1.2 API接口的解依赖
      stub、mock、fake

 

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

 

.基础项目（支撑其它应用，不直接面向用户）的接口测试

 

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

4.持续集成与构建

 

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

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

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

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

上面的4点，是我对自动化测试目的一个总结，我对自动化是否有意义的判断也是基于上面的认知。当然你也可能会有其它一些想法。 对于上面提到的那个问题, 我觉得还是不好解释，毕竟场景不同，其对应的方案也会不一样。从我现在所在的团队来看，这样的问题，我会从整个项目的周期来判断，下面是目前我们的一个做法，当然并不是很完整，我简单说一下过程。 软件开发流程，大家比较清楚的可能是瀑布流程，敏捷开发这些。不管采用什么样的流程，测试的工作如何接入配合到开发流程中才是最重要的，最关键的。而不是去考虑什么时间去做自动化测试，自动化测试应该是在合适的时间就得开展。 现在，我们不会去区分角，功能测试人员和自动化测试人员应该就是一个人，测试人员应该对应于一个产品，而不是一种技能。 项目前期，kickoff结束，测试同学就应该参与到项目中，对项目的需求进行一定的把握。下面的流程是我们测试的一些关键时间点： 1. 需求评审    这个阶段可以了解项目的背景，并开始和开发，PD沟通一些功能上的设计问题。为后面设计case提供一些思路。 2. 开发设计&&测试用例设计    有些工作并不一定要等到开发全部完成再进行，紧密沟通合作，保证项目向前推进。在开发设计阶段就可以参与进来，并在开发设计完成后，对应完成测试用例的设计，明确哪些case可以实现自动化，并选择好测试框架和工具。 . 分层测试&&可自动化的部分先行    在未得到稳定的测试版本之前，可以准备测试数据，一键部署的脚本，已经对应测试框架，测试代码的编写。不一定要全部完成，但至少准备工作都得做好。 4. 冒烟&&测试执行    提测之前，对部分重点功能进行常规冒烟测试。达到预期后，进行功能测试。这个测试工程中，即可以对一些自动化测试的case进行编码调试，后面这些功能可以在回归执行中有非常大的作用。 5. bugfix版本，自动化回归   对应一些bugfix的版本，除了验证bug之外，还得将之前的功能进行回归，这个阶段，自动化的case将节省不少的精力。 6. 稳定版本，自动化回归，预发环境自动化验证     在发布上线之前，会准备一个稳定的环境，做一次全量的测试执行，当然自动化case也是这个时候的重点。 7. 发布上线，冒烟    待上述测试执行都结束了，意味着项目也就安心上线发布了。这个时候需要简单的冒烟测试即可。 经历这么一个项目的过程，自动化的case肯定是需要占有一定的比例。当然，大家肯定还是存在下面的一些疑问 开发还未提交测试，或者功能也未稳到，如何进行自动化的测试？ 这个问题，我从下面的2点进行解释，其实前面我也有提到这些。          a. 接口测试，待测的接口肯定需要事先定义好，这里更多的应该是测试数据的准备，已经测试类的编写，case的逻辑可以体现出来，当然调试case需要放到功能开发出来，但是我们的准备工作要都搞定。     b. UI自动化，大家都会说页面还没出来，怎么写？道理是一样的，设计出来的场景是事先通过需求文档，交互PRD这些进行确认过的，同样，需要的测试数据可以先准备出来，代码的逻辑也可以写出一部分，这个时候缺的应该就是页面元素。 如果设计的合理，我们的case应该做到测试数据和测试代码进行分离，这样你需要的部分可以配置为参数的形式，后期传入    现在，在阿里不管是接口测试还是UI自动化，基本上都是在与开发同步进行，我们需要将自动化的作用最大化，提高测试的效率。  所有，我最终的建议是尽量提前来做，将自动化的价值最大化。