通过对性能测试团队所发现缺陷的分析，可以统计出功能测试缺陷所占比例，看是否功能测试缺陷比例过高，是否严重影响了性能测试的进度，从而分析在今后的测试过程中，哪些测试流程需要提高而尽量减少性能测试中的功能缺陷。例如增强和功能团队的沟通，尽量了解性能测试中，每个测试案例里所需主要功能的进展情况等。

　　另外，性能测试需要安装和客户相近的测试环境，所以也会不可避免地发现安装缺陷。它的测试环境的复杂度也会帮助安装团队扩大安装测试范围。

　　如图9-8所示，在性能测试中，功能缺陷占大约28%。这个比例稍微偏高，会对性能测试的进度有所影响。我们在分析过程中可以着重看看哪些功能缺陷是可以通过提高流程而避免的，并制定好相应计划，在今后测试中有所改进。

　　6、操作系统分析缺陷

　　如果是Java EE的应用程序，应该不会有太多操作系统相关的测试缺陷。但由于安装程序或多或少会和操作系统的设置文件有关，所以在测试中不可避免地会发现操作系统特定问题，例如某些缺陷只在Solaris上存在，在其他操作系统上没有问题。

　　通过缺陷分析，可以清晰地了解操作系统特定缺陷所占比例。如果比例不大，在测试中可以把大部分测试案例都放在机器资源相对充足、便宜且操作系统相对简单的环境里测试，以减少测试人员和机器资源的消耗。

　　如图9-9所示，安装测试中和操作系统无关的缺陷占88%，所以大部分测试案例可在一种操作系统上进行测试。但因为其他操作系统也存在特定缺陷，所以在所有其他操作系统上，也要安排一些测试案例。

　　7、按数据库分析缺陷

　　现在绝大部分软件产品会需要数据库来存储并提取数据。不同的数据库处理数据的方式会有所不同。如果一个产品同时支持多种数据库，可能存在同样的测试案例，在一种数据库上工作正常、但在另外数据库上出现问题的情况。

　　在测试过程中要尽量覆盖所有支持的数据库。如果有些功能对数据库不敏感，只需在某一数据库上集中测试，在其他数据库上做些小测试即可。如果功能对数据库极度敏感，要考虑不同数据库都要有足够的测试范围。

　　按数据库分析缺陷，可以相应看到哪些功能对数据库敏感且特定缺陷多，需要考虑是否在此功能上增加不同数据库的测试范围。

　　8、按可用性分析缺陷

　　在测试过程中，不但要测试产品功能是否正确，还要看产品是否好用，即通过用户的使用角度来评估产品。由于它反映了用户的真实使用经验，所以可以视为一种不可或缺的可用性检验过程，例如界面是否友好、是否提供在线帮助，用户在使用错误的情况下是否显示容易理解的异常信息等。测试团队应鼓励测试人员尽可能多地发现可用性缺陷来提高产品的质量，从而使用户有非常好的产品使用经历。

　　例如在安装产品过程中，如果操作系统不符合产品安装要求，应该报出错误信息，并终止安装。如果测试过程中没有报错误信息，只是在安装中途失败，这是一个可用性缺陷。在测试过程中，一定要从客户的角度来看问题。对于任何在使用时觉得不方便，不通用且容易造成用户困惑的功能，都要想想是否是可用性缺陷，是否应该进行修订而提高其易用性。