软件测试--笔记

软件测试第一章 软件测试概述1.1 引子：4W1H 问题对于软件的初学者而言，最常见的五个问题是 4W1HWhat：什么是软件测试，即软件测试是如何定义的？Which：软件测试到底要对软件的哪些部分展开测试，即测试的对象是什么Who：在一个项目小组中，哪些人负责对软件进行测试When：在一个软件产品从立项开发、验收、维护到消亡的整个生命周期过程中，何时开始软件测试工作，何时可以结束对软件的测试How：如何对软件进行测试？这也是大部分初学者最为关心的问题1.2 软件与软件测试1.2.1 软件的定义软件=程序（ P）+数据(库）(DB)+文档（D）+服务（S） 程序：表示能够完成预定功能和性能的指令的集合，如 C 语言程序、java 程序等。 数据(库）：依照某种数据模型组织起来、并存在二级存储器中的数据集合。 文档：指软件在开发、使用和维护过程中产生的文字与图形的集合，如：系统需求规格说明书、测试计划、用户手册等。 服务：指通过提供必要的手段和方法，满足接受服务对象需求的过程。如：安装指导、用户培训、售后技术支持、接受投诉等。注：软件测试不仅仅是对程序的测试，还应包括对数据、文档和服务的测试。1.2.2 软件的特点1) 软件是硬件的灵魂，硬件是软件的基础2) 软件是智慧和知识的结晶3) 软件的核心是人4) 软件不会“磨损”1.2.3 软件的分类1) 按功能分类（固件、系统软件、中间件和应用软件） 固件：直接烧在芯片组或集成电路里的一段程序 系统软件能直接操作底层硬件，并为上层软件提供支持 中间件在应用软件和平台之间建立一种桥梁，常见的中间件包括数据库和万维网服务器 应用软件能为用户提供某种特定的应用服务2) 按技术架构分类（单机版软件、C/S 架构的软件、B/S 架构的软件） 单机版软件直接安装并运行在单个计算机上，如 office、ACDSee 等 C/S 架构的软件基于互联网或局域网，需要一台服务器来安装服务器端软件，每台客户端都要安装客户端软件，如 QQ、MSN 等 B/S 架构的软件：B/S 架构的软件也是基于互联网或局域网，但这类软件不需要安装客户端软件，只需要浏览器软件即可3) 按用户分类（产品软件和项目软件）4) 按开发规模分类（小型软件、中型软件和大型软件）1.2.4 软件测试定软件测试指使用人工河自动手段来运行或测试某个系统的过程，目的在于检验其是否满足规定的需求或弄清楚预期结果与实际结果之间的差别。1.3 软件缺陷1.3.1 软件缺陷的定义只有符合以下五条规则才能叫软件缺陷 软件未达到需求规格说明书中指明的功能 软件出现了需求规格说明书中指明不会出现的错误 软件功能超出需求规格说明书中指明的范围 软件未达到需求规格说明书中虽未指出但应达到的目标 软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好1.4 测试用例1.4.1 测试用例的定义定义：指执行条件和预期结果的集合，完整来讲是针对要测试的内容所确定的一组输入信息，是为达到最佳的测试效果或高效的揭露隐藏的错误而精心设计的少量测试数据。测试用例可以用一个简单的公式表示：测试用例=输入+ 输出 +测试环境输入：指测试数据和操作步骤○ 1输出：指系统的预期执行结果○ 2测试环境：指系统环境设置，包括软件环境、硬件环境和数据，有时还包括网络环境○ 31.4.2 测试用例的重要性测试用例的重要性体现在技术和管理两个层面1、 就技术而言，测试用例有利于以下方面：指导测试的实施○ 1规划测试数据的准备○ 2编写测试脚本的“设计规格说明书”○ 3降低工作强度○ 42、 就管理层面而言，使用测试用例的好处有以下几个方面团队交流○ 1重复测试○ 2检验测试员进度○ 3质量评估○ 4分析缺陷的标准○ 51.4.3 测试用例的评价标准有效性、经济性、可仿效性、可修改性、独立性、可跟踪性1.4.4 测试用例设计的基本原则1、测试用例的代表性能够代表并覆盖各种合理的和不合理的，合法的和非法的，边界的和越界的以及极限的输入数据、操作和环境设置等2、测试结果的可判定性即测试执行结果的正确性是可判定的，每一个测试用例都应有相应明确的预期结果，而不应存在二义性，否则将难以判断系统是否运行正常3、测试结果的可再现性即对同样的测试用例，系统的执行结果应当相同1.4.5 测试用例的输入通常考虑三方面的数据1、正常数据2、边界数据3、错误数据1.4.6 测试用例设计的注意事项1. 测试用例应尽早设计2. 测试用例由专门的人来设计3. 测试用例的功能描述要与软件需求规格说明书保持一致4. 测试用例的设计并非一劳永逸5. 在不知道预期结果的情况下，应推迟用例设计6. 在设计测试用例过程中注意与其他人员的沟通7. 测试用例在不同阶段下实施时应该是独立的8. 整个测试用例设计顺序逻辑性要强，以便于测试人员执行用例9. 测试用例应该满足自清除性10. 测试用例本身无法保证覆盖要求11. 每个测试用例应有一个唯一的标识1.4.7 测试需求1、定义：测试需求是指在一定的策略前提下，对应于验证某个系统的业务需求或功能需求的测试需求注意：软件需求与测试需求的不同在于：软件需求在于用于指导后续设计的开展，而测试需求则是直接源于客户的质量需求2、测试需求应包含两方面的内容：A、 确定测试什么，就是需求测试的内容B、 测试对软件产品的需求，解决需要产品为测试提供什么特性，可以更好的去测试的问题，就是我们通常所说的可测试性需求3、 测试需求的分类与分析对应不同的测试目的，可将测试需求分为两类：A、 验证业务过程的流程类测试需求B、 验证功能点的功能性测试需求1． 5 测试环境1、定义：测试环境就是软件运行的平台，即进行软件测试所必须的工作平台和前提条件公式表示：测试环境=硬件+ 软件+网络+历史数据硬件：指进行测试所必须的服务器、客户端、网络连接设备，以及打印机、扫描仪等辅助硬件设备所构○ 1成的环境软件：指被测软件运行时的操作系统，数据库及其它应用软件等构成的环境○ 2网络：主要针对 C/S、B/S 架构的软件○ 3历史数据：是指测试用例执行所需初始化的各项数据○ 42、测试环境的重要性加快测试速度○ 1准确重现缺陷○ 2提高工作效率和软件质量○ 33、良好测试环境的要素良好的测试模型○ 1多样化的系统配置○ 2熟练使用工具的测试员○ 3第二章 软件测试原理2.1 测试原则2.1.1 软件测试应追溯到用户需求软件开发的最终目的是要满足最终用户的需求，测试员应始终站在用户的角度去看问题，系统中最严重的缺陷是那些导致程序无法满足用户需求的缺陷。用户是软件最终使用者，同时往往也是软件的投资者。因此，不满足用户需求的软件是无法顺利交付和收回成本的。2.1.2 应尽早和不间断地测试2.1.3 对待缺陷的基本原则1、缺陷的群集现象2、缺陷有免疫力3、缺陷关联和依赖2.1.4 测试结果的处理原则1、对缺陷进行复查和确认2、测试结果的全面检查3、出错统计和分析4、妥善保存测试过程文档2.2 软件测试的分类2.2.1 按是否需查看代码分类1、黑盒测试（black-box testing）黑盒测试是将被测试软件看作一个黑盒子，只考虑系统的输入和输出，完全不考虑程序内部逻辑结构和处理过程黑盒测试的依据是各个阶段的需求规格说明黑盒测试又称功能性测试（functional testing）或数据驱动测试（ data-driven testing）2、白盒测试(white-box testing)白盒测试是将黑盒子打开，研究源代码和程序内部的逻辑结构白盒测试的依据是程序源代码白盒测试又称结构性测试（structural testing）或逻辑驱动测试(logic-driven testing)白盒测试白盒测试的定义白盒测试( White-box Testing，又称逻辑驱动测试,结构测试)是把测试对象看作一个打开的盒子。利用白盒测试法进行动态测试时，需要测试软件产品的内部结构和处理过程，不需测试软件产品的功能。白盒测试的目的通过检查软件内部的逻辑结构，对软件中的逻辑路径进行覆盖测试;在程序不同地方设立检查点，检查程序的状态，以确定实际运行状态与预期状态是否一致。白盒测试的实施步骤1. 测试计划阶段：根据需求说明书，制定测试进度。2. 测试设计阶段：依据程序设计说明书，按照一定规范化的方法进行软件结构划分和设计测试用例。3. 测试执行阶段：输入测试用例，得到测试结果。4. 测试总结阶段：对比测试的结果和代码的预期结果，分析错误原因，找到并解决错误。白盒测试的优缺点1. 优点 迫使测试人员去仔细思考软件的实现 可以检测代码中的每条分支和路径 揭示隐藏在代码中的错误 对代码的测试比较彻底 代码优化2. 缺点 昂贵（成本高） 无法检测代码中遗漏的路径和数据敏感性错误 不验证规格的正确性 无法检验程序的外部特征白盒测试法的循环覆盖1) 简单循环依据边界值测试2) 嵌套循环1) 最内层循环开始，见那个其他循环设为最小值2) 对最内层使用简单循环3) 由内到外4) 继续，直到测试到所有循环3) 串接循环1） 彼此独立，对每个循环进行简单循环测试2） 注意第一个循环是第二个循环的初始值，则使用检讨循环白盒测试法的逻辑覆盖白盒测试法的辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、修正判定条件覆盖和件组合覆盖六种覆盖标准：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、修正判定条件覆盖和件组合覆盖发现错误的能力呈由弱至强的变化。语句覆盖每条语句至少执行一次。判定覆盖每个判定的每个分支至少执行一次。条件覆盖每个判定的每个条件应取到各种可能的值。判定/条件覆盖同时满足判定覆盖条件覆盖。条件组合覆盖每个判定中各条件的每一种组合至少出现一次。路径覆盖使程序中每一条可能的路径至少执行一次。 语句覆盖 为了暴露程序中的错误，程序中的每条语句至少应该执行一次。因此语句覆盖（Statement Coverage）的含义是：选择足够多的测试数据，使被测程序中每条语句至少执行一次。语句覆盖是很弱的逻辑覆盖。判定覆盖 比语句覆盖稍强的覆盖标准是判定覆盖（Decision Coverage）。判定覆盖的含义是：它要求设计足够多的测试用例，使得程序中每个判定至少有一次为真值，有一次为假值，或者说使得程序中的每一个取“真”分支和取“假”分支至少经历一次，因此判定覆盖又称为分支覆盖。条件覆盖 在设计程序中，一个判定语句是由多个条件组合而成的复合判定。为了更彻底地实现逻辑覆盖，可以采用条件覆盖（Condition Coverage）的标准。条件覆盖的含义是条件覆盖要求设计足够多的测试用例，使得判定中的每个条件获得各种可能的结果，即每个条件至少有一次为真值，有一次为假值。判定/条件覆盖：设计足够多的测试用例，使得判定中每个条件的所有可能结果至少出现一次，每个判定本身所有可能结果也至少出现一次。修正判定条件覆盖这个覆盖度量需要足够的测试用例来确定各个条件能够影响到包含的判定的结果。它要求满足三个条件：1、判定（即由条件和零或者多个布尔操作符号组成的布尔表达式）中的每一个条件（即含有布尔操作符号组成的布尔表达式）的所有可能结果至少出现一次2、每一个判定本身的所有结果也至少出现一次3、每一个入口与出口点至少被唤醒一次，且每一个条件都能单独的影响判定的结果（即在其他条件不变的情况下改变这个条件的值，使得判定结果改变）条件组合覆盖，它的含义是：设计足够的测试用例，使得每个判定中条件的各种可能组合都至少出现一次。显然满足多条件覆盖的测试用例是一定满足判定覆盖、条件覆盖和条件判定组合覆盖的。静态白盒测试静态测试并不实际运行被测软件，而是直接分析软件的形式和结构，查找缺陷，主要包括对源代码，程序界面，各类文档及中间产品（如产品规格说明书、技术设计文档等）所做的测试，静态白盒测试的主要内容包括：代码检查、静态结构分析、代码质量度量、函数执行性能测试、动态内存