本文首发于个人网站「BY林子」，欢迎移动阅读更多内容。
我以前写过一篇文章《神圣的QA》，是想从事的 QA 文章中提到了工作的毕业生 QA 五项基本职责：
了解和澄清业务需求
制定策略并设计测试
测试的实现和执行
缺陷管理与分析
质量反馈和风险识别
最近，一位朋友希望我能分享系统测试需要注意哪些方面，我想到了这五个基本职责。根据生产杯的需要，本文将从测试实践和方法集的角度分析测试需要做什么和如何做。
业务需求是软件开发的源泉，正确理解需求的正确性不言而喻，理解和澄清需求也是测试工作的重要组成部分。
如何理解和澄清需求？我认为测试人员可以从以下三个维度来理解和澄清业务需求：
关于这些维度的维度的详细内容《敏捷测试如何优化业务价值》中有介绍。
除了正确理解业务需求外，还需要注意需求描述的质量，其中需求的可测试性是最重要的方面：
若需求不可测，则无法验收，无法知道项目是否成功完成；
只有通过通过测试编写，以确保需求能够正确实现和验证。
要求的可测试性主要体现在以下三个维度：
完备性
需求的完整性主要是指流程路径需要综合考虑，逻辑链路需要完整，包括正路径和异常场景。
例如：正确的用户名密码可以登录，不正确的用户名和密码登录会发生什么，两者都需要明确定义。
客观性
需求的描述不应该用一些主观的词来解释，而应该用客观的数据和例子来解释。例如，以下主观描述是一个非常糟糕的需求示例：
该系统应易于有经验的工程师使用，并应尽量减少用户的错误。
推荐采用“实例化需求 编写需求文档，通过实例表达业务规则，不仅容易理解团队中不同的角色，而且不容易产生歧义。
独立性
独立性主要是针对单个业务功能点（敏捷开发中的用户故事），要尽量的独立，跟其他功能边界清晰，减少因为依赖导致的功能点不可测。
例如，在同一功能点中可以验证输入和输出，A 功能点的输入不能通过 B 功能点的输出来验证。
敏捷开发中的用户故事遵循INVEST原则上，可测性和独立性是分开描述的，我认为独立性也会影响可测性，独立性是可测性的一个因素。
制定策略和设计测试是五项职责中最关键的一项，涵盖了更多的内容。它似乎是策略和测试设计的两部分，但它实际上包含了测试需要考虑的各个方面。以下是我认为更有价值的内容。
策略是方向。没有测试策略的指导，我们就不能做好软件测试。测试策略通常对经验不足的测试人员具有挑战性。然而，我曾经提出过一页纸测试策略可以帮助测试人员思考和制定自己的项目适应性。一页纸测试策略如下：
指导原则：团队对质量负责
测试什么：测试内容
如何测试：左移、右移和精益测试
我们经常发现，一些团队对测试过程有明确的定义，但对每个环节的效果没有严格的要求。许多质量工作做得不到位，导致测试人员在后期测试阶段压力大或最终交付质量低。
前面一页纸测试策略已经包含了测试过程的一部分，这里再次提到，主要是为了强调质量访问控制的重要性。每个项目或团队的测试过程可能不同，但无论测试过程包些链接，每个链接的输出结果都必须明确定义，即每个链接的质量访问控制，如下图所示：
注:这张图只是一个例子，实际情况需要根据自己的团队情况进行适应。
上述流程图示例中列出了多种不同的测试类型，实际测试类型远不止这些。由于篇幅有限，这部分内容不是本文的重点，本文只介绍了四种典型的测试类型，与测试人员密切相关。这四种测试的分类维度不同，这里不详细。对于不清楚但感兴趣的学生，请在线搜索。
冒烟测试
吸烟测试来自电路板的测试，即通电后看电路板是否吸烟。如果吸烟表明电路板不能正常工作，则无需验证其他功能。
与软件相对应的吸烟测试是验证软件最基本的行为是否正常，如程序是否运行、用户界面是否打开？或者单击事件有效吗？等等。只有通过吸烟测试，才有必要进一步验证软件功能测试，否则需要修复并重新发布新版本。
我们发现有些团队只对新开发的功能进行吸烟测试，这是不正确的，或者这个测试不被称为吸烟测试。吸烟测试应验证整个系统级别的基本行为，而不区分新旧功能。
回归测试
回归测试的目的是验证新的开发功能或修复 bug 是否损坏了现有的功能。因此，回归测试的对象主要针对现有功能，新功能的测试不称为回归。
回归测试通常有四种策略：
全面回归：这是对所有现有功能的全面测试，不分青红皂白。该策略成本高，但覆盖率全。一般来说，对于质量要求特别高的金融产品，有更多的方法可以全面回归。
选择性回归：这种一般是测试会跟开发进行沟通，了解当前代码编写可能影响到的范围，选择对这些受影响的功能模块进行回归。这种形式可能漏掉没有意识到但是关联到的功能，有一定的风险，但是较为经济的一种做法。
指标法回归：这种一般是团队对回归测试的覆盖率有要求，比如要覆盖 50%的已有功能测试用例，执行回归测试不能低于这个覆盖率。这种光看指标数字的做法是最不推荐的，虽然覆盖率达标了，但是有可能该测的没有测到。
精准回归：精准回归就是当下非常热门的精准测试，这是采用技术的手段将代码改变所影响到的范围跟测试用例关联起来，精准地执行受影响的用例。这种质量最为有保证，但是精准测试实现成本是非常高的。
回归测试可以手动进行，也可以是自动化测试，但通常回归测试的量都会比较大，以自动化的方式进行会比较高效。
端到端测试
端到端测试基于测试覆盖的粒度分类，是针对单元测试和接口测试等而言的。
端到端测试是从头到尾验证整个软件及其与外部接口的集成，其目的是测试整个软件的依赖性、数据完整性以及与其他系统、接口和数据库等的通信，以模拟完整的业务流程。因此，端到端测试是最能体现用户真实业务行为的测试，有着非常重要的价值。
但是，由于端到端测试涉及到系统各个相关组件和外部依赖，其稳定性和执行成本相对都是比较高的。于是有了覆盖范围较小的接口测试和单元测试，这些测试一般都是通过隔离依赖来实现的测试，此处不再细述。
探索式测试
探索式测试由 Cem Kanner 博士于 1983 年提出，是针对脚本化测试而言的。
Cem Kanner 对探索式测试的定义如下：
探索式测试是一种软件测试风格，它强调独立测试人员的个人自由和职责，为了持续优化其工作的价值，将测试相关学习、测试设计、测试执行和测试结果分析作为相互支持的活动，在整个项目过程中并行地执行。
探索式测试的核心旨在将测试学习、测试设计、测试执行和测试结果分析作为一个循环快速地迭代，以不断收集反馈、调整测试、优化价值。
探索式测试特别需要测试人员的主观能动性，需要有较为宽松的鼓励测试创新的环境才能较好地开展，如果对于测试指标要求过高，测试人员主观能动性难以发挥的情况下，探索式测试的效果也很有限。
探索式测试是一种相对自由的测试风格，不建议被各种测试模型套住，也不建议严格规定探索式测试的执行方式，这些都会影响到探索式测试的发挥。
更多的关于探索式测试的内容欢迎参考 Thoughtworks 同事刘冉的文章《探索式测试落地实践》和史湘阳的文章《敏捷项目中的探索性测试》。
前面介绍端到端测试的时候提到了不同覆盖范围的测试，可能有单元测试和接口测试等。自动化分层策略就是针对这些不同粒度的测试类型进行分层，根据成本、稳定性等因素建议自动化测试需要考虑不同层的覆盖比例。
根据下图谷歌测试定律，我们能够很清晰的看到不同层的测试发现问题之后的修复成本的差异性，单元测试比端到端测试发现的问题修复成本要低得多，因此，通常建议测试分层应该倾向于测试金字塔的模式，也就是下图右侧的样子。Thoughtworks 同事 Ham Vocke 的文章《测试金字塔实战》对此有很详细的介绍。
需要注意的是测试金字塔不是银弹，测试策略不是一成不变的，需要根据实际情况阶段性调整、演进，满足当下产品/项目质量目标才是关键。
更多的关于自动化测试分层的内容，还可以参考下列文章：
设计测试用例是每一名测试人员必备的基本功，测试用例的好坏直接影响到测试的有效性，测试用例的重要性不言而喻，但是要设计好的测试用例也不是一件很简单的事情。这里说的测试用例不区分手动用例和自动化用例。
首先，我们有必要了解什么样的测试用例算是好的用例。
好的测试用例应该是正好能够覆盖所测软件系统、能够测出所有问题的。因此，好的测试用例需要具备下列特点：
整体完备性，且不过度设计：有效测试用例组成的集合，能够完全覆盖测试需求；同时也不会有用例超出测试需求。
等价类划分的准确性：每个等价类都能保证只要其中一个输入测试通过，其他输入也一定测试通过。
等价类集合的完备性：所有可能的边界值和边界条件都已经正确识别。
当然，因为软件系统的复杂性，不是所有测试用例都能做到正好 100%覆盖，只能是做到尽量的完备。
测试用例设计方法
力求完备的测试用例，就需要了解相应的测试用例设计方法。测试用例应该是结合业务需求和系统特点，综合起来考虑设计。通常建议的用例设计方法有如下几种：
数据流法：基于业务流程中的数据流来切分测试场景的方法。考虑业务流程中的数据流，在数据存储或者发生变化的点进行流程的切断，形成多个用例场景。这个在我的文章《说起 BDD，你会想到什么》里有介绍。
等价类划分法：把程序所有可能的输入数据划分为若干部分，然后从每个部分中选取少数有代表性的数据作为测试用例。等价类分有效等价类和无效等价类，根据等价类划分方法设计测试用例要注意无冗余和完备性。
边界值法：边界值分析方法是对等价类划分的补充，通常取正好等于、刚刚大于或刚刚小于边界的值作为测试数据，包括对输入输出的边界值进行测试和来自等价类边界的用例。
探索式测试模型法：推荐史亮和高翔两位老师的著作《探索式测试实践之路》，书中将探索式测试按测试对象不同分为系统交互测试、交互特性测试和单个特性测试三个层次，每个层次都分别介绍了不同的探索模型。虽然我不认为探索式测试需要严格按照这些模型来做，但是这些模型是可以帮助测试人员在探索过程中进行思考的，同时也是设计测试用例非常有价值的参考。
关于用例设计，还可以参考下列文章：
实现和执行测试就是以测试策略为指导、根据设计的测试来落地执行的相应的测试活动。这部分内容相对比较简单，从手动测试和自动化测试两个维度来简单介绍。
手动测试，顾名思义就是手工执行的测试，根据是否有提前设计好的测试用例（脚本）可以分为脚本化测试和探索式测试。
脚本化测试的执行，在有成熟测试用例的前提下，相对比较简单。但是，有些测试可能准备工作较为复杂，比如要通过长链路来准备测试数据、或者让系统到达测试触发的状态等，还有可能要考虑不同的环境对应的配置调整，同时也会包括环境的准备和管理。这些都是测试人员要做好手工测试可能需要涉及的内容。
关于探索式测试，在《探索式测试实践之路》中有详细介绍基于测程的测试管理（Session Based Test Management，SBTM）方法来执行探索式测试：将测试章程分解成一系列测程，测试人员在测程中完成一个特定测试章程的设计、执行和记录。
同样，这个方法对探索式测试有一定的指导意义，但是不建议严格规定必须按照这个模式来执行，不然的话就破坏了探索式测试的本质，达不到相应的效果。
前面部分介绍了自动化测试的分层策略，把自动化测试的实现和执行放到这里介绍。
工具选型
自动化测试的实现依赖于自动化测试工具，对于工具的选型非常关键。通常在工具选型时需要考虑如下几个因素：
满足需求：不同的项目有不同的需求，根据需求来选择，不求最好，只求适合就好。
易于使用：常见的易用性，以及跟写测试的人技能匹配的易用性，都是需要考虑的。同时需要易于上手，如果一款工具对于新人不友好、很难上手的话，就很难动员大家都来积极地使用。
支持的语言：较好的做法是使用与项目开发相同的语言编写自动化脚本，让开发人员能够灵活地添加测试。
兼容性：包括浏览器、平台和操作系统之间的兼容。
报告机制：自动化测试的结果报告至关重要，优先选择能够提高完备的报告机制的工具。
测试脚本易于维护：测试代码跟产品代码一样重要，对测试的维护不可忽视，需要一款易于维护的工具。
工具的稳定性：不稳定性会导致测试有效性降低，首先要保证工具本身的稳定性，不然得不偿失。
代码执行速度：测试代码的执行速度直接影响到测试效率，比如 Selenium 和 Cypress 编写的测试代码执行速度就有很大差别。
测试实现
关于自动化测试的文章随处可见，这里强调一点，不要把测试数据写死在测试脚本里，要将数据独立出来，做到数据驱动，以提高测试代码的可复用性。
自动化测试的执行
是不是觉得自动化测试实现以后，执行就是简单的跑起来就可以呢？也不是。测试的执行也需要一定的策略，例如：对不同的测试按需设置不同的执行频率，将自动化测试跟流水线集成做到持续地测试，以持续反馈，最大化发挥自动化测试的价值。
关于自动化测试，推荐阅读以下文章：
缺陷对软件质量、软件测试来讲是非常宝贵的，好的缺陷管理和分析将会带来很大的价值，但是往往容易被忽略。
缺陷管理很重要的一个部分是搞清楚缺陷的生命周期是什么样的。往往大家觉得缺陷从发现到修复并验证通过了就可以了，其实并不止这些。我认为缺陷的生命周期应该包括如下阶段：
发现缺陷：这个比较简单，就是发现跟期望行为不一致的系统行为，或者性能、安全等非功能性问题。缺陷可能是在测试过程中发现，也可能由用户报告，还可以是例行日志分析或日志监控报警等等通过日志来发现。
定位和信息收集：发现缺陷之后，需要收集相应的缺陷信息并做初步定位。其中，缺陷相关信息要尽可能收集全，包括完整的重现步骤、影响范围、用户、平台、数据、屏幕截图、日志信息等。这一步有的时候可能需要开发或者运维人员帮忙。
记录缺陷：就是将收集到的日志信息记录在日志管理系统，关联相应的功能模块，并定义严重性。
Triage/排优先级：对于记录的缺陷也不是所有的都要修复，所以要先对缺陷进行分类整理，确定缺陷是否有效、对有效缺陷的优先级排序，并且确定哪些是要修复以及在什么时间修复。这一步可能需要跟业务和开发人员一起来完成。
修复缺陷：这一步就交给开发人员来完成，对缺陷进行修复。
测试缺陷修复：对开发修复的缺陷进行验证，确保缺陷本身已经修复，并且需要对相关功能进行适当的回归测试。
添加相应的自动化测试：对于已经发现的缺陷，最好添加自动化测试，下次如果再发生类似的问题可以通过自动化测试及时地发现。自动化测试可以是单元测试、接口测试或者 UI 测试，根据实际情况结合自动化测试分层策略来定。这一步可能跟上一步顺序倒过来。
统计和分析缺陷：对缺陷的数量和严重程度进行统计分析其同比/环比趋势，用鱼骨图和 5 Why 法等分析缺陷发生的根因，定位缺陷引入的阶段，并且分析之前缺陷预防举措的执行效果等。
制定改进举措预防缺陷：根据第 8 步分析的结果，制定相应的可以落地的改进举措，以预防缺陷的发生。
定期回顾和检查改进情况：结合缺陷的统计分析，定期回顾缺陷管理的系列活动，并检查改进举措的执行情况，以持续优化缺陷管理流程，更好的预防缺陷。
关于缺陷的管理和分析，我之前有写过相应的文章，朋友们欢迎移步阅读：
测试对产品质量状态需要有清晰的认识，能够及时识别质量风险，并反馈给整个团队。
前面讲到缺陷的统计分析，与质量相关的除了有缺陷信息以外，可能还有很多其他的数据，将这些数据进行收集和统计，并且可视化展示给团队，将会帮助团队不同角色更好地做到为质量负责。在对质量数据的统计和分析过程中可以识别到相关的质量风险，将风险也一并反馈给团队很有必要。
质量状态信息可能包括测试覆盖率、缺陷相关数据、代码冻结期长度、测试等待时间等内容，具体需要收集哪些信息还得根据项目实际的质量需求来定制化。
质量反馈建议周期性的进行，由测试人员主导定义需要收集的数据有哪些，开发人员协同测试人员一起收集相关数据，后面的分析过程可能也需要开发人员的参与。
本文为构建测试的体系化思维的基础篇，主要是从测试的基本职责出发展开，介绍了相关的方法、工具和实践，适合初级测试人员；当然，对于中高级测试人员，也可以对照着看看是不是这些基本职责平常都做到了，在自身的测试体系里边是否涵盖了相关内容。
后续计划还会出高级篇，在新的文章出来之前，大家可以先关注我的自出版小书《不止测试》，书中介绍的其实是测试人员或者 QA 需要关注的超出测试基本职责之外的内容。
（扫码可免费领取电子书👆👆👆）
点击上面链接关注BY林子公众号👆👆👆