自动化测试脚本编写小结

1. 注释

• 业务代码必须要写好注释。变量的命名也需要考虑规范，尽量和业务名相关，这样也算是一种注释，让人看得清楚。
• 纯逻辑代码注明该块代码的作用是什么，入参、返回值的注释。一头(入参)、一尾(返回值)、一大概(功能)，让他人拿到就能用，不用想怎么实现的，应用为先。

2. 代码抽取、封装

• 使用两次及以上的代码块，即可考虑封装成函数，抽取复用的代码，提出入参为变量。
• 涉及到对某个字段或者特定数据等进行多种操作时，考虑写成类的形式。
• 某业务的操作涉及的数据和逻辑功能较多且复杂，考虑将业务操作和数据分离。

3. 业务相关

• 写代码前一定要考虑好业务需求，评估需要实现的业务；理清业务之间的关系，业务中也分轻重，并不是所有的业务都是需要立即去实现的。
• 使用思维导图梳理业务，将业务走一遍，再思考每一步怎么用代码实现。
• 磨刀不误砍柴工，明确需求、思路更重要，代码只是实现的手段。

4. 结果校验

• 写测试脚本，校验是必不可少的一环，有的字段配置下发后，是否成功未知，测试未知，需要通过重新获取来验证，常常使用assert来判断。
• 结果数据的展示，使用 f 语法来展示数据（比%s、.foramt()更清晰），在pytest+Allure 中使用allure.attach(数据，’描述信息’)

5. 调试

• 遇到bug，重复运行两遍不如debug一遍，调试最能发现问题所在。
• 调试技巧需要不断地提升，提高调试的能力。

6. 提交代码

• 提交代码前先自己检查一遍，将调试的代码删除，比如使用main函数调试的代码，将没用到的变量、导包、无用的注释删除， 再使用 Ctrl+Alt+L 将代码格式化后符合PEP8规范。
• 每次提交的信息，都应该简明扼要地描述当前提交的代码。
• 每天记得更新项目代码，避免在开发新的脚本过程中落后master太多，也便于提交代码时合入、减少冲突。

7. 及时总结

• 每写一项业务、一个脚本，及时记录自己在其中遇到的问题，有哪些教训可以总结哪些东西。
• 有的业务只有在用自动化覆盖时才去了解，一旦了解后就记录该块的业务知识、注意点，业务这种东西一旦学习了，以后就只要花很少时间就能拿起来。

8. 向同事学习

• 同事写的代码总有值得学习的地方，学他人之长，补己之短。
• 对于别人写的不好的地方，思考是否有优化的空间。
• 刚开始可以学习模仿别人写代码，慢慢地试着优化代码。