测试三十六计-第三计-借刀杀人

上一篇 / 下一篇 2013-05-26 10:12:34 / 个人分类：测试

【释义】

敌人的情况已经明了，友方的态度尚未确定。利用友方的力量去消灭敌人，自己不需要付出什么力量

如何才能降低测试成本呢，这是每个测试管理者最大的问题。在传统测试过程中，一般是开发将代码开发完毕后，移交给测试人员进行测试。一般开发人员会进行单元测试和集成测试。

然而，在现在敏捷开发的过程中，开发人员也必须进行一些功能测试，尤其是自动化测试的大量引入，很多人都觉得开发人员必将取代测试人员的角色，从而使得测试人员这个角色逐渐的消亡。

其实这是一个很片面的想法。在敏捷开发过程中，测试角色不是被削弱或者是被取代，而是更加的被强化，测试驱动开发测试敏捷开发的真髓。

在测试驱动开发的敏捷开发过程中，测试人员和开发人员同时对user story进行分析，开发人员根据其进行代码实现，而测试人员是通过书写相关的测试场景来验证开发人员实现的质量。

也就是说，测试人员不再是去根据需求和设计文档在后期进行代码实现度的验证，而是转变为依据或者是贴合最终用户来控制开发的方向和质量。

验证标准也从了是否完成了预期的设计变成了是否满足了用户的需求。

所以，借刀杀人已经成为普遍的开发策略。核心的想法就是，开发人员在做完常规的单元测试和模块测试之后，必须依据测试用例对代码进行功能测试，只有那些完成了p1&p2测试用例的代码，才会提交给测试人员进行测试。

这样的好处是：

1.在开发阶段就能评审代码是否符合用户需求，这是敏捷的灵魂。

2.在测试阶段减少大量因为P1&P2导致的等待时间和重复测试率。

3.开发测试的用例可以是手工测试用例或者自动化测试脚本，这样的话加强了测试人员和开发人员的交互，不再是单纯的质量保证，而是主动质量控制。

所以，借刀杀人的最大核心就是，那些测试用例需要开发人员来执行。这就是测试用例要分层的原因所在，只有分层的测试用例，才能很简单的提取一个测试集合用来执行借刀杀人这个计谋。