获得推荐和 GVP 还不太一样，GVP 要求更高，但也值得鼓励！
GVP 要求如下

基础设施跟得上的话，可以考虑手自一体，手工用例就是自动化用例，以关键字驱动方式运行，避免重复劳动。

之前有在 MTSC 上分享过我们的实践，希望能有启发/

我们用禅道管理用例。
歪个楼：楼主考虑过手自一体化吗？手工用例也是自动化用例。
一系列问题：手工用例是不是资产？这些用例最多运行过多少次？超过 2 次的比例有多少？
如果用例步骤类似这种和协议强相关的话，要不要考虑直接做自动化呢？用自动化来建设功能

一般提到自动化，先考虑分层，做 UI 还是接口？或者两者都做
UI APP 好像有个 appium，但我不是搞这个的，不太清楚，web 端的可以考虑 selenium、playwrigt、cypress
接口自动化，也有平台/脚本两种玩法，平台可以试试 MeterSphere，开源版就满足需求了，脚本的话就是自己用一些 http 的请求库，以代码方式组织用例

有一种情况叫做，我不知道别人不知道。比如您这里的：“仪表盘用的官网模板（截图里面的 json 文件）”，我现在想帮您解决问题的话，您是希望我从官网重新下载一份，完整复现一下吗？您作为问题提出方，是否有义务提供更多的信息呢？

发挥独特价值

让我们先猜猜您是如何配置的

啥叫用例覆盖率？用例覆盖了多少功能？还是用例覆盖了多少代码？如果单论代码覆盖，行覆盖，分支覆盖，MCDC 覆盖分别怎么样？怎么采集？回到用例覆盖的功能，什么才能算用例覆盖了功能？是正向都写了，还是逆向也写了，异常考虑全了没？进一步的，调用链路覆盖情况怎么样？光覆盖的指标都多了去了。。。，在考虑个执行效率，执行周期，问题发现频率，误报率等等。。。。

因为回帖格式默认是 markdown，星号是特殊标记格式。。。

ansible 它不香嘛

极客时间系列课程，钻进去学，是有收获的

有些产品形态必须要写代码才能测

确实是优秀团队的能做出来的理想情况了，给您和您的团队点赞

感谢陈老师的回复，我仍然关注一些具体数据，具体疑问如下：
1.“您所在团队迭代周期中，自动化测试用例调试编写的时间在总测试时间的占比是多少？” 您回复说 “在一个迭代内基本上一天搞定”，并没有直接回复比例，您所在团队一个迭代周期是多久？2 周吗？所以我关注占比，想看看能力优秀的团队做自动化到底会花费多少项目资源，我们目前距离优秀团队还有多少差距。
2.如果有问题立刻就解决，为什么通过率会不好算呢？难道每次执行都会有不通过的用例吗？连续五次执行失败会进入修复库，这种需要修复的用例的平均修复时间大概是多久呢（从进入修复库到修复完成）？
3.咱们的自动化执行频率又是如何呢？每次全量执行，耗时大概多久呢？
4.您所在团队的自动化用例是否考虑异常场景？如考虑，异常场景会考虑到什么程度？
盼望老师的解答。

感谢老师的解答，我这边也和测试团队一起做了多年的自动化测试，感触颇深，因此还有些问题想继续和老师探讨:
1.关于 1 自动化跟不上版本进度的问题，您所在团队迭代周期中，自动化测试用例调试编写的时间在总测试时间的占比是多少？写不写手工用例？写的手工用例能否直接转为自动化用例？
2.关于通过率，如果自动化的通过率/稳定性堪忧，如何能让人信服自动化的测试结果呢？所以我才问您所在团队的自动化通过率是多少。
3.对于一次非 100% 通过的自动化测试，这次结果怎么算？那些没有通过的用例，又是怎么处理的呢？是要把这些用例改对，还是认为是误报？
4.自动化测试发现过缺陷吗？发现缺陷的频率大概有多高？
5.咱这边接口串联场景引用接口数量的中位数大概为多少？最大为多少？
盼望您的具体回答，最好能列举具体示例，少些 “政治正确、套路正确” 的表述

有几个问题：1.自动化测试建设的进度跟不上版本发版的进度，怎么办？2.要做动态数据的自动化吗？对应的断言校验又要怎么处理呢？3.陈老师这边接口自动化建设的规模如何，效果如何，每次执行通过率如何，不通过的都是什么原因呢？

找几家商业的工具，先听他们的售前团队给你讲一讲，就清楚个大概了

如题

我们的做法：id 使用 bigint 作为主键，由雪花算法生成，提供 order 字段用于排序，初始值 65535，下一个是 2*65535，以此类推，用例调整顺序，新顺序的 order 值=（前一个用例的 order+ 后一个用例的 order）/2，这样在较大的有限次移动顺序内，不会把 order 值耗尽，之后，每晚凌晨三点，对 order 字段重排序，重新按照 65535,2*65535 等等重新排序，以确保给之后的操作留出空间

不如问问 AI

“判断 getter/setter 是否为简单的返回和赋值操作。” 这段部分对我还挺有用的，感谢分享

为啥感觉你这一段看着好像互联网黑话 ，没有恶意，能展开详细讲讲嘛，比如 沉淀到流量池，数据血缘，沉淀出知识图谱，代码大模型的能力加持（用的啥模型？啥部署方式呢），

我们做精准测试，不在于衡量些什么，在于能给开发和测试团队提供些什么信息，主要精力是奔着变动影响去的

先说题外话：
instrumentation 有控制仪器的含义，instrumentation 也是 javaagent 机制当中两个入口 premain 和 agentmain 函数中，由 jvm 提供的操作句柄，通过他可以设置自定义的类字节码转换器，从而实现对代码的插桩，但这并不是 inst 的全部，具体不在展开

再聊聊一些个人观点
1.关于精准测试平台的作用，我们现在是开发做一份变动影响分析，测试做一份变动影响分析，精准测试平台再根据规则算出来一份，三份互相查漏补缺，从而努力达成 “尽量把变动的影响分析全了” 的这个目标
2.为了实现上述的目标，精准测试平台需要存储和计算，这就要求了一定的代码能力，产品思维，和对技术框架，业务规则甚至软件测试本质的洞察，是需要有一定的积累才能进行一些尝试的东西
3.采用注入 skywalking 等遵循 OpenTracingAPI 这样的全链路监控工具固然好，但也不是所有公司的产品都是 Java 微服务的形式，也有单体，也有 C/C++ 的服务，有时候，应用内调用链也是关注的一部分，在此目的上，做代码调用链路分析这个目标其实并不冲突，并且，代码调用链路分析这个事儿，本身并不复杂，就是个会者不难难者不会的问题