测试方案和测试计划，测试报告几乎都是每个测试人员都必须掌握的。但有时经常搞混，特别是测试方案和测试计划。

测试方案和测试计划的区别

方案和计划英文翻译都叫“plan”，但具体的区别：

什么是测试方案？
　　所谓测试方案是指描述需要测试的特性、测试的方法、测试环境的规划、测试工具的设计和选择、测试用例的设计方法、测试代码的设计方案。

什么是测试计划？
　　所谓测试计划是指描述了要进行的测试活动的范围、方法、资源和进度的文档。它主要包括测试项、被测特性、测试任务、谁执行任务和风险控制等。

测试方案-偏技术：属于技术层面的文档，从技术的角度对测试活动进行规划。主要使用什么技术、什么工具等，即怎么测。

测试计划-偏项目：属于组织管理层面的文档，从组织管理的角度对测试活动进行规划属于技术层面的文档，从技术的角度对测试活动进行规划。主要是目标，时间，人员，资源、环境等，即测什么。

从大的方面讲，测试方案包含测试计划。

测试方案和测试计划什么时候编写

测试方案：是在项目立项或者需求分析的时候，这时候你就要考虑产品/项目需要用什么方法测，比如是web、app等，使用的技术不一样；其二，每个阶段使用技术/工具也不一样，更多的是测试经理或领导在项目成立或需求分析阶段编写的，考虑总体的大致方案，每个版本的计划，风险等，这样后面知道需要怎么去进行测试，可以解决一些技术难题。

测试计划：是在项目执行的时候，更多的是测试带组人员安排并编写，其目的是看看这个版本你需要多少人、什么时候完成，这就是计划。

测试方案

测试方案分为大方向，和小方向，大方向是指项目的，小方向是每个版本。

小方案的测试方案接近测试计划，这个方案是跟项目经理评审，确定要做什么内容，了解项目情况，哪些需要测试，哪些不需要。

例如：

最小集测试（入口检查）、可生产性、合入故障（修改点）、功能测试、性能测试、压力测试、兼容性测试、自动化测试、外场测试、其他。

以上的确认下在这个版本需要测试吗？如果需要，要考虑需要什么技术或工具测试。然后这些安排谁去测试，什么时候测完等等，很接近测试计划，也顺便吧测试计划做了。

大方向一般内容模板如下（文档是死的，人是活的，根据实际去考虑）：

1	引言	4
1.1	编写目的	4
1.2	背景	4
1.3	预期的读者和阅读建议	4
1.4	参考文档	4
2	术语、定义和缩略语	4
2.1	术语、定义	4
2.2	缩略语	5
3	综合描述	5
3.1	软件功能	5
3.2	测试需求范围	5
4	测试风险	6
5	测试策略	7
5.1	测试方法	7
5.2	缺陷管理	8
6	测试计划	8
6.1	集成计划	9
6.2	集成测试进度安排	9
6.3	测试环境与资源配备	10
6.3.1	人员配备	10
6.3.2	测试环境	11
6.3.3	终端特性	12
7	测试报告	13

部分内容如下：

测试方法：

集成测试一般采用大爆炸测试&自底向上方法测试

1.功能测试：测试各功能（含协议、框架、驱动）是否存在问题，集群基本业务是否正常；
2.性能测试：在特定条件下，使用工具操作，是否出现问题或异常现象；
3.稳定性测试：跑monkey是否出现问题或异常现象；
4.疲劳测试：固定几台终端不关机、不重启，一致测试，考察终端承受能力；
5.压力测试：针对集群业务相关，如集群呼叫、短信收发、集群联系人存储、应用和按钮频繁连续操作等；
6.异常测试：在特殊场景下测试功能性，如迟后接入、异常操作、低电、业务中断等；
7.内存测试：使用工具获取应用测内存使用情况，提供研发分析；
8.并发测试：同时使用两个应用以上（含集群），如公网并发、短消息并发、音乐/视频同时并发；

测试报告：

其他的参照实际公司情况，根据模板或在扩展编写。

测试计划

测试计划相对就简单点，遵守5W+1H原则：

1.what：测什么 --目标

2.when：什么时候 --时间

3.where：在哪里测--环境

4.who：谁测--人员

5.why：为什么测--目的

6.how：怎么测--方法

简单来说：我们的测试目标，这个版本测到什么程度，测试目的是为了商用，还是合入故障验证，测试时间，几个人，几个模块，分多少用例，有什么环境什么资源，用什么方法，什么工具。。。。这些计划安排出来就明显，测过程需要些什么。

测试报告

测试报告就是给领导看的，那就把你的内容都安排放里面即可。比如，多少用例，多少人，多少bug，合入故障，解决故障等，最好是数字化图表化，这样领导一看就清楚。这个可以百度搜索模板，有些公司都有属于自己的模板。

记住，报告开头最明显的是告诉这个版本是否测试通过，这个有通过标准的，看公司怎么定义。

2021年森林督查暨森林资源管理“一张图”更新工作方案

各省、自治区、直辖市、新疆生产建设兵团林业和草原主管部门，国家林业和草原局各派出机构、各直属规划设计院、大兴安岭林业集团:

2018年以来，在我局统一组织下，各地统筹推进“天上看、地面查”的森林督查、森林资源管理“一张图”年度更新和国家级公益林监测工作，全面掌握森林资源动态变化情况，依法严厉打击违法违规破坏森林资源问题，森林资源管理秩序持续向好,取得了积极成效。为确保相关工作规范开展,我局研究制定了2021年工作方案(见附件1)，现将其和技术规定(略有修改，见附件2)印发给你们，请结合全国打击毁林专项行动，进一步落实主体责任，统筹谋划部署，强化自查质量，狠抓问题整改，不断提高森林资源管理水平。

特此通知
国家林业和草原局
2021年3月30日
附件:
1.2021年森林督查暨森林资源管理“一张图“更新工作方案
2.森林督查暨森林资源管理“一张图”年度更新技术规定

关注微信公众号，后台回复“2021”即可下载PDF完整版！

本文转自硬件十万个为什么

曾经说过，在开始动手画原理图之前，需要做需求分析，专题分析等等工作。但是在真正开工之前，有反复的方案设计的迭代过程。也有一些不是研发出身的老板跟我抱怨，硬件工程师让结构先设计、结构工程师说硬件工程师应该先给大致的需求，不知道应该谁先动。

工欲善其事,必先利其器是说:工匠想要使他的工作做好，一定要先让工具锋利。比喻要做好一件事，准备工作非常重要。语出《论语·卫灵公》：子贡问为仁。子曰：“工欲善其事，必先利其器。居是邦也，事其大夫之贤者，友其士之仁者。” 这个准备工作，当然不只是指工具，还有动手之前的策划、思考、评估、方案设计、架构设计等。

硬件工程师动手画原理图之前，需要画的一个东东就是，用“猥琐”（Visio）画出电路板方案框图。

当然，每个工程师都有自己的喜好。有的人喜欢用Visio、有的人喜欢用PPT，这都无所谓。关键是这个电路板的框图不是简单的拍脑袋就出来的。
它的诞生，就是一个电路板方案设计的过程。如果这个阶段拍脑袋、回板就会拍大腿，最后只能拍拍屁股走人了。

那么我们如何能够完成一个电路板的方案设计过程呢？除了凭借我们的经验，还有什么是我们需要做的呢？

【步骤一、建立归档文件夹，明确归档计划】

建议自建SVN的云服务器，讲需要归档的文件夹，按照本企业或者本项目的需求进行设立需要的文件夹。这些自然就是我们在产品研发完成一个完整的产品，需要产生和考虑的所有维度、需要归档的所有内容的纲领。
github或者内网文件夹共享其实都可以，但是github速度不快有点影响设计效率，内网文件夹不便于版本管理，当服务器出现故障会影响整个团队的开发，也不便于移动办公。

【步骤二、建立问题跟踪机制】
之前的系列，我们专门说过问题跟踪，我们针对当前项目，需要建立例会的制度，根据人员情况和人员的素质不同，需要有针对性的进行例会。可能是每天晨会、也可以是每周例会，灵活把握跟踪频度。
但是我们需要针对项目建立该项目的问题跟踪表格，便于整个项目过程中所有出现的问题，跟踪闭环，避免问题跟踪出现遗漏。

当然我们还可以计算更复杂的表格，以前我们做个一个表格可以计算每个任务的完成提前、拖延的天数，可以作为KPI进行考核。（这个做法不提倡）

【步骤三、需求跟踪】
在华为、这个部分会由SE（系统工程师、system engineer不是stupid engineer）进行分解分配。硬件工程师根据分解分配结果对照检查，并创建单板需求跟踪表。跟踪表完成后需召集SE、整机结构、产品工程工艺（PCB Layout工程师、工艺工程师）、生产、测试、软件等周边人员评审归档。

当然，我们从来都是期望需求能归档之后不再修改。但是我们在设计过程中会发现会不可避免的进行修改。但是我们在TR3之后是应该禁止修改的，如果在TR3之后增改需求，所有的需求变更需要通过CR（需求变更电子流）进行跟踪。

从硬件稳定的角度来说，越在项目的后期，需求的变更带来的影响越大，带来的设计变动，对质量的影响越大。但是随着敏捷的思想，以及客户需求可能在硬件长周期过程中的变化，很多场景我们不得不去变更需求。

需求的分析和理解往往不可能一步到位，研发人员的理解也有可能不能非常准确理解现场场景。所以需求跟踪完成之后，需要进行两轮的需求的串讲、反串讲。（串讲，是指需求发布者与开发者讲解，反串讲是指开发者理解需求之后，对需求发布者进行讲解）。

需求反串讲，是设计者向SE、项目经理等角色逐条讲解硬件需求，形成统一的认识。对于已有实现方案的需求，讲解要包含方案。串讲和反串讲一定要让SE/软件/测试领域全程参与，提出的问题要在详细设计开始前全部解决闭环。

【步骤四、关键器件分析】
我们研发一个新项目的时候，不可避免的会使用我们没有使用过的器件，甚至是整个公司都没有使用过的器件。

我们根据设计需求选定了基本方案之后，需要对新器件、关键器件进行应用分析，输出应用分析报告，并召集相关人员、管理者、有经验的工程师进行评审和分析。

方案分析过程中需要参考和更新器件的Bug List和设计注意事项。同时收集案例，并给出应对解决措施，提前预防已知问题。

关键器件不仅仅局限于新引入的器件，还包括复杂的器件、开发人员及项目组经验积累都不足的器件。

这个关键器件的分析，我们需要对器件的datasheet进行分析、寻找并Demo板、查阅厂家的errata，寻找已经产品化或者已经完成过的设计，部分电路的改动，需要动手做电路实验、或者做电路仿真，进行验证。

【步骤五、预布局及结构设计】
我们根据需求，明确了必要的功能、性能、然后明确了关键器件，也就是电路板上面大功率器件、新器件、复杂器件都已经敲定了。那么我们可以做一个预布局，明确电路板尺寸，形状的大致想法。

我们为了实现一个准确的预布局，需要输出一个预布局原理图，要求原理图至少包含主要器件、电源、热敏感器件和接插件。

预布局需要把电路板的信号流向、器件功能、主要器件的电源管脚分布、整个电路板的电源的基本分布和流向。

然后把相关的诉求，提供给ID工程师，给一个基本的ID设想，然后由结构工程师进行结构设计的细化。

如果是成熟的机框，则这个过程相对简单一些，例如ATCA、VPX这种标准机框。一些个人消费电子产品这个过程反复的可能性非常大。

为了避免这个过程，硬件工程师在完成初步的预布局，之后应该把自己的设计诉求，全部记录在《结构要素图设计说明书》中，提供给结构和ID工程师。

【步骤六、散热评估】
硬件工程师需要提供单板布局和器件热耗（功耗）表、各器件散热参数。数字器件要注意提供尽量准确的功耗数据，特别是DDR/FPGA等器件要根据使用场景进行计算。提供的器件的功耗需要准确，避免过设计，也避免散热风险。

【步骤七、新器件导入评估】
在华为，一个新器件的导入是非常复杂的，我们不在华为，选择新器件，也需要谨慎选取，并做相关评估。

这个其实应该是一个sourcing的过程：我们不但需求考虑新器件功能是否满足我们的需求，同时需要考虑：可靠性、可采购性、成本、焊接工艺、功耗、散热等维度。

【步骤八、背板管脚分配、板间FMEA分析】
我们需要根据背板标准，分配电路板的管脚。如果是新设计背板，需要考虑背板连接器的成本、速率、数量。

在产品设计阶段，FMEA针对所有板间信号/关键器件展开分析，可确保无故障遗漏。用以分析所有故障影响，同时做到优化故障管理能力。在这个过程中存在着两个标准，那就是对于严重故障，要求尽最大可能避免；对于需要处理的故障，要求能够监测并定位到现场置换单元（FRU，Field Replacement Unit）。

【步骤九、归一化分析】
归一化作为DFx的一项内容，需要硬件特别关注。每个产品需整理自身的BOM归一化器件清单，常用器件选型只能在归一化清单中选择。归一化清单为本企业或者本部门使用过的器件或者采购过的器件。

尽量减少器件种类，有效减少器件种类、不但降低管理成本、同时也降低加工和采购成本。

【步骤十、可重用性分析】
所有单板都要进行可重用性分析，包含三方面内容：
1. 本单板可重用的已有电路；
2. 本单板希望能够重用的电路；
3. 本单板完成开发后，可提供其它项目重用的电路。

【步骤十一、早期BOM审查】
1. 方案确定后就把已确定的关键器件，通过采购进行关键器件的意见反馈。
2. 所有非常规器件、非主流器件、器件必须逐一和采购进行确认，详细评估风险，有风险的器件要选择替代方案。
3. 有关键器件在设计过程中变更时，还需要与采购人员进行确认。

经过上述十一个步骤
1. 我们选定了关键器件、并进行了预布局、明确了结构的设计，排除了可行性、采购、可靠性、散热方面的风险。

1. 通过需求跟踪，确保所有需求能够在设计中落实，最终设计的产品符合客户的需求。

2. 通过归一化、可重用性分析，提升了整体的设计效率，并且隐性的提升了设计质量。

3. 通过《问题跟踪表》、建立《归档文件夹》，确保了交付的项目管理。
   完成这些准备工作之后，我们的电路原理框图、电路原理图的设计才是让人安心和可靠的。