先把自己沉淀下来

  • 扒代码分析接口逻辑或与前后端研发确认接口规范,明确关键参数,以及参数对应的业务处理逻辑

    • 根据具体业务逻辑来确认需要覆盖的参数场景
    • 根据前端调用规范,构造参数场景

    接口 20+ 参数,一般都是数据采集类型吧?确认下接口用途,采集类型 的话,只需要关注关键参数逻辑,确保所有参数都能采集就完事了

  • 😅 我们打个补丁去

  • 谈一谈今年的 TesterHome at 2022年11月29日

    大环境是一方面,新技术的接受度也是一方面,比如:前些时候百度、蚂蚁的干货分享

    还有一方面,老同学上升了,新鲜血液少了

  • 有两种情况:
    1、非常熟悉业务对应接口,对于接口数据源也非常了解(经常负责的对应业务接口,理论上应该是完全能够掌握,数据来源了,从上层接口还是数据库进行获取数据,心里有数的)

    • 在需求出来后,第一时间就可以和研发一样,结合需求同步进行初步接口分析和用例设计
    • 研发接口文档出来后,结合自己的分析情况,进行查缺补漏。研发分析的不代表是全的、对的
    • 要求前、后端开发对接口文档达成一致后,完善用例

    2、能进行接口测试,没办法自行分析接口伪开发需求,比如现有接口是否能满足?新的需求用到的数据,需要从哪里获取之类的

    • 梳理业务点
    • 研发接口文档出来后,结合业务点,确认接口是否满足
    • 编写接口测试用例
  • 在创新或 KPI 设定时,针对这块内容要进行完整性规划的, 比如前期调研、后期维护、使用期间的各种问题解决、指导相关、工具或平台的推广,各阶段对应的是长线成本还是短期成本,工具或平台最终目标,预计成果。

    KPI 或创新的完成与实践成果挂钩,最终只考核落地效果,与实际收益进行挂勾,达不到预期效果的扣除绩效、奖金。达到预期的提升绩效、奖金。

    当为了做而做,无意义时,就没有人再去做门面了

    当然一个有意义的工具或平台,在后面投入成本进行维护,也是有必要以及公司认可的行为,这也是属于工作内容的一部分

  • 好久没发帖了 灌个水 at 2022年11月25日
    仅楼主可见
  • 两个类型是不一样的吧,一个是数组,一个是字符串

  • 仅楼主可见
  • 实施和客户对接:
    测试是最熟悉环境部署相关的,在很多传统企业实施也是可以由测试进行的,产品上线后,经常是测试进行演示以及实施部署

    测试同时是最接近客户的群体,本身就代表着客户,可以借这个机会放大自身优势,和客户一起来探讨产品设计,逆推功能有效性以及适用性,可以尝试配合产品一起挖掘新功能,新产品

  • 测试环境和生产环境虽然是隔离的,但既然被攻击到,还是有必要看一下的,确认线上是否做好了安全防护。
    但应该是针对线上环境,一般情况下,测试环境和线上环境一定是有拓扑差异的。

先把自己沉淀下来