软件测试实验教程(txt+pdf+epub+mobi电子书下载)

作者：朱少民,吴振宇,马海霞,蔡秋亮,蒋琦,王新颖,刘冉

出版社：清华大学出版社

格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT

软件测试实验教程试读：

前言

如今，软件开发模式从传统的瀑布模式已转向敏捷开发模式，软件开发和软件测试越来越趋于融合，这也意味着不仅专职的测试人员要开展软件测试工作，而且开发人员也要从事测试相关的工作。从这个角度看，单元测试就显得更为重要，在软件测试教学中需要进一步加强。况且，在校的大学生对业务的感受比较少，但他们对代码更熟悉、更感兴趣，更容易接受单元测试，这和业界的需求也正好一致。为此，本实验教材重视单元测试，为单元测试共设计了7个实验，不仅包括逻辑覆盖（如语句覆盖、判定覆盖、条件覆盖、MCDC等）的测试设计、动态测试等实验，而且包括静态测试分析工具的实验。考虑到大多数学校开设了C/C++、Java编程的课程，动态测试工具选择了JUnit和CppUnit。在敏捷开发中，持续集成是最重要的、优秀的开发实践之一，为此增加了基于Jenkins的集成测试实验作为集成测试的关键实验。所以，在第1篇单元测试与集成测试实验中共设计了8个实验，分别是：

◇实验1：语句和判定覆盖测试设计

◇实验2：条件覆盖和条件组合覆盖测试设计

◇实验3：修正条件／判定覆盖测试设计

◇实验4：基于JUnit的单元测试

◇实验5：基于CppUnit的单元测试

◇实验6：基于JavaScript的单元测试

◇实验7：基于PMD的静态测试

◇实验8：基于Jenkins的集成测试

目前，Windows应用越来越少，而Web应用、移动App应用成为主流，所以在系统测试中主要以Web应用、移动App应用作为测试的对象（案例），开展系统的功能测试、性能测试、安全性测试、兼容性测试等。这类实验不仅要求学生能够进行测试分析、测试设计，而且要求学生能够开发自动化测试脚本，借助测试工具来完成测试脚本的执行与结果分析。从测试分析与设计的方法、思路上看，在不同的平台上（Web、移动App、Windows桌面、Mac OS桌面等）系统的功能性测试和非功能性测试基本是一致的。如果学生要开展Windows或Mac OS桌面的系统测试实验，也可以参照Web应用、移动App应用的相关实验，并利用网络资源，做到举一反三，完成相应的实验。如果确实有困难，可以发邮件到Kerryzhu@tongji.edu.cn提出问题，我们会给予解答。根据大家的反映，如果这类需求还比较多，我们将在本书第2版增加Windows桌面、Mac OS桌面的相关测试实验。目前，我们在第2、3篇共设计了7个系统测试的实验，分别是：

◇实验9：Web应用的功能测试

◇实验10：Web应用的性能测试

◇实验11：Web应用的安全性测试

◇实验12：移动App功能与兼容性测试

◇实验13：移动App功能自动化测试

◇实验14：移动App代码反编译安全测试

◇实验15：移动App敏感信息安全测试

上述15个实验可以被看作软件测试教学的基本实验，可在基础教学计划中安排这些实验。但为了使教材内容相对完整，并照顾某些有测试方向的学校，增加了几个其他实验，覆盖验收测试、利用虚拟技术搭建测试环境等方面的内容。现在开源测试工具或框架很多，是在校学生很好的学习资源。针对开源测试工具的分析能够一举两得，既进一步了解测试工具的实现机制、对测试有更深的探讨与研究，又能学习开源框架的优秀编程实践，提升开发能力，为此特地增加了“开源测试框架Fitnesse的解析”实验。总之，在最后一篇，我们设计了4个实验，分别是：

◇实验16：基于Fitnesse的验收测试实验

◇实验17：开源测试框架Fitnesse的解析

◇实验18：搭建虚拟测试环境

◇实验19：系统安装／卸载和兼容性测试实验

本教材的每个实验，首先会说明实验目的、实验前提、实验内容、实验环境，让教师先检查一下是否具备这些条件和环境，明确实验目的和内容，然后再开始实验。如果不具备实验条件或环境，可先做些准备工作。每个实验在简要叙述实验环节之后给出详细的实验操作过程，教师和学生可以按教材的详细过程一步一步进行实验。实验需要安装的文件或文档，统一放在清华大学出版社网站（www.tup.com.cn），大家可以自行下载。

参与本教材编写的（按拼音顺序）有包蕾、蔡秋亮、陈林儿、姜华军、蒋琦、蒋兴、李燕青、林建宇、刘冉、刘涛、马海霞、王新颖、吴振宇、姚煌杰、郑碧娟、朱少民。

由于水平以及大家投入的时间都有限，教材中难免存在一些问题，希望大家不吝赐教，我们将尽力改正，力求不断推出更高质量的教材。编者　于丁酉年第1篇单元测试与集成测试实验单元测试是软件开发和系统测试的基础，只有每个单元模块得到了充分的测试，系统测试才能相对轻松地完成，否则系统测试变得没有止境，缺陷永远找不完。作为开发人员，需要对自己所写的代码负责，也需要做单元测试。单元测试一般和编程同步进行，写完一段代码，就要进行单元测试。相对来说，软件的单元规模很小，可以精确、有效、完整地进行测试，也比较容易进行测试覆盖率的分析，通过不断改进测试，最终可以达到所需的测试覆盖率。从测试充分性看，单元测试可以更好地帮助我们保证软件产品质量。单元测试，除了人工的代码评审，其他的测试（代码静态分析、动态测试等）都属于自动化测试范畴，通过工具和脚本自动完成。单元测试的实验，从代码行覆盖／判定覆盖开始，逐步深入到条件覆盖、条件／判定覆盖、组合覆盖和MC/DC覆盖、基本路径覆盖等，并结合PMD、JUnit、CppUnit等单元测试工具，完成实际代码的测试，其中包括测试覆盖率的度量和分析，并把TDD/ATDD/BDD、类、包的测试和Mock技术的运用等更复杂的单元测试留给大家练习与思考。本篇主要开展单元测试实验。通过这些实验，提高同学们的单元测试能力，并巩固结构化测试方法的应用。◇实验1：语句和判定覆盖测试设计◇实验2：条件覆盖和条件组合覆盖测试设计◇实验3：修正条件／判定覆盖测试设计◇实验4：基于JUnit的单元测试◇实验5：基于CppUnit的单元测试◇实验6：基于JavaScript的单元测试◇实验7：基于PMD的静态测试◇实验8：基于Jenkins的集成测试实验1　语句和判定覆盖测试设计1.1　实验目的（1）巩固所学的语句覆盖和判定覆盖测试方法；（2）提高运用语句覆盖和判定覆盖测试方法的能力。1.2　实验前提（1）掌握语句覆盖和判定覆盖的基本方法、概念；（2）熟悉程序语言的逻辑结构与基础知识；（3）选择一段程序语言。1.3　实验内容

以保险产品投保为实例，针对保险产品投保业务逻辑代码进行分析，运用语句覆盖和判定覆盖法进行测试用例设计。

某个人税收优惠型保险产品A/B1/B2/C款承保规则：（1）凡16周岁以上且投保时未满法定退休年龄的（男性为59周岁、女性为54周岁，后续将随国家相关法规做相应调整），适用商业健康保险税收优惠政策的纳税人，可作为本合同的被保险人。保险公司根据被保险人是否参加公费医疗或基本医疗保险确定适用条款。（2）被保人为健康体，或者参加医疗保险的，可选择A款、B1款或B2款。（3）未参加公费医疗的非健康体（有既往症）只能选择C款。

以下为个人税收优惠型保险产品承保的部分伪代码实现：1.4　实验环境（1）首先要让学生了解保险产品投保业务场景，能够模拟操作保险产品的承保流程；（2）能够将业务场景与代码逻辑关系对应；（3）根据代码画出程序流程图，并分析各判定节点；（4）根据代码流程图分析出判定条件与真假取值。1.5　实验过程简述（1）明确被测试对象使用的测试方法；（2）小组讨论业务场景并进行分析；（3）测试实施工作安排；（4）评审程序流程图和测试用例；（5）执行测试，根据测试用例代入各条件测试数据，给出测试结果。1.6　测试过程实施

1. 测试分析（1）根据保险产品的承保业务描述，分析产品承保流程，包括主流程、分支流程以及正常流程、异常流程。（2）模拟保险产品承保场景：触发允许产品承保的条件，不同条件是否走不同的承保流程。（3）数据项检查：数据项的计算规则，数据项后台判断逻辑。

2. 测试设计

根据产品承保代码，设计出程序流程图，并对程序流程图做节点标记，分析图1-1所示的两个判定： 判定A:(性别="男"AND 16＜年龄＜59)OR(性别="女"AND 16＜年龄＜54) 判定B:健康体OR有医疗保险

3. 测试设计

根据业务场景与流程逻辑判定，运用语句覆盖法进行用例设计。

语句覆盖是一个比较弱的逻辑覆盖标准，通过选择足够多的测试用例，使得被测试程序中的每个语句至少被执行一次。根据如图1-1所示的流程图，为使程序中的每个语句至少执行一次，只需设计两个测试用例，覆盖语句A、B、C、E，即覆盖判定A“成立”、判定B“成立”或“不成立”各被覆盖一次，如表1-1所示。图1-1　流程图表1-1　语句覆盖测试用例设计

接下来我们运用判定覆盖法来进行用例设计。判定覆盖又称为分支覆盖，判定覆盖语句覆盖的标准稍强一些，它是指通过设计足够多的测试用例，使得被测试程序中的每个判定（即上述判定A、判定B）都获得一次“真”“假”值，如表1-2所示。表1-2　判定覆盖测试用例设计

4. 测试结果分析

从本实验可看出，语句覆盖实际上是很弱的，CASE1、CASE2可以满足语句覆盖，但如果第2个条件语句中OR写成了AND，CASE1、CASE2都不能发现它。“判定覆盖”比“语句覆盖”严格，因为如果每个分支都执行过了，则每个语句也就执行过了。但是，“判定覆盖”还是不够的，例如，CASE3~CASE5未能检查AB分支中女性被保人的承保情况。1.7　实例练习（1）程序实例，计算个人所得税。（2）请根据程序实例（表1-3），设计语句和判定覆盖的测试案例。表1-3　条件分析实验2　条件覆盖和条件组合覆盖测试设计2.1　实验目的（1）巩固所学的条件覆盖、条件组合覆盖测试方法；（2）提高运用条件覆盖、条件组合覆盖法的能力。2.2　实验前提（1）掌握逻辑覆盖的基本方法、概念；（2）熟悉程序语言的逻辑结构与基础知识；（3）选择一段程序语言。2.3　实验内容

以银行内部转账为实例，针对内部转账业务逻辑代码进行分析，运用条件覆盖进行测试用例设计。

内部转账用于处理发起户口号和接收户口号都是内部账户的系统内资金转账业务，主要用于财务资金的划拨、未实现自动清算业务的清算资金的划拨。（1）内部转账发起是指：发起行发出内部资金交易，并换人复核，满足条件时需会计主管授权。（2）内部转账接收是指：内部资金交易接收方根据接收方确认方式，对交易进行接收经办，满足条件的需复核或授权。

确定接收方的入账流程，“确认方式”分为以下三种：（1）不需接收方确认，即发起方发起后自动记发起方和接收方的一套账务，接收方无须再做接收动作。（2）需接收方确认，即接收方接收时不能更改接收信息，只能依据发起方输入的信息入账或退发起方。以目前的处理方式，接收经办→入账（金额小于100万元），大于100万元时为接收经办＋接收授权→入账。（3）需接收方经办，即接收方接收时可以更改接收信息，执行入账或退发起行。以目前的处理方式，接收经办＋接收复核→入账（金额小于100万元），大于100万元时为接收经办＋接收复核＋接收授权→入账。

内部转账权限控制如表2-1所示。表2-1　内部转账权限控制

以下为银行内部转账控制的部分伪代码实现：2.4　实验环境（1）首先要让学生了解银行内部转账业务，能够模拟操作转账流程；（2）能够将业务场景与代码逻辑关系对应；（3）根据代码画出程序流程图，并分析各判定节点；（4）根据代码流程图分析出条件覆盖、条件组合覆盖。2.5　实验过程简述（1）明确被测试对象使用的测试方法；（2）小组讨论业务场景并进行分析；（3）测试实施工作安排；（4）评审程序流程图和测试用例；（5）执行测试，根据测试用例代入各条件测试数据，给出测试结果。2.6　实验过程实施

1. 测试分析（1）根据银行内部转账业务描述，分析内部转账流程，包括主流程、分支流程以及正常流程、异常流程。（2）模拟内部转账场景：触发内部转账的条件，不同条件是否走不同的转账流程。（3）数据项检查：数据项的计算规则，数据项后台判断逻辑。

2. 测试设计

根据内部转账业务需求，设计出程序流程图，如图2-1所示，并对程序流程图做节点标记，分析流程图的判定条件与结果。

3. 测试执行

根据业务场景与流程逻辑判定，运用条件覆盖法进行用例设计。图2-1　程序流程图A~Q为测试路径编号，在下面的测试用例分析中将根据测试路径编号确定测试用例的业务流向。

条件覆盖即设计足够多的测试用例，运行被测程序，使得每一判定语句中每个逻辑条件的可能取值至少满足一次。条件覆盖率的公式是：条件覆盖率＝被评价到的条件取值的数量／条件取值的总数×100%。具体地说，就是在各种条件中，不考虑条件组合的因素，对每一个条件变量分别只取真假值一次，使得被测试程序中的每个条件取值至少被覆盖一次。

条件组合覆盖是通过设计足够多的测试用例，使得被测试程序中每个判断的所有可能条件取值的组合至少出现一次。

注意：（1）条件组合只针对同一个判断语句内存在多个条件的情况，让这些条件的取值进行笛卡儿乘积组合。（2）不同的判断语句内的条件取值之间无须组合。（3）对于单条件的判断语句，只需要满足自己的所有取值即可。

测试的依据是需求与设计文档，根据程序流程图实现。（1）条件覆盖

银行内部转账流程在不考虑判定、仅考虑条件分支的情况下，条件分支数为5，即T1~T5。在条件覆盖中只考虑每个判定语句中的每个表达式，没有考虑各个条件分支。

根据图2-1所示的流程图，标记出节点。根据条件覆盖方法来进行分析，得到如表2-2所示的符合条件覆盖标准的测试用例。表2-2　符合条件覆盖标准的测试用例

S(2)条件组合覆盖

对于判定1：

①条件转账金额＞100W　取真为T1

②条件转账金额＜=100W　取假为F1

对于判定2：

①条件“确认方式”==1　取真为T2

②条件“确认方式”==2　取真为T3

③条件“确认方式”==3　取真为T4

④条件T2、T3和T4都不成立　取假为F2

对于判定3：

①条件“确认方式”==2　取真为T5

②条件“确认方式”==3　取真为T6

③条件T5和T6都不成立　取假为F3

通过设计足够多的测试用例，使得被测试程序中的每个判断的所有可能条件取值的组合至少出现一次。在这个银行内部转账流程上，判定1的条件和判定2、3中的条件分别构成组合。由于业务特定的逻辑，其组合简化为7个，而不是14个。

①判定1的条件T1和判定3中的各个条件构成组合，即3个组合，而不是2×3=6个组合；

②判定1的条件F1和判定2中的各个条件构成组合，即4个组合，而不是2×4=8个组合。

因此根据条件组合覆盖，总共有7个测试用例完成组合覆盖，如表2-3所示。这里不考虑异常情况，如转账金额＜=0的情况。遇到这种情况会直接异常退出，也无法进入下一个判定2或判定3，和组合也没关系。表2-3　符合条件组合覆盖度量标准的测试用例

4. 测试结果分析

从实验2项目案例中可以看出，条件覆盖仅考虑单个条件取真或取假一次，覆盖度相对较弱。如果想增强覆盖度，可以将本实验的条件覆盖和实验1的判定覆盖结合起来，构成更强的覆盖，即条件-判定覆盖。如果还想达到更高质量的要求，可以设计足够的测试用例达到组合覆盖测试。但条件组合的测试有些冗余，效率偏低。在这种情况下就要考虑到修正条件／判定覆盖来设计测试用例。2.7　实例练习（1）程序实例：企业发放的奖金根据利润提成。（2）请根据以上程序设计条件、判定条件、条件组合判定覆盖方法测试用例。实验3　修正条件／判定覆盖测试设计3.1　实验目的（1）巩固所学的修正条件／判定覆盖测试；（2）提高运用修正条件／判定覆盖测试的能力。3.2　实验前提（1）掌握逻辑覆盖的基本方法、概念；（2）熟悉程序语言的逻辑结构与基础知识；（3）选择一种程序语言。3.3　实验内容

以信用卡还款为实例，见图3-1，针对信用卡还款业务逻辑代码进行分析，运用修正条件／判定覆盖法进行测试用例设计。信用卡还款是网上银行系统和第三方支付平台的常见功能。登录第三方支付平台，选择信用卡还款模块，进入信用卡还款页面。在信用卡还款页面的第二步操作页面，验证储蓄卡是否有效并进行还款。信用卡还款业务流程描述如下。（1）在“填写还款信息”页面，输入信用卡卡号、持卡人姓名，单击“确定付款”按钮，进入“使用储蓄卡付款”页面；（2）在“使用储蓄卡还款”页面，输入储蓄卡卡号、持卡人姓名、单击“下一步”按钮，进入“还款详细”页面；（3）在“还款详细”页面，在“还款类型”下拉框中选择“全部还款”或“分期还款”，单击“确定还款”按钮完成还款。

以下为通过第三方支付平台进行信用卡还款的部分伪代码实现。图3-1　信用卡还款界面3.4　实验环境（1）首先要让学生了解信用卡还款业务场景，能够模拟操作信用卡还款流程；（2）能够将业务场景与代码逻辑关系对应；（3）根据代码画出程序流程图，并分析各判定节点；（4）根据代码流程图分析出判定条件与真假取值。3.5　实验过程简述（1）明确被测试对象使用的测试方法；（2）小组讨论业务场景并进行分析；（3）测试实施工作安排；（4）评审程序流程图和测试用例；（5）执行测试，根据测试用例带入各条件测试数据，给出测试结果。3.6　测试过程实施

1. 测试分析（1）根据信用卡业务描述，分析信用卡还款流程，包括主流程、分支流程以及正常流程、异常流程。（2）模拟信用卡还款场景：触发信用卡还款的条件，不同条件是否走不同的还款流程。（3）信用卡还款数据项检查：数据项的计算规则；数据项后台判断逻辑。

2. 测试设计

根据信用卡还款代码，设计出程序流程图（图3-2），并对程序流程图做节点标记，分析流程图的判定条件与结果。图3-2　程序流程图

3. 测试执行

根据业务场景与流程逻辑判定，运用修正条件／判定覆盖法进行用例设计。修正条件／判定覆盖法是为了实现条件／判定覆盖中尚未考虑到的各种条件组合情况覆盖，减少条件组合覆盖中产生的过多、无价值的测试用例。具体地说，修正条件／判定覆盖满足以下条件：（1）每个判定的所有可能结果至少能取值一次（达到判定覆盖）。（2）判定中的每个条件的所有可能结果至少取值一次（达到条件覆盖）。（3）一个判定中的每个条件独立地对判定的结果产生影响（在条件组合中固定一个变量或条件，改变另一个变量或条件，如果对结果有影响，就需要测试，如果对结果没有影响就不需要测试）。（4）每个入口和出口至少执行一次，覆盖不同入口或出口的路径。

根据修正条件／判定覆盖方法（MC/DC）进行分析，得到如表3-1所示的符合MC/DC质量标准的测试用例。表3-1　符合MC／DC质量标准的测试用例

4. 测试结果分析

从实验3可以看出，修正条件／判定覆盖是逻辑覆盖方法中相对较强的，超过判定覆盖、条件覆盖和条件／判定覆盖。3.7　实例练习

根据以下程序（根据销售额计算奖金）设计修正条件／判定覆盖的测试用例：实验4　基于JUnit的单元测试（共2学时）4.1　实验目的（1）通过动手实际操作，巩固所学的单元测试相关知识；（2）初步了解JUnit工具的使用方法，加深对单元测试的认识。4.2　实验前提（1）学习单元测试基本知识；（2）熟悉Eclipse工具的基本操作；（3）掌握基于Eclipse工具的Java编程；（4）选择一个被测试的Web应用系统，能够正常编译部署（本实验中选择开源Web框架Jeesite）作为单元测试对象。4.3　实验内容

针对被测试的Web应用系统（本实验中为开源Web框架Jeesite）中的某个类进行单元测试，并使用JaCoCo对测试覆盖率进行分析。4.4　实验环境（1）2~3个学生一组；（2）基础硬件清单：1台Windows操作系统的客户端（进行单元测试）；（3）Jeesite框架：Jeesite网站源码需要转换成Eclipse工程，若需要部署网站还要安装MySQL数据库，可自行拓展，具体可按照源码doc目录中提供的帮助文档进行操作。本次实验直接从网盘的jeesite-master文件目录中下载，在本地安装，重命名为jeesite；（4）Java环境：在客户端上需要安装Java运行环境和Eclipse。Eclipse安装路径需要记录，如本实验中使用的路径是C:\eclipse-jee-juno-win32\eclipse。具体安装步骤参考附录A。4.5　实验过程简述（1）确定单元测试方案与实施步骤；（2）下载并安装Tomcat；（3）下载并安装JUnit工具；（4）在JUnit单元测试环境下，完成对JaCoCo工具的安装；（5）使用JUnit对Jeesite网站中的Java类进行单元测试；（6）使用EclEmma工具，根据单元测试成功与否以及单元测试覆盖率进行分析。4.6　实施过程

1. 确定单元测试方案

本实验选择Jeesite网站框架源码（关于Jeesite参见附录D）作为Java单元测试的对象，选用Eclipse作为Java开发工具，下载并安装JUnit和JaCoCo工具，使用JUnit进行单元测试，使用JaCoCo进行覆盖率分析来辅助进行单元测试。

2. Tomcat的下载与安装

在客户端中已安装Java、Eclipse的基础上，可从Apache网站中下载apache-tomcat并解压，本实验中使用的Tomcat版本为7.0.70。使用Eclipse导入Jeesite工程后（单击菜单栏中的File→Import→General→Existing Projects into Workspace，单击Next按钮，通过Browse按钮选择Jeesite工程所在路径D:\jeesite，最后单击Finish按钮导入成功），选中Jeesite工程，单击工具栏中的Window→Preferences，在弹出窗口中选择Server→Runtime Environment，单击Add按钮，在弹出的窗口中选择Apache Tomcat v7.0，单击Next按钮后添加解压的Tomcat路径，如图4-1所示，单击Finish按钮完成Tomcat的配置，安装完成后重启Eclipse。

3. JUnit的下载与安装

JUnit是一个开源的Java测试框架，是单元测试框架体系xUnit的一个实例，目前已成为Java单元测试的事实标准。JUnit软件包可以从网站http://www.JUnit.org中下载，实验中使用的版本是JUnit 4.11。

无须解压JUnit压缩包，选中Jeesite工程，在Eclipse菜单Project的子项Properties中选择Java Build Path，单击Libraries标签，单击Add External JARs按钮，选择junit-4.11.jar后单击“打开”按钮，完成JUnit的安装，如图4-2所示，安装完成后重启Eclipse。

4. JaCoCo的下载与安装

JaCoCo是一个开源的覆盖率分析工具，可以帮助大家在单元测试时分析代码覆盖情况。可从网站http://www.eclemma.org/download.html中下载JaCoCo的Eclipse插件EclEmma的最新版本，本实验中使用的版本是Eclemma 2.3.3。

解压eclemma-2.3.3.zip到Eclipse安装路径下的dropins目录中，并且仅保留如图4-3所示的文件和文件夹。打开Eclipse，在工具栏的Help菜单中选择Install New Software，在Install窗口中单击Add按钮，并在Local的弹出框中选择EclEmma所在路径，添加Name，完成后在Install列表中勾选展示的EclEmma程序，单击Next按钮直到安装完成，如图4-4所示。安装完成后重启Eclipse，工具栏中会出现一个Coverage图标，如图4-5所示。图4-1　Tomcat配置图4-2　在Eclipse中安装JUnit图4-3　将EclEmma解压到Eclipse的dropins路径下图4-4　在Eclipse中安装EclEmma图4-5　EclEmma安装完成

5. 使用JUnit进行单元测试

在配置好JUnit工具后，就可以对Java类进行单元测试，具体步骤如下。（1）选择被JUnit测试的类。使用Eclipse打开Jeesite工程，选中其中的一个类文件D:\jeesite\src\main\java\com\thinkgem\jeesite\common\utils\StringUtils.java，选择菜单New→Other（或按Ctrl+N键），选择JAVA→JUnit→JUnit Test Case作为单元测试对象，单击Next按钮，如图4-6所示。（2）在弹出的New JUnit Test Case对话框内输入相关单元测试信息（默认已自动填写），如图4-7所示。（3）单击Next按钮，选择被测试类的方法，可以选择多个，在实验中选择lowerFirst（String）方法进行测试，该方法的作用是将首字母转换为小写字母，如图4-8所示，单击Finish按钮后，页面会自动显示生成的测试代码。图4-6　新建JUnit Test Case图4-7　单元测试类信息填写图4-8　选择被测类的方法（4）针对自动生成的代码，根据StringUtils类的lowerFirst（String）方法编写单元测试代码，如图4-9所示，将框内原测试代码末尾的@Test中的所有代码替换为补充的测试代码。图4-9　StringUtilsTest.java测试代码

补充代码如下：（5）保存修改后执行单元测试。右击StringUtilsTest.java，执行Run As→JUnit Test命令。按照上述的代码执行后，出现红色的提示条，代表这个测试案例失败，并给出错误的原因和数目，如图4-10所示，失败数为1个，错误代码在第50行，失败的原因是预期结果应该是This is test1，而实际结果是this is test1。双击失败原因的信息，会出现Result Comparison对话框，说明期望值This is test1与实际结果this is test1不符，测试没通过。（6）修改代码。修改（5）中提示的第50行代码，将预期结果改为this is test1后再次执行单元测试。结果成功，出现绿色的提示条，代表测试对象能正常工作。

6. 使用EclEmma查看测试覆盖率

Eclipse中已安装EclEmma，在单元测试的基础上进行覆盖率的实验。图4-10　JUnit Test Case测试失败示例（1）同样选择已进行过单元测试的StringUtilsTest.java文件，右击该文件后，选择菜单Coverage As→JUnit Test，如图4-11所示。图4-11　进行单元测试覆盖率检查（2）查看单元测试执行结果。与单元测试类似，如果预期与实际相符，JUnit标签的界面会出现绿色的提示条，如图4-12所示，若失败则会出现红色提示条，同样也会提示失败原因和代码行。图4-12　覆盖率测试下的JUnit标签界面（3）查看覆盖率。打开被测代码StringUtils.java文件，会发现lowerFirst（String）方法整个用绿色标示了，代表此段代码的所有分

试读结束[说明：试读内容隐藏了图片]

下载完整电子书