测试需要写测试用例吗?

简介: 测试需要写测试用例吗?

昨天下午星球群里有同学发了一段话,引起了很多同学的讨论。这段话是这样的:测试用例主要作用:有效地评估软件的质量,测试用例质量体现了测试的质量。下面摘取一部分同学的观点:

  • 评估软件质量应该看测试报告之类的结果;
  • 测试用例主要作用是确定测试范围和测试场景;
  • 这句话没毛病,除非你没按照测试用例好好执行;
  • 评估软件质量最有发言权的应该是用户和软件的实际使用者;

他们说的对吗?我个人认为不全对。但他们说错了吗?也不见得。视角不同,出发点不同,观点不同。这篇文章,我想聊聊我对于测试用例的观点,以及软件的质量到底由什么决定。

如何理解软件的质量

我们都知道,一个软件从无到有要经过需求设计、编码实现、测试验证、部署发布这四个主要环节。需求来源于用户反馈、市场调研或者商业判断。意指在市场行为中,部分人群存在某些诉求或痛点,只要想办法满足这些人群的诉求,且投入产出有差价有利润可赚,就会创造需求。这些需求经过专业的评估分析和加工设计,就会变成具体的业务需求和对应的产品设计图。然后由专门的研发同学设计实现的技术方案,通过编码来将抽象的业务逻辑变成具体的软件产品功能。产品功能实现后,交付给测试同学,通过各种方法和手段来验证软件产品具体的功能、性能、安全、交互等特性是否满足产品需求的预期目标。产品测试验证通过,再交付给专门的运维或者负责线上部署的同学,在生产环境编译打包发布。然后通过产品发布会或者消息推送告知用户,我们提供了什么软件产品,可以满足你们的什么诉求。这其中的逻辑很简单,服务提供者提供的软件产品,是否满足了用户的需要。通过提供这个软件产品,服务提供者的业务目标是否达成(比如广告投放、平台手续费、增值服务费)。决定用户使用产品并且不断有更多的用户使用产品的因素,在于用户对产品是否认可,在于用户的量级和留存转化(人越多,成本越容易摊薄,业务场景也越多,商业利润的来源方式就越多)。这个逻辑就对软件产品本身提出了要求:功能要方便正确,交互要人性化,操作反应要快,信息不能被盗取。与之对应的就是功能的正确性、UI交互的体验、软件的高性能、软件的安全措施。因此,软件的质量由谁决定呢?由用户使用产品最终导向的业务目标(商业价值)是否达成决定

测试用例的作用是什么

我们都知道,随着业务复杂性和系统架构复杂性的提升,以及团队人员的变动、需求的迭代和各种配置的变更,软件本身可能会出各种问题,这是一个不断墒增的过程。软件研发交付已经变成了一个特别复杂的团队协作才能完成的巨大工程。为了控制复杂性不断墒增,为了降低软件可能出问题的风险和影响,为了保证复杂的团队协作可以朝着同一个方向前进,为了保证软件研发交付过程的每个环节都达成预期目标,我们做了哪些事情?

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

其中测试用例的作用是什么?写用例是为了验证本次交付范围尽可能覆盖到,不遗漏,交付部分不出问题或者问题已知风险可接受。是一种在有限的已知范围内,尽可能cover风险的手段同样,需求设计环节会有大量的讨论和评审,研发编码阶段的code diff、code review、单元测试,也是这个目的。甚至我们常见的产品验收测试、线上灰度发布的作用还是这个。

测试要不要写测试用例

我个人认为,写不写case,做不做质量门禁之类的都是手段。大部分时候,测试做的工作都是测试环境的质量保障,最终发布上线,交付给用户的使用结果和业务目标是否达成,才是真正的质量。只不过人总会失误、遗漏,人的能力参差不齐。所有才要写用例,定规范,用各种手段来保证这件事。你会发现,到最后要解决的,还是人的问题。如何把不同能力、不同认知的人,用一些手段,让他们的认知、能力、水平保持在某个基线之上,督促这些人完成同一件事,达成同一个目的,这才是关键。测试用例只是测试思维的一个载体,它指导着测试活动的进行,是测试执行的最低保障。过程可控,测试计划,方案,用例,还有日报,周报这些,其实都是为了达成这个目的。质量保障的各种方法和手段,就是提高团队的交付产出物下限。举一个不太恰当的例子:团队中的各种角色就像羊群,需要头羊(负责人)带领方向;需要牧羊犬(流程规范)时刻督促保证羊群不跑出既定范围不落队;需要项目管理的手段(里程碑和deadline)来提醒天亮出圈天黑回圈;也需要公司选择合适的草地(业务范围)和天气(市场时机)放牧。

最后分享一句我很喜欢的话:目标固然重要,行动才是灵魂。而正确的目标+合理可行的行动方式+高效协作的团队才是这一切的核心。

相关文章
|
1月前
|
测试技术 Python
自动化测试项目学习笔记(三):Unittest加载测试用例的四种方法
本文介绍了使用Python的unittest框架来加载测试用例的四种方法,包括通过测试用例类、模块、路径和逐条加载测试用例。
62 0
自动化测试项目学习笔记(三):Unittest加载测试用例的四种方法
|
2月前
|
测试技术
测试用例设计方法之基本路径测试法
基本路径测试法是在程序控制流图的基础上,通过分析控制构造的环路复杂性,导出基本可执行路径集合,从而设计测试用例的方法,设计出的测试用例要保证在测试中程序的语句覆盖100%,条件覆盖100%
113 7
测试用例设计方法之基本路径测试法
|
2月前
|
测试技术 数据库
『软件测试2』 关于黑盒测试和测试用例的基础知识
该文章讲解了黑盒测试的基本概念以及如何编写有效的测试用例,包括选择合适的输入数据、预期结果的设定和测试执行的步骤。
|
3月前
|
测试技术
测试与开发问题之测试用例设计的重点是什么,如何实现
测试与开发问题之测试用例设计的重点是什么,如何实现
|
2月前
|
测试技术 数据安全/隐私保护
软件测试的艺术:如何高效地编写测试用例
【9月更文挑战第2天】在软件开发的海洋中,测试用例是导航灯塔,指引着质量保障的航向。本文将带你航行于测试用例编写的技巧之海,从理解需求到设计思路,再到实际执行,我们将一起探索如何高效而精准地构建测试用例,确保软件的稳健与可靠。
65 0
|
3月前
|
Java 测试技术 API
SpringBoot单元测试快速写法问题之计算测试用例的分支覆盖率如何解决
SpringBoot单元测试快速写法问题之计算测试用例的分支覆盖率如何解决
|
4月前
|
测试技术
单元测试策略问题之寻找边界问题如何解决
单元测试策略问题之寻找边界问题如何解决
|
4月前
|
测试技术
软件交付问题之为什么测试用例不能全由开发人员告知测试人员
软件交付问题之为什么测试用例不能全由开发人员告知测试人员
|
6月前
|
Web App开发 测试技术 数据安全/隐私保护
软件测试: 测试用例
软件测试: 测试用例
|
4月前
|
测试技术 开发工具 git
后端测试,好的建议,后端测试----Postman如何创建项目,导入测试用例和测试集,注意对测试用例进行保存,格式用测试用例---xxx测试用例
后端测试,好的建议,后端测试----Postman如何创建项目,导入测试用例和测试集,注意对测试用例进行保存,格式用测试用例---xxx测试用例