01 一个生产环境 Bug 的解决办法先来跟大家分享一个生产环境下的 Bug一个在线订购葡萄酒的系统订购流程相对复杂下单过程中后台会有随机的失败系统采取的措施是重试就是说顾客下单后后台如果有错误就会不停的重试直到成功这个过程对顾客是不可见的。这听起来没什么问题用户体验 似乎也不错。后来有个新版本上线了顾客下单后还是会有随机失败系统依然不停的重试但这次不一样的是有的随机失败下单却能够成功这样就导致用户虽然只订购一箱葡萄酒由于后台的多次重试都成功了用户最终拿到的可能是好几百箱葡萄酒。这是一个非常严重且昂贵的 Bug对于这样的问题作为 QA你能想到的解决办法有哪些1. 瀑布式 QA 流程瀑布式软件开发模式下测试是计划驱动的基本是根据需求文档进行验证测试的目的就是找到尽可能多的 bug而且测试阶段处于开发阶段结束之后的一个相对独立的阶段测试结束之后发布产品到生产环境。基本流程如下对于上述葡萄酒订购系统的 Bug通常的办法就是加强在测试阶段的测试保证除了验证系统功能跟需求文档的一致性以外还可以增加一些 ad hoc 测试 ( https://en.wikipedia.org/wiki/Ad_hoc_testing )确保发布到生产环境的系统尽量的稳定。2. 敏捷 QA 流程敏捷测试则提倡尽早测试、频繁测试QA 要从需求分析阶段就开始介入QA 参与从需求到发布的整个生命周期中各个阶段。在整个 QA 的过程中会依据敏捷测试象限 ( http://lisacrispin.com/2011/11/08/using-the-agile-testing-quadrants/ )在不同阶段采取不同的测试还会根据测试金字塔 ( http://martinfowler.com/bliki/TestPyramid.html )的分层指导加强自动化测试制定有利于项目质量保证的测试策略同时也会做探索式测试 ( http://www.satisfice.com/articles/what_is_et.shtml )尽量去发现更多不易发现的缺陷。敏捷 QA 的流程如下对于葡萄酒订购系统的 bug处理方式也无非就是加强上线前各个阶段的测试提高发布到生产环境的产品质量。除此之外我们还有什么处理办法呢上面两种开发模式下QA 的重点都是放在发布前的测试和预生产环境的质量保证上而较少考虑生产环境的系统质量。随着敏捷开发和持续交付的出现QA 角色逐渐转变到需要分析软件产品在生产环境下的质量。这需要引入产品系统的监控, 制定检测紧急错误的警报条件持续质量问题的确定以及找出在生产环境下使用的度量以保证这种方式可行。回到前面葡萄酒订购系统的那个 Bug如果在生产环境下设置监控预警对于一个订单购买葡萄酒数量异常的情况进行监控将能及时发现 bug并且比较容易在损失发生之前及时阻止产生更严重的后果。这就是生产环境下的 QA 内容之一02. 生产环境的特点为了更好的实践生产环境下的 QA先来分析下生产环境有哪些特点1. 真实、不可破坏生产环境都是真实用户在使用是真正的支持企业业务运转的系统不可以随意在生产环境去做测试尤其是破坏性的测试。2. 基础设施差异生产环境往往有着比测试和预生产环境要复杂和健全的基础设施可能会出现测试和预生产环境不能预测到的缺陷和异常。3. 系统复杂度生产环境需要与多个不同的系统集成 系统复杂度会比测试环境和预生产环境高很多这种复杂的系统集成很有可能导致一些意外的情况出现。4. 数据复杂度生产环境的数据量和数据复杂度也是测试环境和预生产环境无法比拟的通常都不是一个数量级的数据容易引发性能问题、或者一些复杂的数据组合导致的问题。5. 用户行为千奇百怪生产环境的用户分布广泛使用习惯各种各样导致用户行为千奇百怪某些使用行为可能就会产生意想不到的问题。6. 访问受限生产环境由于是真实业务线上的系统对安全性和稳定性要求更高服务器的通常不是所有 QA 可以随便访问的这种访问受限的情况对于生产环境的一些缺陷的排查带来了很大的不便。7. 真实的用户反馈真实用户在生产环境使用能够提出一些真实而重要的反馈但是开发团队往往不能直接接触终端用户QA 也就没有办法获得第一手的用户反馈这些反馈常常需要通过支持团队的转述。生产环境的这些特点决定了 QA 在生产环境不是想做什么就能做什么的原来测试环境和预生产环境那套质量保证理论和方法都行不通了。生产环境下的 QA 有这么多挑战听起来是不是很沮丧不要着急针对生产环境独有的特点一定能找到相应的解决方案。接下来咱们一起来看看生产环境下不仅是 QA可以做什么。03. 生产环境下可以做什么生产环境的这些特点决定了 QA 在生产环境不是想做什么就能做什么的原来测试环境那套质量保证理论和方法都行不通了。要实现生产环境下的 QA有以下三个方向直接在生产环境测试监控预警用户反馈收集1. 直接在生产环境测试前面讲到不能随便去操作生产环境下的系统对其进行测试怎么还能直接在生产环境测试呢的确不是像在测试环境那样测试有一些限制和特定技术的采用。对于只读操作和可隔离特性的测试在不影响真实用户体验的情况下可以对某些功能进行只读操作需要选择用户使用频率较低的时段进行不能进行大数据量的只读操作以免影响系统性能。对于某些特定的特性如果比较方便隔离的话可以在生产环境利用独立的测试数据对其进行测试。蓝绿部署Blue Green Deployment蓝绿部署是一种通过运行两个相同的生产环境“蓝环境”和“绿环境”来减少停机时间和风险的技术虽然不能算是真正意义的直接在生产环境测试也是非常典型的实践之一。在任何时候只有一个环境是活的活的环境为所有生产流量提供服务。通常绿环境是闲置的蓝环境是活的。部署新的版本到绿环境可以先进行测试而不会给真正在使用的蓝环境带来影响。完成部署和测试以后再进行蓝绿环境的切换。此技术可以消除由于应用程序部署导致的停机时间。此外蓝绿部署可降低风险如果新版本在绿环境上发生意外情况可以通过切换回蓝环境立即回滚到上一版本。这样就有机会提前发现新版本部署生产环境可能引起的问题。金丝雀发布Canary release不同于蓝绿部署有两套服务器金丝雀发布也就是我们常说的灰度发布只有一套服务器是通过先部署新版本到其中部分服务器并测试验证没问题再推广部署到更多服务器的发布流程。2. 监控预警前面讲到不能随便去操作生产环境下的系统对其进行测试但是可以通过监控的方式去获得我们需要的信息对异常情况进行预警。提到监控预警不得不提大家都了解或者至少听说过的日志和网站分析工具这两者都是做好生产环境下的 QA 非常有帮助的工具。日志日志就像是飞机上的黑匣子可以记录系统运行的各种信息包括错误、异常和失败等。一旦程序出现问题记录的这些信息就可以用来分析问题的原因同时可以利用记录的日志设置好预警提前预测系统可能出现的问题。生产环境下日志所提供的监控和预警信息将有利于阻止不良后果避免大的损失前面提到的葡萄酒订购系统就是一个很好的例子发现潜在的性能问题通过对日志进行分析可能发现还没暴露出来的性能问题提前修复指导测试和预生产环境的测试通过生产环境下日志的分析可以看出哪些功能易出什么样的错误从而相应调整测试策略加强预生产环境的相关功能的测试。网站分析工具网站分析工具根据具体工具不同所能记录信息也有差异但基本都可以记录如下信息用户使用的操作系统、浏览器等信息用户行为习惯包括使用的时间、关键路径、关键业务流程等用户所在地区、语言等区域信息用户访问量请求的响应时间网站性能等利用网站分析工具收集到的以上数据可以帮助我们调整预生产环境的测试侧重点指导预生产环境的测试根据用户行为习惯等信息还可以帮助优化产品业务价值。3. 用户反馈介绍生产环境特点的时候提到一点就是生产环境能够收到真实的用户反馈这是非常有价值的要做好生产环境下的 QA 一定要利用这些反馈。由于用户行为和习惯的千奇百怪用户提供的反馈也可能是各种各样的为了更好的利用它们需要一个严格的 Triage 的过程对所有反馈进行分类并相应处理。用户反馈可以总结为下面几类缺陷用户在使用过程中系统所出现的问题并且能够稳定重现的我们定义为缺陷缺陷通常会影响到功能的使用是需要修复的根据优先级和严重程度安排相应的修复计划并对其进行修复同时还需要对修复的缺陷增加自动化测试以防被再次破坏。除了能够稳定重现的缺陷有时候还会有一些随机的失败比如前面提到的葡萄酒订购系统的 bug或者难以重现的问题这类问题很难找到原因但是又给用户带来很大的不爽。其实它们通常也是一些缺陷引起的只是根源可能隐藏得比较深对于这种问题的处理办法就是前面部分提到的可以添加日志对相关功能进行监控和预警利用日志协助找到问题根源并进行修复。抱怨用户在使用系统过程中由于行为习惯、网络环境等差异总会有各种抱怨一般以非功能性的问题居多比如易用性、性能、可维护性、可扩展性等当然也有可能是某个功能设计的不能满足真实的用户需求。需要对所有抱怨进行分类确定是非功能的缺陷还是新的需求。用户的抱怨有可能千奇百怪不是所有的都能满足需要根据分类定义优先级确定哪些是需要改进和修复从而采取相应的措施。建议除了反馈问题和提出抱怨用户也会对系统使用方面提一些建议。但一般用户很难提出好的建议要想收集到有价值的信息需要提前设计好问卷进行问卷调查有针对性的去收集或者对一些重要用户进行访谈或者发布一个简单的新功能收集用户的使用建议等。然后对收集到的建议进行分析确定可行性并将可行的建议应用到后续的系统和业务流程的改进中。利用用户反馈改进系统功能可以优化业务价值扩大产品的市场影响力提高企业的竞争力。常被用来收集用户反馈的实践有Beta 测试 ( https://en.wikipedia.org/wiki/Software_testing#Beta_testing )很多有前瞻性的网站或应用会发布新功能给特定用户组Beta 用户收集用户使用新功能的统计数据AB 测试 ( https://en.wikipedia.org/wiki/A/B_testing )同时发布两个不同版本的系统到生产环境并将用户引导到两个版本统计使用每个版本的用户数据Observed Requirement ( http://martinfowler.com/bliki/ObservedRequirement.html )发布一个简单的功能或者发布一个 MVP ( https://en.wikipedia.org/wiki/Minimum_viable_product )版本观察用户使用情况从而引出并收集到用户的真实需求。监控预警、收集和分析用户反馈并不是 QA 能独立完成的需要与不同角色协作QA 在整个过程中主要充当分析者和协调者的角色对生产环境下的质量保证工作起到至关重要的作用跟 DEV 一起讨论监控标准把日志标准化的要求融入到软件开发流程中确保日志能够记录到真正需要记录的信息。跟运维团队一起分析收集到的统计数据指导和优化各个阶段的测试以预防和减少系统在生产环境下的缺陷。跟业务分析人员一起分析和梳理从生产环境收集到的需求相关的反馈提炼出合理的需求优化业务价值。04 生产环境下的 QA 在项目上的实践我所在的项目是一个离岸交付项目采用的是敏捷开发模式四周一次发布到生产环境开发的系统包括一个内部员工使用系统和一个外部用户使用的网站用户遍及全球项目整个已经持续了七年有余生产环境具备前面所描述的所有特点并且生产环境每日的错误日志达到几千条。正是由于错误日志的数量到了一个不能忍的程度生产环境引起了各方的关注也使得生产环境下的 QA 迎来了试点的最佳时机。生产环境下的 QA 在我们项目上的实践主要是三部分内容日志分析和优化、Google Analytics 数据分析、用户反馈的收集和分析下面逐个介绍。1. 日志分析和优化既然错误日志那么多首当其冲就是从这些错误日志下手。项目使用的日志分析工具是 Splunk ( http://www.splunk.com/ )这个工具功能强大、使用方便关于工具的详细信息可以参考官网。下图所示为使用 Splunk 通过指定条件搜索日志文件得到的结果页面结果集里四条类似乱码的东西就是代表有四种类型的错误日志每种错误出现的数量和百分比都有统计点击每条结果可以查看详细的错误日志信息。关于日志的分析和优化我们在项目上做了如下工作1) 分析生产环境的错误日志每天会有专人负责错误日志的分析找出其中的优先级高的问题给团队修复。QA 会协助重现、跟踪并负责测试这些重要的需要修复的问题通过对错误日志的分析QA 可以大概的统计出哪些功能特性比较容易产生错误在接下来的预生产环境的测试中要重点关注。另外对于某些功能由于测试环境的数据等局限性担心部署到生产环境会产生错误或者有性能问题一般上线后会着重关注这样的功能除了日常的监控分析之外还要单独对该功能的日志进行检查以防产生严重问题。2) 监控测试环境的错误日志把生产环境错误日志的分析方法应用于测试环境对测试环境的错误日志进行监控尽量把环境无关由功能引起的错误找出来尽早修复不让其流落到生产环境。据不完全统计最近两三个月通过这种方式发现并修复了好几个潜在的 Bug。3) 利用日志监控不同功能的性能Ops 在 Splunk 里设置有专门的统计和监控系统性能的 DashboardQA 会定期从里边拿出潜在的存在性能问题的功能模块创建对应的任务卡由开发团队来做性能调优。4) 日志记录标准化通过对生产环境错误日志的分析发现现有日志记录存在如下问题存储位置不统一有些日志没有办法通过 Splunk 统计分析造成分析成本的增加记录格式不一致有些日志虽然可以通过 Splunk 看到但是没有记录很有用的信息比如没有记录错误发生时候的一些有意义的 message或者是 Post 请求没有记录输入参数导致排查错误日志的工作增加了难度日志级别定义混乱有些没有到达错误级别error的日志也记成了错误error日志这也是错误日志数量大的原因之一。为了让日志分析更轻松、让日志更全面地记录系统的各种情况针对上面的问题团队讨论并达成共识将日志输出到各个服务器的同一个路径统一日志记录格式并且尽量记录更全面的信息帮助后期的日志分析清晰定义各个日志级别DebugInfoWarningErrorCriticalFatal将已有的误记成错误的日志降低到正确的级别对于新功能则严格按照所定义级别记录日志QA 在用户故事Story的开发机验收Dev-box Testing or Desk Check阶段负责跟开发人员确认相关日志记录是否符合标准并且通过测试环境的日志监控可以及时验证新功能的日志记录情况。2. Google Analytics 数据分析Google Analytics ( https://analytics.google.com/ )以下简称 GA是项目用来统计网站使用情况的工具从 GA 上可以获取很多有价值的信息对这些信息的分析是我们实践的生产环境下 QA 的另一块内容具体做了下面几项工作1) 操作系统和浏览器使用情况分析根据 GA 数据统计分析出用户使用的操作系统和浏览器分布情况从而相应的调整 QA 用来测试的操作系统和浏览器尽量让测试环境跟真实用户更接近。比如前两年客户内部员工使用的浏览器最多的是 IE9那么我们 QA 的测试也是主要关注 IE9而今年变成了 IE11我们重点关注的浏览器也相应调整为 IE11当然鉴于 IE9 的特殊性——容易出问题只要还有用户使用我们还是需要关注而对于没有用户使用的 Firefox我们则不用来测试。2) 分析 QA 测试跟用户真实行为的差异及时调整测试根据GA 上用户访问的路径可以发现我们 QA 的测试跟一些真实用户使用习惯的差异这样如果按照我们通常的路径去测试可能有些问题难以在测试阶段发现。比如QA 在测试环境通常打开“工作记录”的方式是这样的而我们从 GA 上发现真实用户使用过程中打开“工作记录”最多的路径是这样的发现了这种差异QA 就要在测试时候做相应的调整让测试更接近用户的行为习惯。3) 提炼关键业务场景增加测试覆盖一个开发好几年的系统其功能必然是比较复杂的由于自动化测试覆盖率不是很理想过去回归测试需要的投入比较大而且由于功能相对复杂又不是很清楚哪些功能对用户来说最为重要测试很难做到有效覆盖。这种情况对于人员比例低下的敏捷团队 QA 来说是一件非常有挑战的事情通常 QA 们在发布前忙得不行。利用 GA 的数据结合客户业务人员对系统各功能使用情况的介绍我们提炼出来系统最为关键的一些业务场景并且尽量分层参考测试金字塔实现自动化测试覆盖从而不需要花费太多的人力去做回归测试同样可以保证主要的业务流程不至于被破坏而 QA 则可以有更多的时间和精力去做探索性测试等更有价值的事情。4) 发现用户较少使用的功能优化业务流程关键场景就是用户使用频率较高的功能类似的我们还可以通过 GA 发现一些用户较少使用的功能这可能的原因是不符合用户真实行为习惯喜欢用其他路径去完成同样的事情或者不符合真实业务需求也就是说真实的业务环境下根本没有要用到这个功能的地方。对于这种功能首先从 QA 角度来讲我们的测试基本不需要太多去关注如果有相关功能的缺陷它的优先级也很低很低另外可以跟业务分析人员一起分析下原因在后续的功能开发过程中可以作为借鉴从而优化业务流程。5) 分析用户地区分布和使用时间段分布合理安排定时任务运行时间系统用户遍及全球使用时间段分布也就变得复杂为了不影响正常使用有些事情是需要尽量在系统没人使用的时候去做的比如统计某类数据需要定时执行 SQL 脚本等定时任务。通过 GA 上的数据统计出哪个时间段是相对空闲的在不影响真实业务的前提下把一些资源消耗较大的任务安排在那个时候执行合理分配资源以减轻服务器的负担。6) 监控系统性能变化趋势规避性能风险QA 定期查看网站平均访问时间监控性能趋势同时要重点关注那些访问非常慢的页面或功能必要的时候创建性能缺陷卡由开发人员来调查分析并修复或优化。7) 确保 GA 能够统计到所有需要统计的功能GA 数据虽然很有用但前提是正确记录了所需要统计的数据所以在开发过程中要确保 GA 嵌入到了各个需要统计的功能或页面QA 在预生产环境测试的时候需要验证这一点。下图为从 GA 拿到的浏览器分布情况和页面平均加载时间的一些数据3. 用户反馈的收集和分析作为开发团队的我们基本是不能直接接触到系统终端用户的直接接受反馈的是我们客户的 Ops 团队QA 主要通过下面几个途径去协助分析和梳理用户反馈1) 跟 Ops 和业务的定期沟通会议QA 会定期跟客户的 Ops 和业务人员沟通了解用户对于现有系统的反馈找出在测试中需要重视的功能特性将测试环境和预生产环境的测试关注点做出相应的调整。2) 培训 Ops 人员指导和协助客户 Ops 人员利用鱼骨图Fishbone Diagram ( https://en.wikipedia.org/wiki/Ishikawa_diagram )的方法对收集到的用户反馈进行分析和分类将分析结果跟现有的测试覆盖情况进行对比找出测试过程的薄弱环节并做出改进。比如如果某个浏览器出现的 bug 比较多而我们的测试则要加强该浏览器的关注或者是因为不同用户权限导致的问题出现频率高那就得在测试中注意覆盖不同用户角色的测试反之则减弱不同用户的覆盖主要测最常用的那类角色即可。3) 调查和跟踪生产环境 Bug帮助重现和调查用户反馈过来的生产环境 Bug并负责跟踪修复和验证对于难以重现的问题则添加日志监控通过分析收集到的日志信息找出问题根源从而进行修复。4) 协助梳理业务需求系统要增加某个新功能的时候客户 Product Owner以下简称 PO或其他业务人员跟用户会一起沟通该功能相关业务现有的使用习惯、使用场景QA 也会尽力参与这种会议收集用户第一手需求信息这些信息对于后期该业务功能开发时候的 QA 过程将非常有帮助。而还有些功能PO 可能一时也拿不定主意要做成什么样子我们会发布 MVP 的版本给用户使用QA 协助业务人员分析用户使用后的反馈梳理更具体的用户需求。05 生产环境下的 QA 有什么特点1. 不同于测试环境和预生产环境的 QA生产环境的特点决定了生产环境下的 QA 是跟预生产环境的 QA 不同的不是主动的去测试生产环境的系统而是通过设置监控条件收集用户使用系统的反馈对反馈进行分析并改进从而让产品质量获得提高。因此生产环境下的 QA 并不是测试环境和预生产环境 QA 活动的简单后延它有着自己独特的特点。2. 不能独立存在生产环境下的 QA 所设置的监控标准是根据系统的行为特点和在预生产环境下的表现来定义的生产环境下各项反馈的分析结果反过来又影响着预生产环境的 QA 过程而且这两者是相辅相成的只有形成了良性环路才能把生产环境下的 QA 做好。3. 有别于 Ops生产环境设置监控预警和收集用户反馈不都是 Ops 团队可以做的事情吗还要 QA 参与干什么那是因为 QA 有着独特的思维模式和视角QA 的参与能够帮助更好的分析生产环境下收集到的各种反馈并且结合对于系统的了解能够将这些反馈更好的应用到日常的开发工作中。这时候的 QA 带着 QA 和 Ops 的帽子兼具 QA 和 Ops 的部分职责类似于 QAOps不过现在都提倡不要有独立的 DevOps我们也不要独立的 QAOps 角色只是让 QA 这个角色可做的事情得到了延伸和扩展而已本质上还是 QA。4. 跟 APM 的侧重点不同可能有人会觉得生产环境下的 QA 跟 APM 有相似之处那么这两者是不是一回事呢维基百科这样解释 APM ( https://en.m.wikipedia.org/wiki/Application_performance_management )“In the fields of information technology and systems management, application performance management (APM) is the monitoring and management of performance and availability of software applications. 在信息科技和系统管理领域APM 是对软件应用程序的性能和可用性的监控和管理。”APM 更多的是从性能角度出发去管理和优化应用的可用性可以发生在各个阶段不一定是生产环境。生产环境下的 QA 是指在生产环境进行一系列的监控和数据收集从系统功能、性能、易用性等多个方面进行优化从而最终优化业务价值。因此两者是不同的。06 总结生产环境下的 QA 将 QA 的工作范围扩大到从需求到生产环境增加了更多的反馈来源跟持续交付结合可以帮助持续提高产品质量、持续优化业务价值。生产环境下的 QA 给 QA 的工具箱添加了更多的工具提供了更多评估和提高系统质量的选项是 QA 们值得深入研究的话题。生产环境下的 QA 不能走的太远必须先做好测试环境和预生产环境的质量保证并且仅适用于持续交付实践的比较好的组织如果连测试环境和预生产环境的质量保证都做不好而就想着去做生产环境下的 QA那只能是舍本逐末、事倍功半。最后下方这份完整的软件测试 视频教程已经整理上传完成需要的朋友们可以自行领取【保证100%免费】​​​软件测试面试文档我们学习必然是为了找到高薪的工作下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料并且有字节大佬给出了权威的解答刷完这一套面试资料相信大家都能找到满意的工作。