qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

性能测试的BLOG

http://blog.sina.com.cn/s/blog_5fa3c7dd0100uu5w.html

posted @ 2011-11-11 10:20 顺其自然EVO 阅读(131) | 评论 (0)编辑 收藏

ERP系统BETA测试攻略

  关于ERP,关于BETA测试理论性的文章太多了,看多了就是两种结果,经历过的只当看过了,没经历过的还是不知道怎么做。最近产品要发版了,准备开展BETA测试,10余家的BETA测试项目,无奈新人太多,怎么才能让大家了解到BETA测试的实战经验以及遇到困难的时候如何应对?今天加班“愤笔急书”写了一个BETA测试攻略,在这里也拿来和大家分享一下,希望我的经验能够成为你开展BETA测试的锦囊妙计。文章中没有太多讲解BETA测试的理论,如果你还不明白的,可以先看一下BETA测试相关的理论知识,同时相信我这篇文章对于ERP项目实施也会有一些帮助,在此先感谢各位的拜读!(相关文档涉及公司资料,不便提供,敬请谅解)

ERP系统 BETA测试攻略

  首先恭喜你将代表公司参加ERP系统的BETA测试,你将被派驻“前线”开展BETA测试的艰巨任务。任务中你会直接面对客户,和客户进行沟通交流。你也许会听到客户的赞赏,友好的沟通,也许会听到客户的批评乃至抱怨,甚至是不信任。你需要通过这次BETA行动让客户的赞赏升级到对ERP系统的敬仰;你需要扭转客户的抱怨以及对产品的不信任,让他们重新认识ERP系统,认可ERP系统这一款伟大的产品。你准备好接受这次挑战了吗?Let’go!党和人民期待你的凯旋归来!

  (BETA测试流程)

  (团队与协作)

  请确认你的BETA测试团队的负责人以及成员。你的团队中会有测试人员以及开发人员,还可能有部署、性能专家,也许还会有产品经理或者需求分析师。不管你的团队有多少人,请记住一旦出发,你们这个团队需要完成BETA测试的所有任务。在前方你需要和现场的实施顾问进行紧密协作,他们是你们在现场面对棘手问题的最有效的盟军。不要尝试自己解决所有的问题,遇到紧急情况可以与总部取得联系,记住你所在BETA测试项目的内部接口人,你遇到的所有问题以及需要寻求总部支持的时候都可以和他取得联系,他是你在前线唯一的接口人,你只需要在前线有条不紊的开展工作,不要被烦心事打乱你的计划,否则你将功亏一篑。

  (行前准备)

  当你被任命为BETA测试团队负责人的时候,你的第一件事,就是和你的团队成员进行沟通,包括你的内部接口人。明确BETA测试的计划安排,并达成一致,注意你必须在计划时间内完成BETA测试,请珍惜每一天,每一分钟。具体请查看《ERP系统BETA测试计划客户信息.xls》,上面有你想要的所有信息。

  第二件事,了解测试计划客户信息文档的内容后,与对应机构的实施顾问进行一次详细的沟通,了解必要的信息:

  1> 了解项目的大体情况,客户关系,客户诉求等

  2> 客户应用业务的领域以及具体应用的业务模块

  3> 客户是否有大量的二次开发业务,主要集中在哪些领域

  4> 客户项目的阶段,上线初期?实施阶段?维护阶段?一期验证,二期准备上线?

  5> 客户应用的环境(操作系统、数据库类型、数据库大小),客户应用ERP系统的规模(大型的客户可能已经有多台服务器集群,如果环境过于复杂,对于后续的验证、升级都会有巨大的挑战,需要提前预知这些风险,及时做应对策略)

  6> 现场的业务以及技术实力的了解。BETA测试能够前往前场的人员有限,不可能验证到所有的业务领域,在环境部署以及服务器配置上也不可能把专家派往每一个现场。所以了解现场的业务以及技术实力非常重要以便于到了现场以后的工作开展。有一部分工作是需要实施顾问配合我们一起完成的。

  了解了必要的信息后,要把你的BETA测试计划(《ERP系统Beta测试现场工作计划_xx客户.doc》)进行整理,并发给实施顾问,让实施顾问和客户做好沟通,并确认。

  有很多实施顾问都没有经历过BETA测试,有的容易把BETA等同为总部人员帮机构完成客户实施交付,有的认为BETA测试是总部派人员来解答客户的问题,你需要把BETA测试和顾问解释清楚,双方要对BETA测试的目标和过程意见一致。具体可以把《ERP系统Beta测试说明文档.doc》发给顾问,并进行说明,如果有需要在BETA测试客户交流沟通的时候也可以提供这份文档,让客户有正确的理解。

  不论在行前沟通还是到现场和顾问沟通,都要注意以下一些顾问最为关心的问题。

  Q:BETA测试对机构有啥好处?(这是机构最喜欢问的问题,也是最核心利益的问题)

  A:BETA测试需要机构来协助总部来验证产品相关的功能以及质量的状况。总部给予机构对客户实际应用的业务进行产品的验证,发现可能存在的缺陷及时修复。如果BETA客户需要正式升级的,总部会支持客户正式环境的升级,通过BETA期间总部的支持大大提升升级效率,升级过程中所有的问题总部都会有绿色通道直接解决,对于需要升级的客户来说好处显而易见。

  Q:BETA测试总部派人来帮助机构完成项目实施交付?

  A:NO,BETA测试的目标是来验证产品的质量稳定性,为正式发版进行实战的验证过程,与项目实施交付并没有直接的关系。但在BETA期间可能会涉及到预测试,甚至客户环境正式升级,可能和项目有一定的结合,但BETA测试的结束不以项目进展为目标,而是以BETA测试的目标达成为结束标志。

  Q:你们赶紧过来吧,客户有很多需求需要总部给予解答

  A:BETA测试阶段主要目标是验证产品的质量以及业务功能的正确性,客户的需求我们可以协助记录并反馈给总部,由总部后续给予解答,但BETA测试团队不对相关的需求问题给予任何承诺,也不会在BETA测试期间解决相关的需求问题。

  Q:BETA测试把客户正式环境升级以后,你们不能走啊,要等客户完全没有问题才能走。

  A:BETA测试有详细的流程以及相关问题处理的方案,正式升级后我们会有一个观察期,客户整体应用没有重大问题后,BETA测试团队就会返回,后续如果还有问题可以按照日常提单流程进行反馈,总部会有相关人员协助处理的。

  Q:BETA测试的费用谁承担?

  A:BETA测试的费用由总部承担,机构无需承担任何费用。

  Q:那你们来吧,我们比较忙,正好ERP系统客户就交给你们了

  A:BETA测试期间必须有实施顾问全程参与,坚决不允许总部BETA测试团队直接和客户接触。所有涉及到商务、需求等相关问题,BETA测试团队不便于和客户直接接触。且相关的客户信息以及交流需要通过顾问的协调和参与。

  第三件事,如果有可能尽量拿到客户的最新帐套,在研发内部进行一次预升级测试,升级过程是BETA测试期间问题最多且最为耗费时间的环节,如果可以拿到客户帐套在研发内部做一次预升级,及时发现可能存在的问题并在研发内部修改完成,有利于现场BETA测试的快速开展,也能够较好的给顾问以及客户信心。

  第四件事,出发前必要的准备,请查看《Beta测试行前准备事项检查表.xls》。

  1> 准备你所需要的笔记本电脑,鼠标,网线。注意安装必要的OFFICE软件,抓图工具等等,BETA测试的相关文档记得出发前索取

  2> 带上你的邮件系统密码卡,邮件系统将是你和总部沟通的关键工具

  3> 记录下你对应项目的内部接口人、部门经理、项目总监等关键人物的手机号码,在遇到突发事件的时候不会手忙脚乱,总能找到你需要找到的人

  4> 出发时间明确后,记得给实施顾问打电话,让他们协助定一下酒店,酒店的位置最好在客户的附近,免除奔波之苦。注意出差标准,和实施顾问明确,否则多的费用是要你自己出的。

  5> 带上身份证,注意当地未来的天气变化,多准备一些衣物,身体对于BETA测试尤为重要,时常记住你所肩负人民的嘱托,不要误了大事。

  6> 最后就是走之前填写出差申请

  (BETA现场阶段)

  --启动会议

  当你离开深圳的时候,就要开始带领你的团队独立作战了。到了目的地安顿好住宿后,先和实施顾问进行联系,找个时间进行一下项目的沟通,交换一下BETA测试的意见,这个时候不要有客户在场,等双方就相关事宜达成一致后,在和客户进行沟通,开展BETA测试启动会议。BETA测试形式不限,有的客户可能会隆重的开会,有的客户可能就确认一下即可。形式不重要,只要和客户确认了整个计划以及BETA测试的目的即可。

  再次强调,整个BETA测试开始就一定要说清楚,实施顾问必须要全程参与,换人可以,但必须保证每天都有实施顾问在现场。

  --预测试

  预测试环节是BETA测试最为重要的环节,是直接决定BETA测试成败,以及检验BETA测试效果的因素。所以预测试需要认真对待,并且百分百投入。

  1> 预测试开始阶段一定要制定一个详细的预测试计划,把客户常用的业务流程进行总结梳理,先设计一个测试方案,测试方案需要有测试用例,颗粒度可以粗一些,但一定要有明确的验证思路。计划的时候一定要考虑可能存在的风险以及客户方的因素。比如客户方业务的参与时间和安排,系统能够切换的时间,任何工作不要过多的影响到客户的正常业务工作。客户复杂的环境以及升级所需要的周期都要纳入到考虑的因素中,总之就是要做好风险管理,把一切可能的因素都考虑进来。

  2> 预测试期间必须关注此次版本测试的目标(质量稳定?扩展平台?性能优化?),这些都必须纳入到你的测试方案中。每项工作都要落实具体的人员,前线的资源是有限的,这个时候不要区分什么需求、开发、测试和顾问,所有的人都应该全力投入到验证过程中,分工有侧重,但并不代表只要各扫门前雪,需要一起开展工作的时候就要全力投入,特别是业务验证阶段,任务最为繁重。

  3> 请按照部门要求在客户现有版本上收集相关业务的性能数据,填写《ERP系统beta验证性能收集.xls》,这个是未来我们未来需要解决的性能关键点。同时你还要填写一个文档《ERP系统Beta测试性能优化验证列表.xls》,这个里面描述了本版本性能优化的点,你需要在升级前在客户的现有版本上收集数据。然后在升级到最新版本,再次收集一次数据,这样才能了解我们这次性能优化的效果如何。

  4> BETA测试一定要想清楚了在开始动手,一切计划准备就绪以后就开始BETA测试吧。BETA测试切记的一点就是时刻做好备份,备份是你一切工作开展的基础。一旦没有备份,造成的后果将是毁灭性的,所以一定要记住!!!不要怕麻烦,有风险的时候就备份一次。做预测试的时候备份账套,执行脚本的时候备份账套,发过来的私家包替换前先备份被替换的文件……

  5> 按照当初制定的计划开展整个BETA测试的执行工作,遇到问题就按照流程进行反馈,直到问题的解决。如果客户关注到我们的某个问题,不要谎报瞒报,客观的和客户反馈并积极跟进解决,千万不要欺骗客户。当然很多工作是需要大家在下面做好的,在客户面前尽量展现良好的精神风貌,无论是产品还是个人。

  6> 预测试期间发现的问题注意更新《ERP系统Beta测试反馈汇总表_XX客户.xls》,并将该文档及时反馈给研发总部人员,不要简单的等到每天晚上才集中反馈,这样对于问题的处理就会延误。所有的问题请注意和内部接口人事先沟通,定一个问题的编码规则,否则会容易乱套的。建议的编码规则为“客户简称_日期_序列号”,比如中国运输的客户,问题编号为“zgys_20100615_002”,这样编号的好处是唯一编号,便于总部和现场的邮件跟踪,有个日期能够方便的了解每天所有问题的处理结果。

  7> 预测试过程中所有的细节都要详细记录,不要被表象麻痹了双眼,特别是数据库升级的时候,每一步的异常以及你的处理方式都要详细记录,因为所有的问题在你正式升级的时候都有可能碰到,如果你没有记录清楚,正式升级的时候带来的影响会是致命的。

  8> 除了每个问题的及时更新,在辛劳一天以后BETA测试负责人还需要对一天的工作进行总结,把项目的大体情况反馈到总部。你也许还坚守在客户的现场,也许你正在酒店舒适的床上,但请记住一定要发送《ERP系统Beta测试_工作日志_XX客户.xls》给总部对应的接口人

  预测试工作比较艰辛,可能你会发现很多的问题在研发的时候都没有碰到,但在客户现场却时常出现,这就是 BETA测试的目的,请认真思考每一个问题,这将是你BETA测试期间最大的收获,也许会是你人生中重大的一次经历。BETA团队负责人注意BETA测试进度以及计划的把控,这就是一次项目管理的亲身经历,也许对于你来说担子重了一点,但你应该庆幸你有这么一次难得的锻炼机会。把自己想象成是麦克.阿瑟或者隆美尔,运用你的聪明才智取得这次“非洲战役”的胜利。

  --系统切换

  系统切换的成败取决于预测试是否充分完善,所以正式升级前请对预测试的内容进行一个回顾,把相关的内容整理清楚,特别是升级和环境部署过程。

  1> 正式升级前一定要把升级计划及时间安排反馈给你的总部接口人,也可以让总部接口人为你在指定的时间内安排可能的支持人员

  2> 正式升级前请做好所有需要备份的工作-环境、数据库、脚本、模板等等

  3> 制定升级计划以及明细的升级步骤,包括每个步骤可能的耗时。想好每一步的后路,做好最坏的打算。即便是升级不成功至少还可以还原客户现有的环境,不影响客户的业务的继续开展。

 4> 计划和步骤明确后,选择好升级时间就可以开始正式升级了,安装正式环境-升级数据库-执行脚本-升级成功。升级过程多少都会有一些小的意外,不要惊慌,认真分析问题产生的原因,并与总部进行沟通寻求帮助。

  5> 经过一到两个不眠之夜(也许会更长),正式环境升级成功,还不要高兴的太早,请安排所有的人员铺到系统上做一个基本的业务验证,做一个凭证,走一张供应链单据,……至少要保证重大业务功能的正确性。此时的验证范围一定要准,一定是客户应用的关键流程,这些业务没有问题,至少客户在正式使用的时候不会造成恶劣的影响。

  --运行观察

  当第一个工作日的来临时候,也是最为紧张的时刻,客户平稳的运行将是你期待的结果。如果遇到了突发问题一定要沉着冷静,要以最快的速度分析问题,并寻求总部的解决,要不断关注问题的解决过程,最好是每4个小时就和总部确认解决情况,这个时候是分秒必争的时刻。不要因为紧张而忽略了要求,继续按照《ERP系统Beta测试反馈汇总表_XX客户.xls》的要求进行反馈沟通,不要以为一个个问题邮件反馈会来的快,那样只会更乱。

  随着系统的稳定,你的等待期间也许会变得悠闲,你的心情也许会格外舒畅。可以和客户方的业务人员拉拉家常,聊聊家庭,生活,工作。在轻松愉快的过程中建立深厚的友谊,这都是缘分呀。在闲扯中不要忘了和客户交流一下产品的应用感受,收集他们的感受,日后也是我们产品改进的方向。

  记得在空闲的时候操作一下系统,填写《ERP系统测试性能优化验证列表.xls》,用数据来感受我们的性能优化的成果。

  --BETA报告

  当一切的艰辛都已成往事,你该为你的工作感到自豪,你已经具备了相当的项目管理能力,闭上眼睛回顾一下你在客户面前从容不迫的神情(尽管你的内心非常的紧张),在面对问题的时候果断正确的决策,还有麦克.阿瑟将军般的指挥风采。原来“非洲战役”对你来说是如此般的成功,想象你正在接受人民的欢呼和祝贺……

  这种感觉是不是非常的好?×&……%¥#@!,擦干口水该起床了。顺利完成BETA测试后,请准备你的 BETA测试报告《ERP系统Beta测试报告_xx客户.doc》,记住测试报告编写完成以后请一定发给BETA测试总负责人审核一下,确认符合要求且没有问题的时候在给客户签字,不要犯一些低级错误,这个是非常影响公司专业形象的。

  BETA报告签字的时候和客户领导简要交流一下此次BETA测试的过程以及成果,特别是功能改善以及性能提升部分的典型成果,我们的目标是帮助客户成功!请让客户体验到帮助客户成功后的喜悦,同时也让客户看到你艰辛努力换来的丰硕成果!分手道别的时候向客户送上公司准备的精美礼品,也祝福客户一帆风顺,飞黄腾达!

  客户可能会谈到一些遗留问题以及后续维护的顾虑,请告诉他我们的策略,打消他的后顾之忧。

  --BETA测试结束

  BETA测试结束,也请整理好你的行囊,整理你所有的费用发票,便于回家后报销。如果可以的话,建议拉上实施顾问找个当地有特色的小馆子小酌几杯,当然这个费用公司不会给你报销的,因为公司提供了出差补助。不要过于在乎这点小钱,对于此次BETA测试你所获得的收获,这点小钱实在算不了什么。日后项目还需要实施顾问继续跟进,难得一次天南海北的相聚,留下一个美好的记忆。说不定日后一不小心又会在一起战斗呢。

  人生就像一场旅行,不必在乎目的地,重要的是沿途的风景和看风景的心情……,退房,赶飞机,回家咯……!

 

 

posted @ 2011-11-10 14:19 顺其自然EVO 阅读(229) | 评论 (0)编辑 收藏

人机交互的测试

当我们在接到一个需要测试的项目或任务时。我们通常往往思考的是在系统中出现的错误现象。如单击某个按钮出现了http500现象,或是其他错误页面。这在我们测试中是无可非议的测试工作。大家有没有想过当你接受这个软件时,她就像一个你从未接触过的汽车。每个档位的转换,每个功能按钮的操作、及其作用都是陌生的。在这个时候你感觉麻烦的地方是最多的时候,有些问题当你接触的时间长了你会有一些麻木感。往往这些麻木感就会变成了习惯。习惯的东西也就无所谓了,或许就是正确的。

  很多项目或产品,当我们的系统软件拿到用户现场的时候。我们的用户会提出一大堆问题。这个该怎么做,那个该怎么做。为什么会有这么多问题的反馈。项目还好说我们大不了给他们进行培训。当我们做成产品的时候,批量生产发货的时候,我们就没有精力去照顾每个用户。用户最开始使用你的东西时,第一印象是非常重要的,用户很少会花很长时间去试用你的推荐。用户感觉这个软件或系统好不好用,很大程度上是在他与机器之间的互通上。

  我感觉有两点值得我们测试人员关注的。

  其一,系统本身的操作,其繁简程度、流程规划上。我们应该熟知业务的需求、规则。如出版业务都需要其三审,每一审我们展现的同样的东西,他们也能工作。有时开发图省事把所有的功能都整合一起,共同使用。必然会带来很多没必要的操作。他们的重点是不一样,我们不应该把每一审都一样,我们要展现给每一审的他们关注的重点,他们的需要的操作。每个人测试的行业都可能不一样,这就需要我们去了解它,运用到我们的测试中。

  其二,用户本身常用操作,使用习惯。这里也就是说用户的习性了。如用户等待时间等。及其软件使用的一些“潜规则”。如按钮的摆放,一些页面的大小等。这就需要我们在平时的多加积累。之前刚开始测试遇见一个问题,就是在弹出页面后让选择其多个目录。我单击一下选择框没选中,又单击还是没选中。之后又单击的内容才勾选上前面的选择框。这一个问题就凸现了我们的使用习惯。在用户使用中一些规范的提示。图标的运用、快捷键、提示的语义等问题,也是值得我们注意的。

  刚接手的系统,它的安装、配置、使用等,应该去记录我们感觉有疑问的操作。在之后的测试工作中在详细的去分析这些疑问。该增、改减、该修、该改,我们再去判定。

posted @ 2011-11-10 14:13 顺其自然EVO 阅读(181) | 评论 (0)编辑 收藏

量化项目管理案例:缺陷趋势预测利器(7)

  在之前的文章里,已经介绍了几种不同的成长曲线的形式,知道了几种曲线的趋势情况。比如,指数曲线就是呈指数的不断增长;S型曲线就是先增后趋于平稳。然而,再进一步,怎么拟合出适合给定样本数据的模型曲线呢?这回,我们介绍曲线的几种拟合算法。

  曲线拟合主要有3种算法:三点法、三和法和高斯-牛顿法。下面简单介绍3种算法的原理。

  1、三和法:

  三和法是利用三个和值来进行计算。将数据平均分成三段,分别求这三段数据的和;随后将三个和值依次做减法;通过求减法得出要预测的参数。也就是求解三元一次方程组,得到最终参数的值。

  2、三点法:

  三点法亦如它的名字,是利用三个点的值来进行计算。选择数据的起点、中点和终点,得到三元一次方程组;解出方程组,得到参数值。

  3、高斯-牛顿法:

  高斯-牛顿法是用逐次逼近的方式来得到最佳参数值。高斯-牛顿法的计算过程是一个不断迭代的过程。由于高斯-牛顿法的计算原理为寻找最优值,因此得到的结果应该最接近实际情况,拟合度最高。然而,高斯-牛顿法对数据要求较高,会出现由于数据原因无法计算的情况。

  由于算法公式较为复杂,暂时没有发表在网站上,但我们会尽快整理。

 三和法

三点法

高斯-牛顿法

原理将大量数据分为3段3点确定一条曲线迭代寻找最优值
对数据个数的要求最少9个3个无要求
易用性较为易用 易用对数据要求严格,易用性较低
准确度较为准确准确性较差准确
可能不适用的情况样本连续出现多个0样本连续出现多个0无法简单判断,只能通过计算得出
使用场景已有一定数据量,可用于评断一个模型合适与否,或用于跟踪、更新模型数据量不够,用于策划得到初始模型数据量要求无太大限制,可用于评价模型的使用情况
注意事项时间从0开始和从1开始计算公式不同选取的三点距离应相等 最优值的选取标准是R2 

posted @ 2011-11-10 11:28 顺其自然EVO 阅读(230) | 评论 (0)编辑 收藏

如何带好软件测试新人

 1、熟悉工作环境,认识新同事

  2、制定学习计划、跟进学习进度

  (1)了解新人的情况,制定出尽量适合新人的学习计划,计划制定的要细致,包括各个阶段要学习的内容、学习时间、学习资料、学习产出。

  (2)找个机会和新人一起看下学习计划,讲解计划内容以及认真听取新人的意见,根据新人反馈的信息适当的调整计划。和新人的沟通可以让自已更能了解新人,制定尽量适合新人的计划能让新人带着合理的目标去学习,而不会让新人感到迷茫和困惑。

  (3)跟进学习进度是让自已了解前期制定的计划是不是适合新人,并且可以通过这种方式了解新人的学习情况和遇到的问题,及时根据具体情况协助新人解决。在新人执行计划前,告诉新人以日报的形式反映学习进度、遇到的问题、心得。

  3、讲解概念性的问题,让新人从整体上有个大概了解

  (1)工作内容:新人一进来不知道自已所在的组是做什么测试的,自已的职责和任务是什么。所以师傅要主动介绍工作内容,测试的系统是什么,是通过哪种方式进行测试,以及她将来要做的工作是什么。

  (2)发布流程方面:告诉新人发布流程的学习网址,告知流程平台的作用。

  (3)业务方面:

  ● 告诉新人业务的学习网址,告知业务学习是根本,虽然一进来是做接口测试,但是只有在了解业务的情况下才能更好的胜任测试的工作。

  ● 把自已以前整理好的主要业务流程图和基本业务术语文档给新人,先让新人阅读,第一遍看新人肯定会懵,所以师傅应该给予大概的讲解,告诉新人遇到任何问题都可以问,不怕被打扰,只怕没问题问,因为只有新人带着问题问才知道新人需要什么帮助。

  ● 新人有一定的经验后可以给予新人整理某块业务的机会,这样有助于她对这块业务更深层次的了解。由于我带的新人所分配的工作任务是做接口测试和偶尔做功能测试,其实在做功能测试的时候她已经了解了一些业务,所以我会整理出相关业务的一级业务点和底层对应的接口,然后让新人查找知识沉淀或者功能基线用例库把该业务的所有业务点画出mm图,让她试着根据阅读接口的实现代码进行完善mm图。

  (4)测试流程方面:测试流程是新人需要掌握的,这样可以让新人知道整个测试各个阶段需要做哪些工作,包括:什么时候了解需求、什么时候测试用例评审、什么时候开始测试、什么时候接口测试完成进入功能测试、什么时候daily测试,什么时候预发测试。

  (5)测试技术方面:

  ● 给新人分享所测系统的架构以及如何搭建接口测试环境,这个分享是很有必要的,新人不仅要知其然而且要知其所以然,所以讲解的时候要通俗易懂,目的只想让新人知道被测系统是怎样的架构,我们又是如何进行接口测试的,直到新人能真正理解为止。

  ● 给个简单的接口让新人第一次与接口测试亲密接触,我是以一个业务逻辑非常简单的接口让新人做的,因为第1次做接口测试,我会告诉她如何去设计正常流和异常流测试用例,如何写测试脚本和验证点到位。同时,我会写好第1个测试脚本,然后让她完成其他脚本的编写,并且给予review。

  ● 给新人找个稍微有点业务逻辑的接口让她测试,这样她可能通过对这个接口测试了解到相关的业务,也可以了解更复杂点的开发代码

  ● 告诉新人如何提bug

  ● 告诉新人测试过程中的重点是什么,以及测试时间的把握

  4、善于听取新人的问题并给予回复

  (1)新人问问题是一件非常正常的事情,反而没有问题可以问这才叫人干着急,所以当新人问问题的时候,尤其前几次问师傅问题时,师傅态度要诚恳,要有耐心,要是一个很好的听众。这点是从我师傅宋缺和文朗那学到的,我觉得做好一个师傅,要善于听取新人的问题和意见,这样新人才敢抛出问题,不会把问题烂到肚子里,从而才能解决问题,这样也可以提升以后的工作效率。

  (2)帮新人解决问题时最好告诉新人自已怎么解决的,解决的思路和方法是什么,这样在你帮她解决问题的同时也在教她知识,下次同样的问题她就会解决了。

  5、信任和鼓励对方、让新人更加自信

  (1)第1次让新人整理mm图时,我会给予一些指导,同时自已也会整理同一个业务的mm图,然后对比新人产出的mm图和新人一起讨论,这样可以知道她的思路是什么,思路对不对,以及表达我自已的观点。互相讨论交换思考可以让新人觉得你尊重她,同时她也会很愿意很主动的表达自已的观点。

  (2)新人来到新的环境工作,心里或多或少会有点压力,在工作中偶尔问问新人工作和生活情况,关心下新人,会让她感觉到新环境的温暖,也许可以让她更轻松更快乐的工作。

  (3)多鼓励别人是一种美德,因为这是你对新人的认可,会让新人更有信心和激情去胜任手头上繁忙的工作。

  (4)当新人成长了,达到自已的预估目标时,我觉得要让新人独立的去承担一些工作,可能新人会很有压力,心里会担心万一业务理解的有偏差遗漏了问题怎么办,万一在发布之前测不完怎么办。其实这种心态是很正常的,所以师傅要把握好这个度,要做好review工作,要在适当的时候问问新人进展过程中有什么风险需不需要帮助。当新人独立的完成了测试工作,体会到整个测试并没有延期,并没有遗漏的问题时,新人会更自信的面对以后的工作。因为信任,所以简单。

posted @ 2011-11-10 11:27 顺其自然EVO 阅读(175) | 评论 (0)编辑 收藏

软件探索性测试 笔记四

  *建立起一个全局目标后,再开始测试

  探索式测试的几个目标:

  1、理解应用程序如何工作、它的接口看起来怎样、它实现了哪些功能

  2、强迫软件展示全部能力:

  *目的是让软件努力运行,证明软件确实实现了设计时所要求达到的功能

  3、找到缺陷,并有目的的使缺陷数量降为零

  把软件特性划分成几个相互重叠的“区域”,具体区域和测试方法如下:

  商业区:

  *含义:用户所要使用的软件特性和功能,你的软件包装盒上描述的特性和掩饰的特性及代码

  测试方法:

  1、指南测试法:根据用户说明书来测试

  2、卖点测试法:观摩哪些销售演示,测试演示过程,并且可以加上质疑测试法

  3、地标测试法:提前确定关键的软件特性,确定他们的前后顺序

  4、极限测试法:向软件提出最困难的问题

  5、快递测试法:关注于数据,找到每个和数据有接触的软件特性

  6、遍历测试法:通过选定一个目标(例如所有菜单项、所有错误消息或所有对话框),然后使用可以发现的最短路径来访问目标包含的所有对象

  历史区:

  *含义:从前版本遗留下的代码,还有那些曾经出现较多缺陷的特性和功能

  测试方法:

  1、恶邻测试法:反复测试缺陷特别多的地方

  2、博物馆测试法:关注被接受重新修改的老代码,或者是没被改动就放到新环境中运行的老代码

  3、上一版测试法:回归测试,关注新版本中无法再运行的测试用例

  娱乐区:

  *含义:软件的辅助特性,而不是主线特性

  测试方法:

  1、配角测试法:关注和主要的特性非常邻近的特性,例如和主要的特性一同出现在显示器上,容易被用户注意

  2、深巷测试法:软件中最不可能被用到的或者最不吸引用户的特性,有助于提高代码覆盖率

  *注:多个特性混合在一起测试时,比如重要的和不重要的混在一起时,可以考虑:

  **有关输入的问题:这两个特性会不会处理同一输入

  **有关输出的问题:这两个特性功能是否在可见的用户界面上操作同一块区域?他们会产生同一个输出吗?

  **有关数据的问题:这两个特性会操作其共享的一些内部数据?是读取共享数据、还是修改共享数据

  3、通宵测试法:性能测试和压力测试,永远不关闭程序,连续不断的使用某些特性来测试软件

  旅游区:

  *含义:只对新用户有吸引力的特性和功能,它关心的是快速访问软件的各种功能,而不是关心软件是否工作

  测试方法:

  1、收藏家测试法:收集软件的输出,收集的越多越好

  *背后的思想是测试人员到达所有那些可到达的地方并把观察到的输出结果记录下来

  2、长路径测试法:测试离应用程序开始点尽可能远的特性,例如:哪个特性需要点击N次才能被用到,选定该特性,一路点击过去,然后测试它

  *指导思想:到达目的地前尽量多的在应用程序中穿行,因而要选取埋在应用程序最深处的特性

  *可以结合收藏家测试法

  3、超模测试法:只关心表面的东西

  4、测一送一测试法:测试时运行一个应用程序,然后运行该应用程序的另外一个拷贝,然后再运行一个拷贝时,关注网络传输数据、文件操作等方面

  旅馆区:

  *含义:指一些经常被忽视的或者在测试计划中较少描述的次要的及辅助功能

  测试方法:

  1、取消测试法:

  *启动操作然后停止它,并花些时间在应用程序里四处检查

  *找应用程序中最耗时的操作来充分实施这种方法

  *可以尝试开始一个操作,不要停止它,然后再开始另一个同时的操作

  *在取消被测对象之前应该改变被测对象的状态,这点也很重要

  2、懒汉测试法:做尽量少的实际工作,

  *可以尝试接受所有的默认值,测试程序对默认值的处理情况

  破旧区:

  *含义:指一些经常被忽视的或者在测试计划中较少描述的次要的及辅助功能

  测试方法:

  1、注意输入的限制,哪些是非法输入;注意不按照指定的顺序做事情

  2、重复执行同样的操作,重复输入同样的数据

  总结:

  跟踪哪种测试法发现的缺陷最多,哪种执行时间最少,哪种的代码、界面、功能覆盖最多等

posted @ 2011-11-10 11:20 顺其自然EVO 阅读(140) | 评论 (0)编辑 收藏

教你维护SQL Server数据库日志。

导读】教你维护SQL Server数据库日志

  交易日志(即oracle中的事务)(Transaction logs)是数据库结构中非常重要但又经常被忽略的部分。由于它并不像数据库中的schema那样活跃,因此很少有人关注交易日志。

  交易日志是针对数据库改变所做的记录,它可以记录针对数据库的任何操作,并将记录结果保存在独立的文件中。对于任何每一个交易过程,交易日志都有非常全面的记录,根据这些记录可以将数据文件恢复成交易前的状态。从交易动作开始,交易日志就处于记录状态,交易过程中对数据库的任何操作都在记录范围,直到用户点击提交或后退后才结束记录。每个数据库都拥有至少一个交易日志以及一个数据文件。

  出于性能上的考虑,SQL Server将用户的改动存入缓存中,这些改变会立即写入交易日志,但不会立即写入数据文件。交易日志会通过一个标记点来确定某个交易是否已将缓存中的数据写入数据文件。当SQL Server重启后,它会查看日志中最新的标记点,并将这个标记点后面的交易记录抹去,因为这些交易记录并没有真正的将缓存中的数据写入数据文件。这可以防止那些中断的交易修改数据文件。

  维护交易日志

  因为很多人经常遗忘交易日志,因此它也会给系统带来一些问题。随着系统的不断运行,日志记录的内容会越来越多,日志文件的体积也会越来越大,最终导致可用磁盘空间不足。除非日常工作中经常对日志进行清理,否则日志文件最终会侵占分区内的全部可用空间。日志的默认配置为不限容量,如果以这种配置工作,它就会不断膨胀,最终也会占据全部可用空间。这两种情况都会导致数据库停止工作。

  对交易日志的日常备份工作可以有效的防止日志文件过分消耗磁盘空间。备份过程会将日志中不再需要的部分截除。截除的方法是首先把旧记录标记为非活动状态,然后将新日志覆盖到旧日志的位置上,这样就可以防止交易日志的体积不断膨胀。如果无法对日志进行经常性的备份工作,最好将数据库设置为“简单恢复模式”。在这种模式下,系统会强制交易日志在每次记录标记点时,自动进行截除操作,以新日志覆盖旧日志。

  截除过程发生在备份或将旧标记点标为非活动状态时,它使得旧的交易记录可以被覆盖,但这并不会减少交易日志实际占用的磁盘空间。就算不再使用日志,它依然会占据一定的空间。因此在维护时,还需要对交易日志进行压缩。压缩交易日志的方法是删除非活动记录,从而减少日志文件所占用的物理硬盘空间。

  通过使用DBCC SHRINKDATABASE语句可以压缩当前数据库的交易日志文件,DBCC SHRINKFILE语句用来压缩指定的交易日志文件,另外也可以在数据库中激活自动压缩操作。当压缩日志时,首先会将旧记录标记为非活动状态,然后将带有非活动标记的记录彻底删除。根据所使用的压缩方式的不同,你可能不会立即看到结果。在理想情况下,压缩工作应该选在系统不是非常繁忙的时段进行,否则有可能影响数据库性能。

  恢复数据库

  交易记录备份可以用来将数据库恢复到某一指定状态,但交易记录备份本身不足以完成恢复数据库的任务,还需要备份的数据文件参与恢复工作。恢复数据库时,首先进行的是数据文件的恢复工作。在整个数据文件恢复完成前,不要将其设为完成状态,否则交易日志就不会被恢复。当数据文件恢复完成,系统会通过交易日志的备份将数据库恢复成用户希望的状态。如果在数据库最后一次备份后,存在多个日志文件的备份,备份程序会按照它们建立的时间依次将其恢复。

  另一种被称为log shipping的过程可以提供更强的数据库备份能力。当log shipping配置好后,它可以将数据库整个复制到另一台服务器上。在这种情况下,交易日志也会定期发送到备份服务器上供恢复数据使用。这使得服务器一直处于热备份状态,当数据发生改变时它也随之更新。另一个服务器被称作监视(monitor)服务器,可以用来监视按规定时间间隔发送的shipping信号。如果在规定时间内没有收到信号,监视服务器会将这一事件记录到事件日志。这种机制使得log shipping经常成为灾难恢复计划中使用的方案。

posted @ 2011-11-10 11:17 顺其自然EVO| 编辑 收藏

《Linux内核修炼之道》——分析内核源码如何入手?(下)

 下面的分析,米卢教练说了,内容不重要,重要的是态度。就像韩局长对待日记的态度那样,严谨而细致。

  只要你使用这样的态度开始分析内核,那么无论你选择内核的哪个部分作为切入点,比如USB,比如进程管理,在花费相对不算很多的时间之后,你就会发现你对内核的理解会上升到另外一个高度,一个抱着情景分析,抱着0.1内核完全注释,抱着各种各样的内核书籍翻来覆去的看很多遍又忘很多遍都无法达到的高度。请相信我!

  让我们在Linux社区里发出号召:学习内核源码,从学习韩局长开始!

  态度决定一切:从初始化函数开始

  任小强们说房价高涨从现在开始,股评家们说牛市从5000点开始。他们的开始需要我们的钱袋,我们的开始只需要一台电脑,最好再有一杯茶,伴着几支小曲儿,不盯着钱总是会比较惬意的。生容易,活容易,生活不容易,因为总要盯着钱。

  有了地图Kconfig和Makefile,我们可以在庞大复杂的内核代码中定位以及缩小了目标代码的范围。那么现在,为了研究内核对USB子系统的实现,我们还需要在目标代码中找到一个突破口,这个突破口就是USB子系统的初始化代码。

  针对某个子系统或某个驱动,内核使用subsys_initcall或module_init宏指定初始化函数。在drivers/usb/core/usb.c文件中,我们可以发现下面的代码。

940 subsys_initcall(usb_init);
941 module_exit(usb_exit);

  我们看到一个subsys_initcall,它也是一个宏,我们可以把它理解为module_init,只不过因为这部分代码比较核心,开发者们把它看作一个子系统,而不仅仅是一个模块。这也很好理解,usbcore这个模块它代表的不是某一个设备,而是所有USB设备赖以生存的模块,Linux中,像这样一个类别的设备驱动被归结为一个子系统。比如PCI子系统,比如SCSI子系统,基本上,drivers/目录下面第一层的每个目录都算一个子系统,因为它们代表了一类设备。

  subsys_initcall(usb_init)的意思就是告诉我们usb_init是USB子系统真正的初始化函数,而usb_exit()将是整个USB子系统的结束时的清理函数。于是为了研究USB子系统在内核中的实现,我们需要从usb_init函数开始看起。

865 static int __init usb_init(void)
866 {
867   int retval;
868   if (nousb) {
869    pr_info("%s: USB support disabled/n", usbcore_name);
870    return 0;
871   }
872
873   retval = ksuspend_usb_init();
874   if (retval)
875    goto out;
876   retval = bus_register(&usb_bus_type);
877   if (retval)
878    goto bus_register_failed;
879   retval = usb_host_init();
880   if (retval)
881    goto host_init_failed;
882   retval = usb_major_init();
883   if (retval)
884    goto major_init_failed;
885   retval = usb_register(&usbfs_driver);
886   if (retval)
887    goto driver_register_failed;
888   retval = usb_devio_init();
889   if (retval)
890    goto usb_devio_init_failed;
891   retval = usbfs_init();
892   if (retval)
893    goto fs_init_failed;
894   retval = usb_hub_init();
895   if (retval)
896    goto hub_init_failed;
897   retval = usb_register_device_driver(&usb_generic_driver, THIS_MODULE);
898   if (!retval)
899    goto out;
900
901   usb_hub_cleanup();
902  hub_init_failed:
903   usbfs_cleanup();
904 fs_init_failed:
905   usb_devio_cleanup();
906 usb_devio_init_failed:
907   usb_deregister(&usbfs_driver);
908 driver_register_failed:
909   usb_major_cleanup();
910 major_init_failed:
911   usb_host_cleanup();
912 host_init_failed:
913   bus_unregister(&usb_bus_type);
914 bus_register_failed:
915   ksuspend_usb_cleanup();
916 out:
917   return retval;
918 }

 (1)__init标记。

  关于usb_init,第一个问题是,第865行的__init标记具有什么意义?

  写过驱动的应该不会陌生,它对内核来说就是一种暗示,表明这个函数仅在初始化期间使用,在模块被装载之后,它占用的资源就会释放掉用作它处。它的暗示你懂,可你的暗示,她却不懂或者懂装不懂,多么让人感伤。它在自己短暂的一生中一直从事繁重的工作,吃的是草吐出的是牛奶,留下的是整个USB子系统的繁荣。

  受这种精神所感染,我觉得有必要为它说的更多些。__init的定义在include/linux/init.h文件里

43 #define __init          __attribute__ ((__section__ (".init.text")))

  好像这里引出了更多的疑问,__attribute__是什么?Linux内核代码使用了大量的GNU C扩展,以至于GNU C成为能够编译内核的唯一编译器,GNU C的这些扩展对代码优化、目标代码布局、安全检查等方面也提供了很强的支持。而__attribute__就是这些扩展中的一个,它主要被用来声明一些特殊的属性,这些属性主要被用来指示编译器进行特定方面的优化和更仔细的代码检查。GNU C支持十几个属性,section是其中的一个,我们查看GCC的手册可以看到下面的描述

‘section ("section-name")'
   Normally, the compiler places the code it generates in the `text'
 section. Sometimes, however, you need additional sections, or you
need certain particular functions to appear in special sections.
   The `section' attribute specifies that a function lives in a
   particular section. For example, the declaration:

     extern void foobar (void) __attribute__ ((section ("bar")));

   puts the function ‘foobar' in the ‘bar' section.

   Some file formats do not support arbitrary sections so the
   ‘section' attribute is not available on all platforms. If you
   need to map the entire contents of a module to a particular
   section, consider using the facilities of the linker instead.

  通常编译器将函数放在.text节,变量放在.data或.bss节,使用section属性,可以让编译器将函数或变量放在指定的节中。那么前面对__init的定义便表示将它修饰的代码放在.init.text节。连接器可以把相同节的代码或数据安排在一起,比如__init修饰的所有代码都会被放在.init.text节里,初始化结束后就可以释放这部分内存。

  问题可以到此为止,也可以更深入,即内核又是如何调用到这些__init修饰的初始化函数?要回答这个问题,还需要回顾一下subsys_initcall宏,它也在include/linux/init.h里定义

125 #define subsys_initcall(fn)             __define_initcall("4",fn,4)

  这里又出现了一个宏__define_initcall,它用于将指定的函数指针fn放到initcall.init节里 而对于具体的subsys_initcall宏,则是把fn放到.initcall.init的子节.initcall4.init里。要弄清楚.initcall.init、.init.text和.initcall4.init这样的东东,我们还需要了解一点内核可执行文件相关的概念。

  内核可执行文件由许多链接在一起的对象文件组成。对象文件有许多节,如文本、数据、init数据、bass等等。这些对象文件都是由一个称为链接器脚本的文件链接并装入的。这个链接器脚本的功能是将输入对象文件的各节映射到输出文件中;换句话说,它将所有输入对象文件都链接到单一的可执行文件中,将该可执行文件的各节装入到指定地址处。 vmlinux.lds是存在于arch/<target>/ 目录中的内核链接器脚本,它负责链接内核的各个节并将它们装入内存中特定偏移量处。

  我可以负责任的告诉你,要看懂vmlinux.lds这个文件是需要一番功夫的,不过大家都是聪明人,聪明人做聪明事,所以你需要做的只是搜索initcall.init,然后便会看到似曾相识的内容

__inicall_start = .;
.initcall.init : AT(ADDR(.initcall.init) – 0xC0000000) {
*(.initcall1.init)
*(.initcall2.init)
*(.initcall3.init)
*(.initcall4.init)
*(.initcall5.init)
*(.initcall6.init)
*(.initcall7.init)
}
__initcall_end = .;

  这里的__initcall_start指向.initcall.init节的开始,__initcall_end指向它的结尾。而.initcall.init节又被分为了7个子节,分别是

.initcall1.init 
.initcall2.init 
.initcall3.init 
.initcall4.init 
.initcall5.init 
.initcall6.init 
.initcall7.init

  我们的subsys_initcall宏便是将指定的函数指针放在了.initcall4.init子节。其它的比如core_initcall将函数指针放在.initcall1.init子节,device_initcall将函数指针放在了.initcall6.init子节等等,都可以从include/linux/init.h文件找到它们的定义。各个字节的顺序是确定的,即先调用.initcall1.init中的函数指针再调用.initcall2.init中的函数指针,等等。__init修饰的初始化函数在内核初始化过程中调用的顺序和.initcall.init节里函数指针的顺序有关,不同的初始化函数被放在不同的子节中,因此也就决定了它们的调用顺序。

  至于实际执行函数调用的地方,就在/init/main.c文件里,内核的初始化么,不在那里还能在哪里,里面的do_initcalls函数会直接用到这里的__initcall_start、__initcall_end来进行判断。

  (2)模块参数。

  关于usb_init函数,第二个问题是,第868行的nousb表示什么?

  知道C语言的人都会知道nousb是一个标志,只是不同的标志有不一样的精彩,这里的nousb是用来让我们在启动内核的时候通过内核参数去掉USB子系统的,Linux社会是一个很人性化的世界,它不会去逼迫我们接受USB,一切都只关乎我们自己的需要。不过我想我们一般来说是不会去指定nousb的吧。如果你真的指定了nousb,那它就只会幽怨的说一句“USB support disabled”,然后退出usb_init。

  nousb在drivers/usb/core/usb.c文件中定义为:

static int nousb; /* Disable USB when built into kernel image */
module_param_named(autosuspend, usb_autosuspend_delay, int, 0644);
MODULE_PARM_DESC(autosuspend, "default autosuspend delay");

  从中可知nousb是个模块参数。关于模块参数,我们都知道可以在加载模块的时候可以指定,但是如何在内核启动的时候指定?

  打开系统的grub文件,然后找到kernel行,比如:

kernel  /boot/vmlinuz-2.6.18-kdb root=/dev/sda1 ro splash=silent vga=0x314

  其中的root,splash,vga等都表示内核参数。当某一模块被编译进内核的时候,它的模块参数便需要在kernel行来指定,格式为“模块名.参数=值”,比如:

modprobe usbcore autosuspend=2

  对应到kernel行,即为:

usbcore.autosuspend=2

  通过命令“modinfo -p ${modulename}”可以得知一个模块有哪些参数可以使用。同时,对于已经加载到内核里的模块,它们的模块参数会列举在/sys/module/${modulename}/parameters/目录下面,可以使用“echo -n ${value} > /sys/module/${modulename}/parameters/${parm}”这样的命令去修改。

  (3)可变参数宏。

  关于usb_init函数,第三个问题是,pr_info如何实现与使用?

  pr_info只是一个打印信息的可辨参数宏,printk的变体,在include/linux/kernel.h里定义:

242 #define pr_info(fmt,arg...) /
243         printk(KERN_INFO fmt,##arg)

  99年的ISO C标准里规定了可变参数宏,和函数语法类似,比如

#define debug(format, ...) fprintf (stderr, format, __VA_ARGS__)

  里面的“…”就表示可变参数,调用时,它们就会替代宏体里的__VA_ARGS__。GCC总是会显得特立独行一些,它支持更复杂的形式,可以给可变参数取个名字,比如

#define debug(format, args...) fprintf (stderr, format, args)

  有了名字总是会容易交流一些。是不是与pr_info比较接近了?除了‘##’,它主要是针对空参数的情况。既然说是可变参数,那传递空参数也总是可以的,空即是多,多即是空,股市里的哲理这里同样也是适合的。如果没有‘##’,传递空参数的时候,比如

debug ("A message");

  展开后,里面的字符串后面会多个多余的逗号。这个逗号你应该不会喜欢,而‘##’则会使预处理器去掉这个多余的逗号。

  关于usb_init函数,上面的三个问题之外,余下的代码分别完成usb各部分的初始化,接下来就需要围绕它们分别进行深入分析。因为这里只是演示如何入手分析,展示的只是一种态度,所以具体的深入分析就免了吧。

posted @ 2011-11-10 11:10 顺其自然EVO| 编辑 收藏

多些时间能少写些代码

  导读:作者陈皓在微博上说过这样一段话:“聪明的程序员使用50%-70%的时间用来思考,尝试和权衡各种设计和实现,而用30%–50%的时间是在忙碌着编码,调试和测试。聪明的老板也会让团队这样做。而愚蠢的老板,愚蠢的程序员会拿出来100%-150%的时间来忙着赶进度,返工,重构,fix大量的bug…所以,越差的团队一般会越忙,而且还忙不完。”文中作者就此观点进行阐述。

  文章内容如下:

  在现在这个浮躁的时期,再加上敏捷咨询师们念的歪经,他们让人感觉上就像是软件产品是可以在很短的时间内高质量的完成的,这令那些管理者们很兴奋,就像巴甫洛夫的条件反射实验中的狗看到了肉就像流口水那样兴奋。他们使用TDD,快速迭代,不断重构,持续集成直至持续部署的方法在进行软件开发

  软件开发真是这样的吗?难道不需要花时间去思考吗?对此,有些观点在Todd的《“品质在于构建过程”吗?》以及《Bob大叔和Jim Coplien对TDD的论战》中谈到过了。我只想想表达下面的观点:

  ● 软件的精髓在于设计,设计是一件很费大脑的事件。对于软件来说,设计没有完美的,它总是一件需要取舍需要权衡的事,比如:时间换空间,空间换时间,TCP或UDP,同步还是异步,数据冗余还不冗余等等。那怕是一个小小的observers模式是pull方式还是push方式都需要仔细讨论。这些的东西需要时间和做前期尝试。

  ● TDD、快速原型和迭代可能会对软件和团队产生负面影响。在一开始,你需要花很大的精力来让你的软件从无到有(做过软件的人都知道,从零开始写代码是很痛苦的事),但是因为你没有想好,先做再说,所以,后期你会面临更多的质量问题而让你需要花更多的时间精力。当然,那些咨询师会让你用持续集成和持续部署这样的方法。但我想告诉你,这并不解决你软件设计的缺陷。举个例子——TDD、迭代、原型只关注功能性需求,其不会关注非功能性需求,比如性能问题,高可用性问题,系统维护问题(模块的耦合问题),等等。而这些问题往往都可以让你的软件设计重新来过。

  ● 重构是恶梦,重构应该越少越好。当你维护一个复杂的系统时你会知道重构是一件多么恐怖的事情(参看《重构代码的7个阶段》)。如果一开始没有想好,你要面临的不单单是re-design, re-architect,还要面对时间和人力成本的增加,最难的是你还要面对的是团队士气因为不断的rework而逐渐低落并产生厌倦和懈怠情绪。

  所以,如果你能有多一些时间去和客户讨论一下需求和未来可能的变化,去调查一下实现的技术难点和细节,去和其他有经验的人讨论并推敲一下架构和设计,去思考设计上的缺陷,那么,你的coding会变得非常地直,直到你一眼就看到尽头,你的测试案例也会写得非常地好,你会几乎不需要重构,于是,你会在未来少写很多代码,从而你的软件开发会越来越轻松,直到技术开始换代。

  我现在在做的项目,花了几乎4个月的时间来做设计,在这个过程中,我们反复思考、讨论和权衡若干种实现方法,并尽可能地穷举所有的场景和细节以及未来可能的变化(那怕是那些简单的模块),有个模块被重写了至少三次,每次都是写到一半就被推翻重写,我们整个团队不断地在和其它团队讨论,并在对系统不断地认识中对系统进行简化和优化,并力求达到完美。现在看来,没有贸然使用Scrum是明智的。

  这就好像我们修路造桥一样,我们需要花大量的时间勘测地形地质,分析数据,思考可能出现的各种问题(各种自然灾害),评估不同的设计方案,而不是先尽快建好再说。

  所以,多一些时间,不是让你多做几次迭代,多完成几个模块,而是可以让你少写一些代码,更快的交付一个更好的产品。

  我相信你会有很多疑问,下面是我觉得你可能会有下面的一些观点,让我一条一条来回复:

  ● 首当其冲的一定会是项目的deadline,或是那种你没有活语权的项目。比如做那种“甲乙方合同式的项目”,我把这种项目统一认为是“外包项目”,在这种项目性质下,你很难有话语权。对此,我觉得,1)作为乙方的你还是应该和甲方在项目计划上争取一下,晓之以情,动之以理。2)如果不行,只能在时间、需求范围和质量上做一个权衡。另外,在这种情况下你要找一个方法,把你的压力和痛苦分担给用户和领导。(找到这个方法的前提需要你找到用户和领导他们害怕什么,嘿嘿)

  ● 过度设计和纸上谈兵。有人说会不会设计太多,造成过度设计,或是在设计上花太多的时间。这有可能。我上一家公司的一个项目团队就花了1年多的时间来不停不停的开会和做设计,结果release的时候还有1000多个bug。这个问题的原因是,这个团队的设计是在纸上谈兵,开会是开神仙会,讨论的设计都是浮云。所以,设计并不是讨论和思考,还需要去尝试,我认为当你的设计完成的时候,你的骨干核心代码都基本完成了。

  ● 我的团队成员水平太差,不会思考。首先,先恭喜你找到一堆码农,当然,这不怪你,这是中国教育和大环境的问题,让人不会思考。对于这样的情况,我有两个建议,1)量力而行,使多大的碗就吃多少饭。2)鼓励思考,那怕那些想法很不靠谱,因为如果不开始,那么将永远不会思考。

  ● 必需使用快速迭代。很多公司都在强行上敏捷,他们希望产品越快release越好,而没有充分的时间思考和讨论。对于这种项目,我的建议是,1)找有丰富经验的人来做。2)迭代过程中力求架构和程序逻辑的简单,简单,再简单,力求代码间的高内聚,低耦合。不然,重构的时候你就好玩了。

  ● 创业团队必需要快。做得快就是做得好吗?很多时候,不是谁快谁就能笑到最后的。这样的例子太多了。第一个做出来的人并不一定就会占领市场,其很有可能会成为先驱。

  ● 有钱的公司才会让团队用更多的时间去思考。错了,你们没有见过有钱的公司,有钱的公司可以招一堆干不成活的人,可以把事搞乱了再新来过,甚至可以把做失败的项目换个名字再重新立项。这些真正的有钱的公司只求快,只求人多,不怕做错决定。像我们这些没钱的人,干什么事都是小心翼翼地,生怕做错决定。

posted @ 2011-11-10 10:58 顺其自然EVO 阅读(112) | 评论 (0)编辑 收藏

Java编程体验:线程的7种状态及相互转换

  先从图片开始

  小小的作下解释:

  1、线程的实现有两种方式,一是继承Thread类,二是实现Runnable接口,但不管怎样,当我们new了这个对象后,线程就进入了初始状态;

  2、当该对象调用了start()方法,就进入可运行状态;

  3、进入可运行状态后,当该对象被操作系统选中,获得CPU时间片就会进入运行状态;

  4、进入运行状态后情况就比较复杂了

  4.1 run()方法或main()方法结束后,线程就进入终止状态;

  4.2 当线程调用了自身的sleep()方法或其他线程的join()方法,就会进入阻塞状态(该状态既停止当前线程,但并不释放所占有的资源)。当sleep()结束或join()结束后,该线程进入可运行状态,继续等待OS分配时间片;

  4.3 线程调用了yield()方法,意思是放弃当前获得的CPU时间片,回到可运行状态,这时与其他进程处于同等竞争状态,OS有可能会接着又让这个进程进入运行状态;

  4.4 当线程刚进入可运行状态(注意,还没运行),发现将要调用的资源被synchroniza(同步),获取不到锁标记,将会立即进入锁池 状态,等待获取锁标记(这时的锁池里也许已经有了其他线程在等待获取锁标记,这时它们处于队列状态,既先到先得),一旦线程获得锁标记后,就转入可运行状态,等待OS分配CPU时间片;

  4.5 当线程调用wait()方法后会进入等待队列(进入这个状态会释放所占有的所有资源,与阻塞状态不同),进入这个状态后,是不能自动唤 醒的,必须依靠其他线程调用notify()或notifyAll()方法才能被唤醒(由于notify()只是唤醒一个线程,但我们由不能确定具体唤醒的是哪一个线程,也许我们需要唤醒的线程不能够被唤醒,因此在实际使用时,一般都用notifyAll()方法,唤醒有所线程),线程被唤醒后会进入锁 池,等待获取锁标记。

  总算全部回忆了一遍JDK1.5在API的使用上有了较好的改进,效率得到很大的提高,不过几个状态转换的原理还是一样。

posted @ 2011-11-10 09:44 顺其自然EVO 阅读(157) | 评论 (0)编辑 收藏

仅列出标题
共394页: First 上一页 368 369 370 371 372 373 374 375 376 下一页 Last 
<2024年11月>
272829303112
3456789
10111213141516
17181920212223
24252627282930
1234567

导航

统计

常用链接

留言簿(55)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜