一直对网络机器人之类的东西比较感兴趣。可以实现定时登录某站点捞积分，还可以提高测试 Web 站点效率（虽然我目前不做这一块）。我目前了解的有以下几个实现途径：

　　（1） JavaScript

　 　所有主流浏览器对嵌入 JavaScript 的支持比较一致，对 JavaScript 暴露了 DOM 访问 API 以及浏览器操作 API。所以“JavaScript”这条路比较好走。但由于 JavaScript 不能访问本地文件（安全性考虑）等限制，我无法做“登录某站点后下载某文件”之类的操作。JavaScript 相关的 Web 自动化工具有：

　 　zope.testrecorder：一个跨浏览器 （IE， Firefox， Safari） JavaScript 程序，记录浏览器事件 （点击和输入文字等） 以及测试断言 （这个文本框应包含这个文字，那个复选框应不应被勾选等）。必须安装 Zope 这个 Web Server，再访问 zope.testrocoder 这个组件，然后输入任意 URL 开始记录测试。但是安装和配置 Zope 太麻烦了。需要配合 Selenium（一个开源的 Web 测试框架）或 zope.testbrowser（见下文）使用。

　　JsUnit：设计为测试静态或生成的 HTML 文档，不能与实际的 Web Server 交互。

　　（2） 控制浏览器

　　IE 和 Firefox 都提供了编程接口以便外部程序控制其行为。

　 　MSDN 给出了 IE 的 COM 接口以及 VB 控制 IE 的例子。pywin32 以 Python 包装了 COM 等机制，所以用 Python 操作 IE 也是可行的。PAMIE 对 pywin32 进一步包装，控制 IE 更加方便。关于 Python 的 COM 编程，请参考《Python Programming on Win32》一书。另外该书的 Chapter 21. Active Scripting 还描述了怎样把 Python 嵌入 IE（受限于安全性，嵌入 Python 不允许导入任何模块，所以并不能提供比 JavaScript 更多的功能）。另外注意： IE 7 及以上版本默认不允许 COM 控制，这样打开：Tools –> Internet Options –> Security –> Security for this zone 修改为"Medium"。

　　XPCOM 是访问 Gecko 库、嵌入或扩展 Gecko 的方法。PyXPCOM 包装了 XPCOM 机制。FireFox 等以 Gecko 作为 Web 排版引擎，所以可以通过 XPCOM 来控制它们。这方面资料较少，我至今还没有在 Google 上发现通过 PyXPCOM 控制 Firefox 的例子。

　　（3） 模拟浏览器

　　浏览器的重定向、表单和 Cookie 等行为比较好模拟，但 Frame、DOM 访问、JavaScript 和 JavaApplet 等就越来越难模拟了。以下按照模拟能力降序排列：

• HttpUnit（Java 实现，配合 JUnit）：支持基本 HTTP 认证、简单的 JavaScript。
• zope.testbrowser 是一个 Zope 组件但可脱离 Zope 单独使用。支持简单 DOM （含表单）、Cookie、定制 HTTP 请求。
• WebUnit（Python 实现，配合 PyUnit）：DOM 方面仅支持表单，其他能力与 zope.testbrowser 相当。
• twill（Python 实现）：模拟能力与 WebUnit 相当。
• Python 3 标准模块 urllib（基于更底层的 http.client 模块）和 http.cookiejar 等配合起来支持基本的定制 HTTP 请求、Cookie。标准模块 html.parser 解析 HTML，可能需要 python-utidylib 做 HTML 整理。

　　（4） 宏记录鼠标点击坐标和时间然后重放

　　这个方法受 Web 页变化影响很大，且测试逻辑不明确，所以这方式的测试用例几乎无法维护。许多商业的 Web 测试软件就是这一类。

　　自动化的最终目标是什么？

　　很多人以为是像工业革命一样消灭手工劳动者，在这里等于手工测试人员。但是测试存 在一个目前来看还算正确的、其他行业不多见的悖论：任何时候，你都不能准确知道还有多少bug，就像警察不能准确知道还有多少贼一样。所以自动化的最终目 标——目前来说——是解放尽量多的人手去进行更多的测试，除非有一种手段能像《少数派报告》里面的预言少女一样预知所有的bug。因为永远有bug，有未 知的bug，所以目前不存在能覆盖所有bug的手段，这意味着总需要人的参与。现代化手段只是减少了而不是杜绝对人员的需求。所以如果认为自动化工作一做 完就没活干，那你就大错特错了。正认为这些人闲下来，他们有空发现更难发现的bug。这本来没什么大不了的，但是搁在计划阶段如果过分乐观，牛皮吹得太大 的话，到后面就不容易圆回去了。因为按上面分析，自动化测试总有些地方是力有不逮的，如果这些地方没有安排好人手时间，只要在这些地方出大问题，那你就玩 完了。

　　能否/怎样自动验证？

　　这个问题每次复审测试计划的时候我都会问，针对每一个提出要实施自动化的地方。每个人、每个工具 谈论自动化的时候都在说如何真实模拟用户使用产品的情况， 这很好，绝对需要关心。不过我得问一句：测试的最后结果是什么？如果你回答“各种使用产品的场景已经运行过“就嘎然而止的话，你就漏掉了一大块：最起码还 得加上“产品能工作/不能工作“！所以模拟用户使用产品的各种情况，只是解决上述问题的第一部分；如何得出测试通过/不通过的最终结论，才是解决问题第二 部分的基础部分，还有详细缺陷描述、上下文数据收集等没做到呢！

　　所以让机器像人一样使用产品，并没有解决全部问题，剩下的事情还有多少，这是需要视情况而定的。如果只是解决了第一个问题就认为万事大吉，那简直就是在赌运气——有些时候自动验证是小菜一碟，但很多时候不是。

　　令事情恶化的是，自动验证了产品的一些指标，并不能反映产品的真实质量。有时验证过的指标通过 了，其实其他地方暴露了问题却没有检查：比如说界面说没有查询结果，这是期望的，实际上查询请求根本没有发过去，不去检查底下做了什么的话是发现不了这种 bug的；有时验证过的指标不通过，其实只是个小问题，大问题需要通过别的指标暴露出来的：比如说返回结果跟预期的不一致，实际上该有的都有，只是没有排 好顺序而已，但是被标记成重要的测试用例没有通过，把开发人员搞个鸡飞狗跳。

　　这个话题深入下去，那就涉及到白箱测试策略、逻辑推演、嗅探和代码注入以及布景伪造（environment mockup）等领域，但我想强调的只是，如果考虑自动化测试，自动验证绝对不是可忽略的问题。

　　整合现有还是自力更生？

　　这个话题用于辩论赛是最好不过的，它符合“没有定论“这个要求 。所以我只谈一下使用每种手段时的一些不正确的假设。

　　“现有的工具多少经过测试，质量比自己做的更有保证“。先不在“是不是更有保证”这个话题上钻牛 角尖，我们先关注几个问题：整个测试方案里面哪些部分是关键，质量不好会导致致命后果的？这些部分有专人保证质量吗？出事的时候反应时间和修复效果如何？ 如果这些问题的答案是“我充分了解”或者“没问题”，那我也同意这个观点（我敢打赌，回答“不清楚”或者“很不妙”的人已经跑去重新考虑整个测试方案 了）。

　　“整合现有的工具省时间和人力”。类似的几个问题：你能在这些工具中自由地调试产品的缺陷吗？整合方案能适应产品的演变吗？几个月后呢？几个版本后呢？有需要变动的话代价多少？（哗啦啦又跑掉一大队人了）

　　“自力更生好控制”。投入产出比如何？引用的技术可靠吗？如果你是开发者（之一），别人都觉得好控制吗？谁来测试你的自力更生成果？

　　“有些事情必须得自力更生“。剪裁现有工具难度如何？时间允许吗？

　　其实，纵观所有提出的问题，我想强调的一点是，自动化测试的开发跟产品开发一样，也是需要规划和管理的，回答这些问题也是自动化测试项目管理的一部分。

　　如何解决历史遗留问题？

　　折腾上个版本的自动化测试框架是新人最头疼的事情。但了解了一些事情之后，原先的事情就没那么令 人头疼了。很多人忙于了解旧框架本身，其实世界一直在变，现在项目需要解决的问题才是关键。无论上个版本的东西多么辉煌，只有它适合现在的项目（的部分） 才是有价值的。所以关于旧的自动化测试技术，了解什么能用得上，而不是了解它是什么，才是需要做的事情。就好像汽车修理工知道怎样拆旧车零件来修新车，并 不需要他知道怎样造一辆出来或者知道怎样修好旧的那辆。

　　另一个极端是“旧的不好浪费，继续用“。“能用“这个结论是基于以前项目的情况的，现在能不能用，值不值得用得看现在的需求。人们要理发就是个很好的例子：总不能因为头发长出来要耗养分不好浪费，就一辈子都不剪吧？

　　本文介绍了基于B/S模式的软件缺陷跟踪管理系统的设计与实现。软件缺陷是在软件生命周期中不可避免的对象。缺陷跟踪管理是软件管理的重要组成。现有管理方法是将进入到系统中的问题,都认为是软件缺陷进行处理。但是实际情况却可能有虚假或重复的缺陷报告。不及时处理这些问题,它本身又可能形成新的缺陷。从软件系统考虑,应将软件缺陷跟踪管理纳入到项目管理信息系统之中,成为项目管理信息系统的一个子系统。对维护人员提交的缺陷报告认真鉴定、筛选、分类,进入不同的处理流程,以获得真正的缺陷跟踪数据。本文在分析讨论这些问题的基础上,提出新的软件缺 陷跟踪管理系统的总体结构。

　　软件缺陷跟踪管理系统在现代软件开发中已经占据了很重要的位置。每一个软件组织都知道必须妥善处理软件中的缺陷。这是关系到软件组织生存、发展的质量根本。可遗憾的是，并非所有的软件组织都知道如何有效地管理自己软件中的缺陷。CMM及CMMI都对软件缺陷跟踪给予了关注并做出了相关规定。本文的侧重点放在了讨论这个程序的需求分析、设计、实现及所用到的项目管理知识。借着实现这个简单的缺陷跟踪系统，探讨了个人软件开发过程当中遇到的各种问题，以及解决它们的方法，展示了个人软件开发的一般过程。

　　缺陷跟踪管理是测试工作的一个重要部分，测试的目的是为了尽早发现软件系统中的缺陷，因此，对缺陷进行跟踪管理，确保每个被发现的缺陷都能够及时得到处理是测试工作的一项重要内容。

　　1、 缺陷跟踪管理的目标

　　缺陷能够引起软件运行时产生的一种不希望或不可接受的外部行为结果，软件测试过程简单说就是围绕缺陷进行的，对缺陷的跟踪管理一般而言需要达到以下的目标：

　　确保每个被发现的缺陷都能够被解决；这里解决的意思不一定是被修正，也可能是其他处理方式（例如，在下一个版本中修正或是不修正），总之，对每个被发现的BUG的处理方式必须能够在开发组织中达到一致；

　　收集缺陷数据并根据缺陷趋势曲线识别测试过程的阶段；决定测试过程是否结束有很多种方式，通过缺陷趋势曲线来确定测试过程是否结束是常用并且较为有效的一种方式。

　　收集缺陷数据并在其上进行数据分析，作为组织的过程财富。

　　上述的第一条是最受到重视的一点，在谈到缺陷跟踪管理时，一般人都会马上想到这一条，然而对第二和第三条目标却很容易忽视。其实，在一个运行良好的组织中，缺陷数据的收集和分析是很重要的，从缺陷数据中可以得到很多与软件质量相关的数据。

　　2、 缺陷的描述

　　对缺陷的描述应该包含以下的内容： 可追踪信息

　　缺陷ID：唯一的缺陷ID，可以根据该ID追踪缺陷

　　缺陷基本信息

　　缺陷状态：缺陷的状态，分为“待分配”、“待修正”、“待验证”、“待评审”、“关闭”

　　缺陷标题：描述缺陷的标题

　　缺陷的严重程度：描述缺陷的严重程度，一般分为“致命”、“严重”、“一般”、“建议”四种

　　缺陷的紧急程度：描述缺陷的紧急程度，从1－4，1是优先级最高的等级，4是优先级最低的等级

　　缺陷提交人：缺陷提交人的名字（邮件地址）

　　缺陷提交时间：缺陷提交的时间

　　缺陷所属项目/模块：缺陷所属的项目和模块，最好能较精确的定位至模块

　　缺陷指定解决人：缺陷指定的解决人，在缺陷“提交”状态为空，在缺陷“分发”状态下由项目经理指定相关开发人员修改

　　缺陷指定解决时间：项目经理指定的开发人员修改此缺陷的deadline

　　缺陷处理人：最终处理缺陷的处理人

　　缺陷处理结果描述：对处理结果的描述，如果对代码进行了修改，要求在此处体现出修改

　　缺陷处理时间：缺陷处理的时间

　　缺陷验证人：对被处理缺陷验证的验证人

　　缺陷验证结果描述：对验证结果的描述（通过、不通过）

　　缺陷验证时间：对缺陷验证的时间

　　缺陷的详细描述：对缺陷的详细描述；之所以把这项单独列出来，是因为对缺陷描述的详细程度直接影响开发人员对缺陷的修改，描述应该尽可能详细

　　测试环境说明：对测试环境的描述

　　必要的附件：对于某些文字很难表达清楚的缺陷，使用图片等附件是必要的

　　除上述描述项外，从统计的角度出发，还可以添加上“缺陷引入阶段”、“缺陷修正工作量”等项目。

　　3、 缺陷管理的一般流程

　　缺陷管理的流程比较简单，图1是一个缺陷状态图。

　　流程中的角色：

　　1、 测试人员：进行测试的人员，缺陷的发起者；

　　2、 项目经理：对整个项目负责，对产品质量负责的人员；

　　3、 开发人员：执行开发任务的人员，完成实际的设计和编码工作；

　　4、 评审委员会：对缺陷进行最终确认，在项目成员对缺陷达不成一致意见时，行使仲裁权力。

　　缺陷的状态

　　1、 初始化：缺陷的初始状态；

　　2、 待分配：缺陷等待分配给相关开发人员处理；

　　3、 待修正：缺陷等待开发人员修正；

　　4、 待验证：开发人员已完成修正，等待测试人员验证；

　　5、 待评审：开发人员拒绝修改缺陷，需要评审委员会评审；

　　6、 关闭：缺陷已被处理完成。

　　4、 缺陷数据统计

　　如前所述，缺陷数据统计也是缺陷跟踪管理系统的目标。一般而言，生成的缺陷数据统计图表包括缺陷趋势图、缺陷分布图、缺陷及时处理情况统计表等。

　　5、 缺陷跟踪管理系统

　　目前已有的缺陷跟踪管理软件包括Compuware公司的TrackRecord软件（商业软 件）、Mozilla公司的Bugzilla软件（免费软件），以及国内的微创公司的BMS软件，这些软件在功能上各有特点，可以根据实际情况选用。当然， 也可以自己开发缺陷跟踪软件，例如基于Notes或是ClearQuese开发缺陷跟踪管理软件。我公司采用的是自己开发的基于Notes的缺陷跟踪系统，除了具有上述功能外，还能够通过Notes的邮件系统方便地向相关人员发送提醒信息（缺陷处理超时提醒、缺陷待处理提醒等）。

　　除此之外，作为一个缺陷跟踪管理系统，还必须注意权限分配的问题。缺陷记录作为软件开发过程中的 重要数据，不能轻易被删除；对于已经关闭的缺陷，也不能随意进行修改。因此，缺陷跟踪管理系统必须设置严格的管理权限，非相关人员不得进行相应操作，修改相应数据。在这一点上，通过Notes也很容易控制。

循序渐进学习QTP–初级篇

      我们使用QTP的目的是想用它来执行重复的手动测试，主要是用于回归测试和测试同一软件的新版本。因此你在测试前要考虑好如何对应用程序进行测试，例如要测试那些功能、操作步骤、输入 数据和期望的输出数据等。
      强烈建议你按照版主oldsidney 写的 Tutorial_oldsidney_cn.pdf 文件来认认真真、从头到尾地执行一遍，包括录制脚本、分 析脚本、增加check point、Split Action等。我想这会减少你在学习QTP过程中的不少困惑和疑虑。
      这篇文档对如何使用QTP写的非常详细，是QTP初学者的经典教材。我就是看了这篇文档后才对QTP的整个测试流程有了一个初步的认识。在此，我对 oldsidney表示感谢。
     注意：
      1，确保你的IE运行正常，依次点击菜单 查看 –> 工具栏，一定要上网助手等插件卸载掉，特别3721这个垃圾网站和其它拦截广告的插件（它也把测试过程中弹出的窗口当成广告，一样会拦截的！）！
    2，如果是按照Tutorial_oldsidney_cn.pdf 文件 中的订购飞机票的例子来练习 QTP的使用，那么只需选择Web 插件就可以了。如果是测试其它的应用程序或系统，就要根据需要来选择相应的插件了。

循序渐进学习QTP—中级篇
在这个阶段你就要自己针对某个系统去录制脚本、维护脚本了。在录制后的回放过程中，你可能会遇到各种问题，这个时候就需要发挥你的主观能动性来解决遇到的 问题。我想你可以按照下面的方法去解决：

       1，查看QTP的有关文档，包括Help 、QTP User’s Guide等文档。这些都是比较系统全面的学习材料。你该好好利用呀。
       2，在本论坛上查看以前别人是如何解决此类问题的（如果有的话）或者是发新贴寻求帮助，也可以搜索Google 等网站寻找问题的解决方法；
      3，与自己部门的同事交流，例如与测试人员交流他们是如何解决的，与开发人员交流某个QTP无法识别的控件具体是用什么属性 来识别的等。毕竟他们对测试的环境和测试的软件比论坛上的人熟悉呀。
      4，自己通过学习VBScript 等方式来提高自己的管理QTP Script的能力。

或许你会发现许多问题都是由提出问题的人来解决的，因为他们希望问题得到解决的迫切心比谁都强烈。

循序渐进学习QTP—高阶篇
如果你对VB Script 、QTP和需要测试的程序或系统非常熟悉，你可能就想直接写QTP Script来表现一下了。如果你能达到这个水平，那么恭喜你－－－你就是真正的高手了。这个时候你已经可以从宏观上把握QTP了，也能灵活自如地使用 QTP了。偶离这个阶段还好远呢。

　增加、编辑、删除等功能，几乎每个系统都会用到，针对这几个方面，写如下测试用例

一：增加

1：在添加页面，输入要添加的数据项均合理，检查数据库以及列表页是否添加了相应的数据

2：在添加页面，留出一个必填项为空，检查是否会提示

3：按照边界值等价类设计测试用例原则设计其他输入项测试用例

4：不符合要求的地方要有错误提示

5：是否支持table键

6：按enter是否能保存

7：若提示保存，也要查看数据库里是否多了一条数据

二、删除

1、删除一个数据库中存在的数据，然后查看数据库以及列表也中是否删除

2、删除一个数据库中并不存在的数据，看是否有错误提示，并且数据库中没有数据被删除

3、输入一个格式错误的数据，看是否有错误提示，并且数据库中没有数据被删除

4、输入正确数据前加空格，看是否能正确删除数据

5、不输入任何字符

6、是否支持table键

7、是否这次enter键

三、编辑

1：对编辑列表页中的每个编辑项进行修改，点击保存，查看是否编辑成功

2：依次对每个编辑项进行修改，点击保存，查看是否编辑成功

3：对于必填项，我们可以修改为空、全角/半角空格，点击保存时，查看是否编辑成功

4：现在很多编辑项目中有很多图片预览的功能，如果对于没有上传的图片，查看编辑页面时，是否显示默认图片。如果上传了图片，是否显示上传的图 片。（因为实际工作中，很多客户很介意这个节目图片显示红叉）

5：在编辑的时候，也要注意添加时，每个编辑项的长度校验，有些时候，添加时有长度限制，而编辑的时候却没有

6：在编辑的时候，查看界面的字段是否同添加时字段显示一致，以及冒号是否也一致（无论是中文冒号或者是英文冒号，但是必须要一致）

四、密码修改

实际当中，根据具体情况具体分析，实际测试中可能只用到几条而已，例如：银行卡密码的修改，就不用考虑英文和非法字符，更不用考虑tap之类的快捷键

有时，需要根据需求具体分析了，例如：连续出错多少次出现的提示，和一些软件修改密码要求一定时间内有一定的修改次数限制等。

1、旧密码、新密码、确认新密码都为空时，查看系统是否会有提示

2、不输入旧密码，直接改密码

3、输入错误的旧密码

4、不输入确认新密码

5、新密码和确认密码不一致

6、新密码中有空格

7、新密码为空

8、新密码为符合要求的最多字符

9、新密码为符号要求的最少字符

10、新密码为符合要求的非最多和最少字符

11、新密码为最多字符-1

12、新密码为最多字符+1

13、新密码为最少字符-1

14、新密码为最少字符+1

15、新密码为非允许字符（例如：密码要求是英文和数字组成，则要试汉字和符号等）

16、看是否支持tap和enter键等

17、密码是否可以复制、粘贴，是否以*之类的加密符号

18、看密码是否区分大小写，新密码中英文小写，确认密码中英文大写

19、新密码和旧密码一样能否修改成功

　　那我说一下我的看法吧。因为大家都是搞测试的，这里我也只谈测试。

首先，我们可以有两条路发展，技术和管理。管理就是做team lead， manager， director这么走。因为我没有走这条路，所以，我这里也只谈技术。而且，即使走管理，也是应该具备很强的技术能力才行，所以技术是我们的发展之本。我个人不喜欢技术不精通的领导，也不喜欢被这种人管理。

技术的发展是分阶段的，基本上你要是能发展到最后的阶段，工作，钱，房子，车子，老婆都不用发愁了。当然要一步一步走，不可能一步升天，而且一路走过来也不是很容易，应该说大部分人可能都达不到。不过只要你肯努力，坚持不懈，就一定能达到。

第一阶段：就是基本功的问题。这个阶段从大学入学就开始了，我接触不少人工作几年都没有达到要求。这个要求是一定要达到的，不然以后没法往高发展。大学的一些课程一定要学好，主要是数据结构，算法，数据库，操作系统，计算机网络。争取精通两门。数据结构，算法对软件开发非常的重要，很多大公司面试就考这些。你不过关，根本通过不了面试，一两道算法题一下就把你难住了。另外，我可以告诉你，顶尖公司的面试80%都是考算法，你有没有经验不要紧，做没做过项目不要紧。关键是考察你的基本功，基本功打好了，其他工作就都容易很多了，基本功打不好，什么都白说。操作系统，争取要精通windows或者linux内核，看你走哪条路了，我是搞windows的，不过他们之间很多地方也是相通的。计算机网络，争取精通TCP/IP协议。数据库我不怎么懂，我的理解是要精通oracle， sqlserver， 还有sql编程。

另外就是编程技术了。C，C++，面向对象一定要搞懂，搞熟。大公司面试的算法就是要你用C/C++实现的。这些搞熟了，学习其他语言就是几个小时的事情。（我指的是上手，不是精通）。这些东西搞不透，不管你其他语言用多少年，回来学他们还是难。

再有就是英语水平了，听说读写，各个方面都要达到要求。技术到了一定程度，英语对你的发展就起到了非常决定性的作用了。你英语好，就可以去外企，就可以外派出国，甚至国外发展。

以上这些都是在大学应该掌握好的。当然了，能在大学掌握好这些的毕竟是少数。这些少数人就是去了微软，google的那些，一毕业就拿到月薪上万工资的。大部分人都是达不到要求的，这没关系，毕业后一定要找时间把这些基本功补上。不然的话，在下个阶段的发展就很受限制了。

第二阶段：计算机知识的扩展，行业知识的精通。这个阶段从你大学毕业走向第一个工作岗位开始。工作之后，发现计算机的世界比大学的知识要博大精深很多。一开始工作，就要拼命吸收以前没有接触过的，新的知识。这个就不多说了，大家都会有很多感受的，会觉得很多东西都不会，不会就学。以后你跳槽去面试，人家就会看你工作几年，这几年干什么了。工作1，2年之后，很重要的一件事情就是要选择一个行业了。也许是你现在正在从事的行业，也许是一个新的行业。总之，你自己要为自己规划，选择一个适合自己，而且又热门，以后有发展的行业。无论是现在的行业，还是跳槽到一个新的行业，都需要你开始积累在这个行业的经验了，要精通这个行业。有这个基础之后，就要去这个行业里top的公司了，国企，外企都可以，一定要有名气，大公司。比如，通信的华为，搜索的百度，等等。如果你精通了这个行业，去这些公司不是很难。

另外有一点很重要，如果你本科不是一所名校毕业的话，争取能上一个名校的研究生，全职，兼职都可以。这样可以为下一阶段做好充分的准备，否则的话会有比较大的困难。总之了，是自己的短处都要想办法去弥补，不然发展总会受限制。

第三阶段：国际著名大公司。有了前两个阶段的积累，加上自己的英文水平，就要找机会进入国际的大公司了。相信这个时候就会有很多猎头来联系你了。选择你这个行业的世界前3，最好是第一或者第二。进去之后要学习两个方面，一是英文，中国人可以学一辈子英文的。另外一个就是大公司的管理。可以这样说，国际大公司的管理有很多类似的地方，因此他们的招聘非常愿意招其他国际大公司的职员。这就是为什么，你一旦踏上一家公司，一辈子都不用愁工作了，可以在这些大公司跳来跳去，工资节节高。到了这个阶段，你基本上可以有个比较不错的生活了，房子，车子都不会是太大的问题。

第四阶段：向国际化发展。如果你还不满足，觉得自己还有能力更进一步，那我就建议你向国际化发展了。中国的工资毕竟有限，到了第三阶段也不过就是20万左右，你可能还不满足。那么你就可以联系国外的公司了，有了你的英文，你的经验，你的背景，到时候就是水到渠成了。我相信国际的猎头也会盯上你的。

最后说一下，如果你现在已经具备了我所说的各个阶段的能力，那么你的简历是任何公司都很难拒绝的了。因为目前的情况，具有这些素质的测试人员在世界都紧缺。很多公司都招不到人，即使连google，MS也不列外。他们都在到处寻找这种人。

最后说一下测试。我一直没有讨论测试的问题，因为我一直没有把测试当作一个难得东西来看待。我认为测试是表面上的，我前边提到的东西要比它重要的多。欢迎大家一起来讨论。我也是进入测试才2年多的时候，其中大多数的时间也像大家一样的迷惘，很多时候也很悲观。不过通过自己的努力，最后终于得到了一个满意的结果。我发现自己对测试这个行业的理解和很多人都不同，希望我的理解能给大家一点帮助。

　　软件测试使用各种术语描述软件出现的问题，通用的术语如下：

● 软件错误（software error）

● 软件缺陷（software defect）

● 软件故障（software fault）

● 软件失效（software failure）

区分这些术语的概念很重要，它关系到测试工程师对软件失效现象与机理的深刻理解，而这些概念尝尝在文献中被混淆。

由于软件内部逻辑复杂，运行环境动态变化，且不同的软件差异可能很大，因而软件失效机理可能有不同的表现形式。但总的说来，软件失效机理可描述为：软件错误→软件缺陷→软件故障→软件失效。

① 软件错误：在可以预见的时期内，软件仍将由人来开发。在整个软件生存期的各个阶段，都贯穿着人的直接或间接的干预。然而，人难免犯错误，这必然给软件留下不良的痕迹。软件错误是指在软件生存期内的不希望或不可接受的人为错误，其结果是导致软件缺陷的产生。可见，软件错误是一种认为过程，相对于软件本身，是一种外部行为。

② 软件缺陷：软件缺陷是存在于软件（文档、数据、程序）之中的那些不希望或不可接受的偏差，如少一逗点、多一语句等。其结果是软件运行于某一特定条件时出现软件故障，这时称软件缺陷被激活。

③ 软件故障：软件故障是指软件运行过程中出现的一种不希望或不可接受的内部状态。譬如，软件处于执行一个多余循环过程时，我们说软件出现故障。此时若无适当措施（容错）加以及时处理，便产生软件失效。显然，软件故障是一种动态行为。

④ 软件失效：软件失效是指软件运行时产生的一种不希望或不可接受的外部行为结果。

综上所述，软件错误是一种认为错误。一个软件错误必定产生一个或多个软件缺陷。当一个软件缺陷被激活时，便产生一个软件故障；同一个软件缺陷在不同条件下被激活，可能产生不同的软件故障。软件故障如果没有及时的容错措施加以处理，便不可避免地导致软件失效；同一个软件故障在不同条件下可能产生不同的软件失效。

在软件生存期中存在和产生形形色色的软件错误、缺陷、故障和失效。不同的软件，其错误、缺陷、故障和失效无论在表现形式、性质乃至数量上都可能大不相同，试图对它们作一个全面而详细的阐述是不现实的，所以有必要加以区别对待。关于“错误”的广义定义是：不正确的事务和行为。在 1999年 （美）John D. Musa的《软件可靠性工程》书中，关于“软件错误”是这样描述的：“错误是在系统运行时，引起或可能潜在地引起失效的缺陷，是一种面向开发的概念。”例如，当用户单击某个具体的菜单时，本应在屏幕上出现特定的对话框，但是却没有出现。这种行为就是一个失效。造成这种失效的错误可能是遗漏代码。这里给出的定义是“电气与电子工程师协会（IEEE）”和“美国标准协会（ASA）”的标准，是通过引起失效和错误的系统成分，来定义失效和错误的。这些成分一般是硬件、软件和人。

John D. Musa（1999年）对软件错误的定义是：软件错误是代码中的缺陷，是由错误引起的，是由一个或多个人的不正确或遗漏行为造成的。例如，系统工程师在定义需求时可能会犯错误，从而导致代码错误，而代码错误又导致在一定条件下执行系统时出现失效。“缺陷”是指欠缺或不够完备的地方。软件的欠缺和不完备主要是针对产品说明书而言的。2001年（美）Ron Pttern著的《软件测试》一书对软件缺陷进行了定义。按照一般定义，只要软件出现的问题符合下列5中情况的任何一种，就叫做软件缺陷：①软件未达到产品说明书中标明的功能；②软件出现了产品说明中指明的不会出现的错误；③软件功能超出了产品说明书指明的范围；④软件未达到产品说明书虽未指出但应达到的指标；⑤软件测试人员认为软件难以理解、不易使用、运行速度慢，或最终用户认为不好用。实践表明，大多数软件缺陷产生的原因并非源自编程错误，主要来自于产品说明书的编写和产品方案设计。

产品说明书称为软件缺陷的罪魁祸首，是因为产品说明书编写的不全面、不完整和不准确，而且经常更改，或者整个开发组织没有很好地沟通和理解。这也就是出自于软件需求说明书本身的问题，或开发人员对需求说明书的理解与沟通不足。

软件缺陷的第二大来源是设计方案，也就是软件设计说明书。这是程序员开展软件计划和构架的地方，就像建筑师为建筑物绘制蓝图一样。这里产生软件缺陷的原因与产品说明书或需求说明书是一样的，片面、多变、理解与沟通不足。

总之，软件缺陷是开发的软件与软件需求说明书、设计说明书的不一致：软件的实现未满足应达到目标的用户潜在需求。故障是指一个实体发生障碍和毛病。软件故障在ISO14958软件产品评价标准中的定义是：计算机程序中的不正确的步骤、过程或数据定义。

软件故障是指软件运行过程中出现的一种不希望或不可接受的内部状态，软件出现故障若无适当措施（容错）加以及时处理，便产生软件失效。显然，软件故障是一种动态行为。

在软件设计和编程过程中，花费很大的精力确保软件系统能从各种故障导致的失效中恢复。当遇到软件出现故障时，系统不能像软件设计和用户要求那样运行而导致失效，就需要有故障恢复措施，以保证故障恢复后的继续执行。软件失效是系统行为对用户要求的偏离，是一种面向用户的概念。这就是说，失效意味着系统的运行。只有在执行程序过程中才会发现软件失效，发现潜在的失效可以是设计审查、代码阅读和其他方法产生的结果。有的项目组还把文档错误计算在软件错误之内，这一般是不正确的，因为文档并不直接影响程序的执行。因为用户接受的是程序使用的错误信息，文档错误可能会导致用户的失效。但是，用户并不是软件成分，不能把用户看成是与失效和可靠性有关的单独的系统成分。

对失效严重程度进行分类，主要是为了结合失效频率来解决失效优先级的确定。常见的分类标准包括对人员生命、成本和系统能力的影响。失效强度常常应用于软件可靠性工程中，最初是指单位时间内的失效次数；基于软件大量的使用经验，失效强度表示为每个自然单元出现的失效数目更加方便。失效强度是表示可靠性的另一种形式。

关于概念不可能彼此分得很清楚，实际上也没有太大的必要。目前软件测试界一般主要使用缺陷（defect）和错误（error）这两个词。在测试过程中，我们找到的错误会有不同的类型，对错误的分析与管理是十分重要的。

　对于测试用例我自己的理解为：测试用例将软件测试的行为活动，做一个科学的组织归纳的过程，简 单地说，测试用例就是设计一个情况，软件程序在这种情况之下，必须能正常运行并达到程序所设 计的执行结果；测试用例描述了按一定的顺序执行的并与测试目标相关的测试活动，它明确的是“怎样”测试。

编写测试软件用例设计的目的，是为了能将软件测试的行为转换为“可管理、可维护”的模式。软件测试行为必须能量化，这样才能进一步让管理层 掌握所需要的测试过程，同时软件测试的生命周期伴随着产品生命周期的发展，其中测试行为也需要逐渐推进的过程，所以测试用例就成为测试行为具体量化与改进 的有效途径。

有了测试用例，可以进行测试用例评审和测试用例的持续改进，进而达到提高测试用例质量的目的。对于测试用列的日常时间中，个人有以下几点心的体会：

1、明确用例设计的必要性：日程的测试行为中，我们不可能对软件进行穷举测试，为了节省资源与实践、提高测试效率、就必须从数量极大的可用测试数据中 科学的挑选即有代表性、特殊性、或典型性（基于业务使用场景），的测试数据来进行测试；

2、以日常实践指导用例设计、改进的思想：

2.1、在实施软件测试之初，以测试的角度解读需求，设计完成测试用例，避免盲目测试，提高测试效率

2.2、测试用例的使用，使得测试的实施重点突出、目的明确

2.3、在软件版本更新后只需维护较少数用例便可开展后续测试迭代，降低测试强度，缩短整个项目周期

2.4、测试用例亦能做到通用化与复用化，使得软件测试过程针对性强，互补性强。并且用例的设计水平不断的精化与攀升

3、科学选择设计方法：目前主流用例方法都比较实用，但在测试实践中，具体采用什么方法，还是要正对开发项目的特点对方法加以适当的选择，切勿死板硬套。