1、软件质量的定义
软件质量是软件特性的综合，指软件满足规定或潜在用户需求的能力，其主要从内部质量、外部质量、使用质量和过程质量这四个方面来衡量。
2、软件质量模型
测度与度量：在软件质量中用于测量的一种量化的标度和方法即为测度，而名词的度量即用来指测量的结果。
1. McCail质量模型
这是由McCall和他的同事在早期提出的软件质量模型，指出了影响软件质量因素的分类，其主要集中在以下三个方面：

操作特性(产品运行)
承受可改变的能力(产品修订)
新环境适应的能力(产品变迁)

具体的模型图如下(来源<软件评测师教程>)：


2. Boehm质量模型
Boehm及其同事提出了如下的分层的软件质量模型，除了包含用户期望与需求之外，还提出了McCall模型中没有的硬件特性。



Boehm模型始于软件的整体效用，从从系统交付后涉及不同类型用户的考虑；用户分为三种，分别为初识用户、将软件移植到其他环境下使用的用户、维护系统的程序员。这三种用户都希望整个系统是可靠的。Boehm模型反映了对软件质量的理解，即软件做了用户要它做的，有效地使用系统资源、易于用户学习和使用、易于测试和维护。
3. ISO9126质量模型
ISO9126软件质量模型是一个分层的质量模型，有6个影响质量的特性，模型中说明了质量特性及其子特性的关系。



标准的软件质量模型分为三个层次，第一层是6个影响软件质量的主要因素(即下面的质量的特性)，在标准中称为质量特性，而每个特性又可以通过第二层的若干个子特性来进行测量，而第二层的每个子特性在测量时又要定义并实施若干个度量。

此模型的出发点是使软件满足用户明确或潜在的需求，这六个特性最大可能的涵盖了其他早期质量模型中的所有因素，并且彼此交叉最小。
3、软件质量的特性
软件的质量特性主要有六个大的特性，其中每个特性中又有一些子特性，分别如下所述。
1. 功能性
定义：软件在指定条件下使用时，满足用户明确或隐含需求的能力。

子特性：

适合性：软件为指定的任务和用户目标提供一组合适功能的能力
互操作性：软件与一个或更多的规定系统进行交互的能力。
安全性：软件保护信息和数据的能力，以使未授权的人员或系统不能阅读或修改这些信息和数据，而不拒绝受权
依从性：软件遵循与各种特性相关的标准、约定或法规以及类似规定的能力。这些标准要考虑国际标准。
准确性

2. 可靠性
定义：软件在指定条件下使用时，维护规定的性能级别的能力。

子特性：

成熟性：软件为避免由软件中错误而导致失效的能力。
容错性：在软件出现故障或者违反指定接口的情况下，软件维持规定的性能级别的能力。
易恢复性：在失效发生的情况下，软件重建规定的性能级别并恢复受直接影响的数据的能力。

3. 易用性
子特性：

易理解性：软件使用户能理解软件是否合适，以及如何能将软件用于特定的任务和使用环境的能力。
易学性：软件使用户能操作和控制它的能力。
易操作性：软件使用户能操作和控制它的能力。

4. 效率
定义：在规定条件下，相对于所用资源的数量，软件可提供适当性能的能力。

子特性：

时间特性：在规定条件下，软件执行其功能时，提供适当的响应和处理时间以及吞吐率的能力，即完成用户
资源利用性：在规定条件下，软件执行其功能时，使用合适的资源数量和类别的能力。

5. 可维护性

易分析性
易更改性
稳定性
易测试性

6. 可移植性

适应性
易安装性
一致性
易替换性

参考
《软件评测师教程》

事务的四个属性

原子性(Atomicity)

事务是一个原子操作单位，对其数据的修改，要么全都执行，要么全都不执行

一致性(Consistent)

在事务开始和完成时，数据都必须保持一致，这意味着所有相关的数据规则都必须应用于事务的修改，以保持数据的完整性；事务结束时，所有的内部数据结构也都必须是正确的

隔离性(Isolation)

数据库系统提供一定的隔离机制，保证事务在不受外部并发操作影响的“独立”环境执行，这意味着事务过程中的中间状态对外部是不可见的，反之亦然

持久性(Durable)

事务完成之后，它对于数据的修改是永久性的，即使出现系统故障也能够保持

并发事务带来的问题

更新丢失

两个事务或多个事务选择同一行，然后基于最初选定的值更新该行时，由于每个事务都不知道其他事务的存在，就会发生更新丢失问题，最后的更新覆盖了其他事务的做的更新

脏读

事务A读取到了事务B已修改但是尚未提交数据，还在这个基础上做了操作，此时，如果事务B回滚，A读取的数据无效，不符合一致性要求

不可重复读

事务A读到事务B提交的新增数据，不符合隔离性

幻读

事务A读取到了事务B提交的新增数据，不符合隔离性

提醒：

脏读：当前事务可以查看到别的事务未提交的数据（侧重点在于别的事务未提交）

不可重复读：侧重于已提交事务的更新修改数据

幻读：侧重于已提交事务的新增和删除

事务隔离级别

 
			
读数据一致性
			
脏读
			
不可重复读
			
幻读
		
未提交读
			
最低级别，只能保证不读取物理上损坏的数据
			
是
			
是
			
是
		
已提交读
			
语句级
			
否
			
是
			
是
		
可重复读
			
事务级
			
否
			
否
			
是
		
可串行化
			
最高级别，事务级
			
否
			
否
			
否
		
 

锅炉作为电厂“三大件”之一，其平稳安全的运行对电厂具有重要意义，做好锅炉安全管理工作，就离不开水冷壁、过热器、再热器和省煤器这“四管”。锅炉四管涵盖了锅炉的全部受热面，它们内部承受着工质的压力和一些化学成分的作用，外部承受着高温、侵蚀和磨损的环境，很容易发生失效、泄漏等问题，影响电厂经济效益和人身安全。

电厂锅炉安全管理特点与问题分析

在锅炉四管安全管理的工作中，有三个特点：

1、检修工作的低频性

正常电厂平均1-2年进行一次停炉检修。由于检修工作的低频特性，导致检修计划的制定、检修记录的整理、录入很难通过一次或者几次的培训来实现熟练掌握。老员工在对新员工进行教学时，实操机会较少，通常只是理论培训，学习效果、培养速度均较低。

2、记录整理的集中性

检修产生的数以万计的各类检修数据，要在短时间内集中完成以实现检修的数据分析与质量评估。这样的工作强度会给电厂工作人员带来巨大的压力，同时由于检修工作的低频性，在非专业人员的参与下也难以保证信息录入的准确性。

3、数据分析的专业性

数据的深入分析如同沙里淘金，是没有止境的。而传统的防磨防爆管理系统提供商，在销售完成后，不会对使用人员进行持续数据分析培训，用户的数据分析能力得不到有效提升，数据虽然存在，但难以真正发挥价值。

电厂锅炉安全管理特点与问题分析

由工作中的特点所引发的隐患和问题主要有一下几点：

1、防磨防爆数据过于分散，事故分析无法整合多方数据，无法实现对施工人员的评价追责；

2、不同位置减薄状态、减薄速率依靠管理人员个人经验，防磨措施的选取缺少数据支持；

3、图档资料缺少统一管理，容易随人员异动而遗失，不便于查阅管理；

4、运行参数监控界面设计不友好，没有进行深入的数据可视化设计与分析研究；

5、检修策划的工作开展困难，容易出现漏检忘检现象；

6、缺少三维模型，数据展现不直观，新员工培训与检修安排依赖二维图纸沟通成本高；

7、检查记录归档不到位，归档数据质量差，无法系统的分析与利用。

电厂锅炉安全管理特点与问题分析

发现问题，用技术与创新管理手段解决问题，防治锅炉四管泄漏工作是一个复杂的系统工程，在重视人员培训和交流协作的同时，重视运行的规范操作，做认真细致的防磨防爆检查工作，重视设备的更新改造，重视问题和事故的深入分析和落实整改。这样，才能保证设备的健康状况，将锅炉四管泄漏问题降低到最低水平。

序言
大家好，我是老马。
平时一直在使用 springboot，却总感觉对于其理解不深入，于是有两个这个系列的整理。
主要是为了系统的学习一下 springboot，残缺补漏一下。主要翻译自官方文档，结合自己的实际使用。
springboot 学习笔记(一)引导类特性详解
springboot 学习笔记(二)外部化配置详解
springboot 教程(三)如何实现配置与环境隔离？
日志
场景
日志是为了问题排查定位，是非常必要的功能。
springboot 默认配置的 logging 就可以非常方便我们使用，不过还有一些细节，值得我们学习一下。
logging
springboot 默认使用 common logging 进行内部的日志输出。
当然，业界最有希望一统天下的就是 slf4j 这套接口标准。
当我们使用 starter 时，默认使用 logback 作为日志实现。
日志格式
我们截取一段日志格式如下：
2021-01-11 19:41:08.821  INFO 1300 --- [           main] c.g.h.s.boot.learn.profile.Application   : Starting Application on hackerone with PID 1300 (D:githubspring-boot-learnspring-boot-profileargetclasses started by Administrator in D:githubspring-boot-learn)2021-01-11 19:41:08.824  INFO 1300 --- [           main] c.g.h.s.boot.learn.profile.Application   : The following profiles are active: prod2021-01-11 19:41:08.883  INFO 1300 --- [           main] ationConfigEmbeddedWebApplicationContext : Refreshing org.springframework.boot.context.embedded.AnnotationConfigEmbeddedWebApplicationContext@195092a: startup date [Mon Jan 11 19:41:08 CST 2021]; root of context hierarchy2021-01-11 19:41:10.221  INFO 1300 --- [           main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat initialized with port(s): 18080 (http)2021-01-11 19:41:10.232  INFO 1300 --- [           main] o.apache.catalina.core.StandardService   : Starting service [Tomcat]2021-01-11 19:41:10.233  INFO 1300 --- [           main] org.apache.catalina.core.StandardEngine  : Starting Servlet Engine: Apache Tomcat/8.5.23
输出以下项目：
日期和时间：毫秒精度，易于排序。
日志级别：错误，警告，信息，调试或跟踪。
进程ID。
--- 分隔符用于区分实际日志消息的开始。
线程名称：用方括号括起来(对于控制台输出可能会被截断)。
记录器名称：这通常是源类名称(通常缩写)。
日志消息。
一般情况下，这些配置就已经足够了，不过还是建议添加一个 traceId，这样更加便于问题排查。
你可以阅读：
java 注解自动输出日志新增拦截器与过滤器
java 注解结合 spring aop 日志唯一标识
java 注解结合 spring aop 实现自动输出日志
控台日志
调整日志级别
一般情况下是 INFO 级别，如果我们想调整日志级别怎么办呢？
有两种方式：
(1)命令行指定
$ java -jar myapp.jar --debug
(2)配置文件指定
在 application.properties 文件中添加
debug=true
效果如下：
2021-01-11 20:32:03.694  INFO 8764 --- [           main] c.g.h.s.boot.learn.profile.Application   : The following profiles are active: prod2021-01-11 20:32:03.694 DEBUG 8764 --- [           main] o.s.boot.SpringApplication               : Loading source class com.github.houbb.spring.boot.learn.profile.Application2021-01-11 20:32:03.754 DEBUG 8764 --- [           main] o.s.b.c.c.ConfigFileApplicationListener  : Activated profiles prod
彩色输出
彩色输出可以让我们更加方便的在控台看出日志的级别。
ERROR 一般是红色，WARN 一般是黄色。
我们的视觉永远更加敏锐一些，不过这也只局限于控台日志，当真输出到文件时，还是白纸黑字。
文件输出
生产中，日志需要长期保留，所以需要输出到对应的文件中。
不过一般实践中，都会直接使用 logback.xml 之类的配置，所以这里只做简单的介绍。
文件名称
默认是只输出到控台的。我们可以指定输出的路径，名称可以是确切的位置，也可以相对于当前目录。
指定文件
# 写入指定的日志文件。logging.file.name = my.log
指定文件夹
# 将spring.log写入指定目录。logging.file.path = /var/log
日志的归档
生成的日志量一般比较大，磁盘都是有限的，所以一般都会对 3 天以上的日志进行归档。
单个的日志文件也不能太大，一般 500M 一个文件。
日志级别
我们有时针对不同的类，希望看到的日志级别可能不同。
比如希望看到 mapper 对应的详细 sql，一般开启 DEBUG 级别。
对于一些中间件 mq 之类的，可能只关心 WARN 以上级别。
这些都可以通过配置方便的指定：
logging.level.root=warnlogging.level.org.springframework.web=debuglogging.level.org.hibernate=error
日志组
发现这个功能还是比较强大的，个人感觉就是把一系列的包归为一个组，可以更加方便的配置日志级别等。
实现方式：
logging.group.tomcat=org.apache.catalina,org.apache.coyote,org.apache.tomcat
这样就可以把 org.apache.catalina 和 org.apache.coyote,org.apache.tomcat 都认为是 logging.group.tomcat 这个组。
我们可以使用下面的方式，统一修改日志级别：
logging.level.tomcat=trace
内置
当然，springboot 有一些开箱即用的内置策略：
web
包含：
org.springframework.core.codec, org.springframework.http, org.springframework.web, org.springframework.boot.actuate.endpoint.web, org.springframework.boot.web.servlet.ServletContextInitializerBeans
sql
包含：
org.springframework.jdbc.core, org.hibernate.SQL, org.jooq.tools.LoggerListener
logback 拓展
针对 logback，spring 还做了一些拓展功能，让其变得更加强大。
特定 profile 的配置
通过  标记，您可以根据活动的Spring概要文件有选择地包括或排除配置部分，在 元素内的任何位置都支持这个属性。 这样才做了 profile 与配置的更加强大的整合。 ¨G11G ¨K28K ` 标记使您可以从Spring Environment中公开属性，以在Logback中使用。
    ${fluentHost}    ...
小结
希望本文对你有帮助，如果有其他想法的话，也可以评论区和大家分享哦。
各位极客的点赞收藏转发，是老马持续写作的最大动力！
我是老马，期待与你的下次重逢。