/此文为引述
 测试工作未来预见
   更好的方法对测试人员更好的培训、更好的欣赏将改革软件产业。具体地说，诸如可执行的说明书、基于模型的测试产生、BUG 预防、系统模拟这些技术，将在这场演变过程中扮演重要的角色。
 BUG 预防和早期检测
   因为现在把重点放在产品交付的质量上来了(而不是在于找到了多少BUG)， 预防实践和静态分析仪这样的检测工具将成为主流。
 仿真测试
   仿真工具变得很普遍，使得仿造计算机环境变得容易起来。在开发过程的早期就可以进行意外和错误流程的测试。代码稳定后，再用真实环境验证仿真是否准确无误。
 及时的测试用例
   庞大的测试用例管理系统将成为昔日的东西，大量的测试用例生成了却没有被使用。测试用例将不再像腐烂的存货一样被收藏起来，因此，让测试用例保持最新变得容易起来。
 积极的方法
   误导人的方法，比如计算BUG 的数量、计算测试用例的数量，将不复存在。有用的方法，比如需求覆盖、模型覆盖、代码覆盖将驱动项目开发。
 更少更精的测试人员
   机器将代替测试人员做大部分他们以往创建测试所做的繁琐工作，测试小组需要比以往更少的测试人员，留下来的测试人员将是经过更多高度培训过的。他们所做的工作将更加有趣，因为在测试中他们将致力于更大的问题，而不是在抱怨中艰难地开展工作。
 更多更好的测试
   测试人员将可以在一天中进行成千上万的测试，所以，如何首先运行最有用的测试将成为一大挑战。相关的工具将允许测试人员为他们的测试区分优先级，以及将测试目标放在那些最易出现重大BUG 的地方。
 测试人员的角色更换
   测试中界限模糊，在测试领域工作使得专职测试的人员和专职创建测试工具的人员界限模糊，一个既是“通过程序破坏事物的测试员”又是“创建程序用于破坏事物的程序员”的专业出现了，――关于如何称呼这个新的专业，新闻圈内的人们还在进行着无休止的争论。测试与开发界限模糊， 测试人员与开发人员一前一后，共同创造可测试的、高质量的代码。测试人员帮助开发人员消除需求中的问题，使得开发人员的工作更易完成，同时，开发人员写出更清晰、可测性更高的代码，使得测试人员的工作更易完成。 顾客反馈与测试合为一体，交付的产品质量更高。测试人员进行根本原因的分析，我们会问比如“我们怎么会遗漏了这个BUG 呢？”或者“我们将来如何防止这类BUG？”这些问题，我们的工作就是使顾客满意。
 新的挑战出现
    复杂和相互关联的计算机世界使得了测试安全这一类的新问题让测试人员不断努力工作，但这没关系――因为这些挑战使测试人员精力充沛。
 测试人员获得尊重
测试人员将不再是在最后时刻才被叫来“对产品狂轰烂炸”，他们将在整个软件开发过程中提供一个可见的、重要的、增值的服务。人们意识到，测试是有益的、有趣的甚至富有乐趣。
 测试变得流行
   软件测试人员开始扬眉吐气，而且，由于破坏事物至少可以带来创建事物一样的乐趣，人们开始在开发和测试角色之间转换，所有的人将学到更多关于如何得到良好代码的知识。
 激情“吸毒者”继续存在
   新的过程运行得如此良好，使得需求撰写者，开发人员以及测试人员不再具有生命力，这就使得那些在激情掌控的世界被提升的人惶惶不可终日，那样的世界意味着工作到深夜、最后一刻测试才参与，以及如同交战开火般的会议。而这些人对于那些还没有受新的运行过程控制的公司来说还具有吸引力。
 测试人员该怎么做
   不管我的预测是否成为现实，未来也会按照它自己的方式到来，下面就是如何准备面临
未来的五个意见：
 不要接受测试的现状，四处看看，并且思考“我们在做些什么毫无意义的事情？”
 领悟如何更好的测试，并且分享这些知识。只有每一个人都试图使他所写的代码达到最佳状态时，整体质量才会改进。
 行业受软件测试的创新思维激发。用参加会议，加入邮件列表，网上冲浪，这些方式来解在测试前沿发生的一切。
 参加一个编程学习班，即使你不打算编写大量的代码。将学习班当作是在BUG 领土上的一次侦察飞行。
 PC 先驱Alan Kay 所言：“预测未来的最好方式就是开创未来”。

软件测试工程师的分类和软件测试的分类一样，按照不同的分法就会有不同的测试类型。根据目前业界行业来分如下：
  测试工具软件开发工程师和软件测试工程师。
  测试工具软件开发工程师主要负责编写测试工具代码，并利用测试工具对软件进行测
试；或者开发测试工具为软件测试工程师服务。
软件测试工程师主要负责理解产品的功能要求，然后对其进行测试，检查软件有没有错
误，决定软件是否具有稳定性，并写出相应的测试规范和测试案例。
 按职位分类：测试部门经理、测试技术总监、测试主管、测试项目经理、测试设计人员、
测试执行人员、测试协助员、技术支持；
 按测试类型分类：功能测试工程师、自动化测试工程师、性能测试工程师等；
 按测试对象分类：web 测试工程师、数据库测试工程师、C/S 测试工程师、个人软件测
试工程师等

 大体上从事软件测试工作，要做好这项工作，就要重点着重培养一下自己一下各方面的素质。因为软件测试正在向工程级发展

基本素质
 沟通能力、自信心、幽默感、记忆力<挖掘以往错误>、耐心、怀疑精神、自我督促、
洞察力<发现重点>；
 广泛的经验；
 表达能力、问题描述能力；
 会提问，会寻求Help；
 逻辑思维能力；
 团队协作能力；
 处理日常事务的能力和处理突发事件的能力
专业素质
 对于系统测试，把握需求是第一位的。对产品熟练，能够快速熟悉新的产品需求， 很
强的需求理解能力显得很重要；
 测试基础：明确测试流程中各个阶段的工作，对测试的认知程度，决定了测试流程管理
的规范性，测试工作的质量；
 测试方案的分析设计能力、测试案例的设计能力(测试案例的覆盖率、优先级等)；
 测试工具的使用(包括测试管理和测试执行工具，也包括开发工具的能力)；
 编程能力，数据库知识，网络知识，操作系统知识；
 团队协作能力，与各个小组之间的沟通能力；
 测试管理，管理决定了工作质量。尤其是测试经理，需要管理团队测试的能力。
一般的说，技术上的问题都不是问题，目前的软件更缺乏行之有效的管理。

   软件测试中的误区：红色部门和绿色部分分别代表了不同的观点。

   软件开发完成后进行软件测试；
 软件质量问题是测试人员的错误，软件发布后如果发现问题，那是软件测试人员的错。
 测试技术要求不高，比编程容易，随便找一个人就可以了；
   有编程经验对测试BUG 的敏感性；
   需要编写自动化测试脚本的能力；
   除了技术还有管理，谁都可以做，但是结果不一样。
 测试跟着开发动，有时间就多测，没时间就少测；
   必须有计划有组织。
 测试是测试人员的事，与开发人员无关；
   开发人员需要自测，还需要沟通协作。

    软件测试是没有前途的工作，只有程序员才是软件高手；
  测试是软件开发的后期活动；软件测试=程序测试；
   “软件缺陷具有生育能力” ；
    需求测试和设计测试也是软件测试的一种；
    软件测试应该涵盖整个软件生命周期；
    同时，软件测试本身也应被测试。
  测试要执行所有可能的输入；
    在实际测试中，穷举测试工作量太大，实践上行不通；
    一般采用等价类和边界值分析等措施来进行实际的软件测试；
    寻找最小最重要的用例集合成为我们精简测试复杂性的一条必经之道。
  好的测试一定要使用很多的测试工具。
    工具所能发挥的作用依赖于使用工具的人。因此，对工具的过分依赖将降低人的能动性，并最终使测试本身受到损害。适当的使用测试工具能够减轻测试人员的机械性工作，提高工作效率，而滥用工具会降低测试的质量。并不是任何工作都适合自动化的，如何合理的自动化测试，合理的选择适当的测试工具已经是研究人员感兴趣的一个课题。

软件BUG和癌细胞

软件BUG和癌细胞有非常多的共同点，有共同的3X，比如：

它们的实际数量都是X，没有人知道也不能用工具度量；

它们的存在位置都是X，一旦到了某种程度才会被发现（通常是晚期）；

它们都有相同潜伏周期X，一旦突破了临界值就会爆发其可怕的一面。

它们都会迅速扩散，消除了局部的并不代表就消除了全部。

针对它们的防治手段只能依靠早期发现，以预防控制为主。

BUG的影响

1、  精神的摧残；

2、  形象的损失；

3、  财富的流失；

BUG的产生

1、  交流不充分或者相互误解；（羞涩、胆怯、依赖、轻视、健忘、误解）

2、  软件的复杂性；

3、  程序员的错误；（过于疲劳、不守规矩、过于热心）

4、  需求变化；

5、  时间压力；

6、  文档贫乏；

7、  软件开发工具；

软件测试是否包含了修复

软件测试和修复都是不同意义的行为过程，最能体现修复行为的是调试和修正。在程序员为主的单元测试中程序员的工作就复合了测试、修复两种行为，看起来修复就包含于测试中了，实际上测试和修复是两种相互独立的行为过程，只是同一个人身上编码、测试角色进行了转换。软件测试和软件修复只可能是某种意义上的重合，但却是两种截然不同的行为。

为什么需要软件测试

如果不经过测试程序便可以正确运行，那么测试是否是一种资源的浪费

答案是肯定的。如果确保程序不出错，那么测试绝对是一种资源的浪费。测试可以保证对需求和设计的理解与表达的正确性、实现的正确性以及运行的正确性，任何一个环节发生了问题都会在测试中表现出来，测试同时可以防止无意识的行为引入一些将来可能出现的错误。

测试可以帮助我们设计代码及其用户界面，因为在编码之前测试人员就代表了客户。

测试同样可以解释和说明程序代码。

不用测试准则

1、  程序的某一行代码存在着缺陷；

2、  编码需要进行修改、扩展或者分解；

3、  你找到一种让全世界程序员都严格遵守的编码规范；

4、  你找到一种完美的世界通用的设计结构；

5、  如果有人问你书写的代码如何使用；

6、  如果有人抱怨你的用户界面不够友好；

7、  如果有人对你说编写的不时他所需求的。

软件测试的目的

软件测试是否发现错误为唯一目的

测试观点：

l         软件测试时为了发现错误而执行程序的过程；

l         测试是为了证明程序有错，而不是证明程序无错误；

l         一个好的测试用例在于它能发现至今未发现的错误；

l         一个成功的测试是发现了至今未发现的错误的测试。

软件测试不以发现错误为唯一目的，查不出错误的测试并非没有价值，通过分析错误产生的原因和错误的分布特征，可以帮助我们发现当前所采用的软件过程的缺陷同时加以改进。同时，这中分析也能帮助我们设计出有针对性的检测方法，改善测试的有效性。没有发现错误的测试也是有价值的整个测试过程本身就是评定测试质量的一种方法。如果我们的测试过程是可持续增长的在运行多次而未发现软件错误，这样多少都可以得出结论：被测软件已经完美了，或者就是需要遗弃这套无法正常工作的测试过程而重新构建一套。因为存在针对性所以软件测试存在多种目的，即：

1、  证明我们所做的是客户所需的；

2、  确保编码人员正确理解设计的意图；

3、  通过回归测试来保证目前运行的程序在将来仍然可以正常工作。

什么是软件

软件就是为了在计算机上实现某些任务而产生的指令代码和数据集合，当然也包括了所有与指令代码和数据集合相关联系的表示方法，即软件不但包含了程序源代码和数据文件，还包含了所有在需求、分析设计等阶段产生的模型的表示方法（包括大量的标准输出工件、数据设计模型、设计模型、远景规划、风险列表等等）。

什么是软件测试

狭义的测试指针对软件编码，执行相对测试用例的活动。扩展后指测试时发现并指出软件（包含软件经过建模、需求、设计等阶段所产生的大量输出工件）存在的缺陷，此过程中指明和标注问题存在的正确位置，详细记录问题出现的操作步骤，及时储存当时的错误状态。