运行期质量

1. 1. 1. 运行期质量
         1. 性能

对用户而言，最关心的是：响应时间和操作总耗时。点击一个按钮，几秒没反应，用户就蒙了。最简单的方法：点击后，马上禁用按钮，操作完成后启用。客户最关心的是，资源使用率。比如：a，带宽，视频网站这个占大头。b，多少台服务器。如果需要多台服务器，看瓶颈在那？内存、CPU运行速度、磁盘读写速度。如果只需要一台服务器就没必要浪费时间。一台服务器比增加的开发成本少得多。如果是单机程序或客户端，在主流配置下能流畅运行就可以了。

1. 1. 1. 1. 安全性

完整性：确保信息在传输过程中没有被篡改。私密性：确保只有可信的实体可以看到这些信息。源认证：确保是可信的源发送了这些信息。不可否认性：不能事后否认发送过这条信息。

不可逆加密原理，乘法的逆运算是除法，除法比乘法复杂得多。找两个大质数相乘，逆运算的运算成本太高。密码保存：最笨的办法是保存明码；稍好的是保存MD5码，黑客知道了MD5一样可以登录，密码+固定后缀再取MD5，可以防止自己网站泄露密码后，祸害其它公司；较好的方法，密码服务器只负责不可逆加密、解密，加密后的密码放到另外一个服务器。

 

1. 1. 1. 1. 易用性

包括：易理解性，易学性，易操作性，吸引性。常见易用性操作：

• 风格统一。
• 删除邮件时，放到回收站，30天后才会自动删除。
• 让用户选择而不是输入。
• 提供默认值，并记录用户的输入。如果有必要，增加配置。
• 足够的使用文档和培训文档。
• 易用不是绝对和通用，必须要细分用户和细分场景。
• 要平衡效率和易用性。
  1. 1. 1. 可伸缩性

系统的可伸缩性可分为：硬件的可伸缩性和软件的可伸缩性。硬件的可伸缩性增减硬件来应对用户的变化，如增减服务器。某游戏服务端，至少需要两个服务器，主服务器、地图服务器，哪怕只有一个人在线，且两个服务器不能是同一台服务器。这样就不具有伸缩性。软件的可伸缩性，有的软件是按实例数收费的，有的软件是按次数收费的，比如：某pdf转png是按页收费的，价格无封顶。如果价格贵的话，可伸缩性就很差了。

1. 1. 1. 1. 可靠性

在规定时间内，软件不发生失效的概率。最简单的可靠性模型，有缺陷的测试用例除以总测试用例数。软件可靠性设计：一，避错设计：简单、同型、对称、层次、线型、易证、安全。二，容错设计：时间冗余，失败后重做；结构冗余，不同的人员、设计方法、算法实现相同功能的模块，多个模块同时运行根据规则选择一个结果，或执行一个模块，出错后执行其它模块。信息冗余，信息中通过增加部分信息码以便检测或纠正数据偏差。三，查错设计，程序运行中自动查找存在的错误。四，改错设计，减少错误的危害程度、限制错误的影响范围。

1. 1. 1. 1. 连续可用性

连续可用性通常以服务器或系统可用时间的百分比来衡量。这通常是以一年为单位，99%的可用性意味着系统每年停机87.6小时，而可用性为99.99%的系统只会停机约一个小时每年。可用性3个9：可用性99.9%。

可靠性和可用性相近，但不同。更新、维护不影响可靠性，但影响可用性；服务端崩了，但马上重启了，某次备份失败，不影响可用性。用户更关心连续可用性，开发人员更关心可靠性。

1. 1. 1. 1. 健壮性

也称茁壮性、鲁棒性、容错性。指的是系统在不正常的输入或不正常的外部环境下仍能表现出正常的程度。原则：一，“没有什么不会发生”，恶意用户不可不防。二，设计系统的时候，把用户当“傻瓜”。铁打营盘流水的兵，客户肯定会招新人。操作员不会总是处于良好状态，比如：睡眠不足、时间紧急等。三，严格要求自己，减少对客户的要求、假设。

最好能截获异常后做异常处理，比如：弹出界面提醒用户发生了什么。其次，能在日志留下些线索以定位问题并解决问题。

1. 1. 1. 1. 互操作性

就是指两个实体的通信能力，如果两个实体之间能够没有任何误解的进行通信，那么我们就说这两个实体可以正确的互操作。常见互操作性：一，利用ocx、com进行交互。比如：智造家打印大师利用Com控制AutoCAD启动、打印。二，“牛牛”服务端和客户端利用通讯协议（如：TCP/IP WebSocket）通信。三，利用相同的数据格式通信。如：读写同一个xml文件、json文件、数据库。四，专用接口，如API。