微信号:grzlwx

介绍:光荣之路官方资讯

产品发布后,一个QA的总结与思考

2015-10-16 21:56 光荣之路


题记:上周,产品终于 Release了,前后历时近两年时间,期间经历了一次需求变动,四次Interation。产品是新版本开发,需要同时在四个平台 (window,Linux,Aix,zLinux)开发,每次迭代实现一个feature。在敏捷盛行的今天,这样的开发周期是很多公司所无法接受的, 但作为一个服务器端产品,对软件质量的要求比较高(作为一名资历尚浅的QA,暂浅不评述这种有点类似“螺旋模型”的开发模式的优劣),只想谈谈在每次迭代 测试间,我们还有哪些地方可以做得更好!

背景:前一版留有测试用例1600+,其中P1的大概200个左右,P2有600多,剩下主要是P3以及少部分 P4。在上一版,在没有automation的来做Regression test的情况下,跑完一轮full cycle,即1600+的测试用例, 差不多需要4名QA,10 working day,也就是每人每天完成40左右的测试用例。

  1. 自动化测试

其实之前的版本留有一套自动化测试,但没有任何文档不稳定难以维护,所以在做新版产品 开发时就决定要投入精力重新开发出一套自动化测试来。作为一个生命周期很长的产品(>5年),有着一套健壮、稳定的自动化测试来做回归测试,以确保 代码改动,或新增功能不会影响以前能够正常工作的功能,这是十分又必须要的。需要明确的是:不要期望自动化测试能够帮助你发现新的bug。

其次,在写自动化脚本之前需要明确哪些测试用例有自动化的价值,并不是之前1600+的测试用例都需要实现自动化,比如讲,有些测试用例实现起来很简单,但它的优先级很低,或者有个P2的测试用例,如果要实现自动化,在技术上有很大难度,而且即使实现了,也不能保证很稳定,在这个时候,就需要考虑投入产出比(ROI)。

从技术上讲,自动化框架编码,写自动化脚本并不是十分困难,那难在什么地方呢?我觉得难点在于:

  • 自动化测试用例能真实全面反映用户场景。同样的关键字,同样的用例,但不同的人写出来的自动化脚本可能是不同的,不同在于对用例的理解,在于经验。

  • 整个自动化测试完成后的Pass Rate。 如果自动化脚本误报率很高的话,就会让人对自动化测试的可靠性大加怀疑了。为了保证准确性,会在一些keyword中,或则自动化脚本中添加一些容错延时机制。

  • 自动化测试完成的时间是可接受的。如果自动化测试跑完需要两三天时间,这就有点无法接受了。要在保证Pass Rate的前提下,尽可能能缩短时间。

  • 自动化测试用例的tuning。当代码改动导致自动化测试用例Fail,排除了是bug,这时候要及时调整keyword,或则自动化脚本。

自动化的开发也分成了两个Interation,第一个阶段完成了自动化框架、大部分的keyword和基本的smoke测试用例的自动化,第二个 阶段,补充一些keyword,完成regression测试用例。最后,新Feature的自动化。到目前为止,产品的自动化覆盖率差不多40%左右, 但覆盖了产品核心功能。

这套自动化测试发现了哪些问题呢?这个问题肯定经常被问到,稍微归纳下:

  • 代码改动导致以前正常工作的功能Fail。举例,之前可以正常处理uuencode编码的邮件(注: UUEncode格式本来就比较难处理),因为一次代码改动fail。

  • 验证HotFix/Patch。一次帮sustain team验证Patch, 打完patch后,没跑几个cases ,系统就挂了。

  • 内存泄露。发现过一次内存泄露,当跑完十几个特定用例后,内存居然被吃光了后Crash。结果发现在跑这十几个cases时,需要reload配置,但每次reload都没释放之前资源。

  • 多线程竞争资源。这次automation 过程中的crash很难重现,最后是RD分析dump文件后找到Root Cause的。

自动化开发过程中的一些经验教训:

  • sync-up meeting(也叫stand up meeting)。每天花上十分钟,sync下进度,讨论下在编码、写自动化用例过程中遇到的问题,这在自动化开发初始阶段还是很有必要的。

  • 确保每天完成的自动化脚本都能100%通过,然后把这些没问题的自动化脚本和之前的脚本串起来跑,确保没问题。

  • 实现好的自动化脚本需要交互检查,看步骤,看检查点是否完备。

  • 自动化框架源码、实现的关键字、自动化脚本、配置文件、生成的Data 都必须加入到版本控制系统中去,如SVN,Git都可以。确保代码,脚本没问题后,及时Check in。

  • 每天自动化测试的结果整理统计后,发给team里面的人。

  • 对于那些Fail的测试用例,需要有人去follow up。

  • 当发现测试用例的fail是由代码改动引起的,确认不是bug后,需要及时调整自动化代码,自动化测试用例。记得Check in 你的变动。

  • 自动化环境的部署文档,自动化框架和关键字实现文档。前人栽树,后人乘凉的道理,方便他人接手。

现有的自动化测试有哪些不足呢:

  • 自动化环境的部署略显复杂。让一个新人跟着文档部署好一套自动化环境,至少需要半天时间,要掌握基本的troubleshoting技巧,写自动化脚本,差不多需要一周时间。

  • 自动化关键字的实现稍显复杂。部分原因是Domino这样的环境决定的。

  • 部分自动化测试用例执行时间偏长。

自动化测试是个持续投入的过程,一套稳健的自动化测试能提高你对产品质量的信心。

(未完待续)

(作者:matt_chen 来源:http://www.cnblogs.com/matt123/archive/2012/11/05/2755900.html)


 
            
 
            
 
            
 
           
 
           
 
           
 
           
 
           
 
           
 
           
 
           
 
           
 
           

感谢作者,传播测试知识、技能与正能量!
欢迎来稿,分享你的测试生活!735821166@qq.com

光荣之路软件测试培训

官网:http://www.gloryroad.cn/

微信公众号:gloryroadtrain

性能测试QQ群:415987441
软件测试招聘QQ群: 203715128
自动化3群QQ: 371211499

 
光荣之路 更多文章 今天晚上的 linux 公开课- Awk 编程 7月28日(今天)晚上的 linux 公开课- shell编程 8月4日(今天)晚上的 linux 公开课- shell编程 9月1日(本周一)晚8点半,光荣之路Web自动化系列基础课—javascript第二讲 推荐本好书《与机器赛跑》
猜您喜欢 微信支付网络连接超时问题定位 程序员语录手册 Facebook上500万人点赞的一组漫画:你孤单吗? 干货 | 透视宝Smart SDK实现原理与案例解析 我们究竟从大数据中挖掘什么?