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

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

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

基本上我们不会去测试协议本身，只是使用协议。所以不太需要 “拿着 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

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

感谢回复，欢迎讨论。

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. 事后总结的时候，对事不对人，用数据说话，和研发领导沟通，逐步落地