Analysis -This is external document phase

　　这是一个外部文档阶段。之所以说是外部文档，是因为这个阶段的工作主要都是从客户和开发组得到的文档。在这个阶段，对这些外部文档进行分析和总结。根据得到的信息，去创建测试的框架和文档。所以本阶段主要的工作是完成分析，搭出框架，书写大纲等。并不是要所有的文档工作都在本阶段内完成。

　　包括的主要工作是：

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

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

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

　　4. Begin writes Test Case based on Functional Validation matrix 根据功能验证矩阵书写测试用例。

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

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

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

　　7. Automation team begins to setup variable files and high-level scripts in Auto tester. 对于自动化测试组来说，这个时候就要做一些基本的工作了。像一些公用的文件和一些一些基础的公共函数和方法。

　　8. Define area for Stress and Performance testing 制定出要进行压力测试和性能测试的区域。并书写测试用例。

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

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

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