logo标签列表

基于Web的项目的自动化测试

testingautomated-tests
8

最近我有一个问题，就是是否值得花费开发时间来生成基于Web的项目的自动化单元测试？我的意思是，在某些时候它似乎是没有用处的，因为这些项目的定位是与用户/客户进行交互，所以你无法预测整个可能的用户操作集，以便检查所显示内容的正确性。即使是回归测试也很难完成。
所以我非常渴望知道其他有经验的开发人员的意见。

7个回答
4
2
是的，确实如此。我上周在处理一个网站时遇到了问题。我最近切换了数据访问层，并为我的控制器和存储库设置了单元测试，但没有对UI交互进行测试。
我被一个非常明显的错误所困扰，如果我有集成测试，这个错误会很容易发现。只有通过集成测试和UI功能测试，您才能发现应用程序不同层之间的交互方式存在的问题。
我赞同这个观点。直到它拯救了你的生命，你才会意识到它的价值。然后你会想知道以前没有它你是怎么睡得安稳的。 :) - cwash
好的，但是你所说的集成测试是什么意思？你会如何进行它？ - Artem Barger
集成测试测试端到端的功能。普通单元测试只测试您希望测试的函数/方法，不涉及其他内容。 例如，要对业务逻辑中从数据库获取客户列表的方法进行单元测试，您将模拟数据库。 然而，集成测试将一直到达数据库并返回，以测试它们如何协同工作。在网页上也是一样。使用WATIN或Selenium，您可以实际访问要测试的网页，并确保数据正确返回等。测试将练习您代码的所有层。 - Doanair
1
我不会花太多时间进行自动化的网络浏览器测试，但我认为它提供了很多价值，特别是对于你“关键路径”函数（你真正关心的函数）。 - Doanair
@Doanair 没错，最好的情况是它们根本没有太多变化。一定要使用自动化浏览器测试来覆盖这些情况。可以从你手动检查的内容中创建一个便宜的回归测试套件。 - cwash
2
如果你在大量编写JavaScript代码，最近出现了很多JS测试框架可用于单元测试你的JavaScript。除此之外，使用Canoo、HtmlUnit、Selenium等工具测试Web层更多是功能或集成测试而不是单元测试。如果UI频繁变化，则这些测试可能难以维护，但它们确实非常有用。记录Selenium测试很容易，并且你可以让其他人（测试人员）帮助你创建和维护。只需知道，维护测试需要付出代价，并且需要平衡考虑。网页层有其他适合的测试类型 - 特别是模糊测试，但很多好的选项都是商业工具。其中一个开源工具，可插入Rails中，称为Tarantula。在持续集成过程中运行类似于此的Web层工具很好，也不需要太多维护。
取决于你在做什么。如果你正在将许多规则/功能放入自定义Javascript中，现在有一些BDD风格的框架可供使用。ScrewUnit是我以前玩过的一个。FireUnit内置于Firebug中，适用于一般测试。但不太适合自动化或持续运行。JSUnit是一个很好的通用工具。如果你正在使用Prototype，请查看Script.aculo.us中的unittest.js；如果你正在使用JQuery，请查看QUnit。 - cwash
还有Test.Simple。我刚刚将其与Selenium连接起来，以便可以从命令行自动化和解释，因此可以进行自动烟雾测试。http://use.perl.org/~schwern/journal/39088 - Schwern
这看起来也很不错： http://misko.hevery.com/2009/05/22/yet-another-javascript-testing-framework/ - cwash
2

这取决于您的Web应用程序的结构和架构。如果它包含一个应用逻辑层，那么该层应该很容易使用自动化工具（如Visual Studio）进行单元测试。此外，使用已经被设计为支持单元测试的框架，例如ASP.NET MVC，会非常有帮助。

没错，但我不是在谈论应用程序逻辑层。每个应用程序层单元都很容易测试，但它们在客户端/浏览器上的集成则更加复杂，而且花费时间覆盖总体可能性的5-10％似乎有点无用。开发用户场景并相应地进行测试似乎更为常见。 - Artem Barger
2
你无法预测用户可能采取的所有行动，因此你需要检查所显示内容的正确性。
你不能预测代码将要处理的所有可能数据，或者在使用线程时出现的所有可能的竞争条件，但你仍然需要进行单元测试。为什么？因为你可以大大缩小范围。你可以预测会发生的一些病态情况。你只需要花点时间思考并积累经验。
用户交互也是如此。有些事情用户会尝试做，无论是病态的还是正常的，你都可以预测到。用户只是输入了特别有创意的数据。你会发现程序员往往会一遍又一遍地错过同样的条件。我有一个清单。例如：将Unicode注入到所有内容中；将开始日期放在结束日期之后；输入无意义的数据；将标签放在所有内容中；省略尾部换行符；尝试两次输入相同的数据；提交表单，返回并再次提交；拿一个文本文件，将其命名为foo.jpg并尝试将其作为图片上传。你甚至可以编写一个随机切换开关和按按钮的程序，一个坏猴子，它会找到各种有趣的错误。
通常很简单，只需要让不熟悉软件的人坐下来使用它。抑制纠正他们的冲动，只是观察他们如何挣扎。这非常有教育意义。Steve Krug将此称为“高级常识”，并写了一本名为《别让我思考》的优秀书籍，介绍了便宜、简单的用户交互测试。我强烈推荐阅读。这是一本非常简短而又开阔眼界的读物。
最后，如果客户的期望得到了充分准备，他们本身可以成为一个非常好的测试套件。确保他们理解这是一个正在进行中的工作，它会有漏洞，他们正在帮助改善他们的产品，并且绝对不应该用于生产数据，并让他们尝试您的产品的预发布版本。他们会做出各种你从未想过的事情！他们将是你所拥有的最好和最真实的测试，而且还是免费的！给他们一个非常简单的方式来报告错误，最好只是在应用程序上放置一个按钮框，自动提交他们的环境和历史记录；Hiveminder上的反馈框是一个很好的例子。快速而礼貌地回应他们的错误（即使只是“谢谢信息”），你会发现他们会很高兴你对他们的需求如此敏感！
1

单元测试在TDD过程中是有意义的。如果您不进行测试优先开发，则它们没有太多价值。然而，验收测试对软件质量来说非常重要。我认为验收测试是开发的圣杯。验收测试显示应用程序是否满足要求。我如何知道何时停止开发功能——只有当所有验收测试都通过时才能停止。验收测试自动化非常重要，因为每次对应用程序进行更改时，我不必手动执行所有测试。经过数月的开发，可能会有数百个测试，手动运行所有测试变得不可行（有时甚至不可能）。那么，我如何知道我的应用程序仍然有效？

自动化验收测试可以使用xUnit测试框架来实现，这在这里会引起混淆。如果我使用phpUnit或httpUnit创建验收测试，那么它是单元测试吗？我的答案是否定的。无论我使用什么工具来创建和运行测试，验收测试都是展示功能是否符合要求的测试。而单元测试则是展示一个类（或函数）是否满足开发者的实现想法的测试。单元测试对客户（用户）没有价值，而验收测试对客户（因此对开发者，记住客户亲和）有很大的价值。

因此，我强烈建议为Web应用程序创建自动化验收测试。

验收测试的好框架包括：

  • Sahi（sahi.co.in）
  • Silenium
  • Simpletest（它是一个用于php的单元测试框架，但包括可用于验收测试的浏览器对象）。

然而

您提到网站与用户互动有关，因此测试自动化无法解决可用性的整个问题。例如：测试框架显示所有测试都通过了，但是由于在

中意外使用了style="display:none"，用户无法看到表单、链接或其他页面元素。自动化测试之所以通过是因为文档中存在
，测试框架可以“看到”它。但是用户却看不到，手动测试会失败。

因此，所有Web应用程序都需要手动测试。自动化测试可以大大减轻测试工作量（80%），但手动测试对于最终软件的质量同样重要。

至于单元测试和TDD——它提高了代码质量。这对开发人员和项目的未来（即长达几个月的项目）都有好处。然而，TDD需要技能。如果您具备这种技能，请使用它。如果您没有考虑获得这种技能，但要注意获得这种技能需要花费的时间。通常需要3-6个月才能开始创建良好的单元测试和代码。如果您的项目将持续一年以上，我建议学习TDD并投入时间进行适当的开发环境。

我不同意有关单元测试在TDD过程中有意义的说法。单元测试总是有很多理由值得做。 - Artem Barger
0
很不幸，我没有足够的声望在这里粘贴参考资料，所以您可以在 Github 的 README 中查看它们。 - GyulaWeber
虽然这个链接可能回答了问题，但最好在此处包含答案的基本部分并提供参考链接。仅有链接的答案如果链接页面发生更改可能会变得无效。 - Mamoun Benghezal
你说得没错，但这只是一个示例代码，我不知道如何在没有链接到GitHub或其他页面的情况下分享它。我认为最好从一个可以直接尝试的示例开始。你觉得怎么样，我应该写下解决方案的关键点，并将此代码作为示例呈现吗？ - GyulaWeber
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接