测试技术：关于上下文驱动测试的总结

语境驱动的七个基本原则：

• 　　1、任何实践的价值取决于其背景。2、在上下文中有良好实践，但没有最佳实践。3、人们一起工作是任何项目背景中最重要的部分。4、随着时间的推移项目以往往无法预测的方式展开。5、该产品是一种解决方案。如果问题仍未解决，则产品不起作用。
• 　　6、良好的[url=]软件测试[/url]是具有挑战性的智能过程
• 　　7、只有通过在整个项目中协同行使的判断和技巧，我们才能在合适的时间做正确的事情来有效地测试我们的产品。

行动原则：

• 　　1、存在测试组以提供与测试相关的服务。他们没有经营开发项目; 他们为项目服务。
• 　　2、代表利益相关者进行测试，以开发，验证，调试，调查或销售产品。完全不同的测试策略可能适合这些不同的目标。
• 　　3、对于不同的测试组来说，完成不同的任务是完全正确的。为一项任务服务的核心做法可能与另一项任务的服务无关或适得其反。
• 　　4、无效的度量标准是危险的。
• 　　5、任何测试案例的基本价值在于其提供信息的能力（即减少不确定性）。
• 　　6、所有的神谕都是错误的。即使产品似乎通过了您的测试，也可能以您（或自动测试程序）未监控的方式使其失败。
• 　　7、[url=]自动化测试[/url]不是自动手动测试：谈论自动化测试就好像是自动人体测试一样毫无意义。
• 　　8、不同类型的测试将揭示不同类型的缺陷 - 随着程序变得更加稳定，测试应该变得更具挑战性或应该关注不同的风险。
• 　　9、测试工件在满足其利益相关者的相关要求的程度上是值得的。

一个例子

考虑两个项目：

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

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

• 　　· 适合第一个项目的测试实践将在第二个项目中失败。
• 　　· 适用于第二个项目的做法在第一个项目中将是犯罪疏忽。

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

评论

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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