总结用于UI测试的时间
我和一个团队合作开发了一个基于网络的软件。我们为该产品编写了~(70-80)硒试验。主要是愉快路径测试和一些回归的错误报告的用户。
这是我们公司第一次进行自动用户界面端到端的测试，这似乎很有帮助。我们也有一些成功的例子，比如在我们使用的库中捕捉到一个严重的倒退(它是由公司的另一个团队开发的)。
无论如何，编写这些测试需要很长时间，部分原因是我们没有使用Selenium或自动UI测试的丰富经验。
经过几个月的开发，我的团队和产品负责人都认为，我们应该统计编写和维护这些测试所花费的时间。(我们通常为Selenium测试做单独的JIRA子任务，这样我们就可以得到一个粗略的数字。)
我担心仅仅这个数字就会给测试留下不好的印象。我们如何产生一个数字与此时间配对，以显示测试的好处，以便我们可以决定它是否值得(或不值得)？
我们可以挖掘JIRA，查找这些测试捕获的bug，但是总结它们记录的工作时间似乎还不够好。修复由自动测试捕获的bug比修复用户报告的发布错误花费更少的时间，还有其他好处，例如，对开发人员来说，更少的中断。此外，在sprint中捕获bug会给开发人员提供更快的反馈，而且通常我们还没有为它们创建单独的JIRA子任务。
总结一下这些时间价值是个好主意吗？
回答 1
Software Engineering用户
发布于 2015-01-18 08:37:47
捕获或修复的bug的数量作为软件度量(它根本不是度量标准)有着非常坏的声誉。只要搜索它，你就会发现一些恐怖的故事。总结这些时间价值确实不会有多大帮助。除了统计数据之外，您还想告诉您的产品所有者如下：
- 您正在使用一个新工具，新方法，您已经设置了一个新的配置来运行测试。这意味着你花了大量的时间学习，这是一项投资。正因为如此，当你在这方面得到越来越多的专家，你花在写这个测试上的时间可能会在未来减少。
- 我假设您和您的团队对这些测试有很好的看法，并且您觉得以这种方式发布产品要安全得多。确保你的PO明白这一点，毕竟你是专家。请强调，在发布前捕获的bug要比在发布后捕获的bug要便宜一个数量级。
- 如果我理解正确的话，你就是在使用scrum。如果您认为您有一种很好的方法来度量团队的吞吐量(在用户故事点或其他方面)，那么您可以建议通过测试来统计它在长期内是如何增长的。
最后的想法:为了使UI测试有效工作，您应该有更多的单元测试和集成测试。您可以在马丁·福勒网页上阅读此内容。
https://softwareengineering.stackexchange.com/questions/270441
复制相似问题
腾讯云开发者
