性能测试需求分析------下篇

随着互联网技术的飞速发展，互联网应用架构越来越复杂，运营系统涉及的利益相关越来越多。因此，在性能测试工作实施过程中，需要从不同的用户层面分析待测需求。

确定性能测试的必要性后，性能测试工程师主要从以下两个用户方面，确定性能测试需求。

业务用户

1. 用户频繁使用，且存在大量用户使用的业务流程；
2. 交易占比较高，日常占比在80%以上甚至更高的业务流程；
3. 特殊交易日，或峰值交易占比80%以上甚至更高的业务流程；
4. 性能较差且有过调整的业务流程
5. 特殊业务场景；
6. 核心业务发生重大流程调整的业务流程

ps：以上从业务用户层面，考虑的可能需要进行性能测试的点。实际实施过程中，如果可能，可向终端用户调研。

项目团队

1. 曾经测试性能后，调整了架构设计的业务。
2. 逻辑复杂，关键的业务
3. 可能消耗大量的资源的业务
4. 与外部系统存在接口调用，且有大量数据交互的业务
5. 调用第三方业务组件，逻辑复杂的业务。

ps：以上从项目开发角度考虑可能，需要进行性能测试业务流程，性能测试工程师，需要对被测对象，进行深入的了解，并且需要研发团队配合。

除了上述两种用户，还可能包括运营团队，调研未来业务发展规划，系统需要满足未来业务需求的可能性。

需求评审

确定性能测试需求后，如果有必要，需要进行某种程度的测试需求评审。

性能测试需求评审与功能测试需求评审类似，都需要关注需求本身的可测性、一致性及正确性。

可测性：

软件可测性，通常理解为，软件本身是否具备实施测试的条件，是否便于发现缺陷以及定位缺陷。

在一定的时间及成本范围内，构建测试环境，设计及执行测试用例，测试工程师能够相对便捷的发现，定位缺陷，从而协助研发人员解决对应的缺陷，无论是功能测试，还是性能测试，都需要被测试对象，具备上述的可测试性特征。

性能测试活动与功能测试活动，都有个显著的特点：被测试对象，运行环境要求不同。实施功能测试时，只要被测试对象，能够在合理的运行环境中，正常运行即可。即使测试环境与生产环境可能存在较大的差异，性能测试则不同。性能测试一定要模拟尽可能真实的运行环境。当测试环境与实际生产环境差异较大时，性能测试结果往往不被接受。如果在性能测试实施过程中，无法搭建相对真实的测试环境，即可认为被测试对象，不具备性能测试的可测性。

一致性

性能测试需求一致性，主要关注用户需求、生产需求、运营 需求几个方面。通过对性能测试需求的分析，判断本次测试需求是否满足用户需求规格说明书中明确列出的性能需求项。生产需求，则是关注被测试对象运行的真实性。从而在测试结束后能够提供相对准确的数据依据。

运营需求，需要以历史数据或者现今运营数据为基础，规划未来业务发展的可能性，从而使得被测试对象，性能指标具有一定的冗余度。

通过性能测试需求评审活动，确定本次性能需求，与上述的关注点一致。

正确性

在可测性与一致性得到保证的基础上，需针对性能测试指标进行验证，从而保证后续实施活动中所关注的各个项目需求、场景及指标的正确性，从而尽量减少返工，重新设计的风险。

通过可测性、一致性及正确性的评估，最终确定本轮性能测试需求，并从作为后续测试实施活动的输入。