感谢回复，欢迎讨论。

1. “别人的数据库”：这个指的是不同系统间的数据库。比如统一认证系统与商城系统，只有业务上的关联，程序上是相互独立的。直链的场景是：商城系统的登录不走统一认证接口，而是直接访问认证系统的用户信息。

2. 关于第 4 点日志的问题：如果是别的系统直连数据库，数据的修改只能从 Binglog 日志中去看。比如，商城系统修改用户信息，直接连接认证系统的库 update，那么对于认证系统来说，就是不可控的。日志级别是系统发布的时候就统一规定好的。这个也是基本的规范。如果页面有操作而在日志里找不到，那是日志的问题。

3.
关于文件存储，有自身的应用场景，这个不做过多讨论，它有你说的缺点，也有自身的优点，对于时效性不强的场景，完全可以这么做。

4.消息队列的使用，如果这个都会增加太多的开发成本。那只能说明团队能力的问题。这已经是业内非常成熟的方案了。谁发起谁消费？这个还需要讨论么？建议你学习下 MQ 相关的内容。

5.不是吐槽对方的方案，不论是从业务角度，还是技术角度，直连别的系统的数据库，就是个非常不成熟的方案。如果你觉的这个方案好，也可以采用。从我自身的观点来看，这个是架构师没做好。

建议你在 Linux 上去压测，Jmeter 在 Windows 下对于端口的回收是存在问题的。我也之前也遇到过。你可以用 netstat 观察下，会有比较多的 time_wait。放在 Linux 上就好了。

另外 ，Windows 的可用端口也没有 65535 那么多。

我有一个类似的故事，哈哈。现在的小伙心理承受能力都这么差么
https://testerhome.com/topics/34403

有一部分，单测为主，还有一些基于 AOP 的方法测试

其它两篇地址：
宏观的微服务测试策略： https://testerhome.com/topics/34678
单体微服务的测试策略： https://testerhome.com/topics/34633

如果做好测试用例的单一性，应该不存在你说的这种问题。

你安排的这一组测试用例，就是为了测试某个确定性的场景，所以不应该存在用例 3 满足不了条件，如果满足不了，就是有问题的啊。应该从用例 1 的测试数据准备开始，就是为了这个场景能够被执行下去。

个人不是很建议在场景用例中做过多的判断，否则这个场景要做验什么，到最后你自己都搞不清楚。如果分支过多，那测试用例执行通过了，你到底是验证到了哪个分支，你自己都不知道。

嗯，在文章中也提到了，并不是所有的微服务都需要这么细的拆解。 在一些核心微服务上才会有这么细粒度的测试。对于微服务从宏观上的测试策略，在另一篇中有说明。https://testerhome.com/topics/34678

接口调错，这个是功能测试需要验证的问题，放在 UI 层，你也发现不了。因为业务逻辑的问题，UI 没办法处理，除非你的检查点设置的非常刚好。

测试分层，做好自己的事。把所有情况在一个层次上去解决，可能什么都解决不了。

测试分层还是没有做好，在 UI 层不太需要关注数据的返回及展示，那是接口层应该去做的。对于 UI 测试来说，更关注的是页面是否能够正常展示，元素是否有变形。而不是过多的关注数据是否正确。

像这种添加成功后，怎么做断言呢？
--这类只要保证数据能被正常展示就可以，是否在第一条并不重要，我会更关注页面的分页是否有效，是否出现了翻页按钮。

还有像这种表单页面，查询怎么做断言？
--查询只要有数据展示就 OK 了，更需要关注的是查询、删除这些按钮是否有错位（比如某些字段值超长，导致页面变形）

再比如说，我是每个页面封装了一个 page,还有业务操作逻辑，那我测试一个完整的流程的时候，是每个页面的方法完了就进行断言，还是整个业务流程结束了再断言？
--断言是需要每个环节都设置的。

不要在 UI 层纠结过多的数据验证！！那是接口需要关注的。不要让 UI 做所有的事，否则你的脚本可维护性会很差

其实没太看明白，为什么要去遍历这所有的参数组合？有什么实际的意义？

好的，下周安排

1. 明确当下不规范的接口问题会带来什么，陈诉厉害关系；
2. 找一份接口规范，团队内一起评审，做相关的取舍，达成一致（有很多成熟的接口规范，但不要直接照搬，一定要组内达成认可）
3. 测试阶段做对应的测试，把不符合规范的也当成一类 BUG 记录，方便约束大家执行
4. 事后总结的时候，对事不对人，用数据说话，和研发领导沟通，逐步落地

测试有一个小的原则，如果一个 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.我只要比别人跑的快，死道友不死贫道，怕啥。

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

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