1、 测试人员需要何时参加需求分析？
原则上，测试人员对需求了解得越深入对测试工作越有利，所以最好一开始就应该参加需求分析工作。这样可以带来如下好处：
■  测试人员全程参与需求分析，对需求了解很深刻，减少了很多与开发人员的交互，节省了时间。测试人员参与前期开发讨论，直接掌握了不清晰的需求点；
■  早期确定测试用例的编写思路，为项目（产品）测试打好了基础；
■  可以获取一些测试数据，为测试用例设计提供帮助；
■   可以发现需求不合理的地方，降低了测试成本。

测试人员主要的工作之一就是确认系统是否正确实现了需求。测试人要不参与前期的工作，就只能依赖最后形成的需求文档，甚至由开发人员来讲解需求，而这些需求可能发生了“问题”，因为这个需求是已经经过分析的需求，很多的内容可能与用户的真正要求发生了偏差。同时如果只看最后形成的需求文档，对需求也会有理解上的偏差。因此作为测试人员要尽可能的获取到“第一线”的需求资料，才能真正地了解用户的业务，从而更好的对系统进行测试。

当然，如果测试人员不能参与需求环节，一定要通过其他途径保证需求的正确性，例如和开发人员进行集中讨论需求疑问的项目会议，并且一定要加强测试案例评审，甚至于是测试需求的评审。

2、 系统测试阶段低级缺陷较多怎么办？
       在系统测试阶段，如果仍有很多低级缺陷，说明测试对象是不合格的，没有达到测试标准。如果系统阶段发现的简单缺陷（也就是不应该有的缺陷）较多，最好停止测试，反馈给开发人员进行测试，发现问题立刻修改，因为这种由测试人员进行测试的成本较高，反复交互还会耽误项目进度。

       建议建立预测试制度：系统测试前对核心模块进行抽查测试，如果问题较多（例如核心功能存在20个以上的缺陷），就可以停止本次测试，反馈给开发组进行测试，直到抽测后问题较少才可以启动系统测试。

3、 缺陷流落到客户那里有什么后果？

       如果软件缺陷被遗落到客户那里，结果就是代价高昂的电话或现场支持费用，还可能需要修复、重新测试和发布新的产品，更糟糕的情况是产品要被召回甚至被客户起诉。这种成本付出非常高，几乎是在内部修改缺陷的几倍，甚至十几倍。

       质量之父PhilipCrosby把质量的费用分为整合费用和非整合费用两类，整合费用是指与一次性计划和执行测试相关的全部费用，用于保证软件按照预期方式进行。如果发现缺陷，经过一系列的缺陷处理流程而解决缺陷，这种费用就是非整合费用。PhilipCrosby在自己的作品中详细论述了内部的整合费用和内部的非整合费用之和远远小于外部也就是客户引起的非整合费用。

       软件测试是保证软件质量的有效手段，但不是唯一手段。高质量的软件不是测试出来的，而是设计出来。这就需要全员一起参与，提高全员的质量意识，共同提高软件的质量。

       总之，软件缺陷一定要尽可能的在内部解决，这对节约成本、提高产品知名度都大有意义的。

4、 状态为已经修改的缺陷没有修改怎么办？

首先对这类缺陷进行分析：

（1）       有些问题在开发环境下没有重现，而开发人员迫于进度压力，往往会把它标记为已经修改。这种条件下测试人员应该和开发人员进行直接沟通；

（2）       有些问题测试人员没有描述清楚，开发人员认为问题不存在也可能把问题标记为已经修改（正确的作法是标记问题为商讨或者不可再现状态）。测试人员应该清晰的描述问题，减少这类问题的发生，尤其要描述清楚运行的环境以及缺陷的重现步骤；

（3）       第三类情况纯属个人行为：迫于进度压力，开发人员来不及修改问题，会故意把一些问题标记为修改，这样就可以在下次测试后进行修改。解决这种问题的方法就是统计缺陷的修改次数，分析出哪些反复修改的缺陷归属于哪些开发人员，然后告知项目经理；（由可能和绩效考核结合起来。）测试人员遇到这种情况，需要重新打开哪些未被修改而状态为修改标记的缺陷。

    决这种问题的根本方法就是加强项目管理，提高项目执行能力，一旦资源较充裕时，测试人员和开发人员就会更加投入的一起解决缺陷，共同来提高软件质量。这就需要在制定项目计划时尽量要合理。

5、 产品测试完成后产品由谁来发布？

       很多时候产品经过最后一次测试后由开发人员来发布，或由质量管理部来发布，这样做都是不合适的。

        开发人员发布产品常常会导致缺陷解决不彻底。一种较常见的现象是最后一次回归测试后，开发人员修改完成最后几个缺陷直接从开发环境发布产品，这种条件下实际是缺陷一次测试，因为修改缺陷通常会引入新的缺陷，甚至是严重的缺陷。

        测试人员发布产品也不符合流程的，测试人员的职责是报告软件质量情况。而且测试人员发布产品容易带来版本管理混乱。

        正确的做法是产品经过最后一次测试后，把产品和缺陷修改情况存入产品基线库，形成一个可以发布的版本。这样发布产品的一个前提是每次产品提交测试前都要有一个预备发布版本，测试或者回归测试后如果有问题需要修改解决，开发人员对该预备版本进行修改。如此反复多次后，直到最后一次测试，所有缺陷都得到修改或者审核，同时开发人员此次测试后没有对产品经过任何修改，我们就可以把这个最后一个预备发布版本存入基线库。

         进行了上面正确的版本控制后，我们可以通过配置管理库进行产品发布管理。对外部发布产品时，直接从配置管理库中提取就可以了

。

6、 用户试用阶段产生的新需求或修改意见由谁来处理？

在试用阶段用户会提出一些新的需求或修改意见，这些意见的反馈渠道应该是怎么样的呢？是反馈给测试人员、质量保证人员、项目经理还是项目的负责人？实际情况证实，这些新的需求或修改意见，反馈给项目经理或项目的负责人是最好的渠道，这样项目经理或项目负责人能够直接得到项目的修改意见或新增需求，而不是其他人员的转述。还因为项目经理或项目负责人是项目的设计者、开发者，他们对软件系统最熟悉，对于用户提出来的新的需求或修改意见可以根据系统的实际情况，应允合理的需求和合理的修改意见。屏蔽一些不合理的需求或修改意见，或给用户一个合理的不能修改的解释。

如果先给测试人员或是质量保证人员，效果不会很好；首先测试人员得到新的需求或修改意见后，不能马上确认是否修改，不清楚修改这些功能的工作量和是否有技术上的难点等疑问。其次在测试人员得到需要后，仍需要转述给项目经理或项目负责人，这样在一定程度上浪费了一些时间。主要表现在，如果测试人员没有完全理解新的需求或修改意见，这样在转述的时候就会有偏差，还得需要项目经理或项目负责人在对需求或修改意见进行再次确认，这样就产生了不必要的工作量