关于公司的自动化测试！

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

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

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

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

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

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

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

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

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

关于性能测试：

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

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

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

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

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