GUI自动化测试的反思.docx

GUI自动化测试的反思

参加过不同类型的GUI测试项目，其中包括JavaSWING,WebPage,Flash,WinForm,ExcelAddin等。总结起来，有以下几点值得反思的。

通常GUI自动化测试的ROI是非常低的。这些GUI项目大多都经常改变界面，甚至每几个月都需要更改界面，这使得自动化测试用例管理和维护变得非常复杂。GUI自动化最大的弊病在于：它发现Bug的可能性很小，在这些的GUI项目中，通过自动化用例发现的Bug屈指可数，99%失败的用例都是由于环境或则测试用例本身的原因导致的，而不是发现任何产品Bug。当然，不同项目有不同的特性，BrainMarick有一篇全面关于评估是否自动化测试的文章，可以帮助作出决定。

AlanPage是微软的第一个测试架构师(TestArchitect,2001)，现在负责微软测试的EE工作。他最著名一句话就是“95%的GUI自动化测试工作都是浪费时间”，他本来写的99%，但是为了表示他并非反对GUI自动化测试，他把这个数字改成了95%。

GUI自动化测试可以提高测试人员的士气。有些测试人员不愿意单单做手工测试，他们需要一些挑战，自动化测试是最好的任务。对于自动化测试，测试人员总是可以根据自己的能力，完成自动测试用例的开发和部署。提高测试人员的士气，比这些自动化测试本身更加有意义。所以，在一定程度上引入自动化测试，是对项目组有好处的。

GUI自动化测试无法代替手动测试，无法模拟用户的行为。对于GUI测试，我相信手工测试仍然是最重要的测试方法，测试人员在测试GUI软件过程中，有不同操作方法和不同的次序，所有这些变化是一个巨大的组合，无法通过自动化测试完成，很多情况下，也没有必要通过自动化完成。测试人员在手工操作软件过程中，每一步骤都通过思考来验证当前状态的正确性，而这些复杂的思考无法简单快速的转成自动化用例的验证部分。

GUI自动化测试的进度往往是无法按时完成的。很多测试人员在制定GUI自动化测试的初期，往往过于乐观，希望通过自动化覆盖尽可能多的测试用例。但是，在项目执行的后期，他们发现需要忙于手工测试，另外产品也不稳定，无法顺利完成既定的自动化测试用例，总有很多客观的理由无法完成最初的计划。通常这个时候，他们会改变计划，减少自动化测试用例的数量，而将自动化测试用例仅仅用于基本测试(BVT,BuildVerificaitionTest)。这些计划的改变，某种意义来说，也是测试资源的浪费。

进行GUI自动化测试并非难事，但是如何利用自动化测试来进行高效的GUI测试工作是需要丰富的经验。

如何开展有效的自动化测试

[2010-3-1614:11:00|By:贺忻]

如何开展有效的自动化测试

很多时候测试人员在开展自动化测试的时候都是不加思考的就开始做，认为用工具录几个脚本再回放就可以了，没有考虑有效性；而做了并不一定就会有效果，如果自动化测试在整个测试工作中发挥不了作用，那么哪怕是只投入了很少的成本也是在浪费资源。所以在开展自动化测试之前必须认真思考虑一些问题，以确保它的有效性：

1、被测系统是否适合做自动化测试；

2、被测系统适合在哪些环节做自动化测试；

3、使用何种测试工具、测试框架；

4、开展自动化测试需要哪些资源，包括：人员、机器、时间；

5、当前可用或是可以申请到的资源；

6、如何在不影响日常测试工作的前提下，开展自动化测试工作。

1、被测系统是否适合做自动化测试。很多人可能都回觉得这个问题有些多余，不需要考虑。可事实上作为一名测试主管必须考虑这个问题，应为自动化测试并非只是做与不做这么简单，而是需要考虑成本投入与效果产出。不管是做软件、做系统、还是做网站，最终的目的基本上都是要盈利的，要盈利就必须控制成本，提高利润。所以在测试工作中也必须考虑到成本投入。

如何确定系统是否适合做自动化测试呢？个人认为主要考虑当前的被测项目是长期的还是短期？如果被测项目是在今后半年或者几年间要不断进行开发维护的，那么就需要重复的进行大量的回归测试，这种情况下如果有自动化的回归测试体系就可以节省成本投入；如果被测项目是短期的，比如说一个月，或几个月，同时如果开发自动化测试又不是很容易，也没有足够的时间去做这件事，那么就完全没有必要作自动化测试，费尽力气做出的自动化测试脚本，可能只会用到一次或两次，这样就很不值当。

2、被测系统适合怎样的自动化测试。自动化测试覆盖的范围很广：单元测试、集成测试、接口测试，GUI测试等等都可以实现自动化执行；同时，不同的系统情况是不一样，有的适合或是可以做GUI的自动化测试，有的可能只适合做接口的自动化测试