51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

测试开发精英班,通向高级软件测试工程师【长期招募】博为峰网校招聘兼职讲师!【hot!】京东商城自动化测试框架开发实战一站式软件测试平台
【你来问我来答第94期】:如何做web安全测试!《51测试天地》51期征稿开始啦! 三分钟颠覆认知 2017软件测试调查报告独家发布 自学软件测试那点事
查看: 122|回复: 1

[原创] 测试自动化技巧和最佳实践

[复制链接]
  • TA的每日心情
    慵懒
    16 分钟前
  • 签到天数: 13 天

    连续签到: 2 天

    [LV.3]测试连长

    发表于 4 天前 | 显示全部楼层 |阅读模式
    本帖最后由 软件测试mini 于 2018-8-10 17:06 编辑

    自动化测试是软件开发生命周期中的一项重要测试活动,因为它可以在开发新功能时为团队提供快速反馈。它还消除了QA重复运行回归测试的负担,从而节省了QA专注于其他测试活动的时间。
    如果做得好,测试自动化对团队非常有益。以下提示将帮助您从自动化测试过程和活动中获得最大价值,并突出显示在开始自动化测试时避免的陷阱。
    手动与自动 - 测试与检查
    避免手动和自动测试之间的比较。它们都是必需的,因为每个都有不同的用途。自动化测试是一组由人员编写以执行特定任务的指令。每次运行自动化测试时,它都将遵循与指示完全相同的步骤,并仅检查要检查的内容。
    另一方面,在手动测试期间,测试人员的大脑正在参与并可以发现系统中的其他故障。每次测试步骤可能不一定相同,因为测试者可以在测试期间改变流程; 在探索性测试的情况下尤其如此。
    自动化回归测试
    您希望自动化的主要原因是您希望在每个新版本上重复执行测试。如果要求测试只执行一次,那么自动化测试的努力可能会超过好处。
    随着被测软件的发展,需要重复执行回归测试。对于QA来说,每天必须运行回归测试,这可能非常耗时且无聊。回归测试是测试自动化的理想选择。
    在自动化之前进行设计测试
    在开始自动化测试之前创建测试用例和场景始终是一个好习惯。这是一个很好的测试设计,可以帮助识别缺陷,自动化测试只执行测试设计。
    直接进入自动化的危险在于,您只对使脚本工作感兴趣,并且通常只能自动执行积极和快乐的流程场景,而不是考虑可以测试的其他可能场景。

    此外,不要仅仅为了使测试工作或通过而减少测试范围。
    从自动化测试中删除不确定性
    自动化测试的关键之一是能够提供一致的结果,以便我们可以确定在测试失败时出现了问题。
    如果自动化测试在一次运行中通过而在下次运行中失败,而在测试软件没有任何变化的情况下,我们无法确定故障是由应用程序引起还是由于其他因素,例如测试环境问题或问题测试代码本身。

    当出现故障时,我们必须分析结果,看看出了什么问题,当我们有很多不一致或误报结果时,它会增加分析时间。
    不要害怕从回归包中删除不稳定的测试; 相反,旨在获得您可以信赖的一致清洁结果。
    查看自动化测试的有效性
    您会对过时的自动化测试数量感到震惊,只是不检查任何内容或者没有检查最重要的验证!
    这可能是直接跳到自动化的症状,而没有花费足够的时间事先计划需要做什么和设计好的测试场景。

    始终有一位同事审查自动化测试的有效性和理智性。确保测试是最新的。
    不要自动化不稳定的功能
    随着新功能或功能的开发,许多事情都可能出错,甚至该功能也可能不再适用,因为业务已经改变了主意。
    如果您在开发功能时开始自动化测试,则随着功能的发展,测试需要多次更新,并且在尝试跟上所有更改时可能非常艰巨。如果该功能不再适用,那么测试自动化的所有工作都会被浪费掉。

    因此,一旦功能稳定并且不易变化,最好自动执行功能。
    不要期望魔法从测试自动化
    测试自动化的主要原因是为有趣的探索性测试释放QA时间,并为团队提供信心,即在提供新的更改时应用程序仍处于良好状态。
    不要指望自动化能找到很多错误。实际上,自动化发现的错误数量总是比手动和探索性测试少得多。
    不要过分依赖自动化 - 谨防通过测试
    自动回归测试可以给团队一种信心,因为回归测试仍然会在新功能交付时通过。团队开始依赖测试,并且有一套好的回归测试可以充当安全网。
    但请注意,并非所有测试都是自动化的或可自动化的,因此始终伴随着自动化测试和探索性测试。
    有时软件的更改应该通过测试; 但是,如果所有测试都通过,这意味着错过了缺陷,并且因为没有号召性用语,那么缺陷就会被忽视。
    瞄准快速反馈
    快速反馈是自动化测试的目标之一,因为开发人员很想知道他们开发的内容是否有效并且没有破坏当前的功能。
    为了获得这种快速反馈循环,测试需要在组件或API层自动化,而不依赖于UI。

    在UI上运行的测试要慢得多,并且由于GUI更改而容易出错。换句话说,功能仍然按预期工作,但由于UI的更改,测试失败。因此,测试可能变得不可靠。
    理解上下文
    测试可以在任何层,单元,API,服务,GUI自动化。每层用于测试的不同目的。
    单元测试确保代码在类级别工作,编译并且逻辑符合预期。此层的测试比验证更多验证。
    API测试或集成测试确保一组函数和类可以一起工作,数据可以从一个类传递到另一个类。
    另一方面,GUI测试测试用户流程和旅程。通常,我们不会测试UI的功能。这应该在较低层进行。
    UI测试的主要目的是确保整个系统按照一些常见的用户场景和用例工作。在这一层进行测试更多的是验证而不是验证
    在UI级别,我们自动化场景而不是故事。
    不要自动化每个测试
    由于可能有数百万种组合,因此无法实现100%的测试覆盖率。我们总是执行可能的测试子集。同样的原则适用于自动化测试。
    要创建一个自动化脚本,它需要时间和精力,并且旨在“自动化每个测试”,我们需要大量的资源和时间,这在许多情况下是不可能的。

    相反,使用基于风险的方法来确定哪些测试应该自动化。为了从自动化中获得最大价值,只能自动化最重要的业务案例和方案。
    此外,大量自动化测试增加了维护成本并且难以维护。
    另外需要注意的是,并非所有测试都可以自动化。有些测试本质上非常复杂,需要许多下游系统检查,并且可能不一致。在这些情况下,最好将这些检查留给手动测试。
    游客,如果您要查看本帖隐藏内容请回复
    回复

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /3 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2018-8-14 17:24 , Processed in 0.059768 second(s), 24 queries .

    Powered by Discuz! X3.2

    © 2001-2018 Comsenz Inc.

    快速回复 返回顶部 返回列表