最近，完成了Framework自动升级的设计和构建，虽然有很多不尽人意的地方，但是也算是应用项目自动化测试的一个起步了。

              从我进入公司开始，就一直在研究自动测试，但是复杂的应用程序流程，多变的客户需求，以及自动测试工具的种种局限，当然还有个人技术水平的影响，都无法让应用产品的自动化程度达到一个令人满意的程度。虽然写了无数个自动测试的脚本函数，虽然完成了很多个项目的自动测试Project，但是始终都只是停留在“自动化手工操作”这样一个层次。我深知自动测试的概念远比我们已经做到的要更加的深刻，却也无能为力。完成的自动测试脚本永远不能覆盖全部的应用程序测试点，为什么呢？总结一下，原因有以下两个方面：

              1：没有选择正确的自动测试的切入点：应用项目和产品不同，其中的环节有很多相关的联系，而我们在进行自动测试脚本的设计的时候，往往只是停留在用户操作的基础上进行，而忽略了内部这些互相影响的环节。也就是说，自动测试开始进行的切入点不正确，没有将要测试的内容模块化。这一点是造成现在的测试脚本不能完全发现问题的主要原因。如果能完成一定数量的单元测试脚本，自动测试就不会总是停留在“冒烟测试”“回归测试”这些方面，而是能真正的起到发现Bug的作用了。

              2：没有选择正确的测试自动化内容：这一点是在完成了Framework的自动升级测试脚本后，我才感受到的。以前做自动测试，基本上是把我会进行手动操作的地方全部用自动测试脚本实现一遍，而实际上因为缺少一些数据的验证，功能点的检查。即使有了错误也无法发现。而实际上对这些操作的验证，可能完成自动脚本的时间远比手动操作要费时费力。而对于某些操作，自动测试能够最大程度的提高效率和发现问题。比如smartdownload，如果让测试人员自己去设定一些service，运行客户端成后，检查客户端下载的文件和服务端的文件版本，日期是否正确，如果不借助工具完成，会是一件非常费力的事情。但是如果是由自动测试完成这些工作，不但提高测试效率，而测试结果真实可靠。再比如LeyserUpdater的运行，先撇开升级后的环境是否正确，单单执行这个操作，如果是从一个stage环境升级，需要大概30分钟，如果是虚机运行或者有多个产品同时升级，可能时间更长。而每天完成了Build后，测试人员往往是早上到达公司才开始升级测试环境，如果还要包括stage环境的恢复等操作，可能时间更长，而实际上这部分操作主要是Copy虚机，Copy文件，执行Leyserupdater这些操作，那么它的可自动化程度就很高。相信现在已经搭建好的每日Build后自动升级的环境，应该能带给Framework测试人员一些益处。所以说，选择一个正确的自动测试内容，也是自动化测试成功的一个基础。

              自动化测试的历程是艰辛的，因为有很多我们不清楚地地方需要继续的发掘，但是在经历了多次的失败后，能总结出一些有益的东西就是成功的。还有很多我们不了解的地方，也许还在走弯路，但是我相信只要善于总结，善于探索，这条艰难的道路总有一天会变得简单…

3月中旬，我就要离开我曾经以为自己会长期驻守的Grapecity了，也许因为这家公司带给我很多不一样的感受，也许因为年龄增长让我已经趋向于稳定的生活，离开这家公司，的确给我很多莫名的伤感和遗憾。

从进入公司开始，我就一直很开心，就算工作中有很多的不愉快和烦恼，面临的加班，工作压力以及机械的工作方式等等，在公司如大家庭般的感受中都无足轻重，我曾经很自豪的向朋友们宣扬，我不会再换工作了，再换就只能出国了...现在想来的确有些幼稚和冲动，可是Grapecity的确有很多吸引我留下来的因素，朋友的热情，年轻而富有朝气的公司文化，甚至于有些像私人别墅的工作环境，都让我无法割舍。在这里我只待了短短的两年，可是留下了记忆却比我在任何一家公司都多，聚餐，看球赛，春游，唱歌，开运动会，打羽毛球等等，都让我无法忘记Grapecity...可是,我还是选择了离开，我不得不承认，自己在爱玩爱闹的同时，还是希望自己的职业生涯更加的精彩，而不是仅仅停留在开心和愉快上。坦白说，生活对于我，没有太大的压力，我总是自己任意的选择自己的职业道路。一直崇尚着开心就好，可是我也不得不面对自己周围朋友，同学，父母，孩子带给我的无形的压力，我可以甘于现状，只要自己快乐，可是每当我看到自己的朋友有着比自己更高的职位，比自己更好的机遇，和我高谈着人生将来的目标时，我就很自卑，尽管我比他们轻松，我比他们快乐，可是我做不到坦然面对。我想这个就是我离开的主要原因吧。既然Grapecity不能给我更多的机会发展，我就不能继续的等待。每个人的激情一生或许只有几次，这一次，就让我的激情战胜自己的惰性吧。

每个人对自己的人生都有不同的要求，你愿意选择哪一种人生呢？衷心祝愿大家未来的路会越来越宽，永远不会后悔自己的选择...

这几天一直在考虑如何完成测试环境的自动更新。以前我们都是作虚机，但是也只限于IIS环境作虚机，因为2005serverPC的虚机有时在回滚后回出现无法登陆域的状况，只能退出域后修改机器名称。而SqlServer所在机器如果更名会有很多的问题，因此每次IIS环境回滚后，需要重新恢复Sqlserver上的测试数据（客户提供的测试数据）。这样基本上每天要花费至少半个小时的时间，有时遇到IIS机器回滚后不正常就的至少一个小时的时间才能做好测试环境。而且，我们虽然是每日Build，但是却没有每日冒烟测试，所以有很多testcase每天都要重复的作才能保证当日的Build没有问题。现在我已经完成了冒烟测试的自动测试脚本，主要的问题就是测试环境的自动搭建。如果这部分工作能在无人值守的情况下自动完成就会节省很多的时间和精力，测试人员只需要重点关注当天新增的功能和修正的功能就可以了。但是测试环境如何确保搭建成功，并自动运行冒烟测试呢？

我现在尝试这样的方法：我的IIS和SQL虚机都已经做好了一个测试环境，保留一份备份文件，然后设定每天晚上在dailybuild完成后，用备份文件覆盖当天已经使用了的脏了的测试环境，这就相当于回滚了虚机环境，但是这样做就不会出现无法登陆域的情况了。然后自动启动虚机后，运行冒烟测试的脚本。

虽然现在前期的准备工作比较多，但是想到以后能节省很多的时间，现在多做一点也没关系，希望这个方法能成功！

1：优化函数公用性

最近开始整理以前完成的自动化测试脚本，因为新增了很多的功能，要使用很多过去完成的Function和sub，这样一用才发现自己当初设计的Function的调用方法实在不合适，比如一个Login的sub，以前设计的是在这个sub中从一个本地数据库中获取登陆信息，然后填入界面上后登陆，可是这次开始使用这个sub，才发现这个方法行不通，因为我的usecase会经常性的Login，而且每次使用的登陆用户名和密码都不同，这样这个函数就不可用了，于是就采用了传递参数的方法，每次调用Loginsub的时候传递输入要使用的的参数进行Login。同样对自己以前做过的函数中类似这样的函数全部做了修正，以便于在使用过程中的调用。

2：优化函数的粒度

自动测试测试的usecase是非常复杂的，一般情况下一个usecase由多个function和sub组合完成，除了上边所说的在调用方式上的灵活性的改善，还有就是这些function的粒度划分。比如上边讲到的Login，以前的Login函数在登陆完毕后有一段判断是否登陆成功的代码。但是系统升级后，Login完成后会有一些系统通知的popupmessage显示出来，关闭这些popupmessage后才能判断登陆是否成功。于是，我在判断登陆是否成功的代码前增加了对popupmessage的关闭代码，并且修改了Login的参数。但是随着用户需求的变更，这些popupmessage变成了一些可以设置的项目，有时候会显示，有时候不显示。在重新思考了这部分可能的变化后，我重新划分了Login这部分功能的实现步骤，分为设定登陆信息并登陆，对PopUpmessage的处理，Login是否成功的判断三个部分组合完成登陆过程。这样在后来又增加了登陆时修改密码等新功能后，我只需要修改popupmessage的处理那部分的代码就可以了。从这个例子中我们可以看到测试case的粒度不仅反映在测试用例上，实际上也反映在你自动测试脚本上。同样从自动测试脚本的划分也就能看出usecase的划分是否合理了。

昨天本来要发布项目，结果到最后还是以失败告终，因为发现了一个隐藏比较深的Bug。遗憾...

从昨天一天的工作状况来看，我们的测试工作存在很多的问题，比如说这个Bug，就是在新增一条数据已经进行了一些验证，而在编辑数据的时候没有进行验证。而开发人员在编写这段代码的时候也没有考虑到用户旧数据的验证方法，导致过去的那个设计思路在出现问题的时候无法继续了。如果我们能早一天发现这个Bug，给开发人员更多的时间去考虑这个问题，也不至于像昨天那样放弃发布。好在今天早上来了以后，开发那边已经解决了这个问题。这也充分说明了我们的测试力度不够，可是该如何提高呢？很多地方的问题我们该如何深入以保证不再出现类似的问题呢？是否除了测试人员应该加大开发力度的同时，开发人员也能在设计和编写代码的同时给与更多的重视呢。呵呵，绝对没有推卸责任的嫌疑，只是觉得无论是开发还是测试都应该认真的对待这个问题。

另外就是对我们现有的测试方法很有感触。因为我们的产品是一个产品框架，而且昨天是升级发布，要测试的就是升级是否正确，不能简单的拷贝，安装就可以了，要将整个测试环境恢复到一个用户现有的环境（包括数据库和IIS服务器），然后升级后验证用户原有的数据结构是否可用，本地库信息是否丢失或者错误，修正的Bug是否已经完成。所以昨天一天的时间，每Build一次，我就要恢复环境一次，然后升级，然后验证问题。而恢复环境，重新升级差不多需要30分钟，然后验证问题需要1个小时左右的时间。因此基本上昨天一天都在作环境，升级，准备测试数据，我总是在想如何简化这些操作呢？使用自动测试方法？可是环境搭建好像没法使用自动测试啊？不知道其他人是如何进行发布测试的？今天准备用自动测试脚本进行测试数据的准备工作。看看能提高多少工作效率...

一直都很想完成一个自动测试的框架，不想每次写自动测试脚本的时候都是从头开始的感觉。但是始终找不到一个合适的方式，好像有这样的方向，却没有思路。就好像以前开发程序的时候，都会写很多的父类程序来继承，用这些父类程序能合成一个框架，执行测试的时候只要套用就可以了。可是现在一直徘徊在只完成了一些公用的function的布局中，没有达到自己的想法。1月12号我们的项目就发布了，希望能在那之后有时间去研究一下自己的这个想法。