软件测试基本理论

基本概念

软件测试的介绍

概念:使用技术手段验证(手工或自动化)软件是否满足需求
在这里插入图片描述

阶段划分:

  • 单元测试

    • 说明:针对程序源代码进行测试(单元:最小独立功能代码段)
    • 提示:
      • 1、国内单元测试一般开发自测
      • 2、单元测试可以解决-快速定位缺陷
      • 3、提高测试执行效率
  • 集成测试

    • 说明:针对单元与单元之间的接口进行测试
    • 提示:又称接口测试。
  • 系统测试

    • 说明:针对系统整体功能+兼容+文档(说明、安装文档)
  • 验收测试

    • 内测:公司内部人员使用,发觉缺陷并修复。
    • 公测:让用户帮忙测试
    • 提示:验收测试,一般要根据项目类型决定是否使用。

在这里插入图片描述

测试原则

1、测试证明软件存在缺陷
2、穷尽测试是不可能的
3、测试尽早进入
4、缺陷集群性
5、杀虫剂悖论(杀虫剂效应)
6、测试活动依赖于测试内容
6、不存在缺陷的谬论

软件生命周期

					立项 - 
					需求分析	(软件需求规格说明书) - 
					设计	(总体设计说明书,详细设计说明书) -
					编码	(用户手册,操作手册,模块开发卷宗) -
					测试	(测试计划,测试用例,测试报告、项目开发总结报告) - 
					发布 运行 维护 	-
					淘汰

软件开发模型

瀑布模型(不适合用户需求变化)
在这里插入图片描述
v模型(测试过程存在不同的等级)
在这里插入图片描述

w模型
在这里插入图片描述

敏捷开发模型
在这里插入图片描述
优点:
敏捷开发的高适应性,以人为本的特性。
更加的灵活并且更加充分的利用了每个开发者的优势,调动了每个人的工作热情。
缺点:
由于其项目周期很长,所以很难保证开发的人员不更换,而没有文档就会造成在交接的过程中出现很大的困难。

质量模型

六大特性:功能性 易用性 安全性 兼容性 效率性 可维护性
在这里插入图片描述
功能性 --需求
易用性 --用户的角度
安全性 –
兼容性 –
效率性 –
可维护性 –

测试流程

需求评审 计划编写 用例设计 用例执行 缺陷管理 测试报告 需求评审
在这里插入图片描述

测试用例

用例编号:项目_模块_编号
用例标题:预期结果(测试点)
模块/项目:所属项目或模块
前置条件:要执行此条用例,有哪些前置操作
优先级:表示用例的重要程度或者影响力p0~ p4 (p0最高)
测试步骤:描述操作步骤
测试数据:操作的数据,没有的话可以为空
预期结果:期望达到的结果

例如:测试qq在这里插入图片描述

黑盒测试:

黑盒测试中运用等价类划分、边界值分析、因果图法、判定表法、正交试验法、功能图法等测试用例设计方法的原理与实现,并从测试设计说明、测试用例说明、测试程序说明三个方面介绍如何编写测试用例。

等价类划分法

概念:
等价类划分法将程序所有可能的输入数据(有效的和无效的)划分成若干个等价类。然后从每个部分中选取具有代表性的数据当做测试用例进行合理的分类。

场景:
针对需要有大量数据测试输入,但是没法穷举测试的地方。(输入框,下拉框,单选复选框)

步骤:
1、明确需求
2、划分有效等价类和无效等价类 (是否满足需求) 注意:有效等价和无效等价各取一个即可
3、提取数据编写用例

原则

  • 1、 若输入条件规定了取值范围或值的个数时,可以确立一个有效等价类和两个无效等价类。 例如:密码的长度必须超过6位小于18位,我们就可以划分为长度在6到18位为一个等价类,长度超过18和小于6的密码分别为两个无效等价类。

  • 2、 若输入条件规定了输入值的集合或者规定了必须遵从某个规则时,可以确定一个有效等价类和无效等价类。
    例如:规定姓名必须由汉字组成,则可以将纯汉字划分为有效等价类,而将非汉字划分为无效等价类。

  • 3、 若输入是一个布尔值,可确定一个有效等价类和一个无效等价类。
    例如:如果登录账号是钻石会员,则在结算时自动享受8折优惠,否则不打折,则钻石会员账号为一个有效等价类,非钻石会员为一个无效等价类。

  • 4、 若规定了输入数据的一组值(假定n个),并且程序要对每一个输入值分别处理,则可以将其输入域划分为n个有效等价类和一个无效等价类。
    例如:电子商务系统中的会员管理,如京东商城,有普通会员、金牌会员、铜牌会员等,不同会员的积分规则和优惠政策不同,故设计测试用例时可划分为若干等价类分别考虑。

  • 5、 若需求规格说明书中规定了输入数据必须遵守的规则的情况下,可以确立一个有效等价类和若干个无效等价类(从不同角度违反规则)。

  • 6、 若确知已划分的等价类中,各元素在程序处理中的方式不同的情况下,则要再将该等价类进一步的划分为更小的等价类。

划分

  • 弱一般等价类测试
    使用最少测试用例覆盖每个有效等价类

  • 强一般等价类测试
    强一般等价类是基于多缺陷假设,强一般等价类的测试用例是要覆盖每个有效等价类取值的笛卡尔积。即在有效等价类取值的所有组合。

  • 弱健壮等价类测试
    在弱一般等价类的基础上,增加取值为无效值的情况。对于无效输入,测试用例将拥有一个无效值,并保持其余的值是有效的。

  • 强健壮等价类测试
    在强一般等价类的基础上,增加取值为无效值的情况。也是运用笛卡尔积思路得出测试用例。

强弱 (是否覆盖所有有效等价类)
一般/健壮 (是否包含无效等价类)
例如:
1、明确需求
在这里插入图片描述
2、划分有效等价类和无效等价类
在这里插入图片描述
3、提取数据编写用例
在这里插入图片描述


边界值分析法

场景:
单个输入类条件的判断

取点:
上点:边界上的点(正好等于)
离点:距离上点最近的点
内点:范围内的点(一般去中间)
注意:最多7个点,但可以优化成5个点:上点2个,内点一个,离点(开内闭外,开区间选内点,闭区间选外点)

步骤:
1、明确需求
2、划分有效等价类和无效等价类
3、确定边界范围
4、提取数据编写用例

例如:
1、明确需求
在这里插入图片描述
2、划分有效等价类和无效等价类
在这里插入图片描述
3、确定边界范围
在这里插入图片描述
4、提取数据编写用例
在这里插入图片描述


判定表法

场景:
条件之间的组合,即输入条件之间的组合影响输出结果。

组成:
条件桩:列出问题中的所有条件,列出条件的次序无关紧要。
动作桩:列出问题中可能采取的操作,操作的排列顺序没有约束。
条件项:列出条件对应的取值,所有可能情况下的真假值。
动作项:列出条件项的、各种取值情况下应该采取的动作结果。

步骤
1、明确需求
2、画出判定表

  • 列出条件桩和动作桩
  • 根据条件项的组合确定动作项
  • 简化、合并相似规则(有相同的动作)

3、根据规则编写测试用例

例如:
1、明确需求
在这里插入图片描述
2、画出判定表
在这里插入图片描述
3、根据规则编写测试用例
在这里插入图片描述

场景法

场景:
根据实际的应用场景,来测试业务用例,可以使用场景法

根据流程图,列举出所有流程,然后制定表格·

例如:
流程图
在这里插入图片描述
流程线:
在这里插入图片描述
用例:
在这里插入图片描述


错误推测法

应用场景:当项目用例都执行完毕,且BUG修复完成,离上线还有一段时间,在这段时间中可是使用错误推荐法复测主要业务或测试未覆盖的功能。
在这里插入图片描述

白盒测试

逻辑覆盖

逻辑覆盖是以程序内部的逻辑结构为基础来设计测试用例的测试技术,通过对程序内部的逻辑结构的遍历来实现程序的覆盖。它属于白盒测试中动态测试技术之一。

语句覆盖:每条语句至少执行一次

判定覆盖:

条件覆盖:

条件/判定覆盖:

条件组合覆盖:

基本路径

缺陷

概念
软件中存在的各种问题,都为缺陷,简称bug;

判断标准

软件未实现需求(规格)说明书中明确要求的功能 【少功能】
软件出现了需求(规格)说明书中指明不应该出现的错误 【功能错误软件】
实现的功能超出需求(规格)说明书指明的范围 【多功能】
软件未实现需求(规格)说明书中虽未明确指明但应该实现的要求 【隐性功能错误】
软件难以理解,不易使用,运行缓慢,用户体验不好 【不易使用】

产生原因

1、需求文档 2、架构设计 3、编码实现 4、环境(硬件、软件)

生命周期

注入bug 发现bug 清除bug

核心要素

在这里插入图片描述

提交要素

在这里插入图片描述

缺陷类型

1、功能错误 2、UI页面错误 3、兼容性 4、数据(数据库)
5、易用性 6、建议 7、架构缺陷

禅道(项目管理工具)

地址:https://demo.zentao.net/user-login.html

  • 22
    点赞
  • 21
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值