软件测试:测试分类
一. 按照测试对象划分
1.1 界面测试
界面测试(简称UI测试),按照界面的需求(UI设计稿)和界面的设计规则,对我们软件界面所展示的全部内容进行测试和检查,一般包括如下内容:
• 验证界面内容的完整性,一致性,准确性,友好性,兼容性.比如页面内容对屏幕大小的自适应,换行,内容是否全部清晰展示.
• 验证整个界面布局和排版是否合理,不同板块字体的设计,图片的展示是否符合需求
• 对界面不同控件的测试,比如,对话框,文本框,滚动条,选项按钮等是否可以正常使用,有效和无效的状态是否设计合理.
• 界面的布局和色调符合当下时事的发展.
• 重叠,截断,文字不合理自动换行等.
1.2 可靠性测试
可靠性即可用性,是指系统正常运行的能力或者程度,一般用正常向用户提供软件服务的时间占总时间的百分比表示
可靠性=正常运行时间/(正常运行时间+非正常运行时间)*!00%
对于可靠性测试,需要借助工具,编写一些脚本,让这些脚本自动运行,自动运行完之后会有报告,人只需要看报告,总结结果.
1.3 容错性测试
容错性测试是指系统能够处理异常,用户的错误操作而不至于系统崩溃,从而能够提高系统的可用性.
• 输入异常数据或进行异常操作,以检验系统的保护性.如果系统的容错性好,系统只给出提示或内如消化掉,而不会导致系统出错甚至崩溃.(例如除法计算器:2/0 , 代码报异常了,不会异常,这对这些异常进行处理(除数不能是0))
• 灾难恢复性测试。通过各种手段,让软件强制性地发生故障,然后验证系统已保存的用户数据是否丢失,系统和数据是否能尽快恢复。
1.4 兼容测试
兼容性测试需求是指明确要测试的兼容环境,考虑软,硬件的兼容,就软件兼容来说,主要考虑一下几个方面:
• 系统自身版本的兼容,用户已有数据的兼容,数据兼容是重中之重,对于用户来说,数据是最有价值的。
• 测试与应用环境的兼容性,比如操作系统,应用平台,浏览器的兼容
• 测试与第三方系统以及第三方数据的兼容性
• 新版本和旧版本的兼容性,新版本添加新功能时,对旧版本回归测试
对于环境(操作系统,应用平台)兼容性的测试不仅仅局限在操作系统,浏览器这两个因素,还包括以下,32,64位CPU;手机平台Android,IOS,Windows, Phone;支持不同的Internet连接速度。
对于IOS 和Android 两个平台,还要区分手机和平板电脑,考虑不同的型号(屏幕尺寸,分辨率等)
1.5 易用性测试
软件设计符合大众审美
颜色和标识符合尝试,避免反人类设计。
软件使用灵活
软件见明知意
1.6 安装卸载测试
• 软件不同的安装和卸载方式
• 应用是否可以在不同的系统,版本下安装(安装兼容性)
• 安装或者卸载过程中给是否可以手动暂停,或者取消
• 安装空间不足的时候是否有提示
• 是否可以正常的卸载
• 卸载和安装过程中出现环境问题,软件是否可以正常并且合理的应付,比如死机,断电,断网等。
1.7 安全性测试
安全性是指信息安全,计算机系统或网络保护用户数据隐私,完整,保护数据正常传输和抵御黑客,病毒攻击的能力。安全性测试属于非功能性测试很重要的一个方面,系统常见的安全漏洞和威胁如下:
• 输入域,如输入恶行或者带有病毒的脚本或长字符串;
• 代码中的安全性问题,如SQL/XML注入
• 不安全的数据存储或者传递
• 数据文件,邮件文件,系统配置文件等里面有危害系统的信息或者数据
• 有问题的访问控制,权限分配
• 假冒ID:身份欺骗
• 篡改,对数据的恶意修改,破坏数据的完整性
1.8 性能测试
我们在使用软件的时候,有时会碰到软件网页打开时越来越慢,查询数据时很长时间才显示列表,软件运行越来越慢等问题,这些问题都是系统的性能问题引起的。
常见的性能问题如下:
• 资源泄露
• 资源瓶颈
• 线程死锁,线程阻塞
• 查询速度慢或效率低
• 收外部系统影响越来越大(需要解耦)
1.9 内存泄露测试
• 分配完内存之后忘了回收
• 程序写法有问题,造成没办法回收(如死循环造成无法执行到回收步骤)
• 某些API函数的使用不正确,造成内存泄漏。
内存泄漏的检测方法
人工静态法:代码走读,人工查找未被回收的内存。
自动工具法:借助相应测试工具测试内存泄漏的工具。如Visual Leak Detector, 记录每次内存分配,清楚告诉用户是如何泄漏的。
二. 按照是否查看代码划分
2.1 黑盒测试
黑盒测试的优点:
• 不需要了解程序内部的代码以及实现,不关注软件内部的实现
• 从用户角度出发设计测试用例,很容易的知道用户会读到哪些功能,会遇到哪些问题,锻炼测试人员的产品思维。
• 测试用例是基于软件需求开发文档,不容易遗漏软件需求文档中需要测试的功能。
黑盒测试的缺点是不可能覆盖所有代码。
2.2 白盒测试
白盒测试又称为结构测试或者逻辑测试,它一般用来分析程序的内部结构,针对程序的逻辑结构来设计测试用例进行测试。
白盒测试的目的是,通过检查软件内部的逻辑结构,对软件中的逻辑内容进行覆盖测试;在程序不同地方设立检查点,检查程序的状态,以确定实际运行状态与预期状态是否一致。
白盒测试可以提高代码的覆盖率
2.2.1 语句覆盖
语句覆盖要求设计若干个测试用例,使得程序中的每个可执行语句至少都能被执行一次。
首先可能想到的是,可以设计两个测试用例,分别覆盖第一个if结构有执行的语句③和第二个if结构有执行语句的分支④.
case1: x=20,y=20;
case2: x=-1,y=-1.
这样即可达到语句的覆盖要求,但可以优化一下测试的设计用例,实际上只需要一个测试用例,即:
case3: x=4,y=4
2.2.2 判定覆盖
是程序中每个判断的真值结果和假值结果都至少出现一次.
判定覆盖表:
2.2.3 条件覆盖
条件覆盖要求判断表达式中的每个条件都要至少取得一次真值和一次假值
2.2.4 判定条件覆盖
是判定表达式中的每个条件的真/假取值至少都出现一次,并且每个判定表达式自身的真/假取值也都要至少出现一次.
2.2.5 条件组合覆盖
条件组合覆盖也叫多条件覆盖,它是要设计足够多的测试用例,使每个判定中条件取值的各种组合都至少出现一次.
2.3 灰盒测试
回合测试,是介于白盒测试与黑盒测试之间的一种测试,灰盒测试多用于集成测试阶段,不仅关注输出,输入的正确性,同时也关注程序内部的情况.
三.按开发阶段划分
3.1单元测试
单元测试是对软件组成单元进行测试,其目的是检验软件基本组成单位的正确性.测试的对象是软件设计的最小单位: 模块.又称为模块测试.
• 测试阶段: 一般单元测试之后
• 测试对象: 模块之间的接口
• 测试人员: 白盒测试工程师或开发工程师
• 测试依据: 单元测试的模块+概要设计文档
• 测试方法: 黑盒测试与白盒测试相结合
• 测试内容: 模块之间数据传输,模块之间功能冲突,模块组装功能正确性,全局数据结构,单模块缺陷对系统的影响.
3.2 系统测试
将软件系统看成是一个系统的测试,包括对功能,性能以及软件的软硬件环境进行测试.
• 测试阶段: 集成测试通过之后
• 测试对象: 整个系统
• 测试人员: 黑盒测试工程师
• 测试依据: 需求规格说明书
• 测试方法: 黑盒测试
• 测试内容: 功能,界面,可靠性,易用性,性能,兼容性,安全性等
3.3 回归测试
回归测试是指修改了代码后,重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误
3.4 冒烟测试
冒烟测试的对象是每一个新编译的需要正式测试的软件版本,目的是确认软件主要功能和核心流程正常,在正式进行系统测试之前执行.冒烟测试一般在开发人员开发完毕后提交给测试人员来进行测试时,新进行冒烟测试,保证基本功能正常,不阻碍后续的测试.
如果冒烟测试通过,则测试人员开始进行正式的系统测试,如果不通过,则测试人员可以让开发人员重新修复代码直到冒烟测试通过,再开始进行系统测试.
四. 按测试实施组织
4.1 α测试
α测试是由一个用户在开发环境下进行测试,也可以是公司内部的用户在模拟实际操作环境下进行的测试,α测试的目的是评价软件产品的FLURPS(即功能,局域化,可使用性,可靠性,性能和支持).
4.2 β测试
β测试是一种验收测试,β测试由软件的最终用户们在一个或多个场所进行.
α测试与β测试的区别:
• 测试的场所不同: α测试是指把用户请到开发方的场所来测试,β测试是指在一个或多个用户的场所进行的测试
• α测试的环境是受开发方控制的,用户的数量相对比较少,时间比较集中,β测试的环境是不受开发方控制的,用户数量相对比较多,时间不集中
• α测试先于β测试执行.通用的软件产品需要较大的规模的β测试,测试周期比较长.