看到一位大佬写的关于“如何科学排查插件或工具报错”的方法，分享给大家：
基本是属于考验你鸡贼不鸡贼，够不够机灵，它和经验无关，所谓经验就是知道答案，而这个是看你会不会迅速发现找到答案的方法。
一个简单的例子，你养了两只狗，你出门回来的时候总是发现冰箱被打开然后偷吃。
但是你又不知道是哪只狗干的，这个时候你会怎么做，当然是：
1、A狗锁牢，B狗不锁，测试是不是B狗干的
2、A狗不锁，B狗锁牢，测试是不是A狗干的
3、两只狗都锁牢，测试是不是有其他狗干的
这样只需要三轮测试，就能测试出到底是哪只狗天天偷开冰箱了对不对，当然也许测试结果是两只狗都干了，但至少能判断出是否有无辜的狗对吧
例子讲完
当你拿到一个新的工具（插件或者流程操作）
上来第一步，如果直接打开你的很复杂的项目场景来进行测试（很多人就是这么莽，就会这么干）
会出现两种情况：
1、没报错，结果正确，顺利 （那就OK，牛逼，没啥好说的）
2、报错，无法得到正确的结果
如果是情况2，不够鸡贼的人这时候就蒙了，完全不知道哪里出了问题，完全没有方向，就算是问人，也不一定问的到答案
而鸡贼的人（机灵的人）却早早地打开了新的场景，新建一个最简单的环境来进行测试。
会出现两种情况：
1、报错，无法得到正确结果
2、没报错，结果正确
如果是情况1，你知道你的场景是干净的，现在你有一个【绝对没问题的场景】，如果还失败，那只能说明大概率就是你操作问题或者软件本身的bug，继续想
办法查官网文档看看正确的操作，直到变成情况2
如果是情况2，那么现在就拿到了一套自己可以确定正确的操作流程，现在你就有了一个【绝对没问题的操作流程】
然后拿着这套自己基本可以确定是正确的操作流程，放到你那个很复杂的项目场景文件里面进行测试
就算出了问题，首先你应该是可以确定你这套操作流程完全没问题的，那根据推断，大概率就是这个项目场景的问题
然后就在场景里进行对比排查，是设置问题？还是模型问题？导出导入重组场景治百病？起码有个方向是不是，而不是一直一头雾水无从下手
总结一下就是，不要一上来就用一个【你不清楚深浅的复杂的场景文件】去测试【你不太了解正确操作流程的操作（插件）】
那样的话，如果出问题了，你会根本无从判断是场景问题还是操作问题还是软件本身的。
如果你搞不明白这个套路，那你可能会经常问出如下问题
“为什么XXX工具不能用啊”
“为什么XXX操作不好使啊”
“为什么arnold渲不出啊”
这类其他人永远也没办法给你解决的问题。
作者：劲爆羊厂长
加载中
