这周没有忘记要写周记了，连续好几周都忘记了，虽然后面都弥补了。有很多原因吧。这周的可以公开一下。
本周上班6天，从端午的假期结束开始，到现在，感觉时间好像过了很久似的。
这周主要是在调试脚本、修改Gitlab上同事提交的问题了。其中上周的一个新增脚本继续调试，现在只要有环境就可以跑了。本周剩余的时间几乎都在修改问题，修改问题还是挺舒服的，没有很大的压力，只是不总是一直有问题改。
通过改以前的脚本，可以发现一些问题：对于报错的地方，思考为什么当初没想到会出现这种问题；以前的代码写的哪里不好、哪里考虑不周，哪些地方可以写的更好，如果遇到自己都看的费劲的地方说明代码写的不好，需要优化。 经常回过头看自己写的东西，还是有不一样的体会的。
在写有的脚本时，还是对很多东西欠缺考虑，举例本周的小问题，在写音频文件导入测试的case时，考虑到测试利用例的要求是模拟用户操作在UI层实现，所以直接写成UI自动化了，没有抓包看是否有纯接口的纯接口方式来实现，其实是有的，只是导入音频文件在浏览器开发工具中无法抓包，但是通过wireshark可以抓到文件post请求；同时在清理测试环境时，删除音频文件导入时在浏览器开发者工具中就可以抓到Delete的报文，当时没有去尝试，其实也有想到测试完音频文件导入后怎么清空已经导入的文件，对此用了其他方式来处理，是我这个case写的不好，今天算是做了修缮。
经常做脚本的优化和问题单的修改，想想也是有写体会的。比如如何快速定位问题，现在是驾轻就熟了，主要是看测试报告中的报错信息、日志打印，语法问题都不算是问题了，基本可以解决，主要是一些不好确定是哪里有问题的Assert报错，脚本不稳定等一些无法复现的问题。对此，我一般都是在出现问题的环境中争取复现，若能复现基本就可以通过debug来解决所有问题。除此，还有异常处理和规避、兼容是适配 ……
目前，我遇到的这块问题可以归类为以下几种情况：
脚本语法问题，考虑不周环境问题影响异常处理、规避同事修改问题引入了其他问题测试场景构建没有达到预期的条件而报错测试场景达到后，没有得到预期的结果而Assert报错网络、设备不稳定导致的请求超时、接口配置下发后返回值有误版本不兼容、需要适配策略选择：哪些需要执行、哪些只在特定版本上执行脚本性能优化，如何提升执行效率、减少无谓耗时小结：
多回顾自己以前写的代码和文章。多复习以前学的东西。多总结计划：
抽空找时间，针对以前我写的脚本中欠考虑的地方，汇总一下共同的共性，小结哪些地方没有考虑周到导致了需要脚本执行时报错、优化归纳同事对我写的代码的评审意见，提炼要点写一篇关于以上两点的文档。