测试同学平时工作中最常遇到的事情就是编写测试用例，但很少见到测试方案。测试方案是抽象的，描述的是整体模型，总体策略考虑从哪些方面进行测试，像大树的主体延伸到枝干；测试用例是具体的，它依据测试方案产生，每一条用例是实际的、可操作的，像大树的细枝末节和叶子。无论是手工测试，还是自动化测试，测试用例/测试方案是基础。只有设计好测试用例，才能保证测试的覆盖率。一般的测试方案是怎么产生的呢，具体要考虑哪些点，通过一个具体例子我们来分析分析。
一、测试方案数据来源
一般我们的需求分为两大类：老业务迭代需求、全新业务
测试方案的数据来源：
（1）产品编写的PRD、MRD
（2）技术同学编写的技术文档
（3）老业务沉淀文档
（4）撸代码查看整个链路
（5）询问了解相关业务的同学
二、测试方案的主干
对于需求测试，我们需要考虑到方方面面：功能测试、兼容性测试、安全性测试、性能测试、异常测试、回归测试、权限测试
（1）功能测试：功能测试在测试工作中占比最大，测试软件的实际功能是否和产品描述的需求相符合，也就是我们平时说的正向测试，需要考虑到 界面测试：筛选、列表数据展示、按钮是否生效、分页等等，业务数据（值、精度、格式等）；
（2）性能测试：性能是一种指标，表明软件系统或构件对于其及时性要求的符合程度。其次是软件的一种特性，可以用时间来进行度量。检验软件的性能一般可以从这几个方面作为衡量的标准：
● 响应时间：系统对请求做出响应所需要的时间；
● 并发用户数：同一时间段内访问系统的用户数；
● 吞吐量：单位时间内系统处理的客户请求数量；
对于性能测试，我们会考虑使用大促压测来检测系统的性能，或者简单的数据上限测试，使用工具批量造数据并请求即可检测基本的系统性能；
（3）异常测试：也成为逆向测试；考虑系统可能出现的异常，是否有做异常提示或兜底、降级等等；场景的异常场景如：系统断电、服务器宕机、网络故障、非法入参、系统升级、数据迁移等等。
（4）兼容性测试：新版本需求，老版本是否兼容，常见于APP测试，发新版，老版本功能正常，不会受到影响；
（5）安全性测试：对于系统中用户的敏感信息做脱密展示，考虑接口安全，使用用户A的账号不能查看到用户B的信息；
（6）回归测试：对于迭代性业务，需求一般是在系统原有代码上做变更，会影响原来的业务，需要保证原有的业务不受影响；
（7）权限测试：用户A是店铺01的商品管理员，他只能拥有管理商品的权利，并不能拥有操作财务的权利，否则很容易造成资损；
（8）容错性：系统有两台机器，一台机器出现问题时，另一台机器可以取而代之，保证系统的正常运行。
三、测试方案的延伸
根据上面的模块我们已经了解了测试方案的主干，接下来我们把主干延伸，就是一个测试方案需要的基本信息了。
参考资料：
《全程软件测试（第3版）》
《软件性能测试过程详解与案例剖析（第二版）》
