一、测试用例设计
1.测试用例
软件测试贯穿于软件的整个生命周期。
1.1 概念
什么是测试用例?
测试用例(testcase)是为了实施测试而向被测试的系统提供的一组集合,这组集合包含:测试环
境,操作步骤,测试数据,预期结果等要素。(笔试)
【笔试是以excel表格形式编写;面试是说,如以登录页面编写测试用例;工作中用思维导图】

设计测试用例原则一:
测试用例中一个必需部分是对预期输出或结果进行定义
对某一个测试用例,按照测试用例的要素实现用例编写的格式规范:在测试之前还不知道实际结果。
1.2 万能公式
设计测试用例的万能公式:功能测试+界面测试+性能测试+兼容性测试+易用性测试+安全测试
功能测试:从产品功能出发,验证产品功能的正确性
界面测试:肉眼可以看到的都是界面上所有的元素都需要测试,元素(大小、颜色、材质等)
性能测试:通过一些极端的情况测试。软件:高并发、响应时间
兼容性测试:不同版本(软件、系统),浏览器兼容性,数据兼容性
易用性测试:是否具备简单易上手的属性(新手教程)(方法教程)(用户说明书)
安全测试:接口请求参数或者响应,考虑数据的安全性,数据存储的安全性,输入密码要加密显示,SQL注入,越权(垂直、水平)等。如用户的隐私数据:密码、身份证号、银行卡号等,都是以++加密++的形式保存在数据库中
【示例】

除此之外,还有一个比较常用的测试类型:弱网测试、安装卸载测试
构造弱网环境-->fiddler(抓包工具)

2.设计测试用例的方法
软件测试原则

2.1 基于需求的设计方法
需求确定后,测试人员需要根据需求文档来编写测试用例,也是总的设计测试用例的方法。
测试人员接到需求之后,要对需求进行分析和验证,从合理的需求中进一步分析细化需求,从细化的需求中找出测试点,根据这些测试点再去设计测试用例。
【示例--登录页面】

2.2 具体的设计方法
(黑盒测试)
2.2.1 等价类
主要解决了不能穷举的问题;每个等价类是一个集合
依据需求将输入(特殊情况下会考虑输出)++划分为若干个等价类++,从等价类中选出一个测试用例,如果这个测试用例测试通过,则认为所代表的等价类测试通过,这样就可以用较少的测试用例达到尽量多的功能覆盖,解决了不能穷举测试的问题。
等价类分类:
- 有效等价类:对于程序的规格说明书是合理的、有意义的输入数据构成的集合,利用有效等价类验证程序是否实现了规格说明中所规定的功能和性能
- 无效等价类:根据需求说明书,不满足需求的集合。
如设计一个登陆页面需输入6~15位的电子邮箱,在6~15位之间的数就是等价类,而 <6 和 >15 为无效等价类。为此只需要分为三类集合,每个集合测试至少一个即可。
根据等价类设计测试用例的方式:
1.确定有效等价类和无效等价类
2.编写测试用例,设计具体测试数据
2.2.2 边界值
边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充,这种情况下,其测试用例来自等价类的边界。(一般情况下1和2一起使用)
边界值包含:边界值+次边界值,如:[6,15)
2.2.3 正交法
目的是为了减少用例数目,用尽量少的用例覆盖输入的两两组合。
正交表:

因素:输入条件
水平:条件对应的选项
正交表的性质:
- 每一列中,不同的数字出现的次数相等。
- 任意两列中数字的排列方式齐全而且均衡
根据正交表的性质,一般人很难通过手动设计出正交表,
正交法设计测试用例的步骤:
1.找到因素和水平
2.用allparis工具生成正交表
a.将因素和水平写入Excel表格中,如:

b.allparis目录下创建新的文本文件new.txt,复制Excel中的因素和水平,直接粘贴到文本中保存并退出
c.使用allparis命令生成正交表:allparis.exe new.txt>zhengjiao.txt【在pairs所在目录输cmd回车,在终端输入】


(如果使用命令在执行过程中有输出信息,说明test.txt文件格式有问题,需要重新写)
d.打开输出的文件查看正交表,如下:

3.根据正交表编写测试用例
4.补充遗漏的重要测试用例,如下:

【注意】使用 allpairs 工具生成的正交表和实际的正交表有出入,不影响用例的设计。

2.2.4 判定表法
通过具体的方法能够将测试用例设计的更加完整和规范。(表达逻辑判断的工具)
示例:

题目:用户输入的账号中包含admin字符,或者通过内部链接进入注册页面,提交注册按钮成为管理员身份;反之无管理员身份。
设计判定表步骤:
1.找出输出和输入条件
输入条件:包含admin字符(a)、内部链接(b)、提交注册按钮(c)
输出条件:管理员(Y)、非管理员(N)
2.找输入的组合情况和对应的输出

3.生成判定表

4.根据判定表编写测试用例

2.2.5 场景法
现在的软件几乎都是用事件触发来控制流程的,事件触发时的情景便形成了场景,而同一事件不同的触发顺序和处理结果就形成事件流。
通过运用场景来对系统的功能点或业务流程的描述,从而提高测试效果的一种方法。++用例场景来测试需求是指模拟特定场景边界发生的事情,通过事件来触发某个动作的发生,观察事件的最终结果++ ,从而用来发现需求中存在的问题。我们通常以正常的用例场景分析开始,然后再着手其他的场景分析。场景法一般包含基本流和备用流,从一个流程开始,通过描述经过的路径来确定的过程,经过遍历所有的基本流和备用流来完成整个场景。场景主要包括4种主要的类型:正常的用例场景,备选的用例场景,异常的用例场景,假定推测的场景。
【示例】

编写测试用例:
1.输入正确的账号密码,点击注册后系统发出确认邮件并在24H内确认,注册成功。
2.不输入账号密码,点击注册,提示重新输入
3.只输入账号,不输入密码,点击注册,提示重新输入
4......
2.2.6 错误猜测法
错误猜测法是对被测试软件设计的理解,过往经验以及个人直觉,推测出软件可能存在的缺陷,从而针对性地设计测试用例的方法。
这个方法强调的是对被测试软件的需求理解以及设计实现的细节把握,还有个人的经验和直觉。
错误推测法和目前流行的"探索式测试方法"的基本思想一致,这类方法在敏捷开发模式下的投入产出比很高,被广泛应用于测试。
3.场景案例

【更多场景设计测试用例】
3.1 命令行场景
对某个命令来设计测试用例:zip,unzip
zip命令
功能测试:
对不同的文件类型进行测试
1)普通的txt文件能够生成zip文件
2)图片/视频/zip文件能够生成zip文件
3)多个文件能够生成zip文件(混合文件)
4)空文件夹可以生成zip文件
5)错误的命令是否可以解压(zip zip/没有写压缩包文件名称/没有源文件)

3.2 web程序--接口
接口的场景
接口的组成:URL,请求方法,请求参数,请求头,响应数据
接口测试工具:postman


二、测试分类
测试不是单一维度,而是从多个维度保障产品的质量
1.按照测试目标分类
1.1 界面测试
界面测试(简称UI测试),指按照界面的需求(一般是UI设计稿)所展示的全部内容进行测试和检查,一般包括如下内容:
- 验证界面内容显示的完整性,一致性,准确性,友好性。比如界面内容对屏幕大小的自适应,换行,内容是否全部清晰展示;
- 验证整个界面布局和排版是否合理,不同板块字体的设计,图片的展示是否符合需求;
- 对界面不同控件的测试,比如,对话框,文本框,滚动条,选项按钮等是否可以正常使用,有效和
- 无效的状态是否设计合理;
- 界面的布局和色调符合当下时事的发展。
1.2 功能测试
功能测试就是对产品的各功能进行验证,根据功能测试用例,逐项测试,检查产品是否达到用户要求的功能。
根据产品特性、操作描述和用户方案,测试一个产品的特性和可操作行为以确定它们满足设计需求。本地化软件的功能测试,用于验证应用程序或网站对目标用户能正确工作。使用适当的平台、浏览器和测试脚本,以保证目标用户的体验将足够好,就像应用程序是专门为该市场开发的一样。功能测试是为了确保程序以期望的方式运行而按功能要求对软件进行的测试,通过对一个系统的所有的特性和功能都进行测试确保符合需求和规范。
如何进行功能测试?
设计功能测试用例,参考产品规格说明书进行用例的编写 ,具体的测试用例需要使用黑盒设计测试用例的方法,如等价类、边界值、判定表法、正交法、场景法、错误猜测法等。
1.3 性能测试
大量并发功能是否正常,响应时间是否符合预期
我们在使用软件的时候有时会碰到软件网页打开时越来越慢,查询数据时很长时间才显示列表,软件运行越来越慢等问题,这些问题都是系统的性能问题引起的。
要进行软件产品的性能问题,要对产品的性能需求进行分析,然后基于系统的性能需求和系统架构,完成性能测试的设计和执行,最后要进行持续的性能调优。
1.4 可靠性测试
可靠性(Availability)即可用性 ,是指系统正常运行的能力或者程度,一般用正常向用户提供软件服务的时间占总时间的百分比表示。
可靠性=正常运行时间/(正常运行时间+非正常运行时间)*100%
系统非正常运行的时间可能是由于硬件,软件,网络故障或任何其他因素(如断电)造成的,这些因素能让系统停止工作,或者连接中断不能被访问,或者性能急剧降低导致不能使用软件现有的服务等。
可用性指标一般要求达到4个或5个"9",即99.99%或者99.999%

不同的应用系统,可用性的要求是不一样的,非实时性的信息系统或一般网站要求都很低,9%和99.5%就可以了,但是军事系统,要求则很高;
1.5 安全测试
安全性是指信息安全,是指计算机系统或网络保护用户数据隐私,完整,保护数据正常传输和抵御黑客,病毒攻击的能力。
安全性测试属于非功能性测试很重要的一个方面,系统常见的安全漏洞和威胁如下:
- 输入域,如输入恶性或者带有病毒的脚本或长字符串;
- 代码中的安全性问题,如SQL/XML注入
- 不安全的数据存储或者传递
- 数据文件,邮件文件,系统配置文件等里面有危害系统的信息或者数据;
- 有问题的访问控制,权限分配等
- 假冒ID:身份欺骗
- 篡改,对数据的恶意修改,破坏数据的完整性
安全性测试的方法有代码评审,渗透测试,安全运维等,常用的静态安全测试工具有,Coverity,IBMAppscan Source,HPFortify,常用的动态安全测试有OWASP的ZAP,HPWeblnspect等。其中静态安全测试是常用的安全性测试的方法。
1.5 易用性测试
许多产品都应用人体工程学的研究成果,是产品在使用起来更加灵活和,舒适。软件产品也始终关注用户体验,让用户获得舒适,易用的体验,针对软件这方面的测试称之为易用性测试。
用性在ISO25020标准中指容易发现,容易学习和容易使用。易用性包含七个要素:符合标准和规范,直观性,一致性,灵活性,舒适性,正确性和实用性。
2.按照执行方式分类
2.1 静态测试
静态测试即++不实际运行被测软件++ ,而只是静态的检查程序代码、界面或文档中可能存在的错误的过程.
不以测试数据的执行而是对测试对象的分析过程,仅通过分析或检查源程序的设计、内部结构、逻辑、代码风格和规格等来检查程序的正确性。
常见的静态测试方式有代码走查,代码扫描工具等。
2.2 动态测试
动态测试(dynamictesting),指的是实际运行被测程序,输入相应的测试数据,检查实际输出结果和预期结果是否相符的过程,所以判断一个测试属于动态测试还是静态的,唯一的标准就是看是否运行程序。
大多数软件测试工作都属于动态测试
3.按照测试方法
3.1 白盒测试
又称结构测试或逻辑测试,一般用来分析程序的内部结构,针对程序的逻辑结构来设计测试用例进行测试。
目的是通过检查软件内部的逻辑结构,对软件中的逻辑路径进行覆盖测试;在程序不同地方设立检查点,检查程序的状态,以确定实际运行状态与预期状态是否一致。
白盒测试设计测试用例方法:

案例:

3.1.1 语句覆盖
每个语句至少执行一次
测试用例:

3.1.2 判定覆盖
判定语句(if语句):要么为真,要么为假
测试用例:

3.1.3 条件覆盖
测试用例:

3.1.4 判定条件覆盖
结合判定覆盖和条件覆盖
结合目的:将条件覆盖和判定覆盖四个测试用例整合成两个测试用例,即可以提满足条件覆盖,也可以满足判定覆盖,从而达到减少测试用例数量的目的
测试用例:


3.1.5 条件组合覆盖
同一个判定里的条件进行组合。条件是A B C D
测试用例:

(横着,一共四个用例)
3.1.6 路径覆盖


3.2 黑盒测试
黑盒测试就是在完全不考虑程序逻辑和内部结构的情况下,检查系统功能是否按照需求规格说明书的规定正常使用、是否能适当的接收输入数据而输出正确的结果,满足规范需求。
所以,黑盒测试又称之为++数据驱动测试,只注重软件的功能++
黑盒测试的优点:
不需要了解程序内部的代码以及实现,不关注软件内部的实现。
从用户角度出发设计测试用例,很容易的知道用户会用到哪些功能,会遇到哪些问题,锻炼测试人员的产品思维
测试用例是基于软件需求开发文档,不容易遗漏软件需求文档中需要测试的功能。黑盒测试的缺点是不可能覆盖所有代码。
黑盒测试用到的测试方法有,等价类,边界值,因果图,场景法,错误猜测法等
3.3 灰盒测试
测试:单元测试-->集成测试(灰盒测试)-->系统测试(黑盒测试)-->验收测试
灰盒测试,是++介于白盒测试与黑盒测试之间++的一种测试,灰盒测试多用于集成测试阶段,不仅关注输出、输入的正确性,同时也关注程序内部的情况。
但是,灰盒测试没有白盒测试详细和完整,黑盒测试是覆盖产品范围最广的测试,因此灰盒测试基本是不能够替代黑盒测试,否则需要很大的代价,设计非常多的用例。
常见面试题:你知道的测试方法有哪些?哪种用的比较多?
常见的测试方法有黑盒测试,白盒测试和灰盒测试。开发人员主要用白盒测试和灰盒测试,测试人员主要用白盒测试和黑盒测试。对于测试人员来说,相较于白盒测试,黑盒测试用的更多一些
4.按照测试阶段分类
4.1 单元测试
与编码同步进行,针对软件最小组成单元进行测试,主要采用白盒测试方法,从被测试对象的内部结构出发设计测试用例。
最小单元(认为规定的):一个方法,一个类都可以理解为最小单元
4.2 集成测试
把最小单元集成在一起执行测试,用到的方法是灰盒测试
集成测试也称联合测试(联调)、组装测试,将程序模块采用适当的继承策略组装起来,对系统的接口及集成后的功能进行正确性检测的测试工作 。集成++主要目的是检查软件单位之间的接口是否正确。++
- 测试阶段:一般单元测试之后进行
- 测试对象:模块间的接口
- 测试人员:白盒测试工程师或开发工程师
- 测试依据:单元测试的模块+概要设计文档
- 测试方法:黑盒测试与白盒测试相结合
- 测试内容:模块之间数据传输、模块之间功能冲突、模块组装功能正确性、全局数据结构、单模块缺陷对系统的影响
4.3 系统测试
- 对通过集成测试的系统进行整体测试,验证系统功能性和非功能性需求的实现。
- 测试阶段:集成测试通过之后
- 测试对象:整个系统(软、硬件)
- 测试人员:黑盒测试工程师
- 测试依据:需求规格说明文档
- 测试方法:黑盒测试
- 测试内容:功能、界面、可靠性、易用性、性能、兼容性、安全性等
4.3.1 冒烟测试
这一术语源自++硬件++ 行业。对一个硬件或硬件组件进行更改或修复后,直接给设备加电。如果没有冒烟,则该组件就通过了测试。在软件中,"冒烟测试"这一术语描述的是在将代码更改嵌入到产品的源树中之前对这些更改进行验证的过程。在检查了代码后,冒烟测试是确定和修复软件缺陷的最经济有效的方法。冒烟测试设计用于确认代码中的更改会按预期运行,且不会破坏整个版本的稳定性。
冒烟测试的对象是每一个新编译的需要正式测试的软件版本,目的是确认软件主要功能和核心流程正常,在正式进行系统测试之前执行。冒烟测试一般在开发人员开发完毕后提交给测试人员来进行测试时,先进行冒烟测试,保证基本功能正常,不阻碍后续的测试。
如果冒烟测试通过,则测试人员开始进行正式的系统测试,如果不通过,则测试人员可以让开发人员重新修复代码直到冒烟测试通过,再开始进行系统测试。
4.3.2 回归测试
回归测试是指修改了旧代码后,重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。
在整个软件测试过程中占有很大的工作量比重,软件开发的各个阶段都会进行多次回归测试。随着系统的庞大,回归测试的成本越来越大,通过选择正确的回归测试策略来改进回归测试的效率和有效性是很有意义的。
回归测试主要由人工测试和自动化测试进行。
在实际工作中,回归测试需要反复进行,当测试者一次又一次地完成相同的测试时,这些回归测试将变得非常令人厌烦,而在大多数回归测试需要手工完成的时候尤其如此,因此,需要通过自动测试来实现重复的和一致的回归测试。通过测试自动化可以提高回归测试效率。为了支持多种回归测试策略,自动测试工具应该是通用的和灵活的,以便满足达到不同回归测试目标的要求。
4.4 验收测试
针对用户需求,对通过系统测试的软件进行交付性测试,以确定系统是否满足验收标准,由用户或其他授权机构决定是否接受系统。验收测试是部署软件之前的最后一个测试操作。它是技术测试的最后一个阶段,也称为交付测试。验收测试的目的是确保软件准备就绪,按照项目合同、任务书、双方约定的验收依据文档,向软件购买都展示该软件系统满足原始需求。
- 测试阶段:系统测试通过之后
- 测试对象:整个系统(包括软硬件)。
- 测试人员:主要是最终用户或者需求方。
- 测试依据:用户需求、验收标准
- 测试方法:黑盒测试
- 测试内容:同系统测试(功能...各类文档等)
单元测试,集成测试,系统测试,回归测试之间的关系
5.按照是否手工测试
5.1 手工测试(Manual testing)
手工测试就是由人去一个一个的输入用例,然后观察结果,和机器测试相对应,属于比较原始但是必须的一个步骤。
5.2 自动化测试(Automation Testing)
就是在预设条件下运行系统或应用程序,评估运行结果,预先条件应包括正常条件和异常条件。简单说自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。自动化测试比如功能测试自动化、性能测试自动化、安全测试自动化。自动化测试按照测试对象来分,还可以分为接口测试、UI测试等。接口测试的ROI(产出投入比) 要比UI测试高。
5.3 自动化测试和手工测试优缺点

6.按照实施组织划分
大型通用软件,在正式发布前,通常需要执行Alpha和Beta测试
6.1 α测试(Alpha Testing)
α测试又叫内测或者叫a测,其实都是一个涵义
a测试通常是公司内部的用户在模拟实际操作环境下进行的测试。a测试的目的是评价软件产品的FLURPS(即功能、可使用性、可靠性、性能和支持)。α测试不能由程序员或测试员完成。
6.2 β测试(Beta Testing)
B测试又叫公测或者叫b测
β测试由软件的最终用户们在一个或多个场所进行,这里就可以理解为,β测试是正式用户中的一部分,他们在任意的场合来使用软件,目的是为了发现软件是否存在一系列的问题
(通常会发送一些邀请码,来邀请用户参与项目测试)
α测试和β测试区别

6.3 第三方测试
是指由独立的第三方公司或者组织进行的软件测试活动。通过第三方测试,可以确保软件的质量,节省成本,确保软件尽快上线,
7.按照测试地域划分
分为国际化和本地测试
7.1 国际化测试
测试人员需要测试软件在不同语言和地区是否能正常工作
国际化测试需要关注软件的哪些特性:布局、时间、日期、数字格式、货币、机器型号等
7.2 本地测试
【上面内容都是】