-
软件的生命周期
-
问题的定义及规划
-
需求分析
-
软件设计
-
程序编码
-
软件测试
-
系统环境转换
-
运行维护
-
?
-
什么是软件测试
-
定义:软件质量保证的一种手段
-
目的:发现错误以及避免这些错误的发生,使产品达到完美
-
概念:是软件工程中的一个非常重要的环节,是开发项目整体的一部分。是有计划有组织的,是伴随软件工程的诞生而诞生的,软件测试不是万能的,不可能发现全部缺陷,软件测试是有局限性的。在规定的条件下对程序进行操作,以发现程序错误,衡量软件质量,并对其是否能满足设计要求进行评估的过程。
?
-
?
?
?
-
测试流程
-
需求分析,需求评审(产品原型图)
-
制定测试计划(产品项目计划,人员安排、任务安排)
-
制定测试方案(测试需求点分析,测试模块划分,流程图分析)
-
编写测试用例(功能测试用例、脚本测试用例)
-
执行测试用例(功能点测试、脚本测试)
-
进行回归测试(跟踪bug修改情况,缺陷修复进度)
-
进行验收测试(完成测试环境测试,提交生产环境进行验收测试)
-
产品上线后跟踪与维护(收集用户反馈问题)
?
-
-
测试的方法
-
黑盒测试
?
-
等价类划分法
等价类划分法是一种典型的、重要的黑盒测试方法,它将程序所有可能的输入数据划分为若干个等价类。然后从每个部分中选取具有代表性的数据当做测试用例。测试用例由有效等价类和无效等价类的代表数据组成,从而保证测试用例具有完整性和代表性。
使用该方法设计测试用例主要有两个步骤
(1)确定等价类;(2)生成测试用例。
举个栗子
栗子1,用户名注册有如下需求,
1)用户名由数字,字母,下划线组成
2)用户名字符长度在6~18
3)用户名以字母开头。
这是一个简化版的注册,只考虑以上需求!!!
?
用等价类划分设计测试用例
-
-
?
?
测试点 |
关注点 |
需求 |
有效等价类 |
模块编号 |
无效等价类 |
模块编号 |
注册用户名 |
组成 |
由数字,字母,下划线组成 |
字母 |
A01 |
汉字 |
B01 |
字母+数字 |
A02 |
特殊字符 |
B02 |
|||
字母+下划线 |
A03 |
空格 |
B03 |
|||
字母+数字+下划线 |
A04 |
数字 |
B04 |
|||
数字+下划线 |
B05 |
|||||
规则 |
以字母开头 |
大写 |
A05 |
以数字开头 |
B06 |
|
小写 |
A06 |
以下划线开头 |
B07 |
|||
长度 |
[6,18] |
[6,18] |
A07 |
len>18 |
B08 |
|
0<=len<6 |
B09 |
-
边界值分析法
-
边界值分析法是对程序输入或输出的边界值进行测试的一种黑盒测试方法。实际的测试工作证明,考虑了边界条件的测试用例比那些没有考虑边界条件的测试用例具有更高的测试回报率。这里所说的边界条件,是指输入和输入等价类中那些恰好处于边界、或超过边界、或在边界以下的状态。
举个栗子
与等价划分的区别:
(1)边界值分析不是从某等价类中随便挑一个作为代表,而是使这个等价类的每个边界都要作为测试条件。
(2)边界值分析不仅考虑输入条件,还要考虑输出空间产生的测试情况。
?
对输入或输出边界值进行测试的一种黑盒测试方法。通常边界值法是对等价类划分法的补充。对输入值的选择不是对等价类的任意取值,而是选择等价类的边界(甚至是次边界)取值的方法。
?
栗子2
用边界值分析设计测试用例,补充栗子1(A07)
?
?
测试点 |
关注点 |
需求 |
case |
模块编号 |
注册用户名 |
长度 |
[6,18] |
null |
A07_a01 |
len=5 |
A07_a02 |
|||
len=6 |
A07_a03 |
|||
len=7 |
A07_a04 |
|||
len=17 |
A07_a05 |
|||
len=18 |
A07_a06 |
|||
len=19 |
A07_a07 |
-
因果图法
-
等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系,相互组合等。考虑输入条件之间的相互组合,可能会产生一些新的情况,但要检查输入条件的组合不是一件容易的事情,即使把所有输入条件划分成等价类,他们之间的组合情况也相当多。因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例,这就需要利用因果图。
因果图法是一种适合于描述对于多种输入条件组合的测试方法,根据输入条件的组合、约束关系和输出条件的因果关系,分析输入条件的各种组合情况,从而设计测试用例的方法,它适合于检查程序输入条件涉及的各种组合情况。因果图法一般和判定表结合使用,通过映射同时发生相互影响的多个输入来确定判定条件。因果图法最终生成的就是判定表,它适合于检查程序输入条件的各种组合情况。采用因果图法能帮助我们按照一定的步骤选择一组高效的测试用例,同时,还能指出程序规范中存在什么问题,鉴别和制作因果图。
举个栗子
有一个饮料自动售货机(处理单价为5角钱)的控制处理软件,
它的软件规格说明如下:? 若投入5角钱的硬币,按下“橙汁”或“绿茶”的按钮,则相应的饮料就送出来。若投入1元钱的硬币,同样也是按“橙汁”或“绿茶”的按钮,则自动售货机在送出相应饮料的同时退回5角钱的硬币。
?
栗子3
解决方法:
原因:
- 投入1元硬币;
- 投入5角硬币;
- 按下“橙汁”按钮;
- 按下“绿茶”按钮;
结果 :
- 退还5角钱;
- 送出“橙汁”饮料;
- 送出“绿茶”饮料;
?
用因果图法设计测试用例
从因果图中导出的判定表中的每一列为一个测试用例。
?
? | ? | ? |
1 |
2 |
3 |
? |
4 |
5 |
6 |
? |
7 |
8 |
输入 |
投入1元 |
A1 |
√ |
√ |
√ |
? |
0 |
0 |
0 |
? |
0 |
0 |
投入5角 |
A2 |
0 |
0 |
0 |
? |
√ |
√ |
√ |
? |
0 |
0 |
|
按下橙汁 |
A3 |
√ |
0 |
0 |
? |
√ |
0 |
0 |
? |
√ |
0 |
|
按下绿茶 |
A4 |
0 |
√ |
0 |
? |
0 |
√ |
0 |
? |
0 |
√ |
|
中间节点 |
已投币 |
B1 |
√ |
√ |
√ |
? |
√ |
√ |
√ |
? |
0 |
0 |
以按钮 |
B2 |
√ |
√ |
0 |
? |
√ |
√ |
0 |
? |
√ |
√ |
|
输出 |
退还五角 |
C1 |
√ |
√ |
0 |
? |
0 |
0 |
0 |
? |
0 |
0 |
送出橙汁 |
C2 |
√ |
0 |
0 |
? |
√ |
0 |
0 |
? |
0 |
0 |
|
送出绿茶 |
C3 |
0 |
√ |
0 |
? |
0 |
√ |
0 |
? |
0 |
0 |
-
错误推测法
-
错误推测法是基于以往的经验和直觉,参照以往的软件系统出现的错误,推测当前被测程序中可能存在的缺陷和错误,有针对性地设计测试用例。
使用场景:先用其他方法设计测试用例,再使用错误猜测法补充用例。
举个栗子
????栗子1中已有某用户名,再次使用此用户名进行注册会有什么结果
????栗子3中没有饮料时,投入硬币后会有什么结果
?
-
场景法
通过运用场景来对系统的功能点或业务流程的描述,从而提高测试效果的一种方法。用例场景来测试需求是指模拟特定场景边界发生的事情,通过事件来触发某个动作的发生,观察事件的最终结果,从而用来发现需求中存在的问题。主要用于测试系统的业务流程,分为基本流(正确流程)和备选流(错误流程),还要补充一些异常情况。
业务(需求)层面:对被测软件的重要功能、业务逻辑(系统要实现什么、如何实现?)、行业背景深入理解
技术层面:基于等价类划分中的有效等价类——模拟用户正确操作;无效等价类——模拟用户错误操作
核心概念:
基本流(正确流、有效流):模拟用户正确的操作流程
备选流(错误流、无效流):模拟用户错误的操作流程
?
-
?
-
白盒测试
通过检查软件内部的逻辑结构,对软件中的逻辑路径进行覆盖测试。在程序不同地方设立检查点,检查程序的状态,以确定实际运行状态与预期状态是否一致。
-
程序结构分析,根据源代码可以首先绘制程序的流程图,然后根据流程图分析程序的结构。
-
逻辑覆盖方测试,根据程序的内部结构,对所有的路径进行测试,是一种穷举路径的测试方法。
-
基本路径测试,根据程序的逻辑判断,分析程序中的路径,再进行用例的设计。
-
-
黑盒测试与白盒测试的区别
-
软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子,测试人员完全不考虑程序内部的逻辑结构和内部特性,只依据程序的需求规格说明书,检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试。
?
-
软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子,它允许测试人员利用程序内部的逻辑结构及有关信息,设计或选择测试用例,对程序的所有逻辑路径进行测试,通过在不同点检查程序状态,确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试。白盒测试主要是想对程序模块进行检查。
?
-
-
手工测试
由专门的测试人员从用户视角来验证软件是否满足设计要求的行为。更适用针对深度的测试和强调主观判断的测试。
?
-
自动化测试
适用单独的测试工具软件控制测试的自动化执行以及对预期和结果进行自动检查。
手工测试和自动化测试的区别:
手工测试
优点:易发现缺陷、容易实施、灵活性
缺点:覆盖低、重复测试效率低、可靠性低、人力资源依赖
自动化测试
优点:高效率速度快、高复用性、覆盖率高、准确可靠、持续运行
缺点:机械发现缺陷率低、一次性投入大
?
-
安全测试
安全测试是在IT软件产品的生命周期中,特别是产品开发基本完成到发布阶段,对产品进行检验以验证产品符合安全需求定义和产品质量标准的过程 。
?
-
探索性测试
探索性测试可以是一种测试思维技术。它没有很多实际的测试方法、技术和工具,是一种测试思维方式。探索性强调测试人员的主观能动性,抛弃繁杂的测试计划和测试用例设计过程,强调在碰到问题时及时改变测试策略。
?
-
随机测试
随机测试主要是对软件进行功能和性能抽查。
根据测试说明书执行用例测试的重要补充手段,是保证测试覆盖完整性的有效方式和过程。
随机测试主要是对被测软件的一些重要功能进行复测,也包括测试那些当前的测试用例(TestCase)没有覆盖到的部分。
?
-
冒烟测试
冒烟测试,就是开发人员在个人版本的软件上执行目前的冒烟测试项目,确定新的程序代码不出故障。冒烟测试目的是确认软件基本功能正常,现基本执行对象为测试人员,在正规测试一个新版本之前,投入较少的人力和时间验证基本功能,通过则测试准入。
?
-
α测试
α测试是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的测试。α测试的目的是评价软件产品的FLURPS(即功能、局域化、可使用性、可靠性、性能和支持)。大型通用软件,在正式发布前,通常需要执行Alpha和Beta测试。α测试不能由程序员或测试员完成。
?
-
β测试
-
Beta测试是一种验收测试。Beta测试由软件的最终用户们在一个或多个客房场所进行。
?
alpha测试和beta测试的区别
-
测试时间不同:
Beta测试是软件产品完成了功能测试和系统测试之后,产品发布之前所进行的软件测试活动,它是技术测试的最后一个阶段。alpha测试简称“α测试”,可以从软件产品编码结束之时开始,或在模块(子系统)测试完成之后开始,也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。
-
测试的目的不同:
α测试的目的是评价软件产品的(即功能、局域化、可用性、可靠性、性能和支持)。尤其注重产品的界面和特色。α测试即为非正式验收测试。Beta测试是一种验收测试,通过了验收测试,产品就会进入发布阶段。
-
测试人员及场所不同:
α测试是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的受控测试,α测试不能由程序员或测试员完成。α测试发现的错误,可以在测试现场立刻反馈给开发人员,由开发人员及时分析和处理。Beta测试由软件的最终用户们在一个或多个客户场所进行。开发者通常不在Beta测试的现场,因Beta测试是软件在开发者不能控制的环境中的“真实”应用。
-
?
-
测试用例
-
什么是测试用例
-
一组由前提条件、输入、执行条件、预期结果等组成,以完成对某个特定需求或者目标测试的数据,体现测试方案、方法、技术和策略的文档?
?
?
?
-
为什么要写测试用例
科学有效的对测试步骤进行组织规划,方便管理,记录
?
-
测试用例主要包含哪些内容
编号、日期、设计和测试人员、优先级、标题、目标的描述、环境、输入输出数据/动作、步骤、预期结果、备注等
?
-
编写测试用例需要什么
软件需求、设计说明书、软件模板
?
-
设计测试用例的注意事项
从高到低,独立性,与功能一一对应,根据需求设计
?
-
设计测试用例的原则
有模板,正确性,代表性,可判断性,重现性,详细准确清晰的步骤,符合规范
?
-
用例的管理工具
Excel、TestRail、jira、testlink等
?
-
用例的管理过程
编写→评审(修改→再次评审)→使用→保存管理→维护/升级