要监控到细致程度的话，必然需要比较高的权限：

1. 要监控系统数据，需要数据库权限 2.要监控服务器状态，需要服务器权限

在线上监控用到这些权限，从安全角度，测试能把控这种风险吗？

看你的例子，只能说贵公司处分很严格，但是流程有点儿戏。
例如问题 2，在正式发布 APP 之前不需要测试吗？ 而且是测试 leader 被炒了，难道是他同意在后台 API 没上线的时候上线的？

提高效率：

1. 提高执行效率，该上的自动化手段尽快加上，比如接口，UI 2.提高测试覆盖效率：如何在有限时间里做到尽量精准的测试。 参考上面的答案，diff，代码变更分析等。
2. 提高测试覆盖面和争取起码足够的测试时间：把时间紧迫造成的风险及早提出。

你是要传这个文件的路径，还是传文件的内容呢？
要不你把 open 去掉，直接传文件路径试试

换根好点的数据线吧

做 SDK 就是要做支付平台和商户间的桥梁，上面这些都是要考虑的。
笼统？ 你的问题两点，我给你说了八点啊大哥

第三方支付的流程一般都是：

1. 商户发起新订单，即用户在前端点击购买
2. 支付平台生成订单号并返回订单号，支付金额（可能涉及汇率换算）等信息。 3.引导用户到对应的支付界面。这部分通常是支付平台提供的。 4.用户完成支付，支付平台进行校验。
3. 支付平台讲支付结果返回商户。 6.商户根据支付结果进行校验并进行发货处理。

作为商户方要留意：

1. 是否支付成功，要以支付平台的返回为准。所以最好是 Server to Server 的通信，并且加上 IP 白名单过滤。

2. 做好支付的校验，一般支付平台会提供校验方式，注意在服务器端处理和保密。

3.建议增加二次校验，即支付平台返回一个支付结果回调一样，再主动到对方校验一次。

4.做好重复性校验，即同一笔订单不要重复发货。

5.做好商品和订单、支付金额的校验，防止收到小额商品的金额，发了大额商品的货。

6.支付平台一般会有沙盒环境，注意要做好测试订单的区分和控制，防止被测试订单刷单。

7.做好定时的对账处理，遇到异常订单可以及时止损。

8.做好监控，如果用户频繁购买或大额购买，可能是异常行为。

解决 chrome 下的跨域问题：
在 cypress.json 中添加：

"chromeWebSecurity": false

建议隐私信息要打码

你的图都挂了

除非能找到接口正式下线的批准，否则删掉是很大风险的；
另一个层面，接口即使不用了，对应的代码应该还是有参考价值的，一般也没有删掉的必要

几乎不用？ 那假如删了之后发现还有在用怎么办？
覆盖率会比功能稳定更重要吗？

应该是没有重跑所有用例。
如果要改，你就把这个 执行 按钮绑定的方法，改成和详情页 重跑全部用例 按钮绑定的方法一样就可以了，具体的方法你可以右键属性查看；修改的话，应该是在 test_suite.js 这个文件里

那我猜测你的 import 相对路径不对，少了 app_auto_run 这个层级，你加上试试

你截图里看不到 adr 这个目录，是路径不对吗？ 比如试下从项目根目录开始引入？

你直接在代码里调用第三方就可以了，然后把这部分封装为一个关键字

建议你可以试下这么改：把识别的过程封装为一个关键字，然后在需要的时候调用这个方法进行识别。
具体怎么封装新的关键字，可以看下上面正文里的说明

有个问题啊，如果元素没找到，timeout 就减一秒。这里是不是没考虑找元素 find element 方法执行的耗时？

尝试过沟通吗？
如果是竞聘，可以问一下自己落选的理由，自己有什么不足。

从你的描述，对方管理的人员多，这在领导眼中是很重要的，毕竟部门合并，除非你的能力比对方强很多，或者对方能力离预期差很远，不然稳定是最好的选择。

他意思是第二条用例要紧接着第一条用例后面才能执行，也就是第二条用例依赖于第一条用例

execute shell 里的路径不用变； 下面 post action 里的 report 把 workspace 去掉

不用加 workspace 的参数

env: sh: Not a directory

你的日志里是说这个目录不存在，你最好检查一下对应的两个目录，一个 result,一个 report

env: sh: Not a directory

你的日志里是说这个目录不存在，你最好检查一下对应的两个目录，一个 result,一个 report

签名方法是根据你要测的接口来定的，你要拿到对应的接口文档或许找开发要对应的签名算法才能改