软件测试培训
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
⑥算法错误，语法错误，计算和精度问题 ⑦非法操作的错误处理没有考虑 ⑧界面设计的遗漏，覆盖，乱码等
测试效果的好坏是组织级的问题
有效的测试最好由一个独立的团队来实施。
便于确定工作目标 便于人员的培养与升迁 利于团队建设 对质量的忠诚度高 利于新技术，新方法的产生和推广 工作职责明确 思考依附于开发的团队：质量妥协，思路受限，目
编码阶段的测试(略）
编写测试用例
编写测试用例方法
按照用户来编写 按照功能来编写 按照界面来编写
测试用例的来源
需求文档 详细设计文档 测试人员编写
测试用例方法格式
测试环境的描述（可选） 标题：功能点明确 步骤：单独的动作为一步 期望结果： 测试用例的属性：模块，用户，功能，性能等
如何使用
对安全性的需求进行评审 分析与安全性有关的处理流程 转包给专业的人员
例子
定义了被保护的资源，权限进行了控制，日志文件和审查追踪是可 用的。
什么时间使用
当被保护的资源对于组织具有重要的价值的时候
错误处理测试
目标
所有可能的错误条件均经过了验证
如何使用
一组有经验的人员预测在那里会出现问题
系统测试 验收测试
执行人
开发人员，用户 开发人员，用户
开发人员 开发人员
开发人员，测试 人员，用户 测试人员
用户
静态校验 √ √ √
动态校验
√ √ √ √
测试的技巧
BVT测试（T）
目标 刚发布的版本，确保基本功能的正确性
如何使用 使用基本功能测试用例对版本进行检测
例子 各种软件产品
什么时间使用 当较为重要的版本更新出现时（大规模的软件产品：新 版本出现时）
包括性能相反，性能相近，性能相关；
测试工具的选择
测试工具分类
性能测试工具： loadrunner:工作原理，录制、回放脚本、模 拟多用户同时访问被测试系统，制造负载， 产生并记录各种性能指标，生成分析结果， 从而完成性能测试的任务。；
自动化测试工具：Winrunner，Nitro， 原理：对比GUI
缺陷产生的原因
①需求不清晰 ②设计不合理而造成参数传递、方法调用、
对象状态变化等方面问题。 ③在系统实际应用中，数据量很大。从而会
引起强度或负载问题。 ④系统设计考虑不周导致的安全性问题，兼
容性问题
续……
⑤对程序逻辑路径或数据范围的边界考虑不 够周全，漏掉某些边界条件，造成容量或边 界错误。
性能 可操作性
继续……
压 执 恢 操 完 安 需 回 错 手 系 管平 单
力 行 复 作 整 全 求 归 误 工 统 理行 元
性性
处支兼
理持容
√√
√
√
√√
√
√
√ √√ √ √ √ √√
√
√
√
√
√
√
√√
√√
√ √
√√
√√ √
为什么缺陷很难被找出？
看不到 看到但是抓不到 典型的缺陷类型
需求解释有错误 用户定义错了需求 需求记录错误 设计说明有误 编码说明有误 程序代码有误 数据输入有误 测试错误 问题修改不正确 正确的结果是由于其它的缺陷产生的
测试要素（略）
正确性：数据输入，过程处理和输出的正确性（IPO）。 文件完整性：文件被正确使用，恢复和存储的数据正确。 授权：特殊的授权可以执行一个特殊的操作。 进程追踪：当进程运行中，程序有能力证实进程在正常工作。 系统运行的连续性：当有非致命性问题发生后，系统有能力
继续运行关键的任务。 服务水平：系统有紧急情况发生时，要求程序的输出结果不
测试发现的BUG（续）
BUG格式
标题：功能点明确，错误明确 测试环境的描述 步骤：单独的动作为一步 期望结果： 预期结果 附图，日志，其他信息， 出错原因分析
BUG
识别BUG的替换法：PC，产品，连接线等，至少要换设备复现1次 确认BUG的对比法：对比需求；对比标准版；对比行业标准；用户
常见的找缺陷的思路
软件生命周期的阶段：编码结束，测试刚开始， 版本的着重点：新功能 需求更改频繁的区域 设计复杂的功能点/接口多的功能点 边界值 很少弹出的界面和很少用的功能 测试人员的盲点而用户很可能会用到的地方：比如Help，安装等 Bug的周围再看看 特殊场景：内存占用高，进程和线程多，系统冲突 针对不同模块的功能精心组合: 比如手机静音模式+闹铃；设计思路
邀请用户来做，来体验，用户来反馈BUG 记录用户的行为
测试要素/测试技巧矩阵（略）
测试要素 可靠性
压执恢操复安需 力行复作合全求
性性
√√
√
回错 手 系管并 单 归误 工 统理行 元
处支兼 理持容
√
√
授权
√√
√
文件完整性
√
√
√
√
审查追踪
√
√
√
过程连续性 √
√√
√
测试要素
服务水平 权限控制 一致性 正确性 易用性 可维护性 兼容性 耦合性
续……
静态测试
在不运行程序的情况下检查程序的运行情况。
动态测试
运行程序代码
测试分类
单元测试 集成测试（组装测试） 系统测试 验收测试
续……
功能测试
测试功能需求
性能测试
验证系统稳定性和主要性能参数
黑盒测试
在不了解系统结构的情况下以说明书作为基础进 行测试。
白盒测试
以系统内部结构和相关知识为基础进行测试。
测试规划
好的测试不是碰巧发生的，而是规划出来的。
时间上 人员上 环境上 技术上 关系上 资金上 。。。
测试的时间
开始于项目的测试计划 结束于测试报告
谁参与测试？
用户方代表 软件最终使用者 软件开发人员 软件测试人员 高层经理的支持 过程保证人员（SQA）
测试流程--结构化测试方法
的参数
软件的测试过程
软件的测试过程
计划 需求 设计 编码 测试 维护
测试各阶段的工作
计划阶段
确定项目计划 确定开发计划和测试计划
需求阶段
确定收集了足够的需求 产生功能性的测试用例
设计阶段
确定设计和需求之间的联系 确定进行了足够的设计（详细设计说明书） 产生结构和功能的测试用例
测试阶段
测试关注点
在需求，设计，编码阶段多进行一些测试， 在系统测试阶段就会少一些问题。
文档
测试阶段的测试计划 测试用例 阶段性测试结果 测试BUG 正式的测试总结报告
测试发现的BUG
测试BUG严重等级
系统级 程序级 功能机 UI级
测试BUG优先级
思考，等级低但是优先级高的BUG
在需求和设计阶段发现的缺陷修正的花费最小 修正系统测试阶段发现的缺陷，花费是以上的10倍 发布产品以后，修正缺陷的花费是原来的100倍
设计阶段的测试(略）
交付的产品
输入说明 过程说明 文件说明 输出说明 控制说明 系统流程图 硬件和软件的需求 操作手册说明书 数据保留的策略
编码阶段
确定和设计之间的联系 产生结构和功能的测试用例
续……
测试阶段 确定设计了足够的测试用例 测试应用系统已经完成 关键资源已经到位
安装阶段 测试报告完成
维护阶段 修改和重新测试
测试计划
评审测试计划（略）
涉及评审的问题
评审测试的开始时间是否会延期 有没有抵触评审的角色 一段时间内是否很难得到工作的检查信息。 更换工具有可能导致他们反感评审工作 评审结果可能会影响对个人的工作评价
例子
建立一个错误处理的列表
什么时候使用
贯穿整个开发生命周期 要点：知道路径的和不知道路径的
安装测试
目标
软件或系统的正确安装和卸载
如何使用
系统或软件需要在不同的平台应用时。
例子
打印机驱动安装
注意要点
安装界面的所有选择，包括路径，全部或部分安装，安 装的提示文字，安装后的版本和ICON，卸载时的界面， 中止卸载尝试，卸载后的系统残留和影响。
传统的软件开发生命周期：
计划，需求，设计，编码，测试，系统维护
经验：
测试不应该被局限在单一的阶段 大量的系统问题产生在软件开发前期 越早进行测试越有效，投入产出比越高
测试要素（T）
一致性：确保最终设计和用户需求完全一致 可靠性：在规定的时间内都可以正常运转。 易于使用：多数人均感觉易于使用。 可维护性：可以很容易的定位问题，并且进行修改。 可移植性：数据或者程序易于移至到其它系统上。 耦合性：系统中的组件可以很容易的联接。 性能：系统资源的占用率，响应时间，并发处理 操作性：易于操作
标和计划的迷失…
测试方法学
QC和QA
质量控制
验证产品的正确性，当发现与设计不一致的时候 进行纠正。
质量保证
充当支持执行全面质量管理的角色
测试涉及的定义和概念
缺陷
与需求规格说明书不一致的地方。
静态检查
确保系统按照组织的标准和过程运行，主要依赖 于评审和非运行的手段来检查。
动态检查
在生命周期中进行测试（运行）
经或进行简单的处理后就可以直接使用。 权限控制：防止系统被误用（意外或者有意的）
测试工作量
太少的测试是不负责任，过多的测试是一种 犯罪。
100％的测试是不可能的，不同的用户采用的 测试策略是不同的。
重要的版本：所有功能点+性能参数 普通版本： bug验证+新功能点+未测试的
功能点
确定测试计划（T）
例子
– 计算通信的时间 – 单位时间处理的信息量
什么时候使用
－ 在程序开发的早期进行
压力测试
目标
模拟出实际用户环境
怎么用
产生测试数据 测试组模拟用户处理被创建的数据
例子
测试系统过载的情况 通讯的容量是否足够
什么时间使用
当关于容量的信息不确定的时候
安全性测试（略）
目标
安全性的缺陷很难被发现。 大多数的情况下组织能够防止一般性的破坏者。
对于最终成品的检查
项目的需求规格说明书 软件返工/维护的文档 升级后的技术文档 被更改的源程序 测试计划 用户手册（包括在线帮助）
需求阶段的测试（略)
测试成本
在软件开发的所有阶段进行测试
被设计用来减少测试成本
IBM的数据
大约 60个缺陷/千行 2/3的缺陷产生在需求和设计阶段
静态测试（略）
需求评审 设计评审 代码走查 代码检查
动态测试
功能测试 性能测试 回归测试 冒烟测试（ＢＶＴ测试） ＵＩ，本地化，国际化．．． 用户情景测试（user scenario）
使用静态和动态测试来进行结构和功能测 试
测试阶段
可行性评审 需求评审 设计评审 单元测试 集成测试
软件测试培训 Margo
培训列表
✓ 软件测试的目的和策略 ✓ 测试方法学 ✓ 测试的技巧 ✓ 测试工具的选择 ✓ 软件生命周期中的测试过程
软件测试的目的和策略
软件测试的目的 验证最终交付给用户的系统是否
满足用户的需要
典型测试步骤
1.计划：
2.执行： 3.检查： 4.循环： 5 总结：
定义目标 确定计划 确定方法 建立环境 执行计划 一步步验证 执行完毕 没有改正 继续执行 经验教训
缺陷管理工具： QC，PS，JIRA，BUGzilla
测试工具(继续……)
单元测试工具：Jtest，需要点击，自动生成测试用 例并执行；确认异常，函数错误，内存泄露，性能 问题，安全弱点 Junit，简化测试编写，立即的回馈,Free, 包括基础断言、数字断言、字符断言、布尔断言、 对象断言
Xunit: CPPunit,Dunit,Nunit, UI测试工具 集成测试工具:公司自己开发，简化的模块，带数据
单元测试
关注单元一级（函数，类，图形的窗口或菜 单）
代码分析和测试 功能分析和测试/结构分析和测试
模块接口测试（集成测试重点）； 局部数据结构测试； 边界条件测试； 模块中所有独立路径测试； 模块中的各条错误处理通路；
代码覆盖率
用户情景测试
适用于大型的系统，用户种类多的应用软件 定义主要用户群和定义使用习惯 创建测试用例
选择并确定测试要素的等级
多数情况下选择3～7个
确定测试阶段 明确商业风险
开发人员，重要用户和测试人员通过评审的方式 对这些风险达成一致的意见。
测试完成的标识（T）
按照测试计划完成测试任务 所有缺陷（bug）都要关闭
什么是缺陷？
缺陷：最终产品同用户的期望不一致 缺陷（未触发）VS.错误（应首先解决）
注意事项：用例的数量，小于5%
回归测试（T）
目标
程序修改后，确保功能的正确性
如何使用
重新测试应用程序中没有改变的部分
例子
重新执行以前的测试用例
什么时间使用
当新的程序有可能影响老的功能的时候
性能测试技巧
目标
– 确定系统达到了希望达到的性能水平
如何Βιβλιοθήκη Baidu用
– 使用软件和硬件的监视器 – 使用模拟的监控模型，对关心的性能指标进行监控 – 创建一个小程序
测试效果的好坏是组织级的问题
有效的测试最好由一个独立的团队来实施。
便于确定工作目标 便于人员的培养与升迁 利于团队建设 对质量的忠诚度高 利于新技术，新方法的产生和推广 工作职责明确 思考依附于开发的团队：质量妥协，思路受限，目
编码阶段的测试(略）
编写测试用例
编写测试用例方法
按照用户来编写 按照功能来编写 按照界面来编写
测试用例的来源
需求文档 详细设计文档 测试人员编写
测试用例方法格式
测试环境的描述（可选） 标题：功能点明确 步骤：单独的动作为一步 期望结果： 测试用例的属性：模块，用户，功能，性能等
如何使用
对安全性的需求进行评审 分析与安全性有关的处理流程 转包给专业的人员
例子
定义了被保护的资源，权限进行了控制，日志文件和审查追踪是可 用的。
什么时间使用
当被保护的资源对于组织具有重要的价值的时候
错误处理测试
目标
所有可能的错误条件均经过了验证
如何使用
一组有经验的人员预测在那里会出现问题
系统测试 验收测试
执行人
开发人员，用户 开发人员，用户
开发人员 开发人员
开发人员，测试 人员，用户 测试人员
用户
静态校验 √ √ √
动态校验
√ √ √ √
测试的技巧
BVT测试（T）
目标 刚发布的版本，确保基本功能的正确性
如何使用 使用基本功能测试用例对版本进行检测
例子 各种软件产品
什么时间使用 当较为重要的版本更新出现时（大规模的软件产品：新 版本出现时）
包括性能相反，性能相近，性能相关；
测试工具的选择
测试工具分类
性能测试工具： loadrunner:工作原理，录制、回放脚本、模 拟多用户同时访问被测试系统，制造负载， 产生并记录各种性能指标，生成分析结果， 从而完成性能测试的任务。；
自动化测试工具：Winrunner，Nitro， 原理：对比GUI
缺陷产生的原因
①需求不清晰 ②设计不合理而造成参数传递、方法调用、
对象状态变化等方面问题。 ③在系统实际应用中，数据量很大。从而会
引起强度或负载问题。 ④系统设计考虑不周导致的安全性问题，兼
容性问题
续……
⑤对程序逻辑路径或数据范围的边界考虑不 够周全，漏掉某些边界条件，造成容量或边 界错误。
性能 可操作性
继续……
压 执 恢 操 完 安 需 回 错 手 系 管平 单
力 行 复 作 整 全 求 归 误 工 统 理行 元
性性
处支兼
理持容
√√
√
√
√√
√
√
√ √√ √ √ √ √√
√
√
√
√
√
√
√√
√√
√ √
√√
√√ √
为什么缺陷很难被找出？
看不到 看到但是抓不到 典型的缺陷类型
需求解释有错误 用户定义错了需求 需求记录错误 设计说明有误 编码说明有误 程序代码有误 数据输入有误 测试错误 问题修改不正确 正确的结果是由于其它的缺陷产生的
测试要素（略）
正确性：数据输入，过程处理和输出的正确性（IPO）。 文件完整性：文件被正确使用，恢复和存储的数据正确。 授权：特殊的授权可以执行一个特殊的操作。 进程追踪：当进程运行中，程序有能力证实进程在正常工作。 系统运行的连续性：当有非致命性问题发生后，系统有能力
继续运行关键的任务。 服务水平：系统有紧急情况发生时，要求程序的输出结果不
测试发现的BUG（续）
BUG格式
标题：功能点明确，错误明确 测试环境的描述 步骤：单独的动作为一步 期望结果： 预期结果 附图，日志，其他信息， 出错原因分析
BUG
识别BUG的替换法：PC，产品，连接线等，至少要换设备复现1次 确认BUG的对比法：对比需求；对比标准版；对比行业标准；用户
常见的找缺陷的思路
软件生命周期的阶段：编码结束，测试刚开始， 版本的着重点：新功能 需求更改频繁的区域 设计复杂的功能点/接口多的功能点 边界值 很少弹出的界面和很少用的功能 测试人员的盲点而用户很可能会用到的地方：比如Help，安装等 Bug的周围再看看 特殊场景：内存占用高，进程和线程多，系统冲突 针对不同模块的功能精心组合: 比如手机静音模式+闹铃；设计思路
邀请用户来做，来体验，用户来反馈BUG 记录用户的行为
测试要素/测试技巧矩阵（略）
测试要素 可靠性
压执恢操复安需 力行复作合全求
性性
√√
√
回错 手 系管并 单 归误 工 统理行 元
处支兼 理持容
√
√
授权
√√
√
文件完整性
√
√
√
√
审查追踪
√
√
√
过程连续性 √
√√
√
测试要素
服务水平 权限控制 一致性 正确性 易用性 可维护性 兼容性 耦合性
续……
静态测试
在不运行程序的情况下检查程序的运行情况。
动态测试
运行程序代码
测试分类
单元测试 集成测试（组装测试） 系统测试 验收测试
续……
功能测试
测试功能需求
性能测试
验证系统稳定性和主要性能参数
黑盒测试
在不了解系统结构的情况下以说明书作为基础进 行测试。
白盒测试
以系统内部结构和相关知识为基础进行测试。
测试规划
好的测试不是碰巧发生的，而是规划出来的。
时间上 人员上 环境上 技术上 关系上 资金上 。。。
测试的时间
开始于项目的测试计划 结束于测试报告
谁参与测试？
用户方代表 软件最终使用者 软件开发人员 软件测试人员 高层经理的支持 过程保证人员（SQA）
测试流程--结构化测试方法
的参数
软件的测试过程
软件的测试过程
计划 需求 设计 编码 测试 维护
测试各阶段的工作
计划阶段
确定项目计划 确定开发计划和测试计划
需求阶段
确定收集了足够的需求 产生功能性的测试用例
设计阶段
确定设计和需求之间的联系 确定进行了足够的设计（详细设计说明书） 产生结构和功能的测试用例
测试阶段
测试关注点
在需求，设计，编码阶段多进行一些测试， 在系统测试阶段就会少一些问题。
文档
测试阶段的测试计划 测试用例 阶段性测试结果 测试BUG 正式的测试总结报告
测试发现的BUG
测试BUG严重等级
系统级 程序级 功能机 UI级
测试BUG优先级
思考，等级低但是优先级高的BUG
在需求和设计阶段发现的缺陷修正的花费最小 修正系统测试阶段发现的缺陷，花费是以上的10倍 发布产品以后，修正缺陷的花费是原来的100倍
设计阶段的测试(略）
交付的产品
输入说明 过程说明 文件说明 输出说明 控制说明 系统流程图 硬件和软件的需求 操作手册说明书 数据保留的策略
编码阶段
确定和设计之间的联系 产生结构和功能的测试用例
续……
测试阶段 确定设计了足够的测试用例 测试应用系统已经完成 关键资源已经到位
安装阶段 测试报告完成
维护阶段 修改和重新测试
测试计划
评审测试计划（略）
涉及评审的问题
评审测试的开始时间是否会延期 有没有抵触评审的角色 一段时间内是否很难得到工作的检查信息。 更换工具有可能导致他们反感评审工作 评审结果可能会影响对个人的工作评价
例子
建立一个错误处理的列表
什么时候使用
贯穿整个开发生命周期 要点：知道路径的和不知道路径的
安装测试
目标
软件或系统的正确安装和卸载
如何使用
系统或软件需要在不同的平台应用时。
例子
打印机驱动安装
注意要点
安装界面的所有选择，包括路径，全部或部分安装，安 装的提示文字，安装后的版本和ICON，卸载时的界面， 中止卸载尝试，卸载后的系统残留和影响。
传统的软件开发生命周期：
计划，需求，设计，编码，测试，系统维护
经验：
测试不应该被局限在单一的阶段 大量的系统问题产生在软件开发前期 越早进行测试越有效，投入产出比越高
测试要素（T）
一致性：确保最终设计和用户需求完全一致 可靠性：在规定的时间内都可以正常运转。 易于使用：多数人均感觉易于使用。 可维护性：可以很容易的定位问题，并且进行修改。 可移植性：数据或者程序易于移至到其它系统上。 耦合性：系统中的组件可以很容易的联接。 性能：系统资源的占用率，响应时间，并发处理 操作性：易于操作
标和计划的迷失…
测试方法学
QC和QA
质量控制
验证产品的正确性，当发现与设计不一致的时候 进行纠正。
质量保证
充当支持执行全面质量管理的角色
测试涉及的定义和概念
缺陷
与需求规格说明书不一致的地方。
静态检查
确保系统按照组织的标准和过程运行，主要依赖 于评审和非运行的手段来检查。
动态检查
在生命周期中进行测试（运行）
经或进行简单的处理后就可以直接使用。 权限控制：防止系统被误用（意外或者有意的）
测试工作量
太少的测试是不负责任，过多的测试是一种 犯罪。
100％的测试是不可能的，不同的用户采用的 测试策略是不同的。
重要的版本：所有功能点+性能参数 普通版本： bug验证+新功能点+未测试的
功能点
确定测试计划（T）
例子
– 计算通信的时间 – 单位时间处理的信息量
什么时候使用
－ 在程序开发的早期进行
压力测试
目标
模拟出实际用户环境
怎么用
产生测试数据 测试组模拟用户处理被创建的数据
例子
测试系统过载的情况 通讯的容量是否足够
什么时间使用
当关于容量的信息不确定的时候
安全性测试（略）
目标
安全性的缺陷很难被发现。 大多数的情况下组织能够防止一般性的破坏者。
对于最终成品的检查
项目的需求规格说明书 软件返工/维护的文档 升级后的技术文档 被更改的源程序 测试计划 用户手册（包括在线帮助）
需求阶段的测试（略)
测试成本
在软件开发的所有阶段进行测试
被设计用来减少测试成本
IBM的数据
大约 60个缺陷/千行 2/3的缺陷产生在需求和设计阶段
静态测试（略）
需求评审 设计评审 代码走查 代码检查
动态测试
功能测试 性能测试 回归测试 冒烟测试（ＢＶＴ测试） ＵＩ，本地化，国际化．．． 用户情景测试（user scenario）
使用静态和动态测试来进行结构和功能测 试
测试阶段
可行性评审 需求评审 设计评审 单元测试 集成测试
软件测试培训 Margo
培训列表
✓ 软件测试的目的和策略 ✓ 测试方法学 ✓ 测试的技巧 ✓ 测试工具的选择 ✓ 软件生命周期中的测试过程
软件测试的目的和策略
软件测试的目的 验证最终交付给用户的系统是否
满足用户的需要
典型测试步骤
1.计划：
2.执行： 3.检查： 4.循环： 5 总结：
定义目标 确定计划 确定方法 建立环境 执行计划 一步步验证 执行完毕 没有改正 继续执行 经验教训
缺陷管理工具： QC，PS，JIRA，BUGzilla
测试工具(继续……)
单元测试工具：Jtest，需要点击，自动生成测试用 例并执行；确认异常，函数错误，内存泄露，性能 问题，安全弱点 Junit，简化测试编写，立即的回馈,Free, 包括基础断言、数字断言、字符断言、布尔断言、 对象断言
Xunit: CPPunit,Dunit,Nunit, UI测试工具 集成测试工具:公司自己开发，简化的模块，带数据
单元测试
关注单元一级（函数，类，图形的窗口或菜 单）
代码分析和测试 功能分析和测试/结构分析和测试
模块接口测试（集成测试重点）； 局部数据结构测试； 边界条件测试； 模块中所有独立路径测试； 模块中的各条错误处理通路；
代码覆盖率
用户情景测试
适用于大型的系统，用户种类多的应用软件 定义主要用户群和定义使用习惯 创建测试用例
选择并确定测试要素的等级
多数情况下选择3～7个
确定测试阶段 明确商业风险
开发人员，重要用户和测试人员通过评审的方式 对这些风险达成一致的意见。
测试完成的标识（T）
按照测试计划完成测试任务 所有缺陷（bug）都要关闭
什么是缺陷？
缺陷：最终产品同用户的期望不一致 缺陷（未触发）VS.错误（应首先解决）
注意事项：用例的数量，小于5%
回归测试（T）
目标
程序修改后，确保功能的正确性
如何使用
重新测试应用程序中没有改变的部分
例子
重新执行以前的测试用例
什么时间使用
当新的程序有可能影响老的功能的时候
性能测试技巧
目标
– 确定系统达到了希望达到的性能水平
如何Βιβλιοθήκη Baidu用
– 使用软件和硬件的监视器 – 使用模拟的监控模型，对关心的性能指标进行监控 – 创建一个小程序