测试管理的若干建议[1] 软件测试
下面是可以提高软件测试管理的一般建议。
尽早开始测试管理活动
虽然这一点看起来像最显而易见的建议，但是很少软件项目真正地应用这一观念。在早期开始确定测试资源很容易而且很常见，但是许多测试分析(如识别关键的、优先的测试用例)可以而且应该尽快开始。一旦用例被充分开发产生事件流，就可以得到测试程序。如果一个项目没有使用用例需求，那么仍可以从确认初始需求说明中得到测试。尽快开发测试能帮助减轻未来不可避免的时间限制。
迭代化测试
软件测试应该是一个反复的过程，在整个项目周期的早期生成有价值的测试工件和工作。这是遵循尽早开始测试流程的首要建议：一个迭代的测试流程应该很早就关注测试管理。测试管理通过组织迭代的各类工件和资源来指导这一点。这个基于风险的方法有助于确保以最有效的方式处理项目时间线里可能出现的变更、延迟和其他一些不可预见的障碍。
重用测试工件
在一个项目或多个项目里重用测试工件能够极大地提高测试团队的有效性。这样可以极大地缓解时间和资源有限造成的压力。可以重用的工件不仅包括自动操作测试对象，还包括测试程序和其他的计划信息。为了有效地重用工件，测试管理必须在组织和描述给定项目的与测试相关的各种信息方面做得很好。在创建工件时，重用总是需要一些预先计划，而且这一原则通常可以应用于测试管理。
使用基于需求的测试
测试可以被分成两种常用的方法：
确认事情按照计划进行
尽力找出什么使得事情停止下来
虽然后面的探索性测试对于发现导致错误的难以预测的场景或情形来说非常重要，但是确认基本的需求可能是测试团队执行的最重要的评估。
基于需求的测试是确认一个应用软件或系统的主要方式，它既适用于传统需求也适用于用例需求。基于需求的测试往往没有探索性测试那么主观，它也可以带来其他的益处。软件开发团队的其他部分可能质疑或者谴责探索性测试的结果，但是他们不能怀疑直接确认需求的测试。另一个好处是它可以更容易地计算所需的测试工作(与探索性测试相反，它总是受限于可以利用的时间)。
它也可以提供各类统计数据，他们可能是有用的度量，例如测试覆盖率。测试用例是由需求产生的，并且随着事情变化对其关系的跟踪也更为重要，这是一件复杂的工作，应该通过工具进行处理。RequisitePro 和 ClearQuest 中的测试管理能力提供了满足这一需求的结果方案。
这一流程的局限性是它信赖于一个好的系统需求和一个十分有效的合理的需求管理计划。从另一方面来说，探索性测试可能更加特殊。它很少依赖软件开发团队的其他部分，这有时会导致测试工作很少被关注在确认需求的重要任务上。虽然较好的测试工作应该将不同的方法集成起来，但是不应该忽视基于需求的测试。
文章来源于领测软件测试网 https://www.ltesting.net/