使用测试设计规范，可以简化对当前测试周期的理解。这个文档回答了像“我们在做什么?”，“我们怎么做?”和“为什么要这样做?”这样的简单问题。然而，要达到这个结果，必须正确地将许多事物融入到创建规范中，使其变得完美合理。
在软件行业中，"规范"这个词对任何人来说可能并不陌生。根据理论定义，规范是关于设计和制造某物所涉及的详细描述和材料。规范已经采取了多种形式，并为不同部门提供了多种不同的服务。对于开发者来说，软件需求规范(SRS)可能是首先记录他的理解并传达给客户或其他团队成员的文档。对于测试人员来说，SRS文档变成了测试设计规范(TDS)，它具有相同的目的，但专注于测试并且仅供测试人员使用。
什么是测试设计?规范的清晰度在很大程度上取决于我们对测试设计及其在测试领域中的作用的理解。
测试设计提供了关于在软件应用程序上执行的测试的想法。重要的是要注意，测试设计预期在测试之前构建，而不是在测试过程中或之后。这样，我们就知道应该采取哪些路径并避免哪些路径。
构建测试设计包括三个阶段：
分析我们经历的第一个阶段是测试分析。在这个阶段，我们分析应用程序和我们所拥有的其他所有东西。测试人员在分析阶段收集的所有数据将成为以后测试用例的基础。
计划一旦我们分析了应用程序并收集了非结构化的原始数据，我们会计划使用所有资源进行高效的测试。这在很大程度上取决于我们向用户发布的软件类型。游戏应用程序可能需要大量的UI、UX和硬件响应测试。在银行应用程序中，担心这些问题可能不那么重要。
创建测试用例我们有资源和结构可以在测试阶段对软件进行测试。因此，我们开始创建测试套件，记住我们是根据前一阶段创建的计划来工作的。测试套件的创建可能指示编程脚本或基于英语的定义。
在一些组织中，开发者可以通过测试套件来清楚地定义应用程序目标，从而确定系统的功能。例如，“检查文件上传”可以是一个包含与上传框相关的测试用例的测试套件。之后，测试人员可能会在文件上传中探索各个领域，如上传具有允许扩展名的文件、上传具有不正确扩展名的文件、在上传过程中断开网络连接等。
另一方面，如果质量保证直接参与其中，他们甚至可以直接在此处以脚本形式设计测试套件。
完成了所有这些三个步骤后，我们的测试设计就完成了。但这主要侧重于应用程序的测试部分。这将是我们需要创建的测试设计文档的核心。将测试设计与完成文档所需的其他元素相结合，形成了测试设计规范。
在进行测试时，重要的是考虑真实的用户场景。为了使测试环境更加真实，应该在真实设备云上运行测试。
您可以使用LambdaTest——一个测试编排和执行平台，提供跨3000多种真实浏览器、设备和操作系统对网站和应用程序进行手动和自动化测试。根据您的项目需求，您甚至可以在真实设备云和基于Android模拟器和iOS模拟器的移动应用程序上进行测试。
什么是测试设计规范?测试设计规范定义了我们的测试将如何构建。当我们深入研究这个概念时，我们就到达了测试设计规范或者说是一份比测试设计更丰富、更深入的文档，供测试人员(有时也供开发人员)使用。
它不仅讨论测试和场景，还回答了与测试相关的更深层次的问题。例如：
如何执行测试?我们需要多久执行一次测试?我们正在使用的方法是什么?为什么要使用这些方法?我们正在选择哪些测试工具?为什么要选择这些工具?具体解释的测试场景是什么?根据测试人员或项目/组织的需求，还可以添加更多内容。
测试设计规范围围绕特征而不是测试用例展开，与测试设计相比。在讨论时，我们考虑单个特征，并记录在测试中将使用哪些测试用例或场景(从测试设计池中选取)。因此，我们为一个软件创建多个测试设计规范。
测试设计规范的格式在测试设计规范中，我们可能会遇到来自不同人的不同观点。即使消除了地理差异，你和我可能会产生完全不同的规范(或任何文档)。这是因为我认为必要的东西对你来说可能并不重要，反之亦然。
为了解决这种情况，IEEE组织在软件行业中处理、管理和规范每种类型的规范。IEEE包含一个庞大的数据库，定义了软件开发的每个阶段的标准，甚至在编写一行代码之前就开始了。
对于那些针对SDLC中的特定领域的人来说，搜索特定规范可能变得耗时。为了处理这种情况，IEEE描述了一个数字，它指代一个区域内的标准文档。对于我们的测试计划、测试设计和测试用例规范，我们使用IEEE 829文档。
IEEE 829描述了在文档中需要描述的以下基本要素：
测试设计规范标识符。需进行测试的功能。方法细化。测试用例标识。功能通过/失败的标准。让我们逐个分析它们。
标识符在创建设计规范时的第一个基本要素是标识符。它记录在文档的顶部，并且每个测试设计规范都有一个唯一的标识符。在文档中需要这个要素的原因是，一个软件可能包含与单个功能或一组功能相关的多个规范。
为了对这些文档描述一个独特的标识符，我们可以在不打开它们的情况下识别每个文档的摘要。这种安排有助于更快地找到所需的信息，最终有助于快速完成测试阶段。
在创建测试设计规范标识符时，请记住以下几点：
名称应该简短且唯一。指定版本日期号。规范的作者及其联系方式，例如电子邮件地址。明确定义修订历史(如果有)。
需进行测试的功能根据IEEE 829，测试设计规范的第二要素定义了需要测试的功能列表。通常，这对应于由高级管理层或客户确定的从需求池(包含所有需求)中提取的需求。这些需求满足应用程序的功能，因此将其称为“需进行测试的功能”。
测试人员应仔细组合所有的测试用例规范，以满足所有需求。没有这些规范，我们的应用程序有可能存在错误和漏洞。
根据IEEE的规定，设计规范需要涵盖以下内容：
功能：属性和特征。功能：如果存在分组。如果测试计划涉及多个层次的测试，请确定特定功能涵盖的层次。与包含需求池的文档的关联。方法细化测试设计规范的第三部分涉及特征细化和我们的方法。 "细化" 部分有一些指定的部分必须包含，但测试人员可以在其上添加一些自己的内容。
作为一个测试人员，您可以考虑这一段是一个测试人员为其他测试人员记录的最深层次的知识。对于那些不参与项目的测试人员来说，他们尤其需要用文档回答有关测试技术的每个问题。
根据IEEE的规定，这种技术水平被分为以下几个部分：
测试技术的具体细节：这部分将包括有关每个功能中使用的测试技术的较少细节。为什么使用某种测试技术：详细说明为什么使用特定的测试技术以及它带来的优势。结果分析方法：突出显示如何分析测试阶段的结果。这一部分的主要目的是定义结果分析中使用的方法和所提到的工具。测试人员还可以说明为什么使用某个工具以及其目的。例如，JMeter 被用于分析负载测试结果。特征级别关系：此部分定义了特征或测试项与测试级别之间的关系。标准信息：测试人员认为对多个功能/测试用例有共同意义的任何信息应在此部分共享。这可能包括测试环境信息、设置信息、恢复信息和依赖项。
IEEE按照上述顺序描述了这些部分。并不一定要遵循如此严格的步骤，只需要确保测试设计规范中的信息是完整的。
测试标识设计规范的这一部分用英文描述测试用例，以便读者在深入了解具体细节之前能对测试用例有一个大致的了解。
此部分分为两个部分：
测试用例标识介绍每个测试用例的简要知识。测试过程标识介绍每个测试过程的简要知识。
功能通过/失败的标准最后但同样重要的是，在测试设计规范中必须包含功能通过/失败的标准。我们的目标是为每个测试确定通过或失败的标准，并分析结果。
例如，如果一个测试用例涉及 "在网站上注册"，通过的标准可能是 "用户在数据库中被创建"。如果使用失败的标准，那么 "用户没有在数据库中创建" 就意味着测试未通过。
这些标准帮助我们评估所有测试用例的最终结果，并阐明当我们说测试通过或失败时的含义。
结论当一个测试人员加入团队时，自然而然地，团队将面临各种不同类型的问题。除了定义方法和标准程序外，项目相关的问题可能会占用您大部分时间。
通过电话澄清所有疑问，并为每个测试用例提供解释，包括 "我们为什么这样做"，这是不可行的，而且老实说，新成员不太可能很快记住这些内容。因此，我们采用文档的方式来解决这个问题。
在每个领域中，文档提供了团队成员和参与项目的人(无论是技术人员还是非技术人员)的参考材料。由于这些时候人们从世界各地聚集在一起共同开发一款优秀的软件，因此需要一种标准的文档来确保每个人在参考测试设计相关内容时都处于相同的页面。
IEEE是负责此类事务的组织，他们提供了一个标准的分段文档，称为测试设计规范，用于测试设计领域，并记录团队所做的选择以及与测试流程有关的一切。
本文介绍了这个文档，并将复杂的部分分解为简单易懂的概念。希望这个指南能为您在下一个项目中建立一个强大的测试设计规范提供快速参考。
