测试用例 Design

背景

目前软件测试趋势逐渐从传统向敏捷过渡，新的测试模式会带来更多挑战，测试人员的能力要求随之也会提升，当然提升的方面不仅仅局限于代码能力(自动化测试是敏捷测试的基础)、工具、框架、平台等等。

用例设计的能力(思维认知)也是重中之重，一切的核心都是人，只有思维认知的整体综合提升才能做到 “以不变应万变”。往往技能是可以很轻易复制和淘汰的，但是思维方式却不会。不要试图想现在学什么、会什么去满足什么，而是要考虑你能够适应什么 ?

但是，由于软件测试门槛偏低，导致大部分测试人员的基础能力比较薄弱，尤其是理论基础( 至于什么原因懂得自然懂)，大部分人往往在自我提升的过程中追求自动化、工具、框架、平台等等相关技术提升。往往忽视了最重要的用例设计，测试用例才是软件测试的基础，所有的测试活动都是需要靠测试用例来开展的.

即使是敏捷测试有一部分声音开始推崇“去用例化”(这里说的去用例化并不是不写用例，而是摒弃了传统写用例文档的方式)，而探索性测试活动依然是敏捷流程中很重要的环节，因此一个测试人员的用例设计能力至关重要。

笔者这里将从白盒测试和黑盒测试两个方面去回顾学习如何结合科学有效的测试方法进行对用例的设计。

一、白盒测试

白盒测试的方法总体上分为静态分析方法和动态分析方法两大类：

• 静态分析：是一种不通过执行程序而进行测试的技术。静态分析的关键功能是检查软件的表示和描述是否一致，有无冲突或者歧义。可以简单理解为 Devops 流程中常用的静态扫描 sonarQube
• 动态分析：是当软件系统在模拟的或真实的环境中执行之前、之中和之后，对软件系统行为的分析。动态分析包含了程序在受控的环境下使用特定的期望结果进行正式的运行。它显示了一个系统在检查状态下是正确还是不正确。开发人员写的单元测试。

白盒测试技术 (White Box Testing) ： 深入到代码一级的测试，使用这种技术发现问题最早，效果也是最好的。该技术主要的特征是测试对象进入了代码内部，根据开发人员对代码和对程序的熟悉程度，对有需要的部分进行在软件编码阶段，开发人员根据自己对代码的理解和接触所进行的软件测试叫做白盒测试。

这一阶段测试以软件开发人员为主，比如在 JAVA 平台使用 Junit 系列工具进行测试， Junit5 目前的功能比较强大感兴趣的可以去尝试一下。

---

二、黑盒测试

从理论上讲，黑盒测试只有采用穷举输入测试，把所有可能的输入都作为测试情况考虑，才能查出程序中所有的错误。实际上测试情况有无穷多个，不仅要测试所有合法的输入，而且还要对那些不合法但可能的输入进行测试。这样看来，完全测试是不可能的，所以我们要进行有针对性的测试，通过制定测试案例指导测试的实施，保证软件测试有组织、按步骤，以及有计划地进行。

黑盒测试行为必须能够加以量化，才能真正保证软件质量，而测试用例就是将测试行为具体量化的方法之一。具体的黑盒测试用例设计方法包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表、正交试验设计法、场景法等。

黑盒测试（ Black Box Testing ）的内容主要还是覆盖全部的功能，可以结合兼容，性能、安全等方面进行，根据软件需求，设计文档，模拟客户场景随系统进行实际的测试，这种测试技术是使用最多的测试技术涵盖了测试的方方面面，可以考虑以下方面：

• 正确性 (Correctness) ：计算结果，命名等方面
• 可用性 (Usability) ：是否可以满足
• 边界条件 (Boundary Condition) ：输入部分的边界值
• 性能 (Performance) ： 正常使用的时间内系统完成一个任务需要的时间，多人同时使用的时候响应时间在可以接受范围内
• 错误恢复 (Error Recovery) ：错误处理的能力，包括突然间断电，输入脏数据等，可以了解一下目前的混沌工程。
• 安全性测试 (Security) ：不仅要考虑本身系统的安全问题还需要考虑业务本身的安全性问题。
• 兼容性(Compatibility) ：不同浏览器，不同应用程序版本在实现功能时的表现。

优缺点

• 黑盒测试的优点：适用于功能测试、可用性测试及可接受性测试;对照说明书测试程序功能;可测试长的、复杂的程序的工作逻辑，易被理解。

• 黑盒测试的缺点：不可能进行完全的、毫无遗漏的输入测试，有一些软件Bug或人为设置的故障通过黑盒测试是无法检测出来的。正是因为黑盒测试的测试数据来自规格说明书，这一方法的主要缺点是它依赖于规格说明书的正确性。实际上，人们并不能保证规格说明书完全正确。如在规格说明书中规定了多余的功能，或是漏掉了某些功能，这对于黑盒测试来说是完全无能为力的。

最后

以上是简单了解了两种测试方法的相关概念，后面会详细针对白盒测试和黑盒测试方法的学习记录。