直播网站建设书籍,四大商业网站,网页设计入门书哪本比较好,搜索百度一、测试用例的基本要素
测试用例#xff08;Test Case#xff09;是为了实施测试而向被测试的系统提供的一组集合#xff0c;这组集合包含#xff1a;测试环境、操作步骤、测试数据、预期结果等要素。#xff08;注意#xff1a;不需要执行结果#xff0c;因为执行结果…一、测试用例的基本要素
测试用例Test Case是为了实施测试而向被测试的系统提供的一组集合这组集合包含测试环境、操作步骤、测试数据、预期结果等要素。注意不需要执行结果因为执行结果需要执行完测试用例才知道没有测试用例自然就没有执行结果
好的测试用例是一个不熟悉业务的人也能依据用例来很快的进行测试。
评价测试用例的标准对比好坏用例的评价标准。 用例表达清楚无二义性。用例可操作性强。 用例的输入与输出明确。一条用例只有一个预期结果。 用例的可维护性好。 用例对需求的覆盖率高。 1、测试用例的给我们带来的好处
测试执行者的依据。使得工作可重复自动化测试的基础。评估需求覆盖率。用例的复用。积累测试的方法思路以供后续借鉴。 1使用时带来的困扰 测试用例的设计是费时费力的工作往往设计测试用例所花费的时间比执行所花费的时间还多。 2能解决的问题 不知道是否较全面的测试了所有功能。测试的覆盖率无法衡量。对新版本的重复测试很难实施。存在大量冗余测试影响测试效率。 二、测试用例的设计方法 1、基于需求进行测试用例的设计 基于需求设计测试用例是测试设计和开发测试用例的基础第一步就要分析测试需求验证需求是否正 确、完整、无二义性并且逻辑自洽。 在需求正确的基础上细化测试需求从测试需求提炼出一个个测 试点或者测试项然后根据每一个测试点进行测试用例的设计。 在分析测试需求时一般分为 功能测试需求 和 非功能测试需求 。 【163 邮箱注册】 1功能需求测试分析 对于功能测试中可以借助功能框图来帮助我们进行测试的需求分析。概括起来功能测试需求包括以下通常包括以下几个方面 系统各个功能界面的验证。借助业务把功能串起来进行测试。功能的一致性交互性多功能互操作的测试。系统的不同输入结果输出的业务数据测试。功能的错误操作异常操作的测试属于负面测试。功能实现用到的算法验证有时需要用运代码评审。用户操作的易用性用户体验往往结合功能测试同时验证。 针对具体的需求可以根据业务分类用户角色餐厅的会员系统或者用户操作区域等将系统的功能分解成若干个功能模块然后按照功能模块分别进行测试需求分析。按照功能模块划分业务模块划分是最常见的做法。 【日历系统的需求分析】 对日历根据 web 界面的功能布局分析出的功能框图如下 也可以采用思维导图的方式更为方便有效只管的呈现测试需求的分析结果可以更好的支持测试分析思路的连贯性。 【百度云盘手机端核心功能需求分析】 在进行需求分析的时候我们还要考虑业务规则如上传文件的大小有没有限制一次性崔铎上传多少数量的文件比如小于 100 个文件夹最多有多少层等等 2非功能需求测试分析 非功能测试需求主要涉及性能安全性可靠性兼容性易维护性和可移植性等。从测试需求分析来看每一类非功能特性测试都需要根据需求单独分析。他们之间可能会存在相互影响如安全性越高就越有可能给易用性性能带来更大的挑战。 这里要说明的是对于每一个应用软件系统非功能特性的质量需求都是存在的但是不同的项目类型对各个非功能特性的要求是不一样的这个需要根据具体的项目、具体需求和不同产品应用的特点进行分析。 a. 纯客户端软件 比如字处理软件WordPPT)媒体音频 / 视频播放软件电脑自带的等。这类软件对系统的功能测试要求是最低的但是对兼容性和稳定性可移植性有一定的要求。 b. 企业内部的客户端/服务端C/S)应用系统 比如电子邮件即时通信系统飞Q企业QQ等在系统功能测试需求上比纯客户端复杂要求功能正确稳定性能好。但是整体上看对性能安全性兼容性要求不高。 c. 外部大型复杂网络应用系统 比如电子商务网上银行视频网站腾讯优酷等除了有复杂的系统的功能测试需求外在系统的性能安全性兼容性容错性可靠性等都有很高的要求。 此外对于大型企业级应用系统由于应用模式系统架构的不同分布式微服务等我们必须结合架构和应用模式来具体分析非功能性测试需求特别是可扩展性可靠性安全性等。技术架构对功能的影响小但是非功能性测试就要深入架构分析才能更好的把我测试范围和测试方法。 继续举一个例子百度云盘非功能测试的例子 用户需求:
购买3000块钱以内的华为智能手机
测试用例
1.价格3000元
2.品牌为华为
3.智能手机
4.手机功能验证4-1.打电话4-2.接电话4-3.发短信4-4.收短信... 软件需求
1.1.1.1.5.3 异常事件流
1. 若用户未收到激活邮件可在登录界面录入电子邮件及密码后再次发送激活邮件。
2. 每次发送的激活邮件仅在发送邮件后起24小时之内有效超过24小时后需重新发送激活邮件。
**测试用例**
1-1、未收到邮件登录时输入电子邮件及密码后再次发送激活邮件
1-2、已收到邮件登录时输入电子邮件及密码后不发送激活邮件2-1、收到邮件未激活24小时内进行激活
2-2、收到邮件未激活24小时后链接过期进行激活。
2-3、收到邮件已激活24小时后链接过期再次点击激活
页面检查
1、收到激活邮件
2、邮件内容正确
3、激活URl正确可激活
4、再次激活提示已激活
5、过期激活提示已过期 2、具体的设计方法 1等价类 举例 原则上讲 老师应该依据每个学生自身的情况 指定符合的学习方案。 但是实际上学生太多老师管不过来 只能分成几类 优等生强调知识面的扩展和综合能力的提升中等生强调夯实基础查缺补漏差等生强调优先掌握重点暂时跳过难点... ... 思路输入的集合是无穷的 不能全都覆盖到。 依据需求将输入特殊情况下会考虑输出划分为若干个等价类从等价类中选出一个测试用例如果这个测试用例测试通过则认为所代表的等价类测试通过这样就可以用较少的测试用例达到尽量多的功能覆盖解决了不能穷举测试的问题。 有效等价类对于程序的规格说明书是合理的、有意义的输入数据构成的集合利用有效等价类验证程序是否实现了规格说明中所规定的功能和性能。满足用户需求输入集合。无效等价类根据需求说明书不满足用户需求输入的集合。 等价类只考虑输入域的分类没有考虑输入域的组合需要其他的设计方法和补充。 【超市买水果】
有效等价类苹果、梨子、西瓜...
无效等价类青菜、大米、饮料...
|用户名 | 必填录入用户名 | 6至15有效等价类6~15位
无效等价类小于6位 大于15位等价类思想设计测试用例的步骤
充分理解需求划分有效等价类和无效等价类针对有效等价类和无效等价类中设计测试用例。 2边界值 边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充这种情况下其测试用例来自等价类的边界。 日常语言中的 “边界” 漏洞考完试发成绩了, 老师布置寒假作业超过 60 分的所有题目抄写 1 遍低于 60 分的所有题目抄写 3 遍。于是小明就没有写作业因为他刚好 60 分。 输入框长度为 1~11取边界值为1、11、12、0。运动员的参赛项目为 1~3 项取边界值为0项、1项、3项、4项。查询面页面有 999 行每 50 行为一页取边界值为输出0行、1行、50行、51行、999行。 边界点 上点边界上的点。 内点边界内的点不管范围是闭区间开始开区间。 离点边界值附近的一个点闭区间区间外距离上点最近的点开区间区间内距离上点最近的点。 3因果图 因果图是一种简化了的逻辑图能直观地表明程序输入条件原因和输出动作结果之间的相互关系。因果图法是借助图形来设计测试用例的一种系统方法特别适用于被测试程序具有多种输入条件、程序的输出又依赖于输入条件的各种情况。 A. 因果图的需要掌握的基本知识
a. 恒等 条件为真结果一定为真。 b. 与 所有的条件都得满足如果有一个条件不满足那么结果就为假。 c. 或 满足其中一个条件结果就为真如果条件全部为假那么结果就为假。 d. 非 条件为假结果才为真。 B. 因果图法设计测试用例的步骤 分析所有可能的输入和可能的输出。 找出输入与输出之间的对应关系。 设计判定表。把判定表对应到每一个测试用例。 C. 判定表 判定表Decision table是一种表达逻辑判断的工具。 【淘宝 618 活动】 假设业务单据的处理规则为 “ 淘宝 618 活动订单已提交订单合计金额大于 300 元或有红包则优惠” 。 a. 对于这条业务规则首先通过分析所有可能的输入和可能的输出可以得到如下结果 输入订单已提交、金额大于 300、有红包。 输出优惠、不优惠。 b. 第二步找出输入与输出之间的对应关系。通过分析可以看出有以下的对应关系。 订单已提交订单金额大于300元有红包则优惠。 订单已提交订单金额大于300元没有红包则优惠。订单已提交订单金额小于等于300元有红包则优惠。订单已提交订单金额小于等于300元没红包则不优惠。订单不提交订单金额大于300元有红包则不优惠。订单不提交订单金额大于300元没有红包则不优惠。订单不提交订单金额小于等于300元有红包则不优惠。订单不提交订单金额小于等于300元没红包则不优惠。 c. 设计判定表 d. 把判定表对应到每一个测试用例 可以在后面补充符合要求的测试要素。 4正交排列 因果法设计用例太多怎么办 正交法的目的是为了减少用例数目。用尽量少的用例覆盖输入的两两组合。 正交试验设计Orthogonal experimentaldesign是研究多因素多水平的一种设计方法它是根据正交性由试验因素的全部水平组合中挑选出部分有代表性的点进行试验通过对这部分试验结果的分析了解全面试验的情况找出最优的水平组合。正交试验设计是一种基于正交表的、高效率、快速、经济的试验。 因素Factor在一项试验中凡欲考察的变量称为因素变量。水平位级Level在试验范围内因素被考察的值称为水平变量的取值。正交表的构成行数Runs正交表中的行的个数即试验的次数用 N 代表。 因素数Factors正交表中列的个数用 C 代表。 水平数 Levels 任何单个因素能够取得的值的最大个数。正交表中的包含的值为从 0 到数 “ 水平数 -1” 或从 1 到 “ 水平数 ” 用 T 代表。 A. 正交表的表示形式 L 行数 ( 水平数 * 因素数 ) LN(TC) B. 正交表的两条性质 每一列中各数字出现的次数都一样多。任何两列中的各有序数对出现的次数都一样多。 C. 正交法设计测试用例的步骤 充分理解需求有哪些元素(变量) - 确定因素水平每个因素有哪几个水平(变量的取值) - 画正交表选择一个合适的正交表把变量的值映射到表中 - 补充正交表 - 将正交表转换成测试用例把每一行的各因素水平的组合作为一个测试用例加上你认为可疑且没有在表中出现的用例组合 【注册的需求】 姓名、邮箱、密码、确认密码、验证码必须全部输入才能进行注册。 1、因素 姓名、邮箱、密码、确认密码、验证码 2、水平 填写、不填写 利用 allpairs 画正交表
1先将水平和因素填写到 excel 表格中 2将 excel 表格内容复制到 .txt 文件中 3CtrlS 保存到 allpairs 的下载路径 4进入 cmdwindowsR将路径切换到 allpairs 安装路径下 进入到 allpairs 的目录下执行命令allpairs.exe 文件名 结果文件名 至此就可以看到生成了 20240506_result.txt 注意~ 意味着此时这个取值可以填写也可以不填写。 5场景设计法
场景设计法是针对整个流程进行设计的。
现在的软件几乎都是用事件触发来控制流程的事件触发时的情景便形成了场景而同一事件不同的触发顺序和处理结果就形成事件流。该方法可以比较生动地描绘出事件触发时的情景有利于测试设计者设计测试用例是测试用例更容易理解和执行。
典型的应用是是用业务流把各个孤立的功能点串起来为测试人员建立整体业务感觉从而避免陷入功能细节忽视业务流程要点的错误倾向。 【注册】 想象注册的场景来设计用例这与根据需求的业务流来设计差不多。主要是想象各种业务流来设计用例。例如我们可以再想象以下场景 用户激活后再次点击邮件激活链接。已注册用户再次注册。 【ATM 取款】 通常情况下需要将用户经常使用的功能模块串在一起进行测试。 6错误猜测法
错误猜测法是对被测试软件设计的理解过往经验以及个人直觉推测出软件可能存在的缺陷从而针对性地设计测试用例的方法。
错误猜测法更多依靠的是经验。这个方法强调的是对被测试软件的需求理解以及设计实现的细节把握还有个人的经验和直觉。
错误推测法和目前流行的“探索式测试方法”的基本思想一致这类方法在敏捷开发模式下的投入产出比很高被广泛应运于测试。
这个方法的缺点是难以系统化并且过度依赖个人能力。 【注册】 校验中特殊字符空格的处理。密码校验中的大小写。姓名中的特殊字符。密码发送是否明文。 如何模拟弱网
1、借助工具Fiddler / Charles 2、打开限速模式 上传 1kb 文件需要花费 300ms下载 1kb 需要花费 150ms这里的数字越小说明网速越好 如何测试接口需要回顾
1、借助工具PostmanCanary/ 代码
2、http 方法进行测试 3、针对接口的参数进行测试
1参数通过 parameter 传递
传参数不传参数传入非法参数 2通过 json 传递 写一个冒泡参数针对这个代码如何测试呢 方法参数参数类型、不给参数、参数传递为空等异常处理除零错误代码规范语句覆盖涉及白盒测试、条件覆盖、语句条件覆盖、判定覆盖...... ... 针对 Linux 中 zip 这个命令如何进行测试呢
功能
打包的是一个不存在的文件命令使用正确文件存在文件是否被压缩能否一次性打包多个文件打包后的文件内容是否有缺失
界面
打包后的 zip 高亮打包后的文件后缀名为 .zip
易用
输入错误是否会有提示
性能
打包 1Kb 的文件需要多长时间打包 1Gb 的文件需要多长时间一次打包多个文件需要多长时间 【测试用例设计万能公式】
1功能
物体这个物体是用来干什么的软件软件实现功能
2界面
物体外表、材质、大小、容量...软件界面、字体大小、字体颜色、页面布局...
3易用
经验操作简单、操作流程、人性化符合人体工学、见名知意
4兼容
物体物体除了本质的功能外是否还有其它功能软件操作系统电脑windows、mac、linux、手机ios、Android、设备、浏览器版本
5性能
物体使用寿命软件响应时间、吞吐量、并发数、CPU占用率
6安全
物体物体材质是否有毒物体是否会对人体健康造成伤害软件sql 注入、xxs 漏洞、输入有毒脚本、密码加密保存、权限控制
7网络
软件2G~5G、弱网、Wifi
8中断
物体闹钟、短信、电话软件切换到桌面 【水杯测试用例】 【微信发送朋友圈测试用例】 三、测试用例的有效性
1、什么是测试用例的有效性
测试用例对应的功能已删除不可操作了。比如微信刚出来时与 QQ 可以互发消息下一个版本后就不可以发消息。
执行一条测试用例未发现 BUG实际该处有 BUG。iPhone7 手机微信添加了 mobile 单车小程序扫码不能开锁只能使用 mobile APP 开锁测试用例未涉及到 iPhone7 微信小程序扫码开锁。
执行一条测试用例发现了 BUG。iPhone7 手机微信添加了 mobile 单车小程序用例已写到了 iPhone7 微信添加 mobile 小程序扫码开锁问题被发现。
执行一条测试用例未发现 BUG实际该处 BUG 已修改。iPhone7 手机微信添加了 mobile 单车小程序扫码开锁可以正常开锁。 四、测试用例的粒度和评价
1、测试用例的粒度 好的测试用例是一个不熟悉业务的人也能依据用例来很快的进行测试。 粒度指测试用例编写的详细程度。 测试用例可以写得很简单也可以写得很复杂。最简单的测试用例是测试的纲要仅仅指出要测试的内容如探索性测试中的测试设计仅会指出需要测试产品的哪些要素、需要达到的质量目标、需要使用的测试方法等。而最复杂的测试用例就像飞机维修人员使用的工作指令卡一样会指定输入的每项数据期待的结果及检验的方法具体到界面元素的操作步骤指定测试的方法和工具等。 1测试用例写得过于复杂或详细会带来两个问题一个是效率问题另一个是维护成本问题。另外测试用例设计得过于详细留给测试执行人员的思考空间就比较少容易限制测试人员的思维。 2测试用例写得过于简单则可能失去了测试周例的意义。过于简单的测试用例设计其实并没有进行 “设计”只是把需要测试的功能模块记录下来而已它的作用仅仅是在测试过程中作为一个简单的测试计划提醒测试人员测试的主要功能包括哪些而已。测试用例的设计的本质应该是在设计的过程中理解需求检验需求并把对软件系统的测试方法的思路记录下来以便指导将来的测试。
大多数测试团队编写的测试用例的粒度介于两者之间。而如何把握好粒度是测试用例设计的关键也将影响测试用例设计的效率和效果。应该根据项目的实际情况、测试资源情况来决定设计出怎样粒度的测试用例。
主要考虑可以参考如下内容
产品的质量要求。项目对用例的要求。测试时间和资源是否充分。 注意 不管用例怎么简化都不应该省略。 2、测试用例的评价 测试用例设计出来了如何提高测试用例设计的质量就像软件产品需要通过各种手段来保证质量一样测试用例的质量保证也需要综合使用各种手段和方法。评审分为正式和非正式评审。 同行评审 用户检查 项目组评审 1测试用例的检查可以有多种方式但是最敏捷的应当属临时的同行评审。 同行评审尤其是临时的同行评审应该演变成类似结对编程一样的方式。从而体现敏捷的 “个体和交互比过程和工具更有价值”要强调测试用例设计者之间的思想碰撞通过讨论、协作来完成测试用例的设计原因很简单测试用例的目的是尽可能全面地覆盖需求而测试人员总会存在某方面的思维缺陷一个人的思维总是存在局限性。因此需要一起设计测试用例。 2除了同行评审还应该尽量引入用户参与到测试用例的设计中来让用户参与评审从而体现敏捷的 “顾客的协作比合同谈判更有价值” 这一原则。 这里顾客的含义比较广泛关键在于如何定义测试如果测试是对产品的批判则顾客应该指最终用户或顾客代表在内部可以是市场人员或领域专家如果测试是被定义为对开发提供帮助和支持那么顾客显然就是程序员了。 3由测试负责人组织协调开展会议用例编写人对用例进行讲解参会人员有异议的当场提出。 【某手机软件有用 TF 卡导出数据的功能】 请写出测试此功能点的思路
