Sarah的博客

在系统日渐复杂的产品测试团队中，全员熟悉每个特性和业务细节、演进进度的学习成本和沟通成本巨大，但又不能完全各自为营不闻不问，测试脚本就是很好的沟通语言，它建立在懂代码、懂测试框架这样的基础公共能之上，原则上具备这类公共能力的人员即可理解。一个变化的特性，在传统既定的测试流程中设计大量文本的调整。一些部门组织中对测试用例文本的可信度的执念构筑着产品整体的质量信心，但在版本节奏催促下，测试人员最可能的反应是直接手动验证，一个特性验证完，相关的测试资产没有完整记录跟踪，测试资产的可信度很难在高强度下得到保证。

随着系统演进，场景越来越复杂，即使是一个很小的改动，也要考虑所有可能场景组合下的潜在风险。测试的工作量极具膨胀，时间有限，为了避免漏测，重点都投在了前期测试设计反串，头脑风暴和热烈的讨论后产出一个庞大的Xmind思维导图。后面就是加班加点的完成Xmind指导的动作，机械又重复，还要拉着各种开发定位问题，加班到头秃也没什么提升。测试用例可重用性和场景多样化是矛盾的，在测试前期设计时，为了尽可能多的覆盖到现网存量场景，会将测试输入尽可能发散。某些用例或测试活动可能只是针对现网一个局点的情况做镜像验证。

A test automation framework is a set of assumptions, concepts, and practices that provide support for automated software testing. This article describes and demonstrates five basic frameworks.Michael K

在本章中，我们为一个简单但完整的应用程序controller创建了一个测试用例。测试用例并不是测试单个的组件，而是检验多个组例，如何一起工作。我们从一个可以用于任何类的简单测试用例开始．然后把新的测试逐个添加到测试用例中，直到所有初始的组件都被测试到。由于断言变得越来越复杂、因此我们通过Hamcrest匹配器找到了一种简化断言的方法。我们预期这个包会日益增长，所以我们为测试类创建了另一个源代码目录。