【编程素质】软件质量

本文主要是介绍【编程素质】软件质量，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

1，好的编程习惯

1）魔法数

魔法数指在代码中直接出现的数值，而只有这个数值记述的那部分代码才明确其含义。
《重构》中指出，魔法数降低代码可读性。改善：用有名字的static final或enum，可以提高可读性、可维护性。

2）延迟初始化

延迟初始化指用的时候，才对值进行初始化。
这样可以提高性能，避免计算的浪费，减少程序对内存的要求。提高程序的启动性能。（《重构》）
场景：一个对象的创建开销很大，其中加载了若干个对象实例，但只有一些对象实例需要立即执行，则对其它进行初始化延迟，提高程序的启动性能。

3）条件语句的优化

①switch

为了降低系统各部分的依赖和避免魔法数，将switch语句用多态替换掉
点击查看，搜索“switch”

②if-else

将if-else段落提炼出来作为一个函数，这样可以突出条件逻辑，增强可读性。

③消除控制标记

用continue和break替换。
结构化编程，每个程序有一个入口一个出口。消除控制标记，可以增强程序可读性。

4）函数

①参数

如果函数可以通过其他途径获得参数，那么这个参数就不应该通过参数传值获得。
过长的参数会降低程序可读性，故可以将有共同行为的参数移到新的对象中。（《重构》）

②返回值

多个return是不好的编程习惯：
首先，当程序很复杂的时候，显得很混乱；
其次，很多操作也很不方便。比如给整个函数体内的遇见加上一个try-catch之类。
保证程序的单一入口和单一出口，定义局部参数做返回值：只返回一次。这样程序便清晰很多了。例如：22

String s = "A";  
int Return(){  int i = 0;  if (s.equals("A")) {  i = 1;  }  else if (s.equals("B")) {  i = 2;  }  else{  i = 3;  }  return i;  
}

2，概念

1）软件维护

①升级

完善性维护或增强。

②预防

预防性维护或再工程。
改进应用软件的可靠性和可维护性，为了适应未来的软硬件环境的变化，应主动增加预防性的新的功能，以使应用系统适应各类变化而不被淘汰。

③纠错

纠错性维护（校正性维护）。

④适应

适应性维护。
使用软件适应信息技术变化和管理需求变化而进行的修改。

⑤支援性维护

如用户的培训等。

3，软件质量

1）定义

简而言之是软件满足用户需求的程度。

2）提高质量途径

① 寻求改进软件开发过程质量的方法
以ISO9000-3、SPICE(ISO/IEC 15504)、CMM等规范软件过程开发
② 对开发完成的产品进行测试和评价
验证软件是否符合要求。
软件产产品评价结果差的原因：软件产品评价大多采用定性方法，缺少定量的方法。

3）软件质量度量

①使用质量（此为我们的实际目标）

是用户使用的感受，真实的软件质量。
是基于用户观点的软件产品用于指定的环境和使用周境时的质量。它测量用户在特定环境中能达到其目标的程度，而不是测量软件自身的属性。

②外部质量

是达到指标要求的质量，是设计要求。

③内部质量

是软件开发中的质量。
内部度量可用于开发阶段的非执行软件产品(例如标书、需求定义、设计规格说明或源代码等)。
内部度量为用户提供了测量中间可交付项的质量的能力，从而可以预测最终产品的质量。这样就可以使用户尽可能在开发生存周期的早期察觉质量问题，并采取纠正措施。
注意：在版本变化的时候，也要注意相关大的变动提交，整理成文档（如规格说明书），交由用户签字确认后再实施，避免后期纠纷，也是为了发现所提交的产品与客户需求的偏离程度。
GB/T 8566中定义了软件生存周期过程，其中基线是：在配置项的生存周期内的某一特定时刻已正式指定和固定的且经正式批准的配置项的一个版本。当基线变化时，应该有文档确认。

4)内外部质量的分层定义

①功能性

满足明确和隐含要求的功能的能力。

a.适合性

b.准确性

c.互操作性

与其他指定系统进行交互的能力。
如分隔层：在发现对象模型不稳定时产生。在对象模型和数据库模型间插入一个分隔层，就可以分离两个模型的变化（计算机中，大多数都可以通过添加分隔层来解决）。升级时，只需修改自身和分隔层。
中间件：数据处理中间件、提取中间件、清理中间件。是连接各个系统的独立的系统。大多数中间件都支持负载均衡，实现负载均衡大大降低了系统的崩溃现象，从而减少对企业带来的损失。

d.安全保密性

防止对程序或数据的未经授权访问的能力。
如Token技术，但是安全永远是相对的。包括加密、授权、日志跟踪（确保后期追责）、网络隔离。

e.功能性的依从性

②可靠性

软件产品维持规定的性能级别的能力。软件不会损耗或老化。

a.成熟性

软件产品避免因软件中错误发生而导致失效的能力，主要是对内错误的隔离。

b.容错性

是指在软件发生故障或违反指定接口的情况下，软件产品维持规定的性能水平的能力，主要是对外错误的隔离。

c.易恢复性

是指在失效发生的情况下，软件产品重建规定的性能水平并恢复受直接影响的数据的能力。

d.可靠性的依从性

③易用性

a.易理解性

这要依赖于软件提供的文档和初始印象。

b.易学性

c.易操作性

d.吸引性

e.易用性的依从性

④效率

相对于所用资源的数量，软件产品可提供适当性能的能力。

a.时间特性

b.资源利用性

云计算：资源的充分利用、合理分配，是资源的动态调配。

c.效率的依从性

⑤维护性

见1-1）软件维护的类别。

a.易分析性

b.易改变性

c.稳定性

d.易测试性

e.维护能性的依从性

⑥可移植性

a.适应性

软件产品无需采用额外的活动或手段就可适应不同指定环境的能力。

b.准确性

c.易安装性

d.共存性

软件在公告环境中同其它独立软件共存的能力。

e.易替换性

软件在同样环境下，替代其它相同用途的软件能力。

f.可移植性的依从性

5）使用质量的质量模型

①有效性

在指定周境下，使用户能达到准确性和完备性相关规定目标的能力。

②安全性

在指定周境下，达到对人、业务、软件、财产、环境造成损害的可接受的风险级别能力。

③生产率

在指定周境下，达到有效性而消耗适当数量的资源能力。

④满意度

6）软件质量改进和能力成熟度模型

CMM/CMMI、SPICE。
产品文档，应该有权威的模板，遵循XXX权威标准。 SJ-T11234与CMMI都定义了成熟度5级。

CMMI的5级：

① 初始级：完成要求了，无总结，成功不可复制。容易超出计划中记录的预算和成本。
② 已管理级：项目执行和管理能根据文档化计划来进行。包括：软件配置管理、软件质量保证、软件子合同管理（用于核算成本）、软件项目跟踪和监督（SQA小组制定质量标准，项目经理保证软件质量）、软件项目规划、需求管理
③ 已定义级组织标准过程集得到建立并随时间改进。过程描述更为具体。包括：对等复审（结对编程）、组间协作、软件产品工程（产品：指程序、部件、系统；工程：指规范化、标准化过程）、集成的软件管理、培训计划、组织过程定义（有行为规范）、组织过程关注。
④ 已量化管理级项目绩效与选定的子过程的性能得以使用统计与其他量化技术进行控制，预测的部分地基于对精细粒度的过程数据的统计分析。包括：软件质量管理、量化的过程管理（比如：结对编程错误率不超过5%。这些量化由企业根据经验定义）
⑤ 持续优化级处于成熟度级别 4 级时，组织与项目关注于子过程层面对性能的理解与控制，并使用其结果来管理项目。处于成熟度级别 5 级时，组织使用从多个项目收集来的数据对整体的组织级绩效进行关注。包括：过程变化管理、技术变化管理、错误预防。 SJ-T11234中6级为：不完整级、已执行级、受管理级、已定义级、定量管理级、持续优化级。

4，需求

1）客户需求

①隐含需求

这个阶段，客户对自身的需求不清楚，但知道自己对哪里不满意。

②明确需求（客户提出）

对需求明确。

③采购标准

有时我们对客户提出的明确的采购标准可能无能为力。

2）需求不确定性

往往是需求的不确定性对开发造成了影响。不确定是因为：

①描述不清

比如：用户要求系统有可扩展性，但是具体是什么样并不清楚。此时我们需要自己信任的团队去做市场调研。

②需求变更

随着开发进程，用户对原先模糊的需求明确了，要求需求变更。

③需求冲突

用户不清楚具体实现。
用户的需求描述有潜在的冲突和内在的矛盾。
开发人员对相关领域不熟悉，引发对需求的误解。
用户并不一定认识到自己的实际需求。

此时我们需要有一套专门的成熟的流程方案，来问用户需求。（即需求分析，很重要的环节，如果缺少，后期会付出惨重代价）

④自然语言描述有歧义

⑤外部环境变化

如某政策变化。

3）面对需求的原则

a. 在《重构》中，有说：不管用户提出什么方案，你可以确定且卫衣能够保证的是：它们一定会在6个约4内再次提出修改。笔者认为甚是中肯，我们不应该抱怨软件需求的不断变动，而应该注重需求分析和开发过程中软件质量的保证。
b. 不同的用户需求变动也不同，很多特性并不是越成熟越好。比如：军方软件，要求高可靠性，低可移植性。
c. 软件质量是生产出来的，而不是检测出来的。
测试只能证明代码的错误，但不能改善软件的质量。

5，软件测试

1）测试用例

一组测试数据（典型值、边界值、异常值等）+预期结果，测试实际情况是否与期望输出相同。
有专门的文档进行管理，可能包括：路径测试用例、功能测试用例、健壮性测试用例、性能测试用例、图形用户界面测试用例、信息安全测试用例、压力测试用例、可靠性测试用例、安装/反安装测试用例。每个用例下有成套的成熟的测试问题流程。

2）重要性

软件发布后，客户报告的软件问题有：
② 客户执行了未经测试过的代码。
②执行了与测试顺序不同的程序语句组合。
③ 执行了与测试输入语句不同的组合。
④ 客户的操作环境从来没测试过。
（软件环境）比如网络环境、系统、浏览器版本等。
是故，大型通用软件，在正式发布前，通常需要执行Alpha和Beta测试，目的是从实际终端用户的使用角度，对软件的功能和性能进行测试，以发现可能只有最终用户才能发现的错误（此时即是获取软件环境，需要在Beta版本中，做好自动上传错误的处理）。
Alpha版本经过实验室模拟环境测试后，发布为Beta版本给真正的用户去测试。我们不仅需要了解软件环境，还要了解软件周境：即使用人员的身份和能力（用户画像）。包括：用户、任务、设备、产品物理环境、社会环境等。

2）关注点

①软件的可靠性

是一个概率指标。
在《重构》中，亦有提出：类应该包含它们自己的测试代码（把期望的输出放进测试代码中，做一个比较即可。确保所有测试完全自动化，让它们检查自己的测试结果）。我们需要一套测试来反馈异常。包括：容错性（如word自动保存、撤销等功能）、成熟度（避免软件故障引起软件失效）、易恢复性（文档异常关闭可以恢复、删除只是不对用户显示，并未删除真实数据）。服务请求的重定向，也属于可靠性的一个范畴。