分层测试策略模型

2016-12-07  橙子 

    在面试中,发现很多测试同学由于公司限制,都是基于需求的测试,基于界面功能的测试,无法接触到开发的代码,甚至有的公司,测试人员都无法控制测试环境、数据库等,这些活都是有开发来干的。对于有些公司的现状,是可以理解的,但是对于测试人员的发展以及对于产品的质量都是很不好的。

    有些同学工作多年,但是也都是基于需求的测试,测试用例完全是需求文档的复制版。这样对于测试来说,就失去了很大的作用;因为很多问题缺陷往往就是由于需求没有考虑到,需求没有描述、开发功能 遗漏或误解导致的,所以如果测试仍然是死板的按照需求一步一步去测,那往往就会漏掉很严重的问题,测试之作用将失去大半。

    测试不只要测试需求,还得关注隐式需求,也就是用户的真实需求,真实意图,真实场景。另外除了需求,我们必须要关注开发的实现,开发是通过什么方式什么技术实现的,开发是怎么设计的?他们设计的是否正确,是否合理?是否满足了需求?是否高效?是否具有可扩展性?是否健壮?流程是否可控,是否兼容了异常情况,是否形成了闭环?底层数据处理的是否合理?等等,其实需要我们测试人员关注的有很多很多。

    为了保证新入职员工与我们的老员工能够统一测试思路,能够快速融入我们的团队,我们团队建立了一些测试策略模型,此处分享一下。分层测试策略模型,以下模型属于我本人编写,仅供参考;是否适合您的团队,是否全面,还需要根据实际团队,实际项目进行调整。



<作者:张强(JD零售)   2016/12/07   如需转载,请注明作者及来源    >

141°|1379 人阅读|4 条评论

小窝  2016-12-07

秒置顶


橙子  2016-12-07

@小窝 速度好快啊


胡先生  2017-01-14

感觉文章写了一半,开了个头,贴了个图,其实可以讲讲为什么你分了这几层,还有没有多几个例子,也同样讲讲分层的出发点,以及分层的方法,是否仅仅就是靠脑图,这样可能会更有帮助吧。


橙子  2017-01-16

非常感谢 能如此用心看我的博客文章,还提出了非常好的建议。其实当时写这篇文章是针对我的模型图有感而发,当时没有想太多太细。但是我的分层模型绝对是根据我们的实际工作情况总结的,每一条也都是我思考之后的结果。一些虚的我们没用的就干掉了。其实编写这个分层测试模型,就是为了指导新入职的员工或经验还不是很丰富的员工,在测试过程中能够更多的关注系统的底层,而不只是只看UI以及用户看到的功能。测试人员除了测试需求文档,还应该关注软件本身,根据软件的结构,关注不同层次我们应该关注的东西。具体等我抽时间再整理一下我的思路,看看是否还有更多更细的东西分享给大家。再次非常感谢胡先生。

登录 后发表评论