软件测试经验之谈

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

软件测试经验之谈

【质量】

测试人员核心的产出,发现bug,提升产品质量和用户体验,尽量少的把bug遗漏到线上去,让用户或者监控发现;是的,这两年来,对于一个新业务来说,我们在这么多、

这么变、这么复杂的需求和迭代项目中,我们拼劲了全力,新业务的质量有了稳步的提升,线下bug的数量、线上bug的数量和趋势、系统的稳定性等各个角度来看结果,都说明

了我们真的不错,是的,这是我们的基本工作,也就那样吧。

【效率】

对于一个新业务,对测试效率的要求也是更加考验,新零售是链接线上和线下、商家

和消费者之间的桥梁,我们在测试效率上也是面对很大的考验;是的,这两年来,对于一

个新业务来说,我们在这么多、这么变、这么复杂的需求和迭代项目中,我们继续拼劲了

全力,新业务的研发效率有了稳步的提升,开发自测质量提升、初级bug、ISV对接效率、全网回归效率、10+测试数据工具等各个角度来看结果,都说明了我们真的不错,是的,

这好像也是我们的基本工作,有了一些进步,还不错的,不过也就那样吧。

【技术驱动业务】

你是开玩笑吧,是的,我没有开玩笑,对于测试来说,驱动业务简直是难如登天,开

发是天生的,测试是后天养的;天猫智慧门店在线下业务的拓展过程中,我们对每一个商家、每一个线下门店都会有质量的责任,我们经历过双11,经历了痛点。是的,这两年来,对于一个新业务来说,我们在这么多、这么变、这么复杂的需求和迭代项目中,我们再次

拼劲了全力,我们在商家业务配置检查、商家ISV验收、线下门店预演等一系列的结果上

来驱动天猫新零售商家和门店的规模化发展,我觉得我们是技术驱动业务了,为业务高速

发展提供了保护伞,都说明了我们真的不错,是的,这好像也可能是我们的基本工作,有

了更多进步,还不错的,不过好像技术含量比较低,扩展性一般,其实也就那样吧。

好吧,刚刚都是自夸,看不下去了吧;其实我想说的是,这两年,我们做的还不错,

各个层面都有结果,特别是第三个层面的,有的时候是可遇不可求的,总体上团队能力和

技术都有提升,但是在某些结果上的确不让人满意,我们的一些测试大佬们既要、也要、

还要、反正什么都要,你要是哪个没有,不好意思,只能这样了。说实话,我有时候也能

理解他们,真的理解。

12年 / 国内测试都在关注啥?

这个话题有点大,其实真的不敢写,但是无知者无畏,虽然在阿里干测试9年多了,自我感觉蛮了解的,比起”阿里测试都在关注什么”,我觉得我更敢写这个,其实也有点

心虚的。这些年,我一直专注在我们自己的业务和系统、测试问题,这些细节非常多,我

们的目标和规划都围绕这个来,非常接地气;是的,说这个就说明我对国内测试在发生什么,在追求什么,其实对细节了解不多,但是在微博、在大会的主题、在相关的ppt和群讨论中,还是能感知到一些的,接下来就说说,很多理解不一定对和全面的,欢迎大家补

充讨论。

在正式的说之前,大家回想我之前说的一句话,我们干测试的,很多时候就是在平衡这三步的比例和深度,在质量、效率、驱动业务上不断的调整策略和战术,根据不同的业务阶段、根据不同的目标、根据当前的大事件驱动等。

我们最怕干的是就是平衡,因为平衡的好,前途光明,平衡的不好,万丈深渊。大家都知道我们干测试的,杂活特别多,很多事情都需要投入一点,很多事情做起来很多人看来也没有亮点,那我们很多时候就是在不断的平衡一些事情,但是不管怎么样,我们的目标还是比较聚焦的,就是对应自己的业务和开发技术,以及未来的业务发展,在质量和效率上如何做的更好,成本上越来越低,解决方案也越来越有技术含量。

大家都知道,不同行业对应测试的要求是不一样的,那么测试技术和要解决的问题也是不一样的,但是有几个套路其实是差不多的,大体上分这几个方向。

1. 基于模型的测试:这块领域很多人不太熟悉,而且在不同的行业的实践和效果是差异比较大的,但是不能否定这个方向带来的价值,在通讯、IOT、嵌入式等领域都有非常多的实践,效果也不错,我认为是测试前移比较重要的一块;但是很多人对于这块只是基本的了解,很多时候都有可能直接放弃;最后的结果,可能是我们的开发同学先开始业务建模,先开始各种模型抽象,提升开发效率,然后再到测试的模型和效率提升,很显然,我们是被动的,而且很多时候我们错过了一些风景,可能感知不到呢。

2. 可测试性:这块话题,其实是大家聊的比较少的,因为很多方面是偏理论的,真正落到实践到项目过程中,和业务项目的技术架构、技术能力、技术人员思维都有比较大的关系;而这块对于大公司是比较看重的,特别是微软、google级别的重视技术体现的公司,我们作为测试开发工程师的重点是从开发角度去做测试工作,会把主要精力投入在系统设计和编码阶段。开发人员关注某个功能最优实现方案,而我们测试要有整体产品的视野。所以测试在设计阶段,帮助开发人员完成代码复用和模块交互方面的设计,在设计review的时候,保持目的性:完整性、正确性、一致性、设计、接口与协议、测试(可测试性)。还有一个明显的,就是做这块,需要沉下心来,慢慢积累和思考,对于很多急功近利的公司来看,绩效和沉淀方面难说了,而且这块的确是我们测试的短板,接下来我觉得还是有可能会重新重视起来。

3. 自动化测试:这个是很明显的提升测试效率的手段,这里面不同的行业的自动化测试策略和框架也可能不一样,但是的确是互联网企业发扬光大的,包括分层自动化测试实践,其效果也是非常显著的,不管是什么行业领域,都是逃不掉的;不管你是采用流量录制和回放、页面录制和回放、关键字驱动、数据驱动的自动化脚本运行,这些经验和沉淀目前也是国内的公司强烈关注的,为什么非要关注这块,说实话,这些能带来XX平台的沉淀,XX平台的开发和技术品牌、XX平台的能力透出;如果我们加上功能依赖分析、系统依赖分析、代码覆盖率等各个因素的影响,我们可以加上精准测试的方向,进一步提升自动化测试效率,这块上国内有一些公司都在沉淀和探索,也有一些不错的结果。

4. 灰度&监控:这块话题,是测试右移的核心思路,基本上也是互联网和移动互联网企业的测试策略的标配,测试和开发一起共建,来加强灰度的落地,监控覆盖率和提升;但是测试在其中的体现到底多少,价值多少,这个就很难说了,我们的沉淀的方向到底是什么呢?我们开发有没有加上这块的监控、开发为什么没有加上这块的监控、我们测试是

相关文档
最新文档