在项目启动会议上，项目经理告诉大家说将在项目中采用自动化测试工具，然后指定你在下周的会议之前提交一份工具选型报告。你感到很惊讶，项目经理是从什么地方了解到自动化测试的，为什么突然对自动化测试这么着迷，你突然想起几周前某个工具厂商的销售人员曾经到公司拜访……

　　你忧心重重，难道项目经理已经掉入了所谓的自动化测试陷阱中？！

　　陷阱1：自动化测试工具是万能的！

　　到目前为止，还没有一款商业测试工具能支持从测试计划，到测试设计，再到测试执行的自动化。

　　你经常会在某些测试工具的产品推介会、演示会上看到演讲者展示测试工具的种种好处、优点，让你为自动化测试激动不已；但是他们往往不会告诉你自动化测试的难点所在，实施自动化测试的复杂度，以及所需的投入有多大。

　　你的项目经理也许就在这时候开始一步步迈向自动化测试的陷阱。

　　陷阱2：一个工具能适合所有项目

　　到目前为止，还么有一款工具可以支持所有操作系统环境。

　　你也许会被项目经理要求寻找一款可以支持所有实时嵌入式系统测试的测试工具，而你们的应用需要跑在各种操作系统环境上，包括VxWorks、Integrity、mainframe、Linux 和 Windows XP，编程语言包括Java和C++。

　　陷阱3：引入自动化测试工具后，测试人员的负担立即减轻

　　引入自动化测试工具后，并不会马上就减轻测试负担，事实上一开始往往会增加负担。

　　项目经理往往希望通过引入自动化测试工具来减轻测试负担。但是经验表明，在一个新项目中尝试实施并且有效地应用自动化测试，往往需要经过一条学习的曲线。测试的负担并不会马上减轻，但是项目经理却希望马上看到自动化测试发挥其威力，希望马上看到效果。

　　事实上，在一开始的时候，很大可能会增加测试的负担，因为测试工程师需要一段时间熟悉和掌握测试工具，而与此同时，手工测试一刻也不能停止，因此测试的负担没有减轻，反而加重了。

　　另外，自动化测试需要仔细的分析被测试应用程序，哪些部分需要和能够被自动化实现；并且需要仔细地设计和开发测试脚本。这些无疑都将加重测试的负担，尤其是在初始阶段。

　　陷阱4：引入自动化测试工具后，进度可以马上被压缩

　　上了自动化测试工具之后，整体测试进度不会马上缩短，相反，在初始阶段，往往会对进度造成一定的延误。

　　另外一个误区是，自动化测试工具能马上缩短测试时间表。但是由于测试的负担在初始阶段加重了，因此很自然地，我们不能期待进度缩短，相反，在引入自动化测试后，我们应该给初始阶段的进度表预留一些时间。一旦整个自动化测试的流程建立起来之后，我们就可以期待自动化测试给我们的进度带来积极的影响。

　　陷阱5：自动化工具是很容易使用的

　　自动化测试工具要求测试人员掌握新的技巧，通常需要额外的培训。应该制定培训计划，投入时间和成本，度过学习的曲线。

　　通常很多工具厂商都会夸大自己产品的易用性，他们会否认所谓的"学习曲线"。工具销售人员通常鼓吹所谓的"录制/回放"可以简单地记录下测试工程师的键盘和鼠标动作，然后再简单地回放出来。

　　但是，有效的自动化测试远远不仅仅是"录制/回放"那么简单。录制下来的脚本需要手工修改，以便让其可重用性和可维护性更强一点、更灵活一点，而这些都需要语言和脚本知识。因此他们需要针对工具和内建的脚本语言接受培训。

　陷阱6：所有测试都可以被自动化

　　并非所有的测试都可以被自动化。

　　自动化测试是手工测试的增强。乞求项目中的测试百分百实现自动化是不合理的。在首次引入自动化测试时，最好先验证一下，工具是否能识别出所有对象和第三方的控件。这对于基于GUI的测试工具来说非常重要，因为这类工具往往在识别一些个性化控件方面有困难，例如一些calendar、spin、grid控件，而这些控件被广泛应用在程序界面中，并且这些控件往往由第三方编写，大部分测试工具厂商未能跟上他们的发展速度。

　　测试工程师在碰到这种情况时要么放弃这部分应用了难以识别的控件的测试自动化，要么找出一些解决的办法。

　　另外，还有一些测试是基本上不可能被自动化实现的，例如，测试工程师可以实现自动化地把文档发送到打印机的过程，但是检查打印的效果（是否被正确地打印出来，有没有越过纸张打印线）这部分则必须人工进行。

　　至于哪些测试用例应该被自动化实现，可以参考下表决定：

		YES	NO
测试执行的次数	测试会被执行多次吗？
	测试会有规律地运行吗？例如经常被重用，作为回归测试的一部分或每日构建测试？
测试的关键程度	测试覆盖了软件功能的最关键部分的路径吗？
	测试覆盖了最复杂的部分吗？（通常是最容易出错的部分）
测试的代价	如果手工进行测试的话，是否不可能、非常难以执行，例如并发测试、持久性测试、性能测试、内存泄漏测试等。
	测试非常耗时吗？例如需要检查成百上千个测试结果输出。
测试的类型	测试需要组合很多输入，但是共用一个测试步骤吗？例如同一个功能，用很多不同的输入来验证。
	测试需要在多种软硬件配置环境下执行吗？
被测试应用或系统	测试是在一个稳定的应用程序上执行的吗？例如功能特性已经基本完成。
	使用兼容的技术和开放的架构

　　陷阱7：自动化能提供百分百的测试覆盖率

　　并非所有内容都可以被自动化地测试到。不可能覆盖所有可能的输入，所有可能的组合和路径。

　　自动化测试可以增加测试的广度和深度，但是仍然无法达到100%的测试覆盖率，因为没有足够的时间或资源。

　　例如一个简单的登录界面的测试，假设我们需要测试它的密码验证函数的正确性，密码长度在6到8个字符之间，每个字符可以大写或小写，至少包含一个数字，那么输入的可能组合将达到2,684,483,063,360个。

　　即使我们可以每分钟创建一个测试，也需要155年来完成全面的测试。因此，不可能穷尽所有可能的输入的测试。

　　陷阱8：测试自动化就是录制和回放

　　仅仅录制得到的不是有效的自动化脚本。

　　很多项目经理仍然把测试自动化等同于使用录制回放工具。而事实上，录制得到的脚本通常是不可重用的脚本，脚本中充满了硬编码的值，这些值应该被参数化，否则脚本仅仅适用于一个测试情况，脚本还应该加入条件判断、循环等结构，以便增强测试脚本的灵活性。

　　陷阱9：自动化的软件测试与手工的软件测试过程一样

　　自动化测试所需要的技巧与手工测试所需要的技巧是不一样的。

　　通常，你的项目经理会被那些测试工具销售们迷惑，认为自动化的软件测试就是简单地按一个录制的按钮，产生测试脚本。而事实上并没有那么简单。

　　区分自动化测试所需要的技巧与手工测试所需要的技巧是非常重要的。最重要的是，自动化测试工程师需要掌握软件开发技巧，没有接受任何培训的手工测试人员，或者没有编程背景的手工测试人员，在实施自动化测试时会碰到很多困难。

　　陷阱10：忘记了测试的最终目标：找到BUG

　　在自动化测试中，同样要注意把边界值分析、等价类分析、基于风险的测试方法、挑选最合适的测试用例等技术应用起来。

　　通常在自动化测试过程中，我们都忙着搭建自动化框架和编写测试脚本，但是我们往往忘记了测试的本来目的：找bug。

　　项目经理可能雇佣了最好的自动化开发人员来搭建框架，使用了最新最好的自动化开发技术，创建了成千上万的自动化测试脚本。但是如果BUG仍然被遗漏了，那些本该被自动化测试脚本捕捉到的BUG，结果没有被捕捉到，那么你的自动化测试仍然会被认为是失败的。

　　小结

　　正在你忧心重重，担心项目经理一步步迈向自动化测试的陷阱的时候，你看到了这篇文章，你决定拿给项目经理看看，希望他在看完这篇文章之后，对自动化测试有一个新的认识，从而把那只即将踏入陷阱的脚抽回来！

来自：http://www.51testing.com/?action_viewnews_itemid_106406.html

 

“抢钱原则”——你面对飘洒满地的纸币，有100元，50元，10元，5元，2元，1元，5毛，2毛，1毛。 各种面值。大家抢钱的时候，都是先挑选100元的抢走，然后找50元的，选择的顺序很清晰，都是从面值大到面值小。这就是“抢钱”原则。

　　测试执行的时候，大家面对是一堆用例，这些用例起到的作用也是不同的，那么如何保证我们在有限的时间执行的用例是最有效的，最有价值的。

　　尤其是无法全部执行用例的时候，势必有裁剪的时候，我们需要有很好的用例执行的优选原则。

　　我们要应用抢钱原则，选择好最有价值的用例优先执行。那么，如果搞清楚什么样的用例最有价值，就OK。

　　用例价值大的用例主要有三个方面的因素：1 容易发现的故障的用例；2 用户最常用的场景；3 如果泄露，用户的生气程度大的。

　　1、容易发现故障的用例

　　1） 性能相关的用例—上游的环境受限，所以这个部分比如容易发现故障

　　2） 边界值相关用例—边界引发的故障比例最高

　　3） 开发部在集成测试最不容易做到的用例，比如场景复杂度高的

　　2、用户最常用的场景

　　1） 比如局内呼叫，做主叫，做被叫，短消息，预付费，彩铃等多是最常用的业务，这些业务如果出现问题，只有回退版本了。

　　2） 配置管理的号码分析，动态管理的查看链路状态，告警查看

　　3、如果泄露，用户生气程度大的

　　1） 比如无法拨打电话 > 可拨打，单通 > 可以正常通话，无回铃音 > 可以正常通话，回铃音有杂音

　　2） 无法出话单 > 话单内参数错误

　　如上的仅仅是一些实例，没有复杂的算法模型来排序用户行为。

　　总之：拿到用例，一定要先分析出最有价值的用例，再开始执行。如果拿到用例，平铺直叙的执行。 那咱不就成了抢钱时候先抢毛票的傻子了？

 

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

什么样的用例是好的用例?

　　一.质量属性

　　Quality Attributes

　　1.正确性：确保测试标题描述部分的内容正确性。

　　2.经济性：只为确定需要的目的设计相应的测试步骤

　　3.适应性：既能适应短期需要，又能考虑长远需要。

　　4.可追踪性：用例能追踪到一个具体的需求。

　　5.自我清理性：单个用例不会影响整个测试环境，即用例执行完了可以恢复原有的测试环境。

　　二.结构化和可测试性

　　Structure and testability

　　1.含有规范的测试标题和编号。

　　2.含有一个确定的测试某一个特定需求的目的。

　　3.含有关于测试方法的描述。

　　4.指定条件信息-环境、数据、预置的条件测试、安全入口等。

　　5.含有操作步骤和预期结果。

　　6.陈述任何辅助证据，例如截图报告并确保这些东西妥善保存。

　　7.确保测试环境的干净（即用例不会影响整个环境）。

　　8.描述时使用主动语气结构。

　　9.操作步骤不要超过15步

　　10.确保单个用例测试执行时用时不超过20分钟。

　　11.自动化脚本用例添加必要的注释，比如目的、输入和期望结果。

　　12.如果可能，建议提供可选择性的预置条件测试。

　　13.用例之间的先后顺序是否跟业务流程一致，即用例在业务流程中的彼此顺序关系是否合理。

　　三.配置管理

　　Configuration management

　　1.采用命名和编号规范归档。

　　2.保存为特定的格式，文件类型。

　　3.用例版本是否与当前被测试软件版本一致（对应）。

　　4.包含用例需要的相应测试对象，如特定数据库。

　　5.存档阅读。

　　6.存档时按角色控制访问方式

 

原帖链接：http://www.51testing.com/html/200812/n98758.html

在大家懵懵懂懂之中，踏入测试大军的那一刻起，想来都曾经看过或者说都曾经被问过：身为一个测试人员，需要具备什么素质？测试员的责任是什么？

　　在从事了一两年的测试工作之后，很多人在坚守着自己当初对这个行业许下的诺言。也有些人，终日混在开发人员堆里的（这个几率很大），渐渐的就如被火烫伤过的猫一样，收回了自己的利牙和尖爪，他们和开发人员一起，“各管一片”，只是应对着某一个小小的问题。在测试中，即使发现了别的问题，也会因为这个问题跟这次测试的主要目的不同而“ 视而不见”。。

　　这样的测试到底对不对？自己以前的思维到底对不对？

　　我近来常常在思索这个问题。

　　一个成规模的测试团队，却因为其中有偶尔的几个有过编程经验，可以帮助开发人员去Fix Issue的人而得益。这是怎样一个团队？一个测试人员，不从如何提高自己的测试水平出发去努力，而是努力的如何去跟开发人员搞好关系（我不是说不重要），如何去游说周边的人，开发人员修改一个问题或者发布一个版本的辛苦。。这是怎样的一个团队？

　　我无语。。

　　无论如何难解。我还是坚定地认为，测试人员应该首先看清自己的责任。应该明白什么叫做测试的机会和测试的成本。应该懂得如何在发现Issue的第一时间来报告和促使解决这个问题。

　　这些都是最基本的知识，确实在现实生活中，尤其在这样的开发和测试团队中最难做到的。。

　　我相信，终有一刻，终有一日，坚守的会开发结果。放弃原则的，夹缝中的人，会无处藏身。。

　　记住测试人员的责任：站在客户的角度，尽早的找出bug,并且促使其修复。

　　 好的测试工程师应具备的素质

　　人是测试工作中最有价值也是最重要的资源，没有一个合格的、积极的测试小组，测试就不可能实现。然而，在软件开发产业中有一种非常普遍习惯，那就是让那些经验最少的新手、没有效率的开发者或不适合干其他工作的人去做测试工作。这绝对是一种目光短浅的行为，对一个系统进行有效的测试所需要的技能绝对不比进行软件开发需要的少，事实上，测试者将获得极其广泛的经验，他们将遇到许多开发者不可能遇到的问题。

　　1.沟通能力。

　　一名理想的测试者必须能够同测试涉及到的所有人进行沟通，具有与技术（开发者）和非技术人员（客户，管理人员）的交流能力。既要可以和用户谈得来，又能同开发人员说得上话，不幸的是这两类人没有共同语言。和用户谈话的重点必须放在系统可以正确地处理什么和不可以处理什么上。而和开发者谈相同的信息时，就必须将这些活重新组织以另一种方式表达出来，测试小组的成员必须能够同等地同用户和开发者沟通。

　　2.移情能力。

　　和系统开发有关的所有人员都处在一种既关心又担心的状态之中。用户担心将来使用一个不符合自己要求的系统，开发者则担心由于系统要求不正确而使他不得不重新开发整个系统，管理部门则担心这个系统突然崩溃而使它的声誉受损。测试者必须和每一类人打交道，因此需要测试小组的成员对他们每个人都具有足够的理解和同情，具备了这种能力可以将测试人员与相关人员之间的冲突和对抗减少到最低程度。

　　3.技术能力。

　　就总体言，开发人员对那些不懂技术的人持一种轻视的态度。一旦测试小组的某个成员作出了一个错误的断定，那么他们的可信度就会立刻被传扬了出去。一个测试者必须既明白被测软件系统的概念又要会使用工程中的那些工具。要做到这一点需要有几年以上的编程经验，前期的开发经验可以帮助对软件开发过程有较深入的理解，从开发人员的角度正确的评价测试者，简化自动测试工具编程的学习曲线。

　　4.自信心。

　　开发者指责测试者出了错是常有的事，测试者必须对自己的观点有足够的自信心。如果容许别人对自己指东指西，就不能完成什么更多的事情了。

　　5.外交能力。

　　当你告诉某人他出了错时，就必须使用一些外交方法。机智老练和外交手法有助于维护与开发人员的协作关系，测试者在告诉开发者他的软件有错误时，也同样需要一定的外交手腕。如果采取的方法过于强硬，对测试者来说，在以后和开发部门的合作方面就相当于“赢了战争却输了战役”。

　　6.幽默感。

　　在遇到狡辩的情况下，一个幽默的批评将是很有帮助的。

　　7.很强的记忆力。

　　一个理想的测试者应该有能力将以前曾经遇到过的类似的错误从记忆深处挖掘出来，这一能力在测试过程中的价值是无法衡量的。因为许多新出现的问题和我们已经发现的问题相差无几。

　　8.耐心。

　　一些质量保证工作需要难以置信的耐心。有时你需要花费惊人的时间去分离、识别和分派一个错误。这个工作是那些坐不住的人无法完成的。

　　9.怀疑精神。

　　可以预料，开发者会尽他们最大的努力将所有的错误解释过去。测式者必须听每个人的说明，但他必须保持怀疑直到他自己看过以后。

　　10.自我督促。

　　干测试工作很容易使你变得懒散。只有那些具有自我督促能力的人才能够使自己每天正常地工作。

　　11.洞察力。

　　一个好的测试工程师具有“测试是为了破坏”的观点，捕获用户观点的能力，强烈的质量追求，对细节的关注能力。应用的高风险区的判断能力以便将有限的测试针对重点环节。

        测试是用来保证软件开发过程的高效性，以及保证开发出来的软件产品的高质量和可用性的。软件开发本身就是一件非常困难的事情，这也决定了有效的测试决不是简单的依靠一些测试工具就可以进行的。在使用工具的同时，我们更要加强关于测试的培训、教育，使大家对于测试首先有一个正确的认识。只有这样，我们才能够更加有效、高效的使用工具，才能够使测试真正起到它应有的作用。

按一般统计，在完整的软件项目中测试成本占整个开发成本的35%，而开发部分只占30%多一点；另外的35%是系统架构，也就是平常说的需求分析，系统分析，项目规划这些工作。如果说需求分析部分的成本由于往往以来来去去的修改体现出它的价值的话，那么测试，尽管天天说成本比开发的部分还要多；但实际上呢？通常如果是IMS类型的项目，都是十到二十分之一的时间用于测试，更多的时侯，干脆让用户来测试，美其名若系统稳定期。唯一例外的大概是开发防火墙的过程，为了获取准确的性能水平，必须外包进行测试，这才显得测试的成本变得铁打不动的真金白银。

    测试一般是放在系统完成后进行测试，但今天，却常常听到资深开发人员劝导新人们：“测试是开发的第一步”这句话如何理解呢？如果从日本人发明的巴克质量管理的方式去理解，大概是指每一个环节交给下一级时都应该进行测试。有些测试对后面的操作没有太大的影响，如图片不漂亮，菜单不合理，布局很难看之类；而另一些，却直接让下一级无法开始工作，象用例不清晰；用例自相矛盾；组件内部错误；框架不合理等等。固然，一级级把关，可以把质量提高到至少一个档次以上；但就每一个环节而言，仍然是在开发的最后阶段。所以，看来本人的水平还是不到家，"测试是开发的第一步"难以理解，唯一可理解的就是规范先行，文档先行，文档规范化总应该是在编码以前，这也是QA的主要内容；大概这还多少算解释得通。这样，测试和规范两样东西就重合起来了，从严格角度看，测试就是测试，规范归入规范，还是从模块（项目）后的测试开始理解吧；所以所有关于编程和文档、设计规范的内容本人全部不纳入测试讨论范围。或者说，我们重点放在QC上，而不是着眼于规范的QA，尽管那也非常重要。

    单元测试(Unit test)：是针对模块组件或方法的测试。在本人的操作中，一般是开发员工作范围内的测试；在具备组件接口规范的情况下，一般需要做一个测试工具模拟调用环境，编写测试实例，通过断点情况监视模块实际工作是否正常。一股采用这种方式开发的单一功能模块质量都是非常高的。但是如果没有统一的模块规范，那么开发与测试的工作量接近一比一；但如果模块是按统一的标准开发的，那么同一套测试套件就可以用到各个模件上，从而节省了测试时间。本人认为这属于开发部门工作范围内的测试，与QA/QC部门没有什么大的关系，事实上，在这一层次的用例也不是QC可以做到和理解的。

    白箱测试：在理解内部流程的情况下针对逻辑流程设计测试实例，目的是找出极限边缘以及内在的逻辑错误。单元测试中白箱测试的比例很高，（原因不难理解，还有谁比作者自已更理解模块的构造流程的？）。

    黑箱测试：这是QC部门的主要工作。黑箱测试主要在于编写测试实例。不过在实际操作中，都是把最不懂技术的成员分配做测试，最高技术水平就是会用VSS，所以也就别指望编什么测试实例。所谓的黑箱测试，常常是对着菜单按钮，这个按下去，噢，有东西出来了，对的，打个勾——其实，这时侯的实例就是一个个按下去然后看看有没有输出，而且只限于界面方面，内在的部分和边缘情况大概是不用指望的。但据作者所知，在CMM达到四以上的国外软件公司中，黑箱测试是对软件评价的最主要方式，通过合适的测试实例，除了最常见的可用性测试外，还包括压力测试，和怪用测试（Monkey test)。

    压力测试：评价一个系统极限可以承受的压力是多少，同时在超负荷后的的响应情况；同时，在极限状况下，一些平时不太出现的bug也会浮现出来。所以，这个测试作者认为不应该单独由QC部门进行，而应该由开发部门与QC部门联合进行。理想的系统在极限测试状况下就算响应不及，也不至于当机，并在负荷恢复正常后一段时间内可以恢复正常运转。这时当初对windows恶评的原因之一：象网站一旦超出100-200个concurrent,windows不但罢工还死掉了；不得不重启系统（当然，windows任意硬重启都能死鱼翻生，大多数情况下吧，也属一种难能可贵的优点）；而linux在超出负荷后一般情况下下降曲线不至于太明显——不过这也不是绝对的，作者就发现一旦linux在极限状态下进入内存抖动时，死相和windows差不了多少；所以内存不至于耗干是 linux可靠性能超过windows的重要因素。

    回归测试；在修改其中一个模块后看其他模块有什么问题。作者认为这个测试是过程化程序的观念产物，在模块化软件中相互耦合程度低，而且服从统一的调动协议，是不是修改真是自家里的事情，和他人（模块）没有半点相干。

    整体测试：把不同的模块连结后，看看联合工作情况如何。这实际上是对接口协议的测试。作者认为是可以作为接口互动部分的设计一部分工作，没有必要摆出来作为流程之一。同理还有系统测试，反正最后整个系统运行起来是什么情况。看似大，但如果前面已经做到好好的，这里如果出问题那才叫怪呢！

    Alpha测试：放任内部成员胡作非为的测试；

    Beta测试：让全世界的坏人都胡作非为的测试。

    过了这一关后，大概应该可以了吧？？在欧洲美国日本的规范的软件公司大概是可以了。但在中国可不见得，许多时侯业务需求人员会蹦出来说：“不是这个样子的！”早的时侯他不知上那里去了！或者“加上另一个什么功能吧？”，早的时侯他大概是睡觉了。大家伙儿前面做的事情，就冲这两句话就全废了,全部事情得从中间某个环节重来，这才叫恶梦。这时，与其顺着他们老哥胡说八道跑，不如找出合同来一条条地仔细颁下去。

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

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

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

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

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

对一个想进入软件测试行业的新人来说，我想首先需要提到的是要想清楚自己是否真的是喜欢测试这个行业，或者是其它什么原因（比如刚进入公司就受到老班的“器重”：小刘，以后测试就靠你了，质量就靠你了）硬着头皮进入这个行业；如果你对此没有兴趣，也不是因为生活所迫，而只是认为软件测试可以作为进入软件行业的敲门砖的话（在很多人眼里，一直有软件测试是一个苦力胜过于技术的错误观念！)，那我劝你看了这篇文章后赶快逃吧！

　　也就是说对于软件测试入门来说，是需要很大的兴趣驱动的，对大多数人来说，在经历了一些比较痛苦且乏味的测试训练（比如有的公司会让新人写大量的测试用例，其实这也是一种错误的方法--对软件测试工作来说）之后，有很多人开始打退堂鼓，这个时候，兴趣就显得很重要了。从另一个方面来说，兴趣也是做好一件事情的必要条件，否则如果自己像对待敌人一样仇视自己所做的事情，不知道会有什么样的结果……

　　当你拥有了上面所说的必要条件之后，我要对你说，欢迎加入我们的行列！也许在此之前你已经看过一些关于软件测试方面的消息，或许听到了一些对于软件测试不利或有利的消息(无非就是国内的软件测试行业发展很不健全，很多公司不注重软件测试，而另一面则说我国软件测试行业正处于快速起飞阶段等等)。也许现在的你开始有点动摇了，这里我有一点需要提醒的是，相信你所选择的，既然有兴趣，就走进来看看，看过之后再下结论也不迟。或许你会发现自己真的不适合软件测试，或者软件测试真的不适合自己，但是至少在你离开之前放下了好奇的包袱。当然，我相信更多的人会越发坚定地认为：自己真的选对路了！

　　说了这么多，感觉还是要讲点实际的东西。就介绍几本书吧。一本是很多前辈认为非常好（我也认为很好^_^）的《软件测试》（《Software Testing》Ron Paton）,这本书有几个译本，我感觉都还不错。还有一本书是 《软件测试入门》（《Introducing Software Testing》Louise Tamres  中文译本有人民邮电出版社2004版的）。

　 做测试过程中发现，一般没有需求说明文档有3种情况

　　1、开发人员的意识不足，开发流程不规范，可能是以前做项目一直都是拿到市场可行性分析，然后项目管理人员进行简单模块划分，任务就分配下去了，更不就不写需求文档，或者只是简单书写大体功能点。

　　2、项目进度紧张，后期需求变动可能比较大，来不及书写详细的需求文档

　　3、项目是从原有项目上进行迭代开发，开发人员认为不要再进行需求文档编写。

　　针对上述3点提出个人意见：

　　对于第一种情况：

　　1、测试负责人应该坚持开发没出需求文档，就不进行测试，要坚持让开发输出项目需求文档，哪怕是写的不够详细也好，最少都要输出一份简单的功能列表；

　　2、需求文档要进行评审，评审做会议记录，并有专门人员对需求文档进行修改；

　　3、最后就是测试人员进行测试需求分析，再根据测试需求点进行测试用例编写了。

　　对于第二种和第三种情况：

　　1、测试人员尽量找到已存在的资料，比如市场调研书，可行性分析报告，收集一切对项目有用的文档。并提出其中的功能点需求；

　　2、如果是迭代项目开发，则找到前期项目的一些需求文档，概要设计，详细设计，测试需求，用例等。提起里面的功能点；

　　3、咨询相关人员，获取项目一些大体功能，最好能知道大体项目的框架，然后记录咨询到的功能点；

　　4、了解项目大体框架后，可以在网上寻找同类产品，把里面的一些亮点功能点进行提起；

　　5、整合上面的几点，测试人员应该书写一份你认为的测试需求点，然后分发给每个和项目有关人员，如测试人员，开发人员，市场人员。组织进行一个会议评审，在评审中详细记录修改的地方；

　　6、最后整理出一份评审过的测试需求点，进行设计测试用例。

　　没有需求文档对于编写测试用例来说，确实很困难，做为测试人员，在没有测试需求文档情况下，我们不能等着开发人员输出，应该主动点，尽可能去多了解项目的一些情况，多知道一点，对测试用例就能多写点。

用例执行百分比=项目测试完成百分比？

测试执行过程应注意的问题

 　　测试环境搭建之后，根据定义的测试用例执行顺序，逐个执行测试用例。在测试执行中需要注意以下几个问题：

　　全方位的观察测试用例执行结果： 测试执行过程中，当测试的实际输出结果与测试用例中的预期输出结果一致的时候，是否可以认为测试用例执行成功了？答案是否定的，即便实际测试结果与测试的预期结果一致，也要查看软件产品的操作日志、系统运行日志和系统资源使用情况，来判断测试用例是否执行成功了。全方位观察软件产品的输出可以发现很多隐蔽的问题。以前，我在测试嵌入式系统软件的时候，执行某测试用例后，测试用例的实际输出与预期输出完全一致，不过在查询 CPU 占用率地时候，发现 CPU 占用率高达 90 ％，后来经过分析，软件运行的时候启动了若干个 1ms 的定时器，大量的消耗的 CPU 资源，后来通过把定时器调整到 10ms ， CPU 的占用率降为 7 ％。如果观察点单一，这个严重消耗资源的问题就无从发现了。

　　加强测试过程记录： 测试执行过程中，一定要加强测试过程记录。如果测试执行步骤与测试用例中描述的有差异，一定要记录下来，作为日后更新测试用例的依据；如果软件产品提供了日志功能，比如有软件运行日志、用户操作日志，一定在每个测试用例执行后记录相关的日志文件，作为测试过程记录，一旦日后发现问题，开发人员可以通过这些测试记录方便的定位问题。而不用测试人员重新搭建测试环境，为开发人员重现问题。

　　及时确认发现的问题： 测试执行过程中，如果确认发现了软件的缺陷，那么可以毫不犹豫的提交问题报告单。如果发现了可疑问题，又无法定位是否为软件缺陷，那么一定要保留现场，然后知会相关开发人员到现场定位问题。如果开发人员在短时间内可以确认是否为软件缺陷，测试人员给予配合；如果开发人员定位问题需要花费很长的时间，测试人员千万不要因此耽误自己宝贵的测试执行时间，可以让开发人员记录重新问题的测试环境配置，然后，回到自己的开发环境上重现问题，继续定位问题。

　　与开发人员良好的沟通： 测试执行过程中，当你提交了问题报告单，可能被开发人员无情驳回，拒绝修改。这时候，只能对开发人员晓之以理，做到有理、有据，有说服力。首先，要定义软件缺陷的标准原则，这个原则应该是开发人员和测试人员都认可的，如果没有共同认可的原则，那么开发人员与测试人员对问题的争执就不可避免了。此外，测试人员打算说服开发人员之前，考虑是否能够先说服自己，在保证可以说服自己的前提下，再开始与开发人员交流。

　　及时更新测试用例

　　测试执行过程中，应该注意及时更新测试用例。往往在测试执行过程中，才发现遗漏了一些测试用例，这时候应该及时的补充；往往也会发现有些测试用例在具体的执行过程中根本无法操作，这时候应该删除这部分用例；也会发现若干个冗余的测试用例完全可以由某一个测试用例替代，那么删除冗余的测试用例。

　　总之，测试执行的过程中及时地更新测试用例是很好的习惯。不要打算在测试执行结束后，统一更新测试用例，如果这样，往往会遗漏很多本应该更新的测试用例。

　　提交一份优秀的问题报告单

　　软件测试提交的问题报告单和测试日报一样，都是软件测试人员的工作输出，是测试人员绩效的集中体现。因此，提交一份优秀的问题报告单是很重要的。软件测试报告单最关键的域就是 “ 问题描述 ” ，这是开发人员重现问题，定位问题的依据。问题描述应该包括以下几部分内容：软件配置、硬件配置、测试用例输入、操作步骤、输出、当时输出设备的相关输出信息和相关的日志等。

　　软件配置： 包括操作系统类型版本和补丁版本、当前被测试软件的版本和补丁版本、相关支撑软件，比如数据库软件的版本和补丁版本等。

　　硬件配置： 计算机的配置情况，主要包括 CPU 、内存和硬盘的相关参数，其它硬件参数根据测试用例的实际情况添加。如果测试中使用网络，那么网络的组网情况，网络的容量、流量等情况。硬件配置情况与被测试产品类型密切相关，需要根据当时的情况，准确翔实的记录硬件配置情况。

　　测试用例输入 \ 操作步骤 \ 输出： 这部分内容可以根据测试用例的描述和测试用例的实际执行情况如实填写。

　　输出设备的相关输出信息： 输出设备包括计算机显示器、打印机、磁带等等输出设备，如果是显示器可以采用抓屏的方式获取当时的截图，其他的输出设备可以采用其它方法获取相关的输出，在问题报告单中提供描述。

　　日志信息： 规范的软件产品都会提供软件的运行日志和用户、管理员的操作日志，测试人员应该把测试用例执行后的软件产品运行日志和操作日志作为附件，提交到问题报告单中。

　　根据被测试软件产品的不同，需要在 “ 问题描述 ” 中增加相应的描述内容，这需要具体问题具体分析。

　　测试结果分析

　　软件测试执行结束后，测试活动还没有结束。测试结果分析是必不可少的重要环节， “ 编筐编篓，全在收口 ” ，测试结果的分析对下一轮测试工作的开展有很大的借鉴意义。前面的 “ 测试准备工作 ” 中，建议测试人员走读缺陷跟踪库，查阅其他测试人员发现的软件缺陷。测试结束后，也应该分析自己发现的软件缺陷，对发现的缺陷分类，你会发现自己提交的问题只有固定的几个类别；然后，再把一起完成测试执行工作的其他测试人员发现的问题也汇总起来，你会发现，你所提交问题的类别与他们有差异。这很正常，人的思维是有局限性，在测试的过程中，每个测试人员都有自己思考问题的盲区和测试执行的盲区，有效的自我分析和分析其他测试人员，你会发现自己的盲区，有针对性的分析盲区，必定会在下一轮测试用避免盲区。

　　总结：

　　限于文章的篇幅，本文不可能给出一个类似于 checklist 的指导性的软件测试新手入门。无论从事软件测试还是从事其它的工作，技术上的和技巧上的问题都可以通过查询相关的软件测试技术书籍获取，掌握一套基本的方法论是最重要的。以上文字，都是作者从事软件测试工作积累的经验之谈，如发现谬误之处请不吝指出。

　测试用例设计

　　测试需求收集完毕后，开始测试设计。测试用例是什么？测试用例就是一个文档，描述输入、动作、或者时间和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作。设计测试用例需要考虑以下问题：

　　测试用例的基本格式

　　软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果，下面逐一介绍。

　　用例编号： 测试用例的编号有一定的规则，比如系统测试用例的编号这样定义规则： PROJECT1-ST-001 ，命名规则是项目名称＋测试阶段类型（系统测试阶段）＋编号。定义测试用例编号，便于查找测试用例，便于测试用例的跟踪。

　　测试标题： 对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。比如 “ 测试用户登录时输入错误密码时，软件的响应情况 ” 。

　　重要级别： 定义测试用例的优先级别，可以笼统的分为 “ 高 ” 和 “ 低 ” 两个级别。一般来说，如果软件需求的优先级为 “ 高 ” ，那么针对该需求的测试用例优先级也为 “ 高 ” ；反之亦然，

　　测试输入： 提供测试执行中的各种输入条件。根据需求中的输入条件，确定测试用例的输入。测试用例的输入对软件需求当中的输入有很大的依赖性，如果软件需求中没有很好的定义需求的输入，那么测试用例设计中会遇到很大的障碍。

　　操作步骤： 提供测试执行过程的步骤。对于复杂的测试用例，测试用例的输入需要分为几个步骤完成，这部分内容在操作步骤中详细列出。

　　预期结果： 提供测试执行的预期结果，预期结果应该根据软件需求中的输出得出。如果在实际测试过程中，得到的实际测试结果与预期结果不符，那么测试不通过；反之则测试通过。

　　软件测试用例的设计主要从上述 6 个域考虑，结合相应的软件需求文档，在掌握一定测试用例设计方法的基础上，可以设计出比较全面、合理的测试用例。具体的测试用例设计方法可以参见相关的测试书籍，白盒测试方法和黑盒测试方法在绝大多数的软件测试书籍中都有详细的介绍，这里不作赘述。

　　重用同类型项目的测试用例

　　如果我看得远，那是因为我站在巨人的肩上 －－牛顿。

　　一般来说，每个软件公司的项目可以分为固定的几大类。可以按业务类型划分，比如 ERP 软件、产品数据管理软件、通信软件、地理信息系统软件等等；可以按软件结构来划分，比如 B/S 架构的软件、 C/S 架构的软件、嵌入式软件等等。参考同类别软件的测试用例，会有很大的借鉴意义。如果，公司中有同类别的软件系统，千万别忘记把相关的测试用例拿来参考。如果，系统非常接近，甚至经过对测试用例简单修改就可以应用到当前被测试的软件。 “ 拿来主义 ” 可以极大的开阔测试用例设计思路，也可以节省大量的测试用例设计时间。

　　利用已有的软件 Checklist

　　在上面一个小节中，按照不同的规则划分了不同的软件类型。每种类型的软件都有一定的测试规范，比如， Web 软件系统在系统测试过程中，会有一系列的范式，比如针对 Cookie 就会有很多测试点。在设计测试用例的时候，不妨到网上去搜索相关的 Checklist ，不过国内外的网站很少有这方面的资料，即便有，也不是特别系统。可以先找一份粗糙的 Checklist ，然后，在设计测试用例的时候不断的去完善它，以作为下次测试用例设计的基础。

　　加强测试用例的评审

　　测试用例设计完毕后，最好能够增加评审过程。同行评审是 CMM3 级的一个 KPA ，如果因为公司没有通过 CMM3 级，就不开展同行评审是不恰当的。测试用例应该由产品相关的软件测试人员和软件开发人员评审，提交评审意见，然后根据评审意见更新测试用例。 如果认真操作这个环节，测试用例中的很多问题都会暴露出来，比如用例设计错误、用例设计遗漏、用例设计冗余、用例设计不充分等等；如果同行评审不充分，那么，在测试执行的过程中，上述本应在评审阶段发现的测试用例相关问题，会给测试执行带来大麻烦，甚至导致测试执行挂起。

　　定义测试用例的执行顺序

　　在测试用例执行过程中，你会发现每个测试用例都对测试环境有特殊的要求，或者对测试环境有特殊的影响。因此，定义测试用例的执行顺序，对测试的执行效率影响非常大。比如某些异常测试用例会导致服务器频繁重新启动，服务器的每次重新启动都会消耗大量的时间，导致这部分测试用例执行也消耗很多的时间。那么在编排测试用例执行顺序的时候，应该考虑把这部分测试用例放在最后执行，如果在测试进度很紧张的情况下，如果优先执行这部分消耗时间的异常测试用例，那么在测试执行时间过了大半的时候，测试用例执行的进度依然是缓慢的，这会影响到测试人员的心情，进而导致匆忙地测试后面的测试用例，这样测试用例的漏测、误测就不可避免，严重影响了软件测试效果和进度。因而，合理地定义测试用例的执行顺序是很有必要的。

　　测试用例执行

　　测试用例设计完毕后，接下来的工作是测试执行，测试执行中应该注意以下几个问题：

　　搭建软件测试环境，执行测试用例

　　测试用例执行过程中，搭建测试环境是第一步。一般来说，软件产品提交测试后，开发人员应该提交一份产品安装指导书，在指导书中详细指明软件产品运行的软硬件环境，比如要求操作系统系统是 Windows 2000 pack4 版本，数据库是 SQL Server 2000 等等，此外，应该给出被测试软件产品的详细安装指导书，包括安装的操作步骤、相关配置文件的配置方法等等。对于复杂的软件产品，尤其是软件项目，如果没有安装指导书作为参考，在搭建测试环境过程中会遇到种种问题。

　　如果开发人员拒绝提供相关的安装指导书，搭建测试中遇到问题的时候，测试人员可以要求开发人员协助，这时候，一定要把开发人员解决问题的方法记录下来，避免同样的问题再次请教开发人员，这样会招致开发人员的反感，也降低了开发人员对测试人员的认可程度。

 本文面向软件测试新手，从测试前的准备工作、测试需求收集、测试用例设计、测试用例执行、测试结果分析几个方面给出建议和方法。鉴于国内的软件开发、测试不规范的现状，本文为软件测试新手提供了若干个软件测试的关注点。

　　【关键词】软件测试、测试用例、测试需求、测试结果分析

　　引言

　　几年前，从学校毕业后，第一份工作就是软件测试。那时候，国内的软件企业大多对软件测试还没有什么概念，书店里除了郑人杰编写的《计算机软件测试技术》之外，几乎没有其它的软件测试相关书籍，软件测试仅仅在软件工程的教材中作为一个章节列出来，因此，我对软件测试一无所知。不过，在正式走上工作岗位之前，公司提供了为期两周的系统的软件测试技术专题培训，对接下来的软件测试工作有很大的指导意义。现在，我继续从事软件测试的培训与咨询服务，在这个过程中，亲眼目睹了很多软件测试新手面对的困惑，他们初涉软件测试行业，没有接受系统的培训，对软件测试一无所知，既不知道该测试什么，也不知道如何开始测试。下面针对上述情况，给出若干解决办法。

　　测试准备工作

　　在测试工作伊始，软件测试工程师应该搞清楚软件测试工作的目的是什么。如果你把这个问题提给项目经理，他往往会这样回答： “ 发现我们产品里面的所有 BUG ，这就是你的工作目的 ” 。作为一名软件测试新手，如何才能发现所有的 BUG ？如何开始测试工作？即便面对的是一个很小的软件项目，测试需要考虑的问题也是方方面面的，包括硬件环境、操作系统、产品的软件配置环境、产品相关的业务流程、用户的并发容量等等。该从何处下手呢？

　　向有经验的测试人员学习

　　如果你进入的是一家运作规范的软件公司，有独立的软件测试部门、规范的软件测试流程、软件测试技术有一定的积累，那么，恭喜你！你可以请求测试经理委派有经验的测试人员作为你工作上的业务导师，由他列出软件测试技术相关书籍目录、软件测试流程相关文档目录、产品业务相关的文档目录，在业务导师的指导下逐步熟悉软件测试的相关工作。其实，在很多运作规范的软件公司，已经把上述的师父带徒弟的方式固化到流程中。

　　如果你进入的是一个软件测试一片空白的软件企业，那么，也恭喜你！你可以在这里开创一片自己的软件测试事业，当然，前提是老板确实认识到软件测试的重要性，实实在在需要提高产品的质量。这时候，可以到国内的软件测试论坛和相关网站上寻找软件测试资源，这种情况下，自学能力和对技术的悟性就至关重要了。

　　阅读软件测试的相关书籍

　　现在，中文版的软件测试书籍越来越多，有的是国人自己写的，有的是翻译国外经典之作。可以到 www.chinapub.com 或者 www.cnforyou.com 等网络购书的站点查找软件测试相关的书籍。目前，从国外引入的软件测试书籍有很多经典之作，但是，翻译成中文后，翻译质量对阅读效果有很大的影响。

　　走读缺陷跟踪库中的问题报告单

　　如果您所在的公司已经有软件缺陷跟踪库了，无论采用的是商用工具，如 Clear Quest 、 TestDirecter 等工具，还是采用的 Bugzilla 、 Mantis 等开源工具，这都无关紧要，缺陷跟踪库中的缺陷报告单才是有价值的。缺陷跟踪库中的问题报告单是软件测试工程师工作绩效的集中体现，同时也是软件产品问题的集中体现。一般来说，缺陷报告单中最关键的几个部分包括：第一部分是发现缺陷的环境，包括软件环境、硬件环境等；第二部分是缺陷的基本描述；第三部分是开发人员对缺陷的解决方法。通过对上述缺陷报告单的三个部分作仔细分析，不知不觉你已经吸收了其他软件测试人员的工作经验，并掌握了软件产品常见的基本问题。这是迅速提高软件测试经验的好方法。

　　走读相关产品的历史测试用例

　　如果你所在的公司有测试用例管理系统，那么，走读相关产品的软件测试用例是迅速提高测试用例设计水平的一条捷径。走读测试用例也是有技巧的。测试用例写作一般会包括测试用例项和根据测试用例项细化的测试用例，下面举例说明。 “ 测试用户登录的功能 ” 是一个测试项，该测试项的目的是测试用户登录功能是否正确，是否能够完成正常的登录功能，是否能够对非法用户名和密码做异常处理等等。因此，根据该用例项，可以设计出若干个测试用例，大多数情况下，测试用例项和测试用例是一对多的关系。

　　通过走读测试用例项目，你可以掌握应该从哪些功能点着手未来的测试工作；通过走读软件测试用例，你可以了解如何根据被测试的功能点开展软件测试用例的设计工作，包括如何确定测试用例的输入、测试用例的操作步骤和测试用例的输出结果等。

　　总之，走读其他软件测试人员设计的优秀软件测试用例，是提高自身用例设计水平的好方法。

　　学习产品相关的业务知识

　　软件测试人员不仅要掌握软件测试技术相关知识，对产品相关的业务知识也要学习。这很好理解，如果从事财务软件的测试工作，一定要学习财务知识；如果从事通讯产品测试工作，那么相关的通讯理论知识也是必须的；如果从事银行软件的测试，银行的业务流程也是不可或缺的知识点。

　　因此，在学习软件测试技术的同时，千万不要忽略产品相关业务知识的学习。如果你是一个软件测试技术专家，但是对产品业务知识一无所知，那么也只能测试出来纯粹的软件缺陷，而面对眼前出现的产品业务相关的缺陷，很可能是视而不见，如此这般，软件测试的效果会大打折扣。

　　识别测试需求

　　识别测试需求是软件测试的第一步。如果开发人员能够提供完整的需求文档和接口文档，那固然好。可以根据需求文档中描述的每个功能项目的输入、处理过程和输出，来设计测试用例。如果开发人员没有提供软件需求文档，那该如何是好？下面给出几个有效的方法：

　　主动获取需求

　　开发人员通常不会更好地考虑软件测试，如果没有开发流程的强制规定，他们通常是不愿意提供任何开发文档，即便有强制规定，需求文档也未必能够真正指导软件系统测试工作。因此，需要测试人员发挥主观能动性，与相关的软件开发项目经理和软件开发人员保持沟通，了解软件实现的主要功能是什么，并记录得收集到的信息。一般来说，开发人员即便没有提供相关需求文档，也会保存一些简单的过程文档，主动向开发人员索要这些文档，可以作为测试的参考。此外，可以与公司的技术支持人员交流，技术支持人员是最贴近用户的人，因此，通过交流可以获取第一手的用户使用感受，在测试的过程中会更加贴近用户。

　　当拿到相关的资料后，从哪些方面分析需求？如何与开发人员交流需求？其实，只要把握需求分析的几个关键的点就可以解决问题：输入、处理过程、输出、性能要求、运行环境，下面针对每一个项目逐一分析：

　　软件输入： 与该需求相关的一切可能输入，可以从这几方面考虑，输入来源、输入参数的数量、输入参数的度量单位、输入参数的时间要求、输入参数的精度和输入参数的有效输入范围。在测试用例设计中，这部分内容作为测试用例输入的依据。

　　处理过程： 描述对输入数据所执行的所有操作和如何获得输出的过程。测试人员了解处理过程即可，在测试过程中发现 BUG 时候，如果对处理过程了解的深入，对定位问题根源有很大的帮助。

　　软件输出： 描述每个需求的输出结果，包括输出的位置（如计算机显示器、打印机，文件），输出参数的数量、输出参数的度量单位、输出参数的时序、输出参数精确度、输出参数的有效输出范围、错误消息。在测试用例设计中，这部分内容作为测试用例的预期输出。

　　性能要求： 与该需求相关的性能要求，比如 “ 插入 ATM 取款卡后， 3 秒钟内弹出提示用户取款的图形界面 ” 。 3 秒钟这一限制，就是对需求的基本性能要求。

　　运行环境： 软件的运行所需的环境，包括硬件平台的要求、操作系统的要求、数据库的要求，以及其它相关支撑软件的要求。

　　确认需求的优先级

　　确认需求的优先级是很必要的，如果在产品进度比较紧的情况下，测试人员可以考虑优先测试优先级高的需求项，如果进度允许，那么在测试优先级低的需求项，如果进度不允许，那么就放弃测试优先级低的需求项。如果软件公司有规范的流程支撑，开发人员在提供软件需求文档的时候，应该在文档中确定需求的优先级。但是，如果开发人员连基本的软件需求文档都没有提供，又怎能指望他们确定软件需求的优先级？如果是这样，需求的优先级只能由测试人员完成了。

　　加入开发小组的邮件群组

　　测试人员需要通晓被测试产品，但是，产品在开发的过程中往往是不断变化的。如果软件开发团队有一套变更控制流程，测试人员会对产品的变更了如指掌。如果没有变更控制，那就要采用其他的土方法了。如果公司里面有自动化办公系统，也许采用的是 Lotus Notes 系统，也许使用的是 E-mail 系统，测试人员应该加入到开发人员的邮件群组中。当开发人员通过邮件讨论问题、通知召开技术会议的时候，测试人员可以及时知晓，如果必要，可以参加开发人员的技术会议。即便公司里面有了软件变更控制流程，加入到开发邮件群组也是一个很好的习惯。

　　与开发人员为邻

　　建议测试人员与开发人员为邻。我所在的测试组曾经与开发组是在相邻的写字间里，开发人员与测试人员的关系非常融洽，抛去同事关系，大家还是不错的朋友。不管开发人员有什么样的活动，测试人员都能第一时间获得信息。无论从事软件测试工作，还是从事其它的工作，与工作中上下游环节的同事保持良好的个人关系对工作有很大便利。一般的公司内部都存在部门墙，良好的人际关系是打通部门墙的手段之一。向领导建议测试人员与开发人员为邻，这很必要。

开头语：

        做测试很久了，一直为一些问题所困扰，也一直对微软有一种顶礼膜拜的向往，终于有一天，近距离的接触了微软的测试，感觉不是以前想象中那么遥不可及，却又难以企及。于是把个人觉得微软值得借鉴的地方整理了一下，希望能对大家有所帮助。

1． 软件测试流程

          首先说说软件测试流程，微软的软件测试流程也没什么新的东西，和大多数的软件测试流程一样。

          大致是先进行测试准备，然后是Testcase的编写，然后是白盒测试（不一定每个项目都有），然后是功能测试阶段，然后是验收测试，最终 release。

          如果看流程的话，和一般公司大同小异，没什么新花样。但是我觉得值得借鉴的是两点。

第一， 微软的流程执行的非常认真。

          这点非常值得提倡，我们都知道，测试的最终质量决定于软件测试流程和测试人员素质，要想测试质量有保证，要么是流程很完善，要么你流程不行，但是个人能力超强。如果有一个很好的流程，就算执行的人稍微差点，最终的质量也不会差到哪里去。所以流程是很重要的。

          但是，看国内的公司欠缺的就是这个，要么是没有流程，要么流程是个花架子，没认真执行过。我想微软的测试人都是超级牛人，但是人家还是老老实实的忠实按照流程来走，我觉得这点非常好。（在IBM 也是这样，笔者以前在IBM作项目的时候，发现他们的文档写的特认真，流程特认真），所以说忠实的执行一个好的流程是成功的一大半。

  第二， 在整个流程中，微软非常强调测试尽早介入。

        微软在这方面是一致提倡的，按照我们国内IT业的恶习，一般都是软件主体差不多成型了，拉几个测试人员过来点点，其实这是非常不好的。微软的测试人员在项目一开始就和开发人员同步介入，在需求阶段就开始介入，进行需求评审。在开发人员开始编码的时候，测试人员就开始编写Test case，并开发一些测试工具，或者写一些配套的测试代码（不要奇怪，微软的测试人员都能写很好的代码）。微软的理念就是：预防bug比解决bug好，所以非常提倡测试尽早介入，把一部分bug消灭在需求阶段。

2． 自动化流程

          说到自动化，大家可能以为我是说微软的自动化测试工具多牛，其实微软内部用到的自动化测试工具倒是不多，就算有也都是内部开发的，非常实用的，他们不会去用MI的工具。

          说微软的自动化程度高，主要是体现在流程方面，譬如说整个自动构建流程，在开发人员代码check in之后，系统自动发邮件，邮件内容就是一个change list，包括代码更新list以及一个编译者添加的comment，其内容是该版本功能的变化或者修改掉的bug ID。整个测试过程中能用自动化的地方都尽可能采用自动化，尽可能减少人为失误，并且可以使人和机器并行工作。个人觉得，这点很值得我们国内的测试公司借鉴，能自动化的流程都自动化，减少一些不必要的沟通。

版权声明：51Testing软件测试网及相关内容提供者拥有 51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像。51testing软件测试网欢迎与业内同行进行有益的合作和交流，如果有任何有关内容方面的合作事宜，请联系我们。

 发布时间: 2008-5-14 16:30    作者: godn_1981    来源: 51Testing投稿