🎉 🎂 🍰 TesterHome 创立 9 周年纪念日 🍰 🎂 🎉

  • 关于梯度压测的一些问题 at 2021年09月23日

    首先我没用过图里的工具,从字面上获取到的信息是测试执行了 11 分钟多点,并发用户最大为 178,而设定目标是 1000。
    大概率是加压策略的问题,用户数是可以直接计算出来的,性能再差,不妨碍我们继续加压,只不过很多用户可能无法得到响应而已。

  • 关于梯度压测的一些问题 at 2021年09月23日

    这个问题换个角度想,如果"想知道这个怎么计算请求接口多少次 起始人数是 5 最多人数 10,每次持续 30 秒
    那是不是每秒请求 5 次持续 30 秒,然后每秒请求 10 次持续 30 秒。计算公司 5*30+10*30=450 次"这里的思路是正确的,那是不是压力测试只要设计好就能知道 TPS 了,根本不用测😂
    所以答案很简单,那算法只是你期望的最理想值,而实际结果跟服务器的性能相关,那也正是测试的意义所在。

  • 随机这事可太折磨人了,这题也不知道原始出题人的思路是啥,到底想考察哪方面,建议大家不要使用这道题😂

  • 绕了一会才想明白,原来是只能生成 0 和 1 这两个值,所以就不能用类似 random.random() 的方法去获取一个 0 与 1 之间的小数。目前想到的解法也就是累加和 2 进制了,蹲个更好的答案。

  • 测试讲究的是指定的输入得到预期的输出,那接口测试怎么验证实际结果就是预期的呢?
    所谓去数据库捞数据校验并不是有没有必要的问题,而是比较省事的做法,而且这只适用于开发告诉你测试的 api 一定能在数据库中产生或修改一条记录的场景。
    拿注册用户为例,接口返回注册成功了并不能保证接口一定没有问题,你得调用登录接口验证,那谁能保证登录接口又是好的,还不是数据库里查比较方便么。
    按这个思路,我们只要查不出记录就说明接口有问题,具体原因可以再排查,就算是数据库产品的自身问题也不影响被测接口不可用这个事实。

  • 有很多酷炫的 chrome 插件,其中有个叫 chropath,支持 web 页面的元素录制功能,可能不能完全满足需求。
    如果自己会点 js,或者找个会 js 的帮忙改改源码,就都能搞定了
    app 同样可以自己改 uiautomator,只不过是 java 的
    如果你用 airtest,那就更简单,直接把页面上所有带有 text 属性的元素 dump 下来。
    但话说回来,这种做法看似高效,实际意义并不大,元素定位并不是自动化测试的痛点

  • 我们现在的方法是有自测用例,范围是正向业务流程,且通过开发及产品评审
    每轮迭代自测用例 100% 通过的才接受提测
    自测通过的用例被测试按同样的步骤、数据执行时发现有 bug 则打回该轮提测申请,要求开发修复后重新自测
    定期统计测试打回次数

  • 对 airtest 很有好感,工作中也一直在用。
    希望能看到新的优秀技术或思路,而不是历史倒退啊。

  • 本来想吐槽的,发现都被吐槽完了😅

  • 上家公司的产品就叫项目管理系统跟 OA 系统这两名字么😂