第一章软件测试概述V1分析报告.ppt

* 工作包括管理 例如性能测试等 * 手工完成测试的全部过程无法保证测试的科学性与严密性: 对测试过程中发现的缺陷缺乏科学、有效的管理手段，责任变得含混不清 测试花费的时间越长，测试的严格性也就越低；难以对不可视对象或对象的不可视属性进行测试。 ？？？ * 使用脚本录制/回放工具时，首先要执行一遍手工测试 * 因为一个软件模块本身不一定是一个单独的程序，所以必须为每个单元测试开发驱动器或/和稳定的桩(stub)。 在大多数应用中，一个驱动只是一个接收测试数据，并把数据传送给要测试的模块，然后打印相关结果的“主程序”。子程序桩的功能是替代那些被本模块调用的模块。 根据模块间关系的不同需要有不同的桩和驱动器，可以根据桩的类型开发一些通用结构的桩和驱动器，以减少桩和驱动器的开发工作量。 * 首先对代码风格和规则、程序设计和结构、业务逻辑等进行静态审议，及早地发现和解决不易显现的错误。 接口测试：保证进出单元模块的数据流是正确的。 内部数据结构：保证临时存储的数据在算法执行过程中的完整性。 全局数据结构：全局数据结构对单元模块的影响应当审查。 边界：采用边界值分析技术，保证模块在边界条件和及县情况下正常执行 语句覆盖：保证每个语句均执行一次 错误路径：对所有处理错误的路径进行测试 * 自顶向下集成：模块集成的顺序是首先集成主模块，然后按照控制层次结构向下进行集成，隶属于主模块的模块按照深度优先或广度优先的方式集成到整个结构中去。 自底向上集成：从原子模块开始来进行构造和测试，因为模块是自底向上集成的，进行时要求所有隶属于某个给定层次的模块总是存在的，也不再有使用稳定桩的必要。 集成测试的过程 明确测试目标和完成准则，并确定关键部分。 确定阶段和进度安排。 测试和修正协调的策划。 清理系统结构。 确定集成测试方法的组合策略。 描述集成顺序。 针对每次集成编制测试用例，从而形成测试方案。 进行附加软件（驱动器及桩）的开发。 测试软件和测试环境准备。 依据测试方案进行测试。 根据测试结果提交测试报告。 测试报告的分析。 缺陷的管理。 修正和测试工作。 完成测试软件提交配置。 * 在需求分析阶段要确定软件的可测性，保证有效完成系统测试工作。要对软件需求规范中的要求形成确认标准，并且在其形成之初进行评审，保证可测试性。对于一些不能由测试确认的需求，要在需求规范中说明，如果可能尽量明确其他的确认方式。 * 重新根据6、8特性定义 * 产品-确认测试 项目-用户验收测试 项目试运行-相当于b测试 * 当一个新的模块被当作集成测试的一部分加进来的时候，软件就发生了改变，这些改变可能使原本工作正常的功能产生错误。 * 选择回归测试策略应该兼顾效率和有效性两个方面。常用的选择回归测试的方式包括： 再测试全部用例 选择基线测试用例库中的全部测试用例组成回归测试包，测试成本最高 基于风险选择测试 可以基于一定的风险标准来从基线测试用例库中选择回归测试包。首先运行最重要的、关键的和可疑的测试，测试从主要特征到次要特征。 回归测试方式 基于操作剖面选择测试 重新测试修改的部分 基于操作剖面选择测试 测试所使用的测试用例个数可以由测试预算确定，回归测试可以优先选择那些针对最重要或最频繁使用功能的测试用例 重新测试修改的部分 当测试者对修改的局部化有足够的信心时，可以通过相依性分析识别软件的修改情况并分析修改的影响，将回归测试局限于被改变的模块和它的接口上 * 配置测试环境是测试实施的一个重要阶段，测试环境适合与否会严重影响测试结果的真实性和正确性。软件测试环境包括设计环境、管理环境和实施环境。 * 缺测试过程 * 测试用例的代表性，能够代表各种合理和不合理的、合法的和非法的、边界和越界的。以及极限的输人数据、操作和环境设置等。 测试结果的可判定性，即测试执行结果的正确性是可判定的或可评估的。 测试结果的可再现性，即对同样的测试用例，系统的执行结果应当是相同的。 测试人员拿到用例，可独自执行该用例，而不需要编写者的帮助。不会因为执行该测试用例而影响其它测试用例的执行，比如执行某些用例后，会对应用系统产生影响，用例中应说明如何将应用系统恢复到最初状态，而不影响后续测试的进行 什么是好的测试用例 准确 ，测试用例的设计确实符合测试需求 没有冗余步骤 可重用 可跟踪，是针对特定测试需求的 适当，对于当前的测试环境，对于测试者是可以执行的 独立于编写者，这要求用例应是详细的 * 对于手动执行的测试用例采用上文描述的用例设计方法，确定测试用例，然后详细描述执行步骤及预期结果。 对于可自动执行的测试用例首先采用工具录制脚本，如录制／回放工具，性能测试工具等，然后回放脚本，针对不能正确回放的脚本，进行修改。或者使用通用的脚