看了51testing上一位老兄写的《软件测试新手的感受》，有些感触，他干软件测试的时间不长---半年时间，写的文章却很好，很有想法，主题就是将自己半年来学到的关于软件测试的东西整理了一下，写出了自己的想法，既提高了自己，也给别人做了借鉴，挺好。

自己干软件测试也有半年时间了，测试的软件前前后后也有几个，包括的框架种类也各不相同，因此学习的东西也杂七杂八，可惜的是自己一直也没有一个清晰的思路，大海捞针似的学，稀里糊涂的干。因为是半路出家，没有老师具体指导，只能自学，边摸索，边干活，很有些累。

虽然一如继往地写读书笔记，笔墨也浪费了不少。但真正坐下来利用大段的时间将自己的思路理清还没有过。因为最近有了一定的时间，更因为狠狠地泡了一段时间51Testing软件测试论坛，下载学习了该网站的电子测试杂志之后，自己的思路终于开始清晰起来，朦朦胧胧地开始看清了远方的路，麻着胆子去分析一下自己，也学着展望一下未来了，毕竟摸黑走路的感觉很不好。

一直以为：学习的最好的辅助方法是写心得体会。尝试着将自己学到、想到\做到\尝试的东西归纳一下，写出来，对自己都会有好处，如果能给别人当个借鉴那会更好。在学习的过程中，歇一歇，写一写，抬头看看路，不会浪费太多的时间，不是有那句老话“磨刀不误砍柴工”。下面我就来总结一下前一阶段的学习和工作，就算磨第一刀吧。

先来作一下自我分析：目前拥有的计算机知识多不是在学校里学的（转行），通过几年的工作和学习对windows，unix，linux等操作系统有了一定的了解，但不系统，应付日常的工作当然没有问题，但是如果要更深入一点，尤其是如果是搞测试我想需要的知识会比较多，那点本钱根本不够，还需要大大的提高。

编程，接触了一点点。主要还是在学校里学习到的，但那是很久以前的事情了，大部分的内容多已经还给了老师。前不久刚刚学习了一下c#，还不错比较新鲜，可以借用，但是实际操作经验比较少。幸好本人还没有老化到不愿意学习的地步，每天学习一点，相信不久的将来自己还会有很大的提高，呵呵，写写网络日记也可以给自己一个督促。

本文转载自51Testing软件测试网（查看全文）：http://www.51testing.com/?203341/action_viewspace_itemid_93828.html

1、 软件测试计划和实际情况的偏差过大

在项目开发中，这个问题并不是我们软件测试管理个别问题，几乎每个项目的计划都和实际存在偏差，而对于这个问题，很多的软件测试团队都是采用滚动式计划方式，及时根据环境条件和实际完成情况定期或者临时的来进行小范围的调整计划，对于大范围的计划变更，即软件测试管理团队无法解决的，应该上报风险；

2、 软件测试策略的制定没有达到其效果

在说明其问题之前，我们先清楚一下几个名词的概念：软件测试方案，软件测试策略和软件测试用例。

软件测试方案是对测试工作上的总体描述，测试方案我个人认为是测试的系统架构；

软件测试策略可以分为粗放型和精细型，我个人任务粗放型的测试策略可以相当于概要设计，而精细型的测试策略可以相当于详细设计；

软件测试用例比较好理解，这个相当于程序代码了；

所以说我们在进行测试策略的设计时，我们的目标是什么，是详设还是概设？当我们定下目标后，我们就非常清楚的知道，测试策略在测试用例设计中的作用和其应用的效果了；

3、 软件测试阶段的划分

关于测试阶段划分不明确的问题，我个人认为这点是第一个问题中的一个具体问题展现，同时其测试阶段的划分除了其计划时的划分外，还需要根据其测试的情况适当的调整其测试周期，如根据bug的多少趋势或者达到某个标准时，退出此阶段进入下一阶段；

4、 软件测试团队沟通

在上次测试总结中，说此问题是个人和组员的问题，我认为那个说法是片面的，其主管不仅负责自己和下属的沟通，还要负责组织组员和组员之间的沟通；同时团队中的沟通不仅仅是工作信息之间的传输，还包括其他方面之间的信息流通。

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

软件测试方法多种多样，大家可以通过下文的学习，更有针对性的选择软件测试方法，确定方向，提高效率。

可移植性测试

可移植性测试，英文是Portability testing。又称兼容性测试。

可移植性测试是指测试软件是否可以被成功移植到指定的硬件或软件平台上。

用户界面测试-UI测试

用户界面测试，英文是User interface testing。又称UI测试。

用户界面，英文是User interface。是指软件中的可见外观及其底层与用户交互的部分（菜单、对话框、窗口和其它控件）。

用户界面测试是指测试用户界面的风格是否满足客户要求，文字是否正确，页面是否美观，文字，图片组合是否完美，操作是否友好等等。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。

用户界面测试用户分析软件用户界面的设计是否合乎用户期望或要求。它常常包括菜单，对话框及对话框上所有按钮，文字，出错提示，帮助信息 (Menu 和Help content)等方面的测试。比如，测试Microsoft Excel中插入符号功能所用的对话框的大小，所有按钮是否对齐，字符串字体大小，出错信息内容和字体大小，工具栏位置/图标等等。

冒烟测试

冒烟测试，英文是Smoke testing。

冒烟测试的名称可以理解为该种测试耗时短，仅用一袋烟功夫足够了。也有人认为是形象地类比新电路板功基本功能检查。任何新电路板焊好后，先通电检查，如果存在设计缺陷，电路板可能会短路，板子冒烟了。

冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。

随机测试

随机测试，英文是Ad hoc testing。

随机测试没有书面测试用例、记录期望结果、检查列表、脚本或指令的测试。主要是根据测试者的经验对软件进行功能和性能抽查。随机测试是根据测试说明书执行用例测试的重要补充手段，是保证测试覆盖完整性的有效方式和过程。

随机测试主要是对被测软件的一些重要功能进行复测，也包括测试那些当前的测试样例(TestCase)没有覆盖到的部分。另外，对于软件更新和新增加的功能要重点测试。重点对一些特殊点情况点、特殊的使用环境、并发性、进行检查。尤其对以前测试发现的重大Bug，进行再次测试，可以结合回归测试 (Regressive testing)一起进行。

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

曾经，软件测试是软件工程教科书上薄薄的几页四号字，是百度知道上大段的介绍，是想象中繁杂的文档……

百度知道上这样定义软件测试工程师的工作：“软件测试工程师的工作就是利用软件测试工具按照测试方案和流程对产品进行功能和性能测试，甚至根据需要编写不同的软件测试工具，设计和维护测试系统，对测试方案可能出现的问题进行分析和评估。执行测试用例后，需要跟踪故障，以确保开发的产品适合需求”。

推敲一下，不难发现其隐含的对软件测试的定义：按照测试方案和流程对产品进行功能和性能测试，确保开发产品适合需求。再仔细推敲，感觉不对，按这个理解，测试只是从需求定下以后入手，以需求为标准，使得产品功能满足需求即可。实际的情况是怎样呢？稍夸张一点说，就像我们不能保证产品不存在bug一样，没有人能保证需求不变动。因此，需求定下以后测试工程师再介入只能是一句空话。

入职以来，亲身的经历是测试工程师从PRD评审阶段就介入了。这样的好处也体会到了：需求不再是word中冷冰冰的字眼，而是评审中经过大家讨论的，烂熟于心的东西，而且一些存在的问题尽早地被挖掘出来，尽早地解决，后期的需求变动减少甚至没有，使得上线前的压力减小。

当然也有一些问题：例如PRD文档写的过于简单或者拿到PRD到评审之间的时间很短，没有时间仔细研究PRD或PRD看的不是很清楚，这样会导致PRD评审的作用和意义就不那么明显了。

PRD评审后，测试的工作就全面铺开了。写TC，执行TC，记录bug，跟踪bug，回归测试，性能测试……各种测试的方法就可以择机而上，根据各自的特点发挥各自的作用，最终的目的就是：从各种角度，最大限度地保证产品的质量和性能。

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

一套完整的软件测试应该由五个阶段组成：

1．软件测试计划

首先，根据用户需求报告中关于功能要求和性能指标的规格说明书，定义相应的软件测试需求报告，即制订黑盒测试的最高标准，以后所有的软件测试工作都将围绕着软件测试需求来进行，符合软件测试需求的应用程序即是合格的，反之即是不合格的；同时，还要适当选择测试内容，合理安排软件测试人员、测试时间及测试资源等。

2．软件测试设计

将测试计划阶段制订的测试需求分解、细化为若干个可执行的测试过程，并为每个测试过程选择适当的测试用例（测试用例选择的好坏将直接影响到测试结果的有效性）。

3．软件测试开发

建立可重复使用的自动测试过程。

4．软件测试执行

执行测试开发阶段建立的自动测试过程，并对所发现的缺陷进行跟踪管理。测试执行一般由单元测试、组合测试、集成测试、系统联调及回归测试等步骤组成，软件测试人员应本着科学负责的态度，一步一个脚印地进行测试。

5．软件测试评估

结合量化的测试覆盖域及缺陷跟踪报告，对于应用软件的质量和开发团队的工作进度及工作效率进行综合评价。

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

优秀的软件测试员是修炼成的，需要内炼内功，外炼招式和兵器。内功的修炼，即软件测试理论的学习，在《实用主义软件测试员眼中的测试理论》中已经讲过。这里我们来看看十八般兵器，我们软件测试员怎么把它们都耍好？

对待软件测试工具的辨证态度

软件测试工具对于测试员来说是必不可少的，但是不能迷恋工具。

必不可少是因为很多测试如果缺少了软件测试工具是不可能完成的。实用主义测试者不会浪费时间在一条条数据去手工录入，造出100万条的数据表。

会有这样的软件测试员，他们非常向往工具的使用，认为如果不使用工具，好像只是停留在手工的测试，感觉处于测试的很低级的阶段。他们努力地寻找、试用各种新版本的测试工具，以为这样就可以让自己跟上软件测试的潮流了。

我曾经面试并看多很多测试应聘者的简历，他们往往喜欢在简历上注明熟悉甚至精通什么样的工具。在面试过程中，他们也会很迫切地希望我知道他们对某些工具是了解的，生怕因为没有提到这点而竞争不过别人。再看看培训市场上，到处是关于测试工具的培训，不得不让人认为，测试员如果少了这几项兵器好像就要落后于时代似的。

真正的实用主义测试者不会这样，他们对待测试工具的态度是：按需索取、信手拈来。

大工具

实用主义测试者当然也会有常用的兵器，例如性能测试工具、GUI回归测试工具等。而这些工具一般都是专门的“铸剑人”（测试工具厂商）提供的。我们要先“品剑”，再“练剑”，然后是“用剑”，“论剑”。

“品剑”：在真正使用一个工具之前，最好能取得它的试用版，试用一段时间，还要结合自己项目来试用，不要只是按照工具附带的例子和测试程序来试用，因为它的例子肯定都是可用、可通过测试的。例如，有些工具不支持新版本的.NET Framework，而如果你的项目是在新版本Framework下开发的，则即使买过来也不能用。

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

从企业方面：多数企业较难招聘到满意的软件测试工程师，尤其在软件测试外包企业，人才问题成了这类企业的发展瓶颈，这些恰恰反映了整个软件测试行业的发展遇到了瓶颈；

从个人方面：很多软件测试人员薪资和职位到了一定阶段就很难得到提升，例如很多软件测试工程师做到测试经理后，几年内得不到提升。

职业发展尤其体现在待遇方面。下表是北京市一些IT企业测试工程师的月薪数据。这些数据主要从一些网站收集，由一些测试工程师发布。

通过上面的数据，我们可以看出：

（1） 企业规模越大，越重视测试，而测试人员的待遇也越高；

（2） 掌握软件测试工具的测试人员待遇往往高于那些只能进行手工测试的工程师；

（3） 软件测试技术越熟练，待遇越高，而具备一定领导能力的测试工程师待遇会更高些；

但是我们就整个IT行业来看，尤其是与开发人员相比，软件测试工程师的待遇显得很低。就作者掌握的资料来看，同一级别的开发工程师要比测试工程师高1～2K（人民币），甚至更多。

与开发人员相比，测试工程师的职业目标则很少，主要下面几类：

◇ 测试组长（也可称之为测试负责人、测试经理）：这类测试人员通常是测试项目负责人，既要具备较高的测试技术能力，还要具备一定的管理能力。主要职责是制定测试与编写测试计划、监控和管理整个测试过程。测试组长职位之所以受青睐，是因为测试组长可以向上发展为测试部门经理、质量经理，也可以横向发展为项目经理，因此通常待遇相对高些。

◇ 测试分析师：主要职责是对系统的测试结果进行综合的分析，例如缺陷分析、性能分析等。测试分析师不但测试技术能力较强，还要具备数据库、操作系统等多方面的技术知识。这类职务的发展空间也不错，可以发展成系统设计师等。

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

Parasoft Jtest

是第一个自动化Java单元测试工具。软件测试工具Jtest能够自动测试任何Java类或部件，而不需要您写一个软件测试用例、驱动程序或桩函数。只要点击一个按钮，Jtest自动测试代码构造（白盒测试）、测试代码功能性（黑盒测试）、维护代码完整性（回归测试）和静态分析（编程标准执行和指标度量）。不需要复杂的设置，Jtest能够立即使用并指出问题。如果您使用“按合同设计”技术在代码中加入描述信息，Jtest能够自动建立和执行软件界测试用例验证一个类的功能是否符合其功能描述。

网址：http://www.parasoft.com

Parasoft C++Test

是单元测试和静态分析工具，自动测试C和C＋＋类别、功能或组件，而无需编写单个测试实例、测试驱动程序或桩调用。只需点击按钮，C++Test即会采用业内编码标准执行代码的静态分析，测试代码构造（白盒测试），测试代码功能性（黑盒测试），并保持代码完整性（回归测试）。

网址：http://www.parasoft.com

Parasoft .TEST

是单元测试和静态分析工具，自动测试写在Microsoft?.NET框架的类别，而无需编写单个测试场景或桩调用。只需点击按钮，.TEST即会在.NET源代码上自动执行完整系列的静态和动态测试。.TEST RuleWizard性能通过图形化表达希望.TEST在自动编码标准执行过程中查找的模式，支持设计定制的编码标准。

网址：http://www.parasoft.com

Parasoft Insure++

是一个自动化的内存错误、内存泄漏的精确检测工具。Insure++能够可视化实时内存操作，准确检测出内存泄漏产生的根源。Insure++还能执行覆盖性分析，清楚地指示那些代码已经测试过。将Insure++集成到您的开发环境中，能够极大地减少调试时间并有效地防止错误。

网址：http://www.parasoft.com

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

问题描述：初级软件测试工程师或新进入一家公司从事软件测试工作的人员，如何快速得到提升和认可？

精彩答案：

会员 yolander ：

题目写的非常清楚，角色定位为初级软件测试工程师，那就来看看对于软件测试新手入行，我们都看重他（她）的哪些方面吧

首先，从个人素质来看，我喜欢的软件测试新人要具备：

1、快速的学习能力

——这也是我最看重的一点，作为软件测试人员也好，开发人员也好，同为技术岗位，如果缺乏学习能力，那么他将来的发展肯定是十分有限的，而对软件测试岗位来说，快速的学习更显得尤为重要，因为作为入门级的开发新手，或许只需要看懂设计文档，能够使用开发工具进行编码就可以了，但是软件测试人员则不同，除了编码（更多的是体现在测试脚本的开发上），更需要深入掌握系统知识，业务能力上要比研发人员高一大块，这样在将来的工作中，提出的问题也更有说服力，更能够被开发人员所接受

2、细致认真的工作态度

——很多人都将软件测试人员比喻为“挑毛病的”，这可能是一句戏言，但也体现了作为软件测试人员的一种定位，我们从事了这样的行业，随时都在给开发人员编写的程序找bug，那么我们自己的工作是否也能够被人找出bug来呢？如果缺乏细致认真的工作态度，提交个问题报告也会错别字百出，甚至漏洞一堆，那么怎么能够让人相信我们的工作是有效的呢？要做好测试工作，那么首先要在工作中竖立自己的威信，但这种威信，并不是靠你的上级授权的，更多是通过自己的日常工作积累，给大家留下的深刻印象，共同认定为你是这个行业中的权威才行

3、充沛的精力

——我很喜欢与有着充沛精力的软件测试人员一起工作，测试是一门需要足够耐心的行业，虽然自动测试技术的兴起，已经能够减少我们工作中一些简单繁琐的重复性劳动，但实践经验来看，软件测试并不能完全杜绝这种单调的手动测试工作，仍然需要大量手动测试的执行，所以就需要我们测试工程师具备自我激励的能力，能够在这样的乏味工作中找到自己的兴奋点，并且能用自己的充沛的热情去感染别人

本文来自51Testing软件测试网（查看更多）：http://www.51testing.com/zhuanti/job/job.html

我们做软件测试的这帮人，往往会有这样的想法：由于软件的复杂导致了测试的复杂，所以不能指望培训能给我们很多工作中的实际指导。偏重理论是肯定的，但并非没有意义，虽然理论同样可以从相关的文献资料上得到。因为做软件测试时从来不希望检测被测系统所有可能的输入、路径和状态，那么应该选择什么？什么时候应该停止测试？什么时候应该暂停测试？怎样编写一个软件测试包，它可以检测足够多的消息和状态的组合来说明没有失败的操作，但是从实用性来说它又足够的小？

测试提出了许多基本的但却令人困惑的难题，带着这些问题，所以参加了几次实用软件测试培训。

一，软件测试员的目标是尽可能早地找出软件缺陷，并确保其得以关闭。仔细思考后，我觉得此目标包含三个含义。

1．软件测试员的基本目标是发现软件缺陷。

这似乎是个不言而喻的事实，但有必要再次强调。因为有时开发小组要测试员只是为了证实软件可以运行，而不是找缺陷。在这种情况下，软件测试人员也就缺乏不懈努力发现缺陷的探索精神和热情。所以做好测试的首要条件是明确软件测试员的基本目标是发现软件缺陷。

2．软件测试员追求的是尽可能早地找出软件缺陷。

因为软件的修复费用，随着时间的推移，将数十倍的增长，所以软件测试员应尽可能早地找出软件缺陷。对于大型的软件，在软件开发的同时，就应该有紧随其后的测试，如果等到产品已经开发完毕才开始测试，非常有可能引起大量耗时费力的返工。而如何尽可能早的找出缺陷？理论上有一些测试方法：静态黑盒测试、动态黑盒测试、静态白盒测试、动态白盒测试；配置测试、兼容性测试、易用性测试……，怎样才能有效的用这些方法尽早的发现软件缺陷，需要在工作实践中不断的摸索、总结，不断的提高测试能力。针对公司的情况，如果软件的规模不是很大，开发中的测试工作可能由开发人员完成比较合适。

3．软件测试人员必需确保找出的软件缺陷得以关闭。

并不是每个软件缺陷都有必要修复的。可能是由于没有足够的时间、不算作真正的软件缺陷、修复的风险太大等原因，产品开发小组决定对一些软件缺陷不作修复。但是，测试人员必需确保找出的软件缺陷得以关闭，也就是说一旦登记了软件缺陷，就要跟踪其生命周期，监视其状态，提供必要的信息确保其得到修复和关闭。

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