上下文驱动测试

原则

语境驱动的学校的七个基本原则

1. 任何实践的价值取决于其背景。

2. 在上下文中有良好实践，但没有最佳实践。

3. 人们一起工作是任何项目背景中最重要的部分。

4. 随着时间的推移项目以往往无法预测的方式展开。

5. 该产品是一种解决方案。如果问题仍未解决，则产品不起作用。

6. 良好的软件测试是具有挑战性的智能过程

7. 只有通过在整个项目中协同行使的判断和技巧，我们才能在合适的时间做正确的事情来有效地测试我们的产品。

行动原则的插图

• 存在测试组以提供与测试相关的服务。他们没有经营开发项目; 他们为项目服务。

• 代表利益相关者进行测试，以开发，验证，调试，调查或销售产品。完全不同的测试策略可能适合这些不同的目标。

• 对于不同的测试组来说，完成不同的任务是完全正确的。为一项任务服务的核心做法可能与另一项任务的服务无关或适得其反。

• 无效的度量标准是危险的。

• 任何测试案例的基本价值在于其提供信息的能力（即减少不确定性）。

• 所有的神谕都是错误的。即使产品似乎通过了您的测试，也可能以您（或自动测试程序）未监控的方式使其失败。

• 自动化测试不是自动手动测试：谈论自动化测试就好像是自动人体测试一样毫无意义。

• 不同类型的测试将揭示不同类型的缺陷 - 随着程序变得更加稳定，测试应该变得更具挑战性或应该关注不同的风险。

• 测试工件在满足其利益相关者的相关要求的程度上是值得的。

一个例子：

考虑两个项目：

1. 一个是开发飞机的控制软件。“正确行为”意味着什么是高度技术性和数学性的主题。必须遵守FAA规定。你做或不做的任何事情都将成为20年后诉讼中的证据。开发人员共享工程文化，重视谨慎，精确，可重复性，并仔细检查每个人的工作。

2. 另一个项目是开发一个将在网络上使用的文字处理器。“正确的行为”是微软Word用户对您的软件的巨大和不明智的观众。没有重要的监管要求（管理公开发行股票的除外）。上市时间问题 - 从现在起20个月，无论好坏，都将结束。开发人员显然不是来自工程文化，并试图以正常的方式谈论第一种文化，这会使他们称之为“伤害被绕过”。

• 适合第一个项目的测试实践将在第二个项目中失败。

• 适用于第二个项目的做法在第一个项目中将是犯罪疏忽。

来自Cem Kaner，James Bach和Bret Pettichord，软件测试方面的经验教训。

评论

自从我们首次发布上述描述以来，有些人发现我们的定义过于复杂，并试图将其简化，试图将方法与敏捷开发或敏捷测试等同，或者与软件测试的探索风格等同。这是定义中的另一个裂缝：

上下文驱动的测试人员首先查看具体情况的详细信息，包括委托测试的利益相关者的愿望，选择他们的测试目标，技术和可交付成果（包括测试文档）。上下文驱动测试的本质是项目适当的技能和判断应用。上下文驱动的测试学院将这种方法置于人文社会和道德框架内进行测试。

最终，上下文驱动的测试就是尽我们所能，尽我们所能。我们不是试图应用“ 最佳实践”，而是接受非常不同的实践（甚至****是常见测试术语的****不同定义）在不同情况下最有效。

对比上下文驱动与上下文感知测试。

许多测试人员认为他们的方法是上下文驱动的，因为他们在工作时会考虑上下文因素。以下是一些可能说明上下文驱动和上下文感知之间差异的示例：

• 上下文驱动的测试人员拒绝最佳实践的概念，因为他们提供了适当的独立于上下文的某些实践。当然，人们普遍认为，在某些情况下，任何“最佳做法”都可能不适用。然而，当有人首先考虑最佳实践并且首先考虑项目特定因素时，这可能是上下文感知的，但不是上下文驱动的。

• 类似地，有些人创建标准，例如用于测试文档的IEEE标准829，因为他们认为有一个标准来规定通常正确的事情是有用的。这不是不寻常的，也不是声名狼借的，但它不是由上下文驱动的。标准829 始于良好文档的愿景，并鼓励测试人员根据利益相关者的需求修改创建的内容。上下文驱动的测试始于利益相关者的要求以及项目的实际约束和机会。对于上下文驱动的测试人员，该标准提供了实现级别的建议而不是处方。

对比上下文驱动与上下文不注意，特定于上下文和上下文帝国测试。

说“上下文驱动”是为了区分我们的测试方法与上下文不注意，特定于上下文或上下文帝国的方法：

• 在不考虑测试实践和测试问题之间的匹配的情况下完成上下文不经意的测试。这在刚刚学习手艺的测试人员中很常见，或者只是复制他们看到其他测试人员所做的事情。

• 特定于上下文的测试应用针对特定设置或问题进行优化的方法，在上下文发生更改时无需进行调整。这在具有长期项目和团队的组织中很常见，其中测试人员可能没有在多个组织中工作。例如，一个测试组可能会开发军事软件的专业知识，另一个团队开发游戏。在特定情况下，特定于上下文的测试人员和上下文驱动的测试人员可能以完全相同的方式测试他们的软件。但是，特定于上下文的测试人员只知道如何在她或他的一个开发环境（MilSpec）（或游戏）中工作，并且他/她不知道在各种情况下熟练测试的程度会有所不同。

• Context-imperial测试坚持改变项目或业务，以适应测试人员自己的“最佳”或“专业”实践的标准化概念，而不是设计或调整实践以适应项目。上下文帝国方法在知识主要来自阅读书籍，或者其实践经验是针对具体情况的，或者试图吸引市场的顾问中很常见，这些市场认为其发展方法是一种真正的方式。

对比上下文驱动的敏捷测试。

敏捷开发模型倡导客户响应，浪费最小化，人性化的软件开发方法，以及上下文驱动的测试。但是，上下文驱动的测试本身并不是敏捷开发运动的一部分。

• 例如，敏捷开发通常主张广泛使用单元测试。上下文驱动的测试人员将修改他们测试的方式，如果他们知道单元测试已经完成。许多（可能是大多数）上下文驱动的测试人员会建议将单元测试作为一种方法，使以后的系统测试更加高效。但是，如果开发团队没有创建可重用的测试套件，那么上下文驱动的测试人员将建议不期望或依赖于成功的单元测试的测试方法。

• 同样，敏捷开发人员通常会建议使用渐进式或螺旋式生命周期模型，并根据需要开发最少的文档。许多（也许是大多数）上下文驱动的测试人员在这个生命周期中工作会特别舒适，但是在瀑布项目中创建广泛记录的测试并且预先创建大量文档也同样受上下文驱动。

最终，上下文驱动的测试就是尽我们所能，尽我们所能。在没有有效的单元测试的情况下，可能没有敏捷测试（在敏捷开发社区使用的意义上）这样的东西，但肯定会有上下文驱动的测试。

对比环境驱动与标准驱动的测试。

一些测试人员提倡偏好生命周期模型，青睐组织模型或偏爱文物。例如，考虑V模型，编程和测试组之间相互可疑的分离，以及向测试人员提供的所有代码都带有详细规范的要求。

上下文驱动的测试没有空间进行这种宣传。测试人员得到他们得到的东西，熟练的上下文驱动的测试人员必须知道如何应对他们的方式。当然，我们可以而且应该向人们解释权衡，明确是什么使我们更有效率和更有效，但最终，我们将测试视为服务于做出更广泛的项目管理决策的利益相关者。

• 是的，当然，有些要求是不合理的，我们应该拒绝它们，例如要求测试人员伪造记录，对产品或测试做出虚假声明，或者工作不合理的时间。但这并不意味着每个利益相关者的要求都是不合理的，甚至是一些我们不喜欢的。

• 是的，当然，有些要求是荒谬的，因为它们要求不可能，例如评估产品与合同规定的特性的一致性，而无需访问合同或其规范。但这并不意味着我们不喜欢的每个利益相关者的要求都是荒谬的，或者是不可能的。

• 是的，当然，如果我们的任务是评估产品与其规格的一致性，我们需要一个规范。但这并不意味着我们总是需要规格，或者我们坚持接受它们总是合适的（甚至通常是合适的）。

总有约束。其中一些是实用的，另一些是道德的。但在这些限制条件下，我们从项目的需求开始，而不是从我们的流程偏好开始。

上下文驱动的技术？

上下文驱动的测试是一种方法，而不是一种技术。我们的任务是在这种情况下做最好的测试 - 我们知道的技术越多，在考虑如何应对新情况时我们可以获得的选择就越多。

我们需要的一套技术 - 或更好的知识体系 - 不仅仅是一套测试集。在此，我们遵循[Jerry Weinberg的脚步]从头到尾，我们将软件开发项目视为一项富有创意的复杂人类活动。要了解如何很好地为项目服务，我们必须了解项目，利益相关者和他们的兴趣。][我们的许多核心技能来自心理学，经济学，人种学和其他社会科学。

作者：TeacherAilie
链接：https://www.jianshu.com/p/098e46b1f562