为什么需要测试
1.功能可能会存在问题。因此为了保证软件的功能是可用的,我们必须要进行测试。
2.当前的软件件行业已经不在是功能为王了, 户不仅仅只盯着软件的功能是否满足需求, 用
还会对软件是否容易上手,执行效率是否 OK .....等一系列其它体验都有了更高的要求,所以
这也需要我们对软件进行大量的测试。
专业度:软件测试和软件开发分别属于软件行业当中二个不同的技术方向。所以让专人
做专事对于质量更加有保证。
思维定式: 在软件的开发周期中 对于程序员来说他们大多数的时间都是在思考如何实现
具体的软件功能,而不会去从用户的角度考虑如何去"奇葩"的使用这些功能。
软件测试定义:通过手工或者工具对 "被测对象"进行测试操作,从而验证实际结与预期结果之间是否存在差异
所谓的测试原则指的就是我们在执行测试工作时必须要遵守的一些规则。
1.测试证明软件存在缺陷:无论执行什么样的测试操作都保能证明当前软件是有缺陷的。
2.不能执行穷尽测试:有些功能是没有办法将所有的测试情况都逻列出来,所以任何的测
试操作都有结束的时间。
3.缺陷存在群集现象:对于软件功能说,核心功能占 20%,非核心是 80%。在实际工作中
我们会集中测试 20%的核心功能,所以这个部分发现缺陷的几率就会高于 80%。因此我们我
们就会遇到缺陷都集中在 20% 功能模块里的现象。
4.某些测试需要依赖特殊的环境
5.测试应尽早介入:为了更多的发现和更好的解决软件中的缺陷,我们追求测试工作尽早
的开展。
6.杀虫剂现象:同样的一个测试用例不能重的执行多次,因为软件会对它产生免疫。
7.不存在缺陷谬论:任何软件不可能是完美的。
对于当前的测试行业来说我们最经常测试的主体就是 软件( 主体功能 ),但是需要我
们明白是一个软件也不仅仅只有功能需要测试。我们可以将软件分为三个部分组成:功能集
合+使用说明书 + 配置数据。
对于一款软件来说从无到有需要不同的过程,我们可以将这个过程分为不同阶段,然后
每个阶段都会相应有测试对象
1. 需求分析阶段:各种需求规格说明书。
2. 软件架构设计:API 接口文档( 接口测试 )
3. 编码实现阶段:源代码( 白盒测试、单元测试 )
4. 系统功能使用:软件功能主体( 当前行业做的最多的一种测试 )
测试级别
软件的开发都会依据相应的开发模型, 测试级别指的就在这个模型当中我们人为定义 则
的开发步骤。其中对于测试来说我们最常见的一种级别分类如下:
1.单元测试[ UT unit test ]:在软件测试中单元指的就是组成软件最小的底层代码结构,
一般就是类、函数、组件( 当下的软件测试行业,不会刻意要求测试人员对源代码进行测试
2.集成测试( IT system ingertaion test ):将多个单元模块组合在一起,然后验证它们之间
沟通的"桥梁"是否能正常工作( 接口测试 )
3.系统测试( ST system test ):这是当前行业做的最多的一种测试。由测试人员充当用户
然后对软件的功能主体进行测试。
4.验收测试:
(1) a测试 ---- 内测
(2) b测试 -----公测
(3) UAT( user acceptance test )测试---- 由客户派出对于业务非常精通的人员来使
用该软件,从而对功能进行测试。
(4) 验收测试的核心就是让用户为当前软件 "买单"
系统测试分类
1. 功能测试:验证当前的软件主体功能是否可用。
2. 兼容性测试:验证当前软件在不同的环境下是否还可以使用。
3. 安全测试:验证软件是否只是能授权用户提供功能使用。
4. 性能测试:相对于当前软件消耗的资源 它的产出能力。
按测试对象进行分类
1.白盒测试:这种测试的主体就是软件的底层代码,不会在意外在的界面是否 OK ,只要
求底层功能实现,同时逻辑正确。
2.黑盒测试:这种测试就是指测试软件外在主体功能是否可用。
3.灰盒测试:介于二者之间( 接口测试 )
4.上述三种方法当中的 "盒" 指的就是被测对象。
二、按测试对象是否执行分类
1.静态测试:指的就是测试不执行。
2.动态测试:将软件运行在真实的使用环境中进行测试。
三、按测试手段进行分类
1.手工测试:由测试人员手动的对被测对象进行验证,优点就是可以灵活的改变测试操作
及环境。
2.自动化测试:所谓自动化主要有二种形,一种是自已写测试脚本,另外一种就是通过第
三方的工具对被测对象进行测试。优点就是可以高效率的去执行一些人工无法实现的操作。(可以承受多少用户服务)
描述当前软件是否好用,在当前的软件行业里我们所采用的一套标准是基于 ISO 组织制定
1. 功能性:软件需要满足用户显式或者稳式的功能。
2. 易用性:软件易于学习 和上手使用。
3. 可靠性:指的就是软件必须实现需求当中指明的具体功能。
4. 效率性:类似于软件的性能。
5. 可维护性:要求软件具有将某个功能修复之后继续使用的能力。
6. 可移植性:当前软件可以从一个平台移植到另一个平台上去使用的能力。
软件测试流程
1. 需求分析
(1) 当前阶段的核心目的就是梳理清楚我们需要设计的点是什么。
(2) 需求的来源:需求规格说明书、API 文档、竟品分析、个人经验
2. 设计用例:
(1) 用例就是用户为了测试软件的某个功能而执行的操作过程。
(2) 设计用例是有方法的( 等价类、边界值、判定表...... )
3. 评审用例:对当前的用例进行添加或者删除。
4.环境配置
(1) 环境:指的就是当前被测对象运行所需要的执行环境,做为测试人员需要具备配环
境的能力。【 一般情况下都会使用一键安装的集成环境 】
(2) 环境分类:操作系统 + 服务器软件 + 数据库 + 软件底层代码的执行环境。
5. 执行用例
(1) 一般在执行用例之前我们会做一个冒烟测试。 种测试的核心就是快速的对当前软 这
件的核心功能或者主体执行流程进行验证。如果冒烟测试阶段有问题,则可以将此
版本回退给开发。
(2) 如果冒烟测试通过那么才会开展示全面的测试。
6. 回归测试及缺陷跟踪
(1) 回归测试指的就是当我们将某个缺陷提交给开发之后,由它们进行修复,修复完成
之后需要测试认员再次对其进行测试【回归测试】
(2)缺陷跟踪:指的就是当测试人员发现某个缺陷之后需要一直对其进行状态的跟踪。
7. 输出测试报告
将当前的测试过程中产生的数据进行可视化的输出。方便其它人去查看。
8. 测试结束
当将整个测试过程中产生的一些文档进行整理归档,方便后续版本使用。
一、开发模型—瀑布模型
优点:开发阶段,各个阶段比较清晰;强调早期计划及需求调查;适合稳定需求的产品开发;
改良:每个阶段都可以融入小的迭代工作!
二、开发快速原型模型
实现一个基本原型,让用户对原型进行评价,逐步调整,使其满足用户最终需求;
优点:适合不能确定需求的软件;
缺点:不适合开发大型系统。
三、测试v模型
需求分析、概要设计、详细设计、编码、单元测试、集成测试、系统测试、验收测试;
- 单元测试:又称模块测试,针对单一的程序模块进行的测试
- 集成测试:又叫组装测试,在单元测试的基础上,对所有模块进行测试。
- 系统测试:将整个软件看做一个整体来进行测试,包括功能、性能、兼容性
- 验收测试:
(1)、内测版(alpha)内部交流版本,可能存在很多bug,不建议用户安装。
(2)、公测版(beta)面向所有用户,通过用户的反馈再去修改细节。
(3)、候选版(gamma)与正式软件相差无几。
四、测试v模型优缺点
1、优点:包含了底层测试(单元测试)和高层测试(系统测试);清楚的标识了开发和测试的各个阶段;自上而下逐步求精,每个阶段分工明确,便于整体项目的把控。
2、缺点:自上而下的顺序导致了,测试工作在编码之后,就导致错误不能及时的进行修改;实际工作中,需求经常变化,导致v模型步骤,反复执行,返工量很大,灵活度较低。
改良:每个步骤都可以进行小的迭代工作。
五、w模型
优点:开发和测试伴随着整个开发周期,需求和设计同样要测试;更早的介入测试,可以发现初期的缺陷,修复成本低;分阶段工作,方便项目整体管理。
缺点:开发和测试依然是线性的关系,需求的变更和调整,依然不方便;如果没有文档,根本无法执行w模型;对于项目组成员的技术要求更高!
定义:开发一个v;测试一个v组合起来的模型(w模型也叫双v模型)
总结:v模型适用于中小企业,w模型适用于中大型企业(因为人员要求高),h模型人员要求非常高,很少有公司使用。
六、黑盒测试
又称数据驱动测试,完全不考虑从内部机构和特性,值注重软件的功能需求(不管代码)
七、白盒测试
把盒子打开研究里面的程序结构和源代码;
八、黑盒测试分类
一、功能测试:
1、逻辑功能测试
2、界面测试
3、易用性测试
4、安装测试
5、兼容性测试
二、性能测试:
九、随机测试
针对重要功能、新增加的功能、特殊情况、以前发现过重大bug的模块进行二次测试;也叫探索测试,它可以结合回归测试来使用;
十、软件测试分类:
1、按测试阶段划分:单元测试、集成测试、系统测试
2、是否覆盖源代码:
(1)白盒测试
(2)黑盒测试:1、功能测试 2、性能测试
3、是否运行:静态测试(不运行程序)、动态测试(运行程序)
4、其它:1、回归测试 2、冒烟测试 3、随机测试 4、验收测试(内测、公测、候选版)
5、是否自动化:1、人工测试 2、自动测试
十一、测试用例
测什么?怎么测?
十二、等价类划分法
属于黑盒测试,它将不能穷举的测试过程进行分类,从而保证完整性和代表性;
思考步骤:
- 确定有效等价类和无效等价类
- 有效等价类划分(题目条件,还要注意边界值(极值),中间再随意找个值)
- 无效等价类划分(跟有效等价类相反,其它特殊情况(中文、英文、特殊符号、空格、空))
注意:两个框要一个正确,一个错误,这样才能准确的判断;一定要根据需求来判断预期结果;
十三、等价类细节
- 考虑输入长度
- 考虑输入类型
- 组成规则
- 是否为空
- 是否区分大小写
- 是否重复
- 是否去除空格
某城市电话号码由三部分组成,分别是
地区码:空白或是3位数字
前缀:非‘0’且非‘1’开头的三位数字
后缀:4位数字
-用户名(昵称)长度为 3-19:以字母开头
-登录名称:非空
-密码: 非空
什么是边界?
边界是指对于输入等价类和输出等价类而言,稍高于其边界值及稍低于其边界值的一些特定情况。
边界值分析法也是一种常用的黑盒测试方法。
大量的错误是发生在输入或输出范围的边界上,而不是在输入范围的内部。
•修改手机银行登录密码
密码必须由字母与数字组合,密码长度在8~24之间(包含8和24)
–等价类划分法和边界值分析方法都是着重考虑输入条件,但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了,但多个输入条件组合起来可能出错的情况却被忽视了。
- 判定表
根据因果图来制作判定表(因果图可以不画)
组成部分:
- 条件桩:所有条件
- 动作桩:所有结果
- 条件项:针对条件桩的取值
- 动作项:针对动作桩的取值
书写步骤:
- 列出所有条件和动作桩
- 填写条件和动作桩中的项目
- 简化判定表
注意:如果出现“-“代表此选项不影响最终结果。
|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
条件桩 | 学习好 | 1 | 1 | 0 | 1 | 0 | 1 | 0 | 0 |
品德好 | 1 | 0 | 1 | 1 | 0 | 0 | 1 | 0 | |
遵纪守法 | 1 | 1 | 1 | 0 | 1 | 0 | 0 | 0 | |
动作桩 | 好学生 | Y | Y | Y |
|
|
|
|
|
坏学生 |
|
|
| Y | Y | Y | Y | Y |
- 场景法
主要用来测试业务流程;分为基本流(正确流程)和备选流(错误流程)
注意:还要补充一些异常情况;
在冒烟测试中主要采用场景法来测试;
用例 编号 | 场景/条件 | 账号 | 密码 | 预期结果 |
01 | 输入正确的账号和密码后点击“登录”按钮 | Y | Y | 程序正常登陆 |
02 | 输入正确的账号,错误的密码后点击“登录”按钮 | Y | N | 程序应给出错误提示
|
03 | 不输入账号和密码,直接点击“登录”按钮 | (空) | (空) | 程序给出错误提示“请您输入账号后登陆” |
04 | 输入正确的账号,不输入密码,点击“登录”按钮 | Y | (空) | 程序应给出错误提示 |
05 | 不输入账号,输入密码,点击“登录”按钮 | (空) | Y | 程序应给出错误提示 |
06 | 输入错误的账号和密码,点击“登录”按钮 | N | Y | 程序应给出错误提示 |
- 流程分析法
适用于有先后顺序的测试;常用于业务流程、安装流程等等。每个流程就是一条测试用例,它只是在测试整体流程是否正确,细节还需要使用等价类、边界值等方法进行完善;
•第一步:详细了解需求;
•
•第二步:根据需求说明或界面原型,找出业务流程的各个页面以及各页面之间的流转关系;
•
•第三步:画出业务流程(产品经理使用Axure软件制作);
•
•第四步:写用例,覆盖所有的路径分支。
- 错误推断法
凭着直觉和经验来设计测试用例,它是根据之前项目相关的bug数据总结来的;
- 正交表
从全面试验中挑选出有代表性的点进行测试(均匀分散,整齐可比);高效率、快速、经济的方法;
- 正交表使用方法
- 根据控件和取值数选择一个合适的正交表
- 列举取值并编号,生成取值表
- 把取值表与选择的正交表进行映射
- 混合正交表工具
在实际工作中,很多情况都是因素(控件个数)和水平(每个控件的可选个数)不同,我们在现成的正交表中找不到对应的表格,此时我们就需要使用混合正交表工具来生成混合正交表;
使用步骤:
- 制作取值表(不需要编号,列出数据即可)
- 复制表格中的数据放在一个新建的txt文本文档中,保存到allpairs文件夹中(例如:test2.txt)
- Win+r再输入cmd进入控制台界面
- 使用控制台代码进入allpairs文件夹中(例如: e: 回车 cd 复制文件夹路径 回车)
- 再输入allpairs.exe test2.txt>chenggong.txt (test2.txt是我们刚新建的文件,chenggong.txt是我们最终生成出来的正交表文件)
、