虽然功能测试是绝大多数软件都无法回避的，但多数开发企业不谙其中滋味，所以，测试外包市场才会如此繁荣而且规模日益壮大。目前，功能测试已跨越了单靠手工敲敲键盘、点点鼠标就可以完成的阶段，正朝着自动化和智能化方向发展。自动化是指各类测试工具已经得到日益广泛的应用; 智能化是指测试人员从脚本编制、运行、调试到结果分析乃至测试方案改进，都需要有深入的了解。
而性能测试的重要性是随着网络应用的发展而发展的，由于网络环境、数据库环境、应用服务器环境、系统平台和技术等的复杂性和多样性，软件性能非常难于控制。虽然，改善系统性能不是单单依靠性能测试就能完成的，但性能测试至今仍是控制性能的非常有效的手段，在软件的能力验证、能力规划、性能调优、缺陷修复等方面都发挥着重要作用。
功能测试工具的选择
那么，如何高效地完成功能测试？选择一款合适的功能测试工具并培训一支高素质的工具使用队伍无疑是至关重要的。尽管现阶段存在少数不采用任何功能测试工具，从事功能测试外包项目的软件服务企业。短期来看，这类企业盈利状况尚可，但长久来看，它们极有可能被自动化程度较高的软件服务企业取代。
目前，用于功能测试的工具软件有很多，针对不同架构软件的工具也不断推陈出新。这里重点介绍的是其中一个较为典型自动化测试工具，即Mercury公司的WinRunner。
WinRunner是一种用于检验应用程序能否如期运行的企业级软件功能测试工具。通过自动捕获、检测和模拟用户交互操作，WinRunner能识别出绝大多数软件功能缺陷，从而确保那些跨越了多个功能点和数据库的应用程序在发布时尽量不出现功能性故障。
WinRunner的特点在于: 与传统的手工测试相比，它能快速、批量地完成功能点测试; 能针对相同测试脚本，执行相同的动作，从而消除人工测试所带来的理解上的误差; 此外，它还能重复执行相同动作，测试工作中最枯燥的部分可交由机器完成; 它支持程序风格的测试脚本，一个高素质的测试工程师能借助它完成流程极为复杂的测试，通过使用通配符、宏、条件语句、循环语句等，还能较好地完成测试脚本的重用; 它针对于大多数编程语言和Windows技术，提供了较好的集成、支持环境，这对基于Windows平台的应用程序实施功能测试而言带来了极大的便利。
WinRunner的工作流程大致可以分为以下六个步骤:
1．识别应用程序的GUI
在WinRunner中，我们可以使用GUI Spy来识别各种GUI对象，识别后，WinRunner会将其存储到GUI Map File中。它提供两种GUI Map File模式: Global GUI Map File和GUI Map File per Test。其最大区别是后者对每个测试脚本产生一个GUI文件，它能自动建立、存储、加载，推荐初学者选用这种模式。但是，这种模式不易于描述对象的改变，其效率比较低，因此对于一个有经验的测试人员来说前者不失为一种更好的选择，它只产生一个共享的GUI文件，这使得测试脚本更容易维护，且效率更高。
2．建立测试脚本
在建立测试脚本时，一般先进行录制，然后在录制形成的脚本中手工加入需要的TSL（与C语言类似的测试脚本语言）。录制脚本有两种模式: Context Sensitive和Analog，选择依据主要在于是否对鼠标轨迹进行模拟，在需要回放时一般选用Analog。在录制过程中这两种模式可以通过F2键相互切换。
只要看看现代软件的规模和功能点数就可以明白，功能测试早已跨越了单靠手工敲敲键盘、点点鼠标就可以完成的阶段。而性能测试则是控制系统性能的有效手段，在软件的能力验证、能力规划、性能调优、缺陷修复等方面都发挥着重要作用。
3．对测试脚本除错(debug)
在WinRunner中有专门一个Debug Toolbar用于测试脚本除错。可以使用step、pause、breakpoint等来控制和跟踪测试脚本和查看各种变量值。
4．在新版应用程序执行测试脚本
当应用程序有新版本发布时，我们会对应用程序的各种功能包括新增功能进行测试，这时当然不可能再来重新录制和编写所有的测试脚本。我们可以使用已有的脚本，批量运行这些测试脚本测试旧的功能点是否正常工作。可以使用一个call命令来加载各测试脚本。还可在call命令中加各种TSL脚本来增加批量能力。
5．分析测试结果
分析测试结果在整个测试过程中最重要，通过分析可以发现应用程序的各种功能性缺陷。当运行完某个测试脚本后，会产生一个测试报告，从这个测试报告中我们能发现应用程序的功能性缺陷，能看到实际结果和期望结果之间的差异，以及在测试过程中产生的各类对话框等。
6．回报缺陷（defect）
在分析完测试报告后，按照测试流程要回报应用程序的各种缺陷，然后将这些缺陷发给指定人，以便进行修改和维护。
性能测试的三大步骤
第一步 准备和组织是性能测试过程的第一步，在这个阶段，需要明确性能测试的目标和需求，并组织起合适的人员，制订性能测试计划。
一般来说，性能测试的应用领域分为能力验证、能力规划、性能调优和缺陷修复四个方面。其中能力验证表明测试的目的是验证系统能力是否达到预期的性能标准; 能力规划是要考察系统的可扩展性; 性能调优则是为了找到系统的性能瓶颈，为性能调优提供依据; 缺陷修复是为了找出系统中存在的并发等方面的缺陷。
明确目标也就是要把性能测试的目的归到相应的应用领域，而确定需求则是要更详细地确定性能测试的基准。对产品的性能测试需求的来源是软件需求、设计文档或是用户备忘录等设计和需求相关的文档。当然，并非所有的性能测试需求都在这些文档中以明确的方式标识出来，此时就需要根据不十分明确的文档描述进行进一步的细化。我们的经验是在文档评审时高度关注所有与性能相关的描述，例如“要求操作响应时间小于……”、“要求……能够快速……”、“要求……能够支持……用户访问”、“要求……能快速稳定运行”等，然后进行进一步的细化，从而作为测试的依据。
性能测试涉及的设备、环境、技术、工具较多，性能测试人员的组织也必须兼顾这些方面。一个性能测试组最好包括系统工程师（负责测试环境搭建、服务器和应用服务器的配置）、网络工程师（负责网络环境的维护和验证）、性能分析工程师（负责测试计划的拟定，对性能测试结果进行分析，给出性能测试报告）、自动化工程师（负责测试脚本的编写和测试工具实施）、数据库工程师（负责对数据库层进行性能问题定位）。在条件允许的情况下，还可以包括开发工程师和客户代表，辅助对性能测试结果进行分析和确认。
性能测试计划是用来指导性能测试过程的主要文档，在测试计划中除了要写明本次测试的测试目标、测试需求外，还需要在测试计划中给出明确的测试退出条件和测试的时间和资源计划。
第二步 第二步测试设计，也是性能测试的主要内容。测试设计一般基于测试场景进行，一个测试场景就是一个用户的实际使用系统的剖面。
在性能测试过程中，明确每个场景的参与者人数、比例和具体行为是非常重要的，这些都是构成性能测试脚本的基础。根据经验，可以从应用服务器的日志中分析用户行为。例如，对于一个OA系统，我们从日志中分析出在上午9:00～9:30时段内有200个查看邮件页面的page view，且查看时间基本集中在前10分钟; 而在9:00～9:30时间段内对BUG显示页面的查看量是300个page view，对页面的访问基本平均分配在整个时间段，则我们可以建立两个脚本，前一个脚本模拟查看邮件操作（脚本1），后一个脚本模拟查看BUG操作（脚本2），考虑运行15分钟的测试场景，则只需在前5分钟运行脚本1，在整个过程中运行脚本2，通过调整think time使得page view达到实际的数值即可。
当然，并不是每个不同的用户应用剖面都需要作为测试场景来设计，在多数情况下，可以通过对测试场景出现的几率、重要性、风险等进行分析，从而最终确定需要设计的测试场景。明确了场景之后，根据性能测试应用领域的不同，可以采用不同的性能测试方法来达到性能测试的目标。另外需要提醒的是，性能测试设计还应该包括测试环境、测试数据等的设计，因为影响系统性能的因素很多，保持测试过程中环境和数据的可控性是非常重要的。
第三步 第三步性能测试结果分析，是性能测试过程中最困难，也是最重要的步骤。它需要分析人员对测试结果中的各项数据有准确的认识，明确各指标之间的关系。如果各项数据指标间没有明显联系，在多数情况下需要综合考虑各种因素，才能得出最终结论。
根据经验，在性能测试过程中最容易发生的问题是数据库访问层问题、应用服务器配置问题以及网络问题。因此建议一般按照“从简至繁”的原则，先排除网络问题，其次对应用服务器配置进行分析，然后在数据库访问层进行性能分析，重点是索引、数据库Cache、死锁等问题的分析。在确认所有这些因素都不是性能瓶颈的情况下，才对代码进行分析和检查，找出导致性能问题的因素。
只要看看现代软件的规模和功能点数就可以明白，功能测试早已跨越了单靠手工敲敲键盘、点点鼠标就可以完成的阶段。而性能测试则是控制系统性能的有效手段，在软件的能力验证、能力规划、性能调优、缺陷修复等方面都发挥着重要作用。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/