在IT行业工作时，我们总要面对过多的专业术语。有程序，文档，任务和其他所有相应专有名称的事物。那我们该怎么记住，理解并每次正确的在上下文中使用它们呢？
这是在软件测试课中经常被问到的问题，我总是根据经验告诉我们的学员，我们很少注意到这些术语，它们已经成为我们词汇量中的一部分了。
但往往会有很多关于这个问题的困惑，今天这篇文章中，我就将试图定义一些常用的术语。
测试计划和测试策略之间有什么区别？
测试计划是一个术语和可交付成果。测试计划是一个列出了QA项目中所有的活动的文档，制定时间表，定义项目的范围,角色和责任,风险,进入和退出标准、测试目标和其他任何你能想到的。我喜欢称测试计划为“超级文件”，因为其中列出了你需要了解和可能要用到的一切。通过此链接可以获取更多信息和范例。
测试策略也是一个可交付成果和文档。它描述了测试方以及关于这个的一切。它不同于测试计划,就意义而言测试策略只是测试计划的一个子集。这是一个核心测试文档,在某种程度上是通用的,静态的。还有一些争论关于在应该在什么水平使用测试策略或测试计划——但我真的没觉得有任何的差异。
例如：测试计划给出了测试由谁何时进行的信息。例如:模块1将是由“X测试人员”进行测试。如果出于某种原因测试人员Y取代了X,测试计划已经更新
相反,测试策略将有类似“各个模块将由测试团队成员测试”的细节。在这种情况下,不用管是谁测试它,所以它是通用的,团队成员的变化不需要更新,保持了静态。
测试用例和测试脚本之间的区别是什么？
在我看来，这两个术语可以互换使用。是的，我的意思是没有区别的。测试用例是一系列帮助我们在对应用程序执行测试的步骤。测试脚本也是一样的东西。
现在，有一个派别认为测试用例是用于手工测试环境中的术语，测试脚本是使用于自动化环境的。这在一定程度上是对的，还是根据不同领域测试人员的习惯程度以及工具对于测试的适用度决定（有些称之为测试脚本另一些称之为测试用例）。所以实际上，测试脚本和测试用例都是对一个应用程序，为验证其功能而进行的手动或自动测试的步骤。
测试场景和测试条件之间的区别是什么？
测试场景是测试人员创建的作为起始点的单行指示性内容,是作为进入测试设计的过渡阶段。这主要是一个简短的定义“什么”功能是我们要进行测试的。通常,测试场景是创建测试用例的输入。在敏捷项目中,测试设计的输出只有测试场景,无需据此编写测试用例。一个测试场景可能导致多个测试。
------------
测试场景实例：
1.验证管理员是否可以添加新的国家
2.验证管理员是否可以删除现有国家
3.验证现有国家是否可被更新
另一方面测试条件则更为具体。它可大致定义为某一测试的目的。
测试条件实例：
在上面的例子中，如果要测试场景1，我们可以有如下的测试条件：
1.输入国家名称为“印度”（有效），并检查是否成功添加
2.输入空白，并检查该国能否被添加
在各个情况下，描述特定的数据使得试验的目的更明确。
测试程序和测试套件之间的区别是什么？
测试过程是基于特定逻辑原的测试用例的组合，如执行例如一个端对端或类似情况。其中测试用例的执行顺序是固定的。
例如，如果我的目的是测试从Gmail.com发送电子邮件，我可以按顺序结合测试用例，形成一个测试程序，也就是：
1.测试，以检查登录
2.测试撰写电子邮件
3.测试添加一个/多个附件
4.通过使用各种选项使电子邮件满足要求的格式
5.添加联系人或电子邮件地址到收件人，密件抄送，抄送栏
6.发送电子邮件，并确保它显示在“已发送邮件”中
以上所有的测试用例的都是基于实现某一目标而被分为一组。并且，测试程序有几个测试用例组合而成。
测试套件，在另一方面，是所有需要作为测试周期或一个回归阶段的一部分执行的测试用例的列表。没有基于功能的逻辑分组。构成测试用例的执行顺序可能重要也可能不重要。
测试套件实例：如果一个应用程序的当前版本是2.0。以前的1.0版本可能有1000个测试用例来完全测试。对于版本2新版本中增加的新功能有500个测试案例。所以，目前的测试套件。将有1000+500个测试用例，包括回归测试和新的功能的测试。套件是一个组合，但我们并不是要达到一个目标函数。
测试套件可以包含数百个或数千个测试用例。
结论
现在到了这个定义文章的末尾。
通常像这样的文章是更深入讨论的极好的出发点。所以，请贡献您的想法，相同意见，或不同意见。我们期待您的反馈。
{测试窝原创译文，译者：大头}
译者简介：大头，在读日本九州大学修士，计算机专业，主研究方向为文本挖掘，及自然语言处理。
