1.分别创建测试计划与测试详细规格、测试用例 编写软件测试计划要避免一种不良倾向是测试计划的“大而全” ， 无所不包 ， 篇幅冗长 ， 长篇大论 ， 重点不突出 ， 既浪费写作时间 ， 也浪费测试人员的阅读时间 。“大而全”的一个常见表现就是测试计划文档包含详细的测试技术指标、测试步骤和测试用例 。
【网站测试怎么写】 2. 坚持“5W”规则 ， 明确内容与过程 “5W”规则指的是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）”、“How（如何做）” 。利用“5W”规则创建软件测试计划 ， 可以帮助测试团队理解测试的目的（Why） ， 明确测试的范围和内容（What） ， 确定测试的开始和结束日期（When） ， 指出测试的方法和工具（How） ， 给出测试文档和软件的存放位置（Where） 。
为了使“5W”规则更具体化 ， 需要准确理解被测软件的功能特征、应用行业的知识和软件测试技术 ， 在需要测试的内容里面突出关键部分 ， 可以列出关键及风险内容、属性、场景或者测试技术 。对测试过程的阶段划分、文档管理、缺陷管理、进度管理给出切实可行的方法 。
3. 采用评审和更新机制 ， 保证测试计划满足实际需求 测试计划写作完成后 ， 如果没有经过评审 ， 直接发送给测试团队 ， 测试计划内容的可能不准确或遗漏测试内容 ， 或者软件需求变更引起测试范围的增减 ， 而测试计划的内容没有及时更新 ， 误导测试执行人员 。
2. 加入一个测试经理对一个网站进行测试,都需要做什么 （一） 先说测试计划吧 一个好的测试计划是用来计划测试的 ， 指导整个测试过程 。
所以一个好的测试计划一定是可以指导测试的 ， 就是对整个测试过程中的人力 ， 时间 ， 资源 ， 策略 ， 范围的一个说明 。作为一个测试计划来讲 ， 核心的三个要素是时间 ， 资源 ， 范围 。
（这句话摘自微软的软件测试培训材料） ， 时间就是什么时候做以及要花多久做 ， 资源就是你要调用的人力、机器等资源 ， 范围是你要测试的东西以及测试重点 。除以上提到的3项之外 ， 还有比较重要的项目有策略（具体就是怎么测）、风险控制（一旦有问题采取什么应急措施）等项目 。
要把一个计划做得很有实用性 ， 按照笔者的经验 ， 要注意以下几个方面：a. 上面提到的三要素不能少 b. 测试策略一定要交待清楚 ， 就是大概怎么测试 c. 需要其他人员（部门）协调的 ， 要交待清楚 d. 在估计测试所需的时间、人力及其它资源时 ， 尽量做到客观、准确、留有余地 ， 特别是估计开发时间和debug时间 ， 以及要对自己的执行用例速度 ， 回归速度心里有数 e. 测试计划中每个阶段要明确表明 ， 并且测试阶段的输入、输出文档要清楚 f. 测试计划中的时间段不宜太长（最好以day为单位） ， 太长就比较模糊 ， 不好度量 ， 不好check g. 一定要有风险控制 ， 要不然计划缺乏可执行性 h. 计划写完之后不是装在兜里 ， 要组织PM和Dev进行评审 i. 要不断更新计划 ， 记住：每个计划都是动态的 ， 不是一成不变的 （二） 再说测试用例 和测试计划一样 ， 测试用例很多时候也沦为形式 ， 这是软件测试的可悲之处 ， 软件测试的依据就是测试用例 ， 如果用例弃之不用 ， 你凭什么做好测试？这个很可笑 。但是实际测试过程中很多时候测试用例并没用到实处 ， 笔者认为还是用例实用性问题 ， 有的时候用例洋洋洒洒数万字 ， 到回归测试的时候根本用不上 ， 至于如何选择回归测试用例 ， 我曾经写过另一篇文章 ， 欢迎查阅 。