测试方法总结
2015-02-17 10:59
155 查看
黑盒测试和白盒测试是两种最普遍的策略。
黑盒测试 - black-box testing 又称为数据驱动的测试或输入\输出驱动的测试。将程序视为一个整体、且忽略其内部结构的测试方法。单纯从软件的规格说明书中获取测试数据。
测试的目标与程序的内部机制和结构完全无关,而是将重点集中在发现程序不按其规范正确运行的环境条件。
如何达到这种目的: 就是穷举输入测试,将所有可能的输入条件都作为测试用例。但穷举测试时不现实的,不符合经济学的。
白盒测试 - white-box testing 又称逻辑驱动测试,允许我们检查程序的内部结构。一种检查程序内部结构的测试类型。
穷举路径测试 - 优点:可以减少,但不完全。缺点: 不现实,不符合经济学原理。其次,穷举路径测试也不能保证测试设计符合设计规范, 也可能因为程序缺少某些路径而存在错误,穷举路径测试可能不会暴露数据敏感错误。
软件测试的原则:
1.测试用例中的一个必须部分是对预期输出或结果的定义。
2.程序员应当避免测试自己编写的程序。
3.编写软件的组织不应当测试自己编写的软件。
4.应当彻底检查每个测试的执行结果。
5.测试用例的编写不仅应当根据有效的和预期的输入情况,而且也应当根据无效的和未预料到的输入情况。
6.检查程序是否“未做其应该做的”仅是测试的一半,测试的另一半是检查程序是否“做了其不应该做的”。
7.应避免测试用例用后即弃,除非软件本身就是一个一次性的软件。
8.计划测试工作是不应默许假定不会发现错误。
9.程序某部分存在更多错误的可能性,与该部分已发现的错误的数目称正比。
10.软件测试是一项极富创造性、极具挑战性的工作。
牢记如下三个重要的测试原则:
• 软件测试是为发现错误而执行程序的过程。
• 一个好的测试用例具有较高的发现某个尚未发现的错误的可能性。
• 一个成功的测试用例能够发现某个尚未发现的错误。
1.静态测试 - static testing
1)代码审查 - Code Inspections
数据引用错误 - 1.是否有引用的变量未赋值或未初始化; 2.对于所有的数组引用,是否每一个下标的值都在相应的界限之内;3.对于所有的数组引用,是否每一个下标的值都是整数;4.对于所有通过指针或引用变量的引用,当前引用的内存单元是否分配。5.如果一个内存区域具有不同属性的别名,当通过别名引用时,内存区域中的数据值是否具有正确的属性。6.变量值得类型或属性与编译器所预期的是否一致。7.是否存在寻址错误。
运算错误 -
[b]数据声明错误 - 比较错误[/b]
控制流错误- [b]输入/输出错误[/b]
接口错误
2)代码走查 - Walkthroughs
3)桌面检查 - Desk checking
4) 同行评分(Peer Ratings)
动态测试:
一、黑盒测试
等价类划分
边界值分析
因果图分析
错误测试
二、白盒测试 - white-box-testing
白盒测试关注的是测试用例执行的程度或覆盖程序逻辑结构(源代码)的程度。
语句覆盖 -
判定覆盖
[b][b][b][b]条件覆盖
[/b][/b][/b][/b]
判定/条件覆盖
多重条件覆盖
逻辑覆盖测试 - Logic - Coverage - Testing
语句覆盖(有很大的不足)< 判定覆盖/分支覆盖 (较强。判定/分支覆盖准则将所有判断的每个可能结果都至少执行一次,以及将程序或子程序的每个入口点都至少执行一次。 判定覆盖通常可以满足语句覆盖) < 条件覆盖()
错误猜测 - Error Guessing
5.模块测试
增量测试
自顶向下的测试;
自下向上的测试;
6.更高级别的测试 - 当程序无法实现其最终用户要求的合理功能时,就发生了一个软件错误。
最终用户-> 需求-> 目标->外部规格说明书->系统设计 ->程序结构设计 ->模块接口规格说明 ->代码
1)功能测试 - Function Testing - 试图发现程序与其规格说明之间存在不一致的过程。- 黑盒测试的过程, 依赖早起的模块测试的过程来实现理想的白盒逻辑覆盖准则。
2)系统测试 - System Testing - 将系统或程序与其初始目标进行比较。1.系统测试并不局限于系统; 2.根据定义,如果产品没有一组书面的、可度量的目标,系统测试也就无法进行。根据用户文档和书面材料来阐明测试用例。 两个作用:1.将程序与其目标和用户文档相比较,2.同时也将用户文档与程序目标相比较;
能力测试 - Facility Testing - 判断目标文档提及的每一项能力是否都确实已经实现 ----问题检查单。
容量测试 - Volume Testing - 使程序经受大容量数据的检验。
强度测试 - Stress Testing - 使程序承受高负载或强度的检验 - 短时间内 。
易用性测试 - Usability Testing - 试图发现人为因素或易用性问题。
安全性测试 - Security Testing -
性能测试 - Performance Testing - 很多软件都有特定的性能和效率目标,这种特性描述为在特定的负载和配置环境下程序的相应时间和吞吐率。
存储测试 - Storage Testing - 程序使用的内存和赋存的容量,以及临时文件或溢出文件的大小。
配置测试 - Configuration Testing -
兼容性/配置/转换测试 - Compatibility/Configuration/Conversion Testing
安装测试 - Installability Testing
可靠性测试 - Reliability Testing
可恢复性测试 - Recovery Testing
适用性测试 - Serviceability Testing
文档测试 - Documentation Testing
过程测试 - Procedure Testing
Notes: 系统测试的执行 1.不能由程序员来进行系统测试; 2.在所有的测试阶段之中,这是唯一明确不能由负责该程序开发的机构来执行的测试。
3)验收测试 - Acceptance Testing
最初的需求及最终用户当前的需要进行比较的过程。不同寻常的测试,因为这个测试都是由程序的客户或最终用户来进行。
4)安装测试 - Installability Testing
测试的计划和控制
测试计划应包括:1.目标;2.结束准则;3.进度;4.责任;5.测试用例库和标准;6.工具;7.计算机时间;8.硬件配置;9.集成;10.跟踪步骤;11.调试步骤;12.回归测试;13.
7.调试 - Dubugging - 简单地讲,调试时执行一次成功的测试之后所要进行的工作。
记住所谓成功的测试 - 是指它可以证明程序没有实现预期的功能。
调试包含两个步骤:1.确定程序中可疑错误的准确性质和位置; 2.修改错误。
1)暴力法调试 - Debugging by brute force
2)归纳法调试 - Debugging by Induction
3)演绎法调试 - Debugging by Deduction
4)回溯法调试 - Debugging by Backtracking
5)测试法调试 - Debugging by Testing
8.极限编程 - XP - Extreme programming - 极限测试 - XT - Extreme testing
[b]12个实践
[/b]
1.计划于需求分析
2.小规模,递增的发布
3.系统的隐喻
4.简要设计
5.连续测试
6.重构
7.结对编程
8.代码的集体所有权
9.持续集成
10.每周40小时的工作
11.客户在现场
12.按标准编码
12个实践归纳为4个概念
1.聆听客户和其他程序员的谈话
2.与客户合作,开发应用程序的的规格说明和测试用例
3.结对编程
4.测试代码库
极限测试的测试类型 - 单元测试和验收测试
不同点:
但是在开发过程的那个阶段设计测试用例有所不同。
尽管如此:极限测试和传统测试的目标是相同的。
极限单元测试----单元测试是极限测试中采用的主要测试方法。两个简单规则:1.所有的代码模块在编程开始之前必须设计好单元测试用例;2.在产品发布之前须通过单元测试。
验收测试 ----目的是判断应用程序是否满足如功能性和易用性等其他的需求。在设计和开发阶段,有开发人员和客户来设计验收测试。验收测试时回归测试的一种形式。
黑盒测试 - black-box testing 又称为数据驱动的测试或输入\输出驱动的测试。将程序视为一个整体、且忽略其内部结构的测试方法。单纯从软件的规格说明书中获取测试数据。
测试的目标与程序的内部机制和结构完全无关,而是将重点集中在发现程序不按其规范正确运行的环境条件。
如何达到这种目的: 就是穷举输入测试,将所有可能的输入条件都作为测试用例。但穷举测试时不现实的,不符合经济学的。
白盒测试 - white-box testing 又称逻辑驱动测试,允许我们检查程序的内部结构。一种检查程序内部结构的测试类型。
穷举路径测试 - 优点:可以减少,但不完全。缺点: 不现实,不符合经济学原理。其次,穷举路径测试也不能保证测试设计符合设计规范, 也可能因为程序缺少某些路径而存在错误,穷举路径测试可能不会暴露数据敏感错误。
软件测试的原则:
1.测试用例中的一个必须部分是对预期输出或结果的定义。
2.程序员应当避免测试自己编写的程序。
3.编写软件的组织不应当测试自己编写的软件。
4.应当彻底检查每个测试的执行结果。
5.测试用例的编写不仅应当根据有效的和预期的输入情况,而且也应当根据无效的和未预料到的输入情况。
6.检查程序是否“未做其应该做的”仅是测试的一半,测试的另一半是检查程序是否“做了其不应该做的”。
7.应避免测试用例用后即弃,除非软件本身就是一个一次性的软件。
8.计划测试工作是不应默许假定不会发现错误。
9.程序某部分存在更多错误的可能性,与该部分已发现的错误的数目称正比。
10.软件测试是一项极富创造性、极具挑战性的工作。
牢记如下三个重要的测试原则:
• 软件测试是为发现错误而执行程序的过程。
• 一个好的测试用例具有较高的发现某个尚未发现的错误的可能性。
• 一个成功的测试用例能够发现某个尚未发现的错误。
1.静态测试 - static testing
1)代码审查 - Code Inspections
数据引用错误 - 1.是否有引用的变量未赋值或未初始化; 2.对于所有的数组引用,是否每一个下标的值都在相应的界限之内;3.对于所有的数组引用,是否每一个下标的值都是整数;4.对于所有通过指针或引用变量的引用,当前引用的内存单元是否分配。5.如果一个内存区域具有不同属性的别名,当通过别名引用时,内存区域中的数据值是否具有正确的属性。6.变量值得类型或属性与编译器所预期的是否一致。7.是否存在寻址错误。
运算错误 -
[b]数据声明错误 - 比较错误[/b]
控制流错误- [b]输入/输出错误[/b]
接口错误
2)代码走查 - Walkthroughs
3)桌面检查 - Desk checking
4) 同行评分(Peer Ratings)
动态测试:
一、黑盒测试
等价类划分
边界值分析
因果图分析
错误测试
二、白盒测试 - white-box-testing
白盒测试关注的是测试用例执行的程度或覆盖程序逻辑结构(源代码)的程度。
语句覆盖 -
判定覆盖
[b][b][b][b]条件覆盖
[/b][/b][/b][/b]
判定/条件覆盖
多重条件覆盖
逻辑覆盖测试 - Logic - Coverage - Testing
语句覆盖(有很大的不足)< 判定覆盖/分支覆盖 (较强。判定/分支覆盖准则将所有判断的每个可能结果都至少执行一次,以及将程序或子程序的每个入口点都至少执行一次。 判定覆盖通常可以满足语句覆盖) < 条件覆盖()
错误猜测 - Error Guessing
5.模块测试
增量测试
自顶向下的测试;
自下向上的测试;
6.更高级别的测试 - 当程序无法实现其最终用户要求的合理功能时,就发生了一个软件错误。
最终用户-> 需求-> 目标->外部规格说明书->系统设计 ->程序结构设计 ->模块接口规格说明 ->代码
1)功能测试 - Function Testing - 试图发现程序与其规格说明之间存在不一致的过程。- 黑盒测试的过程, 依赖早起的模块测试的过程来实现理想的白盒逻辑覆盖准则。
2)系统测试 - System Testing - 将系统或程序与其初始目标进行比较。1.系统测试并不局限于系统; 2.根据定义,如果产品没有一组书面的、可度量的目标,系统测试也就无法进行。根据用户文档和书面材料来阐明测试用例。 两个作用:1.将程序与其目标和用户文档相比较,2.同时也将用户文档与程序目标相比较;
能力测试 - Facility Testing - 判断目标文档提及的每一项能力是否都确实已经实现 ----问题检查单。
容量测试 - Volume Testing - 使程序经受大容量数据的检验。
强度测试 - Stress Testing - 使程序承受高负载或强度的检验 - 短时间内 。
易用性测试 - Usability Testing - 试图发现人为因素或易用性问题。
安全性测试 - Security Testing -
性能测试 - Performance Testing - 很多软件都有特定的性能和效率目标,这种特性描述为在特定的负载和配置环境下程序的相应时间和吞吐率。
存储测试 - Storage Testing - 程序使用的内存和赋存的容量,以及临时文件或溢出文件的大小。
配置测试 - Configuration Testing -
兼容性/配置/转换测试 - Compatibility/Configuration/Conversion Testing
安装测试 - Installability Testing
可靠性测试 - Reliability Testing
可恢复性测试 - Recovery Testing
适用性测试 - Serviceability Testing
文档测试 - Documentation Testing
过程测试 - Procedure Testing
Notes: 系统测试的执行 1.不能由程序员来进行系统测试; 2.在所有的测试阶段之中,这是唯一明确不能由负责该程序开发的机构来执行的测试。
3)验收测试 - Acceptance Testing
最初的需求及最终用户当前的需要进行比较的过程。不同寻常的测试,因为这个测试都是由程序的客户或最终用户来进行。
4)安装测试 - Installability Testing
测试的计划和控制
测试计划应包括:1.目标;2.结束准则;3.进度;4.责任;5.测试用例库和标准;6.工具;7.计算机时间;8.硬件配置;9.集成;10.跟踪步骤;11.调试步骤;12.回归测试;13.
7.调试 - Dubugging - 简单地讲,调试时执行一次成功的测试之后所要进行的工作。
记住所谓成功的测试 - 是指它可以证明程序没有实现预期的功能。
调试包含两个步骤:1.确定程序中可疑错误的准确性质和位置; 2.修改错误。
1)暴力法调试 - Debugging by brute force
2)归纳法调试 - Debugging by Induction
3)演绎法调试 - Debugging by Deduction
4)回溯法调试 - Debugging by Backtracking
5)测试法调试 - Debugging by Testing
8.极限编程 - XP - Extreme programming - 极限测试 - XT - Extreme testing
[b]12个实践
[/b]
1.计划于需求分析
2.小规模,递增的发布
3.系统的隐喻
4.简要设计
5.连续测试
6.重构
7.结对编程
8.代码的集体所有权
9.持续集成
10.每周40小时的工作
11.客户在现场
12.按标准编码
12个实践归纳为4个概念
1.聆听客户和其他程序员的谈话
2.与客户合作,开发应用程序的的规格说明和测试用例
3.结对编程
4.测试代码库
极限测试的测试类型 - 单元测试和验收测试
不同点:
但是在开发过程的那个阶段设计测试用例有所不同。
尽管如此:极限测试和传统测试的目标是相同的。
极限单元测试----单元测试是极限测试中采用的主要测试方法。两个简单规则:1.所有的代码模块在编程开始之前必须设计好单元测试用例;2.在产品发布之前须通过单元测试。
验收测试 ----目的是判断应用程序是否满足如功能性和易用性等其他的需求。在设计和开发阶段,有开发人员和客户来设计验收测试。验收测试时回归测试的一种形式。
相关文章推荐
- 绘制不规则位图方法总结,多种实现方法,全面测试比较
- 由[ERP系统验收时测试流程方法及内容]总结现公司验收流程 2007/5/4
- 自动化测试中的验证码处理方法小总结
- 测试用例设计方法总结
- web项目测试方法总结
- 绘制不规则位图方法总结,多种实现方法,全面测试比较
- event对象获取方法总结在google浏览器下测试
- 测试用到的方法总结
- web项目测试方法总结 .
- web测试方法总结
- 网站测试基本方法-8. 网站功能测试总结
- 性能测试方法总结
- Visual Studio 进行单元测试时如何附加被测试文件的方法总结
- 设计报表测试(统计方面)用例方法总结
- 性能测试培训总结-axwin frame window:thumbprocess.exe 解决方法
- B/S结构测试的基本方法总结(不全的希望大家补充)
- 报表测试用例设计方法总结
- 软件测试 方法总结
- BDD课题研究之测试思想和方法总结(三)
- 关于测试方法的总结