我不同意应该这样对测试自动化代码进行“版本化”。应该根据需要进行更改。我希望收到一些反馈。
#1 楼
我相信这是一个非常好的做法，在我公司中，我们做的完全一样，我认为这仅仅是出于历史原因（在我们的情况下），但总的来说，您将尝试使用尽可能少的系统，因此在不久的将来，将测试自动化脚本与相同版本的源代码统一起来可能很有意义。#2 楼
同步源代码和测试代码版本的最大优势是，您可以使用标签（例如，参见Git或SVN）轻松地在VCS中返回时间，从而使您可以快速检出特定源代码和测试版本。我个人是语义版本控制的忠实拥护者，您可以总结如下：进行不兼容的API更改时，请增加以下版本：
MAJOR版本；以向后兼容的方式添加功能时，
MINOR版本；当您进行向后兼容时，请增加PATCH版本。进行向后兼容的错误修复。
可以使用预发布和构建元数据的附加标签作为MAJOR.MINOR.PATCH格式的扩展。源代码版本控制遵循以下规则，使测试代码版本同步更加有意义：例如，如果您进行了不兼容的API更改，因此增加了版本的源代码，您的测试也可能会中断。然后，您将为新的测试界面创建一个修复程序，并增加测试代码的主要版本。
#3 楼
我认为这是一个绝妙的主意。随着版本的发展，有必要进行更改和调整，以便自动化的实际代码也将增加版本的数量。
如果透明对客户而言，它看起来好多了，可以下订单。
#4 楼
停止为测试代码使用单独的分支。测试自动化代码是解决方案的一部分，就像“实际”产品代码一样。测试代码将没有自己的版本。根据定义，它将具有与产品代码相同的版本。无需同步2个版本。这就是我们这样做的方式，我们从来没有以其他方式做到过。#5 楼
随着系统的发展，测试必须以完全相同的方式发展。没有一个测试版本是没有意义的，特别是因为您可能想要测试同一软件的不同版本，例如在添加功能之前/之后或在修复错误之前/之后。测试和系统在测试是两个不断发展的实体，应对这些演变的最佳方法就是让它们相处。
#6 楼
好的，我看到这里的答案100％支持将版本放入我的测试自动化代码中。我听起来会很愚蠢/愚蠢/愚蠢（是的，一个！），但是我只是创建了分支并将测试自动化代码推送到分支。我从来没有在SourceTree中放置任何版本/标签到代码。谁能和be友好地告诉我如何通过SourceTree做到这一点？ （例如，签入一个版本，然后下次签入时使用其他版本）谢谢！
评论
这不应该是答案。提出一个单独的问题，社区将为您提供帮助。
–beatngu13
18年2月8日在21:22
#7 楼
我认为有两种不同的方案：您要为现有产品添加新的自动化方法
，在这种情况下，尝试尝试“应用程序代码的当前版本号” '
您拥有一个完全开发的测试套件
，在这种情况下，使版本号与其他人建议的一致会更加有意义。这些是否是不同的代码库。我通常赞成使用相同的仓库（即使使用不同的语言）。有了这个，我看到需要注意正式版本号的次数就更少了，而更多地关注快速发布的工作软件（带有自动化）。
评论
对我来说，这是个好主意。我个人更喜欢对所有内容进行标记。@YuZhang我不认为OP通常会反对版本控制（包括标记）的想法，仅是与同步源代码和测试代码版本的方案不同。
在测试代码中使用不同版本或完全没有版本有什么好处？如果您无法列出任何好处，为什么您会不同意呢？
@ beatngu13，谢谢，我重新阅读了，你是对的。