测试Delphi应用程序的最佳方法

Osa*_*eed 12 delphi testing oracle testcomplete

我有一个Delphi应用程序,它有许多依赖项,并且很难重构它以使用DUnit(它很大),所以我考虑使用像AutomatedQA的TestComplete这样的东西从前端UI进行测试.

我的主要问题是错误修复或新功能有时会破坏之前测试过的旧代码(手动),并且用于工作.

我已经设置了应用程序以使用命令行开关来打开可以测试的特定表单,并且我可以创建一组需要完成的值和点击.

但在我做任何激烈的事情之前我有几个问题......(在购买之前)

  1. 这值得么?
  2. 这是一个很好的测试方法吗?
  3. 测试结果应该在我的数据库(Oracle)中,是否有一种简单的方法可以在testcomplete中检查这些值(多个表中的多个字段)?
  4. 我需要设置一个测试数据库来进行所有自动化测试,是否有一种简单的方法可以自动重新设置测试数据库?除了删除用户级联,创建用户,...,impdp.
  5. testcomplete中是否有一种方法可以为exe指定命令行参数?
  6. 有没有人有类似的经历.

Ali*_*ard 14

我建议你计划同时使用DUnit和TestComplete之类的东西,因为它们各自用于不同的目的.

DUnit非常适合单元测试,但很难用于整体应用程序测试和UI测试.

TestComplete是为数不多的实际支持Delphi的自动化测试产品之一,我们的QA工程师告诉我他们的支持非常好.

请注意,设置自动化测试是一项庞大而耗时的工作.如果您严格应用单元测试和自动UI测试,您可以轻松获得比生产代码更多的测试代码.

对于大型(现有)应用程序,您在实施自动化测试方面处于困难的境地.

我的建议是首先与自动构建服务器一起设置单元测试.每当有人检查任何来源控制时,单元测试都会自动运行.不要试图直接设置所有内容的单元测试 - 这对现有应用程序来说太大了.只要记住在添加新功能时以及何时即将进行更改时都要创建单元测试.我还强烈建议,每当报告错误时,您创建一个单元测试,在您修复之前再现该错误.


Too*_*the 10

我处于类似的情况.(具有大量依赖关系的大型应用程序).几乎没有自动化测试.但是有一个很大的愿望来解决这个问题.这就是为什么我们要解决每个新版本的一些问题.

我们即将发布新产品的第一个版本.而且最初的迹象是好的.但这是很多工作.因此,下一个版本我们确实需要一些方法来自动化测试过程.这就是我已经引入单元测试的原因.虽然由于依赖性,这些都不是真正的单元测试,但你必须从某个地方开始.

我们做的事情:

  • 引入了更多面向对象的方法,因为代码的很大一部分仍然是程序性的.
  • 移动文件之间的东西.
  • 尽可能消除依赖关系.

但是在要求清单上还有更多要求,确保整个团队有足够的工作直到退休.

也许我有点奇怪,但清理代码可能很有趣.没有单元测试的重构是一项危险的任务,特别是如果有很多副作用.我们使用结对编程来避免愚蠢的错误.还有很多测试会议.但最终我们的代码更清晰,引入的新bug数量极低.

哦,确定你知道这是一个昂贵的过程.这需要很多时间.而且你必须对抗连续解决多个问题的倾向.