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

编辑导语：软件测试，是使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。正确的“软件设计”是完成一款好的软件的前提和基础，而设计验证是判断软件设计正确与否的一个好方法。

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

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

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

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

一、关于设计验证

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

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

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

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

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

1）抱怨举例1

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

2）抱怨举例2

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

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

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

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

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

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

要回答这个问题首先看一下其它的行业是如何做的。

盖房子、造机器、制衣服等行业能否等到完成后再检查判断设计方面是否有缺陷呢？

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

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

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

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

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

二、设计验证的内容

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

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

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

• 业务验证保证了 “系统可用” 的最低要求。

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

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

• 应用验证保证了 “系统好用” 的最高要求。

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

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

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

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

注2：应用设计等同于UI和美工设计吗？

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

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

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

图1：三种用例之间的关系

1. 三个检查的作用

1）业务验证（对业务设计成果的推演）

以需求为依据，对业务的梳理、优化内容进行推演，重点在于对“业务逻辑、数据逻辑”的确认，是“内涵”。

2） 应用验证（对应用设计成果的推演）

以业务用例的数据作为主线，加入系统功能（流程机制、高保真界面、功能按钮等），进行用户操作过程的合理性、友好性推演，重点在于“信息化环境”的确认，是“外表”。

3）软件测试（对完成系统的测试）

软件测试除去按照自有的测试用例（比如：功能、bug、性能、安全、集成等）进行检查外，还要再加入前述两个验证用例的内容，以测试完成的系统是否可以准确地演出这个“剧本”。

2. 三个检查的区别

1）业务验证与应用验证的区别

这两者的区别从设计的目的上就可以看出来：

• 业务设计决定了系统的主体、内涵，业务正确保证了系统核心价值的存在；
• 应用设计决定了系统易操作性、功能的智能化，用信息化手段提升客户的工作效率等。

用户对业务价值的感受是通过操作界面来获得的，因此，应用设计的不好用，用户就感受不到业务设计的价值了（因为他不想用）。

2）设计验证与软件测试的区别

这两者的区别从系统完成后的效果上就可以看出来：

• 设计验证（业务&应用）：要证明的是“设计是按照需求进行的，设计是正确的”，但是无法保证后续软件开发是否会出错。设计做好了，会得到客户的赞扬，提升满意度，因为软件的客户价值绝大部分来源于设计。
• 软件测试：要证明的是“软件是按照设计编写的，程序没有错”，但不保证软件设计是否是正确的。

软件测试的结果再好（假定100分），只是证明了软件是按照设计开发的，客户只会在设计正确的前提下给予表扬，因为客户买的是业务设计和应用设计的价值，而软件不出bug、性能良好、安全等不是购买的目的（是应该的！）。相反，如果测试结果不好，所有的客户反馈都是差的，因为无法使用，业务和应用价值再高也无法证明。

3. 软件合格的标准

软件开发完成在交给客户前，到底要测试到什么程度呢？

关于这个的“度”的问题有不同的说法，其中强调“软件不同于其它行业…”的说法也不在少数，但是有一个原则不论什么行业都是要遵守的，那就是交到客户手中的产品原则上是不能有质量问题的，不论这个质量问题是设计造成的（业务、应用和技术）还是编写程序造成的。

“没有bug了，所以测试完成了”的说法是不正确的，测试完成的标准应该是：测试结果证明产品的开发完全符合设计要求。

按照这个标准做测试，不但要有测试用例，还必须有业务用例和应用用例，一定要记住：客户的满意度是针对整个软件的设计、开发和服务而言的，没有“bug”不是软件开发合同的内容。

另外，“测试结果”是不能直接用于验证“客户需求”的，而只能用于验证“设计结果”，因为客户需求都要经过多重的设计（业务、应用、技术）之后才能确定下来交付开发。

因此，测试开发是对软件设计要求负责的，而不是对需求调研结果负责的。三个检查的作用不同，效果不同，缺一不可。通常前两个检查没有被重视（或做到不够），所以完成的软件即使是没有bug也没有获得客户的好评其原因就在于此。

四、由谁来做设计验证

软件测试用例通常是由测试工程师编写的。那么设计验证的用例由谁来做呢？回答是：需求工程师。当然前提条件是这名需求工程师参与了需求调研和软件设计的工作。

设计的验证用例，与软件的测试用例视角不同、关注点不同、需要的知识和经验不同、编写的方法也不同，更重要的是设计验证用例只有参与了调研和设计工作的人才能写出来。

从上述的说明中可以看出，测试工程师是难以做出这样的设计用例的，而且在时间上也不允许，相反，如果有了需求工程师编写的设计用例，也会对测试工程师编写测试用例提供很大的帮助。

设计验证小结：

对于一名需求工程师来说，能够写出设计用例是一个比较高的要求，如果你做了需求收集、分析、业务和应用设计，但是没有做设计验证，那你就不敢说自己设计的正确、优秀，很可能设计是完全咬合不到一起的你也不知道，更不敢保证开发完成的软件是可以让客户满意的。

所以，作为一名合格的需求工程师，必须要掌握所设计验证的方法，通过设计验证，可以让自己对设计的产品有一个整体的认知、查出问题，同时也让客户、程序员和测试工程师等相关人对要开发和完成的软件有一个完整的认知。

能够独立地完成咨询、调研、设计和验证4个环节的需求工程师，才可以称之为一名成熟的、合格的需求工程师。

以下两篇本文，重点对业务设计验证和应用设计验证的方法进行说明。

 

本文由 @李鸿君 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议