测试有一个小的原则，如果一个 BUG，前端能改，后端也能改，那就应该由后端改，因为后端改是最安全，前端有可能存在多处调用，不太可有所有的调用都要做类似的判断。而且，还有部分接口可能是直接给外部用的，类似 OpenApi 这类的。更不可能依赖对别人的信任来处理。

从题主的描述上看，其实更多的是研发规范上的问题，比如删除一个不存在的 ID，长度没校验导致入库失败等等，可以和研发一起确认下。

这个就需要团队成员去反馈，说明原因，或者了解上级的动机是什么。如果不能有效的传递信息，是很伤团队士气的。

都可以，反正场景固定了就好

性能测试并不是简单的上压力就完事的。你需要分析业务模型是什么样的，哪些节点需要做性能，业务比例是多少。
还需要考虑数据模型，比如哪些是基础数据，哪些需要参数化，哪些可以直接关联，对系统的影响有哪些，等等。
具体可参考：https://mp.weixin.qq.com/s/dJ8sIoQ5I3M1SgbrE-npPQ

看了半天，才发现是个接口测试平台。。。和数据工厂没有半毛钱关系

从各个渠道的反馈来看，我大概能理解为什么了。现实情况是大多数测试团队对于接口测试的落地还只是存在于个人或者少数人的阶段。测试的发展还是任重道远。就像其它楼主所说，个人用 JMeter 还是比较方便，还容易上手。

如果不从团队的角度看，只是个人，或者说少数人用，我是可以理解的。但是上升到团队规模，Jmeter 真的是不合适。

对的，从团队的角度看，JMeter 的硬伤无法得到有效的解决。个人用没什么问题。

1. 逻辑客观的事实，不带自己的主观观点。就比如你的负责人让你统计 BUG 数据一样，这是客观事实。你说的 “感觉很多都是开发并不认真导致的，一个 bug 反复改都改不好，而且不仅没改好，还导致了更严重的问题” 这个就是主观观点，这个是有问题的。

2. 事先打好招呼：要统计哪些问题，事先打好招呼，让大家有个心理预期，也好准备查找根因（嗯，找好说辞）

3. 对事不对人：不管什么原因，不要在周报上提及个人，表扬可以。

4. 报风险，给方案：暴露问题和风险没有问题，最好能给方案。

1. 如何部署，推广这些功能。 --这个指的是测试平台么? 推广要结合不同团队的实际情况去协助他们解决问题。你是去协助解决问题的，不是去给他们增加负担的。这个要特别注意

2.怎么获取不同（某个）项目的代码，接口文档，来进行测试
-- 代码不都可以看么？现在测试还会没会代码权限？？？ 接口文档的话，有就问，没有就自己分析，或者让开发出。

3.碰到问题，特别是调试类的一些问题。开发为何要配合你做一些不属于他本来的工作
-- 人际关系搞好些就好了啊，而且同样的问题，不要总是去麻烦别人，也会好很多。测试和开发可以是很发的合作方，而不是对立方。

1. 如果让上级接受你的想法，怎么确定你的想法就能提效？
   -- 先做，再说。多沟通。能不能提效是需要验证的，当然，团队应该要允许一些失败的情况发生。做为主管，也要有包容的心态。如果上级太强势，那就算了。

2. 如何确定你目前公司需要什么
   --观察、分析团队的痛点在哪里，尝试去沟通和解决。前提是要了解足够多的信息，多交流。很多时候团队做的不好，不是因为能力问题，可能是其它的外部因素。

最后，不要被测试这个角色困住了。谁说你只能做测试？我现在挂的是测试架构，但做的很多事，细说起来，都来测试没什么直接的关系 。

https://testerhome.com/topics/34288 原话题

角度不太一样，感觉您这边更多的是从硬件层的调度和性能分析为看的。而我是从应用层的角度来分析，需要知道的一些知识点，关注点不一样。

从应用的性能来说，关注的基本还是基本逻辑是否能跑通，是否能够充分调度到硬件资源。硬件层本身的性能瓶颈，应用层是没办法突破的。

希望硬件性能能有大的性能突破，这样应用层就可以 “任性” 一点。

感谢回复，按着你的思考，尝试回答下几个问题：
1.性能测试的路会不会开始就是错的？

性能测试现在是处理比较尴尬的地位，上不去，下不来。随着现在各类研发框架的完善和流行，只要开发不乱来，浅层的性能问题会越来越少，只会简单的压测意义不大。而深层次的问题，中小企业的研发能力又不一定能修复（比如中间件的问题，框架本身的局限性等）。

同时，随着硬件的工艺改进，当下的服务器足以满足中小企业的日常性能需求，团队对于性能测试的渴求度也没那么高。

所以，走性能这条路，要么走深，要么就不选。这也是我近几年逐渐转方向的原因（本人在大型企业做过性能测试负责人）

2.从楼主的介绍来说，可能随便一个本科的课程都比楼主说的详细。

不敢和本科课程比较，本来就是一时兴起写的，篇幅的原因，没有展开来详细写。只是纯粹的小科普。

3.楼主提的问题，其实我想问楼主，你的答案呢？然后你的答案又从何而来？哪些是你自己的东西？

我的答案在我心中呀，自己真实落地实践过，所以应该算是我的东西吧。之前为了做好性能测试，把《计算机组成原理》一书啃了好多遍。

4.未来技术只会越来越深，这种对技术的粗浅理解，真的太容易被替代了

原则上来说，我们不需要对所有的技术做很深刻的理解，本质工作的能力，当然是越深越好。但是一些常识性的东西，粗浅理解比不了解要好，了解比不知道要好。留点映像，以待用时。

5.我只要比别人跑的快，死道友不死贫道，怕啥。

这个是对的，先发优势总是占优的。

最后，发贴的意义在于写自己想写的，并引发一些讨论，补充自己的不足。至于是粗浅理解还是精通优秀，都是因人而异，每个人都有自己的擅长和知识盲区。欢迎讨论。

可以确保周更。。。

理论上是认可这类测试分层的，从研发的角度上来看，确实我们应该多投入时间在单测上，优势很明显，颗粒度小，验证快速快，方便定位。但是在实际的实践过程中，Unit 测试推广不开个人认为有以下几个原因：

1. 成本问题。虽然现在有比较好用的单测框架，但如果真的要产生实际价值，还是需要大量的代码编写，比如 Mock 其它服务，比如数据准备等，而且开发人员的时间和精力有限（现状如此），让测试人员来写 Unit，就更不靠谱了。

2. Uint 无法完整的描述业务价值，它更多的是验证工程实践是否有问题，但很难从业务价值上做出评估。

所以，现在更多的团队选择接口测试这种粒度来快速验证。因为他的粒度相对也比较小，能够做到快速执行，快速反馈，对于代码的定位也是比较快的。而且，好的接口一定是为了实现某些具体的业务价值。所以可以更好的去评估代码与业务价值的关系。

测试策略的选择，还是会受很多现实因素的制约。也是一个不段在做动态平衡的过程。

这不就是回归测试的典型场景么？

回归测试：每天来回走一遍，看看哪里的砖有晃动；

自动化测试：骑个车（轮子宽一点的那种），碾压过去，提高效率，

埋点测试：路上等距离安装摄像头，然后在监控室里观察

用户反馈：人家都投诉了，你还不知道哪块砖有问题？做好安抚，快速修复。

业务需求：有没有一种可能，从业务的角度上看，确实有可能是故意设计的这么脆弱的，否则怎么签二期合同。（别对号入座哈），很多时候有些奇葩的需求都是服务于某些特定的场景，只是测试不知道而以。

简单地把线上 BUG 分成三个等级，便于分析。
简单易现的问题：如果是比较简单就复现的问题，那作为测试人员就要反思下为什么了，这个锅跑不了，还是要有对自己的工作负责的态度。如何避免这类问题的出现呢？有几个小办法：

注重测试策略的设计（好多人都忘记这件事了，后面会专门谈谈测试策略的问题），对于每个迭代（版本）的测试重点和测试方法做一次梳理。
测试用例设计更全面些，多考虑一些业务场景，更多的确认手段，而不仅仅只停留在页面的操作上。
测试用例评审，避免自己陷入测试盲区，让产品和研发一起来确认场景覆盖是否充足。
认真执行测试用例，这点很简单，但是很重要。因为人都会情绪低潮，在某些情况下，心存侥幸，可能用例直接就 Pass 了。
特定场景或者数据才会出现的问题：这种情况，遇到一次，就完善一次用例（如果能自动化，就最好了），同时思考为什么只有这种情况才会出现，类似的还是不同环境配置引起的问题。这类问题需要注意平时的积累，形成自己的经验，这类 “锅”，可以团队一起背，但要给出改进方案，不能多次在同一个地方跌倒。

深层次的偶发问题：这类问题其实是提升团队技术能力很好的试验场，集中力量解决掉就是了，更能激发技术宅男们的热情。这类问题，一般情况下做好线上监控，能及时预警，比客户更早或者不能落后太多发现，就可以的，让团队有缓冲解决问题的时间就好（准备好相关的话术，安抚客户也是 OK 的）。
你看，这么一分，是不是心理负担就少很多了，有些 “锅” 也不是什么坏事。不是么。

你的质量观在哪里‍
最后，再聊聊测试人自己的质量观。每个人走上测试这条路的理由五花八门，也导致了大家对质量这件事本身的看法也有很大的不同。

看法一：把测试这个职业定义为仅仅是保证系统不出重大事故，一点就蹦的情况出现，其它交给开发，出现 BUG 就是开发能力不足。因为他们对测试的理解就出现了偏差，所以遇到比较复杂的，难以测到的问题，就放弃努力，给自己找借口。比如自己薪资就那么点，因为能力有限啊，发现不了还能怎么办？比如你行你来测试啊？谁家软件还没有个 BUG 呢。凡此种种，肯定不会觉得自己应该背这个锅的。

看法二：从自己手中出去的产品，要有最低的质量保证，如果出现问题，及时反思，寻找解决办法，什么 “Bug 藏得太深”、“测试环境无法复现” 等理由都不是借口，总结经验教训，努力提升自己。真正把测试当做职业来对待，一定会想到办法解决或者规避此类问题的再次发生。在做好自己的同时，给团队带来正面影响，逐渐影响到其他人。

看法三：通过更好的实践方式，提前预防问题的发生。单测、静态分析、自动化测试，还有现在比较流行的混沌测试，都会帮助我们及早的发现问题。在适当的机会引入敏捷理念，通过自己的能力和实践，协助团队内建质量，培养全员质量意识。

参考：https://testerhome.com/topics/32230

我们说的好像不是一个事。。题主问的是测试工程师这个角色，而不是这个角色中的高中低级别。

高级测试人员的能力强肯定对项目上帮助大，这个没有什么疑问。

这个没有什么必然的联系的。测试工程师在团队中的地位取决于你能给团队创造什么价值，能给研发过程带来什么帮助。地位都是自己争取来的，而不是 title 带来的。

不能说测试人员的 “地位” 高，质量就会好，毕竟测试人员也不产出质量啊。更多的时候，测试人员只能保障产品质量的下限，然后通过质量内建等一些方法来逐步提升这个下限。

关于如何提升测试人员的地位，可以参考：https://testerhome.com/topics/32121

关于第二个问题，不是地位越高，而是能力越强（不管是代码能力，还是横向拉通、解决问题的能力），那么质量保障水平就会越高。现在各类大会上提出的新观点，新技术都在验证这个结论。

没太理解为什么只能用 UI 来准备数据，UI 调的不还是接口么？不太清楚有啥特殊的地方。

另外按题主的说法，可以尝试把这两部分解耦，数据准备和接口测试分开来处理。如楼上恒捷大大说的那种处理方式。

至于是引用工具，还是写代码，就看团队的整体能力啦。

不能仅仅对着操作写用例。试着从这个需求的实现价值开始，想想为什么会有这个需求，用户在什么场景下会用，后台是如何实现的等等方向去思考。

https://testerhome.com/topics/33655 这里有具体的场景和案例，可以参考下。

优秀~~下载啦，好好学习

https://testerhome.com/topics/32826 可以参考下这篇文章，测试还是有很多不同的阶段可以提升的。

那我那篇还能参与这个活动么

还有这种群哇