《测试架构师修炼之道》读后感1000字

　　《测试架构师修炼之道》是一本由刘琛梅著作，机械工业出版社出版的平装图书，本书定价：69，页数：300，特精心从网络上整理的一些读者的读后感，希望对大家能有帮助。

　　《测试架构师修炼之道》精选点评：

　　●这本书很系统地说了测试架构师需要哪些技能，关于测试的很多概念，也结合了实际的例子来讲解，易懂易记，是本不错的测试书籍

　　●闲来可以用来消遣的一本书，写的确实和我目前的现状很符，很真实

　　● 一看开篇作者就说要测一个东西并不需要了解是用什么语言实现的，只用从用户那考虑……随机翻了几下发现完全扯名词讲套路，直接放弃了

　　●没什么价值，测试在变革，整个研发测试模型都在变革，这一套已经完全不适用了

　　●这套在大厂不太适用了。

　　●对于我这样的新人来说，觉得很有用。

　　●案例讲的过于专业化，不是人人都懂通信，很多案例要读很多次才知道需求是什么要测什么。94页图有错误的地方。并且很多章节非常的没有实感，全是理论和口号。

　　●“秘书九段”的故事对于任何一个职场人都是十分适用。作者对于瀑布流模式的测试过程管理讨论的比较透彻，有不少可取之处，但是测试过程中研究和检查的太多，可能导致实际执行起来比较繁琐和死板。

　　《测试架构师修炼之道》读后感(一)：差评

　　对于我，就是0星的书，我从头翻了一遍，没有任何看的欲望。1 作者不是互联网企业的，书中概念互联网产品套不上。2，书中没有技术，且Windows计算器的测试案例是抄的。俄罗斯方块的测试案例跟互联网产品更相去甚远。3，没有app测试东西，本身跟时代脱节。4，内容陈旧，废话很多。你要介绍测试用例写法就好好介绍，别拽名词。同时你测试用例介绍的也不完整权威。5，致命的，作者拿华为那套讲测试，有几个公司是华为那种商用级别软件，成熟软件的软件测试岗位说混日子的也不为过，难怪扯这么名词卖书赚钱。早知道华为写的根本不买。

　　华为测试架构师就一头衔，早从华为出来的这种水平的有都是，真不是怼作者，希望从现有工作经验出发，跟上时代潮流。你为写这种书也是蛮拼的了，发明了不少名词。

　　你文中大谈测试架构师需要技术，但你自己书中对技术避而不谈，让人费解+笑掉大牙。

　　《测试架构师修炼之道》读后感(二)：勘误以及读后感

　　

勘误

书的质量不算特别好，至少错别字和错图让人觉得不爽。

　　198页的iOS能写成ISO和安卓系统并列，作者马虎，责编校对也如此？？？

　　175页的坐标系，“密度1”，“密度2”，”密度3“这样的写法，会让读者误解，为啥坐标系不是线性增长的，“密度3”在“密度1”和“密度2”之间，你换个密度的名字（“密度a,b,c”）就会好很多

　　285页 表8-26，“第一代”的“定义”中 “回放”少写了一个“放”只剩个“回”

再谈谈作者的思维

　　几乎所有的开发流程都是围绕着V模型，一点都不适合目前流行的敏捷模型，哪里有那么多时间给你开xx会，做这许多的缺陷分析，那么多文档表格？

　　再说里面举例，很多都是网络防火墙的例子，你让不懂这个行业的人怎么看得懂，大家连需求都读不懂好嘛，怎么读懂你的实例？

　　很多观点还是停留在理论，没有实例支撑。

最后谈谈可取之处

　　第四章，讲测试设计，尤其是88页的最小线性无关覆盖很有意思，但是93页的图4-57“加密消息”到“发送消息”的箭头画反了

　　109页的PICT工具也挺有意思的。

　　《测试架构师修炼之道》读后感(三)：吸取精华之处（软件测试思路、流程、方法）

　　上周再次重读了此书读，这次第2次读了，但与第一次不同的是，第一次只是从头到尾的通读了一遍，之后很少思考，因此当再次拿起此书时，没有任何印象。

　　这次读完后，我梳理了本书的思维导图，而且在读的过程中，也将自己的10多年的工作经历中技术、工作中遇到的问题、疑惑与书中的内容相结合并思考，便有了更深刻的认识。虽然现在的研发流程变了，但软件测试本身的核心思想“质量模型、测试方法、测试的评估方式”仍然值的学习，而这些内容占了全书内容的90%左右，让你从测试工程师到测试架构师的所需技能有了全面的了解，所以还是可以好好学习下的。 想了解自动化测试的内容很少，大家就得再针对性学习。如下是个人梳理的思维导图，供大家参考。

　　《测试架构师修炼之道》读后感(四)：瀑布式开发的测试总结

　　

背景

本人在敏捷开发团队中从事测试。被人推荐此书，因为本书没有介绍作者的工作背景，所以我默认是敏捷流程，所以前半本看得比较认真，后发现与我的体验差距比较大，且发现本书有一些问题，后半本读得比较粗略。

我认为有用的地方

　　作者是一个有多年经验的测试人员，书中介绍了一些有用的工作经验，比如和各个角色之间的沟通技巧。从流程来看，本书有把测试策略、编写测试用例、进行用例评审、执行测试用例、缺陷分析这个流程都介绍完，让我对瀑布式开发的测试工作有了一些浅层的了解。

我觉得不好/对我用处不大的地方

　　1. 我的感觉是这本书是先写了目录再往里填内容。这种写书方式没什么不好，但这本书给我的感受是很多地方显得非常空洞，前后重复，阅读思路不够顺畅。

　　2. 干货不多，一些本来比较简单的地方因为引入了复杂的理论反而变得复杂起来（比如测试时间和缺陷趋势的关系，相关内容讨论发现新缺陷的速率问题[p183]，其实直接讲速率比画出图像比较函数的凹凸性更简单。类似的引入复杂理论解释简单问题的地方还有很多）。

　　3. 一些内容的主体不明确，比如在介绍产品质量评估模型时，测试覆盖度的评估是对单元测试的要求，但这个内容和之后的测试自己进行的测试过程评估无缝衔接，对于懂的人，这种程度的介绍意义不大，对于不懂的人，这种叙述方式会让人不得要领。

　　4. 有些过于执着于解释各种“术语”的差别，比如测试策略、测试方针、测试计划等。作者不停地引入各种概念，费了笔墨解释，但大多数地方并没有真正用到这些概念。如果把这些术语抽掉，相关的内容依然可以理解，甚至可能会更清楚。

　　5. 本书介绍的写好测试用例的方法、用例评审的工作方式在敏捷开发实践中不太需要。相比于寻找已开发系统的bug，我更希望学习识别正在开发中/即将开发的故事卡的风险的经验。但这不是本书的主题。

总体评价

　　本书比较全面，但个人认为过于全面。开篇的软件测试工程师的职业规划、非常基础的测试方法没有太多的干货，可以略去不表或一笔带过，把后面的工作经验/测试策略等处做更有针对性地展示。目前本书的重点有些模糊。

　　虽然本书给我的阅读体验不够好，但是对测试新人还是相对友好的。如果带着批判的思维阅读，还是会学到很多实际的工作流程/方法/技巧。如果是有一定工作经验的测试人员，特别是敏捷开发团队的测试，个人就不推荐这本书了。