优雅测试

我有500W

反射、泛型、自动拆装箱、动态代理、控制反转、依赖倒置、面向接口编程、面向切面编程、设计模式，在这些词背后，是程序员对优雅编码的一种追求。他们已不再屑于卖弄算法技巧，而开始追求以优雅从容的方式完成工作。去看一些大师的作品（如开源框架），很容易能感受到那种“谈笑间，樯橹灰飞烟灭”的豪情。相对于开发人员的优雅编码，测试人员能够进行优雅的测试吗？下面我们就随便聊聊，看看哪些能称之为优雅测试。
    先从测试执行说起。
    很久前做的一个项目，IT阶段测试人员匮乏，派了一个开发人员去做测试工作。当时的测试任务比较重，但内容还是比较单调的，就是“点点点”。干了两天后，发现有点不对劲了，这效率也太低了，手都点麻了，还没发现多少问题。因为代码是开发团队做的，所以他就想到了能否模拟界面点击，直接传入参数遍历测试。当是的做法还是比较土的，这个测试工具使用同开发一样的代码框架，一样的通讯模式，一起在IDE里面进行加载和调试。入口参数从txt中读入，预期也是同txt中的比较。但效果还是非常明显的，五十组数据点的话要执行一上午，用IDE跑的话，也就几分钟，闲暇时间可以从容的喝杯咖啡，测试人员产出排名还能得第一。
    上面这个其实有点自动化测试的意思了，测试人员也想把这个工具改造为自动化工具，但由于其对被测系统侵略性和耦合性太强，遂放弃。看来，在追求优雅的道路上，自动化是绕不开的。自动化的发展从最初的基于录制回放，到后来的元操作，关键字驱动，行为驱动开发等等，已经有比较成熟的开源工具和相关理论支撑，已经成为一个测试利器。之前就听人说过，有个前台秘书，利用自动化工具录制回放功能，在电脑上自动执行收集资料、转发邮件等机械重复的工作，我觉的这个就很优雅。我也相信自动化测试必然会完成从个人行为到团队行为的转变。自动化是执行阶段最能体现优雅的地方。
    再说一个T公司的，他们在做稳定性和可靠性测试时，经常如遇到如下一些问题：1、系统A 依赖系统B ，希望在系统B有故障情形下，测试系统A的稳定性，如何做？2、如何模拟因为硬盘坏道或空间满导致的写文件失败的情形？3、如何模拟网络延迟导致远程调用大量超时的情形？4、如何验证可能含有线程安全问题的代码？原来可能会这样做：关闭硬件、停应用、改配置、故意改坏代码、重新发布。这些操作是可以达到目的的，但缺点是效率低，不优雅，兴师动众。后来，在测试人员的努力下，开发了故障注入测试工具，能够轻易模拟上述故障。从技术层面上来讲，其实就是基于java字节码的测试，类似于IDE的远程调试功能，能够对内存进行修改，重新加载类等。但对测试人员包装为了一个web应用，一个屏蔽实现细节后的可视化界面。这样，测试人员可以基于此web应用设计测试用例，轻松完成稳定性和可靠性测试，很优雅 。
    接着谈谈测试管理。
    测试管理有优雅之说吗？丑陋的产出物和折腾的灰头土脸的过程，是我们想要的吗？其实，测试管理的优雅就体现在过程和交付件中。整个过程我们不展开来说，只提提缺陷预防和敏捷测试这两个点。
    缺陷预防的基本原理是检查发现的问题，找出问题发生的根本原因，并采取措施阻止这类问题的再发生。基本技术可以概括为：1、建立缺陷分类方法。2、从Review表格、评审报告、测试报告中收集缺陷数据。3、使用统计技术对数据进行分析。4、使用鱼骨图等质量方法查找多发问题、典型问题的根本原因。5、针对根本原因采取措施防止缺陷的再次发生。上述的说法讲的有点太生涩了，都是定性定量的分析。自己从项目管理中得出的体会是，缺陷预防等于测试尽早的介入。只有测试尽早的介入才能使测试风险可控，测试过程不至于慌乱。企鹅公司的测试管理鼓励测试人员对代码开发心存好奇，能够去看详细设计，能够review开发的代码，甚至把这种review当作他们测试工作的一部分。这种介入程度，已经比传统的测试人员评审需求正确性和可测试性，提出可测试需求要深入的多。追求优雅测试，也是在追求这种掌控力，追求这种能够优雅起来的环境。缺陷预防，正是在创造这样的环境。
    再来谈谈敏捷测试。这里不谈H模型、测试驱动开发、持续反馈、迭代验收等等。只说一下从CMM到敏捷我感受最深刻的----测试开发融合。记得当时刚推行敏捷时有个说法：测试人员和开发人员的区别以后会越来越小，理想情况下，敏捷方法中，测试人员和开发人员在不同的迭代周期可以互换。当时觉得不可思议，测试人员怎么可能去做开发呢？后来全员敏捷，在敏捷岛上测试与开发开始交叉坐位，不再向原来一样测试组坐一头，开发组坐一头。测试人员参与度开始大大提高，他们可以很方便的与开发讨论问题，也可以很轻易的了解开发状态和项目进展。开发对测试的认可度也在提高，感觉测试人员由原来处处为难你变为了现在想方设法帮你，测试是在同开发一起解决问题。当然，这不仅仅是因为测试与开发坐在了一起，更多依靠的是敏捷理念的深入。测试人员站在了更高的角度看待问题，,可以从客户角度来阐述自己的观点,扮演“用户代表”角色。如H公司的敏捷开发团队，研发项目中的PO角色由最初的SE慢慢演变为TL，敏捷顾问也赞成这种改变，因为TL比SE更能对需求负责，更能对客户负责。敏捷，是一系列敏捷实践的集合。敏捷实践，是前人不断追求和探索的结果。这些实践，使测试管理者能够在更广的范围和更深的层面，追求管理上的优雅。
    最后简单聊一下组织体系。
    《谷歌如何做软件测试》一文谈到，测试人员的项目与汇报组织结构是相分离的。这一点其实与许多软件企业相同，即采用矩阵式的管理模型，横向是产品线，纵向是资源线，每个测试人员都有两个维度。从资源维度来看，关注的是人员成长和组织氛围，目的是使团队整体技能得到提升并持续改进。谷歌鼓励测试工程师经常更换自己服务的产品团队，以保持饱满的精神状态，并保证有效和客观的工作 。其实更换团队的节奏也是因人而异的，会尊重员工自己的选择。在谷歌，有些测试工程师在Chrome项目下数年，而有一些则在加入团队18个月后去了别的团队。在产品知识与新颖的视角间保持一个良好的平衡，是一个测试管理者需要关注的。相信这种组织体系还是受很多人所喜欢的，因为它能为你追求优雅测试提供更多的机会。
    从测试执行、测试管理又谈到了组织体系，那么如何让自己的测试变得优雅起来呢？其实，有一颗追求优雅的心就够了。这难道还不够吗？