测试需要写测试用例吗？

如何理解软件的质量

我们都知道，一个软件从无到有要经过需求设计、编码实现、测试验证、部署发布这四个主要环节。

需求来源于用户反馈、市场调研或者商业判断。意指在市场行为中，部分人群存在某些诉求或痛点，只要想办法满足这些人群的诉求，且投入产出有差价有利润可赚，就会创造需求。

这些需求经过专业的评估分析和加工设计，就会变成具体的业务需求和对应的产品设计图。然后由专门的研发同学设计实现的技术方案，通过编码来将抽象的业务逻辑变成具体的软件产品功能。

产品功能实现后，交付给测试同学，通过各种方法和手段来验证软件产品具体的功能、性能、安全、交互等特性是否满足产品需求的预期目标。

产品测试验证通过，再交付给专门的运维或者负责线上部署的同学，在生产环境编译打包发布。然后通过产品发布会或者消息推送告知用户，我们提供了什么软件产品，可以满足你们的什么诉求。

这其中的逻辑很简单，服务提供者提供的软件产品，是否满足了用户的需要。通过提供这个软件产品，服务提供者的业务目标是否达成（比如广告投放、平台手续费、增值服务费）。

决定用户使用产品并且不断有更多的用户使用产品的因素，在于用户对产品是否认可，在于用户的量级和留存转化（人越多，成本越容易摊薄，业务场景也越多，商业利润的来源方式就越多）。

这个逻辑就对软件产品本身提出了要求：功能要方便正确，交互要人性化，操作反应要快，信息不能被盗取。与之对应的就是功能的正确性、UI交互的体验、软件的高性能、软件的安全措施。

因此，软件的质量由谁决定呢？由用户使用产品最终导向的业务目标（商业价值）是否达成决定！

测试用例的作用是什么

我们都知道，随着业务复杂性和系统架构复杂性的提升，以及团队人员的变动、需求的迭代和各种配置的变更，软件本身可能会出各种问题，这是一个不断墒增的过程。软件研发交付已经变成了一个特别复杂的团队协作才能完成的巨大工程。

为了控制复杂性不断墒增，为了降低软件可能出问题的风险和影响，为了保证复杂的团队协作可以朝着同一个方向前进，为了保证软件研发交付过程的每个环节都达成预期目标，我们做了哪些事情？

• kickoff：项目启动会，宣讲项目目标，关键里程碑，各角色职责范围；
• 流程规范：约定了在项目研发交付过程中，要遵守的原则，即划定边界。让不同职业背景、技术栈不同的各个角色可以不跑偏，始终朝着同一个方向前进；
• 质量门禁：在软件研发交付的整个过程中，每个环节设定指标。保证从无到有的过程中，每个环节的交付产出物都满足标准（即风险尽可能被降低和接受）；
• 质量度量：通过各种不同维度的数据采集和分析评估，判断最终的交付产出物满足业务预期目标。

其中测试用例的作用是什么？写用例是为了验证本次交付范围尽可能覆盖到，不遗漏，交付部分不出问题或者问题已知风险可接受。是一种在有限的已知范围内，尽可能cover风险的手段。

同样，需求设计环节会有大量的讨论和评审，研发编码阶段的code diff、code review、单元测试，也是这个目的。甚至我们常见的产品验收测试、线上灰度发布的作用还是这个。

测试要不要写测试用例

我个人认为，写不写case，做不做质量门禁之类的都是手段。大部分时候，测试做的工作都是测试环境的质量保障，最终发布上线，交付给用户的使用结果和业务目标是否达成，才是真正的质量。

只不过人总会失误、遗漏，人的能力参差不齐。所有才要写用例，定规范，用各种手段来保证这件事。你会发现，到最后要解决的，还是人的问题。

如何把不同能力、不同认知的人，用一些手段，让他们的认知、能力、水平保持在某个基线之上，督促这些人完成同一件事，达成同一个目的，这才是关键。

过程可控，测试计划，方案，用例，还有日报，周报这些，其实都是为了达成这个目的。质量保障的各种方法和手段，就是提高团队的交付产出物下限。

举一个不太恰当的例子：团队中的各种角色就像羊群，需要头羊（负责人）带领方向；需要牧羊犬（流程规范）时刻督促保证羊群不跑出既定范围不落队；

需要项目管理的手段（里程碑和deadline）来提醒天亮出圈天黑回圈；也需要公司选择合适的草地（业务范围）和天气（市场时机）放牧。