你所理解的软件测试到底是什么？(2)

　　每个流程绝对独立，不能够通过条件去判断数据类型而向不同分支延伸，也就是不允许存在树状流程设计，只允许平行的流程设计;

　　有几个测试组分别演示了自己的selenium自动化设计方法，其中有两个让我印象非常深刻。一个是把数据和操作拼接为一个字符串作为一个xml节点或者csv单元格来存储，测试执行的时候通过外层的方法去加载命令执行;另一个组是把每个页面组件封装成一个VO，内含一组get和set的方法，将操作封装为一系列的BO，测试用例中直接引用这一堆的VO和BO去组装成测试脚本。这些很与众不同的方法都是来自于他们各自的实践和总结，不能说不好或者不实用，但是我想说的是：技术手段虽好，但是设计方法遗漏了最根本的效益因子和对一些基本原则的遵守。很明显，第一个虽然号称在模仿RF，但是错误的理解了关键字驱动是怎么回事，绑定了测试数据和操作，不够灵活：维护不便、重构不便、转平台不便。而第二个则明显复杂化了自动化测试脚本设计，要知道测试人员在做测试，而并非去写一套很高明的、需要交付给客户的代码。这么做耗费的人力成本是很高的，被测应用逻辑的变更造成的维护成本翻倍，而且这种做法让脚本的可读性严重降低。

　　我原以为那些粗浅的设计原则都是公理一样被所有人所遵从，但是这次会议真的让我见识到了人的思维意识差别之大。恕我不厚道的猜想，大家并非不知道这些简单的规则，只不过这些行为都是基于主动创新为出发点的，所以忘记了一些基本的、必须遵守的原则。前面说了，测试自动化不是创新活动，而且可以说测试工作不需要以创新活动来保持活力，所以还是要强调一下，请不要为了一些没有意义的目标去违背一些简单的原则。

　　重复建设——测试部门的灾难

　　无论团队组建是还是人员发展，无论是自动化体系建设还是得到自动化测试收益，都不是一朝一夕的事情，这些行为一旦开始以进度为主，急于得到回报的时候，质量问题就会在不远的前方等待着你。由此开始的问题暴露和新的快速修复就会导致反反复复的重复建设、重复开发，让人身心俱疲并且找不到问题所在：到底是工具不好还是人员素质不够高呢?显然都不是!我们测试部门方方面面的发展都是点滴积累的过程，无论是技术积累还是管理方法的摸索，都要切中当前的测试需求。测试经理和所有的工程师都要记得时刻提醒自己：我们是做软件测试的，我们应该为软件质量买单，这些先进的技术如果无法一时半会得以应用，那么我们要先以测试为主，这华丽的技术现阶段能用多少就用多少，不能一蹴而就。

　　——摘自《软件测试自动化的探索与管理》2009

　　这个问题最初体现在我们的QTP自动化测试建设上，花两年时间逐步完善自动化的系统，他们的测试脚本质量远远高过那些为了完成指标在3个月内匆匆赶工做出来的系统。无论测试脚本可用性、正常情况下的运行通过率，还是测试脚本本身的可信程度，都有着质的差别。不过，这都是过去的事情了，测试部门为了迎合规划部门对整个公司的持续集成体系的规划，要丢弃历时近5年建设而成的QTP自动化测试平台体系、测试框架和近2万回归测试脚本，全部从头开始重新建设。这种行为太野蛮了，实在是荒诞不经，我本无意在你们玩过家家玩得正High的时候说这些，但是我觉得你们惯于玩一刀切，你们已经严重伤害到我个人的利益了。即便我无力改变你们的想法、做法，但我还是得说两句：

　　应该搞清楚哪些系统必须要参与持续集成，而哪些不需要，哪些不能够，如果一定要坚持认为整齐划一，那我们就只能选择沉默不语、被动配合，坐等你的决策带领我们走向失败;

　　必须要参与持续集成的系统可以优先安排开源自动化的转平台;

　　无需持续集成的系统，不要强制，让开发和测试分析、协商如何选择后续的做法;

　　不能够参与持续集成或者说做持续集成没有价值的系统，绝对不要强制他们去参与这项活动，同时自动化测试脚本可以根据现有的自动化水平去选择是要保持原有的建设成果还是推翻重来;

　　通过一些网上的材料可以知道，五年前，我们基本和百度、腾讯测试部门在同一水平线上，甚至有些方面比他们建设得要好一些;而现在他们站在QCon的演讲台上为同行布道，我们只能在台下唏嘘自己的原地转圈圈。这看起来是每一个测试人员的责任——但是测试经理们你们认真反省过没有：每次接受一条新的政令，你们是否站在测试目标达成的角度上去考虑过，自己将要做的是不是有益于测试部门的长期建设呢?你们如果没有勇气抵制不正当作风和来自其他部门的错误决策，你们有什么资格来带领大家，有什么资格给大家宣导SCC理念!眼下的那点靠“讲故事”达成的KPI，靠“讲故事”赢得的差强人意的考核结果对你个人、对你的下属、对你的分组、对你的测试部门能有什么长远的价值?

　　顺便提一下，不要反复的请顾问或者咨询师，别人再强，知识都是自己的;再说一个人再强，也无法摸清整个公司所有部门的情况，他们所能做的事情也非常有限。所以靠外力来推动内部因不受认可而阻滞的政令不会产生多大影响的。如果请顾问只是为了借一两个强人之口来推行自己无法推行的政策，那么最终面临的还是失败，过几年如果诸位还记得今天看到的，可以回过头来数一数自己被顾问了多少次。

　　质量意识——测试工作的灵魂

　　前几天微薄上争论测试到底是以技术为主还是以工具为主，是以人为主还是以流程为主;其实我认为测试工作应该以达成需求为根本目标，而达成需求靠人，人要拥有做好测试工作的意识，然后才是通过掌握必须的技术或者工具来完成具体的工作。做好测试工作的意识是什么?意识就是无论做什么事情都要本着以达成测试需求为根本目标，无论采用什么手段都是以做好测试工作为核心目标。

　　我们常常面临的问题是，动辄被要求按照某种规范和流程统一去做某件事情。至于为什么要按照这种做法去做一般是问不得的，因为一旦知道背后哪些真实的目的，很多人都要被气得肝胆俱裂、七窍生烟!所以我曾对同事戏言：有些事情不要理解太透彻，否则你就不想做了。

　　就拿测试支持组来说，我们需要知道测试平台的使用规范和框架远景设计目标，问其索要;可能他们刚开始还不明白规范应该界定哪些内容去管理，就会产生不知出于什么目的的规范来。我想知道Jenkins上如何规范能便于管理测试日志、测试报告，如何能够提供集群的报表，如何能提供最便捷的测试分析方法让测试人员去了解构建结果;如何定义将来运行的串、并行调度模式，而由此决定我们私有的框架下如何选择工具的使用方法。但是得到的答复是：不允许使用TestNG，只能用JUnit;不允许修改selenium的核心Jar包去加入用户自定义方法;不允许引入平台上不存在的第三方工具包……在我质疑之下，便得出了真正的原因：要支持测试支持组的工作!可是测试支持的一个兄弟说：“测试支持组，是应该最大可能的支持测试工作、满足测试的需求，而不是成为测试工作的瓶颈!”看到他同我一样很郁闷，我竟有十分开心的感觉：并不只是因为有个人能够认同我的看法，也是因为还有人在坚持，还有人在为了测试工作，而不是了形式上的建设而随波逐流。

原文转自：http://www.ltesting.net