使用GitHub回购来跟踪测试用例是个好主意吗？
我试图让我的团队标准化一个工具来管理和保存测试用例。目前，我们在Google文档或其他格式(如Confluence )中有一堆文档，目前的主要要求是在一个地方跟踪事情。
我现在强烈考虑GitHub (使用Markdown编写测试用例)，因为我可以启动一个回购，它将具有一个容易记住的URL，并且测试用例/测试计划可以像代码一样被提交/评审。
我想知道这是否是其他人尝试过或目前正在使用的东西。有没有更好的选择？我的主要要求只是有一个地方，跟踪/文档测试用例的产品测试。与诸如JIRA或CI之类的bug系统集成是可选的(但希望如此)
澄清:我说的是手动测试用例/场景，主要是为了文档的目的。例如，典型的测试用例文档看起来可能类似于
Login test:
1. Visit test environment
2. Type in valid username/password
3. Press login
Verify login succeeds
... etc.回答 3
Stack Exchange QA用户
发布于 2015-03-20 19:56:55
我的建议是:把你的文档保存在最容易找到和访问的地方。您的目标应该是尽可能简化那些积极使用上述文档的团队成员，以便他们继续这样做。如果我在你的位置上，我会问那些团队成员同样的问题。
请记住，如果服务或工具需要稍后更改，因为更多的涉众想要访问，那么以后再处理这个问题。找点有用的东西。
在一个地方跟踪，我的意思是，我可以指出一个新的雇用或业务团队中的人到一个URL，他们将能够看到我们的所有测试用例。
几乎没有人希望看到您的测试用例或详细的文档，其中包括您的团队成员。测试的目标是找到信息，这样你提交给团队或项目的报告将是最有价值和最具参考价值的材料。这是来自多年的经验！LOL。这就是为什么现代/精益测试将文档的创建限制在最低限度。
多年来与我一起工作的大多数“业务用户”都不愿意使用GIT，更不用说如何访问GIT了。(您说的是GIT，而不是GitHub，它有一个简单的URL，并且以最易读的方式显示标记文本)。
目前，我们实际上将文件作为Google文档放在Google驱动器上，但缺点主要是在可发现性方面--您需要知道指向文档的链接才能查看它们。
我想你对任何工具/产品都会有同样的问题。在GDocs上存储文件的缺点是有人可能没有Google帐户，在这种情况下，您只需将上述文件公开即可。
如果发现是你的主要问题，那么我建议在你的每日/每周/站站或测试报告中包括链接。
Stack Exchange QA用户
发布于 2015-03-18 07:58:06
Git在管理二进制文件方面不是很好，并且不会帮助您比较非纯文本文档的版本，至少在默认情况下，不添加第三方的diff工具。
Stack Exchange QA用户
发布于 2015-03-18 17:02:28
我不知道测试用例，但我使用GIT将我所有的selenium测试用例保存在(使用Python的IDE和Webdriver )中。当我更新测试时，我可以推送新版本，而GIT允许我很容易地跟踪更改，更重要的是跟踪更改的原因(我是注释的黏贴者，这样下一个人就不必弄清楚为什么某些事情是以特定的方式完成的)。对我来说效果很好。
https://sqa.stackexchange.com/questions/12448
复制相似问题
腾讯云开发者
