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

性能测试的背后目的是什么？我的理解无非就是两个，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 测试之道 人月神话 软件测试 测试架构师修炼之道 软件工程导论 这些基础可以先看，然后就得根据你个人的发展规划以及项目中遇到的问题了。

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

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

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

就我们团队的经验看，看问题先看个性的，开始不要眼光放太宽。

第一步挖掘问题。在看问题的时候，要避免主观判断，比如去问业务线同学你们的痛点是什么，大家也许什么都不反馈，也许给你反馈一堆问题。建议通过客观的数据统计来分析，看是什么问题在困扰大家。我这边比较习惯于让大家做平时的工时统计，在工时统计上分析大家的时间有哪些不必要的损耗，损耗在哪里。

第二步分析问题。在分析问题的时候要看下问题引入的原因，做改善的话空间有多大。避免为了做工具而做工具，这方面我们也是走了一些弯路，比如我们做了问题定位和分析工具，但是后续大家使用的很少。当时的分析是客观的，确实从数据上看大家在问题定位上贡献太少，贡献太少的原因是问题定位人工分析的时间太久，然后我们做了工具化，但是后来没有被用起来的真实原因是多数同学根本就不觉得自己应该在提交缺陷的时候做问题定位。

第三步提炼问题和做解决方案输出。在抽取单一项目或者单一产品线的问题后，分析这个问题是不是在其他产品线也有，做解决方案的时候是否需要考虑服用。比如我们之前在某个业务线需要做一些图像识别的性能测试，这需要构造大量的测试数据用于做识别监测。在分析问题之后，我们发现其他产品线虽然没有挖出这个问题，但是其他产品线其实也有做图像识别的需求，只是使用的图像数据不一样。如果这个时候没有考虑复用，那方案后续肯定还得改，所以在一开始我们就设计方案上支持不同类型的图像数据构造。在抽象的过程中，务必要脱离开你当前的业务。比如刚那个例子，如果之前的业务线是需要构造用户身份证数据做测试，另一个项目是构造户口本数据，你可能会觉得是两个项目，但是如果你脱离开身份证和户口本的实例做抽象，你应该要想到其实两者本质上都是做图片的图橡树别和关键内容提取。抽象的问题自然也就共性了。

以上是我的一点经验，希望对你有帮助。

主要是我们的测试工具，还有做一些创新项目挖掘的。

(⊙o⊙)…，请问你是哪个团队的呀？

我没有专门考虑过技能树这个东东。基本技能大神们整理了那么多，我就不多嘴了。
其他方面，当前还是以问题驱动型去做储备为主的。不过在思考这个驱动上，不是以当前的问题为主线，是以即将出现的问题为主线思考，如果知道自己下一步要承接什么样的产品什么样的任务，会提前思考下需要什么样的技能，如果自己和团队还不具备的，就针对性的做一些学习，为即将出现的问题打基础。

嗯 刚检查了 我已经髌骨软化症了。

我也在整理这部分内容呢，回头会整理一下再发出来，届时可以再一起讨论下。

没听说有公司内部专利一说，我们是提交国家专利局，香港专利局以及国际专利的

嗯嗯 是我，我是慧众，你是？

自己开发的，以解决自己的问题为主，后来发现可以对外输出给大家用，也就开始做一些输出的工作了。也是提升自己将工具打磨的机会。

有机会多交流

含金量普遍一般般

百万年薪的老铁介绍认识下 求教百万年薪方法

这个 19 没关系 常年如此

欢迎欢迎

一般般 也有一些糟心的东东 没做出成果 哈哈