文章目录
- 回顾一:上篇博客[软件测试- 基础篇 ](https://blog.csdn.net/DarkAndGrey/article/details/125318528?spm=1001.2014.3001.5502)
- 回顾二:[概念篇](https://blog.csdn.net/DarkAndGrey/article/details/125281778?spm=1001.2014.3001.5502)
- 软件测试 - 用例篇
回顾一:上篇博客软件测试- 基础篇
回顾二:概念篇
1、什么是测试用例?
2、为什么软件测试人员要写测试用例?
软件测试 - 用例篇
简单来说:这篇博客就开始教大家怎么去写一个测试案例!
测试用例的基本要素
测试用例的设计方法
PS:讲解顺序不是按照上米南的顺序来的。
基于需求设计测试用例
总结
有的人可能觉得有点糊,你确定是在讲 “基于需求设计测试用例”嘛?
实战案例 - 日历系统
需要注意的是:上面提到这些非功能性的测试(易用性,兼容性,性能,安全性,可移植性,可维护性),不是所有的,都要测试!
不同的应用软件 对于 以上 非功能性的要求 是 不一样的!!!
比如:
1、面向客户端的软件:【画图板,office,Word,xmind】
2、面向企业内部的软件
比如:飞Q,飞书(字节跳动)。。。。这种用于企业内部员工使用的交流软件。
3、大型的商用软件
比如:微信,QQ
具体的设计测试用例的方法
等价类
下面,我们再来举个例子,了解一下 等价类的应用场景。
边界值
而我们测试中的边界值,是 输入 和 输出 的边界。
我们要针对 输入 和 输出 的 边界 进行 测试用例的设计。
tips (建议):等价类 和 边界值 结合在一起进行测试用例的设计。
因为 等价类 的 测试用例中,就包含着 边界值 测试用例。
只不过在等价类中是分离开的,有效等价类 和 无效等价类。
错误 猜测法
错误 猜测法,有点类似于 探索性测试。
案例 - 水杯测试 - 培养的思维
场景设计法
因果图法
首先,因果图 是 一种逻辑图,它具有 恒等,与,或,非 逻辑。
用因果图来设计测试用例,就叫做因果图法。
下面我们来看一下:因果图法 设计测试用例 的 步骤
正交排列 - 了解即可
正交排列的运用场景
正交表的构成:
正交表的两条性质:
正交法设计测试用例的步骤:
案例:
3、测试用例的有效性
2、执行一条测试用例未发现BUG,实际该处有BUG
4、执行一条测试用例发现了BUG
5、执行一条测试用例未发现BUG,实际该处BUG已修改
4、测试用例的粒度和评价 - 了解
测试用例的粒度
测试用例可以写得很简单,也可以写得很复杂。最简单的测试用例是测试的纲要,仅仅指出要测试的内容,如探索性测试中的测试设计,仅会指出需要测试产品的哪些要素、需要达到的质量目标、需要使用的测试方法等。
而最复杂的测试用例就像飞机维修人员使用的工作指令卡一样,会指定输入的每项数据,期待的结果及检验的方法, 具体到界面元素的操作步骤,指定测试的方法和工具等。
测试用例的评价
(1)测试用例的检查可以有多种方式 但是最敏捷的应当属临时的同行评审。同行评审,尤其是临时的同行评审,应该演变成类似结对编程一样的方式。从而体现敏捷的“个体和交互比过程和工具更有价值”,要强调测试用例设计者之间的思想碰撞,通过讨论、协作来完成测试用例的设计,原因很简单,测试用例的目的是尽可能全面地覆盖需求,而测试人员总会存在某方面的思维缺陷,一个人的思维总是存在局限性。因此需要一起设计测试用例。
(2)除了同行评审,还应该尽量引入用户参与到测试用例的设计中来,让用户参与评审,从而体现敏捷的“顾客的协作比合同谈判更有价值”这一原则。这里顾客的含义比较广泛,关键在于如何定义测试,如果测试是对产品的批判,则顾客应该指最终用户或顾客代表(在内部可以是市场人员或领域专家);如果测试是被定义为对开发提供帮助和支持,那么顾客显然就是程序员了。
(3) 由测试负责人组织协调开展会议,用例编写人对用例进行讲解,参会人员有异议的当场提出。
实战测试用例:百度云盘的测试用例 - 自己可以参考这个写一个。
百度云盘功能需求分析 - 粗略版