如果你的项目只有有限的时间预算,你会把你的团队的时间花在编写非GUI单元测试还是gui自动化端到端测试脚本上?对我来说,我更喜欢gui自动化端到端测试,因为它可以模拟用户的实际操作。
发布于 2011-06-27 10:29:41
编写自动化E2E UI测试的优点,而不是编写单元测试
您不必熟悉特定的实现,甚至不需要熟悉编写自动化UI测试的编码工作原理。许多工具允许您只需单击record,执行某些操作,并保存脚本。
您还将发现更多影响用户的bug,因为您直接从用户的角度处理应用程序。
编写自动化的E2E UI测试而不是单元测试的缺点
自动化的端到端测试并不像真正的单元测试那样易于维护。GUI测试也是如此,因为GUI是程序中最有可能以破坏现有自动化的方式进行更改的部分。
在自动化单元测试中获得100%的代码覆盖率也容易得多,而且您不太可能在每次测试中重复逻辑。如果您得到一个测试失败,它更有可能对应于特定的代码段。相反,如果代码中有一个中断,则不太可能导致多个测试失败。
在这个级别上,你更有可能处理奇怪的角落案例,如果你不直接与代码交互,你永远不会看到这些案例。
将机器设置为在更集成的环境中自动运行测试也要困难得多。对于真正的隔离单元测试,您可以在您的开发机器上运行它们,甚至可以在您的构建机器上运行它们,因为它们应该完全不依赖于运行它们的机器,也不会对运行它们的机器产生影响。
策略
我个人更喜欢让开发人员编写单元测试,这样测试团队就可以专注于更高级别的测试自动化。
您还应该考虑加载/perf/security/fuzz测试。它们本质上是更高的级别,即使不是不可能,也很难手动测试,并且为测试自动化提供了巨大的回报(从小时到严重程度)。它们也是最不可能需要从头开始工作的,因为有几十个现有的工具可以利用。
发布于 2011-06-27 10:50:04
单元测试是可以测试实现的每个方法的功能的测试。进行单元测试的主要原因是让开发人员有信心对代码进行更改,因为他们知道一个地方的更改不会影响其他地方,也不会导致工作代码出现异常。
在您的情况下,您可能希望衡量您是否在项目中看到维护价值(即,您将获得维护阶段合同),如果您看到了,您可能希望将更多的重点放在单元测试上。
单元测试是为更改请求和错误修复提供保证的一种最可靠和明确的方法。:D
发布于 2011-06-27 11:11:51
此视频compares different types of testing techniques.
单元测试更可取,因为:
https://stackoverflow.com/questions/6488075
复制相似问题