Testing 软件测试自动化-硕士论文

我正试图写一篇关于软件测试自动化的论文。我计划比较两种记录和编程测试脚本的方法，并讨论几种自动化框架，例如Abbot、Selenium、Yemmy、FEST等。。。在我的论文中，我还将对软件测试技术做一个简短的概述，并可能对自动化测试和软件测试进行比较

编辑：我计划在GUI上测试应用程序的各个方面。因此，我的测试将主要在测试世界的黑盒一侧。我还没有打算写单元测试

目前我读了很多关于不同自动化框架的书，但我可能没有时间回顾所有这些框架。因此，我计划阅读有关他们的文章，使论文更具文学基础

• 你认为这个话题会成功吗
• 关于这个话题，你还有其他想法吗
• 你能推荐文学吗
• 你对这个话题有什么看法

---

我不懂文学，但我认为你们学校图书馆的ACM出版物可能会产生效果。尤其是美国。（也许吧？）

---

对我来说，这确实是一篇很好的硕士论文。当然，你的论文导师是最后的决定者。你应该去和他们谈谈。
作为一篇基于文献的综述，这是一个很好的话题；外面有很多材料。显然，我不打算开始讨论所有细节，因为这是你作为作者的工作。：-）

---

然而，尽管我不熟悉硕士论文的原始研究要求，但这对于博士论文来说肯定是不够的。我会寻找原创作品，你可以添加到这个。一个想法是对测试方法和系统进行分类。您还可以检查测试与正式验证相比的作用。
软件测试自动化是一个大主题，您可能希望缩小您的关注范围，而不是试图涵盖框架、回放/录制、技术概述、自动化与非自动化的混合
关于软件测试自动化的整本书都已经写好了：
• 作为一般性话题
• 专注于功能/特性测试（FIT）
• 关注单元测试
• 关注使用一种特定语言和框架的单元测试
框架针对不同类型的测试：
• 单元测试
  • 测试驱动开发
  • 行为驱动开发
• 特性/功能测试
• GUI测试（Windows、Java GUI、X Windows等）
• 网络测试
• 性能测试
• 安全测试
我会把重点放在框架（或技术，或任何东西）上，而不是试图覆盖它们。或者选择其中的几个区域并进行对比

---

对我来说，回放/录制与手写测试的问题似乎由来已久。在20世纪80年代，供应商喜欢推动Windows GUI自动化的播放/录制。它带来了巨大的演示和巨大的希望。但它也适用于脆性测试和搁置。使用工具开始播放/录制很好，但为了便于维护，通常需要在更高级别编写脚本。这开创了电子表格和基于关键字的方法的新时代，并最终适应了/适合了。
对于一篇硕士论文来说，文献调查应该是一个很好的重点。听起来你只想谈谈黑匣子GUI驱动面向客户的工具，这是一个相当小的利基
正如上面提到的，您/可能/希望有一两页关于整个测试工具世界的内容——单元测试、安全性、负载等。但我认为你很好地定位了你的利基市场
我认为有了一篇6学分的论文，你应该有足够的时间去探索和尝试一些更大的商业和开源工具，以及调查文献。我鼓励您研究商业工具（quick test pro，test complete）和关键字驱动的自动化，例如selenium RC。还有人提到“在GUI后面”进行测试，例如FIT/Fitnesse，这可能值得讨论和评估
我在2008年12月发行的《软件测试与性能》杂志的月刊专栏中介绍了黑匣子、功能测试自动化：
（第7页）
这是一页浅薄的介绍。五句话的介绍是，屏幕记录/回放工具会比较所有内容，因此，如果您的GUI发生了任何变化（即使您只是更改了屏幕分辨率），也可能会返回错误。关键字驱动的工具只检查您告诉他们要检查的内容-如果按钮突然被无故禁用或图标不透明，它们将错过检查
只有人类才善于在每个测试用例结束时检查隐藏的断言“……并且没有发生其他奇怪的事情。”
因此，基于计算机的测试执行和评估可能有一些价值，但它应该是平衡早餐的一部分
其他需要调查的事项：
• 詹姆斯·巴赫的“软件测试自动化蛇油”
• Kaner、Bach和Pettichord的书《软件测试中的经验教训》
• 我关于测试框架的博客文章- （这是谷歌“什么是测试框架”的第四大搜索结果，所以我很乐意推荐它）
• 雷区类比（）
• Doug Hoffman关于测试自动化的论文：
• 测试自动化的经典“shelfware”问题
• blackbox测试自动化社区的一些支持者所推行的反智能主义
• Kaner的黑盒软件测试课程
• 詹姆斯·巴赫的研究/认知/测试
• 上下文驱动的软件测试
• Jon Kohl关于“人与机器”或电子人方法的工作（而不是计算机单独的测试执行和评估）
我希望这会有帮助。
一本好书