寻找使用电子表格进行测试用例管理的出色示例

#1 楼

我没有任何示例，但是我可以描述一种经验，尽管更多的是关于书面测试用例，而不是关于使用Excel。

当我开始上一份工作时，没有写下测试用例。此外，IT部门对质量检查团队公开表示敌视。要求将服务器作为测试用例存储库不是一个入门者。作为中间步骤，我选择了产品的一个子集，并将测试用例放在共享的Excel电子表格中。我认为有四列：测试用例的描述，分配给它的测试人员，通过/失败状态和自由格式的注释（例如，有关错误ID的注释）。

测试用例是简单的声明性声明，而不是分步说明，例如“每个字段都遵循其最小和最大字段长度”或“字段X是必填字段。”

每个版本，随着产品的更改，某些测试用例也需要进行修改。我想保留旧的测试结果用于历史目的，因此我们为每个发行版制作了电子表格的新副本。

我认为我们遵循了一些发行版的做法。我们取得的成功有限。一方面，测试人员喜欢写下一些东西，并且喜欢明确指出谁在测试什么。另一方面，团队中的许多人都不习惯编写测试用例-尽管它们重叠，但是编写与实际测试是不同的技能。

在发布了几个版本之后，我们设法让IT部门在服务器上安装Mediawiki，因此我们转而在此处记录测试用例。我们返回到个人通讯或电子邮件，以分配测试人员来测试案例并报告状态。 （我们使用Bugzilla进行错误跟踪，但是我们没有正式的方法来声明测试了哪些测试用例，还有哪些要做。）几年前我离开了那份工作。据我了解，他们仍然使用我的测试自动化框架，但是他们完全停止使用书面测试用例。我认为测试用例已经过时，并且团队中没有人对写作感兴趣。

#2 楼

我为名为Gmail的项目制作了此示例电子表格（在此处下载）。



一些评论：



/>测试用例ID：使用此值可将每个错误与一个或多个测试用例ID关联。

测试用例描述：它们可能彼此独立或类似


运行测试用例ID 4
单击“提交”


状态栏（带有颜色的栏）非常不言自明。 “失败”状态应包括指向检测到的问题的链接。失败的测试用例应与Bugtracker中的一个问题和唯一一个问题相关联。否则，很难进行回归测试。

对于每次测试，左侧都会添加一列。最左边的列应该是最近的测试运行。 （可选）您可以包含受测试的修订。


优点


很容易在电子邮件中显示结果，只需复制并粘贴电子表格和最新的测试运行。另外，由于使用了颜色，因此很容易看到测试运行的整体状态。
很容易添加更多测试用例。


缺点


很难知道之前是否已经编写过一个测试用例，即是否不编写重复的测试用例。

#3 楼

作为顾问，我经常被派往没有测试用例管理工具的客户。这可能是一个短暂的合同，期限不长，不如引入测试用例管理工具并教会用户如何使用该软件所需的时间。

使用Excel，我可以格式化基本测试用例模板，供我自己或客户在几分钟之内使用。然后将其用于跟踪对某个功能进行过测试的内容（测试步骤或场景），并监视测试是否通过。如果测试失败，则在“注释”列中概述该错误。修复错误后，重新运行的结果记录在Excel工作簿的第二张工作表中。

最后，可以将电子表格放置在网络上以供参考，附加到电子邮件或打印。

根据我的经验，这种方法有助于客户对测试的价值充满信心，并为他们提供了考虑使用哪种工具的空间。

最后，我对团队现在正在记录他们的测试，他们的结果以及比电子邮件更正式的错误（通常是这样）的知识感到欣慰。这使测试过程具有可重复性，可追溯性和可调整性，同时还引入了共同的参考点。

#4 楼

最近，我的老板要求我找到一个测试用例管理器来保存我们的回归套件。经过广泛的研究，我发现TestLodge在可负担性和UI交互方面是最好的。我们最初使用的是TeStuff，但与价格相比，这简直就是昂贵。我并不是所有测试过的基于Web的平台的忠实拥护者，但是TestLodge到目前为止是最好的。

我真正喜欢并为您推荐的一件事是Google Docs集成。我将所有高优先级回归测试导出到excel文档中，并将其拉到共享的Google文档中。最好的部分是现在我们将它们存储在云上，并且可以被允许的任何团队成员访问，这对我们来说是一个巨大的好处。然后将它们导入TestLodge并根据需要将它们分配给团队的每个成员。
希望这会有所帮助:)。

#5 楼

在我的第一份工作中，我们广泛使用了Excel（并且在一些地方使用了Excel）。我认为这不是一个可怕的工具，因为我看到人们惊人而有效地使用它，而这取决于主要目的。太多的非工程公司中，有大量的人从事非编程质量保证工作，对于他们来说，将测试用例与脚本等集成起来可能不是最重要的功能。

（我曾经作为，不建议在其他工具上使用excel）测试计划和案例


表格2-测试用例：第一列的TC标题为粗体，后跟步骤。第二列有预期结果，第三列-实际结果，第四列-优先级，第五列-通过/失败，第六列-评论。

我和一个使用excel宏和公式的人一起工作，他非常好地制定了期望的结果输入数据的结果。在进行手动测试时，他只需在相应列中输入输入值和实际值即可。他的电子表格的最后一张纸上有“测试用例”，如果期望值与实际值匹配，则将设置为“通过”。

#6 楼

在我目前的公司中，我们使用excel来跟踪我们的测试。我们有一个质量检查清单临时电子表格，该电子表格包含：


功能清单-需求清单。主要关注应用程序是否按预期工作并且适合目的和用途（正面测试）

测试方案清单-测试人员在测试应用程序时记录的测试方案列表。这些测试方案可以是详细的或高级的，这都取决于测试人员，并且测试的类型可以从否定，探索性到性能测试不等。


我们正忙于研究不同的测试管理工具来代替excel电子表格，但在过去的几年中，它们一直在我们公司取得了相对良好的成功。

#7 楼

在我的项目中，我们使用excel电子表格进行测试用例的执行和管理。测试完成后，我们将使用excel附加组件在Quality Center上导入相同的文件（我知道这是在浪费精力）。

Excel工作表具有特定的格式，即Sheet1-版本控制，带有步骤的Sheet2-测试方案，Sheet3-参考等。如果您正在寻找示例模板，请告诉我。

#8 楼

一个适合您的技术和示例。我们的开发团队和我有两种交流错误和错误修复的方法：电子邮件和Excel。如果是大范围的错误或功能，或者是安装版本，请使用excel。

就大范围的错误或功能而言，我的excel电子表格至少包含3个标签。首先是受影响的版本和对象，以及开发人员告诉我的所有测试记录。第二个是我的测试场景，包括暂存数据，步骤，预期结果和实际结果。该文件按版本和平台存储，因此可能会变得很大。第3个标签包含我们所谓的“问题列表”。 （眨眼眨动一下，又称“错误列表”）在“问题列表”上，我为问题编号，提供说明，文档的超链接和“状态”列（打开/关闭/他说/她说）。通常还会有一个“注释”专栏，因为开发人员有时会为我分解具体修复的对象或其设计意图的设计逻辑。

当我在这里开始工作时，没有一个这被跟踪。我停止了。在澄清了他们和客户的期望之后（一开始并不受欢迎，但是我是牛头犬），然后我通常在Word .doc文件中（婴儿步骤，亲朋好友）提供了测试步骤和结果。慢慢地，我的系统在我们的团队中成长。我之前已经在SQA上说过，然后再说一遍：做最适合您团队的事情。对您的团队有效的方法对我的无效，反之亦然。灵活性是关键！

有一天，一个叫我“ Macguyver”的开发人员-我没看电视节目，不得不问别人，他只是侮辱我还是什么？幸好我发现这是一种赞美。

我为与开发人员的融洽关系并为保护它而付出的努力感到自豪。

最后，我最为我的.xls文件感到骄傲的是：我竞选了该想法并将其出售给管理层和开发人员，以将全面的.xls上传到SharePoint，在SharePoint中，我们都使用问题的最新，最大更新来更新.xls文件。有用;他们全都为此。最初，他们不得不通过查看我的测试场景而推迟了工作，但我很快学会了使其开放到问题列表中以节省时间。另外，为节省时间，当一个问题被确认为固定或以其他方式解决时，如果存在>说10个问题，我将其移至名为“已解决问题列表”的标签，从而消除了已解决的问题，因此开发人员可以专注于未解决的问题。

我喜欢SharePoint上的文件的一件事是能够在更新文件时接收电子邮件。因此，他们一旦对其进行更新，就会收到一封电子邮件。然后，我检查是否发现了一个有效的错误，这是设计错误，还是我误解了该功能（几乎没有提供任何要求）....有时我完全错了。

您提到使用Excel进行测试计划。多年前，我曾尝试过一个Excel测试计划，该计划受到了我的经理的欢迎，但并没有进一步发展。我们严格将Excel用于测试方案，对象/版本参考和错误列表。

最后，当我第一次来这里工作时，我建立了一种使用Excel存储测试用例的实践（他们是99％不存在）。如果需要，我有数百个（如果不是数千个）Excel测试用例示例。但是，由于我们的质量检查人员从3人增加到1人，我不再有时间创建和维护测试用例。

#9 楼

尽管Excel已经存在了很长时间，但其惊人的简单性和易用性仍然使其成为一个很好的测试管理工具。而且，由于测试套件始终是手动测试和自动测试的组合，因此您不可避免地需要手动管理测试。此外，基于云的电子表格使共享访问成为可能，以便可以轻松更新测试套件记录。使用电子表格可以轻松维护多个环境的测试记录。

#10 楼

使用Excel来管理测试用例确实存在很多问题，但是您可以做一些事情来使生活变得更轻松。


使用协作工具-代替使用Excel，如何使用关于诸如Google电子表格之类的工具。这样，您就可以在线工作，还可以允许多个人同时使用该工具并进行编辑。
维护模板-确保您清楚地标记哪个扩展名是主要模板，并在开始新模板时始终复制该模板测试周期，并始终确保对此主副本进行任何编辑。
共享-确保每个人都可以访问文件的存储位置，以防止人们进行多个副本。

最终，您会发现这有点痛苦，您可以做的最好的事情就是尝试向团队解释使用专用工具的好处。 （也许建议为一个项目拖着一个工具，看看它们如何进行）

#11 楼

作为开发人员，我的回答会很讽刺。如果您仍在使用Excel，请不要亲自使用它：)


如果您仍在使用Excel，那么现在是更新质量检查工具的正确时机吗？


如果您听说过敏捷宣言和敏捷软件开发，那么您可能会知道，由于有了这些方法，质量保险就成为了开发的一部分，而且功能也不相同。当您使用TDD，BDD或任何测试优先方法时，您需要在编码之前先进行测试，因此显然Excel Spreadsheet不是正确的工具。您通常需要用于敏捷开发的工具

如果您没有意识到，Excel是90年代的老工具，它是电子表格，而不是管理工具。如果您需要管理工具，建议您寻找一个管理工具。如果项目管理/ JIRA这样的报告工具不足以满足您的质量检查需求，我热烈建议您与一些测试管理解决方案提供商联系。


http：// www .qasymphony.com / qtest.html
http://www.practitest.com/
http://www.testuff.com/
http://www.qmetry.com/

例如，如果获得每月订阅，Testuff每月将花费27 $，拥有难以管理的Excel电子表格来处理您的质量检查将使您花费更多：)