《软件测试》复习重点(精).doc

1. 软件开发过程中错误之所以不可避免, 从客观上说, 是由于所开发的软件具有相当的复杂 性。从主观方面讲,则是由于人们思维的局限性。2. 软件测试是指在特定的条件下系统或其中的部件进行操作、 观测并记录结果, 并对系统或 部件的某方面作出评估的过程。3.Myers 给出的三个重要观点:测试是为了证明程序有错,而不是证明程序无错误;一个好的测试用例是在于它能发现至今未发现的错误;一个成功的测试是发现了至今未发现的错误的测试。4. 错误出现在书写程序的过程中导致错误的原因 :对需求的误解;编写代码逻辑不清或疏忽软件配置错误故障是错误在程序代码中的体现,程序中的故障就是导致程序按照非预期的方式运行的因 素, 并不是所有的软件故障均有编码错误引起, 当一段包含故障的代码被执行且导致不正确 的状态并传播到程序的输出,即失效发生。并不是所有的故障均会导致失效,一个故障可能导致多种失效症状由错误故障失效的基本过程:由于程序设计人员犯了一个错误, 并导致软件源代码中形成一个故障。 如果在一定的条件下 该故障被执行且促使系统产生错误的结果,从而形成了一个失效。5. 软件可靠性就是软件在给定条件和给定时间间隔内不出现失效的概率。软件正确性只有当一个程序在 每一种输入 下都能按预期执行才能被称为是正确的。 正确性是一种二进制度量,而可靠性则是 0至 1的区间度量。6. 软件调试是在计算机程序中发现故障并减少其数目的一个方法性的过程。Testing 与 Debugging 的区别测试的目的是显示存在错误, 而调试的目的是发现错误或导致程序失效的错误原因, 并修改 程序以修正错误。调试是测试之后的活动。测试和调试在目标、方法和思路上都有所不同,具体如下:1. 测试从一个已知的条件开始,使用预先定义的过程,有预知的结果。调试从一个未知的 条件开始,结束的过程不可预计。2. 测试过程可以事先设计,进度可事先确定。调试不能描述过程或持续时间。3. 测试是显示错误的行为;调试是推理的过程。4. 测试显示开发人员的错误;调试是开发人员为自己辩护。5. 测试能预期和可控;调试需要想象,经验和思考。6. 测试能在没有详细设计的情况下完成;没有详细设计的信息调试不可能进行。7. 测试能由非开发人员进行;调试必须由开发人员进行。7. SQA与 ST 的区别与联系软件测试和软件质量保证是软件质量工程的两个不同层面的工作。软件测试只是软件质量保证工作的一个重要环节。质量保证 (QA的工作是通过预防、检查和改进来保证软件质量。SQA 从流程方面保证软件的质量ST 从技术方面保证软件的质量QA 采取的方法主要是按照“全面质量管理”和“过程管理”并改进的原来展开工作。 在质量 保证的工作中会掺入一些测试活动, 但它所关注的是软件质量的检查和测量。 因此, 其主要 工作是着眼于软件开发活动中的过程、 步骤和产物, 并不是对软件进行剖析, 找出问题和评 估。测试虽然也与开发过程紧密相关, 但它所关心的不是过程的活动, 相对的是关心结果。 测试 人员要对过程中的产物 (开发文档和源代码 进行静态审核, 运行软件, 找出问题, 报告质量 甚至评估, 而不是为了验证软件的正确性。当然, 测试的目的是为了去证明软件有错, 否则 就违背了测试人员的本职了。 因此, 测试虽然对提高软件质量起了关键的作用, 但它只是软 件质量保证中的一个重要环节。SQA 重点是对软件开发过程进行监督、管理、控制;ST 重点是对软件开发的成果进行检查、控制。8. 确认是指如何决定最后的软件产品是否正确无误。验证是指如何决定软件开发的每个阶段、每个步骤的产品是否正确无误,并与其前面的 开发阶段和开发步骤的产品相一致。确认和验证是有联系的,但也有明显的差别。Boehm 在 1981年是这样来描述两者差别的:确认要回答的问题是:我们正在开发一个正确无误的软件产品吗?验证要回答的问题是:我们正开发的软件产品是正确无误的吗?9. CMM软件评估与 软件测试成熟度 T MM 无联系10. 软件测试方法可以从不同的角度进行分类:按照是否执行程序划分按照代码的可见性划分按照测试的实施者划分按照测试过程划分针对软件特定特征的测试11. 静态测试 是指不利用计算机运行被测试的程序, 而是通过人工的方式对程序或相关文档 进行检查以达到检测目的的方法。动态测试 就是通过执行被测程序, 并监视其执行状态、 收集并对比其执行结果以判断程序是 否正确运行的方法。12. 静态测试主要包含的方法有:桌面检查 (desktopcheck 一种最为传统的方法,由程序员检查自己编写的程序。程序员在 程序通过编译之后, 对源程序代码进行分析、 检验,并补充相关的文档,目的是发现程序中 的故障。 由于程序员熟悉自己的程序及其程序设计风格, 桌面检查由程序员自己进行可以节 省很多的检查时间,但应避免主观片面性。同行评审 (peer review 由若干程序员和测试员组成一个审查小组, 通过阅读、 讨论和争议, 对程序进行静态分析的过程。通常分两步进行:小组负责人提前把设计规格说明书、控制流程图、程序文本及有关要求、规范等分发给 小组成员,作为审查的依据。小组成员在充分阅读这些材料后,进入评审的第二步。召开评审会。在会上,首先由程序员逐句讲解程序的逻辑。在此过程中,程序员或其他 小组成员可以提出问题,展开讨论,审查缺陷是否存在。实践表明, 程序员在讲解过程中能发现许多原来自己没有发现的错误, 而讨论和争议促进了 问题的暴露。代码走查 (code walkthrough 代码走查同样也分两步进行:第一步也是把材料先发给走查小组成员,让他们认真研究程序,然后再开会。开会的程序与同行评审不同,不是简单地读程序和对照错误检查单进行检查,而是让与 会者“充当”计算机, 即首先由测试组成员为所测程序准备一批有代表性的测试用例, 提交 给走查小组。 走查小组开会, 集体扮演计算机角色, 让测试用例沿程序的逻辑进行运行一遍,随时记录程序的执行轨迹,供分析和讨论用。走查人员借助测试用例的媒介作用, 对程序的逻辑和功能提出各种疑问, 结合问题开展热烈 的讨论和争议,能够发现更多的问题。13. 功能性测试 , 又称作黑盒测试、 基于规格说明的测试等, 是通过软件的外部表现来发现 其缺陷和错误,检查程序是否按照需求规格说明书的规定正常实现。结构性测试 ,又称作白盒测试、 基于程序的测试等,通过分析程序的内部结构,以覆盖程序 结构元素为目标的一类测试方法的总称在结构性测试中可使用各种测试方法的综合策略如下:在测试中,应尽量先用工具进行静态结构分析。测试中可采取先静态后动态的组合方式:先进行静态结构分析、代码检查和静态质量度 量,再进行覆盖率测试。利用静态分析的结果作为引导,通过代码检查和动态测试的方式对静态分析结果进行进 一步的确认,使测试工作更为有效。覆盖率测试是白盒测试的重点,一般可使用基本路径测试法达到语句覆盖标准;对于软 件的重点模块,应使用多种覆盖标准衡量代码的覆盖率。在不同的测试阶段,测试的侧重点不同:在单元测试阶段,以代码检查、逻辑覆盖为主; 在集成测试阶段,需要增加静态结构分析、静态质量度量;在系统测试阶段,应根据黑盒测 试的结果,采取相应的白盒测试。14. 过错缺陷:是指在实现软件过程中对某些功能进行了错误的实现而引起的一类软件缺 陷。遗漏缺陷:是指在实现软件过程中遗漏对某些功能的实现而引起的一类软件缺陷15. 功能性测试 遗漏缺陷结构性测试 过错缺陷能力强16. 灰盒测试结合了白盒测试盒黑盒测试的要素,是两者的折中17. 按照测试实施的组织,软件测试通常可以划分为如下三类:开发方测试:通常也叫“验证测试”或“ 测试”。用户方测试:通常也叫 测试第三方测试:介于软件开发方和用户方之间的测试组织实施的测试活动。是由在技术、 管理和财务上与开发方和用户方相对独立的组织进行的软件测试。 一般情况下是在模拟用户 真实应用的环境下,进行软件确认测试。18. 功能性测试 v.s. 结构性测试 19. 按照测试过程,通常可以划分为如下四个步骤:单元测试 (Unit Testing:又称为模块测试,针对软件设计的程序模块进行正确性检验 的测试工作集成测试 (Integrated Testing :集成测试也叫组装测试,通常是在单元测试的基础上, 对由若干个模块组装而成的子系统实施的测试。确认测试 (Validation Testing:验证软件的功能和性能及其他特性是否与用户的要求 一致。系统测试 (System Testing:是将通过集成测试的软件,作为整个基于计算机系统的一 个元素,与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起,在 实际或者模拟运行 (使用 环境下,对计算机系统进行的一系列测试。验收测试 (Acceptance Testing:验收测试往往不是对系统进行全覆盖测试,而是针对 用户的核心业务流程进行的测试。20. 单元测试要解决的问题:模块接口:对于被测模块,信息能否正常无误地流入和流出。 (应首先检验 局部数据结构:在模块工作过程中,其内部的数据能否保持其完整性,包括内部数据的 内容、形式及相互关系不发生错误。边界条件:在为限制数据加工而设置的边界处,模块是否能够正常工作。覆盖条件:模块的运行能否做到满足特定的逻辑覆盖。出错处理:模块工作中发生了错误,其中的出错处理设施是否有效。21. 驱动模块 (driver:用以模拟被测模块的上级模块。桩模块 (stub:用以模拟被测模块工作过程中所调用的模块。22. 集成测试的分类:非增量式集成测试增量式集成测试1. 自顶向下集成测试:将模块按系统程序结构,沿控制层次自顶向下进行组装。 、 测试实施步骤:(1 首先以主模块作为所测模块兼驱动模块, 所有直属于主模块的下属模块全部用桩模块代 替,对主模块进行测试。(2 再采用深度优先或广度优先的策略, 用实际模块代替相应的桩模块, 再用桩模块代替它 们的直接下属模块,与已测试的模块或子系统组装成新的子系统。(3 然后测试新组装成的子系统, 排除组装过程中引入新错误的可能, 直至所有模块均组装 到系统中为止。优点:(1 在测试过程中较早地验证了主要的控制和判断点,能较早地发现主要控制方面的问题 。(2如果选用按深度方向组装的方式,可以首先实现和验证一个完整的软件功能,可先对逻 辑输入的分支进行组装和测试, 检查和克服潜藏的错误和缺陷, 验证其功能的正确性, 为对 其后分支的组装和测试提供了保证。缺点:(1 在测试需要建立桩模块,而要使桩模块能够模拟实际子模块的功能十分困难。(2 涉及复杂算法和真正输入 /输出的模块一般在底层,它们是最容易出问题的模块,到组 装和测试的后期才遇到这些模块,一旦发现问题,就会导致过多的重复测试。2. 自底向上集成测试:实施步骤:(1 首先由驱动模块控制最底层模块的并行测试, 也可以把底层模块组合成实现某一特定软 件功能的簇,由驱动模块控制它进行测试。(2 再用实际模块代替驱动模块,与它已测试的直属子模块组装成为子系统。(3然后为子系统配备驱动模块并进行新的测试,直至组装达到主模块为止。优点:(1 不需要桩模块, 而建立一个驱动模块一般比建立桩模块容易。 (2 由于涉及到复 杂算法和真正输入 /输出的模块最先得到组装和测试, 可以把容易出问题的部分在早期解决。 (3 可以实施多个模块的并行测试,从而提高测试效率。缺点:程序一直未能作为一个实体存在, 直到最后一个模块加上去后才形成一个实体。 也就 是说,在自底向上组装和测试的过程中,对主要的控制直到最后才接触到。23. V模型 V 模型是软件开发瀑布模型的变种,它反映了测试活动与分析和设计的关系,从左到右,描 述了基本的开发过程和测试行为, 非常明确地表明了测试过程中存在的不同级别, 并且清楚 地描述了这些测试阶段和开发过程期间各阶段的对应关系。V 模型的软件测试策略既包括低层测试又包括了高层测试, 低层测试是为了源代码的正确性, 高层测试是为了使整个系统满足用户的需求。V 模型的局限性:仅仅把测试过程作为在需求分析、概要设计、详细设计及编码之后的一个阶段。容易使人理解为测试是软件开发的最后的一个阶段, 主要是针对程序进行测试寻找错误, 而 需求分析阶段隐藏的问题一直到后期的验收测试才被发现。V 模型的局限性在于没有明确地说明早期的测试, 不能体现 “ 尽早地和不断地进行软件测试 ” 的原则。改进措施:在 V 模型中增加软件各开发阶段应同步进行的测试, 被演化为一种 W 模型, 因为实 际上开发是“ V ”,测试也是与此相并行的“ V ”。W 模型W 模型的局限性:W 模型和 V 模型都把软件的开发视为需求、设计、编码等一系列串行的活动。开发和测试保持一种线性的前后关系,无法支持迭代、自发性以及变更调整。24. 软件测试信息流: 软件配置 :包括软件需求规格说明、软件设计规格说明、源代码等。测试配置 :包括测试计划、测试用例、测试驱动程序等。实际上,在整个软件工程中,测试 配置只是软件配置的一个子集。测试工具 :为测试的实施提供某种服务, 以减轻测试任务中的手工劳动。例如:测试数据自 动生成程序、静 (动 态分析程序、测试结果分析程序以及驱动测试的测试数据库等。25. 回归测试 (Regression Testing :在软件维护过程中,为了确保修改代码或新增功能的 正确性,并保证修改部分不带来副作用的测试活动称之为回归测试。回归测试的基本过程:(1识别出软件中被修改的部分。(2从原基线测试用例库 T 中, 排除所有不再适用的测试用例, 确定那些对新的软件版本依然 有效的测试用例,其结果是建立一个新的基线测试用例库 T0。(3依据一定的策略从 T0中选择测试用例测试被修改的软件。(4如果必要,生成新的测试用例集 T1,用于测试 T0无法充分测试的软件部分。(5用 T1执行修改后的软件。第 (2和第 (3步测试验证修改是否破坏了现有的功能, 第 (4和第 (5步测试验证修改工作本 身。26. 测试用例的维护主要内容包括下述几个方面:(1删除过时的测试用例。(2改进不受控制的测试用例:一些对输入或运行状态十分敏感的测试用例测试不容易重 复且结果难以控制。(3删除冗余的测试用例。 测试用例集约简(4增添新的测试用例。26. 在组织回归测试时需要注意两点:首先是各测试阶段发生的修改一定要在本测试阶段内完成回归,以免将错误遗留到下一 测试阶段。其次, 回归测试期间应对该软件版本冻结, 将回归测试发现的问题集中修改, 集中回归。 27. 功能性测试方法1. 边界值测试2. 等价类 (划分 测试:把所有可能的输入数据,即程序的输入域划分成若干部分,然后从 每个部分中选取少数 代表性 数据当作测试用例。两个步骤:(1 划分等价类;划分原则 (1 如果输入条件规定了取值范围, 或值的个数, 则可以确立一个有效等价类和两 个无效等价类。例如,在程序的规格说明中,对输入条件有一句话:“ 项数可以从 1到999 ” 则 有效等价类是“1项数999”, 两个无效等价类是“项数999”。 在数轴上表示成 :划分原则 (2 如果输入条件规定了输入值的集合, 或者是规定了“必须如何”的条件, 这时 可确立一个有效等价类和一个无效等价类。例如, 在 Pascal 语言中对变量标识符规定为“以字母打头的串”。 那么所有以字母打头 的构成有效等价类,而不在此集合内 (不以字母打头 的归于无效等价类。划分原则 (3 如果输入条件是一个布尔量,则可以确定一个有效等价类和一个无效等价类。 划分原则 (4 如果规定了输入数据的一组值 (假定 n 个 , 而且程序要对每个输入值分别进行处 理。 这时可为每一个输入值确立一个有效等价类 (共 n 个 , 此外针对这组值确立一个无效等 价类,它是所有不允许的输入值的集合。划分原则 (5 如果规定了输入数据必须遵守的规则,则可以确立一个有效等价类 (符合规则 和若干个无效等价类 (从不同角度违反规则 。划分原则 (6 如果我们确知,已划分的等价类中各元素在程序中的处理方式是不同的,则应 将此等价类进一步划分成更小的等价类。(2 选取测试用例。例:某程序规定:“输入三个整数作为三边的边长构成三角形。当此三角形为一般三角形、 等腰三角形及等边三角形时,分别做计算.”试用等价类划分方法为该程序进行测试用例 设计。依据程序的需求规格说明, 可以看出程序输入条件要求的关键之处有:(1整数 ; (2三个数 ; (3非零数 ; (4正数输出条件要求的关键之处有:(5应满足两边之和大于第三边 ; (6等腰 ; (7等边其中, (3、 (4和 (5并没有在题目上明显给出,但这些条件是必要的。 列出等价类表:列出覆盖上述等价类的测试用例: 覆盖有效等价类的测试用例: 覆盖无效等价类的测试用例:3. 判定表测试方法:判定表 (决策表 是分析和表达多逻辑条件下执行不同操作的情况下的 工具。判定表的建立步骤:(根据软件规格说明 1. 确定条件及其可能的取值;2. 确定规则的个数;3. 确定动作项;4. 填入条件项的可能取值;5. 针对每一条规则,填入恰当的动作项值;6. 验证规则是否正确;7. 化简规则。条件桩 (Condition Stub:列出了问题的所有条件,通常认为列出的条件的次序无关紧要。 动作桩 (Action Stub:列出了问题规定可能采取的操作,这些操作的排列顺序没有约束。 条件项 (Condition Entry:列出针对它左列条件 (即条件桩 的取值。动作项 (Action Entry:列出在条件项的各种取值情况下应该采取的动作。规则 (Rule:任何一个条件组合的特定取值及其相应要执行的操作。 在判定表中贯穿条件项 和动作项的一列就是一条规则。4. 因果图测试方法因果图测试方法的基本步骤1、 分析软件规格说明描述中, 哪些是原因 (即输入条件或输入条件的等价类 , 哪些是结果 (即 输出条件 ,并给每个原因和结果赋予一个标识符。2、分析软件规格说明描述中的语义,找出原因与结果之间、原因与原因之间的关系。根据 这些关系,画出因果图。3、标明原因与原因之间,原因与结果之间不可能出现的组合情况地约束或限制条件。4、把因果图转换成判定表。5、把判定表的每一列拿出来作为依据,设计测试用例。例:设要对一个自动饮料售货机软件进行黑盒测试, 该软件的规格说明如下:有一个处理单 价为 1元 5角钱的盒装饮料的自动售货机软件。 若投入 1元 5角硬币, 按下“可乐”、 “雪碧” 或“红茶”按钮, 相应的饮料就送出来。 若投入的是 2元硬币, 在送出饮料的同时退还 5角硬 币。首先,可以列出原因和结果如下:原因:(1 投入 1元 5角硬币; (2 投入 2元硬币; (3 按“可乐”按钮; (4 按“雪碧”按 钮; (5 按“红茶”按钮。中间状态:(11 已投币; (12 已按钮。结果:(1 退还 5角硬币; (2 送出“可乐”饮料; (3 送出“雪碧”饮料; (4 送出“红 茶”饮料。 根据原因和结果,可以设计这样一个因果图如下:转换为测试用例,如下表所示,每一列可作为确定测试用例的依据5. 组合测试方法 用在两个方面：1.程序输入；2.配置空间 正交设计试验：假定有一个3因子3水平的测试问题，其中三个因素分别记为A、B和C，三个 水平则分别用1、2、3表示。 如果取三因子所有水平的组合，则可以得到： 简单对比法： 首先固定B、C于B1、C1，使A变化： 如得出结果A3最好，则固定A于A3，C还是C1，使B变化： 得出结果以B2为最好，则固定B于B2，A于A3，使C变化： 28. 测试用例：就是事先设计的程序的一种执行情形，主要由测试数据与期望结果构成。看 程序在测试数据的输入下，能否正常运行并且达到所设计的预期执行结果。 29. 程序插装就是向程序中插入一条或是多条语句， 以便监视程序的某方面的执行特征或行 为。 分类：语句覆盖插装；边覆盖插装；断言插装 30. 控制流分析(Control Flow Analysis, CFA就是发现一个过程(方法中的控制流，并用 适当的形式表达出来，可扩展到过程(方法间。 常见的控制流表示方式有两种： (1 抽象语法树AST，主要用于程序编译处理阶段，进行程序控制逻辑的存储与优化； (2 控制流图CFG，是在AST基础上更高层的抽象表示，能较好地可视化表示程序中语句、 模块之间的执行顺序和相互调用关系，被公认是当今程序分析、理解与测试的基础。此外， 还有一些基于形式语义的分析与表示方法。 31. 控制流图CFG是一有向图G = (N, E, nentry, nexit. 其中， N是节点集，程序中的每 个语句都对应图中的一个节点；边集E = | n1, n2 N且n1执行后，可能立即 执行n2； nentry和nexi分别为程序的入口和出口节点。 程序控制流图的绘制： 程序语句格式化、规范化处理； 识别程序的逻辑行； 根据