书名：测试开发实战教程
ISBN：978-7-115-59412-9
本书由人民邮电出版社发行数字版。版权所有，侵权必究。
您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。
我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。
如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。
主 编 霍格沃兹测试开发学社
责任编辑 张 涛
人民邮电出版社出版发行 北京市丰台区成寿寺路11号
邮编 100164 电子邮件 315@ptpress.com.cn
网址 http://www.ptpress.com.cn
读者服务热线：(010)81055410
反盗版热线：(010)81055315
本书采用理论与实战相结合的方式，不仅对软件测试的理论知识进行了深入的讲解，还配套了与理论相结合的实战练习，能帮助读者更深入地理解每个知识点。本书共8章，第1章讲解软件测试的入门知识，包括测试流程、测试常见方法、测试用例设计等；第2～5章讲解Web测试、Web自动化测试、App测试、App自动化测试；第6章和第7章讲解接口测试，包括接口抓包分析与Mock介绍、接口自动化测试；第8章讲解持续集成。
本书既适合软件测试工程师阅读，又适合想要深入学习软件测试、自动化测试、测试开发等技术的初学者作参考书，同时还可以作为高等院校相关专业师生的学习用书以及培训学校的教材。
主 编：霍格沃兹测试开发学社
编委会成员：黄延胜 方 圆 胥 娟 李 旭 黄小忱
张 颖 周少玲 张 炳 张福勇 孙高飞
李 隆 丁 超 张琰彬
审 稿 成 员：汤易怀 李晓丹 王 森 陈 杰 杨晨晖
盖金凤 吴从佛 杨铁桥 马云龙
在此诚挚感谢所有为此书付出努力的作者（排名不分先后）。
随着互联网行业的发展，互联网产品已经和人们的日常生活密不可分。不论工作、娱乐、生活都已经离不开各种类型的互联网产品。正是因为互联网产品如此广泛地存在人们的日常生活中，所以互联网产品的质量必然会影响每个人的日常生活。
软件测试工程师正是负责把控互联网产品质量的最重要的角色。
可如今，互联网软件测试人才的缺口越来越大，可作为这个人才缺口最重要的补充的大学生，在学校里主要学习的是测试的基本理论知识以及部分工具的使用，缺乏系统的项目实战技能，不仅很难把所学知识很好地运用到项目中，而且对整体测试知识学习的课时较短，所学技能不能满足企业所需！本书针对此问题，每一个章节的内容不但包括理论知识，还精心设计了实战案例及相关练习。大学生通过本书既能学习到测试技术，还能具备实战能力。
霍格沃兹测试开发学社具备多年的测试开发知识培训经验，可以很好地将测试开发技术、实际项目与测试开发知识相结合，针对大学生和初学者缺少的测试思维、测试技术进行优化与提升，以帮助他们尽快提升实战能力。
本书共8章。
第1章：测试流程与理论。主要包括测试流程介绍、测试用例设计方法，以及测试流程实战练习。
第2章：Web测试方法与技术。主要讲解Web测试方法与技术，包括Web基础技术、HTML、JavaScript、CSS等，并将这些常见技术与软件测试结合，让读者理论结合实践，学以致用。
第3章：Web自动化测试。主要讲解Web自动化测试过程中常用的技术，以及常见问题的解决方法，如Selenium的常用API、经典的UI自动化测试模式（PO设计模式）等。
第4章：App测试方法与技术。主要讲解App测试中常用的工具与技术，包括模拟器、常用的adb命令，并举一反三地介绍这些技术的应用方法。
第5章：App自动化测试。主要讲解App自动化测试过程中常用的技术以及常见问题的解决方法，如Appium的常用API、多种定位方法。
第6章：接口协议抓包分析与Mock。主要介绍接口测试的价值和意义，以及接口测试的常用技术，如用于接口测试的Mock和抓包；目前行业内常用的接口测试工具的使用方法，如Postman、CURL、Charles等。
第7章：服务端接口自动化测试。主要介绍如何处理多种类型的接口请求和响应问题，以及接口自动化测试中常见的加密问题和多环境切换的问题，并提供了实战示例与解决方案。
第8章：持续集成。主要介绍持续集成在测试过程中的使用场景与Jenkins常用的操作，并结合Jenkins与自动化测试脚本，构建一套完整的持续集成体系。
感谢参与创作本书的作者，本书从内容选取、案例设计到具体内容的写作都凝聚着各位作者的智慧和努力。
本书编辑联系邮箱：zhangtao@ptpress.com.cn。
编者
软件测试是对软件进行检测和评估，以确定其是否满足所需结果的过程和方法。它是在规定的条件下对程序进行操作，发现程序的错误，从而衡量软件质量，并对其是否满足设计要求进行评估的过程。
与计算机系统操作有关的计算机程序、文档及数据都可称为软件。
程序就是可以被“操作”的产品，例如，WPS、微信、QQ、网页等，这些都是程序；需求文档、设计文档、用户手册这些都属于文档，页面中展示的或用户输入的内容这些都是数据。
程序、文档、数据这3个结合起来，就是完整的软件。
软件开发流程的演变其实就是软件开发模型的演变过程。
软件开发模型是在软件开发中逐渐被总结的程序员的很多经验或方法，这些经验或方法经过提炼汇总就变成了软件开发模型。例如，最开始普及的是瀑布模型，后来出现了敏捷开发模型，现在很流行的是DevOps模型。
下面，分别介绍一下这几种软件开发模型。
瀑布的意思是从山壁上或河床突然降落的地方流下的水，远看好像挂着的布匹。通俗理解就是水从上向下流形成的一个水流动的形式。软件开发中的瀑布模型也是一样，开发步骤像水流一样从上往下一步一步进行。瀑布模型如图1-1所示。
图1-1
（1）需求分析
在系统开发之前，我们首先要做的就是需求分析。
需求分析中的需求文档的内容是产品人员从用户那里了解到的需要解决的问题。产品人员了解清楚用户想要解决的问题之后，再把了解的内容细化成为一个文档——需求文档。需求文档中清楚地列出了系统大致拥有的大功能模块，大功能模块中又包括哪些小功能模块，并且还列出了系统具有的界面和界面功能。有了这个需求文档，系统的UI界面、功能就都确定下来了。
（2）设计
完成需求分析之后就开始做系统设计。设计包括两个方面。
1）界面设计：UI设计师根据需求文档设计出前端界面的一个设计稿。
2）程序设计：程序开发人员设计系统的基本处理流程、模块的划分、接口的规范等。
（3）编码
在软件编码阶段，程序开发人员会根据设计好的方案，通过代码实现一个系统。
（4）实现
实现就是开发人员用代码实现了需求文档里提出的系统功能。
（5）测试
开发人员把系统实现之后，软件测试人员就可以介入了。这也是瀑布模型的流程：先有系统代码，再做软件测试。
（6）发布与维护
软件测试工作完成之后，发布系统上线运行，并继续对系统进行维护。
（7）瀑布模型的特点
在瀑布模型中，软件开发人员的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，并对当前活动的工作结果进行验证。
瀑布模型的优点很明显，软件开发的各个阶段比较清晰，强调早期计划及需求调查，比较适合需求稳定的产品开发。
但是，因为软件开发人员的活动是线性的，所以依照此模型开发的系统的早期错误可能要等到开发后期的阶段才能被发现，这增加了开发的风险。
为了解决瀑布模型的这个问题，后面又慢慢发展出来了别的开发模型。
敏捷开发模型是一种从20世纪90年代开始逐渐引起广泛关注的一种新型软件开发方法。这种开发模型更适用于产品需求频繁变化和产品需要快速开发的场景。
常见的敏捷开发模型有XP和Scrum，下面分别介绍这两种开发模型。
（1）XP（Extreme Programming，极限编程）
XP是一种近似螺旋式的开发方法（模型）。它是把复杂的开发周期分解为一个个相对比较简单的小周期，在每一个小周期里面，项目开发人员和客户都可以非常清楚地了解进度、变化、待解决的问题和潜在的困难等，而且可以根据实际情况及时地调整开发过程，如图1-2所示。
图1-2
在图1-2中可以看出，极限编程是从3个维度来组织开发流程的。
1）编程方法
首先是编程方法这个维度。这个维度对开发人员的开发方法做出了规定。
● 简单设计：XP要求开发人员用最简单的办法实现每个小需求。一些设计只要能满足客户在当下的需求就可以了，不需做更高深的设计，这些设计都可在后续的开发过程中不断地调整和优化。
● 结对编程：指代码由两个开发人员一起完成。一个人主要考虑编码细节，另外一个人主要关注整体结构，不断地对第一个人开发的代码进行评审。
● 测试驱动开发：测试驱动开发的基本思想就是在开发功能代码之前，先编写测试代码。测试代码编写好之后，再去编写可以通过测试代码验证的功能代码。这样就可以让测试来驱动整个开发过程。这样做，有助于开发人员编写简洁、可用和高质量的代码，代码会具有很高的灵活性和健壮性。
● 重构：XP强调简单的设计，但简单的设计既不是没有任何结构的流水，也不是缺乏重用性的程序设计。XP提倡重构代码，主要是努力减少程序和设计中重复出现的部分，增强程序和设计的可重用性。
2）小组实践
小组实践是从团队合作的维度来规定开发人员的工作方法。
● 代码集体所有：代码集体所有意味着每个人都对系统所有的代码负责。反过来又意味着每个人都可以更改代码的任意部分。
● 编码标准：既然大家都可修改代码，那开发小组中的所有人都需要遵循一个统一的编程标准，这样所有的代码看起来好像是一个人编写的。因为有了统一的编程标准，小组中的每个程序员更加容易读懂其他人编写的代码，这是实现代码集体所有的重要前提之一。
● 稳定高速的步伐：可以把项目看作是马拉松长跑，而不是全速短跑。这需要团队成员保持长期稳定的工作节奏。
● 持续集成：集成就是要把团队中开发人员的代码合并到一起。团队中的开发人员需要经常把他们开发的程序集成在一起，每次集成都通过自动化的构建方式（其中还包括了自动化测试）来验证，这样能尽快发现系统代码集成后出现的错误。
● 隐喻：为了帮助开发团队中的每个人清楚地理解要完成的客户需求、要开发的系统功能，团队往往需要用很多形象的比喻来描述系统或功能模块是怎样工作的。例如，对于一个搜索引擎，它的系统隐喻可能是：一大群蜘蛛，在网上四处寻找要捕捉的东西，然后把东西带回家。
3）交付和发布
交付是把产品交到客户手中；发布是把产品上线运行，让用户可以使用系统。总体来说，交付和发布都是把产品交给用户，并可以上线使用。整个交付的过程会涉及4个方面。
● 小规模发布：规模有多小呢？就是系统每个迭代用时1～3周。在每个迭代结束的时候，团队交付可运行的、经过测试的功能，这些功能可以立即被使用。
● 计划游戏：预测在交付日期前可以完成多少工作，确定现在和下一步该做些什么工作。不断地回答这两个问题，就是直接服务于系统开发的实施及调整。
● 完整的团队：每一个项目中的贡献者都是“团队”完整的一部分。这个队伍是围绕着一个需要每天和队伍共同工作的商业代表——“客户”，建立起来的。
● 现场客户：在XP中，“客户”并不是为系统付账的人，而是真正使用该系统的人。XP认为客户应该时刻在开发现场并提出问题。
从XP开发模型可以看出，开发人员和客户在系统开发中占据主导地位。测试人员的工作基本都是通过自动化测试的方式进行的。例如，编码过程中的测试驱动开发这个环节和持续集成中都包含了自动化测试。总体而言，这个开发模型对开发人员和测试人员的要求都是非常高的，团队里的人必须都具有非常高的技术水平，这样才能使这个模型运转成功。
（2）Scrum
在Scrum模型里面，最基本的概念是Sprint。Sprint其实就是一个冲刺，通俗一点来说就是一个迭代周期，如图1-3所示。
图1-3
整个项目开始之前，会先有一个产品Backlog（清单）。使用产品Backlog来管理产品的需求，它是整个项目的概要文档。Backlog是一个按照商业价值排序的产品需求列表（清单），列表条目的体现形式通常为用户故事，即描述用户渴望得到系统的功能。
使用Scrum模型的团队从产品Backlog中挑选最高优先级的需求进行开发，挑选的需求在Sprint计划会议上讨论。
在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表，这个任务列表被称为Sprint Backlog。
Scrum中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的建议时间长度是2～4周。
在每个迭代周期中，使用Scrum模型的团队会举行每日站会。在每日站会上团队检验Sprint目标的进展，做出调整，从而优化次日的工作。
每个迭代周期结束时，使用Scrum模型的团队将递交潜在可交付的产品增量。
在每个迭代周期最后，团队需要召开一次Sprint评审会议，会上团队的人员向产品负责人和利益相关方展示已完成的功能。
Sprint评审会议结束之后，下一个Sprint计划会议之前，需要召开Sprint回顾会议。回顾会议的目的是：在Sprint过程中，回顾一下哪些地方执行得很好，哪些地方执行得不好，团队可以做哪些改进。
整个Scrum模型的工作流程中，每一个Sprint也是一个迭代周期，其实也是一个小的瀑布。每个迭代周期都会完成一个需求分析—设计—编码—测试—上线这样的流程。
DevOps（Dev和Ops的组合词）涉及软件整个开发生命周期中的各个阶段。
DevOps是一个非常关注开发（Dev）人员、运维（Ops）人员，以及测试人员之间沟通合作的开发模型。DevOps是通过自动化方式完成软件测试交付流程的，以便让构建、测试、发布软件能够更加地快捷、频繁和可靠地进行。
它的出现满足了现在的项目需要更加快速地上线并且每天都能上线新功能的需求。若在项目中用敏捷开发模型，项目上线新功能最快也需要一周的时间，满足不了每天都可以上线新功能的需求。所以，为了能够更加快捷地上线新功能，开发、测试和运维工作必须紧密合作。DevOps更适合用在项目中需求频繁变化，开发、测试、运维都需要敏捷的场景，如图1-4所示。
图1-4
DevOps是有生命周期的，下面介绍一下DevOps生命周期中包含了哪些阶段。
（1）持续开发
这是DevOps生命周期中软件不断被开发的阶段。与瀑布模型不同的是，软件可交付成果被分配在多个任务节点，目的是在较短的时间内开发并交付系统功能。
DevOps生命周期中软件不断被开发的阶段包括计划阶段、编码阶段和构建阶段。
1）计划阶段：可以使用一些项目管理工具，如JIRA来管理整个项目。
2）编码阶段：可以使用Git或者SVN来维护不同版本的代码。
3）构建阶段：使用打包工具，如Maven，把代码打包到可执行文件中。
（2）持续测试
在这个阶段，程序员开发出来的软件会被持续地测试。
对于持续测试，可以使用一些自动化测试工具实施，如Selenium、Appium。Selenium是做Web自动化测试的工具，Appium是做App自动化测试的工具。自动化测试的工具还需要配合测试框架一起使用，如Java中的TestNG、JUnit，Python中的unittest、pytest。有了这些自动化测试的工具，就可以持续地对开发出来的软件进行测试了。
（3）持续集成（CI）
一旦新提交的代码测试通过，这些代码就会不断地与已有代码进行集成，这就是持续集成。
这个时候可以使用Jenkins，它是现在流行的持续集成工具。使用Jenkins，可以从Git 库中提取最新的代码，并生成一个构建任务，最终可以把程序代码部署到测试环境或生产服务器中。
还可以把Jenkins设置成：发现Git库里有新提交的代码，就自动触发新构建任务；我们也可以单击Jenkins的“构建”按钮手动触发一个新的构建任务。有了Jenkins这款利器，开发人员就可以非常方便地完成代码的持续集成工作。
（4）持续部署
持续集成完成之后，就可以直接把代码部署到实际环境中。在这个阶段，需要保证只有通过了持续测试的正确代码才能被部署到服务器上。
因为，如果系统上线了新功能，就会有更多用户使用新功能。这样的话，为了不让系统宕机，运维人员可能还需要扩展服务器来容纳更多用户。持续部署是通过配置管理工具快速、频繁地执行部署任务实现的。这让产品的新功能可以更快地和用户见面，打通了开发、测试到上线的一个快速通道。
在这个阶段，容器化工具Docker也发挥着重要作用。它可以帮助保持各种运行环境是一致的，如测试环境、生产环境等，因为运行环境的不同也可能会导致一些系统Bug的出现。
（5）持续监控
系统上线之后，就到了持续监控的阶段。这是DevOps生命周期中非常关键的阶段。通过线上的监控可以帮助我们提高软件的质量，监控软件的性能。
这里也需要运营团队的参与，他们也会监控用户在使用产品过程中出现的一些“错误行为”，用以系统的进一步优化。
在这个阶段，可以使用ELK Stack，这是一个收集线上数据，并分析、展示数据的平台，通过这个工具可以自动地收集用户使用系统的动作和产品的一些线上的badcase（坏案例）数据，通过分析这些数据，可以为产品将来的发展方向做出指导。
深入了解被测系统的架构与数据流，有助于理解业务逻辑、梳理业务用例，以及促进部门间协同。
更深入地理解业务逻辑是指：要分析公司是做什么的？公司重要的商务决策是什么？公司内部数据流是怎么运行的？有哪些常见的业务场景。
更好地梳理业务用例的本质是：在测试过程中，测试人员可以更全面地测试公司的业务。例如，复杂的电商系统或者保险行业的管理系统，内部涉及的业务流以及包括的用户种类都很复杂、多样，测试人员不理解其中的业务逻辑和数据，就很难编写出一个覆盖完整系统功能的业务测试用例。
更好地与研发、运维进行跨部门间协同是指：当产品出现问题时，研发和运维部门都会排查。作为测试部门，更要了解出现的问题并帮助研发、运维部门解决问题，这样可以加快部门间协同解决问题的速度。
下面以开源项目litemall为例，分析一下这个项目的系统架构。
litemall是一款小的网上商城应用，系统以Spring Boot作为后端，Vue结合微信小程序作为前端，同时Vue也作为移动端。
（1）系统架构
litemall系统架构如图1-5所示。
图1-5
（2）技术架构
litemall的技术架构如图1-6所示。
图1-6
Mall项目是一套电商系统，包括前台商城系统及后台管理系统，基于Spring Boot + MyBatis实现，采用Docker容器化部署。前台商城系统包含首页、商品推荐、商品搜索、商品展示、购物车、订单流程、会员中心、客户服务、帮助中心等模块。后台管理系统包含商品管理、订单管理、会员管理、促销管理、运营管理、内容管理、统计报表、财务管理、权限管理、设置等模块。
（1）系统架构
Mall系统架构如图1-7所示。
图1-7
（2）业务架构
Mall的业务架构如图1-8所示。
图1-8
通过litemall和Mall两个开源项目可以看出，这两项目的公司架构一般分为业务架构和系统架构。
（1）业务架构
1）商业模式：也是大家最关心的问题，公司使收益最大化的运作模式，例如，抖音的运作模式以及其裂变系统是怎样进行的。
2）业务数据：公司系统中包括的角色、资源和数据，例如，公司系统的账户管理中的角色有管理员、用户等，而这些角色又可以分为输出内容的人和消费内容的人。除了角色，公司系统上还有核心资源的种类及数据信息。
3）业务流程：业务数据中的角色的行为以及数据之间的集成关系。
（2）系统架构
系统架构就是要把业务架构进行落地实施，实现其中的商业模式与业务流程。
● 架构角色与技术栈：架构中的角色基本不会变，而技术栈会随着技术的发展而不断变化。其中的技术栈有：网关（Apache/Nginx/F5）、应用开发（Spring Boot/ Spring Cloud）、通信协议（Dubbo/HTTP/PB）、数据处理（Hadoop/Spark/Flink）、数据存储（Redis/MySQL/Oracle/ES）、文档存储（MongoDB/HBase/Neo4j）。
● 部署架构：架构角色的集成关系。
为快速了解公司的系统架构，可以使用统一建模语言（UML）来分析公司的系统架构。常用的编译工具有：
plantuml（推荐）、yed、draw.io、processon、visio。
下面以plantuml工具为例，设计图模型，用以分析公司系统架构。
（1）用例图：用来描述商业模式、业务角色。
（2）时序图：用来描述业务流程、调用关系。
（3）部署图：用来描述系统架构与集成关系。
（4）活动图：用来分析业务逻辑。
下面对上述设计图模型进行简单说明。
（1）用例图
使用用例图梳理商业模式、业务角色，如图 1-9所示。
图1-9
（2）部署图
使用部署图分析系统架构与集成关系，如图1-10所示。
图1-10
（3）时序图
使用时序图分析业务流程和调用关系，如图1-11所示。
图1-11
（4）活动图
使用活动图分析业务逻辑，如图1-12所示。
图1-12
需求分析是开始测试工作的第一步。产品设计人员会根据客户要求先汇总一个需求文档，然后给开发人员和测试人员进行需求宣讲。在需求宣讲中，大家一起分析需求文档中是否存在需要完善的内容。宣讲结束后，测试人员通过需求文档分析测试点并且预估测试工作的排期。
产品设计人员在做完用户需求调查之后，会根据用户需求汇总一份需求文档，需求文档中会详细描述用户所需的系统功能和功能实现的效果。
需求宣讲的过程也是对需求文档进行评审的过程。需求文档评审可以从以下角度进行。
（1）业务场景角度
1）站在使用者的角度，考虑用户使用产品时会遇到的各种情况，反观各种情况在需求文档中是否都能找到对应的描述，即用户故事。
2）根据用户故事应该能构建出简单的流程图，流程图中各种路径之间的约束关系、执行条件要有明确、合理的定义。
（2）功能点角度
1）数据约束是否全面、合理。
2）存在分支的逻辑、描述是否覆盖所有路径。
3）多状态流程、状态流转描述是否合理且完整。
4）权限描述是否明确。
在评审的时候，参与人员可以从以上几个角度进行考虑，检查产品设计人员写的需求文档是否完善。若需求文档中有不完善的地方，要提出问题并和产品设计人员、开发人员和测试人员一起讨论。最终的目标是让需求文档更合理且完整。
产品设计人员把需求文档最终完善好之后，参与人员就可以详细地去分析需求文档了。需求分析就是把不直观的需求文档简化为直观的需求。
需求分析步骤：
1）明确测试范围：把测试活动的边界确定好，系统中很多模块都是有关联的，在分析需求文档的时候，需要看新加的功能和已有的功能耦合度，考虑是否需要对关联的功能模块也进行测试。
2）明确功能点：把需求文档中的功能点列出来。
3）明确业务流程：根据业务流程图梳理。
4）明确输出结果：方便验证。
5）分析异常流程：提高系统的容错性。
6）预估测试需要的时间和资源：为测试计划的编写做好准备。
综上，为了提高需求分析能力，就需要深入地理解需求文档。
（1）熟悉业务，了解系统。任何系统都有大的业务应用背景，只有在熟悉业务的基础上才能更有效地使用系统。任何人使用系统都有一个熟悉的过程，对系统熟悉度越高，越容易发现系统问题。
（2）用客观的思考方式，站在用户的角度分析。在满足客户要求的基础上，测试人员站在业务或者系统现有实现的角度上，给产品设计人员和开发人员一些好的建议。
（3）善于总结，乐于分享。把常见的测试用例设计的误区、一些好的需求分析实例，以及需求分析习惯分享给团队其他人，这样可以集众人之所长，不断提升大家需求分析的能力。
项目管理有其特定的对象、范围和活动，着重关注成本、进度、风险和质量。项目管理参与人员还需要协调开发团队和客户的关系，协调内部各个团队之间的关系，监控项目进展情况，随时报告发现的问题并督促问题的解决。
软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对人员（People）、产品（Product）、过程（Process）和项目（Project）进行分析和管理的活动。
随着信息技术的飞速发展，软件产品的规模也越来越庞大，个人单打独斗的“作坊式”开发方式逐渐不适应企业的需要。各软件企业都在积极将软件项目管理引入开发活动中，对开发的项目实行有效的管理。
同时，随着软件开发规模及开发队伍的逐渐增大，迫切需要一种开发规范来约束每个开发人员、测试人员与支持人员的工作，用以保证项目组每个成员按约定的规则准时完成自己的工作。
软件管理的流程大致可以分为6个阶段，如图1-13所示。
图1-13
（1）需求阶段
1）项目经理：负责建立项目目录，分析项目所需资源，评估项目风险，预估项目的完成周期等工作，并输出一个包含大致时间规划的项目计划表。
2）产品经理：需要完成收集与整理需求、环境分析等工作，并输出一个需求文档。
3）研发人员：要参与到需求分析和环境分析工作中。
4）测试人员：要参与到需求分析和环境分析工作中。
（2）设计阶段
1）项目经理：负责监控项目进度，组织安排每阶段的评审，分解任务到人，细化项目计划等工作，并输出一个涉及各功能模块的项目计划表。
2）产品经理：需要完成系统功能设计，输出系统说明书。
3）研发人员：需要完成系统功能技术设计和数据库设计，输出概要设计文档和详细设计文档。
4）测试人员：需要组织测试计划评审，输出一份测试计划表。
（3）开发/单元测试阶段
1）项目经理：负责监控项目进度，调整人员安排，跟踪、解决技术难点等工作，并输出更新进度后的项目计划表和项目进度报告。
2）产品经理：参与项目需求细节完善的沟通。
3）研发人员：需要完成项目具体功能开发，组织代码审查和单元测试等工作，工作完成后输出功能代码和单元测试代码。
4）测试人员：需要完成测试用例编写和组织测试用例评审等工作，工作完成后输出测试用例。
（4）集成测试阶段
1）项目经理：负责监控项目进度，跟踪、解决技术难点等工作，并输出项目进度报告。
2）产品经理：参与项目需求细节完善的沟通和Bug修改方案的制定。
3）研发人员：需要完成集成测试、Bug修改等工作，工作完成后输出集成测试报告、部署测试环境。
4）测试人员：支持研发人员进行集成测试，准备测试数据。
（5）系统测试阶段
1）项目经理：负责分配Bug修改与跟踪、解决技术难点等工作，并输出项目进度报告。
2）产品经理：参与项目需求细节完善的沟通和Bug修改方案的制定。
3）研发人员：支持测试活动，修改Bug。
4）测试人员：需要完成测试环境搭建、补充测试数据、功能测试、自动化测试等工作，工作完成后输出系统测试报告和缺陷报告。
软件项目管理的方法如图1-14所示。
图1-14
（1）制订项目计划
对于大项目，一般在项目启动或者立项时参与人员会制订一份完善的项目总体计划。对于小项目或者项目版本更新，因为开发完成周期比较短，一般一个月即可完工，所以直接制订简单的日程计划进行跟踪即可。
（2）执行该计划并监控跟踪管理
项目计划制订并得到项目组评审确认后，项目组要按照计划中安排的任务、时间和人员去执行。项目管理人员需要对计划执行情况进行监控，例如，每周检查任务完成情况，每个“里程碑”时间点检查这期间内所有任务完成情况。监控的结果会在项目日程计划中体现新任务的完成进度，以便在非“里程碑”任务时间点时可以查看项目进度。必要时每周要召开项目例会并形成项目周报。每个“里程碑”任务结束时，要召开“里程碑”任务总结会议。
（3）项目风险应对与问题解决
项目经理通过对项目的周跟踪、“里程碑”跟踪活动，会发现项目进展中出现的问题及潜在问题，以及已经影响或将要影响项目的问题。项目组需要跟踪和分析项目数据，对这些问题和风险进行识别、分析并给出相应的应对措施。
对问题解决或风险缓解措施的执行，项目经理须进行监督和控制，持续跟踪问题和风险状态变化，确保措施有效执行，直至问题解决、风险解除。对问题与风险的识别、解决和跟踪等信息，项目经理应记录在项目周报和“里程碑”总结报告的问题跟踪表或者风险跟踪表中。
（4）项目收尾
项目收尾是项目最后一个重要的工作环节，包括保存项目资产，移交工作责任、进行项目总结与评价，并最终释放项目资源等工作。
（1）与产品经理沟通
由于产品经理的岗位职责就是设计产品功能、输出产品需求文档，所以，测试人员和产品经理沟通的阶段有以下4个：
● 需求评审会；
● 分析需求阶段；
● 测试用例编写阶段；
● 测试过程中。
总之，只要涉及项目需求方面的问题，测试人员都需要和产品经理进行深入沟通，这样才可以深入完整地理解项目业务的逻辑和项目的需求，最终交出去的测试后的软件才是符合用户需求的。
（2）与研发人员沟通
● 分析需求阶段
● 测试用例编写阶段
● 测试过程中
● 线上监控发现Bug时
在需求分析和测试用例编写阶段，测试人员如果遇到项目中一些需求的实现手段和逻辑不是很明确的话，就需要和研发人员进一步沟通。
在测试过程中，测试人员如果发现Bug也要和研发人员进行沟通，接下来还要协助研究人员完成复现Bug，提交日志，验证Bug等工作。
（3）项目上下游配合测试
现在公司中的一个项目往往会涉及多个团队来完成，例如服务端团队、客户端团队、数据库端团队等。同样在项目测试的时候，需要多个团队的测试人员合作（联调），这样进行测试会更加容易，并且可以更好地发现项目中存在的问题。
在这种项目上下游配合测试的时候，为了使团队合作更加顺畅，参与人员需要注意以下3个方面。
1）测试计划沟通：项目上下游模块参与人员可沟通各自的测试计划安排、测试范围、测试重要场景、跨团队测试数据的构造、配合的方式，把团队间的影响降到最低。
2）环境对接：了解相互之间提供的接口调用问题，各自提供的接口是否清楚，各自提供的接口是否满足需求等，确保联调环境的可用性。
3）熟悉业务：了解对方的业务、权限等，避免影响测试进度。
JIRA是目前比较流行的测试流程管理工具，它的定制性非常强，所以很多大型企业使用。JIRA可以自定义流程、界面和字段。通过自定义的方式，我们就能让整个工具更贴合公司的业务。并且JIRA提供的各种插件也非常丰富，可以满足公司的各种业务需求。
测试中的测试用例和Bug都可以用JIRA进行跟踪管理。
JIRA中有一些基本的概念需要在使用前了解清楚。
Project（项目），开发一个App是一个项目，开发一个微信小程序也是一个项目。项目管理范畴内可以被看作“项目”的都是JIRA中的项目。
Issue（问题）是JIRA的核心。项目是由多个需要解决的问题组成的。管理不同的问题，可以用不同的问题类型。
JIRA里有一些预制好的问题类型，如Task（任务）、Sub-Task（子任务），可以直接选择使用这些问题类型，也可以自己创建新的问题类型。
问题包含属性，如名称、详细描述、提交人、提交时间、优先级、状态等。属性就是JIRA中的Field（字段）。待测的系统本身定义了一些常用的字段，用户也可以创建一些自定义的字段。
Issue也有不同的状态，如待办、进行中、已完成。Workflow（工作流）就是用来定义Issue的状态以及状态间的流转的。
接下来介绍在JIRA中如何管理测试用例。
（1）创建测试用例管理项目
在JIRA中创建一个流程管理类型的项目，项目被命名为【测试用例管理项目】。测试用例可以在这个项目中进行管理。流程管理如图1-15所示。
图1-15
（2）新建测试用例
在【测试用例管理项目】项目中创建一个新的Issue。在JIRA界面上单击【新建】按钮，可以看到新建测试用例的界面（创建问题界面），在界面中可以填写测试用例的内容。
例如填写一条最基本的UI验证用例，如图1-16所示。
图1-16
（3）查看并编辑测试用例
在JIRA界面上单击【编辑】按钮，进入测试用例编辑页面修改测试用例的内容，如图1-17所示。
图1-17
（4）查看用例状态转换
执行测试用例时，可以单击JIRA界面上的“状态转换”按钮，切换测试用例的不同状态。
通过这些状态，我们可以对测试用例进行管理。如果在执行测试用例的时候，执行后得到的实际结果与预期结果不一致，这时就表明发现了系统Bug，就需要把Bug也提到JIRA中进行管理。
要管理Bug，同样也需要先创建一个项目。创建好项目之后，Bug可以被提交到这个项目中进行管理。
我们是通过执行测试用例发现Bug的，可以通过测试用例管理的“创建链接问题”项来管理Bug，如图1-18所示。
图1-18
可以通过设置字段类型对Bug进行概要性描述，如图1-19所示。
图1-19
Bug管理项目创建好之后，可以通过编辑问题（Bug Issue）对Bug进行详细描述，如图1-20所示。
图1-20
软件测试是软件质量保证流程中的关键环节。通过软件测试越早发现软件中存在的问题（Bug），修复软件中的问题的成本就越低，软件质量也就越高，软件发布后的维护费用越低。
为了能更好地保障软件质量，在软件测试的实践中，测试人员慢慢形成了一些流程用来达到保障软件质量的目标。下面介绍一下常见的测试流程。
常见的测试流程包含了如图1-21所示的步骤。
图1-21
下面分别介绍每一个流程的含义。
（1）单元测试
单元测试是对软件中的基本组成单位进行的软件测试。目的是检验软件基本组成单位的正确性。
1）测试阶段：编码完成后。
2）测试对象：最小模块。
3）测试人员：开发人员。
4）测试依据：代码、注释、详细的设计文档。
5）测试方法：白盒测试。
（2）集成测试
集成测试是在软件系统集成过程中进行的测试，目的是检查软件模块之间的接口是否正确。
1）测试阶段：单元测试完成后。
2）测试对象：模块间的接口。
3）测试人员：开发人员。
4）测试依据：单元测试模块、概要设计文档。
5）测试方法：黑盒与白盒结合。
（3）冒烟测试
冒烟测试是在软件开发过程中针对软件基本功能的一种快速验证，是对软件基本功能进行确认验证的手段。
1）测试阶段：提测后。
2）测试对象：整个系统。
3）测试人员：测试人员。
4）测试依据：冒烟测试用例。
5）测试方法：黑盒测试（手工或自动化测试方式）。
（4）系统测试
系统测试是对已经集成好的软件系统进行彻底的测试，验证软件系统的正确性和性能等是否满足其规约所指定的要求。
1）测试阶段：冒烟测试通过后。
2）测试对象：整个系统。
3）测试人员：测试人员。
4）测试依据：需求文档、测试方案、测试用例。
5）测试方法：黑盒测试。
一般系统的主要测试工作都集中在系统测试阶段。根据不同的系统，所进行的测试种类很多。在系统测试中，又包括如下测试种类。
1）功能测试：功能测试是对系统的各项功能进行验证，以检查这些功能是否满足需求。
2）性能测试：性能测试是通过自动化测试工具模拟多种正常、峰值及异常负载情况对系统的各项性能指标进行的测试。
3）安全测试：安全测试检查系统对非法入侵的防范能力。
4）兼容性测试：兼容性测试主要是测试系统在不同的软硬件环境下是否能够正常地运行。
（5）验收测试
验收测试是部署软件之前的最后一种测试。验收测试的目的是确保软件准备就绪，向软件购买方展示该软件满足其需求。
1）测试阶段：发布前。
2）测试对象：整个系统。
3）测试人员：用户/需求方。
4）测试依据：需求文档、验收标准。
5）测试方法：黑盒测试。
软件测试模型用于定义软件测试的流程和方法。众所周知，软件开发的质量决定了软件的质量，同样地，测试的质量将直接影响测试结果的准确性和有效性。软件测试和软件开发一样，都遵循软件工程原理，遵循管理学原理。
随着测试管理的发展，软件测试专家通过实践总结出了很多很好的测试模型。这些模型是对测试活动的抽象、概括，并与开发活动有机地结合起来，是测试管理的重要参考依据。下面介绍几种常见的测试模型。
（1）V模型
V模型是开发模型中瀑布模型的一种改进。瀑布模型将软件生命周期划分为计划、分析、设计、编码、测试和维护这6个阶段。由于早期的系统错误可能要等到开发后期的测试阶段才能发现，所以使用瀑布模型进行开发很可能给系统造成严重的后果。
V模型改进了瀑布模型的缺点，在软件开发时期，开发活动和测试活动几乎同时开始，在开发活动进行的时候，测试活动开始进行相应的文档准备工作，从而提高软件开发的效率和效果，如图1-22所示。
图1-22
V模型的优点是明确地标注了测试过程中存在着哪些不同的测试类型，并且可以清楚地表达测试和开发各阶段的对应关系。
但是，它也有一些缺点，例如，容易使人误解，测试只是软件开发完成后的工作。而且由于它的顺序性，当编码完成之后，正式进入测试时，我们发现的一些Bug可能不容易找到其产生的根源，而且代码修改起来也很困难。在实际工作中，因为用户对系统的需求变更较快，所以使用V模型可能导致要重复变更需求、设计、编码、测试，返工量会比较大。
（2）W模型
W模型从V模型演化过来，相对于V模型，在软件各开发阶段中W模型增加了应同步进行的验证和确认环节。
W模型由两个V字型模型组成，分别代表测试与开发过程，图1-23中明确表示出了测试与开发的并行关系。测试与开发是同步进行的，有利于尽早、全面地发现系统中的问题。
图1-23
在W模型中测试伴随着整个软件开发周期，而且测试的对象不仅是程序，需求、设计等也需要测试。
系统使用W模型有利于尽早、全面地发现系统中的问题，例如，需求分析完成后，测试人员就立即参与到对需求的验证和确认工作中，以便尽早地找出需求中的缺陷所在。
对需求的测试也有利于及时了解项目的测试难度和测试风险，尽早制定应对措施，这将显著减少总体测试时间，加快项目进度。
使用W模型的优点很明显。首先测试与软件开发同步进行，而且测试的对象不仅仅是程序，还包括需求和设计。这样可以尽早发现软件缺陷，降低软件开发的成本。
但是W模型还是有一些缺点，例如，开发和测试依然是线性的关系，项目的需求变更和调整依然不方便。而且如果前期工作流程中没有产生文档，根本无法执行W模型。
（3）H模型
相对于V模型和W模型，H模型将测试完全独立出来，形成一个完全独立的工作，将测试准备工作和测试执行工作清晰地体现出来，如图1-24所示。
图1-24
图1-24仅仅演示了在软件整个生产周期中某个层次上的一次测试——“微循环”。图1-24中标注的其他流程可以是任意的开发流程，例如，设计流程或编码流程。测试流程是灵活的，只要满足测试条件，并且完成测试准备活动，测试就可以进行了。
H模型中包含了如下概念。
1）测试准备：所有测试活动的准备，判断是否达到测试就绪点。
2）测试就绪点：测试准入准则，开始执行测试的条件。
3）测试执行：具体的执行测试的程序。
4）其他流程：设计流程或编码流程。
H模型揭示了软件测试中除测试执行外，还有很多其他工作。它让测试活动完全独立贯穿于整个软件生命周期，并与其他流程并发进行。在H模型中，软件测试活动可以尽早准备、尽早执行，具有很强的灵活性。而且软件测试可以根据被测对象的不同而分层次、分阶段、分次序执行，同时也是可以被迭代的。
但是H模型对于项目管理要求很高，需要定义清晰的规则和管理制度，否则测试过程将很难管理和控制。而且对于测试人员的技能要求也很高，因为H模型要求测试人员对迭代规模有控制能力，迭代的规模不能太大也不能太小。在H模型中，测试就绪点的分析也比较困难，在测试过程中，测试人员并不知道测试准备到什么程度是合适的？就绪点在哪？就绪点标准是什么？这会给后续的测试执行带来很大的困难。
（4）3种测试模型对比
上面介绍的3种测试模型使用场景会有一些不同。
● V模型适用于中小企业。
● W模型适用于中大型企业。
● H模型对测试人员的技能要求非常高，使用比较少。
系统测试工作流程如图1-25所示。
图1-25
下面分别解释一下图1-25所示的每一步的具体含义。
（1）项目计划
这是描述软件测试目的、范围、方法和重点等内容的文档。
（2）需求分析
测试工程师参与需求分析，可以增加对需求的了解，减少后期与产品和开发人员的沟通成本，节省时间。早期确定测试用例的编写思路可以为测试打好基础。在需求分析的过程中测试人员可以获取一些测试数据，有助于测试用例的设计。而且在需求分析过程中可以发现需求不合理的地方，降低后期的测试成本。
（3）测试设计
测试设计是指把概括的测试目标转化为具体的测试用例的一系列活动。测试设计时要结合需求、系统架构、设计和接口说明等文档评审测试依据。通过对测试项、规格说明、测试对象行为和结构的分析，识别测试条件并确定测试优先级；根据分析的内容设计测试用例，同时确定测试条件和测试用例所需的必要的测试数据。
（4）用例评审
测试用例评审一般进行两轮。一轮是组内评审，组内人员会评审测试用例是否完全覆盖了需求，并提出一些修改意见。二轮评审需要和产品经理、研发人员一起进行，产品经理和研发人员会从不同角度对测试用例进行一些补充。测试用例评审并且把评审中的建议补充完毕之后，测试用例才最终被设计完毕，进入等待执行的状态。
（5）测试执行
开发人员完成需求的开发之后会提测，也就是把可以测试的产品交付给测试人员进行测试。提测后需要先执行冒烟测试，冒烟测试通过之后正式进入测试执行阶段。
开始执行测试之前要确认已经正确搭建了测试环境。测试环境没有问题后，就根据计划执行，如通过手工或使用测试工具来执行测试用例。执行测试过程中需要记录测试执行的结果，以及被测软件、测试工具的标识和版本，将测试得到的实际结果和预期结果进行比较，得出实际结果和预期结果之间的差异，作为Bug上报，并对Bug进行分析以确定引起差异的原因。Bug修正后，重新对系统进行测试。
（6）Bug管理
软件缺陷（Bug）是一种泛称，它可以指功能的错误，也可以指性能低下、易用性差等。
（7）发布维护
监控上线后的产品，若发现产品有问题应及时修复。
Bug的管理也需要遵循一定的流程，基本流程如图1-26所示。
图1-26
（1）提交Bug
在提交一个Bug的时候，测试人员先尽量描述这个Bug的属性：重现环境、类型、等级、优先级，以及详细的重现步骤、结果与期望等。在提交一个问题（Bug）之前首先应该保证，这个Bug是没有被提交过的，以免造成重复提交Bug。
（2）指派Bug
有些公司的测试部门与开发部门相互独立，那么测试人员就不好确定自己测试的系统模块是由哪位开发人员负责的，在这种情况下，测试人员统一把测出的问题指派给项目组长或经理，由项目组长（或经理）对问题进行确认后再次分配给相应的开发人员去解决。有些测试人员是和研发团队在一起工作的，这时，测试人员会对某开发人员负责的模块非常清楚，就可以将测出的问题直接指派给相应的开发人员。
（3）确认Bug
开发人员接到测试人员提交的一个Bug，首先对其进行分析与重现，如果对其进行分析后发现不是Bug（可能由于测试人员不了解需求）或无法对此Bug进行重现，那么就需要将此问题返回给测试人员再次进行回归测试，并注明返回Bug的原因；如果确认为是Bug，则需要对其进行处理。
（4）判断是否推迟处理
在处理问题（Bug）之后，开发人员还需要对Bug进行一次判断，决定是否需要推迟处理此Bug。有些Bug已经被确认了是需要解决的问题，由于其可能在极端情况下才会出现，或处理此Bug需要对系统架构进行改动，或其优先级非常低，所以暂时不需要对此Bug进行处理或到下个系统版本再修复此Bug。
（5）遗留Bug
对于推迟处理的Bug可以暂时进行遗留。一般遗留的Bug需要经过项目经理与测试经理协商后才可以决定接下来要做的工作。
（6）处理Bug
开发人员在确认完一个Bug需要处理时，就对其进行处理。
（7）回归Bug
确认不是一个Bug：对于测试人员提交的一个Bug，开发人员处理后确认不是Bug或无法重现此Bug，就直接把此Bug转交给测试人员回归测试。测试人员再次确认此Bug，如果真如开发人员所说，则将此Bug取消；如果非开发人员所说，是由于对Bug描述模糊或其他原因造成未重现Bug，则再次注明Bug出现的原因并转给开发人员。
确认修复Bug：测试人员对开发人员修复的Bug再次进行确认，确认此Bug已处理，则取消此Bug；确认此Bug还存在，将Bug再次转给开发人员进行处理。
确认遗留Bug：有计划地对遗留的Bug进行确认，有些遗留Bug随着时间的推移、版本的更新或已经不存在了，对这类Bug应该及时取消。有些遗留Bug被取消后依然存在且需要紧急处理，对于这类Bug应该及时交给开发人员处理。
（8）关闭Bug
对于已经修复的Bug进行关闭，这也是一个Bug的最后一个状态。
传统的测试流程就是测试人员接到项目后参与需求评审，然后根据需求文档写测试用例和准备测试脚本，等开发人员提测之后正式开始测试、提交Bug、回归测试，测试通过后项目开发工作就结束了，运维人员把项目上线运行。
这样的流程看似没什么问题，但缺点是测试过程是在一定时间间隔内发生的，测试人员必须等待产品完全构建后才能开始找错误和软件故障。“等待代码”成为测试人员加快测试进度的瓶颈。
而测试左移以及测试右移能够让测试人员拥有更多的主动权，有更充足的时间进行测试，同时不会像之前因为测试质量差使系统延期上线，并且系统质量也得到保证。
不管是测试左移还是测试右移都是为保证产品质量服务的。不要把提测认为是测试活动的开始，上线是测试活动的结束，更不要认为质量只是测试人员需要关注的。
（1）测试左移
测试左移是系统测试工作向测试之前的开发阶段移动。
测试左移的原则是支持测试团队在软件开发周期早期和所有干系人合作。这样是为了使测试人员在清晰地理解需求后，高效地设计出测试用例，用这些测试用例让软件“快速失败”，进一步促使开发团队更早地修改系统中所有的Bug。
测试左移聚焦于使测试人员在项目的全部或最重要的实施阶段参与进来，让测试人员把工作焦点从发现Bug转移到预防Bug上。
测试左移为测试人员提供了早于开发人员设计测试用例的机会，也促使开发人员根据这些测试用例去开发软件，以充分保证系统功能满足用户需求。
（2）测试右移
测试右移是系统测试工作向产品发布之后的阶段移动。是产品上线之后进行的一些测试活动。测试右移是测试人员在生产环境中做测试监控，监控线上产品的性能和可用率，一旦线上产品发生任何问题，测试人员可尽快反映问题，提前解决问题，保证产品给用户良好的体验。
软件测试是软件开发的一个重要组成部分，贯穿于整个软件开发的生命周期，是对软件产品（包括阶段性产品）进行验证和确认的活动。其目的是尽快、尽早地发现软件产品中所存在的各种问题，以及产品与用户需求、预先定义的不一致性地方。检查软件产品中可能存在的Bug，并编写缺陷报告，交给开发人员修改。软件测试人员的基本目标是发现软件中的错误。
软件测试技术相当于是软件测试人员的武器。作为软件测试人员，必须要清楚了解可以通过哪些手段去保障产品的质量，只有知道了这些，才能更好地完成软件测试工作。
软件测试的分类一般按照下面的这些维度去划分。
（1）按开发阶段分类
● 单元测试
● 集成测试
● 冒烟测试
● 系统测试
● 验收测试
（2）按软件测试实施组织分类
1）α测试：非正式验收测试。
2）β测试：内测后的公测。
（3）按软件测试执行方式分类
1）静态测试：不启动被测对象的软件测试，例如，代码走读、代码评审、文档评审、需求评审等。
2）动态测试：启动被测试对象的软件测试，例如，白盒测试、黑盒测试等。
（4）按是否查看代码分类
1）黑盒测试：指的是把被测的软件当作黑盒子，不关心盒子里面的结构是怎样的，只关心软件的输入数据和输出结果。
2）白盒测试：指的是把盒子盖子打开，去研究里面的源代码和程序运行逻辑。
（5）按是否手工执行分类
1）手工测试：手工一个一个地执行测试用例，通过键盘/鼠标等设备输入一些参数，查看程序返回结果是否符合预期结果，通常用于黑盒测试或系统测试阶段。
2）自动化测试：把以手工为驱动的测试行为转化为机器执行测试的一种自动化执行活动。
（6）按测试对象分类
1）性能测试：检查系统是否满足需求规格说明书中规定的性能。
2）安全测试：用于对各种攻击手段的测试，例如，SQL注入、XSS等。
3）兼容性测试：验证软件和硬件之间是否能够配合且发挥很好的工作效率，软件
和硬件之间是否会有影响从而导致系统的崩溃。
4）文档测试：测试软件产品中的各类文档。
5）易用性测试：用户体验测试。
6）业务测试：测试人员将系统的各个模块串接起来运行、模拟真实用户实际的工
作流程，验证按需求定义的功能是否满足用户要求所进行的软件测试。
7）界面测试：也称为UI测试，测试用户界面的功能模块的布局是否合理，整体风格是否一致，各个控件的放置位置是否符合客户的使用习惯，还要测试操作界面的操作便捷性、页面元素的可用性、界面的文字是否正确、元素命名是否统一、页面是否美观、文字和图片组合是否完美。
8）安装测试：测试程序的安装、卸载。
（7）其他分类
1）回归测试：修改了旧代码后，重新对修改后的程序执行测试以确认修改后的程
序没有引入新的错误或导致其他代码产生错误。
2）随机测试：指软件测试中的所有输入数据都是随机生成的，其目的是模拟用户
的真实操作，并发现一些边缘性的错误。
3）探索性测试：“试”是一种测试思维，探索性测试没有很多实际的测试方法、技术和工具，但却是所有测试人员都应该掌握的一种测试思维，探索性测试强调测试人员的主观能动性，抛弃繁杂的测试计划和测试用例设计过程，强调在碰到问题时及时改变测试策略。
黑盒测试又称功能测试、数据驱动测试或基于需求规格说明书的功能测试。该类测试注重于软件的功能。
采用这种软件测试方法，测试工程师把测试对象看作一个黑盒子，完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求文档，检查程序的功能是否符合用户需求。测试工程师无需了解程序代码的内部构造，完全模拟软件产品的最终用户去使用该软件，检查软件产品是否达到了用户的要求。
黑盒测试方法能够更好、更真实地从用户角度考察被测系统功能的实现情况。在软件测试的各个阶段，如单元测试、集成测试、系统测试及验收测试等阶段中，黑盒测试都发挥着重要作用，尤其在系统测试和确认测试中，其作用是其他软件测试方法无法取代的。
白盒测试又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。测试人员用白盒测试可以全面了解程序内部逻辑结构、对所有逻辑路径进行测试。
白盒测试常用的方法有代码检查法、静态结构分析法、静态质量度量法、逻辑覆盖法和基本路径测试法。
分层测试体系如图1-27所示。
图1-27
其中Unit代表单元测试，API代表接口测试，UI代表页面级的系统测试。分层的自动化测试倡导在产品的不同层次都需要自动化测试，这个金字塔也表示了越靠下越容易执行自动化测试，越靠下成本越低，越靠下效率越高。
分层测试顾名思义就是分多个层次的软件测试，例如先测完软件的中间接口层，再测软件的最上层的界面。不过也可以同时测试二者。
分层测试的测试方法对测试人员的代码编写能力还有自动化测试水平有较高要求，同时要求测试人员和开发团队真正地理解敏捷开发和敏捷测试，甚至要求开发团队具备开发即测试、测试即开发的能力。
（1）单元测试
对软件中最小的单元进行检查和验证，即开发者编写的一小段代码，用于检验被测的一个很小的功能是否正确实现。一个单元测试通常用于判断某个特定条件（或者场景）下某个特定函数的行为。
（2）接口测试
接口测试是测试系统组件间接口的一种测试，主要用于检测外部系统与本系统之间，以及内部各个子系统之间的交互点。
测试的重点是检查接口参数传递的正确性，接口功能实现的正确性，输出结果的正确性，以及对各种异常情况的容错处理的完整性和合理性。
接口测试可以使测试人员更早介入，介入越早越能更早地发现系统中的问题，还可以缩短项目测试周期，能够发现更底层的Bug，减少开发成本。
考虑到公司中不同部门（前端、后端）的工作进度不一样，所以，测试人员可针对最先完成的接口，以及需要调用第三方系统的（银行、支付宝、微信、QQ等）一些接口进行接口测试及验证。
（3）UI测试
UI测试的是应用中的用户界面是否如预期设计，例如，用户在界面上输入数据需要触发正确的事件，输出的数据能正确地展示给用户，UI的状态能随着程序的运行发生正确的变化等。
UI测试可以采用静态测试方法或动态测试方法。
对用户界面的布局、风格、字体、图片等与显示相关的部分UI测试应该采用静态测试方法，例如，点检表测试，即将测试必须通过的项用点检表一条一条列举出，然后观察每项是否通过。
对用户界面中各个类别的控件应该采用动态测试方法，即编写测试用例，对每个按钮的响应情况进行测试，判断这些按钮是否符合概要设计所规定的标准，还可以对用户界面在不同软/硬件环境下的显示情况进行测试。
UI测试需要关注的内容有以下几个方面。
首先，要通过浏览器去操作测试对象，关注测试对象是否可以正确反映业务需求的功能。
其次，还要关注测试对象是否支持各种访问方法，如按Tab 键、移动鼠标、操作快捷键等。
最后，还需要关注浏览器窗口的对象特征，如浏览器的菜单展示、窗口大小、窗口位置、窗口的状态等，都需要符合标准。
测试管理平台是贯穿软件测试整个生命周期的工具集合，它主要解决的是测试过程中团队协作的问题。在整个软件测试过程中，需要对测试用例、Bug、代码、持续集成等进行管理。下面分别从4个方面介绍现在比较流行的管理平台，如图1-28所示。
图1-28
测试用例管理是软件测试管理中非常重要的一项工作，测试用例也是测试人员的重要产出。现在比较常见的测试用例管理平台如下。
（1）JIRA：可定制性很强，大互联网公司使用较多。
（2）Redmine：开源、可定制性很强。
（3）TestLink：流行的测试用例管理平台，使用体验不太好。
（4）其他：TAPD、云效、禅道、GitLab、在线协作文档。
（5）无协作模式：Excel、思维导图。
Bug管理平台通常与测试用例管理平台一致。JIRA是现在大型企业中比较常用的平台。在JIRA中，测试用例、Bug都可以使用Issue（问题）管理。
代码管理也叫版本控制，用以记录系统中若干文件内容的变化，方便程序员查阅系统中特定版本的修订情况。
（1）Git：分布式管理，它的每个客户端都是独立的版本管理中心，团队开发的代码可以存放在本机上，也可以上传到服务端以便汇总所有的更新代码。
（2）GitLab：可本地部署的Git代码管理平台。
（3）GitHub：在线的基于Git的代码管理平台，开源项目常用。
（4）Subversion：SVN代码管理平台，客户端需要把新代码上传到服务端。
（5）Bitbucket：与JIRA同属一家公司开发的代码管理平台。
持续集成是敏捷开发工作中的组成部分。团队在不断推进项目开发的同时持续上线新增加的各类小规模功能。当开发人员专注于添加功能时，代码错误也会随之而来，并导致软件无法正常使用。为了阻止错误被集成到系统软件中，持续集成管理平台需要先对代码质量进行把关，即使有问题的代码已经被集成进系统中，持续集成管理平台仍然能够快速发现是哪个程序出了问题。
实践中常用的持续集成管理平台如下。
（1）Jenkins：持续集成与持续交付的主流管理平台。
（2）GitLab Runner：GitLab的持续交付管理平台。
（3）GitHub Action：GitHub的开源管理平台。
（4）自建DevOps平台：企业定制平台，如TAPD、云效等。
测试用例（TestCase）是为特定的测试目的而设计的一组测试输入、执行条件和预期结果的文档。它的作用是为了测试系统功能是否满足用户某个特定需求。测试用例是指导测试人员工作的依据。
标准的测试用例通常由以下几个模块组成。
● 测试用例编号：测试用例的唯一标识。
● 模块：标明被测需求具体属于系统中哪个模块，这是为了更好地识别及维护测试用例。
● 测试用例标题：又称为测试点，就是用一句话描述测试用例的关注点，每一条测试用例对应一个测试目的。
● 优先级：根据需求的优先级别来定义，高优先级的测试用例要覆盖核心业务、重要特性，以及使用频率比较高的系统功能部分。
● 前提条件：测试用例在执行之前需要满足的一些条件，否则测试用例无法执行，例如，一些测试环境或者需要提前执行的操作。
● 测试数据：在执行测试用例时，需要输入一些外部数据来完成测试，这些数据根据测试用例的统计情况来确定，有参数、文件或者数据库记录等数据。
● 测试步骤：测试用例执行的步骤描述，测试用例的使用人员可以根据测试步骤完成测试的执行。
● 期望结果：是测试用例中最重要的部分，主要用来判断被测对象是否运行正常。
● 实际结果：结果一般有通过、失败和未执行。
在实际工作中，测试人员根据系统需求会把测试用例划分成不同的等级。
● P0：核心功能测试用例（冒烟测试），确定此系统版本是否可测的测试用例，此部分测试用例的结果如果是FAIL（失败），其他测试用例就可以不用执行了，需要把程序退回去给开发人员修改，然后再重新提测。
● P1：高优先级测试用例，最常执行的测试用例，测试系统功能是否稳定，它包含基本功能测试和重要的错误、边界测试。
● P2：中优先级测试用例，用以更全面地验证系统功能的各个方面，包含异常、边界、中断、网络、容错、UI等的测试用例。
● P3：低优先级测试用例，不常被执行，一般包含性能、压力、兼容性、安全、可用性等的测试用例。不同的公司可能对测试用例的等级划分有所差异，但基本上大同小异。
写测试用例能带来哪些好处呢？
首先，测试用例可以帮助测试人员做到心中有数，在测试用例的指导下，测试人员不会在一个测试点上重复测好多次，同时也避免漏掉测试点。而且测试人员在测试用例中可以将测试数据提前准备好，这样就不会漏掉一些重要的数据了。
其次，测试用例的执行结果也是评估测试结果的度量基准。如果设计全面覆盖需求的测试用例都执行通过了，发现的系统问题全部修改了，程序员即可放心地把应用程序交付给客户使用。
再次，测试用例也是分析缺陷的标准。因为测试用例中会详细描述期望结果，这个期望结果其实就是分析系统中是不是有Bug的一个标准。测试用例执行后反向的结果和预期结果一致的，就说明系统没有Bug；反之，和预期结果不一致，就是系统存在Bug，需要开发人员对Bug进行修复。
在写测试用例的时候，测试人员可以使用思维导图把待测的系统模块和测试用例的设计思路理清楚。思维导图完成之后就可以对测试用例进行评审，评审完毕后，测试用例有需要修改的地方可以在思维导图上直接修改。
如果团队要求测试人员用表格的方式去写测试用例，可以再把思维导图中的测试思路转化成为表格形式。测试用例的具体设计方法，请参考后面的章节。
边界值分析法是一种很实用的黑盒测试用例方法，它具有很强的“发现”系统故障（Bug）的能力。边界值分析法也是对等价类划分法的补充，测试用例中的边界值是通过等价类划分出来的。
在测试实践中，测试人员用这个方法发现的系统Bug往往出现在定义域或值域的边界上，而不是在系统模块的内部。为检测系统边界附近的值而专门设计的测试用例，通常都会取得很好的测试效果。
边界值分析法一般用在输入条件规定了取值范围，以及限定值的个数的场景上。
提示：在分析等价类案例、划分等价类的时候，测试人员发现此时一般都存在比较特殊的点，这种点叫作极点或者上点，例如，[1,100]中的上点就是 1 和 100，这两个数值就被称为边界值，也可以叫作极值。设计测试用例的时候，可以在等价类的基础上，重点验证系统在边界点运行的情况。
例如，需求文档中对某输入值的要求是：输入的参数值必须大于等于0同时小于100的整数。
正确的代码中可以这样设置判断条件：
# 正确条件 1
num > -1 and num < 100
# 正确条件 2
num >= 0 and num < =99但是在实际的代码编写过程中，可能会因为各种原因，导致判断条件设置错误：
# 错误条件 1
num >= -1 and num <= 101
# 错误条件 2
um > 0 and num < 101
# 错误条件 3
num > 1 and num < 100因为要求输入的参数是大于等于0并且小于100的整数。
● 第一种错误是，num >= −1中多写了“=”，这样就把−1包含到了有效范围内，这是不符合要求的。而num <= 101也是因为多写了“=”，并且条件值选择错误，导致100和101也被包含到了有效范围内。
● 第二种错误是，有效范围漏掉了0，并且包含了100。
● 第三种错误是，有效范围漏掉了0。
使用边界值分析法设计测试用例需要考虑3个点位的选择，如图1-29所示。
图1-29
● 上点，边界上的点位。
● 离点，离上点最近的点位。如果输入域是封闭的，则离点在域范围外；如果输入域是开区间，则离点在域的范围内。
● 内点：在输入域内任意一个点位。
一般来说设计测试用例时要把上点、离点和内点域的数值都取到，所以选取正好等于、刚好大于或刚好小于边界值的数值作为测试数据。
综上，上个题目中通过边界值分析法就可以取到6个点。
（1）基于边界值分析方法选择测试用例数据的原则
常用的有以下3种原则。
1）如果输入条件规定了值的范围，则应取刚达到这个范围边界的值，以及刚超过这个范围边界的值作为测试输入数据。
2）如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少一、比最大个数多一的数作为测试数据。
3）如果规定了输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试的数据。
注：在选择离点时，需要考虑数据的类型和精度。比如上点数据类型是实数，精确度为0.001，那么离点就是上点减0.001或者上点加0.001。
（2）实例
问题：计算1～100的整数之和（包括1和100）。
上面已经用等价类的方法设计出来了一部分测试用例，其余的要使用边界值分析法补充测试用例，如表1-1所示。
表1-1
| 用例编号 |
所属等价类 |
输入框1 |
输入框2 |
预期结果 |
|---|---|---|---|---|
| 1 |
有效等价类 |
1 |
99 |
100 |
| 2 |
有效等价类 |
99 |
1 |
100 |
| 3 |
有效等价类 |
100 |
2 |
102 |
| 4 |
有效等价类 |
2 |
100 |
102 |
| 5 |
无效等价类 |
0 |
40 |
给出错误提示 |
| 6 |
无效等价类 |
40 |
0 |
给出错误提示 |
| 7 |
无效等价类 |
101 |
2 |
给出错误提示 |
| 8 |
无效等价类 |
2 |
101 |
给出错误提示 |
首先分析边界值：1和100（有效等价类），其次是边界值两边的值：0、2、99、101（0和101是无效等价类，2和99是有效等价类）。
在计算整数求和的例子中，我们需要在输入框中输入两个整数，那么这两个输入框需要取的边界值有1、2、99、100。无效等价类中也要覆盖到0和101这两个值，同样的两个输入框输入值都需要覆盖。
用边界值分析法补充测试用例时，要注意确定边界的情况（输入或输出等价类的边界），选取正好等于、刚好大于或刚好小于边界值的数值作为测试数据，同时需要确定各个值的等价类，明确边界值和等价类的区别，即边界值分析不是从某等价类中随便挑一个值作为代表，而是这个等价类的每个边界都要作为测试条件。
等价划分法是一种不需要考虑程序的内部结构，只需要考虑程序输入数据的黑盒测试方法，它将不能穷举的测试过程进行合理分类，从而保证设计出来的测试用例具有完整性和代表性。
需要把用户所有可能输入的数据划分成若干份（若干个子集），然后从每一个子集中选取少数并且具有代表性的数据作为测试用例的数据，这种方法被称为等价类划分法。
在有限的测试资源的情况下，用少量且有代表性的数据进行测试会得到比较好的测试效果。
等价类划分的基本思想是首先把可能用到的数据划分为不同的类别，然后再从每一类别里面挑选有代表性的数据用以测试。这样挑选出来的数据就可以代表这一类里面的全部数据。通过这种方式，可以减少测试用例的数量。
根据不同类别划分出来的范围中，又可以分为以下两种情况。
（1）有效等价类：指符合需求文档描述，输入合理的数据集合。
（2）无效等价类：指不符合需求文档描述，输入不合理的数据集合。
所以等价类可以等同于有效等价类和无效等价类的组合，如图1-30所示。
图1-30
用户的软件不仅要能够接收合理的数据输入，对输入不合理的数据也需要做出正确的响应，因此在对系统设计测试用例时，两种等价类都需要考虑，这样的测试才能确保软件具有更高的可靠性。
所有的有效等价类和无效等价类所用的数据合起来，就是整个的测试数据。
通常按照以下原则划分等价类。
（1）如果规定输入的取值范围或个数，则划分一个有效等价类和两个无效等价类。例如，注册用户名的长度限制为6～18个字符，6～18个字符是有效等价类，小于6个字符和大于18个字符则是两个无效等价类。
（2）如果规定了输入的集合或规则必须要遵循的条件，则划分一个有效等价类和一个无效等价类。例如，注册用户名的格式要求必须以字母开头，以字母开头是有效等价类，非字母开头是无效等价类。
（3）如果输入条件是一个布尔值，则划分为一个有效等价类和一个无效等价类。例如，在注册用户时需要遵循协议或条款是否接受时，“接受”是有效等价类，“不接受”则是无效等价类。
（4）如果输入条件是一组数据（枚举值），并且程序对每一个输入的值做不同的处理，则划分若干个有效等价类和一个无效等价类。例如，网游中充值VIP等级（3个等级），对每个VIP的等级优惠不同，VIP1、VIP2、VIP3不同等级是3个有效等价类，不是VIP用户则是无效等价类。
（5）如果输入条件规定了必须要遵循某些规则，则划分为一个有效等价类和若干个无效等价类（无效等价类需要从不通的角度去违反规则）。例如，密码设置要求首位必须是大写字母的，首字母大写是有效等价类，首位小写字母的、首位为数字的或者首位为特殊字符的则是无效等价类。
（6）不是所有的等价类都有无效等价类。例如，性别的选择只有男或女两种。
（1）先划分等价类：找出所有可能的分类。
（2）确定有效等价类：需求文档中提出的条件。
（3）确定无效等价类：与条件相反的情况，再找到特殊情况（中文、英文、符号、空格、空等）。
（4）从各个分类中挑选测试用例数据。
划分等价类要点：文本框要求输入数据的长度、类型、组成规则、是否为空、是否重复、区分大小写、是否去除空格。
等价类设计步骤的前3个步骤，可以通过等价类表这种方法来辅助进行分析。
例：还是以计算器为例，这一次的计算范围是1～100中的两个整数之和。
（1）创建等价类表
在确立了等价类之后，可按表1-2所示的内容列出所有划分出的等价类。
表1-2
| 输入条件 |
有效等价类 |
无效等价类 |
|---|---|---|
| 1～100的整数（包括1和100） |
[1,100]整数 |
<1整数 |
|
|
|
>100整数 |
|
|
|
小数 |
|
|
|
字母 |
|
|
|
汉字 |
|
|
|
特殊字符 |
等价类表可以帮助分析和划分等价类，这是一个辅助工具，初学者可以借助这种方式快速地编写出测试用例。
设计测试用例的时候需要注意，应该按照以下原则来覆盖不同的等价类。
1）设计新的测试数据，尽可能多覆盖尚未被覆盖的有效等价类，重复这一步骤，直到将所有的有效等价类都覆盖完为止。
2）设计新的测试数据，只覆盖一个无效等价类，重复这一步，直到将所有的无效等价类都覆盖完为止。
（2）设计测试用例
我们先编写一个很简单的测试用例，只包含最关键的一些信息，如测试用例编号、所属的等价类，两个输入框中的测试数据，还有预期结果。
因为在这个加法的例子中，想要得到最终计算结果需要在两个输入框中都输入数据，所以这里已经涉及了多个元素，就需要输入两个值。
在涉及多个元素的情况下，要采用控制变量法，如果要覆盖无效等价类，设计测试用例的时候，当前元素覆盖无效等价类的同时测试用例中涉及的其他元素要保持有效，如表1-3所示。
表1-3
| 用例编号 |
所属等价类 |
输入框1 |
输入框2 |
预期结果 |
|---|---|---|---|---|
| 1 |
有效等价类 |
30 |
60 |
90 |
| 2 |
无效等价类 |
−2 |
40 |
给出错误提示 |
| 3 |
无效等价类 |
40 |
−2 |
给出错误提示 |
| 4 |
无效等价类 |
110 |
2 |
给出错误提示 |
| 5 |
无效等价类 |
2 |
110 |
给出错误提示 |
| 6 |
无效等价类 |
10.5 |
3 |
给出错误提示 |
| 7 |
无效等价类 |
1 |
10.5 |
给出错误提示 |
| 8 |
无效等价类 |
a |
5 |
给出错误提示 |
| 9 |
无效等价类 |
人 |
20 |
给出错误提示 |
| 10 |
无效等价类 |
20 |
人 |
给出错误提示 |
| 11 |
无效等价类 |
5 |
a |
给出错误提示 |
| 12 |
无效等价类 |
! |
5 |
给出错误提示 |
| 13 |
无效等价类 |
5 |
! |
给出错误提示 |
| 14 |
无效等价类 |
空格 |
5 |
给出错误提示 |
| 15 |
无效等价类 |
5 |
空格 |
给出错误提示 |
| 16 |
无效等价类 |
为空 |
5 |
给出错误提示 |
| 17 |
无效等价类 |
5 |
为空 |
给出错误提示 |
表格中的每一条测试用例都遵循了控制变量法（只验证一个输入框中的无效等价类），这样可以排除更多不确定因素和干扰因素。
（3）等价类总结
等价类划分法非常简单，也很容易理解，是在设计测试用例中使用最广泛的一种方法。
它的优点是考虑了单个输入域、所有可能的取值情况，避免了在设计测试用例时盲目或随机选取输入测试不完整或不稳定的数据。
最大的缺点是产生的测试用例比较多，而且在设计时，可能会产生一些无效的测试用例，也没有对特殊点进行考虑，所以在设计测试用例时需要结合其他的方法进行完善。
因果图法是一种利用图解法分析输入与输出的各种组合情况，从而设计测试用例的方法。
因果图法比较适合输入条件比较多的测试场景，可以测试所有的输入条件的排列组合。因果图的“因”就是输入条件，因果图的“果”就是输出结果。
等价类划分法和边界值分析法都是着重考虑输入条件，但没有考虑输入条件的组合以及制约关系。如果在测试时必须考虑输入条件的各种组合，那各种组合的数目可能非常多，所以必须考虑采用一种合适的方法对条件组合进行分析、简化。最终目的是用最少的测试用例覆盖最全面的场景。
因果图中的基本符号有4种（也表示4种基本关系），分别是恒等（—）、或（∨）、与（∧）、非（～）。
（1）恒等原因和结果都只能取2个值，1代表条件成立，0代表条件不成立。恒等相当于原因成立，则结果出现；若原因不成立，则结果也不出现。恒等关系用“—”来表示。
（2）非原因和结果相反。若原因成立，则结果不出现；若原因不成立，则结果出现。非的关系用“～”表示。
（3）或有多个原因。若几个原因中有一个成立，则结果出现；若几个原因都不成立，则结果不出现。或的关系用“V”来表示。
（4）与有多个原因。只有几个原因都成立，结果才会出现；若其中一个原因不成立，则结果不出现。与的关系用“^”来表示。
因果图中除了4种基本关系之外还会有一些约束。从原因考虑有4种约束：互斥、包含、唯一、要求。从结果考虑有1种约束：屏蔽。
（1）互斥（E）：可不选，要选最多选一个。
（2）包含（I）：至少选择一个，可以多选。
（3）唯一（O）：必选，且只能选一个。
（4）要求（R）：一个出现，另一个一定出现；反之，另一个不确定。
（5）屏蔽（M）：a成立时，b不成立；a不成立时，b不确定。
唯一和互斥的区别是：唯一表示必须选且只能选一个；互斥表示可以不选，如果要选只能选一个。
（1）找出所有的原因，原因即输入条件或输入条件的等价类。
（2）找出所有的结果，结果即输出条件。
（3）明确所有输入条件之间的制约关系，以及组合关系，判断条件是否可以组合。
（4）明确所有输出条件之间的制约关系，以及组合关系，判断结果是否可以同时输出。
（5）找出不同输入条件组合会产生哪些输出结果。
（6）将因果图转换成判定表。
（7）把判定表或决策表中每一列表示的情况设计成测试用例。
（1）需求解释
交通一卡通自动充值软件系统。系统只接收50元或100元纸币，一次只能使用一张纸币，一次的充值金额只能为50元或100元。
明确输入的条件如下。
1）选择投币50元。
2）选择投币100元。
3）选择充值50元。
4）选择充值100元。
输出的结果如下：
a．完成充值、退卡 b．提示充值成功 c．找零/退钱 d．提示错误
（2）分析输入的条件
输入的条件之间的关系如图1-31所示。
1）不能组合的条件
● 条件1和条件2不能同时成立。
● 条件3和条件4不能同时成立。
2）可以组合的条件
● 条件1和条件3可以同时成立。
● 条件1和条件4可以同时成立（注，如果充值失败或充值数额不足，则提示错误，同时退回钱）。
● 条件2和条件3可以同时成立。
● 条件2和条件4可以同时成立。
● 条件1、条件2、条件3、条件4可以单独出现。
（3）分析输出条件
输出条件之间的关系如图1-32所示。
图1-31
图1-32
1）不能组合的输出结果（互斥关系）
● 输入a和d不能同时出现。
● 输出b和d不能同时出现。
2）可以组合的输出结果（要求）
● 输出a和b一定会同时出现（要求）。
● 输出a、b、c可以同时出现。
● 输出c、d可以同时出现（注，如果充值失败或充值数额不足，则提示错误，同时退回零钱）。
● 输出d单独存在。
（4）分析输入和输出的对应关系
● 条件1和条件3组合——输出a、b组合（投币50元，选择充值50元——完成充值、退卡）
● 条件1和条件3组合的对应关系如图1-33所示。
图1-33
由图1-33转化为对应的判定表如表1-4所示。
表1-4
| 输入 |
组合1 |
组合2 |
组合3 |
组合4 |
组合5 |
组合6 |
组合7 |
组合8 |
|---|---|---|---|---|---|---|---|---|
| 1．投币50元 |
1 |
|
|
|
|
|
|
|
| 2．投币100元 |
|
|
|
|
|
|
|
|
| 3．选择充值50元 |
1 |
|
|
|
|
|
|
|
| 4．选择充值100元 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 输出 |
|
|
|
|
|
|
|
|
| a．完成充值、退卡 |
1 |
|
|
|
|
|
|
|
| b．提示充值成功 |
1 |
|
|
|
|
|
|
|
| c．找零/退钱 |
|
|
|
|
|
|
|
|
| d．错误提示 |
|
|
|
|
|
|
|
|
注：单元格中的“1”表示输入的条件或输出的结果，下面不再提示。
● 条件1和条件4组合——输出c、d组合（投币50元，选择充值100元——退钱、提示错误）
● 条件1和条件4组合的对应关系如图1-34所示。
图1-34
由图1-34转化为对应的判定表如表1-5所示。
表1-5
| 输入 |
组合1 |
组合2 |
组合3 |
组合4 |
组合5 |
组合6 |
组合7 |
组合8 |
|---|---|---|---|---|---|---|---|---|
| 1．投币50元 |
1 |
1 |
|
|
|
|
|
|
| 2．投币100元 |
|
|
|
|
|
|
|
|
| 3．选择充值50元 |
1 |
|
|
|
|
|
|
|
| 4．选择充值100元 |
|
1 |
|
|
|
|
|
|
| 输出 |
|
|
|
|
|
|
|
|
| a．完成充值、退卡 |
1 |
|
|
|
|
|
|
|
| b．提示充值成功 |
1 |
|
|
|
|
|
|
|
| c．找零/退钱 |
|
1 |
|
|
|
|
|
|
| d．错误提示 |
|
1 |
|
|
|
|
|
|
● 条件2和条件3组合——输出a、b、c组合（投币100元，选择充值50元——
充值成功、退卡、找零）
● 条件2和条件3组合的对应关系如图1-35所示。
图1-35
由图1-35转化为对立的判定表如表1-6所示。
表1-6
| 输入 |
组合1 |
组合2 |
组合3 |
组合4 |
组合5 |
组合6 |
组合7 |
组合8 |
|---|---|---|---|---|---|---|---|---|
| 1．投币50元 |
1 |
1 |
|
|
|
|
|
|
| 2．投币100元 |
|
|
1 |
|
|
|
|
|
| 3．选择充值50元 |
1 |
|
1 |
|
|
|
|
|
| 4．选择充值100元 |
|
1 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 输出 |
|
|
|
|
|
|
|
|
| a．完成充值、退卡 |
1 |
|
1 |
|
|
|
|
|
| b．提示充值成功 |
1 |
|
1 |
|
|
|
|
|
| c．找零/退钱 |
|
1 |
1 |
|
|
|
|
|
| d．错误提示 |
|
1 |
|
|
|
|
|
|
● 条件2和条件4组合—— 输出a、b组合（投币100元，选择充值100元—— 完成充值、退卡）
● 条件2和条件4组合的对应关系如图1-36所示。
图1-36
由图1-36转化为对应的判定表如表1-7所示。
表1-7
| 输入 |
组合1 |
组合2 |
组合3 |
组合4 |
组合5 |
组合6 |
组合7 |
组合8 |
|---|---|---|---|---|---|---|---|---|
| 1．投币50元 |
1 |
1 |
|
|
|
|
|
|
| 2．投币100元 |
|
|
1 |
1 |
|
|
|
|
| 3．选择充值50元 |
1 |
|
1 |
|
|
|
|
|
| 4．选择充值100元 |
|
1 |
|
1 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 输出 |
|
|
|
|
|
|
|
|
| a．完成充值、退卡 |
1 |
|
1 |
1 |
|
|
|
|
| b．提示充值成功 |
1 |
|
1 |
1 |
|
|
|
|
| c．找零/退钱 |
|
1 |
1 |
|
|
|
|
|
| d．错误提示 |
|
1 |
|
|
|
|
|
|
● 条件1单独出现—— 输出c、d组合（只投币50元——充值失败、提示错误、退款）
● 条件1单独出现的情况如图1-37所示。
图1-37
由图1-37转化为对应的判定表如表1-8所示。
表1-8
| 输入 |
组合1 |
组合2 |
组合3 |
组合4 |
组合5 |
组合6 |
组合7 |
组合8 |
|---|---|---|---|---|---|---|---|---|
| 1．投币50元 |
1 |
1 |
|
|
1 |
|
|
|
| 2．投币100元 |
|
|
1 |
1 |
|
|
|
|
| 3．选择充值50元 |
1 |
|
1 |
|
|
|
|
|
| 4．选择充值100元 |
|
1 |
|
1 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 输出 |
|
|
|
|
|
|
|
|
| a．完成充值、退卡 |
1 |
|
1 |
1 |
|
|
|
|
| b．提示充值成功 |
1 |
|
1 |
1 |
|
|
|
|
| c．找零/退钱 |
|
1 |
1 |
|
1 |
|
|
|
| d．错误提示 |
|
1 |
|
|
1 |
|
|
|
● 条件2单独出现—— 输出c、d组合（只投币100元——充值失败、提示错误、退钱）
● 条件2单独出现的情况如图1-38所示。
图1-38
由图1-38转化为对应的判定表如表1-9所示。
表1-9
| 输入 |
组合1 |
组合2 |
组合3 |
组合4 |
组合5 |
组合6 |
组合7 |
组合8 |
|---|---|---|---|---|---|---|---|---|
| 1．投币50元 |
1 |
1 |
|
|
1 |
|
|
|
| 2．投币100元 |
|
|
1 |
1 |
|
1 |
|
|
| 3．选择充值50元 |
1 |
|
1 |
|
|
|
|
|
| 4．选择充值100元 |
|
1 |
|
1 |
|
|
|
|
| 输出 |
|
|
|
|
|
|
|
|
| a．完成充值、退卡 |
1 |
|
1 |
1 |
|
|
|
|
| b．提示充值成功 |
1 |
|
1 |
1 |
|
|
|
|
| c．找零/退钱 |
|
1 |
1 |
|
1 |
1 |
|
|
| d．错误提示 |
|
1 |
|
|
1 |
1 |
|
|
● 条件3单独出现—— 输出d（只选择充值50元——充值失败、提示错误）
● 条件3单独出现的情况，如图1-39所示。
图1-39
由图1-39转化为对应的判定表如表1-10所示。
表1-10
| 输入 |
组合1 |
组合2 |
组合3 |
组合4 |
组合5 |
组合6 |
组合7 |
组合8 |
|---|---|---|---|---|---|---|---|---|
| 1．投币50元 |
1 |
1 |
|
|
1 |
|
|
|
| 2．投币100元 |
|
|
1 |
1 |
|
1 |
|
|
| 3．选择充值50元 |
1 |
|
1 |
|
|
|
1 |
|
| 4．选择充值100元 |
|
1 |
|
1 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 输出 |
|
|
|
|
|
|
|
|
| a．完成充值、退卡 |
1 |
|
1 |
1 |
|
|
|
|
| b．提示充值成功 |
1 |
|
1 |
1 |
|
|
|
|
| c．找零/退钱 |
|
1 |
1 |
|
1 |
1 |
|
|
| d．错误提示 |
|
1 |
|
|
1 |
1 |
1 |
|
● 条件4单独出现—— 输出d（只投币100元——充值失败、提示错误）
● 条件4单独出现的情况，如图1-40所示。
图1-40
由图1-40转化为判定表如表1-11所示。
表1-11
| 输入 |
组合1 |
组合2 |
组合3 |
组合4 |
组合5 |
组合6 |
组合7 |
组合8 |
|---|---|---|---|---|---|---|---|---|
| 1．投币50元 |
1 |
1 |
|
|
1 |
|
|
|
| 2．投币100元 |
|
|
1 |
1 |
|
1 |
|
|
| 3．选择充值50元 |
1 |
|
1 |
|
|
|
1 |
|
| 4．选择充值100元 |
|
1 |
|
1 |
|
|
|
1 |
|
|
|
|
|
|
|
|
|
|
| 输出 |
|
|
|
|
|
|
|
|
| a．完成充值、退卡 |
1 |
|
1 |
1 |
|
|
|
|
| b．提示充值成功 |
1 |
|
1 |
1 |
|
|
|
|
| c．找零/退钱 |
|
1 |
1 |
|
1 |
1 |
|
|
| d．错误提示 |
|
1 |
|
|
1 |
1 |
1 |
1 |
把所有的条件与输入对应完毕之后，就得到了最终的判定表，如表1-11所示。然后要把这个判定表再转为测试用例。
（5）转换为测试用例
判定表最终转化出的测试用例如表1-12所示。
表1-12
| 用例编号 |
测试点 |
测试步骤 |
预期结果 |
|---|---|---|---|
| 1 |
投币50元充50元 |
1．点击投币50元按钮 |
充值成功并退卡，提示充值成功 |
| 2 |
投币50元充100元 |
1．点击投币50元按钮 |
提示输入金额不足，并退回50元 |
| 3 |
投币100元充50元 |
1．点击投币100元按钮 |
完成充值后退卡，提示充值成功，找零50元 |
| 4 |
投币100元充100元 |
1．点击投币100元按钮 |
充值成功并退卡，提示充值成功 |
| 5 |
投币50元不充值 |
1．点击投币50元按钮 |
提示错误，退回50元 |
| 6 |
投币100元不充值 |
1．点击投币100元按钮 |
提示错误，退回100元 |
| 7 |
不投币点击充值50元 |
1．不点击投币按钮 |
提示错误 |
| 8 |
不投币点击充值100元 |
1．不点击投币按钮 |
提示错误 |
测试人员不能只关注软件中某个控件的边界值、等价类是否满足软件设计要求，也要关注软件的主要功能和业务流程是否正确实现，这时就需要使用场景法来完成验证。
软件的运行几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。场景法就是通过场景对系统的功能或业务流程进行测试。
场景法一般包含基本流和备选流，从一个流程开始，通过业务流程经过的路径来确定测试的过程，并遍历所有的基本流和备选流来完成系统中的所有场景。
场景法的基本过程如图1-41所示。
图1-41
（1）基本流：按照正确的业务流程来实现的一条操作路径，即模拟用户操作软件的正确的流程。
（2）备选流：导致软件出现错误的操作流程，即模拟用户操作软件的错误的流程。
测试人员在使用场景法设计测试用例时，需要覆盖系统中的主成场景和扩展场景，并且需要适当补充各种正反面的测试用例，以及考虑出现异常场景的情形。
设计场景法测试用例，首先需要根据需求文档得出系统功能模块的流程图，描述出系统程序的基本流及备选流；其次根据基本流和备选流生成不同的场景，构造场景列表；最后对每一个场景生成相应的测试用例，对所有的测试用例重新复审，去掉多余的测试用例，确定测试用例之后，为每一个测试用例确定测试的数据值，这就完成了场景法测试用例的设计了。
为在淘宝网上通过购物车购物的流程设计测试用例。
（1）画流程图
整个业务通过流程图来表示，如图1-42所示。
（2）确定基本流和备选流
1）基本流
① 进入淘宝首页。
② 浏览商品。
③ 进入单品页。
④ 选择商品规格和数量。
⑤ 加入购物车。
⑥ 前往购物车。
⑦ 选择商品。
⑧ 结算，前往确定订单页。
⑨ 提交订单。
⑩ 付款成功。
⑪ 等待收货。
⑫ 确认收货。
2）备选流
① 加入购物车时，不选择商品规格和型号，返回基本流第4步。
② 加入购物车时，商品库存不足，返回基本流第4步。
③ 加入购物车时，未登录，登录后返回基本流第3步。
图1-42
④ 加入购物车后，继续选购，返回基本流第4步。
⑤ 加入购物车，未选择商品，结算，返回基本流第7步。
⑥ 支付失败，返回基本流第8步。
⑦ 未选择商品加入购物车，退出购物，结束。
（3）构造场景
① 登录后成功购物（基本流）
② 未选择商品规格和型号就添加购物车（基本流+备选流第1步）
③ 选择的商品库存不足（基本流+备选流第2步）
④ 未登录，添加购物车（基本流+备选流第3步）
⑤ 商品添加到购物车后继续购物（基本流+备选流第4步）
⑥ 进入购物车，未选择商品直接结算（基本流+备选流第5步）
⑦ 支付过程出错（基本流+备选流第6步）
⑧ 没有添加商品到购物车（基本流+备选流第7步）
（4）生成测试用例的判定表（见表1-13）
表1-13
| 测试用例编号 |
测试点 |
测试步骤 |
预期结果 |
|---|---|---|---|
| 1 |
登录后成功购物 |
前提条件：登录 |
确认收货成功，订单完成 |
| 2 |
单品页未选择商品规格和型号，添加购物车，单品页上提示需要选择商品规格与型号 |
前提条件：登录 |
单品页上提示需要选择商品规格与型号 |
| 3 |
选择的商品库存不足，添加商品到购物车，提示库存不足 |
前提条件：登录 |
单品页上提示库存不足 |
| 4 |
未登录，添加商品到购物车，进入登录页面 |
前提条件：未登录 |
进入登录页面 |
| 5 |
添加商品到购物车后继续购物，留在单品页 |
前提条件：登录 |
可以正常查看 |
| 6 |
进入购物车，未选择商品直接结算，提示未选择商品 |
前提条件：登录 |
页面提示请勾选要结算的商品 |
| 7 |
支付过程出错，提示支付失败，回到确认订单页 |
前提条件：登录 |
回到确认订单页，提示支付失败 |
| 7 |
支付过程出错，提示支付失败，回到确认订单页 |
7．进入购物车页面 |
回到确认订单页，提示支付失败 |
| 8 |
没有添加商品到购物车，结束购物 |
前提条件：登录 |
购物流程结束 |
最终生成的测试用例的判定表如表1-13所示，这种利用场景法设计出来的测试用例一般是对等价类和边界值的补充。
1.12节因果图分析法中最后会得出一个判定表（见表 1-11），从讲解中可以得知因果图和判定表是有联系的，它们一般需要结合起来使用。
因果图是一种分析工具，通过分析最终得到判定表，再通过判定表编写测试用例。在一些特殊情况下，测试人员也可以直接写出判定表，省略因果图，进而编写测试用例。
判定表是由条件桩、动作桩、条件项和动作项组成的。条件桩表示可能出现这个问题（Bug）的所有条件，动作桩表示这个问题（Bug）的所有输出结果，条件项为条件桩的取值，动作项为条件项的各个取值情况下的输出结果。
设计判定表首先需要列出所有的条件桩和动作桩，确定规则数量，规则数由条件桩确定，规则数=条件取值数的条件数次方。
依次填入条件项和动作项得到初始判定表。初始判定表会包含冗余的内容，这些内容一般不适合设计测试用例，进一步简化判定表，合并相似的规则得到一个完整并且简洁的判定表，以便最终设计测试用例。
输入3个正整数a、b、c，分别作为三角形的三条边，判断三条边是否能构成三角形，如果能构成三角形，判断三角形的类型。
C1：a、b、c构成三角形的条件为a<b+c、b<a+c、c<a+b。
C2：a = b？
C3：a = c？
C4：b = c？
注：C1代表条件1，C2代表条件2，C3代表条件3，C4代表条件4。
A1：非三角形。
A2：不等边三角形（一般三角形）。
A3：等腰三角形。
A4：等边三角形。
A5：条件组合不可能出现。
表1-14
| 条件桩 |
条件项 |
|---|---|
| C1：abc构成三角形？ |
1：满足两边相加大于第三边 |
| C2：a = b？ |
1：a=b |
| C3：a=c？ |
1：a=c |
| C4：b=c？ |
1：b=c |
表1-15
| 动作桩 |
动作项 |
|---|---|
| A1：非三角形 |
1：不是三角形 |
| A2：一般三角形 |
1：是一般三角形 |
| A3：等腰三角形 |
1：是等腰三角形 |
| A4：等边三角形 |
1：是等边三角形 |
| A5：条件组合不可能出现 |
1：不可能出现 |
共有4个条件，每个条件的取值为“是”或“否”，即2种可能，因此有24 = 16条规则。
（1）填写初始判定表。按照对半取值的组合方式，对如下条件进行组合取值。
第一个条件C1，按照16条规则对半取值组合如下。
C1：8个0，8个1。
第二个条件C2，对16条规则的一半再进行对半取值，组合如下。（后面的条件依次类推。）
C2：4个0，4个1，4个0，4个1。
C3：2个0，2个1，2个0，2个1，2个0，2个1，2个0，2个1。
C4：0，1，0，1，0，1，0，1，0，1……
注：0代表条件不成立，1代表条件成立。
把以上分析的各个条件组合的值填写到判定表中即可（见表1-16和表1-17）。
表1-16
| 条件桩 |
组合1 |
组合2 |
组合3 |
组合4 |
组合5 |
组合6 |
组合7 |
组合8 |
组合9 |
组合10 |
组合11 |
组合12 |
组合13 |
组合14 |
组合15 |
组合16 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| C1:a b c |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
1 |
1 |
1 |
1 |
1 |
1 |
1 |
1 |
| C2:a =b? |
0 |
0 |
0 |
0 |
1 |
1 |
1 |
1 |
0 |
0 |
0 |
0 |
1 |
1 |
1 |
1 |
| C3:a =c? |
0 |
0 |
1 |
1 |
0 |
0 |
1 |
1 |
0 |
0 |
1 |
1 |
0 |
0 |
1 |
1 |
| C4:b =c? |
0 |
1 |
0 |
1 |
0 |
1 |
0 |
1 |
0 |
1 |
0 |
1 |
0 |
1 |
0 |
1 |
表1-17
| 动作桩 |
组合1 |
组合2 |
组合3 |
组合4 |
组合5 |
组合6 |
组合7 |
组合8 |
组合9 |
组合10 |
组合11 |
组合12 |
组合13 |
组合14 |
组合15 |
组合16 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| A1:非三角形 |
1 |
1 |
1 |
1 |
1 |
1 |
1 |
1 |
|
|
|
|
|
|
|
|
| A2:普通三角形 |
|
|
|
|
|
|
|
|
1 |
|
|
|
|
|
|
|
| A3 :等腰三角形 |
|
|
|
|
|
|
|
|
|
1 |
1 |
|
1 |
|
|
|
| A4:等边三角形 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1 |
| A5:不合逻辑 |
|
|
|
|
|
|
|
|
|
|
|
1 |
|
1 |
1 |
|
（2）简化判定表
上面已经得到了完整的判定表，但是这些条件的组合中一些是冗余的，例如，构成三角形的条件如果不满足的话，结果是非三角形，和其他3个条件无关，这种情况下可以对判定表进行简化（见表1-18和表1-19）。
表1-18
| 条件桩 |
组合1 |
组合2 |
组合3 |
组合4 |
组合5 |
组合6 |
组合7 |
组合8 |
组合9 |
|---|---|---|---|---|---|---|---|---|---|
| C1：a b c构成三角形？ |
0 |
1 |
1 |
1 |
1 |
1 |
1 |
1 |
1 |
| C2：a = b ？ |
|
0 |
0 |
0 |
0 |
1 |
1 |
1 |
1 |
| C3：a = c ？ |
|
0 |
0 |
1 |
1 |
0 |
0 |
1 |
1 |
| C4：b = c ？ |
|
0 |
1 |
0 |
1 |
0 |
1 |
0 |
1 |
表1-19
| 动作桩 |
组合1 |
组合2 |
组合3 |
组合4 |
组合5 |
组合6 |
组合7 |
组合8 |
组合9 |
组合10 |
组合11 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| A1：非三角形 |
1 |
|
|
|
|
|
|
|
|
|
|
| A2：普通三角形 |
|
1 |
|
|
|
|
|
|
|
|
|
| A3：等腰三角形 |
|
|
|
1 |
1 |
|
|
|
|
|
|
| A4：等边三角形 |
|
|
|
|
|
|
|
|
1 |
|
|
| A5：不合逻辑 |
|
|
|
|
1 |
|
1 |
1 |
|
|
|
设计测试用例时把不可能的情况排除，然后根据条件组合是否成立自行设计测试数据即可。设计完毕后得出最后的测试用例如表1-20所示。
表1-20
| 编号 |
a |
b |
c |
预期结果 |
|---|---|---|---|---|
| 1 |
4 |
1 |
2 |
非三角形 |
| 2 |
3 |
4 |
5 |
普通三角形 |
| 3 |
2 |
2 |
3 |
等腰三角形 |
| 4 |
2 |
3 |
2 |
等腰三角形 |
| 5 |
3 |
2 |
2 |
等腰三角形 |
| 6 |
5 |
5 |
5 |
等边三角形 |
注：表中a、b、c的数值是笔者根据条件组合随意设定的。
白盒测试又称为结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试是一种测试用例设计方法。盒子指的是被测试的软件，白盒指的是盒子是可视的，即清楚盒子内部的东西以及里面是如何运作的。白盒法在全面了解程序内部逻辑结构的基础上，对所有逻辑路径进行测试。白盒法是穷举路径测试。在使用这一方法时，测试者必须检查程序的内部结构，从检查程序的逻辑结构着手，得出测试数据。
白盒测试是在程序不同地方设立检查点，用来检查程序的状态，以确定实际运行状态与预期状态是否一致。
白盒测试是根据待测产品的内部实现细节来设计测试用例。白盒测试涵盖单元测试、集成测试。一般使用代码覆盖率作为白盒测试的主要度量指标。
（1）语句覆盖：每行代码都要覆盖至少一次（覆盖是测试人员之间常用的交流语言，也即测试到的地方称为覆盖）。
（2）判定覆盖：判定表达式的真假至少覆盖一次。
（3）条件覆盖：使每个判定表达式中的每个条件都取到各种可能的值。
（4）判定/条件覆盖：判定覆盖与条件覆盖都需要覆盖到。
（5）条件组合覆盖：判定表达式中的所有条件组合都需要覆盖。
（6）分支覆盖：控制流中的每条边都要被覆盖一次。
（7）路径覆盖：所有的路径都要尽量覆盖。
（8）指令覆盖：一行代码会被编译为多条指令，尽可能地覆盖所有指令。
（9）方法覆盖：每个方法至少要被覆盖一次。
（10）类覆盖：每个类至少被覆盖一次。
（1）EMMA：是一个开源、面向Java程序的测试覆盖率收集和报告工具。它通过对编译后的Java字节码文件进行插桩，在测试执行过程中收集覆盖率信息，并通过支持多种报表格式对覆盖率结果进行展示。
（2）Cobertura：是一款优秀的开源测试覆盖率统计工具，它与单元测试代码结合，标记并分析在测试包运行时执行了哪些代码和没有执行哪些代码，以及所经过的条件分支，来测量测试覆盖率。除了找出未测试到的代码并发现Bug外，Cobertura还可以通过标记无用的、执行不到的代码来优化代码，最终生成一份美观、详尽的HTML覆盖率检测报告。
（3）JaCoCo：是一个开源的覆盖率统计工具，针对Java语言，是现在流行的覆盖率统计工具。
流程覆盖用路径覆盖率表达，是利用代码执行流代表流程。执行时需要对流程进行裁剪获得一个适合业务的小规模的业务子集。
流程覆盖率 = 测试经过的路径 / 业务子集路径
精准化测试是一套计算机测试辅助分析系统。精准化测试的核心组件包含软件测试示波器、用例和代码的双向追溯、智能回归测试用例选取、覆盖率分析、缺陷定位、测试用例聚类分析、测试用例自动生成系统。这些组件的功能完整地构成了精准化测试技术体系。
精准化测试强调代码调用链与黑盒测试用例之间的关联。可以根据代码变更自动分析影响范围。例如，研发人员修改了1行代码，功能用例代码有1000行，但实际上很多用例和这1行代码是没有关系的，精准化测试可以判断出有哪些测试用例和改动的这1行代码有关系。例如1000个测试用例当中，只有20个和修改的代码有关系。那么测试的范围可以大大缩减，测试效率就会提高。
精准化测试还有一个很有价值的作用，就是在黑盒测试过程中，借助代码流程覆盖率指导测试活动。例如，在黑盒测试结束之后，观察代码的覆盖情况，发现有一些路径没有被覆盖到，这个时候就需要继续补充测试用例，一直到代码可以很全面地被覆盖。这是系统测试与底层白盒测试相结合的一个方法。
精准化测试还可以用线上数据推导有效的测试用例。例如测试一个系统，这个系统有大量历史数据，这时就可以提取其中一段运行时间的数据，使用这些数据继续测试这个系统。测试完成后统计这些测试数据中哪些数据对于测试覆盖率的增加是有帮助的，可以使用大数据的方法，自动提取出对于测试覆盖率有增益效果的数据。这些测试数据实际上属于同一个集合，在这种集合中，只取一部分测试数据就可以。利用线上数据反推有效测试用例也是精准化测试的重要作用。
由于精准化测试需要测试人员对白盒测试相当了解，对测试人员的技能要求比较高，所以实现起来有一定的难度。目前，行业中还没有开源的精准化测试的工具。现阶段只能通过JaCoCo工具，自主地去实现精准化测试。
测试策略是指在特定环境约束下，描述软件开发周期中关于测试原则、方法、方式的纲要，并阐述了它们之间是如何配合的，用以高效地减少缺陷、提升软件质量。
测试策略中需要描述测试类型与测试目标以及测试方法，准入/准出的条件，以及所需要的时间、资源与测试环境等。
测试策略是一种因地制宜的策略模式，不同的公司，不同的团队，不同的项目对应的测试策略内容不同。
对于测试策略来说，重点关注以下内容：
（1）测试的目标是什么？
（2）测试可能存在的风险是什么？
（3）测试的对象和范围是什么？
（4）如何安排各种测试活动？
（5）如何评价测试的效果？
（1）总体测试策略
明确产品质量目标：需求覆盖度、测试用例执行度、安全性、性能优化、代码规范、Bug修复率、产品标准输出文档。
功能分类的测试策略：根据功能类型分配优先级，例如，新功能的开发优先级为高，旧功能修改优先级为中，还有一些不用修改的旧功能优先级为低等。
进行风险分析：提前识别项目中可能存在哪些会阻塞测试的风险，然后基于风险来调整测试策略，增加一些测试活动或者质量保证活动。基于风险来加强和降低测试投入。例如，产品需求文档不清晰、需求文档更新不及时，导致测试设计时遗漏或不准确，以及新版本要修改的功能点修改的范围没有明确的文档记录或者产品设计比较复杂，难以理解等，根据存在的问题划分风险优先级。
总体测试安排：具体时间的分配安排，包括产品的概念阶段、设计阶段、开发阶段、测试阶段、发布阶段。
（2）初级版本测试策略
1）确定测试范围：包括对具体的功能以及功能的概述；对这些功能的使用人群进行详细的说明。
2）明确测试目标：通过对象—测试方法—测试结果这样的方式来描述测试目标，强调对版本的测试要求。
3）重点业务关注：列出重点需要关注的功能，并对重点内容进行详细的说明。
4）分配测试的资源与环境：测试资源分为人力和工具两部分，人力资源主要指参与测试的人员，工具主要是指可能用到的其他软件；测试环境是指系统兼容的环境信息。
5）用例设计选择：管理测试用例的设计，根据测试用例选择策略，并总结测试完成情况。
6）冒烟测试策略：开发人员将版本转给测试人员时，测试人员先对这个版本进行一次测试，确认版本没有阻塞测试的问题，能够按照测试策略完成测试，如果存在影响测试进度的问题，及时找开发人员沟通解决。
7）文档管理：需求说明文档和用户手册，以及部署实施的情况和测试进度的情况。
（3）跟踪测试执行
跟踪测试用例执行情况：包括测试用例的执行数量，测试用例执行未通过数量，测试用例执行通过数量，测试用例执行通过率和测试用例未执行数量以及测试用例未执行原因。
缺陷跟踪：跟踪版本需要解决但还处于待修复状态的Bug情况。
（4）版本质量评估
需求和实现的偏差：最终实现的功能与需求文档描述的偏差，需要修复的问题和修复说明。
测试过程评估：测试方法回顾，总结比较有效的测试方式和方法；测试投入回顾，投入资源的汇总；测试用例分析，测评测试用例的覆盖度并总结测试思路。
缺陷分析：在整个测试工作完成之后，总结功能缺陷密度是否在正常范围内。
（5）后续版本测试策略
后面的版本在考虑实际的产品研发情况和测试情况基础上，测试人员对测试策略进行调整，因此，后面版本的测试策略还需要增加回归测试策略和探索式测试策略的内容。
（6）发布质量评估
确认总体测试策略中的质量目标是否完成，分析遗留缺陷，暂挂Bug的处理情况。
总结来说，测试策略的主要内容都是围绕着测试关注的重点来展开的。
不同的测试场景下采用不同的测试手段，根据测试场景选取正确的测试方法。常用的测试方法有黑盒测试、白盒测试、动态测试、静态测试、手工测试、自动化测试，这些测试方法可以在测试策略的指导下根据需要安排到对应的测试环境中。
软件缺陷常常又被称为Bug。所谓软件缺陷就是指计算机软件或者程序中存在的某种破坏正常运行能力的问题、错误或者隐藏的功能缺陷。
Bug的存在会导致软件产品在某种程度上不能满足用户的需要。
（1）从产品内部看，是指软件产品开发或维护过程中存在的错误、毛病等问题。
（2）从产品外部看，是指系统所需要实现的某种功能的失效或违背。
缺陷可以分为不同的种类。
（1）遗漏：指规定或预期的需求未体现在产品中。
（2）错误：指需求是明确的，在实现阶段未将需求的功能正确实现。
（3）冗余：指需求说明文档中未涉及的需求被实现了。
（4）不满意：除了上面3种情况外，用户对产品的实现不满意也称为缺陷。
不同的企业对软件缺陷等级的划分大同小异，大致可分为5个等级。
（1）致命：指造成系统或应用程序死机、崩溃、非法退出等问题，会导致用户数据丢失或被破坏，功能设计与需求严重不符。
（2）严重：指功能和特性没有实现，导致模块功能失效或异常退出，还有程序接口错误或者数据流错误等问题。
（3）一般：指主要功能丧失，提示信息不太正确，用户界面设计太差以及删除未提示等问题。
（4）提示：指对功能几乎没有影响，产品及属性仍可使用的问题。
（5）建议：测试人员提出的建议、质疑等问题。
缺陷报告是测试执行完成后最重要的输出成果之一，一份好的缺陷报告也是提高软件质量的重要保障。
不同的公司因为缺陷管理的流程不一样，可能有不同的缺陷报告模板。但是一个完整的缺陷报告通常应该包含以下内容。
（1）编号：用数字进行唯一标识缺陷，通常是，在缺陷管理工具中新建Bug时会自动生成。
（2）状态：通常描述当前缺陷的状态，如修复、延期等。
（3）标题：通常用一句比较简洁的话来概括Bug，通过描述可以初步推测Bug形成的原因，帮助开发人员提高处理Bug的效率。
（4）类型：主要为了进一步描述缺陷产生的原因，如功能错误、接口错误、数据库错误等。
（5）所属版本：描述当前Bug所在的测试版本，便于后期回归测试时注意测试版本。
（6）所属模块：描述Bug所在的业务模块，便于后期统计缺陷的分布情况，利于回归测试的方法及测试策略的改进。
（7）严重级别：指Bug的严重程度，通常不同的Bug严重程度给软件带来的后果、风险都不一样，开发人员处理的优先级也不同。
（8）处理优先级：开发人员根据Bug的严重级别来确定处理的优先级。
（9）发现人：Bug的提交者。
（10）发现日期：一般在提交Bug时，由Bug管理工具自动生成，便于后续进行缺陷的跟踪。
（11）复现概率：指Bug重现的概率，便于开发人员定位Bug并分析。一般包括必现、偶现等。
（12）指定处理人员：根据Bug的类型指定处理人，通常指定具体的开发人员，如果是需求错误则需要指定产品经理或需求分析人员，便于后期跟踪Bug。
（13）详细描述：详细描述缺陷引发的原因以及复现步骤，需要包含测试环境、前提条件、测试数据、复现步骤、预期结果、实际结果等内容。
（14）附件：为了详细描述Bug，我们可以在描述Bug时添加一些附件信息，如截图、录屏、错误的日志信息等。
通常情况下我们把Bug分为4个类型，分别是功能、性能、安全和专项质量。功能类型关注于系统业务流程是否正确，性能类型关注于系统业务流程是否顺畅；安全类型判断系统是否存在漏洞，是否符合安全标准与规范；专项质量通常关注于系统的用户体验（UX）、兼容性、稳定性和可靠性。
软件测试人员的首要任务就是发现Bug，把发现的Bug提交给开发人员进行修复。测试人员掌握Bug定位可以在提交Bug时为开发人员提供更多有用信息，方便开发人员分析Bug的形成原因，更有效率地进行溯源并建立Bug特征，批量追踪和解决问题。
（1）条件：测试数据。 （2）过程：测试步骤。 （3）结果：测试结果。
我们把软件从技术架构层次上分为3层，即视图层（View）、控制层（Controller）和模型层（Model）。由于Web和App在具体的层次上，因此我们关注的技术方向是不同的，具体如下。
● 视图层（View），网页开发（HTML、CSS样式等），移动应用App（Activity页面、View组件等）。
● 控制层（Controller），网页开发的工具（Chrome Devtool），移动应用使用的工具。
● 模型层（Model），模型的传递方式（HTTP、TCP、RPC串口），模型的形式（JSON XML binary）。
Bug的定位往往也会依照软件技术架构层次采用MVC三层分析方法，分析View层、Controller层和Model层的运行平台、应用调试机制和链路。
View层常见的问题是用户界面（User Interface，UI）和用户体验（User Experience，UE）。目前，常采用人工测试和自动化测试，通过人工校验为主，自动化校验为辅的方式检验界面交互的准确性以及用户的体验感受。此外利用UI的Diff对比分析界面变化，定位更深层次的问题。
Controller层通过平台自主提供的日志（log）以及应用程序本身提供的应用调试日志（debug trace hook profile）分析代码层次的逻辑问题。
Model层根据运行平台的log、App调试机制以及链路来具体分析出现的问题。
（1）Web UI View层Bug分析方法
界面展示主要依赖于HTML、CSS、JS（JavaScript），可以使用Chrome开发者工具的elements和style两个板块来分析界面，elements可以展示具体控件，控件格式通过style来确定，由此来判断是否是样式、布局或输出方面的问题。如图1-43所示为style板块的内容。
图1-43
（2）Web Controller层分析方法
程序员用JavaScript根据操作流程对代码进行修改的结果，如图1-44所示，底层逻辑的错误在Console板块会展示出详细的出错信息。而用source模块可以对错误进行定位，并通过Debug分析问题存在的上下文，找到代码问题的根源所在。
图1-44
（3）Web Model层分析方法——分析数据传递方式与结构
Model层分析方法是基于运行平台的log，例如Chrome的network模块分析请求方式和数据的具体情况。链路分析使用代理工具，常用的有Fiddler、Charles和Mitmproxy以及网络层的嗅探（常用的工具有Tcpdump和Wireshark）。Chrome的network模块如图1-45所示。
图1-45
（1）App View层Bug分析
App的UI界面交互和UX/UE用户体验目前常用的是人工校验的方式，以自动化作为辅助手段，用UI Diff的方式分析，尝试发现界面中存在的问题，其中人工测试能够发现未知特征的Bug，自动化测试可以断言常用功能是否正常，通过UI Diff可以发现界面结构细节的问题。如图1-46和图1-47所示是两个存在Bug的App界面。
图1-46
图1-47
（2）App Controller层分析
通过logcat分析App runtime日志。如图1-48和图1-49所示是两个logcat的内容。
图1-48
图1-49
（3）App Model层分析方法
根据平台本身提供的log或者运行平台的调试工具，利用应用的日志，通过追踪模式分析链路问题。通过追踪模式分析链路问题，可以使用代理工具（如Charles、Fiddler、Mitmproxy、嗅探）进行抓包分析，也可以使用Wireshark、Tcpdump工具分析链路，从而找到Bug相应的日志，定位到问题，辅助开发人员尽快解决代码中的问题。
（4）Android Profile网络分析
Android提供的工具对App交互发生的网络请求进行中间过程的分析。如图1-50所示是Android Profile的分析内容。
图1-50
（5）使用代理工具分析
当工具本身不可调试时，可以使用代理工具分析。如图1-51所示是Charles代理工具。
图1-51
（6）网络层协议分析
通过Tcpdump对程序进行抓包，并导入Wireshark进行分析。如图1-52和图1-53所示是Tcpdump抓包和Wireshark分析的内容。
图1-52
图1-53
（1）H5性能分析方法
H5的性能分析方法通常对网页加载的过程进行分析，通过W3C定义的Performance API对程序每个阶段发生的问题进行统计，需要各个浏览器支持对性能方面的分析。如图1-54所示是performance API所涉及的阶段。
图1-54
（2）利用Chrome分析Web性能
图1-55所示是使用Chrome开发者工具分析出的有关Web性能的内容。
图1-55
（3）分析性能瓶颈，使用Profile进行代码剖析
图1-56所示是使用Profile进行代码分析的结果。
图1-56
（4）代码覆盖率分析方法
图1-57和图1-58所示是使用JaCoCo得到的代码覆盖率的结果。
定位Bug首先要明确Bug的特征和复现步骤，通过分层分析关键过程的数据与问题特征，积累识别Bug特征与问题根源的经验，提高发现Bug的能力。
图1-57
图1-58
被测系统（Application Under Test，AUT）包括需要被测试的App、网页和后端服务。大致分为两个方面——移动端测试和服务端测试，如图1-59所示。
（1）UI：一般有Web、App和IOT里面的用户界面交互。
（2）Service：对互联网各个端提供的服务，包括RESTful、WebService和RPC。
（3）code：直接以代码形式提供的被测系统，如SDK和lib。
图1-59
测试部署包括脚本部署和容器部署。脚本部署是基于自动化脚本和自动化平台，通过自动化脚本完成对软件的分发、配置和启动。容器部署基于容器镜像Docker。
（1）脚本部署
1）通过bash、Python等脚本实现自动化的构建与部署，如图1-60所示。
图1-60
2）通过持续集成平台，如Jenkins，完成测试流程管理，如图1-61所示。
图1-61
（2）容器部署
● 自动化构建bash。
● 容器构建Docker。
● 容器编排K8S（Kubernetes）。
● 持续集成Jenkins。
图1-62所示是容器部署的流程。
图1-62
（2）被测产品体验地址
实战演练章节需要结合本章节所学知识点，完成对不同类型产品的测试用例设计练习。
（1）被测产品介绍
某股票软件主要有以下几大板块功能，问答板块、精华板块、交易板块、股票展示板块、首页板块、话题板块。在此股票软件上，用户可以通过切换不同的板块实现不同的操作，除了查看各类型消息之外，也可以参与讨论、发帖等交互。
此系统的登录功能需求为：
● 账号是手机号或者邮箱；
● 手机号仅限为国内常用的号段；
● 密码必须为“数字+英文”的形式，字段长度为8～12个字符；
● 点击登录按钮，发起登录请求；
● 请求成功，跳转到首页；
● 点击忘记密码按钮跳转到找回密码页。
https://xueqiu.com/。
（3）测试点考查
● 理解需求后，需要完成对此系统登录功能的测试用例设计。
● 需要考虑测试用例设计全面性（等价类、边界值、判定表）。
（1）被测产品介绍
测试人论坛技术社区平台，主要为技术人员使用，技术人员作为普通用户可以在社区参与帖子的讨论，也可以发帖提出问题。社区具有分类、搜索、发帖、回帖等功能。
此系统的搜索功能需求如下。
① 入口：点击顶部栏的搜索按钮，展示搜索控件。
② 搜索控件。
● 展示搜索框，搜索框中展示默认文案，可以输入搜索关键词，回车跳转到搜索结果页。
● 点击选项按钮，跳转到搜索结果页。
③ 搜索结果页。
● 页面上部展示banner，3张图片轮播。
● banner下部展示搜索框，搜索框中展示默认文案或者搜索关键词。
● 搜索框后方展示搜索按钮。
● 右侧边栏展示高级搜索。
● 关键词搜索不到结果。
● 关键词为空，点击搜索按钮或者回车，搜索框下方展示提示文案。
● 关键词可以搜索到内容，搜索框下方展示搜索结果。
● 搜索到的结果数展示1～50条，超过50条结果时展示“50+”。
（2）被测产品体验地址
https://ceshiren.com
（3）测试点考查
● 理解需求后，需要完成对此系统搜索功能的测试用例设计。
● 需要考虑测试用例设计的全面性（等价类、边界值、判定表）。
