Google 软件测试之道
Google 对质量的理解
质量不等于测试, 即质量不是被测出来的
开发和测试应该并肩齐驱, 测试就是开发过程中不可缺少的一部分
质量是一种预防行为而不是检测
Google 对软件测试的划分
抛却复杂的专业术语, 简单按照测试范围去划分:
小型测试: 对一个代码单元的测试, 通常就是单元测试
中型测试: 对两个或多个模块之间交互的测试, 通常类比于 "集成测试"
大型测试: 对一个应用系统及其子系统整体的测试, 通常类比于 "端到端测试"
这样划分的好处有:
容易定位问题: 测试范围从小到大, 各自负责不同的功能, 某个测试一旦失败容易让开发找到问题所在
产生较高的测试回报率: 测试的回报率等于测试所产生的业务价值与测试执行成本之比. 范围小的测试越容易被自动化, 但因为覆盖业务范围小所产生的业务价值也就越小, 范围大的测试则反之. 根据团队和产品具体情况, 通过制定合理的测试策略和划分测试范围, 决定自动化测试的比例, 可以产生较高的测试回报率
Google 对软件测试角色的划分
SWE(软件开发工程师): 主要职责是实现用户功能, 除编码外也具有编写和组织测试的能力, 日常活动是代码设计, 代码实现与编写测试
SET(软件测试开发工程师): 主要职责是让 SWE 更容易地去写测试, 工作重心在可测试性和通用测试基础框架上, 是 SWE 的紧密合作伙伴, 关注质量提升, 具备观察代码质量, 编写测试框架等能力, 日常活动是参与设计评审, 代码重构, 编写测试框架等
TE(测试工程师): 主要职责是专注于用户角度的测试, 关注集成后的系统是否可以满足最终用户的需求, 是真正的产品专家, 质量顾问和风险分析师, 具备全局审视与分析思考的能力, 日常活动是模拟用户使用场景, 对 SWE 和 SET 编写的测试进行分类组织, 分析, 解释和测试运行结果, 特别是在项目最后阶段推进产品发布
与传统软件测试中的角色不同, Google 将编写测试的工作大部分转交给 SWE 进行, 因为测试本来就应该是开发工作的一部分, 由开发去完成再合理不过. 考虑到 SWE 在测试编写方面需要统一的支撑, SET 作为 SWE 的紧密合作伙伴介入进来, 予以框架工具和技术方面的支持, 并帮助观察代码质量. 而 TE 的作用向后推移, 更关注系统集成为一个整体后, 从用户角度是如何使用的, 能否满足用户需求, 因为毕竟质量的定义就是 "满足用户需求".TE 看起来更像一个具备很强验收能力的产品经理, 并且被验收的不仅仅是用户需求, 还会用放大镜仔细看 SWE 和 SET 所做的测试工作细节.
Google 的 "工程生产力团队"
测试是独立存在并与业务领域部门平行的部门, 横跨于各个业务领域, 被称为 "工程生产力团队". 测试人员以租借的方式进入产品团队帮助做提高质量相关的事情, 寻找测试方面的可改进之处. 测试人员并不直接向产品团队汇报. 这种借调模式, 一是可以帮助测试人员保持新鲜感, 二是可以让一个好的测试实践迅速在公司内的不同团队间蔓延.
测试左移 (前移) 与测试右移(后移)
相对于传统的认为测试工作主要是测试人员的事的看法, Google 提倡测试左移与测试右移:
测试左移: 开发阶段就应该完成大部分测试工作, 尽量将测试放在早期进行, 有助于尽早发现问题和质量内建
测试右移: 既然 TE 的主要工作是从用户角度审视产品是否满足用户需求, 那为什么不直接找真实用户来进行测试呢? 内测用户, 众包测试都是测试右移的手段, 直接, 快速地收集来自真实用户的反馈, 能得到更有用户价值的测试结果
但是, 个人认为测试左移是测试右移的前提条件, 即团队尚不能完全保障产品的功能完整与稳定性之前, 不要仓促开放给哪怕只是部分用户. 团队应该先着力于发展自己内建质量的能力, 即让人人都来关注质量, 以及提前预防问题的发生.
来源: http://www.bubuko.com/infodetail-3343818.html