6、了解手头的任务和相关的测试目标
判断一个程序功能是否正确的要素：
- 合法输入有正确的返回
- 非法输入有对应的提示
- 不论何种输入程序都不应挂起、崩溃或退出
- 可以在预定的时间内一直正常运行
- 实现了功能性、非功能性需求
了解测试目标的途径如下：
- 理解系统。从更高的层次来理解需求，而非独立的思考需求本身
- 尽早介入
- 理解企业文化和过程。为更好的适应和提出改进意见做准备
- 实现的范围
- 测试期望。高层、客户对测试的期望
- 吸取教训
- 工作量大小
- 解决方案的类型。复杂的解决方案，还是简单的解决方式
- 技术选择。根据技术栈确定待测对象
- 预算。根据预算来确定投入的测试工作量
- 时间表。根据时间表来调整测试时间
- 版本提测方式。迭代提测还是大版本提测
在对系统有了全面的了解后，就可以知道系统的规模和相应的工作量、客户的问题及潜在的风险。通过这些信息来了解当前的测试任务，并据此确定测试目标及对应的测试框架。最终形成测试计划或者测试策略文档。
7、考虑风险
在此之前需要对新进行层次划分，在针对划分后的对象进行相关的风险考虑、复杂度考虑、必要性考虑。而在制定测试策略的时候就需要充分考虑这些因素，通常测试策略需要具体分析的问题还包括：
- 选择测试设计技术。如：等价类划分、边界值、路径分析法、功能分析法、因果类。
- 选择测试工具。购买、开源、开发测试工具，考虑使用者的熟悉程度。
- 开发内部测试工具或脚本。
- 确定测试需要人员和技术。
- 确定测试覆盖率。包括代码覆盖率需要提前确定，具体而言如果有明确要求则按要求，没有则需要根据对系统业务的分析，确定哪些是必须的，哪些是非必须的。
- 建立发行标准。约定好可以发行的具体标准。如：达到覆盖率、无严重缺陷、主功能可用。
- 设置测试时间表。依据测试计划的进度表来安排。
- 考虑测试阶段。针对不同的测试阶段设计测试策略。如：功能、性能、灰度测试。
为用户需求设定优先级，根据优先级对需求进行分组。具体的方法有：
- 风险等级确定。高风险为高优先级。
- 操作特性考虑。频繁操作的需求为高优先级。
- 用户需求。用户关注的需求为高优先级。
- 可用资源。
通常的风险造成原因如下：
- 短时间发布/面市。短时间发布通常都无法做到充分测试，只能进行相应的测试策略的调整，最大限度的覆盖测试。
- 新的设计过程。使用了新的设计过程或者技术。
- 新的技术。功能性、安全性、熟练性。
- 复杂度。越复杂的功能越容易出错，出错的影响程度越大。需要重点关注
- 使用频率。对于经常性使用的功能，其其失败影响的风险较大。
- 不可测需求。此类需求因无法确定其实现程度，导致风险较大。
分析风险是为了评估其带来的影响，针对影响大的风险需要重点关注，如果风险太大，则可能需要终止项目。另一方面需要根据风险的优先级来指定测试策略及安排相关人员。重点功能需要关键人员进行重点测试。
8、根据功能优先级安排测试工作
功能列表可以按照不同的标准来划分优先级：
- 风险由高到低
- 复杂度由高到低
- 客户的需要
- 预算的限制
- 时间的限制
- 人员的限制
最终可以针对不同维度对某个需求进行打分，然后综合各维度的得分，最后就可以得到一个功能列表的优先级综合得分。
9、牢记软件方面的问题
- 制定测试计划的时候需要考虑软件方面的影响因素。比如：
- 使用Beta或者预发行版技术、类库、系统
- 新技术和不完善的技术，使用新技术的风险总是显而易见的
- 分阶段提测。确保每个阶段的功能都具有可测性
- 缺陷。针对block的bug需要更高的修复优先级
- 补丁或版本升级。需要考虑功能在最新可获取的升级版本可用。比如：最新版本浏览器
10、获得有效的测试数据
野蛮的遍历所有的测试输入数据和测试输出数据组合是不可取的，所以需要通过合适的测试设计来获得有效的测试数据。测试数据需要覆盖系统级的所有功能。而评审测试数据时需要从如下几点考虑：
- 深度。需要了解测试数据的数量和规模
- 广度。考虑测试数据的内容变化，比如：划分类型和区域
- 范围。对于验证的结果进行范围确定，不能多、不能少、不能错
- 测试过程中保证数据的完整性。避免测试数据互相影响，不同人员操作相互影响。
- 条件。为特定测试场景准备一些基础数据，从而高效实现测试执行。
最后，如果可以的话尽量使用客户或者线上已有的测试数据，这样的数据即丰富有真实，尽可能的模拟了线上用户操作。
11、规划测试环境
具体的操作如下：
- 获得客户环境样本的描述。比如：系统、软件、硬件（cpu、mem、disk、network、display、printer）、配置等
- 确定是否需要归档测试后产生的文件
- 确定需要的自动化测试许可证数量
- 确定执行过程中需要的其它软件
- 确定完整基础环境安装需要支持
- 考虑其它特殊资源
通过这些方式确定了测试环境所需的内容，并核查所需组件是否全部具备，如果外购则需要提前申请资源。
12、评估测试准备和执行所需的时间
特定项目的测试工作量依赖于许多变量，比如：团队的测试成熟度、被测应用的复杂度、测试需求的范围、测试人员的能力等。所以测试工作的评估可以从测试任务详细列表来进行。具体的方法如下：
- 开发比例法。不同的产品、不同项目、不同的用户、不同的阶段所需的开发测试比是可以调整的
- 项目人员比例法。当项目组中开发人员动态变化时，可以参照此法
- 测试过程法。分析项目的测试过程数，根据以往类似项目测试过程数的人员工作量，等效计算出当前项目的工作量。
- 测试任务规划法。测试任务包含：需求评审、测试计划、测试设计、测试执行等一系列测试活动。同样以历史数据来等效计算出。
- 其它考虑。测试需求范围（功能、性能、负载、ui、可用性、安全性、内存泄漏、代码覆盖率、边界测试、程序模块性能、模块复杂度分析、接口、系统、集成）、人员的技能和水平、使用工具的熟练度、对产品的认知能力、测试组的结构、测试工作的启动参与、测试开发的范围、软件计划迭代的升级的次数、是否有完善的过程定义指导、是否为高风险软件（危机生命、涉及金钱）