软件测试方法汇总

在工作中,经常听到"白盒测试""黑盒测试""系统测试"" 预测试"等名词,也能从书上看到各种测试方法论不同的称谓,有时感觉这些方法论叫得有些天花乱缀的感觉,很不容易分清,甚至有时不少人对这些称谓的内含以
及意义给搞混的也有,呵呵,我就听到过有一次某位leader对某种测试方法的表述出错的情况,只一个"汗"字了得,今天公司内部网络出现情况,没啥事, 就总结了一下各种测试方法论,可能不全,有新听见的再加吧!这下面没啥定义解释,全是按照个人理解而写的,主要是自己能记住能理解性了,如果按照IEEE 的定义,哎,只一个字,难记啊!还是平民化点的好!

名称	简述
黑盒测试	把程序当成一个黑盒子,在完全不考虑程序内部结构和内部特性的情况下,在程序接口进行测试,它只检查程序功能是否按照需要规格说明书的规定正常运行,特点:基于需求规格说书和功能
白盒测试	把程序当成一个打开的盒子,依据程序内部逻辑结构,对程序所有逻辑路径进行测试,特点:基于代码的内部逻辑,覆盖全部代码的分支,路径,条件
灰盒测试	看不到程序内部,但可以看到模块与模块之间的调用,特点:灰度主要是按照整体特性信息和内部具体实现信息所占的比例来确定的, 最常见的灰盒测试就是集成测试
静态测试	以一些人工模拟技术对软件进行分析和测试,特点:基于人工模拟
动态测试	通过输入一组预先按照一定准则构造的实例数据来驱动运行程序,特点:基于数据驱动
单元测试	用于检测被测试代码最小,最明确的功能是否正确,特点:测试最小单元功能块或代码块的正确性
跟踪测试	新功能增加后,对应用系统所做的连续测试
集成测试	也叫组装测试或联合测试,将所有模块根据设计结构图组装成子系统或系统进行集成测试,特点:一个应用系统的各个部份联合后的测试
功能测试	也称为行为测试,测试产品的一个特性或可操作行为,附合规设计需求,特点:基于系统的功能需求
系统测试	系统测试将已经确定的软件,硬件,外设,网络环境等元素组合在一起,进行各种组装测试和确认测试,其目的是验证系统与需求规格说明书相一致,特点:基于需求规格说明书,覆盖所有功能点
端到端测试	模块现实世界的使用环境,进行各种端口与端口间通信的测试,如,程序与数据库接口的测试
冒烟测试	对每一个新编辑的正式版本进行预测试,确定该版本可以进入下一轮测试,特点:基于,进入下一轮测试的前置条件测试
健全测试	冒烟测试的另一种称谓
预测试	冒烟测试的另一种称谓
回归测试	软件环境或软件错误修复后进行的验证测试,特点:基于验证,受控验证
验收测试	确定产品是否能够满足合同或用户所规定需求的测试,特点:基于客户或最终用户的需求规格书的测试
接受测试	验收测试的另一种称谓
负载测试	测试系统在重负荷下的表现
强迫测试	在重负荷下的系统测试
性能测试	交替进行负荷和强迫测试
可用性测试	”用户友好性”的测试,是一种主观测试的方法
易用性测试	可用性测试的别一种称谓
UI测试	界面测试的另一种称谓,对用户使用界面进行的测试,主要验证界面的友好性,易用性,以及是否符合行业或公司标准等
安装/卸载测试	对软件全部,部分或升级安装/卸载的处理过程进行测试
恢复测试	测试系统从特定灾难中能否较好的恢复
安全性测试	测试系统在防止非授权的内部或外部用户的访问或故障破坏等方面的能力,技术性要求很高
兼容测试	在不同硬件,不同操作系统,不同浏览器,不同网络等环境下,系统的功能或性能如何
比较测试	与竞争对手的产品进行对比测试,了解产品的优缺点,以及竞争的优劣势
Alpha测试	由用户在开发者的场所进行，并且在开发者对用户的“指导”下进行测试,特点:受控的环境下进行测试
Beta测试	由软件的最终用户们在多个场所,多个场景下进行测试,特点:真实环境