🍅 点击文末小卡片 ，免费获取软件测试全套资料，资料在手，涨薪更快
本文将从更高一层的维度来讨论测试用例如何能够帮助测试人员进行更好的测试，提升测试用例的价值。
所有测试用例编写的前提，是测试人员足够熟悉业务需求，过分追求设计方法，而忽略了业务本身的诉求，有点本末倒置。测试人员要如何快速熟悉需求呢？主要有以下几个方向。
- 整体把握：结合业务流程图、系统架构图，对业务系统有个整体的感知。知道业务系统的整体业务流向及涉及的系统架构，这样有助于测试人员从大的方向去拉通测试场景，不至于陷入细节中而无法顾及全貌。
- 场景细节：在了解了系统整体的构成之后，就可以根据业务场景，去详细了解业务的流转规则、约束条件及数据流向。业务时序图可以帮助我们更好的了解场景细节，这也是测试用例设计中场景法的基础。在这个环节，需要去实例化业务场景，去梳理数据流向，去弄清楚状态约束。
- 他山之石：可以从过往的测试用例中去了解业务，也可以与其他测试人员、开发人员、产品侧去了解系统，发掘功能背后的业务诉求和演进过程。
- 落地实践：用不同的角色权限，多去尝试、使用系统。去理解哪些场景下会使用到哪些功能，操作是否流畅？数据展示是否合理。很多时候，测试人员喜欢用管理员账号来测试，因为权限足够大，但它往往会忽略掉一些约束条件。多动手，多实践。
好的测试用例设计策略，有助于我们更高效地进行测试，以更少的用例覆盖更多的场景。这也是多数测试用例文章探讨的重点。这里就不具体展开，主要做下归纳。
- 基于业务：ACC建模、流程图、状态机、决策表等，主要用于解决复杂场景下的测试用例设计。等价类、边界值主要用于解决单因素的验证场景。还有针对常见的缺陷模式、典型的错误类型及遇到过的缺陷，进行总结、归纳并逐步形成体系化的错误推测法。同时，需要具备探索性测试思维，基于错误猜测和逻辑推理，整理和分析出更多有针对性的测试关注点。
- 基于技术：异常流测试（数据容错、异步补偿、非法数据等）、高并发测试、组件特性测试（如针对MQ的测试、针对缓存的测试等）
- 基于场景：围绕真实用户的使用场景，进行更多的探索，以第一人称的主观视角进行描述，按照用户使用的自然顺序进行测试用例的设计，贴近用户的真实使用习惯。
以上都是理论的内容，在具体的落地实践中，我们需要分清测试用例的优先级，并注意测试用例的组织方式，综合灵活应用。同时，需要注意以下几个问题：
- 当前的系统状态是什么：是MVP版本、快速迭代中的版本还是稳定运维的版本？根据系统所处的不同阶段，关注系统的质量要求，对测试用例设计进行针对性的取舍
- 用户关注的是什么：用户对象是谁？是侧重于功能交付，还是功能实现？对哪些内容比较敏感，是数据的正确性，还是操作的顺畅性？是稳定性优先，还是新功能优先？需要梳理清楚这些信息，对用户重点关注的内容，进行更多的用例覆盖。
- 如何定义P0（重要）级别的用例：除开迭代内的测试执行，很多时候我们需要提供P0级别的用例给研发做冒烟测试，需要在发版后，做P0级别的测试用例回归等。需要测试人员合理地对测试用例进行分级，不能太多，也不能过少。
好的测试用例，能给团队或者测试人员带来什么价值：笔者认为主要是两方面：
- 一份思维：制定针对当前迭代特性内容的测试策略，通过不同方式的测试建模，输出一份高质量的测试用例，本质上，就是测试人员测试思维的体现，如果你仅仅是顺着开人员人的研发思路进行测试，又或者只是关注产品的需求文档，只进行简单的页面增删改查验证，那是远远不够的。只有你深入了解需求，了解需求的具体使用场景，结合自己的经验和能力，设计出高效的测试用例，才能体现你测试的专业性。
- 一份底线：写用例是为了保障本次交付内容尽可能覆盖、不遗漏，交付内容不出问题或问题已知风险可接受，是一种在有限的已知范围内，尽可能发现风险的手段。也是测试执行时的底线。在迭代中，已有写的测试用例，必须被百分百覆盖（如果有特殊场景未覆盖，需要明确给出原因）。
测试用例不拘泥于表现形式，不论是Xmind、Excel还是各类平台，不论是哪种承载方式，测试用例都需要经过设计，而不是凭经验和直觉进行测试。培养自己的测试思维，是测试人员的基本素养。
最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
这些资料，对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！凡事要趁早，特别是技术行业，一定要提升技术功底。
