标签：style blog http io ar os 使用 sp strong
在软件测试过程中，测试方案起到什么样作用？ 如何编写测试方案？等等类似关于软件测试方案的问题，往往没有一致的答案。不同的公司往往有自己的测试方案模板，测试工程师的理解也会有所差别。以下是我关于测试方案的理解，希望能够抛砖引玉。
编写测试方案的目的是啥？也许有人会说：根据产品功能需求（比如PRD）文档，参考产品设计文档，测试工程师就可以理解需求、设计测试用例了，不需要测试方案文档，即使写了测试方案，也主要是把产品需求和设计文档内容copy一下而已。有以上这样的想法，是因为没有真正理解测试方案的作用。其实软件测试方案的作用非常类似于产品设计说明（文档），开发工程师根据产品功能需求和设计说明来编码实现功能，而测试工程师需要基于产品功能需求和测试方案来设计和执行测试用例，同时也要参考产品设计说明文档，所以测试方案目的是: 在方向上明确要测什么、怎么测，以及达到什么样质量标准。
如何产出有效的测试方案？ 如果只是把产品需求和部分设计说明内容copy一下，给出测试进度计划，这样的测试方案对用例设计和执行意义不大。我想作为方案，至少要包括几个关键因素：范围，时间，资源和质量，而不同行业产品，测试方案应该相应地进行对这几个关键因素进行分解和调整。对于软件测试方案，我想主要应该包括：测试需求分析，测试策略，测试资源，测试计划，项目风险和质量，如果我们能够明确以上这些因素，这样的测试方案就一定能够有效地指导我们测试设计和执行。
测试需求分析：测试需求分析就是把产品需求（比如PRD文档）和对用户的理解（用户体验）转化、分解成测试功能点，产品需求是我们测试需求主要输入，但不是全部，我们还需要仔细分析产品设计说明，可以产出更多可测试的功能点（这些功能点往往没有包含在产品需求中）。还要加入对性能、安全、接口和回归测试范围分析。测试需求是确定测试进度计划和资源的主要依据。
测试数据： 在此简要说明测试数据的形成，如以客户单位具体的业务规则和《XX系统需求分析说明书》，参考《XX系统概要设计说明书》、《XX系统详细设计说明书》和《数据规格说明书》中规定的运行限制，设计测试用例，作为整个XX系统的测试数据。
测试策略： 测试需求确定后，我们就要思考如何验证测试需求中的功能点，采用什么测试方法：手工、自动化测试和是否需要新方法或工具，比如新功能采用手工测试，部分回归用例使用自动化脚本，用新方法来准备测试数据，采用合适的工具验证复杂的测试结果。确定测试优先级，确认哪些业务功能是最重要，那个是新代码模块，哪些旧模块改动较大，与之相关的功能点要重点测试，测试不可能１００％覆盖，但是对于重要、高危的功能必须要全面验证，保证资源投入到当前最高优先级的任务。
测试资源：一般情况下，团队同时有多个项目，测试PM需要根据项目的优先级来确定每个项目的测试资源，一般情况下，软件测试资源主要包括：人力和设备机器。
测试计划：根据测试需求和策略，结合项目优先级和测试资源情况，评估测试进度计划，一般情况下，测试资源越充分，测试进度越乐观，但并非绝对，有时候一些软件ＢＵＧ会阻塞测试进度，这也是项目风险的一部分。
风险管理：在测试执行开始之前，对可能的风险进行分析和识别很重要，可以提前进行预防和采取应对措施，所以项目过程中，我们需要定期评估测试进度情况，提前进行风险预警。
质量：质量是指测试项目需要达到的标准，各个公司和项目都会有相应的标准要求，由于质量标准可以是公司内多数项目共识，所以也可以不必在测试方案中列出。对测试项目来说，比较常见的是以测试用例执行率、通过率和未关闭BUG级别/数量来设定质量标准。
测试方案初稿完成后，必须要请项目相关测试、开发和需求方同事评审，澄清对需求和设计的理解，讨论测试方法，往往在测试方案评审中，我们能够对产品需求进行完善，给产品详细设计提供更多输入，使开发同事能够提前完善代码逻辑，而且测试工程师也能够进一步理解需求和设计，从而有助于设计完善测试用例设计，保证测试覆盖率。
测试方案包括测试的目的以及测试用例。
测试方案 != 测试用例
测试方案不属于测试计划
1、测试方案的设计，是要解决从软件需求、设计需求以及其他需求中提取出来的测试需求，该如何测试的问题。
测试方案的设计，关键是要提醒在测试对象的分析过程中，最终得出合适的测试点和测试方法。
2、从过程中来讲，相对于开发过程而言
|-----》概要设计/详细设计------》编码
需求-------
|-----》测试方案设计------》编写用例
我个人觉得从上面的两个图来看，之前一般情况下，我们只是“需求---》用例”这个过程，与开发过程对比，确实少了一个从高层次对需求的分析，分析问题的过程，总是逐步的分解，“需求--》用例”的过程是不是太快，或者说我们是不是没有把对需求的分析写出来。在实际的工作中，我曾经按模块列出测试功能点，在列测试功能点的时候大家一起分析，讨论，如果一定要从概念上套用的话，那么我们没有把测试方案写出来，是在我们的脑袋里，或者说我们是不自觉地在做这样的事情。以后有机会再去实践吧。
3、方案的设计
测试方案设计三步曲
确定测试范围-----》测试对象深入分析-----》确定测试点/测试方法
需注意
A、不能只有结论，还要有分析过程，说明对象的测试方法为何是这样的方法，而不是那种方法。
B、方案的设计要以理服人，要有理有据的分析。
C、设计依据不局限与需求，还要参考概要/详细设计等开发文档。
D、方案的分析结果就是测试点，和测试方法。
现在公司在搞项目管理的规范化，分我配一个新开始的项目开始跟踪。通过项目开发计划，发现需要写一个测试方案，可是目前除了项目的一个总体描述、页面规范、代码规范和需求说明文档外没有任何东西了。这样写东西感觉有些别扭，因为对于系统的功能，只有通过需求文档的描述，对于系统的功能只能完全靠想像了。
一开始我想着是将全篇的需求文档全部看完，然后再分析功能，写出相应的测试点，看了几个模块后，发现这样效果并不好，因为对于整个系统的功能除了文档外没有任何其他可参照的内容，而且是电子文档不像纸制文件可以一边看一边用笔划着帮助增强记忆。至于看到后面的时候，再看以前已经看过的功能，感觉仍然像是看一个完全新的功能。于是改变了看的方法。按照下面的步骤对测试方案进行整理。
1.看单个模块的总体介绍
在看的过程中，通过总体介绍对于模块功能有一个大体上的了解，根据功能的了解在纸上写出大概的功能点，这点感觉很重要，因为这样在看模块功能的具体介绍的过程时，可以看一出与自己理解功能之间的偏差，并进行记录，提交给开发人员对描述进行调整
2.看单个模块的具体功能的介绍
看具体功能的时候，需要逐字的查看，如果遇到存在歧义的内容时，使用WORD的审阅功能进行标识，如有必要可对纸制中记录的内容进行修改。
3.整理单个模块的测试点
测试点的整理就是根据了解对功能点的整理， 这里对功能点进行了标号，是想对于下一步的测试用例可有一个参照，这样方便用例与功能点的对应，方便查找问题的功能点信息
4.对于与当前整理相关的已经整理模块的测试进行调整
如果遇到与已经整理过的模块相关的模块功能整理，内容之间不完善或者存在理解错误时，对以前的功能点进行调整，或者由项目经理人解答后再进行调整。
我在看需求文档时，由于开发人员处于封闭状态，与我没有在同一办公地点，沟通上不上很方便。因此我并不是遇到问题就立即向项目经理询问，这样也很影响他们的工作，毕竟他们工作时也是有思路的，总打断不好。而是进行很详细的记录，在看完一遍文档后，统一进行整理，询问项目经理的程序功能具体情况，这是用邮件的方式来进行的。他们会在文档中写出解答意见，我在需求文档当中再将答复意见一同记录，以便以后查询。
目前就是这些心得了，如果有了新的再补充吧。就到这里啦。
标签：style blog http io ar os 使用 sp strong
原文地址：http://www.cnblogs.com/shengs/p/4094327.html
