心中的测试用例结构 为新模型做准备
创始人
2024-07-29 05:11:23
0次

记得去年年初的时候,就做过关于如何写的分享,说了为什么要写测试用例,什么是测试用例,如何写测试用例,什么样的才叫好的用例,什么样的叫不好的用例,也说了写用例的纠结:前提条件和执行步骤的纠结;测试用例标题的纠结;预期结果的验证的纠结等等。

个人觉得讲得很详细了,觉得效果不错的,为啥后来那些培训的同学对于写测试用例没有一个系统的概念呢,不知道怎么去写一个好的用例呢?这个blog的作用不是讲这些,而是说下工作一两年内都很容易出现的用例结构问题。你去问一线测试工程师,资深测试工程师,TL,Manager,甚至是Director,都不能对怎么写好用例达成一个共同的意识,以及共同的作业方式,当然我们不期望流程化,死板化,但我希望我们不要忘了我们的测试信念,我们的质量意识。

背景介绍:今年部门大量采用新模型进行项目测试,将去年做好基础的自动化测试,接口测试用到项目过程中去,真正的做到测试提前,为开发质量提高更早,更前面的保证和跟踪。模型注意改进点在开发Coding阶段,我们先看下以前SPR模型下,测试做了哪几个工作:

1. 接口说明文档评审

2. 数据库设计文档评审

3. 测试设计

4. 测试用例编写

5. 测试用例评审和修改

相比较旧模型而言,下面再看下新模型下,测试又会去做什么呢:

1. 制定测试开发计划

2. 接口说明文档评审

3. 数据库设计文档评审

4. 自动化测试设计

5. 自动化测试脚本开发准备(Page Model 和 DB model的建立;自动化脚本伪代码编写)

6. 接口测试设计

7. 接口测试脚本开发(搭建接口测试环境,接口测试代码编写,调试,后期Hudson上回归)

8. 自动化测试脚本和接口测试设计评审和修改

9. Code Review

大家是不是感觉到了明显的变化,那就是我们测试需要做更多的前期事情,那这样我们就需要对我们的测试用例模型(MM图)进行改进,以适应新的变化。对于做MM图,我自己对MM图的理解也许和大家不一样,我每次做项目,做出来的MM图都比较细,不仅仅是列出我要测试的每个功能点,而且每个功能点的测试设计和测试场景都写出来了,而且我觉得一个非常好的MM图(测试设计)需要经过如下三个步骤:

MM 1 ——— PRD阶段,使用RBT方法做出来的MM图(功能点划分,P1 和 P2的用例场景)

MM 2 ——— UC阶段,使用RBT方法强烈Review UC做出来的MM图(补充P1 和 P2的用例场景,P3和P4的用例场景)

MM 3 ——— 系统设计阶段,通过Review接口说明文档,详细设计文档,数据库设计文档(补充每个功能点容易遗漏的异常场景和详细校验点)

当然这里面的MM 图不是一成不变的,在测试执行阶段,这个MM图也会新增或修改测试思路(特别是发现了一些用例没有写的bug),下面就看一下例子吧:

那么如果我们使用了新模型后,我们的MM图就必须加一些标记了,新模型的coding阶段,我们测试人员没有太多时间去编写详细的测试用例,我们有很多的自动化测试用例和接口测试用例,这时我们的MM图就可以变成这样了:

注意上图的Automan就是自动化测试脚本的标记,iTest就是接口测试脚本的标记,另外一个就是Manual了。

当然也不能简单了,我们最好能把自动化测试脚本和接口测试脚本编写的环境连接起来,比如我打开了一个标记为自动化测试用例的环境,如下:

Page Model,DB Model 和 Ruby编程环境,能够把用例标题写入脚本模板中

再比如我打开了一个标记为接口测试用例的环境,如下:

Java代码编写环境,能够把用例标题写入脚本模板中,优化脚本模板

其实这里面区别开我们的手工测试用例,自动化测试用例,接口测试用例可以有2种方式:

1. 一种是在功能点来进行划分:细分到一个很小的功能点,写测试思路的时候,不用Care是什么类型的测试用例,最好评审完后,加上一个简单的标记即可,上图的方式就是这种方式,就是统计数据比较麻烦一点。

2. 另一种是根据用例类型来划分:首先划分3个维度,然后再维度后面加上自己的功能点的测试思路

这样做的优点就是很清晰的知道不同的测试类型的用例个数或复杂度等,但注意这里面有个缺点:就是有可能一个功能点会存在多个不同的测试类型,所以本人建议使用第一种方式来做。

最后需要强调的是我们的测试思路的标题一定要是可见性的,正确性的,目的性的。另外如何在一个功能需求模块中把这些用例结构清晰的抽象出来,需要多思考,需要对于即将测试的需求有整体性的把握,然后在完善MM图的过程中不断的调整用例MM结构图,使其能让开发清楚的知道我们即将要测试哪些点。我们也可以很快捷方便的完善我们的所以测试思路。

最后说明下,这里的测试思路的载体MM图,如何去进行组织用例结构和思路编写规范,是需要一些探索式测试ET 的一些技巧的,特别是测试设计和测试执行的相关注意点。

【编辑推荐】

  1. 浅谈测试用例分析和设计
  2. 如何有效减少测试用例数目
  3. 测试用例设计方法1 等价类边界值
  4. 测试用例设计方法2 因果图判定表

相关内容

热门资讯

PHP新手之PHP入门 PHP是一种易于学习和使用的服务器端脚本语言。只需要很少的编程知识你就能使用PHP建立一个真正交互的...
网络中立的未来 网络中立性是什... 《牛津词典》中对“网络中立”的解释是“电信运营商应秉持的一种原则,即不考虑来源地提供所有内容和应用的...
各种千兆交换机的数据接口类型详... 千兆交换机有很多值得学习的地方,这里我们主要介绍各种千兆交换机的数据接口类型,作为局域网的主要连接设...
粉嫩如何诠释霸道 东芝M805... “霸道粉”是个什么玩意东芝M805拿过来的时候,笔者扑哧笑了,不是笑这款笔记本,而是笑这款产品的颜色...
如何利用交换机和端口设置来管理... 在网络管理中,总是有些人让管理员头疼。下面我们就将介绍一下一个网管员利用交换机以及端口设置等来进行D...
什么是大数据安全 什么是大数据... 在《为什么需要大数据安全分析》一文中,我们已经阐述了一个重要观点,即:安全要素信息呈现出大数据的特征...
全面诠释网络负载均衡 负载均衡的出现大大缓解了服务器的压力,更是有效的利用了资源,提高了效率。那么我们现在来说一下网络负载...
如何允许远程连接到MySQL数... [[277004]]【51CTO.com快译】默认情况下,MySQL服务器仅侦听来自localhos...
30分钟搞定iOS自定义相机 最近公司的项目中用到了相机,由于不用系统的相机,UI给的相机切图,必须自定义才可以。就花时间简单研究...
Windows恶意软件20年“... 在Windows的早期年代,病毒游走于系统之间,偶尔删除文件(但被删除的文件几乎都是可恢复的),并弹...