首页 测试 体会 查看内容

新手的一年软件测试小结

2014-9-22 20:06| 发布者: informix| 查看: 676| 评论: 0

摘要:   时常会想自己为什么会选择测试,因为开发功底薄弱,而且测试的门槛较低,加上网络上对测试需求量大的宣传,也就选择了测试。假若自己选择开发,同样的付出,绝对是测试得到的回报更多些。也不曾想去争辩什么,觉 ...

  时常会想自己为什么会选择测试,因为开发功底薄弱,而且测试的门槛较低,加上网络上对测试需求量大的宣传,也就选择了测试。假若自己选择开发,同样的付出,绝对是测试得到的回报更多些。也不曾想去争辩什么,觉得虽然测试地位确实比不了开发,但是自己努力了知足就好。

  一年的经历,自己也从一个新手成长了很多,不得不说,作为测试很容易获得成就感,成长后就得总结或者思考,老大总是喜欢让我们写总结,每个版本,对于负责的特性进行总结输出文档,通过这样的方式,能对所学的业务进行梳理,但是对于自己所掌握的经验,却感觉有些虚无缥缈了,自己到底学到了么,以前总是喜欢说会XX业务,对XX流程更加熟悉了,现在觉得业务流程都是死的,但是测试思路貌似自己还没有形成雏形,苦思冥想也无法说出个啥,但是每次到新版本分析的时候,却总是能突然冒出其他想法,想对自己的所认知的流程进行梳理总结,希望能获得些什么。

  分析需求时,以为FRS(原始需求),总体方案,单部件方案为素材,三者可以用继承的关系描述,总体方案是为了实现FRS,而对于目标如何实现,总体方案提供了一个大概思路,再进行单部件分解需求。先看原始需求,将主要功能点罗列,带着这些功能点去阅读总体方案,功能点是否覆盖,最后去阅读单部件方案。分析时候将疑惑的地方进行标注,汇总问题提交给下需求人员,当总体方案与FRS实现不一致处,需要将情况通过邮件方式陈述给一线的。在需求分解阶段,喜欢使用XMind工具,画出思维导图,将需要实现的功能,重点关注的流程都罗列出,这样在写总体方案的时候容易有一个参照,避免需求遗漏。

  需求分解完毕,开始着手编写测试方案,测试方案的编写维度可以从角色入手,不同的角色会有不同的权限以及操作,比如管理员,权限较大,需要关注其操作是否会带来一些不可恢复的操作,比如类似rm -rf *的操作(残念,当年就干过一次啊,还好备份了),对于普通用户来说,权限的控制一块也是相当重要的。分析完不同角色的权限以及可以进行的操作,就可以考虑场景了,因为做的是解决方案的测试,所以和单部件测试区别还是很大的,只需要考虑端到端的场景。对于FRS上正常的场景必须要实现,对于一些其他场景可以采用交叉覆盖的方式进行验证,但是出现bug的地方,往往不会是基础的场景,这时候就得从总体流程入手,一种场景的流程,在其某个阶段,是否可以存在断层或者分支,人为操作是否可以介入干预,可以那此块就得考虑了。其实对于场景的考虑,也就是对各种影响因素的考虑。觉得最好的流程就是一气呵成,这样能减免很多误操作,但是很多时候,没办法,比如确认支付的场景,就得再三确认。对于场景的设计一块,必须需要关注是否对老功能造成影响,倘若新功能的实现影响了老功能,只能说是太失败了。

  方案写完就是方案评审了,毕竟一个人的力量总是有限的,再者这也是对流程的再一次梳理的过程。其实对于自己分析的方案是最熟悉的,但是对于使用客户来说,他怎么能清楚这些,这时候就得靠组内成员帮忙看待功能实现了,觉得这是相当必要的过程。在讲解的过程中,自己也得不断的思考,是不是这样就全了,虽然不可能达到全场景覆盖,但是保证基础功能的前提上,尽量考虑多的且很容易触发的场景。比如赠送应用场景,

  场景一、A赠送B,A购买

  场景二、A购买后赠送B,

  场景三、A赠送给A(一般人真心干不出......)

  场景四、B购买后,A赠送

  场景五、B被A赠送,后被C赠送

  ............(还有折扣场景)

  其实用枚举的话,场景还是相当相当多的,但是这也很明显,对于一个场景的结束端,难道就真的这样结束了么,比如场景二,赠送给B了,还可以继续下去赠送给C或者D吧,虽然结果很明显,但是还得要测下的。

  从后台流程的理解来看,用户本身有着自己的键值,产品也有,两者在交易列表中存储,形成关联关系,假若正常的购买流程purchasetype枚举值为1,就正常存储。若是赠送流程, purchasetype其枚举值是2,后台就根据枚举值进行判断,采取新的存储方式,将被赠送方与产品进行关联,赠送方存储在其他字段,之后拥有所有权的用户去使用,此时就会调用接口进行查询,有关联关系就直接使用,没有那就只好自己掏钱买了。这是理解流程的一种方式,觉得作为一名测试不仅仅需要明白测试结果是否正确,还得明白为何需要这样实现,当累计到一定的程度,就是对系统相当熟悉的时候,就可以开始去想是否有更好的实现方式没。

  需求评审完后,得到了建议,需要修改的修改,需要确认的确认,之后就是设计用例了,其实评审完需求后,大致的用例也就出来了,照葫画瓢就出来了,在写测试用例的时候,决不能因为是自己测,所以用例写起来就很粗糙了,之前见过一个同事写的用例,根本没办法测,测试步骤和预期结果就一句话,当时就跪了。写用例的时候,最好当做是写给新手的,步骤一定要全,预期结果一定要给出确认结果,在写的时候还喜欢将名称标明确,比如产品A,会写成产品Gray,后续使用也会用产品Gray,测试用例也是体现测试人员功底之处,毕竟这也是展示的部分,最好的测试用例是即使是没看过需求的人也能正确执行。在写预期结果时,喜欢将重要信息或者检查点标明,比如后台的传参,决不能错,当然能将后台流程也描述一下也是不错的。虽然再全的用例也不能覆盖,毕竟不同测试小组,其任务也是不一致的,但是需要关注的重点还得关注。

  功能测试阶段,这时候真的就是八仙过海了。因为测试的是自己的流程,之前对流程分析过,测试起来还是比较有感觉的,但是在测试的时候,也可以根据个人喜好,采取不同的方式。因为自己在设计用例的时候喜欢将关联性比较强的场景放在一起,这样避免了反复触发流程,但是这带来的麻烦就是,不是端到端全流程,中间倘若去除一部分,流程不能连贯下去。功能测试的时候其实关注点一块,页面展示OK只是最基础的地方,对于后台的传参一定要敏感,对于方案上明确的接口以及枚举值一定要查看,对于和第三方系统对接的部件,信息的传递重要信息,如密码一定要加密,决不能仅仅做一个透传。用例跑完,之后就是到发挥的时候了,考虑其他场景,有欠缺的地方进行补充。

  对于漏测之处,最好还是能做一个总结,避免类似的场景再次漏掉。

  对于流程的实现,归纳为三点,数据,接口,逻辑。数据通过接口进行传递,根据数据传递的信息,进行逻辑判断进行不同的处理,后两者都是为数据服务的,以上。

版权声明:本文出自 forstkksk 的51Testing软件测试博客:http://www.51testing.com/?600991

原创作品,转载时请务必以超链接形式标明本文原始出处、作者信息和本声明,否则将追究法律责任。


鲜花

握手

雷人

路过

鸡蛋

扫一扫关注最新动态

毒镜头:老镜头、摄影器材资料库、老镜头样片、摄影
爱评测 aipingce.com  
返回顶部