软件测试效率手册

版权信息

书名：软件测试效率手册

ISBN：978-7-115-49911-0

本书由人民邮电出版社发行数字版。版权所有，侵权必究。

您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。

我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。

如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。

版权

主　　编　赵 振　高 杨　李 泽

副 主 编　李福鑫　范明勇　解同磊

责任编辑　吴晋瑜

人民邮电出版社出版发行　　北京市丰台区成寿寺路11号

邮编　100164 　电子邮件　315@ptpress.com.cn

网址　http://www.ptpress.com.cn

读者服务热线：(010)81055410

反盗版热线：(010)81055315

内容提要

根据现有软件测试理论，想要全面完成一次测试，其过程比较烦琐，并且需要投入大量时间、精力等成本。基于经典的软件测试理论，本书提出一套符合“二八定律”的最佳软件测试实践方法，以指导读者进行测试。所谓“二八定律”，就是花费20%的时间、精力等成本，可以测试出80%左右的问题，有助于提升软件质量。

本书拥有大量教学案例，极易上手，并且书中提出的指导思想能够节省测试人员的精力、减少投入成本，让测试人员花较少的时间测出较多的问题，可以基本保证软件系统平稳上线。

本书适合以下几类读者阅读：大学生及想要了解软件测试系列技术的初学者；想快速了解如何使用软件测试理论来保证软件系统质量的项目经理；软件测试从业人员。本书尤其适用于规模较小的公司，可以节省成本，保证软件质量。

《软件测试效率手册》

编委会名单

主　编：赵　振　高　杨　李　泽

副主编：李福鑫　范明勇　解同磊

参　编：都姜帆　季金一　崔舒娅

　　　　杨红光　周生昌　陈其钊

　　　　徐靖皓　谢梦玮　安典龙

　　　　李新占　李妍青　吕光越

前言

作为软件项目过程中的重要环节，软件测试是对软件质量把控的最重要的一环，也是必不可少的一环。由于其复杂性、重要性，软件测试不仅在工程应用领域非常重要，同时也是学术界研究的热点方向。

从一定程度上来说，软件测试的难度、重要性和实际意义比软件设计与编程更重要。因为有一定编程经验的程序员编写程序代码以实现合同规定的需求是比较容易的，但程序员写完代码后，对代码质量如何、能否作为成品交付、还有没有问题等却一无所知。没有通过测试的软件系统绝对不能交给用户，因为可能会漏洞百出，使软件公司的专业形象一落千丈，并将大大影响客户使用的效果和体验，甚至会带来安全、经济等方面的危害与损失。

这时我们能做的，只有对软件进行测试：测出一个问题来，修改、优化这个问题；再测，再改进。也就是说，软件系统设计实现后，软件项目的推进就只能依靠软件测试了。如果软件测试环节起不到应有作用，软件项目就会停滞。如果交付未经较完备测试的软件，将直接影响软件质量。

软件测试非常烦琐，稍有不慎就会漏测，导致软件功能测试不完整，上线后出现问题。按照现有软件测试理论的指导，想要全面完成测试，需要投入大量时间。

为此，本书特总结出一套基于“二八定律”的方法论，来指导测试人员进行测试。这里所说的“二八定律”，是指花20%的时间和成本，可以测出80%的问题，基本保证软件质量合格上线。

适用读者

以下4类读者可能会对本书感兴趣。

• 大学生及想要了解软件测试系列技术的初学者。本书采用了案例教学，容易理解。此外，本书总结的根据“二八定律”进行软件测试的指导思想，是基于软件测试理论的最佳实践总结的，简单实用。
• 软件团队的项目经理，以及想要迅速了解如何使用软件测试理论保证软件系统质量的读者。
• 软件测试工作从业人员。
• 小、微型软件公司的软件从业人员。由于公司规模较小，为了节省成本，公司既没有独立组建软件测试队伍，也没有设立软件测试职位。在这些公司中，软件工程师兼具了软件测试的职责。学习本书提出的指导思想能够帮助这些公司节省精力，减少投入成本，花较少时间测出较多问题，基本保证软件系统的平稳上线。

各章内容

第1章，对白盒测试的概念，白盒测试中单元测试的定义、方法和现状，以及集成测试的定义、方法和现状进行了介绍。

第2章，对单元测试中的测试方法进行讲解，提出以“二八定律”为核心的单元测试指导思想，并在该单元测试思想的指导下设计测试用例。

第3章，对单元测试框架JUnit的安装、使用进行了讲解，并使用JUnit对第2章设计的测试用例进行测试。

第4章，对常用集成测试方法做了介绍和总结，在此基础上提出了风险模块优先、自底向上顺序集成的高效测试方法。

第5章，对Mock的概念、使用方法进行了讲解，并基于第4章提出的集成测试指导思想，使用Mock方法对案例进行了测试。

第6章，对功能测试方法和以往的功能测试指导思想进行了讲解，在此基础上提出了基于“二八定律”的功能测试指导思想，并基于该指导思想设计了贯穿案例的功能测试用例。

第7章，对自动化测试工具QTP的安装、配置和使用进行了讲解，并基于第6章中提出的指导思想使用自动化测试工具QTP对贯穿项目进行了测试。

第8章，对性能测试的概念、分类、应用场景，以及常见的术语进行了说明和阐述，并列举了开源的性能测试工具的发展与优势。

第9章和第10章，在第8章的基础上，对性能测试工具JMeter的安装、使用进行了讲解。

第11章，对Web页面测试的概念、标准，以及自动化测试工具Selenium的安装、使用进行了讲解。

第12章，对软件测试管理、测试需求管理、测试文档管理，以及测试缺陷管理进行了讲解。

第13章，对目前国内市场上比较主流的软件测试管理工具进行了介绍，并对第14章中案例所用的TestLink和Mantis两款软件测试管理工具的优越性进行了分析。

第14章，结合贯穿案例对TestLink和Mantis两款软件测试管理工具的安装、配置、使用、测试管理过程进行了讲解。

资源与支持

本书由异步社区出品，社区（https://www.epubit.com/）为您提供相关资源和后续服务。

提交勘误

作者和编辑尽最大努力来确保书中内容的准确性，但难免会存在疏漏。欢迎您将发现的问题反馈给我们，帮助我们提升图书的质量。

当您发现错误时，请登录异步社区，按书名搜索，进入本书页面，点击“提交勘误”，输入勘误信息，单击“提交”按钮即可。本书的作者和编辑会对您提交的勘误进行审核，确认并接受后，将赠予您异步社区的100积分（积分可用于在异步社区兑换优惠券、样书或奖品）。

与我们联系

我们的联系邮箱是contact@epubit.com.cn。

如果您对本书有任何疑问或建议，请发邮件给我们，并在邮件标题中注明本书书名，以便我们更高效地做出反馈。

如果您有兴趣出版图书、录制教学视频，或者参与图书翻译、技术审校等工作，可以发邮件给我们；有意出版图书的作者也可以到异步社区在线提交投稿（直接访问www.epubit.com/selfpublish/submission即可）。

如果您来自学校、培训机构或企业，想批量购买本书或异步社区出版的其他图书，也可以发邮件给我们。

如果您在网上发现有针对异步社区出品图书的各种形式的盗版行为，包括对图书全部或部分内容的非授权传播，请您将怀疑有侵权行为的链接发邮件给我们。您的这一举动是对作者权益的保护，也是我们持续为您提供有价值的内容的动力之源。

关于异步社区和异步图书

“异步社区”是人民邮电出版社旗下IT专业图书社区，致力于出版精品IT技术图书和相关学习产品，为作译者提供优质出版服务。异步社区创办于2015年8月，提供大量精品IT技术图书和电子书，以及高品质技术文章和视频课程。更多详情请访问异步社区官网https://www.epubit.com。

“异步图书”是由异步社区编辑团队策划出版的精品IT专业图书的品牌，依托于人民邮电出版社近30年的计算机图书出版积累和专业编辑团队，相关图书在封面上印有异步图书的LOGO。异步图书的出版领域包括软件开发、大数据、AI、测试、前端、网络技术等。

异步社区

微信服务号

1　白盒测试基础知识

1.1　白盒测试简介

1.2　白盒测试的分类

白盒测试是软件测试中非常重要的一部分，本章将介绍白盒测试的概念，进而对白盒测试中的单元测试和集成测试作初步的介绍。

1.1　白盒测试简介

1.1.1　白盒测试的定义

白盒测试是代码层面的测试。“白盒”指的是把被测试的代码看作一个打开的盒子，要求测试人员对被测试代码的内部逻辑非常熟悉，因此，进行白盒测试一般以软件开发人员为主。白盒测试要求测试人员根据被测试代码的流程图编写测试用例，对被测试代码中重要的业务逻辑进行测试，验证业务逻辑中的分支条件是否得到满足、执行路径是否按预定的要求正确工作。

1.1.2　与黑盒测试的区别

与白盒测试相对的是黑盒测试。黑盒测试是在不考虑程序内部逻辑的情况下，检查程序的功能是否按照需求规格说明书的规定正常使用。与黑盒测试相比，白盒测试具有以下两个优点。

（1）白盒测试在代码层面对程序中重要的业务逻辑的分支条件、执行路径进行细致的检查，不仅要保证程序能干什么，还要保证程序不能干什么，以提高程序的健壮性和稳定性。

（2）白盒测试要求开发人员绘制程序的流程图，帮助开发人员发现业务逻辑中的瑕疵与错误，修改和优化业务逻辑中不合理的部分，促使开发人员编写高质量的代码。

与黑盒测试相比，白盒测试还具有以下两种局限性。

（1）白盒测试是代码层面的测试，不对需求规格说明书等文档进行检验，不能检查出被测试代码遗漏的功能。例如，按照需求规格说明书程序要实现四个功能，但在实际开发时程序只实现了两个功能，那么进行白盒测试时，只能对已经实现的两个功能进行测试，不能测试出该代码是否按照规格说明书的要求实现了四个功能。

（2）盲目的白盒测试性价比不高。在没有好的指导思想引领的情况下，只能根据测试人员的测试经验进行白盒测试，会导致测试人员漫无目的地编写大量测试用例，导致费时费力且测试效果不明显。

1.2　白盒测试的分类

根据测试粒度的大小，可将白盒测试分为单元测试和集成测试，其中集成测试的粒度大于单元测试。本节将对单元测试和集成测试的定义、测试方法及现状进行概要介绍。

1.2.1　单元测试

1．单元测试的定义

单元测试是指对软件中最小的可测单元进行测试，最小的可测单元可以是一个方法，可以是一个函数，也可以是包含多个函数的一个功能，单元的划分要根据程序具体的情况确定。一般情况下，单元测试由开发人员完成，与非开发人员相比，开发人员对代码的内部逻辑结构更加了解，对测试单元的划分更加明确，能够更有针对性地进行单元测试。由于集成测试的粒度大于单元测试，在一般情况下，我们先进行单元测试再进行集成测试，因此，单元测试与集成测试相比，能够较早地发现软件的缺陷且可以比较精确地确定出程序出现缺陷的范围。

2．单元测试中的方法

单元测试中的方法有代码走查法、插桩法和逻辑覆盖法。

（1）代码走查法

代码走查是单元测试的第一步，通过人工静态检查的方式，保证代码逻辑的正确性、项目的规范性。

（2）插桩法

插桩法是一种被广泛应用的测试方法，通过向程序中插入打印语句或设置断点的方式来获取程序的动态信息。通过插桩法，我们既能检验测试的结果，又能借助打印的信息掌握程序的运行状态。

（3）逻辑覆盖法

逻辑覆盖法是以程序内部的逻辑结构为基础来设计测试用例的方法，即根据程序的顺序、分支和循环3种基本结构的特性设计测试用例。在逻辑覆盖法中，又包含语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖等6种覆盖测试方法。

3．单元测试的现状

单元测试的测试用例设计要求保证测试时程序的所有语句至少执行一次，而且要检查所有逻辑条件，因此导致许多开发人员认为单元测试费时费力并且测试效果不明显。现阶段，由于开发人员不了解单元测试的重要性，或缺少高效的指导思想引领测试人员编写测试用例，许多开发人员都不进行单元测试，这是当前单元测试的现状。因此，找到高效的单元测试指导思想，能使开发人员在短时间内测试较少的代码并得到最佳测试效果，对提高单元测试在开发人员心中的认可度是非常有必要的。在第2章中，我们将提出事半功倍的单元测试指导思想。

1.2.2　集成测试

1．集成测试的定义

集成测试，也叫组装测试，是指在单元测试的基础上，将所有模块按照设计要求组装成为子系统或整体系统来进行测试活动。用单独类调试系统时无法发现的问题，在把模块组装成子系统或整体系统后很可能展现出来，这会影响系统功能的运转，进而影响产品交付时间。因此，单元测试完成后，有必要进行各个类之间的集成测试，发现并排除在调用类的过程中可能发生的问题，最终完善整个系统，成功交付产品。

2．集成测试的方法

针对传统软件的集成测试主要有非增量式集成和增量式集成两种方法，其中增量式集成测试还分为自顶向下和自底向上两种集成策略。其他常用的集成测试策略还有“三明治”集成、基于风险的集成和基于功能的集成等。

对于Web系统的集成测试方法主要有基于线程的测试和基于使用的测试，测试过程中主要用到静态测试和动态测试两种方案。

集成测试在白盒测试中主要用到的技术是Mock，有关Mock的知识将在本书第5章中介绍。

3．集成测试的现状

随着软件行业的发展以及智能PC的兴起，越来越多的Web系统和PC端软件被开发出来，其质量上的一些问题也逐渐暴露出来，影响软件的验收和用户的体验。由此可以看出软件测试对于保证软件质量具有多么重要的意义。但是我国软件行业仍处于发展的初期阶段，我国大部分的软件企业仍然存在着重开发、轻测试、单一追求实现功能需求的现象，这给软件质量的保证和软件行业的发展带来了极大的风险和极为不利的影响。调研结果显示，我国软件企业未设置独立测试部门的比重大约为50%，软件测试人员与软件开发人员的比例在1:5左右，这与美国与印度1:1的比例相差甚远，软件测试行业存在严重缺陷。

在软件测试的周期中，集成测试在单元测试之后，大约占整个软件开发周期的25%，而通过各家软件公司开发实践证明，集成测试进行的好坏将直接影响软件的质量。一些软件总是出现故障，就是因为集成测试不过关甚至未进行，由此可见集成测试在软件开发中的重要地位。

所有的软件项目都不能摆脱系统集成这个阶段。不管采用什么开发模式，具体的开发工作总得从一个个软件单元做起，软件单元只有经过集成才能形成一个有机的整体。具体的集成过程可能是显性的，也可能是隐性的。只要有集成，就会出现一些常见的问题，工程实践中，几乎不存在软件单元组装过程中不出任何问题的情况。因此，一个软件项目的开发过程离不开集成测试。

2　单元测试

2.1　已有的单元测试方法简介

2.2　以往单元测试方法的弊端

2.3　以“二八定律”为目标的单元测试指导思想

2.4　基于“二八定律”的单元测试指导思想的最佳实践

单元测试是白盒测试中的重要部分。本章将详细介绍单元测试的测试方法，分析以往的单元测试方法中存在的弊端，提出以“二八定律”为核心的、事半功倍的单元测试指导思想，并在该单元测试指导思想的指导下设计测试用例。

2.1　已有的单元测试方法简介

2.1.1　代码走查法

代码走查是单元测试的第一步，此阶段的工作主要是检查代码的逻辑正确性、代码和设计的一致性、代码对标准的遵循、代码的可读性和代码结构的合理性等方面。

代码走查主要对以下几方面进行检查。

（1）检查代码的逻辑正确性。确定代码中业务逻辑是否与设计方案保持一致，重点检查分支、循环等结构。

（2）检查输入参数有没有进行正确性检查，确定输入参数是否需要进行正确性检查，重点检查敏感参数以及可能为空或null的参数。

（3）检查异常处理。检查代码中能预见出错的条件是否设置了异常处理，以便程序一旦出错能够处理错误，保证程序的正常运行，增强程序的健壮性。

（4）检查表达式、SQL语句的正确性。检查、验证程序中的SQL语法是否正确，能否实现预定的功能。对于容易产生歧义的表达式或运算符优先级（如<、=、>、&&、||、++和--等）重点进行检查，确保表达式无二义性。

2.1.2　插桩法

在单元测试过程中，我们往往需要知道程序动态运行的状态以及一些中间变量等动态信息。为了获取这些我们最关心的动态信息，需要在代码中插入打印语句或通过开发工具打断点的方式来获取这些信息。

设计插桩测试用例时需要注意以下两个问题。

（1）获取哪些信息。对于获取哪些信息，需要具体问题具体分析，一般情况下会获取中间变量的值、表达式运算结果、程序的执行路径等信息。

（2）在被测试代码的什么部位插入打印语句或通过开发工具打断点：

• 在for、whlie、do-while等循环结构中，用于获取循环判断条件、循环结束时的变量值；
• 在if、else、else if等分支结构中，用于获取程序的执行路径；
• 在赋值语句、表达式、调用子函数之后，用于获取赋值语句的返回值、表达式的返回值、子函数的返回值；
• 在被调用子函数的第一个语句之前，用于验证被调用的子函数是否执行。

2.1.3　逻辑覆盖法

用例设计如下。

用例设计如下。

逻辑覆盖测试是通过对程序逻辑结构的遍历实现程序的覆盖。根据覆盖被测试代码的不同程度，可以将其分为以下6种覆盖方法：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。下面将结合具体的案例详细介绍这6种覆盖方法。

具体案例如下。

public class TestDemo {

     //定义a,b,x变量
     private int a;
     private int b;
     private int x;

     //构造函数
     public TestDemo(inta, intb, intx){
     this.a= a;
     this.b= b;
     this.x= x;
         }

     //测试函数
     public intdemo1(){
     if(a>1 &&b==0){
     x = x/a;
             }
     if(a == 2 || x>1){
     x = x+1;
             }
     return x;
         }
     }

该案例所对应的流程如图2-1所示。

图2-1　案例对应的流程

1．语句覆盖

主要特点：语句覆盖要求设计足够多的测试用例，使得程序中每条语句至少执行一次。

优点：可以很直观地从程序源码中得到测试用例，无须细分每个条件判定。

缺点：从上例可以看出，语句覆盖实际上是很弱的。

（1）如果第一个条件语句中的“&&”被误写成“||”，那么上面的测试用例是无法发现这个错误的。

（2）又如第三个条件语句中“X＞1”被误写成“X＞0”，上面的测试用例也无法发现这个错误。

2．判定覆盖

主要特点：判定覆盖要求设计足够多的测试用例，使得程序中每个判定的真假分支至少执行一次。

用例设计如下。

优点：判定覆盖使每个分支都执行过了，那么每个语句也就执行过了，因此判定覆盖的测试能力强于语句覆盖。

缺点：判定覆盖的测试能力还是不够强。大部分的判定语句是由多个逻辑条件组合而成的，如果仅仅判断这个判定的结果而忽略各个判定中每个条件的取值情况，一定会遗漏部分路径。

3．条件覆盖

主要特点：条件覆盖要求设计足够多的测试用例，使得每个判定中的每个条件获得各种可能的结果，即每个条件至少有一次为真值，有一次为假值。

用例设计如下。

优点：条件覆盖保证了每个判定中的每一个条件都得到了两个不同的结果，而判定覆盖则不保证这一点，因此条件覆盖的测试能力强于判定覆盖。

缺点：要达到条件覆盖要求设计足够多的测试用例，但是条件覆盖不能保证包含判定覆盖，例如上文中的两个测试用例都没有覆盖判定（A>1 &&B==0）为真的情况。

4．判定/条件覆盖

主要特点：判定/条件覆盖要求设计足够多的测试用例，使得每个判定中每个条件的所有可能结果至少出现一次，每个判定本身的所有可能结果也至少出现一次。

优点：判定/条件覆盖既满足判定覆盖标准，又满足条件覆盖标准，弥补了二者的不足。

缺点：从表面上看判定/条件覆盖测试了所有条件的取值，但是采用判定/条件覆盖不一定能测试出逻辑表达式中的错误。

（1）对于第一个表达式（A>1 && B==0），如果A>1为假，那么编译器认为表达式的结果为假，这时不再检查B==0条件是否成立。

（2）对于第二个表达式（A=2 || X>1），如果A=2为真，那么编译器认为表达式的结果为真，这时不再检查X>1条件是否成立。

5．条件组合覆盖

主要特点：条件组合覆盖要求设计足够多的测试用例，使得每个判定中条件结果的所有可能组合至少出现一次。

用例设计：我们要选择适当的测试用例，使得以下8种条件组合能够出现。

a. A>1，B=0　　b. A>1，B≠0　　c. A1，B=0　　d. A1，B≠0

e. A=2，X>1　　f. A=2，X1　　g. A≠2，X>1　　h. A≠2，X1

优点：条件组合覆盖满足了判定覆盖、条件覆盖和判定/条件覆盖标准。

缺点：条件组合覆盖并不能覆盖每一条路径，例如上文中的测试用例就没有覆盖abef路径；另外，条件组合覆盖线性地增加了测试用例的数量。

6．路径覆盖

主要特点：路径覆盖要求设计足够多的测试用例，以覆盖程序中所有可能的路径。

用例设计如下。

优点：路径覆盖可以对程序进行比较彻底的测试，比语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖和条件组合覆盖等5种覆盖测试的测试能力都强。

缺点：由于路径覆盖需要对所有可能的路径都进行测试，因此需要设计大量的测试用例，这使得设计测试用例的工作量呈指数级增长。

2.2　以往单元测试方法的弊端

以往的单元测试的指导思想如下。

（1）保证一个模块中的所有独立路径至少被使用一次。

（2）对所有逻辑值均需测试true和false。

（3）在上下边界及可操作范围内运行所有循环。

（4）检查内部数据结构以确保其有效性。

毫无疑问，上述指导思想对于测试业务逻辑简单的程序是可行的，而在实际开发中，被测试代码的业务逻辑一般比较复杂，测试人员不可能穷举所有路径，也不能测试所有逻辑值以及所有循环，因此以上单元测试指导思想在实际的单元测试中是不可行的，它仅仅指定了一个理想的测试目标，并没有提出切实可行、能够达到该测试目标的测试方案。

因此，非常迫切需要一套切实可行、花费测试人员最少的精力得到最好的测试效果的测试方案。我们以“二八定律”为目标，提出了更加简单高效的单元测试指导思想。

2.3　以“二八定律”为目标的单元测试指导思想

为了解决以往的单元测试指导思想不切实际的问题，我们提出了以“二八定律”为目标的单元测试指导思想。在该指导思想的指导下进行测试，能够达到花费20%的精力测出80%问题的目标。该指导思想的具体内容如下。

（1）单元测试应由开发人员完成，因为开发人员比其他非开发人员更加清楚被测试代码的业务逻辑，知道测试的重点应该放在哪个部分，知道怎样测试效率较高。

（2）只有当开发人员认为自己开发的代码已经实现了预期的功能并且能够正常运行时，方可进行单元测试。单元测试不宜开始过早，开始过早会导致将调试阶段的问题堆积到测试阶段解决，降低了单元测试的效率。

（3）能够使用黑盒测试通过审核的就不要用单元测试。单元测试尽量只用于核心功能和逻辑较复杂的代码测试，以Java Web项目为例，像与页面显示相关的HTML和JSP、逻辑功能简单的DAO层等，这些功能单元一般不需要进行单元测试，只需进行黑盒测试即可。

（4）测试方法一般以判定覆盖、条件覆盖、判定/条件覆盖为主，条件组合覆盖和路径覆盖这两种测试方法由于设计测试用例的工作量较大，一般情况下不会被选用。

• 如果测试代码中的每个判定只有一个条件，一般情况下，选用判定覆盖即可。
• 如果测试代码中的每个判定含有多个条件，但是其中没有“&&”与“||”同时出现、只有“&&”或“||”连接多个条件，一般情况下，如果条件个数不多，那么选用条件组合覆盖，如果条件个数很多，那么选用判定/条件覆盖。
• 如果测试代码中的判定含有多个条件，并且条件之间既有“&&”又有“||”，一般情况下，选用判定/条件覆盖。

上述单元测试的指导思想只对大多数的项目具有指导意义，并不适合所有项目，读者在进行实践时要注意结合项目的具体情况进行取舍。

2.4　基于“二八定律”的单元测试指导思想的最佳实践

2.4.1　测试步骤

单元测试指导思想对高效地进行单元测试具有重要指导意义，是对如何进行单元测试的高度概括。要进行具体的测试，我们还要设计具体的测试步骤。基于单元测试指导思想的测试步骤如下。

（1）画出业务逻辑流程图。

（2）根据代码的具体情况，结合单元测试的指导思想选定覆盖测试方法。

（3）根据选定的覆盖测试方法，结合业务流程选取测试数据并设计测试用例。

（4）在JUnit下使用参数化测试和断言对代码进行测试。

2.4.2　单元测试案例简介

本节将在单元测试指导思想的基础上，对本书开篇介绍的系统进行单元测试。根据单元测试的指导思想，我们需要对代码中的核心功能（即查询）进行测试。

查询功能是根据表单（form）提交的起始日期（startTime）、终止日期（endTime）、SIM卡号（gprsNum）、一维码（one_dimensional_Code）、产品型号（PRODUCT_TYPE）等查询条件的组合情况去MongoDB数据库中查询出符合条件的数据并在页面上显示，如图2-2所示。其中，查询条件共有5种组合情况。

图2-2　查询页面

（1）查询条件都为空，查询出所有数据并在页面上显示。

（2）SIM卡号和起始日期、终止日期不为空，查询出符合这3个条件的数据并在页面上显示。

（3）一维码和起始日期、终止日期不为空，查询出符合这3个条件的数据并在页面上显示。

（4）产品型号不为空，查询出符合该条件的数据并在页面上显示。

（5）起始日期和终止日期不为空，其他条件均为空，查询出符合该条件的数据并在页面上显示。

2.4.3　测试用例

本节将对上文中介绍的查询功能进行单元测试，重点介绍测试用例的设计流程。下面将根据单元测试的步骤设计该查询功能的测试用例。

1．画出查询功能的业务逻辑流程图

为了方便后边的逻辑覆盖测试，理顺程序的流程，我们需要先画出被测试代码的业务逻辑流程图。查询功能的业务逻辑流程如图2-3所示。

图2-3　查询功能的业务逻辑流程

2．根据查询功能的业务逻辑，结合单元测试的指导思想选定覆盖测试方法

查询功能的每个判定的条件为多个，在5个判定中，判定B、判定C和判定E中既有“&&”又有“||”，因此根据单元测试的指导思想，选用判定/条件覆盖测试方法进行单元测试。

3．根据选定的判定/条件覆盖测试方法，结合查询功能的流程设计测试用例

具体的测试用例如表2-1所示。

表2-1　测试用例