发布新日志

  • 预测:2009年国内软件测试的十大热点(Z)

    2009-03-04 22:12:58

     2009年悄悄地来到了,送走了艰难的、折腾的2008年。人们对2009年会充满更多的期望,9是一个吉祥的数字,天长地久,而且农历是牛年,牛年更牛。

         到了2009年,该为软件测试写点什么。顺民意,预测一下2009年国内软件测试的十大热点。
    1. 基于云的测试将是新的课题,包括测试方法、技术和工具。而且,云环境下的测试也是减少测试成本的一个途径。
    2. 基于Web 2.0/Ajax 的软件测试技术还是热点。Java/Javascript技术变化很快,系统开发框架也是层出不穷。
    3. 软件测试自动化也还是热点,包括更多的开源测试工具、自动化测试模型和框架、自动化测试的理论研究等。
    4. 移动测试:移动计算、移动应用用来,包括3G的应用,移动测试(包括无线应用系统的测试)将会受到更多的关注,是测试的一个新的增长点。
    5. 虚拟技术(如Citrix、微软、VMware的产品)的日益普及,越来越多的测试团队会将虚拟技术应用于测试环境创建、维护和优化,甚至是测试的执行。
    6. 安全测试:软件系统安全形势更加严峻,对安全测试会提出更高的要求,软件工具厂商会推出更多的安全测试工具。
    7. 软件外包测试:中国软件外包迎来发展良机和挑战,大型的软件外包企业发展更快,小的软件外包企业困难增大、被兼并的可能性增大,软件测试在外包企业得到更好的发展。
    8. 测试培训:软件测试培训的竞争将更加激烈,无论宣传还是市场争夺,将会进入白热化的地步。ISTQB将成为2009年国内培训市场的一颗新星。
    9. 课程与图书:有越来越多的大学,为研究生和本科生开设“软件测试”课程。软件测试的图书在2008年很热,在2009年热度,可能依旧不减。
    10. 测试会议和沙龙:全国性或国际性的软件测试会议会成为新的热点之一,软件测试的沙龙越来越多。
  • Testing Book

    2009-02-06 13:46:42

    虽然FP已经列了很多的测试书籍了,但是还是看到会有人问看什么书,我在这里把我自己看的书贴出来(包括已经买了,没有看完和没有来得及看的)。

    测试书籍:
    《软件测试(原书第2版)》
    建议先看这本,这本书是软件测试界的经典书籍,里面的很多理论都写的不错,而且翻译的不错。
    【原书名】     Software Testing (2nd Edition) [原书信息]
    【原出版社】   Sams
    【作者】   (美)Ron Patton[同作者作品] [作译者介绍]
    【译者】   张小松[同译者作品] 王钰 曹跃 等
    【丛书名】   计算机科学丛书
    【出版社】   机械工业出版社
    http://www.china-pub.com/computers/common/info.asp?id=29706

    《软件测试的艺术(原书第2版)》
    这本书技术性强,建议大家现看《软件测试》再来看这本书
    【原书名】     The Art of Software Testing, Second Edition [原书信息]
    【原出版社】   John Wiley & Sons
    【作者】   (美)Glenford J.Myers 等[同作者作品] [作译者介绍]
    【译者】   王峰[同译者作品] 陈杰
    【丛书名】   软件工程技术丛书
    出版社】   机械工业出版社
    http://www.china-pub.com/computers/common/info.asp?id=27827


    《面向对象的软件测试》
    这本书挺难得,如果没有面向对象编程基础就不要看了,看不懂的
    【原书名】     A Practical Guide to Testing Object Oriented Software [原书信息]
    【原出版社】   Addison Wesley
    【作者】   John D.McGregor David A.sykes 著[同作者作品]
    【译者】   杨文宏[同译者作品] 李新辉 杨洁 译等
    【丛书名】   软件工程技术丛书
    【出版社】   机械工业出版社
    http://www.china-pub.com/computers/common/info.asp?id=7078

    《软件测试自动化》
    【原书名】     Just Enough Software Test Automation [原书信息]
    【原出版社】   Prentice Hall PTR
    【作者】   (美)Daniel J.Mosley,Bruce A.Posey[同作者作品]
    【译者】   邓波[同译者作品] 黄丽娟 曹青春
    【丛书名】   软件工程技术丛书/测试系列
    【出版社】   机械工业出版社
    http://www.china-pub.com/computers/common/info.asp?id=14358

    《软件评测师教程》这本书涉及面很广,不过过于理论了,有些地方写的不好不是很看地懂(可能个人水品有限吧,这个考试最近开始火了,不错好像很难考)!
    【作者】   全国计算机技术与软件专业技术资格(水平)考试办公室组 柳纯录 黄子河 等[同作者作品]
    【丛书名】   全国计算机技术与软件专业技术资格(水平)考试指定用书
    【出版社】   清华大学出版社
    http://www.china-pub.com/computers/common/info.asp?id=23803

    以下的书是有关思想方面的书籍,或者说思考书籍,都是由Gerald M.Weinberg(温伯格)写的,这个人的书籍强调思考,强调本质,大家有了时间可以看看。

    《质量·软件·管理:系统思维(第1卷)》
    系统的讲述了什么是质量,质量的本质,不过本书本人还没有看完
    作者:(美)温伯格 著,邓俊辉 译
    出版社:清华大学出版社
    系列:软件与系统思想家温伯格精粹译丛
    http://www.dangdang.com/product/8867/8867166.shtml

    《你的灯亮着吗》
    这本书讲了如何思考,不错的
    【原书名】     Are Your Lights On? How to Figure Out What the Problem Really Is [原书信息]
    【原出版社】   Dorset House
    【作者】   (美)Donald C.Gause;Gerald M.Weinberg
    【译者】   章柏幸[同译者作品] 刘敏
    【丛书名】   软件与系统思想家温伯格精粹译丛
    【出版社】   清华大学出版社
    http://www.china-pub.com/computers/common/info.asp?id=9919

    以下的书籍都没有看过,不过都买好了:

    质量·软件·管理(第Ⅱ卷):一阶测量
    还未看
    【原书名】     Quality Software Management: First-Order Measurement [原书信息]
    【原出版社】   Dorset House Publishing Co.,Inc.
    【作者】   (美)Gerald M. Weinberg[同作者作品]
    【译者】   李先华[同译者作品] 邢彦 张红艺
    【丛书名】   软件与系统思想家温伯格精粹译丛
    【出版社】   清华大学出版社
    http://www.china-pub.com/computers/common/info.asp?id=27538

    《质量·软件·管理--协调行动(第Ⅲ卷)》
    还未看
    【原书名】     Quality Software Management: First-Order Measurement [原书信息]
    【原出版社】   Dorset House Publishing Co.,Inc.
    【作者】   (美)Gerald M. Weinberg[同作者作品]
    【译者】   李先华[同译者作品] 邢彦 张红艺
    【丛书名】   软件与系统思想家温伯格精粹译丛
    【出版社】   清华大学出版社
    http://www.china-pub.com/computers/common/info.asp?id=26184

    《软件自动化测试:引入、管理与实施》
    【原书名】     Automated Software Testing Introduction,Management,and Performance
    【原出版社】   Pearson Education
    【作者】   (美)Elfriede Dustin Jeff Rashka John Paul[同作者作品]
    【译者】   于秀山[同译者作品] 胡兢玉 等
    【丛书名】   国外IT精品丛书
    【出版社】   电子工业出版社
    http://www.china-pub.com/computers/common/info.asp?id=8531

    《软件子系统测试》
    【原书名】     The Craft of Software Testing:Subsystem Testing,Including Object-Based and Object-Oriented Testing [原书信息]
    【原出版社】   Prentice Hall PTR
    【作者】   (美)Brian Marick[同作者作品]
    【译者】   韩柯[同译者作品]
    【丛书名】   软件工程技术丛书/测试系列
    【出版社】   机械工业出版社
    http://www.china-pub.com/computers/common/info.asp?id=14355

    《软件测试:经验与教训》
    【原书名】     Lessons Learned in Software Testing [原书信息]
    【原出版社】   John Wiley & sons,Inc.
    【作者】   (美)Cem Kaner,James Bach,Bret Pettichord[同作者作品] [作译者介绍]
    【译者】   韩柯[同译者作品]
    【丛书名】   软件工程技术丛书/测试系列
    【出版社】   机械工业出版社
    http://www.china-pub.com/computers/common/info.asp?id=14718
  • 对自己好这件事是不用对别人妥协的

    2008-12-04 19:33:42

    对自己好这件事是不用对别人妥协的

    作者:黃力泓 (原创) 2008-10-12 8:09 阅读:148
    关键字: 妥协 关怀自我 

     

    有位大学同学的婆婆是美国人,现住在美国的养老院,朋友每星期和她先生到养老院看婆婆,她婆婆已独居30多年,88岁时还可以独自开车旅行。

    最令我惊讶的是,当我到美国同他们到养老院探视婆婆时,她说婆婆前一星期才换装6颗假牙,共花了20多万台币。如果印象没错,在台湾的老人或家属大概不会想到要帮一位96岁的老太太换更合嘴的假牙,如果假牙不合用,往往老人本身也会觉得算了,家属也多半认为,都96岁了,何必费事、花这个钱?可是朋友的老公是美国人,想法不一样,他希望母亲有较好的牙齿享受食物的美味,没有想过这口假牙用多久的问题,只想着就是要给老妈妈好的生活品质。

    年长了更有资格善待自己
    这件事让我想起,有一次探访一位知名的专栏作家,那年她70岁决定植牙,她不太有钱仍决定花这100万元,有朋友知道后都问,都70岁了为何仍大费周章的植牙?

    面对朋友的质疑,她的想法很简单,「只要活着,就要有好的生活品质。」她说,如果知道植牙后只有2年可活,她照样会植牙,因为可以过2年好品质的生活也值得。

    是的,人总是劳累一辈子,希望到老时可以享受清闲的生活,但真正到老时,却又认为已经老了,也就什幺都算了,仍选择侷促、将就将就地活着,一辈子都没对自己好过。


    人生有限,想做什幺就去做,就是一种生命品质的体现。我们的长者一向被「老」字拘束得紧,觉得老了就应妥协,不应奢求,不应多所要求。

    不!服过社会役和亲子役的你们是最有资格对自己好的一群,何况常常所做的只是合理而没有「特别好」。

    对自己好这件事是不用对别人妥协的。

    享受生活别等到下辈子
    一位朋友的妈妈之前因为不好意思说要换假牙,一直带着一副不合嘴的假牙,只有委屈自己谁也不知。有一天在公园运动时,听同样为假牙而苦的老朋友说换了假牙后吃东西那种快活的感觉,心想「目光不清,牙齿不健,活到老,难道就这幺等着回苏州卖鸭蛋?」

    因而觉悟不再委屈自己,84岁 的她以半年的时间,接受迷你植牙手术,从此不再三餐只喝流质食物,重拾吃花生的滋味,这让她觉得非常开心,不但如此,这位老太太现在更爱笑了。的确,有品 质的生活从体贴自己的需要开始。有不少长者花自己的钱做想做或喜欢的事,还要在意别人的眼光或评价,这样,生命的品质一直出不了头。

    记得以前邻居的阿公阿妈,每次巧遇他们准备出门去玩的模样,问他们要上哪去玩,他们却总是说,「呒啦,只是要去刈香啦!」到庙里刈香是乡镇旅游活动中

    最好的替代字眼,也是真的去庙里进香了,但他们总不好意思直言自己是去玩的,好像去玩是不道德或是逾越本分的事。

    其实,尊重自己的意愿或适度的表达,就是一种品质,喜欢就好,想玩就去玩吧!喜欢就值得去做,别忘了,这辈子就只这一次,遇到好玩的或是幸福的事,

    可别总是期待留给下辈子。有没有下辈子,只有天知道,是吧?

    这辈子就在自己的手中,像一个化妆品的广告词说的「因为你值得」,亲爱的银发长辈,你们值得对自己更好一点。
     
  • 次贷危机与SOA

    2008-11-18 21:24:51

    信息不对称而产生信息孤岛,归根究底是技术方面的原因。美国并不缺乏像微软、IBM英特尔 些在科技上领先的大企业,但是,为什么这些美国企业,没有利用自己的科技研发实力,提前解决政府与商业企业之间信息不对称的问题,遏制住次贷危机的爆发 呢?一个原因可能是由于美国经济结构过于复杂、庞大,要做这样一个能够整合所有数据资源的系统,超出了企业现有的技术能力;另外一个原因则可能是次贷危机 爆发的速度过快,包含着许多不确定因素,企业来不及为政府思考如何从技术层面上去防范危机的产生。我们应当相信的是,在今时今日信息技术如此发达的社会, 没有科技解决不了的问题,所以,一切都只是时间的问题。

      事实上,在解决信息不对称的问题上,IBM公司一直在努力。从2008年的9月份开始,IBM在中国的一些权威媒体上大力推广SOA(面向服务体系的结构)解决方案 务,帮助企业与政府机构解决信息不对称、分散资源和异构系统的整合难题SOA的核心在于确保不同应用程序和异构系统之间的信息数据得到无缝连接与实时交 互。其实早在1996年,全球最具权威的IT研究与顾问咨询公司Gartner便最早提出SOA的思想;200212月,Gartner又提出SOA现代应用开发领域最重要的课题,呼吁社会各界一起来研究SOA的应用性。IBM其实蓄势已久,只是没能赶在次贷危机爆发之前,把服务架构向政府与企业之间延伸。

      可以想像得到,如果处于社会大系统中的各个环节的信息与数据,能够利用SOA解决方案连接紧密,彼此反馈,那么美国次贷危机的发生可能性将会 小之又小。与IBM做的事情不尽相同,位于江苏无锡市的一家潜心于SOA实施的技术服务型企业——德意科技,也注意到了信息不对称引发的管理、经济上的重 大问题,并不断用实力证明中国软件企业可以从中国制造走向中国创造这样的事实。早在2005年,德意科技便开始研发基于SOA实施的产品和解决方 案,经过三年攻关,终于突破了技术障碍,研发成功了基于SOA关联型数据库实时交换管理软件,并在业内率先提出RDMPRealData Management Planning)实时数据管理计划的概念,将管理层所需的数据用实时的、可视的图形界面数据形式表现出来,将管理提升到了量化的数据化层面。据了解,该 产品因此获得国家版权局颁发的计算机软件著作权证书,也获得了无锡市科技局创新项目奖。基于全球领先的技术创新的基础,德意科技获得了国际软件巨头的青睐,在9月份先后与IBM、英特尔结成了合作伙伴关系,强强联手,准备在异构系统的数据整合领域有所作为,与国际同行共同推动SOA事业的发展。

      中国经济面临的风险与机会

      美国经济在信息不对称的前提下爆发了次贷危机,那么在中国,由于信息不对称将会爆发什么危机呢?其实笼统点来看,人民币汇率上升,银根紧缩, 物价、房价上涨,股指下跌等,都是整个社会的信息不对称所导致。港股直通车的提议及全国社保系统的统一、环保治理和实施监控等方案,当然也是出于信息 数据无法在多平台、多系统中流通,而迟迟未能实现。从年初起,国内的一大批企业由于资金链断裂、原材料成本上升、人力成本加大,而不得不关停并转,谋求企 业在经济萎靡期里的出路。说到底,倒掉的企业里,90%以上是由于管理不善导致。中国的企业大多停留在草创期,信息闭塞,对科技不感冒,对管理软件的使用 少之又少,为数不多的一些企业使用了OAoffice automatic)、ERP(Enterprise Resource Plan)CRM(Customer Relationship Management)HRM(Human Resource Management)SCM(Supply Chain Management)等管理软件,但也只是停留在业务层面的简单操作,而不能整合到背后与管理相关联 的数据流,导致管理层判断出错,决策失误,最终让企业走上了一条不归路。

      中国经济要实现自救,中国企业首先要解决信息数据不及时、不准确的问题。为避免像美国一样出现类似于次贷危机这样的事件,相关人士普遍认为中 国政府应大力推动SOA事业的前进,从根本上解决信息孤岛的问题,利用技术平台,一方面能实时监管一些大型私有及国有企业,及时发现企业存在的弊端,施以援手,同时规范市场环境,打击投机倒把的行为;另一方面做为企业方,要从长远着想,正确评估企业现况,及早解决信息不对称,消除信息孤岛,从信息化的基础建设做起,用实实际际量化的数据来审视企业内外部环境,做到未雨绸缪,及时遏制风险的滋长,做出正确的管理决策。

      风险总是与机会并存的,从美国的次贷危机中我们也看到了中国经济的缩影,每个国家的经济结构都有一定的相同性与可借鉴性,如果不客观汲取美国过去的经验教训,从根本上解决问题的本质,那么中国经济,也许将会成为次贷危机下的另一个华尔街

  • 敏捷测试体会谈

    2008-11-07 17:42:24

    严格的说,我对于传统测试没有太多经验。从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,甚至可以让他们协助你做一些非测试的工作(例如,产品演示,但不要占用他们的工作时间)。无论如何,他们一定会对你下一步的决策 产生巨大的帮助的。

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

Open Toolbar