如果应用程序是用某种语言编写的,例如Python,Ruby,Clojure等。质量工程师应该使用相同的语言编写测试吗?

这是否应该决定我们可以应用于使用不同语言编写的多个应用程序?

应该考虑哪些因素,以及使用相同语言还是使用不同语言的优缺点?
这与白盒/黑盒测试有什么关系? />

评论

避免技术扩散并确保质量检查工程师和应用工程师使用相同的技能是有利的。

#1 楼

正如Michael所说,使用与应用程序语言相同的语言进行自动化测试的测试团队有很多优势。 Michael遗漏的唯一一点是,当应用程序自动化和测试自动化使用相同的语言时,开发人员可以为测试人员提供自动化代码,从而允许在构建测试(在所有级别)时进行测试人员与开发人员的对编程。 />以多种语言编写的多个应用程序-我会考虑使用一种语言进行自动化测试,因此我可以轻松地重用自己创建的任何帮助程序。

黑盒与白盒测试-测试自动化的语言选择与白/黑盒测试无关:重要的是,您的测试自动化是否正在检查测试的内部逻辑。您正在测试的软件。如果您正在测试外部逻辑,例如选择选项A禁用选项B,则它是黑框。如果要测试内部逻辑,例如用输入值Y调用函数X应该调用函数Z,则它是白框。

#2 楼

我的偏好如下:


主要:实用时使用相同的语言

优点:
-应用程序和应用程序可以共享代码评论测试代码
-自动UI测试编写者可以轻松理解单元测试的内容
-讨论使用相同的术语而无需不断翻译
-重用基础结构部件而无需更改

缺点:
-测试人员可能不具备应用程序工程师所使用语言的技能
-测试人员可能会失去独立性
-测试人员可能会在应用程序代码方面思考更多,而在用户体验方面则较少


中学:使用现有的测试语言专业知识

-自动化开发人员可以应用现有的专业知识和知识

缺点:
-代码审查更难
-开发人员和测试人员之间的差距更容易
-应用程序和测试代码库必须保留同步


第三级:在整个组织中使用默认的硒语言绑定

优势:
-自动化开发人员可以应用现有的专业知识和知识
-重用技术和实践
-自动化工程师可以重用代码
-易于开发和共享等待技术

劣势:
-当应用程序代码是另一种语言

评论


从小学到小学,我只同意来自优势的第一项,从中学到中学,只有相同的,只有优势的部分相同,而从其他方面来看,我认为所有其他项目似乎都不那么强大。

–劳达
17年8月17日在19:47

我在原始问题中没有看到Selenium

–Rsf
17年8月18日在18:42

如果QA团队在软件设计和编程方面具有“初级”水平的技能,而Dev团队是“专家”,则有助于使用开发人员和质量保证人员都熟悉的语言。但是,这不应该是选择语言的唯一理由。在这种情况下,开发人员可以纠正QA代码中的设计缺陷,并使测试更易于编写,维护和更可靠。

– MasterJoe
20 Mar 24 '18:13



#3 楼

防御的第一级是单元测试,并且按照定义使用您的应用程序语言编写。

对于QA和自动集成/ GUI / API / e2e测试,您希望使用最高效的语言。发现,因为(让我们面对现实)测试不是可计费代码(即使没有测试也无法生成可靠的可计费代码)。我发现在使用动态类型的语言(例如Python)时,我的工作效率更高。(我有数十年使用十多种不同语言的经验,因此我有权在这里发表意见)。

如果该语言针对生产力进行了优化,并且使用QA / e2e / AutoTest开发人员确实可以提高生产力,则使用与应用程序相同的语言是有好处的。

OTOH是针对性能进行了优化的应用程序语言(C,C ++和其他静态类型的语言),使用Python之类的语言进行自动e2e测试可能有意义,以保持生产力。或对于Angular应用,您将在前端使用JavaScript,但在后端可能使用其他语言。因此,使用JS(而不是后端语言)编写e2e AT是有意义的。

PS-AT =自动化测试。

评论


“防御的第一级是单元测试,根据定义,它们是用您的应用程序语言编写的。” –我知道几个使用Ruby,Scala或Clojure进行单元测试的Java项目。 (许多项目使用基于Java的内部DSL。)我还知道至少有一个用Assembly + C编写的嵌入式项目,该项目使用用Ruby编写的自开发测试和模拟框架在Ruby中编写单元测试。

–Jörg W Mittag
17年8月17日在19:24

有趣。我说了很多话,即使为自己的代码编写单元测试也不是很好。 Java与Scala或Clojure有所不同,IIRC它们都使用JVM,因此可以相互调用。对于嵌入式项目,我将使用Forth,它足够灵活以编写核心代码和单元测试(以我的经验,它比汇编更紧凑)

–Peter M.-代表莫妮卡(Monica)
17年8月17日在20:44

#4 楼

何时使用与应用程序使用的语言相同的语言:


您具有足够的技术知识来了解该语言
您已经/为此语言选择了稳定的自动化框架
dev可以帮助编写自动化测试
如果需要,dev可以帮助编写框架的其他库

为什么不选择与应用程序使用相同语言的原因:


编程语言不是太广为人知,太老或太新
您在开发团队中有技能,这对qa
开发代码审查没有帮助,如果他们不知道框架,那些方法做什么/返回什么以及应该对此进行何种验证
dev可以理解代码审查,如果测试的书面性不好并且不能高效/可维护,将无济于事。
来自开发人员的代码,这种情况很少发生或根本不会发生,在最坏的情况下,开发人员可以在需要时帮助推进,但是在日志运行中却没有
,您没有足够的熟练的技术人员在这种语言中,如果数量很少,您可能会得到一些永远无法重用和/或维护的代码

我们的时代。
应用程序是用多种语言编写的,而这些语言不应在选择正确的工具和正确的语言时会影响您。

您需要选择一些可用于自动化的工具,并选择使用质量检查团队拥有的一种语言,并提供其余您需要的东西(报告等)

如果您希望一切顺利进行,请:


创建一个编码标准并使用它
/>教育您的团队了解如何使用该工具
始终进行改进,确保尽可能多地重用
使用设计模式并且您的框架中具有强大的体系结构
清理代码,每周进行一次自动化会议
让负责人,例如框架/自动化所有者
代码审查非常重要,请确保有足够的人在进行审查,并请他们中的关键人员,例如自动化所有者或高级自动化工程师


计划>准备>执行>完美


#5 楼

没有特定于应用程序的特定语言来编写测试。我曾经在应用程序是.NET的地方工作过-我的Java自动化框架;应用程序是Java-我的自动化框架是基于.JS的。根据我的经验,选择编程语言进行E2E测试确实取决于以下几个问题:


我最喜欢哪种编程语言?
我被强制使用由于管理/领导层的选择,在我的工作中使用某些特定的编程语言? (开源VS付费工具)
如果遇到任何障碍,我在测试脚本编写过程中需要多少开发团队帮助?
我是否可以建议哪种编程语言最适合E2E测试? (良好的在线支持,庞大的用户社区等)


#6 楼

关于自动化测试,要考虑很多事情。我们在谈论什么样的测试?您是否要编写端到端测试,单元测试?您是在开发移动应用程序还是在Web应用程序上(也许两者都有)?

此外,您是否在自动化方面与其他QA一起工作,还是一个人,您是否有良好的编程经验?

如果您不熟悉特定的软件语言也许您可以使用与测试语言相同的语言进行测试(如果可能),因此如果您需要帮助或一些编程技巧,则可能会更好。

但是,如果您的公司没有为自动化测试指定任何语言,请使用您喜欢的语言。您不必为唯一要做的事情而烦恼。

#7 楼

这取决于谁(人类)的受众进行测试。通常,我会使用两个。

从总体上看,让您和您的客户确信您已了解需求的最佳方法是进行
测试,这些测试可以作为每个用户的需求
都尽可能地接近英语散文。

一个例子是在90年代,我记下了“测试笔记”(这使我的销售老板花了大约80个小时进行所有检查),并编写了一个测试框架,该框架可以理解一组简化的(合理化的)指令,这些指令的读法类似于英语,因此他在其中写了“单击Such and Such按钮”和“在Author字段中输入'some text'”这就是测试脚本所说的。

现在,您将使用https://cucumber.io/之类的东西来测试用其他语言编写的系统。

测试仅由技术人员进行有关具体细节
应以技术团队最容易写和最清晰阅读的方式写成
(例如,如果客户要求排序列表,他们通常不会在意它进行排序,只是排序而已)。您离单元测试越近,用相同的语言编写测试就越有意义。

xUnit测试框架是使用多种语言进行单元测试的流行框架之一。

#8 楼

我认为遗漏的一个方面是确保以与平台无关的语言和方式编写接口和通讯测试的重要性。

我最近遇到一个案例,一个与我们的主应用程序通信的实用程序的编写者在通信测试失败时抱怨。这些测试是使用struct库以Python编写的,该库允许您指定结构,包括特定的长度,字节顺序和打包。

他们认为那里的协议没有什么问题,因为它们使用与主应用程序相同的.h文件,但没有考虑到它们是使用Visual Studio开发的用于MS-Windows目标的事实,并且他们需要能够与使用qcc为qnx所构建的主应用程序进行通信一个大型的endian平台。

如果测试套件是用相同的语言编写的,那么以后就会发现这个问题。

因此,任何与其他平台进行通信的东西您需要一种独立的,通常是不同的语言。

#9 楼

如果可能的话。这样做的主要原因是因为上下文切换非常昂贵。如果您必须使用多种语言(甚至可能使用多种IDE),那么对于一项功能,您的团队可能会在工具和语言之间来回切换。当然,如果其中一种语言仅偶尔使用一次,则每次切换都将花费时间。

精通一种编程语言很困难,而精通多种语言则更难。切换思维所需要的越少越好。同样,您可能无法完全使用第二种语言的功能,而创建快捷方式只是为了使其工作并完成使用。

有充分的理由为项目引入额外的工具或语言,只需确保您权衡了上下文切换,学习曲线,学习的动机(主要是从开发人员那里)的成本,并为新的-

与开发人员一起工作:

由于测试工程师通常是次要的编码之神,因此能够利用您的主要开发人员来协助开发人员进行良好的编码实践在我的书中必须测试自动化。因此,请确保您将测试自动化语言与它们一起选择。

如果您希望开发人员在添加新功能时运行,维护和扩展测试,我会非常谨慎地在项目中引入额外的语言作为测试人员。只需确保以完整的团队方法介绍测试工具即可。

评论


为此+1,因为“测试工程师通常是较少的编码之神”。以我的经验,这通常是正确的。我也是一个小编码员。

– MasterJoe
20 Mar 24 '20 at 18:32