-
录制脚本是的thinktime
2008-05-29 22:10:21
考虑时间Thinking Time指的是在性能测试脚本中，事务与事务之间，会有一些短暂的停顿，就好像真实用户在操作时，两次操作之间需要考虑一下。比如用户注册的时候，在打开注册页面到提交注册页面之间，是有一段考虑时间的（用户在填写个人信息）。
下面就讨论一下在性能测试实战中，为什么要设置考虑时间。
先说一个概念：吞吐量，这指的是服务器系统（包括软件和硬件）单位时间内处理业务的数量。我们现在做一个小试验，写一个小程序，执行一个简单的业务，并且在程序中进行计时，计算每分钟能执行多少次。然后当我们运行1路这个程序的时候，每分钟能完成约6万次。好，现在问一个问题，如果我们起2路，是不是每一路都能达到 6万/分钟 的吞吐量？
试验发现，当运行2路的时候，两个程序的数值都降了下来，但是它们的总和仍然是6万次。而且不管我们起多少路，这些程序的性能总和都接近于6万。
这就好像一个人1分钟最快能吃1个馒头，你让他一个一个吃，他两分钟能吃2个，如果你让他一手拿一个，同时吃，他两分钟吃不了4个，还是只能吃两个。
我们不是在说“考虑时间”么，哈哈，别急，因为上面的问题必须要先说清楚。
如果我们需要进行性能测试的业务是一个单纯的业务，就好像上面举的那个例子一样，那么测试脚本中就不需要设置“考虑时间”，因为不管你用什么方法测试，一个服务系统处理单一业务的吞吐量总是一个定值。
但是在实际环境里面，往往一个系统都是要处理多种业务，并且这些业务之间是有逻辑关系的。举例说明，比如一个论坛系统，每天最常处理的业务有两个：A打开帖子、B回复帖子。那么每天系统处理AB业务的总数是不是一样的呢，答案很明显，看帖子多，回复的少一些。假设A:B=2:1。
好，如果我们不设置考虑时间，起2路A的脚本，1路B的脚本进行性能测试，我们会得到什么结果呢？我们会得到这两个业务的吞吐量，并且能算出每个小时系统完成A、B业务的总数，吞吐量 × 时间 ＝ 总数。
这时我们发现，同样时间，AB业务的处理总数却不是2:1的关系，这是为什么呢？原因是这样的，我们在跑AB脚本的时候，这两组脚本都在尽全力争夺服务器的资源，他们的并发路数虽然是2:1，但是给服务器的压力却不一定是2:1，可能会出现偏差，测试结果就是最好的证据。A查看帖子由于响应时间短，因此跑的次数更多，最后的比例可能是4:1。
那么这样的结果有什么问题呢。总结为一句话：测试环境的业务和真实环境不符，这样测出的数据没有价值。即使测试通过，也不能证明真实环境是ok的；或者即使测试不通过，也不能说明真实环境不ok，呵呵。
比如上面的例子，如果我们测出的结果是B回复帖子的吞吐量不够，响应时间太长，那可能是因为A业务抢走了过多的，本不属于A的资源，而引起了B的性能降低。
说到这里，大家应该明白了，我们设置考虑时间，是为了保证测试复合业务的时候，各个业务之间的比例关系符合我们的真实生产环境。 -
性能测试模型分析
2008-03-09 21:56:18
对于应用系统的性能测试，测试模型的建立至关重要，性能测试模型要以实际生产环境为标准搭建，只有模型符合实际的生产环境，性能测试的结果才能真实有效的反映将来上线的生产环境的实际性能情况。根据长期测试关键核心业务系统的经验，应用系统系统的性能测试模型分析应当按照下面几个步骤来实施：
业务模型建立
全面分析应用系统系统上线后所面临的性能压力的来源和类别，并且通过分析历史交易数据来确定各种性能在整个系统压力所占比例。例如确定前台应用子系统的业务类别和并发比例，后台批处理业务的数据规模和类别等。最终目的是建立一个能够逼真模拟应用系统系统实际运行场景的业务模型。
测试数据模型建立
根据业务模型准备测试数据和基础数据，确保系统数据库中数据容量和真实性符合实际运行情况。
监控模型建立
性能测试的目的不仅仅是获得关键业务的性能指标，同时也要通过性能测试监控主机、数据库、中间件的各个性能指标，从而发现性能瓶颈，为进一步的性能调优提供准确的参考数据。
测试模型建立
对应用系统系统的测试，因该采取基准测试、单业务负载测试、混合负载测试的顺序来执行。这样做的好处，在单业务负载测试是就可以发现各个系统本身的性能缺陷，而混合负责测试时将重点检查各个业务相互影响导致的性能缺陷。
执行模型建立
应用系统系统的性能测试必须要局方客户、系统开发商、第三方测试服务商紧密配合，才能保证整个测试工作的成功。因此，只有建立一套规范的性能测试流程，明确各个角色的工作职责，才能使性能测试工作有序、高效的开展。
风险模型建立
由于性能测试的特殊性，因此在整个测试过程中，会遇到很多导致整个性能测试失败的风险。丰富性能测试经验是必须的，能够提前分析可能遇到的各种风险并制定相应的规避措施。这样才能将性能测试的风险降到最低，最终圆满完成应用系统系统的上线性能验收测试。
上面的步骤或者说方面只是性能测试项目实施中要完成的工作方面的的概述，不同的项目可能有不同的实施方法或步骤要视项目而具体实现。要完成一个有效的应用系统的性能测试，从需求调研到测试分析的各个阶段，有很多工作需要完成，在以后的文章中，会对性能测试项目的分阶段工作进行讲解，适当的时侯会搭配一些项目实施的例子来进行讲解。 -
性能测试高端发展方向
2008-03-09 21:52:49
业界认为性能测试ROLE划分为 性能测试工程师(偏重编写性能测试脚本、性能测试执行) 和性能测试分析师 (偏重性能分析、系统调优,也需要更加广、深）的知识。
根据个人的理解，性能测试高端发展有如下一些方向： 性能调优，架构评估，性能监控，容量规划，应用性能管理。
性能调优偏重系统级调优、代码级调优，需要非常熟悉系统架构、profile工具(如jprof, gprof ) 。有开发背景的最合适往这个走。
架构评估偏重参与项目前期，根据以前的性能测试经验以及教训判断架构合理性。以后进一步发展成系统架构师。
性能监控就是充分应用现有的工具（如 rpc.rstatd, openview, sitesope,cacti等）以及扩展工具满足详细指标，并图形化展现 容量规划则根据现有系统能力开展what if分析（如增加cpu，更换吞吐率，甚至机型），推算if之后系统性能表现，需要很强的数学功底以及建模能力。目前比较好的工具有teamquest。国内广东电信研究院评测中心和上海电信都在用。
应用性能管理，可以参考Mercury 的BAC产品，如何抢在用户之前主动发现网站或者业务瓶颈。 可以利用QTP/loadrunner的脚本结合sitescope 主动监控。 目前浙江移动已经实施。 -
终于如愿以偿的进入测试行业
2008-03-01 14:38:07
想一想半年前还是对策是一无所知，然后一如既往的选择测试，学习测试，到现在从事测试，感觉经历了很长的时间，现在想想其实还没一年。测试很注重行业知识，我现在的公司做的是金融软件，所以也就迷迷糊糊的测起了金融软件，对这个行业还是比较看好的，所以要好好看，虽然现在做的是MS银行的UAT测试，难度不是很大，但是可以学到很多业务知识，所以还是有的学，反正什么都是学。
恩，要好好干，多认识业务的朋友，尤其是金融行业的朋友，想跟我认识的可以加我qq，173509599.
-
Web的系统测试要点
2007-07-09 00:33:56
一、功能测试
1、链接测试
链接测试可以用工具测试。链接测试必须在集成测试阶段完成，在整个Web应用系统的所有页面开发完成之后进行链接测试。
测试所有链接是否按指示的那样确实链接到了该链接的页面；
测试所链接的页面是否存在；
保证Web应用系统上没有孤立的页面(所谓孤立页面是指没有链接指向该页面，只有知道正确的URL地址才能访问)。2、表单测试
包括注册、登陆、信息提交等，必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。
用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等；
检验默认值的正确性；
如表单只能接受指定的某些值，测试时跳过这些字符，看系统是否会报错。3、Cookies测试
Cookies是否起作用；
Cookies是否按预定的时间进行保存；
刷新对Cookies有什么影响。4、设计语言测试
Web设计语言版本的差异可以引起客户端或服务器端严重的问题，例如使用哪种版本的HTML等。除了HTML的版本问题外，不同的脚本语言，例如Java、Javascrīpt、 ActiveX、VBscrīpt或Perl等也要进行验证。
5、数据库测试
数据一致性错误：主要是由于用户提交的表单信息不正确而造成的；
输出错误：主要是由于网络速度或程序设计问题等引起的。
二、性能测试
1、连接速度测试
Web系统响应时间
超时的限制2、负载测试
负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。
3、压力测试
压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃。压力测试的区域包括表单、登陆和其他信息传输页面等。
三、可用性测试
1、导航测试
导航是否直观
Web系统的主要部分是否可通过主页存取
系统是否需要站点地图、搜索引擎或其他的导航帮助
Web应用系统的页面结构、导航、菜单、连接的风格是否一致
Web应用系统导航帮助要尽可能地准确。Web应用系统的层次一旦决定，就要着手测试用户导航功能。
2、图形测试
要确保图形有明确的用途，图片或动画不要胡乱地堆在一起，以免浪费传输时间。Web应用系统的图片尺寸要尽量地小，并且要能清楚地说明某件事情，一般都链接到某个具体的页面。
验证所有页面字体的风格是否一致
背景颜色应该与字体颜色和前景颜色相搭配图片的大小和质量也是一个很重要的因素，一般采用JPG或GIF压缩
3、内容测试信息的正确性
4、整体界面测试
整体界面是指整个Web应用系统的页面结构设计，是给用户的一个整体感。
四、客户端兼容性测试
1、平台测试
在Web系统发布之前，需要在各种操作系统下对Web系统进行兼容性测试。
2、浏览器测试
测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中，测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。
五、安全性测试
现在的Web应用系统基本采用先注册，后登陆的方式。因此，必须测试有效和无效的用户名和密码，要注意到是否大小写敏感，可以试多少次的限制，是否可以不登陆而直接浏览某个页面等。
Web应用系统是否有超时的限制，用户登陆后在一定时间内（例如15分钟）没有点击任何页面，是否需要重新登陆才能正常使用。
为了保证Web应用系统的安全性，需要测试相关信息是否写进了日志文件、是否可追踪。
当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。
服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。
-
31个用来测试网站各项性能的免费工具
2007-06-29 15:28:47
你是否肯定你的网站完全兼容各大浏览器？是否知道多少秒可以打开你的网站？ 是否可以自信地说你的网站根本就没有打不开的时候？ 是否……
虽然它看似不重要，但这些在一定程度上也对你的网站的访问量产生了影响 （ 其它一部分影响浏览量的原因及解决办法 ）。这里列出了一份 31 个我最喜爱的免费在线测试工具，你可以通过这些工具来测试你的网站，并根据结果对你的网站进行修改。
网站代码验证 没人可以细致到保证自己的网站代码都是正确的，你可以通过以下测试来验证网站代码是否正确。
1 .WDG HTML Validator一个很好的工具，能找出网站语法错误的地方，并标注出来，也可选择对网站上单独的每一页进行单页分析。（ 强烈推荐 ）
2 .W3C Markup Validation Service对 HTML 和 XHTML 都能进行代码测试，自称是互联网络上第一个（也是使用者最多的）的 HTML 验证工具。
3 .W3C CSS Validation Service用于验证 css 源代码，能够标注出不好的 css 代码设计。例如：“Same colors for color and background-color in two contexts”。
4 .RUWF XML Syntax Checker用于查找 XML 文件的错误。
5 .W3C Feed Validation Service用于查找 Atom 和 RSS feed 中的错误语法。（ 这个我经常用到 ）
6 .W3C Link Checker用于搜寻查明你网站内的所有链接里是否有断链。（ 强烈推荐 ）
7 .Juicy Studio Link Analyser测试网站内的链接的 URL 是否存在死链，与 W3C Link Checker 很类似。
网站的使用性
我们常常看到网站设计者把重点放在怎网站的吸引力上，而完全不考虑会不会影响来访者的使用，一个浏览难度很大的网页是注定要失败，要让你的来访者方便的得到他要的信息（从而成为重复访客），你的网站应当遵循 WCAG section 508 易用性规则。
8 .Watchfire WebXACT所有严谨的设计师和开发者都必须使用的工具，它会生成一个非常详尽的报告书，包括：网站质量，易用性和隐私等。（ 强烈推荐 ）
9 .ATRC Web Accessibility Checker测试网站的 WCAG 2.0 Level2 兼容性，它会生成一份报告，提出一系列建议，如：如何提升页头，链接，数据，图表和文字的访问速度。
10 .WAVE 3.0 Web Accessibility Tool高度可定制的工具，它采用了图形化模型展示网站兼容性问题（ WCAG 1.0 and section 508 ）。（ 强烈推荐 ）
11 .TAW Web Accessibility Test测试网页是否存在冲突（ WCAG 1.0 兼容性 ），通过图形模式生成一份依据 wcag 优先模式为基础的网站修改建议。
12 .HiSoftware CynthiaSays portal采用了非常严格的规则来测试网页（ 根据 section 508 和 WCAG 1.0 规则 ），生成的报告也极为详细（ 详细到很难看懂 ）。
13 .HERA Accessibility testing with Style使用一种极为复杂但容易理解方式指出网页的 wcag1.0 兼容性问题。
14 .Juicy Studio CSS Analyser进行了色彩对比测试，以确保你的网站的色调会符合 WCAG 1.0 的要求。
15 .Juiciy Studio Readability Test分析你网站上的文字是否有语法错误或拼写错误等问题，容易让人理解不（ 根据 the Flesch Reading Ease 和 Flesch-Kincaid grade level algorithms 规则 ）。（ 适合英文网站使用 ）
网站的速度
打开你的网站的速度快慢，是来访者会不会再次访问网站的关键因素，在一般情况下，一个网络不是很快的来访者是不愿意访问一个充满着图片、flash 动画、多媒体文件的网站。为了使你的网站覆盖人群的范围最大化，你必须优化你的网站，使它的打开速度尽可能的快。
16 .Web Page Analyzer from Website Optimization一个很好的工具，它在分析完一个网页后，会为减少加载时间提出优化建议，着重优化物体的数目，图片和网站的总体大小。（ 强烈推荐 ）
17 .WebSitePulse Test Tools有一系列的工具来确定网站的加载速度和主机信息。
18 .Internet Supervision Url Check从世界各地不同的服务器来测试你的网站的加载时间，用于确定是不是各地的来访者都能顺利快速的打开你得网站。
浏览器模拟工具
这是一个普遍的问题，因为现在有着很多的操作系统和浏览器，你得网站必须得兼容它们，但这绝不是一件容易的事。通过下列工具，你可以了解你得网站在各种浏览器上的显示效果。
19 .Browsershots能给出你的网站在不同浏览器下显示效果的截图，包括：Firefox 和 Internet Explorer （ Windows ）、Firefox 和 Safari （ Mac OS X ）、Iceweasal 和 Konqueror （ Linux ），但是结果要在 1 - 3 小时后才能出来。
20 .IE NetRenderer实时生成你的网站在 Internet Explorer 5.5 、6.0 和 7.0 下的截图。
21 .MobiReady Report分析使用手机访问网页的兼容性问题，会生成一份详细的报告，并提供了在两种不同类型的手机浏览器上你得网站可能显示的样子。
搜索引擎优化 (SEO)
一个网站，如果对搜索引擎有着比较好的友好度，一定会比较有竞争力。
22 .UrlTrends会显示网站的访客是如何通过搜索引擎来到你的网站，还有各个流量是多少。这些数据是包括 Google, Yahoo,MSN, Alexa, AlltheWeb, Altavista和其他一些网站。（ 强烈推荐 ）
23 .iWEBTOOL Backlink Checker一个很好的工具，它能找出有什么站点链接到你的站点，那些站点是什么类型的站点。
24 .iWEBTOOL Multi-Rank Checker显示你网站的 Alexa 和 Google PageRank 数值。
25 .Microsoft adCenter Labs: Advertising and Keyword Research Tools一个极好的工具，用于分析和预测你网站的来访者和市场。（ 强烈推荐 ）
26 .Domain Tools Whois lookup一个 WHOIS 网络工具。
27 .SEO-Browser可以让你看到在搜索引擎眼里一样的网站（ 去掉所有的”美丽”配件 ）。
28 .SEO Workers SEO Analysis Tool非常有用的工具，分析了网站上的各种分类特征，包括 meta 标签、关键字密度及加载时间。（ 强烈推荐 ）
29 .Seekport Seekbot可以分析网站的数据和内容，以得出搜索引擎会如何有效的解释分析的网站。
30 .SEO Chat SEO Tools用以分析网站 Google adsense 盈利潜力，关键字密度，Meta tag 等等……
31 .Marketleap Search Engine Marketing Tools用来分析网页，让你知道你的网站检索、设定的关键字好不好。 -
Tester's Necessary Traits
2007-06-25 01:24:48
软件测试工程师除了技术，还要求具有否定性的创造力；探测技巧；总体理解产品的能力；用客户的眼光进行评估；怀疑的而不是敌意的态度；能经受得住坏消息而保持目标；拥抱新技术的热望等特征。
否定性的创造力。一个软件工程师不能怕引起一个产品的瘫痪或烧毁。在软件测试中，边界意味着被超越而不是被遵从。如果一个程序对某个值的极限为10(例如，可以在一时间被打开的最大文件数)，测试工程师的第一想法应当是“如果我把那个值取11，或0，或10.1，甚至不设这个值会如何？”
在我的早期的工作生涯中，有一次我测试一个开发和QA工程师遗漏下来的PC数据库。有问题的数据库是2.01版。这本身就说明产品有问题。2.0版没解决1.0版的所有缺陷吗？或者2.0版又加入了新的缺陷？很遗憾因为时间紧我没有调查这些，只是证实了最后的缺陷修复后就告捷了。
这是很大的错误。我应当重测开发人员所谓“没有变化”的所有产品功能。2.0版本中的缺陷确实复修了，但在修复的过程中，有人破坏了请求。事实就是如此，在数据库里不能搜索数据了，第一个收到这项产品的beta客户发现了这个缺陷。
我宣布以前的测试无效，要求对产品进行全面测试。找到几个缺陷之后，我发现这个数据库读取写保护文件或写保护了的磁盘的时候就会引起瘫痪。开发人员很吃惊我会试着写保护一个数据库。他们的反应就是：“没人会这么干的！”产品的市场经理很快用他们的方式承认了错误。
探测技巧。在一个理想的世界中，软件测试应当在一个经常更新的写得很清楚的功能与设计说明文件(一般被称为specifications”)中被完整而精确地描述。不幸的是，这一完善被开发程序每一方面文件的任务，包括记录在开发中对程序不可避免的改变，要花很多的时间和精力以至于人们无法完成编程。而且花费也太大。
正式与非正式的信息源 正式系统 要求文件 功能说明书 设计说明书
非正式系统 用户文件 与其他开发人员的交流 与软件支持人员的交流
有关产品的文件 有关产品的缺陷 从工作于相关或早期版本产品获得的“局部知识”
因为我们不是在理想世界里编程，测试工程师应当能够自己找出工作的方式。典型的是，总会有一些设计和功能说明书让测试工程师用于开始他的研究。这些文件能看成为描述被测试软件的“正式”系统。测试工程师应当能用更广大的“非正式”系统的信息来扩展“正式”系统的信息。同时，在项目周期的任何一个点，任何文件都可能是正确或不正确的，所以测试工程师必须根据对软件工作模式的观察，与开发人员和其他项目人员的交谈，或对有关或看上去不那么相关文件的审核，来确定文件的精确性。
总体理解产品。在一个程序项目是，软件开发工程师主要把他们的精力和注意力集于自己的项目部分。结果当这些项目部分组合在一起进行测试的时候，就会碰到兼容性的问题。到产品寄给一个客户之前，唯一能见到整个产品的就是测试工程师。因此测试工程师必须能够对整个产品的操作与使用保持一种“系统”的眼光。
测试工程师对产品的任何一部分的操作可能不是最好的专家，但他必须是产品整体操作的专家。例如，如果被测的产品是一个类似于Microsoft Office的由文字处理、扩展页和其他有关程序组成的办公室自动组件，测试工程师必须了解每个程序的操作，各个程序之间的相互作用和客户其他的软件硬件和软件环境。
用客户的眼光进行评。测试工程师必须是客户的拥护者。被测程序有可能运行可靠满足所有的设计要求，但在客户的软件环境中未必能够用。产品被送到客户之前的测试之一就是要证实产品达到了客户的要求与期望。在这项测试中，测试工程师必须模拟用户的软件环境，把自己放到他们的位置上。
关于软件功能“正确”而不能满足客户需要的一个悲剧性的例子就是美国航空公司965航班1995年在哥伦比亚卡利市的一次失事。在飞行着陆时，空中信号控制系统指示机组人员朝一个叫“Rozo”的航空信号灯飞。这个信号灯在航空图中标为R。机组人员把R输入到飞行管理计算机中，看到了明显是由近到远列出的六个航空信号灯。机组人员选了第一个信号灯，以为这就是Rozo。但那不是。自动驾驶仪把飞机向左转了九十度，撞到了山上。
什么地方出错了呢？当航空表里把Rozo列为R的时候，飞行管理计算机要求机组人员输入信号灯的全名调出它的方位。同时，计算机只显示了信号灯的编码字母和方位。计算机功能“正确”，但不满足用户的需求。
要求变化。项目刚开始时的要求与最终项目完成时的要求一致的情况是极少见的。有时技术变化了，产品必须改变以适应于技术。有时竞争对手的产品具有你的产品所没有的功能。很多情况下，客户的或潜在客户的要求需要变化。这些因素合在一起的一个例子就是目前Microsoft Internet Explorer和Netscape的竞争。
随着计算机首次用户的迅速增加，今天的测试工程师比以往更需要把自己置于客户的位置上。这些新的非技术用户不愿意接受缺陷，对缺陷的解释或理性思考，或通过“升级”修正缺陷。他们只希望他们所买产品的软件和硬件都是能工作的。
怀疑的而不是敌意的态度。测试工程师不能按表面值接受事物，必须执着地对一切提出疑问直到被证实。工程师必须用一种与项目的其他的人合作精神来平衡这种怀疑性与执着性。测试部门与其有关部门的关系可能会变得紧张，特别是在大量缺陷被发现后，或者在每个找出的缺陷会潜在地延迟产品的发货时间而延迟了项目时。测试工程师应当记住要攻击程序的整体性，而不是程序员。
经受得住坏消息而保持目标的能力。一个测试工程师必须忠实地汇报产品中的缺陷。这一信息应当被项目组欢迎，因为每一个测试工程师遇到的问题(除非加入新的问题)都意味着减少客户会面临的问题。但不幸的是很多人不想听到有问题，特别是在程序项目的后期。
测试工程师应当能处理因为工作做得太好而引起责备的情况。这对有些人来说是很难做到的，会严重地影响斗志与自尊。
看起来常常是测试工程师阻挠了向客户交货。客观的项目经理才能感觉到测试工程师是在对项目提供有价值的服务。我清楚地记得一个项目经理举起他的手求我他要的是：“解决方案，不是问题！”(他不明白解决方案的实现有时要求一个问题的解决。)有时项目经理在项目计划不方便的时候对于因为发现缺陷而打折是有压力的。在这些情况下，测试工程师应当能基于他对产品的经验和知识进行辩护，但他不应表现为象是他个人受到了威胁。
如何避免这些情形呢？就测试的内容、时间及如何更新测试结果和缺陷信息，设定其他项目组成员的期望。我曾经为一个希望延迟产品发送日期的QA经理工作过。他的目的不是为了产品成功，而是政治权力的操纵。他确信自己能被提升，把一些为他工作的工程师指定为“manager”，开始自称为“director”，还要大楼管理人员把他的办公隔间加宽一英尺。(当然，“director”没有实现，只是他的座位有了更多伸脚的余地。)
拥抱新技术的热望。对多数人来说，年龄越大越难学习。在商业世界里，人员越往公司的食物链高处走，越远离他们所建立的技术基础。这一部分是因为他们需要把精力集中于其他的经营和指导其下属的任务中。有时也是因为他们不幸地认为自己已不需要进行实践的技术工作了。互联网增加了技术变化的速度。不继续学习或跟着发展就无法做出商务与技术的决断。
从前的一个经理给我树立了如何对待新技术的榜样。我跟他工作的时候他年近六十，但他象新手一样地热心于学习新技术。他大量地获取信息，不断补充在网络服务器、防火墙、和Perl或Expect等新语言的知识。他还重视做QA或测试组织的工作。他的最初背景是软件开发和开发管理，但他并不认为做QA经理是在降低他的声望。他明白一个独立的测试或QA组所进行的完整测试能使开发经理的工作变得多简化。
-
[转]软件测试的心理学问题
2007-06-22 15:15:32
1、程序测试的过程具有破坏性人类的活动具有高度的目的性，建立适当的目标具有重要的心理作用。如果我们的目的是要证明程序中没有错误，那我们就会不自觉地朝这个方向去做；也就是说，我们会倾向于挑选那些使程序出错的可能性较小的测试数据。另一方面，如果我们的目标是要证明程序中有错，那就会选择一些易于发现程序所含错误的测试数据。而后一种态度会比前者给程序增添更多的价值。测试的定义意味着程序测试的过程是具有破坏性的，其程度甚至达到了不可容忍的地步。社会上大多数人的人生观是建设性的，而不是破坏性的。人们倾向于创造一个物品，而不是轻易毁坏—个物品。因此，程序坏—个物品。因此，程序测试的破坏性的定义使人们对程序测试工作望而生畏。程序测试定义还隐含着如何设计测试情况（测过数据），以及应该由谁和不应由谁来测试一个给定程序等等观点。心理学研究还告诉我们，当人在干一件已经知道是不合适的或不可能做到的事时，往往做得不好。例如：如果让一个人在15分钟解出一个刊登在星期曰《纽约时报》上的交叉填字字谜，10分钟后我们会看到这人几乎没一点进展，因为他会感到实际上不可能做到而放弃自已的努力。然而，如果我们要求花4小时解出这题，那也许就会看到他在开头的10分钟内有较大的进展了。把程序测试定义为在程序中找出错误的过程，就使测试成了可以做到的任务，从而克服了心理上存在的问题。另一个令人烦躁的问题是即使程序完成了预期要求，仍可能含有错误。也就是说，如果程序不按要求工作，它显然有错，但是如果程序做了不要它做的事，它也有错。2、程序员应避免测试自己的程序开发者被指定测试自己的代码是一件很糟糕的事。开发和测试生来就是不同的活动。开发是创造或者建立什么东西的行为，一个模块或者整个系统。而测试的唯一目的是证明一个模块或者系统工作不正常。这两个活动之间有着本质的矛盾。一个人不太可能把两个截然对立的角色都扮演的很好。基于这个想法，应该限制开发者在测试中的参与。给他们比较合适的任务是进行有可能的最低层的测试--单元测试。不同当一个程序员在完成了设计，编写程序的建设性工作后，要一夜之间突然改变他的观点，设法对程序形成一个完全否定的态度，那是非常困难的。许多户主都知道，揭掉糊墙纸（破坏性过程〉是不容易的，若糊墙纸原先是由他而不是别人贴上的，他几平会感到难以忍受的沮丧。所以，大部分程序员都由于不能使自己进入必要的精神状态（不是抱着要揭露出自己程序中错误的态度），因而不能有效地测试自己的程序。除了这个心理学问题之外，还有一个重要的问题：程序中可能包含由于程序员对问题的叙述或说明的误解而产生的错误。如果是这种情况，当程序员测试自己的程序时，往往还会带着同样的误解致使问题难以发现。再者，可以把测试看做是对一篇论文或—本书作校对，或与写评论相类似的工作。正如许多作者所知，校对或批评自己的著作是非常困难的。也就是说，在自已的工作中找出缺陷往往是人的心理状态所不容的。以上看法并不意味着程序员不可能测试自已的程序。不过相比之下如果由另外—些人来进行程序测试，就会更有效、更成功。注意：这个论断并不适用于纠错（改正已知错误），由原来程序的作者纠错肯定效率更高。3、程库设计机构不应测试自己的程序在许多意义上来说，一项工程或一程序设计机构是个有生命的有机体，它同样有心理学问题。再者，在大多数情况下，人们都是以在给定日期内，以一定代价编制程序的能力来衡量程序设计机构和项目管理人员的。这祥做的一个理由是时间和成本指标便于衡量，而程序的可靠性却很难度量。要程序设计机构在测试自己的程序时持客观态度是困难的，因为如果用正确的定义看待测试，就不大可能按预定计划完成测试也不大可能把耗费的代价限制在要求的范围以内。软件生产的三个最重要的因素是：质量、进度和费用。计算技术的进步，意味着在经济领域中信息系统更新的速度更快。新的硬件技术的发展，均会使软件过时，系统交付使用的时间变得日益重要，新产品在其性能和费用上被其他产品取代之前的推销时间，即市场窗口就已经缩小了。由于费用和进度的限制，要开发一种高质量、快速交付和低成本的软件产品变得越来越困难，也就是说要同时达到三个目标是困难的。因此在软件产品的开发中就要权衡它们之间的关系，使软件的特性能满足用户的要求，这意味着软件产品特性的度量和预计是必要的。软件测试由独立测试机构承担有许多好处。独立测试是指软件测试工作由在经济上和管理上独立于开发机构的组织进行。独立测试可以避免软件开发者测试自己开发的软件，由于心理学上的问题，软件开发者难以客观、有效地测试自己的软件，而找出那些因为对问题的误解而产生的错误就更加困难。独立测试还可以避免软件开发机构测试自己的软件，软件产品的开发过程受到时间、成本和质量三者的制约，时间和成本指标便于衡量，而质量却很难度量，因此在软件开发过程中，当时间、成本和质量三者发生矛盾时，质量最容易被忽视，如果测试组织与开发组织来自相同的机构，测试过程就会面临来自与开发组织同一来源的管理方面的压力，使测试过程受到干扰。采用独立测试方式，无论在技术上还是管理上，对提高软件测试的有效性都具有重要意义。①、客观性对软件测试和软件中的错误抱着客观的态度，这种客观的态度可以解决测试中的心理学问题，既能够以揭露软件中错误的态度工作，也能不受发现的错误的影响。经济上的独立性使其工作有更充分的条件按测试要求去完成。②、专业性独立测试作为一种专业工作，在长期的工作过程中势必能够积累大量实践经验，形成自己的专业优势。同时软件测试也是技术含量很高的工作，需要有专业队伍加以研究，并进行工程实践。专业化分工是提高测试水平，保证测试质量，充分发挥测试效用的必然途径。③、权威性由于专业优势，独立测试工作形成的测试结果更具信服力，而测试结果常常和对软件的质量评价联系在一起，由专业化的独立测试机构的评价，更客观、公正和具有权威性。④、资源有保证独立测试机构的主要任务是进行独立测试工作，这使得测试工作在经费、人力和计划方面更有保证，不会因为开发的压力减少对测试的投入，降低测试的有效性，可以避免开发单位侧重软件开发而对测试工作产生不利的影响。 -
[转]如何成为一名优秀的软件测试工程师
2007-06-22 15:12:56
现在软件测试工作越来越收到企业的重视，许多人员也投入到软件测试的行列中来，软件测试工程师的队伍越来越壮大。但是如何成为一名优秀的软件测试工程师呢？这是大家比较关注的一个问题，尤其是初入这个行当的莱鸟更想了解这个问题的答案。本文根据自己多年来在IT公司从事软件测试的经验总结了一些东西给大家共享，同时也希望大家提出宝贵的意见和建议。
起码有三年以上的软件开发经验现在许多软件企业招收一些刚刚毕业的大学生或者非计算机专业的人员作为自己公司软件测试工程师，这是非常错误的，也是对软件测试不负责任的表现。虽然他们可以发现软件中的一些错误，但是对于软件中的一些关键，致命，危险的错误他们是很难发现的。大家都知道，软件工程中有个模型叫瀑布模型，这是最基本的软件模型，这个模型又叫碗状模型，因为开发位于碗的最底部，左上方依次为建模，需求分析，设计；右上方依次为测试，部署，维护。这就是说明软件开发是一切软件活动的基础，同时也是软件测试的基础。一个人只有经历过一定年限的软件开发工作，才可以积累丰富的经验，知道在软件中哪些地方容易出错而那些地方不容易，这给以后的软件测试工作带来非常宝贵的经验。
有逆向思维的能力我曾经接触过一些软件测试工程师，他们干了一段时间软件测试工作后返回去又开始去做开发工作了，问他们为啥？答案是软件测试工作太难了，开发是顺向思维，而测试是逆向思维，老要找一些稀奇古怪的思路去操作软件。软件的使用者千差万别，软件在使用过程中遇到的各种现象也是千差万别的，所以要求软件测试工程师需要具有一些逆向思维的能力，想别人所不想，测别人所不测，这样才可以找到更多的软件中的错误。这是作为一名优秀的软件测试工程师最基本的素质。
善于同软件开发人员沟通沟通是当今软件项目中需要掌握的最关键技术之一。软件测试人员要善于同软件开发人员沟通，软件测试人员与开发人员搞好关系，使测试人员不成为开发人员的眼中钉，这对于提高整个软件项目质量是十分重要的。沟通主要包括：
讨论软件的需求，设计：通过这样的沟通，你可以更好的了解所测试的软件系统，以至于尽可能少的测试出软件中不是错误的“错误”，从而降低给软件开发人员带来的压力。
报告好的测试结果：作为一个测试人员，发现错误往往是测试人员最愿意而且引以自豪的结果，但是一味地给开发人员报告软件错误，会给他们造成厌恶感，降低整个软件的质量和开发进度。所以作为一名软件测试工程师，当你测试的模块没有严重的错误或者错误很少的时候，你不妨跑到开发人员那里告诉他们这个好消息，这会给你带来意想不到的结果。
讨论一些与工作无关的事情：作为一个测试人员经常和开发人员讨论一些与工作无关的事情，比如大家可以谈谈新闻，趣事，家庭…这样可以加强相互间的默契程度，许多统计表明，这样可以更好的提高软件工作质量。
善于同领导沟通测试人员往往是领导的眼和耳，领导根据测试人员的测试结果可以了解公司的产品质量，从而调整其他的工作。领导工作一般比较繁忙，所以作为一名优秀的测试人员要学会把测试结果进行总结，最好以图表的形势给领导看。
掌握一些自动化测试工具测试工作往往是比较繁琐，枯燥无味的工作，测试人员长期处于重复的手工工作，会降低测试效率，并且对于测试质量也往往是不利的；况且许多测试不使用测试工具是不可以进行的，比如性能测试，压力测试等等。目前市场上有许多测试工具供你使用，你可以根据自己的需要选择一些测试工具来辅助你的测试。但是要记住一点，不是说有了测试工具就不要人工测试了，测试工具不是万能的。
善于学习的能力软件测试技术随着时间的变化也在做一些提高和改进，作为一名优秀的测试人员要善于利用书籍，网站，论坛，交流等各种途径不断提高自己的软件测试水平。
提高自己的表达能力软件测试人员当发现软件中存在缺陷的时候，往往要书写缺陷报告，缺陷报告要写得详尽清楚，使开发人员能够尽快定位错误，修改错误，所以作为一名优秀的测试人员提高自己的写作能力是非常必要的。
了解业务知识更好的了解你说测试软件的业务知识是非常重要的，对业务知识了解得越深入，越能够找出更深入，更关键，更隐蔽的软件错误。所以作为一名优秀的软件测试工程师，要多向该领域专家，同行学习，提高自己的业务知识水平。
-
[转载]漫谈软件测试工程师与mercury认证。很经典！
2007-06-22 14:54:06
作者： 叶赫华
sinckyzhang@hotmail.com
自从本人从事软件测试培训以来，接触了太多的软件测试工程师；发觉从业者多数存在以下现象：
——刚刚毕业，踏入IT行业，不懂开发或开发经验薄弱，被迫或“亚被迫”从事软件测试工作；这心哪，瓦凉瓦凉的，一是根本不懂这工作是干嘛的，二是这工作不被很多公司重视，于是唏嘘的心里留下一声声叹息，蹒跚的人生步履留下一串串疑问…
——从事软件测试工作2年以上，由于公司不正规的测试流程，不标准的测试方法，因此，终日碌碌无为的点击按钮，某日拍脑袋突发奇想，测试出来一个bug，于是兴奋焉…终后没有新思路，于是没有发现新bug，于是不再兴奋；于是这两三年来，无论测试经验，还是测试技术、方法，包括理论，都无长进，于是郁闷甚至极度懊恼这几年来究竟做了些什么，明天又该何去何从呢？仰天长啸，却无语对穹苍…
——有过若干年开发经验，也许由于疲惫于终日编码，也许感觉软件测试是个朝阳领域，于是转做测试…但是好景不长，兴奋度持续一段时间，感觉自己的想法和思维方式与现实工作模式严重分歧，所谓天妒英才，空有一身本领，竟无用武之地！于是满腹的经纶化作无言的泪水，内心的豪情壮志也逐渐泯灭！接着开始逐渐适应了眼前的这份高级测试工程师的头衔和薪水，觉得干工作就是那么回事，何必计较那么多？虽未清晰构建余下二三十年的职业蓝图，但是也觉得起码自己比起很多同行，还算不赖；时间如流水般在烟圈与香水中消逝，吾生就是这样终日撞钟，铛——铛——铛——（好响！斑竹，猪头切一半给我，堵耳朵！）…
如果您作为一名测试工程师，看了上述三种状况，感觉自己不属于任何一种，那么只有两种可能：一是您是超级高手——您聪明绝顶，有着可以大展宏图的工作机会，又有满意的薪资，而且对这一行业无限热爱…反正对您来说，一切都太完美了，无懈可击！二呢，也许您是个漠视一切、目空一切的家伙，天塌下来当被盖的那种，反正什么言论对您都无懈可击！为此，本人建议此两种人不看本文，以免互相拍砖，破坏安定团结的大好局面^-^。
好啦，气氛活跃至此止，以下是严肃话题。
如果您是个积极进取、想在年轻时成就一番事业的人，那么请绝对相信这几句话：
——行行出状元！
——人生能有几回搏！
——错过这村，就没这店了！
为此，有必要说明下这几句俗语在软件测试行业的应用。首先，我们国内的很多软件测试从业者，是对软件开发不太擅长，但是又对软件行业又由衷的热爱，所以做了软件测试。但苦于读书时候没有学习过该方面知识，公司里又不一定有经验丰富的人员给予指导；因此，初涉软件测试的年轻朋友，大多做了半年、一年，感觉自身技能提高并不大，再加上整体行业发展缓慢，和网上的同行一交流，更是感觉软件测试没有希望，自己的前途黯淡无光！无奈只好终日吟唱“我的天是灰色，我的心是蓝色…”常言道，“男怕选错行，女怕嫁错郎！”——当然如今男女平等了，尤其软件测试从业者，男女比例基本上还算对等——那么，是不是软件测试行业真的没前途？软件测试工程师真是低人一等呢？当然不是，而且绝对不是！和软件开发领域相比，测试发展不过短短的10来年，而且主要是近三五年，所以整体行业不成熟也就情有可原。但是换句话说，乱世出英雄！如果你学软件开发，你知道作为一名合格开发工程师需要学习什么，知道开发工程师的待遇如何，知道开发工程发展前景如何；但是测试行业还没有发展到让你足够看清这些东西的阶段，所以在软件行业中对于喜欢挑战性职业的人，那么软件测试绝对是个好的突破口。各种统计数据表明，国内软件测试的人才缺口，未来几年将达到30到40万，所以对于朋友们来说，干这行还是有相当大的发展空间！但是，如何在众多的从业者中独树一帜、成为行业状元呢？这就需要技巧了！
再说第二方面。记得有句歌词叫“无怨无悔我走我路，走不尽天涯路…”！如今这个年代，各行各业竞争都很激烈，很难再有90年代初猛然蹦出一批暴发户的机会；因此，不管你因为什么选择了软件测试行业，都要无悔的走下去，只要有决心和毅力，终会成就正果！网上有篇文章叫《不做浮躁的人》，说的很好，我想我们确实该脚踏实地的做些事情，提高自己。抱怨这个行业只会让心情更加压抑，投入的做些具体的事情，待到自己有足够能力的时候，那么你就是推动这个行业发展的先驱；如此一举多得的事情，干吗不做呢！做踏实的人，不做抱怨的人，就算我们改变不了这个世界，也不要在这个世界里迷失自我。换句话说，年轻时候不卖力做点事情，老来方悔则一切晚矣，回首这一生，碌碌无为，可怜、可叹…这也是我要说的“人生能有几回博”。
唱了这么多高调，鼓舞一下大家的气势。那么，究竟如何在国内的软件测试行业现状下找到一条适合自己发展、并能快速提高职业技能的捷径呢？
我想应该从测试工程师的职业生涯定位谈起。从宏观意义讲，软件测试可以划分为以下三个方面：
●软件测试管理：测试流程管理、测试职业管理，测试技能方法管理等
●软件测试技术方法：根据软件测试的不同阶段周期、不同测试类型、不同软件类型等，深入研究软件测试的技术及方法
●软件测试自动化：自动化测试流程、自动化测试管理、自动化测试工具等
软件测试大致分为以上三类，每类可细化为更多子方面，例如第二类根据测试类型还可细化为功能测试、性能测试、安全测试等，根据测试方法可细化为黑盒测试、白盒测试、灰盒测试等。因此，软件测试工程师的职业发展方向，也大致可以如此粗略分类，并逐渐细化。这里，之所以将软件测试自动化单独列出来，是考虑到软件测试自动化既包括技术方法方面，又包含管理方面；更重要的是，软件测试自动化是软件测试领域无法逾越的发展阶段，随着应用软件程序规模的不断扩大，业务逻辑的不断复杂，以及从业者相互协作关系的日益重要，在软件的测试活动里适当使用自动化测试是非常必要的；并且，这种思维已经逐渐在国内外众多软件企业的测试领导者头脑中定型，他们也都意识到自动化测试的种种优势，并都或多或少希望购买和培训自动化测试工具。我们接触的很多大中型软件公司，包括外企，甚至早就在内部实施自动化测试，其中以使用mercury loadrunner、quicktestpro以及testdirector等工具的企业用户居多。
这里我想对喜欢自动化测试或立志成为自动化测试工程师的同行朋友说点个人想法，并结合mercury自动化测试工具，推荐些许学习方法，以供大家参考。
1）如果你有过开发经验，哪怕一点点，并且一直以来从事的是功能测试工作，那么推荐你学习自动化功能测试工具，并在此方面深入研究下去。该职位待遇一般是本地城市手工测试工程师的两倍左右，如果到达高级自动化测试工程师职位，从事自动化测试设计或测试框架的开发，待遇会更高。Mercury公司的winrunner和quicktestpro，是目前最主流的自动化功能测试工具，学习二者的方法也很简单，只要懂得c语言和VBscrīpt即可。要深入学习，当然还要熟悉自动化功能测试的流程、管理及深层开发（包括测试框架、库函数等）。当前国内的应用软件开发，主流还是c/s与b/s两种架构，前者一般采用vb、vc、delphi、pb或java等开发，而winrunner工具对此类软件支持得比较好，很适合在这样的软件测试活动中采用自动化测试；后者一般是采用.net或j2ee技术开发的基于浏览器类软件，测试该类软件就非quicktestpro莫属了，它是mercury公司专门针对web程序的自动化测试工具。由于自动化功能测试工具品牌多，入门简单，因此，也是众多立志成为自动化测试工程师的首选。
2）作为一名软件测试从业者，我们知道执行性能测试，使用手工方式是无法想象的，因此借助工具来实现是非常必要的。目前业内存在两种现状：一是很多公司为了节约购买工具的成本或本身不要求软件性能指标而干脆不执行性能测试；二是由于性能测试是一门博大精深的技术工作，起步较高，因此这方面的高手不多，造成很多大中型软件企业或外企严重缺乏性能测试工程师！性能测试工程师待遇，一般是本地手工测试工程师的三倍甚至更多；我们接触的企业客户需求里，很多开价上万的性能测试工程师职位，竟然很难招到。随着软件开发技术越来越高深，业务逻辑越来越复杂，对软件的质量要求同样也会越来越高，软件一定会存在性能缺陷，因此对软件的性能要求也会随之而来；况且，软件的性能指标是软件用户手册里的重要组成部分，从正规测试流程上来说，凡是网络应用软件，不可不做性能测试！但是，从事性能测试的工程师，需要掌握太多的知识，包括计算机网络、数据库、操作系统、服务器等，而且还要有深厚的性能测试计划、设计、分析能力，以及丰富的性能测试经验，这些如果单靠个人的自行摸索，肯定是不太实际的。Mercury公司的loadrunner，是目前国际上性能测试工具的绝对领导者，具有百分之75的市场占有率；在国内，业界同行也都是提起性能测试首先想到loadrunner；因此loadrunner是在软件测试领域里立志成为一名合格的、优秀的性能测试工程师的朋友们的绝对首选。
3）如果你从来没有过软件开发经验，一直从事的只是手工测试，而且对软件测试的流程管理有着浓厚的兴趣，尤其对于那些从事测试的姑娘们！testdirector都听说吧？它集测试需求、测试用例、测试执行、软件缺陷管理于一身，将软件测试的整个流程统一管理，并支持异地分布式测试资源管理。和众多的软件测试同行接触，我们愈加发现一个问题，那就是我们很多的业界朋友，缺乏完整的、系统的软件测试知识体系，喜欢满足现状，而不去思考如何更加有效的实施软件测试活动，优化软件测试流程。针对这种现状，学习国外优秀的软件测试流程与管理经验，就理所当然了。而testdirector就是当前市场上最优秀的软件测试流程与资源管理的工具，目前本人还未见过一款测试管理工具集成如此众多功能（当然它的升级版quality center也是mercury公司的）。因此，掌握该款工具的使用，是立志成为软件测试管理者的一个非常必要的方面。
4）其他自动化测试领域，本文暂不讨论，例如白盒测试、特殊类型测试等。
那么，什么是开拓上述三种自动化测试职业的捷径呢？
答案很简单，如果你可以抛开世俗观念，考取mercury认证绝对是捷径！
下面我要向大家论证考取mercury认证的几大理由：
首先，mercury公司是软件质量保证工具开发商中的绝对领导者。下图是美国gartner公司的最新调查结果，位于坐标第一象限最右上角的就是mercury，图中还有其他我们熟知的几个公司，如IBM rational、compuware等，但是mercury长久以来，一直独占着软件测试工具提供商的领先地位，包括很多在华投资成立软件研发基地的外企，他们多数都是使用mercury测试工具。如果有了这个测试工具供应商的王者，那么，想要学习自动化测试工具，有什么理由不选择mercury呢？ 其次，拿本人经验来说，有了mercury工具的使用经验，即便将来所在公司不使用该款工具，那么再学习其他的工具也会相当顺手，不费吹灰之力！为什么呢？举例来说，比如loadrunner的网络协议是本人所接触的性能测试工具中，支持最多的（相信很多人会同意我这个观点），如果将来你打算换用webload、silkperformer（当然它们的局限性要比loadrunner大的多）等性能测试工具，绝对不会比loadrunner还复杂；再比如拿quicktestpro和其他针对web程序的测试工具（如qawizard、XDE Tester等）相比，使用更是完全类似（不了解的人可以到本人blog查看我的文章去亲自对比）。至于testdirector，更是独一无二的功能强大的测试管理工具，没的选择！
再次，如果你的眼光足够长远，能够看清未来软件测试中自动化测试的重要地位，那么你更应该选择。回想当年的思科认证，刚刚推出时候价格昂贵，但是依然有那么多的人去考。为什么呢？因为有大量的需求！认证通过的人过后都认为这笔投入值得！类比软件测试行业，虽然现在还没到达计算机网络行业发展的那样成熟，但是未来的两三年后，如果有一天到处都是自动化测试的人才需求，到时再临时抱佛脚，相信你不会有什么优势了。任何认证都是初期最有价值的，如果抓住机会在推广初期考取，等到这个认证普遍到一定程度，你已经有了几年的实用经验，所以优势仍在、风采依然！顺便提醒一句，计算机行业发展是相当快的，回首过去这3年，软件测试行业一直是在飞速前进的。如果错过如今这段大好时光，没有及时为自己充电，那么如今你这位软件测试新手，到了3年以后，依然是新手，只是比那时刚毕业的热血青年显得沧桑了一些… 所谓岁月不等人咧，这也是我前边要说的“过了这村就没这店啦”…
然后，我要说明为什么要考取mercury认证，而不考其他认证。理由很简单，本人一直坚定的认为软件测试是实用性学科，是实践性工作，重理论而不强调理论，不断实践同时积累经验，遵守规范并不断创新！如果你为了眼前一个工作机会而花点小钱，获得一个什么机构颁发的资格认证，尤其那种完全理论性的、满篇题目都是“负载测试与压力测试什么区别”之类的恶心至极的题目的考试，那么恕我直言，你真是鼠目寸光！试问这样的认证有什么用呢？哪个企业的老板会笨到雇用一个纸上谈兵的军师呢？况且你这个军师也是“墙上芦苇，头重脚轻根底浅；山间竹笋，嘴尖皮厚腹中空”！坦诚的说一句，为了应付这样的考试花2个星期背那些题目，都不如下载个试用版loadrunner，对照网上的使用手册练习一下工具的使用！
最后，我要说一个实际的问题，那就是money了。相比当年的思科认证、微软认证的上万元报名费，mercury认证的三千多、六千多，还是相当便宜的。最直白的说一句，如果你的眼下薪资有3k，花一个月或两过月的薪水买个“国际认证”，那么这件事绝对值得！当然，考取mercury认证的真正核心价值，完全是顺应软件测试自动化的时代潮流，掌握最先进的软件测试自动化技术和管理方法。
最最后，再为有志于考取mercury认证的同行朋友给予一点点建议。
如果你是初涉软件测试行业的测试工程师，没有或很少接触过自动化测试，那么可以从mercury认证的CPE（certification product education）开始，该认证是mercury认证的汉化版，通过者可以掌握mercury认证工具的完全使用。
如果你具有了3个月以上的mercury工具使用经验，英文能力还不错，或者通过了CPE考试，那么可以直接考取CPS(certification product specialist)，之后考取CPC(certification product consultant)。这两种考试都是英文，证书由美国mercury总部颁发，后者价值大于前者，考试难度也大于前者。并且，二者认证已经不限于工具本身的使用，而是结合了代表mercury公司作为软件测试行业龙头地位的先进、正规的自动化测试流程，其通过者也相当受大中型软件公司、尤其外企的青睐，当然这一需求也是我们在长期积累的企业客户关系中总结出来的。
详细mercury认证咨询，请登陆 www.51testing.com 查阅。
送上最后一句至理名言----“命运掌握在自己的手中”！如果你对一件事物犹豫不决的时候，那么请尝试学习《卡耐基成功之道》里介绍的方法，在纸上分别写下做此事的理由与不做此事的理由，如果此事的可行性是百分之五十一，那么就别再踌躇了，放心大胆的去做吧！时间会证实一切，因为你的确在进行着一件该行业前所未有的划时代式活动；记住，上帝宠爱勤奋的孩子，他会与你并行….（祝福ing）
（2005年7月5日于上海无空调的日子）
写在后面的话：决定写这篇文章的时候，已经知道没办法避免广告嫌疑了；因为本人就在51testing，而且国内仅此一家代理mercury认证！就算从职业道德上讲，也要维护本公司利益！不反对吧？再者，您真的认为本文就是个华丽的广告而已？^-^这是其一。
其二，注意我的措辞“如果你能屏弃对认证的世俗观念”，如果不能，对本文进行抨击也没有必要，怎么说我们也是同行！而且，我在文章最初也说了，如果你看了文章觉得让你血压升高，其实根本没必要看完的，对吧^-^
其三，我在文章强调考取该认证是个在测试行业快速成长和提高的快捷方式，不是必须！
其四，对于有朋友问的认证后有何用处，我觉得还是有很大好处的。在我们接触的众多企业客户里，还是很多大中型软件企业购买工具，实施自动化，但是想招一位自动化测试专家来在公司实施这件事，还是有很大难度，原因就是这样的人太少了。所以，我觉得如果你能经过该认证对自动化测试方面的系统培训并通过考试，面对此类人才需求，肯定还是有大展宏图的机会的（当然对此没兴趣的人，还是当我废话算了）。 -
软件测试的常识
2007-06-22 14:34:16
[来自张华老师的文章]软件测试的常识
软件开发和使用的历史已经留给了我们很多由于软件缺陷而导致的巨大财力、物力损失的经验教训。这些经验教训迫使我们这些测试工程师们必须采取强有力的检测措施来检测未发现的隐藏的软件缺陷。
生产软件的最终目的是为了满足客户需求，我们以客户需求作为评判软件质量的标准，认为软件缺陷（ Software Bug ）的具体含义包括下面几个因素：
• 软件未达到客户需求的功能和性能；
• 软件超出客户需求的范围；
• 软件出现客户需求不能容忍的错误；
• 软件的使用未能符合客户的习惯和工作环境。
考虑到设计等方面的因素，我们还可以认为软件缺陷还可以包括软件设计不符合规范，未能在特定的条件（资金、范围等）达到最佳等。可惜的是，我们中的很多人更倾向于把软件缺陷看成运行时出现问题上来，认为软件测试仅限于程序提交之后。
在目前的国内环境下，我们几乎看不到完整准确的客户需求说明书，加以客户的需求时时在变，追求完美的测试变得不太可能。因此作为一个优异的测试人员，追求软件质量的完美固然是我们的宗旨，但是明确软件测试现实与理想的差距，在软件测试中学会取舍和让步，对软件测试是有百益而无一弊的。
下面是一些软件测试的常识，对这些常识的理解和运用将有助于我们在进行软件测试时能够更好的把握软件测试的尺度。
• 测试是不完全的（测试不完全）
很显然，由于软件需求的不完整性、软件逻辑路径的组合性、输入数据的大量性及结果多样性等因素，哪怕是一个极其简单的程序，要想穷尽所有逻辑路径，所有输入数据和验证所有结果是非常困难的一件事情。我们举一个简单的例子，比如说求两个整数的最大公约数。其输入信息为两个正整数。但是如果我们将整个正整数域的数字进行一番测试的话，从其数目的无限性我们便可证明是这样的测试在实际生活中是行不通的，即便某一天我们能够穷尽该程序，只怕我们乃至我们的子孙都早已作古了。为此作为软件测试，我们一般采用等价类和边界值分析等措施来进行实际的软件测试，寻找最小用例集合成为我们精简测试复杂性的一条必经之道。
• 测试具有免疫性（软件缺陷免疫性）
软件缺陷与病毒一样具有可怕的 “ 免疫性 ” ，测试人员对其采用的测试越多，其免疫能力就越强，寻找更多软件缺陷就更加困难。由数学上的概率论我们可以推出这一结论。假设一个 50000 行的程序中有 500 个软件缺陷并且这些软件错误分布时均匀的，则每 100 行可以找到一个软件缺陷。我们假设测试人员用某种方法花在查找软件缺陷的精力为 X 小时 /100 行。照此推算，软件存在 500 个缺陷时，我们查找一个软件缺陷需要 X 小时，当软件只存在 5 个错误时，我们每查找一个软件缺陷需要 100X 小时。实践证明，实际的测试过程比上面的假设更为苛刻，为此我们必须更换不同的测试方式和测试数据。该例子还说明了在软件测试中采用单一的方法不能高效和完全的针对所有软件缺陷，因此软件测试应该尽可能的多采用多种途径进行测试。
• 测试是 “ 泛型概念 ” （全程测试）
我一直反对软件测试仅存在于程序完成之后。如果单纯的只将程序设计阶段后的阶段称之为软件测试的话，需求阶段和设计阶段的缺陷产生的放大效应会加大。这非常不利于保证软件质量。需求缺陷、设计缺陷也是软件缺陷，记住 “ 软件缺陷具有生育能力 ” 。软件测试应该跨越整个软件开发流程。需求验证（自检）和设计验证（自检）也可以算作软件测试（建议称为：需求测试和设计测试）的一种。软件测试应该是一个泛型概念，涵盖整个软件生命周期，这样才能确保周期的每个阶段禁得起考验。同时测试本身也需要有第三者进行评估（信息系统审计和软件工程监理），即测试本身也应当被测试，从而确保测试自身的可靠性和高效性。否则自身不正，难以服人。
另外还需指出的是软件测试是提高软件产品质量的必要条件而非充分条件，软件测试是提高产品质量最直接、最快捷的手段，但决不是一个根本手段。
• 80-20 原则
80% 的软件缺陷常常生存在软件 20% 的空间里。这个原则告诉我们，如果你想使软件测试有效地话，记住常常光临其高危多发 “ 地段 ” 。在那里发现软件缺陷的可能性会大的多。这一原则对于软件测试人员提高测试效率及缺陷发现率有着重大的意义。聪明的测试人员会根据这个原则很快找出较多的缺陷而愚蠢的测试人员却仍在漫无目的地到处搜寻。
80-20 原则的另外一种情况是，我们在系统分析、系统设计、系统实现阶段的复审，测试工作中能够发现和避免 80% 的软件缺陷，此后的系统测试能够帮助我们找出剩余缺陷中的 80% ，最后的 5% 的软件缺陷可能只有在系统交付使用后用户经过大范围、长时间使用后才会曝露出来。因为软件测试只能够保证尽可能多地发现软件缺陷，却无法保证能够发现所有的软件缺陷。
80-20 原则还能反映到软件测试的自动化方面上来，实践证明 80% 的软件缺陷可以借助人工测试而发现， 20% 的软件缺陷可以借助自动化测试能够得以发现。由于这二者间具有交叉的部分，因此尚有 5% 左右的软件缺陷需要通过其他方式进行发现和修正。
• 为效益而测试
为什么我们要实施软件测试，是为了提高项目的质量效益最终以提高项目的总体效益。为此我们不难得出我们在实施软件测试应该掌握的度。软件测试应该在软件测试成本和软件质量效益两者间找到一个平衡点。这个平衡点就是我们在实施软件测试时应该遵守的度。单方面的追求都必然损害软件测试存在的价值和意义。一般说来，在软件测试中我们应该尽量地保持软件测试简单性，切勿将软件测试过度复杂化，拿物理学家爱因斯坦的话说就是： Keep it simple but not too simple 。
• 缺陷的必然性
软件测试中，由于错误的关联性，并不是所有的软件缺陷都能够得以修复。某些软件缺陷虽然能够得以修复但在修复的过程中我们会难免引入新的软件缺陷。很多软件缺陷之间是相互矛盾的，一个矛盾的消失必然会引发另外一个矛盾的产生。比如我们在解决通用性的缺陷后往往会带来执行效率上的缺陷。更何况在缺陷的修复过程中，我们常常还会受时间、成本等方面的限制因此无法有效、完整地修复所有的软件缺陷。因此评估软件缺陷的重要度、影响范围，选择一个折中的方案或是从非软件的因素（比如提升硬件性能）考虑软件缺陷成为我们在面对软件缺陷时一个必须直面的事实。
• 软件测试必须有预期结果
没有预期结果的测试是不可理喻的。软件缺陷是经过对比而得出来的。这正如没有标准无法进行度量一样。如果我们事先不知道或是无法肯定预期的结果，我们必然无法了解测试正确性。这很容易然人感觉如盲人摸象一般，不少测试人员常常凭借自身的感觉去评判软件缺陷的发生，其结果往往是把似是而非的东西作为正确的结果来判断，因此常常出现误测的现象。
• 软件测试的意义 - 事后分析
软件测试的目的单单是发现缺陷这么简单吗？如果是 “ 是 ” 的话，我敢保证，类似的软件缺陷在下一次新项目的软件测试中还会发生。古语说得好， “ 不知道历史的人必然会重蹈覆辙 ” 。没有对软件测试结果进行认真的分析，我们就无法了解缺陷发生的原因和应对措施，结果是我们不得不耗费的大量的人力和物力来再次查找软件缺陷。很可惜，目前大多测试团队都没有意识到这一点，测试报告中缺乏测试结果分析这一环节。
结论：
软件测试是一个需要 “ 自觉 ” 的过程，作为一个测试人员，遇事沉着，把持尺度，从根本上应对软件测试有着正确的认识，希望本文对读者对软件测试的认识有所帮助。 -
[转]免于失业的十大软件技术
2007-06-19 23:50:37
你是一名正失业的软件技术人员?或许本文章的内容对您有所帮助!
技术仅仅是一种元素,新的技术总是曾出不穷，更重要的是你的学习能力和解决问题的能力。
下边让我们来看看这些免于失业的十大软件技术吧。
1. XML
首先，你要了解XML。我不是说仅仅是XML规格本身，还包括一系列相关的基于XML的语言：最重要的是 XHTML、XSLT、XSL、DTDs、XML Schema (XSD)、XPath、XQuery和SOAP。那些在过去5年内从未碰过键盘的人，可能不知道XML为何物。XML是一种文本文件，使用与HTML类似的标记。XML能定义一个树状结构，并能描述所含的数据。
XML最好的一点是既能存结构化数据也能存非结构化数据。它既能存贮和描述“规格的”(regular)表格数据，也能容纳和描述“粗糙的”(ragged)文件数据。
XHTML是现今写HTML的首选方法。因为它是形式完好（well formed）的XML，比起古老的、通常是畸形（malformed）的HTML文件，XHTML格式的文件更容易处理。
XSLT和XSL是用于把XML文件转成其它格式的语言。可转换的格式包括：文本文件、PDF文件、HTML、以逗号为分隔符的文件，或其它XML文件。 DTD和XML Schema描述XML文件所能包含的内容的类型，并让你“验证”XML文件内容的合理性，而不用写特殊代码以确保内容符合规则要求。
XPath和XQuery是用于从XML文件中抽取单个项目或一组项目的查询语言。XQuery扩展了XPath，因而更重要。XQuery与XML的关系正像SQL与关系数据库的关系。
SOAP是Web服务之间的一个标准通讯协议。尽管你不需要对SOAP标准一清二楚，你应该熟悉一般的schema和它的工作原理，以便能应用这门技术。
2. Web服务
Web服务是XML流行后的一个直接产物。因为你能用XML描述数据和物件，因为你能用schema确保XML文件内容的合理性，因为XML是基于文本的规范，XML为跨平台通讯标准提供了一个极其方便的基本格式。如果你还从来没碰到Web服务，你可能很快就会碰到，在未来5年内，你几乎肯定会碰到。熟悉Web服务十分重要，因为它是目前所有跨不同机器、不同语言、不同平台和不同地点的通讯协议中最简单的一个。不管你需要与否，Web服务是迈向互用性的重要一步。
XML工作组主席John Bosak曾说XML“给Java一些事做”。实际上，Web服务让所有语言都有了一些事做。Web服务让在大型机上运行的COBOL应用软件能调用在手持设备上运行的Java应用程序、能让Java applet与.NET服务器交谈、能让微机软件与Web服务器无缝连接，并提供了一个相对容易的方法，让企业不光能向外界提供数据，还能提供功能，而且是一种与语言、平台和位置都独立的方法。
3. 面向对象的编程
很多程序员仍认为OOP是象牙塔里的技术。但如果你想一下是什么语言在过去的10年里占主导地位，你就会理解OOP不是象牙塔里的技术。OOP从Smalltalk开始，传到C++和Pascal (Delphi)。Java使OOP大踏步地迈向主流，几年后的VB.NET和C#则完全确立了OOP的优势地位。尽管这些语言中的多数并不要求你必须会 OOP，但我觉得如果你不了解OOP的基本概念也不知道如何应用这些概念，你能找到的编程工作将越来越少。
4. Java、C++、C#和VB.NET
我把这些语言列在一起，并不是建议你成为每一种语言的专家。我的理由是：学习编程最有效的方法之一是看代码，而你能看到的大量的代码很可能不是用你所喜爱的语言编写的。
在过去几年，各语言的能力越来越接近。现在，你可以用VB.NET写Windows服务、Web应用程序或命令行程序。即使你只使用一种语言，你也应该学一些其它语言，以便能看懂那些样例，并将其翻译到你所用的语言。这4种语言是基本核心，还有其它一些满足不同需要、颇具用途的语言，如FORTRAN、 COBOL、APL、ADA、Perl和Lisp。
5. Javascrīpt
尽管名字有些相像，但Java 与Javascrīpt并无关联。为什么一个脚本语言会如此重要呢？因为所有主流浏览器都用Javascrīpt。如果你需要写Web应用程序，你就有足够的理由学Javascrīpt。Javascrīpt可以用作ASP或ASP.NET的服务器语言，也可以当做用于扩展XSLT的功能语言 (functional language)。Javascrīpt是Mozilla/Netscape中用于激活基于XUL的程序接口的首选语言。Javascrīpt的一个变种Actionscrīpt是Flash MX的编程语言。将来，Javascrīpt很可能成为新设备的编程语言，以及大型应用软件中的宏语言。
与Javascrīpt相对照的是VBscrīpt。尽管Microsoft的软件对VBscrīpt有良好的支持，但VBscrīpt在未来的开发工作中很可能是一个糟糕的选择。就是Microsoft也倾向于用Javascrīpt（或Microsoft自己的变种：Jscrīpt）写客户端程序。在选择脚本语言时，请选择Javascrīpt。
6. 正则表达式（Regular Expressions）
查寻关系数据库可以用SQL，查询XML可以用XPath和XQuery，查询纯文本文件则可以用正则表达式。例如，你可以用一个命令从一个HTML文件中查找并删除所有的注释。各种开发语言内置的一些简单的文本查询功能，如"IndexOf"函数或VB中经典的"InStr"函数或"Like"操作符，根本不能与正则表达式相提并论。现在，各种主要的开发语言都提供使用正则表达式的途径。尽管正则表达式本身既难懂更难读（是回到早期计算机时代的一种倒退），但它却是一个功能强大而且未被充分利用的工具。
7. 设计模式
正像OOP通过把对象分类以简化编程一样，设计模式对一些普遍的对象之间的交互进行分类，并赋予一个恰当的名称。OOP用得越多，设计模式就越有用。一些最常用的模式的名称已经变成了软件开发领域共同使用的术语，所以要跟上信息的主流，你就要对设计模式有相当的理解。
8. Flash MX
如果你需要在客户端得到比HTML和CSS更多的图形和更强的编程功能，Flash是你的答案。用Flash编程比开发Java applets或写.NET代码要快得多，也容易得多。
在最新版本 (MX) 中，Flash不仅仅是画图和制造动画的工具，它已经成为一个编程功能强大的开发环境：能调用SOAP Web服务，也能调用远端服务器上的ColdFusion、Java或.NET程序。Flash无处不在。它的引擎存在于世界上大多数客户端计算机，包括手持设备、置顶盒、甚至是新的书写板电脑。所以使用Flash能大大扩展你的程序的应用范围。
9. Linux/Windows
熟悉Linux。在一台旧机器或新机器上安装Linux。下载图形用户界面，在其基础上写一些程序。安装Apache，写一个Web应用程序。这个世界不再仅仅是属于Windows，这种趋势可能还会持续下去。如果你是一名中坚的Linux开发人员，那就抛弃你对Windows的憎恶，看看你能否做一些 Windows编程。Windows能继续在台式电脑上称王是有其原因的，这不仅仅是因为Microsoft控制了这个市场。
没人知道你们公司会在什么时候决定从Linux转向Windows（或从Windows转向Linux），或者你想跳到一家用另一种平台的公司，或者你想出了开发一个杀手软件的好主意，所以你要争取拥有在不同操作系统上的编程经验。
10. SQL
尽管SQL不像本文讨论的其它技术那样新，而且SQL的重要性在未来10年内很可能降低，但它仍然是一项基本技能。很多开发人员还没有掌握这门技术，或掌握得不够，不足以有效率地使用它。不要依赖具有图形用户界面的SQL生成器替你做事情，你要自己手工地写查询命令，直到你熟悉基本的SQL语法为止。了解SQL不仅能帮助你日后学习XQuery，你还有可能马上发现能简化或改进目前项目的方法。
培养好奇心
最后，（对，我意识到这是第11门技术），好奇心是你最重要的技能。要去尝试各种东西。新语言或新技术对你当前或将来的工作可能有用，也可能没用，但并不是你所学的每一件事都是为了工作。不要害怕失败，万事开头难，学新技术也是如此。大多数失败是因为人们希望太快地学到太多的东西。要对每一点进步感到满意，不要让时间（或缺乏时间）妨碍你。相反，你要安排时间留心、研究、试验新的开发技术和工具。
你可能永远也没有必要成为这些技术的专家，而且我的选择可能根本不适合你的特殊情况，但通过培养好奇心，你将会发现你应该了解的东西。
标题搜索
我的存档
数据统计
- 访问量: 6801
- 日志数: 12
- 建立时间: 2007-06-19
- 更新时间: 2008-05-29
