自动化和手工测试的区别

自动化测试用例最擅长回答的问题是“软件系统是否按照我们预先设计的方式正确运行了？”，而这里的“预先设计”也是由工程师编写代码完成检查条件的设定的。因此，自动化测试主要用于软件功能的批量回归验证，是一种机械式且重复性的验证工作，而这正是机器所擅长的。相反，手工测试的最核心价值在于回答“我们是否正在开发一个正确的、满足用户期望的软件系统？”，因为在手工测试过程中，我们可以主动观察、学习和分析，进行更具有创造性的工作，例如探索测试、用户友好性验证或者用户体验的改善。这种类型的工作是机器不擅长的，目前也无法由机器来做。

增加自动化测试用例的着手点

1、针对代码热区不吃自动化测试用例 2、跟随新功能开发的进度 3、从测试金字塔的中间层向上下两端扩展 4、自动化测试用例的质量比数量重要，其次，不要在不同层级的测试（例如单元测试层和组件测试层）中，针对相同的逻辑编写测试用例。

良好自动化用例的特征

1、用例之间必须相互独立 2、测试用例的运行结果必须稳定 3、测试用例的运行速度必须快

测试用例数应保持低位

正如前面我们讨论过的测试金字塔所指出的那样，处于顶层的用户验收自动化测试的数量不应该太多。那么，这么少的测试数量，应该覆盖哪些场景？验证的重点是什么? 首先，用户验收自动化测试应该以用户旅程地图（User Journey Map）的方式来验证 软件应用或服务的核心工作流程。用户旅程地图是指一系列的主要交互过程，它们从用户 角度出发，以叙述故事的方式描述用户与软件产品之间的交互。 用户验收自动化测试应该验证软件应用或服务的端到端行为，而非具体实现细节。例如，当验证系统登录行为时，其验证的目标主要是验证整个登录流程是否得到正确执行，而不是验证输入信息是否非法，因为后者可以通过更低层次（且更低成本）的自动化测试用例来覆盖。

为自动化测试用例预留API

在编写这类测试用例时，应该尽量调用位于界面下层的API来驱动业务流程的执行，而少用模拟图形界面操作的代码。图形界面是给人类交互使用的，并不是给机器使用的。界面操作通常反应比较慢，且很多情况下不容易定位界面元素，容易出现运行不稳定的代码。 这要求在程序设计时就考虑到端到端自动化测试的便捷性，支持相应的API驱动方式。例如，你可以使用界面在系统上创建一个登录账户，同时也应该能够通过REST-API创建账户，有时甚至为了自动化测试的便利性，也应该增加必要的API，只是不对外开放这类API。在生产环境上发布时，也可以通过技术手段隐藏或去除这些API。

自动化测试策略和方法小结

前置周期（lead time）是精益生产管理中的一个概念，它是指从用户下订单开始到其收到产品之间的时间周期。这个时间周期越短，说明交付效率越高，越能提升客户的满意度。 对交付频率的要求越高，希望前置周期越短，自动化测试就越为重要。我们讨论了软件快速交付对自动化测试的4项基本要求，即快速、便捷、可信和及时。为了能够做到这4点，我们以分层的自动化测试金字塔为指导，合理设计自动化测试的实施策略，从而增加自动化测试的收益。对自动化测试的实践管理来说，希望大家能够记住5条重要原则。 （1）自动化测试用例运行次数越多，平均成本越低，收益就越大。 （2）自动化测试用例之间应该尽可能相互独立，互不影响。 （3）在质量有保障的前提下，自动化测试用例的数量越少越好。 （4）遗留代码的自动化测试编写应该从代码热区开始。 （5）自动化测试用例从测试金字塔的中间层开始补充，投入产出比最高。