做好自动化测试的15个实践原则

做好自动化测试的15个实践原则 何勉 2 何勉，上海贝尔公司精益和敏捷教练，曾任软件工程师、项目经理、部门经 理等职。 目前主要关注： - 产品开发中的价值发现、澄清和验证过程，实践和综合各类方法提高这一过程的 有效性，如实例化需求（SBE）和影响地图（Impact Mapping）等。 - 精益产品开发和看板方法的实施，是Agile China 2013“精益和看板”模块的制作人， 兼任大会程序委员会主席。 - 精益创业和精益用户体验设计，帮助中小创新型企业落实相关实践 自我介绍自我介绍自我介绍自我介绍 什么是好的自动化测试什么是好的自动化测试什么是好的自动化测试什么是好的自动化测试？ 易于理解理解理解理解 易于创建创建创建创建 易于维护维护维护维护 足够的覆盖覆盖覆盖覆盖 足够的效率效率效率效率 大纲大纲大纲大纲 1. 原则 1 - 5:关于测试集的组织 2. 原则 6 -10: 关于测试用例的设计 3. 原则11-15: 关于测试活动的管理 后面出现的例子基于的工具后面出现的例子基于的工具后面出现的例子基于的工具后面出现的例子基于的工具 Robot Framework 测测测测试试试试集集集集 Test Suite 测试用例测试用例测试用例测试用例 Test Cases 脚本脚本脚本脚本 Scripts 原则原则原则原则 1 5: 关于测试集的组织关于测试集的组织关于测试集的组织关于测试集的组织 原则原则原则原则1: 把测试锚定到需求上把测试锚定到需求上把测试锚定到需求上把测试锚定到需求上 按照需求的结构来组织自动化测试按照需求的结构来组织自动化测试按照需求的结构来组织自动化测试按照需求的结构来组织自动化测试 以被“要测试什么”为核心，而不是“可以测什么”或“怎么测”为核心。 用例业务流程需求类别 用户故事 随意 ? 迭代 迭代结束后通过重构使其按需 求领域组织 迭代内的测试临时组织在一起 原则原则原则原则2: 在测试集上描述需求在测试集上描述需求在测试集上描述需求在测试集上描述需求 测试应该是自文档的（Self-documented） 原原原原则则则则3: 每个测试用例验证且只每个测试用例验证且只每个测试用例验证且只每个测试用例验证且只 验证一验证一验证一验证一个概念个概念个概念个概念 原原原原则则则则3: 每个测试用例验证且只每个测试用例验证且只每个测试用例验证且只每个测试用例验证且只 验证一验证一验证一验证一个概念个概念个概念个概念 原原原原则则则则4: 测试用例的名测试用例的名测试用例的名测试用例的名称清称清称清称清晰的晰的晰的晰的 表达其目表达其目表达其目表达其目的的的的 原则原则原则原则5: 测试用例之间的不要相测试用例之间的不要相测试用例之间的不要相测试用例之间的不要相 互依赖互依赖互依赖互依赖 原则原则原则原则5: 测试用例之间的不要相测试用例之间的不要相测试用例之间的不要相测试用例之间的不要相 互依赖互依赖互依赖互依赖 原则原则原则原则 1 5: 关于测试集的组关于测试集的组关于测试集的组关于测试集的组织织织织 总结总结总结总结 可执行需求可执行需求可执行需求可执行需求 Executable Requirement 原则1: 把测试锚定到需求上 原则2: 在测试集上描述需求 原则3: 每个测试用例验证且只验证一个清晰的概念 原则4: 测试用例的名称应该清晰的表达其目的 原则5: 测试用例之间的不要相互依赖 可执行需求 原则原则原则原则6-10: 关于测试用例的设计关于测试用例的设计关于测试用例的设计关于测试用例的设计 原则原则原则原则6: 把环境及配置从脚本中分离出来把环境及配置从脚本中分离出来把环境及配置从脚本中分离出来把环境及配置从脚本中分离出来 环境配置文件 产品配置文件 原则原则原则原则7: 明确的明确的明确的明确的setup（环境准备环境准备环境准备环境准备）和和和和teardown（环境拆环境拆环境拆环境拆 除除除除） 原则原则原则原则8: 尽可能使用三层模型尽可能使用三层模型尽可能使用三层模型尽可能使用三层模型 数据驱动的测试数据驱动的测试数据驱动的测试数据驱动的测试 业务 规则 用户工作流 技术活动 测试什么测试什么测试什么测试什么：例如例如例如例如，在什么在什么在什么在什么用用用用户和交户和交户和交户和交 易类型可以易类型可以易类型可以易类型可以享受享受享受享受什么样的折扣什么样的折扣什么样的折扣什么样的折扣 用户的使用步骤用户的使用步骤用户的使用步骤用户的使用步骤: 例如例如例如例如，用户的商品用户的商品用户的商品用户的商品 交易交易交易交易流程流程流程流程 特特特特定的操作步骤定的操作步骤定的操作步骤定的操作步骤：例如例如例如例如，放入购物车放入购物车放入购物车放入购物车， 设定支付方式设定支付方式设定支付方式设定支付方式 等等等等 原则原则原则原则8: 尽可能使用三层模型尽可能使用三层模型尽可能使用三层模型尽可能使用三层模型 数据驱动的测试数据驱动的测试数据驱动的测试数据驱动的测试 业务 规则 用户工作流 技术活动 清晰性清晰性清晰性清晰性 稳定性稳定性稳定性稳定性 在业务规则层描述需求在业务规则层描述需求在业务规则层描述需求在业务规则层描述需求 在用户工作流层组合技术活动以实现一个用户使用流程在用户工作流层组合技术活动以实现一个用户使用流程在用户工作流层组合技术活动以实现一个用户使用流程在用户工作流层组合技术活动以实现一个用户使用流程 易于易于易于易于 理解理解理解理解，创建创建创建创建 和维护和维护和维护和维护易于易于易于易于 理解理解理解理解，创建创建创建创建 和维护和维护和维护和维护 Setup: 创建和配置端口 Teardown: 删除端口 1 2 3 3个重复的工作流 数据驱动的模式数据驱动的模式数据驱动的模式数据驱动的模式 Setup Teardown 用户工作流用户工作流用户工作流用户工作流 明确的业务规则明确的业务规则明确的业务规则明确的业务规则 原则原则原则原则9: 在用户工作流中使用三在用户工作流中使用三在用户工作流中使用三在用户工作流中使用三阶段模阶段模阶段模阶段模式式式式 Given, When, Then 原则原则原则原则 10: 最小化和稳定化依赖最小化和稳定化依赖最小化和稳定化依赖最小化和稳定化依赖 减小关键字的可见范围，以最小化依赖和影响 - 只把关键字暴露至需要使用的层次 尽量维持底层的库的稳定 - 一个反模式: 任何用户接口的改变都会影响到底层的库 原原原原则则则则6-10: 关于测试用例的设关于测试用例的设关于测试用例的设关于测试用例的设计计计计 总结总结总结总结 分分分分离关注点离关注点离关注点离关注点 关注1关注2.1关注2.2关注2.3关注3 Enviroment Libs Test TestSuite +Document +tags -setup() -teardown() TestCase +document +tags +bissiness ruler -setup() -tearDown() 0* TestRun +tags HighLeveLlib run Env +variables UserFlow use include inclu de 原则6: 把环境及配置从脚本中分离出来 原则7: 明确的setup和teardown 原则8: 尽可能使用三层模型 原则9: 在用户工作流中使用三阶段模式 原则10: 最小化和稳定化依赖 分离关注点这些原则背后的基本指导原则分离关注点这些原则背后的基本指导原则分离关注点这些原则背后的基本指导原则分离关注点这些原则背后的基本指导原则， 它意味着它意味着它意味着它意味着： “业务或需求领域的一个小的变化只对应着测业务或需求领域的一个小的变化只对应着测业务或需求领域的一个小的变化只对应着测业务或需求领域的一个小的变化只对应着测 试用例的一个小的变化试用例的一个小的变化试用例的一个小的变化试用例的一个小的变化” 原则原则原则原则 11-15: 关关关关于测试活动的管理于测试活动的管理于测试活动的管理于测试活动的管理 原则原则原则原则 11: 把测试当作需求的第二面把测试当作需求的第二面把测试当作需求的第二面把测试当作需求的第二面 以可执行文档为目标组织测试 提前定义测试(例如：与需求分析的同时定义测试) 在定义测试的同时对需求进行概念验证 尝试验收测试驱动开发（ATDDacceptance test driven development) 和 实例化需求（SBE Specification by Example)等实践 原则原则原则原则 12: 用例用例用例用例首先是给人阅读的首先是给人阅读的首先是给人阅读的首先是给人阅读的 创建可以在机器上运行的脚本非常容易，但是 用例首先应该是让人阅读的 一些简单的提示 - 用意图来命名测试和测试步骤 - 清晰的层次，在每个层次上保持同样的抽象级别 - 持续重构测试用例 - 用文档的方式来组织测试集（Fitness），或者用测试集生成文档（Robot Framework） - 让业务人员一起评审测试用例和测试脚本 原则原则原则原则 13: 象对待代码一样对待脚本象对待代码一样对待脚本象对待代码一样对待脚本象对待代码一样对待脚本 使用配置管理，工作在共同分支上 加入到持续集成系统中去 关注测试的架构和设计 用更好的IDE(集成开发环境)，特别是能够支持重构(方法提取、重命名等) 的IDE 建设设计和开发能力 持续重构，持续运行 原则原则原则原则 14: 统一管理手工和自动测试统一管理手工和自动测试统一管理手工和自动测试统一管理手工和自动测试 吃你自己的狗粮， 不要人为分离自动测试的开发者和使用者 自动测试应该是防止bug的纱窗，而不是苍蝇拍 - 更早、更频繁的测试 (test early, test often) - 建立自动测试和手动测试之间的质量循环: 当有bug越过纱窗时，应该考虑怎么改 善纱窗 - 尝试在同一个工具和视图中管理自动和手动测试 原则原则原则原则 15: 拥抱开源拥抱开源拥抱开源拥抱开源 收益 - 经证明的设计 - 丰富的库 - 实用的工具链 - 和业界同步演进 - 社区互动和支持 - 节省成本 - 职业安全 记得反馈社区 测试即需求 脚本即代码 原原原原则则则则 11-15: 关于测试活动的管关于测试活动的管关于测试活动的管关于测试活动的管理理理理 总结总结总结总结 测测测测试即需求试即需求试即需求试即需求，脚本即代码脚本即代码脚本即代码脚本即代码 原则 11: 把测试当作需求的第二面 原则 12: 用例首先是给人阅读的 原则 13: 象对待代码一样对待脚本 原则 14: 统一管理手工和自动测试 原则 15: 拥抱开源 测试即需求测试即需求测试即需求测试即需求 脚本即代码脚本即代码脚本即代码脚本即代码 总结总结总结总结 原则 11: 把测试当作需求的第二面 原则 12: 用例首先是给人阅读的 原则 13: 象对待代码一样对待脚本 原则 14: 统一管理手工和自动测试 原则 15: 拥抱开源 原则6: 把环境及配置从脚本中分离出来 原则7: 明确的setup和teardown 原则8: 尽可能使用三层模型 原则9: 在用户工作流中使用三阶段模式 原则10: 最小化和稳定化依赖 原则1: 把测试锚定到需求上 原则2: 在测试集上描述需求 原则3: 每个测试用例验证且只验证一个概念 原则4: 测试用例的名称应该清晰的表达其目的 原则5: 测试用例之间的不要相互依赖 Enviroment Libs Test TestSuite +Document +tags -setup() -teardown() TestCase +