测试工件只是软件测试的组成部分。这些通常是文档集，软件项目测试人员会在STLC(软件测试生命周期)中获得这些文档。测试工件是在执行软件测试时生成或创建的副产品。然后，将这些生成的测试工件与客户，测试团队或团队经理，团队负责人，与项目关联的利益相关者以及其他团队的成员共享。
只需从客户那里签收，这样就不需要沟通上的空白。这些工件在与成型产品相同的工件集中进行通信，工程设计，构造或开发。这些工件还以可编程和可重复的格式(例如软件程序)实现。建立团队成员之间的透明度是测试工件的主要目标和目的。因此，它们以正确的方式记录了准确，准确的数据或信息以及详细信息。
因此，由于一切都被正确记录，因此识别和跟踪更改非常容易和简单，并且可以从需求中了解测试活动的最新进展。这些工件的开发人员所使用的工具，技术和培训与软件工程师在开发或创建最终产品时所使用的工具，技术和培训相同。
测试工件的类型：
1.测试策略：
测试策略通常由测试或项目经理在管理级别上制定。是文档的概要，描述了软件开发周期的测试方法，其中列举了如何使用可用资源来达到预期的结果。
它只是提供了对目标，工具，技术，基础结构以及将要执行的测试活动的时间的轻松理解。它还可用于识别测试期间可能出现的所有风险因素，以及用于降低或减轻风险的适当解决方案。它还阐明了完成项目所有测试过程的主要重要挑战和方法。测试策略通常源自业务需求规范格式。要制定此策略，需要牢记几点。其中一些如下：
- 测试的主要目标是什么，为什么要执行此测试?
- 执行测试需要遵循哪些准则?
- 测试所需的所有需求是什么，例如功能需求，测试方案，资源等?
- 完成测试的每个职能和项目经理的角色和职责是什么?
- 有哪些不同级别的测试?
- 该测试的主要交付内容是什么?
- 关于测试以及项目风险有哪些风险?
- 有什么方法可以解决可能出现的问题?
2.测试计划：
测试计划是详细的文档，描述了软件测试范围，测试策略，测试可交付成果，风险，目标和活动。它是系统方法，通常用于软件应用程序测试。简单地确保基线计划中最初有任务和里程碑清单以跟踪或识别项目进度是最重要和必要的活动。
它是动态文档，通常充当参考点，并且仅基于QA(质量保证)团队中进行的测试。只是蓝图说明了测试活动将如何在项目中进行。制定测试策略时，需要牢记几点。其中一些如下：
- 测试活动的主要目的是什么?
- 未来的测试范围是什么，即执行测试时需要遵循或涵盖的确切路径?
- 什么是测试方法，即如何进行测试?
- 测试所需的全部资源是什么?
- 完成测试后退出标准是什么，即完成测试需要满足的一组条件和活动?
- 您将如何管理可能出现的风险?
3.测试场景：
测试方案是用于描述可以测试的应用程序功能的语句。它仅用于确保功能或软件的端到端测试是否正常进行。它来自用例。
它包含应用程序形式的情况或条件，可以开发许多测试用例。测试方案也称为测试条件或测试可能性。一个测试场景可以容纳一个或多个测试用例。因此，测试方案与测试用例具有一对多关系。这意味着要详细讨论和思考需求。
4.测试用例：
测试用例是详细的文档，描述了在测试时将有助于执行的用例。它是由测试用例名称，前提条件，步骤/输入条件和预期结果组成的文档。测试用例的开发还有助于识别或跟踪软件应用程序的需求或设计中的问题。
它只是一组条件或变量，在这些条件或变量下，软件测试人员将识别被测系统是否满足要求或以正确正确的方式工作。要编写好的测试用例，需要在测试用例中包括一些要点：
- 编写测试用例ID，即测试用例的唯一标识号。
- 写下测试用例名称，即测试用例的强标题。
- 编写有关测试用例的完整详细信息和描述。
- 分步骤编写，使其清晰明了，即简单。
- 写下预期或实际结果或测试结果。
5.追溯矩阵：
可追溯性矩阵是包含表的矩阵，该表显示并解释了需求与测试用例之间的多对多关系。实际上，该文档与需要多对多关系才能检查，跟踪和映射关系的两个基线文档中的任何一个相互关联。通常，它有助于确保软件测试产品的透明度和完整性。
它是通过测试用例跟踪客户的所有需求并识别缺陷的方法。可追溯性矩阵有两种类型：前向可追溯性矩阵和后向可追溯性矩阵。可追溯性矩阵中包含的一些参数如下：
- 需求ID。
- 需求类型以及描述。
- 测试设计的状态以及测试状态的执行。
- 系统和单元测试用例。
6.软件测试报告：
软件测试报告是描述所有测试活动的文档。它提供有关给定范围的测试用例，测试套件或测试脚本的状态的详细信息。非常需要一份测试报告来以正式的方式表示测试结果，以便有机会快速找出测试结果。测试报告可以有多种类型：个人测试报告，团队报告。测试报告可以每天生成，也可以在测试完成后或测试周期结束时生成。