关键字：第三方软件测试，性能效率，需求分析
0引言
第三方软件测试是不同于软件开发企业内部或系统建设单位自组织的测试活动，其目的是为了保证测试工作的客观性。第三方测试在测试依据、测试能力、质量管理体系等方面上都有其特定的要求。它在运行过程中受国家认证认可监督管理委员会的监督。
目前，国内第三方测试机构在进行软件测试时，所依据的主要标准为GB/T 25000.51-2016 《系统与软件工程 系统与软件质量要求和评价（SQuaRE）第51部分：就绪可用软件产品（RUSP）的质量要求和测试细则》。该标准关于性能效率质量特性的定义为：在规定条件下，相对于所用资源的数量，软件产品可提供适当性能的能力。其中，资源可能包括其他软件产品、系统的软件和硬件配置，以及物质材料（如打印纸，磁盘等）。本文所谈到的“性能”即为上述标准所提到的“性能效率”概念。
时间特性是指产品或系统执行其功能时，其响应时间、处理时间及吞吐率满足需求的程度；
资源利用性是指产品或系统执行其功能时，所使用资源数量和类型满足需求的程度；
容量是指产品或系统参数的最大限量满足需求的程度。这里的参数可包括存储数据项数量、并发用户数、通信带宽、交易吞吐量和数据库规模；
性能效率依从性是指软件或系统遵循与性能效率有关的标准、约定或法规及类似规定的程度。
1需求分析概念及范围
性能测试需求分析作为性能测试过程的初始阶段，是整个测试工作顺利开展的基础。对于第三方测试机构而言，性能测试需求分析不仅仅意味着对性能测试指标、架构及使用场景等内容的分析，也需要对拟采用的测试技术方法进行可行性分析；从时间跨度上来看，覆盖了从原始性能测试需求接收至合同内容确定这个时间段；此项活动的总体目标是确定委托方（提出测试需求的机构）及第三方测试机构双方均认可的性能测试需求内容。具体来说可以分为三个方面：
1、明确委托方真实测试意图、指标等；
2、确定是否可以帮助委托方解决测试需求，即是否有相应的测试技术解决方案；
3、根据测试指标，评估测试工作量。
2需求分析路线
2.1依据性能测试需求文档进行初步分析
一般来讲，委托方所提供的系统建设需求规格说明书中会列明性能测试指标，特别是对于验收测试来讲，系统建设需求规格说明书是性能测试所依据的一个重要参考文档，该文档通常会描述了该系统所要完成的内容及要达到的性能水平。特别是近年来，大家对系统/软件质量重视程度有所提高，所以性能测试需求分师可以在这个文档中试着寻找对性能测试指标的有关要求。但有些情况下，性能测试需求可能会以其它文档形式提供，比如课题任务书或其它专门为本次测试所编制的测试需求文档。
有时委托方无法提供系统建设需求规格书或是该文档中缺少性能测试指标的描述，那就只能通过其它沟通方式获取对方对性能测试指标的初步需求。
在接到原始测试需求后，测试工程师首先按指标类型将委托方要求的测试指标进行归类整理。这里可以借助表格或附件所提供的模板将指标列出。至此为止，我们所梳理的指标还是比较原始的需求，我们需要对指标一个个地进行分析，分析时需要考虑以下三个重要方面：
一是分析该指标否具备可测试性。可测试性是指该指标可以通过测试而非通过主观评估的手段可得出的结论。比如类似“该系统具有较快的响应时间”。这种描述的指标就不具有可测试性。
二是分析该指标是否具备测试的可实施性。这个可实施性也不是单纯从测试技术方面考虑，还要结合是否有合适的测试方法、环境及工具，比如系统要求“PB级数据量情况下要求达到秒级响应”，虽然在测试方法及工具上可以测试该指标，但是对于PB级的数据量这一测试环境如何才能构造？如果委托方无法提供相应的测试环境，对于这样的测试指标，就不能轻易给委托方承诺可以实施测试。再比如委托方要求10万用户并发的情况，因为受性能测试工具影响、带宽影响、测试压力机数量和性能的影响，可能无法完成委托方的要求。
三是分析指标描述是否明确。有时，委托方虽然提出了测试指标，但是要知道，测试指标需要结合业务场景才有意义，比如页面响应时间要求为3秒钟，那该响应时间是在多大负载下执行哪类业务时要达到的要求？因此梳理指标时发现存在这个问题时，须在后续工作中将这类指标与相应的特定场景相对应。
当然在这个步骤，我们还只是立足于自身角度对指标进行分析，我们可以把有疑问的指标进行标注，以备就这些问题与委托方作进一步的沟通。
列表是进行指标梳理的一个有效的方式。通过表格，将各个指标进行直观表达，同时可以将场景与指标进行相对应，为下一阶段的测试用例设计作准备。
2.2主动了解委托方业务场景
在和委托方取得初步接触后，我们需要就接收到的测试需求展开相关业务知识的了解与学习。
对于资深性能测试工程师而言，结合自己的工作经验，往往可以从委托方简单的业务描述中基本了解系统及业务的内在逻辑，但对于初学者而言，需要另行通过对方所提供的详细技术文档了解委托方的系统业务流程及逻辑，以便与委托方进行更深入的沟通。当然除此之外，学习的渠道很多，可以向周围有经验的同事咨询，也可以通过搜索引擎、委托方官网上关于产品的介绍信息等进行学习。总之所有这期间学习的目的都是为了下一步能和委托方作深入沟通。
2.3与委托方进一步沟通
很多情况下，由于缺少对第三方测试专业性的了解，或是因为文字描述能力水平有限亦或是基于自身业务的考虑，委托方可能会有意或无意地对性能测试需求文档写得不够详细或无法准确表达自己的测试诉求，因此测试工程师需要和委托方作进一步的沟通。沟通可以有多种形式，包括面对面、电话、各种即时通讯工具等。最终沟通的目的是将双方认可的测试内容明确下来。
由于这里所提及的沟通是基于第一、二步骤基础上进行，因此沟通内容可以将重点集中于描述含糊或自己所关注的问题上。具体说来，与委托方要沟通的内容包括如下几个方面：
1.落实未明确的指标及场景，并将场景与相应的测试指标相关联。如“响应时间3秒”这一指标要与100用户并发执行某动作操作相关联。
2.确认是否删除不可测试或因测试条件不具备而无法提供测试服务的指标。即对于不具备可测试性的指标或无法满足测试条件的指标，需要和委托方解释原因，征求委托方意见，以确定是否删除这些指标，如果委托方不同意，则无法进行下一步合作。
3.有时需要建议要增加一些测试指标、场景或其它性能测试服务内容。有些内容尽快委托方没有提及，但是基于第三方测试机构的工作经验，可以从专业性的角度提出一些原始需求中未提及的测试项，供委托方参考。
需要注意的是，这个阶段与委托方的沟通有时不是一次就可以完成的，很多情况下需要多次沟通。一方面是因为尽管测试工程师前期做了比较充分的准备工作，但是面对五花八门的测试需求，测试工程师确实很难立即给出明确的答案。特别是对于性能测试的初学者，因为性能测试经验不够丰富或对评测能力相关资源不够了解，遇到这种情况，需要明确测试资源后再给对方以答复。另一方面，有时委托方也需要作内部协调及沟通，需要内部确认后才能作下一步沟通。
2.4将沟通结果形成文档
委托方及第三方测试机构沟通后所明确的测试需求分析结果必须形成书面文档，作为测试工作内容的主要依据，该内容可以直接体现在测试服务合同正文中或是作为合同附件而存在。以避免双方日后对测试内容理解不一致而产生纠纷。
一个完整而明确的性能效率测试需求至少要包括测试指标及要达到的预期值、相对应的业务功能或事务名称。测试实践中，性能效率指标一般包括三类：时间特性、容量和资源占用率，性能效率的标准依从性质量特性很少涉及，一般不予考虑。时间特性方面表现为页面响应时间、吞吐率等，容量特性表现为吞吐量、在线用户、并发用户等，资源占用率表现为CPU占用率、内存占用率、IO吞吐率等。对于分布式应用下的负载测试，性能测试需求描述除了测试指标及预期值外，还需要将指标与特定的场景关联后加以明确，具体包括背景数据量、用户规模、业务功能等。
3结束语
本文结合第三方性能效率测试实践，总结了其需求分析的工作路线。需要说明的是该路线只是性能测试需求分析的基本工作流，不是一成不变的，根据实际情况，可以做适当调整。
版权声明：本文出自《51测试天地》第五十八期。51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
