软件测试Bug、测试流程基础问答(转载)

  问题1）测试人员发现了BUG，张三说，我负责的模块，正常的发出了消息，不知道李四那里怎么处理的；问了李四，李四又说，我这也是正常的，不知道张三那里怎么处理的，测试人员就在两个人之间跑来跑去，为什么他们两个不直接沟通呢，是推卸责任吗？还是个人不合作？项目经理该如何处理这个问题？

　　问题2）项目管理标准化测试流程是什么？真正的项目测试过程中，正规的测试流程很难走通，测试人员没有正规详细的需求文档，没有办法写出详细的CASE，写完CASE，也没有时间去评审，大部分都是写完就该执行了，时间的仓促，容不得按照流程去走，那请问项目周期很短的情况，如何确保测试按照正规流程走？

　　【解答】

　　问题1）看到这个场景的发生，只能说公司对于技术人员的职责定义不清晰。正常情况下，测试人员不需要处理bug定位的问题，当bug产生后，测试人员只负责追踪bug的处理情况，对于未及时处理的bug，由相关人员（测试或者测试负责人）汇总到项目经理这里，由项目经理统一处理。对于测试人员在两名开发之间充当沟通桥梁的情况，如果是测试人员不知道应该分配给谁，那么则是对于测试人员的工作定义不清晰。测试人员对于缺陷的分配原则是：分配给缺陷爆发所在模块的负责开发人员。至于缺陷是本身模块内的问题，还是被调用模块的问题，是应该由开发人员自己去沟通处理的。开发负责人从中协调，测试人员完全不应该参与，只需要定期汇报未解决的缺陷即可。

　　问题2）

　　a、本身是没有绝对的正规测试流程的，现在大家所听到的正规测试流程只是常见的、出自大公司、被模仿较多的而已。当今认可通用的测试流程是：测试需求分析（评审）－测试用例设计（评审）－测试执行（回归轮次间总结）－测试总结。

　　b、其实只要适合自己的，就是正规的，没有必要去追求所谓“正规”，因为原本就没有正规，只是大家为了凸显自己而加的很多修饰词语而已。如果理解了这点，就很好回答第二个问题，既然没有绝对的正规的流程，那么所谓的评审、TestCase等是否要局限于那个一板一眼的形式就值得商榷了。就像其实用敏捷的方法也是符合CMMI－DEV模型的道理一样，CMMI要求的文档证据，未必一定是Word、PPT，可以是一份会议简要、一个简单的记录、甚至是一张照片，只要能够满足做这个事情的最初目的，形式无所谓。

　　c、当项目非常紧张的时候，我们的测试需求、测试用例等没有必要做的那么一板一眼，按照文档模板写的清清楚楚，也没有必要一定死扣流程，把每个流程都执行到，要知道CMMI都是允许根据项目情况进行裁剪的。我们可以快速的罗列测试需求、简单的写测试用例、清楚的记录缺陷和跟踪缺陷。对于评审这个环节，也可以简化成交叉评审，如果时间更为紧张，就可以只针对优先级高的进行评审，而对于优先级低的可以不评审。

　　总结：考虑到以上两个问题都出自同一个公司，从这些问题可以看出，该公司对于整个开发过程的分工是非常不明确的。分工明确、职责清晰比你配备专职人员更为重要，因为你配备了专职测试，但是测试的分工和职责都不清晰，那这个测试就不能称之为专职了。建议该公司可以参与我公司不定期举行的关于质量和测试的公开课，甚至可以做一次专业的诊断，以更为明确的确定该公司研发方面的问题。