如题，做个大概的介绍：
OMS（订单管理系统）、WMS（仓库管理系统）、TMS（物流管理系统），这几个系统存在一个承接关系，且单个系统的业务流程也比较长和复杂。拿 WMS 系统举例。比如一个订单，现在从上游（erp）推入到 WMS 系统进行订单入库，入库流程下有三、四个环节，做完这些环节才等于入库成功，且少部分客户的环节是不一样的。
现在针对这一个流程，考虑实现自动化，目前遇到的难点如下：
1.接口自动化技术选型。目前考虑的是 python + pytest + request + allure
2.接口该怎么去分层，因为系统业务复杂，涉及到的接口、数据库验证、返回验证都比较多。目前想不到一个好的分层方案。目前是想拿 WMS 系统做起来看看具体的情况
希望各位大佬给几个建议
眯着眼推荐一波 MeterSphere
如果团队确实欠缺这方面的经验，可以先挑一个模块堆若干条用例出来，然后看哪些地方的代码可被复用，又或者哪些东西是希望做权限控制的（比如对测试工程师隐藏数据库配置信息等）。
这些事情做好，分层也就差不多了。
因为我们的业务有部分包含你描述的几个模块, 所以提几个模糊的建议:
- 先从单个接口开始做, 比如一个接口测试做成一个 func, 依赖的数据可以从数据库查询.
- 因为业务关联较大,承接关系较多, 所以可以在单接口的测试中做基于 Feature 的组合业务接口.
- pytest,unittest 之类的单测驱动可能不太适合, 建议自己写个简化的框架驱动, 然后对接口函数进行标签化/排序/依赖关系组合, 从而方便从 1-2 的组织的同时必须要另写代码.
对
H.Devin
回复
H.Devin
回复
WebUI 的, MobileUI 的, WinFormUI 的, 还有 API 的, 我们这块看到业务相对面积较大, 自动化涉及的业务也就较多.
还是那个意思,自动化是为业务服务的, 所以根据业务模式去设计测试脚本的代码架构, 好用的永远是契合业务高的.
根据业务流程来分呗，别想那么大，先整个完整的用例，用到什么就写什么，写出来后再优化数据分离、用例分离。