不要脱离实际环境
有时，我们会因为读到一篇文章或一本书，或者看到一个感觉不完善的介绍而变得异常偏执。在每种情况下，人们只讨论一些技术、解决方案和选项的某些方面，而忽视了一个至关重要的问题:非功能性需求。
诚然，功能性是非常重要的。毕竟，如果您不能展示您构建的系统实现了您想要的功能，那么谁会有兴趣呢?采取一种新颖、巧妙、更简单、更漂亮或更得体的方法来解决某种问题固然很好，但是如果您没有考虑非功能性需求，则您的解决方案可能无法取得实效。
我们都碰到过这样的情况，许多解决方案虽然合理，但是当真正考虑将它们用于大型系统的实际环境，而管理这些系统的人员又非常忙时，它们就变得很荒谬可笑了。造成这些灾难的原因是不重视或忽略了系统的非功能性需求。
非功能性需求是这样一种需求，它不一定解决“我想要我的系统实现这种功能”，而是解决“如何使这个系统能在实际环境中运行”。对于这些实际环境，您很少听到人们提及的一些问题是:
- 对在线系统的请求过多:用户太多了，全都在一块了!
- 部署应用程序的管理员负担过大:在实际环境中，管理员对每个应用程序都将部署多次，而在部署之后必须对每一个应用程序进行监视。
- 管理员会犯错误:毕竟，我们大多数都是普通人!虽然无差错地执行 100 次手动部署步骤在理论上是可能的，但是实际环境中没有出现过。
- 会有恼人的脚本小子 (script kiddy) 和真正的破解高手攻击我们的系统:安全是多么重要啊!
所以，什么是非功能性需求呢?我们可以找到许多很好的定义，不过，我们首先来看 Software Characteristics 的 ISO 9126 列表;除功能性(这是理所当然的)以外，这些特性包括:
可靠性
只显示系统可以做某些事情是不够的。如果一个系统不能可靠地运行(例如，在加载时，或者在系统故障时，等等)，则它就不能满足客户的需要。
有一些问题应该自问一下:
即使硬件出现故障，系统也可以可靠运行吗?
- 复制和故障转移方案是什么?
- 需要手动干预，还是系统可以自动进行故障转移?
- 实现可靠性会对性能造成负面影响吗?
- 实现可靠性的成本有多高?
可靠性需要考虑的一些具体方面是:
- 安全性:假设攻击者就在外面。如何知道系统用户就是他们所声称的，并只让他们访问经过授权的功能?如何保护我的系统不受攻击?考虑到网络攻击、机器攻击，甚至从您自己的系统内部发起的攻击。
- 事务性:如何设计系统来保存工作单元的 ACID 属性?如果在设计中涉及多个独立的子系统(Web 服务和 SOA 就是这种情况)，则这一点就显得特别重要。不要假设始终可以进行两阶段提交 (two phase commit)。
可用性
如果用户不能够从他们可用的渠道(例如 Web)方便地访问您的产品，那么它的好处何在呢?这有时是作为功能性的一部分一起考虑(或者应该在理想的环境下)的，但是常常被忽视，以致于整个项目处于危险之中。这里需要考虑的一些问题是:
- 您是否为用户带来不适当的负担(例如，需要特殊的浏览器版本)?
- 系统是否根据模型-视图-控制器 (Model-View-Controller) 体系结构设计以使多用户界面成为可能?如果是这样，如何将它们绑定在一起?
- 是否界面本来就有状态而功能无状态(反之亦然)?
有效性
如果没有有效地使用资源(例如处理器、内存和磁盘空间)，功能性、可靠性和可用性再好的系统最后都会失败。我们经常发现将有效性划分成两个子范围是很有用的，这两个子范围都应该加以考虑:
- 性能:这个系统的运行情况有多好?它只是平稳缓慢地运行吗?系统可以达到其响应时间目标吗?应用程序的设计是否符合性能要求?您利用缓存了吗?
- 可伸缩性:如果系统在小范围内运行看起来相当快，那么当扩展至每秒、每分钟或者每小时几千或成千上万个活动的时候呢?它的设计是否达到吞吐量目标?可以复制系统来实现线性扩展吗?是否存在瓶颈(例如公共数据库)?
可维护性
这是一个极其重要的需求，因为如果开发人员、管理员和操作人员不能够解决如何管理应用程序的问题，则它在首次发布之前就会夭折。假设您是一位管理员，您承担了解决此问题的任务，那么您如何配置它?如何监视它?如果您一件事情需要执行很多次(例如，安装许多应用程序)，那么会怎么做呢?您是否有一个可复制的部署流程呢?您是否可以使重复的任务自动化，使之在大范围内可行呢?
可移植性
虽然列在最后，但它并非最不重要。例如，如何采用标准来提供某种形式的平台中立性呢?是否计划将应用程序迁移到您的最新和最高版本的应用服务器上呢?如果不打算这样做，则当供应商撤消对该版本的支持时您要怎么做呢?如果您的项目基于开放源代码，则也有类似的问题。如果每当某人有个更好的捕鼠器 (mousetrap) 您就必须重写整个应用程序，则没有人会问津。
在完美的世界中，我们希望每篇文章、论文、红皮书、幻灯片和系统设计都率先解决这些重要问题。它们非常重要。差不多始终都要进行一些折衷，它们应该显式进行以便确定特定的设计是否符合您的需要。如果您阅读的文章没有解决这些问题，将这作为我们的警告——一些重要的东西往往会被忽视。如果您是一位作者，请考虑我们的恳求:不要忽视这些问题!
文章来源于领测软件测试网 https://www.ltesting.net/
