序言
目标读者：有一段测试工作经历，开始从测试执行逐渐转向测试设计。
很多人做测试方案设计，第一步都是找模板，然后逐项填空，如果所在组织的测试模板积累不好，则需要自行探寻方案的设计与编写。测试方案设计的初衷是促进测试工作效果的提升，执行结果很可能成为测试工作的额外负担，沦落为纯文档工作，劳民伤财。
模板的本意是提醒设计者从更多角度思考，将前人的经验、最佳实践沉淀下来，成为后来者前行的阶梯。但这前提需要模板使用者主动体会模板中每个章节的含义。在掌握了设计的核心理念后，设计工作则是行云流水般的自然，超越模板、自定义形式，均可。
测试方案设计本质是分析测试任务，梳理工作思路，最终形成工作安排。简而言之就是：从需求到计划。
自然而然做设计的四个步骤
通识性的处理问题的思路是：分析问题，界定问题，制定方案，解决问题。测试方案设计可以用相同的思路来进行。
第一步：需求分析-建立质量标准
需求分析的目标是建立质量标准，包括要度量的边界及合格的标准。关于需求分析的对象，优先从原始需求做起，但实际工作中产品 PRD 文档可能是更多人的工作起点。输入到测试的需求可能会存在以下不足：
- 需求定义偏业务，不确切、不精确，难以度量
- 需求侧重功能，对于非功能需求描述不全面
功能类需求
首先将原始需求细化为可以度量的指标；不可度量的需求，也就无法验证需求是否得到满足。
其次还要注意对方的需求是原始需求，还是基于原始需求的解决方案。只有理解原始需求，才能进行有效度量。
最后，还要基于对业务的理解，补全遗漏的需求。这主要由两方面因素引起，一种是的确疏漏，另一种更常见的是因知识结构差异而引发的。这些都需要与需求提出者沟通并达成共识，避免想当然。
性能类需求
每个功能需求都有性能需求，但不一定每个功能都要去挖掘性能需求。要根据需求的重要程度，来集中精力做有针对性的需求分析。一般是选择核心场景、关键角色的需求进行重点分析。
安全类需求
基于系统中可能包含的数据的价值，潜在用户对风险的厌恶程度，来分析安全类需求。
稳定性需求
常规的稳定性要求包括 5X8、7X24，其实都有一些前置条件需要明确，包括：
- 压力负载是什么样的？
- 更关注哪个业务流程的稳定性？
兼容性需求
一般要关注运行环境，前端要关注浏览器、手机 OS、CPU、JDK、微信等，而后端则要关注网络、OS、既有框架、数据库、监控体系等。
业务时点需求
不同时间点，业务部门需要的产品支持度如何？是一步到位？还是分模块交付？是追求极致完美，还是对bug收敛有一定的容忍。
第二步：参考实现方案-让工作有侧重点
由于测试对象都是针对需求的某种方案，都是从需求到实现的一种映射。在映射过程中，实现方案会引入很多新的约束条件，也会导致需求的放大或缩小。完全黑盒测试的效果不佳。
参考实现方案还可以让测试更有针对性。实现方案将系统分为两部分：（1）方案未涉及的部分；（2）方案涉及的部分。关于前者，需要关注是否有遗漏的相关部分，是否产生了影响；关于后者，是需要重点测试的对象。
第三步：梳理任务及资源-提前发现协同者
有了质量标准，有了工作重点，有了时限要求，则可以梳理出待执行的测试任务，同时可以梳理出测试资源的需求，包括软硬件资源需求及相关专家的需求。
第四步：形成测试计划-方案的结论
在第三步成果基础上，加上技术方案设计，就可以转换为测试计划，测试方案就同时完成了设计，即可以回答“投入多少资源？获得多少可靠度的需求度量结果？”。
建议
花一些时间重新审视一下刚刚制定的方案和计划，分析其中潜在的风险，并制定应对措施。
