软件测试未来的发展趋势以及软件测试进阶路线_软件测试趋势

全球各地的企业每天都在发展变化着，以应对市场挑战，满足日益成熟的客户需求。即使是正在进行的技术进步也会使软件测试专家在实践的过程中更加专注和精确。

　　2021年给软件测试领域带来了新的技术解决方案，以及质量保证和软件测试的实现。与此同时，诸如敏捷、DevOps、DevSecOps和测试自动化等实践继续在整个软件测试周期中保持其相关性和应用。

　　而2022年-2023年软件测试和开发领域的一些强劲趋势主要有以下几个：

　　1、人工智能促进软件测试

　　《福布斯》的一篇题为《软件测试中的人工智能：机器人会代替你的位置吗?》中提到：“依赖技术完成高重复性任务的趋势，同时使人们能够专注于高价值的活动，如创造收入、建立关系和增长管理，正在加快变化的步伐。因为很多测试空间是重复的，有理由相信人工智能可以很容易地在这些领域中使用。剩下的将留给测试人员，他们的工作将是审查系统，与人工智能一起工作，来彻底改变测试的执行方式。”

　　这说明了AI在软件测试中的必要性和重要性。随着商业数字化转型的加快，人工智能在软件测试速度和准确性方面的应用必将增加。甚至机器学习也在测试和软件开发过程中取得了长足的进步，特别是在预测分析、日志分析、需求跟踪和缺陷分析方面。

　　2、数字化转型与持续集成

　　在过去的一年里，有很多关于数字转型的讨论和文章。企业正在经历巨大的数字化变革，这也带来了许多不安全感和挑战。使用诸如Agile和DevOps之类的方法，测试过程变得更加灵活，并且能够响应业务需求。

　　然而，随着新特性必须以渐进的模式交付，这将增强在启动和运行的应用程序中持续部署和集成的需要。业务转换每天都会遇到新的挑战，这些挑战可能与性能、安全性或功能相关。因此，随着时间的推移，对持续开发和集成的需求只会不断增加。

　　3、测试数据在业务中的有效应用

　　正如业务专家和技术极客所预估的那样，数据将增强测试人员的业务决策能力，并使有效的决策能力成为可能。而更重要的是测试数据，它可以确保推导出的推论是准确的，并以一种容易理解的形式去传递。测试人员需要验证TB级别的数据是否得到了有效的处理，并被分解为精确的集群，以获得所需的推论。

　　这种测试数据可以应用到性能测试、功能测试，甚至是安全测试。在大数据测试中，保证数据的质量是非常关键的，大数据测试可以从精度、准确性、一致性、重复性等特征入手进行验证。

　　4、测试智能应用程序

　　根据ResearchAndMarkets的一份报告，“全球智能应用市场在2017年是83.9亿美元，预计到2026年将达到934亿美元，在预测期间的复合年增长率为30.7%。”对先进分析工具的日益渴望，部署新产品技术的进步，以及大数据和分析市场的提升，正在推动智能应用的发展。发展中经济体的接受程度加深为市场扩张提供了重大机遇。

　　这份报告总结了智能应用的需求，我们可以从未来的趋势中评估，测试需求只会增加。对这些应用程序的准确性、性能、安全性、功能以及任何基于需求的东西进行有效测试的需求也正在增长。

　　5、性能工程，而不仅仅是性能测试

　　确保你的应用程序或软件在不断变化或具有挑战性的条件下按预期工作始终是需要考虑的一个重要因素。性能测试一直是软件测试的一个关键方面，随着趋势的发展，性能测试将最终转向性能工程。重点将主要集中在所有能够确保性能、安全性、可用性、网络兼容性等的因素上，而这些因素都必须致力于交付高质量的应用程序，以满足客户日益增长的需求。

　　即使在未来几年，软件测试的需求和作用也只会越来越突出，技术和数字环境方面的挑战必将进一步增加。因此，对软件测试和质量保证的需求在这些变化的环境中保持相关性同样重要。

 

一、测试与软件模型
软件开发生命周期模型指的是软件开发全过程、活动和任务的结构性框架。软件项目的开发包括：需求、设计、编码、测试、稳定、部署、维护等阶段。

常见的软件开发模型有瀑布模型、迭代开发、螺旋开发和敏捷开发。

1 瀑布模型

瀑布模型式是最典型的预见性的方法，严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤顺序进行。步骤成果作为衡量进度的方法，例如需求规格，设计文档，测试计划和代码审阅等等。瀑布式的主要有以下问题：

各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；
由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险；
早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。
因此，瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。

2 迭代开发模型

迭代式开发是一种与传统的瀑布式开发相反的软件开发过程，具有更高的成功率和生产率。在迭代开发中，整个开发工作被组织为一系列的短小的、固定长度（如3周）的小项目，逐步逐步的完成，故为迭代。每一次迭代都包括需求分析、设计、实现与测试。采用这种方法，开发工作可以在需求被完整地确定之前启动，并在一次迭代中完成系统的一部分功能或业务逻辑的开发工作。再通过客户的反馈来细化需求，并开始新一轮的迭代。迭代开发具有以下优点：

降低风险。如果开发人员重复某个迭代，那么损失只是这一个开发有误的迭代的花费。
适应需求变更。由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段中不断细化的。
持续的测试与集成，降低后期的工作量与风险。
3 螺旋开发模型

螺旋开发，将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。“螺旋模型”刚开始规模很小，当项目被定义得更好、更稳定时，逐渐展开。 “螺旋模型”的核心就在于不需要在刚开始的时候就把所有事情都定义的清清楚楚。您轻松上阵，定义最重要的功能，实现它，然后听取客户的意见，之后再进入到下一个阶段。如此不断轮回重复，直到得到您满意的最终产品。 螺旋开发分为以下四个阶段：

制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；
风险分析：分析评估所选方案，考虑如何识别和消除风险；
实施工程：实施软件开发和验证；
客户评估：评价开发工作，提出修正建议，制定下一步计划。
一个阶段首先是确定该阶段的目标，完成这些目标的选择方案及其约束条件，然后从风险角度分析方案的开发策略，努力排除各种潜在的风险，有时需要通过建 造原型来完成。如果某些风险不能排除，该方案立即终止，否则启动下一个开发步骤。最后，评价该阶段的结果，并设计下一个阶段。

4 敏捷开发模型

敏捷开发，是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。

个体和互动重于流程和工具。
可工作的软件重于求全而完备的文档。
客户协作重于合同谈判。
应对变化重于遵循计划。
其中位于右边的内容虽然也有其价值，但是左边的内容最为重要。人员彼此信任，人少但是精干，可以面对面的沟通。

敏捷开发小组主要的工作方式可以归纳为：作为一个整体工作；按短迭代周期工作；每次迭代交付一些成果；关注业务优先；检查与调整。

最重要的因素恐怕是项目的规模。规模增长，面对面的沟通就愈加困难，因此敏捷方法更适用于较小的队伍，40、30、20、10人或者更少。

5 四种模型比较

传统的瀑布式开发，也就是从需求到设计，从设计到编码，从编码到测试，从测试到提交大概这样的流程，要求每一个开发阶段都要做到最好。特别是前期阶段，设计的越完美，提交后的成本损失就越少。

迭代式开发，不要求每一个阶段的任务做的都是最完美的，而是明明知道还有很多不足的地方，却偏偏不去完善它，而是把主要功能先搭建起来为目的，以最短的时间，最少的损失先完成一个“不完美的成果物”直至提交。然后再通过客户或用户的反馈信息，在这个“不完美的成果物”上逐步进行完善。

螺旋开发，很大程度上是一种风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之前，都必须首先进行风险评估。

敏捷开发，相比迭代式开发两者都强调在较短的开发周期提交软件，但是，敏捷开发的周期可能更短，并且更加强调队伍中的高度协作。敏捷方法有时候被误认为是无计划性和纪律性的方法，实际上更确切的说法是敏捷方法强调适应性而非预见性。

适应性的方法集中在快速适应现实的变化。当项目的需求起了变化，团队应该迅速适应。这个团队可能很难确切描述未来将会如何变化。

6 软件开发过程中的测试

在前面介绍的软件开发过程中，测试都是一个重要的组成部分。尤其对于中大型项目，从项目开始指出就要制定测试计划、对需求进行测试、设计测试和测试用例、执行测试，最后对测试的结果进行总结和分析。软件缺陷发现得越早，修复软件缺陷所需的代价越小。

TDD（测试驱动开发）的思路就是通过测试推动整个开发的进行，开发代码之前，先编写测试代码。在明确要开发某个功能后，首先思考如何对这个功能进行测试，并完成测试代码的编写，然后编写相关的代码满足这些测试用例。并且，软件测试的活动贯穿整个软件开发生命周期的始终。

7 软件测试的目的与原则

测试的定义：使用人工或自动手段来运行或测定某个系统的过程，其目的在于检查它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。

软件测试的目的：发现程序中的错误，保证软件产品的最终质量。

测试是程序的执行过程，目的在于发现错误
一个成功的测试用例在于发现至今未发现的错误
一个成功的测试是发现了至今未发现的错误的测试
确保产品完成了它所承诺或公布的功能，并且用户可以访问到的功能都有明确的书面说明。
确保产品满足性能和效率的要求
确保产品是健壮的和适应用户环境的
软件测试的原则：

测试用例中一个必须部分是对预期输出或接口进行定义
程序员应避免测试自己编写的程序
编写软件的组织不应当测试自己编写的软件
应当彻底检查每个测试的执行结果
测试用例的编写不仅应当根据有效和预料到的输入情况，而且也应当根据无效和未预料到的输入情况
检查程序是否“未做其应该做的”仅是测试的一半，测试的另一半是检查程序是否“做了其不应该做的”
应避免测试用例用后即弃，除非软件本身就是个一次性的软件
计划测试工作时不应默许假定不会发现错误
程序某部分存在更多错误的可能性，与该部分已经发现错误的数量成正比
8 软件的可测性

软件的可测性太差会导致测试的难度相当大，甚至无法测试。这种情况往往是由于极差的软件架构设计和极为不规范的软件开发工作导致的。

紧耦合。不把大半个系统实例化就无法测试。
弱内聚。这个类实现了太多功能，导致测试非常复杂。
冗余。同一个方法在多处使用，每一处都得测。
好的软件架构应该是松耦合、高内聚的。提高软件的测试性的同时也提高了软件的可维护性和可管理性。

二、测试用例设计
测试用例是为特定的目的而设计的一组测试输入、执行条件和预期的结果。测试用例是执行的最小实体。简单地说，测试用例就是设计一个场景，使软件程序在这种场景下，必须能够正常运行并且达到程序所设计的执行结果。

1 黑盒测试与白盒测试

黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。白盒测试：已知产品的内部工作过程，可以进行测试证明每种内部操作是否符合设计规格要求，所有内部成分是否经过检查。

合理的测试策略是将这两种测试要素组合起来。我们可以通过使用特定的面向黑盒测试的测试用例设计方法，而后使用白盒测试方法对程序的逻辑结构进行检查以补充这些测试用例，借此来设计出一个相当严格的测试。

白盒测试方法有语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖。黑盒测试方法有等价类划分、边界值分析、因果图分析、错误测试、状态图、场景法等。

2 白盒测试用例设计

白盒测试关注的是测试用例执行的程度或覆盖程序逻辑结构（源代码）的程度。完全的白盒测试是将程序中每条路径都执行到，然而对一个带有循环的程序来说，完全的路径测试并不切合实际。白盒测试的特点：依据软件设计说明书进行测试、对程序内部细节的严密检验、针对特定条件设计测试用例、对软件的逻辑路径进行覆盖测试。

语句覆盖是最起码的结构覆盖要求，语句覆盖要求设计足够多的测试用例，使得程序中每条语句至少被执行一次。可以很直观地从源代码得到测试用例，无须细分每条判定表达式。由于这种测试方法仅仅针对程序逻辑中显式存在的语句，但对于隐藏的条件和可能到达的隐式逻辑分支，是无法测试的。（遗漏隐藏的逻辑分支）

判定覆盖要求必须编写足够的测试用例，使得每一个判断都至少有一个为“真”和为“假”的输出结果。判定覆盖比语句覆盖要多几乎一倍的测试路径，当然也就具有比语句覆盖更强的测试能力。同样判定覆盖也具有和语句覆盖一样的简单性，无须细分每个判定就可以得到测试用例。往往大部分的判定语句是由多个逻辑条件组合而成（如，判定语句中包含AND、OR、CASE），若仅仅判断其整个最终结果，而忽略每个条件的取值情况，必然会遗漏部分测试路径。（遗漏组合判定中的某些条件取值）

条件覆盖要求设计足够多的测试用例，使得判定中的每个条件获得各种可能的结果，即每个条件至少有一次为真值，有一次为假值。要达到条件覆盖，需要足够多的测试用例，但条件覆盖并不能保证判定覆盖。条件覆盖只能保证每个条件至少有一次为真，而不考虑所有的判定结果。

判定/条件覆盖要求设计足够多的测试用例，使得判定中每个条件的所有可能结果至少出现一次，每个判定本身所有可能结果也至少出现一次。判定/条件覆盖满足判定覆盖准则和条件覆盖准则，弥补了二者的不足。判定/条件覆盖准则的缺点是未考虑条件的组合情况。

多重条件覆盖要求设计足够多的测试用例，使得每个判定中条件结果的所有可能组合至少出现一次。多重条件覆盖准则满足判定覆盖、条件覆盖和判定/条件覆盖准则。更改的判定/条件覆盖要求设计足够多的测试用例，使得判定中每个条件的所有可能结果至少出现一次，每个判定本身的所有可能结果也至少出现一次。并且每个条件都显示能单独影响判定结果。缺点是线性地增加了测试用例的数量。

路径覆盖要求设计足够的测试用例，覆盖程序中所有可能的路径。由于路径覆盖需要对所有可能的路径进行测试（包括循环、条件组合、分支选择等），那么需要设计大量、复杂的测试用例，使得工作量呈指数级增长。而在有些情况下，一些执行路径是不可能被执行的，这样不仅降低了测试效率，而且大量的测试结果的累积，也为排错带来麻烦。

3 黑盒测试用例设计
（1）等价类划分

等价类划分是把所有可能的输入数据,即程序的输入域划分成若干部分（子集）,然后从每一个子集中选取少数具有代表性的数据作为测试用例。等价类分为有效等价类和无效等价类，其中，有效等价类是指对于程序的规格说明来说是合理的，有意义的输入数据构成的集合；而无效等价类是指对于程序的规格说明来说是不合理的，没有意义的输入数据构成的集合。设计测试用例时,要同时考虑这两种等价类。因为软件不仅要能接收合理的数据,也要能经受意外的考验，这样的测试才能确保软件具有更高的可靠性。划分等价类有以下原则：

在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类。如：输入值是学生成绩，范围是0～100；则小于0和大于100的为无效等价类，0~100之间的为有效等价类。
在输入条件规定了输入值的集合或者规定了"必须如何"的条件的情况下，可确立一个有效等价类和一个无效等价类。
在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类。
在规定了输入数据的一组值（假定n个）,并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类。例：输入条件说明学历可为:专科、本科、硕士、博士四种之一，则分别取这四种这四个值作为四个有效等价类，另外把四种学历之外的任何学历作为无效等价类。
在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）；
在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类。
在确立了等价类后,可建立等价类表,列出所有划分出的等价类输入条件：有效等价类、无效等价类，然后从划分出的等价类中按以下三个原则设计测试用例：

为每一个等价类规定一个唯一的编号；
设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步，直到所有的有效等价类都被覆盖为止；
设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步，直到所有的无效等价类都被覆盖为止。
（2）边界值分析

边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件。边界值分析不仅考虑输入条件，还要考虑输出空间产生的测试情况。

长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入和输出等价类的边界，就是应着重测试的边界情况。应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。

（3）因果图

因果图是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。

等价类划分法和边界值分析方法都是着重考虑输入条件，但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了，但多个输入条件组合起来可能出错的情况却被忽视了。如果在测试时必须考虑输入条件的各种组合，则可能的组合数目将是天文数字，因此必须考虑采用一种适合于描述多种条件的组合、相应产生多个动作的形式来进行测试用例的设计，这就需要利用因果图（逻辑模型）。

（4） 错误测试

错误测试是基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法。

如测试一个对线性表（比如数组）进行排序的程序，可推测列出以下几项需要特别测试的情况：

输入的线性表为空表；
表中只含有一个元素；
输入表中所有元素已排好序；
输入表已按逆序排好；
输入表中部分或全部元素相同。
4 测试用例设计综合策略

Myers提出了使用各种测试方法的综合策略：

在任何情况下都必须使用边界值分析方法，经验表明用这种方法设计出测试用例发现程序错误的能力最强。
必要时用等价类划分方法补充一些测试用例。
用错误推测法再追加一些测试用例。
对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度，如果没有达到要求的覆盖标准，应当再补充足够的测试用例。
如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法。
测试用例的设计步骤：1)构造根据设计规格得出的基本功能测试用例；2)边界值测试用例；3)状态转换测试用例；4)错误猜测测试用例；5)异常测试用例；6)性能测试用例；7)压力测试用例。

三、软件测试类型
单元测试

单元测试并不是对整个程序进行测试，而是对构成程序的较小模块进行测试。单元测试减小了调试的难度（一旦某个错误被发现出来，我们就知道它在哪个具体的模块中）；单元测试提供了同时测试多个模块的可能，将并行工程引入软件测试中。

在为模块单元测试设计测试用例时，需要使用两种类型的信息：模块的规格说明和模块的源代码。规格说明一般都规定了模块的输入和输出参数以及模块的功能。单元测试总体上是面向白盒测试的，因此，单元测试的测试用例的设计过程如下：使用一种或多种白盒测试方法分析模块的逻辑结构，然后使用黑盒测试方法对照模块的规格说明以补充测试用例。

集成测试

自顶向下集成和自底向上集成

功能测试

功能测试的目的是为了暴露程序的错误以及与规格说明不一致之处，而不是为了证明程序符合其外部规格说明。

功能测试是一种黑盒测试，功能测试常用步骤有：根据需求来细分功能点，根据功能点派生测试需求，根据测试需求设计功能测试用例。

系统测试

系统测试的目的是为了证明程序不能实现其目标，系统测试的测试用例设计有以下14种类型：

能力测试：是判断目标文档提及的每一项能力（或功能）是否都确实已经实现。
容量测试：使程序经受大容量数据的检验。容量测试的目的是为了证明程序不能处理目标文档中规定的数据容量。
强度测试：使程序承受高负载或强度的检验。所谓高强度是指在很短的时间间隔内达到的数据或操作的数量峰值。
易用性测试：试图发现人为因素或易用性的问题。
安全性测试：设计测试用例来突破程序安全检查的过程。举例来说，我们可以设计测试用例来规避操作系统的内存保护机制，破坏数据库管理系统的数据安全机制。
性能测试：很多软件都有特定的性能或效率目标，这终特性描述为在特定负载和配置环境下程序的响应时间和吞吐率。
存储测试：
配置测试：
兼容性测试。
安装测试：有些类型的软件系统安装过程非常复杂，测试安装过程是系统测试中的一个重要部分。对于包含在软件包中的自动安装系统而言，这尤其重要。安装程序如果出现故障，会影响用户对软件的成功体验。
可靠性测试：所有类型的测试都是为了提高软件的可靠性，但是如果软件的目标中包含了对可靠性的特别描述，就必须设计专门的可靠性测试。
可恢复性测试：诸如操作系统、数据库管理系统和远程处理系统等软件通常都有可恢复性目标，说明系统如何从程序错误、硬件失效和数据错误中恢复过来。系统测试的一个目标是证明这些恢复机制不能够正确发挥作用。我们可以故意将程序错误置入某个系统中，判断系统是否可以从中恢复。
适用性测试
文档测试：检查用户文档的正确性。用户文档应成为审查的对象，检查其正确性和清晰性。在文档中描述的任何范例应编成测试用例，并提交给程序。
四、自动化测试
自动化测试：以程序测试程序、以代码代替思维、以脚本运行代替手工测试。

冒烟测试:就是在一个新版本出来的时候，将软件的全部功能过一遍，看有没有什么大问题。如果功能可以正常运行，不会影响测试进行，那么这个版本就可以真正开始测试了。如果功能有重大问题或影响测试进行，那么这个版本就是不合格的，不用进行进一步的测试。比如，拿到QQ的app新版本，登陆都登陆不上，那么这个版本肯定无法继续测下去。或者，游戏中新的模块出现，但是新的模块总是崩溃、卡死，测试进行不下去，那么冒烟的结果就是不合格的。

回归测试:就是以前版本中发现的bug在新的版本中验证是否存在且是否引发新的bug。

1 自动化测试的优势

回归测试更方便、可靠。由于回归测试的业务流程操作和测试用例是预先设计好的，预期结果也是完全在项目人员掌握之中的，将回归测试交给计算机自动运行，可以极大提高测试效率，缩短回归测试时间。
可运行更多更繁琐的测试，且快速高效。
可执行一些对于手工测试来说相当困难或根本做不到的测试。比如，对大量用户的并发测试等。
具有一致性和可重复性的特点。
自动化测试脚本完全具有复用性。由于自动化测试通常以脚本的方式实现，这样在不同的版本之间，就可能只需要做少量的维护甚至不做任何修改，实现在不同的测试版本中使用相同的测试脚本执行相同的测试用例。
2 自动化测试的劣势

永远不可能完全取代手工测试。自动化测试无法做到手工测试的覆盖率，不是每个测试用例都适合转换成自动化测试用例的。
无法保证测试的正确性。测试脚本本身也可能存在缺陷。
手工测试能发现的缺陷远比自动化测试多。自动化测试几乎是无法发现新缺陷。
自动化测试工具是死的，它本身没有任何想象力。
自动化测试对测试工程师来说必须有一定的开发技术背景。
3 引入自动化测试的时机

项目周期长，系统版本不断。主要在于回归测试。
需求变更不频繁。
系统中的测试对象基本可以正常识别，不存在大批量第三方控件。
需要反复测试，如可靠性测试需要进行上千次的系统测试。
4 何时避免展开自动化测试

项目周期短，需求变更频繁。项目周期短的情况下引入自动化测试，不但收不回成本，而且会延长产品的发布时间。需求频繁改变会使老功能的业务逻辑被修改，从而导致相应的测试脚本也需相应修改。
软件版本还没稳定。
多数对象无法识别以及脚本维护频繁与艰难。
5 自动化测试用例设计

在项目的测试过程中，测试工程师都会首先分析测试需求，产出测试计划后，编写和设计测试用例，设计开发测试脚本。

自动化测试用例的范围往往是核心业务流程或者重复执行率较高的。并不需要覆盖所有的手工测试用例。
自动化测试用例的选择一般以“正向”为主。正常情况即为“正向”，异常情况即为“反向”。功能自动化测试主要还是用于回归测试，回归测试的目的就是保证新增功能后老功能是否能够正常运作。
手工测试用例可以不用回归原点，而自动化用例往往是必须的。所谓回归原点就是执行的测试用例最终需要恢复其在执行前的初始状态。比如添加用户功能，由于用户名是唯一的，第一次执行时没有问题，第二次执行时程序就会出现用户名重复而报错；这种情况下，就需要在自动化测试用例最后增加删除该用户的步骤。
自动化测试用例与手工测试用例不同，不需要每个步骤都写预期结果。
五、测试文档编写与缺陷管理
测试文档包括：测试计划文档，测试设计规格文档，测试用例，软件缺陷报告，状态报告。

测试用例对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。测试用例一般包括验证测试用例和证伪测试用例；验证测试用例用于验证代码是否按照预期执行，得到预期结果；证伪测试用例验证代码是否对异常和错误条件进行了适当处理。

缺陷报告包括：问题/错误的简单描述，重现的环境配置要求，保证多次精确重复的特定输入，期望结果与实际结果的对比，优先级与严重性，对客户的影响等。

六、常用的测试工具
1 功能测试UFT

UFT自动化测试的原理

封装真实被测对象并转化为UFT对象到对象库。
对比对象库里的对象鉴别属性和运行时的真实被测对象的鉴别属性。
对比结果一致，则说明对象成功匹配并可以继续对该真实被测对象进行后续操作；如果不一致则报错，提示对象无法识别。
封装对象模型

在UFT里的封装对象共分两个概念，Test Objects（测试对象，TO）和Runtime Objects（运行时对象，RO）。TO就是被被添加到对象库中的对象，RO就是被测试软件在运行实际所运行的对象。他们都是UFT封装的对象，TO是为了识别RO而存在的。

UFT识别对象通常先在对象库中添加测试对象，然后在被测软件运行的时候，根据脚本中调用的对象名称，在对象库中找到相应的测试对象，并根据这些对象的特征属性，在被测试软件中搜索相匹配的正在运行的对象，最后就可以对这些实际运行的测试对象进行操作。

GetTOProperty()
基本含义：获取对象库中某个对象的某个属性的值。
公式：ReturnValue = 对象.GetTOProperty("封装属性名")

SetTOProperty()
基本含义：设置对象库中某个对象的某个属性的值。
公式：对象.SetTOProperty "封装属性名" "封装属性值"
注：使用代码形式的修改对象属性属于临时性的，只在脚本运行时有效，一旦脚本运行结束，对象库里的属性值就会还原。

GetROProperty()
基本含义：获取实际运行时的某个对象的某个属性的值。
公式：ReturnValue = 对象.GetROProperty("封装属性名")
注：使用GetROProperty这个方法来动态获取实际运行时的一些确认信息，然后和所预期的测试数据做对比。如注册功能，在提交一些注册信息以后，一般都要到接下来的确认页面去验证一些信息，这就可以使用GetROProperty来动态获取实际运行时的一些确认信息。

对象无法识别的解决办法

设置虚拟对象。不推荐，虚拟对象非常脆弱，难以维护；即使对象没有发生变化，但只要对象在界面是那个的方位发生变化，虚拟对象就会识别失败。
使用相对坐标配合WSH去定位对象。
使用DOM组建接口应用技术。只适用于Web项目。
使用UFT自定义扩展SDK Customer来进行二次开发使UFT能够识别对象。难度大。
开发提供专属插件。
把无法识别的对象的一些方法封装到一个dll中并使用UFT调用。
数据驱动与场景恢复

数据驱动Data Table的应用：实现测试数据和脚本业务的分离。
场景恢复：场景恢复可以应对多种类型的错误并进行恢复操作。

2 性能测试LoadRunner

LoadRunner是一种适用于各种体系架构的自动负载测试工具，它能预测系统行为并优化系统性能。LoadRunner的测试对象是整个企业的系统，它通过模拟实际用户的操作行为和实时性能监测，来帮助测试人员更快地查找和发现问题。

轻松创建虚拟用户。Virtual User Generator能够生成虚拟用于，以虚拟用户的方式模拟真实用户的业务操作行为。它先记录下业务流程，然后将其转化为测试脚本，并进行参数化操作（Data Wizard直接连接数据服务器获取数据）。利用虚拟用户可以在不同操作系统上同时产生成千上万用户访问，能极大的减少负载测试所需要的硬件和人力资源。
创建真实负载。建立虚拟用户后，需要设定负载方案、业务流程组合和虚拟用户数量。用Controller能够很快地组织多用户测试方案。
定位性能问题。LoadRunner内含一个实时检测器，在负载测试过程的任何时候都能观察到应用系统的运行性能。
分析结果。一旦测试完毕，LoadRunner收集汇总所有的测试数据，并提供高级的分析和报告工具，一遍迅速找到性能问题并做出相应的调整。
最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

文档获取方式：

这份文档，对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！

以上均可以分享，只需要你搜索vx公众号：程序员雨果，即可免费领取