有同学需要，因此放在这里：

1.          文档的要求

好的模板是经验和智慧的积累，是团队的财富。它可以将一个团队中最好的工作方法迅速传播给每个成员。从而使整个团队的战斗力增强。

大企业不惜重金引入“模板”。例如，联想。

2.       微软实践—从做好需求开始

要像法律条文一样。刚性不强的法律执行起来难度很大，容易偏差。

3.       软件测试计划的目标

计划先行是做好工作的良好习惯。

软件测试也一样，先要制定测试计划，是做好整个测试工作的前提。所以在进行实际测试之前，应制定良好的、切实可行的、有效的测试计划。由不确定到确定，然后执行+跟踪+控制。

l          有效：计划具有可执行性。是可以做得到的。

l          全面：各种测试的手段（功能、性能、稳定、可靠等），各种方法（测试技巧运用合理），各种资源调配情况（软件、硬件、人力），各种风险（时限、优先级、变更等等）

4.       软件测试计划的要点

l          测试目标：要做什么；

l          质量标准：要达到什么样的质量，怎样就算“足够好了”；

l          测试策略：怎样安排测试；

l          测试范围：哪些是要测的（哪些不需要测）；

l          测试用例设计方法：方法是否合理，是否能够覆盖测试范围，能否符合质量标准等；

l          所需资源和日程安排：要有计划性；

l          风险：对风险考虑周全，并计划好应对措施。

测试规划与软件开发活动同步进行，在需求分析时，就开始测试策划，确定测试需求、目标、资源等。测试计划可以按不同的测试阶段（集成测试、系统测试等）来组织，也可以为每个测试任务或目标(安全性、性能、可靠性等测试) 进行考虑。

让质量和效率可以量化。

5.       软件测试计划——制定策略

制定测试策略主要分析测试的目标和质量指标、确定测试的对象和依据，测试的重点和所采用的方法，包括在规定的时间内哪些测试内容要完成，软件产品的特性或质量在哪些方面得到确认。

l          全面细致地了解产品的项目信息：应用领域、测试范围、市场需求、产品特点、主要功能和技术架构；

l          基于模块、功能、系统、版本、性能、配置和安装等各个因素对产品质量的影响，客观地、全面地展开测试计划；

l          根据软件单元在系统结构的重要性差异和一旦发生故障将给客户造成的损失大小，来确定软件测试的等级、重点和先后次序；

l          需要在测试用例数和测试覆盖率上进行权衡而获得一个平衡点，以便能使用尽可能少的有效测试用例去发现尽可能多的程序错误。测试不足意味着让用户承担隐藏错误带来的危险；同时反过来看，过度测试则又会浪费许多宝贵的资源或耽误软件产品的发布时间。

6.       软件测试计划——确定范围

根据需求和产品设计规格说明来确定哪些功能和特性要测试，哪些功能和特性不需要测试。幻灯片中的内容是需要优先和重点考虑的。

例如：ES414不是做的全面测试，ES415做了全面的测试。

7.       软件测试计划——日程安排

工作流程以及工作任务的分配。积累的经验数据。

目的：可控。

由于涉及到不同的项目、不同的测试人员、不同的前期介入方式，要对每人每天能够完成的平均测试用例数目做出一个准确的估计确实很困难，但是可以根据以前一些项目测试的经验或历史积累下来的数据进行判断推理，并适当增加10%-20%的余量，估算结果就比较准确了。我们的项目目前就是按照这个估计的。
    在估算的基础上，进行有效的、合理的资源安排。在不同的测试阶段人力资源的需求是不一样的，所以人力资源的计划要有一定的灵活性和动态性，形成有机的动态平衡，保证测试的进度和资源的使用的效率。

8.       软件测试计划——资源配置

测试资源的分配，不仅要考虑测试团队的构成，而且要考虑不同的所需要的人数和对人员的要求是不同的。其次，软件测试项目所需的人员和要求在各个阶段是不同的：

l          在初期需要项目经理或测试组长介入进去，为测试项目提供总体方向、制定测试策略、测试计划，申请系统资源；

l          在测试前期，需要一些比较资深的测试设计、开发人员，对被测软件的详细了解、测试评估、测试需求的分解，设计测试用例、开发测试脚本；

l          在测试中期，主要是测试执行，要看测试自动化实现的程度，如果测试自动化程度高，人力的投入没有明显的增加；如果测试自动化程度低，测试执行的人员要求多，需要比较早的计划，保证足够的资源。

l          在测试后期，资深的测试人员可以抽出部分时间去做新项目的准备工作。

一个有效的软件测试项目管理者（测试组长，QA经理或测试经理），在测试资源的分配上尽量做到合理，既不过于保守，浪费资源，也不过于激进，使资源的使用总是处于紧张状态，随时有“崩盘”的危险。所以，在资源分配和管理中，要做到：

l          注意合理分配任务，明确规定每一个人在测试工作中的具体任务、职责和权限，每个组员都明确自己该做什么、怎么做、负什么责任、做好的标准是什么。做到人人心中有数，为保证和提高产品质量（或服务质量）提供基本的保证。

l          在安排任务时，尽量考虑每个人不同的技术特长、能力、性格、工作风格等，因为资源需求的估计依赖于工作量的估计和每个工程师的能力评估。

l          在不同的测试阶段，可以进行人员的相互调换，起到相互补充、相互督促/控制的作用。

l          人员的安排应该有一个提前量和余量（buffer，10%左右），因为一个合格的测试人员可能需要一个较长的培训、熟悉产品特性和适应测试流程的过程。

9.       软件测试计划——风险评估

测试风险是不可避免的、总是存在的，所以对测试风险的管理非常重要，必须尽力降低测试中所存在的风险，最大程度地保证质量和满足客户的需求。在测试工作中，主要的风险见PPT。
       前面三种风险是可以避免的，而4）至7）的四种风险是不能避免的，可以降到最低。最后一种回归测试风险是可以避免，但出于时间或成本的考虑，一般也是存在的。

针对上述软件测试的风险，有一些有效的测试风险控制方法，如：

测试环境不对可以通过事先列出要检查的所有条目，在测试环境设置好后，由其他人员按已列出条目逐条检查； （Checklist）（单子条目要细）
有些测试风险可能带来的后果非常严重，能否将它转化为其他一些不会引起严重后果的低风险。如产品发布前夕，在某个不是很重要的新功能上发现一个严重的缺陷，如果修正这个缺陷，很有可能引起某个原有功能上的缺陷。这时处理这个缺陷所带来的风险就很大，对策是去掉(Diasble)那个新功能，转移这种风险； 例如：审计
有些风险不可避免，就设法降低风险，如“程序中未发现的缺陷”这种风险总是存在，我们就要通过提高测试用例的覆盖率（如达到99.9%）来降低这种风险。
为了避免、转移或降低风险，事先要做好风险管理计划和控制风险的策略，并对风险的处理还要制定一些应急的、有效的处理方案，如：

在做资源、时间、成本等估算时，要留有余地，不要用到100%；
在项目开始前，把一些环节或边界上的可能会有变化、难以控制的因素列入风险管理计划中；
对每个关键性技术人员培养后备人员，作好人员流动的准备，采取一些措施确保人员一旦离开公司，项目不会受到严重影响，仍能可以继续下去；
制定文档标准，并建立一种机制，保证文档及时产生；
对所有工作多进行互相审查，及时发现问题，包括对不同的测试人员在不同的测试模块上相互调换；
对所有过程进行日常跟踪，及时发现风险出现的征兆，避免风险。例会制度。

要想真正回避风险，就必须彻底改变测试项目的管理方式；针对测试的各种风险，建立一种“防患于未然”或“以预防为主”的管理意识。与传统的软件测试相比，全过程测试管理方式不仅可以有效降低产品的质量风险，而且还可以提前对软件产品缺陷进行规避、缩短对缺陷的反馈周期和整个项目的测试周期。风险管理的方法不在这里讨论.

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/xumiao_09005108/archive/2009/10/10/4649204.aspx