69、黑盒测试的测试用例常见设计方法都有哪些?请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。
1)等价类划分:
等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.
2)边界值分析法:
是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据。
3)错误猜测法:
基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法。错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例。
4)因果图方法:
前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例。这就需要利用因果图(逻辑模型)。因果图方法最终生成的就是判定表.它适合于检查程序输入条件的各种组合情况。
5)正交表分析法:
可能因为大量的参数的组合而引起测试用例数量上的激增,同时,这些测试用例并没有明显的优先级上的差距,而测试人员又无法完成这么多数量的测试,就可以通过正交表来进行缩减一些用例,从而达到尽量少的用例覆盖尽量大的范围的可能性。
6)场景分析方法:指根据用户场景来模拟用户的操作步骤,这个比较类似因果图,但是可能执行的深度和可行性更好。
7)状态图法:
通过输入条件和系统需求说明得到被测系统的所有状态,通过输入条件和状态得出输出条件;通过输入条件、输出条件和状态得出被测系统的测试用例。
8)大纲法:
大纲法是一种着眼于需求的方法,为了列出各种测试条件,就将需求转换为大纲的形式。大纲表示为树状结构,在根和每个叶子结点之间存在唯一的路径。大纲中的每条路径定义了一个特定的输入条件集合,用于定义测试用例。树中叶子的数目或大纲中的路径给出了测试所有功能所需测试用例的大致数量。
70、探讨测试用例设计的六大思路
有这样一个面试题:在一个Web测试页面上,有一个输入框,一个计数器(count)按钮,用于计算一个文本字符串中字母a出现的个数。请设计一系列测试用例用以测试这个Web页面。
有经验的测试人员可能会问面试官,字母a区分大小写吗?只统计英文字母的a吗?最长输入字符是多少,最少输入字符是多少?对输入的字符类型是否有限制,是否会自动清除不符合要求的字符?
所以第一步应该是明确需求,然后我们才开始进行思考如何设计测试用例。
通常说来,我们考虑一个测试对象的时候至少从以下六方面来考虑:
1.功能性
2.兼容性
3.易用性
4.可靠性
5.性能
6.安全
1.从功能方面考虑:
输入:" "(思路:什么都不输入)
输入:“null”(思路:特殊值)
输入:“Aa”(思路:输入字符既含大写字符也有小写)
输入:“abc”(思路:以a开头)
输入:“cac”(思路:a在中间)
输入:“aba”(思路:以a开头,以a结尾)
输入:" ba"(思路:以空格开头含a)
输入:“中ba”(思路:以中文或者其他字符开头含a)
输入:“AAaa”(思路:输入字符仅仅只有大写A和小写a)
输入:“全角和半角a”(思路:考虑半角和全角符号)
2.从兼容性方面考虑:
1.各个浏览器 显示是否正确,点击按钮是否有效;
2.浏览器各个版本显示是否正确,点击按钮是否有效;
3.是否支持手机端和平板端。
3.从易用性方面考虑:
1.web界面外观,风格是否合适;
2.文本输入框长度是否合适,是否应该默认提示如何输入;
3.输入错误时提示是否友好;
4.考虑该应用是否支持其他语言。
4.从可靠性和性能方面考虑:
1.输入HTML和JavaScript相关标签字符,计算是否正确,是否会破坏页面;
2.这个应用能否在同一台服务器上运行多个实例,多个用户同时使用是否会有问题;
3.在大并发下使用,计算速度是否满足要求。
5.从安全性方面考虑:
1.输入的数据是否会被保存,输入字符串可能包含敏感信息;
2.尝试复制/粘贴字符串;
3.尝试快速点击多次计算按钮;
4.考虑是否有安全漏洞,点击计算按钮,请求是否会被截取,导致返回失败。
71、金融软件测试面试题目有哪些
网上银行转账是怎么测的,设计一下测试用例。
回答思路:
宏观上可以从质量模型(万能公式)来考虑,重点需要测试转账的功能、性能与安全性。设计测试用例可以使用场景法为主,先列出转账的基本流和备选流。然后设计场景,最后根据场景设计数据。实际面试中需要举出具体的例子。
先检查界面。
再测试功能:
验证同行转账,跨行转账。
验证转账限额。
验证非法账户(挂失,冻结,锁定的账户)的转账。
再测试性能方面的。
72、测试工作的流程?缺陷状态有什么?设计测试用例有几种方法?
测试工程师的实际工作流程(以P2P中型版本为例,一个月一个版本):
产品经理或者SR把需求书发下来给开发和测试
测试先看一遍,进行需求分析。测试组长编写测试计划,并且分配测试任务给测试人员(2天时间)(此时开发也在进行需求分析)
过了2天,产品经理再把测试和开发召集在一起,进行需求讲解(或者说需求评审),有问题可以直接问,如果发现需求有问题,也可以提出来,SR回去会修改。(需求讲解时间0.5天)
讲完需求后,测试同事要进行测试场景的梳理和案例的编写了(xmind和Excel就要用上了),一共5个工作日。(此时开发在编写代码)
之后就要进行案例评审了,评审时候有SR、测试同事、开发同事,评审时候一般SR、测试组长、对应模块的开发同事会提出一点意见,评审完之后,回去修改、补充一下案例。(案例评审0.5天)
修改完以后,有两种处理情况:
对大项目有时候要进行案例的第二次评审。
对小项目,在时间紧的时候,一般不会二审,但是要以邮件的形式把修改或者新增后的案例发出来,给领导看,并抄送给其他同事。(案例评审0.5天,修改案例0.5天,案例二审0.5天)
案例评审完就要开始测试了,一般测试环境开发搭建好(要说自己也会搭建,搭建流程背老师总结的):
中型版本的测试一般分2轮:第一轮:5天;第二轮:3天;回归测试2天;(共10个工作日)。
回归测试完后,达到了上线标准,就会如期上线,一般当天晚上12点上线
缺陷状态:缺陷管理的流程图