从开发干到测试开发,从测试开发干到测试。

  • 树莓派搭建 UI 自动化环境 at 2021年02月22日

    👍

  • 一、接口功能测试。我觉得接口层的功能测试主要是去覆盖到一些前端不能触发的场景,测功能的同事可以重心放在验证客户端可触发的测试场景。举个例子,一个购买接口,功能测试同事测试点都是能从客户端触发的,余额足的时候购买余额不足的时候购买...接口测试同事可以验证修改商品 id 成已购买的 id、修改 id 成特殊符号...

    以前觉得接口测试可以无限覆盖各种场景,但是后来发现业务不可能触发的场景,测试了没太大意义。 因为从用户角度出发,永远不可能用到这个场景,这些测试就是浪费。 ----个人建议。

  • 弹窗识别_模型训练 at 2021年01月11日

    👍

  • 不管是在 setup 和 teardown 里面做这些事情,都会遇到你说的并发的问题。个人觉得现在有两种方案:

    1. 简单粗暴一点的: 对于 case 强制分类,数据会影响的放到一组。 不影响的放到另外一组,所以在并发的时候,多组之间的用例是不会相互影响的。
    2. 高级一点的:在每个用例运行的时候,初始化自己的数据库,如 H2, 这样所有的用例都是有自己的数据库(运行完毕后释放即可),就不会相互影响了。
  • 他的意思应该是在 setup 中数据初始化,保证数据库是干净的。

  • 这个问题可以分为两个部分:

    1. 搜索请求接口的测试,测试接口请求返回的数据是否正确。 ----这个可以采用接口测试.
    2. UI 界面上对于给定的数据,是否显示正确。 -----这个可以用 UI 测试,后端要不使用造数据,要不就 Mock.

    如果 1OK 了,那么 2 可以使用造数据或者 Mock.
    如果 1 不 OK,那么 2 可以使用 Mock.

  • 文中不是讲的不让在生产库中操作么?
    问题 1. 你需要知道自己的操作到底操作哪些数据,case 都固定的步骤,怎么会不知道操作了哪些数据了呢? 放在 TearDown 里面去清除数据,这个大家应该都是这么做的。框架都是提供给你让你这么玩的。
    问题 2:提速可能会有个问题,如果多用户同时操作,那么对于用例之间的隔离很重要,多个用例同时操作这个系统,随时可能会造成对多用户对同一数据操作导致用例失败。
    问题 3:其实可以想一下,在手动点点点的测试过程中,我们是如何判断测试通过与否呢(或者说系统更新成功与否呢)?然后用代码替代人为判断就可以了。

  • 我用的还是基于 2 版本的。 3 好像有大改,没有仔细研究。不知道能不能帮到你。 vx: 18694041815

  • MTSC 参会感受 at 2020年11月25日

    造轮子的事情,留给大厂的大团队去实现吧。 现在的小厂小团队大多不会投入那么多人力来搞这些事情的。

  • httprunnerManager 可以自己 fork 了之后做二次开发(好像后面作者又新出了 fastrunner?)。 但是如果自己想重新撸就是我说的自己写。

从开发干到测试开发,从测试开发干到测试。