只看这部分内容，感觉写得太细节了，也缺少成果说明，在现在 hc 紧张的大环境下没什么吸引力。写项目经历还是用下 star 法则吧。

不熟悉 locust ， @debugtalk 帮忙看下是不是参数化姿势问题？

收藏了，后面如果需要弄鸿蒙原生包的时候用得上。

get 到大家的意思了，就是帖子列表页屏蔽掉私人社团的帖子，避免出现看到帖子点进去却没权限看内容。

这个应该是之前遗漏的一个功能点，我加到我的 todo 里，五一抽空弄一下

这个是 android 平台，和 ios 的 WDA 没太大关系。 WD = Web Driver 。

日志挺齐全，先赞一个

先分享下解析日志的思路，便于你看懂下面说的东西：

1、首先，得先大概了解 appium 这个场景下的大致架构原理。以下这个是 appium 在使用 uiautomator2 模式下的最新架构图（出自官方 https://github.com/appium/appium-uiautomator2-server/wiki ，百度搜关键字 appium uiautomator2 ，也能找到相关文章说明）：

2、了解架构后，从 appium 日志开始出错的位置开始分析，了解出错的直接原因

3、从直接原因的日志继续往前看，看前面做了什么，和架构图里的这些组件模块的关系是什么。辅助看 logcat 日志找到一些 appium log 里找不到的安卓系统内部错误信息

然后我从第二步开始详细说下怎么分析：

• 日志出错位置

2022-04-27 03:18:24:008 [UiAutomator2] The instrumentation process cannot be initialized within 30000ms timeout. Make sure the application under test does not crash and investigate the logcat output. You could also try to increase the value of 'uiautomator2ServerLaunchTimeout' capability.

直接原因翻译过来就是：instrumentation 进程在 30 秒超时时限内未能完成初始化。请确认被测应用没有崩溃（这里有点误导，应该看 instrumentation 进程有没有崩溃）并查看 logcat 输出。你也可以通过 uiautomator2ServerLaunchTimeout 调大超时时间

• 往前看，看前面在做什么

2022-04-27 03:17:53:549 [WD Proxy] Matched '/status' to command name 'getStatus'
2022-04-27 03:17:53:554 [WD Proxy] Proxying [GET /status] to [GET http://127.0.0.1:8200/wd/hub/status] with no body
...
2022-04-27 03:18:23:998 [WD Proxy] Matched '/status' to command name 'getStatus'
2022-04-27 03:18:23:999 [WD Proxy] Proxying [GET /status] to [GET http://127.0.0.1:8200/wd/hub/status] with no body
2022-04-27 03:18:24:006 [WD Proxy] Got response with unknown status: {"errno":-111,"code":"ECONNREFUSED","syscall":"connect","address":"127.0.0.1","port":8200}

这段是在不断重试连接 http://127.0.0.1:8200/wd/hub/status 这个地址，为啥要连接这个地址呢？从架构图可以看到，有个 netty server ，实际就是在尝试连接这个 server 。因为只有这个 server 能连上，才有办法从 appium 服务端通过发信息给这个 server ，操作手机里的 app 。

2022-04-27 03:17:52:536 [UiAutomator2] Starting UIAutomator2 server 4.5.5
2022-04-27 03:17:52:537 [UiAutomator2] Using UIAutomator2 server from '/usr/local/lib/node_modules/appium/node_modules/appium-uiautomator2-server/apks/appium-uiautomator2-server-v4.5.5.apk' and test from '/usr/local/lib/node_modules/appium/node_modules/appium-uiautomator2-server/apks/appium-uiautomator2-server-debug-androidTest.apk'
2022-04-27 03:17:52:537 [UiAutomator2] Waiting up to 30000ms for UiAutomator2 to be online...
2022-04-27 03:17:52:538 [ADB] Creating ADB subprocess with args: ["-P",5037,"-s","emulator-5554","shell","am","instrument","-w","io.appium.uiautomator2.server.test/androidx.test.runner.AndroidJUnitRunner"]
2022-04-27 03:17:52:966 [Instrumentation] io.appium.uiautomator2.server.test.AppiumUiAutomator2Server:

这段挺清晰了，在启动 UIAutomator2 server ，并在启动完后等待 30 秒直到它在线。和上一段持续尝试连接能对上了。然后启动用的 adb 命令参数是 "-P",5037,"-s","emulator-5554","shell","am","instrument","-w","io.appium.uiautomator2.server.test/androidx.test.runner.AndroidJUnitRunner"

2022-04-27 03:17:52:238 [UiAutomator2] Performing shallow cleanup of automation leftovers
2022-04-27 03:17:52:251 [UiAutomator2] No obsolete sessions have been detected (Error: connect ECONNREFUSED 127.0.0.1:8200)
2022-04-27 03:17:52:252 [ADB] Running '/lib/android-sdk/platform-tools/adb -P 5037 -s emulator-5554 shell am force-stop io.appium.uiautomator2.server.test'

这段的关键语句是第一行的 Performing shallow cleanup of automation leftovers ，翻译过来就是 清理上一次自动化测试可能存在的遗留内容（有可能上一次是被手动中断的，所以开始前需要检测并恢复到下一步需要的初始状态，和我们自动化测试 setup 做的事情差不多）。实际做了啥？两个事情，一个是尝试连接 127.0.0.1:8200（结果是 ECONNREFUSED ，连不上），另一个是通过 am force-stop 杀掉 io.appium.uiautomator2.server.test 对应进程（这也是后面 logcat 里会存在 crash 这样的字眼的原因，在 crash 位置往上看就会看到是被 kill 掉了）

同时通过这段分析其实可以发现，带有 [ADB] 的是实际执行命令的信息，我们排查日志关键不是看命令细节，而是看意图，所以后续分析主要看带有 [UiAutomator2] 的

2022-04-27 03:17:48:173 [UiAutomator2] Checking whether app is actually present
...
2022-04-27 03:17:50:329 [UiAutomator2] Forwarding UiAutomator2 Server port 6790 to 8200
...
2022-04-27 03:17:50:551 [UiAutomator2] io.appium.uiautomator2.server installation state: sameVersionInstalled
...
2022-04-27 03:17:51:403 [UiAutomator2] Server packages are not going to be (re) installed
2022-04-27 03:17:51:406 [UiAutomator2] Waiting up to 30000ms for services to be available
...
2022-04-27 03:17:51:680 [UiAutomator2] Instrumentation target 'io.appium.uiautomator2.server.test/androidx.test.runner.AndroidJUnitRunner' is available

只看 [UiAutomator2]，相当清爽，我在末尾补上中文翻译方便查看

2022-04-27 03:17:48:173 [UiAutomator2] Checking whether app is actually present ——判断 app 是否存在
...
2022-04-27 03:17:50:329 [UiAutomator2] Forwarding UiAutomator2 Server port 6790 to 8200 ——把 server 的端口从6790转发8200（和网络请求地址端口号是 8200 对上了）
...
2022-04-27 03:17:50:551 [UiAutomator2] io.appium.uiautomator2.server installation state: sameVersionInstalled ——确认 io.appium.uiautomator2.server  的安装状态为：已安装同版本的应用
...
2022-04-27 03:17:51:403 [UiAutomator2] Server packages are not going to be (re) installed——得出结论：Server安装包不需要再安装
2022-04-27 03:17:51:406 [UiAutomator2] Waiting up to 30000ms for services to be available——等待30秒知道服务初始化完毕（因为之前有可能由于某些原因已经启动了应用，所以这里等上30秒保障之前启动的已经启动完毕）
...
2022-04-27 03:17:51:680 [UiAutomator2] Instrumentation target 'io.appium.uiautomator2.server.test/androidx.test.runner.AndroidJUnitRunner' is available——查到有 io.appium.uiautomator2.server.test/androidx.test.runner.AndroidJUnitRunner 的可用服务，和后面强制停掉服务对上号

• 看完 appium log ，结合看 logcat

logcat 因为混杂了所有系统信息，所以需要自己想办法捞和自己要查的东西有关的信息。这个过滤方法的核心就是：进程号。要找到进程号，先得找到进程名，搜索 io.appium.uiautomator2.server.test ，找到和它有关的启动信息

04-27 03:17:52.063 5053 5068 I TestRunner: started: startServer(io.appium.uiautomator2.server.test.AppiumUiAutomator2Server)

然后通过这个信息，找到进程号是 5053 ，线程号是 5068（不是高并发，线程号在这里用处不大，可以忽略）。然后找到所有 logcat 里的 5053 内容（推荐保存到文件后，cat + grep 快速过滤）

04-27 03:17:51.933 5053 5053 I art : Late-enabling -Xcheck:jni
04-27 03:17:51.934 5053 5053 W art : Unexpected CPU variant for X86 using defaults: x86
04-27 03:17:51.936 1698 1710 I ActivityManager: Start proc 5053:io.appium.uiautomator2.server/u0a81 for added application io.appium.uiautomator2.server
04-27 03:17:51.952 5053 5060 E art : Failed sending reply to debugger: Broken pipe
04-27 03:17:51.953 5053 5060 I art : Debugger is no longer active
04-27 03:17:51.953 5053 5060 I art : Starting a blocking GC Instrumentation
04-27 03:17:51.958 5053 5053 W System : ClassLoader referenced unknown path: /data/app/io.appium.uiautomator2.server.test-1/lib/x86
04-27 03:17:51.958 5053 5053 W System : ClassLoader referenced unknown path: /data/app/io.appium.uiautomator2.server-1/lib/x86
04-27 03:17:51.961 5053 5053 W System : ClassLoader referenced unknown path:
04-27 03:17:51.971 5053 5053 I MonitoringInstr: Instrumentation started!
04-27 03:17:51.971 5053 5053 I MonitoringInstr: Setting context classloader to 'dalvik.system.PathClassLoader[DexPathList[[zip file "/system/framework/android.test.runner.jar", zip file "/data/app/io.appium.uiautomator2.server.test-1/base.apk", zip file "/data/app/io.appium.uiautomator2.server-1/base.apk"],nativeLibraryDirectories=[/data/app/io.appium.uiautomator2.server.test-1/lib/x86, /data/app/io.appium.uiautomator2.server-1/lib/x86, /system/lib, /vendor/lib]]]', Original: 'dalvik.system.PathClassLoader[DexPathList[[zip file "/system/framework/android.test.runner.jar", zip file "/data/app/io.appium.uiautomator2.server.test-1/base.apk", zip file "/data/app/io.appium.uiautomator2.server-1/base.apk"],nativeLibraryDirectories=[/data/app/io.appium.uiautomator2.server.test-1/lib/x86, /data/app/io.appium.uiautomator2.server-1/lib/x86, /system/lib, /vendor/lib]]]'
04-27 03:17:51.973 5053 5053 I MonitoringInstr: No JSBridge.
04-27 03:17:51.975 5053 5068 I MonitoringInstr: Setting context classloader to 'dalvik.system.PathClassLoader[DexPathList[[zip file "/system/framework/android.test.runner.jar", zip file "/data/app/io.appium.uiautomator2.server.test-1/base.apk", zip file "/data/app/io.appium.uiautomator2.server-1/base.apk"],nativeLibraryDirectories=[/data/app/io.appium.uiautomator2.server.test-1/lib/x86, /data/app/io.appium.uiautomator2.server-1/lib/x86, /system/lib, /vendor/lib]]]', Original: 'dalvik.system.PathClassLoader[DexPathList[[zip file "/system/framework/android.test.runner.jar", zip file "/data/app/io.appium.uiautomator2.server.test-1/base.apk", zip file "/data/app/io.appium.uiautomator2.server-1/base.apk"],nativeLibraryDirectories=[/data/app/io.appium.uiautomator2.server.test-1/lib/x86, /data/app/io.appium.uiautomator2.server-1/lib/x86, /system/lib, /vendor/lib]]]'
04-27 03:17:51.979 5053 5068 I UsageTrackerFacilitator: Usage tracking enabled
04-27 03:17:51.979 5053 5068 I TestRequestBuilder: Scanning classpath to find tests in paths [/data/app/io.appium.uiautomator2.server.test-1/base.apk]
04-27 03:17:52.060 5053 5068 D TestExecutor: Adding listener androidx.test.internal.runner.listener.LogRunListener
04-27 03:17:52.060 5053 5068 D TestExecutor: Adding listener androidx.test.internal.runner.listener.InstrumentationResultPrinter
04-27 03:17:52.060 5053 5068 D TestExecutor: Adding listener androidx.test.internal.runner.listener.ActivityFinisherRunListener
04-27 03:17:52.061 5053 5068 I TestRunner: run started: 1 tests
04-27 03:17:52.063 5053 5068 I TestRunner: started: startServer(io.appium.uiautomator2.server.test.AppiumUiAutomator2Server)
04-27 03:17:52.065 5053 5053 I MonitoringInstr: Activities that are still in CREATED to STOPPED: 0
04-27 03:17:52.067 5053 5068 I appium : [AppiumUiAutomator2Server] Starting Server
04-27 03:17:53.072 5053 5068 I appium : AndroidServer created on port 6790
04-27 03:17:53.073 5053 5068 I appium : io.appium.uiautomator2.server started:
04-27 03:17:53.084 5053 5070 I appium : Started UiAutomator2

从最末尾的几条信息看，服务是正常启动了的，没有任何崩溃或者报错相关信息。注意这里有个暗坑，可能手机和电脑时间没达到秒级对齐，所以两边的启动时间稍微有点对不上。

结论

从 logcat 日志看，虽然 appium server 30 秒内都没有能访问通 /status 接口，但也没有明显的崩溃或者退出的错误信息。说明可能两种原因：

1、启动太慢了，30 秒内启动不完。
2、其实已经崩溃了，只是 logcat 没采集到

排查方法也不难，按照 appium 前面指引调大 server 检测的超时时间，同时弄个简单的脚本每秒通过 adb 命令（注意不是网络接口）检测 server 进程是否存活（排除可能性 2）。如果改大后，直到超时进程还存活的话，那继续改大超时；如果已经不存活，从 logcat 里尝试捞崩溃日志再分析。

我解答一下吧：

私人社团的本意，是用于给一些组织借助社区作为自己的内部资料记录、交流，同时内容不大想公开给所有人用。比如我们管理员有个内部站务的私人社团，用于记录一些不大适合公开的内部事务。（其实主要是这个是 rubychina 加的功能，我们拿过来成本不高，且又确实有使用场景，所以就拿过来了，哈哈）

至于你提的几个问题：

为什么在私人社团里发的问题，我一个社团外部的人能看到？

能否发下具体的地址及看到入口的截图？这应该是个 bug 。去年年底关站期间，权限系统做了比较大变更，可能引起了这方面的问题。

在什么情况下才需要往私人社团里发问题求解答？

这个属于发帖人自己想法，我也给不了答案。。。

一个私人社团大几百号上千人，“私人” 的意义在哪里？跟整个社区有区别吗？

私人社团的入团是需要社团自己的管理员审核的，内容查看也只有社团内的人可见，这个是 “私人” 所在。至于社团规模，这个我们交由社团管理员自己来控制，从社区管理的角度，现阶段没有太大的控制单个社团人数规模的必要性。而且相比社区 6w 多用户，一个社团几百上千人并不算多。

不知道。。。等楼主本人来说清楚吧。

这个上下文实在太少，团队现状也不知道，不知道怎么回答好。。。可以提供更多信息么？

目前就是卡在，linux 服务器里安装安卓系统，linux 中 adb 连接安卓设备，然后执行 python 脚本，运行 app 自动化，后续结合 Jenkins 集成

额，我语文不大好，你意思是说这么多地方卡住？可以分享下你自己通过什么方式找，找到了什么文章，然后你现在有什么问题是这些文章都解答不了的？

• linux 服务器里安装安卓系统

这个只能弄虚拟机吧，毕竟两个都是完整的操作系统。不过 x86 平台上高性能的 android 系统基本都是 x86 指令集的，用 arm 指令集的因为要额外转译性能都一般，而且目前手机上的系统都有各种自家的二次开发，和原版的有一定差异，所以这么跑出来的结果可信度有限，比较少人这么做。

看起来是个技术优化需求，从需求看应该是 redis 和数据库数据结构不变的情况下，优化中间的定时任务性能。所以还是最好去看下代码确认下逻辑是否一致，纯黑盒难保会有遗漏。

如果是我测，我会这么做：
1、先了解清楚原来老的定时任务，具体做了什么转换。这个了解相比问开发，更需要自己也去看看相关代码，代码里才有最充分的细节
2、然后 review 新的定时任务，转换逻辑和老代码是否一致
3、逻辑 review OK 后，找一些 redis 数据，分别交给新老定时任务去处理， diff 对比下输出值有没有差异，同时可以看看性能是否有提升
4、最后结合整个业务去过一下代驾功能里和这个定时任务有关的用例，确认整体功能正常
5、最后确认下预计的上线切换方案（最稳的是新的任务先不要写到正式表，先写到一个临时表，然后观察一段时间确认写入的内容和老任务一样，再关掉老任务，新任务切换到正式表），做一下演练。

除了找 bug，测试团队是不是能给公司的业务带来更多贡献？比如帮助整个团队的品质得到进一步的提升：“品质 “要比” 缺陷 “的范围大很多。

这点很认可，要扩大上级对测试价值的认知，如果总是觉得测试只是手工活点点点，那后面会处处受限。

这个是什么时候的文章？好像现在很少说测试基建要花大精力去弄浏览器兼容性了。

挺有意思的用法，想了解下有实际落地的效果情况吗，可以分享下不？

看楼主的示例，一个重置密码的流程画起来好像还是有点复杂度的，而且这只是一个实际业务中来说比较简单的逻辑了，复杂逻辑会不会画出来的成本更高？

下载地址 是个纯文字而不是链接，是复制的时候故意去掉的不？

另外，你这个访问地址我试了下公网无法访问，应该是只有你们内网可访问的，建议可以去掉，只分享下思路什么的。

PS：建议楼主前端可以应用下一些样式组件，比如 bootstrap ，更进一步建议了解下 vue + element ui 。现在除了用例管理用 agileTC 颜值还不错外，其他界面颜值有点一言难尽，会严重影响第一印象分。

没用过 locust ，只说明下我的理解，供参考：

一般压测工具只要没有 fail 或者报错，都是请求成功。看你第二个请求的 response 里面有 num_requests 表示发出请求数， num_failures 表示请求失败数，看这个就可以看出来了。

每个请求都记录详细的 response 信息，会很消耗性能，导致压测工具压力上不去，所以一般压测工具默认是直接通过 http status 判断成功（2xx/3xx）/失败（4xx/5xx/请求超时等异常），有别的需要的话得额外写断言。

有些业务的开发人员都不需要测试人员的介入 ... 好多业务不需要测试介入，测试人员对业务就不能进行深入的了解。测试人员的出路在哪呢？或者说测试人员要做些什么呢？

没太看懂，到底是少量开发人员不需要介入，还是大部分？

另外，由于开发同学需要深入很多细节，所以在整体系统的全局视角上一般不如测试，比较明显的就是除了自己负责的模块，其他模块基本只了解皮毛，所以导致开发在做整体系统的集成测试方面不如测试考虑全面（如果测试连这个都比不过开发，那真得好好反思下了）。测试可以从整体系统集成这个方面去看，整体系统质量如何。还可以进一步看哪些地方质量风险大，怎么去做 “预防”，而不仅仅是设计用例和执行测试做 “验证” 。

从楼主的设计初衷看，应该是主要针对相对复杂度不那么高的项目快速建立自动化用例用。从这个角度来看，建议楼主可以针对这个方向进一步优化，比如加上一些自动生成用例或者说录制生成基础用例的手段？

低代码平台一般初衷是相对代码经验弱一些的同学，或者通过高度的封装极大降低代码量。看楼主的思路，应该属于前者。对于代码经验弱的同学来说，自动生成/录制生成会比在界面拖拉拽写用例吸引力更大。如果不写代码但还得要求有编程思想，容易不上不下，写代码的人不喜欢用，不怎么写代码的人也觉得写起来不如自己直接执行方便。

额，为啥要遍历多个页面呢？你能先说明下，你到底要测试的是前端的什么性能不？

这几个方向的目的是有一定差异的

资源加载速度（lighthouse）：基本目标是尽可能有效整合资源/懒加载非立即需要的资源，在网速不变的情况下，减少加载网页所需的总网络请求数（浏览器内部并行网络请求是有限制的，资源太多会导致要等前面加载完才有机会开始加载，减慢加载速度）。常用举措有资源整合和资源拆分（弄懒加载用）

不同地理位置的网络加载速度（各种测速类网站）：基本目标就是加快网速，常用举措是增加 CDN 节点。

开始加载后白屏时间：这个实际是用户体验优化了。在前两者已经没有可优化的点的时候，尽量降低白屏时间。常用举措有骨架屏、懒加载等。

运行时 FPS 等性能数据：这个更多是一个界面流畅度问题的 profile 工具，即通过采集和性能及运行内容有关的数据，辅助定位性能问题。常见使用场景是界面卡顿时定位卡顿原因用。

请问，有找到合适的 android 10 以上监控 app 单独流量的方案了吗？

google 查了下，有个说的比较全的文章，但里面对应 android 10 以上的方案要不得 root ，要不得用 android 应用通过 android api 获取，没有直接通过 adb 获取的方式：https://android.stackexchange.com/questions/203868/how-to-view-network-traffic-requested-by-a-specific-app/204022#204022

你这里的安全问题应该是暴露了敏感的内部错误信息吧。解决方法应该是线上环境通过配置 AOP ，在最后返回内容前换用统一的错误信息（比如常见的 Internal Error ）避免直接返回原始 exception 信息。

接口入参类型不一致只是引起这个问题的其中一种原因，如果下一次这个入参不是来自于接口，而是来自于数据库数据或者别的输入，你光限制接口参数长度就没法防范了，所以这个问题不应该通过限制接口参数长度来解决，成本高且无法彻底解决问题。

前端性能有好几个细分领域，常见的有资源加载速度（lighthouse）、不同地理位置的网络加载速度（各种测速类网站）、开始加载后白屏时间（除了录屏外不大了解还有什么工具）、运行时 FPS 等性能数据（chrome 浏览器的 Performance 选项卡里就有）。

从楼主描述的意思看，应该是最后一个？

前端开发也是比较新的同事，里面很多堆叠的逻辑也不太清楚；

这种情况下做重构，要非常小心。不清楚逻辑就做重构，是重构容易出问题的原因之一。现在你们处于测试没法把场景列得足够全，开发也没有对原有逻辑梳理得十分清晰的就动手重构的状态，重构的两个大坑都踩到了。。。

建议：
1、看这次重构是不是非常必要，如果不是，那就先 hold 一下，或者重新梳理逻辑后再重构吧。
2、如果代码已经上线甚至基于它已经做了一部分功能，不好回滚，那就找熟悉这块逻辑的同事（不限于测试，包括产品等都可以拉过来）一起过来补充更多的场景，以及做好线上用户反馈问题后及时响应的机制。

1、单元测试的测试对象一般是某个组件或者某个函数，目标是保障这个组件/函数满足要求没问题。由于单测一般会把输入都通过类似 mock 的手段进行控制，所以是可以模拟出几乎全部你能想得到的输入（当然前提是你能想到）。不过如果说只是要用到 mock 手段方便你模拟线上数据的多样性，那你只需要一个接口 mock 服务就可以了，不需要特意去弄单元测试。

2、不知道你在测这个重构项目时，对重构的技术方案、改动范围有多少了解？有没有对现有缺陷做缺陷分析，看主要出现的原因是什么？每项测试都有自己擅长的点和不足的点，建议先找到你现在问题的原因，再考虑用什么解决方案。你说的线上数据多样线下难以覆盖，只是一个直接原因。为啥重构前线上同样多样的数据不会出问题，重构后会出问题呢？是不是重构的时候有些地方本身就没考虑完善导致逻辑遗漏，或者重构的人对以前代码逻辑不够熟悉，想当然去写写出了不正确的逻辑？这些才是根本原因。

个人经验，要控制好重构类项目的风险，必须从技术方案开始入手，把重构拆碎成多次，控制每次重构的边界（可以理解为改动范围），每重构完成一部分就测试并上线一部分，就算出问题也可以在这次有限的改动范围内快速找到原因并修复。否则一次大重构非常容易变成重写，影响范围大到几乎整个系统重测，开发测试都得加班加点，且风险难以控制。

这个看具体是什么样的异常吧。

如果是本身业务逻辑中可能存在的异常（比如查询结果查不到结果之类的），那肯定应该有合适的处理。至于 NPE 这类错误，可以提议让开发同学学一下阿里代码规范，里面就有一条 防止NPE，是程序员的基本修养 。

至于是否暴露具体提示信息这个，线上可以通过配置统一 500 返回内容来避免堆栈信息暴露给用户，确认下有没有配置就好了，测试环境暴露倒问题不大甚至有助于排查。

不过一个对 NPE 都不在意的开发团队，你要求接口做得很完善，很难。如果不是专门测服务端的话，建议接口保障好各个可能存在的业务场景都能处理好就差不多了，至于那些尽善尽美的东西，不建议一上来就以规范、缺陷的形式来走，容易冲突。先做一些文化宣贯 + 线上因为接口没处理好出现的故障分析，让开发逐步知道这块没做好会有什么危害，对质量逐步有更高要求，再推进到规范，会比较好。