• 1、分析缺陷产生原因、复现条件,测试环境能否复现,线上环境为什么没有复现、没有复现影响多大 —— 是漏测就得认;
    2、摆事实,讲清测试方案、设计、方法,确认这个方案当时有没有获得一致评审通过,如果当时已经通过了就是大家的锅 —— 如果这些没做测试当然就有主要责任;
    3、看看是不是测试阶段总在做一些验收性的测试:如果是,验收性测试本身就比较耗时间,测试时间不足,测试的深度自然也不足;如果本身不是做一些验收性的测试,测试能够提前介入,一般不会“最后才报BUG”,这里只需要列举“提前”报的BUG。

  • 需求不能量化,能量化的是指标
    你可以先把需求转化为(评测的)指标,然后对指标进性量化
    你已经有一些比较具体的需求(20万、持续时间5min),涉及接口数n
    从需求来讲,就是:20万个用户,在持续5分钟内,连续调用这n个接口的整个过程里面:流畅、稳定、成功率高
    所以,这里的评测指标除了你已经提到的:TPS
    应该至少还包括:各接口的平均响应时间、响应时间方差、(n个接口作为一个事务的)事务通过率

  • 接口测试用例设计 at November 04, 2019

    如果是,不考虑逻辑的前提下,那覆盖率能达到多少呢?如果覆盖率足够高也有一定意义
    这样业务逻辑上可以通过UI自动化补充实现

  • 用1、10、20 个线程分别跑个10分钟得出一个基准场景,看看主要的开销是在CPU还是内存还是带宽出口,在开销达到瓶颈的范围内的可产生的负载就是该机器最大的负载,所以,还得看脚本针对的业务场景,大批量静态文件下载产生的压力小一点,相对简单的表单提交可能大一点

  • 一次性能测试的总结 at July 20, 2019

    原来大家都是差不多,插句话,关于需求调研,和产品那边沟通大概就是 把期望转成需求,把需求转成指标,依据经验对指标的量化做出阈值界定,最好别让太多人掺和太多性能指标和阈值相关的事情。

  • 写的基本都是接近验收阶段的测试了

  • 因为大部分系统的业务知识价值低

  • 1、由于测试时间不足,所以:花1天时间评估系统大概的业务流程、业务角色、场景,评估紧急上线过程所产生的性能风险;

    2、由于没有人配合你,所以:尽可能抓住你所理解的重点进行测试,在开干之前,出一个简要的性能测试方案以尊重目前时间进度紧张的客观事实,简要方案里面包括:

    • 你理解的系统项目背景、系统业务
    • 你准备采用的测试策略
    • 你所理解的测试场景
    • 你所估算的进度计划
    • 你要求的最小资源
    • 你认为目前紧张进度下你所能覆盖范围
    • 你所认为的关注点(责任人的关注点、你依据他的关注点帮他敲定上线标准)
    • 这次测试由于测试时间不足导致你无法覆盖哪些场景最后所引发的那些问题 然后带着这个简要方案找到项目责任人进行评审

    3、依据 评审 意见,修改方案,看看责任人是协调资源给你解决、还是增加测试时间、还是带着风险上线;

    尽量不要瞎操心给项目增加无谓工作量,说不定系统压根就没有人用呢?

  • app的启动页发

  • 首先看测试需求,既然是股票类的APP接口,那实时性、数据正确性当然少不掉对吧?
    实时性的话,脚本同时请求第三方数据源接口数据,比较你们接口数据的延迟情况是否在可接受范围内、以及数据响应的稳定性、连续性。
    另外就是数据的正确性,针对返回报文格式内容、状态是否符合预期。
    大致想到这两点。