无论我们试图建立一个网站多么完美，我们都一定会犯一些错误。错误是不可避免的，无论多么微小。这就是为什么我们不能保证没有错误的发布，甚至在进行了不同类型的全面测试之后，例如压力测试，跨浏览器测试，响应测试等。在投入生产环境之前，请考虑流程中涉及的各种类型的测试。依然可能在上线的版本中发现问题。
出了问题，就要解决问题，不管是测试过程中发现的还是上线以后用户反馈的。但在解决问题的过程中，测试人员需要起到积极的推动作用。当然理想很丰满现实很骨感，有的人总是能找到各种各样的理由逃避问题和责任。
下面分享一些测试人员经常遇到过或者使用过的各种接口，有些我自己也用过。
Chrome 上没问题，其他浏览器上应该也没问题
因此，当你测试了一个网站，遇到了一些错误，然后将其转发给开发团队。他们修复了该问题，并将其转发给您或您的测试团队以供验证。您仔细地对整个网站进行回归测试，以检查更改是否影响了任何现有功能。一切都很好，您进行了确认，因为从系统（而不是浏览器）测试网站时，您没有发现任何错误。一旦更改生效并投入生产，客户使用与您不同的浏览器便开始抱怨 UI 和跨浏览器兼容性问题。
如果该软件在 Google Chrome 或任何其他浏览器上都能正常运行。但是请记住，就像人类对所有事物的理解不同一样，浏览器也是如此。如果代码与一个浏览器兼容，则不必所有浏览器都以相同的方式解释代码。测试人员需要确保自己的网站在所有浏览器上都提供一致的体验和行为，不能忽视跨浏览器测试。
专注于预定的测试用例场景
测试人员最常见的借口之一：他们的工作只是遵循分配给他们的预定义测试用例。但是，测试人员必须超越专注于预定义的测试用例场景。如果执行预定义的测试用例是任何组织唯一关心的问题，那么采用自动化测试会更好。自动化测试和手动测试应该齐头并进。因此，预定义的测试用例最终实现了自动化，测试人员将有更多的时间提出更好的测试方案。开箱即用的思考是测试工作的一部分，必须分析当前项目的开发计划的风险，并强调探索性测试。
部署构建和调试问题不是我的工作
已经批准了整个发行版。现在，您要做的就是等到 DevOps 投入生产。但是，真的必须等待吗？如果您认为部署构建是开发人员的头疼问题，估计要多问问自己几遍了！您是否有能力利用可用资源来采取富有成效的行动？如果是，为什么每次都依赖开发人员？您需要做的就是触发构建并部署适当的措施，没有理由等待。毕竟，您具有使您的工作更轻松的权限和能力。你为什么不能自己做？
部署是员工面临最多失败次数的情况之一。但是，您知道此类失败的最大好处吗？他们会提示您再次调试并学习新知识。如果有什么鼓励您提出问题或浏览器搜索，那将始终是您的最佳选择。
没有足够的时间进行测试
没有足够的时间是世界上几乎所有事物的最普遍借口！在某人无法完成某件事的那一刻，他们在这里为自己的失败指责。测试人员，让我们面对现实吧。要测试的因素太多了，您将永远没有足够的时间来完成这一切。没有足够的时间测试，这并不意味着最终会因此导致时间管理失败。实行有效的时间管理并确定测试程序的优先级至关重要。
我没有测试 IE，因为它已经过时了
Internet Explorer 是一个兼容性解决方案。我们不支持新的 Web 标准，尽管许多站点运行良好，但如今开发人员基本上很少在 Internet Explorer 进行调试。如果考虑到测试 Internet explorer 浏览器兼容性测试的时间，很增加很多不必要的工作量。
不！如果考虑到当前用户的属性和潜在用户的属性，Internet explorer 兼容性测试时必要的。
昨天测试了该功能，不需要再次测试了
如果您认为在报告 BUG 后就完成了工作，那是错误的。您可能会说您已经执行了详细的测试，并将错误传达给了开发人员。但是作为测试人员，您必须意识到报告错误有时会导致代码更改。有时，更改可能会影响以前的功能。
回归测试是所有 SDLC 的最基本方面。无论花费多长时间或重复多少，其重要性都保持不变。作为一名测试人员，我了解通宵的工作以便发布及时的修补程序，短促的发布窗口会造成很大的损失。有时候，我们在回归测试上懈怠。
因此，重要的是要检查修改后产品是否工作良好。必须做好执行频繁检查的准备，并确保没有剩余的回归缺陷。
我认为无法测试此功能
这是到目前为止我遇到的最荒谬的借口之一。令人惊讶的是，有许多测试人员使用它来逃避他们不了解的功能的测试。考虑一下，您测试环境中的每个功能都已经由开发团队进行了测试（或者调试）。如果开发人员知道某个特定功能正在运行，并且能够在沙盒环境中对其进行测试，那么就必须有一种方法来对其进行测试！
可能是，您可能无权访问某些功能中使用的系统。在这种情况下，您需要与开发人员合作，并要求他们向您展示该功能的工作原理以及如何对其进行测试？然后，尝试不同的测试用例并尽可能发现 BUG。
指责开发人员的代码
责备他人是逃避不愉快状况的最简单方法。软件行业中的一些测试人员趋向于将开发人员承担所有令人讨厌的责任。毕竟，如果错误出在开发人员的工作上，没有人会责怪测试人员！当您指责开发人员的问题时，那么他很有可能会选择回击。
但是这种盲目推卸责任的方法是完全错误的，不仅对团队有害，对自己也有害，会让以后的合作更加困难，会让组织在平息愤怒和理清责任上的时间大大增加从而延长发布周期。
用户不了解程序
因此，现在甩锅的循环已经从开发人员转移到了用户！
在任何情况下都不要忘记进行可用性测试。企业的所有努力都取决于用户体验。在可用性测试期间，请不带任何偏见地从小白用户的角度进行测试。
在测试环境上运行 ok
这是一个借口，对测试人员而言只是合乎逻辑的，而对其他人则没有。似乎在测试阶段运行良好的应用程序不一定可以在生产中完美运行。原因可能有多种，在网站上进行测试时，经常无法获得网站进行生产的实时流量和所有情况。
作为测试人员，应该在从测试环境提供批准之前彻底了解生产环境以及两者的差异。
总结一下
测试人员在软件开发生命周期中扮演着极其重要角色。为了生意兴隆，必须为客户提供满足需求又拥有良好体验的产品。为了确保这一点，测试人员需要测试产品并从最终用户的角度对其进行分析。发现 BUG 后，他们需要将相关信息传达给开发团队。然后致力于消除缺点并部署各种纠正措施。
测试人员需要意识到，他们需要摆脱借口的习惯。这将有助于他们的职业发展，并促进公司的发展。相应地进行分析和测试会带来更好的产品和出色的客户体验。
- 郑重声明：文章首发于公众号 “FunTester”，禁止第三方（腾讯云除外）转载、发表
技术类文章精选
- java 一行代码打印心形
- Linux 性能监控软件 netdata 中文汉化版
- 性能测试框架第二版
- 如何在 Linux 命令行界面愉快进行性能测试
- 图解 HTTP 脑图
- 将 swagger 文档自动变成测试代码
- 五行代码构建静态博客
- 基于 java 的直线型接口测试框架初探
- Selenium 4.0 Alpha 更新日志
- Selenium 4.0 Alpha 更新实践
非技术文章精选
请不要频繁的发帖子，控制下节奏。
