通常情况下，软件测试的工作量都很大。而测试中的许多操作是重复性的、非智力性的和非创造性的，并要求工程师做准确细致的工作，这样，计算机就比人更适合完成任务。另一方面，手工测试存在如下的局限性：

　　1.       通过手工测试无法做到覆盖所有代码路径。

　　2.       简单的功能性测试用例在每一轮测试中都不能少，而且具有一定的机械性、重复性，工作量往往较大。

　　3.       许多死锁、资源冲突、多线程等有关的错误，通过手工测试很难捕捉到。

　　4.       进行系统压力、性能测试时，需要模拟大量数据或大量并发用户等各种应用场合时，很难通过于工测试来进行。

　　5.       进行系统可靠性测试时，需要模拟系统长时间运行，以验证系统能否稳定运行，这也是手工测试无法模拟的。

　　6.       如果有大量（几千）的测试用例，需要在短时间内（1天）完成，手工测试几乎不可能做到。

　　于是，就诞生了软件自动化测试这个领域。软件自动化测试是相对手工测试而存在的，主要是通过所开发的软件测试工具、脚本等来实现，具有良好的可操作性、可重复性和高效率等特点。其主要好处有：

　　1.       缩短软件开发测试周期，可以让产品更快投放市场。

　　2.       测试效率高，充分利用硬件资源。

　　3.       节省人力资源，降低测试成本。

　　4.       增强测试的稳定性和可靠性。

　　5.       提高软件测试的准确度和精确度，增加软件信任度。

　　6.       软件测试工具使测试工作相对比较容易，但能产生更高质量的测试结果。

　　7.       手工不能做的事情，自动化测试能做，如压力、性能测试。

　　如上所述，软件自动化测试有很多优点，可以带来非常明显的收益，但是，目前情况下，软件自动化测试还不能解决所有的测试问题，也有以下限制：

　　1.       不能取代手工测试

　　2.       手工测试比自动测试发现的缺陷更多

　　3.       对测试质量的依赖性极大

　　4.       测试自动化不能提高有效性

　　5.       测试自动化可能会制约软件开发。

　　6.       工具本身并无想象力，不能主动发现缺陷

　　另外，人工测试比测试工具更优越的另一个方面是可以处理意外事件。虽然工具也能处理部分异常事件，但是对真正的突发事件和不能由软件解决的问题就无能为力。

　　因此，在引入自动化测试前，我们需要建立正确的自动化测试目标。

　　1.       一种测试工具不完全适用于所有测试

　　2.       自动测试不一定减轻工作量

　　3.       测试进度可能不一定缩短

　　4.       测试工具不一定易于使用

　　5.       自动化测试的普遍应用存在局限

　　6.       测试覆盖率不会达到百分之百

　　所以，软件自动化测试能提高测试效率、覆盖率和可靠性等，同时，自动化测试虽然具有很多优点，但它只是测试工作的一部分，是对手工测试的一种补充，我们要综合评估和运用两者的互补关系，手工和自动化测试结合进行测试，最大限度提高测试效率，减低资源利用率，从而提高软件质量。

软件自动化测试工具的评测方法
                               ------整理


软件测试的主要评测方法包括测试覆盖和质量评测。测试覆盖是对测试完全程度的评测，它是由测试需求和测试用例的覆盖或已执行代码的覆盖表示的。质量评测是对测试对象（系统或测试的应用程序）的可靠性、稳定性以及性能的评测，它建立在对测试结果的评估和对测试过程中确定的变更请求（缺陷）分析的基础上。
1 覆盖评测
覆盖指标提供了“测试的完全程度如何？”这一问题的答案。最常用的覆盖评测是基于需求的测试覆盖和基于代码的测试覆盖。简而言之，测试覆盖是就需求（基于需求的）或代码的设计/实施标准（基于代码的）而言的完全程度的任意评测，如用例的核实（基于需求的）或所有代码行的执行（基于代码的）。
◆基于需求的测试覆盖
基于需求的测试覆盖在测试生命周期中要评测多次，并在测试生命周期的里程碑处提供测试覆盖的标识（如已计划的、已实施的、已执行的和成功的测试覆盖）。 测试覆盖通过以下公式计算：
测试覆盖 = T^(p,i,x,s) / RfT
其中：T是用测试过程或测试用例表示的测试 (Test) 数（已计划的、已实施的或成功的）。RfT 是测试需求 (Requirement for Test) 的总数。
◆基于代码的测试覆盖
基于代码的测试覆盖评测测试过程中已经执行的代码的多少，与之相对的是要执行的剩余代码的多少。代码覆盖可以建立在控制流（语句、分支或路径）或数据流的基础上。基于代码的测试覆盖通过以下公式计算：
测试覆盖 = I^e / TIic
其中：I^e 是用代码语句、代码分支、代码路径、数据状态判定点或数据元素名表示的已执行项目数。TIic (Total number of Items in the code) 是代码中的项目总数。
2 质量评测
测试覆盖的评估提供对测试完全程度的评测，对在测试过程中已发现缺陷的评估提供了最佳的软件质量指标。因为质量是软件与需求相符程度的指标，所以在这种环境中，缺陷被标识为一种更改请求，该更改请求中的测试对象与需求不符。
◆缺陷报告
一般，可以将缺陷计数作为时间的函数来报告，即创建缺陷趋势图或报告；也可以将缺陷计数作为一个或多个缺陷参数的函数来报告，如作为缺陷密度报告中采用的严重性或状态参数的函数。这些分析类型分别为揭示软件可靠性的缺陷趋势或缺陷分布提供了判断依据。
◆性能评测
评估测试对象的性能行为时，可以使用多种评测，这些评测侧重于获取与行为相关的数据，如响应时间、计时配置文件、执行流、操作可靠性和限制。这些评测主要在“评估测试”活动中进行评估，但是也可以在“执行测试”活动中使用性能评测评估测试进度和状态。
主要的性能评测包括：
◆动态监测 - 在测试执行过程中，实时获取并显示正在执行的各测试脚本的状态。

◆响应时间/吞吐量 - 测试对象针对特定主角和/或用例的响应时间或吞吐量的评测。

◆百分位报告 - 数据已收集值的百分位评测/计算。

◆比较报告 - 代表不同测试执行情况的两个（或多个）数据集之间的差异或趋势