很多时候都会在想测试人员应该什么时间介入项目，才是最合适的，从最早期的业务需求评审，每次的项目讨论会，不知道是不是我的不认真，总觉得的参加了评审，讨论会，我的收获并不是很大，很多时候都是默默的坐在一旁，听着业务人员，开发，架构等滔滔不绝的说着，而我听了好像没听多少，重点的部分还是记了下来，以后测试的时候万一遇到什么有争执的部分，这个还可以拿出来做个参考，其实在评审阶段，也是自己能学很多东西的时候，深度的了解的需求，提出设计不合理的观点，给出自己的提案，或是了解系统的架构该是怎样搭建的等等，只是看自己有没有这份用心了，我做的还不够，这点以后要逐步改进。
每次拿到项目的正式软需说明书，开始静态测试，开始编制测试计划书，测试方案，测试案例等；以前一直觉得写测试方案对我来说并没有多大的意义，后来通过一些问题的总结发现，其实写测试方案是对整个项目的一个把握，纵观全局的对系统有一个大致的了解，从而制定出测试的目标，测试的方法，测试的内容，测试环境，测试数据，测试人员安排，风险及依赖等，有一个总体的测试思想，在思想下指导行动，就可以少走很多的弯路；通过一些总结，如果一份报告要能很好的反映整个项目的测试重点，测试进度，测试人员安排的话，我觉得可以从以下几个方面来描述这份测试方案报告，这个也是目前我们项目中经常使用的；
系统测试方案格式如下：
一 项目简介：概括的对这个系统做一个描述，让别人知道这个系统是干嘛用的，简洁而有重点；
二 测试目标：对于本次系统测试要达到什么样的标准，缺陷率应该控制在多少以内，给自己定一个合理的目标，能起到鞭策的作用；
三 测试策略：这个部分主要包括（1）数据流图描述；（2）本项目的测试难点；（3）本项目测试的关键点；（4）需要特别申请的测试资源；（5）性能测试；这部分的内容可以省略；
四 测试的内容和方法：这部分主要包括：（1）场景测试；（2）功能测试；（3）功能模块衔接测试；（4）接口测试及其联测；（5）移行测试；（6）系统升级；（7）产品升级；（8）性能测试；（9）兼容性测试；（10）安全性测试；（11）破坏性测试；这部分需要我们对整个项目有熟悉的了解，根据项目的内容涉及不同的测试方法，从大的方向上确保了漏测某些功能的模块；
五 测试数据：包括（1）系统参数；（2）存量环境数据；（3）业务参数；（4）交易参数；（5）接口文本数据；
六 测试环境：（1）各应用测试环境的版本基础；（2）测试环境硬件要求；（3）测试环境连接图；
七 测试工具及其模拟器：根据项目实际是否使用自动化工具
八 测试人员安排：
九 测试计划：（1）主要工作安排；（2）测试轮次安排；（3）批量计划；
十 人力资源评估：
十一 风险及依赖