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