我强烈考虑GitHub（使用Markdown编写）测试用例），因为我可以启动一个易于记忆的URL，并且测试用例/测试计划可以像代码一样提交/查看。
我想知道这是否是其他人尝试或目前使用的东西。有更好的选择吗？我的主要要求只是为测试的产品提供一个跟踪/记录测试用例的地方。与JIRA之类的错误系统或与CI的集成是可选的（但希望如此）。
说明：
我主要是出于文档目的谈论手动测试用例/场景。即一个典型的测试用例文档可能看起来像
Login test:
1. Visit test environment
2. Type in valid username/password
3. Press login
Verify login succeeds
... etc.
#1 楼
我的建议：将文档存储在最容易找到和访问的地方。您的目标应该是使积极使用上述文档的团队成员尽可能简单，以便他们继续使用。如果我在您的位置，我会向这些团队成员提出同样的问题。请记住，如果服务或工具需要稍后更改，因为更多的涉众想要访问，则稍后再处理该问题。找到现在可以使用的东西。
通过在一个地方进行跟踪，我的意思是我可以将新员工或业务团队中的某个人员指向一个URL，他们将可以查看我们的所有测试用例。
几乎没有人希望看到您的测试用例或详细文档，其中包括您的团队成员。测试的目的是查找信息，以便您给团队或项目的报告将是最有价值和可参考的材料。这来自多年的经验！大声笑。这就是为什么现代/精益测试将文档的创建限制在最低限度的原因。
我多年来与之合作的大多数“业务用户”都不喜欢浏览GIT存储库，更不用说知道如何访问它了。 （您说的是GIT仓库，而不是GitHub，它有一个简单的URL并以一种易于阅读的方式显示降价文本）。
目前，我们实际上将文件作为Google文档放置在Google驱动器上，但缺点是主要围绕可发现性-您需要知道指向文档的链接才能查看它们。
我认为您在使用任何工具/产品时都会遇到相同的问题。在GDocs上存储内容的不利之处是可能没有人拥有Google帐户，在这种情况下，您只需要公开所述文件即可。
如果可发现性是您的主要问题，那么我建议您在每天/每周/站起来或测试报告中添加链接。
评论
感谢您的输入！我的意思是GitHub与Markdown btw。我会澄清
– dming
15年3月20日在20:07
强调这一点：“追踪到一个地方”。请勿将所有无关项目的所有测试计划都放在一个存储库中。根据我的经验，项目会死掉，并被替换，并且您的v1测试计划需要针对v2进行更新，然后您执行此操作，但随后得知v1将继续使用一年，因此现在您的测试计划中有很多“条件”文本，你一年都不会明白。然后，您的文档区域将成为垃圾箱，并且您是唯一可以找到或理解事物的人。
–斯科特·普里夫（Scott Prive）
19年2月28日在11:38
重新阅读我上面的评论，我也不会将测试计划放到WITH WITH代码项目中，因为您的活动只会使他们的活动蒙上阴影（请考虑标记差异）。我将创建一个名为“ projectname_testplans”的新存储库。确保提前计划随着项目的发展如何发展文档。分支是执行此操作的一种方法，并且使文档易于查找。可能使用与主要项目更改（v1，v2，special_customer_release等）相同的字符串来命名文档分支
–斯科特·普里夫（Scott Prive）
19年2月28日在11:43
尽管需要花费一些时间来理解和开始使用它，但值得研究的是Robot Framework，但是它记录“测试为代码”的方式是相当一致的。如果您发现Markdown格式太基本了，那么还会有“ mkdocs”。无论如何，“在所有位置进行跟踪”都是“是”，只是不要对所有内容进行分组。而且，如果您遵循一种模式，即人们可以使用他们用来查找项目代码的相同模式来查找文档，那么您可能不需要一处跟踪所有内容。
–斯科特·普里夫（Scott Prive）
19年2月28日在11:47
...尽管您可能需要某种自动生成的索引。我可以预见，一些技术水平较低的人阅读GH markdown很好，但是却忘记在浏览器中选择适当的分支链接，因此只阅读文档的“默认分支”（错误）版本。
–斯科特·普里夫（Scott Prive）
19-2-28在11:48
#2 楼
Git在管理二进制文件方面不是很出色，并且至少在默认情况下不向其添加第3方差异工具时，至少在默认情况下不会帮助您比较非纯文本文档的版本。评论
是的，我正在谈论的测试用例只是手动测试用例，将以文本/ Markdown编写
– dming
15年3月18日在17:59
#3 楼
我不知道测试用例，但是我使用GIT存储库将所有硒测试用例保存在（使用Python的IDE和Webdriver）中。更新测试时，我可以推送新版本，而GIT允许我跟踪更改容易且更重要的是，为什么要进行更改（我是个评论家，所以下一个人不必弄清楚为什么要以某种特定方式进行操作）。对我来说很好。评论
我做同样的事情。这就是GIT设计用于=存储代码的目的。
–克里斯·肯斯特（Chris Kenst）
15年3月20日在19:33
Markdown文档也非常适合存储在Git中：Github默认情况下可以很好地呈现它们
– Alex Kovshovik
'18 Sep 19'在16:07
我不会说“ GIT专为=存储代码而设计”，因为这很容易暗示它并非旨在存储文档。 GitHub非常适合基于文本的文档，包括标记类型。
–斯科特·普里夫（Scott Prive）
19年2月28日在11:33
@ScottPrive是的，很好。我希望我可以编辑我的声明。
–克里斯·肯斯特（Chris Kenst）
20年6月4日在16:42
评论
您的解决方案的透明度如何？他们能够掌握Git吗？您的要求不明确...“在一处跟踪”是什么意思？如果您只是希望将所有测试用例都放在一个位置，则可以通过易于沟通的简单策略很好地运行Google文档和融合。 Git为您提供版本控制，听起来好像不是必需的。指标如何？您需要一个系统来告诉您哪些测试用例已经运行，哪些没有运行...测试用例通过或失败的频率如何？如果没有，请保持简单...网络共享中的文本文件。
通过在一个地方进行跟踪，我的意思是我可以将新员工或业务团队中的某人指向一个URL，他们将能够看到我们所有的测试用例。目前，我们实际上将文件作为Google文档放置在Google云端硬盘上，但缺点主要在于可发现性-您需要知道指向文档的链接才能查看它们
如果您使用Git，则需要知道Git网址...
我现在正在思考这是一个很好的问题。到目前为止，在Github存储库中跟踪测试用例对我来说听起来很不错：1）测试用例历史； 2）降价； 3）通过拉取请求流程审查测试用例；很多好处，而且很便宜！其他测试用例管理解决方案过于昂贵-每位用户每月$ 10- $ 15。不会为我们工作...