2022年提要自动测试与手工测试比较如何开展

菏泽炫佑科技

2022年提要自动测试与手工测试比较如何开展

到目前为止，我们已经讨论了各种测试类型以及如何开发测试用例，但是运行和检查这些测试用例可能需要花费大量的时间和精力。 随着测试覆盖率和质量的提高以及缺陷的纠正，需要额外的时间来运行测试用例。 解决这个问题的方法是自动运行大部分需要重复运行的测试用例。 通过开发软件和使用工具进行的软件测试称为软件测试自动化（ Test ），也可称为软件自动化测试（或自动化测试）。 本章我们将讨论软件测试自动化中的几个主要问题。

第2页，共43页，2022年8月28日 概述 本章小结 自动测试与手动测试的比较 如何进行自动测试 自动测试方案的选择 第3页，共43页，2022年8月28日 10.1 手动测试和自动测试

手动测试与自动测试相反，自动测试是指不使用工具进行软件测试。 这两种测试方式在很多公司都存在，很多小公司只有手工测试。 手动测试和自动化测试哪个更好？ 自动化测试优于手动测试吗？ 在回答这些问题之前，首先要对手动测试和自动化测试有一个清晰的认识，并知道它们各自的优缺点。 Page 4 of 43, 28, 2022 10.1.2 自动化测试是否优于手动测试？

在大多数软件开发模型中，在软件发布之前，编码-测试-修复过程会重复多次。 如果您想测试软件的某个功能，您可能需要多次执行测试。 重复测试的过程也称为回归测试。 如果一个小型软件项目有数千个测试用例需要执行并重复执行，手动测试会非常单调和枯燥。 使用工具进行自动测试可以将人们从这种枯燥、重复的工作中解放出来。 第 5 页，共 43 页，2022 年 8 月 28 日 ● 提高测试执行速度并节省时间。 因此，与手动测试相比，自动测试具有以下优势： 第 6 页，共 43 页，2022 年 8 月 28 日 ● 提高测试效率。 手动测试存在效率问题，这在软件产品开发的后期尤为明显，因为随着产品的日趋完善、功能的增多，需要测试和检查的内容越来越多，很容易漏掉。 另外，随着产品发布日期的临近，手动、重复的回归测试变得更加困难，难以在短时间内完成大规模的测试覆盖。 第 7 页（共 43 页），2022 年 8 月 28 日 ● 提高了准确性和精度。 测试人员尝试了数百个测试用例后，他们的注意力可能会分散，并开始犯错误。 另一方面，测试工具可以重复执行相同的测试并检查测试结果，没有任何错误。 第 8 页，共 43 页，2022 年 8 月 28 日 ● 更好地利用资源。 手动测试需要测试人员在场，而自动化测试可以每周 7 天、每天 24 小时进行。 它还使位于世界不同地区和不同时区的团队能够监视和控制测试，提供全球时区覆盖。 第 9 页，共 43 页，2022 年 8 月 28 日 ● 模拟测试条件。 有些测试用例的测试条件需要大量的人员或设备，这在现实中是无法实现的。 测试工具可以模拟真实情况。第 10 页，共 43 页，2022 年 8 月 28 日

如上所述，既然自动化测试有如此多的优点，那么它是否优于手动测试，是否可以完全接管手动测试的所有工作呢？ 答案是否定的，自动化测试并没有想象中的那么优越。 第 11 页，共 43 页，2022 年 8 月 28 日 手动测试是不可替代的，因为人类是具有很强智能判断能力的动物，而工具则相对机械，缺乏思考能力。 。 手动测试不可替代的方面至少包括以下几点。 ●测试用例设计：测试人员的经验和猜测错误的能力是工具无法替代的。 ●界面和用户体验测试：人类的审美和心理体验是工具无法模拟的。 ●正确性检验：人的是非判断和逻辑推理能力不是由工具提供的。 因此，自动化测试适合使用在需要重复执行机械化接口操作、计算、数值比较、搜索等的领域。我们应该充分利用自动化测试工具的高效率，帮助测试人员完成一些基本的执行。测试用例，从而实现更快的回归测试并提高测试覆盖率。 第 12 页，共 43 页，2022 年 8 月 28 日 10.2 自动化测试的开发 在进行自动化测试之前，必须考虑以下 5 个方面。 这5个方面是成功进行自动化测试需要考虑的因素。 ，也可以用来衡量当前项目是否具备足够的条件进行自动测试。 第 13 页，共 43 页，2022 年 8 月 28 日 (1) 测试自动化类似于记录/回放软件开发过程的脚本开发方法。 不可能应付所有的自动化测试需求。 因此，需要测试人员具备必要的开发知识和编码技能。

(2)测试自动化是一个长期的过程。 首先，不能指望自动测试能在短期内发现很多缺陷。 自动化测试只有长期运行才能体现其价值。 其次，不要以为只要买了工具，录一些脚本，然后就坐看自动化测试达到想要的结果。 需要考虑维护自动化测试脚本的成本。 随着测试应用程序功能的添加和修改，测试脚本的维护工作量急剧增加。 （3）保证测试自动化资源，包括人员和技能，*好有专门的自动测试工程师，保证测试自动化的持续顺利进行。 自动测试工程师需要负责项目的测试自动化，设计测试框架并解决各种问题。 测试脚本结构解决了测试脚本开发问题，保证自动化测试能够有序地规划、设计、开发和维护。 Page 14 of 43, 2022年8月28日 （4）分步进行自动化测试。 从一开始就不要设想大型自动测试。 这往往是无法实现的。 应该从小开始，熟悉工具和自动测试的基本技能。 然后，整合资源，开始实现一些基础的自动测试用例，比如冒烟测试类型的自动测试脚本。 首先对那些容易实现且相对稳定的功能模块进行自动测试，然后再考虑逐步扩展和补充其他相对难以实现或相对不稳定的功能模块。 (5)保证测试过程的成熟度。 如果软件公司的测试流程和项目管理流程的能力成熟度比较低，那么自动化测试的成功率也会比较低。 在启动自动化测试之前，首先要考察软件公司各方面的管理能力。 例如，测试是否独立进行？ 有配置管理吗？ 进度控制能力如何？ 如果各方面能力成熟度比较差，不要盲目引入测试自动化。Page 15 of 43, 28, 2022 10.2.1 自动化测试的周期

对于自动化测试何时开始和结束，没有硬性规定。 自动化测试工作可以与产品开发同时进行，并且可以与产品的多个发布版本重叠。 与多产品版本一样，自动化测试也有多个版本。 自动化测试的总体要求是自动化测试的交付应该先于测试执行阶段，以便在测试被测产品的当前发布版本时可以使用自动化测试交付成果。 自动化测试的要求跨越多个版本的多个阶段，就像产品要求一样。 测试执行可能会在产品发布后不久结束，但自动化测试在产品发布后仍在继续。 第 16 页，共 43 页，2022 年 8 月 28 日 由于产品开发和自动测试开发具有上述相似之处，因此自动测试所遵循的流程和生命周期模型也与产品开发非常相似。 在绝大多数情况下，自动化测试还遵循产品的软件开发生命周期（SDLC）模型。 本节主要通过V型模型及其扩展来介绍自动化测试的流程。 首先，研究如图10-1所示的产品开发涉及的阶段和自动化测试阶段，并了解两者之间的相似之处。 第 17 页，共 43 页，2022 年 8 月 28 日 6.6 单元测试环境 桩号模块 3﹨﹨﹨﹨﹨﹨ 产品需求 产品规划 产品设计 产品编辑 自动化测试需求 自动化测试规划 自动化测试设计 自动化测试编码 图 10-1 产品开发之间的相似之处和自动测试 第 18 页，共 43 页，2022 年 8 月 28 日 正如本章已经介绍的，自动测试生命周期活动与产品开发活动有着密切的关系。 相似。

就像产品需要收集产品需求一样，自动测试也需要收集自动测试需求。 同样，就像产品规划、设计和编码一样，测试自动化过程中也有自动化测试的规划、设计和编码。 在测试产品时验证测试包非常重要。 测试包是一组自动化的测试用例和与这些测试用例关联的场景 ()。 如果测试包中存在缺陷，则需要花费大量精力来确定缺陷是来自产品还是来自测试包。 在使用自动化测试包测试产品之前，必须首先对其进行测试。 如果测试包报告错误的缺陷，将严重影响自动化测试的可信度，影响下一步的自动化测试工作。 因此，自动化测试包必须具有值得信赖的质量。 为了创建质量值得信赖的测试包，与产品开发一样，一些测试阶段非常重要。 图 10-2 扩展了图 10-1，介绍了产品和自动化测试包的测试阶段。 第 19 页，共 43 页2022年提要自动测试与手工测试比较如何开展，2022 年 8 月 28 日 6.6 单元测试环境 桩号模块 3﹨﹨﹨﹨﹨﹨ 产品需求 产品规划 产品设计 自动测试要求 自动测试规划 自动测试编码 图 10-2W 字模型 — 自动化测试中包含的阶段周期 测试设计 测试包测试设计 自动化测试设计 测试计划 测试需求测试包 测试需求测试包 测试计划 产品编码 产品测试准备情况 测试包就绪 测试包测试 产品测试执行 ﹨﹨﹨∕ ∕∕∕∕∕￣￣－－∕ ∣第 20 页，共 43 页，2022 年 8 月 28 日 产品和自动化测试开发的每个阶段都可以执行一组活动，其中具体包括四个活动。

产品在需求阶段收集开发需求的同时，还完成了测试产品的测试需求、自动测试开发的需求和自动测试的需求。 同样，在规划和设计阶段可以执行一组四项活动。 产品和自动化测试的编码构成了此 W 形模型的编码阶段，该阶段提供产品和测试包。 产品和自动化测试就像铁路的两条铁轨，沿相同方向平行运行，并具有相似的期望。 测试包构成自动化测试的可交付成果。 另外，测试框架也可以被视为自动化测试的交付物。 上一段讨论的测试阶段只是针对测试包，因为测试包需要经过彻底的测试才能用于产品测试。 将测试活动引入产品和自动化测试后，生命周期模型图包含两组并行的开发活动和两组并行的测试活动。 这些活动加在一起就形成了 W 形模型。 因此，对于包含自动测试的产品开发，遵循W型模型是一个不错的选择，不仅可以保证产品的质量，而且可以保证开发的测试包满足预期的质量要求。 第 21 页（共 43 页） 2022 年 8 月 28 日 在讨论 W 形模型时，不能将其解释为特定阶段内发生的所有活动都应同时开始和结束。 例如，在图10-2中，“设计”、“测试设计”、“自动化测试设计”和“测试包的测试设计”都出现在同一阶段（图中并排显示）。 对于产品和自动化测试这些活动可以在不同时间开始和结束。

W型模型只保证活动的流程，不限制开始和结束时间。 产品开发和自动化测试可以有独立的时间表，并作为两个不同的项目进行处理。 不需要同时开始和完成的另一个原因是，在许多公司中，同一个测试团队测试产品并开发测试包。 在这种情况下，显然时间表是不同的，活动的开始和结束时间取决于可用资源和其他依赖项确定的项目进度。 对于公司内部有专门的自动化测试团队的情况，自动化测试计划可以独立于产品发布。 每个产品版本都对应于许多（经过测试的）可交付产品。 这样，可以使用*新开发的测试包来测试产品的当前发布版本。第 22 页（共 43 页），2022 年 8 月 28 日 10.2.2 自动化测试的成本

为了成功地进行自动化测试，必须考虑自动化测试的成本。 成本包括测试人员、测试设备、测试工具等。 Page 23 of 43, 28, 2022 (1) 专职测试人员应能够分配专职测试人员开发自动测试脚本，且分配的测试人员不会影响对现有的手动测试人员是否有影响，要保证自动测试的实施不会影响手动测试的正常进行。 (2)自动化测试可能需要额外的测试设备，如测试执行机、文件服务器、数据库等。自动化测试应准备专用的测试设备。 第 24 页，共 43 页，2022 年 8 月 28 日 (3) 有引入测试工具或开发测试工具的成本预算。 没有工具的自动化测试是不可能的。 项目在启动自动化测试之前，需要做好测试工具的引入、测试工具的培训等准备工作。 （4）有些项目使用了很多第三方控件或者自定义控件，这些控件的可测试性很差。 那么这个项目的自动测试成本会非常高，不适合进行自动测试。 Page 25 of 43, 28, 2022 10.2.3 合理选择引入自动测试的时机

自动化测试只有多次运行后才能体现出自动化的优势。 只有持续运行自动测试，才能有效预防缺陷，减少测试人员手动回归测试的工作量。 如果一个项目是短期的、一次性的项目，那么它就不适合进行自动化测试，因为这种项目达不到自动化测试应有的效果和价值。 另外，在进度非常紧张的项目中也不适合进行自动化测试。 一些项目经理期望引入自动化测试来解决严重延迟的项目中的测试效率问题，但结果却适得其反。 这是因为自动测试需要测试人员投入测试脚本的开发。 同时也需要开发者的配合，提供更好的可测试的程序。 被测试的软件可能还需要修改以适应自动测试的基础知识。 要求。 如果在一个已经落后于计划的项目上实施自动化测试，很可能会适得其反。 第 26 页，共 43 页，2022 年 8 月 28 日 过早的自动化会增加维护成本，因为早期的程序接口普遍不够稳定，处于频繁变化的状态。 这时，自动测试往往得不偿失，我们很难应对“动荡”的界面。 那么，什么时候应该开始自动化测试项目呢？ 当接口尚未稳定时，不应该开始自动化测试，而是需要适当的规划和准备。 在界面原型阶段，可以根据界面原型提供的控件尝试自动测试工具的适用性，因为有些控件无法被自动测试工具识别和测试。 这时候就需要考虑工具的选择了。 当开发者开始开发一些核心代码的时候，可能也会开发一些核心的可复用的控件，它们就是自定义的个性化控件。 那么他们需要在这个阶段获得这些控制并尝试使用自动化工具。 来测试这些控件。 如果您发现某些内容不适用自动化软件开发，您应该考虑要求开发人员重新设计控件或提供更多测试接口。 Page 27 of 43, 28, 2022 10.2.4 自动化测试的人员要求

另外，自动测试工程师和手动测试工程师一样，需要具备设计测试用例的基本方法和能力，并具备了解软件所涉及的基本业务的能力。 此外，应该有能力将测试用例转换为自动化测试用例。 了解各种编程语言、编程工具以及各种标准控件和第三方控件，对于自动测试脚本的编写会有很大的好处。 自动测试工程师应具备一定的自动测试基础，包括自动测试工具基础、自动测试脚本开发基础知识等； 他们还需要了解各种测试脚本的编写和设计方法，知道何时选择什么样的测试脚本开发方法，知道如何维护测试脚本； 需要具备一定的编程能力，熟悉某些测试脚本语言的基本语法和使用方法。 Page 28 of 43, 28, 2022 10.3 自动测试方案选择

在选择自动测试解决方案之前，我们首先要确定自动化的对象和范围，然后决定使用什么样的自动测试解决方案以及使用什么样的引导测试脚本开发方法。 Page 29 of 43, 28, 2022

10.3.1 确定自动化的对象和范围

在产品开发过程中，需求发生变化是很常见的。 对于这种情况，很容易确定要自动化的内容。 自动化应考虑保持不变或不变的部分需求。 需求变更一般会影响场景和新功能，但不会影响产品的基本功能。自动化时，首先要考虑产品的基本功能，以便可以作为“回归测试”和“烟雾测试”

.第 30 页（共 43 页），2022 年 8 月 28 日

某些类型的测试会自动实现。 例如：压力、可靠性、可扩展性和性能测试。 这些类型的测试需要在大量不同的计算机上运行测试用例一段时间，例如48小时等。每天让数百个用户使用该产品是根本不可能的。 他们既不愿意承担重复性的任务，也不愿意找到足够多的具备所需技能的人员。 属于这些类型测试的测试用例是自动化的首要候选者。 回归测试是重复的。 这些测试用例在产品开发的各个阶段会多次执行。 由于这些测试用例是重复的，从长远来看，自动化将节省大量时间和精力。 此外，正如本章已经提到的，节省的时间可以有效地用于即兴测试和其他更具创造性的测试。 功能测试 这种类型的测试可能需要复杂的设置，因此可能需要当前不常见的特殊技能。 利用专家的技能一劳永逸地自动化这些测试用例，以便技能较差的员工可以立即运行它们。 第 31 页，共 43 页，2022 年 8 月 28 日 在产品开发场景中，需要重复进行很多测试。 如果考虑到发布版本的定期增强和维护，好的产品就会有很长的寿命。 。 这为在发布周期内多次执行自动化测试用例提供了机会。 作为一般经验法则，如果一个测试用例需要在不久的将来（例如一年）执行至少 10 次，那么您可以考虑自动化这些测试用例（如果自动化工作量不超过执行这些测试用例的 10 倍）测试用例。

当然，这只是根据经验。 选择哪些测试用例需要考虑很多因素，例如您是否具备所需的技能、在强大的发布日期压力下是否有时间设计自动化测试脚本、工具的成本、是否需要任何支持、等。第 32 页（共 43 页），2022 年 8 月 28 日。作为对自动化范围的总结，我们必须选择自动化那些能够以*少的时间延迟获得*大投资回报的任务。 在开始自动化之前，需要付出很大的努力才能获得管理层的承诺。 自动化通常需要大量工作，并且不是一次性活动。 自动化测试用例还需要维护，直到产品退出市场。 由于开发和维护自动化工具所需的工作量很大，因此获得管理层的承诺是一项重要的活动。 由于自动化需要长期投资，管理层的审批是分阶段进行的。 因此，自动化工作应该集中在管理层已经承诺的领域。 投资回报率也是需要认真考虑的一个方面。 自动化工作估算应为管理层提供预期投资回报的清晰画面。 启动自动化时，重点应该放在排列良好的领域。 这使得自动化能够用更少的代码覆盖更多的测试用例。 另外，自动化首先应该考虑需要时间较短、易于自动化的测试用例。 有些测试用例没有预先确定的预期结果。 此类测试用例需要很长的时间来实现自动化，应该放在自动化的后期阶段。 这可以满足管理层寻求自动化投资快速回报的要求。

第 33 页，共 43 页，2022 年 8 月 28 日

为了遵守“要事**”的原则，首先要实现产品的关键和必要功能的自动化。 为此，所有测试用例必须根据客户期望分为高、中、低优先级。 自动化应从高优先级测试用例开始，然后覆盖中低优先级需求的测试用例。第 34 页（共 43 页），2022 年 8 月 28 日 10.3.2 选择自动测试解决方案和脚本编写方法

采用什么样的自动化测试方案需要考虑以下因素： ● 项目影响：自动化测试能否对项目进度、覆盖率、风险产生积极影响，或者让开发更加敏捷？ ● 复杂性：自动化是否易于实施（包括数据和其他环境影响）？ ●时间：实施自动化测试需要多长时间？ ●早期需求和代码的稳定性：能否证明需求或早期代码在一定范围内变化？ ●维护工作量：代码能否长期保持相对稳定？ 功能特性会进化吗？ ●覆盖范围：自动化测试能否覆盖程序的关键特性和功能？ ● 资源：测试团队是否有足够的人力资源、硬件资源和数据资源来运行自动化测试？ ●自动化测试执行：负责执行自动化测试的团队是否有足够的技能和时间来运行自动化测试？ 第 35 页，共 43 页，2022 年 8 月 28 日。自动测试项目也像普通软件开发项目一样有一个编码阶段。 自动测试的编码阶段主要是通过编写测试脚本来实现设计的自动测试用例。 自动功能测试的脚本开发主要有以下几种方法： (1)录音和回放采用简单的录音和回放方法。 测试工程师使用这种方法来自动测试系统流程或某些系统测试用例。 它可能包含一些冗余的、有时不必要的功能脚本，但录制和回放可以避免测试用例的重复执行。 市面上几乎所有的测试工具都具有录音和回放功能。

测试工程师记录键盘字符或鼠标点击的动作序列，然后按记录的顺序回放这些记录的脚本。 由于录制的脚本可以多次回放，因此可以减少测试工作。 除了避免重复工作之外，录制和保存脚本也很简单。 但这一代工具也有一些缺点。 该脚本可能包含一些硬编码值，使得执行常见类型的测试变得困难。 例如，如果报告必须使用当前日期和时间，则很难使用录制的脚本。 错误条件的处理留给测试人员，因此播放脚本可能需要大量手动干预来检测和纠正错误条件。 当应用程序发生变化时，所有脚本都必须重新录制，从而增加了测试维护的成本。 因此，如果更改频繁发生，或者很少有机会重用或重新运行测试用例，那么这一代测试自动化工具的有效性可能会很低。 6.8 单元测试的过程 Page 36 of 43, 28, 2022 (2) 结构化脚本方法在脚本中使用结构化控制。 结构控制允许测试人员控制测试脚本或测试用例的流程。 在脚本中，典型的结构控制使用“if-else”、“”、“for”、“while”等条件状态语句来帮助实现判断、实现某些循环任务以及调用覆盖常用功能的其他函数。 以下是结构化脚本方法的特点： ●测试用例在脚本中定义。

●编程成本略高于录音回放编程方式。 ●需要测试人员适应的编码技能。 ●需要一定程度的规划和设计。 ●测试数据也硬编码在脚本中。 ●由于比较稳定，所以需要的脚本维护相对较少，维护成本相对录制回放脚本编写方式要低。 ●除了编程知识外，还需要一些脚本语言的知识。 第 37 页，共 43 页，2022 年 8 月 28 日 (3) 数据驱动 数据驱动脚本方法将数据从脚本中分离出来，并将其存储在外部文件中。 这样，脚本就只包含编程代码。 如果要在测试运行时更改数据，则需要这样做。 这样当测试数据发生变化时，脚本就不需要修改代码了。 有时，测试的预期结果值也可以与测试输入数据一起存储在数据文件中。 以下是数据驱动脚本方法的特征： ● 脚本以结构化方式编程。 ●测试用例由测试数据或脚本定义。 ●由于脚本参数化和编程成本的原因，该方法的开发成本相对于结构化脚本方法来说较高。 ●要求测试人员具有较高的代码调整编程能力。 ●需要更多的规划和设计。 ●数据独立存储在数据表或外部文件中。 ●脚本维护成本低。 ●推荐在需要测试正负数据时使用。 第 38 页，共 43 页，2022 年 8 月 28 日 (4) - 关键字驱动的脚本方法在外部数据文件中维护检查点和执行操作的控制。

因此，测试数据和测试操作顺序控制都设计在外部文件中，除了常规脚本之外，还需要额外的库来翻译数据。 关键字驱动脚本方法是数据驱动测试方法的延伸，其特点如下： ● 结合了数据驱动脚本方法和结构化脚本方法。 ●测试用例由数据定义。 ●开发成本高，需要较多的测试规划和设计开发投入。 ●要求测试人员具有较强的编程能力。 ●初期规划、设计、管理成本较高。 ●数据存储在外部文件中。 ●维护成本相对较低。 ●需要额外的框架或库，因此测试人员需要更多的编程技能。 第 39 页（共 43 页），2022 年 8 月 28 日 (5) 行为驱动 行动驱动 该技术使外行能够创建用于自动化测试的测试用例。 运行这样的测试用例不需要输入和预期输出条件。 应用程序中发生的所有操作都会根据为自动化定义的一组通用控件进行自动测试。 动作集被表示为对象，并且这些对象可以被重用。 用户只需要描述操作（例如登录、下载等），其他所需的一切都会自动生成并使用。 Input and are and used. With this of test tools, test can be using the test . - of two main : test case and . Its are as : ●Test cases are by the . ● costs are and in and . ● are to have . ●The , , and costs are very high. ● costs are low. ● and to are . ●Need to have for .Page 40 of 43, 28, 2022

To sum up, the cost of to as the from and to -; the cost of as the from and to -. is . skill , as from -and- to -, the for a 's are . The for and test are as from -and- to -.

, the test be and the be used at the time and in the place.Page 41 of 43, 28, 2022

This the and of and , that can the of , but it the first test. When , the cost and cycle of be , and the of test be . At the same time, it is to the and scope of based on needs, and then what kind of test plan and test to adopt.

Page 42 of 43, 28, 2022

1. the and of and . 2. What does the cycle of? 3． What are the ? 4． When a small and -sized in a small and the cycle is very short, what we use? Page 43 of 43, 28, 2022

炫佑科技专注互联网开发小程序开发-app开发-软件开发-网站制作等