调优肯定得保证功能正常才行

改代码就让研发评估是否需要回归功能，但多数对自己没自信的研发为了保险起见更倾向让测试做冗余回归，这时测试人员能不能 review 研发的改动，评估改动影响大不大，要不要回归，回归多和少，就显得很重要了。

基本功能都不对，还谈什么性能

功能与性能 2 组人马不是同一个 leader？

性能测试一般默认功能没问题，如果代码做了修改，功能和性能是测试的两个维度，如果归属两个团队做，正常来说是都要进行回归测试的，评估下回归的范围就行。

小组长不一样

现在功能复测的时候，一般会做这些：了解优化方案，代码 review，评估影响范围，然后测。但像优化方案评估、影响方案评估，这些不应该是性能测试该干的吗？

如果性能测试这样不管功能只跑脚本，我都想去跑性能了

那要看性能测试的人跟不跟业务，如果他们是一波独立于业务之外专职搞性能的人，不了解业务，你让他们评估也实在是为难别人（当然你可以对外沟通时给他们甩锅，看你自己怎么想）。

从我的角度看，业务最后出问题还是自己受损，你能评估到也是你的 goodcase，如果自己有能力评估还是要尽量参与。

说白了都是无奈之举，大部分测试没能力（技术能力或责任心）负责自己测的需求的性能测试，一天被需求压得都喘不过来气了谁还愿意去搞性能测试，所以搞个压测组，准入准出标准一般还是领导拍脑袋定一个，你把他当作安全测试是不是就好理解了，搞安全的要去管你改动影响范围吗。所以应对方案和应对搞安全的一样，原封不动转给开发去 battle，他那个标准都不一定符合具体业务，需不需要改都两说

性能测试准入标准一般就是功能没问题，如果因为性能问题的修复导致功能有问题了，是不符合性能测试准入标准的。一般性能测试需求不多的，业务向团队内只搞性能的后面就慢慢没事做了

在理，这种 bug 抓出来还是很有趣的

项目做多了你就知道，一般性能测出来的问题，调优，尤其是通过业务流程优化的功能，功能上出些回归的概率是极高的。