01 测试不是为了找bug，而是为了建立信任
大多数人误解了测试。他们认为测试的唯一产出是bug。事实是，bug只是测试过程中的副产品。测试的核心目标，是评估软件的质量并增强对软件的信心。
当你测试一个登录模块时，输入20组不同密码，发现密码框能接受100位字符——这算是bug吗？不一定。如果需求规定密码只需支持16位，这确实是个缺陷。但如果需求没写，这就是个边界值测试。你以为你在找bug，实际你是在确认“这个功能在多大范围内，能稳定运行”。
测试是最后一双眼睛，但不是唯一的一双。
一个经典的案例：某电商App在上线前，测试团队执行了2000个测试用例，发现了300个bug。开发修复了299个，剩下1个是“字体显示偏大”。开发说“这是用户手机设置问题，不是bug”。测试坚持“用户感知就是问题”。最终，产品经理裁定“修复”。上线后，这个“修复”导致首页布局错位，影响40%用户。谁错了？没人错。测试的职责是发现差异，产品的职责是判断差异是否可接受。
测试不是找茬，是提供决策依据。
02 软件测试的经典定义：验证与确认
教科书里，测试的定义分两层：验证和确认。验证是“做得对不对”，确认是“做对了没有”。
验证问的是：我是否正确地建造了产品？例如，一个计算器程序，需求说“两个数相加”。你输入“2+3=5”，结果正确，这是验证。确认问的是：我造的是正确的产品吗？用户需要的计算器，要能算“2+3=5”，还要能算“2+3+4=9”，还要能处理负数、小数、科学计数法。如果需求漏了这些，你验证得再完美，用户也会骂“这个计算器是垃圾”。
验证确保代码没写错，确认确保需求没写漏。
现实中，测试团队往往把90%的精力放在验证上，只拿出10%做确认。一个金融系统，验证了所有交易逻辑，却没确认“用户是否真的需要这么复杂的交易流程”。结果上线第一个月，用户流失率30%。为什么？因为用户要的是“一键转账3步完成”，系统却要求“填写5个字段+2次确认”。你验证了“字段填写正确、确认流程完整”，但用户觉得“这产品有病”。
真正的好测试，在验证开始前，先用确认问一遍产品经理：我们造的东西，用户真的需要吗？
03 测试用例：测试的基本单元
测试用例是测试工作的最小单元。一个完整的测试用例包含：前提条件、输入数据、执行步骤、预期结果、实际结果。
你的公司可能用Excel写用例。为什么？因为Excel够灵活，能追踪、能统计。一个成熟的项目，测试用例数量通常是代码行数的1/3到1/10。一个登录功能，6行代码，你得写50个测试用例。因为要覆盖：正常登录、错误密码、空输入、特殊字符、SQL注入、跨站脚本、不同浏览器、不同分辨率、网络超时、并发登录……50个用例算少的。
测试用例不是写给机器看的，是写给下一个人看的。
我见过新手写用例：“测试用户名正确、密码正确的场景”。文字描述10个字，预期结果写着“登录成功”。这简直是灾难。正确的写法是：前提条件：用户已注册、数据库正常。输入数据：用户名“test@abc.com”，密码“Abc@123”。执行步骤：打开登录页，输入用户名，输入密码，点击登录按钮。预期结果：页面跳转到首页，页面右上角显示用户头像和用户名。看到了吗？预期结果要具体到像素级。
测试用例写得多烂，你的测试结果就有多烂。
04 通过vs失败：结果背后的决策逻辑
测试执行完，你会得到两个结果：通过或失败。但这不是终点。失败用例需要分析原因：是bug？是环境问题？是测试数据不对？还是用例写错了？
一个电商系统，支付测试失败。你以为是支付接口bug。排查后，发现是测试环境网络延迟，导致请求超时。这是环境问题，不是产品缺陷。你应该记录“环境不稳定”，而不是“支付功能异常”。否则，开发员会花2小时查代码，最后骂你“浪费我时间”。
一次失败的测试，可能是十次机会的开端。
有数据显示，在一个中型项目里，30%的失败用例最终被证明不是bug。这些“假阳性”案例，是测试成本的最大来源。你的公司每周跑2000个自动用例，600个失败。其中180个是环境问题、数据问题或用例问题。去掉180个假阳性，实际bug只有420个。这420个里，严重级别的只有50个。这就是测试的真相：90%的测试结果，都在告诉你“没问题”。你真正要找的，是那10%的有问题中的1%。
不要迷恋测试覆盖率。100%的用例通过率不意味着软件可用，0%的通过率却可能意味着环境瘫痪。
---
测试的底层逻辑，从不是为了证明软件正确，而是为了证明“在有限的成本内，软件的错误率降到可接受水平”。市场不养闲人。要么亲手创建价值，要么亲手量度价值。没有第三条路。
测试不是终点，是起点。每一次执行，都在为你搭建信任的阶梯。
京公网安备
11010802035719号