你真是全凭 GPT 来回答啊

图不错

着啥急，问开发啊，找 ETL 啊
不能动数据还不能复制下啦，联系要下 UAT 的数据

没必要，跨度太大而且给公司带来无收益的成本
你可以拿现有的开源产品逐步升级，先让领导看到效果，才能有后续

我的建议是：步子迈大了容易扯着 D

1.平台》框架》脚本集》脚本

你可以选择一步到位，也可以选择期望的逐步降级，先实现再升级

2.怎么校验？

曾经也做过一小段时间的银行业务测试，最大的感慨就是 “SQL 是真 TM 的长！”
当时也有想过自动化校验该怎么实现？
既然是校验数据，那数据必然是经过了一系列的处理，或者数据清洗
那脚本是不是要比对着该业务处理逻辑来对入参同样做处理，最后以脚本结果为期望去比对业务结果

那该怎么保证你的处理逻辑没有 bug 呢？

又该怎么能保证你的逻辑实现能力是强于 ETL 的呢？

如果不能保证，那期望就失去了价值，比对也失去了意义，做的一切也就是无用功

3.你的业务是否真的适合做自动化？

自动化的核心是 “重复”，而你描述的业务给我的印象是：漫长、复杂
这点我认为你可以实际的去梳理下业务线，确定下是不是真的适合脚本化，确定下脚本的维护成本和性价比

最后给你个建议：

遇事不决，可问 5W2H

市场越冷 差距越大！

是 PC 端软件的 UI 自动化吗？

总结：转行试水和买房入坑

内容如何不予评论，界面设计的优化空间很大，至少我是不太想用这个样式，记得之前有个开源的 Rabbit 平台设计的前端就很棒

过两年你会发现大哥生了个大哥
“一声大哥，一生大哥” 其实是俩大哥

祥子到死还是认为活的不好是因为自己不够努力

找到个勉强度日的，大佬有推荐？

曾记得在哪看到对 gpt 回复逻辑的解释就是：
按字拼接，以前一字词来搜索统计下一字词的概率，取较大概率字词来续写，以此类推
也可以理解为一字一判断，当某个字后续的分支路线不符合你要求时，他会换到另一条分支来回复你

工作只是为了活着，都不容易啊

如果是一条流程链的接口用例我建议单脚本 class 多 case，一接口一 case

首次见到第二种写法，我最低也是一个 case 一个点，多接口的就包含在一个 class 内
第二种这样能区分断言吗？

又是一个明珠

我个人认为确认测试和其他三类测试阶段不是一个层级的阶段
验收测试是可以很清晰的确认其在测试周期中的位置，而 “确认” 是可以贯穿整个周期的，单元测试时可以针对代码块做确认，集成阶段可以对多模块做确认，系统阶段/验收阶段也是如此，甚至做性能等其他类型测试时也可以将其部分流程视为确认测试，而它们之间的区别只是确认的范围和内容不同

其实歧义点并不在选项，而在问题本身。这题的点是在测试结束的顺序，而不是测试生命周期的进行顺序，那么测试结束的定义是什么？” 顺序 “的定义又是什么？
从测试阶段的角度来看，以下是一般情况下测试结束的正确顺序：

下午是我的问题及回答：
Q:从测试阶段角度，测试结束的正确顺序是什么
A：

1. 单元测试阶段：在软件开发过程中，单元测试通常是最早进行的测试阶段。在这个阶段，测试人员会针对代码的最小单元（如函数、方法）编写和执行测试用例。测试结束的顺序包括：

   • 编写单元测试用例；
   • 执行单元测试用例；
   • 分析和修复失败的用例；
   • 评估单元测试覆盖率；
   • 汇总单元测试结果。

2. 集成测试阶段：在完成单元测试后，进行集成测试以验证不同模块之间的交互和协作。测试结束的顺序包括：

   • 编写集成测试用例；
   • 执行集成测试用例；
   • 分析和修复失败的用例；
   • 评估集成测试覆盖率；
   • 汇总集成测试结果。

3. 系统测试阶段：在完成集成测试后，进行系统测试以验证整个系统的功能和性能。测试结束的顺序包括：

   • 编写系统测试用例；
   • 执行系统测试用例；
   • 分析和修复失败的用例；
   • 评估系统测试覆盖率；
   • 汇总系统测试结果。

4. 验收测试阶段：在完成系统测试后，进行验收测试以验证系统是否满足用户需求和预期。测试结束的顺序包括：

   • 编写验收测试用例；
   • 执行验收测试用例；
   • 分析和修复失败的用例；
   • 评估验收测试覆盖率；
   • 汇总验收测试结果。 需要注意的是，以上测试阶段的顺序是一种常见的流程，但实际情况可能因项目和组织而有所不同。在实际测试过程中，可能会根据具体情况进行调整和适应。

综上所述，普世的测试顺序是单元》集成》系统》验收，而下一阶段的开始也是由上一阶段的结束来承接的，所以选 A 绝对是没有问题的，如果非要说答案是 BCD，我认为这题就不该出现，一切自圆其说即可

这 Base 换到我这还勉强可以接受。广州也垮成这样不当人子的程度啦？

Base 是个很重要的影响因子

前面的回复都有了很明显的倾向，所以我想补充的是：
考公不等于公务员，考上了才是
而是假使你明年 31 岁就考上， 基本在组织内也不会有啥进一步的发展了，可能毕生的目标就变成了科长
年限存于万物之间

首先我没做过 CV 类验证，但是我猜想这里肯定会有前置工具可圈定比对的目标区域

看有没有兼容或者配套的 driver 了

面向 ChatGpt 编程