码迷,mamicode.com
首页 > 其他好文 > 详细

探索式软件测试

时间:2018-02-23 00:45:43      阅读:151      评论:0      收藏:0      [点我收藏+]

标签:保留   src   信息   分享   基于   必须   image   环境   手册   

探索式软件测试:
在敏捷测试中应用非常广泛
没有固定的测试用例,有一些测试思想和固定的框架以及一些测试场景,来完成测试工作。
即不同的测试思想,不断的应用这些测试思想,本身就是一些策略

自动化测试

手工测试

局部探索性测试

全局探索式测试

混合探索式软件测试

漫游与测试中的棘手问题

手工测试

软件缺陷的根源:

来自软件开发本身!
两种缺陷:
程序员引入缺陷
运行环境导致的缺陷

测试环境和上线环境相差很大

缺陷预防和检测

1.设计更好的设计规范
2.实施代码审核制度 (代码review)
3.运行代码静态分析工具
(代码是否规范,提高代码质量)
4.运行单元测试工具
(自动化测试居多)
敏捷测试中的重构:只是改变实现方法,入参和出参没有改变,因此可以更好的支持敏捷的开发

根本性问题:

开发人员只能是一个糟糕的测试者
处于静止状态的软件
缺乏数据

缺陷检测:

自动化测试:

测试人员编写代码来测试一个应用
selenium
适合用来测试流程固定或者大部分功能以前没有问题,是否依旧没有问题
自动化测试不是用来发现更多的bug,开发的初期很少引入自动化测试

手工测试:

点点点
快速执行,快速执行

自动化测试:

需要测试人员编写代码-----开发人员
花费太多的时间来开发测试代码,减少测试项目时间
自动化测试很炫,可以重复执行多次
自动化测试适合在测试环境中运行
自动化测试局限:
预言家的难题:
如何才能知道被测软件确实完成了他应完成的任务?
被测软件是否输出了正确的结果?

在运行中是否会带来副作用?

自动化测试擅长问题:

1、程序崩溃
2、系统死机
3、程序挂起
4、突发异常
5、原有能用的功能出现问题
过度的依赖自动化测试会为程序的最终成功带来隐患

手工测试缺点:

手工测试很慢,没有规律
不可反复使用
发现问题后不能重现
测试人员的水平决定了手工测试的质量
使用细化的测试用例进行测试,则却笑变通
建议:
测试用例不要使用太细节的描述,而是面试一些笼统的用户使用场景
(对所有字段做输入判断测试)
(输入判断测试测试那些东西?)
手工测试也可以使用自动化测试工具

探索式软件测试

完全抛开测试用例,使用定义的比较笼统的测试用例,称之为探索式软件测试
特点:
1、根据收集到的信息,天马行空,自由发挥
2、测试结果、测试实例和测试文档在测试执行时创建
3、探索式测试适用于“敏捷开发过程”
敏捷:小步快跑,不断的持续集成
4、测试人员有可能没有测试重点

探索式软件测试

局部探索式测试
针对测试对象局部内容进行测试的策略,例如:一个页面,一个输入框等测试策略
全局探索式测试
使用测试集来确定软件是否已经达到发布的质量标准
测试集中的测试用例都是相互有联系的整体
确定了如何对软件进行探索式测试的整体方向

测试目标

所有的重要任务都完成了,而剩下没做的事情是比较次要的,做到这一点就可以尽早尽可能地降低发布风险

方法:

测试是一个不停进行抉择的过程,测试和人员必须季节执行测试用例时和分析现有信息所涉及的各种复杂性,这有助于从多种可行方案中做出正确选择

局部探索式测试法

测试人员不需要知道很多信息就可以完成测试任务,局部测试的重点是把测试经验、专业知识、软件在操作环境下如何构建和运行的知识结合在一起,
使我们在测试过程中做出正确的决定

测试的原则

把测试工作简化为先在所有输入(或者运行环境等)的全体集合中选择一个子集,最后在输入时使用选中的子集,最后通过推理认定是否这些输入已经足够多了
最终产品发布后,再进行测试已经无法提高已发布代码的质量了
对于无限的测试,我们唯一的希望寄托于我们选择了正确的输入和其他的测试策略
随机测试不是好的测试方法,因为他不是缺少必要的策略
探索式测试的精髓:他有一些方针、方向和策略。

五要素之一:用户输入

输入:
输入指的是由环境产生的一种刺激,该刺激导致被测试的应用有所响应
分类:
1、原子输入
例如:输入一个数字、点击一个按钮
2、抽象输入
例如:1-25535之间的任何一个原子输入长度值
3、考虑各种输入之间会相互影响
4、输入值得顺序
例如:
1)单独搜索CD没有问题,单独搜索MV没有问题,混合搜索NV和CD 有问题
2)a和b 的输入组合,ab,ba
3)abc的输入组合:abc,bac,bca等
4)购物车测试,先买书,捷航。为空的时候结账,买一本后结账,然后再买一本

软件的核心功能:

1、接收输入
2、产生输出
3、存储数据
4、进行运算
程序的错误处理程序是重点:
大量的代码除了处理程序的正常逻辑之外
还需要大量的代码处理各种错误和异常情况
微软代码中:50%的代码是用来实现功能的,50%的代码用来做容错(即提示错误信息和异常情况),因,测试设计的测试用例的一半是正常的操作,另外一半做不正常的操作

错误处理程序

1、输入筛选器
防止非法的输入值被传递给应用程序的功能代码
确认开发人员是否正确实现了筛选器
确认是否考科一绕过输入的屏蔽器
2、输入检查
通过if then else case select 等方式实现
测试人员关注错误提示信息,挖掘其他可以触发错误的方式
3、异常代码处理
错误的提示信息比较笼统
确认异常产生的输入、进行修改和引申变化,确认出现异常的函数,通过运行调用次函数的测试用例,尝试查询是否可以发现新的缺陷

常规输入

没有特定的格式或者含义,开发计划中的输入,真实用户经常用的输入
例如:字母和数字等

非常规输入

比较特殊的情况下才会发生,某些特殊条件才会触发的输入
例如:ctrl+c shift+c,esc,ctrl
操作胸膛保留字
不同的字符集,本地化的问题

默认输入

在空白的文本框中不输入任何东西
程序界面元素设定的默认值

测试方法

为空的时候直接提交程序处理
去掉页面默认值后,提交程序处理
修改默认值,增加?减少?变化类型等方式

使用输出来指导输入

把程序的主要输出结果列出来,确定哪些输入会引发这些输出
输入和输出配对,保证大部分场景都被测试过
考虑多次输入(相同值和不同值),对输出的影响
从保存起来的输出结果思考,改动这些值或者改变他们的功能(大小和类型等),可以测试该值对系统的一些影响

五要素之一:状态

软件所处的一种现状
每种状态决定了系统有不同的表现,基于各种状态就可以做不同类型的测试
使用状态信息来帮助寻找相关的输入
使用状态信息来便是重要的输入序列

五要素之一:代码路径

一条代码路径就是一连串的代码语句,始于软件开始运行的语句,种植于一条特定的语句

五要素之一:用户数据

软件一般要存储海量的数据

五要素之一:运行环境

操作系统
当前配置
网络拓扑
驱动程序
文件系统
网络带宽

局部探索式测试

总结:局部探索式测试的每一步都是根据软件过去和当前的运行状况、软件在测试时表现出来的各种行为和软件运行小时的各种信息及时决定

全局探索式测试

探索式测试的几个目标:
理解应用程序如何工作,他的接口看起来怎样,他实现了那些功能
强迫软件展示其全部能力
验证软件可以达到设计和发布的要求
找到缺陷
探索各种软件的极端情况来发现潜在的问题,发现为被测试过的功能或者包含缺陷多的功能

指南测试法

测试人员通过阅读用户手册并严格遵守手册的建议执行操作
如果手册描述了某个特性以及如何使用该特性,则需要进行详细测试
目的是尽量执行手册中提交的场景,验证软件实现的软件特性,也验证用户手册的准确性

指南测试法——变种

博客测试法(第三方建议)
专家测试法(根据抱怨或者用户评论)
竞争对手测试法

卖点测试方法

软件最核心的功能,用户希望使用的功能就是卖点
销售人员会花费大量的时间给用户演示这些程序的卖点,他们会创造出很多出彩的使用场景
测试人员应该和销售人员保持好关系,获取各种销售方面的信息,进一步探索软件的使用场景

地标测试法

技术分享图片

极限测试法

技术分享图片

快递测试法

技术分享图片

深夜测试法

技术分享图片

遍历测试法

技术分享图片

历史区测试法

技术分享图片

娱乐区测试法

技术分享图片

旅游区测试法

技术分享图片
技术分享图片
技术分享图片

破旧区测试类型

技术分享图片

混合探索式测试

技术分享图片

通过场景操作引入变化

技术分享图片

漫游测试

技术分享图片

通过漫游测试引入变化

技术分享图片
技术分享图片
技术分享图片

棘手的几个问题

技术分享图片

漫无目的性

技术分享图片

暂时性

技术分享图片

单调性

技术分享图片

健忘

技术分享图片

探索式软件测试

标签:保留   src   信息   分享   基于   必须   image   环境   手册   

原文地址:https://www.cnblogs.com/python-xiakaibi/p/8460607.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!