如何让测试用例更有价值

01

所有测试用例编写的前提，是测试人员足够熟悉业务需求，过分追求设计方法，而忽略了业务本身的诉求，有点本末倒置。测试人员要如何快速熟悉需求呢？主要有以下几个方向。

整体把握：结合业务流程图、系统架构图，对业务系统有个整体的感知。知道业务系统的整体业务流向及涉及的系统架构，这样有助于测试人员从大的方向去拉通测试场景，不至于陷入细节中而无法顾及全貌。

场景细节：在了解了系统整体的构成之后，就可以根据业务场景，去详细了解业务的流转规则、约束条件及数据流向。业务时序图可以帮助我们更好的了解场景细节，这也是测试用例设计中场景法的基础。在这个环节，需要去实例化业务场景，去梳理数据流向，去弄清楚状态约束。

他山之石：可以从过往的测试用例中去了解业务，也可以与其他测试人员、开发人员、产品侧去了解系统，发掘功能背后的业务诉求和演进过程。

落地实践：用不同的角色权限，多去尝试、使用系统。去理解哪些场景下会使用到哪些功能，操作是否流畅？数据展示是否合理。很多时候，测试人员喜欢用管理员账号来测试，因为权限足够大，但它往往会忽略掉一些约束条件。多动手，多实践。

02

好的测试用例设计策略，有助于我们更高效地进行测试，以更少的用例覆盖更多的场景。这也是多数测试用例文章探讨的重点。这里就不具体展开，主要做下归纳。

基于业务：ACC建模、流程图、状态机、决策表等，主要用于解决复杂场景下的测试用例设计。等价类、边界值主要用于解决单因素的验证场景。还有针对常见的缺陷模式、典型的错误类型及遇到过的缺陷，进行总结、归纳并逐步形成体系化的错误推测法。同时，需要具备探索性测试思维，基于错误猜测和逻辑推理，整理和分析出更多有针对性的测试关注点。

基于技术：异常流测试（数据容错、异步补偿、非法数据等）、高并发测试、组件特性测试（如针对MQ的测试、针对缓存的测试等）

基于场景：围绕真实用户的使用场景，进行更多的探索，以第一人称的主观视角进行描述，按照用户使用的自然顺序进行测试用例的设计，贴近用户的真实使用习惯。

03

以上都是理论的内容，在具体的落地实践中，我们需要分清测试用例的优先级，并注意测试用例的组织方式，综合灵活应用。同时，需要注意以下几个问题：

当前的系统状态是什么：是MVP版本、快速迭代中的版本还是稳定运维的版本？根据系统所处的不同阶段，关注系统的质量要求，对测试用例设计进行针对性的取舍

用户关注的是什么：用户对象是谁？是侧重于功能交付，还是功能实现？对哪些内容比较敏感，是数据的正确性，还是操作的顺畅性？是稳定性优先，还是新功能优先？需要梳理清楚这些信息，对用户重点关注的内容，进行更多的用例覆盖。

如何定义P0（重要）级别的用例：除开迭代内的测试执行，很多时候我们需要提供P0级别的用例给研发做冒烟测试，需要在发版后，做P0级别的测试用例回归等。需要测试人员合理地对测试用例进行分级，不能太多，也不能过少。

04

好的测试用例，能给团队或者测试人员带来什么价值：笔者认为主要是两方面：

一份思维：制定针对当前迭代特性内容的测试策略，通过不同方式的测试建模，输出一份高质量的测试用例，本质上，就是测试人员测试思维的体现，如果你仅仅是顺着开人员人的研发思路进行测试，又或者只是关注产品的需求文档，只进行简单的页面增删改查验证，那是远远不够的。只有你深入了解需求，了解需求的具体使用场景，结合自己的经验和能力，设计出高效的测试用例，才能体现你测试的专业性。

一份底线：写用例是为了保障本次交付内容尽可能覆盖、不遗漏，交付内容不出问题或问题已知风险可接受，是一种在有限的已知范围内，尽可能发现风险的手段。也是测试执行时的底线。在迭代中，已有写的测试用例，必须被百分百覆盖（如果有特殊场景未覆盖，需要明确给出原因）。

05

测试用例不拘泥于表现形式，不论是Xmind、Excel还是各类平台，不论是哪种承载方式，测试用例都需要经过设计，而不是凭经验和直觉进行测试。培养自己的测试思维，是测试人员的基本素养。