软件测试提纲

单元测试：Unit testing，一段代码的基本测试，实际大小未定，通常是一个函数或子程序，一般由开发者执行。单元测试是针对程序模块进行正确性检验的测试。从本质上讲，属于白盒测试。是测试过程的最小粒度。

集成测试：Integration testing，被测系统的所有组件都集成在一起，找出被测系统组建之间关系和接口中的错误。该测试一般在单元测试之后进行。

系统测试：System testing，系统测试实际上是针对系统中各个组成部分进行的综合性检验。尽管每一个检验有着特定的目标，然而所有的检测工作都要验证系统中每个部分均已得到正确的集成，并能完成指定的功能。

验收测试：Acceptance testing，它包括Alpha测试和Beta测试，系统开发生命周期方法论的一个阶段，由相关的用户和/或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收该系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。这是管理性和防御性的控制。

α测试：Alpha testing，既可以是一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试。Alpha测试不能由程序员或测试员完成。

β测试：Beta testing，软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。

静态测试：Static testing，不通过执行来测试一个系统，如代码检查、文档检查和评审等。静态测试是基于期望、专业经验、通用标准来对工作件的特征进行详细描述检查的一种测试方法。

动态测试：Dynamic testing，通过执行软件的手段来测试软件。

白盒测试：White box testing，根据软件内部的工作原理分析来进行测试，是基于代码的测试。测试人员通过阅读程序代码或者通过使用开发工具中的单步调试来判断软件质量。白盒测试一般由项目经理在程序开发中进行。白盒测试也叫结构性测试、逻辑测试或基于程序的测试，是根据被测程序的内部结构设计测试用例的一类测试。

黑盒测试：Black box testing，指测试人员不关心程序具体如何实现的一种测试方法。根据软件的规格对软件进行各种输入和观察软件各种输出结果来发现软件的缺陷和测试，这类测试不考虑软件内部的运作原理，因此软件对用户来说就像一个黑盒子。黑盒测试又叫功能性测试、数据驱动测试或基于规格说明的测试，是一种从用户观点出发的测试。

灰盒测试：Gray box testing，介于白盒测试与黑盒测试之间，灰盒测试结合了白盒测试和黑盒测试的要素，它考虑了用户端、特定的系统知识和操作环境。

功能测试：functional test，功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。

逻辑功能测试

界面测试：User interface testing，指测试用户界面的风格是否满足客户要求，文字是否正确，页面是否美观，文字、图片组合是否完美，操作是否友好，等等。测试的目标是确保用户界面为用户提供相应的访问或浏览功能，确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性。

易用性测试：Usability testing，指用户使用软件时是否感觉方便。

安装测试：Installing testing，确保该软件在正常情况和异常情况的不同条件下，例如，进行首次安装、升级、完整的或自定义的安装都能进行安装。安装测试包括测试安装代码以及安装手册。

兼容性测试：Compatibility testing，指测试软件在特定的硬件平台上、不同的应用软件之间、不同的操作系统平台上、不同的网络等环境中是否能够很友好的运行的测试。

性能测试：Performance testing，评价一个产品或组件与性能需求是否符合的测试。包括负载测试、强度测试、数据库容量测试、基准测试等类型。在一定的负载情况下，系统的响应时间、资源利用、效率等特性是否满足特定的性能需求。

时间性能：事务响应时间等

空间性能：系统资源消耗等

一般性能测试

可靠性测试：在给系统加载一定业务压力的情况下，使系统运行一段时间，以此检测系统是否稳定。

负载测试：通过在被测系统上不断加压，直到性能指标达到极限，例如“响应时间”超过预定指标或都某种资源已经达到饱和状态。

压力测试：压力测试方法测试系统在一定饱和状态下，例如CPU、内存在饱和使用情况下，系统能够处理的会话能力，以及系统是否会出现错误。

并发测试：并发测试方法通过模拟用户并发访问，测试多用户并发访问同一个应用、同一个模块或者数据记录时是否存在死锁或其者他性能问题。

配置测试：配置测试方法通过对被测系统的软\硬件环境的调整，了解各种不同对系统的性能影响的程度，从而找到系统各项资源的最优分配原则。

回归测试：Regression testing，在错误修改之后，重复先前的测试以保证修改的正确性。理论上，对软件的任何新版本，都需要进行回归测试，验证以前发现和修复的错误不会在新软件版本上再现。

冒烟测试：Smoke testing，冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。

随机测试：Ad hoc testing，它主要是根据测试者的经验对软件进行功能和性能抽查，是没有书面测试用例、记录期望结果、检查列表、脚本或指令的测试。随机测试是根据测试说明书执行用例测试的重要补充手段，是保证测试覆盖完整性的有效方式和过程。

软件缺陷生存周期

New、Open、Fixing、Fixed、Reopen、Rejected、Closed

Open、Fixing、Fixed称为缺陷的活动态，Rejected、Closed称为缺陷的终结态。

CMM：Capability Maturity Model，过度成熟度模型。

TMM：Testing Maturity Model，测试成熟度模型。（1级初始级，2级定义级，3级集成级，4级管理和度量级，5级优化级）。

广义的测试概念：广义的软件测试由确认、验证、测试3个方面组成。

1. 确认：评估将要开发的软件产品是否正确无误、可行和有价值。

2. 验证：检测软件开发的每个阶段、每个步骤的结果是否正确无误，是否与软件开发各阶段的要求或期望的结果相一致。

3. 测试：与狭义的测试概念统一。

狭义的测试概念：（第一类测试）软件测试是在既定的状况条件下，运行一个系统或组件，观察记录结果，并对其某些方面进行评价的过程。（第二类测试）软件测试是为了发现错误而运行程序的过程。

软件测试的对象：

软件测试并不等于程序测试，软件测试应该贯穿整个软件定义与开发整个期间。因此需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都应该是软件测试的对象。

软件测试的原则：

软件测试过程：

具体来讲，软件测试过程是一个不断输入数据，观察和记录软件运行行为和输出结果，并判断其行为和输出结果的正确性，直到能够由这些结果有效地分析该软件的性能的过程。

抽象地讲，软件测试就是不断进行测试、排错、修改，然后再进行测试(回归测试)、排错、修改，直到软件达到用户性能要求的一个循环往复过程。

从软件开发的过程按阶段划分有：

1. 需求分析：在软件开发生命周期的需求阶段，业务需求的定义是比较高级的，并且也是后续阶段及最终实现的基础。因此，在需求阶段对需求进行验证，可以使得尽早的发现错误。

2. 单元测试：单元测试是测试的基本阶段，也是在软件开发过程中要进行的最低级别的测试活动，在这个过程中，软件的独立单元将在与程序的其他部分隔离的情况下进行测试，针对的是单个的函数模块，主要采用白盒测试的测试用例，辅之以黑盒测试的测试用例使之对任何合理的输入和不合理的输入，都能鉴别和响应。

3. 集成测试：集成测试是在单元测试的基础上，把程序的基本单元按照软件结构设计的要求，组装成软件系统进行测试。一般采用黑盒测试方法，白盒测试方法作为补充，主要在模块功能、模块间接口等方面的查错。

4. 确认测试：集成测试完成以后，分散开发的模块被联接起来，构成完整的程序，确认测试应检查软件能否按合同要求进行工作。

5. 系统测试：系统测试实际上是针对系统中各个组成部分进行的综合性检验。尽管每一个检验有着特定的目标，然而所有的检测工作都要验证系统中每个部分均已得到正确的集成，并能完成指定的功能。

6. 验收测试：最后，要进行验收测试。验收测试是以用户为主的测试，用户参与设计测试用例，使用用户界面输人测试数据，并分析测试的输出结果，还应该对软件的兼容性、可维护性等进行确认，验收测试实际上是对整个测试计划的一个走查。

软件测试过程模型

V-模型：虽然V-模型已存在了很长时间，且被广泛应用，但是它也存在一些局限性。比如，它没有明确地说明早期的测试，无法体现“尽早地和不断地进行软件测试”的原则。

W-模型：W-模型是V-模型的发展，强调的是测试过程伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试。W-模型也存在局限性，它无法支持迭代的开发模型。对于当前软件开发复杂多变的情况下，W-模型并不能解除测试管理面临的难题。

H-模型：H-模型将软件测试过程活动完全独立出来，使之贯穿于整个产品的周期，与其他流程并发地进行。

X-模型：X模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试，右上半部分显示此后将进行频繁的交接，通过集成最终合称为可执行的程序，这些可执行程序还需要进行测试。

基于模型的测试：软件模型是对软件行为和软件结构的抽象描述。基于模型的软件测试技术可以根据测试模型对被测试程序中所有输入及其状态组合进行系统枚举，因此可以使测试实现系统化、集中化以及自动化。

面向对象的测试：传统程序执行的路径是在程序开发时定义好的，程序执行的过程是主动的，其流程可以用一个控制流图从头至尾地表示；面向对象程序中方法的执行通常不是主动的，程序的执行路径也是运行过程中动态地确定的，因此描述它的行为往往需要动态的模型。与传统的程序相比较，面向对象程序主要具有封装性、继承性、多态性和动态绑定等几大特性。

web测试：Web应用程序拥有许多传统软件没有的特点。Web应用程序通常都是由品类繁多的实体组成，这些实体大部分是使用多语义的标记符或脚本编写而成的，例如，HTML、Javascript、eol脚本、Asp和JSP等。

测试用例设计原则：

测试用例的设计是软件测试人员的工作核心，它的设计必须符合以下原则：

1. 测试用例设计要基于需求：必须按照不同的测试级别的要求，设计测试用例。如单元测试依据详细的设计说明，集成测试，依据概要设计说明书等。

2. 测试用例设计要基于测试方法：必须指明采用的用例设计方法。为了达到不同的测试覆盖率，要采用相应的测试方法，如等价类划分、边界值分析、正交分析和决策表等具体方法。

3. 测试用例必须具有代表性：能够代表并覆盖各种合理的和不合理的、合法的和非法的、边界的和越界的以及极限的输入数据、操作和环境设置等。

4. 测试用例必须具有可执行性：每个用例必须有详细的执行步骤。

5. 一个用例只能针对一个问题：同时覆盖多个测试点，会导致bug定位困难。

6. 测试结果必须具有可判定性：即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望

结果。

7. 测试结果必须具有可再现性：即对同样的测试用例，系统的执行结果应当是相同的。

8. 兼顾测试的充分性和效率：设计测试用例必须权衡分析的覆盖率和时间上的可操作性。

测试用例的描述：

ANSI/IEEE829 标准中罗列了测试用例描述所应包含的信息：

1. 标识符。由测试设计过程说明和测试程序说明引用的唯一标识符。

2. 测试项。描述被测试的详细特性、代码模块等，应该比测试设计说明中所列的特性更加具体。如果测试设计说明说“计算器程序的加法功能”，那么测试用例说明就会详细描述为“加法运算的上溢处理”。

3. 输入说明。该说明列举测试用例的输入内容或条件。如果测试计算器程序，输入说明可能是1+1。

4. 输出说明。该说明用以描述程序执行结果。例如1+1=2吗？

5. 环境要求。用以描述执行测试案例必要的硬件、软件、测试工具、人员等等。

6. 特殊要求。描述执行测试必须做到的特殊要求。如航天航空导航系统的特殊要求。

7. 测试用例之间的依赖。一个测试用例依赖于其它用例，那么它的执行结果会受到其他用例的影响，在此应予以注明。

测试用例的执行过程：

测试执行主要可以分为两个周期，一个是测试周期，一个错误报告周期。

1. 测试周期包括了测试用例执行的几个状态：等待、执行、阻塞、通过、失败和关闭。测试周期中，测试的执行过程就是安排测试用例，运行测试用例，分析测试用例，修改完善测试用例，这几个环节的循环过程。

2. 错误报告周期则包含了寻找错误，触发错误，记录错误，定位错误，修改错误和和确认修复成功等环节。

3. 无论是哪一种测试的执行过程，都不是一个单调的顺序过程，都需要迭代和循环。从理论上讲，每修改一个软件中的错误，软件就会回到测试前的状态，这就需要重新对软件进行全面的测试。实际工程中可能没有要求如此严苛，但是也要对修复问题所影响的模块，进行彻底的全面测试。而测试工作本身即是一个循环往复的过程这就是测试充分性在测试理论中有其特殊地位的原因。

4. 选择首先执行哪些测试用例是一个极具策略性的决定，它取决于我们对软件质量的要求、可供使用的资源、现有的测试文档和风险评估结果的综合。执行测试的重点放在高风险特征项目上。

黑盒测试技术

1. 等价类划分。

2. 边界值分析。

3. 决策表。

4. 错误推测法。

5. 因果图法。

6. 正交表试验法。

7. 场景图。

8. 流程图法。

白盒测试技术

1. 覆盖测试。

语句覆盖，分支覆盖，条件覆盖，分支条件覆盖，路径覆盖

2. 基本路径测试。

3. 循环结构测试。

程序插桩：程序插桩是一种通过向被测测试程序中插入操作来发现和定位错误的方法，在程序调试中有着广泛的应用。在测试和调试程序时，往往要在程序中插入一些打印语句(有的时候是以日志文件的形式存在的)，以便在程序执行过程中，打印出我们所关心的信息，通过这些信息来了解程序执行过程中的动态特性，例如程序的实际执行路径，程序中某语句的执行次数，程序中某变量在特定时刻的值等等，都可以通过程序插桩来完成。

静态分析：

控制流分析：一个程序的控制流关系叙述了程序元素和它们的执行次序之间的联系。对应于控制流关系的图被称为控制流图。

数据流分析：程序和程序的元素通过他们的数据访问行为关联起来，这就确定了数据流关系。

接口分析：也叫接口一致性分析，主要用于程序静态分析和设计分析。接口一致性分析的设计分析设计模块之间的接口的一致性以及模块与外部数据之间的一致性。

表达式分析：对表达式进行分析，可以发现和纠正表达式出现的问题。

动态分析：

内存错误：当一个指针或者该指针所指向的内存单元成为无效单元，或者内存中分配的数据结构被破坏时，就会造成内存错误。

内存泄漏：指由于疏忽或错误造成程序未能释放已经不再使用的内存的情况。内存泄漏并非指内存在物理上的消失，而是应用程序分配某段内存后，由于设计错误，失去了对该段内存的控制，因而造成了内存的浪费。

测试组成员：

测试经理、测试负责人、手动测试工程师、自动化测试工程师、网络测试工程师、环境测试工程师、安全性测试工程师、测试库和配置专家。

静态白盒测试：

正式审查：Formal Review，就是进行静态白盒测试的过程。正式审查的含义很广，从两个程序员之间的简单交谈，到软件设计和代码的详细的、严格的检查都属于此过程。4个基本要素：确定问题、遵守规则、准备、编写报告。

同行审查：Peer Review，就是同事之间你看我的，我看你的。

走查：Walkthrough，代码走查与代码审查相似，代码审查是一种正式的评审活动，而代码走查的讨论过程是非正式的，当然走查比审查要更技术些。

检验：Inspection，也叫技术评审，最正式的审查类型，具有高度的组织化，要求每一个参与者都接受训练。技术评审由开发组，测试组，和相关人员等联合进行，综合运用走查，审查技术，逐行逐段的检查软件。

代码审查的内容和范围：

代码审查主要用于识别和消除安全缺陷，包括可导致掠夺性的缓冲器溢出的缺陷和其他的被认为“源代码安全性审查”的缺陷。

代码检查应在编译和动态测试之前进行，在检查前，应准备好需求描述文档、程序设计文档、程序的源代码清单、代码编码标准和代码缺陷检查表等

驱动程序：driver，对底层或子层模块进行（单元或集成）测试时所编制的调用被测模块的程序，用以模拟被测模块的上级模块

桩程序：stub，也有人称为存根程序，对顶层或上层模块进行测试时，所编制的替代下层模块的程序，用以模拟被测模块工作过程中所调用的模块。

单元测试的内容：

1. 模块接口测试。对被测模块的数据流进行测试。为此，对模块接口包括参数表、调用子模块的参数、全程数据、文件输入／输出操作都必须检查。

2. 局部数据结构测试。设计测试用例检查数据类型声明、初始化、缺省值等方面的问题，还要查清全程数据对模块的影响。

3. 路径测试。选择适当的测试用例，对模块中重要的执行路径进行测试。对基本执行路径和循环进行测试可以发现大量的路径错误。

4. 错误处理测试。检查模块的错误处理功能是否有错误或缺陷。例如，是否拒绝不合理的输入，出错的描述是否难以理解，是否对错误定位有误，是否对出错原因报告有误，是否对错误条件的处理不正确，在对错误处理之前，错误条件是否已经引起系统的干预等。

5. 边界测试。要特别注意数据流、控制流中刚好等于、大于或小于确定的比较值时出错的可能性。对这些地方要仔细地选择测试用例，认真加以测试。

自动化测试的优缺点：

自动测试与手工测试相比，有以下优点：

1. 执行手工测试不可能或很难完成的测试。

2. 需要多次执行同一测试的情况下，自动化测试不需要测试人员每次都重复相同的过程。

3. 提高测试的准确性，降低对测试人员的技术要求。

4. 可实现无人照料。

5. 具有一致性和可重复性。

6. 有利于进行回归测试。

7. 缩短测试时间。

以下是自动化测试的不足之处：

1. 并不能完全取代手工测试。有些测试使用手工测试比自动化测试要简单，测试自动化的开销就比较大。

2. 手工测试比自动化测试发现的缺陷更多。

3. 对测试质量的依赖性极大。

4. 自动化测试可能会制约软件开发。

自动化测试的对象：

1. 重要的测试用例

2. 针对主要功能的测试用例

3. 容易自动化的测试用例

4. 很快有回报的测试用例

5. 运行最频繁的测试用例

软件测试自动化实现的原理和方法：

1. 直接进行静态和动态分析

2. 测试过程的捕获和回放

3. 测试脚本技术

4. 虚拟用户技术和测试管理技术

性能测试的意义（为什么）：

1. 评估系统的能力

2. 识别系统中的弱点

3. 系统调优

4. 验证可伸缩性和可靠性

软件性能指标：

响应时间：指的是客户端发出请求到得到响应的整个过程所经历的时间。

并发用户数：指在某个时间特定点上与服务器端进行会话操作的用户数。

吞吐量：指单位时间内系统处理客户请求的数量，直接体现软件系统性能承载能力。一般来说，吞吐量用请求数/秒或页面数/秒来衡量。

交易成功率：成功的交易数占总交易请求数的比率。

资源利用率：指的是服务器端的系统资源使用程度，主要有CPU利用率、内存利用率、磁盘I/O利用率、网络带宽利用率等。

性能测试步骤：

1. 测试需求分析

2. 制定测试策略

3. 制定测试方案（计划）

4. 开发测试脚本

5. 执行测试方案

6. 分析测试结果

7. 编写测试报告

遗传算法：是一种通过模拟自然进化过程搜索最优解的方法。

变异测试：是一种在细节方面改进程序源代码的软件测试方法。这些所谓的变异，是基于良好定义的变异操作，这些操作或者是模拟典型应用错误，或者是强制产生有效地测试。目的是帮助测试者发现有效地测试，或者定位测试数据的弱点，或者是在执行中很少（或从不）使用的代码的弱点。

Web测试的类型：

内容测试、界面测试、功能测试、性能测试、兼容性测试、安全性测试等情况

客户端测试内容：

1）测试HTML-----静态Web上的设计

1. 整洁是最重要的

2. 测试其他设计方面问题

3. 测试设计时想着图片

4. 测试设计的易用性

5. 实现可访问性

6. 设计用户交互

7. 性能测试

2）测试动态Web

1. 检查应用程序框架

2. 脚本

3. 测试ASP

4. 测试CGI

5. 测试ActiveX控件

服务器测试内容：

1）性能测试

1. 制定基于性能的测试计划

2. 性能测试综述

a) 选择用于性能测试的机器

b) 在性能测试之前检查配置

c) 开始性能测试

d) 继续性能测试

2）其他测试

1. 负载测试和压力测试

2. 可靠性和稳定性测试

3. 可伸缩性测试

基于云计算的测试：

通常该类云的测试也称为测试云，要求符合目标运营主体业务定位的云计算商业运营模式已经比较成熟和完善，且已经具备一整套软件测试网络化运营经验和资源积累。在技术上，测试云要求目标运营主体已经实现软件测试资源化和较为完整的服务体系，且已经构建具备商业运营需要的软件测试资源使用量的计算模型。

面向云计算的测试：

与前者不同，面向云计算的软件测试也称为云测试，是对传统软件测试业务内容和领域的扩展和延伸，其对自身业务增长点的定位是其软件测试业务自身，即通过对云计算环境中软件及其相关资源的测试来扩展软件测试的对象和业务量。

测试工程师分类：

高级软件测试工程师：熟练掌握软件测试与开发技术，且对所测试软件对口行业非常了解，能够对可能出现的问题进行分析评估；

中级软件测试工程师：编写软件测试方案、测试文档，与项目组一起制定软件测试阶段的工作计划，能够在项目运行中合理利用测试工具完成测试任务；

初级软件测试工程师：其工作通常都是按照软件测试方案和流程对产品进行功能测验，检察产品是否有缺陷。

软件测试工程师所具备的职业素质：

1. 专业技能：主要包含三个方面：测试专业技能，软件编程技能，网络、操作系统、数据库、中间件等知识。

2. 行业知识：行业知识即业务知识，是测试人员做好测试工作的又一个前提条件，只有深入地了解了产品的业务流程，才可以判断出开发人员实现的产品功能是否正确。行业知识与工作经验有一定关系，通过时间即可以完成积累。

3. 个人素养：“三心”，专心、细心、耐心。

JUNIT使用过程（例子）

首先，新建一个项目叫JUnit_Test，编写一个Calculator类，这是一个能够简单实现加减乘除、平方、开方的计算器类，然后对这些功能进行单元测试。

第二步，将JUnit4单元测试包引入这个项目。

第三步，生成JUnit测试框架：在Eclipse的Package Explorer中用右键点击该类弹出菜单，选择“New à JUnit Test Case”。

第四步，运行测试代码：按照上述代码修改完毕后，我们在CalculatorTest类上点右键，选择“Run As à JUnit Test”来运行测试。

Selenium使用流程

1. 介绍一下Selenium测试工具，并说明Selenium中如何判断元素是否存在?

Selenium也是一个用于Web应用程序测试的工具。Selenium测试直接运行在浏览器中，就像真正的用户在操作一样。支持的浏览器包括IE、Mozilla Firefox、Mozilla Suite等。这个工具的主要功能包括：测试与浏览器的兼容性——测试你的应用程序看是否能够很好得工作在不同浏览器和操作系统之上。测试系统功能——创建衰退测试检验软件功能和用户需求。支持多种语言，包括Ruby、Python、java等。自由开放源

Selenium提供如下定位元素的方法。

id=id；name=name；dom=javascriptExpression；xpath=xpathExpression；link=textPattern；css=cssSelectorSyntax

判断元素是否存在

assertTrue(selenium.isElementPresent("xpath=//input[@name='XXXX']"));

2. Junit： 

a) 解释Junit中以下注解的意义。

@Test 

表明该方法是单元测试方法。

@Test(timeout=1000) 

该元数据传入了一个时间（1000毫秒）给测试方法

如果测试方法在制定的时间之内没有运行完，则测试也失败。

@Before 

使用了该元数据的方法在每个测试方法执行之前都要执行一次。

@After

使用了该元数据的方法在每个测试方法执行之后要执行一次。 

b) 列举至少三个Assert方法，并说明该方法应用场景。

1. assertEquals()方法，用来查看对象中存的值是否是期待的值，与字符串比较中使用的equals()方法类似；

2. assertFalse()和assertTrue()方法，用来查看变量是是否为false或true，如果assertFalse()查看的变量的值是false则测试成功，如果是true则失败，assertTrue()与之相反。

3. assertSame()和assertNotSame()方法，用来比较两个对象的引用是否相等和不相等，类似于通过“==”和“!=”比较两个对象；

4. assertNull()和assertNotNull()方法，用来查看对象是否为空和不为空。