昨天在James Bach的博客（http://www.satisfice.com/blog/archives/724）上看到两位大师James Bach和Cem Kaner在context-driven-testing方面因为根本意见分歧而分道扬镳的消息。James依然认为上下文驱动测试是一个测试流派，而Cem Kaner已经不这么认为了，他认为上下文驱动测试是一个测试方法。为了了解这次事件的上下文，我于是找到context-driven-tesing来多了解一下上下文驱动测试。
简言之，什么是上下文驱动测试？
上下文驱动测试的核心是强调根据本项目的特定上下文来进行测试。千万不要和上下文驱动测试的人谈什么“最佳实践”。他们只承认“没有最好，只有最合适，一切因上下文不同而不同”。
上下文驱动测试是一种测试方法，或者说一个测试流派（在Cem和James没有在此点上出现分歧之前），而不是一种具体的技术。从事上下文驱动测试的测试人员需要掌握的技术或者说知识不仅仅是测试，而是人文、社科等大框架下的诸如心理学、经济学、人类学等各种知识。
Context driven testing上下文驱动测试的7大金科玉律
The value of any practice depends on its context.
任何实践的价值取决于其上下文。
There are good practices in context, but there are no best practices.
只有在特定上下文下的好实践，而没有最佳实践。
People, working together, are the most important part of any project’s context.
工作在一起的人们是任何项目上下文当中最重要的部分。
Projects unfold over time in ways that are often not predictable.
项目常常随着时间以不可预计的方式开展。
The product is a solution. If the problem isn’t solved, the product doesn’t work.
产品即解决方案。如果问题不解决，产品将无法工作。
Good software testing is a challenging intellectual process.
好的软件测试是一个富有挑战性的脑力劳动过程。
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.
只有拥有判断力和技能的人们在整个项目层面的不断协作才能使我们能够在正确的时间做正确的事情，从而有效地测试我们的产品。
说实话，个人不太理解4、5和7与上下文测试有什么根本的关系。而在Michael Bolton的2006年发表的关于UAT的PPT中也非常强调7。我可能还需要更多阅读他们的文章，来补充理解。
上下文驱动测试和其它测试有什么区别？
上下文驱动测试作为一个独立的流派（至少开始的时候创始人这样认为）需要为自己正名，与其它测试区分开来。所以在www.context-driven-testing.com的首页就花大量篇幅主要介绍了它和另外几种测试的区别。
上下文感知测试context-aware testing
如果你觉得测试的时候考虑了上下文就是在进行上下文驱动测试，Cem Kaner和James Bach可能会说“哦，那可不一定。”因为如果你是先参考了一些最佳实践，然后考虑了与项目具体相关的因素，那你就只是在进行上下文感知测试（Context-aware testing）而非上下文驱动测试(context-driven testing)。例如，一些标准（比如对测试文档进行了一系列的定义的IEEE 829标准）的制定者虽然希望测试人员参照此标准，并鼓励测试人员基于具体项目干系人的需要而修改测试文档，但它在“本和末”上和上下文驱动测试有明显不同。上下文驱动测试从项目干系人的需求和此项目具体的制约因素和机会开始，以此为本，而只把标准当成补充性的“末”。
标准驱动测试Standards-driven testing
有些测试人员有自己比较推崇的测试模型（比如V模型）、组织结构模型（比如严格区分开发和测试团队）、产出物（比如提交测试的代码要有详细的说明书）等。而上下文驱动的测试没有自己的偏好。测试人员拿到给他们的东西，然后开始干活。有经验的上下文驱动测试人员必须知道如何处理摆在他们面前的任何情况。
忽略上下文测试context-oblivioustesting
比如，有些测试人员只是照抄别的测试人员的做法，而不管具体应用场景的上下文，那么他就是在进行忽略上下文的测试。
上下文帝国测试（我的翻译，觉得也许不妥）context-imperialtesting
上下文帝国测试坚持改变项目或者业务来适应测试人员最佳实践，而不是改变实践来适应项目。上下文帝国测试在某些咨询人员身上比较常见，他们或者熟读测试书籍，或者个人经历局限于特定上下文，或者追随当前业界某个被吹捧为唯一正确的方法。
个人感觉就是测试的学究派不顾上下文，生搬硬套测试方法吧！可能和忽略上下文测试在不管当前项目的上下文时有一点类似，但又有一点不同。不同在于它还希望改变项目或者业务来适应测试，这个的确有点霸道的帝国范！
特定上下文测试context-specific testing
特定上下文测试存在于测试人员长期工作在特定类型的项目而缺少多样的测试经验的时候。在特定场景下，一个特定上下文测试的测试人员和一个上下文驱动的测试人员会用同样的方式测试系统。但一个特定上下文测试的测试人员只有在他熟悉的特定上下文才知道如何工作，而不知道换了一个上下文（比如，不同类型的项目）该如何有效地开展测试。
说起来，我感到我们团队和这个蛮类似的啊！提醒自己：首先，对我们熟悉的类型的项目，要多反思，不要老是依照惯性用老方法做事；还要多回顾总结，看在特定上下文下什么实践是比较合适的（哈哈，不敢说最合适的）；其次，对于自己不熟悉的测试类型，要多看多了解，拓宽知识面，功利一点来看有时他山之石可以攻玉，淡然一点来看开卷有益，有助提高测试人员的自我修养。总不能测了一辈子，走出去说，我是运输系统的测试人员，其它测试我一点都不懂吧！
敏捷测试Agile testing
敏捷开发推崇响应客户需要、减少浪费、用人性化的方式进行软件开发。这些点与上下文驱动测试不谋而合。但上下文驱动测试并不是敏捷开发固有的一部分。例如，敏捷开发宣扬大量的单元测试，但上下文驱动测试人员不会依赖高质量的单元测试，而会在单元测试不充分的时候调整测试方法。所以，即使开发不敏捷、测试不敏捷，还是可以做上下文驱动的测试。
结语
关于这次纷争，流派也好，方法也罢，我觉得我还没有到执着于支持哪一方的层次。但根据项目实际情况做测试，即使长期工作在同一个项目，也根据不断变化的上下文而不断摸索和调整测试方法，也是我所赞同的。上下文驱动测试精髓还在，却物是人非！James和Cem两个几十年的老友也闹到要决裂，也许除了网站上的一些变化和申明，背后还有“上下文悠长”！
版权声明：本文出自 zdlzx 的51Testing软件测试博客：http://www.51testing.com/?56882
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
