1、 测试人员需要何时参加需求分析？
　　原则上，测试人员对需求了解得越深入对测试工作越有利，所以最好一开始就应该参加需求分析工作。这样可以带来如下好处：
　　■  测试人员全程参与需求分析，对需求了解很深刻，减少了很多与开发人员的交互，节省了时间。测试人员参与前期开发讨论，直接掌握了不清晰的需求点；
　　■  早期确定测试用例的编写思路，为项目（产品）测试打好了基础；
　　■  可以获取一些测试数据，为测试用例设计提供帮助；
　　■   可以发现需求不合理的地方，降低了测试成本。
　　测试人员主要的工作之一就是确认系统是否正确实现了需求。测试人要不参与前期的工作，就只能依赖最后形成的需求文档，甚至由开发人员来讲解需求，而这些需求可能发生了“问题”，因为这个需求是已经经过分析的需求，很多的内容可能与用户的真正要求发生了偏差。同时如果只看最后形成的需求文档，对需求也会有理解上的偏差。因此作为测试人员要尽可能的获取到“第一线”的需求资料，才能真正地了解用户的业务，从而更好的对系统进行测试。
　　当然，如果测试人员不能参与需求环节，一定要通过其他途径保证需求的正确性，例如和开发人员进行集中讨论需求疑问的项目会议，并且一定要加强测试案例评审，甚至于是测试需求的评审。

　　2、 系统测试阶段低级缺陷较多怎么办？
　　在系统测试阶段，如果仍有很多低级缺陷，说明测试对象是不合格的，没有达到测试标准。如果系统阶段发现的简单缺陷（也就是不应该有的缺陷）较多，最好停止测试，反馈给开发人员进行测试，发现问题立刻修改，因为这种由测试人员进行测试的成本较高，反复交互还会耽误项目进度。
　　建议建立预测试制度：系统测试前对核心模块进行抽查测试，如果问题较多（例如核心功能存在20个以上的缺陷），就可以停止本次测试，反馈给开发组进行测试，直到抽测后问题较少才可以启动系统测试。

　　3、 缺陷流落到客户那里有什么后果？
　　如果软件缺陷被遗落到客户那里，结果就是代价高昂的电话或现场支持费用，还可能需要修复、重新测试和发布新的产品，更糟糕的情况是产品要被召回甚至被客户起诉。这种成本付出非常高，几乎是在内部修改缺陷的几倍，甚至十几倍。
　　质量之父PhilipCrosby把质量的费用分为整合费用和非整合费用两类，整合费用是指与一次性计划和执行测试相关的全部费用，用于保证软件按照预期方式进行。如果发现缺陷，经过一系列的缺陷处理流程而解决缺陷，这种费用就是非整合费用。PhilipCrosby在自己的作品中详细论述了内部的整合费用和内部的非整合费用之和远远小于外部也就是客户引起的非整合费用。
　　软件测试是保证软件质量的有效手段，但不是唯一手段。高质量的软件不是测试出来的，而是设计出来。这就需要全员一起参与，提高全员的质量意识，共同提高软件的质量。
　　总之，软件缺陷一定要尽可能的在内部解决，这对节约成本、提高产品知名度都大有意义的。