不包括单元测试的一般原因通常是“时间不够”，“这是我们需要尽快向客户展示的东西”，“没有人在我为此添加测试之前”。后者尤其具有级联效果。
另一个有问题的部分是，在讨论新功能或项目的设计和体系结构时，无法提高可测试性。
我认为这是一个问题，并想对此做些事情。我们正在加速发展，产生越来越多的未经测试的代码，这些代码通常会导致无法测试且不够模块化的代码设计以及不断增加的技术负担。
#1 楼
要使管理层和一线员工意识到测试的必要性，就必须有某种痛苦。您公司的工作方式取决于软件的真正使命或对生命至关重要。在不受监管的开发商店中，典型的开发人员/测试人员比率为4：1至8：1。 NASA使用的比例为1：8。没错，每个开发人员都有8个测试人员。诸如医疗设备之类的生命攸关软件由FDA监管，每个要求都必须有一个文档记录到测试案例和测试案例结果的链接。如果不存在此文档，则FDA执法人员可以进行调查，直到他们满意并提出指控为止。在调查完成之前，公司可能不会生产或销售任何东西。在某些情况下，调查花费了很长时间，公司破产并关闭了商店。
测试是一种保险政策。因此，它没有投资回报率。就像在问，“您的汽车保险的投资回报率是多少？”。您之所以拥有它，并不是因为有问题，而是因为有可能存在问题，并且希望您在发生某些事情时得到保护。测试的开销，没有负面影响，对他们有好处！他们可能会继续这样做，直到出现痛点为止。
如何改变文化？文化变革是困难的。由于业务进展顺利，而没有测试的开销，因此甚至可能不需要正式的测试小组或测试程序。
您已经表明，前线工作人员有很大的借口而不创建单元测试。管理层有同样的感觉吗？向您的老板和您的上司询问是否关心他们。如果他们不关心缺乏测试和测试程序，您将发现几乎不可能改变文化。您可能必须寻求一种与自己的文化更加契合的文化。创建一个单元测试存储库。为您开发的所有内容创建单元测试。与所有其他开发人员共享该存储库。创建一个文档，描述用于创建和维护单元测试的过程，以便公司的其余部分在准备就绪时可以使用它。让您的老板意识到这些事情。跟踪单元测试发现由您或其他人更改代码引起的问题的次数。这些错误并没有泛滥成灾。通过在公开发布之前捕获它们，您的单元测试有助于保存公司声誉。让您的老板和您的老板知道这些。保持公众参与度，某种形式的指标仪表板可以显示这一点。
评论
绝对棒的答案！我一厢情愿的想法是：自己进行更改并申请NASA :)非常感谢，我学到了一些新知识，现在我需要一些东西来开始跟踪和做更多事情。
– alecxe♦
18/12/14在19:25
完全同意您所能做的树立了一个榜样，并希望它能引起人们的注意。
–乔治M恢复莫妮卡
18/12/14在19:38
请注意，至少起初您的效率将低于不编写单元测试的其他开发人员。但是，最终，您应该提高工作效率，并产生更好的代码。因此，您需要管理支持才能接受最初的生产力损失。并且取决于您的软件在堆栈中的位置，可能很难证明您更可靠的代码实际上是一种资产，因为周围的代码仍然会有问题。本质上，管理人员需要因缺乏质量而感到痛苦，并应说服测试减轻痛苦。
–凯文·麦坚时（Kevin McKenzie）
19年1月1日在17:36
#2 楼
测试文化只能在高层管理人员的支持下才能改变。如果管理层不支持您，那么您将无法改变文化。因此，您必须向管理层说明应优先进行测试。尝试将测试构建为SDLC的一部分。否则，人们总是会引用截止日期和发布周期作为无法进行测试的原因。
#3 楼
经常测试谁，经常发布。
建议的解决方案：一个需要为可见性对项目团队/管理层进行测试的强有力的案例。
我认为关键在于发布频率。这是团队（与管理层）最看得见的东西，可以用来为投资和实施可靠的质量检查提供坚实的依据，例如自动化的单元/ API / UI测试可在每个签入中运行，并在构建过程中提供快速反馈循环。
婴儿步骤：从一个小型烟雾套件（10分钟）开始，该固体如何？作为演示覆盖？根据您当前的错误分析，无疑可以为您带来最大的收益。
评论
是否在生产中导致了一些不良后果？或者您只是在说这种情况可能导致的问题？@AlexeyR。我不知道有什么具体的生产问题可以通过在某种程度上缺乏适当的测试来解释，但是我相信我们已经以这种速度实现了:)
该产品的释放频率是多少？
现在有一些公司在生产中每隔几秒钟就会进行代码掉落……部分答案是他们拥有可靠的测试实践。
@VishalAggarwal很好，尽管我了解发布频率是更好地回答这个问题可能需要使用的指标之一，但我还是尝试保持通用性。谢谢。