尽管单元测试技术已经存在了30年（Kent Beck在1989年写了文章“ Simple Smalltalk Testing：With Patterns”），但并不是所有的程序员都拥有这项技术，也不是所有的公司都将自动测试作为其企业文化的一部分。 。 尽管自动测试具有明显的优势，但行为阻力仍然很强。 尝试实施自动化测试的任何人都知道，总是有某些原因无法实现此目的。
根据我在公司中实施可靠的编程方法的亲身经历，与我磋商过的公司，在会议中进行交流以及从公开渠道获得的经验，我提出了一些典型的反对意见和反对意见，这些看法和反对意见阻碍了自动测试文化的实施。
我将所有反对意见归类为可靠的编程金字塔，其中包括四个层次：
- 职业文化 （最高水平，可靠编程的基础）是一组准则，未成文的规则以及员工的信念，这些指导他的工作。 例如：“将测试未发现的代码发送到存储库是不好的”，“使代码中发现的错误发生沉默是可耻的”。
- 管理是组织采用的程序，政策，规则以及领导者的意愿（决策）。 例如：“每个开发的应用程序功能必须通过审核代码。 也不例外！
- 方法是科学方法，是解决特定问题的方法。 例如：“如果应用程序的功能难以测试，则需要通过应用依赖注入模板来提高应用程序的可测试性。”
- 技术 （最低级别）是编程语言，库，框架，工具。 例如，JUnit，Selenium，XCTest等。
为什么需要这样的划分？ 因为一个级别的问题是通过相同级别的方法或更高级别的方法解决的。 例如，如果组织不习惯编写自动测试（专业文化问题），则无法通过详细描述测试业务流程（级别“管理”）或安装现代框架（级别“技术”）来解决此问题。 我保证，尽管批准了业务流程，但一周内不会有人编写测试。
文化异议
“我的程序没有中断。 我认为没有必要进行测试。”
我从初学者或过分自信的程序员那里听到了这一说法。
当然，一旦编写的功能不能自行中断。 但是在这里重要的是要了解，随着时间的流逝，该程序可能需要支持，引入新功能或对现有功能进行补充。 程序的复杂性-类的数量以及它们之间的依赖关系-很大，最终，在制作另一个新功能或改进现有功能之后，迟早会发生错误。 自动测试将检测到这种回归。
另外，经常会从没有测试概念的新手程序员那里听到这样的反对意见。 例如，只有崩溃被认为是故障，而不是功能错误。
在我进行的一次采访中，进行了以下对话：
-您有自动测试的技能吗？
-不，我编写了简单的程序，没有什么可打破的。
-您换工作的动机是什么？
-我想编写复杂的应用程序。
我知道这怎么结束。 程序员可以开发更复杂的程序，但他不知道自动测试的方法，不能定性地测试应用程序，不能应付项目的规模，这将导致项目中断，开发成本超支，声誉丧失。 因为我亲自管理项目，所以我无法应对项目的规模，而恰恰由于缺乏自动测试而使项目失败。
不愿对代码的质量负责，无法进行测试。
自动化测试是有关软件产品真实质量的操作和客观信息的唯一来源。 换句话说，程序员总是在背后有一个主管，他可以随时向管理层报告程序员的工作状况。 自动化测试使您不仅可以将工作效率与Jira中的封闭票证联系起来，而且可以与软件产品的真实质量联系起来。 在这里，您已经需要考虑如何可靠地编写代码，以便对代码的每次下一次更改都不会破坏现有功能。 这样，每个新功能不仅可以在脚本中正常运行（一切正常），而且可以正确处理错误。
责任是确保工作取得积极成果的自愿承诺。 员工凭借自己的性格和受过教育而承担这项义务。 不幸的是，由于文化和专业危机，并非每个程序员都准备承担这种义务。
“立即写，没有错误”
对软件开发的工作方式不太熟悉的人可能会对提到某种错误的开发人员持消极态度。
-让我们用自动测试覆盖应用程序。
-为什么？
-确保一切正常，并且没有错误。
-你写错了吗？ 您的学历低吗？ 立即写，没有错误。
“是的，但是每个人都会犯错……”
-但是XYZ公司对一位朋友说，他们有顶尖的程序员编写的程序没有错误！
因此，很难将开发的测试“销售”给不精通技术的客户。 结果，管理层被迫在没有自动测试的情况下开发项目，这导致了众所周知的问题。
管理异议
“通过测试，编写程序的时间是原来的两倍。 我们将无法按时完成任务。”
乍看之下，这一论点似乎很公平。 确实需要花费程序员时间编写测试。 但是程序员和管理人员没有考虑到整个产品开发时间不仅包括编程，还包括调试和支持，以及在更正后进行手动回归测试的巨额成本。
自动化测试具有以下功能：
- 正在检查 。
1.1。 测试验证测试对象是否正常工作。
1.2。 测试检查程序员的工作质量：是否解决了任务，是否存在任何回归形式的副作用。 - 诊断 。 诊断测试可以大大减少寻找缺陷的时间。 通过测试，您可以确定错误的位置，该位置对于类和方法是准确的，有时甚至对于代码行也是如此。
- 自动化 。 通过测试，您可以快速轻松地以所需状态输入测试对象以进行调试。
- 记录文件 。
4.1。 验收测试记录了客户对所开发产品的要求。
4.2。 测试显示了使用已开发组件的示例，从而减少了另一个程序员花在研究系统工作上的时间。
在我咨询过的一个组织中，经理拒绝引入自动测试的文化：
-毕竟，编写测试很长时间了！ 我们不会在最后期限之前！
-您有很长一段时间一直在寻找和纠正的错误吗？
-是的，有一些。
-最困难的情况是什么？
-我们搜索了一个错误，持续了80个小时。
-80小时是程序员工作的两个星期。 如果您甚至花了整整一周的时间来测试自动化，则可以节省数月的诊断和调试应用程序的时间！
我们的组织假设：“有了测试，编写程序的速度就快两倍！” 并没有讨论这个假设。 仅讨论系数2-有时为3和4。有些项目如果没有能胜任的自动测试就无法完成（请参见不堪重负的项目）。
“我们已经有一个手动测试部门，让他们进行测试。”
乍一看，将专业划分为测试和编程似乎是合乎逻辑的。
但是，让我们看一下手动测试的缺点：
- 非常昂贵。
- 这需要很长时间。 例如：移动应用程序“ Online Cinema”测试仪的测试脚本需要40个小时。 这仅适用于一个平台！ 如果需要在iPhone，iPad，Apple TV，Android，Fire TV上测试应用程序，则需要花费40×6 = 240小时的工作时间，这是一个半月，这对于较短的开发周期是不可接受的。
- 手动测试会遇到一些常见的人为错误-无法提供客观真实的结果。
此外，由于格式和各种测试脚本的组合数量非常大，因此某些类型的测试无法在合理的时间内执行。 例如：
- 导入CSV文件的功能。
- 文本文档解析器。
- 金融工具。
方法级别异议
无知的自动测试方法。
由于教育危机，大学中没有自动测试学科。 商业IT学校中很少有此类课程。 现有的课程是肤浅的，质量较差。 因此，我经常在程序员中遇到一个傻瓜：他们不知道如何测试非平凡的应用程序（比2 + 2 = 4更困难）。
实际上，测试科学非常广泛。 例如，不是每个程序员都会立即回答以下问题：a）什么是可测试性？ b）什么是可控制性和可观察性？ c）哪些设计模式可以提高应用程序的可测试性？ 依此类推。
程序员不知道他们写的是什么，外观，功能和接口。
测试看起来不清楚的内容非常困难。 换句话说，如果没有应用程序的预定义要求，程序员将无法理解他的期望。
一些项目的特殊性在于它们是使用最小可行产品技术开发的，换句话说，可以描述如下：“让我们至少在最小的时间和最小的预算上做些事情”，并且程序员或客户将程序员视为分析师，设计师，架构师，一瓶程序员和测试人员。 使用这种方法，可以排除设计软件系统的正式阶段：业务逻辑，域，组件接口的定义以及它们之间关系的内部组织。 没有正式的架构，没有接口，没有规定的业务流程-不清楚要测试什么，通过哪些接口以及预期的结果是什么。
代码不正确。
可测试性是一个项目属性，表明可以轻松地对其进行测试。 测试的适用性取决于其他两个属性：可控制性和可观察性。 可管理性-一个属性，用于确定将应用程序进入所需状态进行测试的容易程度（满足前提条件）。 可观察性-测试后考虑状态的难易程度，将其与期望值进行比较。
例如，使用SMS进行两因素身份验证很难自动测试，因为接收SMS的功能超出了自动化测试环境的范围。 这样的系统是不合适的。
面对不合适的系统，程序员放弃并避免测试这种系统。
准备测试数据。
显而易见的阻力之一是准备测试数据和标准。 例如：在其上执行测试的数据库的初始状态。 准备测试数据可能会花费大量时间和例行工作，因此在程序员中，这项工作被视为忘恩负义和无趣的。
解决方案：
- 在开发验收测试阶段开发参考值和示例-它们还将有助于在工作验收阶段解决与客户的冲突；
- 在系统设计阶段开发参考值。 例如，标准的HTTP请求和响应-将有助于更轻松地集成客户端和服务器；
- 开发用于组装数据库的特殊程序，其中自动（而不是手动）创建所需的数据库状态
- 使用Object Mother模板[Fowler，Schuh，Peter和Stephanie Punke。 “在XP中简化测试对象的创建。” XP宇宙。 2003]，这有助于轻松地在所需状态下分配和初始化对象。
测试服务。
在项目的开发过程中，对项目的要求（澄清，更改）可能会更改。 否则可能发生内部重构，这将导致类接口的更改。 随着需求的变化，特定功能的接受标准也将随之变化，并随之进行测试。 在某些时候，程序员可能会拒绝为测试提供服务-即，不对测试进行最新维护。
解决方案：
- 使用“适配器”模板以便将测试的逻辑与正在测试的接口分离；
- 使用高级测试（小黄瓜，黄瓜，Gifn-When-Then）；
- 参见电阻解决方案“测试数据准备”。
结论
毫无疑问，软件必须可靠：超出客户的期望。 自动化测试不是唯一的，而是可靠软件开发中的重要组成部分。
我对实施自动测试提出了典型的反对意见和障碍，这在我自己的组织以及我咨询过的那些组织中都是遇到的。
本文仅概述问题，而未涉及解决问题的方法。 总的来说，解决这些问题的策略在我看来是这样的：
- 形成和推广一种新的IT设计文化，即可靠性，自豪感和对结果的个人责任感。
- 为代码测试开发新的高标准。
- 制定和实施培训课程。
- 在编程人员和管理人员的职业生涯中引入动机，与正在开发的软件产品的质量以及自动测试的技能有关。
我设法理解的最重要的事情是问题处于不同的级别：技术，方法论，管理和文化。 并且需要在适当的级别上解决它们。 如果程序员没有接受适合测试的设计方法的培训，或者如果管理层不支持组织中可靠的编程文化，则很难实施自动化测试。
对于您在组织中实施自动化测试的难易程度的实例，我将不胜感激。 您遇到了什么问题？ 您是如何解决它们的？