在需求收集/分析阶段，需求人员会对用户的需求进行详细的分析，形成产品说明书/需求说明文档，做得更好的可以细化到用例图，活动图等UML图。举一个例子，下面就是一个游戏人物信息系统的用例图。
从图中可以了解这个系统的基本功能，以及各个功能之间的组成。然后可以在测试计划书中结合产品说明书对此系统功能块的测试目标进行详细的描述，从而保证系统重要功能块的覆盖面，后面有经验的案例设计人员会通过测试计划书设计出合理的案例对功能进行测试。这时我们测试人员还可以起到另一个作用，对需求进行评审，比如丢弃物品功能，大家有不同的见解，这时可以让需求人员进一步确认用户是否需要对丢弃物品功能的需求进行修改。不同系统的产品说明书与用例图总是不同的，不过在测试人员的眼中，它可是用来确定产品是否可以满足用户需求的主要标准，我们可以将它提取出来，写成测试规程，测试规程可以对应一个或多个测试用例。这里主要描述产品需要达到的功能，性能要求，稳定性要求。基本要求就是让测试在早期的需求分析阶段就介入项目，对需求有一个整体的把握，有助于确定后期测试的目标。当然，更高要求是对需求进行评审/测试，论证需求是否可以满足用户的要求，从而降低需求带来的风险。
● 同类需求的一致规范性。在同一个项目中，一些细节需要开发人员统一处理，比如：退出正在编辑的界面，是否弹出提示框；标点符号是用中文半角还是全角；错误提示是弹出窗口还是显示在原界面；错误提示语与图标风格是否统一等等。测试人员（或需求人员）最好能整理出一个列表，通过评审与开发人员达成一致，这样在后期测试时会避免很多不必要的麻烦，也为产品风格的统一性铺好了路基。
2.2测试策略/方案/计划
测试策略
测试策略要解决的问题是根据测试需求、资源配备及工程环境，因地制宜剪裁测试工作，形成测试工作的测试流程。对于一个小项目做大测试是得不偿失的，同样，对一个大项目做小测试也是不负责任的。通常，对于工作量小于5个人月的普通商用软件，重点应该抓系统测试（包括功能测试、性能测试及GUI测试等）及验收测试，而不宜铺排开来，面面俱到。而对于一个工作量接近30个人月的中型商用软件而言，一般应该认真完成需求验证、设计验证、单元测试、集成测试、系统测试及验收测试，而不宜只关注系统测试。但这并不绝对，针对产品的测试流程设计还需要从用户的实际需求出发，比如，用户希望软件有好的人机交互界面，这时，就应该考虑采用快速原型生成工具来进行用户界面设计的测试； 又如用户希望软件有较好的健壮性，这时，就应该考虑进行相应的负载测试/可恢复性测试等性能测试内容。
一个好的测试策略设计应能清楚地回答下列问题：是否在测试成本与测试预期效果之间达到了最佳平衡？是否在测试需求与测试活动安排之间达到了最佳平衡？策略设计形成的技术路线是否在工程实际与企业质量承诺之间达到了最佳平衡？策略设计形成的技术路线是否具有可行性？有无设计依据？
测试方案
测试方案是对测试策略设计形成的技术路线的进一步细化。如某一技术路线规定了某小型软件项目测试工作要重点围绕“功能测试与验收测试”展开。那么测试方案设计阶段就必须具体定义哪些功能需要被测试到，以及如何去测试，哪些部分需要做验收，以及采用什么形式做。
测试方案的设计除了要明确定义各个测试活动的对象、执行人员、测试进度、放行标准等一系列属性外，还要充分考虑到成本与技术可行性。一个好的测试方案总是遵循以下设计原则：测试成本与测试工作产生的效益处于最佳比值； 各具体测试活动描述清晰，目标明确，内容完备； 测试手段是可行的； 测试产生的结果是可以用于指导产品质量改进的。
测试计划
测试计划是将测试方案具体安排到项目的各个周期中，确定在项目各个周期中具体实施的测试工作。
所以，最终的测试计划可能包括以下40点：
1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 |
标题 | 软件标识 | 目录 | 文档的目的和阅读人群 | 测试对象描述 | 软件产品概述 | 相关文档列表 | 有关的标准/法规 | 可追溯的需求 | 有关的命名约定和标识约定 |
项目相关部门和成员/联系信息/职责 | 测试项目组和人员/联系信息/职责 | 假设和依赖 | 项目风险分析 | 测试优先级和重点 | 范围和测试限制 | 测试过程描述 | 采用的测试方法描述 | 测试环境描述 | 测试环境有效性分析 |
测试环境建立/配置 | 软件移植性 | 软件配置管理过程 | 测试数据建立需求 | 系统和错误日志描述 /工具 | 缺陷管理/辅助工具 | 自动化测试描述 | 测试工具描述 | 测试脚本/测试代码维护过程和版本控制 | 跟踪/解决的工具和流程 |
项目测试度量标准 | 报告需求/测试交付产品 | 软件入口/出口标准 | 测试周期/标准 | 测试暂停/重启标准 | 人员分配 | 人员培训 | 测试地点/场所 | 测试项目组之外可用的资源 | 与所有权相关的级别/分类/安全/许可 |
此阶段的难点和重点：
● 测试周期时间点的确定：
△ 实际测试总比你预想的要花更多的时间，遇到更多的麻烦，所以要尽量争取足够的测试时间。还要尽可能考虑到测试过程中的风险，比如测试环境的问题、部署失败的问题、开发延期的问题、人员变动的问题等等。尽量避免不加思索的说这个东西我一星期肯定可以测完。
△ 多参考软件开发管理类文档，在测试的时间进度安排上与开发保持同步，如果是整机测试，还需要考虑硬件开发团队的进度计划。
● 测试资源的配置：
△ 最常见的就是角色安排多，测试人员少。解决这一问题的根本途径是招募测试人才，建设高效测试团队。然而，远水解不了近渴。那么，就需要考虑一下变通之策：外包和外协都是不错的处理办法。
△ 不同部门之间配置专门的接口人负责项目信息的快速有效传递，减少人多口杂或信息不流通引起的项目风险。
△ 建议适当考虑自动测试工具，某些工具的确能减少工作压力。
△ 了解测试团队各成员的专业技能与兴趣也是很重要的，避免无人担当相应角色。
● 测试标准的设定：
△ 测试标准以用户需求和功能技术规范文档为基础，根据项目不同的实际情况设定不同的标准，切不可一成不变。
△ 尽量提高测试困难部分的标准：如自动化测试工具开发/环境搭建的标准，集成测试的执行规范，性能测试的执行手册等等。高要求才能出好产品，往往最困难的部分，就是项目成败的关键。同时，也是整个测试团队需要提升和学习的重点技术。
2.3 测试环境搭建
测试环境（test environment）是指测试运行其上的软件和硬件环境的描述，以及任何其它与被测软件交互的软件，包括驱动和桩。测试环境是指为了完成软件测试工作所必需的计算机硬件、软件、网络设备、历史数据的总称。毫无疑问，稳定和可控的测试环境，可以使测试人员花费较少的时间就完成测试用例的执行，也无需为测试用例、测试过程的维护花费额外的时间，并且可以保证每一个被提交的缺陷都可以在任何时候被准确的重现。
简单的说，经过良好规划和管理的测试环境，可以尽可能的减少环境的变动对测试工作的不利影响，并可以对测试工作的效率和质量的提高产生积极的作用。
一般来说，按照测试计划的要求按部就班就可以完成测试工作所需要的软件/硬件/操作系统/数据配置/接口等环境的搭建。
此阶段的难点和重点：
● 测试环境的搭建需要从实际出发：
△ 根据项目的实际需求组成恰当的测试环境，不同的质量标准/行业应用/公司状态都可能搭建出不同测试环境。搭建环境之前，需要先列出测试计划中的各种环境需求，然后针对每一个需求进行分析，哪些是目前已有的，哪些是需要请其他部门帮助协调的，然后逐一完成。针对于不能完成的部分，列出对项目的风险以及是否还有其他补救措施等等。
● 测试环境不是一成不变的：
△ 项目实际执行过程中，测试环境是经常变化，比如测试软件版本更新、测试人员流失等等，需要随时跟踪和改进，尽量将可控的资源进行分类整理。可控资源包括：测试环境配置手册、测试硬件信息、环境变更记录等等。目的是尽量将测试环境进行备份，方便出现未知问题时快速的还原。
2.4 测试规程/用例设计
测试规程（test procedure）是一个提供详细的测试用例执行指令的文档。测试规程应该更注重测试的流程、方法等比较泛的内容，以方便我们对测试用列的编写有一个整体的概念和把握。不同的公司规范、要求和详尽程度可能不同。
测试用例（test case）对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。
测试规程与测试用例的区别：理想化的测试用例确实需要很多测试数据集合，但是现实中对某一软件进行测试时，由于涉及的面太广，无法一一列举出所有数据，所以要根据公司的规范来做相应的调整。所以，测试规程的文档编辑量较轻，但是只适合熟练的测试人员执行，而测试用例的执行者可以使任何人。
测试用例的设计：
测试用例可以分为基本事件、备选事件和异常事件。
● 设计基本事件的用例：参照用例规约（或设计规格说明书），根据关联的功能、操作按路径分析法设计测试用例。而对孤立的功能则直接按功能设计测试用例。基本事件的测试用例应包含所有需要实现的需求功能，覆盖率达100%。
● 设计备选事件和异常事件的用例：采用的基本方法仍然是等价类划分、边界值、因果图等，根据软件的不同性质和测试的不同目标灵活运用，至于最终设计的测试用例是否能暴露更多的隐藏缺陷，全凭用例设计人员的丰富经验和精心设计了。例如，测试一个手机终端的电话本模块。测试人员需要考虑，将相同的号码A存储到不同联系人名B和C 中，号码A呼入和呼出时，显示的联系人名应该是B还是C呢。类似这样的备选事件，往往在需求阶段描述的并不详尽，需要测试人员及早提出并与项目组达成一致。
测试用例在软件测试中的作用 ：
● 指导测试的实施
● 规划测试数据的准备
● 编写测试脚本的“设计规格说明书”
● 评估测试结果的度量基准
● 分析缺陷的标准
此阶段的难点和重点：
测试用例设计的几大基本点
● 使用合理的语言
– 测试人员该做什么，系统输出什么应该写得很清楚明白，也就是说首先要分清楚测试用例的输入和预期输出
– 一种最好的避免含义混淆的方法是在操作步骤中采用动词+名词的结构，动词总是测试人员要做得事情，名词总是测试人员操作的对象、事物
– 将同一个事物命名为同一个名称，不管这个事物是否通过不同的方式出现
● 测试用例的易测性
– 简洁性
简洁性的衡量方法就是执行测试花费时间的长短以及在测试过程中是否能保持整个测试的纯净
– 正确性
正确性意味着测试人员根据测试用例进行的测试获得的测试结果（通过或不通过）是正确的
● 控制测试用例的长度
– 在Step-by-step用例中一个比较好的长度是不多于15步：
△ 执行每个测试用例花费更少的时间
△ 测试人员很少犯错误、丢失步骤或需要帮助
△ 测试经理能够准确地估计测试的时间
△ 测试结果更容易跟踪
● 控制测试用例的操作时间
– 对于Matrix用例，一个好的测试用例的长度的衡量标准是是否能再20分钟内测试完毕
● 测试用例依赖关系的利弊
– 具有依赖关系的测试用例是一些需要依靠先前的测试用例执行的结果来执行的用例
– 考虑是否真的需要其他的测试的结果作为数据输入，如果是，那么测试必需是累积的。应尽量避免这种情况
– 保持测试用例依赖关系的正确性和一致性
– 以一种合理的顺序来安排测试用例的顺序
测试用例设计的五大误区
● 过分追求“能发现到目前为止没有发现的缺陷的用例是好的用例”
实际测试中，很多人一心想要设计出发现“难于发现的缺陷”而陷入盲区，忘记了测试的真实目的所在。测试只 需要保证两点就能达到测试目的：1）、程序做了它应该做的事情 ；2）、程序没有做它不该做的事情。在做好这两点基础上，才谈得上改进测试用例，使其“发现没有的缺陷“。
● 过分抬高测试用例设计标准，达到“使一个没有接触过系统的人员也能进行测试“的程度
不知道有没有公司真正做到这点，能够将每个测试用例都写得如此详细。之前看了微软关于一个工具的GUI 测试用例，它分了几部分，第一部分是一些启动/进入模块的case，感觉确实很详细，基本达到能认识英文就能操作的层次。然后在后期关于具体功能测试时，依然出现前置条件（测试环境）不充分的问题，比如在某一部分的Case中，测试环境中要求将文件A 先拷贝到指定目录下，然后在进行Test Step。在这部分的第一个 Case中有这关测试环境环境的搭建，但是后面几个Case就没有了（如果只做后面几个Case的话，按照Step来操作直接就Fail了）…微软尚且如此，偶相信其他公司也不会高明到哪里去。
测试的目的是尽可能发现程序中存在的缺陷。每个公司实际情况不同，每个项目的实际情况也不同，所以需要因地制宜，根据实际情况制定测试用例的设计标准。如果项目周期短，工作量大，甚至可以考虑使用测试规程来代替测试用例指导实际的测试执行。
● 测试用例没有包含实际的数据
先看一个例子，某测试人员需要检查编辑框内是否不允许输入英文，他设计的测试步骤为“输入任意英文字符”。大家觉得是否很熟悉？
测试用例是“一组输入、执行条件、预期结果”、毫无疑问地应该包括清晰的输入数据和预期输出，没有测试数据的用例最多只具有指导性的意义，不具有可执行 性。当然，测试用例中包含输入数据会带来维护、与测试环境同步之类的问题，这就有回到测试用例的设计标准上了，还是那句话：根据实际情况选择适合自己团队的规范标准。
● 需求/设计变更，而测试用例确没有修改
看似明显的错误，却是在在执行阶段经常出现的老毛病。往往在软件需求和设计已经变更了多次，测试人员觉得这些问题自己知道就行，测试用例没有任何修改。结果导致新加入的测试人员在执行测试用例不知所措，也使测试用例间接变成一堆废纸。
● 测试用例中预期输出过于简单
很多测试用例中，“预期输出”仅简单描述为应用程序的直观反映，其实，“预期输出”还需要更深一层的描述。例如，对一个存储系统， 输入存储数据，点击确定，预期输出为“系统提示成功”。这样的用例完整吗呢？系统提示成功就表示数据成功存储了？显然，还需要去相应界面查看数据是否更新。