1、软件工程 第八章 软件测试,2020/3/18,1,2,2020/3/18,目标,了解测试各个阶段，从开发过程中的测试到系统客户的验收测试。 介绍可以帮助客户选择测试案例的技术以发现程序的缺陷。 了解测试优先的开发。 掌握组件测试、系统测试和发布测试的主要差异，以及了解用户测试过程和技术。,3,2020/3/18,主要内容,开发测试 测试驱动的开发 发布测试 用户测试,程序测试,测试是试图说明一个程序可以做我们期望它所做的工作和在投入使用之前发现程序的缺陷。 当测试软件时，使用人工数据来执行这个程序。 审查测试运行的结果，找出关于程序的非功能属性的错误、异常或其他信息。 能够揭示程序的错误。
2、测试是检查和验证过程的组成部分之一。,4,2020/3/18,程序测试目标,向开发者和用户展示软件满足需求。 对于定制软件，意味着对用户和系统需求文档中的每个需求至少要有一个测试。 对通用软件，意味着对每个集成在产品发布版本中的所有系统特征以及这些特征组合进行测试。 找出软件中缺陷和不足，即软件行为是不正确的、所不希望的或不符合它的描述。 找出所有不希望出现的系统行为的根源。如，系统崩溃，与其他系统不期望的交互、不正确的计算和数据毁坏。,5,2020/3/18,6,2020/3/18,有效性和缺陷测试,有效性测试（是否满足需求） 向开发者或系统客户展示软件满足了其需求; 一个成功的测试表明系统
3、运行符合预期。 缺陷测试（是否存在缺陷） 发现系统中行为不正确或不满足需求规格说明的错误或缺陷; 一个成功的测试是是系统执行不正确的测试或暴露系统缺陷的测试。,7,2020/3/18,程序测试的输入和输出模型,测试只能证明存在错误，而不能证明它们不存在。,检验和验证,检验 我们在建立正确的产品吗？ 验证 我们建立的产品正确吗？软件行为符合用户的期望,8,2020/3/18,检验和验证的信心,检验和验证过程的最终目的是建立信心，即这个软件系统是“达到目的”的。 这个信心水平取决于系统的目的、用户期望和市场环境 软件目的 这个软件越重要，他的可靠性就越重要 用户期望 市场环境,9,2020/3/1
4、8,审查和测试,软件审查，是分析和检查系统需求、设计模型、程序源代码，甚至是建议的系统测试，是一种静态的检验。 软件测试，是执行动作，观察行为，是一种动态的检验。,10,2020/3/18,审查和测试,11,2020/3/18,软件审查,主要审查系统的源代码。 审查不必执行系统，所以可以在系统实现之前进行。 任何可读的软件表示，都被审查（需求、设计、配置数据、测试数据） 。 审查是发现程序错误的一个有效的方式。,12,2020/3/18,审查的优势,在测试期间，一个错误可能会掩盖其他错误。审查是一个静态的过程，可以不必关心错误之间的相互作用。 审查一个系统的不完整版本不需要额外的代价。 除了搜
5、索程序缺陷，审查也可以考虑一个程序更广泛的质量属性。,13,2020/3/18,软件测试过程模型,14,2020/3/18,测试的阶段,开发测试，即在开发过程中进行系统软件测试来发现故障和缺陷。 发布测试，即一个测试小组对一个系统的完整版本进行测试。 用户测试，即系统的用户或潜在的用户在他们自己的环境中测试这个系统。,15,2020/3/18,8.1 开发测试,开发测试包括系统开发团队所进行的所有测试活动。 单元测试，即对单独的程序单元或对象类进行测试 组件测试，即将多个程序单元整合创建一个合成的组件 系统测试，即集成系统中的一些或所有的组件作为一个整体进行测试,16,2020/3/18,8.
6、1.1 单元测试,单元测试是测试单个组件的过程 这是一个发现缺陷的测试过程 单元可以是： 单个函数或对象中的方法 带有属性和方法的对象类 带有访问他们功能的接口的复合组件。,17,2020/3/18,对象类测试,完整测试一个类包括 测试与对象相关的所有操作 设置和检查与对象相关的所有属性 测试对象所有可能的状态 继承使得设计对象类的测试更加困难，因为，被测试的信息不适本地化的,18,2020/3/18,气象站系统对象接口,19,2020/3/18,气象站测试,需要为与对象相关的所有方法定义测试用例，如， reportWeather、 reportStatus。 使用状态模型识别出需要测试的状态
7、转换的序列，并指定迫使这些状态转换发生的事件序列。 例如： Shutdown - Running- Shutdown Configuring-Running- Testing - Transmitting -Running Running-Collecting-Running-Summarizing-Transmitting -Running,20,2020/3/18,自动测试,只要可能的话，应该使单元测试自动化。 在自动化单元测试中，应该充分利用测试自动化框架（例如JUnit）来编写和运行程序测试。 单元测试框架提供了一个通用的测试类，只需扩展它来形成新的测试案例。,21,2020/3/18
8、,自动测试组件,准备部分，用测试用例初始化系统，即输入和期望的输出。 调用部分，即调用所要测试的对象或方法。 断言部分，即比较调用的结果和预期的结果是否相同。如果断言取值为真，那么测试成功；如果断言取值为假，那么测试失败。,22,2020/3/18,8.1.2 选择单元测试案例,测试案例应该表明，当按照预期的方式使用时，所测试的组件能够像假设的那样去执行。 如果在组件中有缺陷，这些缺陷应该被测试案例发现。 两类测试案例 反映一个程序的正常操作，并能显示出组件工作正常 建立在对通常问题的经验基础上，应该使用非正常的输入来检测是否得到正常处理，或者是否使得组件崩溃,23,2020/3/18,测试策
9、略,划分测试，即识别具有共同特性和以同样的方法处理的一组数据 我们应该从这些组中选择测试数据 基于准则测试，即使用测试准则来选择测试案例 这些准则反映了程序员在开发组件时对经常犯的各种错误的经验,24,2020/3/18,划分测试,程序的输入和输出结果总是落在几个不同且有共同特征的类中。 程序通常对一个类中的所有成员其行为都是差不多的。由于这些等价的行为，这些类通常叫做等价划分或是域。 所设计的测试案例要使得输入和输出落在这些划分中。 划分测试即可以用来设计系统的测试案例，也可以用来设计组件的测试案例。,25,2020/3/18,等价划分,26,2020/3/18,系统,输入等价划分,输出划分
10、,可能输入,可能输出,正确 输出,等价分类,27,2020/3/18,测试指导（序列）,用一个只有单个值的序列来测试程序 在不同的测试中使用不同规模的多个序列 导出一个测试，让第一个、中间一个和最后一个元素得到测试 测试序列长度为零时的情况,28,2020/3/18,一般的测试原则,选择能够迫使系统产生所有错误信息的输入 设计能够使系统的输入缓冲溢出的输入 重复相同的输入或一系列输入很多次 迫使产生无效的输出 迫使输出结果太大或太小,29,2020/3/18,8.1.3 组件测试,软件组件通常是由许多彼此交互的对象组合的复合组件 例如，在气象站系统中，再配置组件包括处理再配置各个方面的各对象
11、可以通过它们定义的接口来访问它们的功能 这时可以测试组件的接口行为是否符合它们的描述 假定组件的单个对象的单元测试已经完成,30,2020/3/18,接口测试,31,2020/3/18,接口测试,目标是检测接口错误或无效的接口假设引起的故障 接口的类型 参数接口，主要是数据和函数指针，由一个组件传递到另一个组件 共享内存接口，有一个被子系统共享的内存块 程序接口，子系统封装一组程序，这些程序可以被其他子系统调用 消息传递接口，子系统通过消息传递来请求其他子系统上的服务,32,2020/3/18,接口错误,接口误用 调用者组件在调用其他组件接口时使用不当而产生的接口错误 接口误解 调用者组件误解
12、了被调用组件的接口描述而产生接口错误，对被调用组件行为进行了错误的假设 时序错误 系统使用了共享内存接口或消息传递接口而产生接口错误,33,2020/3/18,接口测试一般准则,审查要测试的代码并明确地列出对外部组件的每个调用。 当有指针从接口传递时，总用空指针参数来测试接口。 设计一些容易引起组件失效的测试。 在消息传递系统中进行强度测试。 当组件通过共享内存来交互时，设计测试使其对激活组件次序有所改变。,34,2020/3/18,8.1.4 系统测试,系统测试包括集成组件来形成一个新版本的系统，然后测试集成后的系统 系统测试强调测试组件之间的交互 系统测试确保组件是可兼容的、能正确地进行交
13、互，以及通过它们的接口在适当的时候传送正确的数据 系统测试测试系统的总体行为,35,2020/3/18,系统和组件测试的区别,在系统测试中，单独开发的可复用组件和商业现货系统可能会与新开发的组件集成到一起，然后对完整的系统进行测试 不同小组成员或群组开发的组件可能在这个阶段集成。系统测试是一个集体的过程而不是一个独自的过程 在一些公司中，系统测试可能由一个独立的测试小组执行，没有设计人员和程序员的参与,36,2020/3/18,用例测试,用例被用来定义系统之间的交互，可以作为系统测试的基础 每个用例通常涉及多个系统组件，因此测试这个用例，迫使这些相互作用发生。 序列图建模用例的实现，可以看到交
14、互中涉及的对象或组件，从而进行测试,37,2020/3/18,38,2020/3/18,收集气象数据的序列图,测试策略,无遗漏测试是不可能的，因此需要建立一个可能的测试子集，根据子集进行测试 测试策略例子 所有的能从菜单中得到的系统功能都应该被测试到 可以从同一个菜单中访问的组合功能需要被测试 在提供用户输入的地方，所有的功能都必须对正确的和不正确的输入进行测试,39,2020/3/18,8.2 测试驱动的开发,测试驱动的开发（TDD）是一种程序开发方法，交错进行测试和代码开发。 代码通过测试，是开发的关键驱动力。 开发代码增量，一起测试该增量。不移动到下一个增量，直到你已经开发的代码，通过其
15、测试。 TDD的引入是作为如极限编程这样敏捷方法的一个部分。但是，它也可用于计划驱动的开发过程中。,40,2020/3/18,测试驱动的开发,41,2020/3/18,TDD 的过程活动,从识别所需要的功能增量开始。这个通常比较小，用几行代码就可以实现。 针对此功能编写一个测试并实现为一个自动测试。 然后运行此测试，以及所有已实现的其他测试。最初，并没有实现这个功能，因此这个新的测试是失败的。 然后实现这个功能，并重新运行这个测试。 一旦所有的测试成功，就可以转去实现下一个功能块。,42,2020/3/18,测试驱动开发的好处,代码覆盖 每个代码片段都至少有一个测试 回归测试 随着一个程序的开
16、发，一个测试套件也增量式的开发出来 简化调试 当一个测试失败时，问题出在何处是很明显的 系统文档 测试本身就表现为一种文档形式，它描述代码应该做什么,43,2020/3/18,回归测试,回归测试就是测试系统，检查变化没有破坏以前的工作代码。 在手动测试过程中，回归测试是昂贵的，但是，自动化测试，它是简单明了的。当程序每次改变时所有的测试都重新运行。 程序在改变之前测试必须成功。,44,2020/3/18,8.3 发布测试,发布测试是为开发组以外的用户使用系统的一个特殊版本所做的测试过程 发布测试过程中的主要目标是说服供应商，该系统是足够使用的。 因此，发布的测试表明，该系统提供了其指定的功能，
17、性能和可靠性，在正常使用过程中，不会出错。 发布测试通常是一个黑盒测试过程，测试从系统描述导出,45,2020/3/18,黑盒测试、白盒测试,黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。 白盒测试：已知产品的内部工作过程，可以进行测试证明每种内部操作是否符合设计规格要求，所有内部成分是否经过检查。,46,2020/3/18,黑盒测试与白盒测试的区别,黑盒测试 测试特点：测试功能； 测试依据：需求规格说明书 方法举例：等价类划分、边界值测试 优点：能站在用户的立场上进行测试 缺点：不能测试程序内部特定部位，如程序有误，则无法发现。 白盒测试 测试特点：测试程序
18、接口与结构 测试依据：软件程序 方法举例：逻辑覆盖 优点：对程序内部特定部位进行覆盖测试。 缺点：无法检验程序外部特性。,47,2020/3/18,黑盒测试与白盒测试的区别,黑盒测试把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，针对“软件界面”和”软件功能“进行测试，只检查功能是否符合需求规格说明书能正常使用。因此黑盒测试又叫功能测试或数据驱动测试。 白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看作一个打开的盒子，他允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。因此白盒测试又称为“结构测试”或“逻辑
19、驱动测试”。白盒测试是按照程序内部的结构来测试程序，通过测试检验产品内部动作是否按照设计规格说明书的要求正常进行，检验程序中的每条通道是否都按照规定正常工作。,48,2020/3/18,发布测试和系统测试,发布测试是系统测试的一种形式。 重要区别 一个独立的与系统开发无关的小组应该负责发布测试。 开发组的系统测试的重点是在系统中发现错误（缺陷测试）。发布测试的目标是检查系统符合它的需求描述，并且足可以对外销售（有效性验证测试）。,49,2020/3/18,50,2020/3/18,8.3.1 基于需求的测试,需求工程的的一个基本原则是需求应该是可以测试的。 基于需求的测试是有效性验证测试而不是
20、缺陷测试它努力证明系统已经正确地实现了它的需求。 MHC-PMS需求 如果知道病人对药物过敏，该药物处方导致系统向用户报警。 如果医生忽略报警信号，需提供忽略原因。,需求测试,建立一个没有已知过敏史的病历记录。 建立一个有已知过敏史的病历记录。 建立一个病历记录，期中包括两个或两个以上过敏药物。 为病人开带两个过敏药的处方，检查发出两个正确的警告信息。 开带过敏药物处方，发出警告。医生拒绝警告，检查系统允许用户提供信息解释警告被拒绝的原因。,51,2020/3/18,8.3.2 情景测试,情景测试也叫脚本测试，或场景测试，是发布测试的一个方法。 需要设计典型的使用场景，并为系统开发测试用例。
21、一个情景是一个故事，描述系统使用的一种方式。 情景测试应该现实，且真实的系统用户应该能将它与自己的工作联系起来。,52,2020/3/18,MHC-PMS诊断情景,通过登录到系统进行身份验证。 下载和上传特定病人的病历到笔记本电脑。 家庭出诊时间安排。 在移动设备上加密和解密病历。 记录检索和修改。 连接包含副作用信息的药物数据库。 电话提示系统。,53,2020/3/18,8.3.3 性能测试,发布测试可能包括测试系统的总体特性，如性能和可靠性。 性能测试通常包括对一系列测试的规划，这里的测试是要让负荷稳定地增长直到系统性能不可接受为止。 压力测试是性能测试一种形式，通过压力测试可以让系统暴
22、露出在正常情况下不会暴露的缺陷。,54,2020/3/18,8.4 用户测试,用户测试是测试过程中一个阶段，在这个阶段，用户提供输入和系统测试的建议。 用户测试是必不可少的，即使全面的系统测试和发布测试已完成。 原因是来自用户工作环境因素对一个系统的可靠性、性能、可用性以及健壮性有很大的影响。,55,2020/3/18,用户测试类型,Alpha（）测试 软件的用户与开发小组一起在开发者的地点测试软件。 Beta（）测试 该软件版本提供给用户让他们进行测试，并向开发者提出他们所发现的问题。 接收测试 客户测试系统来决定他们是否愿意从系统开发者那里接收系统并在客户环境中部署。,56,2020/3/
23、18,接收测试过程,57,2020/3/18,接收测试过程的阶段,定义接收准则 计划接收测试 导出接收测试 运行接收测试 协商测试结果 拒绝/接收系统,58,2020/3/18,敏捷方法和接收测试,在敏捷方法中，用户是开发组的一个部分，他决定是否接收系统。 用户/客户定义测试，并集成了其他测试，程序进行更改时自动运行。 没有单独的验收测试过程。 这里主要的问题是嵌入式用户是否是典型，能够代表系统的所有利益相关者的利益。,59,2020/3/18,要点,测试只能证明系统存在错误，不能说明系统中不再有缺陷。 开发测试是软件开发小组的责任。 开发测试包括单元测试、组件测试、系统测试。 测试软件时，应该根据经验和原则把软件打散来选择测试案例的类型。,60,2020/3/18,要点,有可能的话，应该编写自动化测试。 测试优先开发是开发的一种方法，在代码测试之前就写好测试。 情景测试是非常有用的，因为它可以复制系统的使用。 接收测试是一个用户的测试过程，目的是决定这个软件是否足以进行部署。,61,2020/3/18,
