• 不要轻易的否认自己,也不要轻易被别人改变自己。这是我昨天看的故事书里写的,也送给你
    不要轻易的踏上一条不熟悉的道路,也许那只是一条独木桥

  • 所以优先级是拿来干嘛的?你有空的话可以把全部功能过三遍,没空的话让你过一遍你都过不了

  • 02:24 还在操作帖子,老前辈要注意休息啊

  • 你自己看看你写的,除了你们组的谁能看懂实际代表的概念
    线上 bug 多少算少:0 肯定算,但是很难做到
    线上 bug 多少很难只用数字来计算,如果你出现了最高级别的 bug,那 1 个也是多的;如果你都是非功能性 bug,那一年几十个也不算多
    给个比较宽泛的参考就是无重大问题出现,功能性问题小于 10,非功能性问题不重要
    ps:这里的问题严重程度也要充分考虑对客户的影响程度

  • 你真是全凭 GPT 来回答啊😂

  • 尝试说下自动化测试 at 2024年01月17日

    图不错

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

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

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

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

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

    2.怎么校验?

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

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

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

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

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

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

    最后给你个建议:

    遇事不决,可问 5W2H

  • 市场越冷 差距越大!

  • 是 PC 端软件的 UI 自动化吗?

  • 花菜】我的 2023 年终总结 at 2024年01月15日

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

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

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

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

  • 找到个勉强度日的,大佬有推荐?

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

  • 做测试的最后一年 at 2024年01月10日

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

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

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

  • 又是一个明珠

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

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

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

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

      • 编写单元测试用例;
      • 执行单元测试用例;
      • 分析和修复失败的用例;
      • 评估单元测试覆盖率;
      • 汇总单元测试结果。
    2. 集成测试阶段:在完成单元测试后,进行集成测试以验证不同模块之间的交互和协作。测试结束的顺序包括:

      • 编写集成测试用例;
      • 执行集成测试用例;
      • 分析和修复失败的用例;
      • 评估集成测试覆盖率;
      • 汇总集成测试结果。
    3. 系统测试阶段:在完成集成测试后,进行系统测试以验证整个系统的功能和性能。测试结束的顺序包括:

      • 编写系统测试用例;
      • 执行系统测试用例;
      • 分析和修复失败的用例;
      • 评估系统测试覆盖率;
      • 汇总系统测试结果。
    4. 验收测试阶段:在完成系统测试后,进行验收测试以验证系统是否满足用户需求和预期。测试结束的顺序包括:

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

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

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

  • Base 是个很重要的影响因子