做什么事情只要流程对了，出现错误的频率就会少。
要想把事情做好，基本的流程不掌握也是不行，只有在原有的流程基础上加上自己的理解，对流程的某个节点加以重视，然后再进行“改良”，相信好的东西自然会出现。
测试用例通常出现的问题
在测试工作中，最基础的事情也是编写测试用例，通常会遇到以下问题 测试用例直接拷贝需求的某些片段
测试用例描述冗余
层次结构比较混乱
测试用例没有进行及时维护更新
测试用例重复等
有效的测试用例不多
测试覆盖率不足，出现漏测现象严重 你需要明白，“好的”测试用例一定是一个完备的集合，它能够覆盖所有等价类以及各种边界值，而能否发现软件缺陷并不是衡量测试用例好坏的标准。
设计测试用例的方法有很多种，但综合运用等价类划分、边界值分析和错误推测方法，可以满足绝大多数软件测试用例设计的需求。
“好的”测试用例在设计时，需要从软件功能需求出发，全面地、无遗漏地识别出测试需求至关重要。
如果想设计一个“好的”测试用例，你必须要深入理解被测软件的架构设计，深入软件内部的处理逻辑，需求覆盖率和代码覆盖率这两个指标可以帮你衡量测试执行的完备性。
一条测试测试用例关键的点位
输入条件：定义每个测试用例的输入数据，包括正常值、边界值、异常值等。
预期结果：明确每个测试用例执行后应得到的结果，包括成功情况下的输出以及失败情况下的错误信息。
测试步骤：详细描述执行每个测试用例的具体操作步骤。
优先级和重要性：根据测试用例对产品质量的影响程度来分配优先级和重要性等级。
设计测试用例常用的技术
等价类划分：将输入数据划分为几个等价类，从中选取少量代表性的值作为测试数据。
边界值分析：针对输入数据的边界情况进行测试，因为很多错误往往发生在边界上。
因果图法：通过图形化的方式表示输入与输出之间的关系，适用于复杂的逻辑组合测试。
场景法：基于用户的实际使用场景来设计测试用例，特别是对于涉及多个步骤的操作流程。
审查，优化，文档化
组内同行审查，持续改进，使用文档记录详细的测试用例（包括测试用例ID、标题、前提条件、输入数据、测试步骤、预期结果等信息） 对于每一种不同的测试类型，设计出“好的”测试用例的关注点和方法论可能会有很大的差异 。 有些可能采用黑盒方法，有些可能采用白盒方法，有些还会采用灰盒方法，所以很难有一套放之四海而皆准的套路。
如何设计出好的测试用例
所以，在这篇文章中，我仅以最常见、最容易理解的面向终端用户的 GUI测试为例，跟你聊聊如何才能设计一个“好的”测试用例。
面向终端用户的 GUI 测试，最核心的测试点就是验证软件对需求的满足程度，这就要求测试工程师对被测软件的需求有深入的理解。
在我看来，深入理解被测软件需求的最好方法是，测试工程师在需求分析和设计阶段就开始介入，因为这个阶段是理解和掌握软件的原始业务需求的最好时机。
只有真正理解了原始业务需求之后，才有可能从业务需求的角度去设计针对性明确、从终端用户使用场景考虑的端到端的测试用例集。
这个阶段的测试用例设计主要目的是验证各个业务需求是否被满足，主要采用基于黑盒的测试设计方法。
在具体的用例设计时，首先需要搞清楚每一个业务需求所对应的多个软件功能需求点，然后分析出每个软件功能需求点对应的多个测试需求点，最后再针对每个测试需求点设计测试用例。
这个用例设计过程，你可能觉得有点绕，但是没关系，我以“用户登录”功能的测试用例设计为例，画了一张图来帮你理清这些概念之间的映射关系。
下图的业务需求到软件功能需求、软件功能需求到测试需求，以及测试需求到测试用例的映射关系，在非互联网软件企业的实践中，通常会使用需求追踪管理工具(比如 JIRA、TestLink 等)来管理，并以此来衡量测试用例对业务需求、软件功能需求的覆盖率。
图片具体到测试用例本身的设计，有两个关键点需要你注意
一、从软件功能需求出发，全面地、无遗漏地识别出测试需求是至关重要的，这将直接关系到用例的测试覆盖率。比如，如果你没有识别出用户登录功能的安全性测试需求那么后续设计的测试用例就完全不会涉及安全性，最终造成重要测试漏洞。
二、对于识别出的每个测试需求点，需要综合运用等价类划分、边界值分析和错误推测方法来全面地设计测试用例。这里需要注意的是，要综合运用这三种方法，并针对每个测试需求点的具体情况，进行灵活选择。
用例设计的其他经验
除了上面介绍的方法外，我再跟你分享三个独家“秘籍”，希望能够帮你设计出“好的”测试用例集。
一、只有深入理解被测试软件的架构，你才能设计出“有的放矢”的测试用例集，去发现系统边界以及系统集成上的潜在缺陷。
作为测试工程师，切忌不能把整个被测系统看作一个大黑盒，你必须对内部的架构有清楚的认识，比如数据库连接方式、数据库的读写分离、消息中间件 Kafka 的配置、缓存系统的层级分布、第三方系统的集成等等。
必须深入理解被测软件的设计与实现细节，深入理解软件内部的处理逻辑。
二、单单根据测试需求点设计的用例，只能覆盖“表面”的一层，往往会覆盖不到内部的处理流程、分支处理，而没有覆盖到的部分就很可能出现缺陷遗漏。
在具体实践中你可以通过代码覆盖率指标找出可能的测试遗漏点。同时，切忌不要以开发代码的实现为依据设计测试用例。
因为开发代码实现的错误会导致测试用例也出错，所以你应该根据原始需求设计测试用例。
三、需要引入需求覆盖率和代码覆盖率来衡量测试执行的完备性，并以此为依据来找出遗漏的测试点。
