一、 按开发阶段分
SDK(SoftWare DeveLopment Kit):一般是指软件工程师特定的软件包建立的开发工具集合。
ROI:投入产出比
1. 单元测试(Unit Testing)
单元测试是对软件组成单元进行测试。其目的是检验软件基本组成单位的正确性。测试的对象是软件设计的最小单位:模块。又称为模块测试
- 测试阶段:编码后或者编码前(TDD)
- 测试对象:最小模块
- 测试人员:白盒测试工程师或开发工程师
- 测试依据:代码和注释+详细设计文档
- 测试方法:白盒测试
- 测试内容:模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试
2. 集成测试(Integration Testing)
集成测试也称联合测试(联调)、组装测试,将程序模块采用适当的集成策略组装起来,对系统的接口及集成后的功能进行正确性检测的测试工作。集成主要目的是检查软件单位之间的接口是否正确。
- 测试阶段:一般单元测试之后进行
- 测试对象:模块间的接口
- 测试人员:白盒测试工程师或开发工程师
- 测试依据:单元测试的模块+概要设计文档
- 测试方法:黑盒测试与白盒测试相结合
- 测试内容:模块之间数据传输、模块之间功能冲突、模块组装功能正确性、全局数据结构、单模块缺陷对系统的影响
3. 系统测试
将软件系统看成是一个系统的测试。包括对功能、性能以及软件所运行的软硬件环境进行测试。时间大部分在系统测试执行阶段,包括回归测试和冒烟测试。
- 测试阶段:集成测试通过之后
- 测试对象:整个系统(软、硬件)
- 测试人员:黑盒测试工程师
- 测试依据:需求规格说明文档
- 测试方法:黑盒测试
- 测试内容:功能、界面、可靠性、易用性、性能、兼容性、安全性等
1)回归测试:
回归测试是指修改了旧代码后,重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。
在整个软件测试过程中占有很大的工作量比重,软件开发的各个阶段都会进行多次回归测试。随着系统的庞大,回归测试的成本越来越大,通过选择正确的回归测试策略来改进回归测试的效率和有效性是很有意义的。
2)冒烟测试
这一术语源自硬件行业。对一个硬件或硬件组件进行更改或修复后,直接给设备加电。如果没有冒烟,则该组件就通过了测试。也可以理解为该种测试耗时短,仅用一袋烟功夫足够了。
冒烟测试的对象是每一个新编译的需要正式测试的软件版本,目的是确认软件基本功能正常,可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。
新买手机回来,第一件事情是把常用功能试一遍,第二件事情把所有的功能试一遍。
冒烟测试一般在开发人员开发完毕后送给测试人员来进行测试时,测试人员会先进行冒烟测试,保证基本功能正常,不阻碍后续的测试。
4. 验收测试
买到新手机,一般会有7天包退,一个月包换,我们会尽量在7天内把手机的所有功能都试一遍。
验收测试是部署软件之前的最后一个测试操作。它是技术测试的最后一个阶段,也称为交付测试。验收测试的目的是确保软件准备就绪,按照项目合同、任务书、双方约定的验收依据文档,向软件购买都展示该软件系统满足原始需求。
- 测试阶段:系统测试通过之后
- 测试对象:整个系统(包括软硬件)。
- 测试人员:主要是最终用户或者需求方。
- 测试依据:用户需求、验收标准
- 测试方法:黑盒测试
- 测试内容:同系统测试(功能…各类文档等)
二、按测试实施组织划分
1. α(Alpha Testing)
手机出厂前最后一次测试,开发和测试人员不参与。
α测试是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的测试。α测试的目的是评价软件产品的FLURPS(即功能、局域化、可使用性、可靠性、性能和支持)。
大型通用软件,在正式发布前,通常需要执行Alpha和Beta测试。α测试不能由程序员或测试员完成。
2. β(Beta Testing)
新手机购买回来,参与测试的人是购买者,使用的场所及环境已不再是手面厂商的环境及场所
Beta测试是一种验收测试。Beta测试由软件的最终用户们在一个或多个场所进行。
α测试与Beta测试的区别:
- 测试的场所不同:Alpha测试是指把用户请到开发方的场所来测试,beta测试是指在一个或多个用户的场所进行的测试。
- Alpha测试的环境是受开发方控制的,用户的数量相对比较少,时间比较集中。beta测试的环境是不受开发方控制的,用户数量相对比较多,时间不集中。
- alpha测试先于beta测试执行。通用的软件产品需要较大规模的beta测试,测试周期比较长。
3. 第三方
介于开发方和用户方间的组织的测试。
三、按是否运行划分
1.静态测试(Static testing)
静态方法是指不运行被测程序本身,仅通过分析或检查源代码的语法、结构等来检查程序的正确性。对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错。分析如下:
- 检查项:代码风格和规格审核;程序设计和结构的审核;业务逻辑的审核;走查、审查与技术复审手册
- 静态质量:度量所依据的标准是ISO9126。在该标准中,软件的质量用以下几个方面来衡量,即功能性(Functionality)、可靠性(Reliability)、可用性(Usability)、有效性(Efficiency)、可维护性(Maintainability)、可移植性(Portability)。
代码静态分析和文档测试都属于静态测试
2.动态测试(Dynamic testing)
动态测试方式是通过运行被测程序,检查运行结果与预期结果的差异,并分析运行效率、正确性和健壮性等性能。这种方法由三部分组成:构造测试用例、执行程序、分析程序的输出结果、
大多数软件测试工作都属于动态测试。
四、按是否查看代码划分
不管黑盒、白盒、灰盒,能抓住bug就是好盒
1.黑盒测试(Black-Box Testing)
黑盒测试也称功能测试,测试中把被测软件当成一个黑盒子,不关心盒子的内部结构是什么,只关心软件的输入数据与输出数据
2.白盒测试(White-Box Testing)
白盒测试又称结构测试、透明盒测试、逻辑驱动测试、基于代码的测试
白盒指的打开盒子,去研究里面的源代码和程序结果
接口测试也是白盒测试的一种
3.灰盒测试(Gray-Box Testing)
灰盒测试是介于白盒测试和黑盒测试之间的一种测试,灰盒测试多用于集成测试阶段,不仅关心输出、输入的正确性,同时也关注程序内部的情况
五、按是否手工执行划分
1.手工测试(Manual Testing)
手工测试就是由人去一个一个的输入用例,然后观察结果,和机器测试相对应,属于比较原始但是必须的一个步骤
- 优点:自动化无法替代探索性测试、发散思维结果的测试
- 缺点:执行效率慢,量大易错
2.自动化测试
就是在预设条件下运行系统或应用程序,评估运行结果,预先条件应包括正常条件和异常条件。简单说自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。
自动化测试比如功能测试自动化、性能测试自动化、安全测试自动化
通常所说的自动化是指功能测试自动化
自动化测试按照测试对象来分,还可以分为接口测试、UI测试等。接口测试的ROI(产出投入比)要比UI测试高
- 自动化测试步骤:
- 完成功能测试,版本基本稳定
- 根据项目特性,选择适合项目的自动化工具,并搭建环境
- 提取手工测试的测试用例转化为自动化测试的测试用例
- 通过工具、代码实现自动化的构造输入,自动检测输出结果是否符合预期
- 生成自动测试报告
- 持续改进,脚本优化
六、按测试对象划分
1. 性能测试
检查系统是否满足需求规格说明书中规定的性能
通常表现在一下几个方面:
- 对资源利用(如内存、处理机周期等)进行的精确度量
- 执行间隔
- 日志时间(如中断、报错)
- 响应时间
- 吞吐量(TPS)
- 辅助缓存区(例如缓冲区、工作区的大小等)
- 处理精度等进行的监测
2. 安全测试
安全测试是一个相对独立的领域,需要更多的专业知识。例如web的安全测试,需要熟悉各种网络协议,熟悉各种操作系统的漏洞,熟悉路由器等
从软件来说,熟悉各种攻击手段,例如SQL注入,Xss等
3. 兼容性测试
兼容性主要指软件之间能否很好地运作,会不会有影响、软件和硬件之间能否噶会很好地效率工作,会不会影响导致系统的崩溃
- 平台测试
- 浏览器测试
- 软件本身能否向前或者向后兼容
- 测试软件是否与其他相关的软件兼容
- 数据兼容性测试
最常见的就是浏览器的兼容性测试,不同浏览器在css,js解析上的不同会导致页面的显示不同。常见的IE8的兼容性
4. 文档测试
国家有关计算机软件产品开发文件编制指南中共有14种文件,可分为3大类。
- 开发文件:可行性研究报告、软件需求说明书、数据要求说明书、概要设计说明书、详细设计说明书、数据库设计说明书、模块开发卷宗。
- 用户文件:用户手册、操作手册,用户文档的作用:改善易安装性;改善软件的易学性与易用性;改善软件可靠性;降低技术支持成本。
- 管理文件:项目开发计划、测试计划、测试分析报告、开发进度月报、项目开发总结报告。
- 在实际的测试中,最常见的是用户文件的测试,例如:手册说明书等。也会有一些公司对需求文档进行测试,来保证需求文档的质量。
文档测试的关注点:
- 文档的术语
- 文档的正确性、
- 文档的完整性
- 文档的一致性
- 文档的易用性
5. 易用性测试(用户体验测试)
易用性(Useability)是交互的适应性、功能性和有效性的集中表现。易用性属于人体工程学的范畴,人体工程学(ergonomics)是一门将日常使用的东西设计为易于使用和实用性强的学科
6. 业务测试
是测试人员把系统的各个模块串接起来运行、模拟真实用户实际的工作流程,满足用户需求定义的功能来进行测试的过程
查看邮件:
登录网站——输入用户名、密码登录——进入收件箱——查到邮件——点击打开——查阅——关闭邮件——推出邮箱——关闭网站
业务测试关注需求和用户
7. 界面测试
简称UI测试,测试用户界面的功能模块的布局是否合理、整体风格是否一致、各个控件的放置位置是否符合用户使用习惯,此外还要测试界面操作便捷性、导航简单易懂性,页面元素的可用性,界面中文字是否正确,命名是否统一,页面是否美观,文字图片组合是否完美等
一般大厂都有自己的规范可以作为测试参考。中小公司这部分测试一般都没有,除非明确的错误,否则容易和开发人员引起争议
8. 安装测试
测试程序的安装、卸载
补充:
9. 容错性测试
容错性测试是检查软件在异常条件下自身是否具有防护性的措施或某种灾难性恢复的手段。当系统出错时,能否在指定时间间隔内修正错误并重新启动系统。容错性测试包括两个方面:
- 输入异常数据或进行异常操作,以检验系统的保护性。如果系统的容错性好,系统只给出提示或内部消化掉,而不会导致系统出错甚至崩溃。
比较温柔的容错性测试通常构造一些不合理的输入来引诱软件出错,例如:
(1) 输入错误的数据类型,如“猴”年“马”月。
(2) 输入定义域之外的数值,上海人常说的“十三点”也算一种。粗暴一些的容错性测试俗称“大猩猩”测试,除了不能拳打脚踢嘴咬,什么招术都可以使出来。 - 灾难恢复性测试。通过各种手段,让软件强制性地发生故障,然后验证系统已保存的用户数据是否丢失,系统和数据是否能尽快恢复。
对于自动恢复需验证重新初始化、检查点、数据恢复和重新启动等机制的正确性;对于人工干预的恢复系统,还需估测平均修复时间,确定其是否在可接受的范围内。容错性好的软件能确保系统不发生无法意料的事故。从容错性测试的概念可以看出,当软件出现故障时如何进行故障的转移与恢复有用的数据是十分重要的。
10. 内存泄露测试
很多软件系统都存在内存泄露的问题,尤其是缺乏自动垃圾回收机制的“非托管”语言 编写的程序,例如C、CH、Delphi等。从用户使用的角度来看,内存泄露本身不会造成什么危害,一般用户可能根本不会感觉到内存泄露的存在。但是内存泄露是会累的,只要执行的次数足够多,最终会耗尽所有可用内存,使软件的执行越来越慢,最后停止响应。可以把这种软件的问题比喻成软件的“慢性病”。
造成内存泄露的原因有很多,最常见的有以下几种
- 分配完内存之后忘了回收。
- 程序写法有问题,造成没办法回收。
- 某些API函数的使用不正确,造成内存泄露。
- 没有及时释放。
内存泄漏的检测:
1、对于不同的程序可以使用不同的方法来进行内存泄露的检查,还可以使用一些专门的工具来进行内存问题的检查,例如MemProof. AQTime、Purify、BundsChecker等。 有些开发工具本身就带有内存问题检查机制.要确保程序员在编写程序和编译程序的时候打开这些功能。
2、通过代码扫描分析工具来检查
七、按测试地域划分
1. 本地化测试
之前所讲的所有测试方法的都是本地化测试
2. 国际化测试
软件的国际化和软件的本地化是开发面向全球不同地区用户使用的软件系统的两个过程。而本地化测试和国际化测试则是针对这类软件产品进行的测试。由于软件的全球化普及,还有软件外包行业的兴起,软件的本地化和国际化测试俨然成为了一个独特的测试专门领域。
本地化和国际化测试与其他类型的测试存在很多不同之处。下面是本地化和国际化测试的一些要点。
- 本地化后的软件在外观上与原来版本是否存在很大的差异,外观是否墼齐、不走样。
- 是否对所有界面元素都进行了本地化处理,包括对话框、菜单、工具栏、状态栏、提示信息(包括声音的提 示)、日志等。
- 在不同的屏幕分辨率下界面是否正常显示。
- 是否存在不同的字体大小,字体设置是否恰当。
- 日期、数字格式、货币等是否能适应不同国家的文化习俗。例如,中文是年月日,而英文是月日年。
- 排序的方式是否考虑了不同语言的特点。例如,中文按照第一个字的汉语拼音顺序排序,而英文按照首字母排序。
- 在不同的国家采用不同的度量单位,软件是否能自适应和转换。
- 软件是否能在不同类型的硬件上正常运行,特别是在当地市场上销售的流行硬件上。
- 软件是否能在Windows或者其他操作系统的当地版本上正常运行。
- 联机帮助和文档是否已经翻译,翻译后的链接是否正常。正文翻译是否正确、恰当,是否有语法错误。软件本地化和国际化测试是一个综合了翻译行业和软件测试行业的测试类型。它要求测试人员具备一定的翻译能力、语言文化,同时具备测试人员的基本技能。