集成测试-寻求您的知识，建议和链接！ [英] Integration testing - seeking your knowledge, advice and links!

问题描述

大家好，我正在寻求有关Web应用程序集成测试的一些建议和指示.我们的项目已经运行了很多年，而且相当复杂.我们已经很好地覆盖了单元测试，但是却缺少了一套不错的集成测试.除了单元测试之外，我们没有记录用例，甚至没有合理的测试用例集.今天的集成测试"包括开发人员对更改可能产生的影响的了解以及对应用程序的手动即席测试.这真的不是理想的-我们现在要设计和自动化一套可靠的测试，以允许我们执行回归测试并增强对应用程序质量的信心.

Hey guys, I'm after some advice and pointers on integration testing for a web app. Our project has been running for a number of years and it's reasonably complex. We're pretty well covered with unit tests but we're missing a decent set of integration tests. We don't have documented use cases or even a reasonable set of test cases beyond our unit tests. 'Integration testing' today consists of the developer's knowledge of the likely impact of a change and manual, ad-hoc testing of the app. It's really not ideal - we now want to design and automate a solid set of tests to allow us to perform regression testing and increase our confidence in the quality of the app.

我们终于建立了一个平台(基于Selenium)，使我们能够快速编写和自动化测试的执行.现在的问题是:我们没有任何测试，页面完全空白.该系统具有大约30个相互影响并影响UI的类.对于新用户注册，可以设置大约40个属性，每个属性都会影响体验.在用户生命周期中，它们将生成甚至更多的状态.考虑到如此多的变量和可能的状态，开始它是一个令人生畏的前景，这可能就是为什么到目前为止它一直被忽略的原因.

We've finally built a platform (based on Selenium) to allow us to quickly author and automate the execution of the tests. The problem now: we don't have any tests, the page is well and truly blank. The system has around 30 classes which interact with each other and influence the UI. For a new user signing up there's about 40 properties that can be set, with each once impacting the experience. Over the user life time they'll generate even more states. Given so many variables and possible states it's a daunting prospect to get started, which is probably why it's been neglected thus far.

没有一套像样的测试的痛苦现在变得具有破坏性.我专用于解决此问题的时间-我正在寻求有关编写测试的一些实用建议.你们如何看待它?您有任何我认为有用的链接吗?我如何才能停止为用户数据看似数量众多的状态而烦恼呢?我该如何清除出现故障的边缘情况(以及我们似乎正在发现的用途)?

The pain of not having a decent set of tests is now becoming destructive. I'm dedicating time to get this problem fixed - I'm after some practical advice on the authoring of the tests. How do you guys approach it? Do you have any links I may find useful? How can I stop my mind running away with the seemingly infinite number of states for a user's data? How can I flush out the edge cases which are failing (and our uses seeming to be finding)?

帮助！

推荐答案

如果正是纯粹的组合数量使您无法尝试生成测试用例，则应明确查看 所有配对测试.

If it is the sheer amount of combinations that is holding you back in trying to generate testcases, you should definitly take a look at all-pair testing.

我们已使用Microsoft的 PICT 作为成功使用的工具尽量减少测试用例的数量，同时仍然有足够的信心覆盖大多数案例.

We have used PICT from microsoft as a tool to successfully minimize the amount of testcases while still being reasonable confident to have most cases covered.

全对测试背后的原因 是这样的: 程序通常是由 单个输入参数.下一个 最简单的错误类别包括 那些依赖互动的人 在参数对之间，可以 进行全对测试. 1 涉及交互之间的错误 三个或更多参数是 2 ，而 同时逐渐 通过穷举找到更昂贵 测试，它的局限性在于 详尽测试所有可能 输入.

the reasoning behind all-pairs testing is this: the simplest bugs in a program are generally triggered by a single input parameter. The next simplest category of bugs consists of those dependent on interactions between pairs of parameters, which can be caught with all-pairs testing.1 Bugs involving interactions between three or more parameters are progressively less common2, whilst at the same time being progressively more expensive to find by exhaustive testing, which has as its limit the exhaustive testing of all possible inputs.

这篇关于集成测试-寻求您的知识，建议和链接！的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！