• 首先性能测试还是要支持性能调优的,当然了,只是为了探探系统的底,也未尝不可。

    性能测试的背后目的是什么?我的理解无非就是两个,1. 省钱、也就是做资源的投入优化,2.体验,即能给用户带来更好的体验。
    说到钱,理解为不扩容的前提下能承载更多的业务访问量,或者保证当前访问量的基础上降低硬件的投入。
    说到体验,如果你做得后端压力测试,给用户的直观感受只有响应时间,以及基本的可用性。

    so,你应该关注你的性能测试做完能不能支持调优,以省钱和提升用户体验为出发点。在评估是否需要做性能测试时,先看下预估下后续的业务需求量级和当前系统之间的匹配程度。比如之前我负责过某个项目,历史峰值的请求量才只给系统在 CPU、内存以及带宽上带来不到 10% 的开销,预估后续的业务量也没有井喷的可能,我们当时甚至不去做性能测试(资源也不需要精简,因为当时不差钱)。在用户体验上,肯定是有一些用户的预期的。

    关于覆盖范围,你要了解版本的发布要支持的目的是什么,常规的发布,上新功能(且有可能是爆款)还是配合做运营。或者说你要测算你要对应的业务流量从哪里来到系统那里去。一方面你一定要观察历史数据,这在判断哪些业务内容是主要的,指标如何做确认有很好的帮助意义。比如我们之前配合某个金融机构上一个金融产品并配合做活动,我们肯定是先分析他的历史流量,即他的流量入口量级是如何的,然后是我们观察类似这个产品对用户的吸引程度(即该产品自己的带量能力),然后是了解此次的运营力度(注册送 5 块钱和送 50 块钱效果可定不一样,线上推广和地推效果也不一样)结合历史上类似运营活动力度做一个模型做估算。确认范围也确认性能指标。

  • 感觉你说的是有宽度,深度不够的赶脚。
    不管是测试还是研发,作为 IT 从业者,还是需要一转多能的,然后才是多专全能。某个方向上必须有纵深。
    宽度好,但是深度不够的,我觉得比较适合一些初创公司,什么都做,但什么都不需要深挖的时候,万精油顺风顺水。但是随着规模租到,必然会遇到社会化大分工,大家在各自的方向上精耕细作。

  • 慧众 rodman,可以搜到我

  • 就是现在产品线面向质量工作和效率的不足,掣肘的地方。比如之前我们发现一个问题,很多同学安装 app 测试包,要请别人帮忙,了解之后发现是因为公司的设备是加了安全锁的,不允许电脑里的内容轻易导出来。我们算了一下整个团队开发和测试有 400 人,每人平均每天安装 2 次包,就是 800 次,每次浪费 10 分钟就是 8000 分钟,等于 130 人时。然后我们就做了一个无线 APP 构建站做 wifi 下的 app 分发,这个平台工具当前每个月的下载量超过了 5 万次。你也试着分析团队哪里有影响效率和质量的问题吧。

  • 这是一个矛盾又相辅相成的问题 -- 到底是现有能力成就项目,还是先经历项目夯实自己的能力。先尝试回答自己几个问题

    1. 自己的工具二次开发以及运用,基本功如何。深入了解一款工具不仅仅是了解这个工具该如何使用,还要明白当前工具适用于什么样的场景,存在那些短板和不足,针对这些短板和不足你自己的思路又是如何的。
    2. 如果因为监管的愿意没有能顺利开展,拟尝试做了多少努力,让工具能在符合监管的要求下开展,或者监管要求你是否读懂了。你是听到监管说 xxx 不能做,yyy 不能给权限?还是深入理解 xxx 不能做背后药保护的是什么,yyy 不给权限是放开权限会有什么问题?我们也是做金融项目的,还是银行核心服务以及保险核心服务,监管严格开始也觉得很操蛋,这个不让动,那个不给权限,但是了解一些面向一行三会 IT 安全相关的条款后,还是可以做一些尝试,让自己的东西符合监管的要求,同时能开展工作的。
    3. 通用工具不好落地,是否自己挖掘过项目组的痛点,并开展过专项的?如果没有,可以先尝试找一些痛点,测试体系建设也不止是做自动化,做持续集成这些,做产品评测,做研发的可测行改造都是可以尝试的众多领域之一。
  • 哈?请问您是哪家的,加个好友私聊?

  • 恩是的 平安的流程比较长,等待一般很久,时不时还得等某个大佬做个签报确认。

  • 哈哈 那有机会来我们团队转转啊

  • 测试之美 google 测试之道 人月神话 软件测试 测试架构师修炼之道 软件工程导论 这些基础可以先看,然后就得根据你个人的发展规划以及项目中遇到的问题了。

  • 你的问题有点大呢,有点不知怎么讲。

    我们做人脸识别首先是定义人脸识别的测试标准,比如对人像质量的定义(不同光线,不同角度,不同清晰度等因素设置的基础数据),然后是人像的范围(比如人种,年龄,肤色,性别),干扰内容(比如不同类型和程度的遮挡,纹身,饰品)反向数据(比如狗脸,猴脸,卡通,画像等),这部分做自动化对测试标准的定义很重要,很多同学做自动化会先忽略本身在业务线的测试要求,而机械的从自动化开始。

    本身这部分自动化都是基于接口请求去查看返回阈值的,到底准确不准确有时候过分依赖于人的判断。所以我们首先还是上文所说的基于各种标准准备测试数据,有些从科研机构拿到的,比如耶鲁大学的人脸样本;有些是线上导出的真实数据,有些是写了爬虫工具从网上批量抓取的数据。然后相同的样本做了一个投票设置,分别通过接口驱动查看本品和不同的竞品之前的返回结果,对几个测试结果做投票,对判决不一致的再人工跟进一次。测试的结果主要关注的是本品和竞品之间的比较。