划分测试类型

  • Post author:
  • Post category:其他



目录


按照测试对象划分


界面测试(UI测试)


可靠性测试


容错性测试


文档测试


兼容性测试


易用性测试


安装卸载测试


安全测试


性能测试


内存泄漏测试


按照是否查看代码划分


黑盒测试


白盒测试


灰盒测试


按开发阶段来分(结合软件测试V模型学习)


测试金字塔


单元测试


集成测试


系统测试


回归测试


冒烟测试


验收测试


按照实施组织划分


α测试


β测试


第三方测试


按照是否运行划分


静态测试


动态测试


按照是否手工划分


手工测试


自动化测试


按照地域划分


软件国际化测试


软件本地化测试


按照测试对象划分

界面测试(UI测试)

界面是直接和用户交互的,界面设计的好坏,决定了用户使用软件的直观感受。

  • 保证界面设计和UI设计稿一致性,正确性;
  • 测试界面的每一个功能的正确性;(从上到下,从左到右)
  • 界面的布局排版合理。字体,图片布局,清晰程度等;
  • 界面的控件是否正常。滚动条,按钮,文本框等;
  • 要进行界面不同大小时,界面的分辨排版;(同一个web页面不同页面大小下测试,页面从小到大变化的过程中衔接丝滑,字体不模糊不消失,图片不消失,排版布局合理,页面功能正常使用)

可靠性测试


可靠性=正常运行时间 /(正常运行时间+非正常运行时间)

一般软件,可靠性要求99.99%,一年时间,软件出现故障的时间52min;

特殊软件,比如军用系统99.999%,一年5min;

软件可靠性影响因素:软件本身可控,外界因素不可控(电,网络,灾难)

如果是因为硬件原因发生故障使得软件系统无法正常运行,这个时间是否计算到软件可靠性里?

答:客户端硬件原因(比如手机坏了),这个是不算的。但是如果是部署的服务器硬件故障,是算的。有的公司可能是分开讨论的,硬件可靠性和软件可靠性。

容错性测试

容错性:系统因为自身或者外部一些异常的操作使得系统发生异常,系统能够自行处理这种错误操作或者异常的能力(不让用户感知到)。

容错性测试包括两方面:


  • 输入异常数据或者进行异常操作,以检验系统的保护性。

    如果系统的容错性好,系统只给出提示或者内部消化,而不会导致系统出错甚至崩溃。                                                  温柔的容错性测试通常是

    构造不合理的输入来引诱软件出错

    。粗暴一些的容错性测试俗称“大猩猩”测试,处理不能拳打脚踢嘴巴咬,什么招式都可以用。

  • 灾难恢复性测试。

    通过各种手段,让软件强制故障,然后验证系统已保存的用户数据是否丢失,系统和数据是否能尽快恢复。

文档测试


对整个开发过程中产生的各种文档进行测试。

国家有关计算机软件产品开发文件编制指南中共有14 种文件,可分为3 大类。

–开发文件:可行性研究报告、软件需求说明书、数据要求说明书、概要设计说明书、详细设计说明书、数据库设计说明书、模块开发卷宗。

–用户文件:用户手册、操作手册,用户文档的作用:改善易安装性;改善软件的易学性与易用性;改善软件可靠性;降低技术支持成本。

–管理文件:项目开发计划、测试计划、测试分析报告、开发进度月报、项目开发总结报告。


对比软件功能,测试软件的正确性,一致性,完整性,专业术语。

兼容性测试

兼容性:主要是指软件之间是否能很好的运作,会不会有影响,软件和硬件之间能否发挥高效率的工作,会不会影响导致系统崩溃。

  • 平台兼容性(web网页:各种浏览器,操作系统的兼容性;APP:不同系统IOS/安卓,不同系统版本)
  • 软件本身兼容性:软件本身功能前后的兼容性,比如新功能不能影响老功能;
  • 软件对用户数据的兼容性:比如数据库中某一张表增加字段,不能影响用户之前的数据存储;
  • 软件对第三方软件的兼容性:不能影响其他软件的使用;如果和第三方软件有交互,数据要有兼容性;

易用性测试

易用性(Useability)是交互的适应性、功能性和有效性的集中体现。易用性属于人体工程学的范畴,人体工程学(ergonomics)是一门将日常使用的东西设计为易于使用和实用性强的学科。

用户使用软件的体验,用户体验测试。

  • 符合标准和规范
  • 直观性
  • 灵活性(比如手机上的键盘九宫格全键盘手写等,灵活性==复杂性,两者间找一个平衡点)
  • 舒适性(让用户对自己进行的操作有感知,不产生焦虑情绪。比如安装一个进度条)
  • 实用性

安装卸载测试

软件可以正常安装和卸载。

软件更新。(安装软件时断网断电,死机等异常情况下,软件的响应。安装软件内存不足是否有提示。)

安全测试

安全测试是一个相对独立的领域,需要更多的专业知识。

例如web的安全测试,需要熟悉各种网络协议TCP\HTTP,防火墙,CDN,熟悉各种操作系统的漏洞,熟悉路由器等。

从软件来说,熟悉各种攻击手段,例如SQL注入,Xss,防黑客,防爬虫等。

性能测试


检查系统是否满足软件需求规格说明书中规定的性能。

  • 对资源利用进行的精确度量;
  • 对执行间隔;
  • 日志时间(如 中断,报错)
  • 响应时间
  • 吞吐量
  • 辅助存储区()

内存泄漏测试

很多软件系统都存在内存泄漏的问题,尤其是缺乏自动垃圾回收机制的语言编写的程序。

从用户的角度来看,内存泄漏本身不会造成什么危害,一般用户可能根本不会感受到内存泄漏,但内存泄漏是会积累的,只要执行的次数够多,最终会耗尽所有的可用内存,使软件的执行越来越慢,最后停止响应,可以把这种软件的问题比喻成软件的“慢性病”。


内存泄漏:可积累的错误。

造成内存泄漏的原因:

  • 分配完内存之后忘了回收;
  • 程序写法有问题,造成内存无法回收(比如死循环造成无法执行到回收步骤)
  • 某些API函数的使用不正确,造成内存泄漏

内存泄漏的检测方法:

  • 人工静态发:代码走读,人工查找未被回收的内存;
  • 自动工具法:借助响应测试内存泄露的工具,记录每次内存的分配,清除告诉用户内存是如何泄露的。

按照是否查看代码划分

黑盒测试

黑盒测试就是不关心软件内部代码的实现,

不关心代码的逻辑结构

(相当于代码这一部分是看不见的),

只关心输入输出是否符合预期

黑盒测试的好处:

  • 不用看代码(不懂代码的也可以进行测试);
  • 黑盒测试测试系统的功能,站在用户的角度去使用功能,有利于培养用户思维;(产品经理)
  • 黑盒测试的测试用例是按照需求设计的,不容易遗漏需求;



黑盒测试设计测试用例的方法有哪些?

等价类,边界值,因果图,场景法,错误猜测法,正交法;

白盒测试

白盒测试就是针对代码进行测试,分析和测试代码的逻辑结构,实现的功能,看看是否符合用户的需求。

  • 语句覆盖
  • 路径覆盖:if else try catch finally switch case
  • 判定覆盖 :TT TF FT FF
  • 条件覆盖:无穷尽,用等价类边界值
  • 判定组合覆盖
  • 条件组合覆盖
  • 判定和条件组合覆盖

灰盒测试

介于白盒测试与黑盒测试之间的一种测试,灰盒测试多用于集成测试阶段,不仅关注输出、输入的正确性,同时也关注程序内部的情况。

按开发阶段来分(结合软件测试V模型学习)

测试金字塔

  • UI界面层:功能验证测试,兼容性与用户测试;
  • 业务逻辑层:客户端模拟测试,内外接口测试,SDK接口测试;
  • 数据处理层:单元测试,组件测试;

单元测试

针对软件组成的最小单元模块进行测试(类,方法),目的是检验软件 基本组成单位的正确性。测试的对象是软件设计的最小单位:模块。又叫模块测试。

  • 测试阶段:编码前,编码后;
  • 测试对象:组成软件的最小模块;
  • 测试方法:白盒测试;
  • 测试人员:白盒测试工程师或开发人员;
  • 测试依据:详细设计文档(软件测试V模型);
  • 测试内容:模块的接口,


    局部数据的结构测试


    ,边界测试,异常测试,路径测试,容错性测试;

集成测试

按照一定的策略把单元模块组合起来形成一个大的功能模块,对这个大的功能模块进行的测试叫集成测试。集成主要目的是检查软件单位之间的接口是否正常。

  • 测试阶段:单元测试之后
  • 测试对象:集成模块
  • 测试方法:灰盒测试
  • 测试依据:概要设计文档(V模型)
  • 测试人员:黑盒测试工程师,开发人员
  • 测试内容:整个模块功能的正确性,组成整个模块的单元模块之间接口的正确性,


    全局数据结构测试


    ,测试单个模块的缺陷对整个功能模块的影响,模块之间功能的冲突;

系统测试

当软件开发完成,系统的全面的对软件进行测试。包括对功能,性能,软件运行的软硬件环境。系统测试包括回归测试和冒烟测试。

  • 测试阶段:集成测试通过之后;
  • 测试对象:整个软件系统(软件,硬件);
  • 测试人员:黑盒测试工程师;
  • 测试依据:需求规格说明文档;
  • 测试方法:黑盒测试;
  • 测试内容:功能,界面,可靠性,易用性,安全性,兼容性,容错性,内存泄漏等;

回归测试

当系统引入了新的代码(修改了旧的代码)时,要查看新的代码是否影响了旧的功能,进行回归测试。

回归测试基本上是自动化回归测试,大幅度降低系统测试,维护升级等阶段的成本。

冒烟测试

正式测试之前,对软件系统的基本流程和核心功能进行测试,如果测试通过,才同意正式测试。

冒烟测试一般在开发人员开发完毕后送给测试人员来进行测试时,测试人员会先进行冒烟测试,保证基本功能正常,不阻碍后续的测试。

验收测试

软件上线前的最后一道测试,由用户或者产品经理发起的,是技术测试的最后一个阶段,也叫交付测试。目的是确保软件准备就绪,按照项目合同,任务书,双发约定的验收依据文档,向软件购买都展示该软件系统满足原始需求。

  • 测试阶段:系统测试之后
  • 测试对象:整个系统(软硬件)
  • 测试人员:用户,需求方;
  • 测试方法:黑盒测试;
  • 测试依据:V模型的用户需求,验收标准;
  • 测试内容:同系统测试(包括一些文档,用户使用手册,功能设计文档);

白盒测试怎么去测试某一个单元模块?

Java测试框架:Junit

按照实施组织划分

α测试

指的是

让用户或者除了开发和测试人员以外的公司内部人员

,到开发现场,去进行测试。

  • 测试环境:开发环境

β测试

实际用户在实际使用环境下进行测试,不限时间不限地点。

  • 测试环境:面向用户使用的环境

α测试和β测试区别:测试环境不同,时间集中程度不一样,α测试是优先于β测试的。

第三方测试

第三方软件测评机构对软件进行测试。介于开发方和用户方之间的组织的测试。

按照是否运行划分

静态测试

不运行代码,分析代码风格,是否符合公司的标准规范,分析代码的结构,逻辑,算法,方法的实现是否满足用户的需求。

只能看代码。

静态质量:度量所依据的标准是ISO9126。在该标准中,软件的质量用以下几个方面来衡量,即功能性(Functionality)、可靠性(Reliability)、可用性(Usability)、有效性(Efficiency)、可维护性(Maintainability)、可移植性(Portability)。

动态测试

通过运行代码进行测试,检查运行结构和预期结果差异,执行测试用例进行测试。

按照是否手工划分

手工测试

手工执行测试用例,查看测试结果。属于比较原始但是必须的一个步骤。

  • 缺点:量大容易出错,效率比较低;
  • 优点:

    不可替代的

    ,无法被自动化测试替代,手工测试的过程是人为可控的,

    有利于做探索性测试;

自动化测试

系统按照预先设定好的条件去执行测试,这些条件包括正常和异常的方面。

简单说自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。

哪些项目不适合自动化测试?

自动化的价值和意义:节省人力。自动化脚本运行运用率越高,越有价值。

自动化不适合于:项目不稳定,功能频繁变动的项目。

按照地域划分

软件国际化测试

开发软件时,使用了一种工程技术,使得软件在适应不同国家的语言,风俗使用习惯的时候不用去改变软件的源码就可以做到。(windows操作系统,微博国际版,Microsoft office word)

软件本地化测试

之前的全是本地化测试。



版权声明:本文为qq_51263139原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。