|
实施GJB5000的缺陷管理大致是这样一个流程： 在执行测试过程中，发现实际测试结果与测试用例中预期的结果不一致，测试人员记录下实测结果，分析是否为缺陷，如果是缺陷则记录在软件问题报告单中，当所有测试用例执行完，再把所有的软件问题报告单提交给责任人去分析原因、定位问题、修复缺陷，测试人员通过回归测试验证修复无误也没有引入新的缺陷后，关闭这个缺陷。
这样的一套流程，是一个昂贵而耗时的过程。记录缺陷以及长长的缺陷队列，会导致测试效率的大幅下滑。 而在精益软件开发中的缺陷管理却提倡立即修复缺陷策略，即一旦测试人员发现缺陷，立即和开发人员沟通，经开发人员确认之后，由开发人员创建一个单元测试来捕获该缺陷，然后再修复缺陷。这样就能在之后该缺陷重现时立即被捕获。 采用这样的策略时，测试人员不需要在缺陷跟踪系统中记录缺陷，因为这个缺陷已经有单元测试可以捕获，只要将该单元测试用例纳入常规测试用例集，它就不会再出现；缺陷队列也不会很长，减少了开发/测试人员的等待时间。因此，测试效率可以大大提高。 当然，这个方法需要开发和测试人员之间的密切合作。 另外，值得注意的是，有些轻微的缺陷不值得去修复。这需要开发和测试人员很好地协调，以项目的进度、质量要求为准。 曾经有些专家说我们在编码的过程中都是进行单元测试了，只不过没有把发现的缺陷记录下来。这看起来和精益软件开发的缺陷管理很接近，但实际上却是相差甚远——精益开发中不记录缺陷，是因为已经在测试用例集中包含了可以捕获该缺陷的测试用例，能够确保该缺陷不再出现，可不仅仅是省下记录的时间，这才是不记录的理由！ 所以，我们学习这种不记录缺陷的做法，还需要有测试驱动开发、自动化测试等实践支撑才行。 这正是： 缺陷管理要精益，没有想象中容易 确保缺陷能捕获，才能省时又省力 参考数目：规范敏捷交付——企业级敏捷软件交付的方法与实践，作者：Scott W.Ambler Mark Lines，出版社：机械工业出版社 |
|
|
