对于测试时间和测试资源有限的软件产品测试而言，基于风险的测试是一个比较好的选择，可以帮助测试人员更好地提高测试效率并提升对测试对象的信心。这种测试作为一种有效的软件测试方法，它自身又会面临各种挑战，它的风险又在哪里呢？本文将阐述基于风险的测试过程中经常面临的一些问题并根据实际情况给出的一些建议。

　　（1）测试风险分析自身的风险

　　基于风险的测试需要分析和评估测试中存在的风险，并根据得到的结果将测试对象按照不同优先级排列，首先测试重要和优先级高的部分。但是测试风险评估本身也可能存在偏差，导致测试人员和测试资源分配的不合理。更严重的情况可能是高优先级的测试对象被分析和评估为低优先级，甚至由于时间和成本的原因而没有测试。为了避免这种情况的出现，需要在测试风险分析和评估中采用如下一些方法。

　　● 尽量召集各个方面的项目参与人员共同识别和分析测试风险，如项目经理、系统人员、开发人员、测试人员、实验室管理员和配置管理员等，以求测试风险的全面和准确。

　　● 测试人员积极参与项目的各种评审，从项目管理、业务管理和用户角度深入分析和研究项目中可能存在的各个方面的风险。

　　● 分析测试过程中发现的缺陷的来源。如果发现很多缺陷来自低优先级的测试对象，或者在这种对象中发现了严重的问题，那么需要重新分析和评估这部分测试对象的风险。

　　● 对低风险的测试对象执行一些探索性测试，以判断风险分析和评估的正确性。

　　（2）完成测试之后的风险

　　基于风险的测试可以加速提升对软件产品质量的信心。因此当时间、成本和资源等有限且在测试完成率为“可以发布”时，可能结束测试，而不是达到的测试完成率，测试完成率没有达到意味着低风险或优先级比较低的测试对象可能没有测试或完成测试。实际上这种情况也是存在风险的，需要进一步采取一些措施来减轻这方面的风险。

　　● 在软件发布以后，测试团队在时间和资源允许的条件下，应该继续后续的测试。直到测试计划中的测试全部执行完毕，达到的测试完成率。

　　● 将测试的软件产品和测试环境移交给软件产品的维护组，使其能够快速地定位和解决市场和用户反馈的问题和缺陷。

　　（3）基于风险的测试是管理人员的事情

　　在讨论基于风险的测试时，经常可以听到这样的言论：“这是管理人员的事情”，如根据产品风险对相关测试活动分配测试资源。实际上基于风险的测试不仅仅是管理人员的事情，测试分析、设计和执行人员在其中都有各自的职责。无论是风险识别和评估，还是制订和实施具体的风险应对措施都需要各方面人员的积极参与。

　　（4）风险列表不清晰

　　识别和分析风险可以有多种方法，测试过程中经常采用的是头脑风暴法，即测试经理召集测试团队成员和其他利益相关者开展风险识别活动。通过头脑风暴法，测试团队很快可以得到一个很长的风险列表。面对这样的一个风险列表，如何管理这些风险将是一个问题。例如，有的风险描述含糊不清，有些风险则冗余重复，因此较好的方法是将头脑风暴法和其他风险识别方法相结合。基于风险模板和基于质量特性的头脑风暴法可以为风险提供系统性的保障并避免风险的重复。