[如需转载，请在转载时注明出处，并保证本文的完整性]
理想的天国
-- 关于未来几年的测试发展的思考
> 做人, 还是要有点自信的.
时之今日, 我要将最完美的测试方案呈现出来, 各位 tester 们, 各位 developer 们.
这个方案, 具备完美的项目运转模式, 能让我们的项目快速推进, 更少犯错, 测试资源最优化配置.
别问我什么黑盒, 白盒, 边界, 分支, 还是集成与系统有什么区别, 这在我这个模式里什么都没有, 一切都很简单.
开始之前, 我先抛出几个观点:
1. 质量是写出来的, 不是测出来的.
2. 测试资源是有限的.
3. 人是懒的, 只有足够方便才愿意使用.
所以, 软件测试不能仅仅是验证产品是否符合需求, 而是应当帮助开发人员更高效, 更高质量地完成产品的研发. 这句话很重要, 是我们今天完美的测试方案的最重要的论点.
按更有范的话< google 软件测试之道 >, 我们的测试是生产力工程团队, 着重于高质量, 高效率完成产品的研发.
OK, 我们看图:
我们看到, 我把完美测试方案分为上下两个部分: 项目运转 与 工具框架集合.
我认为, 不断将项目运转中重复的事件提炼出来, 成为工具集合, 这是一个项目运作的最可持续之路. 在这里, 我列出了一些我能想到的工具或系统.
好了, 我们再横向来看, 我把项目运转分为三大部分:
最核心的是第一部分:
通过不断优化的工具集合, 让开发产品不单单是写了代码后提交测试部, 而是必须通过:
代码 --> 单测 --> 审查 --> 集成 --> 代码
来运作. 有人会问了, 这跟我们测试有什么关系?
很好的问题, 很简单, 以我对开发的经验, 每个人都希望写完代码后验证一下功能是否正常, 而且如果他了解自动化, 都会希望自动化掉, 以便下次改动时自动验证. 我把这个环节称为小型测试( 快而小 ).
但是, 很多时候, 验证一个功能很麻烦, 例如, 开发一个 web 网站, 你改一个后端逻辑后, 需要打开浏览器, 输入对应地址, 填好表单, 也许还要构一大堆前置条件. 所以他们并没有去做, 你去强制他们也不行. 如果开发人员测试质量意识较高, 会充分自测下再上库. 这就能成为我们公司的高级开发工程师.
那如果验证功能变的简单会怎么样? 我们提供一套 fake 浏览器的 API( 事实上, 现在已经有类似的了 ), 可以用他们熟悉的语言很快的写出验证代码, 并且, 代码一旦完成, 在本地很容易地验证是否工作. 这就够了. 更酷的是, 如果我们有一套真正的持续集成环境, 一旦代码上库, 就有独立一套环境帮助编译运行对应的测试, 失败时自动邮件提醒. 你愿意每次都手工点击还是?
除此之外, 我认为审查代码( code review )是一个团队快速提高的关键, 如果有一套工具协助大家更加容易完成代码审查和反馈( 例如 github 的 pull request 功能 ), 我真想说, 哇, 太棒了.
如此这般, 产出的代码质量真的是 "写" 出来的, 不是测出来的.( 题外话, 认为写测试代码太难的人写功能代码也烂 )
于是, 需要这样一种人:
他叫软件测试开发工程师( Software Engineer in Test ), 或者说叫在测试领域工作的软件开发工程师. 他不一定有高超的算法分析能力, 不一定有精通 Linux 内核的本领, 但他拥有真正的计算机科学的能力, 写编码干净利落, 质量颇高, 知识面很厂, 对模块设计, 代码质量, 懂得如何测试来保证模块的质量.
他以一顶十, 帮助开发团队解决在开发过程中各种 "痛苦", 但并不会帮你写单元测试, 他的时间很宝贵, 一定在好刀用在刀刃上.
我们还有专门的工具框架, 负责系统化统一解决各种 "痛苦", 例如, 建立一套虚拟化资源管理系统, 帮助快捷申请资源( 妈妈再也不用担心没有设备了 ), 持续集成系统, 代码审查系统, 单测工具.
总而言之, 他用尽一切办法, 协助开发人员快速建立一套快而小的测试套.
第二部分:
随着第一部分的建立, 我们成功地将质量控制住了, 有人做过统计, 将快而小的测试做好, 我们就可以少产出 60% - 80% 的 bug.
但快而小的测试相对低级, 无法确保在真实环境仍然有效. 所以需要有线上自动化测试, 比起前一部分, 这部分用例比较重. 跑的也慢一些, 大约 1 分钟一个 ( 而前一个按 1 秒一个 ). 我们称之为中型测试.
中型测试需要在功能相对稳定的情况下, 而只针对用户最关心的功能做.
第三部分:
如果功能已经相对稳定, 产品需要不断迭代新功能, 则开始将老功能与新功能进行接口与自动化实现, 通过大型测试.
大型测试需要较多的人力与物力. 但与传统的测试模式相比, 我们的思路是将尽可能多的使用自动化测试, 通过机器的重复利用来大规模节省我们测试人员的时间, 而将宝贵的测试资源投入探索性测试, 用户体验测试, 稳定性监控方案设计与分析等.
再来讲讲第二种人:
这样的测试人员( Software Test Engineer ), 需要看得懂开发的代码, 写得了自动化测试, 运用 SET 们提供的框架快速有效完成自动化测试, 懂得运用机器的威力解决双手, 思维活跃, 知识面广阔, 与用户理念同在. 通过自己的智慧反馈问题, 将产品打磨到极致.
说到这里, 基本上一个理想的体系已经出了原型. 当然, 我们还有很多不重要的内容:
第三种人: 对应的管理人员, 与相关流程.
我希望管理这些 "精英" 的管理人员, 也是践行这种理念的人, 有一点, 始终记得他们只不过是比其他人员多一点点智慧和想法而已, 别人需要他的帮忙.
流程不在多, 而仅仅是将最关键的地方明确出来, 甚至, 人人可随时打破它, 只要你的产品可以高效稳定发布.
最后来个总结:
这样一个完美的测试模式, 不是一个一成不变的方案, 而是一种理念的延展:
1. 质量是 "写" 出来的, 不是 "测" 出来的.
2. 测试是一种稀缺资源, 越少越珍贵.
3. 充分发挥机器的潜能, 这是测试人员解放的解决之道.
通过 SET 与 STE 两种角色的工作, 配合 SE 完成整个版本的开发. 最后我推荐一本书: <google软件测试之道>. 在这个领域上, google 也只是比我们快了几步, 但我们也要不断向它学习.
首发自公司内部 CMS, 唯一转至 <testwo.com>
[如需转载，请在转载时注明出处，并保证本文的完整性]
