Question

Robot framework测试脚本编写思考

Answer 1

基于Robot Framework框架使用经验，总结下测试脚本的设计思路。

这里所谓的设计思路，其实就是编写测试脚本时应该关注的点。在工作中，我有根据自己的经验，整理了针对实际工作内容的脚本编写规范，并逐步优化脚本编写规范以及测试脚本的模板。

个人以为，在编写测试脚本时，需要关注以下几点：规范性、简洁性、时效性、结构性、稳定性、可读性。

规范性有多重要呢？大家都遵循相同的规范，那么在看别人的脚本时，就容易找得着北。

测试脚本应该保持精简。精是一种修炼，简是一种风格。如何保持简洁性？最基础的就是不要冗余。

脚本时效性的重要性，大家知道得不彻底。为什么说不彻底呢？因为工作过程中有发现挺多测试人员有个错误的观念：我一个suite/case多花一两秒、几秒或十几秒，有什么关系呢？
有什么关系呢？整个测试工程集有几千个case，每个case要是多花一秒，积少成多就是几千秒了。按照我们现有的case量，一次回归就得至少多花两小时。
对一个初级的脚本编写者来说，关注脚本时效性可以考虑以下几点：

更进一步来说，脚本时效性和测试点、测试用例的组织，脱离不开关系。30个测试点组织成10个case和30个测试点组织成8个case，脚本的运行时效性是不一样的。时效性差多少，就和脚本运行的每个操作有关系了。

清楚地知道每个常用操作的运行耗时，能帮助我们写出时效性更强的脚本。如何知道每个操作的运行耗时呢？看脚本运行结束后生成的log.html即可。

清晰的脚本结构，包括用例集的初始化和结束(Suite setup/teardown)、用例的初始化和结束(Case setup/teardown)。

稳定的脚本可以降低自动化维护成本。
常见的脚本稳定性的问题有：

可读性好的脚本，可以降低他人学习和维护该脚本的成本。

良好的用例编写习惯可以让他人更容易看懂你的测试用例和测试脚本。Case Documentation中要有完整清晰准确的测试用例。

测试脚本中，也可以增加适当的注释使脚本更易于理解。
注释有Comment和"#"两种。前者注释的内容会体现在报告中，后者注释的内容不会显示在报告中。建议在脚本中使用Comment进行注释，并用"Comment step-n"把脚本步骤和用例步骤进行一一对应。