【发布时间】：2008-10-08 18:31:56
【问题描述】：
作为一名学生，我刚刚获得了作为手动测试员的第一份合作工作。我知道这和编码员一样有智慧和要求很高，但我不禁反过来想。我喜欢成为一名编码员，但这是我的第一份工作。因此，我想请您就如何充分利用手动 黑盒 测试工作提供任何建议，即如何使用它来提高我的编码技能。非常感谢。
【问题讨论】：
标签： testing qa manual-testing
【发布时间】：2008-10-08 18:31:56
【问题描述】：
测试有时比开发更具挑战性和回报。在与我合作的团队中，很多优秀的开发人员都来自测试工程师背景。
首先，这项工作可以让您对发展前景有一个独特的看法。一些开发人员认为测试人员是刻薄而挑剔的，他们会在完美的代码中发现问题。一些测试人员认为开发人员是懒惰的人，对半熟的代码很满意。
从两边看情况绝对是一种值得拥有的体验，因为它会减少你以后职业生涯中的误传和误解。
第二个测试人员开始编写测试用例。测试用例很棒，因为它们可以帮助您考虑系统的功能，而不是类及其方法和属性等。编写软件的目标是制作有用的软件，而不是用您的编码技能达到卓越.因此，从这个角度考虑您的应用程序绝对是有帮助的。现在编写测试用例将帮助您以后编写好的架构文档。
您可以推动您的团队/公司向自动化测试迈进。有时这会失败，因为测试人员不知道如何编写自动化代码并尝试使用录制和播放接口。但是，如果您实际上可以编写测试代码，那么您成功的机会就会大得多。请注意，自动化是一项重大的工作，不应掉以轻心。经典书籍说，工作量加倍，然后手动测试与自动化并行完成。我倾向于同意。
【讨论】：
将您在手动测试时经常做的简单事情自动化。这并不总是意味着实际测试，在大多数情况下，自动化功能测试变得更加困难，并且您离代码越远，离界面和人脑越近，您所花费的时间就越少。
例如;测试时是否需要复制文件并输入一些值来运行软件？自动化。您是否需要在数据库中填充数据以帮助您进行测试？自动化。一旦简单的事情被自动化并顺利运行，您就可以处理更难的事情。
另一个建议是阅读和理解源代码提交，如果可能的话，修复你发现的错误。你可以通过这种方式学到很多东西。
【讨论】：
-
这是一个很好的建议。即使您无法自动化实际测试，将繁琐的设置和测试结果报告部分自动化也是一个巨大的胜利。
-
同意。能够非常快速有效地汇总性能测试结果，这让我在第一份工作中获得了加分。
作为程序员尝试破解它:)
Sql 注入、脚本注入等：） 它应该让它更有趣:)
【讨论】：
规划期间：
- 花时间了解您指定区域的功能规范或更改请求。您的编程知识让您在这方面占据优势。
- 质疑矛盾和漏洞。希望您可以在开发仍在进行时访问设计文档。在开始测试之前，我经常通过质疑不明确的设计文档来发现产品中的问题。
- 仔细考虑所有边界情况、否定条件和条件组合。如有疑问，请与开发合作。您不需要知道他们使用的实际代码，但您的编程背景将帮助您编写一个完整的测试模型。
- 不用担心自动化。每个新的测试人员都会看到一百种改进测试的方法，自动化通常是最重要的。黑盒测试唯一应该自动化的是一些测试设置，如果它是一个与被测试功能无关的耗时操作。 （例如，在学习管理系统（LMS）中自动创建20门课程来测试自我注册场景。课程创建不是重点，因此节省几个小时的无脑工作是可取的。）问自动化是可以的，但不要以为你是第一个想到它的人。
测试期间：
- 编写清晰、详细的特定错误报告。如果有人在您的代码中发现错误，请考虑您想要的所有信息。将问题分解为持续解决问题的最小的具体行动。包括重新创建测试数据的步骤和示例。
- 当您发现问题时，尝试通过测试损坏功能的替代方案来缩小问题范围。 （简单示例，在基于浏览器的产品中，使用关闭按钮关闭对话框时出现错误。使用窗口关闭按钮 (X) 关闭时是否也会出现错误？无论答案如何，将其包含在错误中报告。
- 做个好人。测试人员和程序员在同一个团队中。如果开发人员看起来像个白痴，不理解您所说的任何内容，请支持并假设您是不理解的人。它可以节省很多痛苦并迅速改变您的态度。当你谦虚和受教时，沟通会更容易。
【讨论】：
几年前我和你处于同样的位置，对我来说，作为测试员在编码时帮助了我很多，它会在你不注意的情况下发生。
大多数情况下，您会更加小心用户输入、孤立链接等，通常您会更加详细。根据我的经验，这是一个非常好的职位，我认为它确实改变了我的编程风格
【讨论】：
也许您可以尝试自动化一些测试？
编写一些脚本，为手动测试（启动、登录、加载测试数据集等）准备应用程序，
编写一些回归脚本，将之前版本的输出与您正在测试的版本的输出进行比较。
【讨论】：
如果您被雇用进行手动测试，那么这就是您应该关注的。
自动化测试很棒，如果您的公司没有这样做，他们确实应该这样做。但是，您并不是要告诉他们如何经营他们的业务。任何工作的第一件事就是完成分配的工作。在入门级尤其如此。
我的建议是，如何让这成为一种学习体验，以帮助您在未来作为开发人员的职业生涯中有所帮助，那就是注意您在其他人的代码中发现了哪些类型的问题。了解常见错误可以帮助您避免在自己的代码中犯同样的错误。
例如，一些错误只是编码错误，例如在循环遍历数组时被关闭。还有一些是对需求的误解、高级设计中的缺陷或未能检查意外/无效输入。
此外，在报告错误后，请尝试与开发人员联系，以尝试获取有关问题根本原因、他们如何修复问题以及对项目的影响的更多信息。请注意这一点：程序员和 QA 测试人员往往存在逆向关系。他们不会喜欢你告诉他们他们的东西不起作用，尤其是高层的。确保他们知道您正在尝试从中学习，而不是批评。如果可能，请从开发人员中挑选一位“导师”来帮助完成这部分工作。这样一来，您就有一位主要联系人希望与您进行此类对话。
您可能从这个合作社中获得的主要收获是了解软件开发在现实世界中是如何完成的。作为测试人员，您将有机会看到比入门级开发人员更多的“大局”，这在您刚开始时是一件非常好的事情。
如果您认为自己在这家公司有前途，无论是在 QA 还是作为程序员，这是了解他们的产品和行业的好机会。最好的程序员不仅仅是低头的猴子。他们不仅知道他们的代码做了什么，还知道为什么以及如何使花钱使用它的人受益。
祝你好运。
【讨论】：
你可以：
学会隔离问题。当您发现错误时，请尝试找到重现此错误的最小操作子集 - 程序员会为此感谢您，并且您将学到一套重要的技能。
学会正确沟通技术问题。编写一份好的、详细的错误报告需要很多技巧。
学习根据系统的极限情况和扭曲用途进行思考。这将使您以后编写更好的单元测试。
我真的相信所有程序员（包括资深程序员）每年都应该花一些时间进行手动测试，如果只是为了从不同的角度看待事物，并获得对与他们一起工作的测试人员的一些尊重（我说在实践中我自己）
【讨论】：
除了关于自动化的内容外，请确保您对整个生命周期表现出兴趣。很有可能您在测试中发现的任何内容都没有正确记录在需求中，并且在您看到它之前没有经过正确的单元或集成测试。您可以做的任何事情来帮助改善早期的事件链将有助于教育您并使每个人的生活更轻松。
当心自负，当你发现它们时要小心行事。
【讨论】：
如果它与网络相关，请找到其中一个框架，您可以在其中编写击键和/或鼠标单击的脚本，以进行一种虚假的单元测试。它会提高您的工作效率，并且您可以通过它成为忍者，使用它来处理您真正需要测试的东西，而无需处理它之前的 50 页。
它最终可能会让你踏入自动化测试的大门，如果你给人们留下深刻印象，你可能会进入开发部门，因为很明显你可以很好地编写脚本。
【讨论】：
学习一个 *Unit 框架并随时插入不同的案例。
【讨论】：
多任务处理，并在您拥有的每一秒内练习编程。当我有一份无聊的工作来维护一些糟糕的旧 Perl 构建脚本时，任何时候我不工作的时候，我都在学习更高级的 Perl，查找新算法，在 Haskell 中编写原型等等。
【讨论】：
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 的影响和所有可能的解决方案。
不要忘记测试是一项富有创造性和挑战性的任务。最后，这完全取决于您在应对这一挑战时的技能和经验。
交给你：
在下面的cmets中分享你自己的测试经验、技巧或测试秘诀，一定会让这篇文章更有趣，更有帮助！！
【讨论】：
测试比开发更具挑战性，因为自动化测试人员是具有开发和测试知识的 SDET（测试软件开发工程师）。他们将更多地了解用例和场景。因此，尝试实时自动化场景，例如，A Scenario： 1. 启动 Gmail 网站。 2. 登录 Gmail。 3. 点击撰写。 4. 起草一封带有附件的邮件并发送给某人。 5. 登出 所以在这里，你可能有几个问题：我应该使用哪个框架，我应该使用哪个自动化工具，以及附加一些东西到邮件不是基于 Web 的，所以我们需要依赖其他一些自动化工具来处理非基于html 或基于窗口的自动化。
这样您就可以开始切换到自动化。我们只是将手动重复执行的相同场景自动化。
当您开始编写测试脚本时，您的编码技能会自动得到提高。
这是我的经验。如果您想使用 Java 学习 Selenium，我可以为您提供资料。
【讨论】：