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

　　细细算起来，在部落格里面前前后后写了约10万字关于测试或者自动化方面的看法，虽然看法未必成熟，但是回头看看都还挺有意思的。这一坨坨啰嗦的文字倒是记录了一个测试工程师的成长历程，我不想再拿新的观点和说法来博取诸君眼球，下面只简单摘抄一些以前写过的内容，补充点例子进去，再次强调并且与大家分享一下我对我测试工作的看法。

　　质量效益来自管理

　　质量大师约瑟夫·朱兰说过：80%的缺陷来自管理层的决策失误而并非工作技巧问题，笔者认为这种观点对我们所关注的软件质量来说也是一样的，所以管理层的观念和做法不但会影响到我们测试的ROI，甚至更可能会从根本上决定我们的行为是否能够获得成功。

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

　　一个浮夸的、作风不踏实的主管，无论如何都不会把他的团队建设的很好。这种人擅长的工作是：事前想好退路，做好免责声明，而并不去仔细调研分析工作本身。就像你要帮助他的团队引进一种新的技术去解决他们工作中的某些不足，他会不痛不痒的寒暄……绕了半天他会“委婉地”告诉你：做不好就是你们给的方案不给力。

　　我们有很多测试经理都是做技术出身的，之前做开发也好、测试也罢，自身的水平绝对不落后与大多数同事。但是他们屁股坐到分组经理的位置之后考虑的就只是眼前的KPI和考核结果，根本就不考虑从长远来看，培养一个能站在行业高度看问题的技术仔或者说测试架构师能对自己的分组乃至整个部门有多大作用!那你说经理竟然不会比小弟们更加高瞻远瞩?那是因为所处的位置不同，关注点也就变了：之前自己做测试的时候是关注如何测试快速有效;而现在却关注如何做让大家都能不犯大错，甚至连自己之前推崇的技术、方法都被遗弃了。简而言之就是从关心技术变成了关心政治，而且凡事向上汇报的时候总要加个渲染的效果进去——在我们这被通俗的叫做：说故事。是不是只有测试经理是这样的呢?当然不是，这是大环境使然哪，那测试经理们是不是一定都要跟着学呢?咱测试部门是纽带部门，难道都不能改改?!建议找一些信仰坚定、不喜欢随波逐流的人来带队伍吧。

　　测试模式之拿来主义

　　笔者发现有很多同行、同事喜欢照搬别人的“先进经验”，比较信奉Microsoft、Google或者Facebook的经验和理论，总喜欢讨论“别人这么做都怎么样了，我们这么做也应该会怎么样”之类的事情，基本把自己公司实际情况抛在一边。例如，有人说Microsoft开发测试的比例是1：1甚至1：2应该是最合理的，是重视测试的真正体现;有人说Google在开发测试比例1：15的情况下能够完成自动化测试对敏捷开发的支持，说明人家的测试技术才真正是一流的;也有人说我们要引进Microsoft的测试理念、Google的测试技术，改一改我们的规范制度，也尝试一下别人的方法……等等，诸如此类。

　　大家想想，在说这些话的时候之前有没有理清楚自己测试的产品是做什么的，与其他产品有什么不同呢?稍微动点脑子就知道，有些公司是做产品的，有些是做人力外包的，有的是做运营服务的;有些是电信行业，有些是金融行业，有些是互联网、电子商务什么的;有些是做瀑布型开发的，有些是做敏捷开发的……不能一概而论。虽然可能这些不同类型的公司所做的事情有交集，但是要学别人做事的方法先要搞清楚别人和你做的是不是一件事情。

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

　　举个例子：我们的一些保险核心业务系统，传统的J2EE模式，业务逻辑描述大部分都在DB层，Java的Service层基本什么逻辑都没有;在公司统一的要求下，强推持续集成。大家知道这种系统package代码动辄上百万行，单元测试在这方面的投入是非常高的，尤其在系统已经建设已经完成的情况下，做这件事情需要较多的工作量去重构代码，同时还伴随着较高的业务风险。那么在DB层的单元测试方案没有确定的时候是不是要学别人也去做持续集成呢?规范定义的Java代码覆盖率即便达到100%又能有什么意义?徒增人力浪费而得不到一点质量提升!这种情况下我建议开发和测试一起坐下来讨论一下：大家合力探索一条快速可行的单元测试的方法，如果实在得不出成本效益平衡的办法，就放弃底层测试，从业务逻辑分支上去做详尽的分析，将UI层的测试作为主要的测试手段。做不了敏捷测试会死人么?不会，只以敏捷为荣的人可耻!做不了持续集成会死人么?不会，只以持续集成为荣的人可耻!做了公司的特例很丢人么?不会，而且我觉得挺光荣，至少你做的事情是切合实际的，有效果的——跟风玩过家家没啥好处!

　　测试不依赖创新活动

　　创新是什么?创新是在日常工作中不断冥思苦想如何比现有方法更好地去解决问题，以达到提高工作效率乃至生产力的效果，它的真谛并不是灵感突发带来的奇思妙想。测试自动化只是测试的一个发展阶段，而并不是创新，只是在自动化实施过程中可能会有创新行为而已，并且创新行为必须要有一些基本的准则。

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

　　今天下午被拉去参加部门例会，一个让我哭笑不得而又让我深思的会议，感觉很不好。在我看来，UI自动化测试设计至少要遵守如下准则：

　　框架设计要做到能够有效降低测试开发的时间和技术成本，而且支持的要足够灵活，不做过多无畏的封装，不能够成为系统测试的使用需求瓶颈;

　　测试操作与测试数据绝对分离，测试组件属性和测试操作尽可能分离以达到关键字驱动;

　　以最少的代码维护量换取最大的功用，基于业务组件的一致性(UI)来判断是否进行复用;

　　尽可能少的数据维护量，提高数据灵活性，降低对测试数据健康度的依赖：抛开运行速度，基础数据足够的情况下如果一天需要跑800次，那么也必须得能够支持，也就是说要有一套自动化数据构造的方法来支持自动化业务测试的运行;

　　要做到使用尽可能少的数据覆盖尽可能多的场景或流程，降低整体测试的消耗与对数据的依赖性;

　　彻底mock掉对关联系统的依赖，即使是同一个开发组的系统也不可以;

　　测试业务逻辑必须与框架和工具自身的逻辑完全剥离，不允许存在混杂;

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