软件测试之用例总结

最新推荐文章于 2024-08-01 15:23:46 发布

一零二四bit

最新推荐文章于 2024-08-01 15:23:46 发布

阅读量625

点赞数

分类专栏：测试

本文链接：https://blog.csdn.net/qq_41906009/article/details/104069772

版权

4 篇文章 1 订阅

订阅专栏

软件测试用例总结

回归测试的的概念：测试用例是为了实施测试而向被测试系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。（好的测试用例是一个不熟悉业务的人也能依据用例来很快的进行测试）
评价测试用例的标准：
- 用例表达清楚，无二义性
- 用例可操作性强
- 用例的输入与输出明确，一条用例只有一个预期结果
- 用力的可维护性好
- 用例对需求的覆盖性高
- 暴露程序Bug的能力强

* 测试执行者的依据
* 使得工作可重复，自动化测试的基础
* 评估需求的覆盖率
* 用例的复用
* 积累测试的方法思路以供后续借鉴

基于需求的设计
RBT是基于需求的测试方法，会使测试更加高效，因为它使测试专注于质量问题产生的根源，即需求。

基于需求的测试是一种最根本的软件测试，重点关注于以下两个关键问题：

思路：输入的集中是无穷的，不能都覆盖到

依据需求的将输入（特殊情况下会考虑输出）划分为若干个等价类，从等价类中选出一个测试用例，如果这个测试用例测试通过，则认为所代表的等价类测试通过，这样就可以用较少的测试用例达到尽量多功能覆盖，解决了不能穷举测试的问题。
- 有效等价类：对于程序的规格说明书是合理的、有意义的输入数据构成的集合，利用有效等价类验证程序是否实现了规格说明中所规定的功能和性能。
- 无效等价类：根据需求说明书，不满足需求的集合。
等价类只考虑输入域的分类，没有考虑输入域的组合，需要其他的设计方法和补充。
eg:用户名由长度为6-15位的字符串组成，那么针对字符有效等价类为A-Z，a-z，无效等价类为两个：数字：1，0，1，-1；特殊字符：@，#，￥，空

边界值分析法就是对输入输出的边界值进行测试的一种黑盒测试方法，通过边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。
eg:

输入框长度为1-11，取边界值为：1、22、12、0.
查询页面有999行，每50行为一页，取边界值为：输出0行、1行、50行、51行、999行。
以注册邮箱的软件需求为例：用户名要求长度为6-15位，边界值上的点为：5、6、15、16全了吗？
- 在实际的测试设计中，会将等价类和边界值结合起来使用，因此最终可以确认的用例设计为：5，6，10，15，16五个长度的字符的输入值。
- 除此之外，测试并没有完整，中文？半角？全角？特殊字符（扩展字符）

因果图是一种简化了的逻辑图，能直观地表明程序输入条件（原因）和输出动作（结果）之间的相互关系，因果图法是借助图形来设计测试用例的一种系统方法，特别适用于被测试程序具有多种输入条件、程序的输出又依赖于输入条件的各种情况。

正交法的目的是为了减少用例数目，用尽量少的用例覆盖输入的两两组合。

现在的软件几乎都是用事件触发来控制流程的，事件触发时的常见便形成了场景，而同一个事件不同的触发顺序和处理结果就形成了事件流。该方法可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，使测试用例更容易理解和执行。
典型的应用是用业务流把各个孤立的功能点串起来，为测试人员建立整体业务流程，从而避免陷入功能细节而忽视业务流程要点的错误倾向。

错误猜测法是经验丰富的测试人员喜欢用的一种测试方法。
基于经验和直觉，找出程序中你认为可能出现的错误，有针对性地设计测试用例。**经验可能来自于对某项业务的测试较多，也可能来自于售后用户的反馈意见，也可以来自于售后用户的反馈意见，或者从故障管理库中整理bug。**梳理出产品以往哪些地方容易出现问题，问题越多的地方，潜在的bug也就越多。

测试用例对应的功能已删除，不可操作了
- 微信刚出来时可与QQ互发消息，下一个版本后就不可以发消息。
执行一条测试用例未发现BUG，其实此处有BUG
- 测试用例中未涉及苹果７微信小程序扫码开机问题。导致未发现苹果７手机微信添加mobile单车小程序，扫码不能开锁的BUG。
执行一条测试用例发现了BUG
执行一条测试用例未发现BUG，实际该处的BUG已修改