1.1 测试的分阶

关于测试基础，我阅读过很多书籍，大多都介绍的大同小异。本书结合大家的工作，从更贴近工作生活的角度，将软件测试的基础进行划分，以测试的分阶模式来阐述软件测试的理论知识。

1.1.1 入门阶

套用一句俗话“人人都是产品经理”，其实人人也都是测试工程师。

入门阶的测试人员不需要掌握过多的计算机基础技术，只需要像用户一样对系统做各种操作，如果出现不符合预期的结果，则它们被认为是系统存在的bug。这种测试被称为功能测试。

功能测试是通过测试来检测每个功能是否都能正常使用，只关注外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行的测试。这个阶层实现测试的方法是手工测试，也就是俗称的点点点测试。测试人员手动实现各种测试行为。

在这个阶层，测试人员除了需要理解功能测试的基本概念以外，还需要掌握两个要点。

1.及早介入测试的重要性

从项目成本的角度考虑修复bug的代价，如图1.1所示。

从图中可以看出随着项目一个阶段一个阶段的延伸，越到后期修复bug的代价越大，所以测试工程师在工作中需要尽早启动测试活动，从需求分析阶段进入就是最好的时间点。在理解需求的基础上，提取测试需求，为编写测试用例做准备。

2.测试活动贯穿整个软件生命周期

测试并不是软件生命中的一部分，而是贯穿整个周期，如图1.2所示。

在每一个阶段中，测试工程师需要和需求人员、开发人员、设计人员以及运维人员积极配合，参与需求设计调研及评审等会议，务求让测试渗透各方面，为后续测试执行做好充足的准备工作。

以下以故事的形式详细描述一下测试人员贯穿整个软件生命周期的行为。

有一个刚毕业的女孩叫作开心，她的志向是成为一名优秀的测试工程师。经过严格的面试考核制度，她被一家名叫哎呦喂的公司录取了。经过公司的新人培训等内容后，测试部的经理比目鱼先生准备给她委派第一个测试任务。作为没有工作经验的新人，她是否能够顺利地完成任务呢？

“只要勤奋努力一定可以！”开心心中暗暗下定了决心。

测试员开心接到她的上级领导比目鱼先生委派的任务，需要她跟进项目A的整体测试流程，为项目A的质量做好把控。

“测试流程是什么？”开心问比目鱼先生。比目鱼先生给开心画了一张测试项目的流程图，如图1.3所示。

测试项目流程图中包括测试人员需参与的每一个阶段及该阶段中参与的角色、开展的会议以及测试文档的输出。

“我本来以为测试项目只要根据需求验证系统功能就可以了。居然这么复杂！”开心对测试工作多了一份憧憬之情。

“可是这些测试文档我都不知道怎么写，怎么办？”比目鱼先生看着开心苦恼的样子，发了一份测试部门的文档模板给她。

开心带着满满的好奇心打开这些模板。噢，原来测试文档是长这个样子的。

以下提供测试文档模板的目录，根据目录可以了解文档的重要组成部分。

通常情况下，我们会把测试计划与测试方案合为一个文档。

测试计划方案文档如图1.4所示。

（1）文档说明：包含文档目的和读者对象

文档目的：描述编写本文档的目的、编写文档时用到的约定和文档的编排方式。

读者对象：读者包括部门经理/高级经理、项目经理、项目组、测试人员、配置管理员及其他相关人员。

（2）术语与参考：包含参考资料与术语解释

参考资料：填写本文档时使用的参考资料，如详细设计文档、开发文档等。

术语解释：解释测试人员使用的专业术语，如集成测试、冒烟测试是什么意思等。

（3）测试计划概述：包含测试系统概述、测试目标、测试方法、测试里程碑、测试系统发布及沟通策略

测试系统概述：介绍测试的系统体系结构、组件、集成测试相关的系统分解或者组装情况。

测试目标、方法及策略：说明测试目标、方法（手工、自动）、分阶段测试的策略等。

测试系统发布及沟通策略：根据项目的开发情况，说明测试工作和开发工作的协调关系、系统发布的策略等。例如，开发人员和测试人员如何协同工作，是否计划定期定时发布测试版本，发布的周期频度、发布时间等，何种情况下进行紧急发布。

（4）测试范围：描述系统测试的范围

从系统的功能模块及测试类型进行阐述。对需要测试的、不测试的内容分别进行说明。

（5）分阶段测试：包含测试阶段定义、准入与准出标准、测试内容

测试阶段定义如以下表格所示。

轮：填写计划测试循环策略，对于连续的测试发布，发现所有重要错误，并修复错误所需要执行多少次测试。

测试负责人：各阶段测试人员组成，通常可能有项目设计/开发工程师、测试小组leader、客户、最终用户等。

测试的准入与准出标准如以下表格所示。

测试内容如以下表格所示。

表中的测试物或对象说明填写被测系统模块的说明，并在用例/包中填写测试用例文档或测试包的获取路径。

（6）环境与工具：包括测试环境与测试工具

测试环境：根据不同测试类型的测试要求，可能要搭建不同的测试环境进行测试。如果有几种不同测试环境，应分别说明并指出其用途，如下表所示。

测试工具：说明采用的测试工具及其用途、来源和版本，如下表所示。

（7）测试开发：包括测试需求、测试系统设计、测试用例库、测试包及其说明、分析模型［可选］

测试需求：由需求说明书提取出来的测试需求，详情如图1.5所示。

测试系统设计包括测试用例库、测试包及其说明。

测试用例库：按不同的测试类型分类，列举本项目开发的所有测试用例，如下表所示。

测试包及其说明如下表所示。

（测试用例间用“；”分隔）

分析模型[可选]：根据业务流程画出测试设计的分析模型。

（8）［阶段测试详细计划］［可选］

根据项目情况，计划每个阶段中的每一轮的测试计划，包括测试的系统版本和测试物、策略、要求、人员、进度、采用的测试包或测试用例等。

（9）测试执行管理与评价

阐述项目测试的发布、测试记录与缺陷管理等遵循的规范、规则等内容，以及本项目测试的小结和总结的计划。

（10）［风险列表］［可选］

阐述项目测试可能遇到的风险，如进度风险、人员风险等内容。

（11）附录

附录可包含：附件A测试用例、附件B测试脚本等，链接到相应的测试用例和测试脚本文件。

测试需求分析说明书分为项目测试整体需求和项目测试细化需求。

项目测试整体需求如图1.5所示。

（1）测试需求概述

描述本文档的目的、项目达成的标准等。

（2）被测对象

简要描述测试项目的背景、重要模块、需达到的质量目标等。

（3）测试模型需求

测试模型需求包括：测试原理/策略需求和操作流程需求。

测试原理/策略需求：描述所需测试类型的内容及是否使用辅助工具等。

操作流程需求：描述不同类型测试间的先后顺序，以及测试流程的先后顺序。

（4）整体测试需求

整体测试需求包括：测试环境需求、被测对象需求、测试工具需求、测试代码需求、测试数据需求。

① 测试环境需求：描述所需测试类型的环境需求，如功能测试环境、性能测试环境需求。

② 被测对象需求包括应测试的特性和不被测试的特性。

（a）应测试的特性包括：

功能特性——需测试的模块及其功能。

性能特性——测试系统需要达到的性能指标。

配置特性——使用的操作系统、硬件限制以及数据库版本等。

（b）不被测试的特性

本项目不需要被测试的内容，如界面UI测试及稳定性测试等。

③ 测试工具需求

描述本项目需使用的测试工具。

④ 测试代码需求

描述本项目需使用的测试代码，如需建立自动化测试代码、性能测试代码以及需自构测试工具等。

⑤ 测试数据需求

描述本项目需使用的测试数据，如功能测试中的预置条件、性能测试中的数据准备等。

⑥ 测试人员需求

描述本项目需使用的测试人员资历，如需测试经理1名、高级测试人员2名、初级测试5名以及他们需具备的技能标准。

（5）测试设计需求

测试设计需求包括测试工具设计需求、测试代码设计需求以及测试用例设计需求。

① 测试工具设计需求

如有自建测试工具的需求，此处详细描述工具的特性功能设计方案。

② 测试代码设计需求

如有自建测试代码的需求，此处详细描述代码的特性功能设计方案。

③ 测试用例设计需求

此处描述测试用例的框架结构以及使用的设计方法，如下表所示。

比较常用的测试方法有以下几种。

等价类：指某个输入域的子集合。在该集合中，每个输入数据对于揭露软件中的错误都是等效的。对被合并的某等价类代表值的测试结果就等于对这一类其他值的测试结果。

边界值：指假定大多数的缺陷发生在各个输入条件的边界上。如果在边界的取值不会导致错误，那么其他的取值出错的可能性也很小。

正交表：指从大量的试验点中挑选出适量的、有代表性的点。依据正交表，合理地安排测试数据的一种科学试验方法。

状态迁移：指对被测系统抽象出若干个状态及状态间的切换条件和切换路径。从状态迁移路径覆盖的角度来设计测试用例，对该系统进行测试。

掌握了系统整体需求说明书的主要组成部分后，测试人员需要对系统进行各个模块的细化需求提取工作。为了整理提取需求方便，我们可以使用 Excel 来管理项目测试细化需求文件。项目测试细化需求的组成部分如图1.6所示。

项目测试细化需求分为需求汇总信息分析、流程分析、数据功能点分析和角色及部门分析。既然是细化的内容，大家可以根据项目的特性对其进行添加和修改，务必做到适合项目需求。

需求汇总信息分析的内容如图1.7所示。

需求汇总信息分析表汇总了项目中模块的分支流程、字段、功能点以及角色信息等数据。不要小看这些数据，这在测试管理层提交测试报告及测试绩效时是很有用处的。绩效报表之类的文件都是以数据说话的。

测试需求流程分解的内容如图1.8所示。

测试需求流程分解包括总流程与子流程信息。在每个预置条件成立的情况下，系统都能够产生相应的数据流。将这些数据流分解成最小的子集，对估算测试工作量以及提高对系统的熟悉度十分有效。

测试数据功能点分析的内容如图1.9所示。

测试数据功能点分析表包含模块、数据分析字段、角色、功能点以及逻辑这几个部分。

模块：填写需求分析后的系统模块名称。

数据分析字段：填写模块中的数据字段。可与数据库设计中的表字段做对比，也可用作界面测试的数据准备。

角色：填写该模块所包含的角色说明。可用于权限状态迁移的数据准备工作，也可用于优化测试用例的参考。

功能点：填写该模块所包含的功能点说明。可用于功能测试中测试用例的数据准备工作，也可用于优化测试用例的参考内容。

逻辑：填写该模块所包含的逻辑说明。主要包含两部分，数据库设计，如SQL语句的调用，以及程序的调用逻辑。可用于测试用例的数据准备工作，以及优化测试用例的参考内容。

测试角色分析的内容如图1.10所示。

测试角色分析表包括角色类型、角色名称、角色说明。

角色类型：描述角色的权限范围。用于权限相关测试用例的数据准备工作。

角色名称：描述角色权限里的角色职称名。用于状态迁移数据用例的准备工作。

角色说明：描述角色所拥有的权限、涉及的领域。用于测试用例的数据准备及优化工作。

测试部门分析的内容如图1.11所示。

测试部门分析表包括部门类型、部门名称、部门说明。

部门类型：描述部门的权限范围。用于权限相关测试用例的数据准备工作。

部门名称：描述部门权限里的部门职称名。用于状态迁移数据用例的准备工作。

部门说明：描述部门所拥有的权限、涉及的领域。此处可以体现部门与角色的关联关系。

用于测试用例的数据准备及优化工作。

学习以上内容后，开心掌握了测试人员应该对软件需求说明书进行测试需求分析，并且将分析的内容填写在测试需求分析表中。接下来，是不是应该写测试用例了？

初级测试人员开心打开用例说明书模板，如图1.12所示。

作为入门阶的初级测试人员，并不需要自行编写测试用例，所以在1.1.2节“工程师阶”中对测试用例进行具体分析。

开心想到了比目鱼先生交代的任务，要她先根据测试用例对系统执行测试。

“但是当项目进入了测试阶段后，测试人员该如何执行测试呢？”

比目鱼先生看着好学的开心，微笑着说：“那我就要画另外一张图了，你看好了。”

测试执行流程如图1.13所示。

从流程图中开心了解到如下内容。

（1）测试在开发阶段进入测试用例的编写工作。

（2）如果通过测试用例评审会议，开发将提供系统测试版本包的版本基线。

（3）进入测试执行阶段，我们需要先对开发版本进行冒烟测试。

冒烟测试的定义是将测试用例内最主要、最基础的功能及业务点罗列出来，用作冒烟测试用例。当开发提供的测试版本通过冒烟测试时，正式进入整体测试执行阶段。如果冒烟测试不通过，则将测试版本打回，开发修改bug后再次提交版本至冒烟测试通过为止。

（4）冒烟测试通过后正式进入整体测试阶段。大多数情况下，测试人员会进行系统测试。执行系统测试的同时，可以同步进行接口、性能、界面等测试。这部分内容测试人员可以根据项目需要，自行调节安排。

（5）当整体测试执行期间，测试人员需判定是否有bug产生。如存在bug，进入bug管理流程。测试人员和开发配合完成bug的修复工作。当bug的修复率满足测试准出标准时，测试人员进入编写测试报告阶段。

（6）完成测试报告的编写工作后，测试人员需和项目组成员开展测试执行评审会议。

（7）当测试执行评审会议通过后，测试人员提供测试完成版本基线。

（8）测试执行阶段结束。

当开心理解测试执行的流程后，她眼尖地发现在整个测试执行过程中，还有一个重要的环节就是发现缺陷后的bug管理流程。

“bug管理流程又是怎样的呢？”开心问比目鱼先生。

“接下来，我就给你讲解一下bug管理流程。”比目鱼先生又拿出一张空白纸涂涂抹抹了起来。

通常情况下，测试人员会使用一些工具来管理bug。例如Bugfree、Mantis、禅道、测试管理工具QC、jira等。这些工具都可以根据项目需要，自定义bug的修复流程和状态。针对项目特性，测试人员可以自己定义bug该如何管理。当然，你也可以使用Excel进行管理，有时最传统的方式反而比较适合项目上的沟通协作。不论运用何种方式，能够高效完成测试任务的就是最好的方法。

“为了让你看清楚，我画一下最常用的 bug 管理角色说明和bug管理流程。”比目鱼先生边说边画。bug管理流程中的角色说明如图1.14所示。

测试人员完成对缺陷进行录入及验证的工作。缺陷分析员对测试人员提交的缺陷进一步分析，确定是否为非缺陷。如果是，将缺陷打回给测试人员，要其判定该缺陷是否为非缺陷，如果是非缺陷，就将缺陷关闭。最后程序员对新建的缺陷进行修复，测试人员验证修复后的缺陷是否可以被关闭。这就是缺陷管理中的角色闭环。

bug管理流程如图1.15所示。

从bug管理流程图中，测试人员可以了解到bug的生命周期及其主要信息。

（1）测试发现缺陷，填写缺陷相关信息新建缺陷，状态为new。

（2）由缺陷分析员分析是否是缺陷，如果是，将缺陷状态变为 open 并分配给开发修复，开发修复后状态为fixed。由测试人员确定是否修复，如修复完成close，未完成renew，指派给开发重新修复。

（3）如果分析人员确定不是缺陷，则reject缺陷，由测试人员再次确定是否需关闭缺陷。

至此，关于测试人员介入后的主要流程都阐述清楚了。测试用例方面的内容会在测试工程师节中详解。作为入门级的测试人员，测试人员必须对软件测试的主要流程有个清晰的认识。初级测试人员在实际工作中，先根据测试工程师所写的测试用例执行测试结果，参与bug管理，锻炼和程序员沟通协作的能力。

软件测试的基础并不简单，不仅仅是根据需求点点点，而是有很多事要去做。在学习业务，提升测试技术的同时，更应该关注自己软技能的提升。测试人员最重要的软技能就是沟通协作。那么就从能和程序员顺利沟通较完美地完成测试任务开始锻炼自己。

测试工作是需要综合能力的职业，希望测试人员从入门开始就有这个意识，全面地给自己今后的发展打下基础。要做完一件事很简单，而要做好这件事很难。需要测试人员多多思考，而不是得过且过，只关注眼前成果。

在此另外提一下大多数测试人员都会遇到的问题。如果测试人员在一家小公司工作，不需要流程，也没有需求人员。整个公司就一个测试人员，而测试的定位只是开发的辅助，只需要进行功能执行就可以了，不要求编写测试用例。这样的测试人员是不是就没有发展了？不是的，就功能测试本身而言，想做好也需要经过很多思考。

举个关于测试覆盖率的例子，如以下两种情况。

特定条件下，“负负得正”的情况从结果来看是对的，而对于过程来说却是错的。

异常情况通过正常手段无法测试。

就像以上的例子，功能执行也会遇到比较多的特殊情况。如果你是个要求上进的测试人员，我有以下几点建议。

（1）即使领导不要求写测试用例，你也可以自己编写测试用例。我一直说测试用例是测试人员的灵魂，是成长的奠基石。别人告诉你的永远是别人的思想，自己实践过后，才能收获良多。

（2）每一次测试完一个项目后，都记录你在整个过程中遇到的问题及解决的方式。经过长期的积累，你自然会从中有所收获。

（3）不要轻易满足现状，对事物有追求，追求完美是测试人员提升自我的最大的动力。如果你能够将兴趣也放在测试方面，那就是更好的事了。

对于测试行业刚起步的那个时代，门槛其实很低，只需要细心、耐心、聪明就能把入门级的测试工作做好。但随着行业的蓬勃发展，测试被越来越重视，再加上经过多年的沉淀，测试人才也不像当初那么匮乏，因此准入的门槛也越来越高。以目前测试发展来看，入门级的测试人员已经渐渐无法在行业中立足。

1.1.2 工程师阶

软件测试的工程师阶层是指随着IT行业的飞速发展，测试人员犹如身在洪流之中“逆水行舟，不进则退”。知其然已经无法满足当今的测试人员，还要知其所以然。所以测试人员不仅仅要关注系统外部结构，还得了解系统内部的逻辑结构，需要把系统拆成模块，模块拆成单元进行更细致的测试。进行模块级别的拆分后，再把各种部件归纳组合，尽可能多地去遍历测试点，以保证系统的可靠性和稳定性。

一年过去了，初级测试员开心由于上一年积极努力的表现，被领导升为测试工程师级别。

她记得比目鱼先生说过：“到了这个阶层，测试人员需要更加深入地理解软件测试。在进行测试用例的分析前，测试人员需要了解最常见的几种测试类型及其测试方法。”

“那我怎么了解测试类型及方法呢？你会培训我吗？”开心问。

“我不会培训你，你已经不是一名学生，而是工作人员。工作人员就需要具备一定的自学能力。我给你一个星期，你可以利用网络资源，或者以向资深测试工程师提问的方式去学习。一个星期后，给我看你的学习成果作为试用期考核。如果通过了，我会给你讲解对于测试人员最重要的部分—测试用例的知识。”比目鱼先生回复道。

于是开心开始了自学之旅，她通过网络在测试论坛上搜索想要学习的知识点。看不懂的地方就请教团队里的资深测试工程师松心先生。

以下是开心关于测试类型及方法的学习笔记。

根据测试论坛上的测试类型及方法的基本概念，结合测试人员的实践工作，记录测试工程师阶需要理解的测试知识。

为了理解全面，可以将测试类型及方法从三个维度进行划分。

1.1.2.1 按项目开发阶段来分：单元测试、集成测试、系统测试、验收测试

1.单元测试

单元测试在实际工作中，是由开发人员在开发完成后自行进行的测试。

在这里先要明确一个概念，单元测试是一种测试，它需要独立设计测试用例及执行bug 修复的过程，而不是开发在完成程序的调试工作。调试是调试，测试是测试，希望大家不要混淆这两种不同的概念。单元测试是指对软件中的基本组成单位进行的测试，如一个模块、一个过程等。它是软件动态测试的最基本的部分，也是最重要的部分之一，其目的是检验软件基本组成单位的正确性。单元测试方法包括：控制流测试、数据流测试、排错测试、分域测试等。

站在测试的角度，测试人员希望开发人员能够在开发程序后进行单元测试。原因有二。

（1）对于程序员，单元测试能保证一定程度的开发质量，对于程序员自身能力的提高和自我约束能起到很好的作用。很多情况下，整体测试执行中的bug数会被体现在开发的绩效中。而在单元测试环节，开发就能够通过自测修复一部分bug。

（2）对于测试员，单元测试在保证开发质量的基础上，也减少了测试执行的成本。这个成本分为两方面。

测试执行不仅包括测试人员执行测试用例，很多时间是花费在程序员与测试员的交互上。这种交互是由于bug管理而产生的。因为bug数的减少，这部分测试执行的成本会被压缩。

测试执行大约占整个测试过程1/3的比例。由于开发质量问题造成测试增大工作量或者被推翻重来的情况很多。为了让测试成本可控并且有效地减少项目的成本代价，单元测试就是有效维护开发质量的方式。

当开发做了单元测试后，测试人员就利用冒烟测试检查单元测试成果。如果冒烟测试通过，项目正式进入测试阶段。如果不通过，则程序被退回，需要开发自行测试通过后，再交于测试人员进行冒烟测试流程。

还有另外两种情况如下。

（1）单元测试并不是由开发完成的。而是由专业的单元测试人员完成的。

（2）单元测试是由测试人员提供测试用例，但测试执行由程序员自己完成。

这两种情况虽然和我们常规的单元测试定义不同。但理论是死的人是活的，只要测试部与开发部能够达成一致，对该项目有推进作用，那就是可行的方法。

2.集成测试

集成测试是在单元测试之后进行的测试。项目中的集成测试大多由开发自己完成，开发把这种测试叫作接口联调。独立的集成测试项目是指在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确。它根据集成测试计划，一边将模块或其他软件单位组合成越来越大的系统，一边运行该系统，以分析所组成的系统是否正确。

集成测试的策略主要有自顶向下和自底向上两种。

（1）自顶向下的集成是从主控模块（主程序，即根结点）开始，按照系统程序结构，沿着控制层次从上而下，逐渐将各模块组装起来。在从上向下的集成测试过程中，需对那些未经集成的模块开发桩模块。在集成过程中，可以采用宽度优先或深度优先的策略向下推进。

（2）自底向上的集成是从最底层模块（叶子结点）开始，按照调用图的结构，从下而上，逐层将各模块组装起来。在从下而上的集成测试环境中，需对那些未经集成测试的模块开发驱动模块。

大部分情况，测试人员所做的集成测试又被称为接口测试。这也是本书所要阐述的测试重点。接口测试主要分为两种情况。

（1）系统层面

模块与模块间的接口传输是否正确。

系统与系统间的接口的传输是否正确。

（2）代码层面

类与方法的调用。

测试人员会在系统未被组建完全前，对模块的接口调用进行测试。当确定模块的接口传输正确时，我们可以初步认定模块被集成后不会出现问题。模块与模块间的接口是否传输正确，也可以通过功能测试的方法进行辨别。

对于复杂大型的系统架构而言，系统与系统间的接口测试比模块与模块间的接口测试更为重要。例如，一个资金入账的功能，就可能需要通过入账平台、第三方支付平台、资金平台、财务平台等多平台共同工作完成。这时平台与平台间的接口测试就尤为重要了。模块与模块间的接口问题，你或许可以通过系统测试时的功能测试被发现。但平台与平台间的接口问题，则需要独立的集成测试才能被尽早发现。这部分内容，会在接口测试章节中做出详细解析。

3.系统测试

系统测试是在集成测试之后进行的测试，也是测试人员接触最多的测试环节。系统测试是指对已经集成好的软件系统进行测试，以验证软件系统的功能正确性和性能等是否能满足其需求规格说明书所指定的要求。软件系统测试方法很多，主要有功能测试、性能测试、兼容性测试等。

在系统测试中，我们会经常用到回归测试和冒烟测试。

（1）回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误，回归测试的困难在于不好确定哪些内容应当被重新测试。

（2）冒烟测试是指对软件基本的功能进行测试。测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本的功能正常，保证软件系统能跑起来，可以进行后续的正式测试工作。

系统测试在工作中的实践情况为：系统测试是测试人员遇见最多的测试；功能测试就是系统测试的主要组成部分；在测试人员完成功能测试后，如果需求规格书上有对系统性能、安全性、兼容性等方面的要求，测试人员应该根据其规定的指标，进行性能测试、安全性测试以及兼容性测试。

系统测试分为：测试需求提取、测试框架确定、测试用例编写、测试用例执行、测试报告编写及评审阶段。测试人员在编写测试用例时，需考虑测试执行的顺序。在测试用例执行阶段，测试人员通常可以将其分为三轮测试及回归测试进行。将整体测试用例合理地分为三轮测试，最好能做到有两轮测试重复验证重要功能的情况出现，我们称为双重保证。这就需要测试人员去思考，怎样布置测试用例能够保险且不影响测试效率。在测试人员完成测试提交测试基线前，通常还会安排一次整体的回归测试以确保主要业务流程的正确性。

4.验收测试

验收测试是在系统测试结果后进行的测试。由客户或最终用户执行，旨在向软件的购买者展示该软件系统满足其用户的需求。它的测试数据通常是系统测试的测试数据的子集。所不同的是验收测试常常有软件系统的购买者代表在现场，甚至是在软件安装使用的现场。这是软件在投入使用之前的最后测试。

通常验收测试分为两个部分。

（1）Alpha 测试：由用户在开发环境的场所进行，并且在测试人员对用户的“指导”下进行测试。测试人员负责记录发现在错误和使用中遇到的问题。总之，Alpha 测试是在受控的环境中进行的。

（2）Beta测试：由软件的最终用户们在一个或多个客户现场进行。与Alpha测试不同，开发及测试人员通常不在Beta 测试的现场，所以Beta测试是软件在测试开发人员不能控制的环境中的“真实”应用。用户记录在Beta测试过程中遇到的一切问题并且定期把这些问题报告给开发者。接收到在Beta测试期间报告的问题之后，测试人员会初步筛选确定其是否为缺陷，再由开发人员对软件产品进行必要的修改，并将最终的软件产品发布给全体客户。

在很多项目中，除了需求、开发、测试、项目经理这些IT职称外，还有一类职称叫作实施人员。他们是业务人员与运维人员的综合体。他们可以介入测试阶段帮助测试人员一起测试，也是验收阶段的主要执行人员。验收测试一般不由测试人员直接进行，因为经过长时间的测试执行过程，测试人员的思维会形成固式（思维局限性）。实施人员精通业务，他们是需求的创始者，最后会脱离测试用例的约束，真正从初始需求的角度配置生产环境进行验收测试，做好面向客户的最后一道防线。

1.1.2.2 按测试执行的类型来分：功能测试、自动化测试、性能测试

1.功能测试

功能测试俗称点点点测试。初级测试人员的主要测试任务就是执行测试工程师所写的测试用例，记录用例的执行状态及bug情况。与开发人员进行交互直到bug被修复。

功能测试理论上是指通过测试来检测系统每个功能是否都能正常使用，主要关注外部结构，不考虑系统内部逻辑结构，主要针对软件界面和软件功能进行测试。

很多测试人员认为功能测试没有技术含量。其实这个想法是错误的，当你看不到程序是如何运行的情况下，要想找出深层次的问题对测试人员理解系统的程度要求很高。大家总是觉得单元测试很难，而系统测试中的功能测试很简单。但真实情况正好相反，测试人员认为单元测试很难，是因为其不会编码而产生的恐惧。这也就是会者不难难者不会的道理。当测试人员对代码有一定的认知后，会发现真正难的是看不到单元结构的外部测试。随着测试人员的能力提高，自然会在对事情的判断上有所更新。这是测试人员必经的过程。

2.自动化测试

自动化测试也是目前测试行业用得比较多的测试。行业中对于自动化测试的理论描述是这样的：自动化测试是利用软件测试工具自动实现全部或部分测试。它是软件测试的一个重要组成部分，能完成许多手工测试无法实现或难以实现的测试。正确、合理地实施自动测试，能够快速、全面地对软件进行测试，从而提高软件质量，节省经费，缩短软件发布周期。

虽然自动化测试看上去是一件事半功倍、非常值得去做的事情。但在我们的实际工作中，除了有资本实力的大公司，小公司介入自动化测试大多以失败不了了之。首先并不是所有的项目都适合自动化，特别对现在比较流行的 UI 自动化而言。不够成熟的项目对于前端变化很多，这就造成了自动化角度的维护成本很高。再加上人力物力等原因，使用自动化测试的成本高，但效果有时还不如简单的功能测试。实际运用的自动化测试性价比低就是造成其无法在小企业中生存下去的主要原因。所以自动化测试更适合已经成熟稳定的项目，且已具备了前期的投入资本。自动化可以说是测试技术的提升，对测试人员本身的技术成长是有好处的，但是大家还是要做好可行性分析，不要盲目跟风或者夸大其效果。

3.性能测试

性能是自功能后逐渐被大家关注的指标。说到性能，就想到用户体验。性能测试的基本概念为：性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行的测试。常见的性能测试有负载测试和压力测试，两者可以结合进行。

（1）负载测试用来确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。

（2）压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。

性能测试的常用指标为：事务响应时间、TPS、并发用户数、吞吐量、点击率、资源利用率等。

近几年来，会做性能测试也成为了测试人员的硬件标配。行业里也有很多描述性能测试的书籍，都是以工具使用为主的。例如，商业化的 loadrunner、开源型工具的 jmeter 等。使用性能测试工具还是比较方便的，对于大型的性能测试，性能测试工具的管理也比较规范。但就工作而言，要涉及大型性能测试项目毕竟少，而且工具虽好，但局限性也大。如果你是项目型的测试人员，并不是专职的性能测试工程师，工具对你来说就不是那么重要了。而为了使完成测试任务达到灵活便利效率高的效果，测试人员自己编写脚本对于项目的跨平台性和维护性的使用率反而比较强，所以本书会有具体的章节教大家写脚本实现简单的性能测试，以轻便高效为目的，摆脱工具的束缚，用代码提取项目中所需的性能指标。

4.安全性测试

虽然现在由于网络安全问题导致财务上的损失越来越多，人们开始关注安全，但测试人员真正建立独立的安全性测试项目的还是很少。大多数情况下，测试人员都是将安全结合在单元、集成、系统测试中进行的。应用程序级安全测试的主要目的是查找软件自身程序设计中存在的安全隐患，并检查应用程序对非法侵入的防范能力。根据安全指标不同，测试策略也不同。常用的安全性测试方法有静态的代码安全测试、动态的渗透测试和程序数据扫描。

在实际项目中，安全性测试基本是用工具完成的，常用的工具有RSAS、AWVS、Appscan、jsky、burpsuite等。

本书的重点并不是讲安全性测试，但安全性也有和Python相关的部分。例如，Python作为脚本语言，一直和网络爬虫联系在一起。作为一个以“破坏”为主的测试工程师，安全有时就是我们的麻烦，比如突破系统中验证码、加密数据的限制进行模拟请求等。所以要成为一名优秀的Python自动化测试工程师，对安全性也要有一定的了解。

1.1.2.3 按测试技术的不同来分：黑盒测试、白盒测试、灰盒测试

1.黑盒测试

黑盒测试是个很形象的比喻，它的概念就是把测试对象看作一个黑盒子，测试人员不用考虑程序内部的逻辑结构和内部特性，只需依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。界面测试、功能测试就是属于黑盒测试。

黑盒测试的常用方法包括：等价类划分、边界值分析、因果图分析、错误推测法等。

2.白盒测试

白盒测试，顾名思义，就是把测试对象看作一个透明的盒子，测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试，通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。单元测试就属于白盒测试。白盒测试方法包括：语句覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖等。

3.灰盒测试

世界不是非黑即白的，当中也存在灰色地带。灰盒测试可以理解为关注输入数据后的系统输出数据是否正确，同时也关注内部表现，但这种关注不像白盒那样详细，只是通过一些表征性的现象来判断内部的运行状态。例如，接口测试需要验证的是输入不同的数据，对应输出是否正确。它就是典型的灰盒测试过程。就像在上文提到的，当测试人员在做功能测试时，界面输出是正确的，但内部其实已经错误了。灰盒测试就是避免这种问题的有效手段。

一周后，比目鱼先生查看开心的学习成果比较满意，开始给开心培训测试用例的内容。

开心打开测试用例文档，如图1.16所示。

比目鱼先生提问：“开心，你知道测试用例是通过什么写出来的吗？”

开心想到这个问题从网络资源里看到过，答案是测试用例来自于需求，然后信心满满地回答：“测试用例是根据需求规格说明书写出来的。”说完，十分自信地等待着比目鱼先生的表扬。

“错了，测试用例和需求规格说明书之间还隔着两层呢！接下来我给你讲一下测试用例的奥秘。”比目鱼先生回复道。

测试用例是从哪里来的，大多数人会说它来自测试需求。从之前我对测试需求的介绍可以看出，测试用例是被细化的内容，它与测试需求之间似乎还少了点什么。少的这部分内容就是测试用例的框架。所以，测试用例不是从测试需求直接衍生来的，它首先由测试需求衍生为测试用例框架，再由测试用例框架衍生为测试用例。

很多情况下，大家想到测试用例就直接忽略大范围的框架，而只强调关注细节方面的内容。这是本末倒置的做法。

如图1.17所示，在设计阶段测试人员就可以开始测试框架的选择及编写工作。

测试框架可以分为两种类型。

（1）代码型测试框架：指代码框架的选型。如自动化测试中需使用的框架 Cucumber 和RobotFramework等，也可以是自己编写的框架。测试人员可以简单地使用这些框架完成测试用例管理、执行测试、输出测试报告等工作。

（2）用例型测试框架：指编写测试用例的框架，如图1.18所示。

在每个测试用例框架组成部分中的用例都有层级关系，如图1.19所示。

测试用例框架=测试用例整体需求+测试用例层级关系

测试人员在软件的设计阶段，就应该着手去跟进测试用例框架的内容。框架内容确定得越完整，在后期测试用例维护方面的代价就越小，如图1.20所示。

当测试人员确定了测试框架后，就进入测试用例的细写内容。根据整体测试需求的分配，逐一分析测试用例的组成部分。

测试用例汇总表，如图1.21所示。

测试用例汇总表包括：项目名称、版本号、需求基线、备注及用例信息汇总5个部分。

（1）项目名称：填写需写测试用例的项目名。

（2）版本号：测试用例的版本号。每一个项目都有唯一的测试用例版本号，每一次更新测试用例，都应该更新版本号。

（3）需求基线：测试用例来自测试框架，测试框架来自于测试需求，测试需求又从系统需求中提取出，所以在此填写系统需求的基线版本号，便于回溯测试用例的依据。

（4）备注：填写测试用例活动中的突发事件。例如，测试计划中里程碑时间的更改。

（5）用例信息汇总：包括用例区域、用例模块、用例子模块、用例三级模块、用例类型、用例数、备注等7个部分。

用例区域：规模比较大的系统都会按照地理位置或空间划分出很多区域。每一个区域使用的系统都具有其本地化的特色。在此类别中区分系统的区域性。通常我们会给每一个用例区域标一个用例ID，例如，项目A_1、项目A_2。

用例模块：用例模块取自系统模块。把系统按照业务流划分出各个大模块。通常我们会给每一个用例模块标一个用例ID，例如，模块A_1_a、模块A_1_b。

用例子模块：用例模块下的子模块。通常我们会给每一个用例子模块标一个用例 ID，例如，模块A_1_a_1、模块A_1_a_2。

用例三级模块：用例模块下的子模块的子模块，一般区分到三级已经很细，无需再向下延展测试项。通常我们会给每一个用例三级模块标一个用例ID，例如，模块 A_1_a_1_1、模块A_1_a_1_2。

用例类型：描述用例的类型。常用的类型有界面、功能、流程、接口、性能等5个类型。此处可以使用sheet跳转的功能，自动连接到相应类型的用例。

用例数：统计用例类型中的测试用例个数。包括正常测试用例以及异常测试用例。

备注：描述测试用例在编写过程中发生的事故。例如，由于缺失某部分的功能开发说明，导致该测试用例无法完成，需要延期至何时才能完成等信息。

接下来，以界面测试用例的内容为例，讲解一下测试用例的通用要素。

界面测试用例如图1.22所示。

界面测试用例包括：测试类型编号、测试类型描述、测试数据准备、测试项编号、测试用例编号、用例简述、预置条件、输入数据、测试步骤、预期结果、实际结果、用例等级、用例类型、执行状态、SQL语句及备注。

测试类型编号：测试类型编号是指当前sheet所在测试类型的唯一ID。例如，界面测试用例的编号为CSLX_01。常用的测试类型有功能测试、流程测试、业务测试、界面测试、接口测试、性能测试、单元测试、冒烟测试、系统测试。

测试类型描述：测试类型描述是指当前 sheet 所在测试类型的名称。例如，界面测试用例的描述为界面元素的检查。

测试数据准备：测试数据准备是指测试执行前的准备工作。例如，界面测试是以测试需求说明书以及系统原型图为依据的。

测试项编号：测试模块的编号。根据测试用例汇总表中的对应编号填写。

测试用例编号：根据测试项编号填写测试用例编号。例如，项目A_1下的模块A_1_a的子模块A_1_a_1的第一条测试用例的编号为模块A_1_a_1_001。

用例简述：测试用例的简单描述。用一句话说明用例的主要内容即可。例如，检查登录页面的界面元素是否满足要求。

预置条件：测试执行前需要满足的条件。例如，检查个人信息页面前，必须存在已注册用户的数据。初级测试人员在测试执行前按照该内容准备测试基础数据。

输入数据：当前测试执行时需要输入的数据。例如，界面测试中页面元素是联动的下拉框，那么测试数据b时必须输入数据a，初级测试人员在测试执行前按照该内容准备测试输入数据。

测试步骤：测试执行时使用的步骤。初级测试人员按照该步骤执行测试用例。

（1）登录系统。

（2）菜单：维护项目（A_1_a_1）。

（3）查看维护项目（A_1_a_1）初始化界面是否正确。

（4）查看数据编辑页面是否正确。

预期结果：测试执行后正确的输出结果。初级测试人员按照该内容核实测试结果是否正确。

（1）用户成功登录系统。

（2）用户成功进入【维护项目（A_1_a_1）】页面。

（3）显示如图维护项目（A_1_a_1）-001。

（4）显示如图维护项目（A_1_a_1）-002。

实际结果：实际测试执行后的输出结果。初级测试人员将实际结果与预期结果做对比得出测试结果是否通过。

（1）用户成功登录系统。

（2）用户成功进入【维护项目（A_1_a_1）】页面。

（3）显示如图维护项目（A_1_a_1）-001。

（4）显示与如图维护项目（A_1_a_1）-002 不符，缺少界面元素信息项资金流水号。

用例等级：用例执行的先后顺序。用例分为三个等级。

等级-高（H）表示最常执行以保证功能性是稳定的、系统可以正常的用例。通常指能够检验出重要缺陷的测试用例的集合。

等级-中（M）表示使给出的功能区域或功能变得更详细的测试用例。通常是指检查功能的非主要方面，包括边界、配置测试的测试用例。

等级-低（L）表示最少被执行的测试用例。但这并不意味着这些测试都不重要，这些用例在项目的生命期间里不常常被运行或者测试执行的顺序比较靠后，例如，可用性和性能测试等。

用例类型：用例的类型说明。当用例比较少的情况下，可以把所有用例汇总在一个sheet中，以这个字段区分用例的类型。例如，功能测试、接口测试、性能测试等。

执行状态：用例是否被执行通过。该字段分为通过、不通过、空。空的状态与备注项一起使用，在备注项中说明用例是未执行，还是不能执行的情况。

SQL语句：测试执行需要进行数据库操作的测试用例，在此项中填写使用的SQL语句。

备注：记录用例状态的说明或者出现的意外情况及对应措施。

测试用例的这些填写项被称为测试用例的要素。而测试用例经常使用的要素为测试标题、预置条件、输入数据、测试步骤、预期结果、实际结果、测试状态。它们被称为测试用例的7要素。有些测试工程师在面试时就会被提到相关的问题。面试官可以根据测试人员对这些内容的熟悉程度判断测试人员是否写过测试用例。有些测试人员认为只要背下来就可以了。我建议从理解的角度出发，不要死背测试理论知识。当你对一件事思考多了，它自然就烂熟于胸了。

不同测试类型的测试重点不同，它们所使用的测试用例元素也不同。

1.界面测试用例

界面测试用例不需要SQL语句项。用例层级按照最底层页面项区分。通常在测试用例中添加一个名为界面参考的sheet，与用例预期结果里的内容相呼应。

（1）用户成功登录系统。

（2）用户成功进入【维护项目（A_1_a_1）】页面。

（3）显示如图维护项目（A_1_a_1）-001。

（4）显示如图维护项目（A_1_a_1）-002。

界面参考如图1.23所示。

2.功能测试用例

功能测试用例需要包含所有测试元素。用例层级按照最小功能项区分，如图1.24所示。

以下列举一些功能测试用例的书写规范。

（1）测试项编号栏中填写测试用例的分割层级，功能测试用例一般按模块区分，以功能点为最小测试项。每一个功能点下分为多条测试用例。

（2）对于测试用例编号的设定理论上是要具有唯一性的。但如果测试用例只是通过 Excel 进行处理，则不需要作为模板导入，例如，QC 等测试管理工具。建议大家可以用简短的方式给用例一个编号用于区分即可，不需要为了满足规范设置不便于理解的编号。

（3）当用例需要输入大量数据或者它的预置条件十分烦琐时，可以另建一个 sheet 用于存放测试用例的数据准备。该栏直接作为内部链接链接过去即可。

构建独立的测试用例数据准备有以下好处。

使测试用例编写阶段的用例编写可读性强。

在测试执行阶段，测试人员也需要构造各种测试数据。由于测试的灵活性及不可预见性，即使在开发阶段已经设定非常完美的测试数据，届时也会有大量的新增及修改工作，独立的测试数据易于维护。

在bug管理阶段，测试人员需要根据测试执行情况进行bug描述与提交。很大一部分bug的产生就是由于测试数据引起的。如果测试人员前期没有记录，会造成bug描述不准确，甚至无法重现的现象。

（4）测试步骤清晰，以有序列表项标注。

（5）预期结果与测试步骤形成对应，一般一条测试步骤会对应 1～N 条预期结果，以有序列表区分。

例如，测试用例为检查工单打印结果的表头及签字处显示是否正确。

测试步骤如下。

（1）登录系统。

（2）菜单：A_1_a_1工单。

（3）选择一个工单，打印。

（4）查看打印结果。

预期结果如下。

（1）用户成功登录系统。

（2）用户成功进入【A_1_a_1工单】页面。

（3）成功打印，内容显示见SQL语句。

① 表头：卷烟机机械A_1_a_1记录表。

② 签字处值为空。

①和②都对应测试步骤中4的预期结果。把检查点分开写避免确认项多时的遗漏。

（4）当项目小且进度紧时，测试人员也会使用Excel直接对bug进行管理。此时为了让用例及bug形成关联，会在用例中添加bug编号一栏，链接到bug的描述sheet。

3.流程测试用例

流程测试用例不需要SQL语句项元素。用例层级按照最小分支流区分，如图1.25所示。

以下列举一些流程测试用例的书写规范。

（1）在测试需求说明书中，测试人员将系统的流程图进行了分解，得到在不同的预置条件下的多条流程路径。流程测试用例的用例层级就是对测试需求中分解流程的再次归纳梳理，形成主流程下的子流程、子流程下的多条备用流、备用流下的多条流程路径。流程路径对应的就是最小测试用例项。

（2）对于复杂的系统来说，一条主流程下可能会生成多条闭环的子流程，甚至互相嵌套交互。此时由于业务逻辑的复杂性，把流程细细地区分就十分有必要了。就系统层面来说，越多逻辑的地方越容易由于数据冲突等问题形成隐藏比较深的bug。

（3）功能测试用例的书写规范也适用于流程测试用例。

4.接口测试用例

在实际工作中，测试人员最常做的测试就是功能测试了。测试人员会根据需求功能说明书，通过界面上的按钮完成功能测试。功能是不是通过界面按钮完成的呢？其实不是。界面按钮只是触发功能的一种方式而已。

实际系统的功能是如何完成的？功能间的数据传输是如何完成的？完成这些事情的对象，就被叫作接口。程序员通过接口进行数据传输已达到完成功能的目的。

既然接口和功能息息相关，那么怎样的接口测试用例才能通俗易懂，便于维护呢？

以功能层级为区分，以报文内容为检验对象的接口测试用例，如图1.26所示。

以下列举一些接口测试用例的书写规范。

需要测试人员介入测试的接口一般分为两部分，系统间的接口及系统内的接口。接口测试用例也是由这两部分接口组成的。模式为：以菜单为层级区分。注意，此处的菜单并不是指页面菜单，而是更偏向于指功能流（功能流是指由小功能点组成的整个流程上的大功能）。

以材料A接口调用为例，绘制接口调用流程如图1.27所示。

从图1.27可以看出，单单一个功能流中就涉及三个系统的交互。在测试用例的预期结果中，要检查数据传输的报文内容是否正确，测试人员需要根据接口报文规范对所设计的接口传输数据的输入输出进行检验。所以，对应于接口测试用例需新增接口报文规范sheet，详细描述接口的输入输出字段等信息，如图1.28所示。

接口规范sheet包含以下几个部分。

（1）接口标题：详细描述该接口所涉及的功能信息。

（2）方法名：也可以是所调用的接口名。

（3）类型：所调用的接口的传输类型。

（4）调用系统：报文数据在哪些系统中进行传输。

（5）输入参数：该接口的输入参数的字段名称、类型、中文说明、输入参数值、备注。

（6）输出参数：该接口的输出参数的字段名称、类型、中文说明、备注以及在不同的预置条件下输入参数后，该接口所需输出的参数值。

5.性能测试用例

对于测试人员来说，可能还有一部分性能需求，不同于系统完成后的大规模性能测试，而是在前期开发阶段，就完成基本功能的响应时间的需求，为后期模块功能组合在一起后的整体性能达标做好准备。根据项目需要，测试人员可以完成针对具体功能点的性能测试。

一般有两种实现方式。

（1）通过负载接口压测来实现接口的性能测试，一般可以通过程序模拟或jmeter工具来完成。

（2）不通过负载，单用户情况下的响应情况。可以人为地通过httpwatch等工具来完成。

这部分的测试用例层级就和接口测试用例十分相似了，以菜单作为用例的层级关系，如图 1.29所示。

这部分性能测试在系统测试执行时即可完成。

6.其他测试用例

除了以上提到的测试用例类型。在测试用例说明书中，还会出现单元测试用例、冒烟测试用例、系统测试用例。

（1）单元测试用例：包含7元素及程序逻辑的测试用例。需要测试人员对代码程序有一定的熟悉度。一般由测试人员提供，开发人员执行。

（2）冒烟测试用例：系统测试用例中的最基本部分。一般由基本功能构成，包含大部分测试用例的通用测试用例。因为通用测试用例一般是整体测试用例的预置条件，这些用例必须先通过才能保证测试执行的进度。

（3）系统测试用例：以上所说的测试用例类型严格来说都包含于系统测试用例。当系统规模大并且业务逻辑复杂时，就会将系统测试用例切分成各个测试类型的sheet。而系统测试用例sheet本身只具备主要业务流程的用例，这部分用例将在每次上线及版本更新时，给测试人员用作线上的回归测试用例。

本节具体介绍了通过测试需求说明书编写测试用例的规范及用例的编写要素。测试用例是测试人员的灵魂，如果你是个积极向上、要求进步的测试人员，就不要因为项目进度等客观因素而荒废测试用例的编写。当测试人员真正用心地开始编写测试用例后，就会发现做好测试并不简单。往往要写出一份覆盖度高而对效率并没有要求的测试用例，已经不是一件简单的事情。更不要说对测试用例的执行效率有要求所需要付出的努力。所以测试人员应在项目需求阶段就介入测试工作，并在随后的每一个阶段将测试工作层层递进。

工程师阶级的测试对比入门阶级的测试，最大的差别在于需要使用各种测试方法。测试人员并不是想到什么测试什么，而是在理解系统结构的基础上，科学并且合理地利用有限的时间做高效的测试。何为高效的测试？就是需要不断地改进测试用例的编写方式，在经验中总结技巧，在技巧中取其精华，去其糟粕。希望测试人员能够在每次学习中思考以往在项目上的测试行为有哪些改进点，并在之后的测试任务中实践改进措施。

1.1.3 专家阶

一晃5年过去了。测试工程师开心凭借着自己的努力得到了领导及客户的肯定。她从一名普通的测试人员成为了测试小组最年轻的leader。

比目鱼先生欣慰地说：“开心，这几年你很努力，也取得了一点成绩。你对今后的发展有什么想法吗？”

开心微微一笑，谦逊地说：“感谢领导的夸奖，要不是您的悉心栽培和同事的帮助，我也不能学到这么多东西。最近我总感觉自己遇到了瓶颈，却又不知道问题出在哪里！”

比目鱼先生回复：“你是不是觉得别人夸你进步很大，但你却感觉自己不懂的越来越多？你对测试思考的越多，就会越需要其他领域知识的积累。这是一次技术水平上质的飞跃，也是你从测试工程师成为测试专家的必经之路。”

就这样，开心根据比目鱼先生的指导继续她的学习之旅，向成为一名优秀的测试专家前进。

作为软件的专家阶，首先需要测试人员具有一定程度的计算机技术储备，只累积测试经验远远不够，还要不断地学习其他领域的知识。

需要储备的技术大致分为以下几个部分。

（1）js/css前端技术

（2）网络架构

（3）网络协议

（4）DNS解析

（5）负载均衡策略

（6）Linux系统基本操作

（7）数据库知识

1.js/css前端技术

很多测试工作都由前端发起，所以了解前端技术可以让测试人员使用更灵活的方式执行测试任务。如何利用前端技术辅助测试人员更好地执行测试？就要从网络开发模式说起。

网络开发分为前端和后端，为了减少对后端没意义的请求，数据正确性的校验一般都会放在前端代码中。这样即使后端不判断，正常情况下也不会出现什么大问题。但如果遇到前端代码被篡改，就可以绕过前端验证发送请求到后端，而当后端的判断有问题就会造成错误的数据进入，从而引发其他bug，所以要测试这种问题也要会修改前端代码，以便绕过前端验证。

举个输入手机号的例子。

现在一般都是以手机号作为用户名的，而手机号是固定的11位数字，前端一般会限制最多输入11位数字，那要输入12位数字怎么处理呢？这时候需要使用浏览器的开发者工具了，以下为操作步骤。

（1）打开chrome浏览器。

（2）按住F12调出开发者工具。

（3）选择最左边的定位元素按钮。

（4）选中需要测试的输入框。

（5）出现该输入框的对应的代码，如图1.30所示。

可以看到输入框有个属性maxlength=11，这段代码说明了输入框的最大长度是11，将11改成一个很大的数字，然后再在输入框输入就可以超过11了，如图1.31所示。

前端可以修改的东西还很多，这只是举一个简单的例子，所以测试人员需要懂得前端技术。在学习技术的过程中，当遇到不懂的前端代码时可以请教前端开发，与其合作构建符合测试用例预置条件的测试场景。

2.网络架构

网络架构一般分为两种。

（1）C/S（Client/Server）结构

（2）B/S（Browser/Server）结构

对于核心的Server端来说，简单的是可以在一台服务器上布代码和数据库；复杂的就需要一群服务器，有些服务器布代码，有些服务器放数据库，有些服务器做中间层，有些服务器用于存储。

从最简单的开始说起，Server端就是一台服务器，上面有应用代码和数据库。

后来前端访问越来越多，一台服务器无法承受，把数据库和应用代码的服务器分开，于是就形成了几台应用服务器+一台数据库服务器。

往后发展用户越来越多，一台数据库服务器也无法承受了，那就需要进行数据库分离，把不同用户的数据库放到不一样的数据库服务器上，于是形成了几台应用服务器和几台数据库服务器。

随着用户和访问量越来越多，并发的情况导致数据库堵塞，聪明的IT工程师想了一种办法，能不能在代码与数据库之间加上一个保护？于是诞生了中间层。中间层也可以理解为另外一种应用服务器，上面有代码，也有数据库，即代码请求数据的时候不直接连接数据库，而是连接中间层，中间层连接数据库。逻辑如图1.32所示。

这样当中间层缓存了数据库的数据之后，第二次前端访问同样的数据时，即可通过中间层返回，而不需要再去请求数据库。当然这只是读数据库的逻辑，写数据库其实也差不多，就是通过中间层去写数据库，写完数据库再将写完的数据返回来缓存到中间层，这样很大程度减少了读数据库的压力，起到了保护数据库的作用。

有了中间层之后也并不是高枕无忧了，随着业务功能越来越多，应用服务器也可能随时承受不住压力，为了规避风险和提高服务质量，通过域名对业务进行分离，保证一块业务模块单独用一个域名，然后每个域名再用多台服务器，这样一旦某个业务模块出问题之后也不会影响到其他业务模块，而且单独一块业务用一群服务器也能提高处理效率。

经过不停的演变和进化，Server 端越来越复杂，最后如图1.33所示。

当然这并不是一个终极形态，只是完成了树干而已，随着业务的拓展和提供更快、更稳定的服务，可以再进行分离。优化从无止境，所以Server端的网络架构只会更复杂，更精细。了解Server端的架构对于测试来说是一种基础，只有明白了所有的环节，才能对每个点进行测试，不然无法保证测试的覆盖率。不仅如此，这对于定位bug也是大有帮助的。

3.网络协议

在网络上，计算机之间是如何通过通信进行信息交流的？就如同开心和比目鱼先生进行对话一样，网络协议就相当于人类所使用的语言。不同的网络协议类似于不同的语言，它们具备各自的规则特性及约定的标准集合。常用的网络协议有Http协议、Https协议和WebSocket协议等。本书在第4章中会详细讲解这三种协议。

懂得网络协议对测试人员做专项测试尤为重要。特别是接口测试以及性能测试，它们所使用的数据通信机制就是建立在协议的基础上的。测试人员了解协议后，才能明白数据传输究竟是怎么一回事，熟悉协议的组成部分，才能自如地构建测试数据，绕过前端向服务器发送请求。协议是数据传输的本质，也是测试人员在技术提升上的一大步。

4.DNS解析

DNS是计算机域名系统（Domain Name System或Domain Name Service）的缩写，它是由解析器和域名服务器组成的。域名服务器是指保存有该网络中所有主机的域名和对应IP地址，并具有将域名转换为IP地址功能的服务器。

DNS解析就是把域名解析成ip的过程，一般网络的访问流程如图1.34所示。

一般来说DNS服务器都是由网络运营商提供的，也就是说不需要特别设置，当你使用该网络时默认会去访问运营商提供的DNS服务器。当然你也可以自动设置DNS服务器，在网络的TCP/IP协议中，手动输入DNS的IP，于是便会通过你设置的DNS去解析对应的IP。

好学的开心提问：“用不一样的DNS有什么区别吗？”

“对于只有一个IP的网站来说是没有区别的，对于有多个IP的网站就不一定了。”比目鱼先生回复道。

先举个例子，当百度只有一个IP的时候，无论哪个DNS解析到的只有一个IP，这样域名对应IP就是一对一的关系，如图1.35所示。

再举个例子，当百度存在多个IP的时候，不同的DNS会解析到不同的IP，这样域名对应IP就是一对多的关系。然而一个用户只能使用一个DNS服务器，所以对于一个用户来说，他访问IP也是唯一的。如果他改了DNS服务器，也许才会解析到另外一个IP，如图1.36所示。

其实还有一种特殊情况是一个 DNS 解析到多个IP，就是DNS轮询。一个域名针对多个IP a记录的解析，DNS服务器将解析请求按照a记录的顺序，逐一分配到不同的IP上，当轮了一圈之后继续循环，即IP1，IP2，IP3，IP1，IP2，IP3这样的顺序。这样的好处是为了实现负载均衡，但随着CDN技术的普及，这种方式已经渐渐被淘汰，DNS是CDN的基础，所以先要明白DNS，才可能理解CDN。

为了让大家更深刻地理解 DNS，再介绍一下DNS 劫持的原理。简单来说就是计算机中病毒，然后病毒修改了计算机的DNS设置。此时访问任意网站都会通过该DNS，而该DNS返回给你的IP并非该网站的真正IP，而是一些广告网站或者色情网站的IP。当然这并不是最高级的，因为用户可以很容易改回正常的DNS，高级的做法是入侵正常的DNS服务器，改掉域名和IP的正确对应关系。于是使用该DNS的用户都会遭殃，这种情况只能等运营商去修复或者使用其他未被入侵的DNS。

5.负载均衡策略

随着网络的普及和发展，瓶颈已经不再是服务器或者数据库的压力了，而是流量和访问速度。打个比方，有一个很大的水池可以存放很多水，但是只有一个水龙头放水，此时水就会放得很慢，后面的水要等前面的水放出来才能进入水池，那么怎么办呢？多弄几个水龙头同时放水就可以解决这个问题。其实CDN就是这么一件事情。

CDN的全称是Content Delivery Network，即内容分发网络是通过在网络各处放置节点服务器所构成的在现有的互联网基础之上的一层智能虚拟网络。CDN系统能够实时地根据网络流量和各节点的连接、负载状况以及到用户的距离和响应时间等综合信息将用户的请求重新导向离用户最近的服务节点上。其目的是使用户可就近取得所需内容，解决 Internet 网络的状况，提高用户访问网站的响应速度。

最常见的就是通过CDN服务商去分配合适的IP给用户访问，一般遵循3种方式分配。

（1）就近分配，即CDN服务器获取本地IP所在地，然后访问最近的CDN节点，这样可以少经过几条路由，从而加快访问速度，如图1.37所示。

（2）负载均衡分配，如果都按照上图的原则去分配，势必会导致一个问题，即北上广的用户过多，而其他地方用户太少，这样北上广用户还是会慢，都堵在一个节点。所以需要根据每个节点的负载压力自动将其分配到压力较小的节点。

（3）手动分配，以上两种都是自动分配，但有一种情况是某个节点网络出问题，或者机房断电等不可控因素，这时候就要手动调配节点以保证用户不受影响。

当然也可以不通过CDN服务商达到CDN的目的，就是自己做CDN，虽然成本较大，但私密信息不会泄露。毕竟通过CDN服务商必须把信息放在CDN节点上，这样隐秘性比较难保证。

最后说一下云服务，随着网络架构越来越复杂，需要耗费大量的人力和物力去搭建网络架构，还有很大的维护成本。于是就兴起了云服务，云服务的说法众说纷纭，原理搭建一套独立的网络系统提供给企业或者个人使用，从中收取费用。对使用者而言节约了自身的开发和搭建的时间，而对于云服务的开发者来说又提供了很好的服务。这是一个双赢的结果，也是越来越多企业和个人愿意使用云服务，而各种大公司又愿意开发云服务的原因。

6.Linux系统基本操作

Linux 系统作为常用的服务器系统，不论测试环境的部署，还是构建测试场景，它的基本操作对专家级的测试人员来说都是必须掌握的技能。测试人员可以从以下几方面学习Linux知识。

（1）获得帮助

#help

#man

（2）基础命令

tar与gzip

mount，umount

图形界面和命令行界面的切换

列出目录中的文件（LS）

目录切换（CD）

创建、移动、复制、删除文件的操作

重启和关机

（3）建新目录

cp

rm

mv

dudf

cat

（4）文件指令

（5）清除屏幕

ln

grep

find

ar

（6）组管理

（7）进程服务

（8）网卡设置

（9）服务进程

Web服务

ssh服务

7.数据库知识

数据库对于测试人员来说不是陌生的话题。测试工程师在编写测试用例时，要根据数据库的表结构编写SQL语句。让测试结果不受前端显示的影响，可以更彻底地校验数据的正确性。

对于专家级的测试人员，数据库的使用也不是单单停留在查询数据而已。可以通过对数据库的修改构建测试人员所需的测试场景。这算是一种比较高级的测试，这种测试已经不是简单的黑盒测试，首先要对程序逻辑清楚，而且还要对数据库的表和字段都非常熟悉，不然是没法通过对数据库的操作来达到测试的目的的。

有些时候需要测试工程师具备检验异常情况下的程序处理能力，而某些异常场景通过测试数据本身无法模拟。这时候就需要通过修改数据库，如插入一条异常数据，或者修改某个字段，达到构建异常测试场景的效果。具体情况需要根据程序和数据库的处理逻辑来修改，这是专家级测试人员必备的一种测试思路。

以上这些不需要样样精通，但至少需要达到理解的程度。因为具备这些知识不仅可以发现更深层次的bug，对于分析定位bug也非常有用。而此时可以做的测试内容就非常多了，不再局限于手工测试，可以借助于各种辅助工具来协助测试，从而完成一些手工测试无法做到的测试，比如接口测试或者安全性测试等。

专家级的测试人员需要具备很强的综合能力，不但要精通各方面相关技术，还需要具备一定的编码能力，能将人工的测试转化为自动化测试和并发测试，并且通过工具或自己写的脚本把人力从一些烦琐和重复的测试之中解放出来，从而投入到其他更需要花时间测试精力的地方。这就需要测试人员具备专业以外的技能，如项目管理以及业务分析等。

专家级的测试相比工程师级的测试，可以通过各种方式把测试贯穿在整个项目中，将测试进行得更全面和细致，大大缓解了测试时间的压力，自然而然项目的质量也会更好。虽然说“三个臭皮匠赛过诸葛亮”，但考虑人力成本的性价比，公司应该一定会选择一个诸葛亮。

1.1.4 总监阶

光阴似箭，转眼间又一个3年过去了。在测试行业上兢兢业业奋斗了8年的开心，已经具备专业的测试技能和广阔的技术储备。此时的比目鱼先生也从测试部的总监成为整个技术研发部的总监。临近年终，比目鱼先生找开心进行年终谈话。

“开心，明年公司的组织架构要进行调整。我将要管理整个技术研发部，这几年一直带领你管理测试部的事宜。明年，我会把测试部交给你，作为新一任的测试总监希望你能再接再厉，独当一面！”比目鱼先生微笑着说。

“谢谢领导！一定完成任务，是不是又要加工资了？”开心快乐地回答。

“恩，升职了工资是肯定会加的。先给你一个任务，今年的测试部门年终总结和明年的计划就由你来写吧。”

“好的！”开心果断地回复道。

测试总监最重要的工作已经不是身体力行地介入测试执行中，而是能够从大局考虑提升整体测试部门在项目周期中的地位。总监的工作除了为提升测试部能力所做的努力外，最主要的工作为以下两点。

（1）如何向公司汇报测试部的工作。

（2）如何做好明年的工作计划及人力资源的分配。

以下举例说明测试部的年度工作总结及来年计划的组成部分，如图1.38所示。

2018年度测试部门工作总结包含以下5个部分。

1.工作成果展示

（1）测试用例情况

① 专维型及项目型用例情况

一般公司的测试项目分为两种。

专维型：无固定项目周期，需要长期维护的老项目。

项目型：项目周期短，有明确项目截止日期的新项目。

这两种类型的测试项目由于其特殊性，所需匹配的测试流程也不同。所以不论是测试用例，还是bug分析，都需要分开进行统计。

测试用例情况需要将一年所有的测试用例进行归纳整理，用饼图、柱状图等数据报表的形式进行展示。如果测试部是用专业测试管理工具QC进行管理的，那就不需要人为进行统计，QC具有自动报表统计功能。

② 用例优化情况

测试部完成用例的设计方法、框架、通用性提取、测试步骤顺序等大量的优化工作。对测试用例的优化进行归纳整理后，用饼图、柱状图等数据报表的形式进行展示。从图表情况可以看出，用例在保证质量的情况下大量被缩减，这是优化工作、提高测试效率的有效体现。

（2）bug情况

bug情况统计以季度为时间轴，统计bug的总提交数及bug的非缺陷率。

bug的总提交数：测试人员本年度提交的bug总数。

bug的非缺陷率：测试人员提交的bug中，被认定为非bug的数目。

将数据统计出来后，可以用折线图的方式展现。如果其中非缺陷率明显下降，能够说明测试人员测试及业务能力的提升。

（3）测试研究工作

测试研究工作是提升测试部技术水平的重要手段。本年度测试部在不同的测试技术上都进行了研究工作，除了技术文档的积累，还总结了一些过程文档和例子工程，以用作测试分享的素材，如图1.39所示。

（4）测试团队建设

本年度在团队建设和团队管理上，测试部门都会有一些改进。

（a）用增强周报反馈质量的方式来减少测试例会频率，降低管理成本。

（b）增加测试培训和测试分享的次数，完善培训的预习考试跟踪机制，提升测试人员的测试技能。

（c）增加团队活动种类来增加团队活动的丰富性，推动团队建设。

团队建设百分比如图1.40所示。

（5）项目资源投入情况

各项目中人力资源的投入情况，如图1.41所示。

2.工作内容

工作内容中具体描述测试部在本年度中所做的工作内容。可以将项目类、专维类以及研究类划分后分别进行汇报。以测试流程中的改进内容为例。

（1）了解需求

① 本年度项目变更仍然是每个月度为一个变更周期，在每个周期开始前会开展排产会。排产会上主责部门会通知这个周期变更的内容，业务、开发、测试部门确定自己的发布节点。

② 在需求方面，今年测试人员比以往更早的介入测试工作。去年是等待主责部门发送需求文档，完全通过需求文档来了解业务需求。今年测试部门与主责部门进行协商，需求发布后会有一个需求沟通会，会上需求人员会对本次需求进行解说。测试人员有疑问可以在会上及时提出，这种方式使得测试人员提前对需求有了了解，对于需求有了更深的理解，设计出更符合用户需求的测试用例。

（2）冒烟测试

① 在需求沟通会后，测试人员在开发发布前完成用例的设计工作，并通过禅道录入的方式给开发提供单元测试用例，给业务咨询组提供冒烟测试用例。

② 根据质量部认可的准入准出标准，业务咨询组提供的版本必须是冒烟测试通过的。因此测试人员会介入到业务咨询组冒烟测试工作中。见证该版本的变更冒烟测试通过后，业务咨询组会提供版本和针对发布变更的配置表。

（3）测试执行

① 我们根据配置表更新测试数据库后替换版本，初级测试执行人员根据测试设计工程师的测试用例进行测试执行工作。

② 自动化测试负责人开始在新版本上运行自动化脚本。

③ 在测试执行人员进行一段时间后，会有Monkey测试人员介入，形成内部监督机制。

④ 预留时间对仍未修复的bug进行验证和版本发布。

（4）版本发布

发布时，会根据实际测试结果进行测试报告的编写，并提出测试组对项目的建议和意见。同时，将测试版本上传到主责部门SVN的指定路径上。

（5）bug统计

在一个测试周期发布后，测试部门会开展bug统计工作，来总结这个阶段在bug方面测试工作的不足和成长。

3.心得体会

测试人员记录测试过程中总结的经验教训。

（1）需求了解阶段

在需求了解阶段，不能只是通过需求文档，从字面上理解需求的意义，更要通过需求沟通会去了解需求，对比自己从文档上理解的是否有偏差。在理解需求的同时，更要站在测试的角度（是否满足用例设计的需求）提出需求文档的疑问和建议。

（2）测试需求提取阶段

在测试需求提取阶段，要根据需求文档提取出测试流程、功能点流程、接口等信息。功能点如果涉及字段的更新及赋值等要具体到字段。同时要将所有涉及的字段罗列出来，做到一个高的覆盖度。这样设计人员的用例设计条理就会很清楚，也保证了一定的覆盖率。

（3）测试设计阶段

用例设计工作不仅仅是要保证需求的覆盖率，还要在测试执行和下次用例设计的效率上有所考虑。因此我们做了一些功能的研究，并且找到了一些提高测试用例执行效率的方法，并在后续的测试设计中应用，发现整体的测试效率有显著的提高。另外测试用例在稍做修改后提取出来作为通用的，当再出现类似变更时，我们便可以复用这部分的用例，大大节省了资源的投入。

（4）测试执行阶段

在测试执行的过程中，测试人员要始终抱有质疑的态度。当发现一个bug时，要进一步思考bug产生的原因及相关步骤是否也可能存在问题，这样才能更多更好地发现系统中的缺陷。

在bug录入时，描述完特定的操作步骤后，可根据描述的内容再执行一遍操作，以免产生歧义，尽量避免非缺陷。另外，bug 描述中提到的测试数据需保留，避免由于无法重现而漏掉缺陷的情况。

在验证bug的过程中，要始终思考修正了该bug会不会引起其他缺陷，以保证版本的质量。

（5）测试发布阶段

测试发布阶段也是一个很关键的阶段，发布阶段的重点在于测试报告的编写和程序版本的上传。测试报告的编写不仅仅只是测试结果是否通过，除了如实反映测试情况外，更重要的是要反馈出我们测试过程中发现的问题及建议，希望测试部门和主责部门共同改进工作方式。

（6）bug分析阶段

每个周期的bug统计工作，不光是看看本周期测试人员和业务人员提出了多少bug，更重要的是要关注测试人员所提的非缺陷，并总结一下原因，以后是否可以避免类似的非缺陷。同时，对于实施提出的bug，要分析一下是否有我们测试过的变更在业务测试那里被发现问题，如果有，分析一下我们没有发现的原因，提升测试质量。

4.改进措施

描述测试部存在的不足以及改进措施。

举例说明如下。

存在的不足：测试人员技能单一，不能灵活运用。

改进措施：加强员工测试技能培训，提高核心竞争力。

针对测试工作中技能的提升要求，在培训上，测试部门主要采取了以下两种措施来提高测试人员的技术水平。

（1）测试分享

每次测试例会的第一项就是测试分享，测试分享不限制内容。可以是自己最近学习到的一些新技术或者工作中的一些经验教训，做成PPT跟大家分享，形成知识共享平台；不断在工作中累积经验教训，避免大家都犯相同的错误。

（2）定期的培训

在培训上，我们会提前制定培训计划，包括培训主题、讲师和时间。在培训前讲师会提供预习资料，培训过程中讲师会对预习效果进行考核。

培训结束后会有考试或者作业，根据测试人员的作答进行打分，打分的结果结合红黑牌制度进行相应的奖罚措施。这种培训方式提高了参与人员的积极性，使得每个人都会从培训中学到很多。

5.意见和建议

此部分描写测试人员对测试部以及合作部门的建议。

对测试部自身建议

（1）分配资源进行研究工作，进一步提升测试人员技能。

（2）承接更多类型的项目，提升测试人员对不同类型项目的测试能力。

（3）引入新的技术，提升测试质量与覆盖度。

（4）优化工作流程或方式，提升测试工作效率。

对开发部门建议

（5）建议开发部门在bug修复的效率上有所提升。

（6）建议开发部门在文档有变更时及时通知测试部。

（7）希望开发部门在发布变更的同时，先通过项目变更管理流程的变更审核。

工作计划包含以下3个部分。

1.工作总目标

此部分根据项目类型的不同，列出测试工作的总目标。

（1）按时高质量的交付测试版本，并且提出测试组的建议。

（2）在测试过程中发现更多比较深层次的bug，并且可以定位原因，为开发部门提供更多的参考。

（3）测试人员介入项目各个环节，提升测试影响力。

（4）运用自动化思想，提升整体测试日常工作效率。

2.工作重心

描述新一年度测试工作的主要任务。

（1）测试组的主要工作重心还是放在高质量地完成测试项目。

（2）同时在内部工作，人员业务及技术积累上希望得到更多的提升，成长为一个更有核心竞争力的团队，为公司创造更多的利益。

3.人力资源分配

根据不同的项目类型列出测试部预估工作量，进而计划人力资源分配。此部分内容需先于项目承接部门进行沟通，确定明年的项目预算再行评估测试工作量。

（1）外部项目

经过与项目管理部门的沟通，每个外部项目的工作量大概在6人年左右，共计48人年。预估测试组工作量约为12人年。

（2）内部项目

测试管理项目预估工时为1.16人年。

测试技术研究项目预估工时为4人年。

测试总监的工作非常杂，需要测试人员具备各个领域的能力，也是测试技术人员向管理人员发展的一大步。由于长年的技术习惯，很多技术人员转为管理人员会非常不适应。技术与管理原本就会产生冲突，技术讲究具体细节上的完美，而管理更看中的是大局观的建立。

所以，成为一个优秀的测试管理者会是许多测试人员的发展瓶颈。随着近几年测试行业的发展，专家阶测试人员所具备的能力已经能够满足行业对测试人员的需求。但是从自身价值的提高来看，只有让自己不可替代，才可以立于不败之地。如果有更多的人能够成为测试总监，或许那才是测试地位真正崛起的时代。