隐形的软件质量
上一篇 / 下一篇 2012-10-30 11:01:54 / 个人分类:杂谈
q"d)@)[(c~xN'R0 最近被问到了一个话题:软件的质量真的能完全看得到么?比如两款手机,一个是山寨机,一个是三星或者GoogleNexus,同样是安卓系统,同样的配置甚至装上同样的App,那么它们从测试的角度功能可以说Function是完全一样的。它们的质量的差具又在哪里呢?可能这个例子是手机还可以划分到硬件范围,那么举一个纯软件的案例,同样的两款软件,比如都是微博、或者浏览器,当他们外在的功能几乎完全一样的时候,你如何衡量他们质量的区别在哪里?51Testing软件测试网 {sl:Z5Y5P3vwxn
5RA7s7hjBd0 这是一个很有意思的话题,互联网的迅速发展和变化,改变了许多软件设计、研发的模式,许多曾经红极一时的书籍里提到的最佳测试实践也好,测试理念和方法论也好在当前的时代,效率其实是非常低下的,甚至在许多情况下毫无意义,并适得其反的拖延了抢占市场的先机。软件测试的 传统的流程是:开发人员写好代码,测试人员制定策略,编写用例,覆盖率,把所有的bug都找出来然后改正、回归再最终发布。但是当代的软件测试,特别是互 联网测试,夹杂了两个特点对传统的测试流程形成了致命的冲击:1. 需求很可能是时刻变化,传统测试的笨重流程根本无法适应需求的迭代更替。2. 市场Timing转瞬即逝,在许多情况下测试团队不会有足够的时间来执行全套测试,你可能面临代码提交之后2个小时要正式发布这样的挑战,如何在有限的时 间完成对质量的把关,倍加重要。总结一点:团队要敏捷的开发,更要敏捷的测试51Testing软件测试网kH-y{?YL|2z
51Testing软件测试网!^ [a.B9M3S在过去三年的测试实践中,我遇到了这样一种情况:我们的研发团队几乎都是加拿大很优秀的工程师,他们对需求的理解、代码的质量、单元测试都做得非常不错。于是我发现在进行功能测试的 时候,QA在95%的情况下把功能确认了一遍执行正常就完成了测试任务,在5%的情况下发现了一些显而易见更多的是UI的小问题,fire bug并快速的跟这些负责任的开发修复bug,测试任务也随之完成。其实从一个较长的周期来看,QA总是在不断的确认功能,不能有效的发现许多有价值的 bug。这是为什么呢?因为开发人员本身具有不错的水准,他们接到某个功能研发的任务,能高质量的编写代码完成并本着责任心自己会多次确认(包括单元测 试),而在一个架构较为成熟的系统中由于解耦合,不同的开发人员在不同的模块中所写的代码,又不太容易产生交互的深层次bug。这种情况下,QA按照传统 的理念和流程,去一遍遍的安装、操作功能、确认功能正常后测试就pass了,仔细想来,效率低下,且意义真的不大。51Testing软件测试网?oxJf:i!@*b
i.|2NG5gh0 遇到过几个案例,经过测试团队测试通过后发布的产品,在客户那里得到了一些不太好的反馈:比如网页加载速度不理想、比如有的功能在跑的时候网线掉了整个server就挂了,比如一些莫名其妙的错误弹出来,还有特定的条件下例如在用户频繁操作了一个月以上才引发的一些性能问题和不好的用户体验……这些案例无疑都是测试团队的警钟。并不是大家在确认功能交付的时候做得不够仔细或者工作不努力之类的,笔者觉得这是因为软件在表面的功能健康之余,还存在着一种笔者叫做“隐形的质量”的东西。51Testing软件测试网$_2vnP,D