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

假期期间,带着复习巩固测试基础理论的目的,开始阅读《微软的软件测试之道》,阅读过程中有不少启发,遂将自己的思考及学到的知识在此处做个总结记录。

1. 为什么阅读这本书?

????做了几年测试工作,随着对测试理解的加深,我发现测试理论对于日常的测试工作有较大的帮助与影响。待测系统复杂多样性的增加,要求我们也逐步去思考,如何测试,才能保证待测系统的质量,这期间就需要测试理论的支撑。
????我个人的一个观点是,一个优秀的测试工程师,或一个优秀的软件开发测试工程师,需要在三个方面持续的打磨:

  • 理论
  • 技术
  • 实践

????只有在这几个方面有了持续的打磨及积累,才有可能向"优秀的工程师"靠近。
????此外,也是想了解大公司的最佳测试工程实践是如何开展的,故才开始阅读此书。

2. 个人的心得感悟

????和阅读《Google的软件测试之道》这本书不同,阅读本书时,给我的最大感悟就是,原来像 Microsoft 这样的公司,早期的最佳工程实践中也是将基本的测试技术深度研究打磨后在产品测试中进行实践,整体上和个人的领域知识还是有交汇之处的,故在阅读的过程中,结合过往的工作经验,有一些所得与感悟。后续将会逐步将所得与感悟分章节记录下来,也是对自己阅读本书的一个交代。

原文地址:https://www.cnblogs.com/gaozhidao/p/12260318.html

时间: 2024-11-20 20:18:51

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

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

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

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

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

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

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

Google软件测试之道 pdf下载

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

转《Google软件测试之道》

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

10.读google测试之道有感

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

《Google软件测试之道》

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

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

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

google软件测试之道读后感(二)

这几天又翻了几页这本书,觉得妙语连珠,关键语录摘抄如下,并补充自己的一些思考: "如果你想要求一个团队去尝试新的事物或者做某些改进,给他们提供一个联系人会更好一些,这个联系人来源于更大的社区,并可以从他那里得到帮助": "不要陷入尝试去创建一个包含独立指标的完美系统的陷阱中.对所有人都完美的事情是不存在的.在没有可替代的方案时,在合理的地方达成一致并勇往直前是很重要的.需要灵活的时候就灵活一些,但一定要坚持你的原则底线". 当考虑团队建设方面时,在以前总是收获理想很