包括的主要工作是：

　　1.DevelopFunctionalvalidationmatrixbasedonBusinessrequirements制定功能验证矩阵，基于商业要求。嗯，我觉得这里应该是根据设计说明书来划分需要测试的功能区域，每个区域内要测试的元素和功能逻辑。这样是建立了一个可以被测试用例和问题分类使用的功能验证表格。而且可以检验测试的覆盖度。

　　2.DevelopTestCaseformat制定测试用例格式。是制定一系列的文档格式。对于UI，功能，性能，自动化测试脚本等应该都有不同的格式规范。然后给出测试优先级别，这样优先级别低，对系统影响小，一般都比较稳定的一些测试用例可以减少测试频率和周期次数。然后好给每个测试用例估计一个时间，这样便于统计和管理人力资源。

　　3.DevelopTestCyclesmatricesandtimeline制定测试轮次和时间线。这时候应该是根据写好的测试用例估计的时间，按照对系统的不同测试点制定测试轮次。然后每个轮次之间有个时间点。例如在刚刚收到产品时，做的都是简单的功能的验证测试。这时候可以设置一个测试目标，选择一批测试用例。然后在测试目标达到后（比如，测试用例通过率达到85％）可以进行复杂的功能测试。这个可以称之为一个轮次。是以测试用例走完一遍为测试轮次的。当然也可以设置，一周或一个月为一个轮次。因此我们看到，找个实际上考验的是一个制定计划和管理执行计划的能力。好的管理人员能够制定有效的针对具体系统不同的计划，而不是一成不变，老是用一套方法。

　　4.BeginwritesTestCasebasedonFunctionalValidationmatrix根据功能验证矩阵书写测试用例。

　　这个没什么好说了，以前写过一个怎么写测试用例的文档。总之一句话，测试用例书写的标准是满足需要，而不是硬套模板。

　　5.Mapbaselinedatatotestcasestobusinessrequirements将用户需求中的设定测试数据和测试用例链接。有些用户，需要你对某些特殊的数据结构或者数据类型等等进行测试，这时候需要将那些数据独立出来，以便能够复用。

　　6.Identifytestcasetoautomate标示出能够使用自动工具的测试用例。将一些能够使用自动化测试的用例做一个标示，这样，在人力资源较少的时候，或者需要快速回归的时候可以使用自动工具了。有些测试用例是直接写成测试脚本使用测试工具测试的。有些是事先写为手工测试测试用例，可以通过使用已有的自动测试脚本快速的编制成自动测试用例的。毕竟手工测试和自动测试各有利弊。

　　7.Automationteambeginstosetupvariablefilesandhigh-levelscriptsinAutotester.对于自动化测试组来说，这个时候要做一些基本的工作了。像一些公用的文件和一些一些基础的公共函数和方法。

　　8.DefineareaforStressandPerformancetesting制定出要进行压力测试和性能测试的区域。并书写测试用例。

　　9.Beginsetupthetestcycles根据已经完成的测试用例，开始制定测试轮次中包括的测试用例，总轮次，测试时间等等。

　　10.Reviewthedocuments不断的复查文档，防止出现偏差。这个工作可以有一个固定周期，比如一个月内有几次，分别查看那些文档等等。

　　11.Reviewtestenvironments检查测试环境。包括软件，硬件，人力等等。

　　Design-Thisisarchitecturedocumentphase

　　本阶段是完成测试内部文档的阶段，这些文档大部分都是在分析阶段形成了大体的组织结构和大纲的文档，像测试用例之类的都有了一些基本的描述，本阶段主要的工作是完成这些文档的终书写。在本阶段后，基本上测试计划，测试时间表，测试数据，各种相关文档都应该处于完成阶段。当然，仍然可以通过设计的危机处理机制进行更新。

　　但是特别要指出的是，测试用例并不能够在本阶段完成。由于新功能的添加，具体功能的实现方法，修改功能等因素，测试用例只能不断的更新。

　　包括的主要工作是：

　　1.ReviseTestplanbaseonchanges根据具体的变化重新调整测试计划。

　　2.ReviseTestCyclematricesandtimelines根据计划的调整，调整各个测试轮次的内容和时间。

　　3.ReviseFunctionalMatrix根据变化调整功能设置。

　　4.Verifythattestcaseandtestdata确认已有的测试用例和测试数据仍然有效。

　　5.Continualwritetestcasesandaddnewtestcasesbaseonchanges继续书写已经设定的测试用例和添加新的测试用例。一个测试用例，在本文中在上个阶段书写的时候可能只有一个简单的描述，具体的测试步骤需要后面填写。有的时候，有些测试用例事先没有考虑到，有些是重复的，所以需要删改。

　　6.DevelopRiskAssessmentCriteria设置风险评估标准。通过设置风险评估，可以有效的帮助我们灵活的调整计划。比如，某个测试轮次是需要50个小时完成，而我们风险评估标准将这类测试设定为时间值应该设置为150％，也是说，在计划中应该填写75小时为实际设定完成时间。

　　7.Finalizetestcycles终完成各个测试轮次的设置。在本阶段结束后，除非有其他的特殊情况，通过预先设置的危机处理方法处理外，不再修改。

　　8.FinalizeTestplan完成测试计划。

　　9.Estimateresourcetosupportdevelopmentinunittestng评估支持开发人员进行单元测试的可行性。有些项目，需要测试人员去帮助开发人员进行单元测试。