探索性测试揭秘

最近看了不少有关探索性测试的讨论和观点,老实说越看越糊涂。所以忍不住吐槽一下,在这里和大家讨论一下探索性测试。希望对于想学习和尝试探索性测试的朋友有所帮助澄清,或者是更加糊涂,^_^。  探索性测试有很多很多的定义: 百度百科的定义:“同时设计测试和执行测试”。 嗯。。什么意思? Cem 老人家的正式定义:“a style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimize the quality of his/her work by treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project”。啊。。 糊涂了。。。 有人说:“手工测试就是探索性测试”。  更糊涂了。。。…

2

对测试的要求太高?

微软的软件质量控制实践三篇写完了,收到很多评论。不可能一一回答,所以在这里我挑几个评论最多的和有代表性的,和大家再多讨论一下。希望有所帮助。 1. 对测试的要求太高了 在国内培训的时候经常遇到的一个说法:“(比如测试自动化,工具,流程)的确好处很多,但是它对测试的要求太高了”。刚开始的时候我很惊讶,第一次听到对测试要求太高的说法,后来听多了才慢慢意识到这才是问题所在。如果你认为国内的测试比国外落后N年的话,我觉得“对测试的要求太高了“的观念就是导致这个落后的根本原因。我一直在观察和对比国内外测试的区别,当然有技术上的,工具上的,流程上的区别等等,但是这些差别都只是表象,根本的差别是观念上的差别,也就是测试在研发中的真正角色。这个不是找到多少个bug的问题,也不是采用什么测试方法的问题,而是是否把测试做为支撑研发两条腿中的一条腿的问题。测试是一个专门的职业,和开发一样有不同级别。初级人员解决简单的事情,高级人员必须负责解决复杂,高难度的事情。这样才能形成一个完善的测试人员职业发展体系。很多测试经理一直很困惑说我们也在加大在测试上的投资,参加很多技术、流程、管理培训,但是效果都不好。原因就是我们不能总是希望通过学习一个技术,或一个工具来解决观念上的问题,当然没有效果。也容易跟风,刚学会手工测试,又要测试自动化了;刚学会测试自动化;又要ET了。刚学会ET,又要敏捷了。没有观念就没有主见。所以改变观念才是提高软件质量的根本途径。 那么如何改变观念呢?我也不知道。公司老板不愿改变呢?我也没有办法。但是重要的是你知道问题所在了,这就是解决了最大的难题。如果自己都觉得测试没有难度,没有前途或者对测试要求太高了的话,如何指望得了别人?所以我们搞测试的人的一个重要职责就是:把这个观念灌输给其他人,把测试的门槛提高,对测试的要求没用很高只有更高,其它问题也都解决了。    2. Dev不愿意修改bug. 这是一个很多测试抱怨的问题:自己辛辛苦苦找到一个bug,开发却认为不是bug。或者更为令人气愤的是开发在没有沟通之前直接resolved as “by design” or “not repro”。这个情况通常在质量控制成熟度级别(1级或2级)较低的组出现较多。根本上解决的办法是提高整个组的成熟度级别,当然需要在很多方面加以提高,这个问题就随之而去了。可以使用以下几个策略: 首先这里牵涉到两个问题:一个是resolve as “not repro”的问题。很多时候dev resolve as ‘not repro’是因为bug本身不清楚没有足够的信息来判断或进一步investigate(当然他应该和你确认一下先)。所以测试在报bug是一定要记录足够信息。基本原则是当别人在看该bug是否有足够的信息来判断该bug是怎么回事或进一步investigate。我总结过一个好的bug描述应该是Concise,Accurate, Searchable, Entirety, 也就是 CASE 原则。可能你会觉得这需要太多的时间才能报一个bug了。的确是,但是总比你花了两天找到一个bug,花了10秒钟就把bug写完了,结果过两天dev resolve 成not repro强吧。另外就是自动报bug的工具,还有就是创建bug模板等都可以减少报bug的时间。 其次是’by design’的问题。很多时候测试不服气认为就是bug,但是开发不同意修改。我想借用一句话来说明我的观点:a good idea is not really  good  until it is accepted. 也就是说如果你不可以说服别人接受你的主意,再好的主意也没有用。同样的道理你认为的bug,如果不能说服别人,它也不是一个bug。或者bug只有在被修复时才是真正的bug。如果dev/test有分歧的话,通常PM负责一个功能,应该有PM做最后决定;如果没有PM的话,通常有整个team来决定。当然如果你非常肯定,可以继续找更多的理由来支持你的观点。但是最终如果还是不能说服别人的话,还是要服从team的决定,虽然我们常说真理往往掌握在少数人的手里,但是绝大多数时候都是少数人考虑不周。另外一点就是我们通常很少在是不是bug上有分歧,而是在什么时候修复上有分歧。这是另外一个话题了,需要考虑很多其它非技术因素了。   3. 如何做到自动报bug,并把相关的信息放到bug 里面. 我在comments里已经回答过了,就把它拷贝一下吧以是完整:我前面提到微软有很多工具来提高测试人员的工作效率,也就是说把时间花在需要专注的地方而不是在其他繁琐的地方浪费时间。其中一个好的实践就是自动报bug。其实整个过程比较直接:首先用来管理bug的工具应该会有API接口,所以可以使用工具来自动报bug。其次是添加分析处理工具,测试的出错信息比较容易获取,比如测试用例出错了,或者抛异常或者返回错误结果,可以容易地把异常信息或错误信息放到bug里面;分析产品的日志找到错误点有写难度,需要和dev共同努力把测试日志和产品日志通过某些属性(时间戳或操作id)关联起来。或者简单地把相关日志、windows event log,等拷贝到network share,在bug中指向该路径即可。还有对于UI测试,如果测试错误,一定要把当时的屏幕截图抓下来放到bug中去。还是那句话,专注于应该要专注的地方而不是把时间浪费在其它步骤上了,测试用例出错,不应该花太多时间去报bug (最多2分钟)。同样道理有了bug后dev可以直接去investigate,而不是花时间去找日志在那里?那里出错了?等等。有条件的产品组还可以进一步提高,比如工具自动报bug的时候可以到到数据库里根据异常或错误信息查找一遍看一看以前有没有类似的bug,或者做BI,这些信息对于将来的分析和决策非常有帮助,而且也可以帮助预防bug。   —————————————-…

1

软件质量控制实践――Microsoft 篇 (3)

  7. invest on test engineer’s career 无论产品使用何种方式保障质量,人总是最核心最关键的因素。提高软件质量有无数种方式和无数个因素,如果非要说一个最最重要的方式,那就是激发测试工程师的工作热情。You can only achieve average by working hard, but passion is the one driving to excellence. 为了最大化激发测试工程师的潜能,微软为测试工程师设计一整套完善的职业发展计划。测试工程师主要有两个职业发展路线。一个是Individual Contributor (IC): 不管人,管技术。另外一个是Manager: 偏重于管人和项目。这两个路线没有好坏之分,因人而异。两个路线都是以技术能力为核心,也是加薪升职的最主要考虑因素。经理未必比个人挣钱更多,“Become a manager is not a promotion”。You are paid for what you cover。”what you cover”就像长方形的面积,面积大小有长和宽同时决定。VP管的很多(长),但是深度有限(宽)。而技术大牛管的很少(长),但是很深(宽),所以两个长方形的面积大小差不多。这也就是为什么 有些技术大牛一个人不管但是挣钱和VP一样多。下面是几个测试工程师常见的职位: SDET - 初级测试工程师 ,要求是:executor,如果有个问题需要解决,而且告诉你如何解决,你能够很好地把问题解决了。  SDET 2 - 中级测试工程师 ,要求是:designer,如果有个问题需要解决,你自己找出办法去解决。  Senior SDET -…


code coverage, what is for after all?

I was reading discussions on software testing code coverage. The discussion was dominated by what the code coverage number for unit test or overall test  are correct or desired. 40%, 60%, 80%, even 100%? some claims that google only requires 60%. some asked me what are code coverage number requirement in microsoft. as far as i know,…


软件质量控制实践――Microsoft 篇 (2)

4. Drive quality upstream 我们都知道bug越是滞后发现,修复的成本越高。据微软统计,如果产品发布以后需要发布一个热修复,它的直接成本是150万美元(间接成本在200万美元),而在发布之前的一个月发现的话,修复成本是5万,设计阶段修复成本是1千,需求阶段修复成本是1百。在需求分析阶段,测试人员主要职责就是验证需求分析的可行性和可靠性。PM和DEV的共性是易于乐观,倾向于把实际情况简单化,所以会作出很多假设。比如用户肯定不会这么使用,用户肯定知道如何用,所有用户的环境肯定都有该配置。但是实际情况下总会有用户不知道如何用,总会有用户会不按“预先设计”的方式使用,总会有用户环境没有该项配置。所以测试人员的主要职责就是找出这些假设并提出疑问并加以验证。 在dev设计阶段,测试人员需要验证设计,同样找出dev的假设然后疑问这些假设是否合理,看看该设计是否处理很多没有预料的但是有可能会发生的情况,比如用户输入特殊字符,非常规操作,非常规流程,机器重启,死机,数据库连接中断,网络中断,内存耗尽等等。除了验证设计是否处理非正常情况外,测试人员的另外一个更为重要的职责是验证设计的可测试性。可测试性是指测试软件容易的程度。软件的可测性对于提高软件的质量至关重要。道理很简单,如果你的软件很难测试,无从下手,测试一个用例需要几个小时甚至几天的话,你的软件质量也就无从保证。提高软件可测试性通常的做法是把软件模块化,松耦合,模块内部运行状态可见,模块内部运行分支可控制。在评审一个设计时通常问的问题是该如何测试该模块,是否容易测试它,能不能单独测试它。如果不可以的话,需要重新考虑设计。因为一个设计的很容易测试的模块和产品可以使得后期的测试代价大大降低。微软大部分复杂系统都会有一个“one-box”版本,该版本是个假的模拟系统但是拥有真正系统的几乎所有功能,它可以运行在任何机器上。系统的绝大部分功能都可以在该模拟系统上快速方便验证。我在培训的时候很多学生问,他们在后期测试的时候遇到许多无法测试或者很难测试的困境,问我该如何解决。在具体了解困难和困境之后,我发现他们的测试策略非常单调,只能把产品部署到有限的测试环境下从用户界面上做端到端的测试。如果想测试某个特定模块或功能需要好几个其它模块配合起来才可以。我就坦率的说如果你的软件是这么架构设计的话而且已经到了这一步,世界上没有人可以解决你现在面临的困难。因为看起来好像你是卡在现在这一步了,但实际上根本问题是在前期,在需求或设计。就像解决河流的水质污染问题,你在下游无论多大的代价也只能稍微改善,解决问题的根本方法是在解决上游的污染源。或者像隔靴挠痒,隔着厚厚的靴子无法挠到关键地方,必须能够把靴子脱掉直接挠。           5. Getting better every day 软件测试的目的一个是找出bug,另外一个是衡量软件的质量。通过测试来了解产品哪些地方薄弱,哪些地方不稳定. 通过监控测试的结果,包括功能测试,性能压力测试,安全测试,本地化测试,容错测试等等来反映当前软件的质量。这也是持续集成的一个重要原因,它一方面短期迭代,另一方面可以在最短的时间内知道软件的质量,同时跟踪软件质量重开始到发布,软件质量的变化曲线。衡量软件质量的通常指标有:测试用例通过率/趋势,bug数量,种类/趋势,代码覆盖率等等。另外测试在开发周期中通常做的其它工作还有:bug root cause analysis, Bug analysis, Test case failure analysis, test gap analysis, Bug talk, bug share, CCS data analysis等等。这一方面促使产品质量逐渐变好,而且是看得见的好。另外也促使自己放下繁忙的工作静心思考一下,如何更有效率更进一步提高质量。           6. Engineering agility 随着软件即服务和云计算的兴起,它们给开发管理,质量管理,运营管理等提出了很多新的挑战。以前那种保密开发测试2-3年再突然发布的策略无法适应互联网应用服务的要求,而是逐渐演变成快速开发出产品基本原型,然后就发布,根据用户反馈不断加以改进的方式。质量管理方面,基于服务的产品除了关注功能性能,还有其它特别重要的方面,比如scalability, high availability, fault tolerance, disaster recovery, etc.. 这些都是桌面型产品所没有的或不重视的。微软从2010年开始在很多组开始实践如何提高服务型产品的质量,比如Azure, Bing, etc…。其中最为根本的一点就是提高整个团队的敏捷度,团队能够跟的上快速迭代交付的节奏。这需要从产品设计上到测试自动化,工具,基础设施上得以保障。另外一个非常重要的实践就是TiP (test in production) 或 crowd-sourced testing. 我们在前面谈到“drive…

2