我最近在一家公司担任自动化测试员,基本上只有手动测试员(我除外)。短期计划是提出一个好的测试策略,以识别应该自动进行测试的系统和部件。因此,我为解决该问题提出了一个不错的计划,但是我主要担心的是:

公司的领域语言是C#/。NET,也是我最强的编程语言技能是Java。通过用Java编写测试,我会遇到任何类型的问题吗?那会是什么?还是我应该学习C#?这些替代方案的优缺点是什么?

评论

询问团队谁将长期保持结果。重新培训您可能更容易。

如果是单元测试,则显然应该使用易于与系统语言互操作的语言(在这种情况下为C#,F#,VB.NET等)编写它们。如果这些是系统级测试,则用什么语言编写都没关系。但是,如果您对Java的唯一论点是Java是您的“最强编程语言技能”,那么就抛弃它并扩展您的技能吧。 br />

#1 楼

我职业生涯中最大的错误之一是为测试自动化选择了与开发团队不同的编程语言。


编程问题
开发人员在更改应用程序时可能不会运行,也不会维护测试,您将在余生中维护和分析测试结果(例如失败)
开发人员不会在以下情况下添加测试添加功能,因此您将不断落后于

主要是因为它们不喜欢在语言(或框架,工具链等)之间进行上下文切换,因为这很麻烦。我总是用团队的语言编写测试,并让他们尽快维护它们。

C#和Java非常相似,这是Microsoft对Java的回答,因此它具有相似的风格轻松切换。标准库语法有点不同。我会说只是学习C#。

团队是否也在大量使用JavaScript? (大多数归因于前端框架)。这为某些现代测试框架(如赛普拉斯,量角器和伪娘)打开了选项。考虑也请开发团队提供意见!

评论


就语言而言,任何体面的C#开发人员都应该能够理解Java代码。真正的问题出在工具链中。 JDK,IDE(Eclipse?IDEA?),不同的构建文件结构,不同的软件包存储库……不是火箭科学,而是所有这些。并且任何全栈开发人员都已经必须处理.NET和node.js生态系统。但是我不想让第三个人处理:)

– IMil
20年1月9日,0:57

除单元测试外,开发人员通常多久运行,添加和维护一次测试?我以前从未见过这种情况。

–NotThatGuy
20年1月9日在22:34

@NotThatGuy一直在我的团队中。当我进入不是这种情况的团队时,我会针对发现的每个缺陷进行自动测试失败,然后向他们展示如何运行它。指导敏捷测试也有帮助。目前,我在一个政府机构工作,在这里我看到很多测试人员仅定义测试用例,而开发人员则负责所有的自动化和维护。我认为成为一名出色的软件工程师也意味着成为一名优秀的测试人员。

– Niels van Reijmersdal
20年1月10日在8:31

@NotThatGuy Dev在这里,除了单元测试之外还有其他测试吗?

–IllusiveBrian
20 Jan 1 '20 at 2:13

@NotThatGuy哈哈很确定他知道这一点。他在问,除单元测试外,还有哪些其他常见的测试类型?

–MCMastery
20 Jan 1 '20 at 6:42

#2 楼

您可以选择任何语言,而不管开发中使用哪种语言。但是如果您使用与开发中使用的相同的编程语言会更好,在您的情况下,它将是C#/。NET,原因如下:


您可以利用现有的库
开发人员可以为您提供帮助,正如您所说的那样,您将是唯一的自动化人员。
开发人员还可以维护测试/脚本。

除此之外,请尝试根据要自动化的模块或功能找出最适合的自动化工具,并查看这些工具支持的语言。如果可能,请选择支持C#/。NET的自动化工具,以便您的团队也可以轻松地采用它。

评论


+1利用现有代码。在我目前的团队中,我重复使用代码来安排测试设置(例如testdata,users,config)

– Niels van Reijmersdal
20年1月9日,9:01

好点@NielsvanReijmersdal。谢谢!一个人总是可以重用现有代码。

–JAINAM
20年1月9日,9:12

#3 楼

明确学习C#。为什么?


在Selenium测试级别上,它基本上与Java 9相同。带有一些语法糖。开始使用C#不需要花费超过2周的时间。
CI / CD和整个基础设施都已建立了dotnet。如果您不想手动运行此自动化测试,则必须执行以下两种操作之一:配置整个基础结构以使用Java(并学习Java)或学习C#并使用现有的Java。
总是会比一种语言更好地了解两种语言。
假设您需要测试API。您可能已经拥有数据模型,api端点以及用dotnet编写的所有内容。仅将其中的一些内容复制到您的框架中会容易得多。
当您陷入困境时,您会打电话给谁?您的程序员同伴!

我认为学习新的编程语言没有任何不利之处。这只需要一点时间。在那种情况下,我会说的和您在学习Java 6和Java 12之间的区别时所花的钱差不多;)

评论


关于CI / CD的要点。 .Net堆栈可能使用TFS / AzureDevOps。也许您可以集成Java步骤,但是我认为启动dotnet测试会容易得多。

– Niels van Reijmersdal
20 Jan 9 '20 at 9:03

#4 楼

我会说不。我当前的项目使用Java进行测试时,使用Python中的测试进行了质量检查测试。它正在使用黑盒测试。您也可以使用JMeter进行自动测试,这恰好是用Java编写的。

如果要使用TDD创建自动构建测试,则必须知道C#才能将测试集成到源代码中。

如果使用直接进行黑盒测试,则您无需担心语言。由于开发人员和测试人员可能不熟悉堆栈跟踪和调试输出,因此可能会有更多的混乱。

根据您的目标和优先级来选择。

评论


TDD不是白盒测试,您不需要将任何东西集成到源代码中。这取决于您所谈论的测试级别。 TDD在单元测试,系统测试,集成中?除了那个单元测试,其他所有东西通常都是黑盒,即使在TDD中

– PDHide
20年1月9日,14:06



#5 楼

应该从技术和管理角度解决这种情况,需要解决的问题很少:

1。如果团队仅由一个QA组成?

如果团队仅由一个QA负责整个自动化,那么选择与当前团队无关的编程语言将产生依赖性。

如果出现任何不可预见的情况,那么维护框架的工作量将是巨大的。组织需要寻找替代者,并且不能使用内部资源来填补这一职位。

2。开发团队是否编写自动化脚本?

如果该过程涉及开发团队加入以帮助自动化团队,那么建议在开发和测试中使用相同的语言。

但是如果不是这种情况,那么您应该评估在学习一种新语言并减慢该过程方面是否值得付出真正的努力。

3。预期的时间段是多少?

项目是否需要快速发布,那么重点应该是拥有比编程语言更有效的回归测试框架。

4。有没有计划扩展自动化团队?

如果有扩展自动化团队的计划,那么您可以避免“问题1”中的情况。您可以通过雇用更多的Java测试自动化专家并提高内部任何资源的使用技巧来避免产生依赖性。因此,您可以开始研究有效的Java框架,将来的测试工程师可以轻松地对其进行维护。

5。团队的未来计划是什么?

是否有任何计划转移到基于角度的材料开发中,该项目会提出新的建议吗? 。提出更多此类问题,并相应地选择工具和语言。

例如,如果团队正在计划有角度的网站,请尝试使用量角器,赛普拉斯等开发基于javascript的框架,而不是坚持使用c#或Java

#6 楼

如果我可能是恶魔拥护者,我建议您坚持使用Java。如果您是孤独的自动化测试员,则可以使用任何您想使用的东西。

使用java的优点:


不需要Visual Studio许可证
可以在线获得更多对Java的支持
java遇到问题了吗?有可能其他人在线发布了解决方案
大多数Selenium用户使用Java编写代码。然后是JavaScript。然后还有其他所有内容。
一些开发人员可能知道Java(并且比C#更暗地喜欢使用Java)


评论


1)您不需要VS许可证即可编写C#,VSCode是免费的且开源的,并且相当可行,并且,如果您特别反对VS,则可以使用其他替代IDE(例如Rider); 2)根据我的经验,这两种语言都提供了同等的支持,即使在C#中,如果没有更好的支持,因为您不必花20年的时间进行家庭作业; 3)与2完全相同; 4)随领域而变化很大,并且两种语言都受Selenium支持。 5)这是根据您的喜好进行预测的。任何其他开发人员都可以针对任何语言说同样的话。

– Kroltan
20年1月9日,1:11



“如果您是孤独的自动化测试员”。这就是问题的一部分:您应该成为团队的一部分。没有使用的测试没有用处。您需要开发人员一起工作。

–奥勒·阿尔伯斯
20年1月9日,7:50

自动化测试套件并不是“一次编写就忘记了”的工作。虽然OP可能是最初编写它们的人,但是应该期望开发人员在进行更改时对其进行维护。 (除非您要进行与安全相关的事情,这需要开发和测试的独立性;在这种情况下,您需要更多的测试工程师进行交叉检查。)如果这是C#商店,则可以用C#编写。

–格雷厄姆
20年1月9日在15:03

这些优势都不是真正的优势。我怀疑是否有人量化说在线上对Java的支持确实比C#多。我不知道您为什么要使用硒来测试C#后端,而最后一点是可疑的:每次SO开发人员调查始终显示,人们在很大程度上偏爱C#而不是Java。

– Voo
20 Jan 10 '20在9:06



这就是我成为魔鬼拥护者所得到的。我从事自动化测试已有20年了,并且同时使用Java和C#,这取决于对项目最合适的方法。感谢格雷厄姆,“开发人员应该在进行更改时维护它们”,这是一个很好的笑

– ToastMan
20 Jan 10 '20 at 16:31