提效必会：逆向思维在解决问题中的应用
问题提出
项目现场人员经常会出现如下场景：
现场人员给家里支持人员打电话或发邮件：“系统发布失败，出现×××××错误，现场无法解决，错误日志已发过去了，请支持”。
支持人员看过日志,回复：“你把××××修改一下，重启下试试看好用不了”。
现场人员：“修改了，还是不好用……”
支持人员：“哦 ，那你在检查一下×××××配置的是否正确，看看是否哪配错了。”
现场人员：“都检查好几遍了，没发现错误……”
支持人员：“家里这边没有出现你这个问题啊，启动都正常。”
现场人员：“那好吧，我再试试看吧……”
……
上面只是举了一个简单的例子，项目实施过程中可能会遇到各种各样的问题，通常都是按照上面场景描述的方式进行问题解决的。
一些常规的问题，通过一些已经积累的经验，往往可以直接解决，但是有些问题，由于没有遇到过，解决起来只能靠多次的尝试，家里和现场一来二去之后，问题可能还是没有得到解决，或者又出现了新的问题，效率大大降低。
本文介绍了一种逆向思维的问题解决方式，可以较好的提升效率，已在多次问题解决过程中得到应用，效果显著。
应用实例
常规的问题解决的思维方式是这样的：
“修改×××××，看看问题是否解决，如果没有解决，再修改×××，直到问题解决”，这种方式是一种正向思维。
逆向思维的方式是这样的：
“修改××××，看看是否出现问题，如果没有问题，再修改×××，直到问题出现”。
逆向思维解决问题的方式的重点是“重现问题”，而不是“解决问题”，想尽一切办法使问题重现，总会有解决方案。
按照逆向思维的方式，上面提到的场景就变成这样了：
现场人员给家里支持人员打电话或发邮件：“系统发布失败，出现×××××错误，现场无法解决，错误日志已发过去了，请支持”。
支持人员看过日志,回复：“根据你的错误日志，我们经过多次尝试，重现了你的错误，通过调整××××，可以解决这个错误，你试试看。”
现场人员：“好用了，非常感谢！”
通过两种思维方式的对比可以看出，逆向思维的处理方式只用了很少的回合，就解决了实施现场的问题，效率明显提升。
正向思维是指导现场人员去“直接解决问题”，逆向思维是根据现场人员的反馈去“重现问题”，从而“间接的解决问题”。
下面再举几个正向思维和逆向思维的例子：
实例一
实施现场出现页面折线图中文乱码问题，现场环境是linux+websphere.两种思维方式对比如下：
正向思维：指导现场调整linux的locale设置、websphere的jvm字体设置、websphere的jvm参数，现场反复修改测试，始终都还是乱码，问题没有得到解决。
逆向思维：家里有linux+websphere环境，但折线图中文显示正常，没有乱码，经过几轮调整测试，终于也出现了乱码，和现场情况一样了。
最终确定是由于linux自带的字体必须支持中文，其他设置都不是问题关键。现场检查了一下，发现linux自带的字体中刚好就没有安装中文字体，于是问题很快就解决了。
实例二
实施现场反馈，数据导入功能，当导入500条记录时，可以导入成功，当导入1000条记录时，就会失败,现场环境是linux+websphere，而windows+tomcat环境下，1000条记录都可以导入成功。
家里也搭建了测试环境(linux+websphere)，1000条也可以导入成功。
经过几番测试和排查，都没有找到问题在哪，现场人员怀疑和平台有关。两种思维方式对比如下：
正向思维：检查代码、检查现场环境，查找各种可能的解决方案并不断尝试，看问题是否能解决。
逆向思维：在家里的linux+webpshere环境下重现问题，重现现场出现的错误日志。通过分析错误日志，应该是在读取到某条导入数据时，读取到的日期格式有问题，程序无法识别导致出错。
但同样的导入文件，家里环境中可以正常导入。
为了重现错误，故意将导入文件的第一条记录的日期格式改成错误的格式，执行导入，结果日志中出现了和现场一模一样的错误信息，到此已经可以确认就是导入文件中的某些数据有问题。
开发人员完善了代码，将导入的代码中加入了日志输出，如果有数据记录导入失败，则输出该条记录的信息。现场更新代码后再进行测试，日志中果然出现了一条记录的错误日志输出信息，原来该条记录中有汉字显示成了乱码，影响了整条记录的格式。
家里的导入文件是从现场拿来的，同样那条记录中就没有乱码，这也说明了实施现场问题的复杂性，什么稀奇古怪的情况都可能出现。
总结
当正向思维方式很难解决问题时，不妨尝试一下逆向思维方式，二者需要相辅相成，灵活运用。采用逆向思维来解决问题，往往需要搭建一个用于重现问题的环境，需要反复进行假设-测试论证-再假设-再测试论证的过程，直到问题出现。
对于实施项目来说，很多时候现场调试解决问题非常麻烦，逆向思维的这种方式实际上是把更多的测试和验证工作放到了家里，给现场的只是一个最终可以解决问题的结果，不仅仅是提升了支持的效率，相信现场人员对这种支持方式会更加满意。
下面是一份配套资料，对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！
这些都可以以在公众号：伤心的辣条 ！ 免费领取，还有一份216页软件测试工程师面试宝典文档资料。以及相对应的视频学习教程免费分享！，其中资料包括了有基础知识、Linux必备、Shell、互联网程序原理、Mysql数据库、抓包工具专题、接口测试工具、测试进阶-Python编程、Web自动化测试、APP自动化测试、接口自动化测试、测试高级持续集成、测试架构开发测试框架、性能测试、安全测试等。
学习不要孤军奋战，最好是能抱团取暖，相互成就一起成长，群众效应的效果是非常强大的，大家一起学习，一起打卡，会更有学习动力，也更能坚持下去。你可以加入我们的测试技术交流扣扣群：914172719（里面有各种软件测试资源和技术讨论）
喜欢软件测试的小伙伴们，如果我的博客对你有帮助、如果你喜欢我的博客内容，请 “点赞” “评论” “收藏” 一键三连哦！
好文推荐
转行面试，跳槽面试，软件测试人员都必须知道的这几种面试技巧！
面试经：一线城市搬砖！又面软件测试岗，5000就知足了…
面试官：工作三年，还来面初级测试？恐怕你的软件测试工程师的头衔要加双引号…
什么样的人适合从事软件测试工作？
那个准点下班的人，比我先升职了…
测试岗反复跳槽，跳着跳着就跳没了…