大家好，我是小谭。
最近，小谭在做自动化测试时遇到了一个问题，解决这个问题倒是没花多少时间，但在解决问题的过程中，我想了很多，也有一些话想跟小伙伴们分享。
此文遂成。
老规矩，先说问题。
问题
做Windows应用的自动化测试时，有个场景需要对程序的UI界面进行对比断言。
但在win7电脑上运行脚本时，出现了问题：当应用因断言失败重启后，界面的字体发生了变化——原本的字体加粗效果没有了。
、
解决问题
STEP-01 开发不背锅
开始，我以为是应用的问题，因为难以定位问题原因，便将问题抛给了开发，但当我的消息刚发出时，我突然想起两个点：
01 平时在测试应用功能时，也频繁的重启过，没遇到该问题；
02 如果该问题必现，那作为对我司产品有着高要求的业务方，早该反馈了。
故，我脑袋一转，突然质疑——莫不是自动化脚本的问题？
STEP-02 检查代码
于是，我检查了代码。
我用的是win32api库调用Windows的api启动应用。
示例代码如下：
win32api.ShellExecute(0, 'open', '应用程序.exe', '', '', 1)
我将代码从自动化脚本中剥离出来，在cmd里进入Python Console单独执行了一次——应用启动，字体确实变更了。
同时，为了避免因电脑配置带来的影响，我又做了一次试验，手动启动应用——字体未变更，显示正常。
到这里，我可以确定是python脚本的锅。
STEP-03 定位问题
确定了问题，我便开始定位问题原因。
首先，我翻看了win32api的官方文档，没有提到启动应用会造成应用“损伤”的tips。
接着，万能的百度 & 谷歌上场，但这次它们不再万能，没有解决方案。
然后，我又问了开发应用的C语言大佬，亦没有结果。
最终，本着性价比原则，我不再追溯，只有大胆猜测一番——手动启程序需要管理员运行，类似这样：
但，使用win32api库启动，win32api内部可能封装过SuperAdmin的方法，导致缺失该步骤，应用是一种假管理员启动，造成字体读取异常。
以上，纯属猜测，请勿当真。
既然无法定位问题原因，那先解决它吧。毕竟，组内做前端自动化的几个小伙伴还等着下锅煮菜。
STEP-04 解决问题：换用其他方法
我尝试用os、win32process等网上的教程去启动应用，如：
os.system('应用程序.exe')win32process.CreateProcess('应用程序.exe', '', None, None, 0, win32process .CREATE_NO_WINDOW, None, None, win32process.STARTUPINFO())
依旧没有解决问题。
卒。
STEP-05 解决问题：取巧方法
绞尽脑汁之后，我又想到了一个取巧的办法，用python的pyautogui库模拟鼠标操作——双击这个程序启动，待弹出“需要管理员授权”时，点击“是”的选项。
结果，当我快速写完代码，在电脑上实验时，我**的发现，这个授权弹窗，会阻断pyautogui的运行……
又卒。
STEP-06 解决问题：终局之战
怎么办，怎么办……
当时的感受真的是，我手持宝剑（我的大脑），对战一条恶龙（坑爹的机器），但无法战胜它。
好在，我的公主曾告诉我，遇到boss，先休息休息，保存体力。
于是，我下楼走了一圈，在冬日的冷风中，我突然开窍，想到了战胜恶龙的妙招——Windows独特的bat程序可以启动应用。
于是乎，我撸了一个bat脚本。
start /d "程序路径" 应用程序.exe
双击运行bat脚本，恶龙被击伤。
再用Python调用bat脚本去启动应用，恶龙被杀死。
一如既往，做个总结
不论我们做自动化测试，还是普通的功能测试，于问题（bug）的角度而言，总是：
被发现->被定位->被解决
只不过在功能测试中，普遍的说，“被发现”是测试干的，“被定位”、“被解决”是开发干的。换句话说，很多测试理解测试工作仅仅是发现问题，剩下交给开发，等开发解决完问题后，我再验收下，工作就ok了。
读过小谭之前推文的小伙伴肯定知道，小谭经常强调定位问题和解决问题的思维。
定位问题和解决思维的问题有多重要？
抛开其他诸多优点不谈，单就说自动化测试，如果你没有提前养成这种思维，没有将角色从测试转换为测试+开发，没有debug过代码，那么你很难提升自己的自动化测试水平。
其实，不少小伙伴后台询问我怎么做自动化测试，说他们做自动化测试总是停留在写自动化测试用例的层面，不知道该如何提升自己。
我想说，我跟大家分享的这个案例，就是一个提升的过程。以解决问题为导向，你需要定位问题，并在定位和解决的过程中，让自己的一个个想法被一次次现实击败。失败足够令你成长，并且会让你产生更多奇思妙想的解决办法。
试想，如果恶龙一来就被战胜，岂不是遍地都是勇士。
祝关注我的小伙伴们都成为屠龙的勇士！