一.对需求评审阶段,对业务需求细节理解不明确,未深入挖掘隐含拓展需求 改进措施 需求评审前,我们应该先仔细阅读prd及交互文档,先形成自己对产品的思考,通过脑图的方式列出对产品设计的疑问点,从用户或者从行业角度找出产品设计缺陷点: 需求评审会议中,带着列出的疑问点向产品.开发沟通自己对产品的疑惑和质疑点,多提几个为什么?如何实现?数据获取来源?超出预期的数据怎么处理?缓存处理机制如何?数据保存何处?逻辑由前端处理还是后端服务?后端服务逻辑是否跟第三方关联? 需求评审完成后,按照一定的功能,将需求…

一.漏测的概率 漏测,是指软件产品的缺陷没有在测试过程中被发现,而是在版本发布之后,用户在使用过程中发现存在的缺陷. 二.预防漏测的意义 我们都知道,缺陷越早被发现,发现和解决缺陷所花的成本就越小,如果缺陷是在测试中发现的,那么所花的成本将小得多.测试 是保证软件质量的最重要手段之一,因此,进行漏测分析.预防漏测.促使缺陷尽可能在开发过程早期被发现,是非常有意义的,它有 利于降低软件产品成本.提高软件产品质量. 三.原因分析 谁都不敢打包票说自己经手测试的东西没有问题,包括资深的测试工程师,或多…

提bug注意(此为公司开发提出的建议): 开发如果改bug影响导致另一个问题,原bug没有问题,尽量重新提bug,不要直接激活,因为可能不是同一个问题导致的:   不要一个bug里提多个问题,因为不同问题可能负责的人不一样,需要一直转bug,比较麻烦:此外,由禅道可知,有时一个bug提多个问题,开发容易忽略问题,导致没有改全:   举例说明时,尽量用文字输入,不要只有截图,方便开发操作:   提bug时,描述清楚步骤,能给动图尽量给动图,能给数据给出数据,以免出现开发与测试理解不一致情况,以及减…

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

     看完google软件测试之道,以前有认真看过一次,今天又重新看了一遍.   在google,测试人员严格区分为SET和TE.SET前期深度参与项目的开发,推动开发人员的自测,从破坏者的角度寻找各种bug,通过开发各种测试工具来提高工作效率.TE则在后期项目被确立后参与进来,从用户的角度去平衡开发与需求.google中测试人员被派驻到到各个产品中进行测试,SET更多的负责产品的质量保障,加快测试与研发的效率,而TE则是从用户角度去体验和完善产品,优化各个逻辑操作,推动产品的用户体验.  …

<Google软件测试之道>,一直听朋友讲起这本书,出于琐事太多,一直没机会拜读,最近部门架构觉得我们IT部门的技术太low,就给我们挑选了一些书籍,让我们多看看... 个人的一种学习习惯吧,就做了笔记,将自己的学习理解感触写下来... 快乐阅读,快乐测试,祝愿你总能发现(并修复)BUG... ————James Whittaker.Jason Arbon.Jeff Carollo(本书作者) 一.质量不等于测试 软件质量是所有人的事,而不仅仅只是测试团队的事!!! 质量不是被测试出来的,而应…

以下是最近看的一本书<Google软件测试之道>里的一些摘录,收获很多. 1.讨论测试开发比并没有什么意义,如果你是一名开发人员,同时也是一名测试人员,如果你的职位头衔上有测试的字样,你的任务就是使那些头衔上没有测试的人可以更好的去做测试. 2.只有在软件产品变得重要的时候质量才显得重要. 3.假如你被要求去实现一个函数account(void *)返回一个字符串中大写字母A出现的次数.如果候选人上来就直接开始写代码,这无非在传递一个强烈的信息,只有一件事情需要去做而我正在做这个事情,这个事情…

这几天在抽空读一本新书,久负盛名的<google软件测试之道>.之前在网络上一点一点地看过它的英文版,很受触动,还做了很长的读书笔记,现在看到了中文版,才恍觉之前的好些理解存在不恰当的地方,英文读写能力真是个硬伤.. 这本书很多让我惊奇的地方,可以说刷新了从业这么久的三观.例如它说测试团队真正的定位在于提高"工程生产力",google内部只有非常少的专职测试人员,有的是具有测试视角的研发团队,和兼具研发能力的测试工程师,还有具有用户视角的产品经理.由于人员的精简,因此尤其注…

<Google软件测试之道>[PDF]下载链接: https://u253469.pipipan.com/fs/253469-230382198 内容介绍 每天,Google都要测试和发布数百万个源文件.亿万行的代码.数以亿计的构建动作会触发几百万次的自动化测试,并在好几十万个浏览器实例上执行.面对这些看似不可能完成的任务,谷歌是如何测试的呢? <Google软件测试之道>从内部视角告诉你这个世界上知名的互联网公司是如何应对21世纪软件测试的独特挑战的.<Google软件测试…

软件测试之adb命令-实际公司使用场景--今日log Dotest-董浩整理 1)可以看内存泄漏: 2)可以安装.卸载app--截图并提交bug: 3)可以通过抓app日志定位问题: 4)可以结合monkey进行性能.压力(健壮性的测试). 当然​adb命令有很多,也有很多其他的使用场景.不过我这里总结的是实际公司(小米.58等)在软件测试过程中的使用!如果有其他用到的可以告知,共同学习,谢谢! ​怎么才能把学到的东西运用到实际工作中? 实际工作中都用到哪些​知识? 当然不是说你学的多不好​.​…

最近刚刚看完<Google 软件测试之道>,受益颇多,遂记录下: 只有在软件产品变得重要的时候质量才显得重要 第一章:谷歌软件测试介绍 角色介绍 SWE(Software Engineer).SET(Software Test Engineer).TE(Test Enginee) SET也是开发角色 - 100%时间在编写代码,SET和SWE是合作伙伴 - 工作重心在可测试性和通用测试基础框架 - 参与设计评审 - 关注质量提升和测试覆盖率增加- 写代码的目的是可以让SWE测试自己的功能- 关…

[本文出自天外归云的博客园] 以下内容除了笔记还有总结,有个人理解的成分在内. 第一章笔记与总结 1. 开发人员也承担了质量的重任,质量从来就不仅仅是一些测试人员的问题.头衔有测试字样的人的任务是让那些头衔里没有测试字样的人更好的做测试. 2. 写一段代码就要测试一段代码,不要等着都写完了再写测试.写一段代码就立刻测试这段代码,这件事是由写这段代码的开发来做的.Google测试人员少是因为保证质量是开发的事.如果某个产品出了问题,第一个跳出来的必是导致此问题的开发者,而非漏测该bug的测试人员.…

读<Google软件测试之道> 在IT领域,Google是一面旗帜,是一家非常善于思考善于尝试的公司.随着面临挑战的不断增大,传统的测试开展方式也越来越力不从心,这本书讲述的就是一次完整的转型过程,非常的有价值.这是本老书了,一年多前就拜读过,当时更多看到的是差距和困难,随着一年的努力和尝试,突然觉得有点开窍,和大家做一些分享. 基本理念 Google在质量方面的基本共识是: 质量不是被测试出来的 具体的工作目标是: 让每个工程师都注重质量 从业多年,这个口号其实经常能听到,但是大多数时候只是…

转载自:软件测试之Web测试经典总结 基于Web的系统测试在基于Web的系统开发中,如果缺乏严格的过程,我们在开发.发布.实施和维护Web的过程中,可能就会碰到一些严重的问题,失败的可能性很大.而且,随着基于Web的系统变得越来越复杂,一个项目的失败将可能导致很多问题.当这种情况发生时,我们对Web和Internet的信心可能会无法挽救地动摇,从而引起Web危机.并且,Web危机可能会比软件开发人员所面对的软件危机更加严重.更加广泛. 在Web工程过程中,基于Web系统的测试.确认和验收是一项重…

<微软的软件测试之道>[PDF]下载链接: https://u253469.pipipan.com/fs/253469-230382291 内容简介 书的第三部分探讨某些我们工作中使用过的工具和系统.书的最后一部分探讨在微软测试和质量的未来方向,以及我们打算怎么创造未来.<微软的软件测试之道>结构清晰,内容详实,可作为广大软件测试人员的参考用书. 作者简介 Alan page,微软测试卓越工程总监.管理微软的测试技术培训并对微软的测试工程师提供咨询.他是微软最早的测试架构师之一,曾…

软件测试之实际工作工作方式001--log4 Dotest软件测试-董浩整理   领导安排任务后:   1)首先要确认理解:是指的某工作吗?具体有什么要求吗?时间截止到什么时候? 解析:   a.万一自己的理解与上级安排的任务产生歧义,那么你的工作也做了无用功 b.结合上级的安排评估自己的时间和手头现有的任务,提前说明日期内是否完成或调整自己工作的优先级,让上级知晓,是否认可   2)过程中及时反馈:每天固定时间点主动汇报自己的工作,我还有多长时间.剩余多少.遇到什么难题: 解析: a.不要让你…

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

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

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

功能测试,简单的理解就是黑盒测试,就是检测黑盒子,找到里面存在的缺陷. 功能测试新人学习计划: 1. 对于产品的学习---站在客户的角度学习产品.看待问题 测试人员不是简单地按照开发人员的设计文档去撰写测试相关文档,对于设计文档的准确性同样负有责任.测试人员需要认真学习需求说明书,审核设计文档.同时,要站在客户的角度去理解功能设计是否合理. 2. 熟悉各种测试文档:对比自己的测试角度与思维,一边提高自己对功能测试的认识,也一边提升自己的测试能力. 3. 了解功能测试的流程:瀑布模型与敏捷开发模式…

你是否遇到这样的场景? QA发现问题后找到DEV说: 不好了,你的程序出问题了! DEV(追查半小时之后): 唉,是你们测试环境配置的问题 唉,是你们数据不一致 唉,是你们**程序版本不对 唉,是**产品线的问题 当时的日志呢? 当时cpu有异常么? 可以复现么? 这里就应该是这样啊! 你是否期待这样的场景? QA发现问题后,经分析判断,胸有成竹的找到DEV说: 你的程序出bug了,初步断定是XX类的XX判断分支有问题,应该把某某的判断一改就好了!--==定位精准== 你的程序出bug了,过去某…

你是否遇到这样的场景? QA发现问题后找到DEV说: 不好了,你的程序出问题了! DEV(追查半小时之后): 唉,是你们测试环境配置的问题 唉,是你们数据不一致 唉,是你们**程序版本不对 唉,是**产品线的问题 当时的日志呢? 当时cpu有异常么? 可以复现么? 这里就应该是这样啊! 你是否期待这样的场景? QA发现问题后,经分析判断,胸有成竹的找到DEV说: 你的程序出bug了,初步断定是XX类的XX判断分支有问题,应该把某某的判断一改就好了!——==定位精准== 你的程序出bug了,过去某…

5. 接口设计问题 -  主从存在延时,当两个接口需要一个主库,一个从库的时候,可能会出问题,时时性 4. 开发的接口文档也得进行简单的测试,根据产品文档/业务测试接口(针对问题2) 3. 需要上的课程总数,测试环境正确,线上环境错误(估计是线上有缓存的原因) 2. 科目列表,科目没有排序,应该按时间顺序排序 1.  获取产品包加了缓存两小时,影响了另一个项目,新买课程的学生,2小时内,无法看到找老师入口,找老师依赖于学生有新产品包…

2. websocket: 用户频繁刷新,后台每次请求新的排队,内存溢出 1. websocket: 北京中心连接正常,外地中心,连接超时,应考虑到外地延迟问题…

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

第一章:Google软件测试介绍 1.Google的测试团队并非雄兵百万,我们更像是小而精的特种部队,我们依靠的是出色的战术和高级武器 2.在Google,写代码的开发人员也承担了测试的重任.质量从来就不仅仅是一些测试人员的问题,每个写代码的开发者本身也是测试者,质量在名义上也是由这样的开发测试组合共同承担 3.Google团队由SWE(软件开发工程师), SET(测试开发工程师),TE(测试工程师)组成 4.在Google,对于一个测试人员,如果在某个产品中工作满18个月之后,就可以无理由地自…

前段时间比较迷茫,没有明确的学习方向和内容.不过有一点应该是可以肯定的:迷茫的时候就把空闲的时间用来看书吧! 这本书,目前只是比较粗略的看了一遍,感触很大.以下是个人所作的笔记,与原文会有出入的地方.建议感兴趣的伙伴阅读原文书籍! 一.质量不等于测试 质量不是被测出来的:未经测试也不可能开发出有质量的软件. 保证质量: 测试开发同时开展:google目标. 开发对质量的责任:写一段代码后立刻测试,完成了更多的代码就做更多的测试:质量像是预防行为(质量是开发过程的问题,不是测试问题). 测试:线上…

前几天刚刚接触软件测试,这篇文章主要是介绍使用eclipse的插件——Junit4进行单元测试.下面先介绍一下单元测试的定义:单元测试(unit testing),是指对软件中的最小可测试单元进行检查和验证.对于单元测试中单元的含义,一般来说,要根据实际情况去判定其具体含义,如C语言中单元指一个函数,Java里单元指一个类,图形化的软件中可以指一个窗口或一个菜单等.总的来说,单元就是人为规定的最小的被测功能模块.单元测试是在软件开发过程中要进行的最低级别的测试活动,软件的独立单元将在与程序的其他…

1. 构建的基本流程: a. 开发人员在他们的个人计算机上编写源代码文件 b. 他们将编写好的文件存放在一个统一集中的地方,构建组将所有的源代码编译成可以在计算机上运行的二进制文件,且用安装工具把各种需要安装到服务器上的文件包装成可以安装到不同平台的软件包.   c. 组合成一个产品 构建的过程就好比一个组装生产线,源代码文件就像是各种大小配件,被存储在一个大仓库里,源代码中,有些在构建过程中还需要再加工. 2. 构建过程: 3. 构建生产线时,软件开发部门,特别是构建测试团队需要考虑什么? a…

一直在用帆软的报表软件FineReport来做项目,也一直关注着这个公司的发展. 看到<提BUG,拿奖金>的这个活动,有些疑问和思考. 一般FineReport新版本在正式发布前,都会经过测试部反复测试,然后会选定小范围的用户来试用,保证稳定性后再发布,在发布后的一短时间内,用户量变大,会浮现出一些BUG,毕竟每次版本的更新和改动都比较大. 但这次却有些不同,以活动的形式做,还100块钱1个bug,我真是醉了. 1.如果最后征集到很多,finereport这是要丢脸,那么多的BUG反映产品不稳…