接口测试需要遵循的15个原则

什么是好的自动化测试 ？

易于理解

易于创建

易于维护

足够的覆盖

足够的效率

---

关于测试集的组织

原则一：

测试是将需求在复述一遍，一切的用例设计都要和需求保持一致，要以“测什么”为核心，而不是可以测什么或者怎么测

原则二：

测试集上描述需求，测试应该是自文档的

原则三：

每个测试用例验证且只验证一个概念（通用概念）

原则四：

测试用例的名称清晰表达其目的

原则五：

测试用例之间不要相互依赖

关于测试用例的设计

原则六：

把环境及配置从脚本中分离出来

原则七：

明确的setup（环境准备）和teardown（环境拆除）

原则八：

尽可能的使用三层模型--数据驱动的测试

在业务规则层描述需求

在用户工作流层组合技术活动以实现一个用户使用流程！

易于 理解，易于创建，易于维护！

原则九：

在用户工作流中使用三阶段模式：Given，When，Then

原则十：

最小化和稳定化依赖

减小关键字的可见范围，以最小化依赖和影响

只把关键字暴露到需要使用的层次

尽量维持底层的库的稳定

一个反模式：任何用户接口的改变都会影响到底层的库

分离关注点

分离关注点这些原则背后的基本指导原则，它意味着：“业务或需求领域的一个小的变化只对应着测试用例的一个小的变化”

关于测试活动的管理

原则十一：

把测试当做需求的第二面

以可执行文档为目标组织测试

提前定义测试（例如：与需求分析的同时定义测试）

在定义测试的同时对需求进行概念验证

尝试验收测试驱动开发（ATDD）和实例化需求（SBE）等实践

原则十二：

用例首先是给人阅读的

创建可以在机器上运行的脚本非常容易，但是用例首先应该是让人阅读的

在用例中给一些简单的提示：

用意图来命名测试和测试步骤

清晰的层次，在每个层次上保持同样的抽象级别

持续重构测试用例

用文档的方式来组织测试集，或者用测试集生成文档（RF）

让业务人员一起来评审测试用例和测试脚本

原则十三：

像对待代码一样对待脚本

使用配置管理，工作在共同的分支上

加入到持续集成系统中去

关注测试的框架和设计

用更好的IDE，特别是能够支持重构的IDE

建设设计和开发能力

持续重构，持续运行

原则十四：

管理手工和自动测试

明确自动化测试的开发者和使用者都是不可分离的

自动化测试应该是防止bug的纱窗，而不是苍蝇拍

更早、更频繁的测试

建立自动化测试和手动测试之间的质量循环：当有bug越过纱窗，应该考虑如何完善纱窗（维护脚本）

尝试在同一个工具中管理手动测试和自动化测试

原则十五：

拥抱开源

你将得到的好处：

经过证明的设计

丰富的库

实用的工具链

和业界同步的演讲

社区互动和支持

节省成本

职业安全

 

记得反馈社区！

总结：

测试即需求！

脚本即代码！

感谢何勉先生（上海贝尔公司精益和敏捷教练）的知识分享