经常会发生这样的情况：尽管拥有测试环境的测试，但最终未能从中完全避免在生产环境发现 BUG。不禁让人思考：质量检查环境中出了什么问题？为什么在测试环境中已经完全通过的新功能在迁移到生产后又出现 BUG？
缺乏持续监控
监视可以帮助防止超出阈值限制的任何代码部署，从而提供状态稳定性，最终防止 QA 质量检查不全面。不要仅仅依靠监视工具！第三方不能完全考虑到每个公司的实际情况，因此将环境交由第三方服务提供商来处理是不明智的。必要的时候，需要在一个尽可能与生产环境相同的环境上，进行不间断的监控。
最后一小时冲刺
这是在管理方面非常普遍的失望。RAD（快速应用程序开发）的压力导致快速部署。由于来自用户的大量请求，错误日志记录，RCA（根本原因分析），错误修复，验证以及其他职责常常使环境负荷过大，给质量保证蒙上阴影 。结果，当发布日期确定后，才开始准备发布通道的各类事项。管理者需要给测试人员足够的时间在这种环境下对产品进行足够的测试，否则，这与将更改从测试环境推向生产环境没有什么不同。
兼容性测试
一个 Web 应用程序在不同的浏览器及其版本中呈现的方式有所不同。这取决于制造商设计的渲染引擎。结果，并非每种浏览器都以类似的方式支持applet、javascript、CSS等元素。确保用户界面健壮性对于任何企业都是至关重要的，并且是测试人员在进行质量检查验证时应牢记的一项任务。
紧急更新
有时，重大故障会破坏团队的整个工作氛围，从而影响所有人都参与其中。客户，经理，开发人员，甚至测试人员。当服务中断时，客户就非常着急，需要尽快提供快速修复。在这种紧急情况下，我们通常会提供解决方法，甚至立即在生产环境中部署次要修补程序，以使服务能够正常运行，但是有时候会忘记在测试环境中部署该修补程序。在接下来的几个小时或接下来的几天中进行环境修补程序的更新同步。这个时候需要有效的管理，以确保即使是微小的修改也可以迁移到所有关联的环境，尤其是 QA。
下一次迭代质量检查
这与上一点有关。如果在生产中部署了立即修复程序，由于种种原因，缺失了必要的质量检查。修复程序在下一个发行周期中需要引起足够的重视。常规的 QA 验证可以顺利通过，但是当迁移到生产环境时，代码可能会报错，甚至线上服务会出现宕机等问题。这可能是由于这两个环境之间遗漏了一个小错误而导致的。
过时的测试实践
有一些公司遵循过时的测试实践，因为他们拥有孤立的 QA 团队，无法完全与Dev集成。在这种情况下，、测试人员和开发人员之间存在一个固定的争论。修复 BUG 版本迅速发布到测试环境中，然后进行质量检查，发现于此相关的另外一个 BUG，将指针还原回给开发人员，然后开发人员将迅速进行重新部署，并继续进行恶性循环。到发布日期临近时，与计划或客户期望相比，任务远远没有达成，只能靠加班和延期来解决问题。参考文章：集成测试类型和最佳实践。
共同目标缺失
就我所知，这一直是一个问题。独立的团队在同一个项目上工作，但仅专注于他们的目标，而在要求合作时却一脸茫然。团结则存分裂则亡。必须遵循这一座右铭，以达到以客户为中心的交付和高效利用资源的顶峰阶段。参考文章：新词：QA-Ops、DevOps 中的测试工程师、如何实施 DevOps。
数据一致性缺失
如果测试环境与线上环境的数据不一致，很难保证在测试环境进行测试活动的质量。预上线环境的目的是在其上复制尽可能多的线上环境。因此，复制用户数据显得尤为重要。不能再空表上运行测试，而是需要在处理数据库中填充与生产数据库一样多的数据，来测试新功能和回归旧功能。参考文章：生产环境中进行自动化测试。
错过探索性测试
我们对测试已知测试方案花费的资源太大，而我们却忘记了未知的场景。这里所指的未知场景是工程师和测试人员团队无法预见的，但当成千上万的客户使用该产品时，就会暴露这些场景。进行探索性测试对于消除未知风险至关重要。参考文章：探索性测试为何如此重要？。
微服务的部署和管理困难
微服务是团队中实现可靠且平稳的扩展的实践。可以相信，微服务和预上线服务器不是彼此对应的。原因是有这么多独立的团队同时提供与众多第三方应用程序的连接。使用生产环境中运行的最新版本映射所有外部和内部微服务变得非常具有挑战性。这很困难，但是对于确保市场上可靠的高质量产品而言，这是至关重要的。
- 郑重声明：公众号 “FunTester” 首发，欢迎关注交流，禁止第三方转载。