导语
　　Selenium也是一个用于Web应用程序测试的工具。Selenium测试直接运行在浏览器中，就像真正的用户在操作一样。支持的浏览器包括IE、Mozilla Firefox、Mozilla Suite等。这个工具的主要功能包括：测试与浏览器的兼容性——测试你的应用程序看是否能够很好得工作在不同浏览器和操作系统之上。测试系统功能——创建衰退测试检验软件功能和用户需求。支持自动录制动作和自动生成。Net、Java、Perl等不同语言的测试脚本。Selenium 是ThoughtWorks专门为Web应用程序编写的一个验收测试工具。

　　本专题共整理了三个部分：原理篇、技巧篇、实战篇，希望对准备学习Selenium测试工具的朋友有所帮助。

　　原理篇
　　Selenium快速入门
　　http://www.51testing.com/html/98/n-220298.html
　　Selenium使用介绍
　　http://www.51testing.com/html/31/n-134331.html
　　Web软件测试工具Selenium：如何选取元素
　　http://www.51testing.com/html/31/n-807731.html
　　Selenium RC在浏览器兼容性测试的用武之地
　　http://www.51testing.com/html/48/n-76148.html

专题入口：http://www.51testing.com/zhuanti/selenium.html

　　技巧篇
　　浅谈基于Selenium的Web自动化测试框架
　　http://www.51testing.com/html/19/n-235019.html
　　Selenium执行测试脚本稳定性的一些经验分享交流
　　http://www.51testing.com/html/09/n-830809.html
　　毁“三观”的Selenium自动化测试框架
　　http://www.51testing.com/html/43/n-831743.html
　　基于TestNG 与Selenium 的自动化测试设计与实施
　　http://www.51testing.com/html/89/n-818489.html

　　实战篇
　　用Selenium实现页面自动化测试
　　http://www.51testing.com/html/30/n-211830.html
　　Selenium实战：.Net下的自动化测试搭建
　　http://www.51testing.com/html/78/n-840978.html
　　使用开源工具SeleniumRC进行功能测试
　　http://www.51testing.com/html/74/n-209874.html
　　Selenium实例：AJAX自动化测试应用
　　http://www.51testing.com/html/73/n-214973.html

专题入口：http://www.51testing.com/zhuanti/selenium.html

　　让我们先由2个问题引出今天的话题，第一，为什么选择做软件测试？第二，做软件测试的发展又如何？

　　第一个问题，你为什么要选择做软件测试，我敢说十个人有九个不会说实话，什么软件测试能够让我开阔视野啦，软件测试同样也需要很好的技术啦，，，全是虚伪的借口。真正地答案只有一个，软件测试的收入高，要求低！（注意是相对你的能力比来说收入算高，因为你要是选择做开发，肯定不如现在的收入）不管你愿不愿意承认你都得承认，这是绝大部分测试入这一行的原因。

　　第一个问题的答案决定了一个事实，软件测试团队的发展永远不可能像开发团队一样，随着公司的发展而发展，为什么呢？成本！ 世界上没有傻逼的公司，你的公司之所以能够存在，是因为它善于控制成本。站在管理层来看，软件测试团队是一个“显著”消耗成本而又不“显著”创造价值的团队。

　　第二个问题，软件测试的发展如何？既然我们的收入又不低，那么干的就得比人家多，你说是不。人家一天接一个客人，咱就得接三个。作为软件测试的你，是不是有同感？

　　那么，第二个问题的答案是什么呢？答案就是这篇文章的title，软件测试团队将慢慢死去！就像《黑天鹅》的作者塔勒布所讲的，这个世界是由一系列不可能发生的事件组成的。软件测试团队死去这件事情随时可能发生，你要做的，是要提前做好准备！

　　我喜欢描述这样一个场景，一线测试工程师对着电脑在干活儿，左边的高层管理着指着他的鼻子说“别再跟我要head count，我要控制成本！”，右边的中层管理着指着他的鼻子说“去给我拓展业务，我要创造业绩！”，中间的你，那一脸苦逼的表情，还用我描述吗？

　　我认为，测试团队的发展大概要经过这样三个阶段。

　　第一阶段，公司快速扩张，不计研发成本，当然测试也不例外，每天都在非常happy的招人中。。。。

　　第二阶段，经过第一阶段的快速扩张，你的测试团队积累了大量的高级测试工程师，成本已经开始进入高层的考虑范围，技术部开始考虑适度控制成本，而此时，控制最厉害的，肯定是测试团队，当然裁员首先也会从测试团队开始。如果你幸运的没有被裁掉，不要盲目乐观，还有第三阶段。

　　第三阶段，（我认为我所在的公司正处于这个阶段）严格控制测试成本，老大们开始考虑将测试工作向上游转移。此时大量的词汇开始进入我们的KPI，什么推动单元测试，推动开发自测，控制提交测试质量，等等，等等。

　　讲到这里，今天的关键就出现了，如何将测试的工作向上游转移呢？答案就是第四阶段，让测试团队慢慢死去。。。。

　　节省测试成本的最好方式就是把自己干掉！没错！下面我说说方法。

　　测试团队当中，首先应该干掉的是纯手工测试工程师，因为他们的性价比是最低的（有些公司这个时候会选择测试外包）。然后，开发测试工程师当中出色的那部分，会加入开发团队当中，不出色的将被淘汰。他们有一项艰巨的任务，那就是，以开发自测为基础，为开发团队建立起一套完整的基于风险的质量控制体系。开发做测试不是能力问题，而是思想，思想却是最难以改变的。这也是好多人天天说要推动开发自测却没有进展的原因，没有认识到改变别人思想的工作有多难！我提的办法呢一石二鸟。开发测试工程师转入开发团队，既能节省测试成本，又可以帮助开发转变思想，以一带二，以一带三，逐步完成开发团队，全民皆测试的目标！

　　那么最后，测试团队中还剩什么呢？只会剩测试工具组。他们为全公司提供测试工具，平台和流程方面的支持。极少量的团队会保留纯手工测试工程师。但是，你绝对不应该看到“开发测试工程师”这个title，因为他们已经成为了开发团队中的一员，一起开发，一起测试。。。

　　插一段说明，我觉得不必说，但有些人会这么想的。有人会说测试团队应该保留一些测试职位，负责集成测试，系统测试和性能测试。这样说的人很多，但绝对没有过实践经验。为什么呢？ 没有与开发天天在一起讨论问题，功能测试这个阶段，怎么能做好集成，系统测试呢？ 不要妄想了，这些工作也会由开发团队完成。你可能会觉得开发工程师怎么会做呢？ 他们为什么不会做呢？别忘了那些转入开发团队的开发测试工程师有一项艰巨的任务，“以开发自测为基础，为开发团队建立起一套完整的基于风险的质量控制体系”，其中就包括测试分工这些在测试团队习以为常的工作。我相信，开发暴发出来的测试能力是你想象不到的。

　　接下来可能要转换一下角度，站在开发角度来看，他们愿意接受这样一个变化吗？答案是不一定，但只有开发负责人愿意就没问题。我不刻意想学习google，facebook那种模式，但我想说，开发懂测试是一个必然趋势，如果你不想像测试一样被淘汰的话，还是接受吧。

　　测试是一个矛盾体，我们过去，现在，将来一直会做的事情就是让自己死掉（提升开发测试比，开发自测，等等，这些工作我们不是一直在做吗？）。

　　作为测试的你，能做什么呢？如果你不懂开发，要赶紧去学开发，学设计。如果你懂开发，那就还是要学开发，学设计，技术没有止境。有人跟我说“你过于强调技术，其实测试思想才是最重要的”，我认可这种看法，但不完全同意。因为技术能力会束缚你的测试思想，同样也会拓宽你的测试思想。试想都不懂tcp/http协议，怎么测试web server呢？

　　空谈误国，实干兴邦，牢牢把握技术才是王道！

　　上面这篇文章是前阶段淘宝前辈邓悟写的，感觉有一定道理，就拿过来跟大家分享下（已得到前辈同意）；关于测试团队的前三个阶段发展的论述比较赞同，感觉现在好多大公司的确也有这种趋势；对于第四个阶段不发表评论，感觉测试职位只是一种合理分工的产物，如果这种分工方式对于公司来说成本相对较低，公司当然会保留；对于前辈说的这种可能对于国内大多数公司感觉暂时不太可能（未来就不做猜测了），当然像淘宝这样的公司要另说；对于前辈说的“技术”，我的看法也是多多益善，但是人的精力毕竟有限，要结合实际工作做取舍。

本文转载自51Testing软件测试网，查看更多：http://www.51testing.com/html/news.html

　　软件测试，是一件非常令人沮丧的事情。为什么这么讲呢？从软件测试的工作量而言，软件测试是一件非常消耗人力和时间成本的工作；从测试人员的心理而言，重复的去做同一件看似毫无技术含量的工作，没有成就感。大型软件项目的测试尤甚。软件测试的痛苦在于，软件测试的目的在于发现软件bug，从某种角度上讲，发现的软件bug越多，证明了软件测试的有效性越强，但从另一角度而言，软件的bug越多，也就说明软件在设计和实现过程中的问题很多，该软件项目就算是比较失败的项目。有人可能会说，在软件项目中，开发人员应该是最重要的，如果没有开发人员的聪明才智，就不会有成功的软件。没错，但是测试人员的努力工作换来了高质量的软件。

　　既然测试人员工作非常辛苦，而且有了他们的工作才能保证高质量的软件。那么如何做才能够帮助他们实现华丽的转身，让测试人员有时间回家陪老婆抱孩子，而不是整天面对一堆用例，面对众多bug以及不停的回归迭代。

　　自动化测试是目前看似行之有效的方法（没有之一）。自动化测试的概念就如同它的名字一样清晰，就是通过使用自动化工具将测试人员部分的工作解放出来，使测试人员能够专注于测试设计的本身，而不去考虑测试脚本编写、测试执行等实现问题。自动化的好处当然显而易见，但是自动化的实施以及自动化实现的程度却根据不同的公司、不同的项目而异。一般说来，自动化测试对于已经运行维护的系统进行回归测试的效果较为明显，而对于新开发项目的实施成本较高且效果不够显著。这是因为对已运行的系统，其功能和特性已经较为熟悉，在迭代过程中，能够通过自动化去替代人工对原有的功能进行测试。二新开发的软件项目的功能可能并不清晰，在设计开发中的改动也比较大，如果使用自动化测试工具，需要根据被测对象的改变而不停的维护测试工具。因此代价和成本也较高。自动化测试可以从两个方面来解放测试人员的工作，提高测试效率。一方面是自动化测试管理平台的建立，另一方面是自动测试工具的建立。对于前者，可以采用开源软件testLink来实现，主要进行用例的管理维护工作。本文先对后一类型进行说明。目前自动化测试工具用的比较多的有HP公司的QTP。QTP通过录制/回放的功能，能够自动的进行测试。而且QTP不仅支持对象库，而且支持描述性编程，能够适应不停改变的项目。

　　自动化测试的开展首先必须要考虑到自动化要达成什么样的目标？要达到多高的覆盖率？是不是覆盖率越高的话自动化就越好？其实，自动化的覆盖率和自动化效率是一个抛物线的图，对某一项目而言，在自动化覆盖率达到一个阈值时效率最高，随着覆盖率的进一步加大，维护的成本就会加大，被测对象的一点改变都必须进行自动化测试工具相应的维护和改变。目前来看这个阈值只能是根据开发测试架构的测试开发人员的经验去判断。对于前台UI的自动化，有一种说法是这个目标很难实现，因为在设计中UI是最容易变更的，这样对自动化工具而言成本就非常大。一次有幸听过google中国测试部门老大的讲座，他提到没有见到一例做UI自动化成功的。看来UI自动化还是任重道远。对于后台的自动化，因为功能部分比较稳定，因此这里是实现自动化的主要方面。但是后台自动化的问题是如何与前台进行交互。有一种方法是在后台和前台之间放一层中间层，后台所有测试的数据最后都放在中间层中，而前台直接调用中间层的数据，避免了前后台直接交互，而只采用了数据交互的方式。

　　发散的说了这么多，还只是作为一个自动化测试菜鸟的一点学习总结和感悟，自动化测试的愿景是美好的，道路是曲折的。曲折的道路不仅包括技术问题，更重要的是成本的计算、开发测试等项目组人员自动化测试意识的培养、以及整体项目的推进情况决定的。总之，自动化测试就类似于共产主义，测试人员都在期待那天的来临，如果实在太遥远，那就先进行社会主义初级阶段，从可以推进的项目逐渐进行，将测试人员的部分工作逐渐自动化替代，实现测试人员华丽的转身。

本文转载自51Testing软件测试网，查看更多：http://www.51testing.com/html/news.html

　　1、软件测试及其地位

　　软件测试是软件生命周期中的一个重要阶段，是软件质量保证的关键步骤。软件测试的目的是为了检验软件系统是否满足需求。软件测试应该是“为了发现错误而执行程序的过程”。或者说，软件测试应该根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例（即输入数据及其预期的输出结果），并利用这些测试用例去运行程序，以发现程序错误或缺陷。

　　随着软件危机的频繁出现，以及人们对软件本质的进一步认识，软件测试的地位得到了前所未有的提高。软件测试已经不仅仅局限于软件开发中的一个阶段，它已经开始贯穿于整个软件开发过程，人们已经开始认识到：测试开始的时间越早，测试执行的越频繁，所带来的整个软件开发成本的下降就会越多。

　　美国质量保证研究所对软件测试的研究结果表明：越早发现软件中存在的问题，开发费用就越低；在编码后修改软件缺陷的成本是编码前的10倍，在产品交付后修改软件缺陷的成本是交付前的10倍。另外，根据对国际著名IT企业的统计，它们的软件测试费用占整个软件工程所有研发费用的50%以上，软件测试时间占整个软件工程所有研发时间的40%至50%。

　　2、软件测试中的常见问题

　　软件测试虽然日益受到重视，但是，目前不少软件企业的软件开发模式仍然处在无序开发的不规范状态，与软件编程比较，软件测试的地位和作用，还没有真正受到重视，很多人还存在对软件测试的错误认识，这更影响软件测试活动的进行和真正提高软件测试质量。下面几小节将列出一些软件测试上的常见问题并进行解释。

　　2.1 软件测试仅仅是为了发现软件缺陷

　　对软件测试略有了解的人都知道，在说到软件测试时，多数人都会强调软件测试的目的是为了发现软件中的缺陷。一个好的测试用例在于能发现至今未发现的缺陷。也就是人们常说的：软件测试可以说明软件存在缺陷，但不能说明软件不存在缺陷。

　　这种观点不能说是错误的，但至少是不全面的。如果从软件过程的角度来看，就可以看到一个被大多数人忽略的软件测试目的是：软件测试可以帮助发现当前开发工作所采取的软件过程的缺陷，以便进行改进。

　　具体的说，软件测试并不仅仅是为了要找到软件中的缺陷，而是分析错误产生的原因和其产生的阶段。通过分析结果，从软件过程方面去改进，从而避免今后有类似的错误出现，并能发现有关联的潜在缺陷。这样，就可以尽早的发现和修正缺陷，并可以预防某些缺陷的产生。因此，应该正确分析与利用测试的结果并有效地进行软件过程改进，从根本上提高软件质量，降低软件开发成本。

　　2.2 编码完成后再进行软件测试

　　根据软件生命周期的定义，软件项目开发过程一般要经过以下几个阶段：需求分析，概要设计，详细设计，软件编码，软件测试，软件发布。因此，许多人认为软件测试只是软件编码后的一个过程。这是不了解软件测试周期的真正含义造成的错误认识。

　　软件测试是一个系列过程活动，包括软件测试需求分析，测试计划设计，测试用例设计，执行测试。因此，软件测试贯穿于软件项目的整个开发过程。在软件项目的每一个阶段都要进行不同目的和内容的测试活动，以保证各个阶段的正确性。软件测试的对象不仅仅是软件代码，还包括软件需求文档和设计文档。软件开发与软件测试应该是交互进行的，例如，单元编码需要单元测试，模块组合阶段需要集成测试，系统集成阶段需要系统测试。如果等到软件编码结束后才进行测试，那么，测试的时间将会很短，测试的覆盖面将很不全面，测试的效果也将大打折扣。更严重的是如果此时发现了软件需求阶段或概要设计阶段的错误，要修复错误，将会耗费大量的时间和人力。

　　高效的系统测试有赖于高效的计划。测试用例像源代码一样，需要设计、评审和实施。如果不想让测试成为阻碍软件发布的关键路径，就要尽早开始测试计划。可以在了解了需求之后就开始。若采用分阶段交付使用的方法，在第一阶段中途就可获得可执行的软件，这时就可以开始系统测试。

　　......

本文转载自51Testing软件测试网，查看全文：http://www.51testing.com/html/89/n-837489.html

　　不管是软件测试设计，还是测试执行，软件工作产品都是软件测试活动的主要输入，例如：系统需求文档。因此，软件工作产品（项目文档）对于有效开展软件测试活动是至关重要的。然而，现实情况是：即使是试图充分描述软件产品的项目团队，其开发的项目文档（例如需求规格说明文档）也和想象有很大差距，例如：需求不清楚、不完善。这是一个不可对抗的事实，也是一个基本问题。

　　根据实践经验估算，在当前的软件项目中超过80%的代码用于实现错误处理，实现主要控制流的代码不足20%。但是即使是完整的规格说明也可能只会用不足20%的篇幅描述错误处理。这就意味着80%的代码是软件人员边编码边设计的。

　　由于项目文档中将主要篇幅放在了主要功能的描述上面，而对其中的错误处理等方面描述不足。因此，测试人员不能根据需求文档完备、一致或者准确的假设来设计和执行测试，即在软件测试过程中，软件测试人员仅仅考虑项目文档中提供的信息是不够的。下面罗列了一些对测试人员有用的信息源，以补充项目文档中没有提供的信息：

　　1）软件产品相关的国际标准、国家标准和行业标准；

　　2）类似项目的用户手册，或者以前版本的使用手册；

　　3）利益相关者提供的各种培训资料和变更备忘录；

　　4）已出版的图形化界面风格指南和用户界面标准，例如：微软公司出版的指南；

　　5）通过和系统人员、开发人员、客户支持人员等的沟通获取的产品信息和客户信息；

　　6）以前软件产品的缺陷列表和缺陷分类；

　　7）开展探索性测试，以获取软件产品更多的表现行为和输出；

本文转载自51Testing软件测试网，查看更多：http://www.51testing.com/html/news.html

　　在超图工作两年了，这两年来，从刚开始对软件测试认识的朦朦胧胧，现在思路也逐渐清晰了，也明确了自己的发展方向。虽然对那些软件测试理论和软件测试工具以及软件测试技术有了一些加强，但是自我感觉还是不够深入。

　　我一直希望能真正融入到测试的队列中去，让自己每年对软件测试的理解和技术更深入一层，成为一个专业的软件测试人员。这几天整理了一下思路，回顾了这两年来做测试的点滴想法。

　　1、软件测试人员应该不断学习

　　身为测试人员，虽然我们平常的工作大部分都比较安逸。但是千万不能温水煮青蛙。应该自强不息，不断学习，提高自己的测试技术。因为测试本来门槛就稍低，如果懈怠，随时都有可能被取代。重点就是深入学习测试技术，然后将技术应用到现有的项目中。

　　2、测试人员应该熟悉业务需求

　　测试人员的水平主要体现在测试用例的设计上。要设计出全面，覆盖广的测试用例，需要测试人员对自己所测试的项目的业务需求非常熟悉，甚至要比开发人员还要熟悉。1、要熟读功能需求文档，任何有疑问的地方都要去和负责人确认。2、把自己当成最终用户，经常使用自己所测试的软件，模拟用户的行为。3、熟记软件的每个功能。

　　3、学会如何跟开发人员相处

　　测试人员必须跟开发人员密切合作，所以跟开发人员搞好关系是相当重要的。1、和开发人员常打交道，尊重开发人员的工作成果，这样开发人员也会认真对待你提出的bug。2、集中问问题，将需要问的问题都总结起来，集中问开发人员，这样能节省大家大量的时间，也不会打扰开发人员的工作。3.bug描述要清楚，要能重现。以免开发人员要么将问题踢回，要么还得找你重新问，会耽误彼此的时间，降低工作效率。要写好Bug，描述精确，简洁，没有歧义，详细简洁的重现步骤，加截图。

　　4、提升文档的编写能力

　　测试人员写文档的地方比较多，平时测试用例、测试计划、测试报告以及用户手册等等都体现着测试人员文档编写能力的重要性，如果后期往TestLeader发展，还要非常擅长汇总测试报告，能够将完整，清晰，漂亮的测试报告发给各个组，让公司所有的人都能清晰的看到测试组的工作情况。

　　5、实行“一对多”的模式

　　“一对多”的模式是指：一个人可以同时测试多个项目，一个项目由多个人测试。因为每个人的见解和操作方式不同，所以发现问题的可能也不大一样，更有利于找出不易发现的bug，一个测试工程师测久了自己的项目，容易形成眼盲。会对一些Bug熟视无睹。

　　6、测试人员应该深入学习一写测试技术

　　初入测试，可能还提留在探索的阶段，不清楚要学习哪些和测试有关的技术，这时就需要我们主动去发现，通过书本和网上去看别人都是怎么做，汲取可用的经验，避免少走弯路。测试人员要提升的技术包含方方面面。

　　例如：性能测试（可参考的工具loadrunner）、自动化测试（可参考的工具QTP）、脚本语言（VBScript、Python）、数据库（SQLServer、Oracle）、操作平台（windows、Linux）、Web测试（Selenium）等等，还有很多很多，这么多的技术，学习只是一方面，更重要的是要根据我们现有的项目和测试环境，去分析什么才是最适合的，这样才可能真正将所学应用到项目上来。

　　7、建立一套完善的测试流程

　　测试流程已经大同小异了，但是真正按照流程来做的还是很少。如果条件允许的情况，还是应该尽量去按照流程去走，先去做单元测试、然后集成测试，而不是上来就直接进行系统测试。

　　8、多于客户和领导沟通

　　这点是想说给开发人员的，每一个开发人员一定要有自己见解，当某个功能和领导意见不一致时，应该用自己的理由去和领导说明，而不是领导说什么那就是什么，当被问到为什么要这么设计时，他的回答是：领导让这么做的。

　　因为每一个领导看项目的感觉又会不一样，所以今天领导提出一个想法，你改了，明天另一个领导又有新的意见，你又去改回来了。开发人员也没自己的意见，时间久了，一个功能改十次，再强的开发人员也会被拖垮的，而且时间上确实被大大的浪费了。

　　以上8点仅个人在工作中总结的一点意见和想法，仅供大家做下参考，如果不合适的地方，还望指正。

本文转载自51Testing软件测试网，查看更多：http://www.51testing.com/html/news.html

　　作为软件测试人员（SQA/SQC），做的最频繁并且最主要的活动之一就是编写软件测试用例了。首先，请记住以下所有的讨论都是关于编写软件测试用例，而不是设计/定义/确认测试用例（TC）。

　　这项主要活动有几个重要的关键因素，让我们先来大概了解一下吧。

　　A、软件测试用例要易于定期修改和更新

　　我们生活在一个不断变化的世界，软件也不能免于变化。需求也是如此，这就直接的影响到了测试用例。不论什么时候，一旦需求发生变化，测试用例就需要更新。然而，并不是只有需求的变化才会引起测试用例的版本变化和更新。在测试用例执行过程中，脑海中会涌现出许多的想法，单个测试用例的许多子条件会引起更新甚至测试用例的补充。除此而外，在回归测试中一些补丁和/或波纹都会需要修订或是新的测试用例。

　　B、软件测试用例要易于分配于执行用例的测试人员

　　当然了，让单独一个测试员执行完所有的测试用例是几乎不太可能的。正常情况下，一个单独的应用程序会有几个测试员分别负责测试不同的模块，因此，根据他们自己在应用程序中测试的部分测试用例也会相应的分配开。一些和应用程序集成相关的测试用例有可能会由多人执行而有的则只是由单独的个人执行。

　　C、软件测试用例要易于集群和批处理

　　属于一个测试场景的测试用例通常都会要求以一些特定序列或小组格式来执行，这很正常，也是很常见的。可能会有一些测试用例是其他测试用例的先决条件，同样的，根据AUT的业务逻辑，一个单独的测试用例会在几个测试条件中存在，而一个单独的测试条件也可能会由多个测试用例组成。

　　D、软件测试用例有相互依赖的趋势

　　测试用例中一个有趣并且重要的行为就是他们彼此之间是相互依赖的。在具有复杂业务逻辑的中型到大型应用程序中，这种趋势则更为明显。任何应用程序中能明确的观察到这个行为的最清晰的地方就是，相同甚至不同应用的不同模块之间的互操作性。简单的说就是，不管相异模块或应用程序是在哪里相互依赖的，相同的行为都体现在了测试用例中。

　　E、软件测试用例要易于在开发者间分配（尤其是在测试用例驱动开发环境中）

　　关于测试用例，重要的一点就是，它并不是只被测试人员使用的。在正常情况下，当开发人员修改bug的时候，他们间接的使用了测试用例来修改问题。同样的，如果遵守的是测试用例驱动开发，那么开发员则直接使用了测试用例来构建他们代码的逻辑并覆盖测试用例中处理到的所有的场景。

　　所以，将以上的5点记住，这里给出一些编写测试用例的建议：

　　要简洁但是不能太简单；要复杂但是又不能太复杂。

　　这句话似乎是自相矛盾的，但是我发誓并不是如此。走完测试用例的每一步，正确序列和预期结果的正确映射都得要精确，这就是我所说的让测试用例保持简单。

　　而，使其复杂一点实际上指的是测试用例得和测试计划以及其他测试用例相融合。当需要的时候，参照其他的测试用例，相关工件，GUI等。但是做此事的时候得均衡一下，不能让测试人员为完成单个测试场景就来回的搬运大堆的文件。另一方面，不要让测试人员希望你会压缩这些测试用例文件。在编写测试用例的时候，请时刻记住你或者别人不得不修改并且更新这些测试用例。

　　测试用例编制完成之后，以一个测试人员的角度再审视一遍：

　　永远不要以为你写完测试场景的最后一个测试用例后就算完事了。回过头去从开始将所有的测试用例再看一遍，但是不要当自己是个测试用例的编写者或测试策划者，以测试人员的角度审视所有的测试用例。理性的思考并且干运行你的测试用例，评估一下你所提到的每一步都是清晰易懂的，并且预期的结果和这些步骤也是相协调的。

　　测试用例中规定的测试数据不仅要对实际的测试人员是可行的，而且也得是依据真实的实时环境的。要确保测试用例中没有依赖冲突，而且也要确认对于其他测试用例/工件/GUI的所有参考都是精确的，否则测试人员会陷入大麻烦中。

　　约束测试人员，但同时也让他们感到容易。

　　不要把测试数据都留给测试人员，给他们一个输入的范围，特别是当执行运算的时候或者是应用程序的行为是取决于输入的时候。也许你会把测试项目的值分给他们，但是永远不要让他们自己来选择测试数据项目，因为，有意无意的，他们会使用相同的测试数据因而在执行测试用例的时候一些重要的测试数据会被忽略掉。

　　根据测试类别和应用程序的相关领域对测试用例进行组织，这能让测试人员感到容易一些。清晰的指出哪些测试用例是相互依赖的/或是可批处理的。同样的，明确的指示出哪些测试用例是独立的，孤立的，因此，测试人员就可以按照自己的意愿管理他/她的全部测试活动。

　　成为一个贡献者

　　从不接受FS或设计文档原来的样子，你的工作不仅仅是将FS浏览一遍然后明确测试场景。作为一个和质量相关的资源，你要毫不犹豫的去贡献。要给开发人员提建议，特别是在测试用例驱动开发环境中。建议一些下拉列表，日历控件，选择列表，单选按钮，更有意义的信息，警告，提示，可用性的改进等等。

　　不要忘记最终的用户

　　最重要的利益相关者就是将会实际使用AUT的最终的用户，所以，在编写测试用例的任何阶段都不要忘记他。事实上，在SDLC的任何阶段也都不能忽视最终的用户，但是目前我只强调和我讨论的话题相关的。所以在识别测试场景的时候，不要忽视这些大多情况下被用户使用的用例，或者是那些甚至不太使用的业务关键用例。把你自己想象成最终的用户，把所有的测试用例浏览一遍，判断一下你文档中测试用例执行的实际价值。

　　总结：

　　测试用例的编写是一项会对整个测试阶段产生重要影响的活动。这个事实使得测试用例文件编制这个任务变得非常的关键并且微妙。所以，编写测试用例得先适当的计划一下，还得非常的具有条理性。编制测试用例文件的人必须记住，这项活动不是为他/她自己而做的，而是为了整个团队，这个团队包括了其他测试人员和开发者，还有那些会被这项工作直接或间接影响到的客户。

　　所以，在这项活动进行的过程中必须给予适当的关注。对所有的使用者来说，测试用例文档必须是很好理解的，方式明确，维护简单。除此而外，测试用例文档必须介绍所有重要的特征，必须覆盖AUT所有重要的逻辑流，伴随着实时和实际可接受的输入。你编写测试用例的战略是什么？和我们的读者分享你的建议吧~也可把你的问题写在下面的评论中。

本文转载自51Testing软件测试网，查看更多：http://www.51testing.com/html/news.html

　　软件测试团队的四种类型：

　　（1）融合型

　　所谓融合型软件测试团队是指软件测试人员和软件开发人员融为一体，软件测试工作实际上就是由从事该软件开发的人员完成。

　　适用环境分析：

　　这种类型的测试团队虽然从某种角度来看有些优势，但其致命的缺陷是无法有效地保证测试质量。因此，这种类型的测试团队只能作为事业刚刚起步的小公司（因为这种类型的公司一方面资金较紧、项目少，另一方面管理也不完善）权宜之计，绝对不能作为长期采用的类型。

　　（2）相对独立型

　　所谓相对独立型软件测试团队是指软件测试人员和软件开发人员同属于一个部门，但属于不同的小组（即测试人员属于测试小组，开发人员属于开发小组，相对独立），软件测试工作由测试小组完成，软件开发工作由开发小组完成，两小组分工明确。这种测试和开发相对独立的测试团队具有以下一些优缺点。

　　适用环境分析：

　　这种类型的测试团队虽然存在明显的不足，但在大部分情况下还是能较好地保证测试质量，同时也能好地控制测试成本。因此，这种类型的测试团队适合规模不大的软件企业采用（因为这种类型的测试团队不需要占用公司较大的资金和人力投入）。

　　（3）完全独立型

　　所谓完全独立型软件测试团队是指软件测试人员和软件开发人员归属于各自独立的部门（即测试人员属于测试部门，开发人员属于开发部门），测试部门的工作质量由公司评价，测试人员的工作质量由测试部门主管评价。具体地说，就是测试人员和开发人员属于各自独立的部门，公司对各部门独立考核，测试人员的绩效完全由测试主管考核，产品是否通过测试需要由测试人员给出明确的结论。

　　适用环境分析：

　　这种类型的测试团队能有效地保证测试质量，但容易造成开发人员和测试人员之间的误解和矛盾。这种类型的测试团队比较适合从事产品研发和销售的公司采用（因为这样的公司一般产品比较单一、稳定，测试人员不需要向开发人员了解太多的产品信息）。

　　（4）相互制约型

　　所谓相互制约型软件测试团队是指软件测试人员和软件开发人员归属于各自独立的部门（即测试人员属于测试部门，开发人员属于开发部门），但测试人员和开发人员之间存在互相评价工作质量的关系。具体地说，就是测试人员和开发人员属于各自独立的部门，公司对各部门独立考核。测试主管考核测试人员的工作绩效时，以开发部门认可的有效测试工作量和测试质量作为考核指标之一；开发主管考核开发人员的工作绩效时，以测试人员提供的测试缺陷作为考核指标之一，并且产品是否通过测试需要由测试人员给出明确的结论。

　　适用环境分析：

　　这种类型的测试团队虽然存在一定的不足，但能有效地保证测试质量。这样类型的测试团队所占用的测试成本较高，因此比较适合具有一定经济实力的大公司采用，特别是以项目运作为主要业务的大公司采用（因为这样的公司很需要测试人员和开发人员密切沟通和配合）

本文转载自51Testing软件测试网，查看更多：http://www.51testing.com/html/news.html

　　摘要：软件测试是软件质量保证的一个重要组成部分，除了要具备一定的客观条件外，还受到许多主观因素特别是测试人员、组织和管理等方面的影响．在对这些主观因素以及软件测试软环境的构成与优化作了一些研究和探讨后，提出了一些可行性建议。

　　关键词：软件测试；单元测试；测试文档；

　　一、引言

　　软件测试作为软件开发的一个重要阶段，除了必须具备被测软件、测试工具、测试技术等一些必备的客观条件外，还受到测试人员、组织管理、测试策略等相关主观性较强的因素的影响。这些因素的综合作用——本文称之为软件的“测试软环境”，决定了软件测试的成败。

　　二、软件测试软环境的构成要素

　　1、测试人员

　　测试人员是软件测试的执行者，他们的素质将直接影响到软件测试的成败。软件测试是一项严谨的工作，一名优秀的软件测试工程师应具备以下的素质：

　　（1）沟通能力。测试者必须能够与测试涉及的所有人员（包括技术人员和非技术人员）进行沟通。由于人本身具有排他性，因此，当你试图从别人的程序中寻找错误或缺陷时，往往会遭到反对或对抗。测试者应尽量避免冲突和发生矛盾，要对每个人具有足够的理解和同情，具备了这种能力可以将测试人员与相关人员之间的冲突和对抗降低到最低程度。

　　（2）技术能力。由于开发人员对不懂技术的通常持一种不屑或轻视的态度，因此，一旦测试小组的某个成员作出了一个错误的判断，将直接导致他甚至整个测试小组的可信度降低，相反，则会大大增强测试人员的信心和测试工作的说服力。一个优秀的测试人员必须既明白被测软件系统的概念，又要熟悉并会使用相关的工具，而要做到这一点需要有几年的编程经验，只有通过这样的经验积累才会对软件的开发有更加深刻的了解。

　　（3）耐心。软件测试是一项非常烦琐的工作，很容易使人变得懒散，甚至烦躁不安。作为一个测试人员，你必须要有足够的耐心和自律能力，有时你需要花费惊人的时间去识别、排除一个故障，有些看似毫无成就的工作，往往就在你的苦思冥想后豁然开朗。

　　（4）兴趣和自信心。测试者应对自己所从事的工作具有浓厚的兴趣，对自己的观点有足够的自信，如果具备了这两点，那么在开发过程中，不管遇到什么样的困难，都能克服。

　　（5）怀疑与探索精神。一个软件从开发到投入使用通常要经历许多的循环往复，难免出现这样或那样的错误和缺陷，测试人员应具有叛逆心理，敢于怀疑，勇于探索，在可能的条件下，充分发挥自己的潜能，创造性地开展工作，力求寻找出软件中存在的故障。

　　（6）其它方面的素质。具有良好的判断能力，有一定的幽默感，逻辑思维敏捷等等。

　　2、组织与管理

　　（1）测试小组

　　由于软件故障的产生主要来源于软件需求分析、设计和编码阶段，因此，需求分析、软件设计和程序编码等各个阶段所得到的文档资料，包括需求规格说明书、设计规格说明书以及源程序都是软件测试的对象，而由此产生的测试组织与管理也是分阶段的，测试小组的人员组成方式也是不一样的。

　　需求分析阶段。这一阶段的测试人员应包括：用户、项目经理、系统分析员、软件设计、开发以及测试人员。他们需要进行多次讨论和协商来确定软件的功能，以此作为评价需求规格说明书的依据。

　　软件设计阶段。人员组成应包括：系统分析员、软件设计人员、测试负责人以及用户。这一阶段的主要工作是按照需求分析规格说明书的要求对系统结构的合理性以及过程处理的正确性进行审查，用户的作用在这一阶段不是非常突出。

　　软件测试阶段。软件测试作为保障软件质量的一个重要的手段，通常包含以下一些测试：单元测试、集成测试、确认测试、系统测试和验证测试。其中，单元测试由编程小组内部的编程人员交叉进行，其它测试工作则要由测试组来完成，此时，测试组成员的组成应包括：测试经理、测试技术人员、软件开发人员、相关技术支持人员以及用户。需要注意的是，在单元测试阶段，要严格杜绝编程人员测试自己编写的程序。

　　（2）测试管理

　　测试工作的管理，尤其是对于包含多个子系统的大型软件系统，其测试工作涉及大量的人力和物力，有效的测试管理是保证有效测试工作的必要前提。

　　首先，软件测试的有效实施需要测试组织与开发组织充分配合。虽然测试活动看似是对开发人员劳动成果的不断“挑剔”，但测试工作的出发点是：确保开发人员的劳动成果成为可被接收的、更高品质的软件产品。测试经理应在组织协调各组织工作方面发挥作用，并和他们一起工作，甚至对公司以外的个人和组织都是如此。测试经理在工作中所要处理的人员关系可用图1表示。此外，测试经理所处的职位要求他能提交日常主要工作的有关信息，如状态报告、测试计划、评估报告等，同时，还要根据当前的状态做出一些重大决策，这些决策可能会对整个测试过程产生一定的影响。

　　图1 测试经理的人际关系角色

　　其次，为确保软件测试在软件质量保证中发挥应有的作用，建立和完善软件测试管理体系是十分必要的。从软件工程的角度出发，软件测试管理所涉及的管理对象包含以下几个方面：

　　● 测试资源。包括对人员分配、工作环境、相关设施等的管理。

　　● 测试计划。根据资源配备情况，制定总体测试计划，确定各个阶段的测试目标和策略。

　　● 分析与设计。测试分析与设计就是确定测试目标并且如何以一种高效执行的方式组织测试的过程。这个过程需要根据测试计划选择合适的测试方案，设计出好的测试用例。

　　● 测试实施。测试实施是指测试人员根据测试计划，利用测试资源来运行测试用例以获得测试数据、开发测试规程的过程。这个过程涉及到测试环境的设置、测试数据的收集以及测试验证等具体的工作。

　　● 测试管理。测试管理作用于测试的各个阶段，其管理的对象包括测试组织的建立、测试过程的控制、测试计划和测试规程的制订与管理等等。

　　三、测试软环境的构建

　　1、测试人员

　　在一个测试小组中，并不是所有的测试人员都需要具有同样的技能，由于分工不同，他们所起的作用也不同。一般情况下，测试小组中测试人员的构成一般包括：

　　开发人员。最好的情况是：让开发人员去做单元测试，如果需要的话还可以让他们做集成测试。

　　用户。通常在测试阶段会给测试提供很好的帮助。

　　技术支持人员。熟悉软件产品的流程，与用户有更多的沟通，往往更能理解用户的想法。

　　QA人员。他们了解产品质量的重要性，对测试小组的工作是一个很好的补充。

　　技术文员。这是测试工作中必不可少的一个角色。由于工作的需要，他们关注测试过程中的很多细节问题，并按照要求完成相关的技术文档的编制，使得整个测试工作都有据可查。

　　.......

本文转载自51Testing软件测试网，查看全文：http://www.51testing.com/html/61/n-832461.html

　　话说作为一个测试人员，软件测试用例的设计与编写是一项必须掌握的能力，若想写出有效的软件测试用例则需要多方面的技术知识。平时工作遇到功能测试较多，但过多是敏捷型的，涉及少。我认为认真仔细的写好软件测试用例是有必要的。

　　就如何设计测试用例需从如下几个因素出发：

　　1、复用率，随产品不断升级，需要涉及更详细些，可一劳永逸；如仅使用一两次，没必要写的太仔细。

　　2、项目进度，时间允许可详尽，时间紧可执行即可。

　　3、使用对象，如果供多人使用，尤其让后参加测试的工程师来执行，则需要设计的更加详细些。

　　4、关注有效功能，大多数情况：我们不太可能在一个软件测试用例包含全部测试要求，因为众多的功能及不同的路径组合将使测试用例步骤繁多，操作复杂，或者完全不具可操作性。说这些并不是意味为需求中定义的每个功能和特性，编写一个或多个测试用例，只要把握好适度即可。

　　如何区分有效功能：

　　第一点，这个功能是可以还原到用户原始的手工业务流程中去的。

　　第二点，这个功能是否标志用户实际业务的一个阶段性结束，并且这项业务完成后，被完成的业务实体是否可以交付给其他用户或业务供完成下面的工作？

　　5、做好需求分析，这里的需求包含显示和隐式需求，根据需求文档将不同需求来源划分成一个个需求点，针对每小点进行测试分析，界定测试范围，并运用多种测试用例设计方法产生测试节点。

　　6、注重测试用例评审，评审会以检验功能是否覆盖完全，评审会成员有设计，开发，测试及专家成员。

　　如果测试用例编写不规范，后果不堪设想。

　　请参见：http://www.51testing.com/html/03/n-16903.html

　　啰嗦下：测试全面不等于全面测试，要结合实际进行覆盖而不是盲目的追求全面覆盖。有时候测试不全面但在不影响主流程的情况下，存在功能Bug也需要上线，这是测试人员无法掌控的。在成本面前测试人员总是无可奈何。。。

　　专家给的建议：在测试需求阶段进行测试需求分析（如果是已有的升级版本，可通过已确定的需求说明书及开发人员的功能描述，对过往的测试用例进行补足编写；如果是一个全新的需求可通过PRD，开发对产品的可实现功能描述及经验，相关业务知识进行用例设计），明确需求并找出隐式需求，随后制定测试策略。同时进行测试时间的估算和风险的预估，初步制定测试时间，测试工时，测试环境以及测试中可能需要的测试工具（如果有，可考虑）。

本文转载自51Testing软件测试网，查看更多：http://www.51testing.com/html/news.html