你的钱在哪里迷失在测试

编辑器的请注意:这篇文章最初发表在stickyminds.comTechWell社区。

很明显,测试成本钱。但释放一个严重的bug和痛苦随后多次测试会疼痛通常成本,没有考虑到市场营销和形象受损。

测试是必须的,没有办法,然而,人们倾向于想要更有效率和更便宜的比以前。

在第一个迭代,测试从业务测试人员转移到海外。然后测试近岸,敏捷团队中,现在我看到测试人员与开发人员一起。教训:它可以节省我的钱,所以让测试尽可能所以我们可以更迅速地对变化作出反应。

一方面,公司要灵活,要快通过DevOps,缩短他们的发布周期,尽快去市场,整合所有的测试在CI管道,和足够通用测试多个环境,是否真实或模拟。但另一方面,这些公司都不愿意把钱花在工具和服务质量的概述和最高的覆盖可能的风险。

什么是最新企业云迁移的好处和完全重建系统如果不检查所有进程正在像以前那样吗?如果你花了时间和金钱在测试用例覆盖只有一半你的风险,但你不知道,因为没有人认为检查测试覆盖率?这些问题可能会告诉另一个故事。

我们需要更多考虑节约成本在我们的测试用例和其结构本身。

节省测试用例

作为系统随时间变化的,我们需要采取稳定的测试用例,确保他们执行。如果你改变新控制技术可以说的东西,改变了控制,新页面,新功能,新环境变量,etc.-you需要将它添加到您的测试用例。

采用和维护把大部分的钱花在测试,但有简单的改变可以减少这些努力。

例如,它可以节省很多的成本,如果你有技术对象分开,集中,使调整的可能性只有一个对象来保持所有连接测试。如果你有一个登录窗口控件的用户名、密码和登录按钮,一个对象,你可以称它为一个模块,或定义所有应用程序控件的集合在一起,像一个基类,和重用他们。

这个方法是一样的面向对象编程,将创建可重用的构件。你可以把一个页面,列出所有的控制页面,地图每一个与你的测试用例,和重用这些对象。技术的变化将不影响你的测试,他们更稳定,和维护测试用例可以用一个改变,因为你只需要修改一个模块包含更改的控制。

目前典型的测试是通过编写代码并使用基于代码框架,和大部分的钱花在维护的技术变化,有一个新版本的功能。应用面向对象技术方面,你会节约成本,可以投入到创新发展。

技术问题仍然是主要问题打破一个测试在当前设置,但是测试数据呢?我看到多个客户反复使用相同的测试数据。他们创建一个新的测试用例来运行另一组数据。

您可以更改一个数据库和一个有条不紊的让数据从测试用例分离,甚至部分或代码的工具。阅读准备文件从业务将是另一个有效的选择来解决这个问题。立即的好处将会改变您的测试游戏!

从现在起,业务用户可以改变自己测试的数据,而不让测试人员知道。他们可以添加更多的数据集或删除过时的。SQL查询的动态变化,根据输入数据,甚至掩盖了生产数据的使用是可能的,因为它只影响数据库中的数据,拉的查询。

业务用户使用数据也获得的知识的测试,他们可以很容易地应对变化的需求和添加功能,如果他们已经与一个测试用例。可以使用随机测试数据的方法,查询总是返回一个随机数据集,必须符合一定的标准定义。事实上,这是接近比测试一个生产环境中,根据不同的数据集。

你已经看到这是如何影响你的成本吗?业务很容易找到错误,因为他们知道使用数据和可以复制失败。随机测试数据增加了测试覆盖率和可以从生产数据,这已经就需要匿名。风险覆盖率随这个蒙面的生产数据,因为你测试用户实际使用。只要用户倾向于特定功能,你可以在测试环境中测试它与正确的趋势数据。

此外,通过应用程序工作流是一种维护缩小到最小和省钱。将是多么容易生成一个数据驱动测试用例结构中的数据通过使用我上面描述的吗?

创建块预定义的测试步骤和重用对象。让他们尽可能通用和依赖于数据您使用简单的条件。只要工作流程发生变化,你又有一个单一的联系点,添加新的变体您的测试用例将会容易。一个变化将会影响您所有的测试用例,与所有的消耗数据为一个特定的使用和需求。

为一个全球业务,我和我的团队为他们改变测试完全通过聚类测试用例在一起用一个数据驱动的方法和扩展。条件把测试用例的行为方式,建立了基于如何行为在被测系统在执行期间。想象材料标记为不存在于你的系统,并自动测试用例知道它需要验证错误消息而不是成功,只要输入数据。如果你需要检查另一个错误,在另一个系统中,你只要把块和添加数据依赖结构化测试用例。

另一个选择是减少测试用例小零碎东西,看看他们是真正的测试用例的顺序。您必须定义一个测试用例列表部分的整体。新创建的数据可以通过动态数据库和预定义的转发状态。这种方法可能会导致多个重播的几个数据生成测试用例,但它会增加测试用例模块的可重用性,使单点在您的测试组合变化和减少重复。

不再需要花这么多钱在创建新的测试用例。测试人员仅仅把测试用例从预定义的块和必须确保数据流。只需要创建全新的特性,作为一种新的结构块,然后添加到您的测试步骤库。当另一个测试用例通过你的新特性(或应用程序在中间),新的块将把您的测试用例,每当它改变,只有一个单一的需要改变在这个特定的块。

节省测试结构

远离现在的测试用例本身,还可以节省大量的钱在您的测试的计划和初始设置阶段。

想象更快将有预先测试数据创建用户界面,而不是手动创建它们或者基于ui测试用例。数据可以被提取到一个数据库,并被测试用例,无论他们是与一个特定的情况或选择特定的标准。

如果你运行一个microservices环境,可以自动运行API调用,无人值守和并行设置测试环境准备和准备自动化测试用例的运行。创建非ui测试用例的创建或获取测试数据,而且,根据您的设置,您可以将其保存在数据库或直接调用的服务在您的测试。

服务虚拟化也可以节省你的成本在硬件或第三方供应商,而向左移动您的测试,增加测试环境正常运行时间。检查依赖关系在您的测试过程的早期避免停机时间,并设置替代品不稳定的应用程序,功能,或web服务。标准化工具和方法来降低成本在增加,并采用简单的报告不需要集成多个工具。

节约成本的测试方法有很多,但考虑你想做什么预先将最好的行动,而不是改变后更好的性能。清晰的结构和战略测试,支持通过一个对象或基于模型的方法,应该导致成功。

你会省钱在测试过程中与工件重复使用数据驱动测试步骤块和通用技术元素由掩盖了生产数据。技术深度、工作流和测试数据需要分离和采用,使单点变化对每个对象在你的测试。检查工具标准化,利用内置的框架可能已经解决问题和满足您的需要。

三思而后行,认为大,想节省成本的端到端,并预先构建一个框架,是可靠的和可重用的。