测试 --- 背后的英雄，流程的改进

昨天又一次感受了测试人员的悲哀。

系统一有问题，领导第一个想到的就是测试人员。昨天领导关心的一个产品发现了一个bug（应该说是没有实现高农恩），就在追问：这个系统怎么测试的？测试人员平时都在干什么？当系统正常运行，甚至运行尚可的时候，都是业务设计人员、系统设计人员、开发人员的功劳，这个时候测试人员就退居2线了，甚至于退居N线了，在考评、奖励上都得不到倾斜，一旦有问题，测试人员就首当其冲，当然不让承担责任。--- 昨天的问题确实是测试中的失误，现在的问题不仅是测试的问题，昨天同样发生部署人员没有按照开发流程出的部署流程操作，造成系统的故障。这些问题累计起来，看上去问题不少，虽说都是可以避免的，但造成了对测试效果的下降，使领导对测试的成果带来怀疑。

还好昨天说了一句：有问题都是测试人员的问题，但测试人员已经发现、已经排除了多少个bug有谁知道。领导也默认接受，为测试人员稍微平反了一下。

但是从这句话中，也看到了自己工作中的失误。

测试人员排查了多少个bug，为什么不能让领导知道？如果领导知道每周测试人员测试了多少个系统、测试了多少个版本、发现了多少个bug，能够让测试的工作有一个具体的量化的数字，从一个侧面、一个系统的角度来体现测试人员的工作量，这个比口头的交流更有说服力 （这个不代表测试的工作不能改进）。

当领导不能发现某项工作的工作量时候：也是需要我们把问题和领导说明白，说清楚，领导也是需要交流、需要培训的，尤其是一项对于他看来很简单，当其实工作量非常非常大，或者涉及面很广、时间拖得很长的时候：

1.譬如目前网站的修改工作，一直以为也就几个页面，弄一下也就几个小时，工作量大一些的也就2，3天的时间； 其实修改牵涉到多个部门共同工作，弄一个会员专区，从开始到结束，用了1个多月，而整个过程中，开发人员开发的只有不到1周的时间，其他的时间都用在业务部门设计、美工美化、外网系统人员部署上面，不把这些时间统计清楚，清一色的算在开发上，说开发人员的工作效率低下，实在是真不知道怎么说了；

2.譬如目前开发的信息流项目：这个正在让测试人员把信息流的功能点用脑图的方式全部列出来---本来测试就要对这么多功能点进行测试的，做一个脑图，将功能精简一下给领导看，说明说明工作量。主要使用到这个系统的其他部门的人员目前也已经参与到培训、客户化测试阶段了，他们看到这个图都吓一跳，简单的几个字已经说明了一切：这么复杂啊，这么多功能。如果只有底下的人知道，领导不知道，干活的人又白辛苦了。

改进措施：

1. 完善测试流程：
   主要对测试的功能点、测试的覆盖面再做一次整理；尤其是经常用的功能、领导关心的功能（是不是有点太功利了，谁让领导具有一票否决权）
   
2. 测试人员的测试工作进行量化：
   将测试人员每周测试了多少系统、测试了多少版本、发现了多少bug进行统计，这样一来可以监督测试人员的工作，二来也让领导知道一下测试的工作进展、测试的工作量，要知道测试人员不是只对某个产品进行测试，公司目前可以算上产品的数量是测试人员数倍都不止，不把这个列出来，领导只看到有问题的产品，而完好的产品看不到（运行正常没有事情，没有人反映问题，领导甚至把这个产品给忘了），对整个部门的工作评价也是不利的；
3. 对每个产品进行错误统计：
   由于开发人员的因素，有些产品质量一直很好，有些产品反反复复的次数占多数，不仅占用测试人员的时间，而且开发小组本身的工作效率也提不高。通过这个统计，把每个产品的质量进行统计，作为对产品组的一个考评依据。
4. 对测试要树立一个评价体系：
   这个是最难的，如果按照bug率来进行统计，如何统计bug率？按照功能模块来限定bug数量，大功能点和小功能点包含的强度不一样的，按照代码行bug数量来统计，现在的系统泥中有我，我中有你，还真是一件麻烦事。上网看一下测试理论是怎么养的，别人是如何进行评价的。

安装了Screen Anytime

重新在看程序员杂志，在开源项目中，看到了Screen Anytime，一款运行在Windows平台下，用于监控、管理服务器或者工作站屏幕操作细节的视频日志软件。既然程序员上推荐，就下载了一个感觉一下（http://www.screen-record.com/screen_anytime.htm ）

在：http://www.screen-record.com/download.htm 上下载Screen2Exe，free版本（其他几个版本都是商业软件，不free），使用下来感觉不错。

• 录制时，对其他程序没有什么影响，感觉不到它的存在；
• 最主要的录制结果比较小
  录制了几次1分多钟，生成的exe文件在500-600K之间，比其他的程序生成的要小。
• 结果直接生成exe，播放的时候也不用担心使用机器文件格式兼容性的问题。

于是马上想到了测试，在测试过程中，使用这款软件对测试过程进行记录（原来就是担心截屏结果过大，没有使用）。将测试过程记录下来，可以

1.  便于回忆测试过程，和开发人员交流：
   如果发现问题，进行回放就可以了，不用向以前那样为了重现错误，不断回忆操作过程；或者开发员不在的时候，事后和开发员说他们不承认，至少截获下来，眼见为实（虽然当时的环境不复存在）；
2. 记录测试过程，测试人员不能偷懒：
   将测试过程记录下来，测试人员在测试中的一切操作，如何操作，重复了几次，检查了一些什么功能、检查了一些什么环境参数都被记录下来。在提交测试报告的时候，一同提交测试录像，这样，就是想在测试中偷懒，也要考虑后果。对于测试报告中的每一条测试用例，如果检查的时候觉得有怀疑，也可以通过录像进行播放出来；
3. 准备向高层领导进行交流的材料：
   现在测试后，结果还是有很多bug出现。虽然知道在就这么几个人，就这么点环境资源，这么点测试时间，无法做到全面、完整的测试，测试不可能100%捕获bug。就是有相对充足的资源，也不可能100%的堵住漏洞（尤其目前只有黑盒测试，没有代码复查、白盒测试等手段）。
   在使用中遇到bug，高层领导就骂测试是吃白饭的，这些问题怎么都没有发现等等（有时候不是程序的问题，都会怪到程序上来 --- 部署是另一个中心完成的事情，虽然可以安排他们某些工作，但是不是直接的隶属关系，怪罪起来不是很方便）。有了录像，以后有问题，可以用这些录像可以进行检查：如果真的测试人员偷懒，没有按照要求进行测试，进行内部纪律处理；如果测试人员对这些功能进行了充分的测试，拿着录像和高层进行交流，证明这些功能都已经测试了，没有发现问题；领导机器上发现问题，这说明我们现在的测试环境不够或者测试方式不对：如果测试环境还不够，很多应该测试的环境没有资源搭建起来的话，这样也可以名正言顺的要求机器资源了；如果测试方式不对，则修改测试方式，找到一条适合我们自己的测试方式
4. 生成环境中的测试，和其他部门进行交流：
   现在产品出来，需要测试人员在正式环境中的测试环境进行测试一次，有了录像，至少测试人员可以跟着自己提交产品、提交测试报告的测试过程再重复执行一次，其他部门的人员也可以通过测试录像进行验证一次；
5. 也可以作为对客户的操作说明：
   现在使用软件的客户，有相当一群对计算机基本操作一窍不通的，在电话中遥控指挥他们操作真的要累死。有了这个软件，可以通过电话摸清客户的环境，将操作步骤全部录下来，发送给客户，让客户跟着录像执行就可以了；