测试用例之实现自动化

测试用例之实现自动化

——背景：

如果通过手工测试人员进行手动测试，不仅会浪费大量的人力、物力、资源等信息，而且对产品的测试程度相对来说比较低。因此，测试用例的自动化（俗称：冒烟测试）显得尤为重要。从我目前所做的自动化，个人做一些总结。

——结构：

1. 项目A - 这个一个主要从xxx端驱动的自动化测试 用例项目（用例）
2. 项目B - 这个一个主要从xxx端驱动的自动化测试项目,其基本的库可提供给可靠性，稳定性测试使用（接口，可关联）
3. 项目C - 提供了a、b、c等平台的自动化工具，从而制造测试所需的条件或提高测试效率（前台、后台检查接口）

番外——api代码常见问题总结【注意事项】：

• 可调试性

1. 日志或者调试信息不清晰，无法告知问题原因；
2. 该记录日志的地方不记录日志，或者有日志但不打印异常，出问题不好查；
3. 断言不添加描述信息，不利于查问题和后期维护

• 维护性

1. 函数参数、返回值无类型描述；
2. 或者类型描述不具体，没多少意义，例如：字典的类型描述应该要说明key和value的类型；
3. 易调整的、有测试需要的常量应该要提取为运行参数，例如：像外部配置的路径应该要作为运行参数，以方便打桩测试或者环境迁移；
4. 函数抽象与重用，例如：有时候需要某个接口里的一部分功能或者逻辑，有些人会倾向于把代码拷贝过来改改，这样久了就会有很多相似的代码。一般比较好的做法应该是把旧接口进行抽象，或者从旧接口里提取功能子集做为新接口

• 协程

1. 网络IO需要协程化，避免阻塞主线程；
2. 磁盘IO需要协程化，避免阻塞主线程；
3. 内部用多线程、多进程实现的协程接口，要通过锁或者信号量限制并发

• 异常

1. 异常考虑缺失 [json.dumps接口会抛出TypeError异常；json.loads接口会抛出JSONDecodeError异常]；
2. 异常捕获范围太粗，容易掩盖问题；异常导致的资源泄露

• 其他

1. 异常分支要考虑好对全局的影响，必要时要填充默认值来防止错误扩散；
2. 对变量为None的可能没判断好就直接使用；内部实现暴露给用户