网站后台管理维护 不懂编程,如何网站数据备份,网站建设公司的服务定位,哪些编程语言适合网站开发目录
#x1f4d5;引言
#x1f340;测试用例
#x1f6a9;概念
#x1f6a9;设计测试用例的万能公式
#x1f3c0;常规思考逆向思维发散性思维
#x1f3c0;万能公式
#x1f384;设计测试用例的方法
#x1f6a9;基于需求的设计方法
#x1f3c0;明确需求中…目录
引言
测试用例
概念
设计测试用例的万能公式
常规思考逆向思维发散性思维
万能公式
设计测试用例的方法
基于需求的设计方法
明确需求中的功能点
结合万能公式设计测试点
具体设计方法
等价类
边界值
正交表法
判定表法
场景法
错误猜测法
更多用例练习
命令行程序
接口 引言
本文章重点目标
测试用例的概念
设计测试用例的万能思路
设计测试用例的方法
◦ 基于需求的设计方法◦ 具体的设计方法
▪ 等价类 ▪ 边界值 ▪ 判定表法 ▪ 正交法 ▪ 场景法 ▪ 错误猜测法
测试用例
概念
什么是测试用例
测试用例TestCase是为了实施测试而向被测试的系统提供的一组集合这组集合包含测试环境、操作步骤、测试数据、预期结果等要素。 在很早之前通过excel表格来编写测试用例现在用的比较少现在使用脑图或者思维导图。 注意笔试的时候编写测试用例题使用excel表格会涉及到测试用例的要素的方式来答题而面试的时候回答测试用例题不会涉及到测试用例的要素按照思维导图的方式一一道来即可。 使用思维导图现在工作中和面试的时候 设计测试用例的万能公式
案例给门锁设计测试用例 可以看出用例的设计最重要的一点是保证功能是正确的。上图给出的案例能设计出来的测试用例整体上来说数量是合格的但是说出来的测试用例不够具体在笼统了无法作为测试工作的参考依据在互联网企业中这样去设计测试用例的非常少缺乏经验的同学往往以这样的思路去设计。 常规思考逆向思维发散性思维
正确设计测试用例的思想常规思维逆向思维发散性思维
设计测试用例的原则二
1.测试用例的编写不仅应当根据有效和预料到的输入情况而且也应该根据无效和未预料到的输入情况。
2.检查程序是否“未做其应该做的”仅是成功的一半测试的另一半是检查程序是否“做了其不应该做的”。是上一条原则的必然结果
3.计划测试工作时不应默许假定不会发现错误。 明白了设计测试用例是思维的正确还往往不够。
若仅仅通过头脑风暴去设计测试用例那么当我们面对面试官时能够想出来的用例是寥寥无几的 所以在设计测试用例的时候需要有思路的去设计。
比如突然让你说出家里的电器你可能说出电冰箱电视机空调......脑袋突然就想不起来了明明家里的电器很多但怎么就想不起来如果有了引导厨房的电器客厅的电器卧室的电器
万能公式
设计测试用例的万能公式功能测试界面测试性能测试兼容性测试易用性测试安全测试。
简单了解各个公式 各个公式的具体说明
功能测试
功能测试是⼀个试图发现程序与其外部规格说明之间存在不⼀致的过程。外部规格说明是⼀份从 最终用户的角度对程序行为的精确描述。功能测试通常是一项黑盒操作。在进行功能测试时需要对规格说明进行分析以提炼测试用例本课程中讨论的具体设计测试用例的方法尤其适用于功能测试。 然而不仅是工作中还是面试中可能会存在需求不明确的功能这种情况下该如何进行功能测试
◦ 查找其他相关文档来帮助理解所要测试的产品需要完成的目标;
◦ 尽量多参加项目组内的会议比如需求讨论、设计讨论、计划讨论等能够加深对产品的理解;
◦ 召集相关人员对你整理的结果进行讨论通过评审后这份文档就可以作为依据来设计你的case了;
◦ 如果是一款已经上线的产品可以多使用产品有不懂的问产品经理;
◦ 也可以去看历史bug可以了解到一些需要关注的东西。
界面测试
对软件界⾯上所有的内容都需要进⾏测试。
要求
◦ 整体界面测试界面的实现与设计图要求一致。
◦ 界面元素测试 ▪ 控件操作验证
性能测试
性能测试和功能测试的区别是功能测试检查软件是否做了而性能测试测试软件做的好不好。
兼容性测试
软件是部署在硬件系统之上并依赖所需要的软件环境。如QQ可以在PC端打开也可以在移动 端打开移动端又分为IOS系统和Android系统且市面上手机又有不同的品牌、不同的机型、不同的版本。软件是否能够在不同的环境下正确运行需要测试人员进行验证。
问题:既然市面上有众多版本的机器,那么在执行兼容性测试时难道所有的机型都需要全面覆盖吗
选取标准
• 优先选择使⽤当前产品top级别的机型进⾏测试 实际在企业中后台是可以获取到使⽤产品的机型并以报表的形式统计在后台供产品人员 或其他人员制定策略参考。
• 选择主流的浏览器/机型进行测试
易用性测试
易用性测试的标准是检查产品是否具备简单易上手的属性。假如测试人员从来没有安装或使用过 该产品作为一个新用户对当前产品是否能够快速适用产品的使用流程。
安全测试
安全测试和性能测试一样都是比较大的领域。常见的安全问题如
• 隐私数据明文显示。
• 参数未强校验导致SQL注入。
• 越权普通用户也可以执行管理员权限的操作。
接下来针对水杯进行测试 除了万能公式之外还有一个比较常用的测试类型弱网测试、安装卸载测试
弱网测试
弱网测试的目的就是尽可能保证用户体验关注的关键点包括:(为了覆盖更多的网络景,wifi,2G,3G)
• 页面响应时间是否可以接受关注包括热启动、冷启动时间、页面切换、前后台切换、首字时间首屏时间等。
• 页面呈现是否完成一致。
• 超时文案是否符合定义异常信息是否显示正常。
• 是否有超时重连。
• 安全角度是否会发生dns劫持、登陆ip更换频繁、单点登陆异常等。
• 大流量事件风险是否会在弱网下进行更新apk包、下载文件等大流量动作。
如何进行弱网测试弱网需要借助工具来构造弱网这里推荐使用fiddler
1fiddler配置代理
2fiddler进行抓包桌面/移动端
3fiddler如何构造弱网条件
首先当前电脑连上的是手机热点5G此时访问一个网站时速度是非常快的。接下来通过Fiddler设置弱网来访问某个网站。
1.打开弱网设置选项勾选上 2.打开设置弱网脚本 3.打开弱网设置crtlF进行查找 当打开设置的时候此时的if条件为真就会执行if里面的代码; 代码一:上行速率,指客户端发送请求给服务器传输1KB需要多少毫秒,设置数值越大传输速率越慢 代码二:下行速率,指服务器返回给客户端传输1KB需要多少毫秒,设置数值越大传输速率越慢 安装卸载测试
针对需要进行部署的软件除了软件功能外我们还需要关注软件的能够成功安装和卸载一般用于移动软件和客户端软件 注意在面试和笔试中设计出来的测试用例一定要越多越好在工作中则不一定要求测试用例的质量高用较少的用例覆盖更多的功能。 设计测试用例的方法
基于需求的设计方法
基于需求的设计方法也是总的设计测试用例的方法在工作中我们需要参考需求文档/产品规格说明书来设计测试用例。
测试人员接到需求之后要对需求进行分析和验证从合理的需求中进一步分析细化需求从细化的需求中找出测试点根据这些测试点再去设计测试用例。
以该注册邮箱账号需求为例我们来设计测试用例。 基本事件流也就是通用流程绝大多数用户的操作流程/主流程
扩展事件流可能出现的流程
明确需求中的功能点
账号注册账号登陆
结合万能公式设计测试点 具体设计方法
上面根据需求文档先设计初步的测试用例而部分用例还需要细化就需要借助具体的设计方法。下面这些具体的方法旨在提高我们的测试思路和提高我们设计测试用例的能力。
等价类
上述设计的测试用例用例存在用例还未完全设计完成“姓名必填6~15位的字符类型”这样 一个具体的需求该如何来设计测试用例呢
测试的时候通过穷举法来测试6位、7位、8位......14位15位是否测试通过这样的方法能够满足测试的要求吗这只是测试了软件是否做了其应该做的还要测试是否其做了不应该做的例如小于6的和大于15是否都要测试试想一下这样一个简单的测试点需要测试多久呢显示是不符合企业测试要求的。
而等价类法的出现就解决了穷举法不能解决的问题
依据需求将输入特殊情况下会考虑输出划分为若干个等价类从等价类中选出一个测试用例如果这个测试用例测试通过则认为所代表的等价类测试通过这样就可以用较少的测试用例达到尽量多的功能覆盖解决了不能穷举测试的问题。
借组等价类有一个等价类里面有很多数据从里面选一个数据进行测试若这个测试通过则代表等价类中的数据集全部通过。
等价类分类
有效等价类对于程序的规格说明书是合理的、有意义的输入数据构成的集合利用有效等价类验证程序是否实现了规格说明中所规定的功能和性能。例如上述的6-15位无效等价类根据需求说明书不满足需求的集合。例如小于6和大于15的
根据等价类设计测试用例的方式
1.确定有效等价类和无效等价类有效等价类:6~15,无效等价类小于6和大于15
2.编写测试用例设计具体测试数据
例如 缺点等价类只考虑输入域的分类没有考虑输入域的组合需要其他的设计方法和补充。
边界值
边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充这种情况下其测试用例来自等价类的边界。
边界值包含边界值次边界值
边界值即给定范围的左数据与右数据选择次边界值的时候需要根据边界值的有效无效情况来定 1若边界值为有效等价类中的数据则次边界值为无效等价类中的边界 2若边界值为无效等价类中的数据则次边界值为有效等价类中的边界
上述的边界值6 15 (有效) 次边界值5 16(无效)
继续将上述用例通过边界值补充完整 正交表法
通过等价类和边界值方法我们完成了部分用例的补充 当前还剩下一个场景的用例未补充完成“只填写部分选项”这里到底要设计多少测试用例呢对于姓名电子邮箱密码确认密码验证码这5种进行部分填写的组合有很多种例如姓名填写密码填写姓名不填写密码不填写姓名不填写密码填写姓名填写密码不填写对于这两个组合就有4种测试用例那么上述姓名电子邮箱密码确认密码验证码的组合就是2^532种。
那么只是测试一下是否填写这个用例就需要测试32种消耗人力和时间如何优化呢
正交法的目的是为了减少用例数目。用尽量少的用例覆盖输入的两两组合。
正交试验设计(Orthogonalexperimentaldesign)是研究多因素多水平的一种设计方法它是根据正交性由试验因素的全部水平组合中挑选出部分有代表性的点进行试验通过对这部分试验结果的分析了解全面试验的情况找出最优的水平组合。正交试验设计是一种基于正交表的、高效率、快速、经济的试验。
正交表
如图最简单的正交表是L4(2^3)含意如下“L”代表正交表L下角的数字“4”表示有4横行 简称行即要做4次试验括号内的指数“11”表示有11纵列简称列即最多允许安排的因素是11个括号内的数“2”表示水平数表的主要部分只有2种数字即因素有两种水平1与2。 正交表的构成因素数、水平数、行数。
因素对指标的影响条件通常是正交表中的一列。
水平因素对应的可选项。
正交表的性质
每一列中不同的数字出现的次数相等任意两列中数字的排列方式齐全而且均衡(例如上述第一列和第二列的横行1和1组合在两列中只出现一次2和1组合在两列中只出现一次)
上述的姓名分为填写和不填写电子邮箱分为填写和不填写......和我们提到的因素与水平可以一一对应上即姓名电子邮箱密码确认密码验证码就是因素每个因素下就是填写和不填写也就是水平。
根据正交表的性质一般人很难通过手动设计出正交表
正交法设计测试用例的步骤
1. 根据需求找到因素和水平2. 用allpairs工具生成正交表 a. 将因素和水平写入Excel表格中表格不需要保存 b. allpairs目录下创建新的文本文件xxx.txt复制Excel中的因素和水平直接粘贴到文本 中保存并退出 c. 使用allpairs命令生成正交表allpairs.exe xxx.txt zhengjiao.txt
继续以邮箱注册为例采用正交法补全剩下的测试用例
1. 找到因素和水平
因素姓名、电子邮箱、密码、确认密码、验证码
水平填写、不填写
2. 用allpairs.exe工具生成正交表 a. 将因素和水平写入Excel表格中使用微软自带的Excel工具写出的表格不需要保存 b. allpairs.exe目录下创建新的文本文件xxx.txt复制Excel中的因素和水平直接粘贴到文本中 不要有其他操作之间保存关闭或者不关闭。 c. 使用allpairs.exe工具对txt文件生成正交表文件 命令allpairs.exe text01.txt ret-test01.txt 将text01.txt文件通过allpairs.exe工具输出正交表文件放到ret-test01.txt文件(该文件不需要新建)3.进入cmd进行操作
当我们要使用上述命令时此时我的cmd还在c盘Users路径下。 但是我的allpairs.exe文件在d盘paris路径下 即先跳转到d盘进入到paris路径中 现在即可对于text01.txt文件通过allpairs.exe工具生成正交表文件 此时该路径下就有ret-test01.txt文件了 打开该文件里面内容较多只需关注下图即可。此时由32种测试用例变为6种了5和6行的~表示可以是任意选项(填写/不填写) 4.根据生成好的正交表来编写测试用例 5.补充遗漏的重要测试用例 原本要测试32中用例先通过正交表生成的测试用例只有7种了。 注意allpairs工具生成的正交表和实际的正交表有一定的出入上述讲到正交表有两个比较严格的性质对于这两个性质带入我们所生成好的正交表文件(ret-test01.txt)中进行查看在第一列中56行若都为填写/都不填写就不满足正交表的第一个性质在第二列和第四列中横行的填写出现了两次横行的不填写出现了两次也不满足上述性质。但是并不影响整体情况。工作中一般不会用到。 判定表法 通过具体的方法能够将测试用例设计的更加完整和规范。 需求中会存在各种各样的场景现在我们把需求改成如下的要求
用户输入的账号中包含admin字符或者通过内部链接进入注册页面提交注册按钮成为管理员身份反之无管理员身份。
通过这个需求可以看出不同的组合操作可能对应不同的结果。采用正交法无法解决这样的问题。而正交法能够解决需要考虑输入之间的组合关系对应不同结果的场景。
判定表是一种表达逻辑判断的工具形如对于两种条件对应4种结果不同组合对应的结果是不一样的。判定表法非常容易的编写出测试用例 通过该图可以把所有条件对应的结果清晰的表达出来。我们就需要借助该表来清晰的写出测试用例。
根据判定表法设计测试⽤例的步骤
1. 确认需求中输入条件和输出条件2. 找出输入条件和输出条件之间的关系3. 画判定表4. 根据判定表编写测试用例
确认了步骤后我们使用判定表法进一步对上述需求进行测试用例的设计
1. 确认需求中输入条件和输出条件 输入条件账号包含admin字符a、内部注册链接(b)、点击注册按钮(c) 输出条件管理员1、无管理员2
2. 找出输入条件和输出条件之间的关系 3. 画判定表 4. 根据判定表编写测试用例 a.账号包含admin非内部注册链接点击注册按钮为管理员身份 b. 账号包含admin内部注册链接不点击注册按钮非管理员身份 c. 账号不包含admin内部注册链接点击注册按钮为管理员身份 d. 账号包含admin内部注册链接点击注册按钮为管理员身份 e. 账号包含admin非内部注册链接不点击注册按钮非管理员身份 f. 账号不包含admin非内部注册链接点击注册按钮非管理员身份 g. 账号不包含admin非内部注册链接不点击注册按钮非管理员身份
场景法
现在的软件几乎都是用事件触发来控制流程的(比如步骤一走完才触发步骤二步骤二走完才会触发步骤三),事件触发时的情景便形成了场景,而同一事件不同的触发顺序和处理结果就形成事件流。
通过运用场景来对系统的功能点或业务流程的描述从而提高测试效果的一种方法。用例场景来测试需求是指模拟特定场景边界发生的事情通过事件来触发某个动作的发生观察事件的最终结果从而用来发现需求中存在的问题。我们通常以正常的用例场景分析开始然后再着手其他的场景分析。 场景法一般包含基本流和备用流从一个流程开始通过描述经过的路径来确定的过程经过遍历所 有的基本流和备用流来完成整个场景。场景主要包括4种主要的类型一般不关注正常的用例场景备选的用例场 景异常的用例场景假定推测的场景。
读完上面的概念是不是一脸懵场景法就是一个常规的流程中某些阶段可能会出现一些意想不到的情况常规流程是基本流从阶段中分析出来的不同情况被称之为备选流场景法比较考验同学们的发散思维。
以逛街买衣服为例讲讲场景法的使用方法 该方法可以比较生动地描绘出事件触发时的情景有利于测试设计者设计测试用例是测试用例更容易理解和执行。
案例还是根据邮箱账号注册的案例根据场景法来设计测试用例
根据场景法设计测试用例的步骤
1.确定基本流
2.确定备选流
3.根据备选流补充测试用例
4.编写测试用例 编写测试用例
1.基本流输入正确的账号密码点击注册后系统发出确认邮件并在24H内确认注册成功。 2.备用流不输入账号密码点击注册提示重新输入 3.备用流只输入账号不输入密码点击注册提示重新输入 ......场景法在工作中也是一个非常有用的设计测试用例的思路
错误猜测法
错误猜测法是对被测试软件设计的理解过往经验以及个人直觉推测出软件可能存在的缺陷从而针对性地设计测试用例的方法。
这个方法强调的是对被测试软件的需求理解以及设计实现的细节把握还有个人的经验和直觉。
错误推测法和目前流行的“探索式测试方法”的基本思想⼀致这类方法在敏捷开发模式下的投入产 出比很高被广泛应用于测试。
例如当我们一提到某个非常熟悉的人的名字脑海会立刻浮现对他的评价
“武大郎”憨厚老实为人坦诚乐于助人
“潘金莲”美丽“温柔”“疼爱丈夫”“善于交友”“精通制衣”
这个方法的缺点是难以系统化并且过度依赖过往经验和个人能力。
案例 更多用例练习
上面介绍设计测试用例以及方法已经介绍过web场景用例的设计。接下来看看不同题型用例的设计。
命令行程序
存在功能可以在命令行使用zip/unzip命令对文件进行解压缩这样的场景如何来设计测试用例
zip命令
功能测试对不同的文件类型进行测试 1普通的txt文件能够生成zip文件 2图片/视频/zip文件能够生成zip文件 3多个文件能够生成zip文件混合文件 4空文件夹可以生成zip文件 5错误的命令是否可以解压zip zip/没有写压缩包文件名称/没有源文件 6其他参数的测试
界面测试
1文件压缩成功命令行提示是否美观
2文件压缩报错命令行提示是否友好
性能测试
1文件大小超过1G时文件是否可以压缩
2文件大小超过1G时文件压缩消耗的时间是否在合理的时间范围内
兼容性测试
1zip工具可以在多系统上使用如Windows、Linux、Mac
易用性测试
1zip命令有使用帮助教程如zip--help命令下会展示如何使用
安全性
1使用zip命令不会泄漏文件内容
接口
后续讲述......
