将面向对象的思想带入TC

简介:

写TC貌似是很简单的工作,但当动手写的时候往往会出现,不知道写什么,又感觉有一堆的东西需要写,即使一个简单的日常也会觉得里面的逻辑非常复杂,然后就是晕得不知所向。
  个人认为,写TC没有固定的模式,也没有唯一的答案,每个人的方式不同,习惯不同,TC中的如何分类归纳也就自然不相同。但目标是一致的,基本目标是覆盖需求、无盲区;加强目标是加深测试点,完善用户友好性等。

  下面分享下我写TC的几种思路。

  第一种思路——先对象,后流程

  面向对象是在平常入门学习中 首先接触到的概念,它不仅仅存在于代码的编写中,更存在于我们的工作方式和方法中。首先分析需求中涉及到哪些对象,比如页面是一个对象,对它加以细化,页 面大对象可能又分为新增页面,修改页面,删除页面和查询页面等,或者从功能上划分为卖家页面、小二页面等。分析完后再层层细化,比如新增页面包含的哪些文 本的输入框,单选/多选项、日历控件,以及它们之间操作的优先级,错误提示的优先级等等,再洗化到各个控件本身的限制检查,如单行文本最长和最短的校验长 度是多少,非法字符校验等。

  当所有对象类信息完成后,再考虑这些对象之间的流程关系,比如对用户身份审核的操作必须建立在用户身份信息 已创建之后,或者信息被修改后。不光是需要校验正常的操作流程,还需要花大精力放在异常流程的操作上,比如用户在填写信息时,突然中断了操作,这样的情况 通过什么样的流程去处理。因此这里的流程,应该是包括正常流、异常流及扩展流(需求中未涉及,但测试人员基于用户友好或者性能方面考虑需要加入的流程)。

  回过头想一想,我们说,把面向对象的思想带入TC,那面向对象又体现在什么地方呢,难道仅仅是分类么?NO!

   我们是不是经常会在写TC中碰到这样的问题,比如某些项目中,进行查看和修改时,发现自己看到的是相同的页面,也就是可能在做不同操作流程的时候发现到 达了相同的一个出口,那对于这N个流程是否需要写N个平行的TC,是否可以把某部分写成公共模块以提高效率,避免冗余呢。

  第一种思路可 能会有同学觉得很麻烦,很容易复杂化,确实是的,因为大家平常做项目或日常时,至少是有页面或者页面大概的原形,如果需求是很模糊的,又或者客户也不知道 具体是要做成什么样的,同时客户又希望能快速立项的情况下,可以使用这种方式,其实在这样的过程中,测试人员无形中担当了架构的角色,并且能帮助开发完善 产品。

  第二种思路——先流程,再对象

  这种思路,要求是页面设计到位,至少是大概的原形具有,然后对着原形写TC。

   从打开的第一个页面开始层层深入写,比如首先是用户登陆,然后是主展示页面,再可能是搜索宝贝等,先把流程正常流程建立好,然后将这些流程细化,如用户 登陆是否采用弹出窗口,窗口的位置、大小,窗口中的表单项是否完整,如是不是缺少验证码项,再考虑某一项的校验,如用户名是否为单行文本,长度限制多少, 非法字符限制,是否为必填项(不填是否有提示)等。

  使用这种思路的时候,切记至少要包含几类信息:页面总体展示、表单项完整性、表单项正确性、表单项可操作性(独立操作和组合操作)、表单项非法校验、及当前页面的其他跳转出口(如点击“登陆”,在用户输入的信息正确的情况下,应跳转到主展示页面)。

  这种思路可能使用的同学比较多,至少我是经常用的。这里实际上还是把页面当成了大对象,当出现多类页面跳转到相同页面上去的时候,这个相同页面就可以作为公共部分来使用了。

  记得在学校里学习这些原理的时候,对它的用法感悟不深刻,出来工作以后发现,其实很多思想就穿插在平时的应用中,所以有一句话很欣赏:解决问题,思路很重要,技术在其次。

  以上是对于写TC思路的一些个人看法,有不足之处还请大家指正。

本文出自seven的测试人生公众号最新内容请见作者的GitHub页:http://qaseven.github.io/

目录
相关文章
|
9月前
|
设计模式 安全 Go
Go中按次序交替打印1212...,你知道它背后的设计模式吗
Go中按次序交替打印1212...,你知道它背后的设计模式吗
|
4月前
|
算法
lingo中的一些概念解释
lingo中的一些概念解释
|
9月前
|
安全 C#
案例18-案例开门小例子面向对象演化
案例18-案例开门小例子面向对象演化
|
10月前
|
存储 Java 程序员
【C#本质论 六】类-从设计的角度去认知(封装)(上)
【C#本质论 六】类-从设计的角度去认知(封装)(上)
86 0
|
10月前
|
编译器 C#
【C#本质论 六】类-从设计的角度去认知(封装)(下)
【C#本质论 六】类-从设计的角度去认知(封装)(下)
68 0
|
敏捷开发 人工智能 开发者
Code Smell 重构你的日常代码-圈复杂度高多层嵌套
圈复杂度(Cyclomatic complexity)[1]是一种代码复杂度的衡量标准,在1976年由Thomas J. McCabe, Sr. 提出。条件分支越多,圈复杂度越高,测试越难覆盖,也越难维护。随着业务的不断演进,代码的不断新增与调整,如果只在原逻辑下加入自己的新逻辑,就会长出一个超高嵌套的“气功波”代码。
Code Smell 重构你的日常代码-圈复杂度高多层嵌套
|
搜索推荐
提出好问题引出一个好答案
在你和你想要的东西之间,只差一连串更好的问题。 -- 《巨人的方法》
164 0
提出好问题引出一个好答案
|
存储
秒懂高阶编程之函数绑定及柯理化函数思想
秒懂高阶编程之函数绑定及柯理化函数思想
98 0
秒懂高阶编程之函数绑定及柯理化函数思想
|
设计模式 Java
面向对象的设计原则最终篇(一)
关于面向对象的设计原则我之前已经解释过四种了,分别是单一职责原则,开放关闭原则,里式替换原则,依赖倒置原则而接下来我们要解释的就是最后的三种原则了,分别是接口隔离原则, 迪米特法则, 组合复用原则。
面向对象的设计原则最终篇(一)
|
设计模式
面向对象的设计原则最终篇(二)
关于面向对象的设计原则我之前已经解释过四种了,分别是单一职责原则,开放关闭原则,里式替换原则,依赖倒置原则而接下来我们要解释的就是最后的三种原则了,分别是接口隔离原则, 迪米特法则, 组合复用原则。
面向对象的设计原则最终篇(二)