• 说句实话,这种事情可能是很多,但是这种事情又会怎么样呢?他到底影响到了测试什么呢?如果没有影响在意这个东西干什么呢?如果没有影响,你提一下可能会觉得更好,如果不答应那就不答应了。 如果有影响,那有什么影响呢:

    1. 提测质量差?提测质量差就差呗,你就说提测质量太差,比预估的时间要多很多,应为发现了这么多 SB Bug,不应该出现的,应该在提测的时候就查看的,而且因为开发根本没有验证过自己开发的东西最少符合基本功能,所以他们工作量预估都是不对的,要不然怎么会出现这么多 Bug 呢?你不要怕,你说的就是事实
    2. 当然领导不答应你延期,你说加人行不?还是不行,也可以呀,那总要不事情说清楚吧,就是开发质量太差,需求都不知道也不验证一下,那你说你完成了什么?要是完成了,那为什么这么多主流程 Bug 都还有。
    3. 如果领导说你可以重新估计时间,那就多估算点时间测试呗,那就也没有什么影响了,对不对

    如果领导说,开发质量问题改不了,但也不能延期,那就测试快点,出点问题你提前和领导说,可能会有点问题的哦,因为开发质量比较差哦。如果领导还是说出了问题都是你的问题,那这么不看基本事实的地方,你有其他地方就去看看啦,如果没有,那没办法,你改变不了什么,那就想着怎么混过去呗。 但是话你一定要说清楚的。既然这样了,所以完全没必要纠结这些东西。

  • Hey,do you know what are you talking about?I just feel how arogan you are.
    Please, please do unstand it is just my opnion, it doesn't really matter.
    You can present your idea or opnion with reasons,passions whatever it is you name it.
    From my point of view, different scenarios formed different solutions, the manual execution is also one of these solutions. Please remember who are actually do the daily works in most cases, these testers,right? Please take care of them, otherwise, your work may be in trouble. You feel you are a manager, but so what. You even don't know What's your aim. Please make things done, not want things happen.

  • 【连载 14】性能测试模型 at 2025年01月23日

    线程模型和 TPS 模型 这块听上去很有道理,感觉是不对的。
    性能测试的指标主要就看: TPS 和响应时间 RT;线程模型去生成压力,也是产生 TPS 的一种。模拟用户行为对于服务器来说就是产生压力,服务器不管是机器产生还是人产生,对他都一样,就是压力,他的处理能力就是 TPS。

    性能测试指标首先就是先看:

    1. TPS
    2. 响应时间

    TPS 不能满足了要求了,再看资源使用问题,瓶颈在哪里了,如果看不出来就是加机器,水平扩展,如果一定要知道系统的上限在哪里,那就一直加机器提高 TPS 知道看到那个瓶颈的地方。

    这个文章有点概念混淆的意思。那些限流/排队和性能测试本身没有任何关系, 就是为了实现满足特定 TPS 和响应时间的实现方法,这些实现能不能满足要求,需要用性能测试来衡量。

  • 求救! at 2025年01月23日
    1. 查看 Python 环境

    2. 看看环境设置指向哪个

    3. 设置到你需要那个之后,可以考虑重启 pycharm,做好 index 之后再看看

  • 测试经验学习网站 at 2024年12月31日

    这么杂的东西,其实可能花点钱上上这个论坛的大 V 的课说不定好点

  • 需求管理都管不住,就不去测试用例管理了吧。

  • jmeter 压测问题 at 2024年11月04日

    可以在你要测试接口地方设置等待多少个线程完成一起发送的。也是一种模拟性能测试的方式.

    1. 同步释放请求: 模拟同时访问,看吞吐量和响应时间 Synchronizing Timer The purpose of the SyncTimer is to block threads until X number of threads have been blocked, and then they are all released at once. A SyncTimer can thus create large instant loads at various points of the test plan. https://jmeter.apache.org/usermanual/component_reference.html#Synchronizing_Timer
    2. 不设置任何定时器, 就是随机访问,看吞吐量和响应时间,这个本质上也是符合系统场景的,到你要测试的接口,当然前面也有很多操作,那么自然也会形成系统负载,如果前面就撑不住了,到你这个接口也没有什么意义,这个像系统层面一点

    3. 也可以设置其他定时器,按不同场景下吞吐量和响应时间

  • jmeter 的指标判定 at 2024年10月30日

    我看这个要求: 不是说是接口,是说页面加载时间,接口一个 3 秒?这太慢了吧,是慢的恐怖。

  • 如何以上都很熟练了,我觉得是性价比最高的,不费力气,工资也还行吧。其他不要多想了,合适就行。

  • 从解决实际问题出发:

    1. 哪些经常重复做的?包括 Excel 处理,数据处理,是不是可以固定一些脚本,SQL
    2. 自动化如果在有熟练的代码基础上,没什么太多内容,真的是没有什么内容,你看看你能不能回答一下问题:
    3. 如何用 Python 处理 JSON/DICT
    4. 如何用 Python 定义 Model,如果 Python 的类可以自由的和 JSON/DICT 转换
    5. 如何访问 API,request/获取其他库,API 的要素有哪些?HEADER/METHOD/BODY
    6. 如何使用 UI 自动化: 如何识别元素,识别元素有哪几种方法,selenium 也好,playwrite 也好,怎么操作元素?
    7. Python 如何简单的实现数据库访问?使用 ORM 模式,使用 SQL 直接访问的模式
    8. Python 如何自由的读取 EXCEL/CSV 文件,pandas 是不是可以用用?
    9. Pytest 写写测试怎么写?一些特殊的 mark 是不是可以查查就知道了
    10. Python 读写文件/操作环境变量/操作 Shell 命令
    11. FastAPI 写个 Server API 试试,router,request,response,middleware 概念有了,随手写上 API 了

    如果以上都随便写写就能了,其实大部分都能应付了。 80% 的测试自动化技术以上内容如何很熟练了,基本上问题不大了