0.你也有这样的抱怨？
“我把缺陷都报了，还要写那么长的测试报告，谁看啊？”
“我就想搞自动化开发。你别让我做测试执行就行。太无趣了！”
“我月薪才六七千，老板还让我周末凑空研究 Deepseek？它以后取代我咋办，我亲手把我自己裁掉吗？”
……
“思考测试本质有什么现实意义吗？能帮我多发现几个 Bug 吗？能帮我快点儿达成 KPI 吗？能让我摆脱加班吗？拿到三万月薪吗？”
常见的困惑和抱怨，往往源于我们把自己局限在了 “执行者” 的角色里。
如果尝试以 “思考者” 的角度来重新审视它，也许就会发现更多的可能性和出路。
- 测试之他人的观点
“软件测试是执行程序以发现错误的过程。”——Glenford J. Myers（《软件测试的艺术》）
“测试是评估程序或系统行为是否符合规范的行为。”——Boris Beizer（《软件测试技术》）
“软件测试是对程序执行的过程，以评估软件的质量和/或使其更容易发现问题。”——Cem Kaner（《Testing Computer Software》）
“软件测试是为了提供利益相关者关于测试对象质量信息的一组活动。”——ISO/IEC/IEEE 29119（软件测试国际标准）
“测试是一种调查行为，其目标是揭示关于产品质量的信息。”——James Bach（上下文驱动学派）
“测试是对产品的一种评估过程，通过探索、实验和学习来减少未知。”——Michael Bolton（上下文驱动测试推动者）
看了这么多不同的定义，你可能会感到更加疑惑：“到底哪个是对的？我该听谁的？”
其实，我们不必执着于寻找唯一的标准答案。如何看待测试的价值，可能决定了你更倾向于哪种理解。
2.我眼中的测试
这些年，我尝试从不同维度去理解测试，逐渐形成了更全面的认识。而我认为，这样的认知提升，给了我去改造测试的更多的机会。
软件工程视角： 软件测试是一系列以衡量、评价和改善软件质量为目标的过程、方法、工具和实施组织的有机结合。软件质量是交付成功的核心要素，也是衡量企业竞争力和成熟度的重要依据。测试流程、工具和组织的效能，必须置于整个软件工程和产品生命周期中考量，与其他工程环节密不可分。
经济学视角： 软件测试是企业为降低产品发布后的召回成本与劣质风险，提升经济效益而投资与维护的重要资产。决策层如何配置测试资源，主要基于对发布后质量风险的预判与维持测试团队成本的权衡。
统计学视角： 软件测试是一个基于抽样、假设检验、质量建模与风险预测的软件过程。受限于成本，穷举测试不现实。测试用例的选择本质上是一个抽样过程，旨在验证预设标准或需求。基于有限的测试数据，结合质量模型预测上线风险，指导团队采取行动以达到可接受的质量水平。
心理学视角： 从心理学角度看，软件测试是测试人员及组织在提升产品质量的核心动机驱动下，为寻求用户期望、组织目标与个人发展之间的心理平衡，而采取的一系列社会化行为。它既是基于质量目标的理性实践，也交织着组织期望与个人价值实现的情感诉求。测试行为本身，既是对质量的理性追求，也是在这种驱动力下寻求平衡与价值感的体现。
归根结底，软件测试是一种服务于特定上下文的工程实践。其核心价值在于：保障与提升产品质量、赋能工程团队提效、增强产品市场竞争力。测试方法、流程、工具与技术，本身并非目的，而是服务于在组织内部构建适配其上下文的高效测试实践的手段。因此，评价任何方法、工具或技术的好坏，都必须置于特定组织与特定上下文之中，从多维度视角进行审视。在软件测试领域，没有放之四海皆准的最佳实践，也没有一劳永逸的银弹。
3.思考者的起点
看了他人的观点和我的视角，剩下的就是你了。你可以转过头去，因为它能带来你思维方式的提升。
若视测试仅为找 Bug，难免陷入机械与无序。然而，若将其视为提供决策参考依据，便会思考： “谁是利益相关者？他们最关心什么风险？测试如何最大化价值？如何在组织与个人价值上双赢？”
若测试只是重复执行用例，自然困于低效加班。然而，若将其理解为一种抽样与假设检验过程，便会思考： “测试工具选择、计划制定、流程优化…这些能力提升需数据支撑。我该设计哪些实验来验证和呈现这些实践？”
若测试只是开发自动化，自然担忧被 AI 取代。然而，若认识到其经济学本质——降低召回成本与劣质风险，便会思考： “自动化开发真正惠及谁？我在其中的独特价值是什么？我的工作如何服务于企业成本控制的终极目标？”
这种从 “执行” 到 “思考” 的转变，是职业发展的关键一步。 它让我们能识别系统风险、设计关键测试、帮助团队做出更明智的决策。这直接决定了你能否从初级测试工程师逐步成长为测试分析师、测试架构师，甚至质量负责人。
4.思考者的探索之路
测试的成长没有捷径： 需要在项目中积累经验，在挑战中磨炼能力，并通过不断反思，逐步构建自己的测试认知体系。
这条路不容易，但每一步都让你更清楚自己的方向，技术能力更扎实，对质量的理解更深刻。
不必追求唯一的正确答案，也无需迷信权威。 测试的本质，是在你自己的实践、试错和思考中逐渐清晰的。
最终，你会发现： 测试不仅是发现问题，更是帮助组织做好决策；不仅是技术活，更是认知、沟通和判断力的综合体现。“执行者” 和 “思考者” 的差距，不仅在经验多少，更在于是否愿意停下来，想清楚你手中 “测试” 这把工具，到底该指向何方。
不必完全照搬别人的定义，也不必拘泥于我的观点。
能把测试的精髓融入思维和行动，运用自如，达到 “手中无剑，心中有剑” 的境界，这才是测试的技艺之本。
望你在成为 “思考者” 的路上，走得越来越稳，越来越从容。
张昊翔
2025/06/10
WeChat: hzhan11
QQ: 22321262
Email: xjtu_xiangxiang@hotmail.com
LinkedIn: https://www.linkedin.com/in/hzhan11/
也就 tm 测试天天思考自己存在的价值。。。
不过质疑自己存在的价值是件好事，说明拿比干的多，哈哈
赚钱的工具而已，可以为多赚钱精进技术，过了 30 之后发现啥价值不价值的，公司里年终奖最高的是写 PPT 的，原本做技术的都赶着去给老板写 PPT 糊弄上层傻子去了，做不了舔狗，技术再牛也是不能保证你的绩效。当然幸运的人可能遇到好领导，但是实在太少了。
当然楼主说的也有道理，总得给自己打点鸡血，给自己一个相信自己做的事情的理由，加油吧。
想起很多年前，我做部门的测试故障分析。
我觉得我提的都是技术上可以去尝试的点，为什么一到执行就推不下去，一到稍微需要思考的点，下面就各种反对，上面就不断的和稀泥。
后来不断的做不同的研发角色，大中小厂换了一遍，吃了 n 次亏后，哎，都是人性。
--国内不缺人，尤其不缺所谓的技术人士，思考有个锤子用。
国外一个人的成本，国内可以找 10 个测试，国外 965，国内 996。
就算再差，我用 20 倍的时间大概率总比你产出多。玩个锤子。
magicyang
回复
我觉得我提的都是技术上可以去尝试的点，为什么一到执行就推不下去，一到稍微需要思考的点，下面就各种反对，上面就不断的和稀泥。--------------------------确实如此，你的想法，让别人接受并且愿意去做，确实不容易。换位思考一下，你凭什么就相信我在上面的文章中说东道西半天呢？坚持自己认为自己正确的事情，与别人共赢，测试领域和其他领域都一样。
krystalzz
回复
想象为什么 PPT 别人可以写出来，讲出来呢？你看看测试开发大会，最后不都是通过 PPT 传递知识和分享经验吗？
我也赞成让大家做舔狗，职场 PUA。但是，想想公司掏钱为什么雇你去上班，你的价值呢，给公司给别人给社会，当然也是给自己？公司凭什么就花更多的钱找你老板带领你去向上 “糊弄” 呢？你知道老板真的动机是什么吗？
只想做自己，可以选择远离这个纷争和社会契约。或者自己创造符合个人价值观的社会规则，让别人遵守。这些都是很好的出路。
krystalzz
回复
其实做过管理的都知道的，不是 PPT 发挥作用，PPT 只是给老板或者大领导留印象的，真正有用的是底下的人做功劳都归功到我身上了
，你技术再牛，最终做的成果都会归到我身上，因为纸面上就是我带头。然后你们的功劳成果结算，是由我这边结算的
44岁的测试小学生
回复
我并不是支持现在公司这种风气，只是对现实的无奈，我也希望大家抱着赤忱去进入这个行业，但是现实并不是抱着赤忱之心就行了，我见过很多技术很好的人，但是就是因为不够舔，得不到领导的赏识，利用完就丢弃，这种风气真的让人心痛，但是也是无力改变。
看完有一个感觉，楼主想必是个写 PPT 的好手，没有贬义的意思
引用文本：国内公司加班可以在三个月内造出一台新能源车。质量在速度面前失去了它的地位，这或许都是机会主义在作祟。
国内测试现状还是因为这个，速度和效率优先。开发、产品、销售都是可以快速且看的见的产出。测试环节无法直观的看到产出，顶多能看到测试用例、BUG、测试情况，但是这些都是过程，没有产生结果和产出数据。其他的产出都得 PPT 才能体现，但是测试做的这些带不来面向客户的产品、现金收益。领导为了能快速抢市场，只能选择放弃质量。新能源汽车、AI 产品、定制化服务皆如此。
测试的本质就四个字 “找 bug”
补充一句，如果新能源汽车从生产出第一批车到正式交付到用户，必须经过 2 年上路测试和 1 年安全测试。不然不允许上市，我想汽车质量都会有质的提高。恰好这些都是测试做的事情，领导能够同意吗？
Vanessa
回复
对的，应该让开发也思考下价值，现在的开发都不用细细分析需求的，总是等着测试给他用例分析， 有问题了也总是在等待测试的决策改或者不改？？
dun
回复
可以通过 24 小时不间断测试，把 1 年的时间变成 4 个月。
也是一种办法。。。
可以了解了解，细节我还不了解。。。
划水这么久，第一次提交评论，我觉得楼主写的挺好的，我提一些单纯自己个人的想法，有不足欢迎大家帮忙指出
并不是测试闲的没事情干要去找自己的存在感，而是国内的研发现状，除个别公司外，测试最终沦为打杂；当然，咱们也可以什么都不干，也可以试着去改变现状，但是想要改变得先明白自己职能范围，职能的产出以及重要性，做了总比不做强，不管是 it 还是传统行业，都是追求效大于质，但是我们测试在保障质的同时，还默默付出了很多，也产出了很多，只是公司和我们自身都没有意识到这点罢了，当你开始意识到这点，就可以思考怎么改变自己的现状，改变在公司的现状了
再补充一点，售前、市场、销售人员、售后的价值不用赘述，产品、ui、ux 和开发都有实际的产出，唯独测试的产出最无法量化，测试设计，测试用例，测试报告这些和盈利也不挂钩，测试成果也不好衡量，1w 和 2w 的测试产出看似区别不大，入门上手最简单，面试候选人甄别人才最抽象等等各种因素，导致了从业人员稂莠不齐，更加导致测试地位低下，测试不紧紧东一个技术西一个技术的乱学，有的人不懂代码，但是比测开更懂自动化平台和自动化测试，只有真正懂得思考的测试，才能更好的学以致用，在公司有更多的话语权
ps：我当初不懂代码时，专程招了一位 java 开发转测试的同学来做基于公司现有的 java 自动化框架的自动化，基本都是我指导他写脚本的思路
经济学视角： 软件测试是企业为降低产品发布后的召回成本与劣质风险，提升经济效益而投资与维护的重要资产。决策层如何配置测试资源，主要基于对发布后质量风险的预判与维持测试团队成本的权衡。
这个理解到位，这也是为什么有些公司不需要测试或者弱化测试岗位职能的原因。
然而从结果反推，发布的产品召回风险又存在不可控的情况（比如国内近几年大厂出现的宕机、弹窗、全量国补优惠等），就个体而言本着拿钱办事的原则即可。
一代人
回复
嗯，如果想改变自己的生存现状，要想想这样的现状是谁造成的，为什么会这样。
作为执行者，当然容易，也容易被替代。
你想明白领导为什么 PUA 你，就能处变不惊，而不是任由他们去 PUA 你，任由组织的现状持续。
持续保持改变现状的愿景，是所有领导都乐于看到的，抓住一两次机会你就上去了。
dun
回复
说个国外的事情。最近这几天，苹果因为 Siri 误唤醒的 bug，遭到集体诉讼。在北美生活的每个人，都可以提交一个申请赔偿的 ticket，每台设备获得 10 刀的补偿。这就是法规和市场作用的表现。
而在国内，一些至关重要的的领域，嵌入式、金融、医疗、基础架构等等，产品召回成本和劣质质量风险依旧是企业无法承担的，在这些领域做测试你还是保守和渐进性的。
现在有 “质量让位速度”，只能是大多数情况下的现状，这也反向说明 “互联网” 行业代表了大众的喉舌。当然，国人的消费习惯也造成了这种现状。
测试小学生
回复
你说的这个慢慢沦为为资本服务的产物了，某铺子、4 轮电动车，这些行业的立法方还是各个企业派进去成立的。行政立法通过什么方式去做？仍然是检测、成分检测、添加剂检测、有害物质检测、碰撞系统检测、车框架压力检测、防火灭火系统检测、水浸检测、部件老化检测、行驶参数检测、等等。国内的车企、食品为什么总出问题？还不是立法执行不到位或者无法可依。
magicyang
回复
你说的是虚拟真实场景进行检测吗？大多数模拟的真实场景虽然能用，但是准确性存疑，不然也不会在对外宣传上加几个字：“理论”，实际数据大多数时候都比理论数据低。
行业乱象：劣币驱逐良币的恶性循环
高层决策导向：利润至上，质量靠边
只关注市场份额和短期投资回报，对技术积累和产品质量缺乏重视。
投标逻辑：不论实际能力，先靠 PPT 抢标，抢到后再想办法 “凑合交付”。
结果：真正深耕技术的企业因成本高、周期长，反而难以生存。项目执行：层层转包，质量崩坏
“先抢标，再凑合”：抢到项目后，先推出阉割版产品应付交付，后期再扯皮维护。
“包中包中包”：多次转包导致成本压缩、责任模糊，最终交付质量极差。
工资内卷：底层执行方利润被挤压，从业者薪资越来越低，行业人才流失。行业生态：劣币驱逐良币
投机型企业靠低价和忽悠抢占市场，技术型企业因成本劣势被边缘化。
客户受害：短期拿到低质产品，长期面临维护难、升级难的问题。
行业倒退：创新动力下降，整体技术水平停滞甚至退化。
可能的出路？
政策监管：设立更严格的投标审核机制，防止 “PPT 骗标”。
行业自律：头部企业带头拒绝恶性竞争，建立技术壁垒。
客户觉醒：优先选择有技术沉淀的供应商，而非 “低价低质” 方案。
总结：如果继续 “重营销、轻技术”，最终整个行业都会为短视行为买单。劣币或许能一时得利，但良币的消失会让所有人无路可走。
哈哈哈，ai 排版后看起来高级多了
如何向 AI 学习精准表达？
结构化逻辑
AI 的回答通常遵循「结论先行→分点阐述→总结」的结构。
你的练习示例：
✨ 原句：
"我今天遇到一个问题，就是报告写不完，因为数据太多，而且格式还乱了，同事也没帮我。"
✨ 优化后：
"我需要协助：报告因数据量过大和格式混乱可能延迟提交，能否协调同事支持？"
删减冗余词
删除「其实」「可能吧」等模糊词，直接指向问题核心。
对比：
❌ "我其实觉得这个方案可能不够好。"
✅ "方案存在三个风险点：1... 2... 3..."
用 SCQA 模型（情境 - 冲突 - 问题 - 答案）
案例：
S（背景）：本周需提交客户方案；
C（冲突）：但关键数据缺失；
Q（问题）：如何 48 小时内补齐数据？
A（答案）：申请跨部门调取历史数据。
非常赞成