• 这种技术类似dubbo,尽量不要去分析协议,而是直接使用他们的本来提供的client去测试

    • 下载对应的service接口的依赖
    • 然后使用junit发起请求并断言
    • 使用数据驱动与参数化维护用例

    可以借助protoc帮你生成一些样板代码

  • 这个同学的回复,让我想起曾经做过一个测试工程师的成长公开课,讲过这个, 我截图过来给大家参考

  • 学院拿到了一些招聘数据,今年的招聘总量是往年同期的四分之一,找工作会很难,如果能力不是很强,建议先稳一稳,打铁还需自身硬。趁这段时间多去积极的学习提高自身能力。

  • 你的思维模式有问题,你转行到其他行业,遇到难题也会再次这样吐槽。到时候还要往哪转?宣泄情绪不如正视问题解决问题更能得到积极的收获。现在的你是在项目压力下出现了烦躁才会寻求宣泄的,负能量只会让人更加烦躁放大困扰和痛苦。

    临渊羡鱼不如退而结网,你要面临的问题并不大,只是被负能量放大了。你可以把实际的问题抛出来,发到学院的内部学员论坛里寻求下解决方案,助教和老师会给你出谋划策的。

    有很多策略可以改进,比如测试人手少的时候,你可以直接提出增加测试流程,增加项目组团队全体参与测试的过程。用例完善后执行可以交给其他人。

    改进文化,所有出的bug研发也要背负责任,质量是开发出的,不是测试出来的。所以责任共担。

    根据问题类型,用合理的技术方案去改进,接口测试、自动化测试、遍历测试,diff测试等,看哪个可以最合适的解决你们的问题。

    做了十年测试还是点点点,这个问题才是核心。你现在的思维模式有点像工作三年左右的人。我工作三年的时候也面临跟你一样的困扰,搞不定复杂项目,搞不定一些深入的技术,后来就跳槽去了另外一家公司去寻求答案,并最终在新的环境里解决了大部分的疑惑。所以困难和困扰并不是你的特例,几乎是每个工程师都会经历的特定阶段的天花板,只要突破它就可以获得新的成长。

    现在的你的确错过了成长的黄金期,如果你不付出努力去深入学习学院的课程和实战,那么最后一根救命稻草你也丢了,到时候只能试试转行了。个人身价=能力/年龄,年龄分母在不断增大,能力也得同步成长,不然落后的身价就会影响以后的发展,影响你的竞争力。

    怕你马虎,我给你总结下

    • 去内部学员论坛里发帖求助,让助教和老师给你帮你出谋划策
    • 深入学习课程,并在自己公司的项目中应用实战。
    • 改进测试策略、测试技术、测试流程甚至是测试文化,如果你个人很难推动,可以找个高手或者咨询师去辅助
  • 第一个写错了displayed,第二个是1.16新增的功能,可以不依赖app做自动化。但是很多条件还是会需要app的信息,建议都加上

  • 最近这几个月会有很多小公司裁员,疫情会让很多企业损失惨重,他们会缩编的。我已经陆续收到了一些公司裁员的消息。正常裁员也就只能赔一个月,抓紧找下一家是最好的。

    你是不是把简历投递给我了,我给你做个能力评估,推荐下。

  • todo: 年后给大家设计下如何普及这方面的知识。

  • 1、API自动化用例怎么应对项目中快速迭代?

    如果接口变化很快,需要反思下公司的接口设计。
    在接口稳定的情况下,用PO思想封装。

    2、在restassured的API框架基础上怎么做成平台页面化的?(做成页面化主要给让测试新手、产品、运营使用);

    • 不推荐搞平台,成本大,ROI不划算
    • 测试用例核心是保障业务正确。基于用例只是其中一种,还有一些是数据分析为主的。
    • 容易成为KPI项目,开发起来猛如虎,维护起来一地鸡毛
    • 投入太多会脱离测试核心,本质是一个xxx内部管理系统,开发平台的价值并不大,而且也不是核心。
    • 适合第三方来做

    如果做一个比较挫的平台

    • Vue做前端页面 bootstrap ant design vuetify
    • Django Flask SparkJava SpringBoot 完成后端构建 db+rest api
    • 用例的数据驱动 yaml json
    • 把yaml json的数据生成改成一个网页的form来生成并存储db
    • 运行时从db读取用例的数据,转成yaml或者json发给数据驱动引擎

    更推荐的办法

    • 数据驱动
    • jenkins持续集成
    • 持续交付
    • 结果反馈到devops的平台里
    • 用例维护、数据维护尽量是QA、Dev接手。
  • 请求到达接口A,接口A计算,然后写入数据库。
    另外一个接口读取数据库,可能有计算,返回

    req <--> a() <--> db

    res=a1.0(req)
    res=a1.1(req)

    测试方法

    • 基于黑盒需求用例
    • 基于白盒逻辑的用例
    • diff
    • 数据分析
  • 1、自动化测试脚本(ui,接口,性能)一般都在哪些环境上跑?

    ui、接口通常每个环境都跑,研发环境/联调环境、测试环境、预发布环境、线上环境
    性能测试通常只在专属性能环境
    全链路压测可以在线上环境

    2、有公司在生产环境跑自动化脚本吗?如果有的话,像支付场景怎么跑?用真实资金?

    生产环境一定要跑,一般称为线上巡检。
    在线上运行需要解决几个问题

    • 涉及到数据库的断言,没法放到线上,所以要区分开。
    • 普通的支付测试,需要用到mock,在非生产环境主测。线上环境中使用小额的订单进行测试。小额的支付测试是否自动化不是关键,因为线上和依赖服务都相对稳定。可以让公司出钱走报销流程搞个测试专用帐号。

    3、生产环境跑出来的测试数据怎么清理?怎么区分测试数据和真实用户数据?

    • 自动化测试锁定在特定的帐号就可以,这个帐号的数据可以定期让运营清理,不要完全自动化,不然QA就成了数据安全的风险点了。自动化测试也可以加入特定的header,不过很少有专门为了自动化区分流量的投入。
    • 性能测试如果放到线上是全链路压测,这个测试方法会在请求中加入一些特定的标记,比如某个header中加入标记。后端需要区分和过滤这部分的流量。

    4、在生产环境跑自动化脚本的目的和作用是什么?

    • 保证线上质量,有很多因素会导致线上出问题。跟发布流程关联不大,举个例子,没有上线,但是第三方依赖出问题,导致业务出问题。比如第三方的支付服务商、dns、各地的网络抖动之类的。
    • 不需要全部流程都在线上,核心流程在线上即可。

    以上问题设计是环境管理

    • 研发环境、联调环境。让研发去玩,自动化去保证
    • 测试环境:自动化测试、手工测试
    • 预发布环境1:线上环境的mini版本,百度内部就有一个叫做小百度。
    • 预发布环境2:接近于真实的环境,比如使用真实的支付流程。自动化测试、项目组验收测试
    • 预发布环境3:跟线上完全使用相同的数据库
    • 线上环境:测试核心业务、质量监控

    关于数据库

    • 不要直接操作数据库。因为你的脚本里会有密码。写一个service间接操作数据库。把密码隐藏,提供执行sql的接口即可。

一个爱好测试的工程师