第二章 软件测试开发工程师

目录

2.1 SET的工作

测试执行

测试大小的定义

测试规模在共享测试平台中的使用

测试规模的益处

测试运行要求

2.2 测试认证

2.3 SET的招聘

---

2.1 SET的工作

测试执行

只有加速开发过程的自动化测试才是有意义的

做一个代码编译、测试执行、结果分析、数据存储、报表展示的通用的测试框架

新增一个测试程序之后，同事会针对这个测试创建一个构建说明文件，构建文件中包括测试名称、源码文件、依赖库及数据、还要指明规模大小；编写完构建文件后， 后续交给构建工具和测试执行框架；从递交时刻开始， 一个命令可以触发构建、运行自动化、展示运行结果

测试大小的定义

测试大小的定义

小型测试	单元测试， 验证一个代码单元的功能， 可以提供更全面的底层代码覆盖率，外部服务必须通过模拟或者虚拟实现
中型测试	集成测试，验证模块之间的交互，鼓励使用模拟技术解决外部服务依赖问题， 但处于性能考虑可不使用
大型测试	系统测试，端到端测试，验证整个系统作为一个整体是如何工作的， 依赖外部资源

测试规模在共享测试平台中的使用

通用测试执行平台必须支持运行各种各样的测试任务，一些通用任务如下：

• 编译运行小型测试， 立刻知道运行结果
• 有变更代码时，希望运行相关测试，并获得测试结果
• 知道项目的测试覆盖率并查看结果
• 代码变更提交到版本控制系统后，自动运行项目所有测试
• 团队希望每周都得到代码覆盖率，并实时跟踪覆盖率的变化

测试调度器根据测试规模大小，得到每个任务大致运行时间，这样可以优化任务队列 ，达到合理利用的目的

	小型测试	中型测试	大型测试	超大型测试
时间目标 （每个函数）	10毫秒以内	1秒	尽可能快	尽可能快
强制时间限制	1分钟	5分钟	15分钟	1小时

测试规模的益处

测试规模越小，依赖性越弱，速度越快；测试规模越大，对整个系统的稳定性的信心越强

	小型测试	中型测试	大型测试
优点	容易被测试到； 运行快，及早发现缺陷； 可靠运行； 容易做边界场景与错误条件的测试； 容易隔离错误； 使用mock环境	运行速度相对较快；在标准开发环境运行	整个系统的联调，考察在外部系统的情况下应用系统是如何工作的
缺点	对子系统的模拟有难度	对外部系统有依赖，存在不确定性； 运行速度没有小型测试快	对外部系统有依赖，存在不确定性； 测试运行失败，寻找失败根源较困难； 测试数据准备耗时； 不能走到特定的代码路径区域

小型测试带来优秀的代码质量、良好的异常处理、优雅的错误报告；大中型测试带来整体产品质量和数据验证， 因此不同测试类型之间需要一个健康的比例。

检验项目中测试规模之间比率是否健康，一个办法是使用代码覆盖率。google测试比例并不固定， 但有一个经验法则是7/2/1:70%为小型测试，20%为中型测试；10%为大型测试。

针对不同的应用场景， 这个比例也应适当调整：若项目面对用户，拥有较高的集成度或者用户接口比较复杂， 则大中型测试应该更多；如果为基础平台或者面对数据的项目，例如索引或者网络爬虫，则最好有大量的小型测试，中大型测试数量要求少些

Harvester:监视测试覆盖率的内部工作（？？）

测试运行要求

测试本身需要满足的条件：

• 每个测试之间都是独立的，它们可以以任意顺序执行
• 测试不做任何数据持久化方面的工作。保证测试环境的状态与测试用例开始执行之前的状态是一样的（包括保存数据或者修改环境配置信息）

测试需要解决在单一资源方面的依赖， 例如，动态获取未使用的端口；创建临时目录和文件；每个测试运行在自己的数据库实例之上

2.2 测试认证

测试认证（TEST Certified）分为不同的级别， 增加开发人员对测试的重视，最终收获质量方面的提升

2.3 SET的招聘

SET是一个编码能力 很强的程序员；也是一个能力很强的测试这。具有远瞻性。要发现功能开发人员一楼的代码缺陷，而且还要去关心其他工程师是如何使用这些代码模块，甚至关心这些代码未来适用的功能。

SET的面试重点在于考察候选人如何思索问题的解决方案， 以下是例子说明：要求写一个函数返回一个字符串中大写字母A出现的次数。当提出给模块增加测试场景时， 希望执行最佳的测试用例

问题思索：函数作用？构建目的？关心函数的准确性以及如何验证期望行为

通过提问方式来理解需求文档：

• 传入字符串编码？
• 返回值类型？
• 考虑扩展性
• 考虑复用性
• 考虑安全性