软件测试流程常见问题

　　（3）第三类情况纯属个人行为：迫于进度压力，开发人员来不及修改问题，会故意把一些问题标记为修改，这样可以在下次测试后进行修改。解决这种问题方法是统计缺陷的修改次数，分析出那些反复修改的缺陷归属于那些开发人员，然后和绩效考核结合起来。（测试人员也可以这样做，把一些未验证的缺陷标记为“重新打开”，让开发人员来帮忙“验证”，我们仍然可以统计这种问题的次数，后根据时间进行分析。）

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

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

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

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

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

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

　　进行了上面正确的版本控制后，我们可以通过配置管理库进行产品发布管理。对外部发布产品时，直接从配置管理库中提取可以了。详细的内容，读者可以参考配置管理方面的书籍。

　　11、性能测试什么时候开展为合适？

　　大多数情况下，性能测试在系统测试的后阶段进行阶段进行。这主要是由于性能测试是一种综合性的测试，只有在功能测试通过后，谈系统测试才会有较大意义。但下列两类情况比较特殊，性能测试一般进行的较早，几乎伴随着单元测试同步进行：

　　第一类是系统软件，例如开发操作系统或者数据库，等系统开发完成后再进行性能的作用是进行一个综合评估。如果在后发现性能问题，很有可能推翻整个系统。

　　第二类是对性能要求较高的应用软件。例如银行、电信的系统，对系统的性能要远远高于一般的办公自动化系统。这类系统软件后测试时发现性能问题，往往是系统架构或者一些关键算法、重要功能模块的原因，这个时候会带来较大的改动，甚至可能报废整个系统。

　　对于上面两类软件，性能测试应该贯穿着整个软件开发过程，大致要经过下面几个测试过程：

　　（1）单元性能测试阶段。上面这两类软件的性能测试后从单元测试阶段应该介入，具体做法是安排性能测试工程师对一些重要算法进行测试，保证这些算法能够满足性能要求。这样做的好处是把问题尽早解决，可以大大提高整体性能。

　　（2）组成/集成性能测试阶段。这个阶段的性能测试是前面的深入，相当于把系统测试阶段的组合业务性能测试提前进行，可以把一些性能问题在集成测试阶段发现并解决。

　　（3）系统测试阶段的性能测试。这个阶段的性能测试是一个全面的性能测试，有了前面的基础，这个时候发现的问题很更加容易解决。