软件质量的双保险——设计验证与软件测试

提到对软件的质量检查，马上想到的是“软件测试”，软件测试的目的主要是检查“开发程序”是否符合“软件设计”的要求，程序中是否有bug等，也就是说软件测试是检查完成软件“是否满足设计要求”的工作。

完成一款好的软件首先要做到的是“软件设计”是正确的、优秀的，如果软件设计没有做到正确和优秀，后面程序编写的质量再好也没有价值，设计是保证软件正确和优秀的前提和基础。

那么如何判断软件设计的结果是正确的、优秀的呢就要用到“设计验证”的方法，设计验证包括了“业务设计验证”和“应用设计验证”两个部分。

下面重点谈一下关于设计验证的方法（软件测试已有非常多的资料可以参考，省略）。

一、关于设计验证

这里以设计企业信息系统的为例来说明设计验证存在的意义。

大多数具有一定规模的企业信息系统都是定制的（因为没有二家企业的经营管理模式是完全相同的），定制型系统不能像产品型系统一样可以通过不断地改进、完善、提升，每个系统都是唯一的存在。

因此，要想做到系统上线后不再进行大规模地返工、改造，就要尽可能地在投入开发前就通过验证以获得客户对设计的认可。在进行详细说明前先谈两个关于软件设计验证的问题。

1. 为什么要对设计结果进行验证呢/strong>

做过软件的人（不论需求、设计、开发或是测试），都直接或间接地听过这样的事：开发前与客户确认了需求、并且客户也在确认书上签字了，可系统上线后一试用，客户经常会抱怨说：

1）抱怨举例1

• 这个系统不是我想要的、这与事前沟通时想象的不一样。
• 为什么操作这么费劲（输入太繁琐）、为什么要走这么多步才能完成一次输入/li>
• 不用系统工作就够忙的了，结果用了系统更忙了。
• 输入的数据对我的工作没有帮助，都是给领导输入的…等等。

2）抱怨举例2

• 数据计算有错误、页面切换后xx标题就找不到了…
• 经常死机、系统不稳定、输入xx数据后就进入了死循环…
• 系统反映太慢了，去厕所都回来了，一个页面还没打开…
• 页面数据链接错了，找不到相关的数据…等等。

这两组举例的不同之处在于：【举例1】是软件设计问题，【举例2】是软件测试问题。从客户抱怨的内容可以看出设计验证和软件测试的不同，【举例1】的设计问题在测试阶段已经无法改变，通常它们也不是测试工程师的检查对象。

【举例2】的问题出在编程和测试的质量上，不属于设计层面的问题。可以看出要想制作一个好的软件仅对开发结果进行软件测试是不够的，还要对设计阶段的成果进行验证。

上述举例存在的问题如果没有很好地解决，往往会造成在客户企业中系统推广受到阻力、难以执行，其结果可能有两个：

1. 由于存在的问题太多不能推广、最终软件被搁置了；
2. 在领导的压力下勉强推广，但是运行一段时间后就会形成两张皮：线上用系统做一套数据（给领导看）、线下用手工按照传统方式再做一套数据（实际使用），这造成了时间、精力和成本的浪费，造成了用户对信息系统导入有了不信感。

2. 设计验证为什么不能与软件测试工作一同进行呢/strong>

要回答这个问题首先看一下其它的行业是如何做的，盖房子、造机器、制衣服等行业能否等到完成后再检查判断设计方面是否有缺陷呢/p>

显然是不可能的，因为“木已成舟”！因此这些行业通过图纸（2D）、实物模型（用木材、塑料、金属等制作）、或用电脑制成3D模型等，让相关人直观地看到按照设计制作完成后的产品效果。

他们可以利用图纸、实物模型或是电脑3D模型进行反复的推演、验证，以保证完成的产品达到预期的效果。

而在产品制造完成后到交付前的检验都是围绕着“制造质量”为核心进行的（而非“设计质量”）。由于有多样的验证手段，所以建筑业、制造业很少出现制作完成后才发现设计有错误的现象。

建筑物或机器完成后发现严重的设计问题时要修改，甚至推到重来，软件也是一样的，完成的软件出现了设计问题后，修改某一处，由于逻辑关联就可能带来其它地方的变动，造成连锁变化。

如果是原则性的设计问题，就有可能需要重新构建系统，造成重大的损失。因此，设计完成后立即进行设计验证是最有高效的方法，不但可以解决软件设计问题、开发过程管理的可控性，还可以极大地提升客户对未来完成系统的信任度和满意度。

二、设计验证的内容

设计验证包括两个部分：业务设计验证、应用设计验证，它们目的是是检查“设计成果”是否满足“客户需求”。

1. 业务设计验证（以下简称：业务验证）

编写一套业务数据，这套数据可以模拟某个业务处理场景的全过程，用这套数据将系统中要验证的对象串联起来，用以验证业务设计的整体架构、业务流程、界面字段、数据关系、计算公式、管控规则等内容是否正确，确保系统中的业务逻辑、数据逻辑是正确的。

2. 应用设计验证（以下简称：应用验证）

编写一套系统运行的脚本，这个脚本可以模拟客户的某个角色（如经理、会计、库管员等）、或某个流程（采购、报销、物流等）操作的运行全过程，用以验证操作过程的每个细节是否合理、高效，让用户获得最佳的体验，包括：界面布局、操作效率、设计与角色工作的匹配度、智能化程度等。

为了做对比，这里举几个典型的软件测试内容：页面显示、操作功能（按钮：增加、删除、修改、保存、查询…）、权限（身份验证、操作权限）、流程流转、报表打印、兼容性、可扩展性、稳定性、运行速度等。可以看出软件测试与设计验证的关注点是不一样的。

开发完成后的测试，不但要进行有测试用例，而且还应该测试业务用例和应用用例的内容，只有如此，才能交给客户一份满意的答卷。

注1：可能有人会说，我们使用“原型法”做的需求调研，还需要进行设计验证码/strong>

这个说法是不对的，因为需求调研阶段使用的原型法仅仅是确认了界面的基本内容、粗粒度的业务逻辑，而说到设计验证，则必须是要有严格的目标、方法、标准和规范的，否则是不能得出设计结果正确、优秀的结论的。

注2：应用设计等同于UI和美工设计吗/strong>

UI、美工等工作都是构成应用设计的部分，但它们是辅助内容，不是核心内容。

三、设计验证与软件测试的关系

三个阶段的检查使用了三种用例形式，从前到后继承叠加、最后验证出综合效果，这三者是包含关系，测试用例 ＞ 应用用例 ＞ 业务用例。三者各自包含的内容、三者之间的继承关系如图1所示：

伤心的辣条 微信公众号 主要分享测试的学习资源，帮助快速了解测试

来源：测试萌萌