标签:期望 那是 资源 简单 工程 是你 src 测试工程 功能
前不久国庆档上映的一部电影《登山者》,相信大家都已经看过了,在剧中,中国登山队那种不畏困难,勇于探索未知领域的精神着实让人敬佩,特别是最后一刻吴京饰演的方五洲带领队员,终于再次登顶。如果单纯的从事务的本质来看,探索未知区域(比如登山探险)和探索软件有非常多的共通点:
顺着这个思路,计划写三篇关于探索性测试的文章(理论篇、深入篇、情景实践篇),在写文章的过程中,参考Elisabeth Hendrickson的一本书《探索吧,深入理解探索式软件测试》。文章理论知识偏多,所以看上去会比较枯燥,不过我会在文中加一些小案例,方便大家理解,现在让我们一起进入探索测试的世界吧。
所谓的常规测试,指的是我们常规思路的测试:尽可能的写测试用例、依照测试用例执行测试。而探索性测试指的是针对要测试的产品,选定一个模块/方面,选择很多可能变化的点(变量),然后深入进去,挖掘潜在的问题,举个例子:很多产品都有保存图片或文件的需求,这就牵扯到保存文件的路径,这里文件路径就是个变量,我们基于文件路径这一因素,可以提出很多可探索的点:
我觉得所有的软件测试工程师,都有这样的经历,无论自己的测试用例写的多么完善,只要产品上线,就会有大大的惊喜在等待你。那是不是常规测试就不重要呢?换句话说,我们是不是应该更多的进行探索性测试来替代常规测试。其实不然,常规测试和探索性测试是相辅相成的关系,如下图所示:
常规测试就如同上图中的网,而探索性测试则要覆盖网无法覆盖的区域(也就是网格),两者只有全部兼顾到,才能保证产品的质量。一个完善的测试策略应该能融合两种方式做到兼容并包:已测试=已检查+已探索。
与写测试用例一样,探索性测试也有对应的设计模板(姑且称之为探索性测试用例模板吧),其实写测试用例的思想(比如边界值、等价类)完全适用于探索性测试。但是需要注意的是,探索性测试的用例不会像一般测试用例那样具体,我们下面通过例子再来详细说明,通常来讲探索性测试的设计包含下面三要素:
先来看一个比较差的探索性测试策略:
目标:探索编辑姓名
资源:使用输入值 “xuan‘ke”
信息:为了发现【编辑姓名的功能】是否能处理名称里包含’的情况
大家对上面的策略熟悉吗?其实这就是一个比较具体的测试用例,只不过换了一种形式。接下来我们再来看一个比较正常的探索性测试策略:
目标:探索浏览器输入的地址
资源:使用javascript和sql注入式攻击
信息:为了发现系统的安全弱点信息
可以看到上面的测试策略并没有说明,需要具体使用什么javascript脚本或者什么sql语句注入,而是提供了某一个方向或者灵感,剩下的工作需要你自己去探索和尝试。
为了大家能找到有价值的探索性测试点,这里帮大家归纳几个可以寻找测试点的思路。
需求评审是挖掘探索性测试点的理想时机,下面举个例子(例子中人员角色:Alex是软件测试工程师、Pat是开发工程师、Binh是业务分析师):
Alex针对上面的对话情况,制定了如下的测试策略:
目标:探索编辑档案
资源:使用非法用户名
信息:为了发现用户名限制规则未被触发的情况
所以之后的需求评审中,我们又多了一件可以做的事情,可以尝试去发现针对产品可探索性测试的点。
产品经理和开发工程师思考问题的角度是不一样的,所以必然会存在这样的状况:每个人从自己的角度考虑,觉得某些事情或需求点太简单了,不需要再提。但往往是这些隐性期待,造成了沟通障碍,等到最终产品将要上线时,才发现大家对需求的理解都不一样。
举个例子,比如:在开发某一款app时,产品经理期望能打开app就使用某个特别高大上的功能,它的隐性期待是加这个功能不会影响app的启动速度、包的大小等。但是等到开发完成时发现加上这个功能后,app启动速度慢了将近10s,这显然是不能够接受的。虽然产品经理需求文档中并未提及对app的启动速度影响,但是你得尝试发现这些值得探索的隐性期待,将它们加入我们探索测试的策略中。
在一个软件/系统中,会存在很多变量,而这些变量是可以作为我们探索的点,下面列出需要注意的变量:
上面提到的这么多变量,你可以结合自己的产品特性来选择变量作为自己探索测试的策略。
如果你还没有源代码的权限,一定要问开发要一个“测试”的代码权限。看代码的注释是特别欢乐的事情,而这些注释也能帮我们发现探索测试点,比如以下注释:
如果看到代码中有类似的注释,那么说不定这就是值得我们探索的点。
不管我们再怎么努力的测试,软件到用户手上,还是会出现各种各样的问题,原因很多:软件安装的环境不同、用户的操作和使用习惯千差万别、软件运行的环境(比如网络状况)不同。所以多查看用户反馈的平台,也可以帮我们挖掘出探索测试的点,将他们记录下来。
上面提到了几种探索性测试策略的发现的点,但是也需要注意,你找到的可探索测试的点,需要和开发工程师、产品经理保持目标一致,否则会浪费你的时间。举个例子:你将切换程序所在的时区作为一个探索点,花费大量时间在验证切换时区之后的影响,但是最后产品经理告诉你,我们的程序只可能在中国使用。
所以在需求评审时、或者常规的用例评审时,可以将制定的探索性测试策略拿出来,和大家同步下,从而让大家对测试策略的认知达成一致,同时你也可以丰富自己的探索性测试策略。
本文主要介绍了探索性测试的基础内容,可以帮你初步的了解到探索性测试是怎么设计的。其实我觉得在平时的测试工作中,大家已经有意无意的在用探索性测试的理论了,只是目前还是以常规的测试为主,还没有达到和探索性测试相辅相成的效果。希望我能通过【如何做好探索性测试】的这三篇文章,帮助大家优化自己的测试知识体系,同时对我自己来说也是个升级。下一篇文章会更深入的来认识探索性测试。
标签:期望 那是 资源 简单 工程 是你 src 测试工程 功能
原文地址:https://www.cnblogs.com/zhouliweiblog/p/11865290.html