目录
一、软件测试的分类
- 按测试对象划分为界面测试、可靠性测试、容错性测试、文档测试、兼容性测试、易用性测试、安装卸载的测试、安全性测试、性能测试、内存泄漏
- 按是否查看代码划分为黑盒测试、白盒测试、灰盒测试
- 按开发阶段划分为单元测试、集成测试、系统测试、验收测试
- 按实施组织区划分为α测试(Alpha Testing)、β测试(Beta Testing)、第三方测试
- 按是否运行划分为静态测试、动态测试
- 按是否手工划分为手工测试、自动化测试
- 按地域划分为国际化测试、本地化测试
二、按测试对象划分:
1.界面测试---UI测试
- 界面是直接和用户交互的,界面设计的好快决定了用户使用软件的直观体验和感受
保证界面和UI设计稿的一致性,正确性
测试界面每一个功能的正确性
界面的布局、排版是否合理,字体大小,图片布局排版,清晰程度...
界面的控件功能是否正常,比如滚动条,按钮,文本框...
进行页面不同分辨率的测试
同一个web页面不同页面大小下测试
比如页面从小到大变化过程中的衔接是否卡顿,让用户是否可以接收
页面的字体不能模糊、不能重影
页面的图片不能消失,排版布局合理
页面的功能可以正常使用
2.可靠性测试
正常运行时间/(正常运行时间+非正常运行时间);软件自身和软件所部署的环境(硬件,软件系统,网络等)存在问题导致软件无法正常运行,都属于软件非正常运行的时间
一般软件,可靠性要求99.99%
软件可靠性影响因素:软件本身,外界因素(网络、硬件设备、软件系统)
3.容错性测试
- 由于自身或者外部一些异常的操作使得系统发生异常,系统能够自我处理这种错误操作或者异常的能力
3.1数据级别
比如:转账 0.09元
3.2校验级别
比如:输入账号6-16位,输入17位就不能输入了;大小写校验,空格校验等
3.3界面级别
一些复制的操作或者危险性比较高的操作,会给用户提示
3.4环境级别
断电、断网硬件设备出现问题,是否可以让用户无感知;人为让系统发生故障,测试系统是否能够很快恢复稳定,数据恢复,不丢失用户的信息
4.文档测试
整个开发过程中产生的各种文档,需求文档,设计文档、功能文档,用户使用手册进行测试
文档的正确性、一致性、完整性
5.兼容性测试
5.1平台的兼容性
web网页:各种浏览器,操作系统的兼容性;APP:不同系统IOS/Android,不同品牌,不同系统版本
5.2软件本身兼容性
软件对本身功能前后的兼容性,比如开发的新功能不能影响老功能,也不影响后续功能的开发
5.3软件对用户数据的兼容性
比如数据库中某一张表增加字段,不能影响用户之前的数据存储
5.4软件对第三方软件的兼容性
不能影响其他软件的使用;如果和第三方软件有交互,数据要有兼容性
6.易用性测试
- 用户使用软件的体验,用户体验测试
- 易用性是交互的适应性、功能和有效性的集中体现
符合标准和规范
直观性:让用户直接看到自己期望的操作或者预期的结果
灵活性:用户可以根据自己的习惯选择适合自己的操作方式,比如手机上的键盘,九宫格,手写,五笔
舒适性:让用户对自己进行的操作有感知,不产生焦虑情绪,比如安装软件时的进度条
7.安装卸载的测试
软件可以正常安装和卸载
软件更新
安装/卸载软件时断网、断电、死机等异常情况下,软件的响应
安装软件内存不足是否有提示
卸载软件暂停,是否可以继续卸载
卸载软件到一半,取消卸载,看软件是否可以正常使用
卸载后软件的数据文件信息是否清理干净
8.安全测试
防病毒,防黑客攻击,防止xss注入,防止SQL注入、防止爬虫
9.性能测试
内存泄漏、资源瓶颈、系统运行速度、系统运行受外界影响,死锁,查询信息速度慢
10.内存泄漏
- 内存泄漏会导致系统运行越来越慢
导致的原因有:内存分配后,没有回收;API函数使用不正确,无法回收;内存分配方式有问题,无法回收
三、按是否查看代码划分:
1.黑盒测试
黑盒测试不关心软件内部代码的实现,不关心代码的逻辑结构,只关心输入输出是否符合预期;
黑盒测试主要测试系统的功能,站在用户的角度来使用功能,有利于培养用户思维;
黑盒测试的测试用例是按照需求设计的,不容易遗漏需求
黑盒测试的测试方法:等价类,边界值,因果图,错误猜测发,场景法,正交法 等价类,边界值,因果图,错误猜测发,场景法,正交法 https://blog.csdn.net/qq_46235384/article/details/124617344
2.白盒测试
白盒测试就是针对代码进行的测试,分析和测试代码的逻辑和结构,实现的功能,看是否符合用户的需求
白盒测试的测试方法:语句覆盖法、判定覆盖法、条件覆盖法、判定条件法、条件组合覆盖法、基本路径覆盖法。
语句覆盖法:覆盖每个可执行语句。
判定覆盖法:覆盖每个判定分支。
条件覆盖法:覆盖判定中的每个条件。
判定条件法:满足判定覆盖法和条件覆盖法。
条件组合覆盖法:覆盖判定中的每个条件的所有可能组合。
基本路径覆盖法:覆盖每个基本分支路径,环路复杂度V(G)=判断节点数目+1。
白盒测试的基本原则:
1、保障每个模块所有独立路径至少使用一次
2、完成所有逻辑值分别为真值和假值的条件下的测试
3、在上下边界及可操作范围内运行所有循环,完成循环覆盖测试
4、检查内部数据结构以确保其有效性,完成边界条件的测试
3.灰盒测试
灰盒测试,是介于白盒测试与黑盒测试之间的一种测试,灰盒测试多用于集成测试阶段,不仅关注输 出、输入的正确性,同时也关注程序内部的情况。
四、按开发阶段划分:
1.单元测试
单元测试是指对软件程序中的最小功能单元代码(类、方法)进行测试,主要采用白盒测试。
单元测试是对软件组成单元进行测试。其目的是检验软件基本组成单位的正确性。
测试的对象是软件设计的最小单位:模块。又称为模块测试
测试阶段:编码后或者编码前(TDD)
测试对象:最小模块
测试人员:白盒测试工程师或开发工程师
测试依据:代码和注释+详细设计文档
测试方法:白盒测试
测试内容:模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试
驱动模块:用于模拟被测试模块的上级模块,能够调用被测模块。
桩模块:用以模拟被测模块工作过程中所调用的下层模块。
测试驱动开发(TDD)是一种不同于传统软件开发流程的过程模型。要求测试在先,编码在后的开发方法,更符合“缺陷预防的思想”,
在打算添加某项新功能时,先不要急着写程序代而是为待编写的代码先写一段测试用例。然后,利用成开发环境或相应的测试工具来执行这段测试用例,结果自然是失败。 利用没有通过测过造误信息反馈,了解到代码没有通过测试用例的原因,有针对性地逐步地添加代码:为了要该测试用例通过,就要补充、修改代码,直到代码符合测试用例的要求,获得通过。
2.集成测试
集成测试是指将单元模块组装起来,对模块接口进行测试。集成主要目的是检查软件单位之间的接口是否正确。
测试阶段:一般单元测试之后进行
测试对象:模块间的接口
测试人员:黑盒测试工程师或开发工程师
测试依据:单元测试的模块+概要设计文档
测试方法:黑盒测试与白盒测试相结合,灰盒测试
测试内容:整个模块功能的正确性,单元模块之间接口的正确性,全局数据结构测试,单个模块缺陷对整个功能模块的影响,模块之间功能的冲突
集成测试的模式有非渐增式测试模式和渐增式测试模式
非渐增式测试模式:
先分别测试每个模块,再把所有模块按设计要求放在一起结合成所要的程序,如大棒模式;
渐增式测试模式:
把下一个要测试的模块同已测试好的模块结合起来进行测试,测试完以后再把下一个应该测试的模块结合进来测试。
大棒模式:先是对每一个子模块进行测试(单元测试阶段),然后将所有模块一次性的全部集成起来进行集成测试 。
因为所有的模块一次集成的,所以很难确定出错的真正位置、所在的模块、错误的原因。这种方法并不推荐在任何系统中使用,适合在规模较小的应用系统中使用。
渐增式测试有以下组装方法:自顶向下和自底向上,混合策略。
- 自顶向下:从顶层控制(主控模块)开始,采用同设计顺序一样的思路对被测系统进行测试,来验证系统的稳定性。
- 自底向上:从依赖性最小的底层模块开始,按照层次结构图,逐层向上集成,验证系统的稳定性。
- 三明治集成:三明治集成是一种混合增殖式测试策略,综合了自顶向下和自底向上两种集成方法的优点,不需要写桩程序,因为在测试开始自底向上集成已经验证了底层模块的正确性。
自顶向下法的主要优点是:不需要测试驱动程序,能够在测试阶段的早期实现并验证系统的主要功能,而且能在早期发现上层模块的接口错误。
缺点是:需要桩程序,可能遇到与此相联系的测试困难,低层关键模块中的错误发现较晚,而且用这种方法在制早期不能充分展开人力。自底向上法的优缺点与自顶向上法刚好相反。
3.系统测试
系统测试是指从用户角度对系统的功能特性和非功能特性进行测试。
测试阶段:集成测试通过之后
测试对象:整个系统(软、硬件)
测试人员:黑盒测试工程师
测试依据:需求规格说明文档
测试方法:黑盒测试
测试内容:功能、界面、可靠性、易用性、性能、兼容性、安全性等
回归测试
回归测试是指修改了旧代码后,重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。 在整个软件测试过程中占有很大的工作量比重,软件开发的各个阶段都会进行多次回归测试。随着系统 的庞大,回归测试的成本越来越大,通过选择正确的回归测试策略来改进回归测试的效率和有效性是很有意义的。
冒烟测试
冒烟测试的对象是每一个新编译的需要正式测试的软件版本,目的是确认软件主要功能和核心流程正常,在正式进行系统测试之前执行。
冒烟测试一般在开发人员开发完毕后提交给测试人员来进行测试时,先进行冒烟测试,保证基本功能正常,不阻碍后续的测试。
如果冒烟测试通过,则测试人员开始进行正式的系统测试,如果不通过,则测试人员可以让开发人员重 新修复代码直到冒烟测试通过,再开始进行系统测试。
回归测试和冒烟测试都属于系统测试
4.验收测试
验收测试是指在实际用户环境中,验证软件系统功能、性能及其他特性是否符合用户需求,可以采用α测试、β测试。
测试阶段:系统测试通过之后
测试对象:整个系统(包括软硬件)。
测试人员:主要是最终用户或者需求方。
测试依据:用户需求、验收标准
测试方法:黑盒测试
测试内容:同系统测试,包含一些文档,用户使用手册,功能设计文档
五、按实施组织区划分:
1.α测试(Alpha Testing)
α测试指让用户或者除了开发和测试人员之外的公司内部人员到开发现场进行测试;α测试不能由程序员或测试员完成。
2.β测试(Beta Testing)
β测试是软件的多个用户的实际使用环境下进行的测试。是在开发者无法控制的环境下进行的,Beta测试不能由程序员或测试员完成。
α测试与Beta测试的区别:
- 测试的场所不同:Alpha测试是指把用户请到开发方的场所来测试,beta测试是指在一个或多个用户的场所进行的测试。
- Alpha测试的环境是受开发方控制的,用户的数量相对比较少,时间比较集中。beta测试的环境是不受开发方控制的,用户数量相对比较多,时间不集中。
- alpha测试先于beta测试执行。通用的软件产品需要较大规模的beta测试,测试周期比较长。
3.第三方测试
第三方软件测评机构对软件进行测试
六、按是否运行划分:
1.静态测试
静态测试是指对系统需求规格说明书、系统设计规格说明书进行评审,对程序代码进行审查及静态分析等测试活动。
2.动态测试
动态测试通过真正运行程序发现错误,通过观察代码运行过程,来获取系统行为,变量实时结果、内存、堆栈、线程及测试覆盖度等各方面信息,来判断系统是否存在问题。
七、按是否手工划分:
1.手工测试
手工测试就是由人去一个一个的输入用例,然后观察结果,和机器测试相对应,属于比较原始但是必须的一个步骤。
优点:自动化无法替代探索性测试、发散思维结果的测试。
缺点:执行效率慢,量大易错。
2.自动化测试
采用测试工具实现程序驱动替代人驱动所开展的软件测试活动。
自动化测试比如功能测试自动化、性能测试自动化、安全测试自动化。
自动化测试按照测试对象来分,还可以分为接口测试、UI测试等。接口测试的ROI(产出投入比)要比 UI测试高。
手工测试:优点
- 发现缺陷率高,容易实施
- 创造性、灵活性
- 重复测试效率低
- 依赖人力资源
- 测试人员的经验可以继承,对错误有猜测能力
- 测试人员有审美能力和心理体验
- 测试人员有逻辑推断能力
手工测试:缺点
- 无法覆盖代码所有的路径
- 很难捕捉到与时序、死锁、资源冲突、多线程等有关的错误
- 系统负载,性能测试时,无法模拟大量的用户
- 在系统可靠性测试时,要模拟系统运行几年,十几年,以验证系统能否稳定运行,手工测试无法模拟
- 无法实现穷举测试,对于一些关键的程序,如导弹发射软件,则需要考虑利用数学归纳法或谓词演算等进行正确性验证。
自动化测试:优点
- 速度快,效率高。
- 永远不疲惫
- 测试结果准确,可靠
- 可复用性,一旦完成所有的测试脚本,可以一劳永逸地运行很多遍
自动化测试:缺点
- 自动化测试不能取代手工测试
- 手工测试比自动化测试发现的缺陷更多
- 对测试质量的依赖性极大
- 测试自动化不能提高有效性
- 测试自动化可能制约软件开发,自动化测试比手工测试更脆弱,所以维护会受到限制,从而制约软件的开发
八、按地域划分:
1.国际化测试
软件国际化:I18N是借助功能设计和代码实现中软件系统有能力处理多种语言和不同文化,使创建不同语言版本时,不需要重新编写代码的软件工程方法。
2.本地化测试
软件本地化:L10N是将一个软件产品按特定国家/地区或语言市场的需要进行加工,使之满足特定市场上的用户对语言和文化的特殊要求的软件生产活动。