测试 – 软件测试自动化 – 硕士论文[已结束]

我正在写一篇关于软件测试自动化的论文.我计划比较两种测试脚本的记录和编程方法,并讨论几种自动化框架,例如Abbot,Selenium,Yemmy,FEST等等.另外在我的论文中将简要介绍一下软件测试技术和也许是自动化测试与软件测试的比较.

编辑：我计划通过它的GUI测试应用程序的方面.所以我的测试主要是在测试世界的Blackbox一侧.我没打算写关于单元测试的文章.

在片刻,我几乎阅读了不同的自动化框架,但我可能没有时间审查所有这些.因此,我打算阅读它们,并使论文更多地以文学为基础.

>您认为这个主题能否成功？
>您对此主题有任何其他想法吗？
>你能推荐文学吗？
>您对此主题有何看法？

文献调查应成为MS论文的重点.听起来你只想谈谈黑盒子GUI驱动面向客户的工具,这是一个相当小的利基.

您/可能/想要在整个测试工具世界中拥有一两页 – 单元测试,安全性,负载等,如上所述.但我认为你很好地瞄准了你的利基市场.

我认为有了6个学分的论文,你应该有足够的时间来探索和试用一些更大的商业和开源工具以及调查文献.我鼓励您研究商业工具(快速测试专家,测试完成)以及关键字驱动的自动化 – 例如selenium RC.其他人提到测试“幕后GUI”,例如FIT / Fitnesse,可能值得讨论和评估.

我在2008年12月的软件测试和性能杂志中的每月专栏中介绍了黑盒,功能测试自动化：

http://www.stpmag.com/issues/stp-2008-12.pdf(第7页)

那是一页刮擦表面介绍.五句话的介绍是屏幕记录/回放工具比较一切,所以如果你的GUI发生任何变化(即使你只是改变了屏幕分辨率),它可以作为错误的错误返回.关键字驱动的工具只检查你告诉他们检查的内容 – 如果一个按钮突然被禁用,或者图标不透明,他们会错过.

在每个测试用例结束时,只有一个人善于检查隐藏的断言“……没有其他奇怪的事情发生.”

因此,基于计算机的测试执行和评估可以有一些价值,但它应该是均衡早餐的一部分.

其他需要注意的事项：

> James Bach的“软件测试自动化蛇油”
> Kaner,Bach和Pettichord的书“软件测试中的经验教训”
>我关于测试框架的博客文章 –
http://xndev.blogspot.com/2007/09/whats-test-framework.html(这是“什么是测试框架”的4号谷歌结果,所以我很乐意推荐它)
>雷区类比(http://www.testingperspective.com/tpwiki/doku.php?id=minefield)
> Doug Hoffman关于测试自动化的论文：
http://www.softwarequalitymethods.com/H-Papers.html
>测试自动化的经典“货架软件”问题
>黑盒测试自动化社区的一些支持者推动了反智主义
> Kaner的Black Box软件测试课程
>詹姆斯巴赫的工作/认知/测试
>上下文驱动的软件测试
> Jon Kohl关于“人与机器”的工作,或者是机器人方法(而不是仅用于计算机的测试执行和评估)

我希望有所帮助.