软件测试管理的几个基本要素

　　软件测试计划是一个老生常谈的问题了，不同的人对计划的理解往往是大相径庭的。这里让我们回顾一下何为计划，一般来说计划的目的是用来识别任务，分析风险，规划资源和确定进度。从计划的定义上来看，计划并不是一张时间进度表，而是一个动态的过程，最终以系列文档的形式确定下来。拟定软件测试计划需要测试项目管理人员的积极参与，这是因为主项目计划已经确定了整体项目的一个时间框架，软件测试作为阶段工作必须服从时间和资源上的约定。

　　2. 一个完整的测试计划应该包含以下几个方面：

　　(1) 对测试范围的界定，简单的说就是测试活动需要覆盖的范围。在有时间约束，工作产品质量约束的情况下，唯一能够调整就是范围。在实际的工作中，我们总是不自觉的在调整软件测试的范围，比如在时间紧张的情况下，通常优先完成重要功能的测试。这就是一种测试范围上调整。所以作为测试管理者在接收到一项任务的时候，需要根据主项目计划的时间来确定测试范围。如果在确定范围上出现偏差，会给测试执行工作带来消极的影响，例如加班。确定范围前需要管理人员来进行任务的划分，简单的说就是分解测试任务。分解任务有两个方面的目的，一个是识别子任务，二是方便估算资源的需求。完成了上述的任务之后，管理者便需要根据项目的历史数据估算出完成这些子任务一共需要消耗的时间和资源。通常意义上说，执行一次完整的全面测试几乎是不可能的事情，我们总是要在测试的范围上面做出有策略的妥协。

　　(2) 风险的确定，项目中总是有不确定的因素。这些因素一旦发生之后记录对项目的顺利执行产生相当大的消极影响。所以在项目中，首先需要识别出存在的风险。风险识别的原则可以有很多，常见的一种就是如果一件事情发生后，会对项目的进度产生较大影响，那么就可以把该事件做为一个风险。风险识别出之后，管理者需要按照这些风险制定出规避风险的方法。在小的项目中，识别风险和制定规避方法可以省略。

　　(3) 资源的规划，确定完成任务需要消耗的人力资源，物资资源。这些是保证项目执行的物资要素。物资资源是管理者容易忽略的问题，实际上物资资源是人得以开展工作的工具，细致的规划可以让人更有效的去执行项目。常见的物资资源有计算机硬件，软件，测试环境的搭建等等。

　　(4) 时间表的制定，在识别出子任务和资源之后，我们便可以将任务，资源和时间关联起来形成时间进度表。本质上说，时间表是对前3项任务的一个概括。没有前三步的工作，时间进度表是没有意义的。

　　3. 沟通

　　沟通的测试管理人员的必须的技能。虽然我们制定出详细的项目计划，当这不意味着有了这个契约之后，项目中的各种角色就不需要沟通了。做为测试的管理者，需要将测试发现的问题及时的反馈给开发人员，同时也要积极的去了解外界产生的变更。项目中存在变化是普遍现象，而作为管理者就是要去管理这里变化，及时的修订计划。严格的说，如果没有这些变化，做为测试管理者的你就没有多少存在的价值。有些人认为一旦有了计划这个契约之后，只要按照要求去执行就可以，但是项目本身是一个动态的过程，计划是项目在某一个时刻、段的静态体现，所以要按照发展的眼光来对待计划。沟通是了解外界变化的积极手段，所以就测试管理者而言。其计划沟通能力的要求要高于测试技能的要求。

　　4. 执行

　　去年国内流行一本书，名称为执行力。书中的作者认为大多数项目没有成功的原因在于执行。软件测试也存在一个执行的能力问题，有人会说我把要求的事情按照要求做完了不就可以了吗? 的确，按照期望去执行任务是正解，但是这里有一个问题就是如何保证执行者对期望的理解同要求者的期望是完全一致的呢?所以执行的背后还是一个沟通的问题，这里的沟通是测试管理者和执行者之间的沟通。所以作为一名测试管理人员一定要在测试工程师开始工作之前明确任务的意图，前提和结果。

　　5. 版本控制

　　前面说道的几点都是过程，个人技能方面的要求。这里我们要讨论的是纯粹的工程活动——版本控制。对于版本控制这个概念大家都不陌生，它是软件配置管理的初期表现形式，来于于测试对稳定环境的要求。测试版本控制简单的说就是测试版本有明确的标识，说明。并且测试版本的交付是在项目管理人员的控制之下的。

　　测试版本的标识用来识别所用的版本。版本号码的用处很多，例如在填写错误报告的时候往往需要提供发现错误的那个版本。在做缺陷分析时，我们可以利用版本号来区别缺陷和判断缺陷的发展趋势。

　　测试版本的说明，它是开发人员和测试人员之间交流的有效形式。测试人员可以通过这份文档了解到当前的测试版本中就上一版本而言有那些显着的变化，明确了这些之后，测试人员可以更加高效，有针对性的执行测试。

　　测试版本交付，测试版本的控制必须纳于测试管理人员的控制之下。常见的形式就是测试管理者控制测试版本的更新和发布。开发人员在看到错误报告之后，总是倾向于马上修正这些错误并且发布给测试工程师做验证。

　　考虑到大多数的开发人员是典型的完美主义者，这样的做法无可厚非，但是过于频繁的版本更新会较低测试的效率。试想，如果你是一名测试工程师，当测试用例刚刚执行到一半的时候突然发布出一个新的测试版本，在这样的情况下，已经执行完毕的测试用例是否还需要再次执行一遍呢? 为了规避修改代码带来的副作用，我们有必要执行回归测试。质量是有保证了，但是效率较低了。测试在进度上被迫延迟了。所以测试版本的控制有助于保证进度和测试的效率。