什么是基于上下文驱动的测试（context-driven-testing）？它不是一种具体的测试方法，而是一类测试思维的体现，通常是指测试人员首先查看特定迭代的细节（产品特性、业务需求、相关干系人等）来选择他们的测试目标、技术和可交付成果（包括测试文档）。归根结底，上下文驱动的测试是要尽我们所能做到最好。我们不尝试应用“最佳实践”，而是接受非常不同的实践（甚至常见测试术语的不同定义）将在不同情况下发挥最佳效果。

七个基本原则

任何实践的价值都取决于它的背景。

在上下文中有好的实践，但没有最佳实践。

一起工作的人是任何项目环境中最重要的部分。

项目随着时间的推移以通常无法预测的方式展开。

产品是一种解决方案。如果问题没有解决，产品就无法工作。

好的软件测试是一个具有挑战性的智力过程。

只有通过判断力和技巧，在整个项目中协同运用，我们才能在正确的时间做正确的事情，以有效地测试我们的产品。

上下文驱动测试的示例

假设有一个基于Web应用程序的端到端测试。

一般策略顺序是什么？

收集需求并了解应用程序

创建测试计划

创建测试文档——测试场景、测试用例、可追溯性矩阵等。

审查并批准所有文件

搭建QA环境和测试数据

执行测试执行

创建错误报告

生成和共享测试执行状态报告等。

这个一般策略来源于最佳实践、QA 标准、行业指南、过去的经验等，但这一定是最佳的吗？

上下文驱动测试是指让不同的环境决定团队的测试实践、技术甚至定义，而不是标准的、行业认可的“最佳实践”。

假设这些是项目A处理的细节：

一个由4-5名新人和 1 名经验丰富的测试人员组成的团队；

客户想要每日详细的状态报告；

使用基于网络的错误跟踪工具，例如 Mantis 或 Bugzilla；

必须在10天内进行 2 轮测试，其中3天用于测试文档；

该怎么做？

1.由于团队中有很多新人，我们需要大量的同行评审。

2.文档写的越多，审查就越多，这就相当于需要更多的时间。因此，必须保留最少的文档。只记录主要的端到端，其余的将进行探索性测试。

3.测试执行期间的每日状态报告将被创建。

4.大多数测试都是探索性的，所以建议花时间尝试对每个执行的测试做一个简短的概述。这样我们就知道什么被测试了，什么没有被测试。

5.缺陷将实时报告给Mantis。

使环境（而不是标准）成为测试策略的主要输入和影响因素。这将促使我们环顾四周，将周围的一切都考虑在内。