质量综述

随着互联网快速发展，早期的传统软件公司强调工程的严谨性，CMMI，ISO9000格局已经发生变化，逐渐退出历史舞台。前期敏捷理念被迅速的普及。Scrum迎合了产品管理的需求, XP迎合了工程化发展的需求。各自发展都很迅猛，然后逐渐衍生了更深入的CI、CD和DEVOPS等模式。

企业扁平化管理，大质量部模式被打散，为了提高运作效率， QA或者测试工程师团队被逐渐分拆到各个具体业务部门，技术性测试工程师开始逐渐发挥价值。未来随着DEVOPS完善，质量问题将会越来越突出不久的将来可能会出现DEVQA。

根据目前软件发展趋势，软件质量可以分为发布前软件质量和发布后软件质量，发布前软件质量分为软件质量验证和软件质量交互，发布后软件质量可以分为软件质量监控和软件质量运维如下图：

软件质量综述图

质量验证

软件质量验证，具体的说就是软件测试，它分为黑盒测试，灰盒测试，白盒测试，灰度测试。

质量验证及相关内容

在传统软件公司强调工程的严谨性黑盒测试发展很成熟，方式方法也很全面，测试资源投入比较多。这样开发人员可以专心写着优雅的代码，只做单元测试和接口、组件测试就可以了，其他的事情都让测试人员去干。

随着计算机科学专业在大学完善，越来越多的科班生都参与到测试行业，在互联网公司随着开发人员慢慢渗透到测试，自动化测试、白盒测试和灰度测试越来越盛行。流行上面主要原因是分层自动化，测试需求减少，测试人力资源减少越来越专业化，测试、开发比例越来越低，让机器干活，逐渐释放人力，节约成本。下面逐渐开始介绍质量验证，质量验证包括黑盒测试、白盒测试、灰盒测试、灰度测试。

黑盒测试

黑盒测试分功能测试和非功能测试。

常用的功能测试有单元测试、接口/组件测试、冒烟测试、集成测试、系统测试、回归测试、UI测试、α测试、β测试，非功能测试有性能测试、稳定性测试、安全测试、恢复测试这些测试都是一个项目必须要有的方式，但是在时间和人力允许的情况下可以有交叉测试、兼容性测试、可用性测试、比较性测试、探索性测试。然后使用分层自动化测试来提高上面各种测试效率。

黑盒分层自动化可以分为单元测试自动化、集成接口自动化、UI层自动化，单元测试采用框架如java的Junit、testNG，C#的NUnit，python的unittest、pytest等，集成接口自动化框架如SoapUI（改名叫Ready!API）、Postman等,UI层自动化如QTP，Robot Framework、watir、selenium等，具体怎么做分层自动化，具体需求根据具体项目去做。

• 开发人员自测标准：完成需求文档、设计文档、完成代码开发
• 提交测试人员标准：开发人员输出单元测试，接口/组件测试报告、测试人员通过冒烟测试

单元测试、接口/组件测试

• 输入：完成需求文档、设计文档、完成代码开发
• 输出：单元测试用例、单元测试报告
• 人员：开发人员
• 环境：开发环境

冒烟测试

• 输入：完成单元测试报告、冒烟测试用例
• 输出：冒烟测试报告
• 人员：测试人员
• 环境：测试环境

集成测试

• 输入：完成冒烟测试报告、集成测试用例
• 输出：集成测试报
• 人员：测试人员
• 环境：测试环境

系统测试

• 输入：集成测试报告、系统测试用例
• 输出：系统测试报告
• 人员：测试人员
• 环境：测试环境

回归测试

• 输入：功能测试报告、回归测试用例
• 输出：回归测试报告
• 人员：测试人员
• 环境：测试环境\

安全测试

• 输入：功能测试报告、安全测试用例
• 输出：安全测试报告
• 人员：测试人员
• 环境：测试环境

性能测试

• 输入：功能测试报告、性能测试用例
• 输出：性能测试报告
• 人员：测试人员
• 环境：测试环境

稳定性测试

• 输入：功能测试报告、性能测试用例
• 输出：稳定性测试报告（它往往和性能测试报告一起出）
• 人员：测试人员
• 环境：测试环境

UI测试

• 输入：回归测试报告、UI测试用例
• 输出：UI测试报告
• 人员：测试人员
• 环境：测试环境

α测试

• 输入：功能测试报告、α测试用例
• 输出：α测试报告
• 人员：公司内部人员
• 环境：测试环境

β测试

• 输入：功能测试报告、性能测试报告
• 输出：β测试报告
• 人员：客户
• 环境：生产环境

白盒测试

白盒测试常用的测试方式有单元测试、组件测试、系统测试、性能测试、静态代码测试。这里说性能测试和黑盒测试里面性能方式有点不同这里强调的是一个大方法、大函数调用执行1万次所消耗响应时间。

在互联网时代的白盒测试测试人员主要负责代码质量，代码质量包括白盒测试和黑盒测试里面的非功能测试（上面已经介绍了黑盒测试里面的非功能测试这里就不在介绍了）如：静态代码测试（程序风格、程序逻辑、代码安全、程序建状性）及开发人员单元测试、组件测试代码覆盖率，配合开发人员一起完成业务逻辑代码自动化，不能自动化代码分层自动化。完善自动化测试体系。
白盒分层自动化可以分为静态代码扫描（PMD、JOCOCO、Profile）、单元测试(TestNG、junit)、集成测试、安全测试(Fortify+findbugs)、自动化性能测试(jmeter)

• 开发人员自测标准：完成需求文档、设计文档、完成代码开发
• 开发、测试人员标准：完成静态代码测试规则编写、完成白盒测试、自动化测试框架选型

单元测试、接口/组件测试

• 输入：完成需求文档、设计文档、完成代码开发
• 输出：单元测试用例、单元测试报告
• 人员：开发人员
• 环境：开发环境

系统测试

• 输入：单元测试报告、系统测试用例
• 输出：系统测试报告
• 人员：开发人员、测试人员
• 环境：集成环境

静态代码测试

• 输入：完成代码调试
• 输出：静态代码测试报告
• 人员：开发人员、测试人员
• 环境：集成环境

灰盒测试

灰盒测试介于黑盒和白盒之间，它包括恢复测试、安全测试、性能测试，但是目前有很多持续集成中的自动化都是采用灰盒测试用例

灰度测试

灰度测试：把生产环境用户流量引到另外一个互不相干的环境验证系统功能，由A/B测试演变而成，此项测试常用于仿真测试、全链路压力测试，现在好多互联网公司架构，业务改进都向这方面设计，用来保证回归上线用户不丢失。在生产进行灰度测试往往要网络部门进行网络配合，特别适合业务重构，或者业务迁移。常用测试工具如：TCPCOPY、Gor

• 测试、开发、运维人员测试标准：程序代码编写完成，环境搭建完成。
• 输入：完成功能测试，线下性能测试
• 输出：灰度测试报告
• 人员：开发人员、测试人员、运维人员
• 环境：另一套生产环境或者测试环境

质量交互

质量交互它指的是软件开发、配置管理、构建管理、持续集成、测试管理、环境管理、部署管理、数据度量和分析层层交互，它从以前的CI、CD、已经逐步演变成DEVOPS如下图：

质量交互

DevOps是企业内开发、技术运营和质量保障这三方面工作的融合，用于促进开发、技术运营和质保部门之间的沟通、协作与整合。有研究显示，在那些引入了DevOps概念的企业中，开发与运营人员在设计、构建、测试工作中共同在内部应用上进行协作之后，可以将产品开发的效率提升20%,强IT服务绩效的团队比较差IT服务绩效团队的部署频率要快30倍，变更失败率要低50%。如下图

DevOps

配置管理

开发人员从稳定的最新版本中Checkout代码在本地开发新功能，在本地构建（测试、代码检查）Check in在主干上编译、等待持续集成结果。它可以带来以下最佳实践：

• 全面的配置管理，它包括项目代码、配置文件、构建脚本、数据库脚本、部署脚本、基础设施信息等，可以选择SVN或者分布式管理系统Git。
• 有效的代码提交注释。清晰的提交功能说明，提交者信息。
• 频繁的提交代码到主干，按照一定的规则频繁提交变更，让参与者及时获知到项目的变更信息；提交的变更是原子性的，并且有信心不能影响到原有业务。
• 配置的分类，何时将配置信息注入到应用内，构建时，打包时，运行时，推荐在运行时加载配置信息。
• 依赖的管理，应用的外部依赖文件的版本管理，例如jar文件，可以使用Maven、Ivy进行管理。

构建管理

构建模块间依赖采用二进制构建产物，并按照1-5-10（构建运行的时间，最多容忍10分钟，一般是5分钟，最快是1分钟）法则构建任务重Push改成Pull编译结果推送到产品仓库管理。它的最佳实践：

• 构建、部署流程脚本化，让构建、部署过程成为一个可重复性并且可靠的行为。
• 使用相同的部署脚本向所有环境进行部署，避免产生在开发环境能运行，测试环境无法运行的情况。
• 部署过程是幂等的，无论目标环境处于何种状态，部署流程应该总是令目标环境达到正确的状态。
• 部署系统的增量式演进，以迭代的方式不断完善部署过程。
• 任何时候可以重新构建二进制文件,容器部署到各各平台，并且部署平台的依赖都是一致的，使部署的应用做到标准化

持续集成

开发人员频繁提交代码到主干持续集成，并执行自动化构建和测试并分级测试快速反馈，如果构建失败立即修复。它的最佳实践：

• 构建失败后不要提交代码新代码，让开发人员能够快速的找到失败的原因。
• 提交前在本地运行所有的测试用例，或者让持续集成服务器（Jenkins）完成此事。本地测试通过后，可以增加提交的信心。
• 等到提交测试通过后再继续工作，直接把问题扼杀在持续集成中，而不是流露到外面人工检查，10分钟的等待测试通过时间是值得的。
• 时刻准备着回滚到前一个版本，世界上没有完美的事情，谁也无法保证每次提交都是正确的，时刻保持警惕。
• 在回滚到上一个版本之前规定一个修复时间，约定一个修复问题的时间，比如10分钟，如果实在找不到原因，在回退到上一版。
• 不要注释掉失败的测试，保持一定量的测试覆盖率，一般来说50%。同时，可以允许有2%左右被注释掉的测试用例（出于某种情况）。但每次构建时，都需要扫描测试用例的覆盖率。TestNG、junit、Sonar、Selenium工具是不错的选择。
• 特别是测试驱动开发，任何东西都是可测试的，要是不能测试直接重构，直接导致自动化构建和测试，降低了人力成本。

测试管理

建立分级测试体系，从多个层次和多个验证角度实现质量防护网如下图：

分级测试模型

从上面图分级测试模型根据测试运行时间，不包括写测试用例时间它划分为白盒分层自动化、功能分层自动化、非功能分层自动化、线上仿真测试。

• 白盒分层自动化主要以静态代码检查为主，系统设计架构度量可以用RFC，系统设计架构度量达到类高内聚、低耦合LCOM4指标衡量，代码风格可以用sonar加插件（PMD、JOCOCO、Profile）的方式检查，死锁和一致性检查Lint4j插件，安全测试可以用Fortify+findbugs，单元测试可以用TESTNG或者是junit ,Smoke Test可以用从功能自动化程序中抽取一些用例采用junittask去执行。
• 功能分层自动化主要完成功能自动化涉及到功能自动化工具如Testng、Selenium、Junit、Suite、Qunit
• 非功能分层自动化主要是那些不能自动化测试的用例，已经需要长时间运行的性能测试及性能测试异常测试
• 线上仿真测试主要采用是灰度测试常用工具Tcpcopy、Gor

环境管理

基础设施的信息管理是容易被忽视的地方。但是环境的不稳定，造成部署，排错的成本成指数倍增长。它的最佳实践：

• 所有环境标准化，测试环境要和生产环境保持一致，开发环境由于变更频繁，可以有一定的差异，但是差异也是在可控范围内。
• 基础设施的信息也要纳入到版本控制，对待环境信息也要向对待代码一样，记录变更信息，回溯历史版本。
• 使用自动化手段对所有环境进行变更，避免手工操作带来的未知环境差异。Puppet，Ansible配置管理工具能够有效的解决此类问题。
• 虚拟化、容器化方式构建应用运行环境，快速搭建环境，标准化环境。利用现在流行的Docker容器技术，将应用所需所有内容封装起来，交付给下游，是一种非常高效，避免差异化的方式。

部署管理

部署对运维来说是一个体力活，怎么样才能把一个体力活变成一个让机器干的活，这样才能释放运维人员。它的最佳实践：

• 采用统一部署管理平台
• 快速部署、回滚
• 灰度发布
• 运维监控和业务监控

数据度量和分析

在DEVOPS里面数据度量和分析是重要的部分，要是没有这些数据不能体现效率、质量是否提高。这些数据通常包括构建数据、线下质量验证数据、及线上质量数据。

质量监控和质量运维

随着业务发展，互联网公司更应该重视线上质量，对比传统的软件开发，互联网公司更加没有办法确定需求价值，可以说是在不断的尝试过程，线上质量监控分析和线上质量分析运维越来越被各大互联网公司重视。线上质量可分为线上质量监控和线上质量运维，如下图：

质量监控和质量运维图

质量监控分为性能质量监控、功能质量监控、安全质量监控

性能质量监控

基础监控

cpu/cpuload/mem/jvm mem/iowait/diskbusy/net/spinlock/fullgc/ spinlock(使用自旋锁(spinlock)来实现进程调度的问题)

应用监控

Latency/hit ratio/recursive call/queuesize/thread status/stack/Latency(它表示完全执行一个指令所需的时钟周期)

业务监控

Pv/uv/transaction/
例如：下面是一个TPS统计结果如下图

TPS统计结果图

功能质量监控

1、建立线上拨测功能
2、统计线上用户失败率进行分析优化如：请求超时，是业务超时，还是系统超时如下图：

线上用户失败监控

安全质量监控

线上安全质量监控可以采用WAF防火墙。例如NGINX中的ngx_lua_waf支持 WAF 防护功能。
对上面三大部分只是说的简单的监控，并没有深化，对上面三大监控可以进行持续优化，关于质量运维提到的部分还可以跟踪完善、优化，线上质量运维空间还很大。

附录

名词说明
黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。
白盒测试：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否以经过检查
灰盒测试：是介于白盒测试与黑盒测试之间的，可以这样理解，灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法。
恢复测试：主要检查系统的容错能力。当系统出错时，能否在指定时间间隔内修正错误并重新启动系统。恢复测试首先要采用各种办法强迫系统失败，然后验证系统是否能尽快恢复。对于自动恢复需验证重新初始化（reinitialization）、检查点(checkpointingmechanisms)、数据恢复(datarecovery)和重新启动(restart)等机制的正确性；对于人工干预的恢复系统，还需估测平均修复时间，确定其是否在可接受的范围内
互联网的特性：我们可以总结为四个字多、快、好、省，1、多就是指用户多，信息量多和服务器也多，在这个庞大的消费群体作用下，有着巨大的利润市场。2、快是指获取信息和传递信息的速度快，这无疑给信息交流和商贸活动提供了快速的通道。3、好是指在互联网上我们可以根据我们的需要，选择我们个性的东西，不需要因为别的因素而耽搁。4、省是指省时、省力、省财、省物、省心、省神，还可以节省很多很多的费用
DevOps****的技术栈与工具链

Everything is Code，DevOps也同样要通过技术工具链完成持续集成、持续交付、用户反馈和系统优化的整合。Elasticbox整理了60+开源工具与分类，其中包括版本控制&协作开发工具、自动化构建和测试工具、持续集成&交付工具、部署工具、维护工具、监控，警告&分析工具等等，
补充了一些国内的服务，可以让你更好的执行实施DevOps工作流。

• 版本控制&协作开发：GitHub、GitLab、BitBucket、SubVersion、Coding、Bazaar
• 自动化构建和测试:Apache Ant、Maven、Selenium、PyUnit、QUnit、JMeter、Gradle、PHPUnit、Pipeline
• 持续集成&交付:Jenkins、Capistrano、BuildBot、Fabric、Tinderbox、Travis CI、flow.ci Continuum、LuntBuild、CruiseControl、Integrity、Gump、Go
• 容器平台: Docker、Rocket、Ubuntu（LXC）、第三方厂商如（AWS/阿里云）
• 配置管理：Chef、Puppet、CFengine、Bash、Rudder、Powershell、RunDeck、Saltstack、Ansible
• 微服务平台：OpenShift、Cloud Foundry、Kubernetes、Mesosphere
  ·服务开通：Puppet、Docker Swarm、Vagrant、Powershell、OpenStack Heat
• 日志管理：Logstash、CollectD、StatsD
• 监控，警告&分析：Nagios、Ganglia、Sensu、zabbix、ICINGA、Graphite、Kibana
  https://zhuanlan.zhihu.com/p/22638204?refer=ciweekly 工具部分内容摘自这个链接
  DEVOPS参考《黎嘉豪：持续交付：新产品的成长思维.pdf》
  参考url：http://www.d1net.com/cloud/news/381046.html http://www.searchsoa.com.cn/showcontent_83139.html
  https://testerhome.com/topics/6911