《Just Enough Software Test Automation》读书笔记.doc

书附带资源下载： /mosley/ 自动化需要达到什么程度才足够？ 1、什么测试类型能够自动化？ 2、应该考虑测试过程的哪些方面？ 所有领域的自动化水平应该达到这样一种程度，它能够根据时间和成本适应于你的组织。实现的自动化程度越高，你的测试过程就越好越有效。 开发自动化测试框架是一个费钱而且费时的项目。这个框架的创建和实现必须在AUT交付QC（Quality Control，质量控制）之前完成，因此得在该项目的生命周期的早期阶段构建并测试。然而，一旦使用该框架，你可能会发现它不适合你的组织所有的软件测试需要。了解何时使用这样一个框架是测试自动化重要的部分。 测试自动化是一项投资。最初的投资可能很多，但投资的回报也很丰厚。自动化测试运行超过15次以后，测试就是免费的了。 - Hancock 很少有公司完全意识到自动化测试的价值。他们想拥有，也知道他们需要，但最后他们不能让上层管理者信服其成本收益。 普遍接受的看法是自动化测试要花费执行手工测试的3~4倍的时间。如果你能在项目早期预先判断会有超过3~4个重要的可测试构建版本交付给你，那么你的项目就可以选择自动化测试。 是否进行自动化测试的判断准则： 1、如果AUT不复杂而且不太大，那么不要自动化。 2、如果你只将接收几个（3个或更少）构建版本，不要自动化。 3、如果一个特征不是100%有效，不要对它执行自动化测试，不管该AUT的规模或复杂度如何（你可以为它制定计划，但不要创建真的自动化测试脚本，除非该特征能够完成并100%有效）。 4、如果开发周期的时间表很紧，每次交付间隔时间很短，你就没有时间自动化。 5、如果一个特征不能通过自动化测试达到100%准确测试，就不要进行自动化了，除非它能节省大量的手工测试时间。这并不意味着特征必须要100%的测试。注意软件测试几乎不可能覆盖到AUT的每个特征。不要妄图达到这个目标。你执行的测试不应该是主观的。结果应是可预见的，而且应该能指出通过或失败的条件。 对什么进行自动化测试？ 实践表明平均可对整个项目的60%进行自动化，你的目标应该是自动化测试AUT的关键路径。首先，对目标用户将要执行的基本功能进行自动化。如果时间允许，慢慢地但是要确定地加入该应用程序不太关键的部分。一定要开发测试覆盖矩阵，一个轴显示需求，另一个显示已开发测试，以便始终可以清楚地看到什么进行了自动化，什么没有进行自动化。 自动化测试是你的保障，因为它就是用来验证曾经正确工作的部分仍然还在正确工作。 自动化测试脚本/数据设计规则： 1、设计相互独立的测试用例 2、设计自包含式（self-contained）的测试用例 3、设计基于出发点的（home-based）的测试用例 4、设计无重叠的测试用例 测试用例的独立性能够保证一个测试用例不依赖另一个用例的成功完成来运行（它不依赖于前一个测试用例的结果），它也确保了即使在无人干预的情况下，自动化测试套件也能得出结果。 在每一个测试场景中，测试脚本应该包含以下几个部分： 进行设置 进行测试 验证结果 记录结果 处理意外情况 决定停止还是继续测试用例 进行清理工作 Zambbelich将脚本任务分成了以下的几个必要区域： 1、GUI屏幕导航 2、特殊的业务功能 3、数据验证 4、返回导航 结构化脚本的级别： 菜单/命令级 – 执行简单的命令 对象级 – 执行特定事件的动作 任务级 – 关注特定的通常是重复的任务 一般封装哪些函数？ 1、为AUT的所有功能特征编写测试函数 2、为自定义控件编写函数 3、为特定语言命令编写包装器函数。 4、为使用频繁的任务编写函数 5、为多个测试脚本使用的大型复杂任务编写函数 项目级自动化测试失败和终止的首要原因是最终不能正确维护自动化测试脚本。大规模AUT经常有改变发生，经常有新的或额外的功能集成，所以尤其会出现这种情况。 测试脚本维护的一般问题和解决方法： 1、问题：数据输入 解决方法：使用输入数据文本文件 2、问题：程序流改变 解决方法：让输入数据做驱动 3、问题：管理应用程序改变 解决方法：录制或修改非常小的一部分代码 大多数情况下，在数据输入域上双击是首选的选择方法，而且比起单击对象来，双击通常更有必要，双击选择这个域中的所有数据，这样就能让新数据完全替代旧数据。 Or： 光标置于控件中 – HOME – Shift+End – Delete Or： Set “” 维护一套自动化测试程序本身就是一份占用大量时间的工作。的确如此，即使是简单的模块/界面测试也需要成百上千行的测试脚本。 如果不对开发者在分析和设计过程中插入改变的状况进行控制，那么为赶上变化而不断进行的脚本更新会使你发疯！