西工大软微软件测试[参照]

《西工大软微软件测试[参照]》由会员分享，可在线阅读，更多相关《西工大软微软件测试[参照]（8页珍藏版）》请在金锄头文库上搜索。

1、西北工业大学软件与微电子学院软件测试2011 ?软件缺陷 : 就是软件产品中所存在的问题, 最终表现为用户所需要的功能没有 完全实现 , 不能满足或不能全部满足用户的需求 ?软件错误 / 缺陷区别 ： 从产品内部看 , 软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等 各种问题； 从外部看 , 软件缺陷是系统所需要实现的某种功能的失效或违背。 软件测试：在特定的条件下运行系统或构件, 观察或记录结果 , 对系统的某个方面 做出评价；分析某个软件项以发现现存的和要求的条件之差别( 即错误 ) 并评价 此软件项的特性 ?测试是为了证明程序有错, 而不是证明程序无错误 一个好的测试用例是在于它

2、能发现至今未发现的错误 一个成功的测试是发现了至今未发现的错误的测试 ?单元测试 的对象是程序系统中的最小单元-模块或组件上 ,在编码阶段进行 ,针 对每个模块进行测试 ,主要通过白盒测试方法 ,从程序的内部结构出发设计测试用 例,检查程序模块或组件的已实现的功能与定义的功能是否一致、以及编码中是 否存在错误。多个模块可以平行地、对立地测试,通常要编写驱动模块和桩模块。 单元测试一般由编程人员和测试人员共同完成 单元测试主要采用白盒测试方法,辅以黑盒测试方法 ?黑盒测试方法 (Blake-box Testing),是把程序看作一个不能打开的黑盒子,不考虑 程序内部结构和内部特性,而是考察数据的

3、输入、条件限制和数据输出,完成测试 ?白盒测试方法 (White-box Testing),也称结构测试或逻辑驱动测试。 白盒测试方法 是根据模块内部结构了解,基于内部逻辑结构 ,针对程序语句、路径、变量状态等 来进行测试 ,检验程序中的各个分支条件是否得到满足、每条执行路径是否按预 定要求正确的工作。 白盒测试分类：静态 /动态 静态：关键功能是检查软件的表示和描述是否一致,没有冲突或起义 动态：语句、判断、条件、判定条件、条件组合、路径覆盖。 覆盖了所有语句 ,但不能保证覆盖了所有分支;条件覆盖不能保证分支覆盖 ?驱动程序 (driver),对底层或子层模块进行 (单元或集成 )测试时所编

4、制的调用被 测模块的程序 ,用以模拟被测模块的上级模块 ?桩程序 (stub),也有人称为存根程序 ,对顶层或上层模块进行测试时,所编制的替 代下层模块的程序 ,用以模拟被测模块工作过程中所调用的模块。 1 / 8 驱动程序 /驱动模块 （driver ） ，用以模拟被测模块的上级模块。驱动模块在集成 测试中接受测试数据， 把相关的数据传送给被测模块，启动被测模块， 并打印出 相应的结果。 桩程序 /桩模块 （stub） ，用以模拟被测模块工作过程中所调用的模块。桩模块由 被测模块调用， 它们一般只进行很少的数据处理，例如打印入口和返回， 以便于 检验被测模块与其下级模块的接口 ?集成测试 ,

5、也称组装测试、联合测试、子系统测试,在单元测试的基础上 ,将模块 按照设计要求组装起来同时进行测试,主要目标是发现与接口有关的模块之间问 题 。两种集成方式：一次性集成方式和增殖式集成方式。 非渐增式测试模式 ：先分别测试每个模块， 再把所有模块按设计要求放在一起结 合成所要的程序，如大棒模式。 渐增式测试模式 ：把下一个要测试的模块同已经测试好的模块结合起来进行测 试，测试完以后再把下一个应该测试的模块结合进来测试。 自顶向下测试：深度优先、广度优先 采用三明治方法的优点是：它将自顶向下和自底向上的集成方法有机地结合起 来，不需要写桩程序因为在测试初自底向上集成已经验证了底层模块的正确性。

6、采用这种方法的主要缺点：在真正集成之前每一个独立的模块没有完全测试过。 改进的三明治集成方法，不仅自两头向中间集成，而且保证每个模块得到单独 的测试，使测试进行得比较彻底。 A BCD EF G Test 驱动程序 调用 运行 桩程序桩程序 测试结果 被测模块 B 2 / 8 ?功能测试 一般须在完成集成测试后进行,而且是针对应用系统进行测试。 功能测 试是基于产品功能说明书,是在已知产品所应具有的功能,从用户角度来进行功能 验证,以确认每个功能是否都能正常使用 方法：等价类划分法边界值分析法循环结构测试的综合方法因果图法决策 表方法 功能图法正交试验设计方法 ?系统测试 是将软件放在整个计算

7、机环境下,包括软硬件平台、 某些支持软件、 数 据和人员等 ,在实际运行环境下进行一系列的测试,包括恢复测试、安全测试、强 度测试和性能测试等 用户的需求可以分为 功能性需求 和非功能性需求 ， 而非功能性的需求被归纳为软 件产品的各种质量特性，如安全性、兼容性和可靠性等 系统测试 就是针对这些非功能特性展开的， 就是验证软件产品符合这些质量特性 的要求，从而满足用户和软件企业自身的非功能性需求。所以，系统测试分为负 载测试、性能系统、容量测试、安全性测试、兼容性测试和可靠性测试等 ?负载测试和性能测试有较多相似之处，例如，测试方法比较接近、都关注系统 的性能，而且多数情况下使用相同的测试工具

8、 ?负载测试 可以看作是性能测试所采用的一种技术，是通过模拟实际软件系统所 承受的负载条件、改变系统负载大小和负载方式来发现系统中所存在的问题 ?压力测试 可以被看作是负载测试的一种，即高负载下的负载测试 是在强负载情况下（如大数据量、大量并发用户连接等）稳定性进行测试，查看 应用系统在峰值 （瞬间使用高峰） 使用情况下的行为表现， 更有效地发现系统稳 定性的隐患和系统在负载峰值的条件下功能隐患等，确认系统是否具有良好的容 错能力和可恢复能力。 压力测试是在系统（ 如 CPU、内存和网络带宽等 ）处于饱和状态下，测试系统 是否还具有正常的会话能力、 数据处理能力或是否会出现错误，以检查软件系统

9、 对异常情况的抵抗能力，找出性能瓶颈、功能不稳定性等问题。 类型： 稳定性压力测试 ，高负载下持续运行24小时以上的压力测试 破坏性压力测试 :通过不断加载的手段快速造成系统的崩溃,让问题尽快地暴露出 来 渗入测试（soak test ） ，通过长时间运行，使问题逐渐渗透出来，从而发现内存泄 漏、垃圾收集（ GC）或系统的其他问题，以检验系统的健壮性 峰谷测试（peak-rest test ） ，采用高低突变加载方式进行， 先加载到高水平的负载， 然后急剧降低负载， 稍微平息一段时间， 再加载到高水平的负载， 重复这样过程， 容易发现问题的蛛丝马迹，最终找到问题的根源。 ?性能测试 是为获取或

10、验证系统性能指标而进行的测 ?容量测试通过负载测试或其它测试方法，预先分析出反映软件系统应用特征 的某项指标的极限值（如最大并发用户数、数据库记录数等），在其极限值状态 下系统主要功能还能保持正常运行 3 / 8 容量测试属于性能测试中的一种，一般采用逐步加载的负载测试方法，也可以先 采用逐步加载方式， 获得一个基本的容量值或容量范围，然后再考虑用一次性加 载方式，来决定实际可支持的容量值。 ?验收测试 按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个 系统的测试与评审， 决定是否接收或拒收系统。 在系统测试的后期， 以用户测试 为主或有测试人员等质量保证人员共同参与的测试 的目的

11、是向未来的用户表明系统能够像预定要求那样工作,验证软件的功能和性 能如同用户所合理期待的那样 测试： 指的是指的是由用户，测试人员、开发人员等共同参与的内部测试。 测试： 指的是内测后的公测，即完全交给最终用户测试 正式的验收测试 ?安装测试 是指按照软件产品安装手册或相应的文档,在一个和用户使用该产品 完全一样的环境中或相当于用户使用环境中,进行一步一步的安装操作性的测试 ?软件缺陷并不只是在编程阶段才产生, 需求和设计阶段同样会产生缺陷。 软件需求定义中存在缺陷最多 ?功能性测试需求主要是根据产品规格说明书来检验被测试的系统是否满足软 件各方面的功能的使用要求, 包括用户界面的友好性。 ?

12、测试用例 (test case) 是可以被独立执行的一个过程, 这个过程是一个最小的测试 实体, 不能再被分解。测试用例也就是为了某个测试点而设计的测试操作过程序 列、条件、期望结果及其相关数据的一个特定的集合。 ?自动化测试 (automated test)是相对手工测试 (manual test)而存在的一个概念 ,由 手工逐个地运行测试用例的操作过程被测试工具自动执行的过程所代替。测试工 具的使用是自动化测试的主要特征 ?自动化测试vs. 测试自动化 自动化测试 焦点集中在测试执行 ,主要是由测试工具自动地完成测试。 4 / 8 测试自动化 指“ 一切可以由计算机系统自动完成的测试任务都

13、已经由计算机系统 或软件工具、程序来承担并自动执行” 自动化测试：测试工具 ,测试执行 ,单项活动 测试自动化：理念 ,全过程 ,所有测试活动 ,包括测试设计 ,测试管理 自动化测试特点：自动运行的速度快,测试结果准确。高复用性。永不疲劳。可 靠。独特的能力 手工测试vs.自动测试 发现缺陷率高。容易实施。创造性、灵活性。覆盖率量化困难重复测试效率低。 不一致性、可靠性低。依赖人力资源 高效率 ( 速度)高复用性覆盖率容易度量准确、可靠不知疲劳激励团队士气 机械、难以发现缺陷一次性投入大 ?测试覆盖率， 简单的说，就是评价测试活动覆盖产品代码的指标。测试的目的， 是确认产品代码按照预期一样工作

14、，也可以看作是产品代码工作方式的说明文 档。进一步考虑，测试覆盖率可以看作是产品代码质量的间接指标之所以说 是间接指标，因为测试覆盖率评价的是测试代码的质量，并不是产品代码的质量。 代码覆盖率是一种白盒测试， 因为测试覆盖率是评价产品代码类内部的指标，而 不是评价系统接口或规约。 测试覆盖率尤其用于评价测试代码是否已经覆盖了产 品代码所有的路径。 ?LDRA Testbed可度量下列多条件判定的覆盖指标： 分支条件覆盖（ BCC） 度量判定中的每个条件是否都取值TRUE 和 FALSE 分支条件组合覆盖（ BCCC） 度量判定中的每个条件同其他条件的每个组合是否都取值TRUE 和 FALSE

15、修正条件判定覆盖 BCCC 非常费力 , 而 MC/DC 只测试组合总数的子集 MC/DC 是一种度量多条件判定的覆盖，它并不要求执行每种可能的组合 如果条件的数目是n，那么至少有 n + 1个组合需要达到100%的覆盖，而不是 2n个组合 ?等价类 是某个输入域的子集，在该子集中每个输入数据的作用是等效的 将程序可能的输入数据分成若干个子集，从每个子集选取一个代表性的数据作为 测试用例，在分析需求规格说明的基础上划分等价类，列出等价类表 ?有效等价类 是有意义的、合理的输入数据，可以检查程序是否实现了规格说明 中所规定的功能和性能 无效等价类 和有效等价类相反， 即不满足程序输入要求或者无效

16、的输入数据构成 的集合 ?在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类 和两个无效等价类 在输入条件规定了输入值的集合或者规定了“ 必须如何 ” 的条件的情况下，可以确 立一个有效等价类和一个无效等价类。 在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类 5 / 8 在规定了输入数据的一组值( 假定 n 个) ，并且程序要对每一个输入值分别处理， 这种情况下可确立n 个有效等价类和一个无效等价类 在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类 ( 符合规则 ) 和若干个无效等价类 ( 从不同角度违反规则 )。 ?边界值计方法 确定边界情况（输入或输出等价类的边界） 选取正好等于、刚刚大于或刚刚小于边界值作为测试数据 如果输入条件规定了值的范围， 则应取刚达到这个范围的边界的值，以及刚刚超 越这个范围边界的值作为测试输入数据。 如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少一、比 最大个数多一的数作为测试数据 如果软件规格说明给出的输入/ 输出域是有序集合，则应选取集合的第一个元素 和最后一个