fengruxue的专栏

之前还蛮少关注MTSC 的会议内容的，因为好像看起来没有特别多的创新点，还是传统行业测试的各种质量保障手段，但是还蛮想看下今年的MTSC 的内容的，年初deepseek 的出现就开始让部门的测试工作重点有了质的变化，一切能用AI 赋能的测试手段都鼓励尝试，但是因为很多都是处于初步尝试的阶段，实际上没有见到有取到比较好的实践落地效果的，然后就还蛮好奇其他公司有没有比较好的AI 应用落地效果的。

本来想写下自己对于业务测试的这个工作的一些想法，写到后面发现其实又回到了上一篇说的测试的价值是什么？当我找到意义的时候，它又变了。

许久没有自己动手写测试相关的文章了，对于一些测试基础概念，技术细节点网上随便搜索就能找到相关的不太想写，实践相关的之前比较多的还是和工作相关的，基本写的也差不多了，没有特别想要写的。吃早餐的时候突然想到这个主题，其实也是一直困惑自己的问题，你认为做测试的价值是什么？时常也会问身边同事这个问题，但是要么和我有类似的困惑，要么答案不是我心中期望的，能给我解惑的。这个问题其实细想也和工作价值有关，自己的职业岗位title 为测试开发工程师，问测试的价值，其实也可以问自己的工作价值是什么？

学习一门技术语言最好的方式还是多敲多练多实践，deepseek的出现让之前一直辗转于各大网站搜索各种想要知道的内容变得十分便捷高效，只要你能准确的描述想要知道的信息，基本它就像一个专家级别的咨询师一样，给你答疑解惑，还是免费的，解决了各种翻来覆去都找不到解决方案。要不就是没有强关联的解决方案，要不就是各种需要付费看广告的博客文章视频，过程稍长且很容易让人放弃寻找答案的热情。看到视频号说的deepseek的出现会让广大自媒体特别是那种咨询类博主先失业，中国即将迈向共产主义,也不是不可能了。

最近在B站还有各大网站找了一圈和大模型相关的测试领域的视频文章，新兴领域，参考屈指可数，要不就是要交钱的培训营，大概是在AI 大模型的落地运用层面，开发和测试并没有特别明确的细分，一般如果公司在Agent智能体层面的产品落地，测试可能更关注的是UI 层面的功能测试，而内部的算法测试大概是开发在微调的过程中就已经自行覆盖到了。

工作这么久以来，接手测试的需求也非常多了，有持续了一整年的重构性的项目，有从0到1 的维持半年的创新型项目，也有小型的持续数周的需求，还有一些日常的快速迭代，大部分时候，做为测试TPM（Tester Project Manager）,需要制定整体的测试计划，包含了测试策略，测试时间节点，各域联调计划以及各种专项例如自动化，稳定性，性能，多语言，APP端还有各种兼容性测试，弱网测试等的进度跟进。

写下这个标题的时候，脑子里面浮现的第一句话就是“Less is more”。指标度量一方面会促使技术团队有一个清晰的目标指导方向，例如像单测覆盖率指标，如果团队是80%的水位，在开发阶段，技术同学其实也会有意识去把单测覆盖完善，但是倘若没有这个指标，拿我自身举例子，其实我自己写的代码也不太喜欢写单测，先抛开写单测的效率成本问题，没有指标驱动的话，或者单测指标覆盖率已经作为了质量交付之前的一道门禁，所以度量指标的制定有利于团队的统一规范。

周四周五的时候趁着最近项目刚忙完有点时间，在公司花了半天的时间把极客教程茹炳晟老师的软件测试52讲80%的内容看完了，其实一开始看到是2018年的课程会觉得这个里面讲的理念是不是已经过时了，或者是对于自己从业测试多年来讲，讲的东西会不会太基础了，一开始看的还是挺细的，后面部分内容我都跳过看了，但是还是有一点收获的，最令我深刻其实不是说的关于软件测试的理念方法工具这些，而是其中一句话：也许你觉得测试是一件入门门槛较低的工作，但是任何一件事情，如果你想把它做好，做到极致，其实并不容易。 这个观点让我

每个系统都有一个最佳的线程数，当系统达到最佳的线程数后，qps会维持不变，rt 变成，随着线程数增加，QPS 开始下降 ，瓶颈可以是CPU,可以是内存，可以是锁资源，IO 资源：超过最佳线程数--导致资源的竞争，超过最佳线程数-响应时间递增。当qps 维持在一个固定值的时候，增大并发数的情况，会导致响应时间增长 (举例：车辆并发通行的时候，不是所有的车通过都是1s ,请求过来需要排队，导致响应时间变大)负载高常见的有硬件或程序问题，如果是软件问题，可能是系统的JAVA线程被长时间占用，大量内存长时间占用。

以下纯属聊聊过去三年在前公司做过的接口测试，没啥特别的技术含量，可能写的会有点乱 ，只是一些流程，测试方法上的简单总结~~ 过去三年也是就职于某电商公司，前公司的测试架构简单可分为 前端和后端 ，测试呢，大概有几百人，前后端测试的比例基本大概为1:3 ；后端基本是纯接口测试，基本不用涉及任何的前端界面操作， 然后前端呢，基本上因为...