初识探索式测试
与“探索式测试”的结缘,始于一年多前师傅安东尼在组内推荐的【探索式测试实践之路.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大扫除、结对测试等方式。
总之,探索测试的学习与实践,是个长期积累的过程,以上小结只是入门阶段的小小成果,距离深入理解探索式测试的精髓还有很长的路要走,仍需要不断努力积累经验,继续加油!~