前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >零基础探索式测试实践之路

零基础探索式测试实践之路

作者头像
腾讯移动品质中心TMQ
发布2018-02-02 16:24:56
1.8K0
发布2018-02-02 16:24:56
举报
文章被收录于专栏:腾讯移动品质中心TMQ的专栏

初识探索式测试

与“探索式测试”的结缘,始于一年多前师傅安东尼在组内推荐的【探索式测试实践之路.pdf】电子书,通过前两章节的学习,了解到探索式测试是基于经验的一种测试方法,但当时由于自身测试经验不足,加上书中理论介绍有些枯燥,就没有继续,现在想来真是后悔,多走一步就能看到精华了~T_T~~

今年8月,中心成立探索测试小组,通过IEG的itest探索测试平台学习和大拿分享,再结合之前各渠道学到的皮毛,这才对整个探索式测试有了初步的概念,知道了如何去具体结合项目进行实践。

“术”的学习——理论装备

首先,好的实践必须得有理论指导,于是系统学习了《探索式测试实践之路》与《探索式测试》两本“巨著”,分别输出了测试方法模型与总结PPT。

但,仅有书本上的理论还不够,于是与组内一起学习探索测试的同学一起,结合各自负责产品以往所发现的缺陷套路和IEG的经验,输出了适合于浏览器产品的测试方法经验库(即所谓的“术”)

“器”的应用——项目中实践

有了理论的指导,开始在具体项目(Mac QB)中试水了。首先根据漫游探索模型对整个浏览器功能进行分区:

接着,在项目各阶段分别使用探索测试方法实践。

一、 用例设计阶段:根据具体场景采用不同方式设计测试用例并总结优缺点

1. 借鉴实时公交的经验,将单个模块作为一个整体进行分区,替代传统的测试用例

优点:分区一目了然,对于同一功能点采用不同思路进行测试,测试深度高。

缺点:入门门槛高,不利于初学者掌握。

这种方式要求测试人员对漫游模型有深刻理解,适合于功能已细分到足够细的情况,对于粒度较大的功能不适用(分区是会有交叉)。

2. 直接基于经验库设计用例

优点:对用例设计人员要求相对较低,基于经验库的学习即可掌握。

缺点:用例逻辑连贯性不强,对需求覆盖度不便于统计。

这种方式要求测试人员对经验库有一定理解,可以熟练掌握各方法的设计技巧,适合于独立功能模块的测试。

3. 根据传统方式设计用例脑图,然后根据探索测试补充新的case

优点:对测试人员要求低;用例逻辑清晰,连贯性强,可保证需求覆盖度

缺点:探索测试补充的深度不便于统计,对探索测试的整体把握不够清晰

这种方式适合于初步使用探索测试的人员,以及项目组需要开发自测用例的场景,蓝色文字是高优先级的基本功能,灰色为P1、P2优先级的探索补充用例。

小结:以上用例设计的具体实施,可以在项目开发阶段通过尽可能多的收集信息编写,后期不断补充完善;也可以在初期只给出大纲,测试执行过程中边执行边补充用例。视具体项目情况与个人习惯而定。

二、 增量测试阶段:对于新提测的任务应用探索式测试方法进行实践

发现缺陷所用测试方法以及对应发现的问题个数统计如下:

三、 集成测试期间:应用ET主导+ST辅助的方式进行探索测试

ET:探索式测试

ST:传统的基于测试脚本(包括测试用例)的测试方法,也成为脚本化测试

参考用例中需要测试的模块,每个模块为一个测程,先用探索测试方法进行测试,然后对照用例上没有测到的点继续补充场景),测试数据如下:

集成测试结果

探索测试

传统

发现总bug数

17(1致命+4严重+11一般+1提示)

17(2严重+13一般+2建议)

测试时长(天)

6.5

8

Bug总数/人日

2.63

2.13

PS:由于插件box需求是在集成测试以后才提测的,本次统计数据去掉了该模块的所有bug。

四、 项目发布后:总结漏测经验库

项目发布后,总结了接手Mac浏览器项目之后所有版本的漏测bug,对应到探索测试具体可以避免类似问题的方法,补充到测试用例及经验库中。其中, 使用出租车测试法、找麻烦测试法和极限测试法就可以避免绝大多数漏测的场景,具体如下:

测试方法

关注点

补充测试场景数

找麻烦测试法

权限问题、功能处理中设置障碍等

3

极限测试法

操作对象大小、数据极限

2

特殊环境

不同网络环境、双屏显示器

2

特殊页面

视频、PDF、flash等类型页面

2

出租车测试法

分支覆盖、多路径切替操作

2

上一版本测试法

不常用功能的向下兼容

1

快递测试法

关注永久存储数据在程序整个生命周期中的表现

1

最后,附上探索测试工具及平台:

1. 互娱itest系统(仅限腾讯内部使用,暂时无外网权限):http://itest.oa.com

2. SessionTester:基于测程的测试工具,用于记录测试过程并可生成HTML报告。

“道”的思考——如何证明探索式测试的优势?

一、根据前两期的实践,总结探索测试在各项目阶段的应用模型

二、 从5W(何时使用探索测试<when>、什么项目<where>、什么人员<who>适合使用探索测试、以及怎么使用探索测试<how>、具体哪些方法针对什么样的需求更有效<which>) 、以及如何度量探索测试效率等维度进行思考,得出以下脑图,具体效果有待进一步实践验证并持续优化。

三、针对细分研究方向中自己认领及负责的几个小课题,细分出具体实践的点:

写在最后:

探索式测试探索式测试(Exploratory Testing)是一种自由的软件测试风格,强调测试人员同时展开测试学习、测试设计、测试执行和测试结果评估等活动,以持续优化测试工作。它强调独立测试人员的个人自由和职责,为了持续优化其工作的价值,将测试相关学习、测试设计、测试执行和测试结果分析作为相互支持的活动,在整个项目过程中并行的执行。

业界常用的探索测试方法中,除上述漫游模型外, 启发式测试方法局部探索测试方法,场景操作法肥皂剧模型等也有各自适用的场景。

实践管理与方式上,有基于测程的测试、也有集体的TeamExplore活动、Bug bash大扫除、结对测试等方式。

总之,探索测试的学习与实践,是个长期积累的过程,以上小结只是入门阶段的小小成果,距离深入理解探索式测试的精髓还有很长的路要走,仍需要不断努力积累经验,继续加油!~

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2016-01-26,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 腾讯移动品质中心TMQ 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档