作为一名软件测试工程师，为项目制作完成的测试方案并执行，是我们日常工作的重要部分，同时，也是一名合格的软件测试工程师应有的专业素养。下面，我们就一起来了解下完整的测试方案流程。
1、项目的测试计划有制定
     项目的测试计划需根据项目计划、需求规格说明书及开发计划来制定，并按照不同的测试阶段，设计对应的测试计划。
这样做，主要是为了明确组织形式、测试对象、定义测试通过/失败的准则、测试挂起/恢复的准则、测试风险的防范措施、合理分配测试任务以及测试交付的工作产品等。
2、测试分析与设计
     我们都知道，测试方案设计阶段，就是将设计需求进行细化分解，变成若干个可执行的测试过程。
     通常情况下，我们需要根据不同阶段（单元测试、集成测试、系统测试、验收测试）的被测对象，以及每个阶段所要进行的测试类型（功能测试、性能测试、安全性测试、可靠性测试以及兼容性测试等）的不同，进而采用不同的测试策略去设计。
     因此，在划分归类时，我们一定要做到心中有数。
3、测试方案的实现与执行
     我们都知道，测试方案的实现阶段，主要根据：测试脚本、测试用例来完成。
     这当中，测试脚本通常用在自动化测试和性能测试中。我们一般根据自动化测试的目标、性能测试场景，来开发相应的测试脚本。
     而测试用例，则是主要用来指导测试执行。它可以根据用例设计的方法来设计。在不同测试阶段，测试方法也不尽相同。
例如，白盒测试用例设计方法主要有逻辑覆盖法、基本路径法等；黑盒测试用例设计方法主要有等价类划分法、边界值分析法、流程设计法、判定表分析、因果图分析法、正交试验法、错误推测法以及异常处理等。
     对于测试方案执行来说，在执行前，我们首先要根据项目的测试情况，来搭建测试环境。并在测试中，尽量模拟用户的实际环境来进行搭建，这样可以使得到的数据更接近用户的真实结果。
     其次，根据不同阶段，我们在执行前，也应对方案做针对性的调整。比如，性能测试在执行前，需要进行测试数据准备；再比如，系统测试在执行前，需要进行预测试。一般情况下，如果需要进行预测试的，还必须达到预测试的标准指标：90%全部通过。
     另外，在执行时，应严格按照测试计划进行。如果项目时间紧凑，也可以按照用例的优先级进行测试。
     在执行的过程中，我们需要记录每个缺陷（截图、错误日志的消息等）。在每天的工作日报中，我们不仅要将问题反馈在日报中，还需要实时把缺陷记录到缺陷管理工具中，便于后期进行跟踪、管理。
     最后，等开发修复缺陷后，我们还要进行回归测试。
4、测试评估报告
     在做测试评估报告时，我们要根据缺陷的记录，将缺陷的分布、密度以及发展趋势加以分析与评估，并着重分析软件在整个研发过程中，引发缺陷的根本原因。这样便于后期协助开发人员修改，也可以为软件产品的质量，提供更为真实的数据依据。
写在最后
     在测试方案全部制定并执行完毕后，我们除了要整理出测试报告之外，还需要将测试中所涉及的所有文档、数据及相关的资料，进行整理归档，并加以检查。例如：
     1）对测试项目进行全过程、全方位的检查。例如，测试用例是否全部执行；检查测试是否有遗漏；
     2）检查有没有未解决的问题。对项目存在的缺陷逐个进行分析，了解对项目质量影响的程度，从而决定整个测试过程是否可以告一段落；
     3）检查测试报告是否达到产品质量已定义的标准，是否符合测试结束的标准以及对测试产出的风险记录进行评估，最终将测试报告定稿。
另外，在测试结束后，我们最好可以通过对项目中的问题进行分析，找出流程、技术或管理中所存在的问题根源，将相关的经验教训进行总结，并分享到项目组中，避免后续工作中产生类似的错误。

所谓的测试用例设计就是将软件测试的行为活动，做一个科学画的组织归纳。软件测试是有组织性、步骤性和计划性的，而设计软件测试用例的目的，就是为了能将软件测试的行为转换为可管理的模式。软件测试是软件质量管理中最实际的行动，同时也是耗时最多的一项。基于时间因素的考虑，软件测试行为必须能够加以量化，才能进一步让管理阶层掌握所需要的测试过程，而测试用例就是讲测试行为具体量化的方法之一。

简单的说，测试用例就是设计一个情况，必须能够正常运行并且达到程序所设计的执行结果。如果程序在这种情况下不能正常运行，而且这种问题会重复发生，那就便是软件程序人员已经测出软件有缺陷，这时间就必须将这个问题标示出来，并且输入到问题跟踪系统内，通知软件开发人员。软件开发人员接获通知后，将这个问题修改完成于下一个测试版本内，软件测试工程师取得新的测试版本后，必须利用同一个用例来测试这个问题，确保该问题已修改完成。

因为我们不可能进行穷举测试，为了节省时间和资源、提高测试效率，必须要从数量极大的可用测试数据中精心挑选出具有代表性或特殊性的测试数据来进行测试。

使用测试用例的好处主要体现在以下几个方面。

①在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率。

②测试用例的使用令软件测试的实施重点突出、目的明确。

③在软件版本更新后只需修正少部分的测试用例便可展开测试工作，降低工作强度，缩短项目周期。

④功能模块的通用化和复用化使软件易于开发，而测试用例的通用化和复用化则会使软件测试易于开展，并随着测试用例的不断精化其效率也不断攀升。

具体的黑盒测试用例设计方法包括等价类划分法、因果图法、边界值分析法、判定表驱动法、正交试验设计法、功能图法等。应该说，这些方法是比较实用的，但采用什么方法，在使用时自然要针对开发项目的特点对方法加以适当的选择。下面介绍3种常用的方法。

1.等价类划分

等价类划分是一种典型的黑盒测试方法。等价类是指某个输入域的集合。它表示对揭露程序中的错误来说，集合中的每个输入条件是等效的。因此我们只要在一个集合中选取一个测试数据即可。等价类划分的办法是把程序的输入域划分成若干等价类，然后从每个部分中选取少数代表性数据当作测试用例。这样就可使用少数测试用例检验程序在一大类情况下的反映。

在考虑等价类时，应该注意区别以下两种不同的情况:

有效等价类:有效等价类指的是对程序的规范是有意义的、合理的输入数据所构成的集合。在具体问题中，有效等价类可以是一个，也可以是多个。

无效等价类:无效等价类指对程序的规范是不合理的或无意义的输入数据所构成的集合。对于具体的问题，无效等价类至少应有一个，也可能有多个。确定等价类有以下几条原则:

如果输入条件规定了取值范围或值的个数，则可确定一个有效等价类和两个无效等价类。例如，程序的规范中提到的输入条包括“...项数可以从1到999...”，则可取有效等价类为“1到项数<999”，无效等价类为“项数<1，,及“项数>999”。

输入条件规定了输入值的集合，或是规定了“必须如何”的条件，则可确定一个有效等价类和一个无效等价类。如某程序涉及标识符，其输入条件规定“标识符应以字母开头..”则“以字母开头者”作为有效等价类，“以非字母开头”作为无效等价类。

如果我们确知，已划分的等价类中各元素在程序中的处理方式是不同的，则应将此等价类进一步划分成更小等价类。

输入条件有效等价类无效等价类。

根据已列出的等价类表，按以下步骤确定测试用例:

①为每个等价类规定一个唯一的编号﹔

②设计一个测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类。重复这一步，最后使得所有有效等价类均被测试用例所覆盖﹔

③设计一个新的测试用例，使其只覆盖一个无效等价类。重复这一步，使所有无效等价类均被覆盖。这里强调每次只覆盖一个无效等价类。这是因为一个测试用例中如果含有多个缺陷，有可能在测试中只发现其中的一个，另一些被忽视。

等价类划分法能够全面、系统地考虑黑盒测试的测试用例设计问题，但是没有注意选用一些“高效的”、“有针对性的”测试用例。后面介绍的边值分析法可以弥补这一缺点。

2.因果图

等价类划分法并没有考虑到输入情况的各种组合。这样虽然各个输入条件单独可能出错的情况已经看到了,但多个输入情况组合起来可能出错的情况却被忽略。采用因果图方法能帮助我们按一定步骤选择一组高效的测试用例，同时，还能为我们指出程序规范的描述中存在什么问题。

利用因果图导出测试用例需要经过以下几个步骤:分析程序规范的描述中哪些是原因，哪些是结果。原因常常是输入条件或是输入条件的等价类。结果是输出条件。

分析程序规范的描述中语义的内容，并将其表示成连接各个原因与各个结果的“因果图”。

由于语法或环境的限制，有些原因和结果的组合情况是不可能出现的。为表明这些特定的情况，在因果图上使用持殊的符号标明约束条件。把因果图转换成判定表。把判定表的每一列写成一个测试用例。

3.边值分析法

边值分析法是列出单元功能、输入、状态及控制的合法边界值和非法边界值,

设计测试用例，包含全部边界值的方法。典型的包括IF语句中的判别值，定义域、值域边界，末受控状态等。边值分析法是以边界情况的处理作为主要目标专门设计测试用例的方法。另外，边值分析不仅考查输入的边值,也要考虑输出的边值。这是从人们的经验得出的一种有效方法。人们发现许多软件错误只是在下标、数据结构和标量值的边界值及其上、下出现，运行这个区域的测试用例发现错误的概率很高。用边值分析法设计测试用例时，有以下几条原则:如果输入条件规定了取值范围,或是规定了值的个数，则应以该范围的边界内及刚刚超出范围的边界外的值，或是分别对最大、最小及稍小于最小、稍大于最大个数作为测试用例。如有规范“某文件可包含1至255”个记录.“，则测试用例可选1和255及0和256等。针对规范的每个输出条件使用原则，如果程序规范中提到的输入或输出域是个有序的集合(如顺序文件、表格等)就应注意选取有序集的第一个和最后一个元素作为测试用例。分析规范，尽可能找出可能的边界条件。一个典型的边值分析例子是三角形分类程序。选取a, b, c构成三角形三边，“任意两边之和大于第三边”为边界条件。边值分析相等价类划分侧重不同，对等价类划分是-一个补充。 如上述三角形问题,选取a=3, b=4, c=5，a=2, b=4, c=7则覆盖有效和无效等价类。如果能在等价类划分中注入边值分析的思想。在每个等价类中不只选取一个覆盖用例，而是进而选取该等价类的边界值等价类划分法将更有效，最后可以用边值分析法再补充--些测试用例。

1.软件需求的风险

        主要表现在以下的几个方面：

        1）软件需求本身不清晰或者开发商对产品的需求特性理解不准确有偏差，这样导致最终开发的产品功能可能不是用户真正想要的功能。

        2）需求变更风险，在项目的后期用户总是不停的提出需求变更，从而影响设计、代码，并且最终反映到测试中来。需求变更后，测试用例没有及时更新；更重要的是在项目的后期频繁的需求会导致测试的时间不充分。

        【解决办法】

        1）在项目开发过程中的每一个阶段，尽量让有决策权的核心用户看到产品已经实现的每个阶段的功能，如果不是用户想要的东西尽早提出来，总之要让用户参与进来。

        2）另外对于后期用户不停的提出需求变更作为开发商来说，应该多和有决策权的核心用户多沟通，争取更充分的研发时间和测试时间，或者最好能把后期提出的功能放到下一个版本中实现。

2.人员的风险

        人员的风险常常表现在以下等方面：

        1）核心测试人员的请假、离职

        2）测试人员的工作态度不端正、工作状态差

        3）测试人员的测试技术不足，比如说产生测试的思维定势，有些有问题的地方始终测试不到位

        【解决办法】

        1）对于核心的测试人员可能离职而延误测试的情况，作为测试管理者可以在平时给这些核心人员配置一些可以候补的测试人员来向他们学习，以避免这些核心人的请假、离职的时候，可以立即补充上来。对于一些关键的业务和技术一定要有文档。

        2）另外可以通过对测试工程师进行考评的方式监督他们每天的工作情况，看看其工作态度是不是尽心尽力符合目前的项目测试工作，如果发现不符合的话，测试管理者可以找其单独谈话督促其改正。

        3）每个测试工程师的思维方式肯定有差别，所以测试管理者多让这些工程师在测试每一轮后，在进行不同模块的交叉测试。

3.代码质量的风险

        如果开发人员提交上来的代码质量很差、很烂的话，软件缺陷很多，那么对于测试工程师来说漏测的可能性就越大。

        【解决办法】

        对于程序员的提交给测试部门的代码一定要在前期做好充足的单元测试、对于核心模块的代码一定要有资深的研发工程师进行前期检查

4.测试环境的风险

        测试人员在测试过程中搭建的测试环境，虽然原则上是尽可能模拟用户实际使用的环境。但是不可能100%完全和用户的环境一样，这样就会存在一定的风险，因为有些软件的缺陷只有在特定的环境下（包括硬件、操作系统、杀毒软件和软件的不同版本的补丁和用户实际使用的数据等）才能出现。

        【解决办法】

        测试部门在测试过程中搭建的测试环境的时候，尽量尽一切可能无限制的模拟用户使用的环境（硬件、操作系统的版本和补丁，数据库的版本和补丁）在测试的时候尽量和用户沟通要到用户真实的数据进行测试。以减少风险。

5.测试工程师对产品的业务不熟悉

        对业务产品的不熟悉一般表现在以下几个方面：

        1）测试工程师不了解用户究竟是如何操作该产品和用户的操作习惯

        2）测试工程师介入到项目测试的时间太短

        【解决办法】

        可以找一些相关行业的专家给测试人员进行培训，当然用户也就是最好的行业专家。另外测试人员一定要在项目的前期就介入到项目中去熟悉产品，对产品越熟悉找出的软件缺陷越有价值。

6.测试深度和广度的风险

        1）测试的广度，用户的操作肯定是千变万化的，测试工程师在测试的时候肯定不能100%覆盖到这些千变万化的操作。有些极端的情况容易被遗漏、测试不到。

        2）测试的深度，比如有些软件只有在特定的情况下，比如多用户并发的情况下使用的过程中才会产生软件的缺陷bug，但是测试工程师在测试的时候忽略了这种情况，只有某几个测试工程师在测试使用这些功能。

        【解决办法】

        测试工程师在写测试用例的时候尽量提高测试用例的覆盖率（在测试用例完成后组织进行测试用例的评审工作），如果测试用例能覆盖不同的用户千变万化的操作最好。特别是一些边界值、深层次的逻辑关系等。以及用户实际使用环境下的场景（比如大用户量的并发操作等）。

7.测试工具本身可能产生误差

        1）测试工具能模拟用户的手工操作，但是这种工具本身就存在误差、或者使用者操作不当产生的误差，比如：在项目后期的回归测试的时候使用自动化功能测试工具QTP进行回归测试的时候，由于修改了某些脚步导致QTP每次测试都能通过，但是到用户现场的话有可能会最简单的功能都通不过。

        2）在进行性能测试工具的时候大家常常使用Webload、Jemeter、Loadrrunner等，但是这些工具并不能100%模拟用户的并发操作；比如用工具模拟500个用户同时并发登录系统，但是这些并发都是从1台或者某几台测试机器上发出请求的。但是在用户实际使用环境的情况下这500个用户可能来自全国或全世界的各个地方。

        【解决办法】

        1）对于自动化的测试工具，一定要选择一些知名大企业比较成熟的测试工具，比如：HP公司的Loadrunner，QTP或者IBM的系列测试工具

        2）测试工程师在使用测试工具的过程中应该大胆的排除一些不合理的测试值，比如：进行了5次的大用户的并发测试，其中有一次的测试结果与另外4次的测试结果偏差较大，那么测试工程师就可以排除这1次偏差较大的测试（因为这1次测试结果可能受到一些其他因素的影响而导致不准确，比如受到网络因素的影响等）。

        3）另外测试工具仅仅是提高测试效率的，由于测试工程师在使用测试工具的过程中某些参数设置不合理而导致测试结果不准确。所以不要过分的相信测试工具，最后一定要进行人工的审核和检查才可靠。

        4）另外可以用不同的测试工具运行相同的测试场景，如果不同的测试工具运行相同的测试场景的测试结果相近的话，可以认为这种测试是有效的。

8.测试资源的不充分

        测试资源的不充足表现在很多方面，比如：

        1）硬件资源不够，国内的很多小型的软件企业开发和测试居然使用同一个环境，这样肯定会影响测试效果的。

        2）软件资源不充分，比如在项目的后期进行回归测试的工作量很大，但是测试的人手不够。

        3）测试的时间不充足，在企业实际的研发过程中，研发人员由于各种原因（如用户提出修改或者新增某些功能、甚至研发人员的技术水平等）导致提交到测试部门的延迟，这样无形中减少了测试人员的测试，测试时间不充足会影响到测试的效果的。

        【解决办法】

        作为一名测试管理者有义务向公司里申请更多的测试资源，如购置独立的测试服务器把测试环境和研发环境分开；要求招聘更多的测试人员；测试管理者应当做好测试风险的预估，比如：在制定测试计划的时候要预留一定的多余时间以应对临时变化的一些特殊情况。

一、目的和意义

二、测试内容

三、测试流程