UESTC电子科大软件测试期末复习

这是软件测试期末复习的课件总结，放在这里了嗷！！！

第一章：软件测试引论

• 为啥软件测试：

  • 软件中的缺陷有时带来巨大损失或灾难。
  • 只有通过测试 -> 发现缺陷 -> 解决缺陷保证软件质量

• 什么是软件测试：

  • 一种挨近侧软件的安全性，完整性，正确性和评估其质量的活动过程。以程序错误，衡量软件质量为目的。
  • 思维方式：
    • 正向思维：验证软件正常工作。
    • 逆向思维：找出软件有缺陷的证据。
  • 软件测试开销大，占总成本的30%到50%
  • 测试人数约为开发人员的一倍。
  • 测试法则：
    • 穷尽测试不可能
    • 测试具有创造性，但困难
    • 减少但是不可能完全消除
    • 测试有成本，成本高昂
    • 测试需要计划性
    • 测试需要独立性
  • 瀑布模型：修改代价高，只能发现编程缺陷。
  • 测试与开发的关系：

  

• 软件质量保证：

  • 通过对于软件产品进行有计划的评审和审计，来保证软件开发按照产品质量过程标准实施项目的管理活动。
  • 主要任务：
    • 审查和验证软件开发过程是否遵守适用的标准，规程和要求，最终保证产品满足用户需求。
    • 建立软件质量要素的度量机制，对于软件开发的各种质量指标进行量化。
  • 主要工作活动：
    • 质量规范指定
    • 技术评审实施
    • 软件测试流程追踪…
  • 软件质量保证和软件测试的关系：
    • SQA指导软件测试的计划和执行
    • 软件测试是SQA落实的重要手段
    • SQA是管理，软件测试是技术

• 测试驱动开发（TDD）：

  • 根据需求编写测试用例
  • 满足易测试和测试独立性要求
  • 测试在编码之前，频繁测试，提高代码质量。
  • 支持回归测试
  • 有助于编写简洁可用的高质量的代码，加速开发。

问题：

• 答案：C , D

书上：

• 正方：测试是为了程序能够按照预期设想运行而建立足够的信心。
• 反方：测试是为了发现错误而执行一个程序或者系统的过程。
• 测试以检验是否满足需求为目标嗷！！！
• Pareto原则：80/20原则
• V模型：
  • 需求定义 — 验收测试
  • 系统设计 — 非功能性测试
  • 详细设计 — 功能性测试
  • 编码 — 单元测试
• SQA和软件测试之间，既存在包含又存在交叉的关系，二者都贯穿整个软件开发生命周期流程。
• TDD

第二章：软件测试基本概念

软件缺陷

• 软件缺陷：
  • 质量：产品或服务满足明示或隐含需求能力的固有特性集合。
  • 软件质量：软件产品或服务满足用户需求的程度。
  • McCall：
    • 产品操作：
      • 正确性
      • 可靠性
      • 效率
      • 完整性
      • 易用性
    • 产品修改：
      • 可维护性
      • 可测试性
      • 灵活性
    • 产品转换：
      • 可移植性
      • 重复性
      • 互用性
  • ISO 9126：
    • 功能性：满足设计规范和满足用户需求的程度
    • 可靠性：能维持其正常的功能操作，性能水平
    • 易用性：用户学习，操作，使用软件是否容易
    • 效率：软件处理的时间效率等
    • 可移植性：移植的容易程度
    • 可维护性：出现问题修改是否容易
    • 兼容性：软件之间或软硬件之间相互协调工作的程度。
    • 可拓展性：软件增加功能，扩充系统能力的难易程度。
  • 软件质量的分类：
    • 使用质量：
      • 对于软件有效性，安全性，满意性等评估
    • 外部质量：
      • 功能性，可靠性，易用性，效率，维护性，可移植性
    • 内部质量：
      • 代码耦合性，数据耦合性，程序规范性，需求可溯性，代码复杂度等
    • 过程质量
• 软件缺陷定义：
  • 软件存在的任何一种破坏正常运行能力的问题，错误，异常或错误等。
  • 观点：
    • 内部：开发或维护过程中的问题
    • 外部：对于功能的违背
  • 常用BUG代替Defect
• 软件缺陷常见现象：
  • 运行出错
  • 运算错误
  • 功能特性没有实现
  • 设计不合理等
• 出现原因：
  • 技术问题：
    • 系统复杂性，开发人员技术能力局限性
    • 需求经常更改，说明书不完善
    • 不成熟的新技术
  • 软件本身：
    • 不完善的开发标准
    • 没有考虑大量的用户访问
    • 与硬件，第三方软件之间存在紧密依赖，兼容性不好。
  • 团队工作：
    • 理解不一致
    • 软件质量不够重视
  • 软件缺陷构成：
    • 代码：23%
    • 需求：41%
    • 详细设计：24%
    • 概要设计：12%

• 需求规格说明书会产生最多的软件缺陷：
  • 分析人员与用户沟通有偏差
  • 用户需求更改
  • 对于说明书不够重视，有歧义。
• 软件缺陷在不同的开发阶段：

• 发现缺陷数量随着过程越来越少，但是修复缺陷的成本越来越高！！！

• 结论：
  • 缺陷早期出现概率大，成本低
  • 后期出现概率小，成本高
  • 测试应该尽早开始！！！

软件测试分类：

• 按测试方式分类：
  • 手工
  • 自动化
  • 静态
  • 动态
• 按测试对象分类：
  • 单元
  • 接口
  • 数据库
  • 界面
  • 系统
  • 文档

静态与动态测试

• 静态测试：

  • 测试系统需求规格说明书，设计规格说明书（评审）。对于程序代码进行审查以及静态分析。
  • 发现缺陷：
    • 数组越界
    • 无条件分支
    • 控指针
    • 未被调用的程序和过程等
  • 说白了就是读程序，看文档呗orz

• 动态测试：

  • 被测程序进行运行，观察系统行为，变量结果，内存，堆栈等运行数据，判断系统是否存在缺陷的测试活动。

  • 发现缺陷：

    • 程序逻辑错误
    • 异常输入功能失效
    • 空指针的使用
    • 内存没有及时释放关闭的资源
    • Session失效
    • 没有处理空输入的情况。

• 产品评审：

  • 产品评审可以尽早发现需求分析，软件设计阶段的错误。
  • 定义：对于软件开发文档或者代码进行评估的一种手段，以确定其是否和预期结果一致，例如前后完整性，是否符合用户要求等。
  • 产品审查形式：
    • 走查
    • 互为评审
    • 会议评审

• 评审类型：
  • 软件测试部分：
    • 需求评审
    • 设计评审
    • 代码评审
    • 文档评审
  • 软件质量保证：
    • 管理评审
    • 流程评审（整个软件开发流程的评审）
• 静态分析：
  • 源代码研读
  • 人工检测:
    • 代码规范性
    • 算法合理性
    • 代码安全性
    • 代码容错性等
  • 计算机辅助静态评审：
    • 代码结构性
    • 代码安全性
    • 代码容错性
    • 算法复杂性
• 验证与确认：
  • 软件验证：正确的开发了软件
  • 软件确认：开发了正确的软件

主动和被动测试

• 主动测试：
  • 主动发送请求，借助数据和事件驱动被测试对象的行为，从而验证被测试对象的反应或输出结果。
• 被动测试：
  • 人员不干预产品的运行，被动监控产品在实际环境中的运行结果，借助检测机制来获得系统运行的数据。

黑盒和白盒测试：

• 黑盒：用户观点出发，发现软件的外部行为错误。

• 发现：

  • 错误的功能或功能遗漏
  • 不能正确处理输入数据，输出结果错误
  • 界面出错
  • 操作逻辑不方便
  • 安装过程出现问题
  • 初始化问题

• 测试用例与实现无关，可以与软件实现同时运行。

• 白盒：了解程序内部逻辑，对于程序内部变量，数据结构，运行路径进行的测试。检测程序内部动作或功能是否符合设计规格要求。

• 发现：

  • 逻辑错误
  • 状态异常
  • 路径无法跳转
  • 变量遗漏初始化

• 原则：

  • 先考虑各个分支被覆盖
  • 再考虑逻辑条件未真或者假
  • 测试所有独立路径、

• 局限：

  • 穷举路径测试不可能
  • 不能测出程序违反了设计规范的缺陷
  • 数据相关的异常错误发现不了

• 测试方法组合：

  • 静态动态 + 黑盒白盒

• 注意：静态黑盒 – 对于需求文档，说明书的审查，测试等。（不让我看程序，我看别的呗orz）

软件测试层次：

单元测试：

• 最小功能单元代码
• 主要白盒，内部除法设计测试用例，检查实现功能。
• 开发和测试共同完成，开发为主，需要编写驱动和桩模块。
• 代码评审，发现5到7成错误。

集成测试：

• 单元测试基础上，若干模块按照设计组装起来进行的测试，目标是发现接口问题。
• 发现缺陷：
  • 接口参数类型不匹配
  • 形参和实参不一致
  • 通信速度不一致
  • 数据累积误差
• 集成测试方式：
  • 一次性集成方式：各个分别测试，再将所有组装到一起测试
  • 渐增式集成测试：逐个单元组装测试，最后所有单元集成到一起并通过测试

系统测试：

• 集成之后，对于系统层面的功能特性测试和非功能特性测试。
• 从用户角度对于系统各个功能和性能指标进行验证，确认系统是否达到设计目标。
• 功能性测试：各个功能按照功能规格说明书进行测试，确认系统的实现。
• 非功能性测试：测试包括例如性能测试，安全测试，本地化测试，可用性测试，可靠性测试，灾难恢复性测试等。

验收测试：

• 用户实际环境中测试系统的功能和性能是否符合用户需求
• alpha测试：内测，请用户来公司测试。
• beta测试：公测，在公司外部，用户中进行试用测试。

测试计划和测试用例：

• 测试计划：高效完成测试任务的准备工作，工作估量，资源预算，进度安排，风险评估等。

  • 内容：
    • 目标和范围
    • 项目估算
    • 风险计划
    • 进度安排
    • 资源配置
    • 跟踪与控制
  • 总结：
    • 明确测试的目标，增强测试的实用性
    • 坚持5W原则（what why when where how），明确测试内容和测试过程。
    • 采用评审和更新机制，保证测试计划满足实际需求。
    • 指定完整测试计划，详细测试方案设计。

• 测试用例：

  • 为指定测试目的所设计的测试条件，测试数据以及测试规程的使用场景。
  • 作用：
    • 重要参考依据
    • 可以帮助有效的测试，节约测试时间，提高效率
    • 良好的测试可以被重复使用
  • 基本准则：
    • 测试用例应该具有代表性
    • 可判定性质
    • 可再现性
  • 设计步骤：
    • 指定策略和思路
    • 设计框架和用例结构
    • 细化结构
    • 通过用例的评审，不断优化测试用例

专业测试人员职责

• QA经理：负责公司质量体系建设，项目质量评估，项目测试审计等

• 内审员：审查流程，建立测试模板，跟踪缺陷测试报告质量等

• 测试经理：负责项目测试管理，测试计划，任务安排等

• 测试工程师：产品规格说明书的审查，测试用例的设计，实际测试任务的执行

• 测试员：执行测试用例和相关的测试任务。

• 测试经理和QA经理职责划分：

  • 测试经理侧重于技术管理和测试工作指导，保证产品正确性。
  • QA经理侧重于测试过程和产品的监督和检查，保证过程和产品的完整性。

• 测试工程师：熟悉测试流程和方法，具有工作经验，熟悉主流操作系统平台和开发平台，具有一定的程序编程能力和经验。

问题：

• 答案：C , B , D

书上：

• 特性：
  • 功能性
  • 可靠性
  • 易用性
  • 有效性
  • 性能
• ISO 9126三层模型：
  • 高层：软件质量需求评价准则
  • 中层：软件质量设计评价准则
  • 低层：软件质量度量评价准则
• 测试层次分类：
  • 底层测试：单元测试
  • 接口层次：集成测试
  • 系统层次：系统测试
  • 用户层次：验收测试
• 软件评审的对象：
  • 软件测试：
    • 需求评审
    • 设计评审
    • 代码评审
    • 文档评审
  • 软件质量保证：
    • 管理评审
    • 流程评审（过程评审）
• 静态测试：
  • 评审
  • 静态分析
  • 验证和确认
• 主被动测试
• 黑白盒测试（白盒：也称逻辑驱动测试或结构化测试，黑盒：也称数据驱动测试方法）
• 测试级别：
  • 单元测试（主要白盒）
  • 集成测试（一般要求渐增式集成方式）
  • 系统测试（确认每个功能是否能够正常使用）
  • 验收测试（实际的用户环境上进行，和用户共同完成）

第三章：软件测试方法

基于直觉和经验的方法：

• Ad-hoc测试方法，强调测试人员依据自己的专业经验，不受测试用例约束去进行各种测试。可以作为测试方法的一种补充手段，发现一些深的bug。
• ALAC（Act-like-a-customer），基于客户使用产品的经验知识所进行的测试方法，出发点式帕累托（80/20）法则。2成最常用，重点针对性测试；8成大范围，不是重点。
• 错误推测法：根据经验，知识，视觉推测错误。例如：空指针使用，Session失效，输入变量未初始化，空输入点Enter未处理。

基于输入域的方法：

• 等价类划分法：

  • 找出每个类的代表
  • 方法一：输入规定了取值范围或定值，确定一个有效等价类和两个无效等价类：

• 方法二：给定输入集合，一个等价一个无效：

• 输入条件式一个布尔量（本质还是一个集合啊orz），一个有效一个无效：

• 一组值，每一个值分别处理，确定n个有效和一个无效：

• 输入的数据必须遵守特定的规则，可以确定一个有效等价类和若干个无效等价类（从不同角度违反规则）：

边界值分析：

• 选择边界数据，对于多值变量函数测试有效，对于布尔或逻辑无效，等价类划分的补充。

• 要求松一点，两边都可以试试嗷！！！

• 确定边界值的方法：

• 其他边界值：

  • 默认值，空值，空格，无效数据，垃圾数据等输入

基于组合以及优化

判定表方法：

• 条件桩和动作桩，对于条件进行全排列，判断相应的动作。
• 设计步骤：
  • 列出系统的所有条件和动作。
  • 填入条件项。
  • 填入动作项，初始化判定表。
  • 简化，合并相同规则的动作或相似规则。
• 判定表优点：
  • 能够列举各种复杂问题，简明并避免漏洞
• 局限：
  • 适用于输入，输出不太复杂的系统测试。

因果图法：（看PPT复习）

• 利用图解法分析输入的各种情况，设计测试用例。适合于检查程序输入，输出错误，指出程序规范中的二义性。
• Ci表示原因结点，Ei表示结果结点。

• 因果图步骤：
  • 分析 – 输入输出之间的关系
  • 关联 – 不同组合间的关联，约束形成因果图
  • 转换 – 因果图转换成判定表
  • 输出 – 判定表导出测试用例
• 优点：
  • 考虑了相互制约的关系
  • 按照一定步骤，高效率开发测试用例
• 局限：仅仅适合输入/输出不太复杂的系统进行测试

成对组合测试：

• 两个输入条件组合形成不同的测试用例，将众多输入条件两两组合，减少工作量。（总的量：第一多的乘上第二多的。从多的到少的，先分好层，然后从上层到下层，逐个两两组合。）

正交实验法：

• 挑选适量的，有代表性的数据，合理安排实验，降低成本（伽罗华的理论）
• 正交表的构成：
  • 行数：测试用例数 = \Sigma(每列水平数-1) + 1
  • 因子数：正交表中列的个数，就是测试功能点的因子数。
  • 水平数：任何单个因素能够取值的个数。
  • 
  • 特性：
    • 每一列中各个数字出现的次数都是一样多的
    • 任何两列构成的有序数对出现的次数一样多。
    • 
  • 设计步骤：
    • 选择影响功能的因素和状态
    • 选择合适的正交表
    • 利用正交表构建数据集

基于逻辑覆盖方法

语句覆盖：

• 每个可执行语句至少被执行一次。
• 能解决：发现语句缺陷，但是发现不了逻辑错误

判定覆盖：

• 覆盖程序中所有路径。
• 每个分支取真和取假至少经历一次。
• 也被称为分支覆盖测试。

条件覆盖：

• 每个判断中的每个条件可能取值最少满足一次。
• 满足条件覆盖不一定满足判定覆盖

判定-条件覆盖

• 找出判定覆盖和条件覆盖的交集。

条件组合覆盖

• 每个条件的所有可能至少出现一次，每个判定结果也至少出现一次，以上三种都满足。
• 流程：

• 本质上每一个判断中的条件中的全排列，和其他判断的条件中的组合一下，就就好啦，肯定满足判定覆盖的！！！

基本路径覆盖

• 不能保证覆盖所有条件组合
• 复杂度计算：
  • 区域数目
  • 边界数目－结点数目＋２
  • 判断结点数目　＋　１

基于缺陷模式的测试

• 常见缺陷模式：
  • 内存泄露
  • 非法指针
  • 数组越界
  • 非法计算
  • 操作符异常
• 安全罗东缺陷模式：
  • 缓冲区溢出
  • 被感染数据漏洞
  • 竞争条件漏洞
• 差性能缺陷模式：
  • 创建不必要的对象
  • 空字符串比较
  • 不必要的循环等
• 并发漏洞：
  • 多线程处理不当
  • 死锁
  • 资源未释放
• 不良编码习惯：
  • 代码冗余
  • 命名不清楚
  • 参数传递匹配
  • 空指针
• 代码国际化：
  • 翻译不确切
  • 本地化设置
• 易诱骗代码缺陷模式：
  • 代码歧义
  • 无意义比较
  • 分支不可达
  • 分支永远为真
• 基于缺陷模式的测试流程：
  • 预编译，次方分析，人工确认等。

基于模型的测试

• MBT
• 将被测系统抽象定义为模型，采用数学方法来描述系统行为模型，生成测试用例，完成测试。
• 功能图法：使用功能图模型方法描述程序模型，生成测试用例。（由状态迁移图和逻辑功能表构成）。
• 模糊测试方法：模糊器产生大量的，随机的数据作为输入，验证程序是否会出现问题。

问题：

• 答案：C , D , C

• 第二题重点在于多输入，多值域。判定表很困难，正交和两两实验就可以大幅减少测试用例，可行！！！

• 因果图是一种设计测试用例的形式化方法。

• 
• 答案：B , A , B , A

• 答案：B , A

书上：

• 基于直觉和经验的方法：

  • Ad-hoc和ALAC：
    • 严格意义上的测试方法的一种补充手段
    • ALAC采用了Pareto 80/20的想法
  • 错误推测法：
    • 根据工作经验和直觉推测出程序可能存在的错误嗷！
    • 补充

• 基于输入域的方法：

  • 有哪些？
    • 等价类划分
    • 边界值分析
    • 决策表
    • 因果图
    • 两两组合正交
    • 正交实验法
  • 上面的倒数四种都是多变量组合数据的测试

• 特殊之处：

  • 决策表，两两正交组合，正交实验法看作组合方法
  • 因果图，功能图归为基于模型的方法。

• 输入域方法详细介绍：

  • 针对输入数据的处理的验证，适用于单输入，单因素。
  • 等价类划分：
    • 黑盒测试用例中的常用设计方法。
    • 两个常用过程：
      • 分类
      • 抽象
    • 不同处理情形：
      • 规定输入值范围：一个有效，两个无效
      • 规定输入值集合或规定“必须”如何：一个有效，一个无效
      • 规定输入条件是一个布尔量：一个有效，一个无效（本质就是一个集合嘛）
      • 输入一组数据，分别处理：n个有效，一个无效
      • 输入条件必须遵守的规则：一个有效和若干个无效
  • 边界值分析：
    • 不同的处理情形：
      • 规定值的范围：刚刚取到这些值，刚刚超过这些值
      • 规定值的个数：最大个数，最小个数，最大+1，最小-1
      • 每一个输出条件，分别使用以上两个规则
      • 输入域或输出域是有序集合，选第一个和最后一个元素

• 基于组合及其优化方法：

  • 上面的边界值：单因素，单变量的数据分析。多因素和多变量分析就不一样了嗷！！！ -> 检查输入条件的组合
  • 判定表方法：
    • 由条件和活动两个方面组成。
    • 条件桩，动作桩，条件项，动作项，规则
    • 步骤：
      • 列出桩
      • 填入项
      • 初始化判定表
      • 简化判定表（合并）
  • 因果图方法：
    • 借助图形，着重分析输入的各种组合和结果。
    • 形式化的图形语言
    • 看上面嗷！！！
  • 成对组合（两两组合）：
    • 简化输入条件的组合数，降低工作量
    • 真的就是两个两个组合，看 上 面！！！
  • 正交实验法：
    • 因子数（列的个数）
    • 水平数（每个因子的取值个数）
    • 步骤：
      • 确定因子数和水平数
      • 选择合适的正交表
      • 构造数据集
    • 很恶心：当一个因子的水平你不知道怎么填的时候，这个时候就只有填和不填两种情况。

• 逻辑覆盖：

  • 语句覆盖
  • 判定覆盖
  • 条件覆盖
  • 判定-条件覆盖：判定和条件的交集
  • 条件组合覆盖：每个判定中，所有条件和他们的组合出现一次。
  • 基本路径覆盖

  

• 基于缺陷模式的错误：

  • 缺陷整理，找出共性，生成缺陷模式，基于缺陷模式去预防问题嗷！

• 基于模型的测试：

  • 模型是系统的抽象，对于模型的测试往往不是直接针对被测系统进行的，而是针对源代码进行的。
  • 功能图法：
    • 状态迁移图用于标识输入数据序列以及响应的输出数据，输入 + 当前状态 = 输出 + 后续状态。
    • 逻辑功能模型用于表述输入条件和输出条件之间的关系。
  • 模糊测试方法：
    • 自动产生随机数据对于系统进行输入，“轰炸”。
    • 可以模拟黑客的攻击嗷！！！

• 形式化测试方法：
  - 基础是数学和逻辑学，通过数学逻辑和形式语言来完成软件的定义。
  - 三个组成部分：
  - 语法
  - 语义
  - 一组关系
  - 分类：
  - 基于模型的方法
  - 代数方法
  - 过程代数方法
  - 基于逻辑的方法
  - 基于网络的方法
  - 形式化验证：
  - 数学或逻辑学方法对于系统进行验证，首先被用于软件规格说明书
  - 拓展有限状态机：
  - 一种建模工具，描述对象的生命周期内所经历的序列状态，如何响应外界的事件。
  - 五个元素：
  - 输入符号
  - 输出符号
  - 状态集合
  - 状态转义函数
  - 输出函数
  - 拓展有限状态机（EFSM）：在FSM上增加了动作和转移的条件

第四章：测试流程和规范

经典软件测试过程：

• 软件工程角度：
  • 需求评审
  • 设计评审
  • 单元测试
  • 集成测试
  • 系统测试
  • 验收测试
• 项目管理角度：
  • 测试计划
  • 测试设计
  • 执行与监控
  • 结果分析与评析
  • 项目总结
• 软件测试过程的活动：

• 测试阶段的输入输出：

• W模型关系：

• W模型的特点：
  • 测试和开发同时开始同时结束。
  • 测试过程和开发过程相互依赖，前期依赖于开发过程，后期依赖于测试过程。
  • 侧重点不同，测试侧重于软件缺陷消除，开发侧重于软件功能实现。
• TMap模型：
  • Test Management Approach - 测试管理方法
  • 业务驱动的，基于风险策略的，结构化的测试管理方法，尽早发现缺陷，最小成本彻底完成测试任务。
  • 
• Tmap测试模型如何适应各类机构的软件测试：
  • 通过下列三个要素支持整个测试生命周期（L）：
    • 测试小组融入项目组织（O）
    • 稳定，可控，高效的基础设施和工具（I）
    • 支持测试过程技术（T）

敏捷开发过程：

• 特征：
  • 团队对于测试负责
  • 强调持续测试，持续质量反馈
  • 测试人员必须和项目相关人员密切协作
  • 测试计划，设计和执行力求简单
  • 自动化测试，短时间完成测试任务
• 测试流程：
  • 
• 敏捷测试 = 持续的质量反馈
• 基于脚本测试与探索式测试：
  • 基于脚本测试：无论是手工还是自动化测试，都需要先设计测试用例，生成测试脚本，然后脚本测试。
  • 探索式测试：不需要设计用例，一边思考，一边测试。
  • 传统测试中，基于脚本测试，探索式测试作为补充。敏捷测试则主要采用探索式测试，脚本测试作为补充。

基于风险的测试策略：

• 评估优先级，高优先级先做。
• 风险评估方法：

• 基于风险测试的过程：
  • 列出软件的功能和特性
  • 确定功能出错的可能性
  • 评估对于用户的影响
  • 根据上面的两个步骤，计算风险度
  • 根据可能出错的迹象，修改风险度
  • 决定测试的范围，编写测试方案

软件过程改进：

• 测试能力成熟度模型TMM / TMMi：
  • 初始级：
    • 没有结构化和文档
    • 测试在编码后执行
    • 测试目的为软件运行正确
  • 定义级：
    • 已设定测试方针和目标
    • 引入了测试计划
    • 基本的测试技术和方法
  • 集成：
    • 测试和开发集成
    • 标准，方法，步骤文档化
    • 相应的监督和控制措施
  • 管理&度量：
    • 测试过程可以有效度量
  • 优化：
    • 测试过程的数据可以用于防止错误
    • 优化已建立的过程
• 其他测试过程改进模型：
  • 测试过程改进模型（TPI）
  • 关键测试过程模型（CTP）
  • 系统化测试和评估模型（STEP）

软件测试规范：

• 对于每个流程和活动进行明确的规定，形成系统的完整测试体系。
• 国标软件测试规范内容：
  • 角色
  • 进入准则
  • 输入项
  • 活动
  • 输出项
  • 验证和确认
  • 退出准则
  • 度量
• 其他软件测试国家标准：
  • 

问题：

• 答案：C , A , ==D== , B , A

看书：

• 软件工程：（6点）

  • 需求评审
  • 设计评审
  • 单元测试
  • 集成测试
  • 系统测试
  • 验收测试

• 项目管理角度：（5点）

  • 测试计划
  • 测试设计
  • 测试执行和监控
  • 测试结果分析和评估
  • 项目总结

• W模型对应关系：

  • 需求定义分析 -> 测试目标
  • 系统，结构设计 -> 测试计划和系统测试用例设计和环境
  • 详细或程序设计 -> 功能测试用例设计
  • 编码以及单元测试 -> 代码审查，单元测试
  • 后面的功能测试（集成测试），系统测试，验收测试对应的都是缺陷修正！！！

• TMap NEXT

  • 业务驱动，基于风险策略的结构化的测试方法

  • 过程：

    

    1. 计划：任务安排，测试策略，建立进度表，合并测试计划等
    2. 控制：维护测试计划，控制测试过程，报告等
    3. 准备：定义测试单元，指定规格说明数
    4. 设计：测试目标和基础设施的评审说明，构建测试基础设施
    5. 执行：测试目标和基础设施的评审
    6. 完成。

  • TMAP的基石：

    • L - 生命周期
    • O - 坚实的组织融合
    • I - 正确的基础设施和工具
    • T - 可用的技术
    • 中心是生命周期基石嗷！！！

  • 敏捷测试：

    • TDD是敏捷测试的核心哦！！！
    • 单元测试是敏捷开发的基础嗷！！！
    • 可以没有专职的测试人员。
    • 除了“验收测试” ， “似乎”没有过程测试，但是实际上是有过程测试的，融入在开发过程中了，过程测试持续反馈
    • 偏重于探索式测试（主导），但是不可能代替原有的脚本测试。

  • 基于风险的测试策略过程：

    • 风险的测试过程：
      • 列出软件的所有功能和特性
      • 确定每个功能出错的可能性
      • 如果某个功能出错，需要评估对应用户使用软件的影响程度

  • 测试过程改进：

    • 提高软件质量的第一要素是软件过程能力不断改进。
    • TMMi：
      • 一致性检查的实施：
        • 执行过程的适宜性检查
        • 已定义过程的安全度量
        • 安全评审和纠正
    • TMM成熟度分级：
      • 初始级
      • 定义级
      • 集成
      • 管理和度量
      • 优化

  • 软件测试规范：

    • 软件测试规范：

      • 测试分析人员：制定和维护测试计划，设计测试用例和测试过程，生成测试分析报告
      • 测试人员：执行集成测试和系统测试，记录结果
      • 设计人员：设计测试使用的桩程序和驱动程序
      • 编码人员：编写测试驱动和桩程序，执行单元测试。

    • 软件测试输入项：

      • 项目计划 -> 项目开发计划
      • 需求文档 -> 需求规格说明书
      • 架构设计文档 -> 概要设计说明书
      • 详细设计文档 -> 详细设计说明书

    • 活动：

      1. 制定测试计划：

         • 测试设计员

         • 收集和组织测试计划信息，创建测试加护。

         • 操作：

           • 创建测试计划
           • 确定测试需求
           • 制定测试策略
           • 建立测试通过准则
           • 确定资源和进度
           • 评审测试文档

      2. 测试设计：

         • 测试设计员，设计员
         • 设计测试的目的是为每一个测试需求确定测试用例集，确定测试用例。

      3. 实施文档：

         • 测试设计员，编码员

      4. 执行单元测试：

         • 编码员和测试人员

      5. 执行集成测试：

         • 测试员

      6. 执行系统测试：

         • 测试员

  • 软件测试输出项：

    • 测试计划 -> 测试计划模板
    • 测试用例 -> 测试用例模板
    • 测试过程 -> 测试过程模板
    • 结果日志 -> 测试日志模板
    • 分析报告 -> 测试分析报告模版

• 验证和确认：

  • 测试计划评审 -> 项目经理 ， 测试组 ， 其他相关测试计划
  • 测试用例评审 -> 测试组，其他相关组
  • 测试过程评审 -> 测试组，其他相关组
  • 测试结果评审 -> 测试组，其他相关组
  • 测试分析报告评审 -> 项目经理 ， 测试组，其他相关组
  • SQA验证 -> SQA人员对于软件测试活动进行审计

第五章：单元测试与集成测试

单元测试：

• 构建的最小功能组件代码进行的测试。

单元测试的目标：

• 确保构成系统的单元程序的质量。

• 单元测试发现问题比较容易，修正问题更加容易。

• 目标和内容：

  • 目标：确保单元程序的规范性，正确性，安全性和可靠性。
  • 内容：
    • 数据流入流出是否正常
    • 内部数据完整否？
    • 边界能否正确工作
    • 能否满足特定的逻辑分支覆盖
    • 异常是否有出错处理
    • 指针是否正确引用
    • 单元程序是否有安全隐患

• 基本活动：

  • 建立环境
  • 脚本开发
  • 执行和结果分析

• 关注内容：

  • 目标：单元被正确编码
  • 依据：详细设计描述
  • 过程：用例设计，脚本开发，执行和结果分析
  • 执行者：编程人员和测试人员
  • 方法：黑白盒
  • 脚本管理：代码配置管理
  • 结果分析评估：代码覆盖率，分支或条件覆盖率

• 判断标准：

  • 功能和设计一致
  • 接口和设计一致
  • 错误可以处理
  • 错误修正并通过回归测试
  • 测试覆盖率达到
  • 完成单元测试报告

• 任务：

  • 路径测试
  • 内部数据结构测试
  • 单元接口测试
  • 单元边界测试
  • 单元容错性测试
  • 内存分析

单元静态测试：

• 不运行被测程序本身，互查，走查，评审进行测试，也可以使用扫描工具进行分析处理。
• 代码审查：
  • 重要的静态测试方法，有效发现程序缺陷。
  • 分类：
    • 代码走查：
      • 部分小组成员解读代码
      • 其他成员对于代码的风格，是否可能有缺陷，是否违背开发规范进行评述。
      • 发现问题及时记录，后面修改
    • 正式会议审查：
      • 会议方式进行的代码审查
      • 发现问题，及时记录，后续进行缺陷修改
      • 发现问题，修改后还需要重新审查。
  • 

单元动态测试：

• 保证结构可靠，功能正确并且拥有良好的性能响应。
• 实现原理：
  • 驱动程序
  • 被测程序
  • 桩程序
• 类测试：
  • 对于类程序的单元测试可以看作是对类的成员函数进行测试。
  • 主要内容：
    • 功能测试
    • 代码测试
    • 接口测试
  • 类测试的方法：
    • 输入域的测试
    • 组合及优化的测试
    • 逻辑覆盖的测试

单元测试工具：

• JUnit
• JUnit注解：
  • @Test
  • @BeforeClass - 类加载前全局只执行一次
  • @AfterClass - 类加载前全局只执行一次
  • @Before - 每一个测试方法之前执行一次
  • @After - 每一个测试方法后执行一次
  • @Ignore - 所修饰的测试方法会被测试忽略
  • @RunWith - 更改测试运行器

集成测试：

• 多个相关功能模块组装成的子系统或系统所进行的集成接口测试，主要检查这些单元模块之间的接口是否存在问题。

• 模式：

  • 非渐增式集成测试
  • 渐增式集成测试
  • 

• 特点：

  • 非渐增式可以实现并行方法测试，渐增式只能串行测试。
  • 非渐增式不方便debug , 渐增式容易发现单元程序接口问题。
  • 非渐增式需要较长时间实现发现缺陷，渐增式较快。
  • 非渐增式开销小，渐增式需要编写较多的驱动和桩程序。

• 集成测试策略方法：

  • 自顶向下增量集成测试：

  

  一层一层从上往下集成

  • 自底向上增量集成设计：

  

  一层一层从下往上集成

  • 三明治集成测试：
    • 自顶向下和自底向上结合
    • 从上往下和从下往上，一层一层结成
  • 改进三明治：
    • 每一个模块都要单独测试完成，然后从下往上和从上往下进行集成。
  • 各种集成策略的比较：
    • 基本控制程序集成时间：
      • 说白了就是顶层模块的测试时间。
      • 只有自底向上比较晚，其他的都早
    • 是否需要驱动程序：
      • 只有自顶向下不需要，其他的由于都要测试底层的模块，因此需要驱动程序。
    • 是否需要桩程序：
      • 自底向上不需要
    • 测试并行度：
      • 自顶向下最低，因为顶端只有一个
      • 自底向上和三明治都是中等
      • 修改三明治是最高的，因为全部模块一开始都要并行经过测试。

系统接口测试：

• 本系统和外部系统之间或本系统的各个子系统之间的交互点测试。
• 包括：
  • 系统之间的接口调用
  • 系统架构不同层次服务调用测试：
    • Web层
    • Fep层
    • Service层
  • 系统各服务模块之间的接口调用
• 系统接口技术类型：
  • Http - 超文本传输协议
  • Web Service - Web Service访问接口
  • RESTful接口 - REST架构样式的访问接口
• 系统接口测试原理：
  • 模拟服务端向服务端发送请求
  • 服务端接收请求，返回响应接口
  • 客户端接收响应数据并且与预期结果进行比对，从而判断接口是否存在缺陷。
• HTTP接口接触：
  • C/S架构
  • Web服务器：Apache , IIS
  • Web接收请求并且向客户端发送响应信息
  • 默认端口号为80
• 

问题：

答案：C , D , D , C , D

答案：D , D , C , C , D

看书：

• 单元或集成主要使用白盒测试。

• 单元测试：

  • 目的：
    • 对于单元的代码规范性，正确性，安全性，性能进行验证。
  • 内容：
    • 数据是否可以正常流入或流出单元
    • 单元工作中，内部数据是否能够保持完整性
    • 边界能否正常工作
    • 指针错误引用
    • 有没有安全隐患
  • 执行者：开发人员和测试人员共同完成
  • 标准：
    • 功能一致？
    • 接口一致？
    • 输入输出的错误处理？
    • 单元测试中发现的错误完成修改。
    • 相关覆盖率的要求
    • 完成单元测试报告
  • 任务：
    • 功能，逻辑控制，数据，安全性
  • 分类：
    • 单元独立路径的测试：
      • 算符优先级
      • 混合类型运算
      • 变量初始化错误
      • 计算精度不够
      • 表达式错误
    • 单元局部数据结构测试：
      • 不合适或者不相容的类型
      • 变量无初始值
      • 不正确的变量名
      • 溢出
      • 缺省值有错
    • 单元接口测试：
      • 接口参数一致
      • 约束作为参数等
    • 边界测试：
      • 边界值分析
    • 容错性测试：
      • 预见各种出错的情况，并且对于出错情况进行正确处理

• 代码审查：

  • 代码走查
  • 正式会议审查：
    • 评审通过标准：全部代码准则被遵守，错误已经全部修改完成！

• 动态测试：

  • 驱动程序和桩程序

• 分层单元测试：

  • Action层：
    • 跳转的验证
  • 数据访问层：
    • 业务逻辑层，也用于Dao层的数据操作

• 系统集成的模式和方法：

  • 集成测试是将已有分别通过测试的单元，按设计要求集成起来再进行测试，检查接口之间交互的问题。
  • 集成测试是黑盒测试和白盒测试相结合的典型应用场景。
  • 渐增和非渐增
  • 三明治的缺点：真正集成之前，每一个独立的模块儿没有完全测试过

第六章：系统测试

• 测试分类：
  • 系统功能测试：
    • 功能测试
    • 回归测试
  • 系统非功能测试：
    • 性能测试
    • 容错测试
    • 兼容性测试
    • 可靠性测试

功能测试：

• 对于软件系统功能验证
• 不同层次功能测试目标：
  • 单元测试：单元模块儿功能正确性
  • 集成测试：多个模块集成后的功能正确性，模块及接口的正确性
  • 系统测试：确保系统的功能正确性，正确接口
• 测试要求：
  • 界面，逻辑，数据，接口几大方面
  • 功能测试要求：
    • 程序的安装和启动正常
    • 每项功能符合实际要求
    • 支持多种环境
    • 功能逻辑清楚等orz
• Web功能测试主要内容：
  • 页面链接
  • 空间功能
  • 输入文本框
  • Web图形测试
  • 表单测试
• Web服务器的功能测试：
  • 支持Http协议
  • 虚拟主机
  • 网关接口
  • 代理
  • 高速缓存等
• 功能测试工具：
  • UFT
  • IBM Rational Funtional Tester等
• 主流的功能测试开源工具：
  • Selenium
  • Watir
  • WebTest
  • MaxQ等

回归测试：

• 修改了源代码后，重新进行系统功能测试以确定修正没有引入新的错误或其他代码错误。
• 基本过程：
  • 识别处修改部分
  • 排除不适用的测试用例（在测试用例库中），确定仍然有效的测试用例。建立新的基线测试用例库。
  • 策略选择用例进行测试
  • 达不到要求还要补充测试用例。
  • 补充完成之后继续测试。
• 策略：
  • 再测试全部用例
  • 基于风险选择测试
  • 基于操作面选择测试
  • 测试修改的部分或受影响的部分。

性能测试：

• 真实环境，特定负载，测试系统的各项指标，进行分析。
• 常见指标：
  • 请求响应时间
  • 事务响应时间
  • 吞吐量（事务，数据）
  • 连接时间
  • 发送时间
  • 处理时间
  • 点击次数
  • Http响应数
• 开销标准：
  • CPU使用率
  • 内存使用率
  • 网络流量
  • 磁盘I/O
• 常见性能问题：
  • 资源耗尽：CPU利用率达到100%
  • 资源泄露：内存泄露，资源耗尽
  • 资源瓶颈：线程 , DB连接资源少
• 目的：
  • 评估性能
  • 寻找瓶颈
  • 规划配置
• 性能测试分类：
  • 性能验证
  • 性能基准 - 标配下获得性能指标数据
  • 性能规划 - 不同配置的系统性能数据
  • 系统容量 - 系统可以承载的最大性能负载值
  • 压力测试 - 长时间高负载，了解系统的可靠性与稳定性
  • 负载测试 - 不同负载，了解性能指标
• 负载测试：
  • 模拟所受的系统负荷，变换系统负载观察系统性能表现。
  • 目的：发现可能的性能瓶颈，内存泄露，不能实时同步等问题。变换运行负载来发发现问题。
• 压力测试：
  • 长时间高负载（大数据量，大量并发用户）对于系统测试，系统高负载下的表现，有效发现系统稳定性隐患和负载峰值下的功能缺陷。
  • 目的：更快发现内存泄露，资源争用，线程锁定等问题。提高系统的可靠性，稳定性。
• 容量测试：
  • 了解系统的承载能力
  • 目的：确定最大承受量 - 最大用户数，最大存储量，最大吞吐量等

系统负载测试：

• 某时刻系统运行任务强度

• 因素：

  • 在线用户 - 进入系统的用户数
  • 并发用户 - 统一时刻访问相同功能或页面的用户数
  • 思考时间 - 浏览器收到响应到下一个请求之间的间隔时间
  • 访问数据量 - 用户请求的数据访问量
  • 负载测试 - 一次性加载 ， 递增加载 ， 高低变更加载 ， 随机加载
  • 

• 基本过程：

  • 指定性能测试方案
  • 创建虚拟用户
  • 设计测试场景
  • 执行场景
  • 分析测试结果
  • 性能调优！！！

• 拐点很重要嗷！！！，拐点指的是用户达到一定数量，平均响应时间增加，吞吐量不增反降，报错率递增的点，当前并发用户就是拐点。

• 主流测试工具：

  • JMeter
  • Load Runner

• 性能需求：

安全性测试：

• 防范危险措施的有效性
• 软件安全性：
  • 侧重于信息安全，包括机密性，完整性，可用性等
• 软件安全性测试：
  • 校验软件安全危险的措施的有效性
  • 安全性测试类型：
    • 安全功能测试：
      • 数据机密性，完整性，可用性等
    • 安全漏洞测试：
      • 从攻击者的角度，发现软件的安全漏洞，如设计，实现，运行管理上存在的缺点或弱点。
• 不同性质：
  • 机密性：防止有用信息泄露给非授权用户。
  • 完整性：保持信息不被破坏或修改，不丢失的特性。
  • 可用性：可以使用，系统的可靠性，稳定性和可维护性的综合特性。
  • 可控性：安全可控程度
  • 不可否认性（抗抵赖）：参与者不可否认操作或抵赖本人身份。
• 典型测试方法：
  • 想方法截取或破译口令
  • 开发软件来破坏系统的保护机制
  • 找出安全漏洞
• 安全层次：
  • 应用程序安全
  • 系统安全
  • 数据安全
• 计算机信息系统安全标准：
  • 
• 计算机信息系统安全保护等级：
  • 用户自主保护级：
    • 用户决定资源保护
  • 系统审计保护级：
    • 系统记录安全相关用户操作，可以查责任人
  • 安全标记保护级：
    • 对访问者和访问对象实施强制访问控制。
  • 结构化保护级：
    • 关键部分强制性直接控制访问
  • 访问验证保护级：
    • 仲裁访问对象的所有访问活动，实行专控
• 安全测试范围：
  • 基础安全技术测试
  • 安全功能测试
  • 子系统自身保护测试
  • 子系统安全管理测试
• 安全性测试方法：
  • 基于代码分析的安全测试
  • 基于动态渗透的安全测试
  • 基于威胁和漏洞的安全测试
  • 动态污点分析安全测试
• WEB安全测试：
  • 安全加密
  • 登录身份验证
  • 输入检查
  • 防SQL注入
  • 超时限制
• 安全测试工具：
  • Nikto
  • Burp suite
  • Wapiti

容错性测试：

• 检车系统容错能力，异常条件下自身是否具有防护性措施或者某种灾难性恢复的手段。
• 包括：
  • 异常输入，看系统是否崩溃
  • 灾难恢复性测试：软件强制性故障，验证丢失数据进行的恢复处理。

兼容性测试：

• 特定硬件平台上，不同应用软件之间，不同操作系统平台上，不同网络环境中是否能友好的运行。
• 类型：
  • 软件本身向前或向后兼容
  • 软件不同的平台上兼容
  • 软件与其他软件兼容
  • 数据支持兼容
• 意义：
  • 提高产品质量
  • 平台无关
  • 价值，重要指标
  • 产品市场广阔
• 兼容性测试：
  • 向前兼容（向上兼容）：未来版本功能兼容
  • 向后兼容（向下兼容）：以前版本兼容
• 数据共享兼容性测试：
  • 剪切，赋值，粘贴
  • 文件导入，导出
  • 文件存取
• 硬件兼容：
  • 整机兼容
  • 外设兼容

可靠性测试：

• 产品在规定的条件和时间内，完成规定功能的能力。
• 软件可靠性：软件系统在规定时间以及规定环境条件下，完成规定功能的能力。
• 可靠性数据收集：
  • 失效时间
  • 失效间隔时间
  • 失效次数
  • 失效次数
• 可靠性评估：
  • MTTF
  • MTTR
  • FDR
  • 可用性 = MTTF / (MTTF + MTTR)
• 可用性就是系统能够一直提供服务的时间比例。

问题：

• 答案：C , B , B , D

• 答案：D , C

• D , B , A , C

看书：

• 系统测试：

  • 主要进行非功能性测试
  • 包括：
    • 压力测试
    • 容量测试
    • 性能测试
  • 功能测试：
    • 系统安全性测试
    • 归为：界面，数据，操作，逻辑，接口
    • 测试方面：
      • 界面
      • 数据
      • 操作
      • 逻辑
      • 接口
  • 问题：
    • 页面链接需要验证的问题
    • Web图形测试
    • 表单测试

• 工具以及功能：

  • Selenium：专门为Web应用而开发的自动化测试自动集。
  • AutoIT：Windows的客户端的功能测试

• 回归测试：

  • 目的：程序在修改的情况下，验证原有功能是否正常。

• 性能测试：

  • 问题：
    • 资源耗尽
    • 资源泄露
    • 资源瓶颈
  • 测试目的分为如下几类：
    • 性能验证测试
    • 性能基准测试
    • 性能规划测试
    • 容量测试
    • 深入测试
    • 峰谷测试

• 压力测试：

  • 测试压力估算
  • 测试环境准备
  • 问题的分析

• 容量测试：

  • 分析出软件系统某应用特征的某个指标的极限值
  • 并发用户数量等

• 安全性测试：

  • 分类：
    • 安全功能测试
    • 安全漏洞测试
  • 两种级别的安全性：
    • 应用程序级别
    • 系统级别
  • 测试方法：
    • 基于代码的安全测试
    • 基于缺陷模式的方式
    • 基于故障注入的安全性测试
    • 形式化安全测试
    • 模糊测试方法
  • 静态的代码分析方法：
    • 工具扫描
    • 基于缺陷模式的方法
  • 动态的渗透测试：
    • 执行程序，渗透测试

• 容错性测试：

  • 输入错误数据 / 进行异常操作
  • 灾难恢复性测试

• 兼容性测试：

  • 软硬件兼容性测试

• 可靠性测试:

  • 规定时间
  • 规定的环境条件
  • 规定的功能

第七章：验收测试

• 也被称为交付测试
• 内容：
  • 根据需求规格说明书和产品规格说明书，验证系统或产品是否符合用户预期的各项要求，保证被用户接受。
• 测试范围：
  • 软件安装测试，系统启动与关机测试，平台测试，系统配置测试。
  • 系统功能测试（业务功能，系统边界，时序，错误处理等）
  • 系统性能测试（压力测试，容量测试）
  • 系统安全性测试，可靠性测试
  • 系统恢复测试
  • 系统易用性，文档测试
• 步骤：
  • 计划
  • 环境
  • 数据
  • 用例
  • 结果
  • 报告
• 标准：
  • 通过每个测试用例
  • 错误得到修改并且回归测试ok
  • 完成软件验收测试报告
• 注意：
  • 正式的，单独的验收测试报告
  • 验收测试必须在实际用户环境中进行
  • 用户和测试部门共同执行。
• 验收测试：
  • $\alpha$测试：
    • 验收测试，内测
  • $\beta$测试：
    • 真实环境下的测试，公测
• 验收测试报告：
  • 信息化项目验收规范
  • 软件验收测试报告

规格说明书验证：

• 规格说明书基于系统需求的定义，详细描述了开发的系统是一个怎么样的产品。
• 评审方式：
  • 同行审查
  • 走查
  • 正式会议审查
• 注意事项：
  • 客户角度和立场审核。
  • 标准的正确性，行业规范抵触打咩。
  • 完整性，准确性，一致性，合理性等特性。
• 文档测试种类：
  • 用户手册
  • 联机帮助
  • 安装指南
  • 示例和模板
  • 错误提示信息等
• 测试要点：
  • 文档正确性
  • 文档完备性
  • 文档易理解性
  • 文档一致性

用户界面测试与可用性测试

• 界面测试符合如下特性：
  • 规范：软件程序需要遵守的标准和规范
  • 直观：组织和布局合理
  • 一致
  • 灵活：软件操作可以有多种方式
  • 舒适：有恰当的表现
  • 正确
  • 实用
• 可用性测试：
  • 特定的用户在特殊的使用场景下，有效，满意的使用产品达到特定的目标
  • 可用性测试就是若干专家使用软件，并且给出评价和反馈。

安装测试和可恢复性测试

• 安装测试检查内容：
  • 特殊环境要求
  • 安装要求简单否？
  • 合理的提示
  • 与环境有冲突？
  • 安装过程能否正常退出？后退？
  • 能否安全卸载？
  • 升级能用？
  • 许可证和注册号码能够正常发挥作用？
• 可恢复性测试：
  • 容错能力：出错，指定时间内修正或重启
  • 强制发生故障，验证能否快速恢复
  • 自动恢复要验证初始化，检查点，数据恢复，重新启动。
  • 人工干预的恢复系统，评估平均修复时间

问题：

• 答案：A , B , D

• 答案：C , B , B

• 答案：D , A

• 答案：D , C

看书：

• 由用户进行
• 规格说明书

第八章：软件本地化测试

什么是软件本地化：

• 某软件产品的用户界面，文档，在线帮助从源语言向目标语言转化，适应目标语言及文化的处理过程。

• 例子：

  • 本地化翻译
  • 本地化文化适应
  • 时区
  • 用户界面
  • 联机文档
  • 热键等

• 例如我们常见的汉化

什么是软件国际化：

• 保证开发软件能够适应国际市场需要，特定的架构，编程语言能够在本地化时不需要修改代码

• 特点：

  • Unicode字符集
  • 分离程序代码和显示内容
  • 头文件定义常用代码段
  • 翻译文本尺寸
  • 键盘设置等

• 字符集问题：

  • 使用正确的字符集
  • 典型字符集：
    • ASCII字符集
    • Unicode

• 国际化标准：

  • 动态切换语言
  • 输入/输出接口与语言无关
  • 资源文件国际化
  • 支持和包容本地化数据格式

• 本地化测试：

  • 软件本地化各阶段的测试计划和规格说明，设计测试用例。
  • 利用这些测试用例取运行被测软件，发现缺陷

• 本地化测试过程：

  • 计划
  • 用例设计
  • 执行用例
  • 发现错误
  • 生成报告

• 软件本地化测试内容：

  • 安装/升级测试：
    • 本地语言操作系统上正确的安装/升级
    • 升级后是否与源程序一致
  • 功能性测试：
    • 源语言软件功能相同
    • 支持当地语言的输入/输出
    • 当地语言的目录和文件夹

• 数据格式测试：

  • 日期/时间
  • 货币
  • 地址/邮编/电话
  • 键盘布局
  • 硬编码字符串
  • 字符串缓冲
  • 嵌入控制
  • 隐藏控制

• 其他本地化测试内容：

  • 兼容性测试
  • 文档测试
  • 文化等适用性测试

翻译验证：

• 验证翻译内容：
  • 翻译是否准确
  • 是否符合当地文化
  • 符合当地习惯
• 翻译不完整
• 翻译不确切

本地化测试技术问题

• 数据格式转换：
  • 数字
  • 货币
  • 时间
  • 日期格式
  • 度量衡问题
• 页面显示与布局：
  • 不能完全显示
  • 显示乱码
  • 遗漏一些未翻译的文字
  • 文字大小问题
• 匹配与兼容性问题：
  • 输入长度超过数据库字段限制
  • 定义热键冲突

本地化功能测试

• 包括：
  • 语言
  • 翻译验证
  • 界面
  • 兼容性
  • 功能
• why？
  • 本地化时软件适应本地市场再造过程。
  • 内容：
    • 与源语言版本功能对比
    • 联机文档
    • 页面内容和图片
    • Web链接和选项设置

问题：

答案：A , D , A

第九章：测试自动化及其框架

• 手工测试的局限：

  • 手工测试无法做到覆盖所有代码路径
  • 许多时序，死锁，资源冲突相关的错误手工测试难以捕捉。
  • 大量的数据模拟，大量并发用户等测试场景，很难手工测试运行
  • 大量测试用例短时间完成手工很难办到

• 自动化测试：

  • 采用测试工具，实现程序驱动代替人展开测试。
  • 基于软件规格说明书实现测试用例的自动生成。
  • 基于UML时序图或状态图等模型自动生成可运行的测试脚本。
  • 环境设置之后，自动上传软件包到服务器并完成安装。
  • 自动生成测试数据，测试报告等

• 自动化测试原理：

  

• 自动化静态测试原理：

  • 类似于高级语言编译系统，设置类/对象/函数/变量等规范，规则，然后对于代码进行静态扫描分析。
  • 脚本技术：
    • 脚本是一组测试工具执行的指令集合
    • 线性脚本：测试工具录制的手工执行测试用例得到的脚本。
    • 结构化脚本：类似于结构化程序设计，各种控制结构，函数调用功能，实现复杂函数处理。
    • 数据驱动脚本：输入数据放在独立的数据文件中，而不是存储在脚本中，同一个程序可以实现多个数据输入的测试用例的自动执行。
    • 关键字驱动脚本：驱动程序逻辑拓展，基本功能函数封装到关键字操作中，关键字可以直接进行编程测试。

• 自动比较技术：自动将测试输出结果与预期结果进行比较的技术：

  • 简单比较 - 数值比较
  • 复杂比较 - 文件内容比较，图像比较

• 测试自动化系统构成：

  

测试自动化实施：

• 测试工具分类：
  • 测试方法不同，分为白盒和黑盒测试，静态测试工具和动态测试工具。
  • 来源不同：开源测试工具和商业测试工具
  • 测试的对象和目的：单元，功能，性能测试工具，测试管理工具等

功能测试工具特性要求：

• 测试原理：
  • 录制测试脚本：对象识别，用户操作
  • 编辑测试脚本：加入验证点，增强脚本
  • 调试脚本：排除错误
  • 执行：执行验证
  • 结果分析：确定缺陷
• UFT使用功能步骤：
  • 设置环境
  • 录制脚本
  • 增强脚本
  • 测试调试
  • 执行脚本
  • 分析结果
  • 生成报告
• UFT测试工具特性：
  • VB和C等
  • 引用外部脚本
  • 支持录制和回放功能
  • 提供对象识别工具
  • 支持抽象层和对象库
  • 数据驱动测试
  • 关键字驱动测试
• 测试工具特性要求：
  • 虚拟用户生成器录制关键业务操作，生成自动化初始测试脚本。
  • 控制器设计测试场景
  • 负载生成器执行测试任务
  • 执行测试脚本的同时，控制器将监控测试结果
  • 分析器统计测试数据生成图标结果

测试自动化框架：

• 构建功能：
  • 测试脚本存储和管理
  • 测试脚本开发测试
  • 任务安排
  • 测试报告查询

问题：

• 答案：D , C , B , C , B
• 
• 

第十章：测试需求分析与测试计划

• 项目测试过程：

• 测试目标与准则：
  • 目标：确定测试任务，所需要的资源和投入，预见可能出现的问题和风险，计划指导测试执行。
  • 任务：确定测试活动的对象，范围，方法和结果。定义每个角色的责任和工作内容，开发测试模型等。
• 测试准入原则：
  • 清楚了解项目的整体计划框架
  • 完成需求规格说明书评审
  • 测试人员应该具有专业技术知识。
  • 理解技术设计文档
• 管理原则：
  • 明确，高效的测试管理流程和规范
  • 明确活动，技术标准
  • 确定合适的风险管理，进度管理等
  • 有效沟通，奖惩体系
  • 基于测试管理系统实现有效管理测试计划，测试用例等

测试需求分析

• 了解项目背景，理解业务问题。用户是谁，用户测试需求。待测软件的特性功能，非功能性，关注软件质量属性，分析业务功能单元的重要性，确定优先级。
• 功能测试范围：
  • 页面链接：存在？跳转？
  • 控件功能：按钮是否正确，列表是否正确等
  • 输入文本框：格式数据，数据类型，数据长度
  • WEB图形测试：图片文字是否准确
  • 表单测试：请求是否响应，脚本是否正确执行
• 非功能测试：
  • 性能
  • 安全
  • 容错
  • 兼容性
  • 可伸缩性
  • 可用性
• 测试需求分析方法：
  • 从客户角度分析
  • 从技术角度分析
• 测试需求分析技术：
  • UML用例图建模被测系统的功能和边界
  • UML建模系统对象的测试场景
  • E - R实体管理
  • 列表检测被测系统的测试需求

测试项目估算和进度安排

• 测试工作量依据：
  • 质量，测试目标决定
  • 功能特性
  • 质量低，测试量大
• 测试任务分解：
  • 测试计划
  • 需求和设计评审
  • 测试设计和脚本开发
  • 测试执行…
• 测试工作进度安排 - 甘特图
• 测试工作进度表

风险管理和策略

• 风险识别 -> 风险分析 -> 风险防范
• 风险识别：
  • 建立风险项目检查表
  • 历史资料，头脑风暴
• 风险分析：
  • 风险发生概率
  • 风险影响程度
• 风险防范措施：
  • 避免可以避免的风险
  • 高风险转移为低风险
  • 降低不可避免的风险
  • 风险管理计划
  • 应急，有效的方案
  • 留有余地

测试计划内容与编制

• 测试计划内容：
  • 测试目标
  • 测试范围
  • 测试策略和方法
  • 准入 / 准出条件
  • 测试资源配置
  • 进度安排
  • 测试风险分析
• 测试计划过程：
  • 项目调研
  • 确定测试需求与范围
  • 内部审查等
• 测试计划准备工作：
  • 需求规格说明书，设计文档，使用说明书
  • 熟悉系统
  • 对于测试方法和管理技术深刻理解
• 有效测试计划：
  • 清楚测试范围，目标，任务
  • 识别各种风险等
  • 让适合人员参与测试项目的计划制定
• 测试计划编制模板

问题：

• 答案：D , B , D , A , C

第十一章：软件质量保证

• 软件度量：

  • 根据规则对于软件项目，过程，产品的数据定义，收集以及量化。
  • 包括：
    • 验收标准
    • 监控项目进度
    • 分配资源时量化均衡
    • 计划和控制开发进度
  • 度量维度：
    • 项目度量：
      • 侧重于理解和控制当前项目的情况和状态，具有战术性意义，针对具体的项目进行。
      • 规模，成本，工作量，进度，生产力，风险，顾客满意度等
    • 产品度量：
      • 侧重于监控产品的质量状况，用于产品质量的预测和控制。
      • 度量质量为中心，功能性，可靠性，易用性，效率性，可维护性，可移植性等
    • 过程度量：

• 软件度量指标：

  • 规模度量：软件功能点数，对象点数，模块数，代码行数等
  • 复杂度度量：结构层次，构件规模，控制关系
  • 缺陷度量：缺陷密度，缺陷注入率，缺陷清除率

• 软件度量过程阶段：

  • 识别目标
  • 定义度量过程
  • 收集数据
  • 数据分析与反馈
  • 过程改进

• 软件质量度量：

  • 可靠性，可用性，可维护性，效率，可移植性加权计算

• 步骤：

  • 收集缺陷和缺陷信息
  • 找出导致缺陷的原因
  • Pareto原则，80%的缺陷和20%的主要因素
  • 主要因素对于质量数据进行统计处理

• 缺陷因素：

  • 说明不完整
  • 交流不充分
  • 故意和说明偏离
  • 违反编程标准
  • 数据有误
  • 接口不一致

• 影响软件质量的主要因素：

  • IES - 说明不完整或者错误
  • MCC - 与用户交流不够
  • EDR - 数据显示有错误
  • IET - 不完整或错误的测试

• 缺陷率：

• 总体缺陷指标：

软件质量保证

• 保证软件过程质量，达到质量标准，实施的有计划有组织的工作活动
• 内涵：贯穿整个软件过程的第三方独立审查活动，目的是对于软件过程全面监控。
• 保证目标：
  • 监控开发过程来保证产品质量
  • 符合相应的标准和规程
  • 保证软件产品，过程中的问题得到处理
  • 确保项目组制定的计划
  • 收集实施方法和发现实施不利的原因
• 内容：
  • SQA计划直接相关的工作：
    • 根据项目计划指定和其对应的SQA计划，定义各阶段检查重点等，以及SQA输出产品
    • 组织SQA计划评审
  • 参与项目的阶段性评审和审计：
    • 根据项目计划进行阶段检查，了解产品符合计划否？
    • 保证评审过程有效性方面入手，审计参与人员的资格等。
  • 对于日常活动和规程的符合性进行检查：
    • SQL独立于项目组，找出问题，进行跟踪
  • 对于配置管理工作的审查和审计：
    • 对于配置管理工作进行监督，保证每个人得到的是有效版本。
  • 跟踪问题解决情况：
    • SQA跟踪发现的问题直到解决
    • 内部处理，不可以的话就报告给上层经理
  • 收集新方法，提供改进的依据：
    • 好的质量实施方法给更多项目组
    • 项目组反馈的过程规范建议，对于软件过程规范的进一步完善

软件质量保证过程

• SQA计划：
  • 确定审计的重点
  • 产生的文档
  • 如何审计
  • 具体计划
  • 评审
• 质量保证活动的执行：
  • 标准遵循性评审
  • 评审各项软件工程活动
• 结果报告：
  • SQA人员记录相关的工作结果内容，写入SQA报告，发布给相关人员。

问题：

• 答案：D , D , D , D , C