基于流程的测试质量体系

        随着时间的推移，产品不断的迭代，业务越来越成熟丰富，意味着业务流程、市场需求和客户期望变得更加复杂和多样化。因此对软件测试人员也相应带来更高的要求；测试人员也应该慢慢从业务测试工作中转变到业务质量保障中，向质量保障团队转型，承担更多的质量提升工作，更好的为业务提供支持。以前我们可能主要关注测试这一块的工作，把测试注意防的任务做好就足够了，但后面可能不仅要测试还要更广泛地关注整个软件开发生命周期的质量，包括过程改进、质量标准制定、风险管理等。测试人员不仅要关注缺陷的发生，还要关注需求产出、需求评审、设计评审、发布阶段、线上运行等易引发产品问题的各个过程阶段，通过提炼标准和流程来提高整体质量。基于不断提升的质量标准，提炼了基于流程的质量保障体系，以产品标准迭代流程为载体，主动分析各阶段过程中容易引发问题的地方，做质量防护建设。

        一.基于流程的质量保障体系：

                1.需求阶段的核心-需求评审：需求正确性、完整性、可测试
                        1.1理解和澄清业务需求：需求怎么理解，可以参考我前面的文章《测试策略设计四：基于需求的测试策略》，从用户、业务流程、业务影响等几个维度理解。为什么是澄清需求？要有一个意识，就是产品不一定比你更了解业务，产品肯定没有你了解系统；所以这个过程不仅是理解需求，还要反向澄清需求。
                        1.2需求描述质量：一是需求的完整性，包括背景、功能、影响点、验收标准、原型；流程路径需要考虑全面，要求逻辑链路完整，必须有正向路径，最好包括异常场景。二是需求的客观性，需求的描述不要用一些主观性的词语，你理解不了说明其他大多数人也理解不了，对于不易理解的地方吗，要求产品用客观的数据和示例来说明，易于团队不同角色的理解，而且不容易产生歧义。
                        1.3需求可测试性：所谓的可测性就是，在测试需要介入的不同环节，评估是否可以正常开展测试活动的前置条件；在需求阶段，指满足需求要求的正常前置条件有没有。以可测试的方式编写需求，才能确保需求能够正确实现并验证。

                2.需求开发阶段：跟进迭代计划、辅助提高转测质量

                        2.1制定测试策略：澄清了需求，还得知道怎么去验证软件产品是否满足了需求，这就需要制定测试策略，明确测什么以及怎么测，并根据策略设计测试。大概来说，根据需求确定测试范围后，覆盖这些测试范围都需要怎么做，比如不同类型的测试(功能和非功能)，如何设计测试用例，用什么工具实现功能、性能、自动化测试等；也可以是为了达成满足测试覆盖的目标我要怎么去熟悉、分析这些需求，比如哪些资源可以辅助你。

                        2.2制定测试计划：通过测试策略确定的测试活动后，基本可以评估出迭代的测试工作量，那么就可以合理规划测试计划；测试计划中，将测试范围拆解为一个个任务，并为每个任务确定工期、执行的先后次序和责任；谁，在哪个时间点，任务是什么、目标是什么。测试计划需要跟开发计划匹配，保证整体计划与项目目标匹配。

                        2.3测试用例设计：对于测试来说什么样的测试用例是合格的用例，一个合格的用例应该包括以下几个因素：使用了测试用例设计方法，描述清晰、精准、简单明了，符合内部规范，覆盖非功能需求，其他人拿到用例可以直接执行，满足这些因素既是一个合格的用例。要达到好的用例，还需要其他条件，例如使用分层的设计方法，从界面、数据、逻辑全面覆盖；覆盖了测试策略的范围并且引用了策略相关有效的方法；提炼了历史缺陷、线上缺陷、用户反馈、线上产品建议等相关的验证点等。还有就是要提取开发自测用例，一般提取优先级高的，数量不低于总量的20%。

                        2.4测试用例评审：执行测试用例评审这个活动比较容易，拉上相关人员，把用例读一遍，有问题就改一下；但是真正做到有效、高效还是不太好做的。测试用例数量较大，用例评审时，大部分人估计都在神游或者干其他事，评审会议时间也比较长，开发吸收的部分可能也只有很少量的场景。所以针对不同的项目情况，我们要思考怎么提升用例评审的效率。评审的内容不用全部覆盖，抽重点评审；会前准备好用例，结构思路要清晰，表达要准确，有问题的地方在评审前达成一致，重要内容进行标记，会上重点澄清。会中陈述流畅，最好跟原型相结合讲解更生动。基础功能、影响较小的场景可以只讲重点快速过；比较模糊或者不太确定的内容详细评，过程中与开发和产品互动，做好引导和提醒；评审问题要做好标记。会后根据评审内容更新用例；要回顾评审过程，思考优化策略。再好的反馈和想法没有落实也起不到作用。

                3.测试执行阶段：以验证业务需求为目标，尽早发现问题、尽快解决问题

                        3.1冒烟测试：冒烟测试的用例选取也是有策略的，可以对以往缺陷进行分析，如果迭代单功能缺陷多、生产场景缺陷多，冒烟用例可以选取了较多的单功能，少量的组合功能加主流程，测试完成后对单功能缺陷进行分析，提炼共性应对措施，引导开发减少迭代缺陷；当我们做sit测试时，轻单功能，重组合和场景，将更多的时间放在价值大的测试项上。

                        3.2测试执行：在实际执行阶段，除了按用例验证，还可以做一些其他的保障措施；一是测试前置，功能未好，接口先行，通过工具提前保证接口逻辑正确性，间接左移，保障提测质量。二是对于老特性，通过自动化的方式完成核心功能的回归验证，保障历史功能稳定、为手工测试减负。三是实现设计的验证，对于实现设计，通过fillder跟踪+数据库的检查，验证数据更新机制和更新结果，反向把关实现设计质量。

                        3.3缺陷管理：一个严谨的缺陷管理流程应该如下：1.发现缺陷--2.定位和信息收集--3.记录缺陷(包括影响点)--4.排优先级--5.开发修复缺陷、自测--6.测试验证缺陷--7.评估是否添加自动化--8.统计和分析缺陷(分类分析、根根因分析等)--9.制定改进措施预防缺陷--10.回顾检查改进情况。

                        3.4缺陷分析：测试活动还有重要的一环，就是缺陷度量，如果有充足的时间，可以通过“5why法”、’“鱼骨图法”对每个缺陷做根因分析。常规分析一般用以下五个维度，第一个是缺陷原因，这个主要针对非测试角色，以缺陷产生的第一关系人为主，提炼预防方法，赋能相关角色；其他四个针对测试，虽然敏捷迭代的质量是团队共建的，但作为测试要把自己当做质量的第一责任人，所以对测试要重点分析。第一个缺陷所属模块，目的是指导测试执行的优先级；二是缺陷业务归属目的是识别子功能的测试重点、提供缺陷预防的方法；三是同类型缺陷，目的是反哺我们的标准化设计；四是典型缺陷漏测原因，通过罗列典型缺陷测试一起反思测试工作、发散改进措施。

                        3.5测试评估：通过评估测试用例、测试场景是否全部覆盖、验收情况、遗留项和性能相关来判断手动测试的覆盖率。通过内部接口和外部接口的验证情况判断接口测试的覆盖率。如果有UI自动化，通过自动化场景和各项自动化覆盖的功能评估自动化的覆盖率。通过测试策略的覆盖、各个模块功能的逻辑覆盖情况判断功能的覆盖率。最终提供给我们是否具备上线条件的判断依据。

                4.UAT测试阶段：查漏补缺，保证测试覆盖率

                        4.1回归测试：回归测试不仅是回归当前迭代的新功能，还要验证历史功能的正常稳定。这时就要做好回归测试的策略，如果是全面回归，时间成本可能较高，要做好测试项的优先级，先执行比较重要的测试项，这样即使后面没有时间覆盖，剩余的测试项风险也是较低的。如果是选择性回归，需要做代码的影响点分析，知道当前代码可能影响到的功能范围，对这些可能有影响的内容进行回归，但可能会遗漏。比较常用的方法是根据迭代测试情况、缺陷分析结果制定新功能的回归策略；历史功能选取P0级别的用例，用自动化的方式进行覆盖。

                        4.2回归测试：建设核心业务的自动化测试能力，UAT阶段通过自动化验证原有功能的稳定性，包括接口自动化、UI自动化。新功能方面，结合迭代测试策略及完成情况做验证；那怎么去结合呢？迭代测试完成后，回顾测试执行情况，做迭代测试总结：总结未执行完成的、.总结测试覆盖不充分的、总结探索测试章程(一般根据缺陷)；

                5.生产环境：监控系统、最快最小影响解决问题

                        5.1：监控系统：其实也是尽早的去发现问题，在用户之前使用之前去解决问题。测试角度可以通过自动化的方式从业务数据监控(接口自动化)和业务流程监控(ui自动化)两方面监控线上业务功能。当然，一般正式环境对测试验证有各种限制，尽量按照客户制度要求，最大范围监控系统功能的稳定性。

                        5.2线上问题处理步骤(5步法)：
                                (1).确定和定义问题：对问题的定义应该清楚明白,以保证问题解决小组的每个成员都明白所发生的问题从而能够提供相关的信息。
                                (2).临时解决问题：立即采取有效的措施,对已经出现的问题临时制定和实施有效的围堵措施；防止造成客户进一步的不满。
                                (3)分析根因：采用有效的方法和工具找出导致问题发生的根本原因.真正的根本原因应该满足以下三个条件:A、问题能够随着所认定的根本原因的出现/不出现而被打开/关闭；B、所认定的根本原因不是由其他因素造成的；C、在问题发生时所认定的根本原因真的存在或有效。
                                (4).根因治理：采取永久措施以消除或最大程度地降低造成问题发生的根本原因；A、原因找到后,应用时采取纠正措施,改善流程；B、必须监控纠正措施的实施, 对产品和过程都要进行监控.；C、注意:第二步中所涉及的围堵措施应该停止,除非这些措施是第四步的一部分。  
                                (5).措施验证：验证纠正措施的有效性，A、在关闭问题之前,责任人应该确认纠正措施的有效性和得到客户的认可；B、这可以防止问题在将来再次发生。

        研发流程：

        质量规范：

                流程详解：产品输出用户故事、需求设计方案后进行第一次质量把关：需求评审；SM、测试必须参加，三方对需求及设计方案沟通讨论并达成一致。这个活动可能不止进行一次，如果有方案、实现上的问题，需要重现设计需求、再次做需求评审。需求评审通过后进行需求发布，结合团队多方视角补充完善需求设计方案并达成一致。团队成员分配/认领需求，开发开始做实现设计，测试做测试策略、计划设计。
                实现设计完成后，组织实现设计评审进行第二次质量把关，主要是开发、SM、架构师、测试参加。评审活动完成后组织计划会，基于实现设计方案，评估开发任务拆分和计划安排的合理性，并评估测试策略的范围和方法是否完整有效，测试计划与开发计划匹配，锁定迭代目标。接下来开发拉取分支进行需求编码，测试进行测试用例设计。需求开发完成后，开发要做两个活动，单元测试和用例自测进行第三次质量把关，达到要求的単测覆盖率和自测通过率后方可准出，保证开发提测质量，降低低级bug数，从而提高测试效率；同时测试要进行用例评审活动进行第四次质量把关。
                需求提测后，测试首先进行冒烟测试，如果冒烟通过率不达标，打回开发重新自测，上面的流程再执行一遍。冒烟用例通过，进行SIT测试。根据测试用例执行率、测试用例通过率、迭代Bug关闭率等评估准出进行第五次质量把关。SIT测试完成输出UAT测试策略并进行评审，同时产品要进行功能验收进行第六次质量把关，产品验收不通过，打回测试处继续测试。
                产品测试通过更新UAT继续回归测试，主要是测试进行回归，根据前面输出的UAT策略执行。这时可以结合自动化进行回归，测试bug关闭率、接口自动化通过率、UI自动化通过率达到要求方可准出通知用户验收，进行第七次质量把关。用户验收不通过，同样打回测试处重现回归测试。验收完成后，测试输出生产验证策略。
                线上环境发布完成后，测试在正式环境按策略（核心验证点）进行验证，保障系统运行正常。整体流程完成后，进行项目复盘、问题总结、改进优化。并且跟进遗留项(遗留的需求、优化、缺陷、技术债务等排期);且运维监控告警、日志信息及时反馈给产品处分析。

综上，基于流程的质量保障体系可以总结为在一个规范的流程机制运行下，在项目各流程各关键阶段设置一定的质量保障准则，逐层保障产品质量目标达成。