人

)。计划的审查是必不可少的，因为尽管测试工程师尽最大努力来达成一个对产品的全面定义，这一测试设计者

所基于的定义不一定是完整或准确的。此外，就象开发者很难测试他们自己的编码一样，测试工程师也很难明确
评估他们自己的测试计划。每一个计划审查者都可能根据其经验及专长建议修改，有时候审查者还能提供测试工
程师在组织产品定义时不具备的信息。例如，一个市场人员可能了解到了新的客户要求，一个软件支持专家可能

 

从有关的产品领域了解到了一个新的缺陷报告。

测试计划强调测试计划和执行的原则。在测试计划中描述进行测试所需的测试设计和步骤是另一层关于测试设计
和计划的原则。在测试设计和计划中的错误与欠缺在设计转化成测试计划中特定的结构和测试步骤后就经常是再

 

已无法弥补。

测试计划可作为其它项目，例如为不同的产品准备测试时的参考资料。当被测试软件找到缺陷解决并证实后，测
试计划所述的测试可以用于证实缺陷的解决方案。同时，一个主要的测试设计信息来源，特别对于旧产品的新版

 

本而言，是相关产品或前版本的测试计划。在建立新版本时，旧版本的软件测试计划都应当被重新审查。

与功能与设计说明不同，测试计划将从测试的角度来描述产品的功能操作。从这方面说，测试计划构成了公司公
共档案的一部分。随着时间的流逝人们会离开公司，带走他们的知识。以前产品的测试计划就能帮助你定义新产

 

品的测试。

软件测试工程师还要写测试结果报告。测试结果必须写成文档，这样就能确定被测软件的状态，提供关于必须要
解决的缺陷的记录。产品测试中发现的所有缺陷的记录是测试部门最显眼、保存时间最长的文档。测试计划和测
试报告在项目的最后常被遗忘，但现存缺陷的清单

(或数据库)代表项目未完成的议程。这一议程没完成是因为一

些缺陷必须在对原来产品的一个

patch 或 maintenance release 的时候纠正，或者它们在这个产品作为后续

 

产品的基础之前被修复。

在与软件产品打交道的过程中，测试工程师比其他部门的人参与项目的更多方面。测试部门应当记录项目过程中
重大事件

(例如设计决定)的信息。这个信息应能帮助测试部门和其他部门避免在后续项目中犯同样的错误。错误

是不可避免，在一个项目中可能出问题。从这些经验中学习就可能避免问题，避免今后的同样错误。从错误中学

 

习的第一步就是记住它们，记忆的第一步就是把它们写下来。

3、组织技能(Organizational Skills) 

每当执行一个软件项目的测试计划，几乎不可能不遇到至少会阻碍一些测试而必须解决的缺陷。一个测试工程师
应当能灵活地停止测试产品的一部分而开始测试其他部分。有时被测软件需要做根本变动引起大量的测试结果失
效，测试也许得重做不止一次。在问题被查找和改变在进行的过程中，测试工程师必须有条理，保持对执行测试
的软件的前后关系的明确感受

(例如目前被测试的程序特定版本的不同部分)  

。

网络时代要求的动态开发和测试模式使组织性的工作方式对测试工程师越来越重要。在整个开发过程中被测试软
件可能会不断地改进。测试工程师在计划和实施测试的时候必须考虑这些变化因素，必须控制测试环境来保证测

 

试结果的有效性。

记住计划是一个动词。作为一个软件工程师，你永远不会有你想要的所有时间和资源。你总是必须通过理解技术
和产品，开发组织方式，从你和其他人的错误中学习，以及在设计必须改变和出问题的时候的迅速调整，使你的
测试效果和效率最大化。如何能做到这点呢？基本代数：量化任务、目标和结果来减少方程中的变量数。把产品
的功能定义成要求。在测试计划和测试中量化测试及其预期的和实际的结果，把信息提供给项目组。你东点一下
西点一下是不能完成整个测试的。未来软件开发的组织模式要求有灵活的设计和不断进化的开发周期。对产品测

 

试必须随着产品的进化而进化。
4、实践经验(Hands-On Experience) 

 

这是个典型的两难问题。你需要软件测试经验来找工作，你没工作你就没经验。你该怎么办？

Be careful! 这需要勇气和你的 PC

 

的小心备份。

作为自愿者参与

beta 测试。怎样发现需要 beta 测试员的公司呢？首先，给你在软件公司工作的亲友打电话。偶

尔有人会需要

beta

“

的测试人员。如果这不行，到你最喜欢的网络搜索引擎上去找

beta test”。你会发现很多

小

(和不那么小的)公司亟需 beta 测试员。为什么？这得感谢互联网，竞争的加剧使公司必须做出产品模型贴到

“

他们的网址上作为

beta”版推出。这些公司希望人们不仅测试他们的产品，而且对这些免费品感兴趣进而购买他

 

们的产品。