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

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

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

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

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

​一.GET方法和POST方法传递数据的异同  一.GET方法和POST方法传递数据的异同 http请求方法get和post是最常被用到的两个方法,get常用于向服务器请求数据,post常用于提交数据给服务器处理. GET方法其实也可以传递少量的数据. 但它存在以下问题: 1)GET 方法不包含body,因此以在URL中拼接字段的方式传递数据, 2)GET方法中的URL参数会被显示到地址栏上,存在安全问题 3)传递的数据只能是键值对,,无法传递其他类型的数据 因此出于传递大量.多种类型的数据和安…

以下为二维表信息 //统计严重等级Bug SELECT severity,count(severity) FROM `bf_bugview` where product_id=476 GROUP BY severity //统计创建者Bug SELECT created_by_name,count(created_by_name) as count FROM `bf_bugview` where product_id=476 GROUP BY created_by_name ORDER BY c…

小明入职已有两年,期间测试能力已不知不觉成长许多,得到了Leader大熊的高度认可.回首这两年间,小明对"Bug总结流程"印象最为深刻,他对这个流程的认识在不断改变着:从最初的好奇,逐步变为反感,最终因为收益良多,重新走向认同.今天我们来介绍下这个流程. 两年前的某天,大熊在思考一件事情:如何能够帮助组员快速提高测试技能? 以往的管理经验告诉他,只是安排一些讲座培训无济于事,如果没有实际的实例与测试理论知识贯通,这就如同学校里照本宣科一般无法学以致用:同时没有实际的示例,很多异常测试点…

小优有话说: App Crash就像地雷. 你怕它,想当它不存在.无异于让你的用户去探雷,一旦引爆,用户就没了. 你鼓起勇气去扫雷,它却神龙见首不见尾. 你告诫自己一定开发过程中减少crash,少埋点地雷,但总是不得其法. 降低Crash率,需要的是技巧.工具.耐心与时间. 本文由腾讯天天P图测试团队现身说法,为你讲述他们将Crash率直降90%背后的故事,希望能为你“排雷”提供一些思路. PS:以后每周四记得关注这里哦!小优将为你精选“干货”,让腾讯的开发&测试大牛们陪你一起为提升产品质量!…

昨天下午大神把组内几十号人召集在一起开Online bug分析大会,主要是针对近期线上事故从事故原因和解决方案两个维度来分析. 对金融软件来说,每一次的线上事故都有可能给公司带来重大的损失,少扣了用户的钱,为公司带来资金方面的亏损:多扣了用户的钱,则为带来不必要的合约或法律纠纷,故测试金融软件不比其他行业的软件,后者线上bug大多不会直接引起资金方面损失,最多就是用户体验不好,功能没有实现,导致用户量的流失. 对金融软件来说没有小bug,一旦出现bug那就是重大的bug,必须引起高度重视. 俗话…