我正在尝试写一篇关于软件测试自动化的论文。我计划比较两种测试脚本的记录和编程方法，并讨论几个自动化框架，例如 Abbot、Selenium、Yemmy、FEST 等……在我的论文中还将简要概述软件测试技术和也许是自动化测试与软件测试的比较。
编辑：我计划在其 GUI 上测试应用程序的各个方面。所以我的测试主要是在测试世界的黑盒方面。我还没有打算写单元测试。
目前，我阅读了很多关于不同自动化框架的信息，但我可能没有时间查看所有这些。所以我计划阅读它们并使论文更加基于文学。
对文献的调查应该是 MS 论文的重点。听起来您只想谈论黑盒 GUI 驱动的面向客户的工具，这是一个相当小的利基市场。
您/可能/想要在整个测试工具世界中有一两页 - 单元测试，安全性，负载等，正如上面提到的那样。但我认为你很好地瞄准了你的利基市场。
我认为对于一篇 6 学分的论文，你应该有足够的时间来探索和尝试一些更大的商业和开源工具以及调查文献。我鼓励您研究商业工具（快速测试专家，测试完成）以及关键字驱动的自动化 - 例如 selenium RC。其他人提到“在 GUI 之后”进行测试，例如 FIT/Fitnesse，这可能值得讨论和评估。
我在 2008 年 12 月的软件测试和性能杂志的月刊专栏中介绍了黑盒、功能测试自动化：
http://www.stpmag.com/issues/stp-2008-12.pdf（第 7 页）
那是一页纸的粗浅介绍。五句话的介绍是屏幕记录/播放工具会比较所有内容，因此如果您的 GUI 发生任何变化（即使您只是更改屏幕分辨率），都可能会作为错误错误返回。关键字驱动的工具只检查您告诉他们检查的内容——如果按钮突然无故禁用或图标不透明，它们就会错过。
只有人类擅长在每个测试用例结束时检查隐藏的断言“......并且没有发生任何其他奇怪的事情。”
所以基于计算机的测试执行和评估可能有一些价值，但它应该是均衡早餐的一部分。
其他需要调查的事情：
我希望这会有所帮助。
软件测试自动化是一个很大的话题，您可能希望缩小关注范围，而不是尝试涵盖各种框架、回放/记录、技术概述、自动化与非自动化。
关于软件测试自动化的整本书都写过：
框架针对不同类型的测试：
我会考虑专注于其中一个领域的框架（或技术，或其他），而不是试图涵盖所有领域。或者选择其中几个区域并进行对比。
播放/记录与手写测试的问题对我来说似乎很老。在 1980 年代，供应商喜欢推动 Windows GUI 自动化的播放/录制。它带来了很棒的演示和寄予厚望。但它也适用于脆性测试和搁板。回放/记录可以很好地帮助您开始使用工具，但为了便于维护，您通常需要编写更高级别的脚本。这开启了电子表格和基于关键字的方法的新时代，并最终迎来了 FIT/FitNesse。
作为基于文献的评论，这是一个很好的话题；那里有很多材料。显然，我不会开始讨论所有细节，因为那是你作为作者的工作。:-)
但是，虽然我不熟悉硕士论文的原始研究要求，但这对于博士论文来说肯定是不够的。我会寻找您可以添加到此的原创作品。一个想法是测试方法和系统的分类。与形式验证相比，您还可以检查测试的作用。
如果可以在线获得，我将有兴趣阅读该论文。值得考虑以编程方式访问 GUI - Web 和应用程序。然后是 Selenium 或 WatiR 等录制和播放工具。当然，自动化的利弊——工具的局限性（例如，大多数人无法查看 Java 小程序或网页上的 Flash）以及一些人在自动化时忘记的最重要的事情——并非所有事情都应该自动化！
但是，如果您有可能对此发表评论，以便在完成时通知我们，我真的很想读一读。
今年刚刚出版了一本关于测试自动化的优秀书籍：“实施自动化测试”，Elfriede Dustin、Thom Garrett 和 Bernie Gauf、Addison Wesley。