如果是企微回调你们的接口主动上传数据，那实时性要求不高的话，如 10 楼所说，直接用 MQ 会好点，性能压力会极大缓解。
至于模拟加密麻烦。。。这个应该不算什么问题吧，没难度。

一般会有两种办法：

1. Mock 数据，然后只验证自己处理回调接口的性能，默认企微的接口是没有问题的。
2. 看看企微有没有类似沙箱的环境，让你们压。

有个小疑问，你们获取成员聊天记录是想干什么。。。

我也是自己在反思，有时候也会犯错，哈哈。

没那么严格的界线，相对而言，研发过程还是比较透明的，不认论是测试人员还是测试组长，都能看的见。可以适当的去尝试推进。或者找一些 “帮手”，或者和开发维护下感情，都是可取的。不要被自己的限制了。

两条腿走路，极端了都不行。技术辅助，业务主为。

其实天梯也是可以刷分的，本质上都一样。谁还没带过妹子不是。

我在团队的实践思路是：重点关注生产缺陷、流程改进建议数、效能提升项，这三个是考核的重点内容（60%）。其它的，根据团队反馈来估计，占比 40% 左右。想要出成绩，要么保质量（线上不出问题，过程你们自己定，不管你是点点还是自动化，线上不出问题，怎么都可以。出了问题，有没改进项，是否落地了，是否重复出现等），要么改进过程，提升效能。

绩效本来就不会有绝对的公平。这个世界也没有绝对的公平。这也不是我们要去追求的。平衡才是常态。毕竟软件研发过程，还是没办法直观量化的。和工厂的拧螺丝还是有质的区别。

https://testerhome.com/topics/35129#reply2

同名公众号：CKL 的思考空间

其实吧，录制的脚本更麻烦。因为你还是要手动去修改数据，比如参数化，比如登录信息。还不如先熟悉接口，然后再处理。不了解接口你也无法有效的设计用例啊。

严格意义上来说，你这都不算测试开发工程师。。。

解决业务测试的痛点，研发各类小工具，搭建平台等，才能算是测开。

优秀~

提两个小建议：

1. 是否可以根据业务接口来造数据，从上面的介绍看，主要还是依赖于手写数据，这就对测试人需要对对应的表结构或者 MQ 的报文结构非常熟悉才可以做到，特别是上下文依赖。比较容易出错，通过接口调用会好些。

2. 造出来的数据，如何与测试脚本关联起来？需要使用人员再去查询一次么？

造数确实是测试活动中非常重要的痛点，希望看到更多优秀的解决方案。

这个适合纯数学计算的公式，因为可以在不知道入参的情况下做推导或者公式变形。但是对来有业务逻辑的函数或者接口而言，要如何做落地呢？比如测试对像是根据不同的用户 ID 返回不同的用户信息。这个在不知道用户 ID 的情况下，如何做断言呢？好像没办法推导

当我们采用平台化来做专项测试时，封装好功能，降低对测试人员的要求，只要通过页面编排就能够执行相关的测试。那么，测试人员如何提升自己呢？这里涉及到的角色有两个：个人与组织，这两个角色对平台的诉求是不一样的。

组织：从组织的角度来说，希望的是有统一规划和管理，同时能够有效降低准入门槛，通过简单的培训，让更多的测试人员能够开展专项测试，所以更需要平台化的管理方式，能够提供标准化的、可视化的、操作方便的服务 。

个人：当你进入到一个团队中，有现成的平台给你使用时，一定不能满足于使用平台，而是应该抓住机会去了解平台的具体实现，甚至参与到平台的研发过程中，把别人的开发设计和解决问题的思路变成自己的心得体会。如果只会依赖公司平台开展专项测试，那是平台的能力，而不是个人的能力。这也是为什么很多面试官不太喜欢大厂出来的同学，因为离开了平台，个人的能力有可能出现断崖式的下跌，切记（其实很多岗位都会有类似的问题，要学会区分哪些是自己的能力，哪些是平台给你的加成）。

基本上我们不会去测试协议本身，只是使用协议。所以不太需要 “拿着 RFC 标准仔细去看看每个字段/字节/bit 的含义”。当然如果你是测试协议，或者自定义一些私有协议，那是需要去理解协议中的细节。

问题 1：我司的实践就是代码走查，直接查看相关 entity 中对象的定义，lombok 用的规范，其实简单的等价和边界都不太会存在问题，反而更应该关注的是数据权限是否合理（是不是返回了太多的数据）、业务权限是否合法（是否有对应的功能权限），数据结构是否规范；

问题 2：这个现在有蛮多的工具都有类似的功能，以体现自动化测试用例的 “智能”，个人认为意义不大，纯粹的是为了数量好看。

培养一个完善的测试思维、编写一份简洁的报告；拥有承担一点责任的勇气，不断努力精进自己的测试能力

自己的测试思维，制定针对当前迭代特性内容的测试策略，通过不同方式的测试建模，输出一份高质量的测试用例

测试报告是测试人员工作的总结，也是测试人员具体的价值体现。一份好的测试报告至少应当包含以下几点内容：测试范围、测试结论、测试风险

作为测试人，经过自己测试过的内容，应该承担一份责任，能够保证产品的基本质量。

经过一批批测试人员的努力，不断地研究测试底层逻辑，提升测试能力。他们没有躺平在测试 “仅仅是点一下、看一下、验一下” 的认知中，而是通过提升自己的能力，通过单测覆盖、静态分析、接口测试、各类自动化手段，乃至于安全测试、埋点、监控、生产流量导入等等各种手段和方案，来提升质量，让产品的质量更加可靠，让测试的价值得以更好地发挥

还在坚持持续分享

个人的感觉是，随着现在业务技术的复杂度在不断的提升，单靠测试技术的提升已经很难推动落了，不论是精准测试、全链路测试还是变异测试、混沌工程，都不是测试一个部门或者个人能够推动，没有好的技术基础设施，难有大的突破。技术的学习沉淀周期变长了。

以前测试技术更多的是集中于测试本身，类似接口测试，UI 测试等，可以快速落地，出成果，分享也容易。

再一个就是公司给大家尝试的机会变少了，大环境如此，新技术的不确定性高，ROI 低，团队的交付压力变大，保障业务是重中之重。

其实， 在当下，我们可以更多的去思考如做测试本身的提效，在测试策略和测试理论上，下点功夫。这个在技术盛行的时候，容易被忽略。

好像是，我改下，感谢指出。

精准测试是一种利用技术手段对测试过程产生的数据进行采集存储，计算，汇总，可视化最终帮助团队提升软件测试的效率的方法。精准测试并没有改变传统的软件测试方法论，只不过是帮助我们将测试用例与程序代码之间的逻辑映射关系建立起来， 而这个过程则是通过算法和工具去采集测试过程执行的代码逻辑及测试数据，在测试过程加入采集过程，形成正向和逆向地追溯。

正向追溯，开发人员可以看到 QA 执行用例的代码细节，例如用例执行过程中，调用具体方法与实现类，方便进行缺陷的修复与定位。

逆向追溯，测试人员通过 release 前的增量代码快速确定测试用例的范围，极大减少回归测试的盲目性和工作量，提升 ROI，达到测试覆盖率最大化。

精准测试看起来非常友好，随着技术的提升，推荐的用例也会越来越准确，但它有也存在不足的地方，主要有以下几点需要注意：

基于手工测试的精准测试建立映射关系繁杂，如果需求改变频繁，用例维护以及之间的关系维护需要耗费大量时间精力。
精准测试需要一定的自动化测试的覆盖，这样做起来更有意义，例如 api 自动化测试，如果本身用例过少，与代码之间关联关系不多时，变更代码后可能不会得出什么结果。

项目生命周期需要较长，短期项目花费巨大精力开发和维护整套精准测试系统得不偿失。短期项目可以利用精准测试以 api 测试覆盖率作为衡量标准。不去建立繁杂的关系，只监控 UI API 测试覆盖率迭代时的变更来达到目的。

文章讨论的是这个预期结果怎么来，需要从哪些方面去确认，不仅仅是需求文档，而是需要考虑更多的内容。

不知道这个文章哪里刺激到大家了。。翻译了一个名词，加上了自己的理解而以。。奇怪。

” 之前反馈给开发说慢的问题，开发就说，我保证我代码不报错就行，这响应时间长和并发量低，他也没办法 “
--你说：如果你也能和老板这么说，那我也没意见，需求是老板提的，不是我提的。

前期如果真的意识到性能问题，优化起来的收益是非常可观的。从 5 秒变 1 秒是相对比较简单的，从 1 秒变 500 毫妙，那才麻烦。

加油。

” 现在领导就想知道我们平台是否可以支撑住 30-50w 的设备去使用，而且功能不分大小，起码每个模块的功能都能支撑的住这 30w 用户去发生多次事件 “

--大概可以猜测是总量为 50W,那么可以根据每个模块大概的比例，分配出每个模块的用户量（没有必要每个模块都压到 50W，性能测试也是有成本的），比如你们有 ABCDE5 个功能，其中 ABC 占 80%，DE 占 20%，那么 A 功能大约就压到（50W*80%）/3 的量级就可以了。

测试步骤：测试目标明确了，那就好办了，直接上压力，不需要逐步加压（如果性能真的太差，比如直接压挂了，或者响应时间太长，再逐步用二分法减压）

等每个模块的性能问题解决的差不多了（TPS 和响应时间大家都能接受了），再考虑全系统加压

重点关注系统分发功能的性能、资源互锁的问题

最后再做稳定性测试（一般的做法是 80% 左右的峰值量去压）

铺底数据的问题，建议越多越好，直接按 30W 的量去准备就好，SQL 或者接口都行。

图片被压缩了，没办法，可以自行下载：
链接：https://pan.baidu.com/s/12kdCXYvIONnNk07ZDMZyow
提取码：b1jm

厦门是我测试生涯的起点，虽然好多年没有回厦门了，还是希望厦门的测试发展越来越来。感谢题主的组织。