开发人员体验测试工作

         最近，项目不忙，我这边基本上也没有什么事情，我们组另外几个开发人员也只是在修改数量不多的几个bug。但是，测试部正在加班加点的干活，晚上加班，有时候中午都没时间休息，未测试的用例、需要复测的用例……每个系统都有几百个用例要测。经过IT中心协调，我暂时从开发部调到测试部，目前，支援测试部整整一个月了。

        刚刚接手测试工作时，从bugfree上找到划给我的测试用例，感觉步骤好多啊，从准备数据、测试步骤再到预期结果，一眼望不到头，右边的滚动条就那么一点点的高度。刚开始时，什么也不懂，要测试的系统是干嘛的？给谁用的？不清楚。要测的这条用例主要测什么功能？虽然标题可以看没明白，但是一看下面那么多的准备步骤和操作步骤，也立马就又不明白了。所以，只好看完用例上的一句话，在系统上执行一遍相应的操作，用例一句一句的看，系统一步一步的点。当然，中间还有不知道用例上描述的操作，在系统的哪个菜单里，不知道怎么执行的问题，还有执行出问题不知道算不算bug，不知道提给谁的问题……在用例编写者的辅导下，一个用例用了一天的时间才测试完，而且，测试完了也不知道我刚刚都做了什么。

       就这样，过了三四天，放了个周末，当第二周再测试时，突然觉得明白了一些东西似的，根据前几天对系统的了解，仔细看了看用例标题，明白了这个用例要测试什么功能，在看准备数据和测试步骤，慢慢梳理一下，也模模糊糊的能理解要测这个功能，需要造几条这样的数据作为前提条件，对这些数据进行某些操作后，看执行结果是否符合输出要求，如果全部正常，该用例可以passed，如果中间任何一步出了问题，该用例failed，提bug，bug描述要简洁、正确，以使开发人员更高效的定位错误，坚决杜绝提bug时贴用例的情况。failed的用例，需要经过第二轮复测，fixed的bug验证通过后可以关闭，但是，最好还是找到该bug关联的用例，再测试一遍。

       测试时间长了，就觉得越来越省劲儿了。之前，测试每个用例都要从头开始准备数据，后来，发现有些数据，准备一次就够了，能够供好多用例使用。再后来，发现有时候系统中就存在要准备的数据，这时候直接使用就好了。所以，我觉得测试主要是对系统要熟悉。挨着测试人员坐，感觉到写测试用例也挺不容易的，结合系统功能、需求文档，有时候甚至要和需求人员和开发人员面对面的沟通，才能写完一个用例，需求、测试、开发三个部门的相关人员经过用例评审之后，才能执行测试。

       关于提bug，刚开始，除了功能上的bug之外，关于页面上的缺陷（美观、操作不舒服、提示语不够清晰），这些问题，总想着提个bug，后来大家说这是老系统了，线上也一直这样用，就算了，再后来，遇到类似这样的问题，似乎就习惯了。有时候，我倒是很能理解为什么要做成这样，代码简单、好实现啊。也许要我实现这个功能的话，有可能也会有偷懒的想法，现在看来，还是尽量奔着美观、使用舒适度来做吧。

      我的目的一方面是支援测试部，一方面是尽快熟悉公司业务。测试一段时间后，觉得新人熟悉业务，最快的方式就是参与测试的工作，同时手里拿一份需求文档，走完一些用例之后，大概对系统不那么陌生了，这个时候，再看需求文档，要比在没有见到系统或者没有使用过系统而直接看需求文档，要容易理解些。