好的用例是成功的一半

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

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

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

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

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

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

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

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

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

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

下午逛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

 

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

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

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

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