问题标签 [manual-testing]

作为一名学生，我刚刚获得了作为手动测试员的第一份合作工作。我知道它和编码员一样聪明且要求很高，但我不禁反过来思考。我喜欢成为一名编码员，但这是我的第一份工作。因此，我想请您就如何充分利用手动黑盒测试工作提供任何建议，即如何使用它来提高我的编码技能。非常感谢。

As a test engineer, I often engage in exploratory testing. When I encounter a bug, it is not always immediately clear which steps led to the problem. So, obviously, I have to find the required steps to reproduce the problem. Depending on the situation, this can take a large amount of time.

What would be really helpful is a logging tool that keeps track of mouse and keyboard actions and possibly also stores the properties of components that have been clicked (the AUT is written in Java).

I could simply not find a suitable tool, but maybe my search approach is erroneous.

Could anyone point me to the right direction?

我对其他人如何组织他们的测试脚本很感兴趣，或者在他们工作过的任何地方都看到过很好的测试脚本。此外，这些测试脚本的详细程度如何。这特别涉及为手动测试创建的测试脚本，而不是为任何自动化测试目的创建的测试脚本。

我看到的问题是，测试脚本有很多复杂性，但没有受益于组织复杂或大型代码库所使用的原则。您需要能够指定一段代码应该做什么，但又不会让某人在阅读它时感到无聊至死。

此外，您如何布局测试脚本，我不热衷于创建适合由数据输入类型运行的完全指定的脚本，因为这不是我们拥有的团队并且维护它们的开销似乎太高了。此外，在我看来，如此详细地指定流程可以免除实际进行产品质量测试的人的责任。人们是否指定每个按钮单击和要输入的值？如果不是，则指定详细程度。

谁能解释一下 DST、Wanem 等不同的测试是什么。

在工作中，我们目前使用 Trac 来管理我们的测试用例。但是，我们有不少 TC 列在测试计划 wiki 页面而不是票证上。

我的经理最近对更好地记录手动测试的结果产生了兴趣。虽然这是一个崇高的目标，并且 QA 团队中的一些人对这个想法非常热衷，但我实际上觉得如果执行不正确，这样一个系统的开销可能是灾难性的。事实上，我能想到的唯一合理的非 Trac 集成解决方案只是一个简单的任务管理器，我们可以在其中存储和管理更随意的结果，例如“X 在 Env blah 上运行了组件 Y，并且存在这些问题”。我认为从 wiki 移植几个 TC 编号和内容需要很长时间，并且某种系统，如“X 在 Y 时验证 TC 23423432 并且它正在通过”仅适用于有那么多测试用例（以及一个小团队）。

我见过一些用于 Trac 的插件，它们允许您创建测试计划等并报告结果 - 但没有什么令人兴奋的。有没有人有使用这些工具的经验？与 trac 集成将大大减少开销，但我们仍然存在并非每个 TC 都作为票证提交的问题，我们必须解决这个问题。

你对这样的项目有什么建议？你有过类似的情况吗？您的意见将不胜感激，因为我不想成为团队中唯一的反对者并且看起来很懒惰，因为我认为在如此小的团队中过度组织手动测试将是有害的。

任何人都可以发布好的测试脚本模板（MSExcel）吗？-- 感谢软件测试项目

在 QA 过程中，我们通常需要描述一系列操作，这会导致一些错误。

通常最好的方法是通过短信描述情况。有时屏幕截图会有所帮助。但我相信视频或幻灯片应该帮助 QA 团队，并且应该减少 QA 团队的时间损失 - 开发人员迭代。

在我们团队中的某个时间（我们在其他城市有大部分 QA 团队），我们使用TeamView来描述重要的情况。但是建立连接需要很多时间，并且需要停止开发人员的工作以进行展示时间。如果你必须向其他开发人员展示这个错误，你应该再次重复这个过程。视频剪辑是新手开发者的好项目，他们不能完全了解新项目。我认为我们可以找到这种方法的许多优点。

这种方法的缺点是描述量大。

是否有一些工具可以将用户屏幕操作录制到视频或幻灯片中？如果这个工具是免费的，那就更好了。

此工具的好功能是“获取最后 2 分钟的幻灯片”。例如，QA 工程师让它在后台工作，并尝试做一些导致错误的事情。QAE 认为最后 1 分钟的操作会导致错误。如果该工具允许保存 1 分钟前的操作，那将非常有用。

我们有大量的开发人员，但只有少数 QA 人员。通过编写自动化测试，开发人员在整个开发过程中更多地参与了 QA，但我们的 QA 实践大多是手动的。

我希望我们的开发实践是 BDD 和 TDD，并且我们开发了一个健壮的测试套件。问题是：在构建这样一个测试套件时，我们如何决定我们可以信任哪些测试，以及我们应该继续手动测试哪些？

我想开始实施自动化。我只是不知道这是否会很好地利用资源。该应用程序正在以指数速度增长，但我不知道自动化在什么时候有益于测试。

即使您有手动测试人员，您能否给我一些自动化的理由？

测试主要分为手动测试和自动化测试。关于这一点，我想到了一些问题。

它们包括：

• 这两种测试的基本区别是什么？

• 手动和自动测试都涉及哪些挑战要素？

• 软件测试人员分别需要哪些不同的技能来进行手动和自动测试？

• 分别做手工测试自动化测试的软件测试人员有哪些不同的工作前景和成长机会？

• 无论如何，手动测试是否低于自动化测试？如果是，如何？

• 与企业界的自动化测试人员相比，手动测试人员的处理方式有何不同？（如果它们在任何方面确实有区别）