所谓的反模式， 是指用来解决问题的带有共同性的不良方法。它们已经经过研究并分类，以防止日后重蹈覆辙，并能在研发尚未投产时辨认出来。
01
沉迷功能测试，忽视代码能力
虽然说业务测试是测试工作的本质，所有的技术都应该为业务服务，有了一定的代码能力后，可以更好地辅助测试，不论是从风险分析还是测试效能提升来看，都是有益无害的。但很多人却不屑去学习代码，认为那是开发的事，如果测试人员有代码能力了，为什么不去做开发（开发比测试高一等？）。测试学习代码是不务正业，点点点的业务测试才是测试的王道。
这类想法其实很危险，因为业务能力的可迁移性很小（特殊行业如银行、证券类、专业领域性强的行业除外），那么当你换家公司时，你的业务积累并不能成为很大的优秀。而代码能力是通过用的，它可以协助你完成代码走读，快速熟悉系统，对系统做更高层次层次地分析。同时，有一定代码能力的人，还可以通过编写各类小工具，来提升测试效率。
懂代码，一定会让你在测试路上走得更远，它不影响你对业务的理解。两条腿走路，会更稳。
02
沉迷自动化测试，忽视实际效果
自动化测试仿佛成为测试团队的标配。理想情况下，自动化测试确实能提升效率，但是它有很多前提和约束条件，并不是写个框架，跑几个用例就能够解决的。笔者见过太多自动化测试平台，每天执行的有效用例数不超过100个，那有什么意义呢？
在落地自动化测试前，需要从研发侧产出标准化的内容，比如接口测试，如果没有标准、有效的接口文档，而是让测试通过抓包来编写接口测试用例，其实是没什么意义的。维护成本过高。如何设计接口业务场景，如何准备测试数据，如何设计有效的断言，才是接口测试的核心，而不是去追求所谓的接口覆盖率。
标准化、自动化、持续化，自动化测试才能形成有效的战斗力，为业务提供更多质量保障。
03
沉迷马上就干，忽视测试策略和设计
在敏捷测试的环境下，速度并不是唯一追求。时间紧，任务重，直接开干最重要？如果没有全局的思考，只依赖当前迭代的需求内容进行测试，很容易一叶障目，忽略全局。设计测试策略的目标是“减少缺陷的出现和发布”。其中“减少缺陷的出现”可以通过测试前移等方法来解决，在进行软件需求分析和架构设计的时候发现缺陷；而“减少缺陷发布”可以使用各种测试方法、技术来验证和测试编码完成的功能。
在一些核心特性的迭代中，在一些基础能力构建的迭代中，还是需要停下来，好好思考一下如何开展更有效的测试方法，我们需要提前为这个迭代的测试活动做些什么。
当然，这份测试策略不宜太长，一页内最好，要保证团队所有成员能够随时看到这份策略并得到团队的整体认可。
04
沉迷发现缺陷，忽视缺陷预防
手里有锤子，哪里都是钉子。缺陷是质量保障活动过程中的伴随物，并不是最终的目标。测试不应该以发现缺陷为荣。片面所求缺陷数量，测试的目标会变成破坏软件，测试人员绞尽脑汁多提Bug。而开发的目标是实现功能，Bug越多说明实现效率越低。这种追求数量的度量方式很容易引发团队的割裂、针对重大线上问题的追责、质量工作重点的偏离等现象。
测试活动多数情况已经由验证质量、发现问题，转化为构建质量，预防问题，更多地从全员质量意识构建的场景下，去思考如何提升测试效率，更符合当下研发团队对测试的要求。
05
沉迷测试环节，忽视整体效能
当我们提到提升测试效率时，往往想到的都是提升测试执行效率、提升自动化水平。这些活动确实能在一定程度上提升测试环节的效能。但是从更大的软件测试生命周期（STLC）来看，测试是否是流程链路上的最大瓶颈？最大的返工和浪费是否发现在的测试环节？
在测试活动的执行过程中，我们不要忽略了团队的目标。我们需要从更高的维度去保障质量。测试左移，确认验收条件，避免返工。测试右移，线上产品监控，提前发现问题。都是测试人员可以去改进的点，可能会有更大的发现和收获。
06
习惯了的事，也不总是对的。当下舒服的，也不一定是正确的。软件行业已经发生了很大的变化，不怪企业对测试人员的技术要求不断的提高。而是应该庆幸测试的门槛越来越高，你才有更多的机会脱颖而出。
否则，凭什么是你？
