前几天在和邰晓梅老师交流的时候，她提到了基于上下文驱动的测试理论，就去查找了一些相关的资料，发现有很多和自己的想法是相同的，不知道大家是否听说过这个理论呢？如果你听说过，可以直接跳过去，从第 3 点开始看。
01
什么是基于上下文驱动的测试（context-driven-testing）？它不是一种具体的测试方法，而是一类测试思维的体现，通常是指测试人员首先查看特定迭代的细节（产品特性、业务需求、相关干系人等）来选择他们的测试目标、技术和可交付成果（包括测试文档）。归根结底，上下文驱动的测试是要尽我们所能做到最好。我们不尝试应用 “最佳实践”，而是接受非常不同的实践（甚至常见测试术语的不同定义）将在不同情况下发挥最佳效果。
02
Cem Kaner（《软件测试，经验与教训》的作者，建议有机会可以看看这本书，很有意思的）基于自己的经验，针对上下文驱动的测试理念给出了 7 个原则：
1. The value of any practice depends on its context.
2. There are good practices in context, but there are
no best practices.
3. People, working together, are the most important part of
any projects context.
4. Projects unfold over time in ways that are often
not predictable.
5. The product is a solution. If the problem isnt solved,
the product doesnt work.
6. Good software testing is a challenging intellectual process.
7. Only through judgment and skill, exercised cooperatively
throughout the entire project, are we able to do the right things
at the right times to effectively test our products.
相对比较好理解，就不做翻译啦，它倡导的是结合团队具体的信息与干系人关注的重点，不盲目引入 “最佳” 实践，而是关注项目的特定因素，给出当下最好的解决方案。不强制要求测试活动一定要遵循固定的流程或者公式。就个人而言，笔者还是很喜欢这个概念，因为测试实践经常被认为是僵化的和可模仿的。有人做了并且成功了，所以我也要做。在测试活动中，创造性思维、分析问题的能力和决策制定的变化空间还是很大的，需要我们去做更多的尝试。
03
面对不同的团队能力和业务形态，我们的测试策略需要做出动态调整。笔者最近在带制造域的产品测试，会明显地感觉到它与互联网的玩法是不一样的。
在一般情况下，对于跨系统的端到端接口，比较好的实践方式是引入接口自动化，根据业务场景准备好测试脚本和数据，然后定期去执行，验证接口的正确性。看起来好像很美好。但实际的情况是，制造行业的接口本身就相对稳定和标准，难点在于验证数据的有效性和业务逻辑的正确性。它不同于互联网项目，制造域里很多业务行为很难通过系统来判断。比如，在一堆的原材料中，系统其实是很难判断哪些材料是给空调的，哪些材料是给冰箱的，只能靠人为判断（当然，你也可以在系统中去维护这类数据，但是成本太高，光原材料，可能就可上千种，而且是动态变化的）。所以，单纯的接口测试很难在这样的团队中去落地，实际的业务价值也很有限。所以，我们的做法是让不同的业务人员经常跑跑，即可以熟悉系统，也可以验证接口，比写脚本要来得实际些。
另一个场景：有经验的测试同学肯定知道，在测试活动中，SIT 验证优先于 UAT 验证，一定是在 SIT 环境中进行了充分的验证后，才能上 UAT 环境，让用户进行验证。哪能把问题留给用户呢。但是在制造域中，更提倡的反而是尽早地进行 UAT 验证，尽早让真实的一线业务人员卷进来参与验证。坐在办公室里的产品是很难理解在一线的工人是如何操作系统的，并不是他们不专业，或者没有充分的调研，而是不同工种所带来的天然视角上的不同。所以，这个时候，业务人员需要尽早地介入，从业务的角度去提出改进意见，更加有利于产品的上线和价值实现。而不是测试人员对着产品需求进行专业的测试，因为测试是测不出什么太大的问题，系统实现本身没有问题，但它就是与一线员工的操作习惯不符。你觉得哪个测试的价值更大？
04
Change Is The Only Constant ，永恒不变的，只有变化。最好不要试图改变的需求不断变化、测试计划永远无法完成的事实。把你的时间花在设计和执行测试上，而不要花在不断地更新测试计划上。这其实是很符合敏捷的思维。敏捷其实也是一种状态，一种心态。Being Agile 远大于 Doing Agile。
当然，这并不是说那些标准和流程不重要。不论是各类技术能力上的最佳实践，还是行业标准的认证成熟度，都有助于行业整体的规范化发展。但是具体的不同的行业，不同的团队，我们需要根据实际情况及业务特点，做出取舍，甚至创造出适合特定环境的测试方案和能力，因地制宜，因时制宜。
测试人，也需要有想象空间。