在我们的团队中，QA角色身兼两职：测试和过程改进。以往我们对新进来的员工的期望值是先承担测试任务，在能较好地完成测试任务之后，才考虑让他参与一些SQA的工作。因此，有些已经进来大半年的同事，感觉对SQA还是没有什么概念，更没有机会去实践。或者有的同事想参与一些SQA的工作，却感到没有头绪，不知如何下手。而实际工作中我发现，QA的能力可以在每日工作中从点滴、从最开始就培养，这个与以往有没有SQA的知识和经验没有关系。因为简而言之，QA的工作主要围绕持续改进展开。而无论你是否有经验，每天的工作中你都在以自己独特的视角看问题，并可能看到改进的空间。那么，测试人员如何在日常工作中去逐步培养自己的QA能力呢？

1.找到问题

感受到一个问题，有时是出于关怀，你发现有人/自己正因为某件事情而痛苦；有时是出于怀疑，你发现有件事情和你想象/预计的不一样；还可能是出于直觉。但感受到问题其实并不是一件容易的事情。

如果感受不到问题，我们可以试图通过多种方法积极寻找。

如果你刚到一个项目组,提不出问题，可以先去听听别人（项目组成员、用户等等）的抱怨，或者想想自己痛苦的地方（比如找不到文档，系统操作不直观学习起来困难等等），这些就可能是问题。另外，为了培养自己找问题的习惯，可以给自己一个定量目标，每周去总结一个“疑似问题”。经过实践，这个带点自我强迫的方法对于找问题很有帮助。比如，虽然你的测试用例经过了和开发人员的评审，但是测试时你却发现几个重要的分支或者逻辑还是在代码中忘记实现了。除了报告缺陷，是否还有什么有共性的问题存在，并值得改进呢？

如果你在一个项目组大家合作得不错，似乎没有什么问题，但一个看 似不错的结果其实可能隐藏了问题。比如，完成工作，交付高质量的软件产品可以通过多种渠道实现，而非一定体现了高质量。可能是牺牲了时间进行好几轮的测试 和修复和全面的回归测试，又或者某一块有一个英雄人物能够以一己之力确保这块没有问题。又如，虽然大规模代码重构的时候，内部测试能找到大部分重要的缺 陷，但是否测试人员心理还是很抗拒和没底的？虽然这些问题不是单靠测试人员就能改善或者达到，但找到影响质量的问题确实需要测试人员的独立视角和贡献。如 果一个测试人员、一个测试团队能够跳开测试的圈圈，从更广阔的角度看到影响质量的其他环节，帮助开发人员克服一些老的制约生产力和质量的毛病或者习惯，从而提高开发团队的水平，而更高开发水平的开发团队又对测试团队会提出更高的要求，那么这样的良性互动是我们都想看到的。现在被大家所广泛追捧的敏捷开发就提倡忽略角色的分工，大家一起为质量贡献自己的一份力量。

前面说的是流程方面的问题，其实即使是被测程序的问题也存在于在整个软件开发周期。虽然传统对测试的理解是测试找问题更多集中在执行阶段，但借用QA的预防为主的思路，程序的问题也可以通过对需求和设计的评审及时发现和纠正，避免后期更大的浪费。

2.探究问题

感 受到问题之后，需要一种探寻真相的精神去一探究竟。很多人能感受到问题，但是很遗憾地是当有更具体的任务在手头的时候，往往就忽略了这个问题。或者知道问 题很大，也知道有各种原因的阻碍，因此采取放任自流的态度。这里要介绍一个好的习惯，就是把你当前没有时间去细想的问题先记录下来，以后再找机会去跟踪执行。类似outlook的任务或者一些桌面电子便签等工具可以帮助你设定任务及提醒执行。除了记录，还有一个好习惯就是去外部寻找一些同行的交流。如果看到同样/类似的话题，相信会驱使你有更大的兴趣去看自己碰到的问题，也启发你从不同角度看问题。

QA的工作更多的针对的是有共性的问题，所以对这类问题的探究往往需要多个样本。换言之，在报告每一个缺陷的时候我们是在做测试，而对测试结果进行总结、归类、抽象出背后共性的问题则向QA靠近了一步。

3.判断问题

3.1判断一个问题是否真的是问题

测 试人员通常看到实际执行结果后就能马上判断出其与预期结果之间的差异，从而判断是否存在问题。但过程改进相关的问题就没有那么一目了然了。比如，我们收到 一个来自生产环境的缺陷，是因为一个需求变更的影响点大家都没有想到，直到生产环境暴露出来。开会的时候有人提出我们的开发流程不完善，如果能够建立起需 求、设计和测试用例的跟踪矩阵，那么在做影响分析的时候就能顺藤摸瓜，避免此类问题了。听起来不错，是么？可是，如果我们细想，这种类似问题在生产环境对 用户的影响大么？可以绕过去么？此类问题出现的次数多么？如果我们建立这个跟踪矩阵，维护代价有多高？前提还是我们首先要想到所有的内在联系（而这个本身 就是无法确保的）。两相权衡，“没有这个跟踪矩阵”是我们现在的问题么？

“判断一个问题是否真的是问题”最好能广泛听取不同的意见，并找到根源。

3.2判断一个问题是否需要被马上解决

“判断问题是否需要马上解决”在某种程度上这有点象测试人员去设定缺陷的优先级。虽然所有被发现的缺陷都被记录，但是当前版本需要修复的或者可能只是其中一部分，而这一部分中还有需要尽快修复的和可以稍后修复的差别。过程改进的问题也是一样，有个主次和优先级之分。

4.解决问题

对于确实是问题的，我们应该去积极地寻找解决方案。但是新到一个公司或者项目组，发现了问题之后，不要急着去提出自己的解决方案，而应该先试图了解它的来龙去脉和曾经进行过的改进尝试，以及执行中实际的一些阻碍。

解决问题通常牵涉到开发团队中各个角色，除了明确负责的一方，还要对参与的其他方也进行充分的沟通。

确认开始执行之后，为了确保执行的正确性和力度，一定要跟踪执行。一个没有跟踪执行的方案如同瞎子射箭。这样的话，无论射多少回，都是没有目的性和方向性的，也无法在以前的基础上持续改进的。质量理论中常提到的PDCA循环讲的也是这个道理。

在解决问题方面，有很多和测试、质量无关，但和思维、管理类相关的书和文章。例如：《第五项修炼》中就提出对解决问题很有帮助的五大方面：系统思考、自我超越、心智模式、建立共同愿景、团队学习。《金字塔原理》中提出的界定问题、结构化思考、演绎与归纳等多种模式也能帮助我们剥茧抽丝，抓到问题的本质和可行的方案。

6.QA能力进阶

从上面我们看到，QA能力的培养贯穿于每日工作的点滴。其进阶可以大致分为以下级别。

(1)发现的问题级别:

       初级:问题已经发生,而且大家都感受到了(项目组中大家都觉得有问题的问题)

       中级:问题已经发生,但只有少量人感受到了(问题已经发生,但是其危害还没有扩散)

       高级:问题还没有发生,很多人没有意识到(一个解决方案在不同的实施环境中会有的问题)

(2)解决问题的能力的级别：

       初级：可以提出方案，但不能提出很合理的、可以实施的方案

       中级：可以提出合理的可以实施的方案，但是实施效果不太好（方案中存在着一些重要的影响执行的因素没有考虑到）

       高级：可以提出合理的方案，且实施效果好，整个团队受益

　　当今的企业需要掌控其关键业务应用的所有功能测试，以确保所有业务流程工作符合预期。通过实施自动化的功能测试，企业可以极大提高测试速度和精度，从挼间项目中得到更高的投资回报并且显著地降低风险。

　　本文简要描述了自动化功能测试的优势和挑战，帮助企业考虑实施最佳测试自动化的方法。

　　1.介绍

　　毫无疑问，严格的功能测试是成功开发应用的关键。开发人员，测试小组和管理人员所面临的挑战是，如何加速测试流程和提高测试的精确性和完备性，同时还不能增加已然很紧张的预算。

　　通过将功能测试的关键环节自动化，可以满足有挑战性的发布时间安排，测试得更加全面和可靠，检验业务过程功能的正确性，从而从上线的运营中，获得极高的产值和客户满意度。然而，功能测试的自动化会产生一些新的顾虑：

　　测试过程自动化的成本是多少？其投资回报率（ROI）是什么？

　　哪些应用/过程适合做自动化测试，哪些不合适？

　　是否需要新的培训，这将对当前的开发计划安排产生怎样的影响？

　　自动化测试得正确地方法论是什么？

　　自动化测试时涉及到哪些情况？

　　当比较自动化测试产品时，哪些功能最重要？

　　在自动化测试项目开始之前，以上和其他一些问题应该得到全面地调查和了解。

　　2.功能测试与单元测试

　　功能测试是指确保应用按期望运行，也就是按照用户的期望运行。功能测试以一种有效的方式捕获用户的需求，让用户和开发人员对业务过程满足需求充满信心，同时使得QA团队可以检验软件已发布就绪。

　　功能测试是单元测试的补充，但有很大不同。简言之，单元测试说明了代码执行是否正确；功能测试说明了完成的应用是否做正确的事情。单元测试往往是从代码开发人员的角度来看，而功能测试是从最终用户和业务过程角度来看。

　　3.为什么将功能测试过程的自动化？

　　现在，IT部门的压力越来越大。管理部门希望IT部门通过软件可以交付新功能，抓住新的商业机会和提供有竞争力的优势。这就意味着需要完成更多的业务应用开发项目，而时间会很紧迫，并不是都有更多的预算或资源。

　 　同时，管理部门越来越意识到软件和销售额的重要关系。Web Services，联机事务处理和ERP应用不仅是非常关键的，而且，它们直接关系到公司的产值能力。现在企业非常依赖非常复杂的计算机基础设施。如图， 一个典型的企业可能依靠多个应用，运行在不同的系统上，使用几种不同的前端客户端，涉及到大量的业务过程并且与很多种数据集交互。

　　可能的组合是高度复杂，需要成百上千的测试场景。

　　当软件出现故障时，其代价是非常大的，包括销售额下降，员工的低效率，客户的不满和开发和QA人员的士气低落。在软件开发周期中，缺欠发现的越晚其代价越高。上线后发现的缺欠的改正成本可能比在设计阶段发现的高出100倍。自动化是提高软件测试过程的速度，精确度和灵活性的关键，使公司可以更早发现和改正缺欠。

　　4.手工功能测试的挑战

　　手工功能测试过程本身存在很多挑战：

　 　时间过长。有限的IT资源和紧张的交付时间使得手工测试对于满足业务目标来说过于耗时。采用手工测试，测试和开发人员不得不计划冗长的每步测试过程，然 后手工执行，再现问题，快速消耗了有价值的时间和资源。根据Aberdeen Group，一个独立行业分析公司，90%的IT项目交付出现延迟，手工测试是其中一个因素。

　　覆盖不完全。平台，操作系统，客户端设备，业务过程和数据集等的组合对于手工测试过程来说，工作量非常大。需要验证功能的测试用例数量非常巨大。所以当修改完成后手工回归测试花费的时间过长，以至于不能做全面的回归测试。

　　风险更高。手工测试过程比计算机过程的错误和疏忽更多。人们会变得疲倦，输入数据错误，不能总是正确执行测试，并不是总有时间测试所有应该测试的内容。

　　5.自动化测试的好处

　　自动化测试有很多好处，包括：

　 　快速执行。计算机在执行功能测试脚本的时候比人快得多，因此在有限的时间里能测试的更多，在给定的时间里更多的应用可以被测试，可以按时完成更多的工 程。并且和人不同，计算机一天工作24小时，还包括晚上，周末和假期；他们不会感到无聊或者疲倦；而且他们从不对该作的事情和不该作的事情自作主张。

　 　提高测试覆盖。自动测试产品支持在所有流行的浏览器，操作系统等上执行测试脚本，用自动化的工具对不断变化的应用和环境做回归测试，要比手工测试容易得 多。通过整合的数据驱动表单的功能，自动化测试产品允许开发和测试团队执行计算，操作数据集，以及快速创建多种反复的测试，使得扩大测试覆盖范围。使用自 动测试工具可以仿效任何混合的事务和任意的用户负载。

　　提高测试精确度并提早发现更多错误。自动化测试给开发人员提供了一种再现和记录软件缺陷的非常容易的方法。这将在所有环境，数据集和业务过程等之间确保功能的正确性，同时对开发过程起到加速作用。

　　提供规范化的过程。自动化测试鼓励测试团队规范化他们的过程，以得到更高的一致性和更好的文档记录。

　　提高测试的重用性。测试一旦脚本化，开发人员可以使用和重用这些脚本，可以将脚本添加到测试套件中，以适应应用的变化。没有必要为每个应用的相同功能而重新创建脚本。

　　支持ERP/CRM。现在越来越多的用户使用ERP/CRM解决方案，对端到端的回归测试的需求正变得越来越频繁和越来越重要。

　　6.在什么情况下采用自动化测试？

　　一般来说，把自动化测试的工作集中在关键的业务过程，复杂应用，以及由这些组成的用例方面（相对于低级别任务，例如系统级的验证）是很有意义的。

　 　如果一个企业拥有众多每天工作很多小时的软件测试人员，但是产品仍然出现质量和功能问题，那么这家企业肯定能从自动化测试中受益。是否决定实行自动化测 试应当充分考虑到投资回报，但是一般情况下，如果一个应用需要多次构造/补丁/修改；需要在大量的硬件或软件配置下进行测试；并且支持众多并发用户等，那 么将会是值得采用自动化测试。另外，如果涉及到重复性的工作，例如数据装载和系统配置等，或者应用需要满足特定的服务等级协议（SLA）,那么自动化测试 当然也会节约成本。

　　7.如何确定自动化测试的投资回报？

　　任何投资回报都可以从一个简单的计算得出：

　　投资回报=投资的净现值/总初始成本

　　当采用测试过程的自动化时，成本是切实可见的，但是净现值仍旧包含许多无形的因素。最好的方法就是尽量精确计算直接成本，然后与自动化测试产生的直接和间接的效益进行对比。

　　在ROI计算中需要考虑的直接成本包括:

　　购买成本：购买自动化测试软件产品的成本。

　　硬件成本：功能测试所必需的硬件成本。有代表性的是，功能测试不需要特殊的硬件，只需带有以太网端口的标准台式电脑或者工作站即可。

　　劳动力成本：培训职员编写测试用例脚本或进行手工测试的成本因素。确认要包括招聘，雇佣，支付工资，和保留熟练的QA工程师的成本。

　　培训成本：依赖于所选择的测试产品，培训使用者精通编写自动测试脚本是值得的。当然，公司可以选择雇用专业的服务公司创建最初的自动化测试。

　　当衡量自动化的潜在益处时，考虑隐性效益是很重要的，例如测试人员高涨的士气和对工作的满意度，改进的客户满意度和忠实度，还有因为最终用户使用的可信赖的软件而不断提高的知名度。

　　8.如何评估自动化测试软件？

　　很多商家提供自动化测试产品。每个解决方案都有自身的优势和劣势，独特的功能，和市场环境。每个企业需求的特殊性决定了最适合的一种选择。然而，任何自动化测试产品都应当包含一些关键的性能：

　　自动化测试的“Scriptless”表示法：产品应该提供一个可点击的界面，在测试时与应用组件进行访问和交互——而不是呈现出一行行的脚本。测试者应该可以可视化每一步的业务过程，并且直观的观察和编辑测试用例。这将减少测试者在学习上走弯路，并帮助测试团队面对紧迫的最终期限。

　　集成的数据表：自动化功能测试的一个关键的好处就是可以使系统快速产生大量数据。还有一个重要的功能就是操作数据集，执行计算，并以最小的代价快速创建数以百计的重复测试和组合。企业应该寻找拥有提供强大计算能力的集成电子数据表单的产品。

　 　清晰明确的报告：如果测试结果不容易理解或解释，那么即使运行大量测试数据也不会有什么好处。测试产品应当自动的产生并显示所有测试运行方面的报告，并 用易读的格式解释结果。报告应当提供的细节包括：应用在什么地方发生了失败和使用了什么样的测试数据；为应用的每一步提供高亮或有差别的屏幕显示；并提供 每个检查点通过和失败的详细解释。当然还应当能够在不用修改的情况下，在测试和开发团队之间共享报告。

　　9.要点列表：自动化测试成功的五个关键

　　即使已经证明了测试的自动化是经济有效的，然而如何确定转变到自动化测试过程上的最佳方法依然是困难的。这部分略述了执行自动化测试过程的五个基本原则。

　　1.完成一个测试计划文档。理解被测应用的目标是任何测试成功的基础。这包括全面的预先计划以确保测试需求被正确的实施。测试工具应提供为所有被测应用管理测试用例和需求的能力。

　　2.将测试细分为自动测试用例。一个组织自动执行一个测试计划的所有方面是不可能的。自动化测试应该集中围绕在需求设计的复杂应用上和急迫的业务过程功能上，许多组织发现他们使用自动化测试只占总测试用例的60%，而余下的40%为手工测试。

　 　3.创建自动化测试。测试工具极大简化了准备测试数据和脚本的过程。这使得更多的完全测试可最佳地使用测试资源和结果。使用测试工具，使用者可以不必作 任何实际脚本而创建测试。测试工具应能自动捕获目标应用的业务过程，并允许使用者创建一个可以被保存的而且可以被管理的测试流程。

　　4.提高测试覆盖的数据驱动测试。测试者就可以为应用创建一个使用储藏在Excel电子表格里的特殊关键字的依赖于数据的测试。这就允许测试者通过应用驱动大量的测试数据。

　　5.给测试增加验证。需要在测试中添加了“通过或失败”的测试标准。这包括了应用的前端，中间层，或后端数据库的验证。内置的数据库验证使数据库值的存储得到确认，并确保处理的精确性和已更新、删除或增加的数据记录的完整性。

　　10.总结

　　功能测试可以不是耗时或高成本的问题。采用自动化功能测试，企业可以将重点放在改进自动业务过程方面。开发和QA组可以增加测试过程的速度和精确度。整个IT部门可以获得更高的投资回报，而且降低了大量风险。

1       概述

       本测试过程作为功能测试的最佳实践，用于实施不同机构的功能测试工作。它可以作为测试计划工作的基础，应用于每个软件开发的项目。在这个测试过程中描述的活动既可以用于新开发的组件，亦可以用于改进现有的回归测试。

2       测试管理

为了能顺利地获得测试的结果，将测试作为独立管理的过程是非常必要的。测试管理可以分为下面四个领域。

1）测试计划

2）测试执行

3）测试控制

4）测试过程改进

1.1    测试准备
    测试的准备是一个独立的、分离的阶段，测试员在这个阶段中基于需求文档准备测试（业务设计图）。测试的准备要依据标准的方法，并应基于本阶段的工作生成标准化的文档。
1.1.1   业务功能测试
    基于风险评估，针对每个业务功能的不同风险级别都应有一个对应的测试过程和方法组合：
1）A级风险
利用等价类和组合进行系统性的测试完全自动化

2）  B级风险
利用等价类进行系统性的测试完全自动化

3）  C级风险
随意性测试手工执行，在TestDirector中提供文档化的执行过程

       对于每个测试过程和方法组合，要提供一个标准的文档进行方法论级的阐述和规定，每个测试人员依据这些标准的测试过程和方法组合进行测试。

    在TestDirector中要将测试用例的准备结果作为业务功能的附件。

1.1.2   业务流程测试
    业务流程测试是将所有的业务功能组合在一起，使用同一组数据进行工作。
    测试员的任务就是要确定每个业务功能的组合是否能连贯的执行。
    判断的结果使用矩阵来表示，例如下图：
注：yes（+）；no（-）

业务流程矩阵

 
业务流程矩阵的设计如下图：

　　从配置管理员处申请软件配置：《需求规格说明书》和《设计说明书》；根据需求规格说明书和设计说明书，详细理解用户的真正需求，并且对软件所实现的功能已经准确理解，然后着手制订测试用例。

　　二、测试用例制定的原则

　　测试用例要包括欲测试的功能、应输入的数据和预期的输出结果。测试数据应该选用少量、高效的测试数据进行尽可能完备的测试；基本目标是：设计一组发现某个错误或某类错误的测试数据，测试用例应覆盖方面：

　　1、正确性测试：输入用户实际数据以验证系统是满足需求规格说明书的要求；测试用例中的测试点应首先保证要至少覆盖需求规格说明书中的各项功能，并且正常。

　　2、容错性（健壮性）测试：程序能够接收正确数据输入并且产生正确（预期）的输出，输入非法数据（非法类型、不符合要求的数据、溢出数据等），程序应能给出提示并进行相应处理。把自己想象成一名对产品操作一点也不懂的客户，在进行任意操作。

　　3、完整（安全）性测试：对未经授权的人使用软件系统或数据的企图，系统能够控制的程度，程序的数据处理能够保持外部信息（数据库或文件）的完整。

　　4、接口间测试：测试各个模块相互间的协调和通信情况，数据输入输出的一致性和正确性。

　　5、数据库测试：依据数据库设计规范对软件系统的数据库结构、数据表及其之间的数据调用关系进行测试。

　　6、边界值分析法：确定边界情况（刚好等于、稍小于和稍大于和刚刚大于等价类边界值），针对我们的系统在测试过程中主要输入一些合法数据/非法数据，主要在边界值附近选取。

　　7、压力测试：输入10条记录运行各个功能，输入30条记录运行，输入50条记录运行……进行测试。

　　8、等价划分：将所有可能的输入数据（有效的和无效的）划分成若干个等价类。

　　9、错误推测：主要是根据测试经验和直觉，参照以往的软件系统出现错误之处。

　　10、效率：完成预定的功能，系统的运行时间（主要是针对数据库而言）。

　　随着中国软件业的日益壮大和逐步走向成熟，软件测试也在不断发展：从最初的由软件编程人员兼职测试到软件公司组建独立专职测试部门；测试工作也从简单测试演变为包括编制测试计划、编写测试用例、准备测试数据、开发测试脚本、实施测试、测试评估等多项内容的正规测试；测试方式则由单纯手工测试发展为手工、自动兼之，并有向第三方专业测试公司发展的趋势。

　　一、测试用例是软件测试的核心

　　软件测试的重要性是毋庸置疑的。但如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，则是软件公司探索和追求的目标。每个软件产品或软件开发项目都需要有一套优秀的测试方案和测试方法。

　 　影响软件测试的因素很多，例如软件本身的复杂程度、开发人员（包括分析、设计、编程和测试的人员）的素质、测试方法和技术的运用等等。因为有些因素是客 观存在的，无法避免。有些因素则是波动的、不稳定的，例如开发队伍是流动的，有经验的走了，新人不断补充进来；一个具体的人工作也受情绪等影响，等等。如 何保障软件测试质量的稳定？有了测试用例，无论是谁来测试，参照测试用例实施，都能保障测试的质量。可以把人为因素的影响减少到最小。即便最初的测试用例 考虑不周全，随着测试的进行和软件版本更新，也将日趋完善。

　　因此测试用例的设计和编制是软件测试活动中最重要的。测试用例是测试工作的指导，是软件测试的必须遵守的准则，更是软件测试质量稳定的根本保障。

　　二、什么叫测试用例

　　测试用例（Test Case）目前没有经典的定义。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略，内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。

　 　不同类别的软件，测试用例是不同的。不同于诸如系统、工具、控制、游戏软件，管理软件的用户需求更加不统一，变化更大、更快。笔者主要从事企业管理软件 的测试。因此我们的做法是把测试数据和测试脚本从测试用例中划分出来。测试用例更趋于是针对软件产品的功能、业务规则和业务处理所设计的测试方案。对软件 的每个特定功能或运行操作路径的测试构成了一个个测试用例。

　　三、编写测试用例

　　着重介绍一些编写测试用例的具体做法。

　　1、测试用例文档

　　编写测试用例文档应有文档模板，须符合内部的规范要求。测试用例文档将受制于测试用例管理软件的约束。

　　软件产品或软件开发项目的测试用例一般以该产品的软件模块或子系统为单位，形成一个测试用例文档，但并不是绝对的。

　 　测试用例文档由简介和测试用例两部分组成。简介部分编制了测试目的、测试范围、定义术语、参考文档、概述等。测试用例部分逐一列示各测试用例。每个具体 测试用例都将包括下列详细信息：用例编号、用例名称、测试等级、入口准则、验证步骤、期望结果（含判断标准）、出口准则、注释等。以上内容涵盖了测试用例 的基本元素：测试索引，测试环境，测试输入，测试操作，预期结果，评价标准。

　　2、测试用例的设置

　　我们早期的测试用例是按功能设置用例。后来引进了路径分析法，按路径设置用例。目前演变为按功能、路径混合模式设置用例。

　　按功能测试是最简捷的，按用例规约遍历测试每一功能。

　　对于复杂操作的程序模块，其各功能的实施是相互影响、紧密相关、环环相扣的，可以演变出数量繁多的变化。没有严密的逻辑分析，产生遗漏是在所难免。路径分析是一个很好的方法，其最大的优点是在于可以避免漏测试。

　 　但路径分析法也有局限性。在一个非常简单字典维护模块就存在十余条路径。一个复杂的模块会有几十到上百条路径是不足为奇的。笔者以为这是路径分析比较合 适的使用规模。若一个子系统有十余个或更多的模块，这些模块相互有关联。再采用路径分析法，其路径数量成几何级增长，达5位数或更多，就无法使用了。那么 子系统模块间的测试路径或测试用例还是要靠传统方法来解决。这是按功能、路径混合模式设置用例的由来。

　　3、设计测试用例

　 　测试用例可以分为基本事件、备选事件和异常事件。设计基本事件的用例，应该参照用例规约（或设计规格说明书），根据关联的功能、操作按路径分析法设计测 试用例。而对孤立的功能则直接按功能设计测试用例。基本事件的测试用例应包含所有需要实现的需求功能，覆盖率达100%。

　　设计备选事件 和异常事件的用例，则要复杂和困难得多。例如，字典的代码是唯一的，不允许重复。测试需要验证：字典新增程序中已存在有关字典代码的约束，若出现代码重复 必须报错，并且报错文字正确。往往在设计编码阶段形成的文档对备选事件和异常事件分析描述不够详尽。而测试本身则要求验证全部非基本事件，并同时尽量发现 其中的软件缺陷。

　　可以采用软件测试常用的基本方法：等价类划分法、边界值分析法、错误推测法、因果图法、逻辑覆盖法等设计测试用例。视软件的不同性质采用不同的方法。如何灵活运用各种基本方法来设计完整的测试用例，并最终实现暴露隐藏的缺陷，全凭测试设计人员的丰富经验和精心设计。

　　LAYO最近下载了几篇PPT；又看见了这样一段描述。

　　G.J.Myers给出了关于测试的一些规则，被软件工程领域认可：

　　（1）测试是为了发现程序中的错误而执行程序的过程；

　　（2）好的测试方案极有可能发现迄今为止尚未发现的错误；

　　（3）成功的测试是发现了至今为止尚未发现的错误。

　　上面这段话是测试行业经常能看到的一段关于测试的工程的一种解释；可能有些太理性或者说是书面化的解释，作为一个TESTER我很表示同意；但是一直没有认真理解这段话。

　 　测试是为了发现程序中的错误没错；但是我认为有些狭义的想法；综合整体的软件质量去评估去看；不单单在过程中去发现程序中的错误；而包括在设计之初的错 误逻辑和不合理的流程以及操作方式都是测试的过程中要关注的因子；所以就不仅仅是为了发现程序的错误；一个认真思考的TESTER是不拘在程序之内的范 畴。所以我认为测试是为了发现整个项目中任何不合理的错误；包括文档的错误、业务流程中的漏洞、程序中的BUG、不正规的操作方式、不合理的数据流程。当 然这算是一种理想测试过程。

　　好的测试方案极有可能返现迄今为止尚未发现的错误；我总是认为这句话带有钻牛角尖的意味；好的的是方案其实 是一种无穷尽的操作；记得有一个夸张的小道理：一百万只猴子，给他们每人一个键盘，给他们足够的时间，让他们打出莎士比亚全集。就是在接近无穷的测试下会 让程序的问题完全暴漏无疑；一个好的测试方案应该是合适项目的测试方案；到什么山唱什么歌；看菜吃饭、量体裁衣；根据项目去指定测试方案，这种方案下去测 试该项目才能真正说明项目问题。

　　成功的测试是发现了至今为止尚未发现的错误；我认为将测试工作进行了一次反革命性的引导；行业需要创新思维；需要吹毛求疵；只能说在现有的需求下去发现不应该出现的问题。测试用例是在有限的资源下设计出涵盖面最广而最有效的用例；不是说为了测试而测试。

　　测试用例文档的价值在微软和软件测试行业之间有争论。有几个因素可以帮助决定是否选择测试用例文档。测试用例文档有如下一些好处：

　　历史借鉴。测试用例的存在要远远超过产品发布。持续工程以及产品未来版本的负责人往往需要借用测试用例来了解测试过什么，以及如何测试的。测试用例文档以及一个有组织的储存系统，对长期支持或修订产品的一部分是至关重要的策略。

　　测试进展跟踪。通过测试用例文档，可以跟踪一些额外的属性，如测试用例的执行数目、测试用例的通过或失败数目，以及每个功能领域的测试用例总数。

　　可重复性。好的测试用例文档可以由任何人在任何时候执行。这同样适用于自动和手动的测试用例文档。重复准确地执行同样的测试对重视步骤或检验回归是至关重要的。

　　测试用例文档也有如下缺点：

　　建立文档的时间。如果建立测试用例文档的时间比运行测试用例所需的时间还长，建立测试用例文档也许就没有意义了。经常有这样的情况，即测试用例只需要在一个单一的环境下执行寥寥几次。

　　功能变化引起测试用例过期。建立测试用例所需的时间很可能因为功能经常变化而增加，以至于失去控制。如果测试用例的功能领域变化频繁，建立测试用例文档就不一定是明智的。这种场景之一是尝试写测试用例以验证用户界面组件。

　　很难设想读者的知识。写测试用例的人往往对被测试的功能极为熟悉。这些人常犯的错误是在测试用例中使用术语或缩写，而将来运行测试用例的人很可能看不懂这些测试用例。出现这种情况时，测试用例已不再能准确地重复，测试用例也失去了这一关键属性。

　 　测试用例通常用测试用例管理器（TCM）来建立文档，微软大部分团队用测试用例管理器记录绝大多数测试用例。重要的是要记住，测试用例并没有定义所有的 测试活动。如缺陷大扫除，那是整个团队致力于数小时或数天的时间，专注于使用功能或应用程序，寻找可能被测试用例过的缺陷，这种测试活动在微软的各团队是 常见的。许多团队也在产品周期中花时间致力于客户的使用场景。例如，一些Visual Studio的团队经常花一些时间，整个团队除了在Visual Studio开发环境创造和建立各种应用程序外，什么都不做。

　　通常软件测试会暴露软件中的缺陷，经过修正后可以保证软件系统的功能满足需求并正确运行。但是，在系统测试和 确认测试中，测试人员容易遗漏一些隐藏的缺陷。众所周知，软件测试不可能发现所有的缺陷，而软件开发周期各个阶段仍然存在注入缺陷的可能，但是，有一些缺 陷是测试中容易忽略的，也就是说，通过测试方法和用例可以充分暴露这些缺陷，遗憾的是，它们往往被忽略或者某种原因忘记测试了，这就给软件留下了隐患或者 危机。这些容易被忽略的缺陷包括：

　　1、安装缺陷

　　通常项目组完成代码后，发布时候安装打包是最后一个环节，而软件测试人员通常在测试的时候，没有仔细的测试这一部分，而把用例集中在其他功能上。安装时候的缺陷通常通过拷贝而不是运行安装程序方式给测试人员安装软件，结果正式安装时候出现问题，引起例如控件没有注册，注册表没有导入等。删除时候没有注意安装文件夹是否存在用户文件，造成数据丢失;使用绝对路径;安装顺序没有说明书。

　　2、配置文件

　　有些文件在ini等配置文件中写出了管理员口令密码等信息，而且是明文的！这是一个安全隐患。另外，有些安装文件的 XML 文件，为了方便在数据库和中间层连接文件中写入了Admin 口令和密码。作为一个合格的软件测试人员，必须检查这些可以用记事本打开的文件。因为，一个稍有常识而且喜欢探索的用户，可能从中获取信息而成为不自觉的黑客。所以，配置文件可能成为软件安全方面的一个缺陷。

　　3、网页安全缺陷

　　现在网站开发已经注意到：登陆网站进入其内部网页后，直接拷贝网址，然后粘贴到另一IE 窗口输入，可以绕过登陆直接访问。也许商业网站很关注这个问题，但是很多行业软件却很容易忽略。

　　网页安全缺陷还可能存在于 IE 弹出的子窗口。有些设计不严格的软件，在主页面关闭的时候子页面还可以运行，这是一个明显的漏洞，而且还大大增加了错误发生的几率。

　　4、判断顺序/逻辑缺陷

　 　对界面进行多个输入判断的时候，非常容易出现这种问题。例如判断年月顺序，判断长度，判断非空等。假如操作员仅仅满足单个条件，保存不能成功;而按界面 从上之下顺序一一满足条件之后，保存是没有问题的。但是，改变一下输入的次序，校验失效。例如，一一满足条件之后，不保存，倒过来将上面的输入改成非法输 入，然后保存，结果居然也能成功，这是因为原先的判断由于发生过，或者根据语句顺序只检查最后一个判断，所以没有报错。这种错误尤其在 Java scrīpt 脚本的页面中要注意。能够保存不能保证数据正确，有可能引起系统崩溃或者后续数据错误。所以，在测试的时候，不要按照正常的顺序输入，而是要打乱步骤，看 看代码是否强健，是否在判断逻辑上没有错误。良好的代码应该经得起折腾，至少保存时会再此全部进行判断，而不只是简简单单走到判断的最后一行。

　　5、调试语句和冗余信息

　 　维护项目和升级改造的推广系统最容易潜伏这类缺陷。典型表现在没有删除或者屏蔽调试语句。弹出一个界面不友好的提示信息，会使不明真相的用户产生误以为 系统发生了严重故障，从而引起对软件的不信任感。页面中某个角落存在当前客户不需要的冗余按钮和功能也是一种缺陷。多余的功能会使用户以为是额外附加部分 而去使用，其结果可想而知;而多余的按钮会误导好奇心强的用户操作，产生不必要的错误。

　　同样值得关注的还有参数设置，由于没有实际数据，开发人员在调试或者单元测试的时候，习惯性的进行自我设定而忘了删除，软件测试人员可能会忽略掉了这部分测试，也可能导致在客户现场发生错误而影响系统发布和验收。

　　6、不可重现的故障

　　新参加软件测试的人员或者新来的开发人员总是要问，不可重现的缺陷是否需要记录，有必要吗?回答是肯定的。测试必须如实的记录发生的问题，也许不能重现，或者使非软件系统本身问题，但是，可能这些偶然性背后是有规律的，不记录这些，就不可能发现这些规律。

　　7、多节点的逆向流转缺陷

　　当前软件不少喜欢使用工作流来驱动。工作流的问题，就是可能出现多个流向分支。测试容易忽略的部分，就是工作流多节点的逆向流转。例如，通过不 通过涉及两个分支，但是流程逆转的时候，有可能不是回到上一节点而是平级的另一个节点去了。软件测试要格外注意这类用例的设计。另外，有些时候默认分支在 向前的时候是有默认值的，例如默认通过，那么保存的时候要提示用户是否通过，否则可能由于操作疲劳而走错了节点，引起回退。

　　8、输入框缺陷

　　试过往输入框粘贴数据而不是直接输入吗?可能这里会出现问题。按 Ctrl+V 的时候，输入框会根据长度大小自动截断输入长度。但是用鼠标，截断可能会失效。有一次测试人员就是用这种方法把一篇 Word 文档输入进去了，保存的时候，数据库崩溃。有些网站登陆的口令****可以拷贝下来的，只要放在剪贴板里面马上明文显示。

　　输入框可以说是问题最多的部分，能够引起的麻烦也很多。日期、数字、文本等等，都需要耐心的测试一下。

　　9、界面布局缺陷

　　曾经有一次，项目经理回来向测试部反映一个问题，客户对界面不满意。原因很简单，因为界面上删除按钮和保存按钮挨得很近。结果有些操作不熟练的 业务人员，很容易误按。这个问题是测试人员没有意料到的，因此注意关闭、删除、退出按钮与保存、下一步等按钮的距离。类似的按钮应按此规则排列分布。

　　界面布局还可能发生在窗口最大化和最小化上，有可能窗口缩小的时候没有下拉框或不匹配分辨率，对用户来讲，这个错误实在很低级。有些用户由于操 作习惯，非常不喜欢腾出手使用鼠标，尤其是大量输入的界面，因此，要注意设置键盘的快捷方式。还有，按 Tab定位到下一焦点时要注意顺序，避免跳转太灵活而让操作人员感到无从适应，在界面进行维护或者修改的时候，不要忘了软件测试开发人员是否无意改变了这 些快捷方式和跳转顺序。

　　10、版本和补丁包的环境问题

　　理论上讲，这属于兼容性测试应该覆盖的问题。有些客户很喜欢更新最新的软件版本或者微软时不时打些补丁包，问题就出现了。有时候升级不一定是好 事。这些问题最好在测试的时候增加几个用例，多用不同软件版本的机器跑一跑。软件测试有个定律是：你没跑过的地方，就一定会出事。经常听到开发人员抱怨， 怎么我的机器没问题，你的机器就有事了呢?这不能完全靠配置管理员解决问题，环境配置项是大家最容易忽略的。

　　11、用户管理缺陷

　　用户管理的角色和授权需要好好研究一下，作过测试的人员都知道，有时候为了测试的方便，测试用户都是具有超级权限的用户。而且，比较容易忽略用户管理这一部分的测试。往往发往客户的时候，很多测试用户都没有删除。

　　另外，有些接口的用户和口令，到软件使用寿命结束都没有更改过。在一次测试中，软件测试人员发现，给一个用户授超级用户权限，之后更改这个用户 为受限权限。使用中发现，用户居然没有真正回收权限，用户管理界面上没有任何不对。及早准备用户管理用例，不要等到测试快结束时候才想起。

　　12、常识缺陷

　　从逻辑或者统计学上讲，计算机是允许如此处理的，但是从常识上来讲，这些情况不可能发生。例如电话号码不可能出现小数点，终止时间不能大于开始 时间等等。除此之外，常识还要结合业务特点来进行判断，因此，开发和测试人员要格外注意对自己知识的培养以及增加对需求细节的了解。不能因为一味追求进度 而采用最简单的代码来实现，对用户来说，这些错误可能是很荒谬的。

　　尽管我们不可能完美的测试一个软件，但是我们仍然可以改进我们的软件测试。每次测试结束，及时总结测试中的不足，进一步完善用例。思考一下那些容易忽略的软件缺陷，能提高对软件测试的认识，提高所在组织软件的质量。

　 　第一：“明确”待测试项目的需求。对于任何一个项目，无论你接手的项目有多小，甚至可能都算不上一个项目，而仅仅是一个小工具，明确需求非常重要。可能 很多人会说，公司现状，测试能看到需求文档几乎不可能；也或者公司有需求文档，但与实际的待测试项目相差甚远；也或者还有其他的各种可能情况，但无论是什么原因，明确需求是任何一名测试用例设计者必须坚持也必须执行的一条原则。如果你是测试部的负责人，在面对需求不明确的项目时， 请你先收集待测试项目尽可能多的“文档”，这些文档有时并不一定需要是已经现成成稿的，其实我们可以通过“不耻下问”之后自行整理。测试负责人自己必须对 待测试项目做到“胸有成竹”。

　　第二：“分析”待测试项目。可能很多人这个时候会非常不以为然了，为什么要经过这么一个过程？“分析”待 测试项目的目的是让我们更进一步的了解待测试项目，那可能大家这个时候又会问了，了解什么？大家想想，你明确了需求，可是你知道待测试项目的体系结构是什 么吗？你知道我们采用了什么技术吗？你知道这个项目蕴涵的业务知识有哪些吗？对了，我们就是要通过更进一步的分析，整理出更为详细的资料，服务于我们的测 试工作。

　　第三：“学习” 待测试项目的业务知识。这一点我相信很多人都能认同，比如你是做银行相关项目的，那你肯定要具备银行相关方面的知识，只有这样，才能非常容易的明白为什么 这么设计，或者这么设计的优势在哪里？针对采用的某种实现技术，只有更进一步的学习了解，你才能明确这种技术的优势与弱势分别是什么，针对这种技术的弱 势，我们测试又需要重点测试哪些地方等等。这些问题都需要在我们提升我们自身业务水平的同时得到解决。

　　第四：内部讨论。对于这点，我有 非常切身的感受，作为项目测试负责人，一定要更自己的测试团队针对某个项目进行多次内部的讨论，通过内部讨论更进一步发现我们忽律的地方，同时也让大家的 资源共享，用最短，最快的方式收获最好的效果。