下载掌阅APP，畅读海量书库
立即打开
前三章，我们讲了测试的本质是验证软件需求，还讲了如何去审核软件需求。无论是审核PRD还是写用户故事，都是为了解决用户“要什么，为什么”的问题，本质上是解决目标需求的含混性。
事实上，对于软件开发来说，含混性存在两个方面，一个是对目标需求的含混性，另一方面是实现方式上的含混性。实现方式的含混性主要是解决“给用户什么，怎么给，什么样的呈现方式”的问题。FS（Functional Specification，功能规格书）是更进一步回答“ 各个模块具体怎么做 ”的问题。
4.1 实现的含混性
小白 为什么会出现实现的含混性呢？
大鸟 原因有如下两个。
（1）一个是科学的方法大多需要量化的度量技术。含混性的量化公式是：
含混性=实现需求的最大花费/实现需求的最小花费
如果需求过于抽象，那么这个公式给出的含混性就可能非常大，而这种随意性很大的估值是非常忌讳的，很可能会造成亏本。
（2）另一个原因，是我们拔高了我们的底层实现。很多时候，歧义来自于我们自身的能力，因为我们有足够的能力做到多样性，而这些多样性都体现出各自的特点，所以我们才会有了如此众多不同的选择。
通过严格的分析后发现，决定含混性的，始终还是应该由实现相应需求的不同方案的数目来确定的。含混性毕竟还是对这种实现的不确定性的度量。按照成本来度量，可能会存在两方面的问题。其一，许多不同的方案花费相差不大，但在具体实现的时候可能会造成一些执行上的偏差，而这种偏差在最开始度量的时候体现不明显；其二，虽然成本一般都对应着相应的解决方案，但是不排除少数解决方案之间存在大的成本跨度。这些情况大多主要影响的是实现，不过确实也需要提前注意。
小白 为了解决实现的含混性，从QA的角度上如何去关注？
大鸟 前面我们说过了，PRD文档重点体现产品的功能需求和各项指标的说明，开发人员拿到最终版的PRD之后，根据各个模块的不同，由不同的开发人员进行并行开发。各个模块开发人员根据该模块的功能需求和技术参数，输出各个子模块的 FS。FS 更进一步回答了“ 各个模块具体怎么做 ”的问题。其实你也可以把它理解为一种需求（开发级需求）：开发人员需要实现什么？开发期间、维护期间有何质量考虑？开发团队的哪些情况会反过来影响架构？
小白 FS是DEV写的？
大鸟 是的，是软件开发工程师写的。
小白 那么FS都包含什么内容？QA又该如何审核呢？有的时候FS非常复杂，QA很难看懂的。
大鸟 FS包括如下几项内容。
（1）交付目标。
（2）范围约束。
（3）功能描述。
（4）非功能描述。
至于 QA 该如何审核，我简单说一下。QA 首先要做的就是把规格说明中不清楚的模糊点搞清楚，把项目相关人员之间的重要分歧摆平。把系统内在的复杂性梳理清楚，不要犯遗漏、误解和过于简化的错误。QA 对产品、技术和一般测试问题了解得越多，自己的困惑就会成为更准的指南针，指出重要问题所在。
在测试过程中，如果对产品一无所知，那么至少要知道自己的困惑是什么。在这种情况下，困惑可以成为最佳交付内容，即提出也许其他人没有勇气提出的问题。
4.2 交付目标
小白 交付目标是指什么？
大鸟 交付目标是指，到底是要把它做成什么样。我们要交付（Delivery）给用户的到底是什么？是一个模块？一个补丁（Patch）？还是一个ISO（光盘）？是否还包含DOC（文档）？所交付的版本是否清晰？还是兼而有之？
小白 兼而有之是指什么？
大鸟 我们以前有这样的情况：当一个最新产品发布的时候，不但在软件路线图（roadmap）上是一个提升，会交付一个新版本的ISO，此外还要兼顾以前的版本，给出针对以往版本的不足和缺陷的补丁。这样的话，交付目标就有两个。像这种“兼而有之”的情况，我们要特别注意，不要漏了。
此外，对于集成产品（由多个子产品“攒”在一起的产品），还要注意每个子产品的版本号是不是正确的。由于每个子产品都要有自己的版本控制变化，要注意在集成产品中所用到的子产品版本是否是最合适的。
小白 最新的是不是最合适的？
大鸟 不一定，能解决用户问题的才是最合适的。
4.3 范围约束
小白 范围约束是指什么？
大鸟 参考PRD以前的范围约束，简单点说就是要做什么不要做什么。这里是换成具体模块的范围约束，审核方法也与PRD审核类似。
4.4 假设和依赖
小白 假设和依赖是指什么？
大鸟 假设和依赖是指对软件需求规格说明中影响需求陈述的假设因素（与已知因素相对立）。这可能包括你打算要用的商业组件或有关开发或运行环境的问题。你可能认为产品将符合一个特殊的用户界面设计约定，但是另一个研发工程师却可能不这样认为。如果这些假设不正确、不一致或被更改，就会使项目受到影响。
此外，确定项目对外部因素存在的依赖。例如，如果你打算把其他项目开发的组件集成到系统中，那么你就要依赖那个项目按时提供正确的操作组件。如果这些依赖已经记录到其他文档（例如项目计划）中了，那么在此就可以参考其他文档。
以ETT公司的HPC软件交互式安装为例，我们来看一下安装过程中我们都有什么假设和依赖：
案例 ETT公司的HPC软件交互式安装
假设条件
● 管理节点上已经安装了支持的操作系统。
● 用户已经阅读了安装文档，并知晓了相关的先决条件和局限性。
● 用户已经安装了相关软件包。
● 用户已经从ETT公司授权得到了一个合理的License文件。
依赖性——集成包依赖
● 集成包包括了若干个软件包，包含A，B，C等。所有软件包将以RPM方式安装上。如果这些包出现问题，不能保证软件安装包能正常安装。
● 合理的License（许可）文件。
4.5 功能描述
小白 这个功能描述和PRD里面的功能需求相比较来说，有什么区别吗？
大鸟 PRD侧重于把系统要解决的业务逻辑、要实现的功能描述清楚，更宏观；需求规格说明书侧重于把系统的某个功能点的具体约束、输入、输出和处理过程定义讲清楚，更具体。
以软件交互式安装为例，PRD里的功能需求无非就是顺利安装成功。
但是安装中的每一步、每一个过程，比如安装路径、安装端口、设定安装网段、定义域、定义输出结果等，也就是说安装过程中所做的各式各样的每一步操作都要在这里定义好。
4.6 审核功能描述
小白 如何审核这些功能描述呢？
大鸟 主要审核功能描述是否包含如下特质。
（1）质量需求或产品特性的描述是否足够准确。
（2）实现方式可扩展性。
（3）技术合理性。
（4）集成和升级风险。
（5）理解一致性。
（6）设计一致性。
小白 质量需求或产品的特性描述会不准确吗？
大鸟 质量需求或产品的特性描述不准确，将导致DEV/QA和设计人员对产品特性有歧义，结果使某些地方始终测试不到或验证的标准不对。
例 一个iPhone 用户来到苹果5S 店，他想说“我要越狱”；结果想了半天，也没想出来，最后说了一句“我要出轨”。苹果店的服务人员若有所思地想了一会儿，给这个用户手机上装了微信。
小白 这是什么原因造成的呢？
大鸟 当存在这种问题时，你顺着线索往上，最后就能推算出来，是PRD标准或者用户故事写得太模糊了，到了设计层面，研发工程师就跟着倒霉。因为用户需求的模糊，我们可以给出多种实现方式，所以出现这种问题时，我们要反思用户故事是否足够细化。
举个例子来说，“ 当机房机器CPU温度超过60度的时候，系统管理员需要被通知到 。”我们可以有如下的实现方式。
（1）我们可以在GUI实现Alert方法，当温度超过60度的时候在GUI界面上报警提示。
（2）我们可实现邮件服务器，当温度超过60度的时候给管理员发邮件提示。
（3）当机器CPU温度超过60度的时候，可以亮灯报警，如果看机房的人看到后，可以给管理员打电话。
（4）当机器CPU温度超过60度的时候，可以智能给管理员手机发短信。
说不定还有其他实现方式。
小白 感觉第4种方式最智能，第3种方式最土。这么多种实现方式，哪一种才是合适的呢？
大鸟 的确，至于说怎么才算合适，就要看进一步探求用户需求的结果，还要看测试者的经验以及业界的相关标准。
但是越智能的功能，越需要额外的努力，如果时间/人力不允许，或者如果用户可以买账第3种方式，也未尝不可啊。一句话：合适不合适，还是由用户需求决定。
小白 实现方式可扩展性是指什么呢？
大鸟 开发一个软件，不是一锤子买卖，我们要考虑软件接口是否可以通用，代码的可复用性，软件是否可扩展，设计当中会不会有些是hard code（硬编码）处理的，等等。
小白 别写死了。
大鸟 是啊，比如说这个软件暂时是给Rhel平台使用的，但是谁知道将来会不会给Sles使用呢？如果代码写死了，万一将来扩展起来，岂不是很麻烦。所以我们在审核FS这一层时，就要看看将来解决方式是否可扩展。
小白 如何审核技术合理性呢？
大鸟 这是指审核设计人员对产品技术的选择是否合理，是否选用了成熟合理的技术。
当研发工程师为了实现一个功能的时候，或许手头上有一个从网上复制的示例模块，看上去这个可以使用。假如正好它暂时满足了你的需要，你会对这个模块稍加改动，添加一些代码，然后再加一点。你根本就不知道自己在做什么，只是不断地做一些小的修改，直到这个模块完全满足你的需要。但问题是，这样做就像是用纸牌搭建房子，每增添一张纸牌，就增加了一分纸房子坍塌的危险。你根本就不知道这个模块到底是如何工作的，所以你每做一点儿改动，都有可能导致你的模块完全失败。
小白 不成熟的技术虽然暂时解决了问题，但是会留下隐患。
大鸟 是的，急功近利的做法要不得。
小白 集成和升级风险是指什么？
大鸟 举个例子吧：ETT公司的HPC产品由三个集成模块构成，A模块、L模块和P模块，其中一个小模块P需要升级了，例如从原来的P706升级到P901。如果研发工程师没有做调查就直接进行集成，有可能一些旧的环境变量在新的HPC版本上不工作，从而给QA的后续工作造成极大困扰。
小白 那QA该怎么办？
大鸟 辅助DEV一起对变更模块进行调查，搞清楚该模块之前的行为结构和现在的区别，变更点主要是哪些。这些都要吃透。
小白 理解一致性是指什么呢？
大鸟 对于同一个项目的某一个实现点，QA 要确保各个部门（相关的责任人和利益方）对数据库、接口、API的理解在同一层面上。
小白 这还能理解不一致吗？
大鸟 挺多的，不同Team站在不同角度，有不同的诉求。下面是HPC管理网络脚本的一个案例。
案例 HPC管理网络脚本最早是由后台DEV进行开发的，当时只是一个系统的辅助功能，并没有暴露给用户。
但是后来HPC网络管理升级了，新的需求允许在GUI（前台图形界面）上将网络脚本暴露给用户。前台工程师觉得既然之前后台已经做好了，那我直接调用以前的脚本就是了。而后台工程师想反正只是在前台暴露，又不在后台体现，那我就什么都不用做了。这样的话，两方面都理解错了。
最后导致，旧有后台工程师的网络脚本的提示信息、容错机制等都无法满足现有用户需求，最终项目失败。
小白 刚才说了理解的一致性，那现在又说设计一致性是指什么呢？
大鸟 设计的一致性是指设计的元素在视觉、体验、操作上具有传承连贯性。主要检查设计是基于公司/业界标准，还是自己另起炉灶——这样的话就增加了用户的理解难度。当然，对技术的改进另当别论。
小白 具体有哪些表现呢？
大鸟 有的表现为工具界面，也可能是操作流程，也有可能是输出结果。工具界面的测试我们会在UI测试中讲，现在说一下操作流程。关于操作流程，比如说我原来是先做A后做B然后做C，现在改成了先做B后做C然后做A。如果不是技术革新，那就值得商榷一下：为什么要做这样的变化。
4.7 非功能描述
小白 这个非功能描述和PRD里面的非功能需求相比较来说，有什么区别吗？
大鸟 FS里面的非功能描述侧重于描述系统某个模块各个非功能点的具体约束。审核方法还是参照审核PRD的方式，在这里不再赘述。