昨天去取招行发的信用卡，找了半天才找到那个邮局，邮局在一个很大的小区里，周围都是居民楼，下面中间是块很大草坪，给人很浓的都市生活的气息。虽然我就住在天河软件园旁边的一个小区里，但却从来没有这么强烈的家居的感觉。

回到寝室之前，去超市，买了一瓶水。正准备给钱，不经意扭头回去看了一下，看见了一张很熟悉的脸，开始还不确定，过了一会才想起是我上一家公司的人事部经理，他正在后面排队等着买单呢。我吃惊地望着他，都不知道说什么好，他倒是主动给我打招呼，问我现在工作怎么样，我说马马虎虎还行吧。他说你现在应该做的很好吧，素质那么好，我说还行吧。原来他也住在附近。真是太巧了，他居然还记得我，估计也就是记得个样子吧。不过感觉他看上去有点衰老了。

昨天天就阴沉沉的，今天下午就开始下雨气温下降的好快，就躺在床上，盖上被子，看起书来。

这段时间老是不下雨，弄的太干燥，嘴有开始溃疡，希望下雨后能好起来。

天冷了记得多加点衣服。

合同到期了，没有打算离开，希望自己能静下来学一些东西。

老板找过谈过一次话，谈了一下薪水和其它，基本满意，于是就告诉自己还呆一年吧，到时候再看情况。

今天下午，老板叫我到办公室，说让我看看合同，可是合同期却是2年，觉得有很强的意外的感觉。

有一种很忧伤的感觉，怎么都摆脱不出来，2年后我会是什么样子呢？觉得很遥远，又觉得很近！

还会是这样么？可能都没有这么多的激情和勇气，变得衰老和漠然。

唉！是不是应该去改变些什么呢？

包括改变自己！

自动化测试的回归——测试用例（功能测试）。

研究了很长时间的GUI测试，却发现纯粹的GUI测试根本无法满足自动化测试的需要，而自己思考问题的范围却被局限在GUI测试上。似乎离开了GUI测试都不算是自动化测试，可是GUI测试在项目的测试中的作用并不明显，并且花费的时间很多，脚本比较独立，很难被调用，很难维护。并且自动化测试成了一个与我们实际测试工作中毫无关系的多余的一部分，成为了附属的多余工作，于是我们总是觉得时间不够用，甚至很疑惑难道这就是我们需要的自动化测试么？

这段时间的思考让我发现我们理解的自动化范围太窄，似乎功能的自动化测试就等于GUI的自动化测试，除此之外都与自动化测试无关。

现在我发现GUI测试只是自动化测试的一部分，并且是很小的一部分，甚至同时我们还需要很多后台的处理来保证GUI测试的成功执行。比如对GUI测试环境的恢复需要对数据库的操作和处理。（没有这部分的工作，GUI的测试几乎是不可能地。）而还有很大一部分的工作是与GUI测试无关的。如果这些大部分的工作不能自动执行，或者不能通过简单的操作就能执行那自动化只是纸上谈兵，离自动化还差的很远。

我觉得自动化的目的是降低我们的工作量，是对工作有利的，是项目相关的（我们实现自动化必须是与具体项目有关的，因为每一个项目都有它自己的特点），而违背了这个原则的自动化对我们来说是不是需要是个值得思考的问题。有一个简单的标准来衡量项目自动化的程度：能够多大程度上减少工作中花在重复工作中的时间。从这个意义上说，这不仅包括GUI的测试，还包括数据的准备，以及各种与GUI没有关系的后台数据的校验，和其它一些可以被取代的重复性工作。这些也应该是我们自动化测试的目标，成为我们自动化测试的一部分。因为它们是我们项目工作的一部分

为了实现这个目标，我们应该回归到我们项目的测试用例。我们需要做的所有的工作都会在用例上包括。（如果测试用例上没有，证明我们的测试用例不是完善的了，呵呵)。用例中主要包括2个主要的部分，测试数据和测试用例。测试数据准备我们所需要的所有的测试相关的数据记录。而测试用例则包括测试的Pre－condition和after condition，以及测试的步骤，测试涉及数据的编号，测试的每一步执行的期望结果。看看这包括了所有GUI测试所需要的元素，当然也包括了所有其它自动化测试所需要的要素。

现在我们可以来设想一下如果我们能够把我们的用例做的足够完善，以满足我们自动化测试的需要。其实自动化的过程就是把测试用例翻译成自动化脚本的过程。用程序来实现和替代我们手动需要完成的工作。这样自动的目的就达到了。

而自动化的实现的步骤和路径就是不断地完善我们的测试用例，自动的完成测试数据的准备，自动的完成测试的用例。而这需要我们能够让自动化的测试工具和我们的测试用例很好的融合起来。可以一步步去实现，相信每一步的成功都能给我们的工作带来很大的便利。

如果能够放开去思考问题，真正为了改善我们的工作去学习和工作，这些才是最重要的，才是我们真正需要地！

最近又接到通知要把停顿了2个多月的自动化的工作从新做起来，组长在那里滔滔不绝的讲所谓自动化的好处，让人突然觉得很反感，很想发火，不过挠了半天后脑勺，还是忍住了。觉得很无奈！

突然发现自己一直都走一个误区，搞那些商业软件来学，学了一点皮毛，对工作却一点帮助都没有。于是对于这些工具的了解只是一个摆设，只是欺骗自己，忽悠别人的虚幻怪梦。如果那些东西对工作帮助不大，那我为什么不扎扎实实实地去作些真真能够提高工作效率的，提高工作质量的工作。搞那些花架式来骗谁呢？

先对使用的项目简单介绍一下，系统比较大,简单一点划分,主要是：一，通过Browser界面来维护系统的主要参数的功能部分；二，提取或统计数据库中数据，经过简单格式化后，通过水晶报表产生需要的报表的功能部分；三，对外部传来的数据进行解码并把数据保存到数据库的功能部分。

项目分成很多的用例来迭代开发，项目开始时对项目并不是很了解，因为用例是由另一家公司提供。项目的时间很紧，用例的开发和测试都是在很紧迫的情况下完成。所有的测试工作都是由测试人员加班加点手动实现的，包括客户一个阶段结束后，提交客户一个版本后，客户做了接受测试发现问题后，测试人员再做回归验证测试。都是手动测试完成。项目经理找我谈过几次，问能不能用自动化测试，我却支支吾吾，只能说自动化要花更多时间。

现在想起来，主要是几个方面的原因：

首先是功能测试方面的问题：

1）由于其实开发地难点和重点是在对外来数据地解码和保存，这都是在底层实现地，与界面无关。我们绝大多数的工作是在测试数据的准备，和对解码后数据的验证，而数据都是保存到数据库中了，根本没有用例把数据显示到界面上。于是我们大多数时间都花在数据的修改和对比上。现在解决的办法：主要是通过excel和它的VB脚本来准备数据，并把数据从数据库中导出到excel与预期的结果数据来进行比较。比较的一部分如果要做成自动化来实现，可能可以通过funcational tester的java脚本编程来读取数据库中保存的数据，来与datapool中的数据来进行自动比较，实现自动化。可是问题是数据本身的时间部分在不停地变动，并且很难保证输入到数据库的数据与预期的结果一致，变数太大，不好控制。况且实现这部分的数据准备，保证输入数据的正确性，编程实现数据的访问也需要很大的工作量。

2）与界面有关的部分功能比较稳定，与之直接相关的后期的变更很少，几乎没有，而与之有关联的可能会影响到的变更也很少。由于界面部分主要的功能主要是表的一些维护工作，比如增加，查找，删除存储一条或多条记录。功能简单，性能比较稳定。所有用例都开发完之后，测试组4个人花了大约1个月的时间来录制这些与界面有关的用例的功能脚本。可是首先是虽然功能简单，但录制脚本的时候却发现，要校验的功能点却多的让人害怕，于是只能录一些自己认为是主要的功能的脚本。没有脚本质量的任何要求和约束，没有对后期维护的任何保证的措施，于是录了一大堆只有自己看的懂，或者自己也看不懂的东西。结果是这些脚本录完之后，自动化的工作也就结束了。这些脚本对后期的维护工作一点用都没有。因为后期的维护和更新的工作主要是在解码和格式化这一块。理论上这些东西可能有用，但实际上项目的后期基本是没有用到。并且我们没有实现全部的功能覆盖，我们怎么样保证我们的软件的质量。并且我发现，所谓的自动化只有在一个很固定的情况下才能执行的工作，任何的大一点的变更，都能把我们以前的工作变得一文不值，想想也是个风险很大的工作。

3）水晶报表的功能发生变更时，基本上是数据的格式发生变化，需要准备新的数据，期望的结果也发现变化。并且很难保证数据库中的数据来满足以前录制的脚本。数据变了，以前统计的结果也变了。保持稳定的状态是很难的工作了。我想直接的方法，把数据库中相应的表导出备份，做测试时，清空表，再导入备份的数据。（就是把所有的状态都恢复到录制的状态，对于一个大的不停地变更地系统，这个可能需要需要对自动化的脚本制作有一个很好的规划吧）。

关于性能测试：

这一块是由测试组地组长做的，她选了一个与界面相关地用例做了一些多用户并发使用的测试。写了一份性能测试地报告。结果是开发部的经理告诉我这份报告简直就是在敷衍和应付他。

1）先不说她的这份报告的质量怎么样，首先她的测试目的就是错的。由于性能测试不是在我们公司做的，而是在另外一家公司做的。从他们提出的问题，和反馈的情况来推测。他们只是在现实的场景下，对系统做一些单用户的操作（可能是由于系统的客户访问量比较少），然后简单的统计一下系统的反应时间。在提出一些系统反应时间的要求，要求我们公司对系统的功能进行优化。其实大多数的性能问题的原因是由于现实的场景下，数据库中存储的数据量太大（一个表里就存储了上百万的记录），或者满足要求的提取的数据量太大，导致系统反应的时间太长，达不到客户要求的。性能测试的当前的目标主要是测试在大数据量的情况下，系统不同的功能部分的反应速度。

2）性能测试的这个简单验证的目标达到后，下一个目标就应该是调优了。即发现是由于系统中那些问题导致了性能不满足要求，或者是可以通过那些方法能更简单地来满足客户性能的要求。可是我们多用户的测试报告只是一个简单的验证测试结果的报告。对开发没有任何指导意义。显然我们的目标不是简单地告诉别人这个没有满足性能要求，而是发现那里出了问题。就是调优的问题。（顺便说一下，网上下载的loadruner根本就没有提供调优的功能部分。如果想用估计是要花钱买了。）

我觉得自动化测试是一种方法和思维方式，而不是一种或几种测试工具，其目标是提高测试地效率，保证测试软件地质量。如果能能引入一点方法，那怕只是对我们地实际工作有那么一点帮助，这种自动化的方法也是值得肯定地，没必要搞那么多花哨的不实用东西。

以上只是对我面对的这个项目的一些自动化的测试问题提出的一些看法和自己执行自动化测试的一些经验，也只是对这个项目的测试提出个人的意见，难免局限，仅供参考。

这几天感触很多，可能是这几天发生的事情太多了，也可能是刚过完生日，又过去了一年，又老了一岁！

日子一天一天地过，每天都在学习，工作。可却发现什么都没改变，除了让自己一点点地失去激情，失去梦想。

很努力地去溶入生活，却发现自己似乎根本就与生活格格不入，离生活越来越远。

太多幻想的东西在脑子里存在。却一点都触摸不到！

一直以为自己很坚强，却发现自己还是会流泪，还是会伤心，谁会在乎呢？包括自己也不会在乎！觉得擦干眼角的泪水自己就能坚强地生活了，一切的过去就只是过去。该失去总会在我期待的目光中消失，也许习惯了失望，片刻的拥有就让我很满足，感谢上天给我的幸福，当幸福离开时，我只能望着它的背影，转身离开，放弃去抓住的勇气，也可能是早就习惯了失望，它就变成了生活的一部分，变成了习惯。

该忘记的总是会被自己有意无意地从记忆中过滤点，消失在身边流逝的时光中。

还有我的生命还是在继续，虽然，日子还在......