vlambda博客
学习文章列表

出品 | 51Testing软件测试网

摘要：本文定义了软件性能效率测试需求分析的概念及范围，基于第三方软件测试机构在性能效率测试工作的实践经验，总结了一套性能效率测试需求分析的工作思路。

引言

需求分析概念及范围

性能测试需求分析作为性能测试过程的初始阶段，是整个测试工作顺利开展的基础。对于第三方测试机构而言，性能测试需求分析不仅仅意味着对性能测试指标、架构及使用场景等内容的分析，也需要对拟采用的测试技术方法进行可行性分析；从时间跨度上来看，覆盖了从原始性能测试需求接收至合同内容确定这个时间段；此项活动的总体目标是确定委托方（提出测试需求的机构）及第三方测试机构双方均认可的性能测试需求内容。具体来说可以分为三个方面：

1、明确委托方真实测试意图、指标等；

2、确定是否可以帮助委托方解决测试需求，即是否有相应的测试技术解决方案；

3、根据测试指标，评估测试工作量。

需求分析路线

2.1依据性能测试需求文档进行初步分析

一般来讲，委托方所提供的系统建设需求规格说明书中会列明性能测试指标，特别是对于验收测试来讲，系统建设需求规格说明书是性能测试所依据的一个重要参考文档，该文档通常会描述了该系统所要完成的内容及要达到的性能水平。特别是近年来，大家对系统/软件质量重视程度有所提高，所以性能测试需求分师可以在这个文档中试着寻找对性能测试指标的有关要求。但有些情况下，性能测试需求可能会以其它文档形式提供，比如课题任务书或其它专门为本次测试所编制的测试需求文档。

有时委托方无法提供系统建设需求规格书或是该文档中缺少性能测试指标的描述，那就只能通过其它沟通方式获取对方对性能测试指标的初步需求。

在接到原始测试需求后，测试工程师首先按指标类型将委托方要求的测试指标进行归类整理。这里可以借助表格或附件所提供的模板将指标列出。至此为止，我们所梳理的指标还是比较原始的需求，我们需要对指标一个个地进行分析，分析时需要考虑以下三个重要方面：

一是分析该指标否具备可测试性。可测试性是指该指标可以通过测试而非通过主观评估的手段可得出的结论。比如类似“该系统具有较快的响应时间”。这种描述的指标就不具有可测试性。

二是分析该指标是否具备测试的可实施性。这个可实施性也不是单纯从测试技术方面考虑，还要结合是否有合适的测试方法、环境及工具，比如系统要求“PB级数据量情况下要求达到秒级响应”，虽然在测试方法及工具上可以测试该指标，但是对于PB级的数据量这一测试环境如何才能构造？如果委托方无法提供相应的测试环境，对于这样的测试指标，就不能轻易给委托方承诺可以实施测试。再比如委托方要求10万用户并发的情况，因为受性能测试工具影响、带宽影响、测试压力机数量和性能的影响，可能无法完成委托方的要求。

三是分析指标描述是否明确。有时，委托方虽然提出了测试指标，但是要知道，测试指标需要结合业务场景才有意义，比如页面响应时间要求为3秒钟，那该响应时间是在多大负载下执行哪类业务时要达到的要求？因此梳理指标时发现存在这个问题时，须在后续工作中将这类指标与相应的特定场景相对应。

当然在这个步骤，我们还只是立足于自身角度对指标进行分析，我们可以把有疑问的指标进行标注，以备就这些问题与委托方作进一步的沟通。

列表是进行指标梳理的一个有效的方式。通过表格，将各个指标进行直观表达，同时可以将场景与指标进行相对应，为下一阶段的测试用例设计作准备。

2.2主动了解委托方业务场景

在和委托方取得初步接触后，我们需要就接收到的测试需求展开相关业务知识的了解与学习。

对于资深性能测试工程师而言，结合自己的工作经验，往往可以从委托方简单的业务描述中基本了解系统及业务的内在逻辑，但对于初学者而言，需要另行通过对方所提供的详细技术文档了解委托方的系统业务流程及逻辑，以便与委托方进行更深入的沟通。当然除此之外，学习的渠道很多，可以向周围有经验的同事咨询，也可以通过搜索引擎、委托方官网上关于产品的介绍信息等进行学习。总之所有这期间学习的目的都是为了下一步能和委托方作深入沟通。

2.3与委托方进一步沟通

由于这里所提及的沟通是基于第一、二步骤基础上进行，因此沟通内容可以将重点集中于描述含糊或自己所关注的问题上。具体说来，与委托方要沟通的内容包括如下几个方面：

1.落实未明确的指标及场景，并将场景与相应的测试指标相关联。如“响应时间3秒”这一指标要与100用户并发执行某动作操作相关联。

2.确认是否删除不可测试或因测试条件不具备而无法提供测试服务的指标。即对于不具备可测试性的指标或无法满足测试条件的指标，需要和委托方解释原因，征求委托方意见，以确定是否删除这些指标，如果委托方不同意，则无法进行下一步合作。

3.有时需要建议要增加一些测试指标、场景或其它性能测试服务内容。有些内容尽快委托方没有提及，但是基于第三方测试机构的工作经验，可以从专业性的角度提出一些原始需求中未提及的测试项，供委托方参考。

需要注意的是，这个阶段与委托方的沟通有时不是一次就可以完成的，很多情况下需要多次沟通。一方面是因为尽管测试工程师前期做了比较充分的准备工作，但是面对五花八门的测试需求，测试工程师确实很难立即给出明确的答案。特别是对于性能测试的初学者，因为性能测试经验不够丰富或对评测能力相关资源不够了解，遇到这种情况，需要明确测试资源后再给对方以答复。另一方面，有时委托方也需要作内部协调及沟通，需要内部确认后才能作下一步沟通。

2.4将沟通结果形成文档

委托方及第三方测试机构沟通后所明确的测试需求分析结果必须形成书面文档，作为测试工作内容的主要依据，该内容可以直接体现在测试服务合同正文中或是作为合同附件而存在。以避免双方日后对测试内容理解不一致而产生纠纷。

一个完整而明确的性能效率测试需求至少要包括测试指标及要达到的预期值、相对应的业务功能或事务名称。测试实践中，性能效率指标一般包括三类：时间特性、容量和资源占用率，性能效率的标准依从性质量特性很少涉及，一般不予考虑。时间特性方面表现为页面响应时间、吞吐率等，容量特性表现为吞吐量、在线用户、并发用户等，资源占用率表现为CPU占用率、内存占用率、IO吞吐率等。对于分布式应用下的负载测试，性能测试需求描述除了测试指标及预期值外，还需要将指标与特定的场景关联后加以明确，具体包括背景数据量、用户规模、业务功能等。

结束语

本文结合第三方性能效率测试实践，总结了其需求分析的工作路线。需要说明的是该路线只是性能测试需求分析的基本工作流，不是一成不变的，根据实际情况，可以做适当调整。