集成测试 - 寻求您的知识,建议和链接!

时间:2010-03-01 15:52:36

标签: language-agnostic testing integration-testing

嘿伙计们,我正在为网络应用程序的集成测试提供一些建议和指导。我们的项目已经运行了很多年,而且相当复杂。我们已经很好地完成了单元测试,但我们缺少一套不错的集成测试。除了我们的单元测试之外,我们没有记录用例甚至是一组合理的测试用例。今天的“集成测试”包括开发人员对变更可能产生的影响以及对应用程序进行手动,临时测试的了解。这真的不太理想 - 我们现在想要设计和自动化一组可靠的测试,以便我们进行回归测试并增加我们对应用质量的信心。

我们最终构建了一个平台(基于Selenium),以便我们快速创作并自动执行测试。现在的问题是:我们没有任何测试,页面确实空白。该系统有大约30个类,它们相互作用并影响UI。对于新用户注册,可以设置大约40个属性,每个属性都会影响体验。在用户生命周期内,他们将生成更多的状态。鉴于如此多的变量和可能的状态,这是一个令人生畏的开始前景,这可能是迄今为止它被忽视的原因。

没有一套体面的测试的痛苦现在变得具有破坏性。我正在花时间修复这个问题 - 我正在对测试的创作提出一些实用的建议。你们是如何接近它的?你有任何我认为有用的链接吗?对于用户的数据,我如何能够停止看似无穷无尽的状态?如何清除失败的边缘情况(我们的用途似乎在寻找)?

帮助!

1 个答案:

答案 0 :(得分:4)

如果大量的组合阻碍了您尝试生成测试用例,那么您应该明确地看一下 all-pair测试

我们已经使用来自microsoft的PICT作为成功减少测试用例数量的工具,同时仍然对大多数案例都有合理的信心。

  

全对测试背后的原因   是这样的:最简单的错误   程序通常由a触发   单输入参数。下一个   最简单的错误类别包括   那些依赖于互动的人   在参数对之间,可以   被所有对测试抓住。1   涉及之间相互作用的错误   三个或更多参数是   逐渐减少共同2,同时   同时正在逐步进行   通过详尽的找到更昂贵的   测试,其中有限制   所有可能的详尽测试   输入。