不测的秘密：精准测试之路(txt+pdf+epub+mobi电子书下载)

作者：TMQ精准测试实践团队

出版社：机械工业出版社

格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT

不测的秘密：精准测试之路试读：

前言

深圳，已是深夜，深南大道旁的腾讯大厦，有几个人走出公司大门，望着天空中的点点繁星，不由感慨，终于把这个版本发出去了，该回家好好休息了。没错，这几个人就是典型的互联网公司的测试人员。

斗转星移，软件测试从诞生到现在已过去40多年。虽然各种测试理论和技术层出不穷，但这个行业近10年的突破仍然较少。敏捷测试虽然已经普及，但是应用的效果因团队而迥异。大部分的测试团队还是处于一种疲于奔命的状态，团队技术弱，测试一片黑，任务重，测试过程重复单调，测试人员对测试结果没信心。

既然现实这么骨感，我们能不能斗胆强调少测一点？测得精准一点？因此有了精准测试的想法，希望以这种反传统的观点带来一股新鲜的空气。在腾讯的一些团队中，精准测试已应用得比较熟练，从测试效果来看，算是走出了一条不寻常的道路。

我们希望给大家提供一种新的思路——如何做到“不测”？解放人力，弥补缺失，去除冗余。这是一本讲方法论的书，除了提供思想方法，还通过讲解最佳工程实践给出具体的指导。大家可以根据团队的现状找到最合适的切入点，逐渐达到“不战而屈人之兵”的境界。

讲方法论的书往往容易枯燥，我们不想讲得枯燥无味，那样就太对不起读者了。好在写书的几个小伙伴都对金庸老爷子有点崇拜，索性就把易筋经和独孤九剑给用上了，另外也把每个章节通过小故事衔接起来，希望大家喜欢。

由于时间仓促，作者水平有限，书中错误之处在所难免，欢迎读者朋友批评指正。从技术上说，精准测试是不完美的，也不可能是完美的，希望大家与我们共同探讨！本书适合的读者

本书主要介绍人工精准测试闭环和工具平台辅助精准测试闭环，用故事案例的方式阐述精准测试的方法，并给出质量度量的标准。此外，较为详细地阐述了精准测试平台建设的技术方案及其演变。

本书的目标是在不降低质量标准的前提下，探寻缩减测试范围，减少测试独占时长之道，主要解决的是传统黑盒测试回归内容较多、耗时较长的问题。

本书可能适合以下人员：

·探寻敏捷之道的测试leader、测试人员；

·陷入质量和效率两难境地的测试leader、测试人员；

·想要建设精准测试平台的测试人员、测试开发人员；

·想要对交付产品质量有更大信心的测试人员；

·想缩减测试独占时长的项目经理；本书内容及特色

本书有两条主线，一条线是故事线，是为了减少技术内容的乏味之故。编者尽量把晦涩的技术内容用平白的对话展示出来，便于读者理解。故事线各个章节前后贯穿，不可拆分。另一条线是技术线，可以拆分为四大部分，下面一一介绍。

第一部分（第1～2章）

主要是背景介绍。引入了敏捷转型的挑战、对自动化测试价值的探讨，以及开启测试分析的探索。

第二部分（第3～5章，第11章）

主要是讲人工精准测分的闭环，也是从传统黑盒测试转型的第一步。对这个闭环了解透彻，可帮助大家从现状中找到转变点，落地行动起来。

第三部分（第6～10章）

主要是讲为了持续提升代码测分的效率而搭建精准测分平台，并落地见效的过程，是一个平台辅助精准测分的闭环。这个闭环不仅可以给大家提供平台建设的技术方案思路，还可以给大家开展代码测分可能遇到的困境提供解决方案思路。

第四部分（第12～13章）

这是个总论，对整本书每章内容进行精辟的总结，并阐述在面临质量和效率两难境地时破局的思路。同时提出精准测试可助力大家迎接更大挑战。本书阅读建议

如果你是一个喜欢先看全书概论的人，建议你先看第12章，然后再从头看起。

如果你是一个急需了解精准测分如何落地的人，建议你先看第二部分，也就是第3～5章、第11章，然后看第12章，再看其他章节。

如果你是一个喜欢故事情节连贯的人，建议从头看起。关于作者

本书的作者们来自腾讯移动品质中心（TMQ）的电脑管家、手机管家和应用宝测试团队，他们长期实践精准测分，积累了很多实战经验。在精准测试的工程实现上，也做了不少的探索。近年来，在MIG无线研发部两位总经理冼文佟、陈诚的鼓励和支持下，TMQ的同学们踊跃将过去的知识和经验集结成册，分享给业界的小伙伴们。在继《腾讯Android自动化测试实战》、《移动App性能评测与优化》、《腾讯iOS测试实践》后，本书作为TMQ系列的另一新作，希望能从测试思想和方法上，给各位读者带来新的启发。

本书的思路大纲由李德广、刘建生、徐志广、李叶、杜晨亮提供。

本书主编：李德广、刘建生。

本书副主编：薛玲玲。

本书主要编著成员有：窦仟、何冬花、黄小勇、刘楚蓉、卢少娜、马识佳、尚鸿、王媛、熊彪、杨春喜、张艳、赵燕、朱伟鸿（按拼音顺序排列）。

引子

李德广致谢：

非常感谢各位小伙伴们在繁忙的工作之余，投入了大量的精力，终于把这本书完成了，再一次显示了我们团队的力量！同时感谢TMQ的几位总监：廖志、刘建生、丁如敏，携手打造了TMQ这样好的平台和分享氛围！感谢鼎叔张鼎，从一开始就和我们讨论这本书的思路！特别感谢出版社的吴怡编辑，自始至终都在关注我们，给了我们很多帮助和建议！

薛玲玲致谢：

首先要感谢的是，给我们团队带来精准测分思想的李德广、刘建生。没有这两位leader的思想引领和技术引领，就没有整个团队最终精准测分实战的落地和收获。非常感谢！

其次要感谢的是，业务产品对质量和效率的不懈追求。没有你们的鞭策和挑战，就没有测试团队持续攀登高峰的勇气和信心。非常感谢！

然后要感谢的是，TMQ从职业发展角度对业务测试团队提出了更高的技术要求，并提供了更宽广的视野，让大家前进的劲头更足。非常感谢！

更要感谢的是，本书的编者们，没有各位编者在百忙之中，抽出精力，写出自己的实战内容和体会，就没有这本书的完成，小伙伴们太赞了！

此外，我还要感谢我们的设计师老麦（麥偉強）、黄盛全，感谢他们于百忙之中帮助设计本书的主人公头像，大道至简，寥寥数笔，精准地刻画出我们主人公蓬勃向上的头像。还要感谢我们的同事廖海珍，没有她与出版社坚持不懈的催稿，我们这本书也许还要再等待几个月才会与大家见面，感谢！

最后，感谢我的家人们，正是你们的坚强后盾，赋予我坚持不懈努力前行的保障和动力，深深的感激，永远爱你们！

窦仟致谢：

感谢领导的前瞻视野。感谢测试对质量和效率的不断追求。感谢测开对技术的探索精神。感谢家人对我们工作的支持。

何冬花致谢：

从以前粗犷黑盒测试到现在的精准测试，在这个过程中，我们团队经过了一次次尝试和努力，终于形成了我们这本书。感谢我的领导和团队，让我在其中收获满满。感谢家人对我工作的支持。希望这本书会给你带来帮助，这不会是终点，希望跟在测试道路上前行的伙伴们一起努力。

黄小勇致谢：

用更有效率的手段来保证产品质量，一直是我们追求的目标。感谢安全业务测试组给予我们尝试创新的土壤，与各位小伙伴一起进行精准测试探索让我受益良多。同时也要感谢我的家人，你们的支持和鼓励是我不断进取的力量源泉。

刘楚蓉致谢：

感谢品质中心老大们对精准测试技术如何落地不断给予指导，感谢应用宝测试团队长期以来的支持与帮助，一次次的碰撞让精准测试在应用宝多FT运转模式下顺利规模化地运转起来，很大程度提升了测试效率。最后感谢我的家人对我工作的支持与理解。

卢少娜致谢：

感谢手机管家测试成员的努力，精准测试从一个模糊的概念到落实测试过程，从虚到实，脚踏实地帮助我们提升版本内容的质量和效率，让我们做好手机管家的坚实后盾。感谢安东和cody日常提供很好的帮助与指导，最后要感谢我的家人，给我的工作百分百支持。

马识佳致谢：

感谢腾讯，提供给我们追求卓越、勇于创新的土壤，感谢手机管家测试团队，感谢我的领导cody和安东，在精准测试、提升测试效率和质量的过程中给予的帮助和指导，感谢我的家人，对我一如既往的鼓励支持，让我遇到困难时能坚强地面对。

尚鸿致谢：

感谢安全业务测试组的小伙伴，工作中与他们的思想碰撞开阔了我的思路，他们在精准测试中的思考也给了我很大的帮助。特别感谢cody、彪哥和patia，得益于他们的指导在精准测试实践项目中我才能有所总结和突破。

最后感谢我的家人，是他们的支持和鼓励才能让我更专心的投入工作，享受工作带来的成就感。

王媛致谢：

感谢桌管测试团队对精准测试技术的不断探索和研究，让我能够将该技术实践于具体项目中，并有幸参与本书的写作，从而提升了技能，开拓了视野；感谢家人对我工作的支持和理解。

熊彪致谢：

感谢测试团队对测试质量与效率的极致追求，感谢我的家人对我工作的支持与理解。

杨春喜致谢：

感谢职业领路人刘建生先生在应用宝精准测试技术上的指导，感谢应用宝测试小伙伴在实施过程不断的思想碰撞让精准测试在应用宝版本测试中非常完善的落地下来，成为应用宝质量保证的不可或缺的利器。感谢本书的主编李德广先生让应用宝在精准技术实施的案例能够有机会跟大家一起交流。如果你希望更加了解你的被测对象，进而制定出非常专业的测试策略，此书将非常适合您。

张艳致谢：

感谢cody、gandalf在精准测分方面给我们带来的指导、灵感和思路，能与你们一起参与这本书的写作倍感荣幸；感谢电脑管家测试组的所有小伙伴，谢谢你们对我工作中的各种帮助和支持，与你们成为同事真的好开心；感谢所有合作过的开发、产品、运营等等所有的同事，与你们合作，我受益良多；最后，感谢家人，尤其是茜茜小朋友对我工作一如既往的理解与支持，你们一直是我最坚实的后盾，爱你们。

赵燕致谢：

首先要感谢我的领导李德广和高安东在工作中给予我的帮助和指导，其次要感谢我同组的小伙伴长久以来的支持和帮助，最后要感谢我的家人在生活中给予我无微不至的关怀，让我能够专心致志地工作。

朱伟鸿致谢：

感谢广州测试组的小伙伴的支持，感谢他们给予我的指导和提供各种各样的灵感；其次感谢cody与安东，感谢他们在测试工作中给予我的支持与帮助；最后感谢我的家人，特别是我的老婆，感谢家人对我工作的支持，感谢老婆一直以来的陪伴。引子

我们这本书的主人公叫腾小宇，本书讲述的是这名IT男的故事。故事？这不是一本讲测试技术的书籍吗？技术和故事有几毛钱的关系？客官别急，容我慢慢道来。

腾小宇，年方二八。哦，不对，没那么花季，刚满22岁。此时，正值盛夏，他正在一列飞驰的高铁上。百无聊赖中，翻开朋友圈，一条消息跳了出来：2016最励志的程序员——小王毕业一年，省吃俭用，公司安排食宿，不交女朋友，不旅游，一年后存了2万块钱，加上老爸给的98万在市中心买了一套房。

看到这里，小宇不禁笑了起来：“还以为真是励志故事，原来又是一个段子手。”

小宇最近刚从北方一所知名大学毕业，随着浩浩大军南下深圳。在南下的高铁上，小宇开始浮想联翩。“听师兄说今年深圳的房价飙升，很多人都不愿意去深圳了，我这个时候去，是正确的选择吗？”

腾小宇老家在南方的一座小城市，父母都是工厂的工人，能供上他念完大学就已经很不错了。他也没奢望在买房这种事情上，父母能给予多大的帮助。他坚信爱拼才会赢的道理。想到这里，他不由地坚定了自己的想法：“没啥大不了的，深圳机会多，总会成功的！”

他回了几条微信消息，都是几个哥们发来的，问什么时候到站。聊完后，小宇看了看时间，下午4点整，还有2个小时才到深圳。于是，他翻出背包里的一本书，痴迷地看了起来。

小宇是个武侠迷，尤其喜爱金庸老爷子的小说《笑傲江湖》，他羡慕令狐冲的不羁和洒脱。话说那令狐冲在机缘之下学会了独孤九剑，之后就无敌于江湖，这是多么让人羡慕的事情啊。小宇不知不觉睡着了，朦胧中感觉有人在拍他的肩膀：“你好，到终点站了！”。小宇睁开眼，急忙拿起背包，拖着行李箱下了车。走出火车站，回头望了望，大楼上硕大的四个大字：深圳北站！

小宇不由得感到一阵兴奋，这就是深圳啊！他掏出手机，拍了几张照，准备一会儿发给哥几个看看。时针指向晚上6点30分，特区此时还是大白天，阳光还很刺眼。小宇定了定神，开始想想接下来的计划。他要先去一个师兄那里借宿一晚，明后天是周末，刚好找个房子。他正准备叫个滴滴，突然想起来，入职通知中说交通费是可以报销的。于是，他穿过站前广场，顺着标识走进地下停车场，排队打车。

排队的车很多，打车的人也很多，但奇怪的是秩序井然，一点儿也不乱。小宇不由得感叹道：“深圳人民的素质果然不一样”。不一会儿轮到小宇了，他跳上一辆出租车，冷气扑面而来，真舒坦。

小宇打车到了宝安区的一个农民房小区，师兄已经在楼下接他了。“师兄，你们深圳的出租车怎么有两种颜色？”“你们深圳？深圳暂时还不属于我的。”师兄不愧是学计算机的，逻辑好严密。“哦，很快就属于你了。”“红色是关内的出租车，绿色的是关外的出租车。你看你坐的就是绿的。”“哦，原来如此。”

两人把东西陆续搬上楼，安顿好，已经晚上8点了。这时，师兄提议说：“走，小宇，吃饭去”，小宇这才想起来确实饿了。他们走出单元门，往不远处嘈杂的地方走去。

小宇师兄住的这个地方，有好几十栋楼。楼与楼之间挨得很近，最近的地方打开窗户都能握着手，所以很多人都管这种楼叫握手楼，这是广州和深圳的一大特色。

楼下的这条街很热闹，有各种店铺。卖吃的、穿的、玩的，应有尽有，还有那么一两家闪着霓虹灯的理发店。师兄带着小宇找了一家湖南菜，点了几个菜，胡乱吃了起来。“来，小宇，干一杯，欢迎来到深圳！”“多谢师兄照顾！”

两个人边吃边聊，师兄追忆起了校园时光，不时和小宇确认某某老师近况，某某地方怎样了。小宇也不时向师兄请教深圳的感受，两个人好不热闹。“师兄，明天我去哪里找房子好点？”小宇问道。“就这附近吧！生活和交通都方便，离科技园也近，坐地铁可以直达。”“好，明天你有事先去忙，我自己搞定。”“真的搞得定吗？”“没问题！我从小就一个人独立惯了。”“好，那有事打我电话。”

小宇听了一番师兄的交代后，对找房子表示毫无压力。在深圳的城中村中租房，你只需要去每一栋楼下看房东贴的告示就行了。有空房会在上面写出来，想租房的打电话给房东，房东会下来带着你看房，谈价钱，谈好马上就可以入住。

第二天，小宇按照师兄的指示开始了找房行动。果然不怎么费劲，他就看过了三四套房子。最终，他看中了其中一套5楼的，月租1000块，房子里什么都没有，全要自己买。不管怎么样，总算有了一个自己的小窝。腾小宇有点小小的兴奋，在剩下的时间中，他买了几大件儿——床、床垫、衣柜、热水器。

周末一转眼就过了，此时的腾小宇，已经安顿下来。明天就是上班报到的第一天，他充满了期待和紧张。 第1章你心急如焚，我举步维艰第1节初见真颜

上班第一天，小宇早早起床，洗漱完毕，兴奋地背起电脑包搭乘公司班车，一路上小宇心里充满了期待，他心里默默想着：新公司的高大上的办公环境一定很舒适，我的leader是男的还是女的呢？周围的同事一定都很厉害吧，我一定要向他们好好学习，早日成为IT界的大牛。小宇的思绪随着班车的前行越飘越远。“马上就到海滨大厦了，在这里上班的可以下车了”，司机温馨的提示语打断了小宇的思绪。随着人流小宇终于踏入了公司的大门，心里既激动又紧张。

迎接小宇的是亲切甜美的HR姐姐，在HR姐姐的带领下，小宇来到了将要工作的项目组，见到了自己的直属leader莎姐，莎姐留着短发，带着黑框眼镜，显得十分干练且自带强大气场，小宇显得有些拘束，简单做了一下自我介绍。“腾小宇，来，介绍一下，这是你的导师，叫陈导就行”，莎姐指着旁边一位身材稍微发福的人说。“你好，陈导！我叫小宇，请多多指教。”“欢迎！不多说了，一会儿有个项目例会，你跟着参加吧。”“好！”

小宇嘴上答应着，心里却嘀咕着：“节奏也太快了点吧，第一天不是应该先熟悉环境，装好电脑，安装必备软件，申请账号，开通权限之类的吗？”虽然心里充满疑惑，但是作为新人抓住机会赶快适应项目也未尝不是一件好事，趁着开会前小宇赶紧装好电脑和一些常用软件，以最快速度进入工作状态。

环顾四周，同事们都专注于自己的工作，整个办公室都凝聚着紧张的气氛。如小宇所料，IT公司工作强度都是很大的。此时小宇心里有一丝丝疑虑，他一方面担忧自己能否适应这种高强度的工作，另一方面又想既来之，则安之，努力适应当前的环境，作为新人他需要成长。第2节　敏捷转型

项目例会开始了，今天有点奇怪，部门的boss也到场了，大家议论纷纷，觉得一定有不同寻常的事情发生。

果然，boss首先说话了：“同学们，今天给大家宣布一件重大事情！鉴于目前行业现状和公司业务上的要求，我们考虑践行敏捷转型！”“哇塞，敏捷？这个词好熟悉！”下面开始议论纷纷。

boss接着说“没错！虽然敏捷已经在行业里面风靡了好几年了，但是对于我们这样的公司，因为业务性质的关系，我们一直比较谨慎。但经过这几年的观察，我们不得不面临转型的挑战，我们的产品需要快速迭代发布版本！”“领导英明！”众人纷纷支持。“别拍马屁了！鉴于此，我们技术部做出了一个决定，邀请了业界知名的敏捷教练，同我们一起实施这场变革！”boss制止了喧闹。“哇，牛！期待看看是谁！”“下面让我来介绍一下……”

腾小宇听得入迷了，在他看来，自己刚踏上工作岗位，就碰上了这样的事情，实在是梦寐以求。一直以来，他是学霸，计算机编程高手，恨不得有三头六臂，把自己所有的精力都投入到工作中。

在接下来的几个月里，敏捷像一阵风一样侵袭公司的每个角落，包括总经理办公室、会议室、文件打印室和洗手间。不管是研发领导们，还是开发工程师们，仿佛在一夜之间都彻底恨透了CMMI，甚至连配置管理和SQA工程师们也跟着起哄，互相奔走相告践行敏捷转型：“以后不怕产品加需求和变更需求了，尽管放马过来吧！”“终于可以不用加班熬夜写系统设计文档了，让流程见鬼去吧；终于可以想怎么写代码就怎么写代码了，不用为了修一个bug，改一行代码就看测试人员的脸色。”“嗯，SVN服务器的目录和空间可以省一省了。”

……

仔细观察这些人的眉宇之间，好像隐隐有了一种马上都要“出任CEO，迎娶白富美，走上人生巅峰”的豪情壮志。

然而，在这万众欢呼庆祝敏捷转型的到来之际，却有那么一群人看起来不太对劲，会议室里，几个测试员正紧缩眉头，集体苦苦思索着。敏捷转型意味着去流程化，可以想象这对测试人员来说是多大的挑战，需求说变就变，代码想改就改，测试效率如何提高，测试质量又如何保证呢？腾小宇作为一枚新人，当然还体会不到其中的困惑，只是意识到敏捷转型已经是一件势在必行的事情。

敏捷转型的号角已经吹响，各个项目都开始进行敏捷转型落地，开始改革各种流程。产品需求说改就改，测试人员只好见招拆招，你改需求我就要求延长测试时间，作为测试人员质量是最重要的，但敏捷强调快是王道，看起来这似乎是矛盾的。

现实中测试面临的挑战

在传统体系中，我们希望很多事情都是完美的，在测试人员眼中的软件研发应该是这样的：

a）需求是清晰的。

b）流程是固化的。

c）开发是有序的。

d）系统是可测的。

e）测试时间是充足的。

f）用户是讲道理的。

可是，理想是丰满的，现实是骨感的！我们看到的是这样的：需求频繁改，开发者的交付问题多，测试者总是被催促，用户骂声一片，产品经理拼命想点子。

是这个世界太疯狂了吗？不是的。互联网的变化越来越快，用户越来越在乎体验，客户越来越挑剔；交付压力也越来越大；这一切的一切都使敏捷显得势在必行。

既然我们对需求频繁变化不再陌生，并且开始慢慢认为这是合理的；开发人员延迟开发计划、压缩测试时间，已经成为常态。测试经常会是最后的一道工序，加班加点似乎已经成了一种习惯。

那么问题来了，在这种情况下：

·我们还能随心所欲地设计大量测试用例吗？

·还有大段的系统测试时间和集成测试时间吗？

·还能要求充足地回归测试吗？

·还能期望开发人员提供各种测试建议吗？

·现实如此，测试还能不能愉快地进行下去了？第3节　被挑战了

腾小宇在这样的环境中，每天努力工作，在完成培训计划的同时，也承担部分的测试工作，成长很快。直到有一天，他所在的测试组收到了一封邮件，来自平时一向表现稳重的一个业务部门的运营同事，原文大概如下：

致技术部的大牛们：

我一向认为自己谦虚友善、善于沟通，也尊重技术部同学的专业性和工作评估；但今天我忍无可忍，因为业务冲量迫在眉睫，所以希望能够修改激励用户的一个小小的奖励算法。

开发哥告诉我只要修改一个公共方法，三行代码；但你们的测试姐告诉我，因为不确定影响了哪些功能，为了确保不出问题，所以要测试所有的核心功能，一个全职投入的测试姐要一个星期的工作量。加上各种版本管理的时间，这样一个简单的需求，需要两周才能上线。

我们还是遵循敏捷研发流程的互联网企业吗？难道这个工作效率比有关部门会高一些吗？

我也是技术部出身，以前我曾深深地以技术部为荣，今天，我不得不以技术部为耻！“这么劲爆的邮件！”腾小宇心里想，“要回复吗？该怎么回复呢？”可是，等了一个小时，两个小时，四个小时，还是没看到谁来回复这封邮件。可是，小宇注意到，自己的leader莎姐神色凝重的坐在那里，一言不发。

小宇心想：“不是在憋什么大招吧？”

可是，这一天就这么平静地过去了。转眼到了周末，大家又都各自忙各自的去了。回归测试带给我们的痛苦

场景一：

开发哥：“刚修复了一个紧急用户反馈，安排测试测一下吧！”

测试姐：“改了哪些地方？对哪些功能有影响？”

开发哥：“改了好些地方，为了保险，把基本功能都测一下吧。”

场景二：

开发哥：“昨天的修改测试完成了吗？”

测试姐：“哥，别催！还在测试中，要跑500个用例呢！”

开发哥：“啊，我只修改了一行代码吧，怎么需要测这么多呢？”

对于以上对话，是否有似曾相识的感觉？作者不敢妄自揣测所有人都经历过，但在作者的职业生涯中，这样的情况很常见，至于结果，那就是留下测试人员独自在风中凌乱。测试为什么要测这么多地方？因为我们需要做大量的回归测试。

在最早的测试理论中，对回归测试的定义是这样的：“回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。回归测试作为软件生命周期的一个组成部分，在整个测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。内容通常是重复以前的全部或部分的相同测试。”

在测试实践中，回归测试需要反复进行，当测试人员一次又一次地完成相同的测试时，这些回归测试会变得相当令人厌烦，当大多数回归测试需要手工测试来完成的时候尤其如此。传统的测试理论是这样建议的：“在给定的预算和进度下，尽可能多地、有效地进行回归测试。”

在互联网的企业中，这种现象也非常常见：一个有一定的功能复杂度，开发测试人员在30～50人左右的产品，测试用例总量上万是很常见的事；即使我们只选取核心功能作为缩减后的回归测试用例，也高达2000～3000或以上。我们来看看一个实际的较大版本的测试工作量评估：

·开发工作量估算：35人月。

·测试工作量估算：13人月。

·第一批需求测试：约1000测试用例，需25人日。

·第一批回归测试：约800回归用例，需20人日。

·第二批需求测试：约800测试用例，需20人日。

·第二批回归测试：约600回归用例，需15人日。

·第三批需求测试：约900测试用例，需23人日。

·第三批回归测试（可能会和集成测试合并）：约600回归用例，需15人日。

·集成测试：约2500用例（主要指集成相关的测试用例集合），需63人日。

·整体回归测试：约3700用例（部分需求用例加上部分缩减回归用例），需93人日。

·预发布回归测试：约500用例，需13人日。

这个计划可能还是一个相对比较保守的计划，如果在开发过程中，由于开发过程质量比较差，出现比较多的bug，那么零散的回归测试会更多。

从这个计划上来看，实际上需求测试的用例执行次数约为2700次，回归用例的执行次数约为8700次。回归测试执行占总测试量的比例为76%，而且至少超过半数都不是新写的（新需求或需求的变化），为什么？多数团队从风险规避的角度出发，即使知道这样的测试必定是有冗余的（多么痛的领悟），也不得不扩大测试范围。“谎言重复一千遍就变成了真理”，在测试行业中，这种现象很普遍，测试人员甚至把这样的现象奉为方法论。第4节leader的分析

周一一大早，大家刚到齐，就听见莎姐吼了一句：“兄弟们，咱们开个会！”

会议室里，莎姐环视了一周，缓缓说道：“同学们，知道为什么这么着急叫大家来开这个会吗？”“应该是上周那封邮件的事情吧？”腾小宇试探性地说了句。“没错，就是那一封邮件！经过这几天的思考，我觉得对方挑战得对！”“……”大家面面相觑。“敏捷转型已经开始运行一段时间了，而我们测试同学还是沿用传统的测试思维，为了保证软件质量，对于一些细微的改动仍不惜花费大量的时间进行回归测试，但是这真的有必要吗？作为测试我们是否也应该考虑转型。”“这是我周末经过深入思考做的一些总结，打印出来给大家看看，大家看完后可以发表自己的意见和想法。”

腾小宇接过传过来的一叠纸，仔细阅读起来，上面列举了过去的测试策略和测试流程，分析了过去测试策略上的优势和劣势，特别是对过去的测试策略和测试流程在敏捷转型后面临的挑战进行了分析。

大家你一言我一语讨论起来，气氛非常热烈。看得出来，大家对于敏捷模式下的测试工作，还是有很多想法的，总的来说就是要保证质量和提升效率，最终在如何提升回归测试效率的问题上，大家形成了两种意见：

1）缩减回归测试的范围。

2）依靠自动化测试。

对于第一种方案，赞成者居多，但是如何去实现，经过几轮PK后仍然没有好的方案。于是，莎姐再一次站了出来，自动化测试是业内比较成熟的做法，我们可以先尝试一下第二种方案，依靠自动化测试来解决回归测试的效率问题。第5节自动化，想说爱你不容易

腾小宇他们所测试的产品，是一款互联网的PC音乐播放器，用标准的C++开发的软件。说到自动化测试，大家都不陌生，因为在过去的几年中，测试开发团队已经做出了一个自动化测试框架。

开会后的第二天，莎姐召集了几个人，其中就有陈导，开始讨论自动化测试的实施方案。“我们可以用现成的自动化测试框架，以前测开组做的那个。”彪哥第一个发言。“还能用吗？我们的UI可改了好几版了。”陈导提出一个疑问。“应该没问题。只要开发哥还遵守了以前我们定义的规范，UI对象应该还可以识别。”彪哥答复。“这只是设想，需要去摸个底。”陈导说。

按照大家讨论的情况，莎姐做了分工，腾小宇也被安排进了这个自动化突击队，因为他在面试时表现出的良好代码能力给莎姐留下了深刻的印象。莎姐觉得这样的人才应该在这个关键时刻用上，加上小宇是个新人，更需要这样高强度的项目来磨练，帮助他快速成长。

自动化突击队开始了自我救赎之路，他们挑选出了所有的P1级别的用例，数量在500个左右。腾小宇也被分配了任务，他的工作是按照手工用例的步骤，在自动化框架下写测试脚本。

经过半年的努力，自动化测试突击队终于圆满的完成了任务，看着自己写的测试代码如丝般顺滑地跑了起来。大家的心里别提有多高兴了。尤其是小宇，这是他进公司以来参与的最有挑战的工作，此刻心中充满成就感。

自动化测试脚本每天都在跑，大家心里充满了期待，希望在最近的迭代版本中，自动化测试能在回归测试中派上用场。

紧张的时刻到了，在更新了版本代码后，发现很多用例都跑失败了。“咦，怎么这么多用例都跑不过去？”腾小宇第一个发现了问题。“我去，查一下，是咋回事！”陈导跳了起来。“这个版本做了UI大改版，以前的UI控件被改得面目全非了，整个操作流程都改变了……”陈导说。

这天晚上，时针指向10点整，腾小宇还在和大家调试自动化测试的脚本。“陈导，咱们自动化测试怎么这么脆弱呢？”小宇鼓起勇气问了句。“没办法，UI自动化天生就有这个缺陷。高度依赖UI属性，一旦产品的界面发生改变，脚本的维护量非常大。”陈导耐心地解释着。“哦，有人解决过这个问题吗？”小宇问。“很少。据我所知，在传统软件领域内，还有那么一些公司的自动化效果还不错，但是他们的产品不像我们互联网公司的产品，产品UI相对比较固定。”陈导望着远方说道。“哦，确实是，我来这里一阵，界面就改了两三回了！”小宇若有所思。“嗯，别想那么多了，今晚先把眼前的问题解决了吧！”陈导催促到。

在一瓶瓶红牛的助力下，突击队终于把所有的用例维护好了。踏出公司大门的那一刻，小宇看着漫天的星斗，吸着凉爽的空气，感觉脑袋特别清醒。他发了一篇朋友圈：凌晨2点的天气，真好！第6节自动化测试的价值

小宇所在的自动化突击队，在经历了半年的攻坚、兴奋、持续维护之后，大家集体陷入疲惫状态，leader莎姐及时发现了这种现象，带领大家就几个问题进行了深刻的反思。1.传统的自动化价值有哪些？

一些“敏捷理论”里是这样说的：“在传统的瀑布式开发里，自动化测试的推行，是一种进步；而在敏捷研发模式里，自动化是必不可少的基础。”

·自动化测试能提高效率，缩短测试工作时间。

·自动化测试和人工测试相比，每一次的测试执行操作都是固定的，非常忠实、可靠。

·自动化测试能加大每一轮回归的力度，从而提升测试覆盖率。

·自动化测试具备更好地重现软件缺陷的能力，因为它有很强的一致性和可重复性。

从以上的声音出发，很容易得出一个结论，自动化测试能节省人力，能缩减测试人员的投入，能增强测试有效性。它不仅能为老板省钱，也比人做得更好。

传统自动化ROI（成本与收益）的公式也是这样写的：

自动化的收益＝迭代次数×全手动执行成本―首次自动化成本―维护次数×维护成本

或者如果假设迭代次数和维护次数近似相等，这个公式在某些情况下可以成立，比如一个比较新的产品：

自动化的收益＝迭代次数×（全手动执行成本―维护成本）―首次自动化成本

正因为有这些光环，所以自动化测试的价值很容易说服老板们。

从这个公式里也很容易看到，实际上传统的自动化ROI分析，主要是基于把自动化测试定位在回归测试执行者的角度。

然后，这里实际上有一个很大的前提。也是传统的自动化理论“赖以生存”的基础。这个前提就是“测试做得越多越好”。老板们对测试覆盖率的理解，分子是指测试或自动化测试跑过的用例数，分母是产品所有的功能对应的测试用例。

这个理解仅对于一个全新的、第一次做的项目或产品，是正确的；但对后续的“迭代”和“增量版本”来说，也是合理的吗？前面我们已对回归测试做过分析，在回归测试中，有很大一部分是因为项目团队及测试人员的“不放心”，因为不放心进行测试，冗余比例是非常高的。也就是说，我们上述的自动化ROI计算公式，收益很大一部分也是来自于这里。2.回过头来重新思考，自动化测试的价值到底在哪里？

谈到这个话题，我们需要先温习一下自动化测试的定义。

传统的自动化测试，通常是指测试过程被自动化。简单说就是把手工测试的用例让机器去做。

广义的自动化测试应该包括：

·测试环境的搭建和管理；

·测试环境的检查、监控和报警；

·测试代码的静态检查、编译和构建；

·测试场景的构造，测试数据的自动化准备；

·测试用例的分发和执行；

·测试结果的保存与管理；

·测试报告的生成；

·测试优先级的建议。

从自动化测试的类型上，可划分为：

·单元测试；

·代码静态检查，文件检查，签名校验，证书检查；

·接口自动化测试，又分本地接口测试和服务接口测试；

·UI自动化测试（包括Web UI，Windows/手机/Pad/智能硬件等终端UI）；

·性能测试（本地性能测试和服务性能测试）。

在项目测试的实战中，这里所有的广义自动化类型和内容都有可能被使用到，并且被使用时的场景都是不一样的。例如UI自动化帮助我们回归；静态检查、接口测试、性能自动化测试，做到了人工测试无法测试到的场景；所有这些自动化测试都有可能在开发人员还没有移交给测试人员的时候，就开始介入到测试工作中去，提早发现问题。

好的自动化测试不能仅仅考虑时间和资源成本的节省收益；好的自动化测试应该能带来迭代周期的缩短，从而缩短项目周期；好的自动化测试应该能让某些时候变不能做为能做，进而带来的机会收益是巨大的。

总结一下自动化测试可能的价值：

1）帮助回归、节省人力。

2）构建人工测试无法构建的场景、数据准备，或执行一些人工测试做不到的测试用例，有效提升测试覆盖率。

3）前置测试，让测试和开发有可能并行，提升项目敏捷度，降低测试独占周期。3.找到方向

但是，不管自动化测试有多大的价值，从本质上来说，它只不过是按照人工设置的场景按部就班地去执行，说白了是执行工具而已。所以，着急补齐的并不是自动化测试，而是如何缩减回归测试的范围，如何让不能做的测试变得能测，进而再考虑如何让自动化测试发挥最大价值。

测试独占周期是指从开发正式将版本、迭代、需求移交给测试开始，到版本达到待发布状态的时间长度，这个周期内包括测试活动，也包括开发活动（如修改测试出来的Bug，开发一些临时变更或新增的需求等）。

测试覆盖率传统上是指测试执行的用例总数除以所有测试用例总数，本书提到的“测试覆盖率”，区别于“传统测试覆盖率”，是指测试执行的用例总数/需要真正被执行的测试用例总数；区别在于分母并不包含因为“担心影响到”“害怕有问题”从而执行的大量低价值回归测试用例。

测试业界对测试用例的叫法可能存在不同，有些公司可能会称之为“测试案例”，或“案例”，这里统一称为“测试用例”，含义为测试执行的最小颗粒度，适用于手工测试和自动化测试。自动化测试的代码则称为“自动化测试脚本”或“自动化脚本”。测试员之路在何方

一家节奏非常快的互联网企业，测试经理在逐个面试来应聘的候选人：

测试经理：“我们公司的交付速度非常快，每个版本需求虽然不多，但只有几个小时或1天的时间测试，如果你来承担这个工作，你会怎么做？”

A：“假如我很精通业务，了解需求，我会很有经验，知道这些需求大概会需要测试什么，所以我通常测试得很快”；

B：“我会要求开发哥跟我讲清楚，我需要测试什么，开发哥给我的测试建议非常重要，我根据建议，认真仔细地去测试，就能保质保量”；

C：“站在用户的角度去测试好了，我们抓准用户的需求，做好需求分析，就能更轻松地去测试”；

D：“其实测试没有那么复杂，就是一个鼠标点点，眼睛瞄瞄的工作而已”；

……

无论你是面试官还是被面试者，这样的问题都很常见。测试从业者在工作多年后，或多或少都会有职业困惑：

我是不是选错行业了？如果我当初选择做开发者，做产品经理，是不是现在会拿到更高的薪酬，获得更大的职业成功？

测试人员的未来和发展是什么？除了在管理职位上晋升到主管、经理、总监（好像也到头了），难道只能转项目经理、产品经理、产品运营，甚至是商务？（回音：还是选错行了……选错行了……错了……）

我们首先来问自己一个问题：“你为什么要选择做测试。”

估计抓十个人来回答这个问题，九个不会说实话。什么“我热衷于发现bug的乐趣”，“我的性格比较细心、耐心，适合做测试这个行业”，“测试能够让我开阔眼界”，等等。很多面试官在听到这个答案时，都是“会心一笑”，因为“你懂的”。真正的答案只有一个，测试的门槛看似比较低。不管你是否愿意承认，这的确是绝大部分人入测试者这一行的真正原因。

从大多数公司的发展过程来看，测试团队的发展也会大致经历以下4个阶段：

阶段一：公司刚起步，产品初创，需要先把东西做出来获得市场的初步验证，或获得投资人的认可。这个阶段往往还不需要测试人员，即使有也是个把人。

阶段二：公司开始快速扩张，不计研发成本，每天都在不断地招聘测试人员。

阶段三：经过快速扩张后，开始稳定运作，成本开始被考虑。技术部思考如何适度控制成本，如果少量裁员，最先考虑的往往是测试人员。

阶段四：开始严格控制各个环节的成本，老板们开始考虑把测试工作往上游转移。此时大量的新词汇开始进入测试人员的KPI中，例如推动单元测试、开发自测、控制递交测试质量、降低测试独占周期、提升敏捷度，等等。那如何将测试的工作往上游转移呢？

入门容易精通难，这是测试行业现状。从测试行业的从业人员分布来看，绝大部分是黑盒测试人员（以手工功能测试为主），少部分是测试分析人员、自动化测试人员、性能测试人员，只有极少部分的测试架构师、测试分析专家，如图1-1所示。图1-1　测试行业的从业人员分布图

从一个职业发展的角度，衡量职业核心竞争力有多强，最重要的不是我做了多少年，而是我的工作是否可被轻易取代。所以如果有一天测试行业出现危机，首当其冲的就是金字塔底端的黑盒测试人员。实际上在许多互联网巨头公司中，这个情况已经开始发生了，这部分的人员已经开始被缩减，或被外包取代。

谈到这里，我们再来问自己一个问题，我们的核心竞争力在哪里？

有些人说，我比开发人员精通业务，我善于从用户的视角出发去考虑业务。但最精通业务的不应该是产品经理、产品运营、市场研究人员吗？这好像不算是测试的核心竞争力。

还有些人说，我比公司的业务方更懂技术。这听起来有一些道理，但实际上并不一定成立。要知道开发人员进行需求开发之前，也需要深入了解业务逻辑。的确有很多开发人员在这方面做得不够好，但我们的核心竞争力不应该建立在其他岗位做得很不足的基础上。

有些人说，从技能上来说，我和开发人员相比似乎没有什么太大优势；但在思想上，我才拥有测试思维，这是开发人员不具备的。开发人员来做测试不是能力问题，而是思想问题，这是最难以改变的。这一点听起来似乎的确很有优势。但我们测试人员中，开发技能最好的那一批去哪里了？很多情况下，他们都转去做开发了，并且比一般的开发人员做得更好，也很注重自己的代码质量，测试这些人提交的内容，你几乎很难发现bug。

那么，亲爱的读者，你的核心竞争力会在哪里呢？ 第2章易筋经和独孤九剑第1节启动探索

莎姐带领大家重新审视了自动化的定位，明确了下一步敏捷的方向之后，又专门开了一次沙龙，和大家一起探讨如何在保证质量的前提下，缩减回归测试的范围。

沙龙会上大家畅所欲言，各位有经验的前辈纷纷出谋划策，想了不少方法，比如让开发自测、产品走查、灰盒测试等；但同时又提到了很多现实的困境，比如开发自测很难推动、测试没有代码权限很难有话语权等。经过几轮难点和方法的聚焦，一个最有可能但难度最大的事情逐渐浮出水面，那就是代码分析。大部分人对此持观望态度，称现有业务测试压力太大，代码分析又要投入更多精力，且不知道对测试范围缩减的贡献有多大，很难兼顾质量和时间要求。莎姐看了大家一圈，并没有表态，只是总结发言说这次沙龙开得非常成功，看到了大家的问题，也看到一些解决方案，接下来会认真研究并推动落地核心方案。

莎姐不愧是leader，接下来居然很快为大家解决了代码权限的问题，并在组内开始创建代码分析的文化氛围。事后听人传言，莎姐为此和GM们PK了半天，带上技术很牛的陈导一起阐述利弊，还立了军令状，称一年内要是没有效果，就自动离职。小宇不由得对莎姐心生敬佩，同时对代码分析这件事情重视起来。

莎姐在例会时和大家说，代码权限大家已经有了，探索的方向已经清晰，就是走代码分析来缩减测试范围这条路，但考虑到目前还没有成功经验，所以并不会对所有业务强推，而是采取先锋队的方式，先由一两个项目摸索出成功经验，然后再推广开来。陈导作为具有丰富经验和技术能力的大牛，将会作为先锋队的导师，参与进去出谋划策。莎姐同时表示，先锋队采取自愿加入原则，需要大家在不影响原有业务支持的前提下来探索新技术、新方法，过程如需更多资源，会全力协调支持。小宇听了，虽然对为什么要分析代码不甚明白，但对莎姐的决心和支持看得很明白，心里面开始摩拳擦掌。第2节曙光乍现

项目仍旧以双周发布的节奏进行着，一天，莎姐走过来对小宇说：“小宇，线上出了一个问题，有点严重，要马上发一个补丁版本出去！”“哦，这么着急，要什么时候发？”“两个小时后，你去找一下开发哥，对接具体情况。”“好！”

腾小宇急忙跑去找开发哥，问清楚了情况。原来，前几天发布出去的版本在部分用户机器上出现了问题，和用户的机型有关系。“开发哥，你这次打算怎么修这个问题？”“我就改几行代码，加个判断，做个特殊处理。”“明白，改好了告诉我。我这就去准备测试环境。”

回到座位上，腾小宇开始准备测试。不一会儿，开发哥跑过来说：“改好了，你赶紧跑一下，没问题就发布。”“哥，你的改动风险大不？”“应该不大，不过为了保险，你还是把整个模块功能都回归一下吧。”

听到这话，腾小宇感觉此时心里犹如万马奔腾：莎姐要我两个小时就发出去的版本，你让我整个模块功能都回归一遍，半天时间都不够。思来想去，与其坐以待毙，不如主动出击，去分析一下开发的代码如何。

说干就干，小宇从SVN中把整个开发工程导（check out）出来，找到刚才开发哥提交的代码，一对比，别说，还真有大的发现。经过分析，开发哥就真的只加了个判断语句，细想之下，风险系数很低。于是，腾小宇满怀信心地只测试了两个用例，分别针对这个判断的true和false条件。5分钟就结束了测试，新的版本即将通过运维人员发布上线。看到这里，小宇内心里不由得泛起一股自豪的感觉。

亲自分析开发实现，评估改动的风险，测试内容比开发要求少了太多。此时小宇感觉仿佛漆黑的夜晚点亮了一根火柴，感觉好像找到了方向。新的版本已上线，观察了一个小时以后，各项数据都正常，小宇终于踏出了公司的大门。大街上依旧灯火通明，此时小宇的内心也感觉明亮多了。第3节为什么要关注开发实现

腾小宇回到家，开始认真思考这个问题：我们为什么要关注开发实现，进行代码分析呢？

很多人都说，测试工程师应该从用户角度去分析。对，确实是这样！但是这样就足够了吗？从过去的经验来看，如果我们不了解开发实现，会带来几个问题：回归测试冗余，被开发哥忽悠，测试起来像是用大炮打蚊子。

腾小宇翻开一本书，里面讲解了几个概念：

白盒测试：知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都能按预定要求正确工作。

黑盒测试：在测试时，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，检查程序功能是否能按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。

白盒测试的优势在于对程序内部实现的了解，黑盒测试的优势在于对用户场景的把握。那有没有可能把这两者结合起来呢？既从用户角度出发，又关注程序的内部实现。

思考到这里，小宇觉得这个问题越来越有趣了，不由得兴奋起来。测试是一种破坏性的活动，归根结底，是基于不信任的一种挖掘和验证工作。对产品需求和产品设计，对开发的系统设计和代码实现，都是不能简单地信任的。不然，哼哼，分分钟被“坑”没商量。

不入虎穴焉得虎子，只有去了解开发者的实现，才有可能赢得这场战争。而关注开发实现，不就是要让测试变得更精准一点吗？

想到这里，腾小宇对莎姐的远见充满了钦佩，隐隐觉得似乎得到了一本秘籍，他要带着这个想法去找陈导好好探讨一下。第4节测试分析理论的由来

第二天吃过午饭，腾小宇急急忙忙找到了陈导。“陈导，我这两天有一些想法，对咱们的敏捷测试应该有一些作用。”“哦，不错，说来听听。”“我想找一种结合白盒测试和黑盒测试的方法，目前想到的是通过分析开发的代码来测试。”“咦，这个想法正合我意，说来听听。”“白盒测试的核心思想是程序逻辑。”说到这里，腾小宇兴奋地找了支笔，在白板上画了起来。如图2-1所示。图2-1　白盒测试与黑盒测试的核心思想

陈导不愧是江湖上混了多年的老司机，一眼就看懂了，他接过话题，开始引导起来：“传统的黑盒测试方法主要有等价类、边界值、场景分析、因果图、判定表、错误推测、正交实验设计、功能图。”

温习完黑盒测试的分析法，腾小宇突然觉得有点打完杨氏太极拳八式的感觉：倒卷肱，搂膝拗步，野马分鬃，云手……十字手。轻松自如，均匀缓慢，若行云流水，连绵不断。细细一品味，还有修身养性的效果。

陈导继续说道：“黑盒测试分析方法在传统测试中非常实用，对功能相对复杂的大型产品，这简单的八招，能快速解除测试人员面临功能场景或条件穷举的尴尬处境，可谓借力打力。但弱点也很明显，从无数项目的实践经验来看，黑盒分析符合二八原则，能挖掘出80%左右的bug，剩下的20%一半靠运气，另外一半就有些力不从心了；而且一旦对手招式过快，更显得有些应接不暇，顾此失彼了。”

腾小宇听得头头是道，不住地点头。

我们再来看看白盒测试方法：

·语句覆盖：程序中每一条语句至少被执行一次。

·分支覆盖或判断覆盖：程序中的每一个分支至少走查一次，即每一条分支语句的真值执行一次，假值也执行一次。

·条件覆盖：当判定式中含有多个条件时，要求每个条件的取值均得到检验。

·判断/条件覆盖：同时考虑条件的组合及判定结果的检验。

·路径覆盖：使程序沿所有可能的路径执行。“小宇，你听了这些对比分析，有什么感受？如果说黑盒测试方法，感觉有太极的浑厚踏实，那么白盒测试方法，我觉得有打开葵花宝典的感觉。”“白盒测试实际能做起来吗？”腾小宇不由地冒出一句。“这个问题问得好！且不说在‘灵活地应用敏捷后’，以‘快’为宗旨的今天各种交付场景，就连早些年过CMMI 4的传统软件公司，恐怕也没做多少单元测试；即使是做了单元测试，大部分开发哥可能也就匆匆走了几个正常路径的走查来敷衍了事。如此看来，要按照这些书中的方法去做好白盒级别的测试，真是欲练此功、必先自宫。”“那怎么办呢？我们既要提升测试覆盖率，又要快，难道……大侠且慢！剑下留……即使重压之下，我们也不能做林平之，更不能做岳不群。”“你的想法很好，我很欣赏，一定有某种新的分析方法，它既能取黑盒测试方法的厚重，又能真正化繁为简。这种方法就是我们要说的测试分析（也叫‘测分’）：建立在对需求本身及对应的系统架构和实现细节的充分了解的基础上，通过对数据流、状态变化、逻辑时序、功能/性能/兼容性等方面进行分析，得出详细的测试关注点的过程。”“敏捷开发模式下，唯一不变的是变化。而测试分析是道，它帮助我们快速地分析出应该测试什么，不应该测试什么。”陈导接着说道。“陈导，真是太服你了！你这个‘道’的比喻太形象了。我读了这么多的武侠书，你知道它最像哪一门武功吗？”“哪一门？”“易筋经！我觉得测试分析像是内功的修为，讲究个人能力。”“对哦！那咱们进一步想一下，测试分析到底应该包含些什么呢？”

在接下来的一个月中，腾小宇和陈导白天忙着项目中的测试，晚上就在一起探讨测试分析。终于，他们弄出了一篇文档，叫做“全面认识测试分析”。下面摘录一下这篇文档。全面认识测试分析1.基于需求的测试分析

这是最传统也是最经典的一种测试分析方法。分析对象是需求规格说明书（俗一点，此后就叫“需求”），即对需求进行分解，考虑需求本身，以及需求所影响的功能模块，从而得到测试范围。

分析的基础：

·对业务的熟悉。

·对用户使用场景的了解。

·产品功能矩阵。

分析的方法：

·业务流程分析：描述业务的正向流程。

·业务状态分析：描述业务对象的状态转换。

·测试范围分析：需求本身的功能模块/受影响的功能模块。

对于这个方法，有经验的人可以对需求本身的功能模块做到很准确的分析，但是对于受影响的功能模块，如果不了解开发的实现，则很难界定准确。2.基于开发实现的测试分析

需要厘清两个方面的问题：厘清用户/需求价值方向、厘清架构/实现的细节。（1）厘清用户/需求价值方向

重点解释一下这一点：这一点要求分析者对于需求要解决什么问题有清晰的认识，我们做的都是商业软件，每个需求应该都是为了解决商业目标上的某个问题。有人可能会问：那不应该放在基于需求的测分（测试分析）里面吗？答案是这样的：大家都知道测试是无穷尽的，如何在有限的时间内做最优的测试，需要平衡取舍（例如，支付类的应用安全是第一位的，通信类的应用性能是第一位的）。这就要求我们充分把握需求的价值方向，在测试策略和测试关注点方面做出正确的判断。（2）厘清架构/实现的细节

万变不离其宗，所有的需求经过理解转化为代码，代码的实现架构、实现的细节就是产品上面的体现。测试在理解架构的实现之后编写的代码可以在测试策略与关注点上更加专一，在输入产出比上会大大的提升，转为测试效率与质量上的提升。当我们看清楚里面具体执行的逻辑，进行的操作，测试路径可以采用穷举路径测试来规避风险，提升我们的质量跟效率，甚至在架构上的不合理也可提出建议，做好迭代的基础。

分析测试关注点（界定内容、影响点）包含如下内容。

功能测试详细分析：

·涉及模块（文件）

·模块交互时序

·接口/类/函数设计

·实现细节

性能测试详细分析：

·基于系统资源的性能测试分析

·性能测试相关点

·开发相关实现细节

·关键指标

·性能测试场景设计（或已有的相关测试用例）

·性能测试脚本设计

·基于响应时间的性能测试分析

接口测试分析：

·针对本次功能需求，是否具备可测接口，需要描述清楚为什么要测以及测哪些

·接口测试覆盖的接口定义描述

·接口内部实现的相关逻辑细节

·接口测试涉及的实现方案

·针对本次功能需求，是否有接口变更，分析变更影响范围及测试内容

·变更接口修改实现的相关逻辑细节

·变更接口（函数）对模块内功能影响分析

·变更接口（函数）对模块外功能影响分析

稳定性测试分析：

·稳定性测试场景设计（用例）

·稳定性测试脚本设计

兼容性测试分析：

·兼容性测试相关点

·开发相关实现细节

·兼容性场景设计、测试环境说明（实验室或众测）第5节测试分析小试牛刀

腾小宇和陈导给大家做了一次分享“全面认识测试分析”，大家听完后都拍手叫好。“咱们什么时候试着用一下测试分析吧。”小宇给陈导提议。“我看可以有！下周6.2迭代开始了，可以挑一两个需求试试。”陈导满怀信心地回答。

在陈导的鼓励下，小宇挑了一个需求，这是个技术需求，对包月付费模块进行重构。顺着测试分析的思路，小宇根据需求和交互，首先画出了业务的状态图。然后找到了开发哥，在开发哥的帮助下，他搞明白了以前这一块代码的架构设计和实现。更重要的是，他借此弄懂了新的重构要怎么实现。

比较有意思的是这次重构要解决付费模块的设计问题，以前的付费逻辑被很多地方用，并且这些地方有一些自己的逻辑，导致代码里面的if-else很多。重构以后，核心的付费逻辑被抽离出来，业务自定

试读结束[说明：试读内容隐藏了图片]

下载完整电子书