我们是大型组织中的小型开发团队。我们没有分配测试人员给我们。我们已经背靠墙五个月，尽快开发出一些东西。考虑到那时，我们进行了手动单元测试，并且我们的（基于Web的React）应用程序运行良好，考虑到了这一点。更紧密地模仿生产的环境。在执行此操作之前，管理层要求我查看如何做才能完成一些初始测试，然后再将其交付用户。我们不希望技术问题减慢UAT并稀释其发现。也就是说，我们不希望UAT遇到我们应该首先解决的基本技术问题，也不要让UATesters不必要地受挫。
未来：
随着我们将其从客户群的一小部分扩展到更大的客户群。鉴于我们知道它会不断增长，因此管理层渴望测试尽快实现更多自动化，从而在添加扩展所需的功能时节省线下的工作量（成本）。
问题：
我们已经花了三个开发人员x五个月的时间来编写此代码，因此存在相当大的代码库，并且可能需要进行大量重构才能使其处于可测试的最高状态。我只是不知道从哪里开始。我一直在研究获取Selenium并进行一些UI级别的测试，因为我们可以在不进行返工的情况下获得一些价值。我也正在考虑回到管理层，并解释说，如果不花费大量时间（可能会暂停开发），我们就只能做象征性的工作。
所以！我们如何开始向即将准备好部署但不幸的是没有优先考虑可测试性的项目中添加一些自动化测试？
其他应用程序详细信息可能与您的答案相关或不相关：
内置React和Redux
从用于存储客户端信息，系统信息等的各种第三方应用程序中提取数据。
为了安全起见，在我们希望在服务器端执行某些操作的地方抛出了一些jsp。
用于身份验证的一些Java
#1 楼
遵循测试金字塔并应用80/20规则：80％的测试是低级单元测试
16％的是API测试（服务）（16％是80％提醒）
4％是UI测试
从手动运行单元测试开始。有空时添加CI进行单元测试，然后添加服务和UI测试。通常建议将Jenkins用作CI的测试运行程序。
请参阅最近被问到的问题：CI中的测试：API +集成测试最合适吗？
与规模较小的质量检查团队配合应对
您已经积累了很多技术债务，因此您将不得不全额支付利息。让您的管理层知道这一点。
IOW：您将无法再继续以当前的速度继续前进（添加新功能），因为您的部分努力将是花在了非面向用户的工作上，例如CI和单元测试。您将放慢一会儿（以偿还债务），然后稍稍提高速度（当涵盖技术债务时）。
单元测试和服务级别测试是您主要的开发语言。
UI级别测试通常是用JavaScript完成的，因为UI是在Angular（或其他JS网站）中进行的本月的GUI框架）。我们（在我们的项目中）决定，因为我们核心应用程序的主要核心语言是Python，并且我们在Python中拥有更好的技能，所以我们也在Python中进行了大多数UI测试。您需要确定团队的技能在哪里。
#2 楼
“我们已经花了三个开发人员x五个月的时间来编写此代码，因此有相当大的代码库，可能要重构很多代码才能使其处于可测试的最高状态。我只是不知道从哪里开始。获得Selenium并进行一些UI级别的测试，因为我们可以在不进行返工的情况下获得一些价值。我也正在考虑回到管理层，并解释说，不花费大量时间，我们要做的不只是令牌工作在此期间，我们可能会暂停开发。“其中有几个关键指标表明了您的问题：
”可能需要大量重构才能最大限度地利用它-可测试状态”。忘掉“最大测试”。编写一个简单的测试。重复。这是测试中常见的失败之一。不要尝试编写真正的智能测试，而只是编写一些测试。然后重构。然后进行迭代。
“我们要做的不只是象征性的努力”。不对。您编写的第一个测试通常会增加巨大的价值，而随后的每个测试都会增加较小的价值。将第一个测试视为“象征性的努力”是您如何看待测试和入门的问题，而带来了测试增加价值的问题。他们是这样。我们知道。
此外，现在添加测试-但不更改编写代码的方式将意味着这是一个临时修复。开发需要使用TDD和/或BDD来更改开发方式。无论您是否花时间为当前的技术债务编写测试，都需要改变自己的发展方式。
使用单元测试，您应该从快速获胜开始，以便
团队习惯了该过程
团队看到了即时反馈
当需要添加CI来使测试自动化时，该团队可以与之合作
另外，不要遵循“首先使经常使用的零件自动化”的建议。毕竟，如果经常使用它，您将通过自然的开发过程对其进行测试，并将其作为测试其他内容的一部分。相反，请去那些变化很大或历史上经常中断的区域。花在创建测试上的时间将为您带来更多的收获。
评论
我还要补充一点，在单元测试中，您应该从快速获胜入手，以便（a）团队习惯于该过程，（b）看到即时反馈，并且（c）在需要解决的时候要有所帮助添加配置项以自动化测试。另外，请远离建议，不要先将经常使用的零件自动化。如果经常使用它，您将通过自然的开发过程对其进行测试。取而代之的是，寻找变化很大或容易破损的区域。花在创建测试上的时间将使您获得更多收益。
– MivaScott
18年5月1日在16:52
优分！添加了他们！
–迈克尔·杜兰特（Michael Durrant）
18年5月1日在17:48
#3 楼
我的朋友，当您找到答案时，请发布它，因为世界上许多团队都面临这种情况。基于我在一个没有自动化的七年项目中的经验，我的建议
从单元测试和CI开始。
用于系统测试
基于三个方面对功能进行优先级排序：使用，影响和自动化的难易程度。
开始自动化这些功能。最常用，影响最大且更易于自动化的工具。这样，您将能够以最少的努力提供大量价值。可能您会在此处拥有一些功能，这些功能背后的API是我们实现UI自动化的方法。
继续使用最常用，影响最大且更难实现自动化的API。这些功能会减慢团队的速度，但是这些功能是您永远不会失败的。这里可能有很多UI自动化。
对于其他的，则创建一个积压工作，这样您就可以每周至少花费一些精力来使新的东西自动化。
我的经验是必须在第三点做大量的返工，但这会随着时间的推移而得到回报。
此外，非功能测试对您来说似乎很重要，因为您希望它能够迅速扩展，因此需要花时间进行负载测试和压力测试。
最后一件事是确定所有潜在风险并与您的管理层坐下来，以便他们了解可能出什么问题。让他们对冒这些风险承担责任。
让我们知道什么对您有用（y）
#4 楼
不幸的是，这种情况太普遍了。我去过的地方比我想的要多得多，有时会使用无法进行单元测试的软件（经典的ASP Web应用程序，所有内容都交织在一起，不，它不会很快退休）。我建议您从@ edwin-jaime建议的方法开始，作为优先确定要编写哪些测试的一种方法。
对于将没有可测试性的代码转换为实际上可测试的代码的技术方面，我发现可以使用以下步骤进行操作，只要您能够并且可以保持对代码的管理支持努力。
编写不良的单元测试-最初，您可能无法隔离依赖项并构建可行的模拟或伪造品。只要您可以编写可测试关键代码单元功能的代码，就不必担心。理想情况下，每个潜在的有效结果都需要一个单元测试，但是您可以从涵盖所有有效结果的单一捕获开始。这将获得一组快速而基本的测试来验证您的业务逻辑。
隔离应用程序代码和测试代码中的依赖项-如果没有，请开始将数据源放置在接口后面并抽象显示代码已经做到了。进行更改时，请对测试代码进行相应的更改，以便在关键代码单元松散耦合时，测试也将松散耦合，因此不太可能出现片状错误。
分解多个职责的代码单元-设置好演示文稿，业务和数据接口后，就可以分解任何能完成一件事情的代码单元。执行此操作后，您将立即开始失败测试，因此请随时更新测试，直到获得SOLID DRY代码。
每次编辑代码时都要重复一次-清理完关键区域后，无论何时出于任何原因都需要使用代码，都可以开始使用相同的过程。这样，在进行错误修复或增强时，您将逐步遍历代码库，随时随地构建更干净，更可测试的代码库。
不要落入陷阱第二次-确保为可测试性编写代码，并在编写任何新代码时编写单元测试，并且不会再遇到此问题。
当然，所有这些这就要求您的管理层接受一段时间，直到您建立了可行的单元测试集然后进行更高级别的测试，新功能开发的步伐才会放慢。所需的时间长短取决于代码库要开始的大小以及它的混乱程度。
收益将伴随将来的变化而出现，如果您不小心破坏了任何带有单元测试的代码，您将立即发现。还将包括持续的集成，涵盖测试和知识，即未来的测试人员将不需要过多地关注核心应用程序逻辑，并且可以花费更多的时间来研究可能存在问题的系统和边缘情况。
评论
您的主要开发语言是什么-似乎是JavaScript？@PeterMasiar：是的，React是JavaScript。
“为了安全起见，一些jsp被抛出到我们希望在服务器端完成的地方。”我可以说一下，这听起来与我过去至少十年来听到的大多数Java开发实践相反。对不起，转移=）