1.移动端测试的话我自己玩过 uiautomator2，后台的测试可以直接上 api 嘛？可以的话就用爬虫把。配合起来就是写对应的测试用例。优点的话就是眼前的问题能及时解决，缺点也很明显，相关内容有改变，测试用例不好维护
2.第二条的话想看看其他大佬有啥好的想法

人工测试的过程中，是人工在各端进行操作，然后进行人工验证。

做自动化测试也是一样，自动化测试也应该支持多种类型自动化的串联，如先做 web 端、然后 app 端，虽然 web 端、app 端的底层驱动技术不一致，但也是可以支持案例串联的。

我们现在实现的自动化测试中，也支持多个不同类型的 step，每个 step 可以是不同端的操作，第一个 step 是 web 端、那第二个也可以是 app 端，断言也支持自定义，甚至是自定义的外部脚本。

如某个案例：先发 A 系统的一个 http 接口，获取一个 url，在 url 中进行 web 自动化，然后通过 http 接口查询交易结果，最后使用自定义的 scprit（py，js 等) 连接数据库进行查询，做最后的数据检查。

如题：当在后台做相应操作前端会改变界面或数据
这种场景我觉得可以使用接口结合 UI 自动化的方式对功能进行测试。
分为三步：

首先，后台作为动作的发起方，先对后台进行测试：使用 WEB 自动化操作后台后，通过数据库对数据进行查询验证后台的操作是否成功
第二步是测试移动端前台：直接通过调用接口模拟后台操作，查看移动端前台页面或数据是否有改变
第三步是联合测试（纯模拟用户实际使用）：使用 web 自动化操作后台，并使用移动端自动化来验证前台是否正常确响应
单回答这个问题的话，是用这种分层的形式进行测试。

然后讨论实际应用中可能遇到的问题是：
如何管理这种串联形式的用例？
每测一个点都要三步感觉会不会用到的数据有些复杂？那我们把用例要用到的数据先用替代方式表现出来：
1.A1 A2
2.B1 B2
3.A1 B2（第三步用到的数据和前两步有重合）
并且由于每三步实际只测试了一个功能点，所以可以将 A1 A2 B1 B2 列为一条用例数据。
测试脚本只需要对对应位置的数据进行存取即可。

想问一下这类测试用例如果存在 ui 或者接口数据变动情况会在实际项目出现嘛？如果出现如何解决需要维护测试用例脚本这种问题呢？

数据变动很正常，变动就得维护脚本，这不应该算问题，应该算在自动化之初就考虑的成本

各个端有不同的 driver 去控制，简单的，脚本调用不同的 driver api 就可以了。完善一点，通过中心 server 来调控不同设备，让不同端作为设备上线到 server，脚本调用 server 的 api 来实现，甚至可以通过统一 API，来完成一套代码，不同平台使用。
atx2 基本就是这种思路。
题中的网页端和手机端的联动测试，选择好各个端的 driver，比如网页端用 selenium，手机端用 uiautomator2（这两种都是支持远程调用的，如果不支持，可以自己写端口转发），在一个脚本中调用两端的 api 即可

tips:然而，其实如果是单纯后台 + 客户端这样的场景，个人觉得是没必要花大价值去做联动测试的。分层测试即可，即保证 web 后台的 ui 自动化 + 接口测试，手机端的接口调用 +ui 自动化测试，这个是性价比最高的。经验告诉我，端数越多，维护成本，出错概览越高。联动测试我们用的比较多的，可能是音视频这一类

直接通过接口层自动化测试吧，参考 UI 自动化的 POM 模式，将各个平台的每个接口都封装成一个个的对象，你这种场景就是接口的组合验证了，直接进行接口层的调用以及校验应该就可以了吧。比如，我下面的例子：

我是来找高分答案的，中奖答案不会公布咩

用例与驱动层隔离，接口，web 和 app 统一封装成驱动层，再往上封装业务关键字

啥时候公布啊？或者用你们的解释权解释一下

方便请留一下联系方式或者添加 QQ540773674，方便我们发放 Q 币奖励哦

方便请留一下联系方式或者添加 QQ540773674，方便我们发放 Q 币奖励哦

觉得分层测试比较好。来找更好更详细的答案