携程内部的测试用例是如何设计的？

在跟大家讲解测试用例之前，首先想要问大家对一个“好的”的测试用例中的“好”是怎么定义的？可能对一些才接触的同学来说，那个“好”可能只是需要它运行起来就可以了，其实不然，接下来跟大家讲解一下“好的”测试用例是什么？如何去做一个“好的”测试用例？

一、什么是“好的”测试用例

“好的”测试用例一定是一个完备的集合，它能够覆盖所有等价类以及各种边界值，而跟能否发现缺陷无关。
举个例子：
如果把被测试软件看作一个池塘，软件缺陷是池塘中的鱼，建立测试用例集的过程就像是在编织一张捕渔网。“好的”测试用例集就是一张能够覆盖整个池塘的大渔网，只要池塘里有鱼，这个大渔网就一定能把鱼给捞上来。
如果渔网本身是完整的且合格的，那么捞不到鱼，就证明池塘中没有鱼，而渔网的好坏与池塘中是否有鱼无关。

二、好在哪里

1、整体完备性，即能够尽可能的覆盖测试需求。
2、等价类划分的完备性，是指对于每个等价类都能保证只要其中一个输入测试通过，其他输入也一定测试通过。
3、等价类集合的完备性，需要保证所有可能的边界值和边界条件都已经正确识别。

三、3种最常用的测试用例设计方法

1、等价类划分
即等价类中任意一个输入数据对于揭露程序中潜在错误都具有同等效果。后续我们只要从每个等价类中任意选取一个值进行测试，就可以用少量具有代表性的测试输入取得较好的测试覆盖结果。
以“用户登录”用户名为例，用户名长度最少5位，最长11位，可以是大小写字母、数字、大小写字母数字混合。
那么我们就可以使用任意的大小写字母、数字，长度限制在5-11位进行混合测试。如“a1514918722”、“123abcD12”，这样就构成了所谓的“有效等价类”。但等价类划分的关键点是要找出所有的“无效等价类”。
综上，考虑了无效等价类以后，测试用例可以设计为：

• 有效等价类1：11位纯数字组合
• 有效等价类2：11位纯大小写混合字母组合
• 有效等价类3：11位字母数字混合组合
• 有效等价类4：大于5小于11位字母数字混合组合
• 无效等价类1：长度超过11位
• 无效等价类2：长度小于5位
• 无效等价类3：包含特殊字符组合
  2、边界值分析
  边界值分析是对等价类划分的补充，你从工程实践经验中可以发现，大量的错误发生在输入输出的边界值上，所以需要对边界值进行重点测试，通常选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据。
  继续上面用户名输入的例子，边界值划分可以是：用户名长度4位、5位、6位、10位、11位、12位
  3、错误推测
  错误推测方法是指基于对被测试软件系统设计的理解、过往经验以及个人直觉，推测出软件可能存在的缺陷，从而有针对性地设计测试用例的方法。这个方法强调的是对被测试软件的需求理解以及设计实现的细节把握，当然还有个人的能力。
  错误推测方法很那系统化，更多依赖测试人员的个人能力，在实践中，为了降低对个人能力的依赖，通常会建立常见缺陷知识库，在测试设计的过程中，会使用缺陷知识库作为检查点列表（checklist），去帮助优化补充测试用例的设计。
  如果对软件测试、接口测试、自动化测试、面试经验交流感兴趣可以加软件测试交流：1085991341，会有不定期的发放免费的资料链接，还会有同行一起技术交流。

四、如何设计出好的测试用例？

一句话概括：对被测软件的需求有深入的理解。
深入理解被测软件需求的最好方法是，测试工程师在需求分析和设计阶段就开始介入，因为这个阶段是理解和掌握软件的原始业务需求的最好时机。

只有真正理解了原始业务需求之后，才有可能从业务需求的角度去设计针对性明确、从终端用户使用场景考虑的端到端（End-2-End）的测试用例集。

在具体的用例设计时，首先需要搞清楚每一个业务需求所对应的多个软件功能需求点，然后分析出每个软件功能需求点对应的多个测试需求点，最后再针对每个测试需求点设计测试用例。

具体到测试用例本身的设计，有两个关键点需要你注意：

1. 从软件功能需求出发，全面地、无遗漏地识别出测试需求是至关重要的，这将直接关系到用例的测试覆盖率。 比如，如果你没有识别出用户登录功能的安全性测试需求，那么后续设计的测试用例就完全不会涉及安全性，最终造成重要测试漏洞。
2. 从软件功能需求出发，全面地、无遗漏地识别出测试需求是至关重要的，这将直接关系到用例的测试覆盖率。 比如，如果你没有识别出用户登录功能的安全性测试需求，那么后续设计的测试用例就完全不会涉及安全性，最终造成重要测试漏洞。

测试用例设计经验

1. 只有深入理解被测试软件的架构，你才能设计出“有的放矢”的测试用例集，去发现系统边界以及系统集成上的潜在缺陷。
   作为测试工程师，切忌不能把整个被测系统看作一个大黑盒，你必须对内部的架构有清楚的认识，比如数据库连接方式、数据库的读写分离、消息中间件Kafka的配置、缓存系统的层级分布、第三方系统的集成等等。【也就是说你要有一定的代码读写能力】

2. 必须深入理解被测软件的设计与实现细节，深入理解软件内部的处理逻辑。
   单单根据测试需求点设计的用例，只能覆盖“表面”的一层，往往会覆盖不到内部的处理流程、分支处理，而没有覆盖到的部分就很可能出现缺陷遗漏。在具体实践中，你可以通过代码覆盖率指标找出可能的测试遗漏点。
   同时，切忌不要以开发代码的实现为依据设计测试用例。因为开发代码实现的错误会导致测试用例也出错，所以你应该根据原始需求设计测试用例。

3. 需要引入需求覆盖率和代码覆盖率来衡量测试执行的完备性，并以此为依据来找出遗漏的测试点。

以上内容希望对你有帮助，有被帮助到的朋友欢迎点赞，评论。