目录
只有加速开发过程的自动化测试才是有意义的
做一个代码编译、测试执行、结果分析、数据存储、报表展示的通用的测试框架
新增一个测试程序之后，同事会针对这个测试创建一个构建说明文件，构建文件中包括测试名称、源码文件、依赖库及数据、还要指明规模大小；编写完构建文件后， 后续交给构建工具和测试执行框架；从递交时刻开始， 一个命令可以触发构建、运行自动化、展示运行结果
| 小型测试 | 单元测试， 验证一个代码单元的功能， 可以提供更全面的底层代码覆盖率，外部服务必须通过模拟或者虚拟实现 |
| 中型测试 | 集成测试，验证模块之间的交互，鼓励使用模拟技术解决外部服务依赖问题， 但处于性能考虑可不使用 |
| 大型测试 | 系统测试，端到端测试，验证整个系统作为一个整体是如何工作的， 依赖外部资源 |
通用测试执行平台必须支持运行各种各样的测试任务，一些通用任务如下：
测试调度器根据测试规模大小，得到每个任务大致运行时间，这样可以优化任务队列 ，达到合理利用的目的
| 小型测试 | 中型测试 | 大型测试 | 超大型测试 | |
| 时间目标 （每个函数） | 10毫秒以内 | 1秒 | 尽可能快 | 尽可能快 |
| 强制时间限制 | 1分钟 | 5分钟 | 15分钟 | 1小时 |
测试规模越小，依赖性越弱，速度越快；测试规模越大，对整个系统的稳定性的信心越强
| 小型测试 | 中型测试 | 大型测试 | |
| 优点 | 容易被测试到； 运行快，及早发现缺陷； 可靠运行； 容易做边界场景与错误条件的测试； 容易隔离错误； 使用mock环境 | 运行速度相对较快；在标准开发环境运行 | 整个系统的联调，考察在外部系统的情况下应用系统是如何工作的 |
| 缺点 | 对子系统的模拟有难度 | 对外部系统有依赖，存在不确定性； 运行速度没有小型测试快 | 对外部系统有依赖，存在不确定性； 测试运行失败，寻找失败根源较困难； 测试数据准备耗时； 不能走到特定的代码路径区域 |
小型测试带来优秀的代码质量、良好的异常处理、优雅的错误报告；大中型测试带来整体产品质量和数据验证， 因此不同测试类型之间需要一个健康的比例。
检验项目中测试规模之间比率是否健康，一个办法是使用代码覆盖率。google测试比例并不固定， 但有一个经验法则是7/2/1:70%为小型测试，20%为中型测试；10%为大型测试。
针对不同的应用场景， 这个比例也应适当调整：若项目面对用户，拥有较高的集成度或者用户接口比较复杂， 则大中型测试应该更多；如果为基础平台或者面对数据的项目，例如索引或者网络爬虫，则最好有大量的小型测试，中大型测试数量要求少些
Harvester:监视测试覆盖率的内部工作（？？）
测试本身需要满足的条件：
测试需要解决在单一资源方面的依赖， 例如，动态获取未使用的端口；创建临时目录和文件；每个测试运行在自己的数据库实例之上
测试认证（TEST Certified）分为不同的级别， 增加开发人员对测试的重视，最终收获质量方面的提升
SET是一个编码能力 很强的程序员；也是一个能力很强的测试这。具有远瞻性。要发现功能开发人员一楼的代码缺陷，而且还要去关心其他工程师是如何使用这些代码模块，甚至关心这些代码未来适用的功能。
SET的面试重点在于考察候选人如何思索问题的解决方案， 以下是例子说明：要求写一个函数返回一个字符串中大写字母A出现的次数。当提出给模块增加测试场景时， 希望执行最佳的测试用例
问题思索：函数作用？构建目的？关心函数的准确性以及如何验证期望行为
通过提问方式来理解需求文档：