软件测试方法按各种类划分为:
一. 按开发阶段划分
单元测试(模块测试)
单元测试是对软件组成的单元进行测试,其目的是检验软件基本组成单位的正确性
TDD(测试驱动开发),开发人员先不写代码,测试人员先写测试用例,开发人员根据测试用例写代码
测试阶段:编码后或者编码前(TDD)
测试对象:最小模块
测试人员:白盒测试工程师或者开发工程师
测试依据:代码和注释+详细设计文档
测试方法:白盒测试
测试内容:模块接口测试,局部数据结构测试,路径测试,错误处理测试,边界测试
集成测试
集成测试又称为联合测试,组装测试,将程序模块采用适当的集成策略组装起来,对系统的接口及集成后的功能进行正确性检验的的测试工作
测试目的:检查软件单位之间的接口是否正确
测试阶段:一般在单元测试之后进行
测试对象:模块间的接口
测试人员:白盒测试工程或开发工程师
测试依据:单元测试的模块+概要设计文档
测试方法:白盒测试和黑盒测试方法的结合(接口就是黑盒测试,功能就是白盒测试)
测试内容: 模块之间数据传输.模块之间功能冲突,
系统测试
将软件系统看成是一个系统的测试,包括对功能,性能以及对软件运行软硬件环境的测试,时间大部分在系统测试执行阶段,包括回归测试和冒烟测试
回归测试在整个软件测试过程中占有很大的工作量比重,软件开发的各个阶段都会进行多次的回归测试
冒烟测试一般在开发人员开发完之后送给测试人员来进行测试,测试人员会先进行冒烟测试,保证基本功能正常,不阻碍后续 的测试
冒烟测试的执行者是版本编译人员
回归测试:指修改了旧代码之后,重新进行测试以确认没有引入新的错误或者导致其他代码产生产生错误
冒烟测试:对一个硬件或者硬件组件进行更改或者修复之后,直接给设备加电,如果没有冒烟,则该组件就通过了测试,也可以理解为这种测试时间短,仅用一袋烟功夫就够了
测试阶段:集成测试通过之后
测试对象:整个系统(软硬件)
测试人员:黑盒测试工程师
测试依据:需求规格说明文档
测试方法:黑盒测试
测试内容:功能,界面,可靠性,易用性,性能,安全性
验收测试
验收测试是软件部署之前的最后一个测试动作,它是技术测试的最后一个阶段,也称为交付测试
测试目的:确保软件准备就绪,按照项目合同,任务书,双方约定的验收依据文档,向软件购买都展示该软件系统满足原始需求
测试阶段:系统测试通过之后
测试对象:整个系统
测试人员:最终用户或者需求方
测试依据:用户需求,验收标准
测试方法:黑盒测试
测试内容:功能,界面,可靠性,易用性,性能,安全性,各类文档
二. 按测试实施组织划分
α测试
α测试是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的测试
目的:评价软件产品的FLURPS(即功能,局域化,可使用性,可靠性,性能和支持)
大型通用软件在正式发布前,通常需要执行α和β测试,注意:α测试不能由程序员或者测试人员完成,需要用户或者公司内部用户完成
β测试
β测试是一种验收测试,β测试由软件的最终用户们在一个或多个场所下进行
α测试和β测试的区别:
测试的场所不同:
α测试是指把用户请到开发方的场所来做测试
β测试是指在一个或多个用户的场所进行的测试
测试的时间不同:
α测试先于β测试执行,通用的软件产品需求需要较大的规模的β测试的周期比较长
三. 按测试执行方式划分
静态测试
静态测试是指不运行被测程序本身,仅通过分析或者检查源程序的语法,结果,过程,接口等来检查程序的正确性
分析如下:
检查项:代码风格和规则核审:程序设计和结构的审核;业务逻辑的审核,走查,审查与技术复审手册
静态质量:功能性,可靠性,可用性,有效性,可维护性,可移植性(质量六性)
代码静态分析和文档测试都属于静态测试
动态测试
动态测试是指通过运行被测程序,检查运行结果与预期结果的差异,并分析运行效率,正确性和健壮性等
由三部分组成:构造测试用例,执行程序,分析程序的输出结果
四. 按是否查看代码划分为
黑盒测试
黑盒测试也称功能测试,测试中把被测软件当成一个黑盒子,不关心盒子的内部结构是什么,只关心软件的输入数据与输出数据
白盒测试
白盒测试又称为结构测试,透明盒测试,逻辑驱动测试或基于代码的测试,白盒指的是打开盒子,去研究里面的源代码和程序结果
接口测试也是白盒测试的一种
灰盒测试
灰盒测试,是介于黑盒测试和白盒测试之间的一种测试,灰盒测试多用于集成测试阶段,不仅关注输出输入,输出的正确性,同时也关注程序的内部情况
五. 按是否手工划分为
手工测试
手工测试就是就是由人一个一个的输入用例,然后观察结果,和机器测试相对应,属于比较原始但是必须的一个步骤
优点:自动化测试无法替代探索性测试,发散思维结果的测试
缺点:执行效率慢,量大易错
自动化测试
自动化测试是以人为驱动的测试行为转化为机器执行的一种过程
自动化测试有比如功能测试自动化,性能测试自动化,安全测试自动化,通常说的自动化是指功能测试自动化
自动化按对象来分,还可以分为接口测试,UI测试等
六. 按测试地域划分为
国际化测试
本地化和国际化测试与其他类型的测试存在很多不同之处。下面是本地化和国际化测试 的一些要点。
本地化后的软件在外观上与原来版本是否存在很大的差异，外观是否墼齐、不走样。
是否对所有界面元素都进行了本地化处理，包括对话框、菜单、工具栏、状态栏、提示信息（包括声音的提示）、日志等。
在不同的屏幕分辨率下界面是否正常显示。
是否存在不同的字体大小，字体设置是否恰当
日期、数字格式、货币等是否能适应不同国家的文化习俗。例如，中文是年月日，而英文是月日年
排序的方式是否考虑了不同语言的特点。例如，中文按照第一个字的汉语拼音顺序排序，而英文按照首字母排序。
在不同的国家采用不同的度量单位，软件是否能自适应和转换
软件是否能在不同类型的硬件上正常运行，特别是在当地市场上销售的流行硬件上。
软件是否能在Windows或者其他操作系统的当地版本上正常运行。
联机帮助和文档是否已经翻译，翻译后的链接是否正常。正文翻译是否正确、恰当， 是否有语法错误。
本地化测试
软件本地化和国际化测试是一个综合了翻译行业和软件测试行业的测试类型。它要求测 试人员具备一定的翻译能
力、语言文化，同时具备测试人员的基本技能
七. 按测试对象划分为
性能测试
检查系统是否满足需求规格说明书中规定的性能
通常包括:
对资源利用进行的精确度量
对执行间隔
日志事件(如中断,报错)
响应时间
吞吐量(TPS)
辅助存储区(缓冲区,工作区大小)
处理精度等进行监测
界面测试
界面测试（简称UI测试)，测试用户界面的功能模块的布局是否合理、整体风格是否一致、各个控件的放置位置是否符合客户使用习惯，此外还要测试界面操作便捷性、导航简单易懂性，页面元素的可用性，界面中文字是否正确，命名是否统一，页面是否美观，文字、图片组合是否完美等。
容错性测试
容错性测试是检查软件在异常条件下自身是否具有防护性的措施或某种灾难性恢复的手段。当系统出错时，能否在
指定时间间隔内修正错误并重新启动系统。容错性测试包括两个方面:
(1) 输入错误的数据类型，如“猴”年“马”月。
(2) 输入定义域之外的数值，上海人常说的“十三点”也算一种。
粗暴一些的容错性测试俗称“大猩猩”测试，除了不能拳打脚踢嘴咬，什么招术都可以使出来
输入异常数据或进行异常操作，以检验系统的保护性。如果系统的容错性好，系统只给出提示或内部消化
掉，而不会导致系统出错甚至崩溃。
比较温柔的容错性测试通常构造一些不合理的输入来引诱软件出错，例如：
灾难恢复性测试,通过各种手段，让软件强制性地发生故障，然后验证系统已保存的用户数据是否丢失，系统和数据是否能尽快恢复。
安全测试
安全测试是一个相对独立的领域，需要更多的专业知识。例如web的安全测试，需要熟悉各种网络协议TCP\HTTP，防火墙，CDN，熟悉各种操作系统的漏洞，熟悉路由器等。从软件来说，熟悉各种攻击手段，例如
SQL注入、Xss等。
兼容性测试
兼容性主要是指软件之间能否很好的运做，会不会有影响、软件和硬件之间能否发挥很好的效率工作，会不会影响
导致系统的崩溃。
平台测试
浏览器测试
软件本身能否向前或者向后兼容
测试软件能否与其它相关的软件兼容
数据兼容性测试
最常见的就是浏览器的兼容性测试，不同浏览器在css，js解析上的不同会导致页面的显示不同。常见的IE8的兼容
性
文档测试
开发文件:可行性研究报告、软件需求说明书、数据要求说明书、概要设计说明书、详细设计说明书、数据库设计说明书、模块开发卷宗。
用户文件::用户手册、操作手册，用户文档的作用：改善易安装性；改善软件的易学性与易用性；改善软件可靠性；降低技术支持成本
管理文件:项目开发计划、测试计划、测试分析报告、开发进度月报、项目开发总结报告
文档测试的关注点：
文档的术语
文档的正确性
文档的完整性
文档的一致性
文档的易用性
文档的可读性
易用性测试(用户体验测试)
易用性（Useability）是交互的适应性、功能性和有效性的集中体现。易用性属于人体工程学的范畴，人体工程（ergonomics）是一门将日常使用的东西设计为易于使用和实用性强的学科。
业务测试
业务测试是测试人员把系统各个模块串接起来运行、模拟真实用户实际的工作流程，满足用户需求定义的功能来进行测试的
过程
业务测试关注需求和用户
安装测试
测试程序的安装、卸载
典型的是app的安装、卸载