在“测试用例设计需要参考哪些输入?”文章中，作者提出了测试用例设计需要参考的几个主要来源：开发文档、用户需求、标准与规范、类似产品需求、测试经验知识库和其他隐性需求等。针对测试对象的测试条件的识别，将以这些参考文档作为输入。 

　　在测试实践过程中，不同测试人员会负责测试对象的不同功能和特性。因此，将某个功能或者特性相关的参考输入文档分配给同一个测试人员，有助于提高测试条件识别的效率和有效性的。下面针对不同的参考输入来源，在识别测试条件上面有哪些特点或者原则?

　　1)开发文档

　　这里的开发文档是一个统称，包含了开发过程中的各种软件工作产品，例如：系统需求规格说明、概要设计规格说明等。对于系统测试而言，系统需求规格说明是其主要的参考输入之一;对于其他测试级别，其主要参考输入来源是相对应的开发文档。

　　假如系统需求规格说明比较完善正规，那么从该文档中提取测试条件相对比较容易，其基本原则是每条需求条目至少有一个测试用例覆盖。根据需求条目的颗粒度不同，多个需求条目可以在一个测试用例中进行验证;而有的需求条目可以合并成一个，并在同一个测试用例中验证。在测试条件提取过程中，测试人员需要注意的是：需求更多的是从软件开发角度出发的，测试人员需要将这样的需求转换为测试的角度进行考虑。


　　假如系统需求规格说明不全，甚至没有的情况下，如何识别其中的测试条件是一个挑战。下面是识别测试条件的几个建议：

 

　　(1)首先，与软件产品的系统人员和开发人员进行讨论，从测试的角度，将存在于他们脑子里的未文档化的需求明确;

 

　　(2)其次，假如测试人员具备代码方面的能力，可以通过实现的代码倒推出软件系统是如何实现的，它们也可以作为识别测试条件的参考。当然，这里面临的一个问题是，代码实现是否是正确的、全面的，这是测试人员需要考虑的一个问题。

 

　　(3)第三，从测试的角度推动开发团队提高开发文档的质量，从规范软件开发过程(流程)的层面逐步改进系统需求的质量，例如：通过输出测试文档或者测试中的检查表，推动改进开发文档质量。

　　2)用户需求


　　测试过程中我们经常会听到测试人员不仅需要验证开发是否正确实现了功能，同时也需要从用户的角度考虑软件产品是否真的满足了用户的需求，这是测试中的确认(Validation)关注点。而用户需求在其中充当了很重要的角色，用户需求通常是从用户实际使用的角度进行描述和划分的，类似于用例场景。


　　由于用户不一定了解和熟悉软件产品相关的知识和技能，因此用户需求很难是完整的。测试人员在分析用户需求的时候，需要结合软件产品的相关开发文档具体内容。同时，需要测试人员积极与客户、产品的技术支持人员、销售人员进行沟通，从他们角度获取可能的测试条件。例如：客户现场实际的网络拓扑结构、用户实际使用的功能配置等。

 

　　3)标准与规范


　　标准与规范中定义的内容会比开发文档中可能详细的多，因此它们是测试人员进行深入和细致学习的重要对象。例如：数据通信产品中的很多功能开发都是基于某些国际、和行业的标准与规范而开展的，基于它们获取测试条件取，对于提高测试的覆盖率和有效性是非常有必要的。下面是基于标准与规范识别测试条件的一些原则和建议：

　　(1)开发文档没有详细描述软件产品的某个功能或者特性，而是直接参考某某协议标准，例如：OAM PDU的格式与Y.1731/802.1ag/D80相兼容。

　　(2)协议一致性测试、标准与规范一致性测试等，这个时候，标准与规范可能是识别测试条件的主要参考输入。测试人员可以基于标准与规范来检查软件产品的实现是否存在偏差，这主要是测试中的验证(Verification)关注点;

 

　　(3)除了通过标准与规范获取测试条件之外，测试人员也可以通过它们检查开发文档是否存在遗漏和错误，这是前期评审工作的主要目的之一。

　　4)类似产品需求


　　随着软件产品越来越复杂，行业内采用增量-迭代开发模型的场合越来越多，例如敏捷开发。测试人员经常面临的软件产品是基于已有的系统之上，即测试对象是基于以前版本的功能增加、缺陷修复、平台移植等变更基础之上。因此测试人员需要分析历史测试是否全面，测试对象变更是否影响以前运行的软件版本等。基于这些信息，测试人员可以获取新的测试需求。


　　5)测试经验知识库


　　测试并不是存在编码之后的一个阶段，测试应该贯穿于整个软件开发生命周期。类似于开发过程改进一样，测试也应该是PDCA(戴明质量环)的过程。因此，不同项目中的测试经验是每次测试用例设计的重要输入。通过测试经验知识库，测试团队的测试经验和技能才能在整个组织中共享。


　　测试经验知识库可以来自测试执行的经验、测试过程中发现的缺陷分类和分析、用户反馈的缺陷分类和分析等。

　　6)其他隐性的需求

　　除了从前面提到的输入文档中识别测试条件之外，其他的一些隐性输出也可以作为识别测试条件的基础，例如不同产品利益相关者针对测试对象中间版本的变更而达成的备忘录;通过杂志、网络等查找类似测试对象产品的一些常见缺陷和失效，以及软件产品在用户现场使用的讨论等。

 

　　通过测试用例设计的参考输入：系统需求、用户需求、标准与规范、类似产品需求、测试经验知识库，以及其他隐性的需求，测试人员可以获取一系列的初始测试条件，即测试条件列表。为了提升测试效率和有效性，需要为每个测试用例需要设定一个测试优先级。 

　　初始的测试条件列表，还需要更进一步的测试类型分析和功能交互分析，才能得到相对完善的测试条件列表。接下来，测试人员可以采用一系列测试技术与方法，进行详细测试用例的设计。