软件测试，作为提升产业竞争力的核心，也是软件产业发展的关键。为了使大家更详细的了解2009年软件测试从业人员现状，从而帮助大家更清晰的认识、定位自我，规划职业发展，迎接更多的挑战，51Testing于即日起发起2009年第三届中国软件测试从业人员调查活动。

本次调查继续从软件测试从业人员角度出发，在2007、2008两届调查活动的基础上，吸取经验、改正不足，对问卷进行了更多的修改和完善，做到更加专业、严谨、客观、实用。

欢迎广大测试从业人员参与，共同打造中国软件测试领域最具广泛性、权威性和实用性的产业调查。

本调查不带任何商业性质，纯属研究活动。51Testing将会根据调查所得数据撰写、发布调查报告。

调查名称：中国软件测试从业人员调查

调查时间：即日起至2010年4月30日止

调查对象：现职为软件测试从业人员

点击开始填写问卷>>

×××项目是我在××公司的第一个软件测试项目，也是第一次直接管理业务人员进行软件测试工作。以前只是组织管理过外包测试人员和实施人员进行过软件测试工作。通过回顾工作中遇到和解决的各种问题，觉得还是有许多经验需要总结。

一、 管理业务人员进行软件测试与以前管理外包测试人员和实施人员的不同。

以往管理外包测试人员时，相应人员已经进行过测试理论及方法，测试流程等测试相关方面比较系统全面的培训，有比较强的测试理念。而实施人员则是带着工作中的各种问题，包括需求问题、易用性问题等等在产品中进行验证。对产品的其他功能关心极少。

现在业务人员就是测试的主要力量，其依据项目测试经理编写的测试大纲和测试案例进行测试，是测试的主体。而且大部分业务人员在参与项目之前从来没有从事过任何测试相关工作。不明白什么叫做测试，测试工作都包括那些范畴，就更不论什么测试方法和测试流程了。所以此时就对测试经理提出了较高的要求。不仅要通过编写全面的测试大纲和测试案例保证产品质量，还需要对管理业务人员的测试进程，及时发现和解决各种问题。保证测试方向不发生偏差，保证所有案例都能得到顺利、有效的执行。

二、 项目过程中发生的各种与业务人员相关的问题及经验教训。

1、 案例编写不够清晰，造成部分案例业务人员执行不顺畅。

一些案例在编写时是按照以前自己写案例，自己使用的情况编写的，一些数据准备及操作步骤没有描述清楚，造成业务人员在执行案例时的困惑，影响了业务人员执行案例的速度。因此，今后在编写案例时，要以他人能正常使用为目标。尽量将案例描述清楚，没有歧义。

而且一些案例是根据评审后需求编写的，但产品在实现过程中又进行了修改，而未通知测试人员，造成案例与产品实现不符。造成部分案例无法执行，或执行结果与预期结果差异较大。这些问题也造成了业务人员的困惑。应该在测试实施前就与业务人员将清楚，由于各种原因，案例并不能100％吻合现在产品实现的情况。需要边测试边与相关人员进行沟通，部分案例还需要在测试过程中进一步进行修改。

本文转载自51Testing软件测试网（查看全文）：http://www.51testing.com/html/06/n-198506.html

软件测试工程师作为软件质量的把关者，其职能在于保证交付到客户手中的软件可靠好用，运行畅通无阻。从产品定义到产品开发再到产品维护，都离不了软件测试。

按其级别和职位的不同，可分为三类，即：

高级软件测试工程师，熟练掌握软件测试与开发技术，且对所测试软件对口行业非常了解，能够对可能出现的问题进行分析评估；

中级软件测试工程师，编写软件测试方案、测试文档，与项目组一起制定软件测试阶段的工作计划，能够在项目运行中合理利用软件测试工具完成测试任务；

初级软件测试工程师，其工作通常都是按照软件测试方案和流程对产品进行功能测验，检察产品是否有缺陷。

工作职责

软件测试就是使用人工或自动手段，来运行或测试某个系统的过程。其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。开发工作的根本是尽量实现软件用户的需求，测试工作的根本是检验软件系统是否满足软件用户的需求。

软件测试工程师简单的说是软件开发过程中的质量检测者和保障者，负责软件质量的把关工作。软件测试工程师具体工作有：

1 、使用各种软件测试技术和方法来测试和发现软件中存在的软件缺陷。测试技术主要分为黑盒测试和白盒测试两大类。其中黑盒测试技术主要有等价类划分法、边界值法、因果图法、状态图法、测试大纲法以及各类典型的软件故障模型等；白盒测试的主要技术有语句覆盖、分支覆盖、判定覆盖、基本路径覆盖等；

2 、测试工作需要贯穿整个软件开发生命周期。完整的软件测试工作包括单元测试、集成测试、确认测试和系统测试工作。单元测试工作主要在编码阶段完成，由开发人员和软件测试工程师共同完成，其主要依据是详细测试。集成测试的主要工作测试软件模块之间的接口是否正确实现，基本依据是软件体系结构设计。确认测试和系统测试是在软件开发完成后，验证软件的功能与需求的一致性、验证软件在相应的硬件条件下的系统功能是否满足用户需求，其主要依据是用户需求。

3 、测试人员将发现的缺陷编写成正式的缺陷报告，提交给开发人员进行缺陷的确认和修复。缺陷报告编写最主要的要求是保证缺陷的重现。要求测试人员具有很好的文字表达能力和语言组织能力。

4 、测试人员需要分析软件质量。在测试完成后，测试人员需要根据测试结果来分析软件质量，包括缺陷率、缺陷分布、缺陷修复趋势等。给出软件各种质量特性包括有功能性、可靠性、易用性、安全性、时间与资源特性等的具体度量。最后给出一个软件是否可以发布或提交用户使用的结论。

5 、测试过程中，为了更好地组织与实施测试工作，测试负责人需要制定测试计划，包括有测试资源、测试进度、测试策略、测试方法、测试工具、测试风险等。

本文转载自51Testing软件测试网（查看全文）：http://www.51testing.com/html/33/n-205933.html

软件测试报告作为对测试工作和项目情况的总结，对测试成果的体现，有着很重要的意义。通常来讲，我们会在软件测试过程中，由测试经理定期写工作汇报给上级，在测试结束后，写一份包罗万象的软件测试报告，然后发给上级、成员、或者客户。这是普遍的做法，但经过这几年的总结，我开始根据不同的对象，写不同的报告。

主要是因为不同的对象，关注不同的事务。如果一股脑的把所有的内容都揉合在一份文档里，文档内容过长，试问哪个阅读者有耐心去读完？曾经把文档的结构做过调整，按阅读者进行了结构的调整，但是问题还是来了，一是，遇到挑剔的上层，他们会认为你发的东西还是过于冗余，太多他不关心的东西，那么你的工作就做的不好。二是，在软件测试报告中，难免会有一些不适合发给客户的内容。其他还有很多情况，让一份包罗万象的软件测试报告被万般挑剔。

总体来说，报告的对象大致分为3类：

项目管理阶层、项目组开发测试人员、客户或其他的预期读者

对于不同的读者，在不同的阶段，侧重点的大概内容如下（这里只说开发结束后的软件测试报告部分，也只提一个框架，具体的大家自己根据公司实际情况去填充。

本文转载自51Testing软件测试网（查看全文）：http://www.51testing.com/html/02/n-201402.html

    这是2010年的第一个月，《51测试天地》再次与您见面。

    在所有同行朋友们的关注和支持下，《51测试天地》和大家共同走过了2009，迎来2010。

在新的一年里，《51测试天地》这个软件测试人学习和交流的平台将继续伴随大家前行。也热切希望更多的朋友来投稿，反馈您的建议和意见，希望汇聚更多人的力量，将这个平台打造的更好、更专业，能够帮助更多的软件测试同行们在职业发展的道路上，不断提高，不断进步！

    2010，新的起点，新的征程，新的精彩，让我们共同拭目以待！

测试架构支撑商业成功

    什么是软件测试架构？商业成功的关键是什么？软件测试仅仅是找bug吗？经过多年商业环境中测试工作的经验和实践，我将在本文分享心中的--测试架构支撑商业成功。

首先，请大家看图一，后续的内容将是对图一的一个全面阐述，告诉大家测试架构，测试活动的执行对商业成功的价值和意义。

............................

部分目录：

● 测试架构支撑商业成功（第一部分）..........................4

● IE对象模型结合HTML DOM的WEB自动化测试.......11

● 利用交叉测试提升软件测试效率...............................23

● C单元测试框架.............................................................29

● 面向对象的测试用例设计思想....................................50

● RDP协议介绍...............................................................54

● Toad Data Modeler使用说明.....................................57

● 如何做好SAP自动化测试............................................69

下载地址：http://www.51testing.com/html/28/n-205128.html

继续本章开头所阐述的问题“在软件测试中心理因素占有重要的位置”，通过对心理学的了解，我们能够找出软件测试中重要的原则或者称为重要的指导方针。这些原则大部分都是浅显易懂，但在实际工作当中却很容易被忽视。表2.1概括了一些重要的软件测试原则，在下面的章节中将详细阐述。

法则1：定义预期输出或结果，是软件测试用例的重要组成部分

这个显而易面的原则是软件测试中最容易忽略的问题之一，当然，这个它也涉及了心理学的一些基础知识。如果一个运行结果在测试用例没有明确定义，它看起来很合理，实际上却是错误的，结果软件测试员将它当作了程序的正确运行结果，这个现象叫“希望即所见”。换句话说，就是尽管这个结果是不正确的，但软件测试员的潜意识里希望它是正确的，那么就将主观的肯定了它的正确性。避免这个现象产生的方法就是在测试用例中列出所有的预期结果，因此，软件测试用例必须由以下两个部分组成：

1. 描述程序的输入数据

2. 精确的描述出每个输入数据所对应的正确输出结果

如果问题的定性没有明确的解释，这看起来似乎很不寻常，或者不符合我们预期的目标，这将很难做出正确的判断。所以我们要事先确定程序的正确运行结果，来明确软件测试目标。如果没有期望，就没有惊喜。

法则2：软件工程师应该尽量避免测试自己编写的程序

任何作家都知道或应该知道，校对自己的作品是个坏主意。尽管作者很了解文章中哪个部分是应该加入的，哪个部分是多余的，但是在潜意识里却希望自己的作品找不出任何破绽。这个道理同样适用于软件开发人员。

软件工程师测试自己所编写的代码的第一个难点在于，在项目中所负担的工作职责突然发生转变，完成由编码到测试的角色转变将很困难，软件工程师如果去承担测试员这一角色，那么就必须打破在编码时所肩负的职责，背弃原有的工作思路，这将会需要相当长的时间或者这种转变根本不可能成功。

正如多数的房屋所有者都知道重新粘贴墙纸（一个破坏的过程）不是件容易的事情，最困难的环节就是动手去贴第一张墙纸并且贴正它。同样的道理，多数软件工程师不能对自己编写的代码进行有效的测试，因为从创造者的角度来看，每个人都不希望自己的作品中存在瑕疵。另外，软件工程师有可能会出于害怕上司的批评影响经后的工作而下意识的逃避错误，但是客户、软件购买者却不存在这样的担心，所以他们发现的问题要比软件工程师自己测试后发现的问题更多。

如果再增加一些心理因素，就会引出第二个难点：如果软件工程师在编写代码的声明的部分时犯了错误，或是错误的理解了软件的需求，那么在测试自己编写的代码的过程中，这些错误的观念可能仍会存在，那么这种测试将会毫无意义，因为软件工程师找不出自己究竟犯了哪些错误。

这并不意味着软件工程师一定不能胜任测试自己编写的代码，只是说如果让另一个人来完成测试的工作，软件测试的有效性和成功性将会大大提高。

对已知问题的争论远不如调试一次更为有效，调试代码是软件工程师测试代码质量的最有效也是有原始的一个步骤。

本文转载自51Testing软件测试网（查看全文）：http://www.51testing.com/html/25/n-205525.html

     经历了几个项目，对测试环境对软件测试的影响深有感受。一个良好的软件测试环境对软件测试人员进行测试是个很好的保障，提高软件测试效率，也是对项目质量的一种保障。同时软件测试环境适合与否会严重影响软件测试结果的真实性和正确性。

    在设计软件测试环境阶段根据客户的需求进行环境设计，当然期望测试环境无限接近于客户所需软件运行的真实环境，这样能够测试出真实环境中的所有问题，同时也需要理想环境以便找出问题的真正原因。但实际上由于各种资源的限制，只能在近似的模拟环境中进行测试。

    相反理想环境有利于代码的调试和分析，但测试结果就无法视为真实结果。

    软件测试环境可以说是测试的基础，它贯穿了测试的各个阶段，每个测试阶段中测试环境对测试影响是不一样的。

    在最初环境的设定，比如版本情况，在错误的版本下测试就可能是得出完全错误结果，发现很多无效BUG，这些白费徒劳的工作可能就会导致真正环境的测试延期，最后导致项目延期。在中途测试环境的宕机，就可能造成测试无法执行。 有时候测试环境无法实现的情况就需要测试人员手工配置，修改系统设置，这样可能会忽略了实际使用可能会出现的BUG，所以这样也不是很合理。

    所以在软件测试工程中，测试人员需要记录好这些环境版本不同而造成的BUG；环境是由于什么原因宕机，以及宕机的时间，及影响测试的功能块；无法模拟的测试环境，也都需要记录，项目上线后，出现问题这也是一种有源可循。这些都可提供PM，PD，TL来评估这些的风险对项目的影响，以及上线后会带来的影响，也便于开发进行问题排查。

    一套稳定良好的软件测试环境，并不只依赖于环境配置人员，需要大家一起配合，将环境因素对项目的影响降到最小。

本文转载自51Testing软件测试网：http://www.51testing.com/html/29/n-205529.html

很早之前买了一本《软件测试经典教程》，总体感觉这本书对软件测试的主要理论介绍得很不错，软件测试的基本概念，测试分类，测试的常识，测试技术，缺陷管理，测试管理，软件测试工具都涵盖到了，是一本综合性的书，有助于测试人员对软件测试有一个整体全方位的了解。本书给我体会最深的就是软件测试的一些基本原则，让我们如何做好测试有一个不错的参考依据：

1.Zero Bug与Good Enough：本条给我们灌输的是一种测试执行通过的标准。显示任何测试通过不可能达到0 bug。那我们就应该达到Good Enough。这条原则是一种权衡投入/产出比的原则：测试既不能不充分也能过，我们需要制定测试通过标准和测试内容，比如：遗留的bug数&严重程度，测试用例的执行率&通过率等来解决上面的问题。

2.不要试图穷举测试：本条需要我们明白一件事，测试是需要考虑测试方法和技术（等价类/因果图/边界值）的，通过这些方法来提升测试的效率又保证产品的质量。

3.软件测试要尽早执行：本条主要想说明一个道理：测试需要贯穿整个软件的生命周期，缺陷修复成本随着各个阶段的靠后而上升。从平时的项目中也已经看出，需求阶段引入的bug不比设计开发阶段少，如何保证好需求的稳定有效已经至关重要。

本文转载自51Testing软件测试网（查看全文）：http://www.51testing.com/html/67/n-116067.html

工作了一段时间了，觉得软件测试工作中的实际流程和书上所说的多多少少有些不一样，下面就先说说我的软件测试流程吧。

一般我的工作都是开发后期参与的，这点是明显不对的，按理说，软件测试应该在项目启动的初期，就应该介入。不过我们的项目功能都是有开发人员决定的，开发人员做好的功能拿给客户使用，客户满意了就可以，当然大多数客户还是会提出他们自己的观点的，比如说：界面不够完美，菜单显示不合理，还应该添加哪些功能等等，双方互相沟通之后，开发人员再作相应的修改。我作为软件测试人员，在收到测试任务后，要和开发人员进行交流，了解需求，简单记录下需求要点，下面就是根据需求开始编写测试用例，测试用例也不是每次都要重新写的，都是按照以前的用例稍微改动一下，使之符合当前项目即可，这样就省事多了，最后就是按照用例开始进入测试了，我们的测试都是手工测试，其实我很想使用自动化测试，但是一直没有找到适合我们的软件测试工具，也苦于自己是个新手，不会开发测试工具，也只能一直采用手工测试了。测试过程中我也可以向开发人员提出我自己的建议，供他们参考，如果有必要他们也会采取我的意见的，这点我觉得很好，毕竟大家都是为了保证产品的质量嘛。一轮测试下来，buglist也就有了，buglist是按时提交的，开发人员验证并修改bug，接下来我的任务就是跟踪bug了，监督开发人员修改bug的情况。开发人员修改完后，将修改的结果显示在buglist中，再反馈给我，并发布新的版本，接下来就是验证bug了，如果有标注“不是bug”的bug，就要及时和开发人员讨论，最终确定是不是bug，修改成功的bug有open改为closed，仍然存在的bug，仍然是open状态，将验证后的buglist再次提交，修改。

我们的项目测试任务也不是我一个人完成的，客户那边也会测试，他们会将测试发现的bug反馈给我们的开发人员，开发人员会将bug转发给我来验证一下 bug是否存在并可以重现，也有些bug在我们这边是不能重现的，这就需要和客户讨论了，可能两边的版本、环境或者硬件不一样，这都有可能的。

本文转载自51Testing软件测试网（查看全文）：http://www.51testing.com/html/57/n-98757.html