测试人员的修炼——测试思想成熟度模型

     从测试目的出发，总结了测试人员的思想成熟度模型。从一段到七段，由初级到高级。

测试一段：发现BUG，发现有价值的关键的BUG。
测试二段：定位BUG，积极主动的定位BUG。
测试三段：解决BUG或提出解决方案。
测试四段：总结和分享
测试五段：思考和预防
测试六段：规范流程
测试七段：成本意识

 

（以后要画个图）

     这是一个真实的例子，我们在一次迭代中的例行回归测试时，场景准备（略），数据准备（略），执行（略）。重点说验收测试结果，首先观察系统页面展示，程序运行正常无告警。其次查看日志，无各级erro报告。然后查看数据库中相关业务表，结果也是对的，没有发现异常。以上各项指标已符合预期输出，有些测试人员到这里，就认为这个CASE通过了。如果真是这样的话，我们就错失机会了。还好实际上，我们的测试人员是足够优秀的，在写测试报告的过程中，从程序输出的日志里发现了异常，刚刚测试的程序，走了另外一个分支（国外的业务逻辑，国内是不使用的），而我们的业务逻辑完全没有被覆盖到。所以之前的测试是无效的，需重新验证。事后想想，如果走错版本分支这件事不被及时发现的话，版本直接发布到现场，后果是不堪设想的。我们知道，我们发现了一个严重的BUG，如果不修复，接下来的一系列测试CASE将无法展开（都是基于国内分支的）。所以说测试不但是一个正明的过程，更是一个正伪的过程。正伪过程中，通过逆向思维能够发现更重要的问题。至此，我们完成了测试人员的第一级修炼，到达“测试一段”。

 

   可是程序为什么会走错分支呢？查看了DB中相于流程分支的配置，正常的。程序的版本，正常的。咨询了相应的开发，国内逻辑没有变，与国外是完全不同的，日志里会打印版本信息。同时，又是一个棘手的BUG，如何定位是一个挑战。
     谁来定位问题，对此存在很多争论，有些测试人员认为定位BUG是开发的事，测试只管发现并提交BUG。那些执相反意见的人，比如开发人员或对自己有较高要求的测试人员，认为这样说是不负责的，等等，然后争论。其实没必要，从思维的角度观察，如果一个测试人员认为定位BUG完全是开发人员的负责的话，我们可以发现客观的原因是，这名测试人员的思想成熟度不够高，还停留在测试一段的水平。世界观决定方法论。

     有了主动定位BUG的思想，就具有了向上的阶梯。定位问题的能力涉及非常广泛和深奥远超软件工程的范围，单说软件产品，定位问题涉及到软件运行的平台环境（主机、数据库、中间件、网络等），程序（业务程序、框架程序、外围接口），业务数据，配置等。上面的这个事例中，我们最终发现是DB中一个基础配置项（决定业务分支）的确被修改过，之后又被改回正确的值，当我们查看的时候，DB中的配置是OK的。而程序在运行时直接使用的配置是加载在专门的共享内存容器中的（从DB加载到共享内存中），被改掉之后做了刷新，恢复之后，没有做刷新的动作。所以，导致了业务流程全部走到一个无效的分支。问题终于定位了，测试人员主动探寻并定准BUG所在的修炼，使我们成为测试二段。

 

     问题终于定位了。有人说，这下好了，可以松一口气了。解决问题的分工，我们公司通常由开发解决程序问题，QA解决配置和数据问题。例子中，这个BUG是由配置引起的，所以QA改一下配置然后刷新就解决了。事实上我们也是这么做的。在接下来的测试过程中，陆续测出了很多BUG，并及时提交给开发修复了代码，最终发布了一个比较稳定的版本。

 

     可是，问题真的解决了么？

事情没有这么简单。两周后，下一个的迭代中，我们再次发现了类似的BUG，同样的配置又被修改了。于是问题有了新的引申，需要重新定位和更全面的解决方案。
     一翻努力之后，问题浮出水面了。另外一个产品线，在这个环境中部署了一套自动化的CASE，在准备场景的时候对基础配置重新做了初始化，这个配置对他们产品线没有影响，只是为了方便把配置表做了全表替换。到此，真正的问题找到了。之后，双方做在一起共同梳理了基础配置。使得双方的测试都可以正常执行，不再相互影响。

     找到问题真正所在，并从根源上解决，做到了这一点，那么恭喜你，可以晋升为测试三段了。

 

     接下来的修炼历程，从认知理论出发，解决了一个问题，并不带表我们真正懂了，掌握一门知识离不开总结和分享。写个邮件，将以上对问题的分析和处理过程分享给团队其他成员或其他团队，让大家共勉，避免类似问题再次发生。再回到解决问题的角度来思考，总结和分享的过程，实现了从解决单点问题，发展到了解决多点问题，甚至继续扩展到一个面。这是一个很大进步。

      今天先写到这里，后面还有很多在酝酿，将慢慢呈现给各位朋友。