软件测试------用例篇

软件测试用例总结

• 测试用例的基本要素
• 测试用例的设计方法
  • 基于需求的设计方法
  • 等价类
  • 边界值
  • 因果图
  • 正交排列
  • 场景设计法
  • 错误猜测法
• 测试用例的有效性
• 测试用例的粒度和评价

---

测试用例的基本要素

• 回归测试的的概念：测试用例是为了实施测试而向被测试系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。（好的测试用例是一个不熟悉业务的人也能依据用例来很快的进行测试）

• 评价测试用例的标准：

  • 用例表达清楚，无二义性
  • 用例可操作性强
  • 用例的输入与输出明确，一条用例只有一个预期结果
  • 用力的可维护性好
  • 用例对需求的覆盖性高
  • 暴露程序Bug的能力强

测试用例给我们带来的好处

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

• 使用中带来的困扰
  测试用例的设计是费时费力的工作，往往设计测试用例所花费的时间比执行所花费的时间还多
• 解决如下问题
  测试的覆盖率无法衡量；对新版本的重复测试很难实施
  不确定是否较全面的测试了所有功能；存在大量冗余测试影响测试效率

测试用例的设计方法

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

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

• 验证需求是否正确、完整、无二义性，并且逻辑一致。
• 要从”黑盒“的角度，设计出充分且必要的测试集，以保证设计和代码都能完全符合需求。
• 案例
  
  软件需求：
  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、激活URI正确，可激活
  4、再次激活提示已激活
  5、过期激活提示已过期

具体的设计方法

等价类

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

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

边界值

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

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

因果图

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

• 因果图法设计测试用例的步骤如下：
  • 分析所有可能的输入和可能的输出。
  • 找出输入与输出之间的对应关系。
  • 画出因果图。
  • 把因果图转换位判定表。
  • 把判定表对应到每一个测试用例。
    因果法设计测试用例可以帮助测试人员理清输入和输出的关系，但是对于比较复杂的输入和输出，会耗费大量时间。

正交排列

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

• 实际中这种做法不常见，科学实验性更重要，实际中会看代码或者想象可能的代码来减少用例。

场景设计法

• 现在的软件几乎都是用事件触发来控制流程的，事件触发时的常见便形成了场景，而同一个事件不同的触发顺序和处理结果就形成了事件流。该方法可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，使测试用例更容易理解和执行。

• 典型的应用是用业务流把各个孤立的功能点串起来，为测试人员建立整体业务流程，从而避免陷入功能细节而忽视业务流程要点的错误倾向。

错误猜测法

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

测试用例的有效性

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

测试用例的粒度和评价

粒度：指测试用例编写的详细程度。
主要考虑可以参考如下内容：

• 产品的质量要求
• 项目对用例的要求
• 测试时间和资源是否充分
  但是不管用例怎么简化，都不应该省略。

测试用例的评价

测试用例的质量保证需要综合使用各种手段和方法，评审分为正式和非正式评审。

• 同行评审
• 用户检查
• 项目组评审

面试案例

笔试题：某手机软件有用TF卡导出数据的功能，请写出测试此功能点的思路。

来源：CSDN

作者：一零二四bit

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