测试MS Access应用程序的最佳方法？
使用同一数据库内的代码，表单和数据，我想知道为Microsoft Access应用程序(例如Access 2007)设计一套测试的最佳实践是什么。
测试表单的主要问题之一是只有少数几个控件具有一个" hwnd"句柄，而其他控件仅具有一个它们具有焦点的控件，这使自动化变得相当不透明，因为我们无法获得要执行的表单上的控件列表。
有经验可以分享吗？
解决方案
回答
我会将应用程序设计为在查询和vba子例程中进行尽可能多的工作，以便测试可以由填充测试数据库，针对这些数据库运行生产查询和vba的集合组成，然后查看输出和比较以确保输出良好。这种方法显然无法测试GUI，因此我们可以使用一系列手动执行的测试脚本(这里的意思是像打开文档1的Word文档，然后单击控件1)来扩大测试范围。
它取决于项目的范围以及测试方面所必需的自动化程度。
回答
我还没有尝试过，但是我们可以尝试将访问表单作为数据访问网页发布到诸如共享点之类的网页上，或者仅作为网页发布，然后使用诸如selenium之类的工具通过一系列测试来驱动浏览器。
显然，这不像直接通过单元测试来驱动代码那样理想，但是它可能会让我们有所作为。祝你好运
回答
MS已弃用Data Access Page已有相当长的一段时间了，但从一开始它就从来没有真正起作用过(它们依赖于所安装的Office Widget，并且只能在IE中使用，然后才严重)。
确实，可以获得焦点的Access控件只有在获得焦点时才具有窗口句柄(而那些不能获得焦点的控件(例如标签)根本就没有窗口句柄)。这使得Access特别不适用于窗口句柄驱动的测试方案。
确实，我质疑我们为什么要在Access中进行这种测试。在我看来，这听起来像是基本极限编程教条，但并非XP的所有原理和实践都可以适应Access应用程序-方钉，圆孔。
因此，退后一步，问问自己我们要完成的工作，并考虑与基于Access中无法使用的方法的方法完全不同的方法。
或者，这种自动测试对于Access应用程序是否完全有效或者什至有用。
回答
Access是一个COM应用程序。使用COM，而不是Windows API。测试Access中的内容。
Access应用程序的最佳测试环境是Access。我们所有的表单/报表/表格/代码/查询都可用，有一种类似于MS Test的脚本语言(好吧，我们可能不记得MS Test)，有数据库环境可以保存测试脚本和测试结果，我们在这里建立的技能可以转移到应用程序中。
回答
我感谢诺克斯和大卫的回答。我的答案将介于两者之间：只需编写不需要调试的表格即可！
我认为表单应基本上按其原样使用，仅意味着图形界面，这意味着它们不必调试！这样，调试工作就仅限于VBA模块和对象，这很容易处理。
当然，有一种自然的趋势是将VBA代码添加到窗体和/或者控件中，特别是当Access为我们提供了这些很棒的"更新后"和"更改时"事件时，但是我绝对建议我们不要放置任何窗体或者控件特定的代码在表单的模块中。这使得进一步的维护和升级非常昂贵，其中代码在VBA模块和表单/控件模块之间划分。
这并不意味着我们不能再使用此AfterUpdate事件！只需将标准代码放入事件中，如下所示：
Private Sub myControl_AfterUpdate()
CTLAfterUpdate myControl
On Error Resume Next
Eval ("CTLAfterUpdate_MyForm()")
On Error GoTo 0
End sub
在哪里：
- " CTLAfterUpdate"是每次以表格形式更新控件时都会运行的标准过程
- CTLAfterUpdateMyForm是每次在MyForm上更新控件时都会运行的特定过程
然后，我有2个模块。第一个是
utilityFormEvents，我将在其中拥有我的CTLAfterUpdate泛型事件
第二个是
- " MyAppFormEvents"包含MyApp应用程序所有特定形式的特定代码，并包括CTLAfterUpdateMyForm过程。当然，如果没有要运行的特定代码，则CTLAfterUpdateMyForm可能不存在。这就是为什么我们将"打开错误"改为"继续下一个"的原因...
选择这样的通用解决方案意义重大。这意味着我们正在达到较高的代码规范化水平(意味着可以轻松进行代码维护)。当我们说我们没有任何特定于表单的代码时，这还意味着表单模块已完全标准化，并且其生产可以自动化：只需说出我们要在表单/控件级别上管理的事件，然后定义通用/特定程序术语。
一劳永逸地编写自动化代码。
这需要花费几天的时间，但是却能带来令人兴奋的结果。在过去的两年中，我一直在使用此解决方案，这显然是正确的解决方案：我的表单是完全自动地从头开始创建的，并带有与"控件表"链接的"表单表"。
然后，我可以花时间处理表格的特定程序(如果有)。
即使使用MS Access，代码规范化也是一个漫长的过程。但这确实值得付出痛苦！
回答
Access作为COM应用程序的另一个优点是，我们可以创建一个.NET应用程序，以通过自动化来运行和测试Access应用程序。这样做的好处是，我们可以使用功能更强大的测试框架(例如NUnit)针对Access应用编写自动断言测试。
因此，如果我们精通Cor VB.NET和NUnit之类的工具，则可以更轻松地为Access应用程序创建更大的测试范围。
回答
如果我们有兴趣在更详细的级别(尤其是VBA代码)上测试Access应用程序，则VB Lite单元是用于此目的的出色单元测试框架。
回答
这里有很好的建议，但我很惊讶没有人提到集中式错误处理。我们可以获得用于快速功能/子模板化和添加行号的插件(我使用MZ工具)。然后将所有错误发送到一个函数中，我们可以在其中记录它们。然后，我们还可以通过设置一个断点来解决所有错误。
