测试需求分析

测试需求分析测试需求分析原始测试需求分析通常情况下，测试需求来源一般都是需求规格说明书，但在现实项目中往往无法获取明确的用户需求，甚至没有需求（有些产品研发即是如此），故测试需求来源可能有多个途径，如开发需求、协议标准规范、竞争性分析文档等。根据测试计划的定义，测试工程师需进行测试需求分析，定义测试范围、明确测试项及测试子项，便于后续设计测试用例。在进行测试需求分析时，通常采用原始测试需求分析→测试项分析→测试子项分析三步法。测试需求分析原始需求：用户需求的概括表述及展示，基本通过用户口述，需求开发人员记录的方式生成，格式相对随意。例如，用户提出需要一杯水，需求开发人员则会记录“用户期望得到一杯水”类似的需求表述。需求规格：在原始需求的基础上进一步细化，软件质量概念中曾描述“满足要求”，因此体现软件质量优劣的核心标准即是特性符合程度，反向理解，即是需求表述是否定量或定性，只有明确了要求的规格，才能根据质量标准验证是否满足用户要求及满足的程度，因此需求规格是测试工程师真正需要关心的验证基础。在运用原始测试需求分析方法时，需要先了解这几个需求概念：原始需求、需求规格、开发需求、测试需求。关于需求规格说明书需求规格说明书是经过原始需求细化、与用户确认，从软件质量各大特性及其子特性考虑的量化的用户期望表述文档。一般而言，需求规格说明书包含功能性需求、性能需求、外部接口需求（用户界面接口及外部应用程序接口），根据用户对象不同，可能还包括安全性需求、移植性需求等。需求规格说明书须写明实现哪些需求，哪些需求不能实现，参考哪些现行标准/协议/规范等。例如，原始需求“用户需要一杯水”，需求规格则是“用户需要一杯50ml、60℃左右的纯净水”，定义了期望目标的容量、温度及属性，这样需求易于实现及易于验证。测试需求分析开发需求：开发需求在需求规格的基础上进一步细化，一般带有明确的实现方式。开发需求由开发人员根据需求规格进行细化，从体系架构、设计思想及人机交互环节考虑。例如，“用户需要一杯50ml、60℃左右的纯净水”细化为开发需求则为“用户需要一杯用双层玻璃杯盛着的50ml、60℃左右的纯净水，并且使用木质托盘送上”。测试需求：从软件测试角度考虑，关注可度量、可实现、可验证等几个方面。例如，上述的需求，50ml、60℃可度量，双层玻璃杯、纯净水、木质托盘可实现，整个定量及定性需求可验证，在开发需求保证继承于需求规格时，测试需求与开发需求差异不大。关于测试需求来源测试需求的来源主要有需求规格说明书、开发需求、协议/规范/标准、用户需求、继承性需求、测试经验库、同行竞争分析等。通过确定不同的需求来源，确定原始测试需求提取的范围。在实际分析提取过程中，存在参考多个来源信息的现象，可能存在重复和冗余，需要整理，整理后的原始测试需求（原始测试项）作为后续原始测试需求分析活动的输入。若测试需求来源是需求规格说明书，则测试工程师可以直接根据需求中的功能、性能、外部接口特性，提取测试项及测试子项。在这种情况下，提取出来的测试项及子项基本能保证测试需求的正确性及有效性。传统的软件项目，经过需求调研阶段，基本都会生成规范的项目需求规格说明书，这种情况下获取原始测试需求、测试项及测试子项相对容易。关于测试需求来源若测试需求来源是开发需求，测试工程师可以考虑直接将一条开发需求作为一条原始测试需求来提取，然后参考被测对象概要设计及详细设计规格，检查提取出的原始测试需求是否存在遗漏。在实际操作中，如果觉得开发需求的粒度不合适，需求不够明确具体，则可以考虑拆分成多条或者合并为一条原始测试需求。为明确测试和开发需求的对应关系，要建立原始测试需求和开发需求的跟踪关系（RTM，需求跟踪矩阵），明确提取的原始测试需求对应的开发需求标识，如果有合并的情况，则对应多个开发需求标识。

随着市场竞争激烈，产品同质化加剧，奢望一份规范的需求规格说明书，将变得很难，因此很多公司可能仅有开发需求，在这种情况下，测试工程师需根据开发需求及自身经验获取测试需求，并且测试需求初步提取后，一定需经过规范的同行评审环节进行评审验证确认。关于测试需求来源若测试需求来源是某行业的协议标准规范，则通常是将开发需求和相关的协议标准规范分配给同一个人，以其中一个为主，另一个为辅来提取原始测试需求。以开发需求为主提取出原始测试需求后，再针对协议、标准、规范来分析补充。可补充的原始需求通常包括如下情况：开发文档未详细说明，而是参见某某协议标准规范；开发文档未充分考虑到相关协议标准规范的要求，存在遗漏或者错误；除开发文档要求外，还存在其他需要遵循的协议规范和标准等情况。

在移动通信、金融证券产品领域内，根据行业协议、标准或规范获取测试需求是比较常见的，因为这些产品的开发基本都是遵循某些行业标准的，在需求规格说明书中经常看到“具体需求，请参考《××××通信协议》”等字样。关于测试需求来源若测试需求来源是用户需求，由于单独从用户需求和开发文档中提取原始测试需求，可能会存在大量的重复，所以通常也是将开发文档和相关的用户需求文档分给同一个人，以其中一个为主，另一个为辅来提取原始测试需求。因为开发需求往往是对用户需求的细化分解，所以一般情况是以开发需求为主提取出原始测试需求后，再通过对用户需求的分析验证提取的原始测试需求是否全面正确。同时，为了让测试更直接面向用户，可以以用户需求为主线，将从开发需求提取出来的原始需求进行整理，因为实际上将这些开发需求还原后，真正的需求来源就是用户需求。

关于测试需求来源质量较高的用户需求通常是从用户实际使用的角度来描述和划分的（可以称之为用户使用场景），此类做法比较符合测试的习惯或要求，可将它们直接作为原始测试需求核心内容，但由于用户考虑问题并没有参考系统的实现，对应到具体的系统上信息不完整，所以需要结合开发需求、设计规格和产品知识进行补充，使得其更加完整和准确。另外部分用户需求是没有体现在开发需求中的，但却可能提取出来作为原始需求。

关于测试需求来源若测试需求来源是继承性需求，可以使用继承性分析工程方法，对系统继承特性（包括从其他系统继承的特性），根据历史测试情况、用户使用情况反馈、用户应用环境变化、与新增特性的交互关系等方面进行继承性分析，得出对这些继承需求需要继承哪些测试项和测试用例、需要和哪些新增需求进行交互测试、需要对哪些变化进行测试，并根据分析的结果提取出原始测试需求。

关于测试需求来源测试经验库中保存了通过测试执行、缺陷分析、用户应用反馈、相关系统同步等途径提取出来的原始测试需求。这些原始测试需求可以作为测试分析设计的直接输入。从同行竞争分析报告之类的原始测试需求来源中可以直接提取一些功能规格、性能指标、操作规范等作为所测试系统的原始测试需求。通过上述环节获取的原始测试需求可记录在RTM（需求跟踪矩阵）或其他需求管理工具中，便于后期的维护及管理。

测试需求分析测试项分析获取原始测试需求后，测试工程师即可分析及确定测试项。测试项分析可以参考的工程方法有：质量模型分析、功能交互分析、用户场景分析等，每个工程方法都需独立的输出初始测试项，也就是说初始测试项是从不同测试角度分析输出的结果。软件质量从功能性、可靠性、效率、易用性、可维护性、可移植性等6个特性角度来衡量，其中每个质量特性又可分为若干子特性角度，质量模型分析是从软件质量因子角度来分析的。从不同的测试目的出发、以不同的角度来分析和测试产品，不同类型的测试会发现不同类型的缺陷。在测试分析设计活动中考虑质量模型分析，能够使测试分析设计人员尽可能从多个方面和角度进行测试分析，能非常有效地提升测试完备性。测试需求分析软件功能不是独立的，功能之间存在交互、顺序执行等影响因素，这就是功能交互分析的角度。将被测功能和软件其他相关功能进行交互分析，根据影响点可以得出初始测试项。被测功能代指原始测试项或一组有逻辑关系的原始测试项集合，软件其他相关功能包括所有需要进行交互分析的新增和继承功能特性。通过分析功能间的相互影响，能非常有效地提升测试完备性。从用户角度出发（注意这里的用户是泛指，而不仅仅指人）关注每个用户如何使用和影响被测功能特性，更能关注用户的真实需求意愿。确定后的测试项与原始测试需求一样，需利用需求管理工具进行管理。测试需求分析测试子项分析测试子项分析活动是针对测试项的进一步分析、细化，形成测试子项的活动过程，主要是对测试项进行细化处理。对测试项的处理存在以下几种原则：对粒度小的测试项不处理，直接进行特性测试设计。