51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 3885|回复: 12
打印 上一主题 下一主题

[原创] 敏捷测试体会谈

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2009-8-17 15:26:19 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
-------转载
  严格的说,我对于传统测试没有太多经验。从06年进入游戏测试行业开始,我所在的团队就在尝试向敏捷方式的转变,成功敏捷后至今,已一年有余。而这近一年半的经历给了我很大的冲击,让我每天都对我的工作有新的认识和体会,这和以前在学院里获得的对于软件开发和软件测试的理解有很大的不同。

  至少在我看来,传统的测试应该是——可以坐在我们测试部门专用的办公区内,等待产品策划的文档;拿到文档后着手准备用例,并看一下项目的计划;在程序员提交可用版本后对产品进行测试,然后将找到的bug提交bug管理系统;最后在产品计划发布之前,拿出几个还未修改的bug理直气壮地说,产品还未准备好……然而现在,我们不再和产品团队有空间距离,不再只是看文档写用例,不再只是提交bug,不再只是争论某个bug是否必须修改……敏捷的开发决定了我们必须以敏捷的测试来应对。

  “沟通”成了最重要的技能之一

  敏捷宣言里讲:个体和交互胜过过程和工具,客户合作胜过合同谈判。在内部需求上,开发人员就是我们的客户。而我在加入团队后所做的第一件事,就是搬位子到开发人员旁。当然,是被要求这么做的。一开始还有点不适应,毕竟我们被分离开了曾引以为豪的独立的测试团队,这和传统的观念是相悖的。不过在经历过几个测试阶段后,这么做的好处就体现了出来。

  以往我们总要等到一个正式的版本,才可以开始测试,否则过多的介入会打乱开发计划。而现在,程序员就坐在我对面的隔间,他一抬头就说:“嘿,X功能做好了,我跑了一遍没问题,你来试试看?”结果我过去试了试,bug出来了。程序员的反应则是:“好,我马上改”。——这样一个bug从发现到修正,最多不超过半个小时。而以往,我要等到版本正式提交,再build好,再up好,发现bug后还要通过提交bug管理系统,等待系统发邮件给程序员。如果恰好程序员忘记开邮箱了,那就可能要更多的时间。

  事实上这里面还有更多的细节。我相信大多数测试人员会和我有同样的经历,在发现并提交一个bug时,我们写了大量的文字来描述bug的环境,bug的重现步骤;程序员修正bug时,也自信满满的说,该bug已修正。但当你一复查时,却发现你所认识的那个bug还在,而程序员完全理解错了你所说的bug。而现在,你所需要做的,只是抬一下头,把问题说出来,直接和程序员进行沟通,让他能够准确的理解你的意思,甚至包括你对于该bug的分析。接下来一切就十分好办了。

  此外,有时有些bug确实不是那么容易重现的,你需要和程序员配合操作,才能发现其中的蛛丝马迹。我们现在最常做的一种合作就是,由我来制造环境,按重现步骤操作,由程序员在另一端跟踪调试代码,一边沟通,一边进行,这样就能很准确的发现问题,并且能很快的得到修正。

  仅仅是几句话的沟通,就能将一个bug在最短的时间内修正,这节省了多少时间?这皆得益于比以往更便捷的沟通。而我们所做的,不过是移动了一下位子,减少了我们之间的沟通成本,却大大的提高了开发效率——我已经记不清有多少bug在还没提交之前就被消灭掉了。但这也对我们测试提出了更高的要求,虽然之前的我们也很强调沟通能力,但现在由于需要更频繁的沟通,我们对沟通能力的提高也变得也越来越重要,成为了最重要的技能之一。

  说到这里,其实我们已经能感受到,测试的角色定位已经变了。因为敏捷开发中,要对质量负责的是整个团队,这一目标就要求测试人员不再是一个独立的质量监督部门,而是要融入到整个团队中,成为开发中不可分割的一部分。

  调整测试用例的粒度

  敏捷宣言里还说,可以工作的软件胜过面面俱到的文档,响应变化胜过遵循计划。那么我们是不是可以都不要文档,不用写用例了呢。我想,如果你的项目是一个“Hello world多国语言版”,大可以如此。但如果是面对一个大型的,多人的,在线的,角色扮演游戏,还是算了吧。

  曾经有位前辈跟我说,测试员最重要的技能就是写用例,通过用例来表达测试思想。我想,即使是到了敏捷时代,这个技能仍然是第一位的。只是,如果你的用例写得过于详细和复杂,那么在团队开始响应变化的时候,你就会措手不及了。

  我就真的遇到过这种情况,某一个设计做到一半的时候,由于效果并不好,被要求进行修改。这时我的用例也要相应的进行修改——最怕这个了。如果这是一系列粒度很细的用例,动辄上千条,一旦改起来,费时又费力。但如果我的用例的粒度本来就并不是非常细,那我调整起来就快速多了。

  至于粒度到什么程度才是合适的呢?那就要看个人的能力,是否强大到能随时调整一份复杂和详细的用例的程度。我个人并不推崇十分详细的用例,因为有些很细节的地方,也没有文档可以参考。而且我们测试的游戏,很多细节没有绝对的对与错之分。即使真的出现了一些有疑问的地方时,迅速的和程序员和策划进行沟通也比写一份更详细的用例要有效得多。要知道,我们的目标也应该和团队内所有的成员一样,是一款可以玩和好玩的游戏,而不是面面俱到的测试用例。

  更多的测试方式

  我看过不少介绍敏捷开发的文章,大都有这么说过:在进行敏捷开发中,快速的响应变化的前提,一定是对质量的保证。如果质量无法保证,那是无法对变化做出响应的。因此这要求程序员能更多的进行自测,包括白盒的,自动化的,测试驱动的。而站在测试人员的角度上,我们能做些什么呢?

  因为对产品接触的更具体,我有了很多机会接触详细的程序设计,这使得我已经可以尝试直接阅读代码,并在此基础上进行测试用例的设计。行话说,这就是灰盒测试。灰盒测试带来的好处是,用例的设计可以比黑盒测试更简洁,而且随着你对程序框架的理解更加的深入,你对所测的产品会更有安全感。当然,传统的黑盒测试是不能抛弃的,因为很多bug都是在你所意料不到的情况下发生的。如何合理的分配灰盒测试和黑盒测试,这还需要在漫长的敏捷测试中慢慢体会。

  除了简单的灰盒黑盒,测试人员尝试做一下白盒也是很有用处的。虽然程序员也做了这样的工作,但测试人员的测试思路会和程序员有所不同,得到的结果也许就会不一样。我就尝试过对核心代码进行白盒测试:包括代码的走查,对函数的独立测试,以及使用内存检测工具的检测,尽管最后还是没有查出bug。

  最后别忘了自动化。由于产品会经常的响应变化——相信我,这事儿真的很轻易的就发生了,对于某些重要的系统的测试就会一次又一次的要重来。若系统简单些还好,若系统是比较复杂,或是比较核心的,如果还是用手动测试,那就会很让人头痛了。所以测试人员的自动化测试是很有必要的。为自己最容易自动化的系统写一个自动测试脚本,这样,随便他们怎么改动,我们都可以随时的进行回归测试了。

  让更多的人参与测试

  当测试人员已经不再是一个独立的测试部门时,需要进行测试的也就不只是测试人员了。程序员要自测,策划也要测试,甚至玩家也可以来测试。不同的人可以得到不同的结果,这样才能使我们对产品有全面的把握,才能时刻的知道产品下一步应该怎样“响应变化”。

  程序员的自测可以减少程序上的bug。策划的测试可以使策划更清楚的看到目前游戏的现状,亲自体验自己设计的系统。而玩家的测试则可以给我们带来我们的最终用户的反馈,这是最有价值的信息。

  我们现在就会经常邀请玩家来进行测试,让我们团队的所有人看到我们所做的游戏在玩家手里是怎么玩的,在玩家心里是怎么想的。这样不断的获得反馈信息,不断的改进后,相信产品会越来越受用户欢迎。最终的目标,就是一个可玩,好玩的游戏,每个人都是这样想的。

  信任你的测试人员

  虽然我是在谈论敏捷测试的体会,但无论你是测试,是策划,还是程序,或者制作人,甚至经理。你都可以而且应该多花点时间和你们的测试人员进行沟通。信任他们,因为他们比这个团队中的任何一个人都更了解产品的现状,他们也是产品面世之前的唯一的玩家。你可以私下找他们聊一聊产品,也可以偷偷的登陆bug管理系统看看现在的bug,甚至可以让他们协助你做一些非测试的工作(例如,产品演示,但不要占用他们的工作时间)。无论如何,他们一定会对你下一步的决策产生巨大的帮助的。

  敏捷究竟是什么?说实话我没怎么仔细考虑过,只是就这样跟着一个敏捷的团队做了一年半的测试,把我们很多传统的测试理念都颠覆了,其实也只不过是在实践中不断的摸索着去改变自己的观念,改变工作方式。直到最近认真的看了看有关敏捷开发和敏捷测试方面的文献,才发现原来这一年半的经历和体会和书中所言是那么的相似,索性借此文和大家分享一下,欢迎指正。
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏1
回复

使用道具 举报

该用户从未签到

2#
发表于 2009-8-17 17:51:29 | 只看该作者

我们这个项目也是敏捷~嘿嘿

状态墙、持续集成、站立会议等12种策略都是敏捷开发模式的表现。
。敏捷开发模式要运用在适合的项目或者产品上,如果不适当也会带来很多问题。
回复 支持 反对

使用道具 举报

该用户从未签到

3#
发表于 2009-8-18 11:47:40 | 只看该作者

这篇转载确实问题比较多,算是个人经验帖

比较认同1楼观点。
用例的编写实力与bug的正常提交保存流程是必须的
转载帖感觉随意性大过敏捷性,这可能和公司项目的综合管理能力有关。
现在确实有些公司这样,坚持发现就改,纯粹口头传达,进度计划随意更改(可能是被迫),没有存档,嫌麻烦用例也很简单随意。急功近利太过浓厚,最后的结果可能就是持续加班而不是持续集成,错误理解了每日building
回复 支持 反对

使用道具 举报

  • TA的每日心情
    慵懒
    2020-8-11 08:18
  • 签到天数: 114 天

    连续签到: 1 天

    [LV.6]测试旅长

    4#
    发表于 2009-8-18 12:25:42 | 只看该作者
    cmm1同样可以快速响应变化。
    事实上cmm1同样可以生产出高质量的软件产品。
    cmm还是敏捷,这并不是什么根本原因,关键在于谁来做。。。
    敏捷模式只是一种结果而已,适合某个团队某些人的一个结果。
    可惜的是,很多企业总喜欢从形式出发……
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    5#
    发表于 2009-8-18 13:12:00 | 只看该作者
    有个疑问:那在什么时候编写用例呢?
    “程序员就坐在我对面的隔间,他一抬头就说:“嘿,X功能做好了,我跑了一遍没问题,你来试试看?””
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2017-9-20 12:50
  • 签到天数: 2 天

    连续签到: 1 天

    [LV.1]测试小兵

    6#
    发表于 2009-8-18 16:05:51 | 只看该作者
    前段时间还见有个朋友问敏捷测试呢。发的及时啊
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    7#
    发表于 2009-8-18 17:06:31 | 只看该作者
    2楼说的很好。

    敏捷也不是free的,如果开发团队距你十万八千里,咋搞
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    8#
    发表于 2009-10-19 12:20:49 | 只看该作者
    呵呵,没怎么接触过,只能充当看客。。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    9#
    发表于 2009-10-19 12:29:08 | 只看该作者
    留下脚印,有空关注
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    10#
    发表于 2009-10-19 15:11:24 | 只看该作者
    敏捷测试好像在游戏测试里用的比较多。。我看过搞游戏测试提过敏捷测试,不过是不是我不清楚
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    11#
    发表于 2009-10-19 16:54:34 | 只看该作者

    从中获得了一些启迪与帮助,感谢LZ

    我们的测试仍然采用的是传统的测试,我想敏捷测试也是因项目而宜
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    12#
    发表于 2009-10-20 00:10:03 | 只看该作者
    学习中  感谢小默默 转载
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    慵懒
    2018-3-14 09:44
  • 签到天数: 134 天

    连续签到: 1 天

    [LV.7]测试师长

    13#
    发表于 2016-8-29 14:20:49 | 只看该作者
    学习中  感谢
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-11-14 14:51 , Processed in 0.109896 second(s), 27 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表