测试质量内建
一、 测试职责
● 1.1、职责一 -理解和澄清业务需求
○ 1. 理解和澄清业务需求的维度：用户、业务影响、业务流程
○ 2、需求可测试性
○ 3、需求描述质量
3.1、需求可测性（需求描述质量）：
● 如果需求不可测，也就不可验收，没办法知道项目是否成功完成；
● 以可测试的方式编写需求，才能确保需求能够正确实现并验证。
3.2、完备性
需求的完备性主要指流程路径需要考虑全面，要求逻辑链路完整，既要有正向路径，也要包括异常场景。（输入正确的会发生什么，输入错误的会发生什么需求都需要定义清楚）
3.3、客观性
需求的描述不要用一些主观性的词语，而是需要客观的数据和示例来说明。易于团队不同角色的理解，而且不容易产生歧义。
3.4、独立性
独立性主要是针对单个业务功能点（敏捷开发中的用户故事），要尽量的独立，跟其他功能边界清晰，减少因为依赖导致的功能点不可测。
不可以A验证输输入必须是B的输出
● 1.2、职责二-制定策略并设计测试
指导性原则：团队为质量负责
测什么：测试的内容
怎么测：测试左移、测试右移和精益测试
1.2.1策略制定：
澄清了需求，还得知道怎么去验证软件产品是否满足了需求，这就需要制定测试策略，并根据策略设计测试。大概说来，需要确定测试范围、测试阶段，覆盖要求的测试范围都需要什么类型的测试（功能与非功能等），在每个阶段采用什么测试方法，手动测试和自动化测试的分配比例，如何设计手动和自动化测试的测试用例，用什么工具实现功能、性能和安全测试的自动化等。
对于杯子来说，确定需求之后，针对每一项需求指标需要确认可能采取的不同测试方法，需要考虑如何测试盛水和加热功能、如何测试耐摔性（直接摔吗？）、以及如何测试安全性等等。
○
○
1.2.2测试流程与质量门禁
目的：把控测试流程各环节的门禁质量从而提升流程整体质量
经常会发现有些团队的测试流程定义的也很清晰，但是每个环节要求做到什么效果并没有严格的要求，很多质量工作做的并不到位，导致后面测试阶段测试人员的压力巨大或者最终交付的质量并不高。
开发阶段：
测试类型：单元测试、接口测试
门禁：单元测试覆盖率、代码扫描通过率、API或者功能连通性
测试阶段：
测试类型：冒烟测试、集成测试、回归测试、探索式测试
门禁：测试用例覆盖率、测试有效性、缺陷修复率
UAT验收阶段：
测试类型：版本功能验证、业务验收
门禁：版本验收通过率、业务验收通过率
1.2.4、典型测试类型：
1、冒烟测试：常见误区认为只针对新功能，不对旧功能，保证提测版本代码可测性
软件的冒烟测试，就是验证软件的最基本行为是否正常，例如：“程序是否运行？”，“用户界面是否打开？”或“单击事件是否有效？”等。只有冒烟测试通过，才有进一步开展验证软件功能测试的必要，否则就需要先修复重新出新版本才可以。
我们发现有的团队只对新开发功能进行冒烟测试，其实这是不太正确的，或者说这个测试就不叫冒烟测试。冒烟测试应该是对整个系统级别的基本行为进行验证，不区分什么新旧功能
2、集成测试：
主要是针对单元测试和接口测试等而言的。
集成测试是从头到尾验证整个软件及其与外部接口的集成，其目的是测试整个软件的依赖性、数据完整性以及与其他系统、接口和数据库等的通信，以模拟完整的业务流程。因此，集成测试是最能体现用户真实业务行为的测试，有着非常重要的价值。
但是，由于集成测试涉及到系统各个相关组件和外部依赖，其稳定性和执行成本相对都是比较高的。于是有了覆盖范围较小的接口测试和单元测试，这些测试一般都是通过隔离依赖来实现的测试，此处不再细述
3、回归测试 常见误区只针对当前迭代版本新功能回归测试
回归测试的目的是验证新开发功能或者修复bug的时候，是否对已有功能有破坏。因此，回归测试的对象主要是针对已有功能，对于新功能的测试不叫回归。
回归测试的策略通常有四类：
● 全面回归：这种就是不分青红皂白，对所有已有功能进行全面的测试，这种策略成本较高，但是覆盖率较全，一般对质量要求特别高的金融类产品采用全面回归的方式较多。
● 选择性回归：这种一般是测试会跟开发进行沟通，了解当前代码编写可能影响到的范围，选择对这些受影响的功能模块进行回归。这种形式可能漏掉没有意识到但是关联到的功能，有一定的风险，但是较为经济的一种做法。
● 指标法回归：这种一般是团队对回归测试的覆盖率有要求，比如要覆盖50%的已有功能测试用例，执行回归测试不能低于这个覆盖率。这种光看指标数字的做法是最不推荐的，虽然覆盖率达标了，但是有可能该测的没有测到。
● 精准回归：精准回归就是当下非常热门、这是采用技术的手段将代码改变所影响到的范围跟测试用例关联起来，精准地执行受影响的用例。这种质量最为有保证，但是精准测试实现成本是非常高的
总结：回归测试可以手动进行，也可以是自动化测试，但通常回归测试的量都会比较大，以自动化的方式进行会比较高效。
4、探索性测试
探索式测试的核心旨在将测试学习、测试设计、测试执行和测试结果分析作为一个循环快速地迭代，以不断收集反馈、调整测试、优化价值。
探索式测试特别需要测试人员的主观能动性，需要有较为宽松的鼓励测试创新的环境才能较好地开展，如果对于测试指标要求过高，测试人员主观能动性难以发挥的情况下，探索式测试的效果也很有限。
探索式测试是一种相对自由的测试风格，不建议被各种测试模型套住，也不建议严格规定探索式测试的执行方式，这些都会影响到探索式测试的发挥
1.2.5、自动化测试分层策略
自动化分层策略就是针对这些不同粒度的测试类型进行分层，根据成本、稳定性等因素建议自动化测试需要考虑不同层的覆盖比例
测试金字塔，你的测试组合应该由以下三层组成（自下往上分别是）：
● 单元测试
● 服务测试
● 用户界面测试
1.2.6、测试用例设计
好的测试用例需要具备下列特点：
● 整体完备性，且不过度设计：有效测试用例组成的集合，能够完全覆盖测试需求；同时也不会有用例超出测试需求。
● 等价类划分的准确性：每个等价类都能保证只要其中一个输入测试通过，其他输入也一定测试通过。
● 等价类集合的完备性：所有可能的边界值和边界条件都已经正确识别。
根据通常的用例设计方法方法论设计
● 1.3、职责三-实现和执行测试
实现和执行测试就是以测试策略为指导、根据设计的测试来落地执行的相应的测试活动。这部分内容相对比较简单，从手动测试和自动化测试两个维度来简单介绍。
1、手工测试：
测试人员严格执行，测试计划实际落地
2、自动化：
工具选型、测试实现（数据脚本分离参数化）、集成代码jenkins
● 1.4、职责四-缺陷管理与分析
******重点如何借助缺陷分析内建质量*******：
缺陷管理很重要的一个部分是搞清楚缺陷的生命周期是什么样的。往往大家觉得缺陷从发现到修复并验证通过了就可以了，其实并不止这些。我认为缺陷的生命周期应该包括如下阶段：
1. 测试缺陷修复：对开发修复的缺陷进行验证，确保缺陷本身已经修复，并且需要对相关功能进行适当的回归测试。
2. 添加相应的自动化测试：对于已经发现的缺陷，最好添加自动化测试或者补充漏测用例库，下次如果再发生类似的问题可以通过自动化测试及时地发现。自动化测试可以是单元测试、接口测试或者UI测试，根据实际情况结合自动化测试分层策略来定。这一步可能跟上一步顺序倒过来。
3. 统计和分析缺陷：对缺陷的数量和严重程度进行统计分析其同比/环比趋势，用鱼骨图和5 Why法等分析缺陷发生的根因，定位缺陷引入的阶段，并且分析之前缺陷预防举措的执行效果等。
4. 制定改进举措预防缺陷：根据第8步分析的结果，制定相应的可以落地的改进举措，以预防缺陷的发生。
5. 定期回顾和检查改进情况：结合缺陷的统计分析，定期回顾缺陷管理的系列活动，并检查改进举措的执行情况，以持续优化缺陷管理流程，更好的预防缺陷。
1.4.1、缺陷管理
缺陷是一项非常有价值的资产，软件缺陷的管理分为两个部分：缺陷信息收集和缺陷分析。
实现管理前提重点:1、缺陷有效信息收集完整 2、缺陷分析
缺陷信息收集应该做到尽量简单，且包含必要的信息。
● 标题：言简意赅，总结性的语句描述是什么缺陷
● 详情：包括重现步骤、实际行为、期望结果等，根据具体情况确定其详细程度，必要时可以添加截图、日志信息等附加说明。
● 重要属性：优先级、严重性、所属功能模块/产品、平台（OS、Web浏览器、移动设备的不同型号等）、环境、根因等，这些属性对应的值需要根据不同项目的情况自己定义，其中“根因”是相当关键的一个属性，后面有示例可以参考该属性对应的值有哪些。
● 其他：每个项目对应的还会有其他信息需要记录的，自行定义就好。
缺陷分析：
1、缺陷因素鱼骨分析法
2、功能模块与环境分析
3、缺陷根因和比例
4、缺陷迭代和收敛趋势
缺陷分析时机：
推荐每个迭代周期分析一次，并且跟以往各个迭代进行对比，进行趋势对比。当然，有时候可能一个迭代发现的缺陷非常少，分析的周期可以适当延长，两个迭代合并分析一次也是可以的。还可能某个迭代突发紧急缺陷，那就可能需要立马分析。
通常情况：每个迭代做一次
特殊情况：紧急情况需要立马分析
总结：
缺陷记录是为更好的跟踪和分析缺陷做准备的，而缺陷分析是软件质量保证的重要环节，对于软件过程的改进，软件产品的发布来说具有十分重要的参考价值，建议各项目定期都要做做缺陷分析。
1.4.2、缺陷分析
1. 如何进行根因分析
1.1、引起缺陷的原因主要有下面这几个方面：
● 需求缺失或者需求不清晰
● 设计问题
● 编码错误
● 测试不够
● 环境相关（硬件、软件、配置等）
1.2、借助五个why定位
案例：
2、如何定位缺陷产生的阶段
找出根本原因之后，同样利用5 Why分析法，基于软件开发生命周期由外往内的问为什么，从而定位引发问题的薄弱环节，找出是哪个环节做的不好导致的问题。拿生产环境的缺陷为例，下面是可能（不限于）的问题列表：
1. 为什么在预生产环境没有发现这个问题？
2. 为什么测试环境没有测出这个问题？
3. 为什么Desk Check没有发现这个问题？
4. 为什么Code review没有发现这个问题？
5. 为什么单元测试没有发现到这个问题？
6. 为什么在需求评审的时候没有发现这个问题？
3、如何建立改进措施
找出了根因，并且定位了引发缺陷的最可能阶段，接下来就是通过“What”问题来确定对应的action，预防类似缺陷再次发生，从而帮助质量内建。
不同的根因对应的可能actions有：
4、质量内建总结：
质量内建的关键是缺陷预防
除了正向的考虑加强每个环节的质量保障工作可以预防缺陷，通过分析缺陷的根因、定位问题出现的薄弱环节、制定可行的对应改进措施，可以帮助我们更有的放矢的做好缺陷预防工作，更有效的做好质量内建。
● 职责五-质量反馈与风险识别
测试对产品质量状态需要有清晰的认识，能够及时识别质量风险，并反馈给整个团队。
前面讲到缺陷的统计分析，与质量相关的除了有缺陷信息以外，可能还有很多其他的数据，将这些数据进行收集和统计，并且可视化展示给团队，将会帮助团队不同角色更好地做到为质量负责。在对质量数据的统计和分析过程中可以识别到相关的质量风险，将风险也一并反馈给团队很有必要。
质量状态信息可能包括测试覆盖率、缺陷相关数据、代码冻结期长度、测试等待时间等内容，具体需要收集哪些信息还得根据项目实际的质量需求来定制化。
质量反馈建议周期性的进行，由测试人员主导定义需要收集的数据有哪些，开发人员协同测试人员一起收集相关数据，后面的分析过程可能也需要开发人员的参与。
跳出测试：
01 从测试到质量
1. 为什么要从测试转变到质量
在五个测试基本职责，那是测试人员开展测试工作务必了解的方方面面，是做好测试工作的基础。
但是，要做好软件产品的质量保障工作，光从做好测试的角度考虑是远远不够的，原因主要有两个方面：
● 软件质量不能通过测试来提高。著名质量管理专家戴明提到：“质量没法检测出来，软件产品开发出来后质量就已经在那了。”
● 软件测试可以验证软件质量是否满足需求，但是随着软件生态的复杂性和不确定性增加，没有办法预知软件行为，也就没法通过测试来验证软件质量的方方面面。
因此，测试是基本功，但只关注测试是不够的。需要跳出测试，将视野调整到软件开发全生命周期质量的角度，关注质量的各个维度，才能更好地建立体系化思维，才能更好地做好软件产品的质量保障工作。
在阅读后面内容之前，我希望读者朋友们先花10秒钟思考以下问题：
02. 软件质量的定义
● 软件功能质量：基于功能需求规范看软件是否提供了相应的功能，这是用户使用软件的角度，是软件外部的质量。
● 软件结构质量：对支持功能需求交付的非功能需求的满足情况，比如健壮性、可维护性等，这是从软件内部结构来看，是软件内部的质量。
从内外部：
外部质量：用户感知、使用质量
内部质量：内部形态、开发质量、开发人员
容易忽视的质量影响因素：
● 理解了质量的定义，在日常软件开发工作中有哪些因素是会影响到软件质量的呢？其实，影响的因素特别的多，可能包括但不限于以下这些：
● 需求分析过程仓促，或者参与人员角色比较单一，导致业务上下文了解不够，关键场景缺乏考虑等；
● 忙于交付更多的特性，忽略了对代码质量的关注，该重构的没有重构，在原本不太健康的代码基础上继续增加更多的代码，导致混乱，筑起高高的技术债；
● 没有足够的测试覆盖，导致新增代码容易破坏已有功能；
● 开发人员提交代码后，就投入新代码的开发，对所提交代码缺乏关注，持续集成流水线上测试挂了不能及时修复，可能影响后面的测试进度；
● 大面积的重构发生在发布前夕，无法全面回归，带来很大的风险；
● 项目初期只考虑少量用户的场景，随着业务的发展，系统功能难以扩展，导致严重性能瓶颈；
● 技术选型失误，开发困难，没有及时改进，一错再错，最后问题严重到无法弥补；
● 第三方组件评估不够充分，导致线上环境无法承载等；
● 开发缺少对异常情况的处理，测试过程缺乏探索，只覆盖到主干路径，边角用例可能引发问题；
● 开发或者测试都只考虑当前功能模块，缺乏更广范围的考虑；
● 缺乏跨功能需求的关注，导致严重的安全或者性能问题；
● 对线上环境了解不够，而且没有足够日志信息记录，线上问题难以定位，导致宕机时间过长；
03质量内建：
1. 质量内建的核心
在介绍具体的质量内建实践之前，还是需要从抽象层面来理解质量内建的核心，其内容可以分为四个方面：
● 测试左移
● 快速反馈
● 测试右移
● 全员参与
1.1 测试左移：强调角色活动左移
传统软件开发会分成分析、设计、开发、测试、发布等几个相对独立的阶段，而测试是其中发生在开发完成之后的一个阶段。
测试左移是针对传统这种独立测试阶段来说的，不再强调独立的测试阶段，而是要将测试活动左移到软件开发生命周期的最早阶段（最左边）——需求阶段，从需求阶段开始做好缺陷预防的工作。
要特别提醒注意的是，测试左移不是测试人员左移，而是强调的测试活动左移：
左移到传统独立测试阶段左侧就叫左移，不一定是左移到需求阶段。当然，根据前面对质量内建的阐述，理想情况下肯定是越左边越好。如果做不到彻底左移，能移一步也是进步。
测试人员的确需要左移参与相应的活动。但是，如果测试人员参与需求阶段，却没有起到澄清需求、验证需求有效性的作用，那就不是有效的测试左移，关键要看成效。
不仅测试人员要左移，开发等其他角色也需要左移。因为需求有效性的验证，需要不同角色的经验，需要来自不同视角的输入；不同角色都有责任参与到每个环节的测试活动中来。
只要能做到从需求阶段开始就有相应的测试活动，不一定都是测试人员参与。这里强调的是测试活动要有，哪个角色来做不是最关键的，角色其实就是戴了一定帽子而已。我们知道，有的团队是没有测试人员的，但不代表这些团队没有测试活动。
1.2 快速反馈：需要快速检验自动化支撑
快速反馈，也就是频繁持续地反馈，可以理解为一个持续测试的过程。
通常快速反馈需要有自动化的支撑，比如自动化测试、流水线上自动代码扫描等；也可以是一些人工参与的实践环节，比如手动测试、各类评审和验收等。通过这样的一些实践活动尽快地获取相应工作（可能是需求分析、开发等）的反馈，根据反馈结果进行及时的修复、调整、或者优化。
为了保障快速反馈/持续测试实践活动的有效开展，通常需要增加质量门禁，并确保质量门禁的严格执行。
1.3 测试右移 ：在生产环境测试、监控预警、用户反馈收集
. 日志分析和优化既然错误日志那么多，首当其冲就是从这些错误日志下手。项目使用的日志分析工具是Splunk
测试右移是跟测试左移对应的，就是将测试活动从独立测试阶段右移到生产环境。
但因为生产环境的特殊性，测试右移又不是测试活动的简单右移，而是通过一些实践活动获取生产环境下用户行为、日志等质量相关信息，利用这些信息来给前期的需求、开发和测试工作提供反馈，促进相应工作的优化改进，以更好的做好质量内建。
测试右移本身不能直接内建质量，但是可以帮助更好地质量内建，所以我认为测试右移也是质量内建不可或缺的核心内容之一。
1.4 全员参与
测试左移、快速反馈和测试右移都不是某个单一角色/人员可以做到的，需要不同角色的不同技能和不同视角的输入，质量人人有责，需要全员参与并且能承担起质量职责才行。
全员参与不仅是很多实践活动需要大家一起参与，还有很重要的一点是团队内部需要有足够的沟通和信息共享。只有信息足够透明，每个人都清楚质量目标、质量状态和风险，才能真正发挥主人翁精神积极地参与，才能发挥团队每个人最大的价值。一定要警惕团队“蘑菇种植”。
挥团队每个人最大的价值。一定要提防蘑菇种植
蘑菇种植：
“蘑菇种植法”：在黑暗的环境下，不断地施肥，然后看看出现了什么。他强调信息需要在团队内流动起来，以提高团队士气，而蘑菇法是阻止这样做的反例。
案例1：未知的高优先级
“张哥，咱们的技术改进这周可以实施了吧？”
“啊？老王给了我优先级更高的事情在做，你们那个先不做了，没人跟你说吗？”
“什么？为什么优先级变动没有人提前告诉我？！”小李不能理解，非常沮丧。
某资深员工小李，正在推动一个技术改进。这个技术改进从开始提出，就有不同的反对声音，他一个个解释澄清，获得了大家的认可，PM老王也是点头同意了的。小李组织几个同事把该准备的内容都按部就班的准备起来了，等到最后时刻去找Ops同事张哥实施的时候，才知道自己一直在推动的事情被默默的停掉了。
此事让小李感觉非常不爽，从此他对项目上的事情不再那么热情。
有更高优先级这件事情是可以理解的，项目团队的优先级列表一定是不断变化的，而项目的优先级变动有必要分享给团队所有成员，万万不可采用“蘑菇种植法”对待。
只有团队成员都能清晰地知道项目的目标和优先级，大家才会有可能积极的参与。不然，渐渐地，团队成员的积极性会被磨灭，最后就是大家对什么事情都不感兴趣的结局。
案例2：神秘的组织
“XX community每周都catchup，好神秘啊，好奇他们都在做什么...”
“最近好像又有不同的组织冒出来，都不知道在干嘛...”
某团队规模较大，为了更好的沟通和能力提升，按角色或者兴趣爱好形成了各种社区，比如QA社区、BA社区、前端社区、架构小组等。这是很好的实践，对大团队来说非常有必要。
但是，这里似乎听到了负面的声音，有的社区/组织可能过于封闭，成为了神秘的“蘑菇种植基地”。
这些组织的本意是更好的横向信息共享，帮助大家了解上下文。但是，如果社区把自己封闭起来，信息只在社区内流动，成为了孤立的组织，反而引起没有加入或者不知详情的同事的好奇或猜疑，不利于信息的大范围流通和共享，同时也是不利于社区成员真正的能力提升的。
作为社区成员，需要以更开放的心态去跟团队其他成员沟通，更开放的把社区的内容共享出来，跟大家一起探讨、一起进步。
案例3：试用期员工突然离开
“小刘竟然假期前就决定要离开了，为啥我们都不知道？！”
“是啊！大家都还想着怎么帮他呢……”
“就是，这个事情为啥要瞒着我们team？太让人郁闷了！”
