大家好,我是bug郭,一名双非科班的在校大学生。对C/JAVA、数据结构、Spring系列框架、Linux及MySql、算法等领域感兴趣,喜欢将所学知识写成博客记录下来。 希望该文章对你有所帮助！如果有错误请大佬们指正！共同学习交流

作者简介:

• CSDN java领域新星创作者blog.csdn.net/bug…
• 掘金LV3用户 juejin.cn/user/bug…
• 阿里云社区专家博主,星级博主,developer.aliyun.com/bug…
• 华为云云享专家 bbs.huaweicloud.com/bug…

场景法

很多软件不同场景,是基于不同事件触发,导致场景走不同的事件流!
不同的功能点串起来形成一个场景.不同的功能点又有不同的输入,不同的输出导致不同的测试场景

例如ATM取款场景

插卡-> 输入密码->输入取款数->取款->退卡

每个步骤都可能导致不同的测试场景
这里就类似于一个事务,只有所有操作都通过了,这个事务才成功,如果其中一个操作失败了,事务也就执行失败

错误猜测

根据测试人员的测试经验,知识的积累,自觉,对自己认为有bug的模块进行专门的测试用例的设计,类似于探索性测试

正交分析法

根据正交分析来测试设计用例,从大量的实验数据中根据正交原则取出最优的数据组合,根据最优集合测试的结果,来分析整个测试结果

测试用例的有效性

• 测试用例对应的功能已经删除,不可操作了
• 执行一条测试用例未发现bug,但实际上此处有bug
• 执行一条测试用例发现了bug
• 执行一条测试用例未发现bug,此处bug已修改

测试用例的粒度和评价

测试用例的粒度

好的测试用例是一个不熟悉业务的人也能依据用例来很快的进行测试
粒度: 指测试用例编写的详细程度

• 测试用例写的过于复杂和详细带来的问题

1.效率问题2.维护成本问题.测试用例写的过于详细,留给测试人员思考的的空间比较少,容易限制测试人员的思维!

• 测试用例写的过于简单,则可能失去了测试用例的意义

它的作用仅仅是在测试过程中作为一个简单的测
试计划，提醒测试人员测试的主要功能包括哪些而已。测试用例的设计的本质应该是在设计的过程中理解需求，检验需求，并把对软件系统的测试方法的思路记录下来，以便指导将来的测试。

大多数编写测试用例的粒度介于这2者之间,主要通过下面方面考虑

• 产品的质量要求
• 项目对用例的要求
• 测试时间和资源是否充分

用例可以简化,但是不能省略

测试用例的评价

测试用例设计出来了,如何提高用例的质量呢?测试用例的质量保证需要综合各种手段和方法.评审分为正式和非正式评审.

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

(1)测试用例的检查可以有多种方式 但是最敏捷的应当属临时的同行评审。同行评审，尤其是临时的同行评审，应该演变成类似结对编程一样的方式。从而体现敏捷的“个体和交互比过程和工具更有价值”，要强调测试用例设计者之间的思想碰撞，通过讨论、协作来完成测试用例的设计，原因很简单，测试用例的目的是尽可能全面地覆盖需求，而测试人员总会存在某方面的思维缺陷，一个人的思维总是存在局限性。因此需要一起设计测试用例。
（2）除了同行评审，还应该尽量引入用户参与到测试用例的设计中来，让用户参与评审，从而体现敏捷的“顾客的协作比合同谈判更有价值”这一原则。这里顾客的含义比较广泛，关键在于如何定义测试，如果测试是对产品的批判，则顾客应该指最终用户或顾客代表（在内部可以是市场人员或领域专家)；如果测试是被定义为对开发提供帮助和支持，那么顾客显然就是程序员了。
(3) 由测试负责人组织协调开展会议，用例编写人对用例进行讲解，参会人员有异议的当场提出。