testing - 如何充分利用手动测试人员

Question

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

Answer 1

测试有时比开发更具挑战性和回报。在与我合作的团队中，很多优秀的开发人员都来自测试工程师背景。

首先，这项工作可以让您对发展前景有一个独特的看法。一些开发人员认为测试人员是刻薄而挑剔的，他们会在完美的代码中发现问题。一些测试人员认为开发人员是懒惰的人，并且对半熟的代码感到满意。

从篱笆两边看情况绝对是一次值得拥有的经历，因为它会减少你以后职业生涯中的误传和误解。

其次，测试人员可以编写测试用例。测试用例很棒，因为它们可以帮助您考虑系统的功能，而不是类及其方法和属性等。编写软件的目标是制作有用的软件，而不是用您的编码技能达到卓越. 因此，从这个角度考虑您的应用程序绝对是有帮助的。现在编写测试用例将帮助您以后编写好的架构文档。

您可以推动您的团队/公司走向测试自动化。有时这会失败，因为测试人员不知道如何编写自动化代码并尝试使用录制和播放接口。但是，如果您实际上可以编写测试代码，那么您成功的机会就会大得多。请注意，自动化是一项重大工作，不应掉以轻心。经典书籍说，工作量加倍，然后手动测试与自动化并行完成。我倾向于同意。

Answer 2

将您在手动测试时经常做的简单事情自动化。这并不总是意味着实际测试，在大多数情况下，自动化功能测试变得更加困难，并且您离代码越远，离界面和人脑越近，您花费的时间就越少。

例如，例如；测试时是否需要复制文件并输入一些值来运行软件？自动化。您是否需要在数据库中填充数据以帮助您进行测试？自动化。一旦简单的事情被自动化并顺利运行，您就可以处理更难的事情。

另一个建议是阅读和理解源代码提交，如果可能的话，修复你发现的错误。你可以通过这种方式学到很多东西。

Answer 3

规划期间：

• 花时间了解您指定区域的功能规范或更改请求。您的编程知识让您在这方面占据优势。
• 质疑矛盾和漏洞。希望您可以在开发仍在进行时访问设计文档。在测试开始之前，我经常通过质疑不清楚的设计文档来发现产品中的问题。
• 仔细考虑所有边界情况、负面条件和条件组合。如有疑问，请与开发合作。您不需要知道他们使用的实际代码，但您的编程背景将帮助您编写一个完整的测试模型。
• 不用担心自动化。每个新的测试人员都会看到一百种改进测试的方法，自动化通常是最重要的。黑盒测试唯一应该自动化的是一些测试设置，如果它是一个与被测试功能无关的耗时操作。（例如，在学习管理系统（LMS）中自动创建20门课程来测试自我注册场景。课程创建不是重点，因此节省几个小时的无脑工作是可取的。）问自动化是可以的，但不要以为你是第一个想到它的人。

测试期间：

• 编写清晰、详细的特定错误报告。如果有人在您的代码中发现错误，请考虑您想要的所有信息。将问题分解为持续解决问题的最小的具体行动。包括重新创建测试数据的步骤和示例。
• 当您发现问题时，尝试通过测试损坏功能的替代方案来缩小问题范围。（简单示例，在基于浏览器的产品中，使用关闭按钮关闭对话框时出现错误。使用窗口关闭按钮 (X) 关闭时是否也会出现错误？无论答案如何，将其包含在错误中报告。
• 对人好点。测试人员和程序员在同一个团队中。如果开发人员看起来像个白痴，不明白你在说什么，请备份并假设你是那个不明白的人。它可以节省很多痛苦并迅速改变您的态度。当你谦虚和受教时，沟通会更容易。

Answer 4

尝试以编码员的身份打破它:)

Sql Injection, Script injection, etc,etc:) 它应该让它更有趣:)

Answer 5

几年前我和你处于同样的位置，对我来说，作为测试员在编码时帮助了我很多，它会在你没有注意到的情况下发生。

大多数情况下，您会更加小心用户输入、孤立链接等，通常您会更加详细。根据我的经验，这是一个非常好的职位，我认为它确实改变了我的编程风格

Answer 6

也许你可以尝试自动化一些测试？

编写一些脚本，为手动测试准备应用程序（启动、登录、加载测试数据集等），

编写一些回归脚本，将先前版本的输出与您正在测试的版本的输出进行比较。

Answer 7

如果您被雇用进行手动测试，那么这就是您应该关注的。

自动化测试很棒，如果您的公司没有这样做，他们确实应该这样做。但是，您并不是要告诉他们如何经营他们的业务。任何工作的第一件事就是完成分配的工作。在入门级尤其如此。

对于如何使这成为一种学习体验，这将有助于您未来作为开发人员的职业，我的建议是注意您在其他人的代码中发现了哪些类型的问题。了解常见错误可以帮助您避免在自己的代码中犯同样的错误。

例如，一些错误只是编码错误，例如循环遍历数组时被关闭。其他是误解的需求、高级设计中的缺陷或未能检查意外/无效输入。

此外，在报告错误后尝试与开发人员联系，以尝试获取有关问题根本原因、他们如何修复它以及对项目的影响的更多信息。请注意这一点：程序员和 QA 测试人员往往存在逆向关系。他们不会喜欢你告诉他们他们的东西不起作用，尤其是高层的。确保他们知道您正在尝试从中学习，而不是批评。如果可能，请从开发人员中挑选一位“导师”来帮助完成这部分工作。这样一来，您就有一位主要联系人希望与您进行此类对话。

您可能从这个合作社中获得的主要内容是了解软件开发在现实世界中是如何完成的。作为测试人员，您将有机会看到比入门级开发人员更多的“大局”，这在您刚开始时是一件非常好的事情。

如果您认为自己在这家公司有前途，无论是在 QA 还是作为程序员，这是了解他们的产品和行业的好机会。最好的程序员不仅仅是低头的猴子。他们不仅知道他们的代码做了什么，还知道为什么以及如何使花钱使用它的人受益。

祝你好运。

Answer 8

你可以：

• 学会隔离问题。当您发现错误时，请尝试找到重现此错误的最小操作子集 - 程序员会为此感谢您，并且您将学到一套重要的技能。

• 学会正确沟通技术问题。编写一份好的、详细的错误报告需要很多技巧。

• 学会从系统的极限情况和扭曲使用的角度来思考。这将使您以后编写更好的单元测试。

我真的相信所有程序员——包括资深程序员——每年都应该花一些时间进行手动测试，如果只是为了从不同的角度看待事物，并获得对他们一起工作的测试人员的一些尊重（我自己把它付诸实践） )

Answer 9

除了关于自动化的内容之外，请确保您对整个生命周期表现出兴趣。很有可能您在测试中发现的任何内容都没有正确记录在需求中，并且在您看到它之前没有经过正确的单元或集成测试。您可以做的任何事情来帮助改善早期的事件链将有助于教育您并使每个人的生活更轻松。

当你发现它们时，请注意自我并小心行事。

Answer 10

如果它与网络相关，请找到其中一个框架，您可以在其中编写击键和/或鼠标单击的脚本以进行某种虚假单元测试。它会提高你的工作效率，你可以用它成为一个忍者，用它来做你真正需要测试的东西，而不必处理它之前的 50 页。

它最终可能会让你踏入自动化测试的大门，如果你给人们留下深刻印象，你可能能够进入开发部门，因为很明显你可以很好地编写脚本。

Answer 11

学习一个 *Unit 框架并随时插入不同的案例。

Answer 12

多任务处理，并在您拥有的每一秒内练习编程。当我有一份无聊的工作来维护一些糟糕的旧 Perl 构建脚本时，只要我不工作，我就会学习更高级的 Perl，查找新算法，用 Haskell 编写原型等等。

Answer 13

测试比开发更具挑战性，因为自动化测试人员是具有开发和测试知识的 SDET（测试中的软件开发工程师）。他们将更多地了解用例和场景。因此，请尝试实时自动化场景，例如，一个场景： 1. 启动 Gmail 网站。2. 登录 Gmail。3. 点击撰写。4. 起草一封带有附件的邮件并发送给某人。5. 登出 所以到这里，你可能有几个问题：我应该使用哪个框架，我应该使用哪个自动化工具，以及在邮件中附加一些东西不是基于网络的，所以我们需要依赖其他一些自动化工具来处理非 html 或基于窗口的自动化。

这样您就可以开始切换到自动化。我们只是将我们手动重复执行的相同场景自动化。

当您开始编写测试脚本时，您的编码技能会自动得到提高。

这是我的经验。如果您想使用 Java 学习 Selenium，我可以为您提供资料。

Answer 14

1) 学会彻底分析你的测试结果。不要忽略任何测试结果。最终的测试结果可能是“通过”或“失败”，但对“失败”的根本原因进行故障排除将为您提供问题的解决方案。如果测试人员不仅记录错误而且提供解决方案，他们将受到尊重。

2) 学习在每次测试任何应用程序时最大化测试覆盖率。100% 的测试覆盖率可能是不可能的，但您仍然可以尝试接近它。

3）为了确保最大的测试覆盖率，将您的被测应用程序（AUT）分解成更小的功能模块。在这些单独的单元模块上编写测试用例。如果可能的话，也可以将这些模块分成更小的部分。例如：假设您已将您的网站应用程序划分为模块，并且“接受用户信息”是模块之一。您可以将此“用户信息”屏幕分成更小的部分以编写测试用例：UI 测试、安全测试、“用户信息”表单的功能测试等部分。

对输入字段应用所有表单字段类型和大小测试、否定和验证测试，并编写所有此类测试用例以实现最大覆盖率。

4) 在编写测试用例时，首先为预期的功能编写测试用例，即根据要求为有效条件编写测试用例。然后为无效条件编写测试用例。这将涵盖被测应用程序的预期和意外行为。

5）积极思考。开始测试应用程序以发现错误/错误。不要事先认为应用程序中不会有任何错误。如果您测试应用程序的目的是发现错误，那么您肯定也会成功找到那些细微的错误。

6) 在需求分析和设计阶段编写测试用例。这样，您可以确保所有需求都是可测试的。

7) 在编码之前让开发人员可以使用您的测试用例。不要让您的测试用例等待获得最终的应用程序版本以进行测试，以为您可以记录更多错误。让开发人员彻底分析您的测试用例以开发高质量的应用程序。这也将节省返工时间。

8 ) 如果可能，识别并分组您的测试用例以进行回归测试。这将确保快速有效的手动回归测试。

9) 应彻底测试需要关键响应时间的应用程序的性能。性能测试是许多应用程序的关键部分。在手动测试中，由于在性能测试中缺乏所需的大数据量，这是测试人员最容易忽略的部分。找出测试应用程序性能的方法。如果无法手动创建测试数据，则编写一些基本脚本来创建测试数据以进行性能测试，或者请开发人员为您编写一个。

10) 程序员不应该测试自己的代码。正如我们在上一篇文章中所讨论的，开发应用程序的基本单元测试应该足以让开发人员为测试人员发布应用程序。但是您（测试人员）不应该强迫开发人员发布产品进行测试。让他们有自己的时间。从领导到经理，每个人都知道何时发布模块/更新进行测试，他们可以相应地估计测试时间。这是敏捷项目环境中的典型情况。

11) 超越需求测试。测试应用程序不应该做的事情。

12）在进行回归测试时，使用之前的错误图（错误图 - 针对不同模块发现的错误数量随时间变化）。此模块级错误图可用于预测应用程序中最可能出现的错误部分。

13) 记下您在测试时学到的新术语和概念。在测试任何应用程序时保持文本文件打开。记下其中的测试进度和观察结果。在准备最终测试发布报告时使用这些记事本观察。这个好习惯将帮助您提供完整明确的测试报告和发布细节。

14) 测试人员或开发人员多次对被测应用程序的代码库进行更改。这是开发或测试环境中的必需步骤，以避免像银行项目中那样执行实时交易处理。记下出于测试目的而进行的所有此类代码更改，并在最终发布时确保您已从最终客户端部署文件资源中删除所有这些更改。

15) 让开发人员远离测试环境。这是检测发布或部署文档中缺少的任何配置更改的必要步骤。有时开发人员会进行一些系统或应用程序配置更改，但忘记在部署步骤中提及这些。如果开发人员无法访问测试环境，他们将不会在测试环境上意外地进行任何此类更改，并且可以在正确的位置捕获这些缺失的内容。

16) 从软件需求和设计阶段就让测试人员参与进来是一种很好的做法。通过这些方式，测试人员可以了解应用程序的可靠性，从而获得详细的测试覆盖率。如果您没有被要求参与此开发周期，那么您可以向您的主管或经理提出请求，让您的测试团队参与所有决策制定过程或会议。

17) 测试团队应与组织中的其他团队分享最佳测试实践和经验。

18) 增加与开发人员的对话以了解更多关于产品的信息。尽可能进行面对面的沟通，以快速解决纠纷，避免任何误解。但是，当您了解要求或解决任何争议时，请确保通过电子邮件等书面沟通方式进行相同的沟通。不要保留任何口头上的内容。

19) 不要没时间去做高优先级的测试任务。将您的测试工作从高优先级到低优先级，并相应地计划您的工作。分析所有相关风险以确定您的工作的优先级。

20) 编写清晰、描述性、明确的错误报告。不仅要提供 bug 症状，还要提供 bug 的影响和所有可能的解决方案。

不要忘记测试是一项具有创造性和挑战性的任务。最后，这一切都取决于您如何应对这一挑战的技能和经验。

交给你：

在下面的评论中分享你自己的测试经验、技巧或测试秘诀，一定会让这篇文章更有趣、更有用！！