软件测试碎碎念

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

　　质量效益来自管理51Testing软件测试网7FDQ|%Y*V

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

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

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

oK'A7`sp4]/u@0　　测试模式之拿来主义51Testing软件测试网\'S0aQ
q.K*h`

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

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

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

　　测试不依赖创新活动

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

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

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

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

Z5Ba4M/wK0　　2、测试操作与测试数据绝对分离，测试组件属性和测试操作尽可能分离以达到关键字驱动；51Testing软件测试网-S)BI7g!j!Z?

W*Q,h1|!i{0　　3、以最少的代码维护量换取最大的功用，基于业务组件的一致性（UI）来判断是否进行复用；

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

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

　　6、彻底mock掉对关联系统的依赖，即使是同一个开发组的系统也不可以；51Testing软件测试网-l7v6{9jsVU yk

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

N!?JX Pmm9eCd0　　8、每个流程绝对独立，不能够通过条件去判断数据类型而向不同分支延伸，也就是不允许存在树状流程设计，只允许平行的流程设计；51Testing软件测试网:RD#[%e*Qh5d

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

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

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

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

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

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

u"lmVg5_+S{0　　1、应该搞清楚哪些系统必须要参与持续集成，而哪些不需要，哪些不能够，如果一定要坚持认为整齐划一，那我们就只能选择沉默不语、被动配合，坐等你的决策带领我们走向失败；51Testing软件测试网n4ZyRpk

P]y M?fL@S
i0　　2、必须要参与持续集成的系统可以优先安排开源自动化的转平台；

　　3、无需持续集成的系统，不要强制，让开发和测试分析、协商如何选择后续的做法；51Testing软件测试网-_5Oz!a]%HDY}%H.@

.am*xDyy,J+Ao
S0　　4、不能够参与持续集成或者说做持续集成没有价值的系统，绝对不要强制他们去参与这项活动，同时自动化测试脚本可以根据现有的自动化水平去选择是要保持原有的建设成果还是推翻重来；51Testing软件测试网/B)yW&N#VB

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

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

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

V&pC,hc0up0　　前几天微薄上争论测试到底是以技术为主还是以工具为主，是以人为主还是以流程为主；其实我认为测试工作应该以达成需求为根本目标，而达成需求靠 人，人要拥有做好测试工作的意识，然后才是通过掌握必须的技术或者工具来完成具体的工作。做好测试工作的意识是什么？意识就是无论做什么事情都要本着以达 成测试需求为根本目标，无论采用什么手段都是以做好测试工作为核心目标。51Testing软件测试网PD(i'{-n6x

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

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

　　我之所以在《软件测试自动化的探索与管理》一文中将软件开发成熟度作达到一定程度为自动化实施的一个前提条件，是因为自动化测试所依赖的还是没 有自动化情况下的测试体系建设水平。不过总有人愿意自我麻痹：我们现有的测试工作做得遇到瓶颈了，需要通过自动化来提高我们测试工作的效率和精确度。我曾 在微薄上和吴博士争论到底是否需要建设好产品用例库再去做自动化，无论大家认同与否，我觉得在做测试自动化之前有几件事情是要好好反省一下自己有没有做 好：51Testing软件测试网Mgj/@h?

　　1、测试完整性——测试人员或者说参与自动化测试的人是否熟悉整个系统的全部逻辑？

b1f.TAk%s2q0　　2、测试复用性——测试需求或者说补丁需求在持续地、周期性地追加或变更，测试人员设计出的测试用例是否每次版本发布之后就失去作用？51Testing软件测试网7E!FxT+W-t
v

　　3、测试探索性——测试人员是否能够在测试过程中不断修改和补充测试用例来让测试更加完善？51Testing软件测试网4\h^)} s7d

G'b_A@'Z1}Y.o0　　4、测试经济性——测试人员有没有能力使用最小的数据矩阵去完成所有当前版本的需求的测试？51Testing软件测试网|msDa

　　5、测试效率性——测试人员最快能够在多少小时之内完成整个版本很多个SRS的一轮测试执行？51Testing软件测试网9[d|C2[_ v;H(W

　　6、测试有效性——测试人员是否在每一个必须的测试检查点上做了足够的检查？51Testing软件测试网H#e4gr)Aq&N

E"z8}}C
M#h-MF0　　这些方面如果没有考虑清楚或者没有做好，我觉得还是不要妄谈测试自动化了，因为手动测试做的不好，自动化测试的设计必然也不会很优秀。因此造成 的自动化负担为长期的测试工作带来的效益很小，但是花费很大，是很不值得的。我们的出发点应该是软件质量，而并非只是为了节省时间或者人力，如果说人力、 进度和质量这三者需要一个平衡点，那么自动化测试在忽略质量的时候，这铁三角一个都得不到。就像朱少民老师提到的软件测试的8组关系、13项原则、21个 关键域，看起来很学院风，但其实也只是测试经验的提炼而已，我们也可以有自己的测试关注点总结。如果我们在日常的测试工作中接到任意一个或者一组需求都能 够考虑到这因素，那说明我们的质量意识是已经养成了的，我们的基础工作做得好才能稳定地保证我们的软件质量。在能够保证质量或以保证质量为前提的情况下， 再去考虑效益的提高才能使铁三角稳固，重复建设的灾难才不会重演。51Testing软件测试网6Vq.E1Q'I U&~