软件测试学习

Google测试之道学习笔记（三）—SET工作
通过参与设计和代码开发的方式使SET尽早介入到测试中去
DET是第一个实现所有接口协议的人。为了尽早地开始做集成测试，SET针对各个模块地依赖提供了mock和fake的实现。在任何阶段，集成测试总是依赖mock和fake。因为有了他们，一些依赖服务的期望错误场景和条件异常会比较容易产生。
1、自动化计划：
规模更小且目的性更强地自动化计划，并存在可以提供帮助地测试框架才会吸引SWE一起参加测试。
Ggoogle，SET遵循下面方法：
我们首先把容易出错地接口做隔离，并针对它们创建mock和fake，这样我们可以控制这些接口之间的交互，确保良好的测试覆盖率。
接下来构建一个轻量级的自动化框架，控制mock系统的创建和执行。这样的话，写代码的SWE可以使用这些mock接口来做一个私有构建。在他们把修改的代码提交到代码服务器之前运行相应的自动化测试，可以确保只有经过良好测试的代码才能被提交到代码库中。这是自动化测试擅长的地方，保证生态系统远离糟糕代码，并确保代码库永远处于一个时刻干净的状态。
SET除了在这个计划中涵盖自动化（mock，fake和框架）之外，还要包括如何公开产品质量方面的信息给所有关心的人。再google，SET使用报表和仪表盘来展示收集到的测试结果以及测试进度。通过将整个过程简化和信息透明公开化，获取高质量代码的概率大大增加。
2、可测试性：
SET第一要务是可测试性。SET在扮演一个质量顾问的角色，提供程序结构和代码风格方面的建议给开发人员，这样开发人员可以更好地做单元测试。同时提供测试框架方面的建议，使得开发人员能够在这些框架的基础上自己写测试。
**小型测试：**外部服务（如文件系统，网络，数据库）必须通过模拟或者虚假实现，为了减少依赖，适当的时候也可以模拟实现被测试类所在模块地内部服务。范畴隔离且没有外部依赖让小型测试在很短时间内就运行结束。
**中型测试：**是验证两个或多个模块的交互，和小型测试相比，中型测试有着更大地范畴且运行时间更久，小型测试会尝试走遍单独函数地所有路径，而中型测试地主要目标时验证指定模块之间的交互，中型测试也被称为“集成测试”，通常由SET来组织运行，且不能频繁测试。
**对于中型测试，**鼓励使用模拟技术（mock）来解决外部服务依赖问题，但这不是强制的，如出于性能考虑可以不使用模拟技术，轻量级地虚假实现（fake），如常驻内存地数据库，在不能使用mock的场景下可以用来提升性能。
**对于大型测试：**通常被称为“系统测试”或端到端测试。大型测试可能会依赖外部资源如数据库，文件系统，网络服务等。
大，中，小测试优缺点：
大型测试的优点和缺点包括如下
a.测试最根本最重要的:在考虑外部系统的情况下应用系统是如何工作的。
b.由于对外部系统有依赖，因此它们是非确定性的。
c.很宽的测试范畴意味着如果测试运行失败，寻找精准失败根源就会比较困难。
d.测试数据的准备工作会非常耗时，
e.大型测试是较高层次的操作，如果想要走到特定的代码路径区域是不切实际的，而这一部分却是小型测试的专长。
中型测试的优点和缺点包括如下：
a.由于不需要使用mock技术，且不受运行时刻的限制，因此该测试是从大型测试到小型测试之间的一个过渡。
b.因为它们运行速度相对较快，所以可以频繁地运行它们
c.它们可以在标准的开发环境中运行，因此开发人员也可以很容易运行它们。它们依赖外部系统
d.由于对外部系统有依赖，因此它们本身就有不确定性。
e.它们的运行速度没有小型测试快
小型测试的优点和缺点包括如下：
a.为了更容易地就被测试到，代码应清晰干净函数规模较小且重点集中。为了方便模拟，系统之间的接口需要有良好的定义。
b.由于它们可以很快运行完毕，因此在有代码变更发生的时候就可以立刻运行，从而可以较早地发现缺陷并提供及时的反馈。
c.在所有的环境下它们都可以可靠地运行。
d.它们有较小的测试范围，这样可以很容易地做边界场景与错误条件的测试，例如一个空指针。
e.它们有特定的范畴，可以很容易地隔离错误。
f.不要做模块之间的集成测试，这是其他类型的测试要做的事情(中型测试)。有时候对子系统的模拟是有难度的
g.使用mock或fake环境，可以不与真实的环境同步
小型测试带来优秀的代码质量、良好的异常处理、优雅的错误报告；大中型测试带来整体产品质量和数据验证。
使用代码覆盖率检查一个项目里地小型测试，中型测试和大型测试之间的比率是否健康。测试代码覆盖率可以针对小型测试、中大型测试分别单独产生报告。覆盖率报告会针对不同的项目展示一个可被接受的覆盖率结果。如果中大型测试只有20%的代码覆盖率，而小型测试有近100%的覆盖率，则说明这个项目缺乏端到端的功能验证。如果结果数字反过来了，则说明这个项目很难去做升级扩展和维护，由于小型测试较少，就需要大量的时间消耗在底层代码调试查错上。Google工程师可以使用构建与运行测试时使用的工具，来产生并查看测试覆盖率结果，只需要在命令行中额外增加一个选项即可。覆盖率结果会存储在云端，任何工程师在公司内网络环境下都可以通过浏览器查看这些报告。
验证法则：70/20/10原则：70%是小型测试，20%中型测试，10%大型测试。
监视测试覆盖率的工具：Harvester；Harvester是一个可视化的工具，可以记录所有项目的CL历史，并以图形化的方式展示，例如测试代码和CL中新增代码的比率、代码变更的多少、按时间的变化频率、按照开发人员的变化次数，等等。这些图形的目的是展示随着时间的变化，测试的变化趋势是怎样的。
3、测试运行的要求：
①　每个测试和其他测试之间都是独立的，使它们能够以任意顺序进行
②　测试不做任何数据持久化方面的工作。在这些测试用例离开测试环境的时候，要保证测试环境的状态与测试用例开始执行之前的状态是一样的。
但也有可能存在对执行顺序有要求的用例：
a.两个测试都要绑定同一个端口，用以接收来自网络的数据。
b.两个测试需要在同一个路径下创建相同的目录
c.一个测试希望创建并使用一个数据库表，而另外一个测试想删除这个数据库表。
解决方案：这种类型的冲突，不仅会导致自己的用例运行失败，而且可能会导致测试执行系统中其他正在运行的用例也失败，即便另外的用例已经遵守了规则。测试执行系统可以找出这些测试用例，并通知给相应的用例负责人。另外，通过设置一个特殊标记，用例可以在指定的机器上以独立排他的方式运行。但排他的方式运行只是一个临时方案。更多的时候，测试或者被测系统必须重构，彻底解决在单一资源方面的依赖。下面的做法可以帮助解决一些问题。
a.在测试执行系统中，让每个测试用例获取一个未被使用的端口，并让被测系统动态地绑定到这个端口上
b.在测试执行之前，为每一个测试用例在临时目录下创建目录和文件，并使用独一无二的目录名。
c.每个测试运行在自己的数据库实例之上，使用与环境隔离的目录和端口。这些都由测试执行系统来控制