• 现在这类非常流行的真实流量复制类的测试,安全、隐私管控是个大坑。悄悄做也就罢了,公共平台宣传不怕给公司惹麻烦嘛

  • 二者应该是相辅相成的。技术服务于业务。技术能力弱也从侧面反映业务并没有到深水区。浅水区很熟不代表能进深水区
    另外所谓的框架、平台是技术部分的浅水区,实际价值也不大

  • 好像有些货,但是要么倒不出要么是不想倒出

  • Jenkins 上需要配置工程路径到你自己的路径,不能使用jenkins的默认路径

    参考
    https://gitbook.cn/gitchat/activity/5c83d2aa6d5f670edc43c606

  • 测试开发就是开发,核心竞争力是开发技能,所以想想“如何成为一名优秀的开发”。把自己从测试圈子中摘出来,放在开发圈子里看自己,可能定位就清楚了

  • 反对1楼唯KPI论,不是做实事的态度

    首先,测试的目的最终是为了交付质量。所以对团队来说,发现bug不是目的,解决bug才是。
    在这个前提下:

    1. 如果测试能够识别是同样的问题,或者是同类的问题,不应该重复提交。浪费的是团队的生产力
    2. 如果是黑盒的原因导致判断不出来是不是同类问题,重复提交也没什么。但是作为专业测试,还是应该尽量提升自己的判断能力
    3. 这里的避免重复单,是同样原因、同样现象的问题尽可能提在一单中,但是故障单中还是应该将可能出现的位置尽可能列全(以交付为导向,其实这不应该是个问题)
    4. 不同测试针对同样的问题提了不同单。这个没办法规避(但同一阶段测试力气使在一处似乎分工上有些问题),先到先得。

    总而言之一句话,和开发其实是一条船。重复单本身不是好事,主观上能规避就规避,真出现的话平常对待就好。

  • 为什么要在teardown之前生成? 需求好奇葩

    allure本质上是报告转换,不是执行框架,就是在执行框架做完事才做事。你这个需求:分成两个测试写,第一个调allure,第二个只包含teardown,不调allure

  • 就是做mock啊。有文档,照着文档造模拟数据不就好了吗? 不清楚为什么POST、PUT不能mock

  • 简单来说,测开要定位为服务团队,服务对象就是业务测试。实际需求是方的,你造的轮子再圆也没有用。
    很多时候不是缺少工具,而是很多已有工具业务测试不了解不掌握。测开沉到业务测试中,做好工具选型并形成最佳实践,教练好团队使用,远比做一堆重复度极高的框架、工具更为重要。

    服务意识往往比技术本身更重要。

  • 主要看维护工作量。
    有的测开工具,把大量业务层的东西抽象出来,做到配置、数据文件里。框架是灵活了,但是对业务测试来说,似乎工作量并少不了多少。有的业务测试怼回来:需求变化用你这个框架配置一遍,比自己写一遍代码还累
    这样的框架稳定有啥用?