我的最新日志

  • 需求分析的20条法则!

    2008-11-10

    需求分析的20条法则!
    对商业用户来说，他们后面是成百上千个供应商，前面是成千上万个消费顾客。怎样利用软件管理错综复杂的供应商和消费顾客，如何做好精细到一个小小调料包的进、销、调、存的商品流通工作，这些都是商业企业需要信息管理系统的理由。软件开发的意义也就在于此。而弄清商业用户如此复杂需求的真面目，正是软件开发成功的关键所在。


    　　经理：“我们要建立一套完整的商业管理软件系统，包括商品的进、销、调、存管理，是总部-门店的连锁经营模式。通过通信手段门店自动订货，供应商自动结算，卖场通过扫条码实现销售，管理人员能够随时查询门店商品销售和库存情况。另外，我们也得为政府部门提供关于商品营运的报告。”

    　　分析员：“我已经明白这个项目的大体结构框架，这非常重要，但在制定计划之前，我们必须收集一些需求。”

    　　经理觉得奇怪：“我不是刚告诉你我的需求了吗？”

    　　分析员：“实际上，您只说明了整个项目的概念和目标。这些高层次的业务需求不足以提供开发的内容和时间。我需要与实际将要使用系统的业务人员进行讨论，然后才能真正明白达到业务目标所需功能和用户要求，了解清楚后，才可以发现哪些是现有组件即可实现的，哪些是需要开发的，这样可节省很多时间。”

    　　经理：“业务人员都在招商。他们非常忙，没有时间与你们详细讨论各种细节。你能不能说明一下你们现有的系统？”

    　　分析员尽量解释从用户处收集需求的合理性：“如果我们只是凭空猜想用户的要求，结果不会令人满意。我们只是软件开发人员，而不是采购专家、营运专家或是财务专家，我们并不真正明白您这个企业内部运营需要做些什么。我曾经尝试过，未真正明白这些问题就开始编码，结果没有人对产品满意。”

    　　经理坚持道：“行了，行了，我们没有那么多的时间。让我来告诉您我们的需求。实际上我也很忙。请马上开始开发，并随时将你们的进展情况告诉我。”

    风险躲在需求的迷雾之后

    　　以上我们看到的是某客户项目经理与系统开发小组的分析人员讨论业务需求。在项目开发中，所有的项目风险承担者都对需求分析阶段备感兴趣。这里所指的风险承担者包括客户方面的项目负责人和用户，开发方面的需求分析人员和项目管理者。这部分工作做得到位，能开发出很优秀的软件产品，同时也会令客户满意。若处理不好，则会导致误解、挫折、障碍以及潜在的质量和业务价值上的威胁。因此可见——需求分析奠定了软件工程和项目管理的基础。

    拨开需求分析的迷雾

    　　像这样的对话经常出现在软件开发的过程中。客户项目经理的需求对分析人员来讲，像“雾里看花”般模糊并令开发者感到困惑。那么，我们就拨开雾影，分析一下需求的具体内容：

    　　·业务需求——反映了组织机构或客户对系统、产品高层次的目标要求，通常在项目定义与范围文档中予以说明。

    　　·用户需求——描述了用户使用产品必须要完成的任务，这在使用实例或方案脚本中予以说明。

    　　·功能需求——定义了开发人员必须实现的软件功能，使用户利用系统能够完成他们的任务，从而满足了业务需求。

    　　·非功能性的需求——描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约束，操作界面的具体细节和构造上的限制。

    　　·需求分析报告——报告所说明的功能需求充分描述了软件系统所应具有的外部行为。“需求分析报告”在开发、测试、质量保证、项目管理以及相关项目功能中起着重要作用。

    　　前面提到的客户项目经理通常阐明产品的高层次概念和主要业务内容，为后继工作建立了一个指导性的框架。其他任何说明都应遵循“业务需求”的规定，然而“业务需求”并不能为开发人员提供开发所需的许多细节说明。

    　　下一层次需求——用户需求，必须从使用产品的用户处收集。因此，这些用户构成了另一种软件客户，他们清楚要使用该产品完成什么任务和一些非功能性的特性需求。例如：程序的易用性、健壮性和可靠性，而这些特性将会使用户很好地接受具有该特点的软件产品。

    　　经理层有时试图代替实际用户说话，但通常他们无法准确说明“用户需求”。用户需求来自产品的真正使用者，必须让实际用户参与到收集需求的过程中。如果不这样做，产品很可能会因缺乏足够的信息而遗留不少隐患。

    　　在实际需求分析过程中，以上两种客户可能都觉得没有时间与需求分析人员讨论，有时客户还希望分析人员无须讨论和编写需求说明就能说出用户的需求。除非遇到的需求极为简单；否则不能这样做。如果您的组织希望软件成功，那么必须要花上数天时间来消除需求中模糊不清的地方和一些使开发者感到困惑的方面。

    　　优秀的软件产品建立在优秀的需求基础之上，而优秀的需求源于客户与开发人员之间有效的交流和合作。只有双方参与者都明白自己需要什么、成功的合作需要什么时，才能建立起一种良好的合作关系。

    　　由于项目的压力与日俱增，所有项目风险承担者有着一个共同目标，那就是大家都想开发出一个既能实现商业价值又能满足用户要求，还能使开发者感到满足的优秀软件产品。

    客户的需求观

    　　客户与开发人员交流需要好的方法。下面建议20条法则，客户和开发人员可以通过评审以下内容并达成共识。如果遇到分歧，将通过协商达成对各自义务的相互理解，以便减少以后的磨擦（如一方要求而另一方不愿意或不能够满足要求）。

    1、 分析人员要使用符合客户语言习惯的表达

    　　需求讨论集中于业务需求和任务，因此要使用术语。客户应将有关术语（例如：采价、印花商品等采购术语）教给分析人员，而客户不一定要懂得计算机行业的术语。

    2、分析人员要了解客户的业务及目标

    　　只有分析人员更好地了解客户的业务，才能使产品更好地满足需要。这将有助于开发人员设计出真正满足客户需要并达到期望的优秀软件。为帮助开发和分析人员，客户可以考虑邀请他们观察自己的工作流程。如果是切换新系统，那么开发和分析人员应使用一下目前的旧系统，有利于他们明白目前系统是怎样工作的，其流程情况以及可供改进之处。s

    3、 分析人员必须编写软件需求报告

    　　分析人员应将从客户那里获得的所有信息进行整理，以区分业务需求及规范、功能需求、质量目标、解决方法和其他信息。通过这些分析，客户就能得到一份“需求分析报告”，此份报告使开发人员和客户之间针对要开发的产品内容达成协议。报告应以一种客户认为易于翻阅和理解的方式组织编写。客户要评审此报告，以确保报告内容准确完整地表达其需求。一份高质量的“需求分析报告”有助于开发人员开发出真正需要的产品。

    4、 要求得到需求工作结果的解释说明

    　　分析人员可能采用了多种图表作为文字性“需求分析报告”的补充说明，因为工作图表能很清晰地描述出系统行为的某些方面，所以报告中各种图表有着极高的价值；虽然它们不太难于理解，但是客户可能对此并不熟悉，因此客户可以要求分析人员解释说明每个图表的作用、符号的意义和需求开发工作的结果，以及怎样检查图表有无错误及不一致等。

    5、 开发人员要尊重客户的意见

    　　如果用户与开发人员之间不能相互理解，那关于需求的讨论将会有障碍。共同合作能使大家“兼听则明”。参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项目成功所付出的时间，同样，客户也应对开发人员为项目成功这一共同目标所做出的努力表示尊重。

    6、 开发人员要对需求及产品实施提出建议和解决方案

    　　通常客户所说的“需求”已经是一种实际可行的实施方案，分析人员应尽力从这些解决方法中了解真正的业务需求，同时还应找出已有系统与当前业务不符之处，以确保产品不会无效或低效；在彻底弄清业务领域内的事情后，分析人员就能提出相当好的改进方法，有经验且有创造力的分析人员还能提出增加一些用户没有发现的很有价值的系统特性。

     

    7、 描述产品使用特性

    　　客户可以要求分析人员在实现功能需求的同时还注意软件的易用性，因为这些易用特性或质量属性能使客户更准确、高效地完成任务。例如：客户有时要求产品要“界面友好”或“健壮”或“高效率”，但对于开发人员来讲，太主观了并无实用价值。正确的做法是，分析人员通过询问和调查了解客户所要的“友好、健壮、高效所包含的具体特性，具体分析哪些特性对哪些特性有负面影响，在性能代价和所提出解决方案的预期利益之间做出权衡，以确保做出合理的取舍。

    8、 允许重用已有的软件组件

    　　需求通常有一定灵活性，分析人员可能发现已有的某个软件组件与客户描述的需求很相符，在这种情况下，分析人员应提供一些修改需求的选择以便开发人员能够降低新系统的开发成本和节省时间，而不必严格按原有的需求说明开发。所以说，如果想在产品中使用一些已有的商业常用组件，而它们并不完全适合您所需的特性，这时一定程度上的需求灵活性就显得极为重要了。

    9、 要求对变更的代价提供真实可靠的评估

    　　有时，人们面临更好、也更昂贵的方案时，会做出不同的选择。而这时，对需求变更的影响进行评估从而对业务决策提供帮助，是十分必要的。所以，客户有权利要求开发人员通过分析给出一个真实可信的评估，包括影响、成本和得失等。开发人员不能由于不想实施变更而随意夸大评估成本。

    10、 获得满足客户功能和质量要求的系统

    　　每个人都希望项目成功，但这不仅要求客户要清晰地告知开发人员关于系统“做什么”所需的所有信息，而且还要求开发人员能通过交流了解清楚取舍与限制，一定要明确说明您的假设和潜在的期望，否则，开发人员开发出的产品很可能无法让您满意。

    11、 给分析人员讲解您的业务

    　　分析人员要依靠客户讲解业务概念及术语，但客户不能指望分析人员会成为该领域的专家，而只能让他们明白您的问题和目标；不要期望分析人员能把握客户业务的细微潜在之处，他们可能不知道那些对于客户来说理所当然的“常识”。

    12、 抽出时间清楚地说明并完善需求

    　　客户很忙，但无论如何客户有必要抽出时间参与“头脑高峰会议”的讨论，接受采访或其他获取需求的活动。有些分析人员可能先明白了您的观点，而过后发现还需要您的讲解，这时请耐心对待一些需求和需求的精化工作过程中的反复，因为它是人们交流中很自然的现象，何况这对软件产品的成功极为重要。

    13、 准确而详细地说明需求

    　　编写一份清晰、准确的需求文档是很困难的。由于处理细节问题不但烦人而且耗时，因此很容易留下模糊不清的需求。但是在开发过程中，必须解决这种模糊性和不准确性，而客户恰恰是为解决这些问题作出决定的最佳人选，否则，就只好靠开发人员去正确猜测了。

    　　在需求分析中暂时加上“待定”标志是个方法。用该标志可指明哪些是需要进一步讨论、分析或增加信息的地方，有时也可能因为某个特殊需求难以解决或没有人愿意处理它而标注上“待定”。客户要尽量将每项需求的内容都阐述清楚，以便分析人员能准确地将它们写进“软件需求报告”中去。如果客户一时不能准确表达，通常就要求用原型技术，通过原型开发，客户可以同开发人员一起反复修改，不断完善需求定义。

    14、 及时作出决定

    　　分析人员会要求客户作出一些选择和决定，这些决定包括来自多个用户提出的处理方法或在质量特性冲突和信息准确度中选择折衷方案等。有权作出决定的客户必须积极地对待这一切，尽快做处理，做决定，因为开发人员通常只有等客户做出决定才能行动，而这种等待会延误项目的进展。

    15、 尊重开发人员的需求可行性及成本评估

    　　所有的软件功能都有其成本。客户所希望的某些产品特性可能在技术上行不通，或者实现它要付出极高的代价，而某些需求试图达到在操作环境中不可能达到的性能，或试图得到一些根本得不到的数据。开发人员会对此作出负面的评价，客户应该尊重他们的意见。

    16、 划分需求的优先级

    　　绝大多数项目没有足够的时间或资源实现功能性的每个细节。决定哪些特性是必要的，哪些是重要的，是需求开发的主要部分，这只能由客户负责设定需求优先级，因为开发者不可能按照客户的观点决定需求优先级；开发人员将为您确定优先级提供有关每个需求的花费和风险的信息。

    　　在时间和资源限制下，关于所需特性能否完成或完成多少应尊重开发人员的意见。尽管没有人愿意看到自己所希望的需求在项目中未被实现，但毕竟是要面对现实，业务决策有时不得不依据优先级来缩小项目范围或延长工期，或增加资源，或在质量上寻找折衷。

    17、 评审需求文档和原型

    　　客户评审需求文档，是给分析人员带来反馈信息的一个机会。如果客户认为编写的“需求分析报告”不够准确，就有必要尽早告知分析人员并为改进提供建议。

    　　更好的办法是先为产品开发一个原型。这样客户就能提供更有价值的反馈信息给开发人员，使他们更好地理解您的需求；原型并非是一个实际应用产品，但开发人员能将其转化、扩充成功能齐全的系统。

    18、 需求变更要立即联系

    　　不断的需求变更，会给在预定计划内完成的质量产品带来严重的不利影响。变更是不可避免的，但在开发周期中，变更越在晚期出现，其影响越大；变更不仅会导致代价极高的返工，而且工期将被延误，特别是在大体结构已完成后又需要增加新特性时。所以，一旦客户发现需要变更需求时，请立即通知分析人员。

    19、 遵照开发小组处理需求变更的过程

    　　为将变更带来的负面影响减少到最低限度，所有参与者必须遵照项目变更控制过程。这要求不放弃所有提出的变更，对每项要求的变更进行分析、综合考虑，最后做出合适的决策，以确定应将哪些变更引入项目中。

    20、 尊重开发人员采用的需求分析过程

    　　软件开发中最具挑战性的莫过于收集需求并确定其正确性，分析人员采用的方法有其合理性。也许客户认为收集需求的过程不太划算，但请相信花在需求开发上的时间是非常有价值的；如果您理解并支持分析人员为收集、编写需求文档和确保其质量所采用的技术，那么整个过程将会更为顺利。

    “需求确认”意味着什么

    　　在“需求分析报告”上签字确认，通常被认为是客户同意需求分析的标志行为，然而实际操作中，客户往往把“签字”看作是毫无意义的事情。“他们要我在需求文档的最后一行下面签名，于是我就签了，否则这些开发人员不开始编码。”

    　　这种态度将带来麻烦，譬如客户想更改需求或对产品不满时就会说：“不错，我是在需求分析报告上签了字，但我并没有时间去读完所有的内容，我是相信你们的，是你们非让我签字的。”

    　　同样问题也会发生在仅把“签字确认”看作是完成任务的分析人员身上，一旦有需求变更出现，他便指着“需求分析报告”说：“您已经在需求上签字了，所以这些就是我们所开发的，如果您想要别的什么，您应早些告诉我们。”

    　　这两种态度都是不对的。因为不可能在项目的早期就了解所有的需求，而且毫无疑问地需求将会出现变更，在“需求分析报告”上签字确认是终止需求分析过程的正确方法，所以我们必须明白签字意味着什么。

    　　对“需求分析报告”的签名是建立在一个需求协议的基线上，因此我们对签名应该这样理解：“我同意这份需求文档表述了我们对项目软件需求的了解，进一步的变更可在此基线上通过项目定义的变更过程来进行。我知道变更可能会使我们重新协商成本、资源和项目阶段任务等事宜。”对需求分析达成一定的共识会使双方易于忍受将来的摩擦，这些摩擦来源于项目的改进和需求的误差或市场和业务的新要求等。

    　　需求确认将迷雾拨散，显现需求的真面目，给初步的需求开发工作画上了双方都明确的句号，并有助于形成一个持续良好的客户与开发人员的关系，为项目的成功奠定了坚实的基础。

    查看(38) 评论(0)

  • 编写测试用例方法心得体会---转

    2008-11-10

    摘至:♂星星々窝

    编写背景： 

    　　一直以来都不太想把技术方面的文章写出来给大家看，一个是怕写作功底不好误导哪些刚入门的测试同行，自己的表达能力有限，另一方面怕有的同行拿出去炒作，再者测试网站论坛上关于测试用例的资料已经实在是多。但是看到同行纷纷都在问我测试用例的问题，都很想知道我写测试用例的心得体会。我就抱着试试看的心态写写吧，希望测试的老前辈看见了，可以给我多提提建议。 

    　　编写测试用例方法心得体会

    　　在我的个人邮箱和MSN上，通常同行都问我类似下面这样的问题：

    　　１、一个测试用例要写到什么程度才比较好?

    　　２、刚开始做测试的时候，你是怎么学习写测试用例的？

    　　３、你对黑盒测试用例的编写的体会是什么？有什么好的版本或者标准吗？

    　　对于测试用例，而我目前正在思考的问题是：怎么写出对公司有价值的测试用例，对公司来说，怎么测试才是最有价值的测试？

    　　下面先来分析第一个问题吧：一个测试用例要写到什么程度才比较好？

    　　这个问题，没有定语，没有说是在什么样的一个情况下，因此我这里只能就我工作中碰到的情况说说了。说起来比较长阿，大家要有耐心看才行哈。^_^

    　　在我测试工作中，碰上的测试类型我自己划分成这么４种：项目的测试，产品的测试，产品个性化的测试，第三方验收测试。项目的测试指的是我所测试的软件是一个项目，是某一个具体用户使用的。产品的测试指的是我所测试的软件是一个通用产品，是供很多用户使用的。产品个性化测试指的是我所测试的软件是某一用户在使用产品时，提出了特殊的功能，针对这些新功能，对产品针对用户进行了个别修改。第三方验收测试大家都应该很熟悉了，这里就不需要做解释了。

    　　对项目、产品的测试，测试的时候通常要考虑这个项目的周期和测试资源。我所在的公司，通常项目开发时间都很短４到５个月，然而测试通常都是在开发即将结束的时候才真正介入。测试就是１个人负责。因此时间和人力资源对测试来说是完成测试工作的一个风险。为此在这种情况下，我都是先熟悉系统的业务，把握重点业务和功能后，参考需求，把测试需求、测试计划和测试大纲给制定好。由于时间关系，测试用例都是先写重点的业务，也就是集成测试的测试用例。另外测试用例是根据测试大纲来的。通常都是先挑最重要的测试项和风险大的业务功能编写测试用例。由于测试用例是本人执行，所以测试用例可以写的简单些，但是一定要开发人员能够看明白。可惜我所在的公司，都没有人来看我的测试用例。测试用例对我来说是用来提示我不要忘记了要测试哪些项。一些很有价值的ｂｕｇ通常不是在写测试用例的时候发现的，而是在测试软件的过程中，我在家睡觉前的思考和回家的路上思考出来的。这就是手动测试的魅力，有些软件的缺陷是在你使用软件的一瞬间和思考的一刹那突然发现的。所以要我回答测试用例要写到什么程度才比较好，我觉的只要你所写的测试用例在你的公司能够顺利的执行，不影响你的测试执行工作就可以了。因为测试用例写的太详细，你要花费时间和人力成本，这样出来的测试用例是最好的也是最贵的，一旦需求变更，也需要修改，这时你会发现这种详细的测试用例是最不挣钱的。测试用例写的太粗，别人看不懂，不能执行，那你要花费你的时间去解释，这就加大了测试的工作量。这也不是好的方法。

    　　第二个问题，刚开始做测试的时候，你是怎么学习写测试用例的？

    　　我之所以选择测试这个工作是因为：我毕业后，在第一家公司做技术支持，产品的问题很多，导致技术支持工作很辛苦、很累。为了让用户买到的产品的质量是好的，我选择了做测试，到了现在的公司。我刚做测试的时候，对测试一无所知，什么测试流程阿、文档阿都不知道，公司的测试和管理也不规范。对测试，大家都认为不就是拿个鼠标点来点去，谁都可以来做。为此，我经常上网查测试的资料，看看自己到底适合不适合做测试，测试到底是什么样的一个职业，怎么去规划自己的个人发展。其实要做好测试，真是不容易。不喜欢，真是不能做这个职业。

    　　现在想想自己刚开始写测试用例的时候，真是好笑。就像小孩子学习写字一样。先是在网上狂搜索了一把测试用例的模板，综合了几个，就形成了。我之所以不用公司原有的测试用例模板，是因为太不适用了。还好，公司没有严格要求必须要那个模板，只要适用就行。模板找好了，可是写就费劲了。对于刚做测试的新人，看似简单的一个填表工作，要写好真是不简单。一开始写的比较不自然，有些生搬硬套，而且还很慢。没有办法，那时候没有人指导我，全靠自己自学和领悟，所以那段日子很苦阿！多写几次后，就知道和领悟了，测试用例要根据测试大纲来写，测试大纲要根据测试计划来写。测试大纲更多的是把握住测试项的方向，而测试用例是指导怎么去执行测试。还好，我有编程的经验，所以对我熟悉软件帮了一个很大的忙。熟悉了软件的业务才能去写测试用例，才能更好的去测试。这也是我一点一点的领悟出来的。说了这么多，不知道这样的回答是否是回答了这个问题。

    　　最后一个问题了，我尽量少写些，文字太多了大家看的也累，我写的也累。嘿嘿。^_^

    　　你对黑盒测试用例的编写的体会是什么？有什么好的版本或者标准吗？

    　　我的体会：

    　　１、测试用例要根据测试大纲来编写

    　　２、测试用例也要分测试项进行归类，这样比较好分析和阅读。如：业务流程测试、安装测试、功能测试、用户友好性测试、兼容性测试、性能测试、安全性测试等等。

    　　３、编写测试用例要考虑各种情况，精力主要集中在软件的主要业务流程和风险高的地方。能分出测试优先级别就最好了。

    　　４、熟悉系统，对编写测试用例很有帮助。

    　　５、即使对测试很熟悉了，在时间非常紧的时候，编写测试用例还是很有必要和好处的。

    　　今天就想到那么些了，以后想到了在补充上了。我把我用的模板给你们粘贴一份上来，只能给你们做些参考，具体还是要看对你所在的公司适用不适用。测试项的归类我就不列举了，因为每个公司的都不太一样。

    查看(60) 评论(0)

  • Bugzilla安装指南（Windows）(转)

    2008-11-05

    Bugzilla安装指南（Windows）

    1．  准备
    Bugzilla在Windows下的安装颇为复杂，所以有很多人写了安装指南。但是使用安装的时候发现每个指南写的都有缺陷。这里我仅仅是把我安装的过程记录下来，给大家一个参考。同时还列出了一些我觉得有帮助的参考文章和站点。
    工欲善其事必先利其器，建议你在开始安装之前把所有需要的软件下载齐全，这样可以提高效率和成功率。Bugzilla所需的软件都是开源的，都可以从它们的官方网站上下载到（我个人不喜欢去华军软件园之类的下载网站上找，因为即不安全，找到的也不一定是最新的版本）。下面把所需东西和下载网站罗列一下：
    n         MySQL（4.1）
    http://dev.mysql.com/downloads/mysql
    n         Perl  （5.8.7.815）
    http://www.activestate.com/Products/Download/Download.plex?id=ActivePerl
    n         Perl模块
    有两个简单的途径可以获得Bugzilla所需的Perl模块。一个是Bugzilla汉化项目整理的，收集的很全而且比较新，还有一个安装批处理程序，所以推荐大家用这个；另外一个是Bugzilla的测试服务器，它也提供了完整的Perl模块集合，但是版本似乎比较老。第三条道路也是有的，但是需要自己去找然后再编译。对于像我一样不懂Perl德人来说是在复杂，因此不推荐大家这样做。
    http://sourceforge.net/project/showfiles.php?group_id=75477
    http://landfill.bugzilla.org/ppm/
    n         Bugzilla（2.20）
    http://www.bugzilla.org/download/
    n         Bugzilla汉化包（2.20）
    http://sourceforge.net/project/showfiles.php?group_id=75477

    2．  安装和配置MySQL
    安装MySQL很简单，只要按照安装程序的提示一步一步的做就可以了，如果有问题可以到MySQL官方网站（http://dev.mysql.com/doc/）上查看在线手册。
    接下来要配置MySQL。有些文章里写道需要手工修改root用户的密码，其实这一步在MySQL安装程序里就已经完成了（可能那些文档写的较早，MySQL的安装程序可能不太好用吧），因此不用再去设置。我们要新建一个Bug数据库和一个Bugzilla访问这个数据库的用户。操作如下：
    C:\mysql\bin>mysql --user=root -p mysql
    Enter password: ********
    Welcome to the MySQL monitor.  Commands end with ; or \g.
    Your MySQL connection id is 15 to server version: 4.0.20a-debug
    Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
    mysql> create database <database_name>;
    Query OK, 1 row affected (0.11 sec)
    mysql> grant all privileges on <database_name>.* to '<user_name>'@'<server_name>' identified by '<password>';
    Query OK, 0 rows affected (0.03 sec)
    mysql> flush privileges;
    Query OK, 0 rows affected (0.00 sec)
    mysql> quit
    Bye
    C:\mysql\bin>

    3．  安装Perl及其模块
    安装Perl也很容易，按照安装程序提示一步一步装就可以了。稍微复杂一点的是安装它的模块。不过有了Bugzilla汉化项目提供的批处理程序，这个步骤也非常简单了。大家只要记住一个简单的命令就可以了：
    ppn install <module_name>
    ppn uninstall <module_name>

    4．  安装Bugzilla
    把下载到压缩包解压到一个文件夹，然后运行Bugzilla的安装检查程序（CheckSetup.pl）。它会自动验证是不是安装了必须的软件。如果没有什么问题它会在Bugzilla目录里生成一个localconfig文件（没有扩展名）。
    用文本编辑器打开localconfig文件，找到下面两段文字。$db_host表示服务器名称，$db_name表示数据库名称，$db_user表示登录用户名，$db_pass表示密码。修改这几个值并保存。
    #
    # How to access the SQL database:
    #
    $db_host = 'localhost';         # where is the database?
    $db_name = 'bugs';              # name of the SQL database
    $db_user = 'bugs';    # user to attach to the SQL database
    #
    # Enter your database password here. It's normally advisable to specify
    # a password for your bugzilla database user.
    # If you use apostrophe (') or a backslash (\) in your password, you'll
    # need to escape it by preceding it with a '\' character. (\') or (\)
    # (Far simpler just not to use those characters.)
    #
    $db_pass = 'bugs@agfa';
    再次运行Bugzilla的安装检查程序（CheckSetup.pl）。这时如果正常它将初始化数据库结构和Demo数据。不过不要高兴得太早，可能会出现“Client does not support authentication protocol requested by server ……”错误信息。这个问题整整困扰了我一个上午，幸亏后来找到Byron Jones写的《Installing Bugzilla on Microsoft Windows》。产生这个错误是因为MySQL 4.1及以后的版本使用了新的密码加密算法，而使用的Perl的DBD::MySql模块不够新，不支持新的加密算法。你可以采取两种方式来解决这个问题：一是使用新的DBD::MySql模块，不过需要自己编译；另一种是在MySQL中强制使用兼容老版本的密码加密算法：
    C:\mysql\bin>mysql --user=root -p mysql
    Enter password: ********
    Welcome to the MySQL monitor.  Commands end with ; or \g.
    Your MySQL connection id is 15 to server version: 4.1.11-nt
    Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
    mysql> set password for '<user_name>'@'<server_name>' = OLD_PASSWORD ('<password>');
    Query OK, 0 rows affected (0.00 sec)
    mysql> quit
    Bye
    C:\mysql\bin>
    5．  配置IIS
    打开IIS管理界面。新建一个虚拟路径，指向Bugzilla所在文件夹。
    然后按应用程序设置按钮。增加一个映射，将.cgi文件映射到perl.exe。这里特别注意，有些文档里写成：perl.exe “%s” %s，这样不正确，在运行时出错（又花去一个小时）。正确的配置应该如下：
    <perl完整路径>\perl.exe -x<Bugzilla完整路径> -wT "%s" %s
    例如：
    c:\perl\bin\perl.exe -xc:\bugzilla -wT "%s" %s


    最后，将index.cgi加入到默认文档列表中。最好移到最前面，这样可以加快查询速度。如果不希望/不能把index.cgi加入到默认文档列表中，也可以在安装Bugzilla的时候，将localconfig文件中$index_html的值改为1。这样运行checksetup.pl时，就会生成一个index.html，自动重定向到index.cgi。
    #
    # With the introduction of a configurable index page using the
    # template toolkit, Bugzilla's main index page is now index.cgi.
    # Most web servers will allow you to use index.cgi as a directory
    # index, and many come preconfigured that way, but if yours doesn't
    # then you'll need an index.html file that provides redirection
    # to index.cgi. Setting $index_html to 1 below will allow
    # checksetup.pl to create one for you if it doesn't exist.
    # NOTE: checksetup.pl will not replace an existing file, so if you
    #       wish to have checksetup.pl create one for you, you must
    #       make sure that index.html doesn't already exist
    $index_html = 1;

    6．  配置Bugzilla
    不想多写了，在浏览器中打开http://localhost/bugzilla（根据你的具体情况而定）。如果你的Bugzilla是第一次使用，它会自动转向到Setup页面，按部就班的做就可以了。

    7．  汉化Bugzilla
    最后要做的就是汉化了，不过你不想汉化也没有问题。将汉化包解压解压到cn文件夹，将整个文件目录 cn 拷贝至 Bugzilla 的子目录 template下；然后以管理员身份登录Bugzilla，点击页脚的 Parameters（系统参数设置）链接，将 languages 一项的值改为 cn，保存，则以后见到的Bugzilla页面就是汉语页面了。如果想返回英文界面，将 cn 改回 en 即可。
    为保证向后兼容，汉化的文件全部存为 UTF-8 格式。但不管你是否汉化Bugzilla，为强迫Bugzilla采用UTF-8来处理字符串，避免Bugzilla偶然出现的乱码，强烈建议大家将文件 <Bugzilla安装目录>\Bugzilla\CGI.pm 的第55行改为 $self->charset('UTF-8')。

    8．  总结
    到这里，Bugzilla的安装就基本上搞定了。也许你已经发现了，这篇文档没有说明关于邮件的问题。这时因为我没有配置，不过按照Bugzilla文档的说明，它已经提供了内置的SMTP支持。可是它不支持需要认证的SMTP，可以使用Glob's sendmail wrapper来解决。

    9．  参考
    Bugzilla官方网站http://www.bugzilla.org
    Bugzilla汉化项目http://sourceforge.net/projects/bugzilla-cn
    http://cosoft.org.cn/projects/bugzillchinese/
    Perl官方网站http://www.perl.com
    ActivePerl官方网站http://www.activestate.com/Products/ActivePerl
    MySQL官方网站http://www.mysql.com
    Fake Sendmait for Windows   http://www.glob.com.au/sendmail/
    Installing Bugzilla on Microsoft Windows
    http://www.bugzilla.org/docs/win32install.html
    The Bugzilla Guidehttp://www.bugzilla.org/docs/2.20/html
    Bugzilla windows安装红宝书http://blog.fz0132.com/trackback.asp?tbID=654

    10． 附录
    安装配置Bugzilla的工作清单
    □下载Perl
    □  下载Perl模块
    □  下载MySQL
    □  下载Bugzilla
    □  下载Bugzilla汉化包
    □  安装MySQL
    □  生成Bug数据库
    □  生成Bugzilla数据库用户并分配权限
    □  安装Perl
    □  安装Perl模块
    □  解压Bugzilla压缩包
    □  运行CheckSetup.pl检查安装
    □  修改localconfig文件，设置数据库访问方式
    □  再次运行CheckSetup.pl完成数据库初始化
    □  修改Bugzilla数据库用户密码加密方式（视情况而定）
    □  在IIS管理器中为Bugzilla建立虚拟路径
    □  将.cgi文件映射到perl.exe
    □  将index.cgi加入到默认文档列表中（可选）
    □  配置Bugzilla
    □  汉化Bugzilla

    查看(22) 评论(0)

  • web 应用程序测试方法和测试技术详解!(转)

    2008-10-15

    1. 概述 
    随着 web 应用的增多，新的模式解决方案中以 web 为核心的应用也越来越多， 很多公司各种应用的架构都以 B/S 及 web 应用为主，但是有关 WEB 测试方面的内容并没有相应的总结，所以我在这里对 web 的测试方法和采用的测试技术进行总结，便于内部交流。
    测试方法尽量涵盖 web 程序的各个方面，测试技术方面在继承传统测试技术的技术上结合 web 应用的特点。 
    l 相关的测试和实现技术也有着很大的关系，由于本公司使用 J2EE 体系，也许例子中只有 JAVA 平台可以使用， .NET 平台测试技术暂时不涉及，如果你有请与我联系。 
    2. 测试方法 
    说明：测试方法的选择取决你的测试策略。 
    一般的 web 测试和以往的应用程序的测试的侧重点不完全相同，基本包括以下几个方面。 
    当然圆满的完成测试还要有好的团体和流程等的方方面面的支持，你同样应该对这些方面进行注意。 
    有些测试方法设计到了流程，哪些应该在你的测试团队建设中建立。 
    2.1 界面测试 
    现在一般人都有使用浏览器浏览网页的经历，用户虽然不是专业人员但是对界面效果的印象是很重要的。如果你注重这方面的测试，那么验证应用程序是否易于使用就非常重要了。很多人认为这是测试中最不重要的部分，但是恰恰相反界面对不懂技术的客户来说那相当关键，慢慢体会你会明白的。 
    方法上可以根据设计文档，如果够专业的话可以专业美工人员，来确定整体风格页面风格，然后根据这个可以页面人员可以生成静态的 HTML ， CSS 等甚至生成几套不用的方案来讨论，或者交给客户评审，最后形成统一的风格的页面 / 框架。注意不要靠程序员的美术素养形成你的 web 风格，那样可能会很糟糕。 
    主要包括以下几个方面的内容： 
    1 站点地图和导航条 位置、是否合理、是否可以导航等内容布局 布局是否合理，滚动条等简介说明 说明文字是否合理，位置，是否正确； 
    2 背景 / 色调 是否正确、美观，是否符合用户需求； 
    3 页面在窗口中的显示是否正确、美观（在调整浏览器窗口大小时，屏幕刷新是否正确）表单样式 大小，格式，是否对提交数据进行验证（如果在页面部分进行验证的话）等； 
    4 连接 连接的形式，位置，是否易于理解等。 
    web 测试的主要页面元素 
    5 页面元素的容错性列表（如输入框、时间列表或日历）； 
    6 页面元素清单（为实现功能，是否将所需要的元素全部都列出来了，如按钮、单选框、复选框、列表框、超连接、输入框等等）； 
    7 页面元素的容错性是否存在； 
    8 页面元素的容错性是否正确； 
    9 页面元素基本功能是否实现（如文字特效、动画特效、按钮、超连接）； 
    10 页面元素的外形、摆放位置（如按钮、列表框、核选框、输入框、超连接等）； 
    11 页面元素是否显示正确（主要针对文字、图形、签章）； 
    12 元素是否显示（元素是否存在）； 
    13 页面元素清单（为实现功能，是否将所需要的元素全部都列出来了，如按钮、单选框、复选框、列表框、超连接、输入框等等）。 
    测试技术 
    14 通过页面走查，浏览确定使用的页面是否符合需求。可以结合兼容性测试对不用分辨率下页面显示效果，如果有影响应该交给设计人员提出解决方案； 
    15 可以结合数据定义文档查看表单项的内容，长度等信息； 
    16 对于动态生成的页面最好也能进行浏览查看。如 Servelet 部分可以结合编码规范，进行代码走查。是否支持中文，如果数据用 XML 封装要做的工作会多一点等等。 
    2.1.l 界面测试要素 : 
    符合标准和规范 , 灵活性 , 正确性 , 直观性 , 舒适性 , 实用性 , 一致性 
    2.1.l.1 直观性 : 
    a 用户界面是否洁净 , 不唐突 , 不拥挤 . 界面不应该为用户制造障碍 . 所需功能或者期待的响应应该明显 , 并在预期出现的地方； 
    b 界面组织和布局合理吗 ? 是否允许用户轻松地从一个功能转到另一个功能 ? 下一步做什么明显吗 ? 任何时刻都可以决定放弃或者退回 , 退出吗 ? 输入得到承认了吗 ? 菜单或者窗口是否深藏不露 ? 
    c 有多余功能吗 ? 软件整体抑或局部是否做得太多 ? 是否有太多特性把工作复杂化了 ? 是否感到信息太庞杂 ? 
    d 如果其他所有努力失败 , 帮助系统真能帮忙吗 ? 
    2.1.l.2 一致性 
    a 快速键和菜单选项 . 在 Windows 中按 F1 键总是得到帮助信息； 
    b 术语和命令 . 整个软件使用同样的术语吗 ? 特性命名一致吗 ? 例如 ,Find 是否一直叫 Find, 而不是有时叫 Search? 
    c 软件是否一直面向同一级别用户 ? 带有花哨用户界面的趣味贺卡程序不应该显示泄露技术机密的错误提示信息； 
    d 按钮位置和等价的按键 . 大家是否注意到对话框有 OK 按钮和 Cancle 按钮时 ,OK 按钮总是在上方或者左方 , 而 Cancle 按钮总是在下方或右方 ? 同样原因 ,Cancle 按钮的等价按键通常是 Esc, 而选中按钮的等价按钮通常是 Enter. 保持一致。 
    2.1.l.3 灵活性 
    a 状态跳转：灵活的软件实现同一任务有多种选择方式； 
    b 状态终止和跳过：具有容错处理能力； 
    c 数据输入和输出：用户希望有多种方法输入数据和查看结果 . 例如 , 在写字板插入文字可用键盘输入 , 粘贴 , 从 6 种文件格式读入 , 作为对象插入 , 或者用鼠标从其他程序拖动。 
    2.1.l.4 舒适性 
    a 恰当：软件外观和感觉应该与所做的工作和使用者相符； 
    b 错误处理：程序应该在用户执行严重错误的操作之前提出警告 , 并允许用户恢复由于错误操作导致丢失的数据，如大家认为 undo /redo 是当然的； 
    c 性能：快不见得是好事，要让用户看得清程序在做什么，它是有反应的。 
    2.2 功能测试 
    功能测试是测试中的重点，主要包括一下几个方面的内容： 
    a 连接：这个连接和界面测试中的连接不同。那里注重的是连接方式和位置，如是图像还是文字放置的位置等，还是其他的方式；这里的连接注重功能，如是否有连接，连接的是否是说明的位置等； 
    b 表单提交：应当模拟用户提交，验证是否完成功能，如注册信息，要测试这些程序，需要验证服务器能正确保存这些数据，而且后台运行的程序能正确解释和使用这些信息。还有数据正确性验证，异常处理等，最好结合易用性要求等。 B/S 结构实现的功能可能主要的就在这里，提交数据，处理数据等如果有固定的操作流程可以考虑自动化测试工具的录制功能，编写可重复使用的脚本代码，可以在测试、回归测试时运行以便减轻测试人员工作量； 
    c Cookies 验证：如果系统使用了 cookie ，测试人员需要对它们进行检测。如果在 cookies 中保存了注册信息，请确认该 cookie 能够正常工作而且已对这些信息已经加密。如果使用 cookie 来统计次数，需要验证次数累计正确。关于 cookie 的使用可以参考浏览器的帮助信息。如果使用 B/S 结构 cookies 中存放的信息更多； 
    d 功能易用性测试 完成了功能测试可以对应用性进行了解，最好听听客户的反映，在可以的情况下对程序进行改进是很有必要的，和客户保持互动对系统满意度也是很有帮助的。 
    2. 2.1 测试技术 
    功能测试的测试技术可是很多的，我们可以结合实际环境选择使用。 
    a白盒测试技术 (White Box Testing) ： 深入到代码一级的测试，使用这种技术发现问题最早，效果也是最好的。该技术主要的特征是测试对象进入了代码内部，根据开发人员对代码和对程序的熟悉程度，对有需要的部分进行在软件编码阶段，开发人员根据自己对代码的理解和接触所进行的软件测试叫做白盒测试。这一阶段测试以软件开发人员为主，在 JAVA 平台使用 Xunit 系列工具进行测试， Xunit 测试工具是类一级的测试工具对每一个类和该类的方法进行测试。 
    b黑盒测试技术（ Black Box Testing ）：黑盒测试的内容主要有以下几个方面，但是主要还是功能部分。主要是覆盖全部的功能，可以结合兼容，性能测试等方面进行，根据软件需求，设计文档，模拟客户场景随系统进行实际的测试，这种测试技术是使用最多的测试技术涵盖了测试的方方面面，可以考虑以下方面 
    c正确性 (Correctness) ：计算结果，命名等方面。 
    d可用性 (Usability) ：是否可以满足软件的需求说明。 
    e边界条件 (Boundary Condition) ：输入部分的边界值，就是使用一般书中说的等价类划分，试试最大最小和非法数据等等。 
    f性能 (Performance) ： 正常使用的时间内系统完成一个任务需要的时间，多人同时使用的时候响应时间在可以接受范围内。 J2EE 技术实现的系统在性能方面更是需要照顾的，一般原则是 3 秒以下接受， 3-5 秒可以接受， 5 秒以上就影响易用性了。如果在测试过程中发现性能问题，修复起来是非常艰难的，因为这常常意味着程序的算法不好，结构不好，或者设计有问题。因此在产品开发的开始阶段，就要考虑到软件的性能问题 
    g压力测试 (Stress) ： 多用户情况可以考虑使用压力测试工具，建议将压力和性能测试结合起来进行。如果有负载平衡的话还要在服务器端打开监测工具 , 查看服务器 CPU 使用率，内存占用情况，如果有必要可以模拟大量数据输入，对硬盘的影响等等信息。如果有必要的话必须进行性能优化 ( 软硬件都可以 ) 。这里的压力测试针对的是某几项功能。 
    h错误恢复 (Error Recovery) ：错误处理，页面数据验证，包括突然间断电，输入脏数据等。 
    i安全性测试 (Security) ：这个领域正在研究中，防火墙、补丁包、杀毒软件等的就不必说了，不过可以考虑。破坏性测试时任意看了一些资料后得知 , 这里面设计到的知识 \ 内容可以写本书了 , 不是一两句可以说清的，特别是一些商务网站，或者跟钱有关，或者和公司秘密有关的 web 更是需要这方面的测试，在外国有一种专门干这一行的人叫安全顾问，可以审核代码，提出安全建议，出现紧急事件时的处理办法等，在国内没有听说哪里有专门搞安全技术测试的内容。 
    j 兼容性 (Compatibility) ：不同浏览器，不同应用程序版本在实现功能时的表现不同的上网方式，如果你测试的是一个公共网站的话。 
    兼容性测试内容详述： 
    a 硬件平台 
    b 浏览器软件和版本：浏览器插件，浏览器选项，视频分辨率和色深，文字大小，调制解调器速率 . 
    c 软件配置 (Configuration) ：如 IE 浏览器的不用选项 - 安全设定最高，禁用脚本程序等等，你们的程序在各种不用的设置下表现如何。 
    2. 2.2 单元测试技术 (Unit Test): 
    2. 2.2 .1 下面是对白盒测试和单元测试的区别的论述 : 
    单元测试和白盒测试是不同的，虽然单元测试和白盒测试都是关注功能，他们都需要代码支持，但是级别不同。白盒测试关注的是类中一个方法的功能，是更小的单位，但是完成一个单元测试可能需要 N 多类，所以说作单元测试需要写驱动和稳定桩，比如查询单元是一个查询包，包括 N 多的测试类、测试数据，运行他需要提供数据的部分，输入参数和发出命令的驱动等等，是比类大的一个整体进行的。 
    另一个明显的区别是白盒测试不会关注类接口，但是单元测试主要的内容就是类接口测试。 
    不过很多时候是很少区分的，因为这两种技术实现起来有很多相互关联的部分。不过要看你对质量的关注程度来决定。 
    2. 2.2 .2 功能测试边界测试 \ 越界测试技术详述 
    a 边界条件 
    边界条件是指软件计划的操作界限所在的边缘条件，如果软件测试问题包含确定的边界，那么数据类型可能是：数值、速度、字符、地址、位置、尺寸、数量。同时，考虑这些类型的下述特征：第一个 / 最后一个、最小值 / 最大值、开始 / 完成、超过 / 在内、空 / 满、最短 / 最长、最慢 / 最快、最早 / 最迟、最大 / 最小、最高 / 最低、相邻 / 最远。 
    b 越界测试 
    通常是简单加 1 或者很小的数 ( 对于最大值 ) 和减少 1 或者很小的数 ( 对于最小值 ) ，例如：第一个减 1/ 最后一个加 1 、开始减 1/ 完成加 1 、空了再减 / 满了再加、慢上加慢 / 快上加快、最大数加 1/ 最小数减 1 、最小值减 1/ 最大值加 1 、刚好超过 / 刚好在内、短了再短 / 长了再长、早了更早 / 晚了更晚、最高加 1/ 最低减 1 。 
    另一些该注意的输入：默认，空白，空值，零值和无；非法，错误，不正确和垃圾数据。 
    2. 2.2 .3 状态测试技术 
    a 软件可能进入的每一种独立状态； 
    b从一种状态转入另一种状态所需的输入和条件； 
    c 进入或退出某种状态时的设置条件及输入结果。 
    具体测试方法可以参考如下： 
    d 每种状态至少访问一次； 
    e 测试看起来最常见最普遍的状态转换； 
    f 测试状态之间最不常用的分支； 
    g 测试所有错误状态及其返回值； 
    h 测试随机状态转换。 
    2. 2.2 .4 竞争条件测试技术 
    竞争条件典型情形参考如下 : 
    a 两个不同的程序同时保存或打开同一个文档； 
    b 共享同一台打印机 , 通信端口或者其他外围设备； 
    c 当软件处于读取或者修改状态时按键或者单击鼠标； 
    d 同时关闭或者启动软件的多个实例； 
    e 同时使用不同的程序访问一个共同数据库。 
    2. 2.3 负载 \ 压力测试 (StressTest) 
    在这里的负载 \ 压力和功能测试中的不同，他是系统测试的内容，是基本功能已经通过后进行的。可以在集成测试阶段，亦可以在系统测试阶段进行。 
    使用负载测试工具进行，虚拟一定数量的用户看一看系统的表现，是否满足定义中的指标。 
    负载测试一般使用工具完成， loadrunner ， webload ， was ， ewl ， e-test 等，主要的内容都是编写出测试脚本，脚本中一般包括用户常用的功能，然后运行，得出报告。所以负载测试包括的主要内容就不介绍了。 
    负载测试技术在各种极限情况下对产品进行测试 ( 如很多人同时使用该软件，或者反复运行该软件 ) ，以检查产品的长期稳定性。例如，使用压力测试工具对 web 服务器进行压力测试。本项测试可以帮助找到一些大型的问题，如死机、崩损、内存泄漏等，因为有些存在内存泄漏问题的程序，在运行一两次时可能不会出现问题，但是如果运行了成千上万次，内存泄漏得越来越多，就会导致系统崩滑。用 J2EE 实现的系统很少但是并不是没有内存问题。 
    a 无论什么工具基本的技术都是利用线程技术模仿和虚拟用户，在这里主要的难点在与测试脚本的编写，每种工具使用的脚本都不一样，但是大多数工具都提供录制功能就算是不会编码的测试人员同样可以测试。 
    b 对负载工具的延伸使用可以进行系统稳定性测试，系统极限测试，如使用 100 的 Load Size 连续使用 24 小时，微软定义的通过准则是通过 72 小时测试的程序一般不会出现稳定性的问题。 
    2. 2.4 回归测试 (Regression Test) 
    过一段时间以后，再回过头来对以前修复过的 Bug 重新进行测试，看该 Bug 是否会重新出现。 
    a 回归测试技术可以在测试的各个阶段出现，无论是单元测试还是集成测试还是系统测试。是对以前问题进行验证的过程。 
    b 回归测试的目的就是保证以前已经修复的 Bug 不会再出现。实际上，许多 Bug 都是在回归测试时发现的，在此阶段，我们首先要检查以前找到的 Bug 是否已经更正了。值得注意的是，已经更正的 Bug 也可能又回来了，有的 Bug 经过修改之后可能又产生了新的 Bug 。所以，回归测试可保证已更正的 Bug 不再重现，不产生新的 Bug 。 
    2. 2.5 A lpha 和 Beta 测试 (Alpha and Beta Test): 
    在正式发布产品之前往往要先发布一些测试版，让用户能够反馈出相关信息，或者找到存在的 Bug ，以便在正式版中得到解决。 
    特别是在有客户参加的情况下，对系统进行测试可能会出现一些我们没有考虑的情况，还可以解决一些客户实际关心的问题。 
    不同的测试技术区分 
    2.3 覆盖测试技术 
    说明 : 测试覆盖率可以看出测试的完成度，在测试分析报告中可以作为量化指标的依据，测试覆盖率越高效果越好。 
    覆盖测试可以是程序代码的执行路径覆盖，亦可以是功能实现的步骤覆盖（可以理解成流程图的路径覆盖）。 
    该技术可以用在任何测试阶段，包括单元测试、集成测试、系统测试。 
    使用该技术时可以使用以上的任何测试方法和测试技术。 
    2.4 白盒测试和黑盒测试技术 
    白盒测试技术 (White Box Testing) ：该技术主要的特征是测试对象进入了代码内部，根据开发人员对代码和对程序的熟悉程度，对有需要的部分进行测试。在软件编码阶段，开发人员根据自己对代码的理解和接触所进行的软件测试叫做白盒测试。这一阶段测试以软件开发人员为主，使用 Xunit 系列工具进行测试，可以包括很多方面如功能性能等。 
    黑盒测试 (Black Box Testing) ：测试的主体部分，黑盒测试的内容主要有以下几个方面，但是主要还是功能部分。主要是覆盖全部的功能，可以结合兼容，性能测试等方面进行，包括的不同测试类型请参考以上内容。 
    2.5 手工测试和自动化测试 
    手工测试 （ Manual Testing ）：即依靠人力来查找 Bug 。方法可以参考上边的测试，也可以根据对实现技术及经验等进行不同的测试。 
    自动测试 （ Automation Testing ）：使用有针对工具实行。可以作出自动化测试的计划，对可以进行自动化测试的部分编写或者录制相应的脚本，可以加入功能，容错，表单提交等，可以参考 MI,Rational 或者其他类测试工具说明。 
    根据权威的软件测试经验，手工测试还是主要的测试方法，自动测试不够灵活，在这里不再详述。微软的测试过程 80 ％还是手工完成。 
    自动测试永远也代替不了手工测试，但是手工测试的工作量很大是不争的事实。 
    2.6 根据 RUP 标准按阶段区分测试 
    单元测试：在上边有详细的叙述，还有针对单元测试和集成测试的论述，请参考。 
    集成测试：分为功能集成测试和系统集成测试，相互有调用的功能集成，在系统环境下功能相互调用的影响等，使用方法可以任意选用上面的内容。注重功能方面。 
    系统测试：在功能实现的基础上，可以加入兼容性，易用性，性能等等。 
    验收测试：可以包括 Alpha 和 Beta 测试，在这里就不再详述。 
    3. 存在风险及解决方法 
    说明：测试不能找出所有的问题，只是尽量在开发阶段解决大多数的问题而已。 
    测试风险如下： 
    软硬件的测试环境提供上也对测试结果有很大的影响； 
    测试团队的水平，经验，合作效果等； 
    整个开发流程对测试的重视程度，测试的进入时间等； 
    由于测试环境操作系统，网络环境，带宽等情况可能产生的测试结果可能不同这是就需要经验以及对测试环境的保护等方面下一些功夫。 
    4. 软件缺陷的原则 
    软件缺陷区别于软件 bug, 它是在测试过程中出现的对系统有影响的，但是在设计中没有的或者对修改后的 bug 测试和开发人员有不同意见等。 
    a 软件未达到产品说明书标明的功能； 
    b 软件出现了产品说明书指明不会出现的错误； 
    c 软件功能超出产品说明书指明范围； 
    d 软件未达到产品说明书虽未指出但应达到的目标； 
    e 软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。 
    5. 文档测试 
    产品说明书属性检查清单 
    a 完整：是否有遗漏和丢失？完全吗？单独使用是否包含全部内容？ 
    b 准确：既定解决方案正确吗？目标明确吗？有没有错误？ 
    c 精确：不含糊，清晰。描述是否一清二楚？还是自说自话？容易看懂和理解吗？ 
    d 一致：产品功能描述是否自相矛盾？与其他功能有没有冲突 ? 
    e 贴切：描述功能的陈述是否必要 ? 有没有多余信息 ? 功能是否满足的客户要求 ? 
    f 合理：在特定的预算和进度下，以现有人力，物力和资源能否实现 ? 
    g 代码无关：是否坚持定义产品，而不是定义其所信赖的软件设计，架构和代码 ? 
    h 可测试性：特性能否测试 ? 测试员建立验证操作的测试程序是否提供足够的信息 ? 
    产品说明书用语检查清单 
    说明：对问题的描述通常表现为粉饰没有仔细考虑的功能 ---- 可归结于前文所述的属性。从产品说明书上找出这样的用语，仔细审视它们在文中是怎样使用的。产品说明书可能会为其掩饰和开脱 , 也可能含糊其词 ---- 无论是哪一种情况都可视为软件缺陷
    i 总是，每一种，所有，没有，从不。如果看到此类绝对或肯定的，切实认定的叙述，软件测试员就可以着手设计针锋相对的案例
    j 当然，因此，明显，显然，必然。这些话意图诱使接受假定情况，不要中了圈套。 
    k 某些，有时，常常，通常，惯常，经常，大多，几乎。这些话太过模糊， " 有时 " 发生作用的功能无法测试。 
    l 等等，诸如此类，依此类推。以这样的词结束的功能清单无法测试，功能清单要绝对或者解释明确，以免让人迷惑，不知如何推论。 
    m 良好，迅速，廉价，高效，小，稳定。这些是不确定的说法，不可测试。如果在产品说明书中出现，就必须进一步指明含义。 
    n 已处理，已拒绝，已忽略，已消除。这些廉洁可能会隐藏大量需要说明的功能。 
    o 如果 ... 那么 ...( 没有否则 ) 。找出有 " 如果 ... 那么 ..." 而缺少配套的 " 否则 " 结构的陈述，想一想 " 如果 " 没有发生会怎样。 
     

    查看(28) 评论(0)

  • 测试web程序的几大要点（转）

    2008-10-15

    客户端兼容性测试 
      1、平台测试 
      市场上有很多不同的操作系统类型，最常见的有Windows、Unix、Macintosh、Linux等。Web应用系统

    的最终用户究竟使用哪一种操作系统，取决于用户系统的配置。这样，就可能会发生兼容性问题，同一

    个应用可能在某些操作系统下能正常运行，但在另外的操作系统下可能会运行失败。 
      因此，在Web系统发布之前，需要在各种操作系统下对Web系统进行兼容性测试。 
      2、浏览器测试 
      浏览器是Web客户端最核心的构件，来自不同厂商的浏览器对Java，、Javascrīpt、ActiveX、 plug

    -ins或不同的HTML规格有不同的支持。例如，ActiveX是Microsoft的产品，是为Internet Explorer而设

    计的，Javascrīpt是Netscape的产品，Java是Sun的产品等等。另外，框架和层次结构风格在不同的浏览

    器中也有不同的显示，甚至根本不显示。不同的浏览器对安全性和Java的设置也不一样。 
      测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中，测试不同厂商、不同版本的浏

    览器对某些构件和设置的适应性。 
      五、安全性测试 
      Web应用系统的安全性测试区域主要有： 
      （1）现在的Web应用系统基本采用先注册，后登陆的方式。因此，必须测试有效和无效的用户名和密

    码，要注意到是否大小写敏感，可以试多少次的限制，是否可以不登陆而直接浏览某个页面等。 
      （2）Web应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内（例如15分钟）没有点击

    任何页面，*是否需要重新登陆才能正常使

    用。 
      （3）为了保证Web应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进了日志文

    件、是否可追踪。 
      （4）当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。 
      （5）服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授

    权，就不能在服务器端放置和编辑脚本的问题。 
      六、总结 
      本文从功能、性能、可用性、客户端兼容性、安全性等方面讨论了基于Web的系统测试方法。 
      基于Web的系统测试与传统的软件测试既有相同之处，也有不同的地方，对软件测试提出了新的挑战

    。基于Web的系统测试不但需要检查和验证是否按照设计的要求运行，而且还要评价系统在不同用户的浏

    览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。

    查看(34) 评论(0)

  • 转载《从外行到专业的软件测试工程师的经历》

    2008-10-15

    其实转行并没有什么特别的，如果你想听到一些传奇经历，恐怕要让你失望了。

    　　我2001年大学毕业，大学期间对计算机有兴趣、有热情，就利用业余时间买了大学计算机专业的教材自学了一遍，毕业前考了一个计算机三级B 的证书。毕业后混进了一家软件公司做HIS系统，做了几个大项目后转到测试——当时的优势是有资深的行业背景，又有开发经验，了解系统的实现——之后就在 测试行业一直混迹到现在。

    　　几年来换过几家公司，所做的系统主要都是HIS系统，电信BOSS 系统以及其它运营商级系统。自己所从事的工作包括开发工程师，测试工程师，Team leader，在前两家公司也零零碎碎的做过一些售前和需求工作。目前又转回技术职位，在一家外企做 Senior Test Engineer，所关注的方向是软件测试过程改进，性能测试和软件测试自动化。

    　　对于转行来说，如果能够充分利用之前专业所积累下的知识和经验，将会对转行有很大的帮助。我的第一份工作并不是因为我的开发能力强，而是因为当时公司所有人对医院内部的各种业务的熟悉程度都不如我。很多软件企业都是作企业应用的，为某一个行业提供服务，那么相对来说，行业知识比计算机专业知识更重要，也更难学的精通，因为作为技术人员很难有机会沉浸到那个环境中去。

    　　对于测试工程师来说，有开发经验和没有开发经验的确是有差别。但是这并不是关键，关键在于如何认清自己的优势并加以利用，找到合适的定位而不是去和别人的长处一争高低。

    　　另外，无论做哪个行业，作什么工作，兴趣都是最重要的。有了兴趣，你就不会怕吃苦，不会怕跨行业时的阵痛，可以从不断超越自己的过程中收获很多乐趣和经验。

    　　其实你问到这个问题让我突然想起了一件事情。在之前几年的工作中，虽然我从来没有刻意要安排自己的发展之路，但是也倒是一路走的很顺利，我一直都认为是幸运女神的眷顾，不过今天想一想，其实在几年的工作生涯中有些东西是不知不觉帮助了我的发展的，这个过程中有些东西是可以总结出来作为经验的，只是一直都被我忽视了。举个例子，在跨行业和换工作是，要尽可能避免太大的变动，要保证新工作的压力不会大到超过自己所能承受的最大限度。在我自己的工作经历中：

    　　1. 第一个行业，优势是对于医院内部各部门以及跨部门业务的精通。所以别人看来头痛无比的东西对我来说轻车熟路，并且乐于同我交流，我用行业知识交换来了很多计算机知识和开发经验。另外，HIS系统其实是一个很庞大繁杂的系统，除了业务类型众多，流程复杂外，还有各种复杂的业务逻辑和算法，甚至包括了完整的财务系统和进销存系统。这使我对“大系统”有了一种宏观上的感受，也见识到了大系统的开发和部署过程中的各种问题;

    　　2.第二个行业是电信行业，优势是对软件测试技术以及开发过程、开发技术的熟悉，所以可以很快的上手本职工作，有足够多的时间学习了各种通信领域的知识，熟悉了各种电信行业的系统和业务;

    　　3. 第三个行业是IPTV和DVB行业，优势是对软件测试技术/过程以及开发过程的精通，和对电信系统行业系统和业务的熟悉——在我学习和测试IPTV以及 DVB行业系统时，可以借鉴到很多电信行业系统的经验——包括技术方面和业务方面。而新近获得提升的是外企工作经验和行业经验，以及英文水平。

    　　我的看法是现在的软件行业分工越来越细，越来越明确，但是工作领域的交叉也越来越多，例如我们公司有些开发人员对于测试的理解恐怕比很多专职测试工程师还要 深入，而在我们实际的测试工作中，也要求测试工程师在计算机网络、数据库、操作系统以及程序设计语言方面有较多的经验。一个测试工程师所要面对的就是面前全是路，自己该选哪一条的问题。不过我的感受是，并不需要刻意成为全能选手，但是要积极的对待自己手边的每一份工作，从工作本身出发，培养自己快速反应的能力和快速学习的能力，不断想着如何更好、更快的完成自己的工作，并以此为出发点去带着问题学习，多多跟同事、同行交流。这样要好过去学习一些开起来漂亮、热门，但是总是用不到的技术好的多。

    　　另外，如果你有了足够多的工作经验，就会发现每件工作都有很多种做法，自己拥有超强的技术并不是最重要的，也未必是最有效的。这也是为什么外企更加看重 soft skill 的缘故。

    查看(82) 评论(0)

  • 如何发现更深次的bug(转)

    2008-10-15


    转自http://www.51testing.com/?2730

    在我们日常的测试活动中，单纯的功能界面测试（黑盒测试）发现的缺陷质量不高，即使发现了，也很少能从根本上去定位，这样的bug提交上去，给我们的研发同事修复带来了困难，同时也不利于提高我们自身的能力。这里我介绍一下个人的经验。

    1、按照需求说明编写用例，然后严格执行，这个方法最常见。

    2、在发现问题后，不要立刻就想着提交bug，应该做下记录，然后自己尝试着去分析这个问题产生的原因，比如看一下源代码，有些问题测试人员是可以自己定位的，只要自己确认了，提交上去的bug质量会更高。比如，执行搜索的时候，输入某个字段值，没有搜出来，查看代码后，发现sql语句并未执行，这时，我们再提交bug，描述里可以具体到那个页面文件，那个源代码，研发同事定位也方便，同事也对我们的技术能力认识上有改变。

    3、如果测试环境带有控制平台，比如tomcat，jboss，weblogic等等，都有控制平台，那么我们测试的时候，不仅仅需要关注前台的页面表现，还要看监控平台上的信息日志。有些系统对错误页面做了处理，我们在发现这类问题的时候，顶多将处理过的错误页面写到bug中，根本的原因可能无法得知，其实我们可以利用控制平台获取真正的错误原因，写到bug中。

    4、结合数据库进行测试，一般流程性的测试，最重要的就是数据在数据库中的状态变化。比如移动的项目，很多是异步的，光从页面是看不到效果的，所以我们可以结合数据库进行测试，弄清楚数据在数据库中的流转流程，这样才能发现更深层的bug，当然需要我们掌握数据库的使用，尤为重要要的是sql语句。举个例子，进行添加操作的时候，添加完成后没有反应，可能有两种情况，第一，添加根本未成功，第二，添加成功了，没回显出来，那么我们可以通过sql查一下添加的数据，如果数据库中有了，就说明回显出了问题，如果没有，就说明insert 出了问题。

    5、可以查看系统的日志检查测试过程中的问题。一切异常都需要关注

    不错，尤其是第四个总结自己以前也发现过这样的问题，只是自己却不知道总结

    查看(32) 评论(0)

  • “并发用户数”、“系统用户数”和“同时在线用户数”之间的差别!

    2008-10-06

    在实际的性能测试中，经常接触到的与并发用户数相关的概念还包括“并发用户数”、“系统用户数”和“同时在线用户数”，下面用一个实际的例子来说明它们之间的差别。

            假设有一个OA系统，该系统有2000个使用用户——这就是说，可能使用该OA系统的用户总数是2000名，这个概念就是“系统用户数”，该系统有一个“ 在线统计”功能（系统用一个全局变量记数所有已登录的用户），从在线统计功能中可以得到，最高峰时有500人在线（这个500就是一般所说的“同时在线人数”），那么，系统的并发用户数是多少呢？

            根据我们对业务并发用户数的定义，这500就是整个系统使用时最大的业务并发用户数。当然，500这个数值只是表明在最高峰时刻有500个用户登录了系统，并不表示实际服务器承受的压力。因为服务器承受的压力还与具体的用户访问模式相关。例如，在这500个“同时使用系统”的用户中，考察某一个时间点，在这个时间上，假设其中40%的用户在较有兴致地看系统公告（注意：“看”这个动作是不会对服务端产生任何负担的），20%的用户在填写复杂的表格（对用户填写的表格来说，只有在“提交”的时刻才会向服务端发送请求，填写过程是不对服务端构成压力的），20%部分用户在发呆（也就是什么也没有做），剩下的 20%用户在不停地从一个页面跳转到另一个页面——在这种场景下，可以说，只有20%的用户真正对服务器构成了压力。因此，从上面的例子中可以看出，服务器实际承受的压力不只取决于业务并发用户数，还取决于用户的业务场景。

           在实际的性能测试工作中，测试人员一般比较关心的是业务并发用户数，也就是从业务角度关注究竟应该设置多少个并发数比较合理，因此，在后面的讨论中，也是主要针对业务并发用户数进行讨论，而且，为了方便，直接将业务并发用户数称为并发用户数。

            （1）  计算平均的并发用户数： C = nL/T      

            （2）  并发用户数峰值： C’ ≈ C+3根号C

             公式（1）中，C是平均的并发用户数；n是login session的数量；L是login session的平均长度；T指考察的时间段长度。

            公式（2）则给出了并发用户数峰值的计算方式中，其中，C’指并发用户数的峰值，C就是公式（1）中得到的平均的并发用户数。该公式的得出是假设用户的login session产生符合泊松分布而估算得到的。

    实例：

            假设有一个OA系统，该系统有3000个用户，平均每天大约有400个用户要访问该系统，对一个典型用户来说，一天之内用户从登录到退出该系统的平均时间为4小时，在一天的时间内，用户只在8小时内使用该系统。

    则根据公式（1）和公式（2），可以得到：

                   C = 400*4/8 = 200

                   C’≈200+3*根号200 = 242

    查看(68) 评论(0)

  • （转）Java学习从入门到精通

    2008-9-19

    Java Learning Path （一）、工具篇 
    一、     JDK (Java Development Kit) 

    JDK    是整个    Java的核心，包括了Java运行环境（Java Runtime Envirnment），一堆Java工具和Java基础的类库(rt.jar)。不论什么Java应用服务器实质都是内置了某个版本的JDK。因此掌握JDK是学好Java的第一步。最主流的JDK是Sun公司发布的JDK，除了Sun之外，还有很多公司和组织都开发了自己的JDK，例如IBM公司开发的JDK，BEA公司的Jrocket，还有GNU组织开发的 JDK等等。其中IBM的JDK包含的JVM（Java Virtual Machine）运行效率要比Sun JDK包含的JVM高出许多。而专门运行在x86平台的Jrocket在服务端运行效率也要比Sun JDK好很多。但不管怎么说，我们还是需要先把Sun JDK掌握好。 

    1    、 JDK的下载和安装     
    JDK    又叫做J2SE（Java2 SDK Standard Edition），可以从Sun的Java网站上下载到，http: //java.sun.com/j2se/downloads.html ，JDK当前最新的版本是J2SDK1.4.2，建议下载该版本的JDK，下载页面在这里：http://java.sun.com/j2se/1.4.2/download.html。     

    下载好的JDK是一个可执行安装程序，默认安装完毕后会在C:\Program Files\Java\目录下安装一套JRE（供浏览器来使用），在C:\j2sdk1.4.2下安装一套JDK（也包括一套JRE）。然后我们需要在环境变量PATH的最前面增加java的路径C:\ j2sdk1.4.2\bin。这样JDK就安装好了。     

    2    、 JDK的命令工具     
    JDK    的最重要命令行工具：     
    java    ： 启动JVM执行    class 
    javac    ： Java编译器     
    jar    ： Java打包工具     
    javadoc    ： Java文档生成器     
    这些命令行必须要非常非常熟悉，对于每个参数都要很精通才行。对于这些命令的    学习，JDK Documentation上有详细的文档。 


    二、     JDK Documentation 

    Documentation    在JDK的下载页面也有下载连接，建议同时下载Documentation。Documentation是最最重要的编程手册，涵盖了整个Java所有方面的内容的描述。可以这样说，学习Java编程，大部分时间都是花在看这个Documentation上面的。我是随身携带的，写Java代码的时候，随时查看，须臾不离手。     


    三、 应用服务器    (App Server) 

    App Server    是运行Java企业组件的平台，构成了应用软件的主要运行环境。当前主流的App Server是BEA公司的 Weblogic Server和IBM公司的Websphere以及免费的Jboss，选择其中一个进行学习就可以了，个人推荐Weblogic，因为它的体系结构更加干净，开发和部署更加方便，是Java企业软件开发人员首选的开发平台。下面简要介绍几种常用的App Server：     

    1    、     Tomcat 
    Tomcat    严格意义上并不是一个真正的App Server，它只是一个可以支持运行Serlvet/JSP的Web容器，不过Tomcat也扩展了一些App Server的功能，如JNDI，    数据库连接池，用户事务处理等等。Tomcat被非常广泛的应用在中小规模的Java Web应用中，因此本文做一点下载、安装和配置Tomcat的介绍： 

    Tomcat    是Apache组织下Jakarta项目下的一个子项目，它的主网站是：http: //jakarta.apache.org/tomcat/ ，Tomcat最新版本是Tomcat4.1.27，软件下载的连接是：http: //www.apache.org/dist/jakarta/tomcat-4/binaries/ 。     

    下载Tomcat既可以直接下载zip包，也可以下载exe安装包（个人建议zip更干净些），不管哪种情况，下载完毕安装好以后（zip直接解压缩就可以了）。需要设置两个环境变量：     

    JAVA_HOME=C:\j2sdk1.4.2 
    CATALINA_HOME=D:\tomcat4 (    你的Tomcat安装目录    ) 

    这样就安装好了，启动Tomcat运行CATALINA_HOME\bin\startup.bat，关闭Tomcat运行 shutdown.bat脚本。Tomcat启动以后，默认使用8080端口，因此可以用浏览器访问http://localhost:8080来    测试 Tomcat是否正常启动。 

    Tomcat    提供了两个Web界面的管理工具，URL分别是：     
    http://localhost:8080/admin/index.jsp 
    http://localhost:8080/manager/html 
    在启用这两个管理工具之前，先需要手工配置一下管理员用户和口令。用一个文本工具打开CATALINA_HOME\conf\tomcat-users.xml这个文件，加入如下几行：     

    <role rolename="manager"/> 
    <role rolename="admin"/> 
    <user username="robbin" password="12345678" roles="admin,manager,tomcat"/> 

    这样用户“robbin”就具备了超级管理员权限。重新启动Tomcat以后，你就可以使用该用户来登陆如上的两个管理工具，通过Web方式进行Tomcat的配置和管理了。     

    2    、     BEA Weblogic 
    Weblogic    可以到BEA的网站上免费注册之后下载到最新的Weblogic8.1企业版，License可以免费使用1年时间，其实这已经完全足够了。Weblogic的下载连接：http://commerce.bea.com/index.jsp，Weblogic的在线文档： http://edocs.bea.com/ 。     

    3    、     IBM Webshpere 
    Websphere    同样可以下载到免费的试用版本，到IBM的developerWorks网站可以看到Websphere试用产品的下载和相关的Websphere的资料，developerWorks中文网站的连接是：http://www- 900.ibm.com/developerWorks/cn/wsdd/ ，Websphere的下载连接：http: //www7b.software.ibm.com/wsdd/downloads/WASsupport.html 。     

    4    、     Jboss 
    Jboss    是免费开源的App Server，可以免费的从Jboss网站下载：http: //www.jboss.org/index.html，然而Jboss的文档是不免费，需要花钱购买，所以为我们学习Jboss设置了一定的障碍。在 Jdon上有几篇不错的Jboss配置文档，可以用来参考：    http://www.jdon.com/idea.html 


    四、 Java应用的运行环境     

    Java    的应用可以简单分为以下几个方面：     

    1    、 Java的桌面应用     
    桌面应用一般仅仅需要JRE的支持就足够了。     

    2    、 Java Web应用     
    Java    的Web应用至少需要安装JDK和一个web容器（例如Tomcat），以及一个多用户数据库，Web应用至少分为三层：     
    Browser    层：浏览器显示用户页面     
    Web    层：运行    Servlet/JSP 
    DB    层：后端数据库，向Java程序提供数据访问服务     

    3    、 Java企业级应用     
    企业级应用比较复杂，可以扩展到n层，最简单情况会分为4层：     
    Browser    层：浏览器显示用户页面     
    Client    层：Java客户端图形程序（或者嵌入式设备的程序）直接和Web层或者EJB层交互     
    Web    层：运行    Servlet/JSP 
    EJB    层：运行EJB，完成业务逻辑运算     
    DB    层：后端数据库，向Java程序提供数据访问服务     

    4    、 Java嵌入式应用     
    Java    嵌入式应用是一个方兴未艾的领域，从事嵌入式开发，需要从Sun下载J2ME开发包，J2ME包含了嵌入式设备专用虚拟机KVM，和普通的JDK中包含的JVM有所不同。另外还需要到特定的嵌入式厂商那里下载模拟器。     


    Java Learning Path    （二）、书籍篇     

    学习一门新的知识，不可能指望只看一本，或者两本书就能够完全掌握。需要有一个循序渐进的阅读过程。我推荐Oreilly出版的Java系列书籍。     

    在这里我只想补充一点看法，很多人学习Java是从《Thinking in Java》这本书入手的，但是我认为这本书是不适合初学者的。我认为正确的使用这本书的方法应该是作为辅助的读物。《Thinking in Java》并不是在完整的介绍Java的整个体系，而是一种跳跃式的写作方法，是一种类似tips的方法来对Java很多知识点进行了深入的分析和解释。     

    对于初学者来说，最好是找一本Java入门的书籍，但是比较完整的循序的介绍Java的语法，面向对象的特性，核心类库等等，在看这本书的同时，可以同步来看《Thinking in Java》，来加深对Java的理解和原理的运用，同时又可以完整的了解Java的整个体系。     

    对于Java的入门书籍，蔡学镛推荐的是Oreilly的《Exploring Java, 2nd Edition》 或者《Java in a Nutshell,2nd Edition（针对C++背景）》，我并没有看过这两本书。其实我觉得电子工业出版社的《Java 2编程详解》或者《Java 2从入门到精通》就很不错。     

    在所有的Java书籍当中，其实最最有用的，并不是O'reilly的 Java Serials，真正最最有用处是JDK的 Documentation！几乎你想获得的所有的知识在Documentation里面全部都有，其中最主要的部分当然是Java基础类库的API文档，是按照package来组织的，对于每一个class都有详细的解释，它的继承关系，是否实现了某个接口，通常用在哪些场合，还可以查到它所有的 public的属性和方法，每个属性的解释，意义，每个方法的用途，调用的参数，参数的意义，返回值的类型，以及方法可能抛出的异常等等。可以这样来说，所有关于Java编程方面的书籍其实都不过是在用比较通俗易懂的语言，和良好的组织方式来介绍Documentation里面的某个package里面包含的一些类的用法而已。所以万变不离其宗，如果你有足够的能力来直接通过Documentation来学习Java的类库，那么基本上就不需要看其他的书籍了。除此之外，Documentation也是编程必备的手册，我的桌面上有三个Documentation的快捷方式，分别是J2SDK1.4.1的 Documentation，Servlet2.3的Documentation和J2SDKEE1.3.1的Documentation。有了这个三个 Documentation，什么其他的书籍都不需要了。     

    对于Java Web 编程来说，最核心的是要熟悉和掌握HTTP协议，这个就和Java无关了，在熟悉HTTP协议之后，就需要熟悉Java的实现HTTP协议的类库，也就是Servlet API，所以最重要的东西就是Servlet API。当然对于初学者而言，直接通过 Servlet API来学习Web编程有很大的难度，我推荐O'reilly的《Java Server Pages 》这本书来学习Web 编程。     

    EJB    的书籍当中，《Enterprise JavaBeans, 2nd Edition》是一本很不错的书， EJB的学习门槛是比较高，入门很难，但是这本书完全降低了学习的难度，特别重要的一点是，EJB的学习需要结合一种App Server的具体实现，所以在学习EJB的同时，必须同步的学习某种App Server，而这本书相关的出了三本书，分别是Weblogic6.1，Websphere4.0和JBoss3.0上面部署书中例子的实做。真是既有理论，又有实践。在学习EJB的同时，可以边看边做，EJB的学习会变得很轻松。     

    但是这本书也有一个问题，就是版本比较旧，主要讲EJB1.1规范和部分EJB2.0的规范。而Ed Roman写的《Mastering EJB 2.0》这本书完全是根据EJB2.0规范写的，深入浅出，覆盖了EJB编程的各个方面，并且还有很多编程经验tips，也是学习EJB非常推荐的书籍之一。     

    如果是结合Weblogic来学习J2EE的话，《J2EE应用与BEA Weblogic Server》绝对是首选读物，虽然是讲述的 Weblogic6.0，仍然值得购买，这本书是BEA官方推荐的教材，作者也是BEA公司的工程师。现在中文版已经随处可见了。这本书结合 Weblogic介绍了J2EE各个方面的技术在Weblogic平台上的开发和部署，实践指导意义非常强。     

    在掌握了Java平台基础知识和J2EE方面的知识以后，更进一步的是学习如何运用OO的方法进行软件的设计，那么就一定要学习“设计模式”。 Sun公司出版了一本《J2EE核心模式》，是每个开发Java企业平台软件的架构师必备的书籍。这本书全面的介绍了J2EE体系架构的各种设计模式，是设计师的必读书籍。     

    Java Learning Path    （三）过程篇     

    每个人的学习方法是不同的，一个人的方法不见得适合另一个人，我只能是谈自己的学习方法。因为我学习Java是完全自学的，从来没有问过别人，所以学习的过程基本上完全是自己摸索出来的。我也不知道这种方法是否是比较好的方法，只能给大家提供一点参考了。     

         其实JDK的学习没有那么简单，关于JDK有两个问题是很容易一直困扰    J学习Java的第一步是安装好JDK，写一个Hello World， Java程序员的地方：一个是CLASSPATH的问题，其实从原理上来说，是要搞清楚JRE的ClassLoader是如何加载Class的；另一个问题是package和import问题，如何来寻找类的路径问题。把这两个问题摸索清楚了，就扫除了学习Java和使用JDK的最大障碍。推荐看一下王森的《Java深度历险》，对这两个问题进行了深入的探讨。 

    第二步是学习Java的语法。Java的语法是类C++的，基本上主流的编程语言不是类C，就是类C++的，没有什么新东西，所以语法的学习，大概就是半天的时间足够了。唯一需要注意的是有几个不容易搞清楚的关键字的用法，public，protected，private，static，什么时候用，为什么要用，怎么用，这可能需要有人来指点一下，我当初是完全自己琢磨出来的，花了很久的时间。不过后来我看到《Thinking in Java》这本书上面是讲了这些概念的。     

    第三步是学习Java的面向对象的编程语言的特性的地方。比如继承，构造器，抽象类，接口，方法的多态，重载，覆盖，Java的异常处理机制。对于一个没有面向对象语言背景的人来说，我觉得这个过程需要花很长很长时间，因为学习Java之前没有C++的经验，只有C的经验，我是大概花了一个月左右吧，才彻底把这些概念都搞清楚，把书上面的例子反复的揣摩，修改，尝试，把那几章内容反复的看过来，看过去，看了不下5遍，才彻底领悟了。不过我想如果有 C++经验的话，应该一两天时间足够了。那么在这个过程中，可以多看看《Thinking in Java》这本书，对面向对象的讲解非常透彻。可惜的是我学习的时候，并没有看到这本书，所以自己花了大量的时间，通过自己的尝试和揣摩来学会的。     

    第四步就是开始熟悉Java的类库。Java    的基础类库其实就是JDK安装目录下面jre\lib\rt.jar这个包。学习基础类库就是学习rt.jar。基础类库里面的类非常非常多。据说有3000多个，我没有统计过。但是真正对于我们来说最核心的只有4个，分别是 
    java.lang.*; 
    java.io.*; 
    java.util.*; 
    java.sql.*; 

    这四个包的学习，每个包的学习都可以写成一本厚厚的教材，而O'reilly也确实是这样做的。我觉得如果时间比较紧，是不可能通过读四本书来学习。我觉得比较好的学习方法是这样的： 
    首先要通读整个package的框架，了解整个package的class，interface，exception的构成，最好是能够找到介绍整个包框架的文章。这些专门介绍包的书籍的前几章应该就是这些总体的框架内容介绍。 

    对包整体框架的把握并不是要熟悉每个类的用法，记住它有哪些属性，方法。想记也记不住的。而是要知道包有哪些方面的类构成的，这些类的用途是什么，最核心的几个类分别是完成什么功能的。我在给人培训的时候一般是一次课讲一个包，所以不可能详细的介绍每个类的用法，但是我反复强调，我给你们讲这些包的不是要告诉你们类的方法是怎么调用的，也不要求你们记住类的方法调用，而是要你们了解，Java给我们提供了哪些类，每个类是用在什么场合，当我遇到问题的时候，我知道哪个类，或者哪几个类的组合可以解决我的问题，That'all！，当我们具体写程序的时候，只要你知道该用哪个类来完成你的    工作就足够了。编码的时候，具体的方法调用，是边写代码，边查Documentation，所有的东西都在Documentation里面，不要求你一定记住，实际你也记不住3000多个类的总共将近10万个方法调用。所以对每个包的总体框架的把握就变得极为重要。 

    第五步，通过上面的学习，如果学的比较扎实的话，就打好了Java的基础了，剩下要做的工作是扫清Documentation里面除了上面4个包之外的其他一些比较有用处的类。相信进展到这一步，Java的自学能力已经被培养出来了，可以到了直接学习Documentation的水平了。除了要做 GUI编程之外，JDK里面其他会有用处的包是这些： 
    java.text.*; 
    java.net.*; 
    javax.naming.*; 
    这些包里面真正用的比较多的类其实很少，只有几个，所以不需要花很多时间。 

    第六步，Java Web 编程 
    Web    编程的核心是HTTP协议，HTTP协议和Java无关，如果不熟悉HTTP协议的话，虽然也可以学好Servlet/JSP编程，但是达不到举一反三，一通百通的境界。所以HTTP协议的学习是必备的。如果熟悉了HTTP协议的话，又有了Java编程的良好的基础，学习 Servlet/JSP简直易如反掌，我学习Servlet/JSP就用了不到一周的时间，然后就开始用JSP来做项目了。 

    在Servlet/JSP的学习中，重头仍然是Servlet Documentation。Servlet API最常用的类很少，花比较少的时间就可以掌握了。把这些类都看一遍，多写几个例子试试。Servlet/JSP编程本质就是在反复调用这些类来通过HTTP协议在Web Server 和Brower之间交谈。另外对JSP，还需要熟悉几个常用JSP的标记，具体的写法记不住的话，临时查就是了。 

    此外    Java Web编程学习的重点要放在Web Application的设计模式上，如何进行业务逻辑的分析，并且进行合理的设计，按照 MVC设计模式的要求，运用Servlet和JSP分别完成不同的逻辑层，掌握如何在Servlet和JSP之间进行流程的控制和数据的共享，以及 Web Application应该如何配置和部署。 

    第七步，J2EE编程 
    以上的学习过程如果是比较顺利的话，进行到这一步，难度又陡然提高。因为上面的知识内容都是只涉及一个方面，而像EJB，JMS，JTA等核心的J2EE规范往往是几种Java技术的综合运用的结晶，所以掌握起来难度比较大。 

    首先一定要学习好JNDI，JNDI是App Server定位服务器资源（EJB组件，Datasouce，JMS）查找方法，如果对JNDI 不熟悉的话，EJB，JMS这些东西几乎学不下去。JNDI其实就是javax.naming.*这个包，运用起来很简单。难点在于服务器资源文件的配置。对于服务器资源文件的配置，就需要看看专门的文档规范了，比如web.xml的写法，ejb-jar.xml的写法等等。针对每种不同的 App Server，还有自己的服务资源配置文件，也是需要熟悉的。 

    然后可以学习JTA，主要是要理解JTA对于事务的控制的方法，以及该在什么场合使用JTA。这里可以简单的举个例子，我们知道一般情况可以对于一个数据库连接进行事务控制(conn.setAutoCommit(false),....,conn.commit())，做为一个原子操作，但是假设我的业务需求是要把对两个不同数据库的操作做为一个原子操作，你能做的到吗？这时候只能用JTA了。假设操作过程是先往A数据库插一条记录，然后删除B 数据库另一个记录，我们自己写代码是控制不了把整个操作做为一个原子操作的。用JTA的话，由App Server来完成控制。 

    在学习EJB之前要学习对象序列化和RMI，RMI是EJB的基础。接着学习JMS和EJB，对于EJB来说，最关键是要理解EJB是如何通过RMI来实现对远端对象的调用的，以及在什么情况下要用到EJB。 

    在学习完EJB，JMS这些东西之后，你可能会意识到要急不可待学习两个领域的知识，一个是UML，另一个是Design Pattern。 Java企业软件的设计非常重视框架(Framework)的设计，一个好的软件框架是软件开发成功的必要条件。在这个时候，应该开始把学习的重点放在设计模式和框架的学习上，通过学习和实际的编程经验来掌握EJB的设计模式和J2EE的核心模式。 

    J2EE    规范里面，除了EJB，JMS，JTA，Servlet/JSP，JDBC之外还有很多很多的企业技术，这里不一一进行介绍了。 

    另外还有一个最新领域Web Services。Web Services也完全没有任何新东西，它像是一种黏合剂，可以把不同的服务统一起来提供一个统一的调用接口，作为使用者来说，我只要获得服务提供者给我的WSDL（对服务的描述），就够了，我完全不知道服务器提供者提供的服务究竟是EJB 组件，还是.Net组件，还是什么CORBA组件，还是其他的什么实现，我也不需要知道。Web Services最伟大的地方就在于通过统一的服务提供方式和调用方式，实现了整个Internet服务的共享，是一个非常令人激动的技术领域。Web Services好像目前还没有什么很好的书籍，但是可以通过在网络上面查资料的方式来学习。 

    Java Learning Path