1.Listen to yourself.如果你听不到自己的发音问题，要纠正就很难了。试着把你讲的话录下来并和英语为母语人士将的对比一下。

2. Slow down! 很多英语学习者常说语速太快容易养成他们的坏习惯。每天操练一些基本语言。以单音节开始，然后单词，最后，把几个词连在一起。

3. Picture it...闭上你的眼睛并在说出口之前想一想如何发这个音。想象出口型和脸部动作。

4. Get physical! 发音是个形体动作。你是在教你的嘴新的发声方法和移动肌肉的方式。每天集中训练几个音。你发 ‘th’ 的音有困难吗？将你的舌头放在齿间（不要咬住）并从口中吐气。感受气流从你的舌间吹过。

5. Watch yourself. 站在镜子前查看当你发某些固定音时的嘴型，唇型和舌头的位置。和你看到的Englishtown发音录像对比！

6.　Copy the experts. 绝对没有取代从专家－英语母语人士处学习发音的方式。因此仔细听！听英语广播节目并看英语的电视节目和电影。（不要念字幕！）模仿你所听到的－就算你还不肯定他们说的话。

7. Practice alone. 发音的问题迟迟不能解决就是因为我们害怕犯错。 －第一次见面，在饭店点菜，询问方向－然后你自己表演出对话内容。别害羞！

8. Find a language buddy. 从其他人处获得反馈是非常重要的。找一个对提高英语水平同样感兴趣的朋友。试着更换录音资料这样你就可以互相听对方的发音。

9. Be poetic. 好的发音不仅是掌握单独的音节。还是对intonation （声音的升降调）和 stress （对单词中一些音节和句子中的一些单词更大声更清晰的发音）的理解。大声念一些诗歌，演讲，歌曲，集中练习单词的重音和音调。

10. Sing a song! 学习一些英语流行歌曲的歌词并跟着唱。唱歌帮助你放松并能让这些词说出来，同时帮助改进你的语音和语调。

好的用例是成功的一半

如果将整个测试流程划分为四个环节：测试的计划，测试的设计，测试的执行，测试的评估；那么需求分析应该贯彻在前两个环节，当然有时在测试的执行阶段出现一些问题，也需要去重新定位需求，但往往不会涉及后两个环节了，测试的执行阶段应当完全依赖测试设计的结果，也就是测试用例；而测试的评估当然就是依赖测试执行的结果：测试用例通过率，缺陷修复率，测试覆盖率等手段，验证产品是否可以交付。

测试的设计是整个测试流程的重中之重；而分析需求的能力，决定测试设计的好坏。

测试的设计，第一步应该对未来项目的生产环境有个认知，需求文档中的要求往往不会具体到的每个细节，有时客户潜意识中已经默认了一些期待，所以我们除了根据有型的文档，更要进行不断的沟通，同时也要考虑资源（财力/人力），来构建我们的测试环境，我认为测试环境的考虑，从功能上说实质是兼容性测试的角度，从性能来说，应当是业务要求的角度（性能方面了解有限）。

撰写测试用例可以说是衡量一个测试人能力主要的硬性指标。顺便推荐一篇文章《How to write better test case》,google一下应该可以下载的到。文章将测试用例分为三类：Step by Step, Matrix, Automated scrīpts。大多数时候，我们默认的测试用例仅仅是第一种，测试脚本是基于测试用例的升级，作者将脚本也归纳成测试用例的一种类型，也未尝不可。

测试人之间经常会讨论测试人员需不需要懂开发，如果单纯的是作为一个测试执行者来说，这方面可能要求不是很高，但作为测试设计者，也就是到了设计测试用例的层面，这问题就不需要回答了。

虽然要求测试人员站在用户的角度考虑，但不代表仅此而己就够了，你也应当理解产品的内部是如何工作的，这有助于你设计出更优秀的测试用例，也就是在测试的执行阶段可以最大化的发现缺陷；同时，自己在设计测试用例时，开发方面的知识可以帮助你去预见一些问题，将他们反馈给开发人员，也许就避免了后面一个性能的瓶颈。这里的价值，可以说弥足珍贵。

除了对于项目的代码逻辑要有清晰的思路，同时对于相应的业务领域也要有很好的理解，举个自身的小例子最说明问题：网上银行输入密码的键盘，其各个键的位置是变动的，而我一直不知道，直到开发人员把这个Bug验证为无效。

在设计测试用例时，首先脑海应该有个架构，应该清楚的知道自己的步骤，注重骨架的划分，不要急于去细化到场景。一般来说骨架是以单元功能块来划分的，当然需求人员可能已经给你划分出来，那更好不用自己操心了。采用功能业务逻辑和代码路径逻辑两种思路结合去分析，去生成多个的场景；然后对应每个场景，去制定相应的测试用例；对应每个测试用例，准备不同业务类型的数据，同时再针对每种类型的数据，灵活的采用黑盒测试方法去划分出最合理的验证组合。

好像大部分测试管理工具都很少支持Matrix这种类型的测试用例编写，不过根据功能需求不同，设计的测试用例也可以采用不同的类型，比如重逻辑轻数据的采用为Step by Step;轻逻辑重数据的可以采用Matrix。我提到的那篇文章有很好的介绍。

设计测试用例，不是追求其书面结构的好看或者理想状态下的面面俱到或者尽量来表现编者水平，它的价值是在接下来的测试执行阶段来体现。有时候应该告诫自己，测试用例到了这个粒度已经足够了。

作者: Fenng | 可以转载, 转载时务必以超链接形式标明文章原始出处和作者信息及版权声明
网址: http://www.dbanotes.net/web/web_tester.html

 

偶然间想到的一个话题，顺便说说我的一些观点。太理论的东西书店一堆堆的，测试更多的时候需要实践和常识，而不是理论，还是说点实战中的建议吧。

必须接触 Unix 环境与文化

Unix 的一个重要设计思想 "不同工具灵活协同以完成任务"，在 Windows 上捣鼓 LoadRunner 之类的玩意儿是不能成为成功的 Web 测试者的。只懂得 Windows 上的商业工具是没有出路的，而只懂得在 Windows 点击鼠标来测试更是丢人的。

学习 cURL

一个 Web 测试人员如果没听过、没用过 cURL ，是不可想像的，cURL 本身就是浏览器，学习浏览器行为，与浏览器对话，用 cURL 会让测试人员事半功倍。

如果作为测试人员又恰好懂点编程技能，那么研究一下 libcurl，这肯定不是浪费时间。至于为什么推荐 cURL 而不是其他的工具? 看一下这个比较表。

使用 YSlow

现在，Yahoo! 公司最出名的产品可能就是这个 YSlow 了 :) 是的，必须用 Firefox 才能用 YSlow，问题是，你为什么不用 Firefox 呢? 尝试一下。再说，Firefox 上诸如 Tamper Data 之类的工具也会让你方便许多。

另外推荐 YSlow 的原因是通过这工具能快速学习优秀站点的 Web 设计，你了解的越多，测试中你会主动关注的点就会更多，你找出来的问题就越多，你的技能提升的就越快。

尝试关心一下 Web 日志

在测试的时候你不用关心其他什么 Web 分析的内容，关注一下 http 404 错误(如果团队里面没人关心的话)。

重新读一遍关于 HTTP 的图书

Web 的根本，HTTP，对这个东西，永远别说自己非常懂，比如 HTTP Performance，别说太懂，另一个原因是 HTTP 还在发展中...Web 也在发展中

对 HTTP 如果要有个更深刻的印象，HTTPWatch 也不错。

--EOF--

Note：Gusing Chen 同学对文此亦有贡献。

Requirements Phase

下午逛51的时候，看到了一份小的需求，觉得挺有意思，抱着试试的态度，画了个分析图，同时有一些疑问。老实说，这只是一个雏形，有兴趣的同学可以一起来探讨，指出不足。

聊天规则：（1）A向B发出聊天邀请，B同意后，A和B进入聊天房间；（2）如果A已经在聊天房间中，则B进入A所在的聊天房间；（3）如果A不在聊天房间中，则创建一个新的聊天房间，A和B都进入这个房间；（4）一个房间最多5个人聊天；（5）房间中的每个人都随时可以退出聊天。请根据以上设计写出测试需求，需要列举出所有进入/退出聊天流程的情况。出处

Diagram:

Question Raised:

1.是否允许一个人可以同时存在不同聊天室，如果可以，最多几个；如果不可以，见Q2（默认按照后者设计）。
2.B接受A的邀请是否意味着B离开原聊天房间（假设B正在一个房间内），还是系统确认可以和A进行聊天时才离开（默认按照前者设计）。

版权声明：原创作品，允许转载，转载时请务必以超链接形式标明文章原始出处 、作者信息和本声明，否则将追究法律责任。

本文出自lghss23的51Testing软件测试博客：http://www.51testing.com/?227608

从计划开始

正如我前面所说，最早介入项目的人，应该是能力和经验并重的人；同样在测试阶段，也是如此。

大多数测试人，包括我自己，测试生涯是从手工测试开始的，完成上级分配给的测试用例基本就是自己的全部工作内容。老实说，这更应该是个智能机器人来干的活。虽然我现在已经从事需求分析的工作，但还是有些诚惶诚恐，每次一个模块完成了测试，提交给客户后，回顾前一时期的工作，发现有些问题，在需求分析阶段就应该给予定性，并进行有效沟通，从而可以避免后期测试时产生的一些冗余流程和开发人员与测试人员之间对产品标准认识的误解。

需求分析是个互动的环节。有时因客户临时的决定，需求会发生变动，让测试人员不得不调整测试策略或用例；更多时候虽然是需求一致，但因开发人员实现时采取不同的方式，也会影响到测试人员。但这并不代表测试部门会被动的接受，你可以，也应当提出你认为合理的方式。比如：开发人员实现一些表单验证，偏好.net自带的一些验证控件，但从测试人员的角度来看，一些场合下最好编写自定义控件来实现，满足易用性的要求。至于前者，大多少时候我们只能将想法告知项目经理或与客户打叫道的负责人，将测试人员的意见纳入到考虑范畴之内。

以上有些内容其实已经渗入到了生成测试用例阶段。做需求分析，往往第一步是生成一份可执行的测试计划文档。虽然网上不乏这样的模板，但这并不是机械的填充与名词替换。重要的不是结果，而是过程。无论是制定测试范畴、进度，归纳产品特性，准备资源配置，预计风险，这些东西总结出来不是摆设，而是真正能够对未来设计测试用例，功能测试，性能测试起到引领作用。

当然，计划只是计划，俗话说计划赶不上变化，很多时候，特别是周期短的项目，微调也是时而发生的，测试团队不可能脱离其他部门，所以最大限度的评估好自己的工作的同时，也要做好因其他原因而改变测试安排的准备，比如，开发团队因某个技术点实现困难，需要延期；客户突然决定产品需要支持Opera浏览器。虽然允许测试计划演变，但演变的因素里不应包含前期因自身工作的疏忽、未考虑周全而频繁变动计划。

最大化的清晰需要完成的测试工作，最小化测试工作的不安因素，我浅薄的认为是测试计划主要完成的两件事。

请给我一份火星人的需求文档

逛测试论坛时，经常会碰到问如何测试一杯水，一张纸等等的帖子，下面的回复络绎不绝，见解更是百花齐放。我很纳闷，这个有多大讨论的价值和意义吗，除了头脑风暴带给的娱乐性。

如果你应聘时被淘汰，是仅因为测试经理面试时提出类似的问题，而你回答的很糟，那么恭喜你，幸好没进入一个糊涂的测试团队，起码是个华而不实的测试经理领导的团队。

其实回答出色的同学不见得比回答很糟的同学测试水平就高，只不过你更了解决定这个物品好坏的诸多因素；如果要是问你如何测试火星人，你肯定疯了，没概念。所以在出色的回答这个问题前，你首先要清楚回答这个问题的前提——我的需求在哪？

没错，之所以你可以回答如何可以测试一杯水，是因为你潜意识里默认了关于”这个项目“的需求；你回答的出色说明你具有成为需求人员的潜力。

一个IT项目，最早介入的人员是架构师和需求人员，这应该是经验和能力最高的人来担当的，如果从测试的眼光来看，他们是避免产生bug的第一层人员。抛开架构师（这个主题太大，我扛不住），一个需求人员的所撰写的需求文档应该可以让开发人员，UI设计人员，测试人员分别生成代码，界面，测试用例，然后经过合作生成最终的产品。

但是需求人员的价值不容易评估，水平也参差不齐。当一个团队有一个很不称职的需求人员时，这就会导致后面的开发人员，UI设计人员，测试人员来扛起需求人员所应承担的责任。所以当一份需求文档发到你手里的时候，你就应该清楚这个团队的水平了。

我在上个公司和现在的公司所接触的需求文档是截然不同的两种概念，前者看其来是个脑袋就可以写，这直接导致我在写测试用例的轻松，但轻松不见得是好事，因为文档中对于项目业务应具备的拓展，对开发技术点的理解没有任何要求，所以你可以很快完成设计测试用例的任务；后者，也就是现在我测试的项目，需求文档是USE CASE,我需要向开发人员请教存储过程，和项目涉及的.NET相关技术，同时自己逼着自己去了解电子商务，考虑如何提高性能，这倒不是我好学，而是因为人家需求文档有明确规定，在生成测试用例时，我需要了解这些内容。

以上好像都是在说一些需求人员的不是，其实我想说的是一个项目对于一个测试人员的锻炼，有的项目完全是你在用积累的经验来工作，那其实是原地踏步；而有的项目是可以不断提示你的经验，从而提示你的竞争力。

而这种差别，从需求分析就开始了...

这算一篇读后感+转载吧。

昨天很偶然的看到《程序员》杂志上的一篇文章《面试经验谈-理发师》，感触很深。任何公司，招聘一个人员，无论多苛刻，归纳起来就是一个出发点——专业，经常会在欧美电影看到这样的镜头，A和B因公事喋喋不休，A很酷的说到：“I am professional.” 心想真帅呀，啥时候自己也生活秀一把。那么到底什么是专业呢，毕业前大学老师没有告诉过我，他只是经常通知我去补考；毕业后老板也没告诉我过，尽管他一直如此要求我。

作为测试人员，我相信大多数人与我一样，努力提高硬件技能：学工具，学语言，学业务；但大多忽略了软件技能：沟通能力，协作精神等，这些几乎在任何招聘启事 上都会出现的字眼。说实话，我一直以为这些东西大多决定于天生的性格，比如有的人外向，沟通能力可能就好些，从未好好想过抛出这部分因素，如何把他像学习 硬件技能似的武装自己。审视下自己的以往，大多情况像那个理发师一样，为了体现出自己的专业、正确，在与开发人员、项目经理、需求人员、测试同行等沟通交 流时，迫不及待的推荐自己的想法和见解，如今看来表现的如此的一厢情愿。

尽管我要推荐的这篇文章的出发点是针对程序员的，场合是面试，但我发现它其实一样受众于测试人员，受众于任何沟通协作的场合。

下面为原文转载：
   
    第一次走进这家理发店，是因为再过几个小时，我就要见客户了。

    我不想让自己看起来蓄着长发，一副没有精神的样子，但又不想跑得太远，所以就近找了一家理发店，整理一下自己。

    洗完头以后，我告诉服务员随便找个设计师就可以了，因为我很清楚自己想要的发型是什么。“把旁边和后面的头发剪掉，因为看起来太长了，前面别剪太短。”这一两年来我的头发都是这样，我也习惯这样，但这个设计师听完以后似乎没有什么动静。

    “先生，我可以给你一些建议吗？”

    我没有做声，看看他想干什么。

    “我觉得你的发型应该要这样设计，然后那样修剪，而且这样调整……”，这个设计师比手划脚地说着。

    我保持微笑，“下次有机会吧，这次照我说的做就好。”

    结果，这个设计师才刚刚动了两下剪刀，似乎并不死心，“不会花多少时间，我觉得这样设计的话，可以换个方式修剪，换种风格……”

    于是我又重复了一遍“照我说的做就好，我赶时间。

    当他第三次再开口的时候，我有点生气了，“你没有超过30岁吧？而且我敢打赌你当设计师不会超过一年。”

    他看起来有点惊讶，“啊？是的，我25岁，刚当上设计师不到半年……”

    我对他说：“你想知道我是怎么知道的吗？如果想知道就乖乖照我说的去做，要不然就换另外一个设计师，两条路你选一条。”这下，我的耳根终于清静了。

    “你要学习聆听客户的想法……而不是你自己想怎么做，因为花钱的是客户。我并不是否定你的专业性，但今天我们是第一次见面，你并不了解我，我的工作、我的过去甚至我的生活。”

    我继续向他解释，“你知道我今年多大了吗？我以前有两个很好的朋友都是发型设计师，一个工作十几年了，另外一个工作快二十年了，你说的我以前都尝试过，但现在，我只希望像我刚刚说的那样去做。”

    在接下来的几十分钟里，我们之间没有任何对白。很快地，我的头发剪好了，除了还有局部维持着他的坚持外，大部分都照我说的做了。当然，连他最后的坚持也都被我修改掉了。

    “你给我的感觉是你很想表现自己的想法，推荐自己的一切，但时间不正确，沟通的方式也不正确，态度更不正确。如果你想留住客户，那么先去做他的朋友，而不是统治者。”

    我不确定他能不能听懂这些话。出了这家理发店，我在拜访客户的路上想了

    很多事，有时程序员也和发型设计师一样，急着向客户推荐自己认为最好的方案，，我们怕别人不认可自己的能力，总认为自．己足以掌握一切，却没想过客户在整个推荐过程中的感受。

    什么是专业？专业不是否定一切，一然后要客户全盘接受自己的观点。专业是一种“协助”的过程，重视现在也重视将来；专业也是一种“沟通”的过程，一种比技术 更专业的专业。如果客户已经有了很明确的想法，必然是已经权衡了很多知道和不知道的一切，我们要做的只是施工，把客户的想法变成实际，而大多数时候，我们 经常是在不了解客户的实际情况下，批判客户不成熟，整个方案应该如何，而忽略了和客户沟通的机会。

    最后，我还是主动向他索要了一张名片，因为他给我上了面试很好的一课，尽管这是一个典型反面的示范。

    等下我见到客户，知道该怎么和客户讨论他们所需要的方案了。

Not all testing situations benefit from writing your own test code. In fact, there are many times when it’s not a good idea to automate testing. So how do you decide whether and when to automate or not? The decision to automate requires analysis and the definition of boundaries between the automated test plan and the manual test plan. Using a programming language like Visual Basic or C# requires additional careful planning since writing test scrīpts is essentially software development in its own right and can eat up plenty of time in a schedule.

How do you determine what to test manually and what to test using automated test scrīpts? While experience is the best judge, there are also some basic questions you can ask yourself prior to embarking on an automated test project. The following three sections will help you determine whether your project is a good candidate for automated testing.

 

Project and Personnel Issues
Too many times test managers undertake automated testing projects without fully considering the abilities and availability of their personnel. Proper staffing is critical to the success of any project. Here are some important things to consider:

What is the scope of the automated testing?
If your goal is to fully automate all tests, then your scope is unrealistic. If you are trying to incorporate automated testing into existing projects or into a new one, then it’s best to start with small, manageable goals. For example, you can ask your team to write some simple utilities to support your test project using Visual Basic or C#. This has the added advantage of checking their experience level as well. Not all testers/programmers have the same capabilities!

What is the automated testing skill level of your testing personnel?
 If automated testing is new to your personnel, then you need to allow time and budget for them to take classes and learn. You will need to add experienced automated testing personnel to your staff prior to your first project. The level of experience will determine the level of automation you will be able to undertake. One introductory course in programming will not be enough to enable your testers to undertake a large project. However, they could possibly use some of Visual Studio’s tools and wizards to support a test project, and perhaps create and use some simple test utilities.

What is the availability of your technically skilled testers?
If you do have technically skilled testers, are they actually available? Many projects start with some experienced members who get pulled off for other projects. This may seem like a no-brainer, but we have seen this situation occur too many times to think it is just an aberration.

 

Product Issues
Not all applications to be tested are created equal. In general, when you write automated test code yourself, you are working behind the GUI. That is, you are harnessing just pieces of the software. You have to spend some time to determine if this is appropriate for your product. You must do a thorough analysis. The following questions are a short list of things to consider:

Is the feature set of the application you are testing relatively stable?
 If not, the scrīpts you write need to change as often as the application changes. You may find yourself spinning your wheels if you start too soon, using up precious budget. Automated testing works best for products that are relatively stable in structure and components.

Do you plan to test the UI? Is your product GUI–based?
 Some automated testing tools are geared specifically for the GUI. If your project is to test the application’s GUI, then certain automated testing tools, commercial or open source, may be a better choice than others..NET languages can be used for GUI testing to a certain extent, but they require a significant amount of coding to do so. For this reason, in most cases, we would not choose using .NET for extensive GUI–based testing.
 Does your product have areas where tests are run repetitively, greater than ten times per test?
 Any repetitive tasks are candidates for automated testing. Computers perform repetitive tasks well. For example, writing regression tests for high-priority bugs or developing a Build Verification Test (BVT) suite for verification of product robustness after each build are good examples of tests that will be required to be run many times.

Will your product need to be compatible with multiple platforms?
 Most products need to run on the various versions of Windows: Windows XP, Windows 2K, Windows NT, Windows 95, and Windows 98. There are many other compatibility issues, of course. Automated testing scrīpts can be written to address some of these compatibility issues.

Is your project size and budget large enough to support an automated test piece?
 Last but certainly not least, you must consider the additional time and budget required for automated testing. Although automated testing adds a lot to a test project, it can, especially initially, be time-consuming and costly. On a relatively small test project, adding automated test capability may not be worth it.

 

Additional Test-Management Issues

 Here are a few more management-level questions to ask yourself and your team:

Do you have Visual Studio .NET software available to the project?
 If not, can you purchase the proper number of licenses and have them in place in time?

Can you insert automated testing without affecting existing testing?
 For example, installing Visual Studio .NET and investigating the integration of the test scrīpting with other tests, such as manual tests or commercial tools, takes time and planning. Can you do this without adversely affecting your total project time and budget?

Do you have enough time to analyze requirements as well as code, debug, and maintain test scrīpts?
 Development of automated test scrīpts is software development and requires all of the same considerations. It’s easy to use up time and budget.

Who will manage the automated testing for each project and across projects?
 An important consideration is to keep and maintain the work done on a project for future use. For example, scrīpts for logging test results (covered in Chapter 5) can be used in any project. Identify a group or an individual who will be responsible for ensuring that code that can be reused on other projects is maintained for future use.

Managing the testing process is a big topic and an important one. There are many excellent texts available so we won’t attempt to compete with them here; check Appendix C of this book for more information on this topic.

 

这两天趁着不忙，整理了一些业内比较常见的测试工具，虽然很多都没有涉及过，经过梳理后对其有了清晰的定位。方便以后去深入了解和对比使用。

在整理的过程中，还了解到了一个有趣的典故，心细的同学会发现selenium和mercury都是一种化学元素，汞是一种有剧毒的重金属，而硒是天然的解毒剂，可以解汞毒，哈，没错，也就是发明者给Selenium工具命名的初衷，很有挑衅的意味吧。

Test + Defect Management	Functional Testing	Performance Testing	Company / Organisation
QC / TD	QTP / WinRunner	LoadRunner	HP - Mercury
TestManager + ClearQuest	RFT	RPT	IBM - Rational
Silk Central Test Manger + Issue Manger	SilkTest	SilkPerformer	Compuware
QA Director	QARun	QALoad	Borland - Segue
Testlink + Bugzilla / Bugfree	WebTest / Selenium / Watir	Jmeter / OpenSTA / WebLOAD	Open source

 

Taking a big step back, a Web server serves pages for viewing in a Web browser, while an application server provides methods that client applications can call. A little more precisely, you can say that:

A Web server exclusively handles HTTP requests, whereas an application server serves business logic to application programs through any number of protocols.

Let's examine each in more detail.

The Web server

A Web server handles the HTTP protocol. When the Web server receives an HTTP request, it responds with an HTTP response, such as sending back an HTML page. To process a request, a Web server may respond with a static HTML page or image, send a redirect, or delegate the dynamic response generation to some other program such as CGI scrīpts, JSPs (JavaServer Pages), servlets, ASPs (Active Server Pages), server-side Javascrīpts, or some other server-side technology. Whatever their purpose, such server-side programs generate a response, most often in HTML, for viewing in a Web browser.

Understand that a Web server's delegation model is fairly simple. When a request comes into the Web server, the Web server simply passes the request to the program best able to handle it. The Web server doesn't provide any functionality beyond simply providing an environment in which the server-side program can execute and pass back the generated responses. The server-side program usually provides for itself such functions as transaction processing, database connectivity, and messaging.
While a Web server may not itself support transactions or database connection pooling, it may employ various strategies for fault tolerance and scalability such as load balancing, caching, and clustering—features oftentimes erroneously assigned as features reserved only for application servers.

The application server

As for the application server, according to our definition, an application server exposes business logic to client applications through various protocols, possibly including HTTP. While a Web server mainly deals with sending HTML for display in a Web browser, an application server provides access to business logic for use by client application programs. The application program can use this logic just as it would call a method on an object (or a function in the procedural world).

Such application server clients can include GUIs (graphical user interface) running on a PC, a Web server, or even other application servers. The information traveling back and forth between an application server and its client is not restricted to simple display markup. Instead, the information is program logic. Since the logic takes the form of data and method calls and not static HTML, the client can employ the exposed business logic however it wants.

In most cases, the server exposes this business logic through a component API, such as the EJB (Enterprise JavaBean) component model found on J2EE (Java 2 Platform, Enterprise Edition) application servers. Moreover, the application server manages its own resources. Such gate-keeping duties include security, transaction processing, resource pooling, and messaging. Like a Web server, an application server may also employ various scalability and fault-tolerance techniques.

An example

As an example, consider an online store that provides real-time pricing and availability information. Most likely, the site will provide a form with which you can choose a product. When you submit your query, the site performs a lookup and returns the results embedded within an HTML page. The site may implement this functionality in numerous ways. I'll show you one scenario that doesn't use an application server and another that does. Seeing how these scenarios differ will help you to see the application server's function.

 Scenario 1: Web server without an application server
In the first scenario, a Web server alone provides the online store's functionality. The Web server takes your request, then passes it to a server-side program able to handle the request. The server-side program looks up the pricing information from a database or a flat file. Once retrieved, the server-side program uses the information to formulate the HTML response, then the Web server sends it back to your Web browser.
To summarize, a Web server simply processes HTTP requests by responding with HTML pages.
Scenario 2: Web server with an application server
Scenario 2 resembles Scenario 1 in that the Web server still delegates the response generation to a scrīpt. However, you can now put the business logic for the pricing lookup onto an application server. With that change, instead of the scrīpt knowing how to look up the data and formulate a response, the scrīpt can simply call the application server's lookup service. The scrīpt can then use the service's result when the scrīpt generates its HTML response.
In this scenario, the application server serves the business logic for looking up a product's pricing information. That functionality doesn't say anything about display or how the client must use the information. Instead, the client and application server send data back and forth. When a client calls the application server's lookup service, the service simply looks up the information and returns it to the client.

 

By separating the pricing logic from the HTML response-generating code, the pricing logic becomes far more reusable between applications. A second client, such as a cash register, could also call the same service as a clerk checks out a customer. In contrast, in Scenario 1 the pricing lookup service is not reusable because the information is embedded within the HTML page. To summarize, in Scenario 2's model, the Web server handles HTTP requests by replying with an HTML page while the application server serves application logic by processing pricing and availability requests.

Caveats

Recently, XML Web services have blurred the line between application servers and Web servers. By passing an XML payload to a Web server, the Web server can now process the data and respond much as application servers have in the past.

Additionally, most application servers also contain a Web server, meaning you can consider a Web server a subset of an application server. While application servers contain Web server functionality, developers rarely deploy application servers in that capacity. Instead, when needed, they often deploy standalone Web servers in tandem with application servers. Such a separation of functionality aids performance (simple Web requests won't impact application server performance), deployment configuration (dedicated Web servers, clustering, and so on), and allows for best-of-breed product selection.

About the author

Tony Sintes is an independent consultant and founder of First Class Consulting, a consulting firm that specializes in bridging disparate enterprise systems and training. Outside of First Class Consulting, Tony is an active freelance writer, as well as author of Sams Teach Yourself Object-Oriented Programming in 21 Days (Sams, 2001; ISBN: 0672321092).

测试经理服务于两种完全不同的客户：测试工程师和高层管理者。对于测试工程师，测试经理帮助他们开发产品测试策略，积累产品测试经验并在测试组内充分共享。对于高层管理者，测试经理搜集尽可能全面的产品信息，供其就产品是否可以发布进行决策。但是有一点是相同的：无论是对于测试工程师还是高层管理者，测试经理将帮助其定义和校验产品发布标准。

产品发布标准的定义和校验：作为一个测试经理，应该找机会与市场、开发人员商讨产品发布标准，并根据客户的反馈对该标准进行修正和校验。开发部门的工作是如何达到公司对产品的期望，要用客户需求为开发人员勾画出客户眼中的产品以及产品应如何工作。一旦产品被清楚地定义，就可以通过测试去验证产品在多大程度上满足了客户需求。

对于测试工程师而言有一点非常重要：将测试任务按优先级划分，使产品发布标准得以满足。由于只有极少数的项目有充足的时间去完成所有事情，所以告诉测试工程师关于 “ 测什么和何时测 ” 测试经理的一个重要职责。

高层管理者需要充分理解产品发布标准，以决定产品是否可以按时发布。我不认为测试组有权利裁决产品是否应该被发布，该权利在组织高层管理者那里。在有了一个通过讨论、达成一致的产品发布标准后，项目组也可以更清楚地了解和认识产品质量。

我的宝贝、宝贝，给你一点甜甜，让你今夜都好眠。
我的小鬼、小鬼，逗逗你的眉眼，让你喜欢这世界。
哇啦啦啦啦啦，我的宝贝，倦的时候有个人陪，
唉呀呀呀呀呀，我的宝贝，要你知道你最美。

我的宝贝、宝贝，给你一点甜甜，让你今夜很好眠。
我的小鬼、小鬼，逗逗你的小脸，让你喜欢整个明天。
哇啦啦啦啦啦，我的宝贝，倦的时候有个人陪，
唉呀呀呀呀呀，我的宝贝，要你知道你最美。

哇啦啦啦啦啦，我的宝贝，孤单时有人把你想念，
唉呀呀呀呀呀，我的宝贝，要你知道你最美。
哇啦啦啦啦啦，我的宝贝，倦的时候有个人陪，
唉呀呀呀呀呀，我的宝贝，要你知道你最美。
 

什么样的男人才算真正健康？最近，美国十几位健康专家经过长时间的努力，公布了一张榜单。专家称，如果这11条中能达到7条，就够格称为“真正健康”的男人了。    
  
    1．他有较高水平的HDL。
    全球每年约有35.6万名男人死于心脏疾病，是癌症的两倍。“如果血液中有充足的HDL（高密度脂蛋白），就基本上不用担心了。”心血管专家埃克尔特博士指出，“HDL有清理动脉的作用，如果能达到或超过90毫克/分升，很少会发生严重的血栓。”
    以色列一项对8586名男人进行历时21年的跟踪调查证实了这个观点，HDL水平最高的男人死于中风的风险最小。要增加他体内的HDL水平，需要至少一周4次、每次20分钟的中等强度锻炼。正常人血液中的HDL是40毫克/分升左右，最好能达到该数字两倍。
  
    2.有两个亲密的哥们儿。 
    这两个哥们儿不能是他目前的同事、邻居、健身教练等，总之不能是任何固定出现在他生活中的人。心理学家谢若德博士认为，如果一个35岁以上的男人符合这一标准，表明他拥有健康的社会联系，他会比2/3的男人更长寿。这意味着他把友谊建立在共同的兴趣上，而不是地理邻近，工作利益，生活便利等等比较浮躁易变的东西上，而正是这些东西让绝大多数男人在40岁以后变得势利又世故。
  
    3.他对以下两个问题回答“是”。
    两个问题分别是：“每天早晨，你期待着去工作吗？”“每天下午，你期待着回家吗？”经过长达30年的实践研究，格雷伯恩博士发现，持肯定答案的人，死于心脏疾病的风险非常低。
   
    4.PSA值低于2.5纳克/毫升。
    PSA全称前列腺特异性抗原。前列腺癌专家海特罗那博士指出，这个指标表明他患前列腺癌的危险比较低。
  
    5.射精能力。
    在一次非常尽兴的床上运动后，他的射精量应达到5毫升。海特罗那博士认为，这是前列腺健康的最直接表现。一个简便的测量方法：量出5毫升水，倒入一个干净的避孕套内，记住水的位置，下次就能够估计出射精量了。
  
    6.能在28分钟内步行3公里。 
    能在相当长的一段时间里保持轻快、有力的步伐，是衡量身体健康的一个真正好方法。根据瑞典研究者的结论，一个健康的40岁男人，应该在28分钟之内走完3公里，相当于正常步幅每分钟走134步。
  
    7.平衡的肌肉力量。
大多数男人热衷于让肌肉做过度的外推运动，例如俯卧撑，而真正具有平衡力量的男人比较少。理想状况是，他的肱二头肌和肱三头肌的力量比率应为1∶1，也就是说，如果他能够拉开25公斤的拉力器10次，也就应该能推开25公斤的推力器10次；他的股四头肌和?绳肌的力量比率应是3:2，即，若他能够负重30 公斤抬腿10次，就可以用腿压下20公斤重物恰好10次。如果经过这次测试，发现他的肌肉力量不平衡，那么请加强锻炼力量较弱的肌肉。

    8.比例匀称的头颅。
在临床上，面部宽度是长度的60%为最佳。具有这样标准头颅的男人不但容貌俊美，而且对呼吸道、下颌及牙齿方面的疾病也有很好的免疫力。不仅如此，他的人缘也会非常好，就连小孩子也会把他当成“好叔叔”来亲近。拿上卷尺为他量一量：第一步测量下巴与颅顶间的距离（长度）；第二步测量他两耳间的距离（宽度），然后用宽度除以长度，再用100减去这个数字。举个例子，如果他的脸长23厘米，宽14厘米，那么14÷23=0.61，也就是 60%，100%-60%=40%。

    9.快速爬坡。
格雷伯恩博士说：“‘布鲁斯方案’是一种测试心脏力量的方法，最准确，同时也最无情。”做起来很简单，让他在跑步机上行走，逐步增加跑步机的倾斜度，直到再也迈不动步子。“大部分30―40岁的男人能够坚持9分钟，若能达到12分钟就很了不起了。”格雷伯恩博士总结说。而我们的标准更高：15分钟，那意味着极佳的心血管健康状况。
可以把这个试验复制到家里进行，但如果他的心脏曾经有过问题，一定要征得医生的同意，这个测试的运动强度足可引发一次心脏病发作。方法是：先走在水平的跑步机上，速度是5公里/小时；然后逐步增加倾斜度，每3分钟加高5厘米（如果你的跑步机不能调节倾斜度，也可以用每3分钟增加1.5公里/小时的速度来代替）。大多数身体很好的男人走上7分钟就开始出汗。

   10.将线穿入针孔，一次成功。
这意味着他有非常好的深度感知力和立体敏锐性。如果他穿不上针或者打球时总接不着球，应该考虑去眼科医生那里做一次Titmus测试--------―测量眼睛的三维分辨能力，可以诊断出弱视。
另外，每年的眼科检查中也需要特别做一下青光眼的检验。青光眼是一种导致眼压增高和眼球组织破坏的疾病，世界上有1亿人因为没有及时诊断青光眼而正在逐渐丧失视力，可见这个检查非常必要。

   11.左右完美对称。
拿软尺量一量他的手腕、耳朵以及鼻孔的周长。如果这些地方左右对称，或相差在1毫米内，他就是一个天生的运动健将。利物浦科学家对50名男性所做的一项研究发现，那些身体最为匀称的男人跑得最快。身体越均衡，做剧烈运动时的自我控制力也就越好

在我还没弄清楚什么是测试职业的时候，我已经被命运安排到这个行业中，就像还不知道爱情为何物，而已经谈上了恋爱。
在不到2年半的毕业时光里，自己经历了人生课堂给予的酸甜苦辣，对比毕业时的心境，现在已然有了奋斗的方向。
方向是一种希望，因为有了希望，使得自己能够从容与淡定。很多时候我会想，如果当初做了那样的决定或者没有做这样的决定，现在的我会是什么样子，更好还是更糟？这样做的结果往往是自寻烦恼。生活是履行蝴蝶效应法则的，所以尽管有时因懒惰而倦怠，因满足而停滞，但还是不断督促自己要更加努力，因为你今天的付出决定你的未来的所得。我记着在《大学生》杂志上看过苹果创始人（他叫什么来的）在斯坦福大学的演讲稿里的一句话，要始终相信时间会把生活的点滴串联起来。
我现在也不敢确定自己是否真的对测试由衷的喜欢，它只是满足了我对工作的几点要求：要有发展，要有成就感，Money。现在看来基本符合。也许随着未来自己会越发的不满足，就像当初毕业时只要找到一份糊口的工作就可以，慢慢希望找个有前\钱途的，然后又希望这份工作能够充实有成就感，人就是这样总会被欲望驱使，不满足-满足-不满足，这样循环着，下次自己会去追求什么，这只能留给以后思考。
新的工作已经近一个月的时间，我不得不承认这是份挑战与机遇并存的工作，我希望我可以做好，我也相信我可以做好。下个月就到25岁生日了，25岁对我来说是个男人分水岭，祝愿自己能够把今后的生活导演的更精彩。