通过一张图来了解一下敏捷测试和DevOps测试

lsekfe

  现在DevOps已经成了一个非常热门话题，但是又有谁真正理解了DevOps，可能少之又少。上周聆听了茹炳晟老师的在线课程，通过一张图我才发现真正理解了DevOps。

对本图的理解
　　这张图很好地使我们理解了敏捷、CI/CD与DevOps之间的关系。下面我先来讲解一下我对这张图的理解。
　　对于精益（Lean）就是对我们以前所说的产品开发周期进行不断地快速迭代更新，它包括了产品开发周期的所有阶段：前期调研->立项->获取需求->需求分析->概要设计->详细设计->代码开发->测试->运维的所有阶段。而敏捷（Agile）可以认为从“需求分析”后期到“测试”全部结束对需求的迭代开发过程。持续集成（CI）仅仅发生在敏捷阶段，而CD可以理解为持续部署（Continuous Deployment），在这里可以把持续部署理解为把构建部署到测试环境、准生产环境或生产环境，也可以把CD理解为持续交付（Continuous Deliver），即把经过测试后的构建交付给最终用户，往往CI/CD中的CD指的是持续交付（Continuous Deliver），而持续部署（Continuous Deployment）往往认为是持续集成（CI）的后续阶段。而DevOps在CI/CD的基础上再加上后期在客户环境运行期间的监控。
　　下面我们来谈谈在Agile和DevOps下如何进行测试。谈起Agile和DevOps下的测试，现在比较火的两个词叫做测试的左移和测试的右移。
　　测试的左移
　　先来谈一下测试的左移，其实测试的左移可以左到Business阶段，我在2002年从事测试工作，由于我毕业那个年代基本没有软件测试这个工种的，从大学里出来从事软件技术行业，除了开发就是运维（那个时候叫网管），立项->获取需求->需求分析->概要设计->详细设计->代码开发->测试，全部由软件工程师来完成，后来测试独立开发之后，发现许多缺陷，测试人员如果在测试时候介入，发现一些问题牵扯到架构，数据库设计等问题，修改起来就太晚了，所以公司CTO要求在需求和设计阶段，必须有1到2名资深人员参与评审，效果是非常好的。这也许就是现在所说的测试左移。
　　敏捷研发中的测试
　　接下来说一下敏捷研发中的测试。现在考虑的是一个比较大型的WEB产品，这个WEB产品下的组织架构是这样的：它有多个Feature，采用敏捷研发模式，由多个Feature Team 和 一个Release Team组成。1到n个Feature分配到1个Feature Team中，最后在Release之前由Release Team进行统一的测试，测试通过部署到准发布环境进行验收测试，验收测试完成，正式发布。团队每3-4天会发布一个Beta版本，每1个月发布一个正式产品。Release Team仅对正式产品和准生产环境下的测试负责，Beta版本不经过Release Team的内部测试。
　　Feature Team的每一个Sprint阶段会把1-2个（最多2个）Feature拆分成数个User Story，然后在Sprint计划会议的时候，把这些User Story拆分成数个Task。Feature Team中的开发人员每天领1-数个Task进行开发，开发完毕进行单元测试静态分析，Pass后可以把代码check in到GitHub。
　　Feature Team中测试人员在Sprint前期进行测试计划、分析和设计。会在开发人员写产品代码和单元测试的时候设计。测试计划非常简单，通常为一页纸的测试计划由team内的TO（Test Owner）负责。分析和设计同时进行，对User Story中关键场景的接口测试和冒烟测试书写GUI测试代码。在正式书写这些代码之前，先书写TOL（Test Object List，可以理解为通常测试用例中的标题一栏），TOL书写完毕必须通过TOL Review。团队人员，MTO（Master Test Owner，负责整个团队的测试活动高层人员）必须参加，相关干系人选择参加，评审结果会产生以下情形。
　　添加。
　　  对于遗漏的TOL需要添加。
　　修改。
　　  对于描述的错误的测试用例进行修改。
　　  对于不应该在接口测试中进行而应该在GUI测试中进行的用例进行调整。
　　  对于不应该在GUI测试中进行而应该在接口测试中进行的用例进行调整。
　　删除。
　　  对于彻底错误的测试用例进行删除。
　　  对于没必要进行自动化测试的用例先记录，在探索式测试阶段进行手工测试。
　　所有这些TOL，Feature Team内的每个开发人员必须知晓。
　　评审完毕，书写这些测试代码。书写完毕必须进行Code Review，通过Code Review后会把这些代码check in到GitHub，然后与开发协商可以启动哪些Test Case，并且这些Test Case分为VIP优先级和普通优先级。VIP优先级的Test Case在开发人员每次check in之前必须运行，VIP优先级和普通优先级的会在每天晚上统一由CI负责。这些产品代码和测试代码可以建立在不同的分支上，也可以在一个分支上。如果建立在不同分支上，每天下班之前必须Merage到主分支上，在放到主分支上之前，也要运行其他小组的所有VIP优先级的Test Case，如果没有通过不允许Merage。另外测试人员每天会从GitHub上获取前一天打包好的CI版本，在本地安装后进行1-2个小时的探索式测试。在Sprint中后期，当开发人员完成所有的开发与单元测试工作，测试人员的接口测试与GUI测试代码也基本书写完成，测试人员应该对产品的性能、安全性进行Early Test和对整个系统中进行探索式测试。在这些测试中特别关注本次Sprint和属于本Feature Team的历史模块，当然也可以测试其他Feature Team的模块。Early Test主要对产品的性能和安全进行初步的测试和验证，执行最小性能和安全测试用例集（这个用例集由团队Test Club起草审核后生效，Test Club由每个团队的TO和MTO参加，MTO为Club的负责人）。目的为了提前发现非功能性问题和为Beta版本奠定基础。
　　团队初期的CI仅提供单元测试、接口测试和GUI测试的测试集。后来先后加入了性能测试与安全扫描测试集。并且随着测试集的增加，测试机器由最初的一台变成了分布式架构。VIP测试用例集会在开发人员每次把代码Check in到GitHub中触发，如果测试未通过自动产生回滚，不允许提交，这样的测试一般在5-10分钟内完成，测试报告通过Email形式发给提交代码的开发人员以及书写测试代码的测试人员。每天晚上CI系统在20:00启动，通常在第二天上午5:00结束所有测试任务，并且把测试结果发送到所有人的Email系统中。
　　Release Team会在产品的正式发布之前对整个产品进行全面的非功能性的测试（比如安全性、性能、可靠性、可维护性、可移植性、安装、卸载、在先升级…）和对整个系统进行探索式测试。
　　Feature发现小组内能够立刻修改的缺陷通过自研发的缺陷管理工具进行管理，这些缺陷往往可以及时修复。Feature Team在Sprint结束前确定修复不了的缺陷以及在日常工作中发现其他team的负责模块的缺陷，应该及时发布在整个团队层面的JIRA中。Release Team发现的缺陷也记录到JIRA中。团队采用缺陷管理委员会（由公司的若干个技术大咖组成），缺陷管理委员会会根据情况，每一到两天集中处理新的和复测退回缺陷，确定是否修复？何时修复以及谁来修复？
　　测试右移
　　最后说下测试右移，这可真正是个新东西，产品到了客户处，帮助运维人员搭建好环境，冒烟测试PASS，后期如果有问题，一般也是由客户在使用过程发现。现在测试右移可以包括以下几个方面：
　　生产环境的全链路压测；
　　配合灰色发布下的测试；
　　通过监控运行环境的监控日志分析问题；
　　抓取微服务各个服务之间的调用，建立契约测试；
　　…。
　　这里来探讨一下灰色发布。“天下武功，唯快不破”，是现在移动互联网时代对软件提出的新的任务，随之对于对用户质量要求不太高的产品提出了灰色发布。灰色发布通常可以分为金丝雀发布与功能开关发布两种情形。现在的网络架构均为分布式架构，采用灰色发布，可以把需要发布并且测试不太充分的模块部署到分布式架构的一台机器上。假设现在这个分布式架构上有10台机器，采用负载均衡的体系，这样就有10%的用户使用的是新版本的产品，在使用过程中如果产生问题会及时通过问题反馈系统反馈给研发人员，假设问题不严重可以在用户使用的情况上，及时调整补丁；但是问题一旦非常严重，立即复原到以前功能（金丝雀发布采用把以前的版本替换新版本；功能开关采用关闭功能开关，由此可见功能开关的策略要比金丝雀发布策略要先进，但是对研发人员的技能也高）。这些问题在本地的进行修改且测试通过后重新进行灰色发布。经过一段时间的运行没有发现问题，可以逐步部署到多台机器上，在这里特别注意，当部署的机器为全部机器的30%、60%和90%的时候，请多留一点时间，因为这个情形下可能会产生一些关于性能方面的问题，一旦发现问题立刻进行修复处理，特别情况下考虑版本的回滚。当所有机器都部署新版本后，系统的升级也就完成。
　　总结
　　总结一下：在DevOps情形下的软件测试包括测试的左移、敏捷开发中的测试以及测试的右移。测试的左移主要考虑对需求设计的评审以及本文未涉及到的TDD（UTDD）、BDD和ATDD。测试的右移主要考虑在生产环境中的测试，敏捷开发中的测试主要考虑在Sprint期间探索式测试和脚本测试相结合的方式和正式版本Release之前的全面的测试。