文章目录

part Ⅰ
- 测试基础
- - 三种质量模型-“产品质量模型”分析
  - - 一级指标“功能性”
    - 一级指标“可靠性”
    - 一级指标“易用性”
    - 一级指标“效率”
    - 一级指标“可维护性”
    - 一级指标“可移植性”
    - 产品质量模型各指标间相关性
  - 三种质量模型-“使用质量模型”分析
  - 五种软件测试的分类-按软件的“不同阶段”分类
  - - 五种分类方式
    - 按不同阶段分类
    - 回归测试
    - 附：简述“验证”与“确认”的区别/li>
  - 软件测试的一组重要观点-软件错误的四种现象
  - 软件测试的一组重要观点-软件测试的成本
  - 附：软件测试的七条基本原则
  - 软件测试的一组重要观点-软件测试的一组“重要论断”
- 黑盒测试
- - 边界值分析-基础定义
  - - 三个点的定义
    - “边界值”定义
    - 常见的几类边界
    - 常见边界的边界值
  - 四种黑盒测试技术
- 白盒测试
- - 逻辑覆盖的6种方法-一组实例
part Ⅱ
- 测试基础
- - 过程质量模型（生存周期）
  - - 生存周期基本过程
  - 五种软件测试的分类-按软件的“不同阶段”分类
  - - 五种分类方式
    - 按不同阶段分类
    - 回归测试
  - 软件测试的一组重要观点-软件错误的四种形式
  - 软件测试的一组重要观点-软件测试的一组“重要论断”
  - 缺陷管理-“缺陷管理信息系统”的设计
  - - MIS设计的三个关键问题/li>
    - - 问题一：“缺陷”对象数据结构设计
      - 问题二：“缺陷”对象状态设计
      - 问题三：针对“缺陷”对象的功能设计
- 黑盒测试
- - 等价类划分-等价类划分的基本方法
  - - *基本思想
    - *基本步骤
    - *基本类型
    - 基本方法
    - 附：设计测试用例的基本原则
  - 等价类划分-练习题
  - - 小结
  - 边界值分析-练习题
- 白盒测试
- - 逻辑覆盖的6种方法
- 性能测试
- - 定义，场景，步骤，3道例题
- 其他测试
- - 文档测试
- 软件质量保证
- - 1.三名管理大师及他们的主要质量观点
  - 2.软件质量保证基本概念
  - ISO9000体系
part Ⅲ
- 测试基础
- - 缺陷管理-“缺陷管理信息系统”的设计
  - - MIS设计的三个关键问题/li>
    - - 问题一：“缺陷”对象数据结构设计
      - 问题二：“缺陷”对象状态设计
      - 问题三：针对“缺陷”对象的功能设计
- 黑盒测试
- - 等价类划分-练习题
  - - 小结
  - 因果图-练习题
  - - 基本思想
- 白盒测试
- - 提升程序“易测试性”方法-错误桩
- 性能测试
- - LoadRunner11中文版-基础教程

part Ⅰ

测试基础

三种质量模型-“产品质量模型”分析

产品质量模型如图所示：

三种质量模型-“使用质量模型”分析

使用质量模型如图所示：

单元测试：对程序员编写完成的某个程序单元测试；
集成测试（组装测试）：将所有程序单元（模块）进行有序的、递增的组装并测试。发现模块间接口以及全局数据结构等问题。
确认测试：通过检验和提供客观证据，证明软件是否满足《软件需求说明书》中规定的需求。
系统测试：为确认是否达到原始目标，对集成的硬件和软件系统进行的测试。检查完整的程序系统能否和系统（硬件、外设、网络和系统软件、支持平台等）正确配置、连接、并满足用户需求。
验收测试：按照项目任务书或合同、供需双方约定的验收依据文件进行的对整个系统的测试与评审，决定是否接收或拒收系统。

回归测试

回归测试：重复以前的全部或部分的相同测试。

目的：软件的改变可能是源于发现了错误并做了修改，也有可能是因为在集成或维护阶段加入了新的模块。回归测试就是为确定修改和检查修改是否损害了原有的正常功能。
重要性：回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。在极端编程方法中，更是要求每天都进行若干次回归测试。

附：简述“验证”与“确认”的区别/h4>

附：软件测试的七条基本原则

初心原则。所有软件测试，都应追溯到用户需求
从速原则。尽早地和不断地进行软件测试
折衷原则。完全测试是不可能的，测试需要终止条件（原因：输入量太大；输出结果太多；路径组合太多）
不完备原则。测试无法显示软件潜在的缺陷
正比原则。测试后程序中残存的错误数目与该程序中已经发现的错误数目成正比
回避原则。程序员应避免检查自己的程序
设计原则。遵循PDCA规律，避免测试的随意性

软件测试的一组重要观点-软件测试的一组“重要论断”

“零缺陷软件”是不可能的，只是一个可望不可及的目标；
完全测试程序是不可能的
测试只能证明错误存在，不能证明错误不存在
测试应当循序渐进，不应企图一次性测完
80-20原则：80％的错误聚集在20％的模块中，经常出错的模块改错后还会经常出错
找到的软件缺陷越多，说明软件缺陷越多
并非所有软件缺陷都能修复
需求说明书总是在不断变化
测试资源是很有限的
软件测试人员通常在项目组中不受欢迎

黑盒测试

黑盒测试（功能测试），又被称为数据驱动测试、基于规格说明的测试或用户测试

边界值分析-基础定义

三个点的定义

内点：在域范围内的任意一个点；
上点：边界上的点（无论开区间、闭区间）。
离点：离上点最近的一个点，且满足：
1）如边界封闭，则域范围外离上点最近的点；
2）如边界开放，则域范围内离上点最近的点。

“边界值”定义

边界上的一组“上点”和“离点”分别构成了这个边界域范围的“内/外”边界值。域的边界被“夹”在上点与离点之间。

常见的几类边界

报表的第一行和最后一行
数组元素的第一个和最后一个；
循环的第0次、第1次、倒数第2次、最后1次等
2字节的正整数边界：65535；65536

常见边界的边界值

part Ⅱ

测试基础

过程质量模型（生存周期）

过程质量模型如图所示：

单元测试：对程序员编写完成的某个程序单元测试；
集成测试（组装测试）：将所有程序单元（模块）进行有序的、递增的组装并测试。发现模块间接口以及全局数据结构等问题。
确认测试：通过检验和提供客观证据，证明软件是否满足《软件需求说明书》中规定的需求。
系统测试：为确认是否达到原始目标，对集成的硬件和软件系统进行的测试。检查完整的程序系统能否和系统（硬件、外设、网络和系统软件、支持平台等）正确配置、连接、并满足用户需求。
验收测试：按照项目任务书或合同、供需双方约定的验收依据文件进行的对整个系统的测试与评审，决定是否接收或拒收系统。

回归测试

回归测试：重复以前的全部或部分的相同测试。

目的：软件的改变可能是源于发现了错误并做了修改，也有可能是因为在集成或维护阶段加入了新的模块。回归测试就是为确定修改和检查修改是否损害了原有的正常功能。
重要性：回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。在极端编程方法中，更是要求每天都进行若干次回归测试。

软件测试的一组重要观点-软件错误的四种形式

软件错误
当程序没有实现其最终用户合理预期的功能要求时，就表现为软件错误
软件错误的四种形式
错误（error）：在软件生存周期内的不希望或不可接受的人为错误，其结果是导致软件缺陷的产生；
缺陷（defect）：存在于软件（文档、数据、程序）之中的那些不希望或不可接受的偏差；
故障（fault）：是一种动态行为，指在软件运行过程中，出现的不希望或不可接受的内部状态；
失效（failure）：指在软件运行时产生的，一种不希望或不可接受的外部行为结果。

软件测试的一组重要观点-软件测试的一组“重要论断”

“零缺陷软件”是不可能的，只是一个可望不可及的目标；
完全测试程序是不可能的
测试只能证明错误存在，不能证明错误不存在
测试应当循序渐进，不应企图一次性测完
80-20原则：80％的错误聚集在20％的模块中，经常出错的模块改错后还会经常出错
找到的软件缺陷越多，说明软件缺陷越多
并非所有软件缺陷都能修复
需求说明书总是在不断变化
测试资源是很有限的
软件测试人员通常在项目组中不受欢迎

缺陷管理-“缺陷管理信息系统”的设计

定义：缺陷管理是指对于测试人员发现的软件缺陷，如何进行提交、确认、修复、验证等管理过程的跟踪管理。

MIS设计的三个关键问题/h4>

问题一：“缺陷”对象数据结构设计

四种严重性
1.严重。系统崩溃、数据丢失、数据破坏（系统级、数据级）
例如：蓝屏、死机、数据保存异常、完整性约束被破坏
2.较严重。操作性错误、错误结果、遗漏功能（功能级）
例如：某菜单项功能无法使用、报表项统计错误、“下一步”无法进入指定环节
3.一般：错别字、小问题（表现级）
例如：对必填框未作校验
4.建议：不影响使用的“瑕疵”或有“更好的”实现（优化级）
例如：某图片显示变形、界面不“横平竖直”、关键内容显示不完整
五种优先级
1.最高。立即修复，停止进一步测试
2.次高。在产品发布之前必须修复
3.中等：如果时间允许应该修改
4.最低：可能会修改，但也能发布

问题二：“缺陷”对象状态设计

缺陷的“状态”及“状态之间的转换关系”设计是“缺陷管理信息系统”过程管理基础。
通常，参考生命周期理论，缺陷对象可设定六种“状态”：
“生死”状态：New 、 Closed（由测试决定）
“确认”状态：Open 、 Fixed（由开发决定）
“拒绝”状态：Declined 、Deferred

六种常见的“错误状态”及“转换关系”
1.New（新信息）：测试中新报告的软件bug
2.Closed（关闭）：错误已被修复，并已经过验证。
3.Open（打开）：bug已被确认，并分配给相关的开发人员处理
4.Fixed（修正）：bug已由开发人员修正完成，等待测试人员验证
5.Declined（拒绝）：测试人员或开发人员认为不是错误，拒绝修改
6.Deferred（延期）：不在当前版本修复，在之后某个版本中修复

错误状态转换图：

附：设计测试用例的基本原则

为每个等价类编号；
一个测试用例，尽可能覆盖多个有效等价类
一个测试用例，只能覆盖一个无效等价类。

等价类划分-练习题

示例一：在某大学学籍管理信息系统中，假设学生年龄的输入范围为16~40，则根据黑盒测试中的等价类划分技术，下面划分正确的是____
A：可划分为2个有效等价类，2个无效等价类；
B：可划分为1个有效等价类，2个无效等价类；
C：可划分为2个有效等价类，1个无效等价类；
D：可划分为1个有效等价类，1个无效等价类；
正确答案：B

示例二：某录入界面有4个输入项，要求分别如下：1）姓名，2-4个汉字；2）性别，男/女；3）年龄，16~40；4）学历，博士/硕士/学士/其他。请用等价类划分方法，对这个界面设计测试用例，预期结果略。
依据等价类划分思想，本题计划采用5个测试用例，进行等价类覆盖：
1.大，大，10，大大
2.大大，男，18，博士
3.大大大大大，女，42，硕士
4.大，大，10，学士
5.大，大，10，其他

示例三：在黑盒测试方法中，等价类划分方法设计测试用例的步骤是：根据输入条件把数目极多的输入数据划分成若干个有效等价类和若干个无效等价类；设计一个测试用例，使其覆盖_(1)尚未被覆盖的有效等价类，重复这一步，直至所有有效等价类均被覆盖。设计一个测试用例，使其覆盖(2)_尚未被覆盖的无效等价类，重复这一步，直至所有无效等价类均被覆盖.
A.1个； B.7个左右； C.一半；
D.尽可能少的； E.尽可能多的； F.全部.
正确答案：E,A

示例四：Nextdate（）的等价类划分测试用例设计。
提示：包括“普通、跨月、跨年”三种情况。

例题一：用边界值分析法，假定X为整数，10<=X<=100，那么X在测试中应该取__边界值。
A_X=10，X=100
B_X=9，X=10，X=100，X=101
C_X=10，X=11，X=99，X=100
D_X=9，X=10，X=50，X=100
正确答案：B

例题二：每位密码都要求为字符（包括大小写字母）或“0”-“9”，请问其ASCII编码的边界是什么br> 在计算机软件中，字符是很重要的表示元素，ASCII是最常见的编码，编写一段代码，观察1-255的ASCII符号

判定覆盖，DC(Decision Coverage)

条件/判定覆盖，CDC(Condition/Decision Coverage)

路径覆盖，PC(Path Coverage)

ISO9000体系

ISO 9000 部分需要掌握的重点

“标准”的基础结构

“核心属性”是缺陷管理的信息化基础，包括：
缺陷引发后果的“严重性”、处理缺陷的“优先级”。
严重性和优先级的设计：
来源：苏凉.py
声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！