读《微软的软件测试之道》有感(上)

  在这个电子书漫天飞的年代,我居然仍然喜欢读纸书,喜欢一边读一遍闻书的味道,就像品尝一顿美味的大餐一样。最近得了一本《微软的软件测试之道》,啃了一段时间了,每次重新拿起来看就觉得里面的内容忘得一干二净了,想起之前有位领导总是教导我们:“要不断总结,要累积,这样才会进步!”之前每次听这话都觉得烦,后来工作久了才知道总结有多重要,如今为了记住这本书的内容,我决定写个读后感,想到哪里写到哪里。

  第一部分:

  第一章《微软的软件工程》

  第二章《微软的软件测试工程师》

  第三章《工程生命周期》

  看完就想说一句:哦,原来大公司是这个样子的。接来下还是讲讲我们自己吧,任职于一家小公司,感觉团队就像一支游击队,可能用抗战片里面的义勇军来形容更贴切些,生源比较复杂,有组织,有自己的战斗模式,但纪律性略差,尽管“组织上”派了很多人来“改造”,但实施起来困难重重,最后都是半路夭折。公司每年都会根据项目情况进行团队重组,提倡人员复用,也因为这样我参与了多个产品的测试工作,经历了从产品投标立项到发布验收的所有过程,这让人听起来有些复杂,一个测试工程师需要经历这么多吗,我开始的时候也很排斥这种模式,后来慢慢就想通了,正是因为经历了这么多才让自己有机会学习到更多,工作不应该是仅仅局限于一片区域,要不断地扩展自己的知识面,经历的越多你会发现自己缺的越多,而在这个过程中会有收获的惊喜,不多解释了,大家都懂得。

  测试的职业发展,我们总会看到两个选择:一个是技术方向,一个是管理方向。其实对于新人来说不必太纠结于这个问题,因为当你工作的一定程度的时候,自然就做出了选择,个人觉得工作不需要违心,人只有按着自己喜欢的方向走,才能充分发挥自己的优势。书中讲到了测试职种的多种发展道路,对于迷茫者来说是一个不错的提示,级别主要是根据技术深度、技术广度和影响力范围来区分的,影响力的范围从一个狭窄定义的产品功能扩展到一个系列产品的功能、一个完整的产品,影响力可以基于测试的各个方面延伸,也可以基于一个方面的技术领域纵向延伸。我的感想是,学无止境,测试也一样,学到的越多,技术水平越高,你才会有能力维护自己的地位,地位越高,你的影响力就越大。

  工程生命周期,作者以做饭为例讲述了一个过程方法:通过协调各种资源,根据情况灵活调整。是按部就班还是灵活机动,都各有好处,并不是一个软件开发模式适用于所有的产品,不同的产品需要不同的方式来实现,尽管在实际操作中会有很多变化,但很多过程方法在实践中已经广泛应用,而且也在实践过程中进行显著的实验和创新。传统的软件工程模型有瀑布模式、螺旋模式、敏捷开发。除了第二种,其他两种我都经历过,目前一直都是敏捷开发。质量改进是定义了工作目标,指定和执行计划以达到目标,检查并确定是否实现了预期的结果,如果没有实现预期的结果,就要修改工作规程以完成计划。Deming循环(或PDCA循环)就是描述上述过程的一种方法,该流程实现能保证产品质量满足期望。之前也阅读过《软件测试与持续质量改进》、《持续集成,提高软件的质量和降低风险》等质量相关的书籍,公司的领导一直提倡流程改进,项目组也进行了多种尝试,并将戴明循环进行实践,且取得了一定的效果。我的总结就一句话:A good process is a process that results in good software.

时间: 2024-08-06 07:55:27

读《微软的软件测试之道》有感(上)的相关文章

测试技术的思考 ---- 读《微软的软件测试之道》有感系列

假期期间,带着复习巩固测试基础理论的目的,开始阅读<微软的软件测试之道>,阅读过程中有不少启发,遂将自己的思考及学到的知识在此处做个总结记录. 1. 为什么阅读这本书? ????做了几年测试工作,随着对测试理解的加深,我发现测试理论对于日常的测试工作有较大的帮助与影响.待测系统复杂多样性的增加,要求我们也逐步去思考,如何测试,才能保证待测系统的质量,这期间就需要测试理论的支撑. ????我个人的一个观点是,一个优秀的测试工程师,或一个优秀的软件开发测试工程师,需要在三个方面持续的打磨: 理论

《微软的软件测试之道》读书笔记 之 结构测试技术

<微软的软件测试之道>读书笔记 之 结构测试技术 2014-07-18 我们需要结构测试吗? 微软的一项试验说明了结构测试的在代码覆盖中起到的效果: 超过3000名测试员参与了这项实验,每25人一组,实验结果在所有组中都是一致的.在这项研究中, 脚本化测试:根据样式书设计的脚本化测试在被测程序上达到了标称83%的代码覆盖率. 探索性测试:然后,实验参与者允许进行每人15分钟,累计5小时的探索性测试.令人惊讶的是,代码覆盖率平均只增加了3个百分点. 结构测试:但是,当实验参与者能够分析探测过的(

10.读google测试之道有感

(一)读google测试之道有感. 1.这样的测试改革必须是整个公司的统一一致的行为,需各个部门的全力配合经过相当一段时间的沉淀才能完成.要看公司的企业文化. 2.手动测试的人员将体验测试化,体验测试是只能在人的参与下完成.这部分TE会减少,但不会消失. 3.增加SET的职位只是辅助了SWE的单元测试,但是符合SWE条件的人不好找,即使找到了,待遇要大于等于SWE,测试部门中凭空增加了一个高成本的职位,老板能接受? 4.TE的角色负责,用户体验测试.自动化脚本测试.但是在敏捷的快速迭代下,需求不

Google软件测试之道 pdf下载

引领一代风骚的明星企业google, 推出过很多成功优秀的产品,搜索引擎不用说,譬如Gmail ,Chrome, Google Doc, G+等等等等,也推出过很多短命的产品,譬如Google Wave等等. 作为一个时常需要推出新产品,但又要根据用户反馈而做进一步选择继续还是放弃的企业,作为一个需要让产品稳定健壮以保持客户满意度的明星企业,该如何测试是一个很大的问题.Google的经验非常值得借鉴. 该书的作者是Google测试的Senior Director(如果我没记错的话),在测试领域有

《Google软件测试之道》测试开发工程师

拖延了将近半年的草稿,断断续续的写完了.之前草草翻看完这本书,关注点主要在TE上,而关于SET的部分则只是浏览,最近后知后觉,又翻出了这本书,重新看了一遍,又有新收获. 就说说Google的SET是如何做的,以及个人的一些思考和收获吧,寥有慰藉... Google的测试流程可以简练的概括为:让每个工程师都注重质量.而在工作流程引入过程中也伴随着一些致命的缺陷,下面简述下Google是如何解决以及其测试流程的是如何进化的. ①.测试并不能保证产品质量.需要一直谨记的一点:质量是内建的,而不是外加的

转《Google软件测试之道》

<Google软件测试之道>,一直听朋友讲起这本书,出于琐事太多,一直没机会拜读,最近部门架构觉得我们IT部门的技术太low,就给我们挑选了一些书籍,让我们多看看... 个人的一种学习习惯吧,就做了笔记,将自己的学习理解感触写下来... 预计会分为五部分写这些学习笔记,分别是Google软件测试基础介绍.软件测试开发工程师.软件测试工程师.测试经理以及附录其他部分... 快乐阅读,快乐测试,祝愿你总能发现(并修复)BUG... ----James Whittaker.Jason Arbon.J

《Google软件测试之道》- Google软件测试介绍

<Google软件测试之道>- Google软件测试介绍 2015-05-21 目录 1 质量与测试  2 角色  3 组织结构  4 爬.走.跑  5 测试类型  相关链接 与Microsoft相比,Google的测试团队并非雄兵百万,更象是小而精的特种部队,依靠的是出色的战术和高级武器.Google信奉“少则清晰”. 1 质量与测试 返回 测试是开发过程中必不可少的一部分,当开发过程和测试一起携手联姻时,即是质量达成之时. 2 角色 返回 软件开发工程师(software engineer

《Google软件测试之道》

Google软件测试之道 Google对质量的理解 质量不等于测试,即质量不是被测出来的 开发和测试应该并肩齐驱,测试就是开发过程中不可缺少的一部分 质量是一种预防行为而不是检测 Google对软件测试的划分 抛却复杂的专业术语,简单按照测试范围去划分: 小型测试:对一个代码单元的测试,通常就是单元测试 中型测试:对两个或多个模块之间交互的测试,通常类比于“集成测试” 大型测试:对一个应用系统及其子系统整体的测试,通常类比于“端到端测试” 这样划分的好处有: 容易定位问题:测试范围从小到大,各自

《Google软件测试之道》心得笔记

Google软件测试介绍 把开发和测试融合在一起--开发和测试必须同时展开 开发人员自己要对自己写的代码负责,比专职的测试人员更适合做测试工作. 测试开发工程师SET 对于Google拥有很少量的测试人员的情况下,还可以取得不错的成果,核心原因在于Google从来不会再一次产品发布中包含大量的功能,实际上,做法恰恰相反,在一个产品的基本核心功能实现之后,就立即对外发布使用,然后从用户那里得到真实的反馈. 软件测试开发工程师(SET) Google的四大主要开发语言:C++.Java.Python