软件产品设计-软件质量双保险（一）——设计验证与软件测试

说到软件质量检查，人们立即想到的就是“软件测试”。 软件测试的目的主要是检查“开发程序”是否满足“软件设计”的要求，程序是否存在Bug。 换句话说，软件测试就是检查完成的软件是否满足设计要求。

完成一个好的软件首先是“软件设计”正确且优秀。 如果软件设计不正确、不优秀，那么后续的编程质量再好也是毫无价值的。 设计是为了保证软件的正确性和优秀性。 良好的前提和基础。

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

我们重点讲一下设计验证的方法（软件测试方面的资料有很多可以参考，就不说了）。

1.关于设计验证

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

大多数具有一定规模的企业信息系统都是定制的（因为没有两个企业的业务管理模式完全相同）。 定制系统无法像基于产品的系统那样不断改进、完善和升级。 系统是独一无二的。

因此，为了避免系统上线后大规模的返工和修改，在进入开发之前需要尽可能地通过验证，以获得客户对设计的认可。 在详细介绍之前，我们先来说一下软件设计验证的两个问题。

1、为什么要验证设计结果？

做过软件的人（无论是需求、设计、开发还是测试）都直接或间接听说过这样的故事：开发之前，需求和客户确认好了软件产品设计，客户也签字确认了，但是系统上线之后试用后，顾客常常抱怨：

1) 投诉示例1

2) 投诉示例2

这两组示例的区别在于，【示例1】是软件设计问题，【示例2】是软件测试问题。 从客户投诉的内容中，我们可以看到设计验证和软件测试的区别。 【例1】中的设计问题在测试阶段无法改变，通常也不是测试工程师检查的对象。

[示例2]中的问题在于编程和测试的质量，而不是设计层面。 可见，要做出一个好的软件，仅仅对开发结果进行软件测试是不够的。 设计阶段的结果也必须得到验证。

上述例子中的问题如果没有得到很好的解决，往往会造成系统在客户企业推广的阻力，难以实施。 可能有两种结果：

由于问题太多，软件无法推广，最终软件被搁置； 在领导的压力下才勉强晋升，但是运行一段时间后，形成了两张皮：线上利用系统创建了一组数据（给领导看），而线上接下来我们需要传统方式手动创建另一组数据（供实际使用），造成时间、精力和成本的浪费，导致用户对信息系统导入没有信心。 2、为什么设计验证不能与软件测试一起进行？

要回答这个问题，首先看看其他行业是怎么做的。 盖房子、造机器、做衣服等行业，能不能等到完工后再检查设计是否有缺陷？

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

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

产品制造完成后、交货前的检验是围绕“制造质量”（而非“设计质量”）进行的。 由于验证方法多种多样，建筑和制造行业很少在生产完成后才发现设计中的错误。

当建筑物或机器完工并发现严重的设计问题时，需要对其进行修改甚至重新启动。 软件也是如此。 完成的软件出现设计问题后，修改一个地方可能会因为逻辑联系而导致其他地方出现问题。 变化引起连锁变化。

如果是根本性设计问题，系统可能需要重建，造成重大损失。 因此，设计完成后立即进行设计验证是最有效的方法。 不仅可以解决软件设计问题和开发过程管理的可控性，还可以大大增强客户对未来完成的系统的信任和满意度。

2.设计验证的内容

设计验证包括业务设计验证和应用设计验证两部分。 他们的目的是检查“设计结果”是否满足“客户需求”。

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

编写一组业务数据。 这组数据可以模拟某个业务处理场景的整个流程。 利用这组数据连接系统中的待验证对象，验证业务设计的整体架构、业务流程、接口字段和数据。 检查关系、计算公式、控制规则等是否正确，确保系统中的业务逻辑和数据逻辑正确。

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

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

为了对比，这里列出了一些典型的软件测试内容：页面显示、操作功能（按钮：添加、删除、修改、保存、查询…）、权限（身份验证、操作权限）、流程流程、报表打印、兼容性表现、可扩展性、稳定性、运行速度等。可见软件测试和设计验证的侧重点是不同的。

开发完成后，测试不仅要包括测试用例，还要测试业务用例和应用用例的内容。 只有这样，才能交出一份让客户满意的答卷。

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

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

注2：应用设计和UI、美术设计一样吗？

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

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

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

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

一、三检的作用

1）业务验证（扣除业务设计结果）

基于需求，推演业务梳理和优化内容，重点确认“业务逻辑和数据逻辑”，也就是“内涵”。

2）应用验证（应用设计结果扣除）

以业务用例的数据为主线吉祥物设计，添加系统功能（流程机制、高保真界面、功能按钮等），推演用户操作流程的合理性和友好性，重点确认“信息环境”，也就是“表象”。

3）软件测试（完整系统的测试）

软件测试除了根据自身的测试用例（如功能、Bug、性能、安全、集成等）进行检查外，还必须添加上述两个验证用例的内容，以测试完成的系统是否能够准确地执行此操作。 “脚本”。

2. 三种检查的区别

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

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

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

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

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

无论软件测试结果有多好（假设100分），都只能证明该软件是按照设计开发的。 只有设计正确客户才会给予好评，因为客户购买的是业务设计和应用设计的价值，而软件没有Bug、性能好、安全等都不是购买的目的（应该是！）。 相反，如果测试结果不好，所有的客户反馈都是不好的，因为无法使用，业务和应用价值再高也无法被证明。

3、软件资质标准

软件开发完成后，需要测试到什么程度才可以交给客户？

对于这个问题的“程度”，众说纷坛，其中有不少强调“软件与其他行业不同……”，但有一个原则是无论什么行业都必须遵守的，那就是交付给客户的产品。 原则上不能存在质量问题，无论质量问题是设计（业务、应用和技术）引起的还是编写程序引起的。

“没有错误，因此测试已完成”的说法是不正确的。 测试完成的标准应该是：测试结果证明产品开发完全满足设计要求。

要按照这个标准进行测试，不仅要有测试用例，还要有业务用例和应用程序用例。 您一定要记住：客户的满意是针对整个软件的设计、开发和服务的。 没有软件没有“bug” 开发合同的内容。

另外，“测试结果”不能直接用来验证“客户需求”卡通形象，只能用来验证“设计结果”，因为客户需求必须经过多次设计（业务、应用、技术）才能确定并交付。 发展。

因此，测试开发是对软件设计需求负责，而不是对需求研究结果负责。 三项检查各有不同的作用和作用，缺一不可。 通常前两项检查没有被认真对待（或者做得不够），因此即使完成的软件没有错误，也不会受到客户的好评。 这就是原因。

4. 谁来进行设计验证？

软件测试用例通常由测试工程师编写。 那么谁来负责设计验证的用例呢？ 答案是：需求工程师。 当然，前提是需求工程师参与需求研究和软件设计。

设计验证用例与软件测试用例有不同的视角和侧重点，需要不同的知识和经验，并且有不同的编写方法。 更重要的是，设计验证用例只能由参与过研究和设计工作的人来编写。

从上面的描述可以看出，测试工程师很难做出这样的设计案例，时间也不允许。 相反，如果有需求工程师编写的设计案例，也将为测试工程师提供编写测试案例的机会。 很有帮助。

设计验证总结：

对于需求工程师来说，能够编写设计用例是一个比较高的要求。 如果你做了需求收集、分析、业务和应用设计，但没有做设计验证软件产品设计，那么你不敢说你的设计是正确的。 ，优秀，很有可能设计根本不契合而你又不知道，也不能保证开发出来的软件能够让客户满意。

因此，作为一名合格的需求工程师，必须掌握设计验证方法。 通过设计验证，可以对所设计的产品有一个整体的了解并发现问题，同时，客户、程序员、测试人员和其他相关人员可以对要开发和完成的软件有一个完整的了解。

只有能够独立完成咨询、研究、设计、验证四个环节的需求工程师，才能称为成熟、合格的需求工程师。

下面两篇文章重点讲解业务设计验证和应用设计验证的方法。