测试流程: 快速测试与敏捷测试
原标题《林应：James Bach 的 Rapid Test 培训总结》
AT重新排版
首先感谢阿里巴巴邀请James大神在北京办公室组织了Rapid Test的培训。
- 本来报名的目的只是想和兄弟部门的同事找机会一起交流交流，对测试本身并没有抱太大的期望。结果课程开始之后，只能说不服不行。另外，哥活生生的被大神当作了教学道具…
- 虽然James大神脱离项目一线专注培训很多年了，而且也没有互联网项目经验，但是一上来就抓住了问题的本质，项目需求不清楚，进度紧张，资源有限，这都是当年项目情况活生生的写照啊！所谓的Rapid Test就是针对这些问题的。为什么这里不说敏捷Agile？因为这里只谈测试，而且谈的是普遍真理，不管你用Agile还是瀑布流，测试都必须解决的一些共性问题。
培训过程就不具体描述了，这里就谈几点总结
如何挖掘需求。
- 在阿里测试人员经常听到开发人员说：这个功能做好了，你测一下，明天就发了。呃…好像这个到底是个什么样的功能都没搞清楚。所以对于测试人员要先了解这个系统，它的功能和设计目标。在教学中举了一个真实的例子，系统看着很简单，输入->判断->输出。一开始觉得这个系统简单，但是在得知是针对航天工程设计的系统时，实时性和稳定性就成为了重要的测试需求。在了解了输入系统的复杂程度之后，测试的重点也立刻明确了。所以对于测试人员，一边要自己摸索，同时也要和团队的其它成员密切沟通，获取需要的各种信息帮助决策。
关于测试用例。
- James基本上否定了测试用例的价值，这点和我们团队内部正在摸索的实践类似。从项目实践的角度来说，光凭借测试用例，我们无法
- 评估测试的有效性；
- 保持测试用例和实际情况同步（谁不服自己上Kelude看）；
- 从测试用例无法了解整个系统（测试评审基本是在过流水）。
- 大神的观点是基于场景做测试，你可以不写测试用例，但是不代表你不需要做你的家庭作业。取代测试用例的是如下的报告：
- 测试场景；
- 每个场景需要覆盖的功能点；
- 对于每个功能点如何测试；
- 场景设计的理由；
- 重点测试模块的选择等。
- 总儿言之，你必须让项目组成员相信你的测试是完整的，有足够覆盖的，能保证产品质量的。
探索性测试不是无目的的。
- 探索意味着自由，自由意味着责任。因为你能负责，所以才给你一定的自由。你必须通过试探，分析，验证这个流程去深入了解产品，之后再去系统的分析，有针对性的设计测试，这样才是真正的探索性测试。探索不是漫无目的的随机布朗运动，而是要通过探索建立对整个产品的了解。
为什么课程叫Rapid而不是Agile敏捷？
- 因为Rapid Test讲的是普遍真理，不管你用什么开发模式，敏捷或者传统的瀑布流都能解决问题。其实说到底，就是在人手有限，时间有限的情况下找到一个最好的平衡点，既能按时交付，又能保证质量。
- 测试人员的定位是守门员，是守住产品质量底线的人。这个观点不是很赞同，毕竟当代足球守门员还担负有后场防守组织的责任。个人认为当代软件测试还承担有带领团队保证软件质量以及不断改进质量的责任。
测试的第一要素是人，工具只是辅助。
- 当人们在谈自动化测试的时候，有人要求过开发自动化编程吗？但是事实上，自动化编程某种程度上确实在发生，比如编译器的工作。对于自动化，我们的衡量标准是生产效率的提高和投入产出比。这个是值得我们在日常工作中借鉴的，有时候比起高大上的全自动化测试脚本，手工测试辅助工具更能提高效率，而且维护成本更低，投入产出比更高。
- 课程只有短短两天，要是指望培训后能力有个突飞猛进那是没可能的。这个课程让你回到测试的原点，解答了为什么要做软件测试，如何做软件测试，如何像一个测试工程师一样思考问题，如何去发现问题。把这些原则与你工作实践想结合，才能真正的提高软件产品质量。
转载自 testerhome.com
AT：所以我现在做的工作，并不是敏捷测试Agile Test，而是快速测试Rapid Test
- 比如：我的用例更多是需求和场景，而非真正的用例设计
- 比如：项目需求不清楚，进度紧张，资源有限，几乎每一轮都是紧凑的
- 比如：真正的用例没人看，没人评审，产品验收更多是跑业务场景和功能跳转的异常干扰
- 实际工作下来，所谓的敏捷，更多在应用时，被理解为快速，轻文档重执行
