软件产品测试手册

１． 测试三要素：方法或工具、被测试对象、目的
２． 软件测试：
（１） 最初定义：“软件测试是为了发现错误而执行程序的过程。
（２） 权威定义：使用人工和自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。
（３） 经典定义：软件测试的目的在于发现错误；一个好的软件测试在于发现从前未发现的错误；一个成功的软件测试是发现了从前未发现的错误。

３． 软件缺陷的4个过程：
（１） 错误(error)：人类会犯错误。
（２） 缺陷(fault)：缺陷是错误的结果。( bug )
（３） 失效(failure)：当缺陷执行时会发生失效
（４） 事故(incident)：当出现失效时，给用户造成不同

４． 为什么会出现软件缺陷：主要问题来自于需求分析阶段

５． 软件缺陷修复的代价：发布阶段的修复费用是开发初期的几十倍甚至上百倍

6． 软件缺陷的定义：（符合下列5个规则中的一个就叫软件缺陷）
（１） 软件未达到产品说明书标明的功能
（２） 软件出现了产品说明书指明不会出现的错误
（３） 软件未达到产品说明书未指明但应达到的目标
（４） 软件功能超出产品说明书所指明范围
（５） 软件测试人员认为软件难以理解、不易使用、速度缓慢，或者最终用户认为不好。
7． 测试的目的：发现软件缺陷
测试的目标：尽可能早些发现软件缺陷，并确保其得以修复
8． 成为一个优秀的软件测试人员:
（１） 时间紧、工作累
（２） 沟通能力
（３） 打破砂锅问到底
（４） 追求完美
（５） 编程经验
（６） 行业知识
（７） 故障排除能手
（８） 创造性
（９） 判断准确
（１０） 老练稳重
9． 软件生命周期：投标、立项；需求分析；设计(概要设计、详细设计)；编码；测试； 发布；维护；退役。
１0． 软件测试模型：左侧是设计阶段，右侧是测试阶段

１1． 软件测试原则
• （1）完全测试不可能
– 输入量太大
– 输出结果太多
– 软件路径太多
– 软件说明书没有标准
– 时间不允许
– 人员不允许
– 资金不允许

• （2）软件测试是有风险的，把握最优测试量
•
（3）测试无法显示潜伏的软件缺陷
• （4）找到的软件缺陷越多，说明未发现的软件缺陷也越多
– 类似寄生虫成群出现的道理
• 程序员的脾气秉性
• 程序员今天心情不好
• 大家易犯同一错误
• （5）杀虫剂怪现象
• （6）并非所有的软件缺陷都能修复
–没有足够的时间
–别人不认同是软件缺陷
–修复的风险大
–不值得修复
–作出错误决定要负责后果
–决策由软件测试人员、软件测试经理、软件开发人员、软件开发经理共同参与。
• （7）难以说清的软件缺陷
– 以产品说明书为准绳，都追溯到用户需求
– 没有产品说明书呢？
• 你认为是缺陷，但开发人员不认同，就写在报告中
• 如果真的会引发很大问题，别人还没有意识到，那要尽量说服对方
• （8）产品说明书不断变化
• （9）软件测试人员在产品小组中不易受欢迎
• （10）避免测试的随意性
应该从工程的角度去理解软件测试，它是有组织，有计划，有步骤的活动。
理解上述10点，假如违反了这些规则会怎样

１2． 术语区分：
（１） V&V（验证&合法性检查）
合法性检查确保产品实际满足用户的需求,规格是正确的在第一个位置,合法性检查是保证产品是建立根据需求和设计规范。合法性检查可以确保你建立正确的事情”。验证可以确保你建立是正确的。合法性检查确认产品,提供,将履行其预期用途。
（2）测试和质量保证
软件测试人员的目标是找出软件缺陷，尽可能早些，并确保缺陷得以修复
软件质量保证人员的主要职责是创建和加强软件生命周期中防止缺陷产生的标准和方法
（3）质量和可靠性
可靠性只是软件质量的一个方面，用户对质量的看法是多方面的

１3． 软件质量定义（三个标准）：
1991年，ISO9126(GB16260):软件质量是软件满足规定或潜在用户需求特性的总和
1999年，ISO14598(GB18905)：软件质量是软件特性的总和，是满足规定或潜在用户需求的能力
2001年，ISO9126：软件质量包括内部质量、外部质量和使用质量三部分。

１4． 软件测试分类
• 按测试阶段划分
– 测试V模型;
• 按测试实施的组织划分
– 开发方测试、用户测试、第三方测试
• 按测试方法、技术划分
– 白盒、黑盒、灰盒
– 静态、动态
– 手工、自动化
– 性能测试、兼容性测试、易用性测试等等

１5． 如何对产品说明书进行测试
设身处地为客户着想
了解要实现的软件
把自己当作客户，尽量弄清客户的需求，有行业背景最好
不清楚、不理解的地方，不要放过。
研究现有的标准和规范
ISO标准
GB
工程标准
主流产品
用户已经习惯的规范
审查和测试同类软件
产品说明书属性检查清单
完整
准确
精确、不含糊、清晰
一致
贴切
合理
代码无关
可测试
产品说明书用语检查清单
总是、每一种、所有、没有，从不
当然、因此、显然、明显、必然
某些、有时、常常、通常、几乎
等等、诸如此类、
良好、迅速、廉价、高效
已处理、已拒绝、已消除
如果…那么…(没有否则

１6． 黑盒测试用例设计方法（需要会分析例子）
• （1）等价类划分法
步骤：
划分等价类，将等价类编号
建立等价类表
选择覆盖等价类的测试用例形成测试用例表
• 划分等价类的原则
– 划分为互不相交的一组子集
– 而且所有子集的合并是整个集合

• （2）边界值分析法
实用分析设计原则1：
如果输入条件规定了值的范围,则应取刚达到这个范围的边界的值,以及刚刚超越这个范围边界的值作为测试输入数据
实用分析设计原则2：
将原则1应用于输出条件，即设计测试用例使输出值达到边界值及其左右的值。
实用分析设计原则3：
如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个元素作为测试用例
实用分析设计原则4：
如果程序中使用了一个内部数据结构,则应当选择这个内部数据结构的边 界上的值作为测试用例。
实用分析设计原则5：
分析规格说明,找出其它可能的边界条件

（3）因果图法
步骤
分析需求描述，找出原因，结果，中间状态和约束条件
画出因果图
转换为判定表：原因结果（或者原因）作为行，原因结果（或者原因）的组合作为列，用0，1填充表格
为判定表的每一列设计一个测试用例

• （4）场景法
步骤
根据说明，描述出程序的基本流及各项备选流
根据基本流和各项备选流生成不同的场景
对每一个场景生成相应的测试用例
对生成的所有测试用例重新复审，去掉多余的测试用例，测试用例确定后，对每一个测试用例确定测试数据值

• （5）错误推测法

１7． 正式审查
（1）四个基本要素：
a) 确定问题：例如审查的目标是找出软件的问题和遗漏，个人情绪化感觉要保留
b) 遵守规则：例如审查的代码量、花费的时间、哪些内容该做记录等
c) 准备：检查人员要做好准备，在审查过程中发现的问题大部分是在准备期间发现的
d) 编写报告：总结出审查结果的书面报告，尽快通知相关人员

（2）正式审查会议的工作流程
e) 会议的准备阶段
f) 会议的召开
g) 会议的跟踪

（2.1）审查会议的准备阶段
会议涉及的角色
• 创建者
• 评审负责人
• 检查者
• 涉及的文档
• 评审检查单：记录检查者的问题
（2.2）审查会议的召开阶段
• 涉及的角色
• 评审负责人
• 阅读人
• 检查者
• 创建者
• 记录者
• 涉及的文档
评审会议记录：记录评审过程中评审的软件缺陷
（2.3）评审会议的跟踪
• 涉及的角色
• 审核者
• 涉及的文档
• 评审会议跟踪表：由审核者跟踪软件缺陷的修复情况，并详细记录到评审会议跟踪表中。

18． 不同的覆盖及含义
a) 语句覆盖
设计若干测试用例，运行被测程序，使程序中每个可执行语句至少执行一次
b) 分支覆盖
设计若干测试用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少运行一次，即判断真假值均曾被满足。
c) 条件覆盖
设计若干测试用例，执行被测程序以后要使每个判断中每个条件的可能取值至少满足一次。
d) 分支条件覆盖
设计足够的测试用例，使得判断条件中的所有条件的可能取值至少执行一次，同时，所有判断的可能结果至少执行一次。
e) 条件组合覆盖
设计足够的测试用例，使得所有可能的条件取值组合至少执行一次
f) 路径覆盖
设计所有的测试用例，来覆盖程序中的所有可能的执行路径

19． 集成测试
自顶向下集成
a) 桩模块
自底向上集成
b) 驱动模块
双向集成

２0． 如何进行兼容性测试，应考虑哪方面内容
（１） 硬件兼容性测试（配置测试）
计划硬件兼容性测试的一般过程：
a) 确定所需的硬件类型
b) 确定哪些厂商的硬件、型号和驱动程序可用
c) 确定可能的硬件特性、模式和选项
d) 将硬件配置缩减为可测试范围
e) 明确使用硬件配置的软件唯一特性
f) 设计在每一种配置中执行的测试案例
g) 在每种配置中执行测试
h) 反复测试直到小组对结果满意为止

（2）软件兼容性测试
• 需要考虑
– 与OS的兼容性
– 与DB的兼容性
– 与中间件的兼容性
– 与浏览器的兼容性
– 与其他支撑软件的兼容性

（3）数据兼容性测试
• 数据标准
– 开发接口类标准
• SQL标准符合类测试
• ODBC
• JDBC
– 通信协议类标准
• 智能网规范
• 智能交通管理NTCIP协议
• 中国远程教育CELTS－20教学管理标准中的基于HTTP协议绑定规范

２1． 本地化测试
软件国际化
• i18n：Internationalization
– 在设计和开发产品时，保证其在无需重新设计的前提下能满足全球的本地化需要，并在全球市场顺利销售所做的工作
- 在设计和编码过程中体现出来
软件本地化
• l10n：Localization
– 将产品针对特定国家、地区的语言和文化进行加工，使之符合特定区域市场的过程

软件全球化
• Globalization：G11N

软件国际化测试
软件本地化测试

软件国际化、本地化步骤：
• 主要步骤：
– 进行支持国际化的设计和实现
• 例如从源代码中分理出资源文件
• 采用国际处理标准等
– 将资源文件本地化
– 可能调整功能、界面
– 文档、媒体资料本地化
• 测试的重点内容：
– 验证设计和实现是否考虑软件国际化
– 功能测试
– 安装、卸载、升级
– 界面翻译测试：完整性、准确性
– 可用性（适用性）测试：用户界面、度量衡、时区、文化、宗教、喜好等
– 兼容性测试
– 文档验证：联机文档、在线帮助、手册等
• 软件国际化、本地化的常见问题?
– 翻译问题
– 文本扩展问题
– 字符集问题
– 数据格式问题
– 热键和快捷键问题
– 索引和排序问题
- 大小写转换问题

２2． 如何进行易用性测试，标准是什么
易用性测试的范围
a) 安装易用性测试
b) 功能易用性测试
c) 用户界面易用性测试
d) 辅助选项测试

２3． 辅助选项测试
针对用户
a) 视力损伤：色盲、近视、弱视
b) 听力损伤：半聋、全聋
c) 运动损伤：程度不一样
d) 认知和语言障碍
高对比度、声音卫士
粘滞键
e) 同时按下两个以上键有困难的人设计
office中的语音识别功能
法律规定
２4． 文档的种类
可行性分析阶段
a) 招/投标书
b) 可行性分析报告
c) 合同、协议
d) 项目规划
e) 项目开发计划
需求分析阶段
f) 需求分析说明书
g) 概要设计、详细设计说明书
h) 数据库设计说明书
i) 测试计划
j) 用户手册
k) 操作手册
l) 验收手册
开发阶段
m) 代码走查报告
n) 单元测试报告
o) 需求，设计变更申请单
p) 测试方案
测试阶段
q) 测试报告
r) 验收测试报告
维护阶段
a) 维护修改报告

２5． 为什么要进行文档测试(文档测试的重要性)
提高易用性：安装、使用
降低成本：支持费用
提高可靠性：正确、清晰的描述引导用户进行正确操作，否则……
促进销路
文档和代码同样重要，好的文档可以复现代码。

２6． 计划测试工作
测试计划的目的：
规定测试活动的范围、方法、资源和进度；了解正在测试的项目、明确要测试的特性、要执行的测试任务、每个任务的负责人，以及与计划相关的风险
• 计划测试工作重点考虑的问题 （内容）
– 1.产品基本情况调研
– 2.确定测试需求（任务）
– 3.定义测试策略
– 4.估计测试工作量和测试进度
– 5.配置资源
6.风险分析（顺序可提前
• 计划要经过评审，要有可行性!

２7． 如何报告软件缺陷
（1）做好测试记录，随时可能发现软件缺陷
（2）有效描述软件缺陷
a) 单一
b) 简短
c) 能复现
（3）不做评价
（4）尽快报告软件缺陷
（5）跟踪缺陷状态
（6）平常心，平常心！
（7）增强专业和行业知识
（8）掌握基本交流和沟通技巧

28． 流转流程（缺陷单处理状态）
测试人员发现、确认缺陷à 提交故障单à开发经理接受并指派à开发人员确认并修复à开发人员提交 à 测试人员验证 à
已提交à已指派à待解决à待验证à
通过关闭
不通过退回
29． 软件测试文档也需要进行评审
测试方针
测试策略
测试计划（不同级别的测试计划）
测试设计说明书
测试用例说明书
测试步骤说明书
测试事件报告
测试日志
测试项传递报告
测试总结报告

３0． 什么是系统性能
（1）用户角度
软件对用户（我）的操作的响应时间
（2）系统管理员角度
系统正常和繁忙时，各项资源指标
（3）设计、开发人员角度
– 技术选择是否合理
– 架构设计是否合理
– 数据库设计是否合理
– 代码编写是否合理
– 服务器配置是否合理
– 系统是否存在性能瓶颈，如何优化
（4）测试人员角度
– 扮演用户、系统管理员、设计、开发人员，多重角度关注系统性能

３1． 系统性能测试类型
负载测试
压力测试
疲劳强度测试

３2． 性能测试过程
确定测试目的
制定测试策略和方案
执行测试
测试结果分析

３3． 性能测试需求分析方法（会计算）
a) 80-20原则
举例：
每年业务量集中在8个月，每个月20个工作日，每个工作日8小时。去年全年处理业务约100万笔，其中15％的业务处理中每笔业务需对应用服务器提交7次请求；其中70％的业务处理中每笔业务需对应用服务器提交5次请求；其余15％的业务处理中每笔业务需对应用服务器提交3次请求。根据以往统计结果，每年的业务增量为15％，考虑到今后3年业务发展的需要，确定性能测试时需要的测试强度（请求次数/sec）
解：
• 每年总的请求数为：
(100*15%*7+100*70%*5+100*15%*3)*2
=1000万次/年
• 每天请求数为：1000/80*2=6.25万次/天
• 每秒请求数为：(62500*80%)/(8*20%*3600)=8.68次/秒
• 即性能测试时，测试强度应为9次/秒

b) 任务分布图
c) 交易混合图

３4． 系统性能–量化的指标
交易响应时间
并发用户数
思考时间
吞吐量
资源利用率