软件测试 | 性能测试范围

更多软件测试学习资料戳>>>

确定了性能测试策略和目标后，接下来的任务是确定性能测试范围。确定性能测试范围是性能测试策略制订工作的延续。

之所以要确定性能测试范围，是因为全面性能测试需要投入很高的成本。因此在具体的项目中通常不会执行真正意义上的全面性能测试，“全面性能测试”是一个相对的概念，主要是指测试范围、测试种类是否满足测试策略与目标。

确定测试范围常见的方法是对测试项或者测试需求进行打分，根据综合评分确定性能测试工作包含哪些测试内容。评分要素主要包含客户关注度、性能风险、测试的成本等，性能风险主要是指不进行该项性能测试需求，然后投产系统可能潜在的风险。

大多数情况下都会把那些客户关注程度或者性能风险较高的测试需求划分到测试范围内。尤其是客户关注度高的测试需求，即使完成此项需求的成本较高也应该进行测试，因为有义务向客户证明和保证系统的性能。在银行信用卡项目测试案例中，一些强度测试和大数据量测试尽管测试成本很高，但是对系统投产具有重大指导意义，而且客户十分关注，所以仍然要执行。

相反，那些对系统不起决定作用、执行成本较高的测试通常不会执行。

3-1 银行卡项目的测试需求打分表

在第 9.6 节测试实施过程中，可以看出打分高的性能需求关联的测试场景基本优先进行。本项目在开发阶段性能测试实施过程中，由于时间充裕，基本执行了全部设计的测试场景；而在用户现场测试阶段，只进行了打分较高的性能测试需求关联的测试场景。通过第 9 章的银行卡案例，还可以看出测试范围在实施过程中会根据项目需要进行调整。

这里需要注意一下的是打分标准，通常不同的公司、不同的项目都会有不同的标准。例如，如果测试人员能力水平很高，成本投入一项的分值可能会低些。

4.目标系统的业务分析

目标系统的分析过程也是熟悉业务的过程，主要任务是深入了解系统，确定系统中哪些是核心业务，哪些是一般业务，进而对系统进行分解。对目标系统进行分析是编写性能测试场景的基础，几乎所有的性能测试都不能脱离业务，尤其是核心业务模块相关联的性能测试。

目标系统业务分析的具体工作内容如下。

（1）确定系统的核心模块。核心模块一般很容易确定，通常业务比较复杂或者用户使用比较频繁的都是核心模块。比较复杂的是针对系统开发而言，使用比较频繁的是针对用户而言。测试分人人员应该站在这两个不同角度来分析系统中各个模块的地位，从而确定哪些是系统的核心模块。

（2）确定模块件的耦合关系。确定模块间耦合关系是为了更加清晰地了解核心模块间的数据传输方式，为设计“集成性能测试”即组合模块性能测试场景做准备。通过确定模块间如何接口，可以更真实地模拟用户并发时的情况，尤其是可以确定用户并发时一些算法是否正确。在第 9 章的银行信用卡的案例中，可以看到在明确模块间耦合关系后，可以很容易发现一些算法方面的问题。

（3）分析系统压力点。分析系统压力点是指站在全局角度来分析系统可能产生的瓶颈的功能点，进而制订合适的测试方案。这项工作很多时候是凭借经验和直觉来完成的。不过系统压力点多是用户使用比较频繁或者数据流量较大的地方，例如第 9 张的银行信用卡的案例中，系统的压力是自动录入数据和审批业务，前者要往数据库中写入大量的数据，后者则是大量的审批用户在并发地访问系统。

完成上面的工作后，测试设计人员基本掌握了目标测试系统的架构，为测试场景的设计打下了良好的基础。

5.用户以及场景分析

性能测试按照场景的不同一般可以分为两种，一种是基于用户实际使用情况的场景测试，另一种是为了特殊测试目的而设计的场景测试。前者主要是基于用户角度而进行的测试，是为了测试系统是否满足用户的基本使用要求，后者主要是基于技术角度而进行的测试，主要是为了测试系统的扩展性、稳定性等方面，两类测试场景都要以用户的实际使用情况为基础来进行设计。

用户场景分析是指对用户使用目标测试系统的情况进行分析，从而确定系统有多少类典型的用户、每类用户的大概数量以及在不同时间段各类用户大概按照何种比例来使用系统。通过对用户使用情况进行分析，可以更加真实地模拟用户行为，保证测试结果的可靠性。比较常见的用户场景有以下三种。

• 一天内不同时间段的使用场景

• 系统运行不同时期的场景

• 不同业务模式下的用户场景

场景设计的详细方法将会在第 3.2.4 节性能测试场景设计中讲解。

在完成了 3.2 经.1 节的一系列需求准备工作后，将进入到性能测试整体规划、计划制订、测试场景设计阶段。

搜索微信公众号：霍格沃兹测试学院