例如，我现在有一个功能。
点击查看线路，会调用两个接口，A 接口叫查询站点，B 接口叫查询用户信息。这两个接口没有关联，只是会并列显示而已。
那我的自动化测试用例应该怎么写呢？
我之前的设计方法是这样的。将两个接口拎出来，每个接口创建一个 java 文件，然后对这个接口的参数做各种校验。
但是今天被人说我这样设计不对，应该按照功能设计。
可是如果按照功能设计，那我就要建立一个查询线路.java 文件，里面放两个类，每个类表示一个接口。这样真的好吗
a, b 是前置接口，你主要校验的功能是查看线路功能，所以 ab 是前置条件，触发后提起对应需要参数，再调用查看线路设计不同场景的 case，进行校验
高内聚低耦合。分开肯定是好的。用你分开的 java 类再拼个功能类不就可以了。甚至，你抽象一个工厂，通过工厂来组装业务（拼接口的类），测试代码只依赖工厂。。。。再抽几个 java 的 interface 类，主要定义测试行为，业务接口的 java 实现这些个 interface
我觉得分单接口测试和流程测试吧，单接口那就按照常规接口的方式设计，流程的那就要按使用流程根据接口的上下文串起来设计流程用例，也就是场景用例吧。
两种类型的用例都需要 特别是系统本身业务流程复杂的话 流程性的用例对于回归来说更重要
如果有合适的业务场景能把俩接口串联起来，一般串起来的接口都是一个写库或者改库的接口 + 一个查询的接口，你这俩查询的放一起意义不大，不如分开呢，俩查询的接口最好上游接上创建或者更改数据的接口
接口解耦，做单接口自动化，另外会新建业务用例集成，该集合用例用带有多个接口的业务流 case，里面的代码就是引用单接口用例
从工程化角度来说，就应该区分原子操作和组合操作。
在这个业务场景，查询信息和查询站点我理解就是一个原子业务操作，无法再继续下拆，所以它们肯定要分开写。两者代码一定要分开，无论是定义为两个不同方法、或者两个不同类，甚至是两个不同代码文件（具体看整个自动化项目别人怎么写，就顺着大家的风格去搞）。
最后在测试用例层面去组合两个原子操作，分别进行校验。这样一来，原子粒度的操作区分开了很容易找到并维护，业务功能层面的一个用例通过组装可读更高（可能十行以内代码量，一行代码调用封装好的查询信息，一行代码调用封装好的查询站点，然后分别校验）；而不是在一个用例里堆砌一堆 “请求业务接口，拿到返回数据，拆分数据校验” 这类和抽象的测试用例不直接相关的底层代码。
测试用例文件里，写为两个用例，使用参数化方式实现
基本都是，写单接口，流程测试的话，就把他们调用拼接起来