1. 测试计划
1.1测试计划编写条件 测试计划（Testing plan），描述了要进行的测试活动的范围、方法、资源和进度的文档。它确定测试项、被测特性、测试任务、谁执行任务、各种可能的风险。测试计划可以有效预防计划的风险，保障计划的顺利实施。
在测试项目之初就要制定相应的测试计划。接下来谈下如何编写测试计划问题。 1． 为什么要编写测试计划？
1）领导能够根据测试计划做宏观调空，进行相应资源配置等；
2）测试人员能够了解整个项目测试情况以及项目测试不同阶段的所要进行的工作等；
3）便于其他人员了解测试人员的工作内容，进行有关配合工作
2． 什么时间开始编写测试计划？
（测试需求分析前总体测试计划书／测试需求分析后详细测试计划书）
3． 由谁来编写测试计划？
具有丰富经验的项目测试负责人
4． 测试计划编写6要素？（5W1H）
1）why——为什么要进行这些测试；
2) what—测试哪些方面，不同阶段的工作内容；
3) when—测试不同阶段的起止时间；
4) where—相应文档，缺陷的存放位置，测试环境等；
5) who—项目有关人员组成，安排哪些测试人员进行测试
6) how—如何去做，使用哪些测试工具以及测试方法进行测试。
注意事项：
1．测试计划不一定要尽善尽美，但一定要切合实际，要根据项目特点、公司实际情况来编制，不能脱离实际情况；
2．测试计划一旦制定下来，并不就是一层不变的，世界万事万物时时刻刻都在变化，软件需求、软件开发、人员流动等都在时刻发生着变化，测试计划也要根据实际情况的变化而不断进行调整，以满足实际测试要求．
3．测试计划要能从宏观上反映项目的测试任务、测试阶段、资源需求等，不一定要太过详细．
评审总结
1.计划评审
测试计划编写完成后，一般要对测试计划的正确性、全面性以及可行性等进行评审，评审人员的组成包括软件开发人、营销人员、测试负责人以及其他有关项目负责人。
2.计划总结
项目完成后，应该对计划的执行情况进行评审，看有哪些不合理的地方，以便为编写下一个项目测试计划做经验积累。
2. 测试用例评审
2.1测试用例 测试用例就是一个文档，描述输入、动作、或者时间和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作。
定义
软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果，下面逐一介绍。
用例编号
测试用例的编号有一定的规则，比如系统测试用例的编号这样定义规则： PROJECT1-ST-001 ，命名规则是项目名称＋测试阶段类型（系统测试阶段）＋编号。定义测试用例编号，便于查找测试用例，便于测试用例的跟踪。
测试标题
对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。比如 “ 测试用户登录时输入错误密码时，软件的响应情况 ” 。
重要级别
定义测试用例的优先级别，可以笼统的分为 “ 高 ” 和 “ 低 ” 两个级
别。一般来说，如果软件需求的优先级为 “ 高 ” ，那么针对该需求的测试用例优先
级也为 “ 高 ” ；反之亦然，
测试输入
提供测试执行中的各种输入条件。根据需求中的输入条件，确定测试用例的输入。测试用例的输入对软件需求当中的输入有很大的依赖性，如果软件需求中没有很好的定义需求的输入，那么测试用例设计中会遇到很大的障碍。
操作步骤
提供测试执行过程的步骤。对于复杂的测试用例，测试用例的输入需要分为几个步骤完成，这部分内容在操作步骤中详细列出。
预期结果
提供测试执行的预期结果，预期结果应该根据软件需求中的输出得出。如果在实际测试过程中，得到的实际测试结果与预期结果不符，那么测试不通过；反之则测试通过。
2.2测试用例评审
首先要清楚内部评审的定义，是测试组内部的评审，还是项目组内部的评审。评审的定义不同，内容也不会相同。
如果是测试组内部的评审，应该着重于：
1. 测试用例本身的描述是否清晰，是否存在二义性
2.是否考虑到测试用例的执行效率.往往测试用例中步骤不断重复执行，验证点却不同，而且测试设计的冗余性，都造成了效率的低下
3.是否针对需求跟踪矩阵，覆盖了所有的软件需求，
4.是否完全遵守了软件需求的规定。这并不一定的，因为即使再严格的评审，也会出现错误，应具体情况具体对待。
测试用例评审如何去做呢？
测试用例的评审能够使用例的结构更清晰，覆盖的用户场景更全面；对于测试工程师来说也是一个快速提高用例设计能力的过程。
评审的内容有以下几个方面：
1) 用例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖。
2) 优先极安排是否合理。
3) 是否覆盖测试需求上的所有功能点。
4) 用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确；期待结果是否有明显的验证方法。
5) 是否已经删除了冗余的用例。
6) 是否包含充分的负面测试用例。充分的定义，如果在这里使用2&8法则，那就是4倍于正面用例的数量，毕竟一个健壮的软件，其中80%的代码都是在“保护”20%的功能实现。
7) 是否从用户层面来设计用户使用场景和使用流程的测试用例。
8) 是否简洁，复用性强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复
用标准步骤。
个人认为，一个“健康”的测试用例至少要通过前5个标准。
5、评审的方式
1) 召开评审会议。与会者在设计人员讲解之后给出意见和建议，同时进行详细的评审记录。
2) 通用邮件与相关人员沟通
3) 通用IM工具直接与相关人员交流
方式只是手段，得到其它人员对于用例的反馈信息才是目的。
无论采用那种方式，都应该在沟通之前把用例设计的相关文档发送给对方进行前期的学习和了解，以节省沟通成本。
1. 测试计划
1.1测试计划编写条件 测试计划（Testing plan），描述了要进行的测试活动的范围、方法、资源和进度的文档。它确定测试项、被测特性、测试任务、谁执行任务、各种可能的风险。测试计划可以有效预防计划的风险，保障计划的顺利实施。
在测试项目之初就要制定相应的测试计划。接下来谈下如何编写测试计划问题。 1． 为什么要编写测试计划？
1）领导能够根据测试计划做宏观调空，进行相应资源配置等；
2）测试人员能够了解整个项目测试情况以及项目测试不同阶段的所要进行的工作等；
3）便于其他人员了解测试人员的工作内容，进行有关配合工作
2． 什么时间开始编写测试计划？
（测试需求分析前总体测试计划书／测试需求分析后详细测试计划书）
3． 由谁来编写测试计划？
具有丰富经验的项目测试负责人
4． 测试计划编写6要素？（5W1H）
1）why——为什么要进行这些测试；
2) what—测试哪些方面，不同阶段的工作内容；
3) when—测试不同阶段的起止时间；
4) where—相应文档，缺陷的存放位置，测试环境等；
5) who—项目有关人员组成，安排哪些测试人员进行测试
6) how—如何去做，使用哪些测试工具以及测试方法进行测试。
注意事项：
1．测试计划不一定要尽善尽美，但一定要切合实际，要根据项目特点、公司实际情况来编制，不能脱离实际情况；
2．测试计划一旦制定下来，并不就是一层不变的，世界万事万物时时刻刻都在变化，软件需求、软件开发、人员流动等都在时刻发生着变化，测试计划也要根据实际情况的变化而不断进行调整，以满足实际测试要求．
3．测试计划要能从宏观上反映项目的测试任务、测试阶段、资源需求等，不一定要太过详细．
评审总结
1.计划评审
测试计划编写完成后，一般要对测试计划的正确性、全面性以及可行性等进行评审，评审人员的组成包括软件开发人、营销人员、测试负责人以及其他有关项目负责人。
2.计划总结
项目完成后，应该对计划的执行情况进行评审，看有哪些不合理的地方，以便为编写下一个项目测试计划做经验积累。
2. 测试用例评审
2.1测试用例 测试用例就是一个文档，描述输入、动作、或者时间和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作。
定义
软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果，下面逐一介绍。
用例编号
测试用例的编号有一定的规则，比如系统测试用例的编号这样定义规则： PROJECT1-ST-001 ，命名规则是项目名称＋测试阶段类型（系统测试阶段）＋编号。定义测试用例编号，便于查找测试用例，便于测试用例的跟踪。
测试标题
对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。比如 “ 测试用户登录时输入错误密码时，软件的响应情况 ” 。
重要级别
定义测试用例的优先级别，可以笼统的分为 “ 高 ” 和 “ 低 ” 两个级
别。一般来说，如果软件需求的优先级为 “ 高 ” ，那么针对该需求的测试用例优先
级也为 “ 高 ” ；反之亦然，
测试输入
提供测试执行中的各种输入条件。根据需求中的输入条件，确定测试用例的输入。测试用例的输入对软件需求当中的输入有很大的依赖性，如果软件需求中没有很好的定义需求的输入，那么测试用例设计中会遇到很大的障碍。
操作步骤
提供测试执行过程的步骤。对于复杂的测试用例，测试用例的输入需要分为几个步骤完成，这部分内容在操作步骤中详细列出。
预期结果
提供测试执行的预期结果，预期结果应该根据软件需求中的输出得出。如果在实际测试过程中，得到的实际测试结果与预期结果不符，那么测试不通过；反之则测试通过。
2.2测试用例评审
首先要清楚内部评审的定义，是测试组内部的评审，还是项目组内部的评审。评审的定义不同，内容也不会相同。
如果是测试组内部的评审，应该着重于：
1. 测试用例本身的描述是否清晰，是否存在二义性
2.是否考虑到测试用例的执行效率.往往测试用例中步骤不断重复执行，验证点却不同，而且测试设计的冗余性，都造成了效率的低下
3.是否针对需求跟踪矩阵，覆盖了所有的软件需求，
4.是否完全遵守了软件需求的规定。这并不一定的，因为即使再严格的评审，也会出现错误，应具体情况具体对待。
测试用例评审如何去做呢？
测试用例的评审能够使用例的结构更清晰，覆盖的用户场景更全面；对于测试工程师来说也是一个快速提高用例设计能力的过程。
评审的内容有以下几个方面：
1) 用例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖。
2) 优先极安排是否合理。
3) 是否覆盖测试需求上的所有功能点。
4) 用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确；期待结果是否有明显的验证方法。
5) 是否已经删除了冗余的用例。
6) 是否包含充分的负面测试用例。充分的定义，如果在这里使用2&8法则，那就是4倍于正面用例的数量，毕竟一个健壮的软件，其中80%的代码都是在“保护”20%的功能实现。
7) 是否从用户层面来设计用户使用场景和使用流程的测试用例。
8) 是否简洁，复用性强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复
用标准步骤。
个人认为，一个“健康”的测试用例至少要通过前5个标准。
5、评审的方式
1) 召开评审会议。与会者在设计人员讲解之后给出意见和建议，同时进行详细的评审记录。
2) 通用邮件与相关人员沟通
3) 通用IM工具直接与相关人员交流
方式只是手段，得到其它人员对于用例的反馈信息才是目的。
无论采用那种方式，都应该在沟通之前把用例设计的相关文档发送给对方进行前期的学习和了解，以节省沟通成本。