如果您的项目只有有限的时间预算，您是否会投入团队的时间编写非Gui单元测试或GUI自动化的端到端测试脚本？对我来说，我更喜欢gui-automated端到端测试因为它可以模拟用户的实际操作。
答案 0 :(得分：3)
编写自动化E2E UI测试的优势，而不是单元测试
您不必熟悉特定的实现，甚至不必编写自动UI测试的编码方式。许多工具允许您只需单击记录，执行某些操作并保存脚本。
您还将预先发现更多对用户有影响的错误，因为您正在从用户的角度直接使用该应用程序。
编写自动E2E UI测试的缺点，而不是单元测试
自动端到端测试几乎不像真正的单元测试那样可维护。与GUI测试相同，因为GUI是最有可能以破坏现有自动化的方式进行更改的部分。
在自动化单元测试中获得100％的代码覆盖率也更容易，并且您不太可能在每个测试中复制逻辑。如果您遇到一个测试失败，则更有可能对应于特定的代码段。相反，如果您在代码中有一个中断，则不太可能导致多个测试失败。
在这个级别，如果你没有直接与代码交互，你更有可能解决你从未见过的奇怪的角落案例。
设置计算机以在更集成的环境中自动运行测试也更加困难。通过真正的隔离单元测试，您可以在您的开发机器甚至构建机器上运行它们，因为它们应该完全没有依赖性或对它们运行的盒子产生影响。
<强>策略
我个人更愿意让开发人员编写单元测试，因此测试团队可以专注于更高级别的测试自动化。
您还应该考虑加载/性能/安全性/模糊测试。它们具有固有的更高水平，即使不是不可能手动测试也很难，并且为测试自动化（从小时到严重程度）提供了巨大的帮助。他们也是最不可能需要从头开始工作的人，因为有许多现有工具可以利用。
答案 1 :(得分：1)
单元测试是指可以测试实现的每个方法的功能的单元测试。进行单元测试的主要原因是让开发人员有信心对代码进行更改，知道某个地方的更改不会影响其他地方或导致工作代码异常。
在您的情况下，您可能想要判断您是否在项目中看到维护价值（即您将获得维护短语合同），如果您这样做，您可能希望更加重视单元测试。
单元测试是保证更改请求和错误修复的最可靠和明确的方法。 ：d
答案 2 :(得分：1)
此视频compares different types of testing techniques.
单元测试最好是：
答案 3 :(得分：0)
将自己设置为类似Scrum的团队，确定产品所有者（代表客户）并为桌面上的每个故事提出“完成定义”。
这将有助于您平衡时间投资，因为团队成员将清楚他们需要做什么才能完成故事/任务。让他们自我组织，并在单元测试和E2E测试中提出正确的策略。
只要他们遇到国防部 - 他们就能达到平衡......
单元测试与E2E测试完全不同 - 开发它们需要不同的技能等。它们同样重要，并且不容易说要投资的位置（以及'切割conrners'的位置） - 这取决于关于团队构建的产品的性质 - 您可能能够管理它。
我认为像scrum团队（敏捷）一样运行它 - 经常进行审核和调整 - 将帮助您达到正确的平衡。