一个缺陷的生命周期

New-open-fixed-close

1. 缺陷编 （Defect ID)
2. 缺陷标题（summary)
3. 缺陷的发现者（Detected By)
4. 缺陷的发现日期（Detected on date)
5. 缺陷所属模块（subject）
6. 发现缺陷版本（Detected in release)

 

编写用例的方法

1. 等价类划分
2. 边界值
3. 因果图
4. 判定表
5. 正交排列法
6. 场景法
7. 测试大纲方法
8. 状态转换图（基本不用了）

等价类划分基本概念：1.应用场合：只要有数据输入的地方就可以使用，从无限多的数据中选取少数代表性的数据进行测试

因果图法：应用场合：在一个界面中，有多个控件，测试的时候要考虑控件的组合关系，不同的空间组合会产生不同的输出结果的组合，为了弄清什么样的输入组合会产生什么样的输出组合，使用因果图。

        因：原因，输入条件，找出所有输入条件

        果：结果，输出结果，找出所有的输出结果

使用图形的方式，分析软件输入和输出的对应关系

 

1. 等价类划分（有效等价类、无效等价类）+边界值设计测试用例
2. 使用因果图法+判定表设计测试用例

 

 

正交拉丁方

正交排列法

• 应用场合：在一个界面中，有多个控件，每个控件有多个取值，控件取值的组合数量很大，不可能（也没有必要）为每一种组合编写一条用例。如何使用最少最优的组合进行测试—正交排列法

区别：

      判定表（因果图）也是考虑控件组合，但是组合数量较少（一般不会超过20种），而且要求测试全面。

 

• 正交表：一种特制的表，一般的正交表记为Ln(m^k)

n是表的行数，也就是需要测试组合的次数

K是表的列数，表示控件的个数（因素的个数，或因子个数）

m是每个控件包含的取值个数（各因素的水平数，即各因素的状态数）

如L9(3^4)

有4个控件，每个控件有3个取值，9为需要测试的组合个数

 

• 使用正交排列法分析程序

1. 分析需求–把控件及其取值列举出来
2. 根据控件和控件的取值个数，选择一个合适的正交表

1. 根据控件的个数，选择正交表的次幂，也就是正交表的列数

4个控件—选4次幂

1. 根据控件取值的个数，选择正交表的底，也就是正交表中包含数的最大值

每个控件有3个取值—选底为3的

1. 把控件及其取值映射到（放到）正交表中

1. 把控件名称分别放到正交表的列名位置
2. 把正交表中每一列的数字分别用对应的控件取值替代

4.根据正交表，编写用例—-把正交表的一行转换成一条用例

 

• 正交表的局限性

正交表个数有限，并且一般要求每个控件的取值个数相等，在实践中很难遇到。

• 正交表选择数据的思想

——-公平、均匀

1. 每个控件都要参与组合，每个控件的取值参与组合的次数尽量相同
2. 从所有的组合数据中，均匀、零星的挑选作为用例的组合数据，而不是只从某个局部选取

 

使用场景法设计测试用例

场景法就是模拟用户操作软件时的场景，主要用于测试系统的业务流程。

• 应用场合

1. 界面特点：没有太多填写项，主要通过鼠标的点击、双击、拖拽等完成操作—-如游戏测试
2. 把自己当作最终的用户，在使用该软件的时候可能会遇到哪些情形（场景），

主要的目的是测试软件的主要业务流程、主要功能的正确性和主要的错误处理能力。

• 核心概念

1. 基本流（正确流）

模拟用户正确的操作流程—–验证软件的业务流程和主要功能

1. 备选流（错误流）

模拟用户错误的操作流程—验证软件的错误处理能力

总结：

1. 场景法是基于等价类划分的一种测试方法（技术层面）
2. 场景法的应用是基于对软件业务（需求）的深入理解（业务层面）

 

三．使用场景法分析程序

1.根据需求，找到基本流和备选流（找出正确的操作流程和可能出错的环节）

银行取款机

（1）基本流—–正确取款

（2）备选流—–出错的环节

• 银行卡错误
• 密码错误
• 密码错误3次
• 卡内余额不足
• 超出当日可取
• ATM余额不足

1. 列出场景：把每个基本流和备选流当做一个场景
2. 对每一个场景生成相应的测试用例

 

 

 

使用测试大纲法编写测试用例

 

 

 

 

总结

一．重点

1.场景法

为了测试程序的主要业务流程、主要功能和错误处理能力（也包括等价类划分）

基本流、备选流

 

2.等价类划分

只要有数据输入的地方（包括选择数据的地方），把无限的数据进行等价类划分，可以减少用例的数量

有效等价类、无效等价类

 

二．重要

 

1. 边界值

找到有效数据、无效数据的分界点，对分界点（最大值、最小值）及其两边的点进行测试

一般有数据范围（如：编 1——5000整数）、数据长度（如：姓名1——20）要求的控件

说明：在实际工程中，由于需求的不明确，有时可能数据的范围未能确定，这种情况下，边界值只能不测

 

     2.判定表（因果图）

     3.考虑多个控件的组合，会产生不同的输出组合（组合数量较少，而且要求考虑全面）

9个图形符

 

• 次重要

1. 正交排列法

多个控件，每个控件有多个取值的组合（参数配置类软件）（组合数量大，而且没有必要全部测试），使用最少的组合达到最大的覆盖程度

      2.测试大纲法

涉及到多个窗口，每个窗口包含多个动作，找到每个窗口的动作之间的联系

 

 

问题思考：

1.哪个阶段引入的缺陷最多高-低）

需求说明书阶段—-程序设计阶段—-编写代码阶段——其它

1. 软件测试阶段划分

1. 单元测试
2. 集成测试
3. 系统测试
4. 验收测试

• （4-1）α ——Alpha测试
• （4-2）Β——-Beta测试

 

 

单元测试

1. 单元测试又称模块测试，是针对软件设计的最小单位——程序模块进行正确性检验的测试工作
2. 类、文件、窗口、函数、菜单、 表或一个存储过程都可以作为一个单元进行测试，其依据是详细设计
3. 目的在于检查每个程序单元能否正确实现详细设计说明中的模块功能、性能、接口等要求，发现各模块内部可能存在的各种错误
4. 单元测试以黑盒测试为主，重点模块可以结合白盒测试
5. 多个模块可以平行地独立进行单元测试。

 

1. 单元测试（常常是开发人员自己完成或是没有）

1. 依据：详细设计文档
2. 以功能测试为主，重点核心模块可以进行白盒测试（检查代码）
3. 可能需要编写驱动模块或桩模块

驱动模块：模拟被测模块的上一级模块（调用被测模块的哪个模块）

桩模块：模拟被测模块的下一级模块（被测模块调用的那个模块）

1. 在实际工程中，为了节约成本，单元测试经常只由开发人员完成，有悖与测试思想（测试必须由第三方来完成）

 

集成测试

1. 拿到一个新的集成版本的时候，一般先做冒烟测试————利用较少的时间（0.5天——2天）、较少的人（1——3名，经验更丰富）对软件的主要功能进行测试，，主要判断该版本是否值得一测，如果值得一测，整个测试组再全部投入；如果不值得一测，打回开发组，令其完善后再给出新版本
2. 一个新的版本测试思路：

1. 冒烟测试
2. 返测：对发现的缺陷是否进行修复的测试
3. 回归测试：对前面版本中所有的用例再执行一遍（保证软件旧的功能正确）
4. 对新添加的功能进行测试

 

系统测试

1. 对整个软件系统进行全面完整的测试过程
2. 在系统测试之前一般有“确认测试”

1. 确认该程序值不值得一测（冒烟测试）
2. 确认相关的文档是否齐全（尤其是交给用户的文档）

 

验收测试

1. 验收测试（用户接受度测试、用户体验测试，UAT,user acceptance test)

1. Alpha测试：由最终的用户在开发的环境中，对软件进行测试（在实际中也经常由开发方自主完成）
2. Beta测试：由最终的用户在实际的环境中进行测试使用

对于一些没有固定用户群体的公共类软件（办公软件，游戏，输入法），一般会发行公测版（beta版），让用户免费使用，发现bug后进行信息反馈。

 

软件测试模型

1. 概念：测试模型体现的是开发和测试的对应关系
2. V模型

1. 优点：测试阶段明确，即包括单元级（可能涉及代码）也包括用户级，与开发关系明确
2. 缺点：容易理解成测试只是开发后的一个工作，不符合越早测试和不断测试的原则
3. 深入理解：

在编码之前，我们需要对相关的需求文档、开发文档进行测试——越早测试

根据相关文档，在测试执行之前编写各个阶段的测试计划、测试用例等文档——测试过程是有计划性的

注意：

如果做单元测试，需要有详细设计文档

如果做集成测试，需要有概要设计文档

如果做系统测试，需要有需求文档

 

1. W模型

 

 

问题思考

1. 测试用例方法选择的综合策略
2. 软件测试V模型
3. 什么是冒烟测试、返测、回归测试
4. 什么是Alpha测试、beta测试

 

软件测试的分类

一．按照测试技术划分

1. 黑盒测试（功能测试–必须的）—（应用举例：等价类划分，边界值分析法，因果图法，判定表法）
2. 白盒测试（逻辑结构测试—通过检查代码的逻辑、算法、结构是否正确—可选）—（语句覆盖、判断覆盖、条件覆盖、判断/条件覆盖、基本路径覆盖、循环覆盖、模块接口测试）
3. 灰盒测试

在单元测试时，白盒应用相对较多

在集成测试时，灰盒应用相对较多

在系统测试、验收测试时一般就不会使用白盒测试和灰盒测试了

 

二．按是否需要运行代码划分

1. 静态测试：（界面测试、文档测试、代码测试）
2. 动态测试

1. 静态中的代码测试重点关注的时代码的规范性，一般检查变量的命名，注释的频率，编程的规范性，不需要写测试用例，一般只需要有代码审查单。

一般经常把白盒测试和静态测试的要素结合在一起，形成“静态白盒测试”

     2.动态测试

        （2-1）动态测试是指通过人工或使用工具运行程序进行检查、分析程序的执行状态和程序的外部表现

        （2-2）实际运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否相等

 

• 按软件特性分类

1. 功能测试
2. 性能测试——分布式软件（B/S;C/S),必须使用工具，如LoadRunner

 

 

 

工具篇

测试管理工具QualityCenter

• 基本概念

1. 自动化工具分类

       （1）功能自动化工具

                QuickTestProfessional (QTP)

       （2）性能自动化工具

                 LoadRunner

       （3）测试管理工具

                QualityCenter (质量中心)——对整个测试流程进行全面管理，包括：版本管理、需求管理、用例的管理、执行用例、缺陷跟踪管理、数据分析统计管理等。

                 禅道

       （4）白盒测试工具

                 Junit、Jtest

 

1. QC简介

（1）B/S结构的产品，QC软件需要安装在服务器版的操作系统中。