ITPub博客

首页 > 自动化运维 > 大规模网络运维 > 曾梦想仗剑走天涯,现在却因Bug想回家,揭秘程序员最难忘的那些Bug

曾梦想仗剑走天涯,现在却因Bug想回家,揭秘程序员最难忘的那些Bug

原创 大规模网络运维 作者:博为峰网校 时间:2019-10-11 18:07:34 0 删除 编辑

●  Anutthara 的缺陷

有一个缺陷让我铭记了四年,至今不能忘却。我们进行的 工作 是本地化 测试 ,为了使用户可以在不同语言的 操作系统 中安装我们的产品。当我在对一产品进行 Beta 版测试时,我将该产品安装在了日语  Windows  2003 (W2K3) 操作系统上,并测试了其基本功能,完全没有碰到问题。当然,它在英语 W2K3 系统上也运行得非常好。所以我们对这次测试的整个感觉非常不错。

 

接着我们即进入循环测试,我将该产品安装在了一台德语系统的机器上,并试图开始运行某一版本。就在此时,机器突然崩溃了!代码开始比对硬编码“Administrator”用于确认用户是否拥有管理者权限。这个缺陷之所以没有在日语 系统测试 中出现,是因为在日语系统中用户组未进行本地化翻译,仍旧保留为“Administrator”,而德语系统中则被翻译为“Administrat?n”。我从中了解到对于硬编码检查的重要性,不能因为单单在一个平台上通过本地化测试,即认为 其他 平台也能正常运行。尽管我们现在已经发现了一箩筐的问题,但仍不能确保是否会有落网之鱼。

● Bruce Shankle 的缺陷

Windows 95 的年代,我还是一个 beta 测试人员。这是我第一次在微软的平台上看到回收站。出于好奇,我想尝试一下它的恢复功能(在 DOS 环境中存在一些恢复功能,但要求您记得 FAT 文件系统中需要恢复的文件名的第一个字母。有时这个功能很好用,但是我不常用),于是开始拖动桌面上的回收站,然后把它放进了自己的图标内。就在此时,系统突然奔溃了。

● Vamshidar Rawal 的缺陷

现象:

Office 在线主页的 RTW 版本总是会出现有些功能无缘无故失灵的情况。尽管多次调试,仍不明问题所在。

原因:

RTW 版本发布前的功能测试阶段,测试人员未能发现问题,且测试环境也没有模拟产品的实际运行环境。所有的功能都被作为单元进行了单元测试,尽管他们每个功能独立工作都没有问题,但一起工作时就说不定了。

问题:

问题就出现在实际运行环境中。由于硬件平衡器(H/W)会识别所有的需求,然后将其传送给服务器运行,包括我们为每个功能所设置的 Cookie/Header,且平衡器对于 cookie 的尺寸存在限制条件,不能超过 4KB,而当我们所有的功能都同时运行时,则就超出了这一限制。平衡器为了保持正常工作会对 Cookie 进行截断,使其尺寸小于 4KB。所以就会出现有些功能由于缺少 Cookie 需求而不能正常运行的情况。

结果:

我们立即修复了这一问题,对原先的 Cookie 进行了修改,使其大小不再超标。

经验总结:

1、测试环境需模拟产品的实际运行环境,特别要注意平衡器的环境要求。

2、功能测试时,不仅要对单个功能进行测试,也要将功能整体连同整个产品一起测试。

这个缺陷的发生,让我们对于如何编写和使用 Cookie 有了更深入的了解,同时也帮助我们在随后的两个版本测试中发现了更多的潜在问题。

● 减小 Cookie 的尺寸可以提高产品的性能,同时提升最终用户的体验。

● 削减不必要的 Cookie 内容,使其尺寸控制在合理的范围内。

●Vamshidar Rawal 的缺陷

现象:

我们将代码设置成在特定的跟踪页面运行时标,以自动检测实际最终用户在站点下载所用的时间(7*24小时)。结果显示无论是否是高峰时期或周末,下载时间能控制在限时 20 秒之内的概率只有 25%。我们对此束手无策,找不出其中的原因,这对于我们最终用户的使用体验无疑是一种打击。

原因:

我们几个月后才开始理出头绪。通过一段时间对网站最终用户实时使用情况的观察,竟然发现一个月内会出现两个特殊时间段,在这两个时间段内下载时间会由原先的 20 秒下跌至 5 秒。这一现象引起了我的注意,是什么导致了这两个特殊时间段的产生?在这两个时间段内发生了什么?后来终于得知在这两个时间段内,我们会进行半个月一次的网站更新,加入新的内容或代码。在这期间,我们的操作团队会占用一半的服务器资源,直至更新完成。而就在这个时间段内,长时间的下载问题也得到了解决。我们惊奇地发现在只有半数的服务器工作的情况下,网站竟然运行得更好。

问题:

◆ 最终,大多数的迹象指向了真正的问题所在:唯一的 OLEDB 连接字符串数量,它自创建之初就一直位于前端访问服务器上。

◆ 我们有 42 个前端访问(FE)服务器对应 28 个后端访问(BE)服务器,共包含 47 个语言数据库(DB)。

◇ 所以每个 FE 服务器都须创建并一直使用唯一的 DB 连接字符串,则唯一的 DB 连接字符串的总数量可达 28*47 = 1316 个。

◇ 问题是这个唯一的连接字符串的总数量远远超过了限定值(约 100 个)。

◆ 在网站更新期间,FE 服务器对应的 BE 服务器的数量缩减到原先的一半(21 个 FE 服务器对应 14 个 BE 服务器,包含 47 个 DB)。

◇ 这也使唯一的连接字符串的数量减少了一半(14*47 = 658 个)。

◇ 同时也提高了网站的性能,将原先 20 秒的延时缩短为 5 秒左右。

结果:

这驱使我们不得不对 FE 和 BE 服务器进行重新的布局和连接,以减少连接字符串的数量。我们最终决定在 FE 和 BE 服务器中间新增 6 个服务器,来解决连接字符串超限的问题。

◆ 现在我们有 42 个 FE 服务器 — 6 个搜索网络服务器 — 28 个 BE 服务器(47 个 DB)。

◆ 每个 FE 上的连接字符串数量递减为 42 * 6 = 252 个。

◆ 下载时间长的问题也彻底得到了解决,无论何时都能达到亚秒级标准。

经验总结:

网站发生的问题不可能被完全模拟,且几乎不容易排除。

必须考虑到实际工作环境的每个方面。

如果没有考虑周全,工作环境的任何部分都可能,且必将影响到网站的性能和最终用户体验。

●Xu 的缺陷

自从我笔记本的内存由 1GB 提升至 2GB 后运行得一直很好,直到我发现有时会出现 XP 不能响应我的休眠请求,不能关闭的情况。它会一直处于“保存个人设置”的状态。有一天我在没有完全确认它完全关闭的情况下,就把它放入了电脑包。半小时后,当我再次取出它时,它竟然热得烫手。我打开它,发现电源仍未用完。所以我猜测它的电源是处于关闭状态的。庆幸的是,功能未受到影响。但是我又担心它那么热容易被烧坏。尽管我在网上一直搜索相关信息,且安装了一些包试图想解决之一问题,可是始终不管用。

●Scott Banning 的缺陷

一年半前我发现我们的产品会存在这样的问题:当用户使用特定场景处理边界线时,更新不能同步进行。客户也反映过类似的问题。但是我们的产品快发布了,如果要修复这一缺陷,势必会打破现有的平衡,需要再进行大量的返工,且客户的反馈也不多,所以我们暂且把它搁置了,标记为未修复。大约一个月后,我再次激活它,并指出客户的反馈,但最终还是未修复。至今这个缺陷仍有待解决。这个缺陷一直让我感到非常沮丧。

● Siderite 的缺陷

我这一缺陷并非来源于我们的代码,而是来源于如 Javascript 引擎或 。Net 架构这类承载代码的东西。那次我正在测试一个应用程序,该程序引入了一个新的日历控制器。测试工作耗费了我大量的时间和精力,我非常担心它是否可以顺利运行。只要一想到老板可能点到一个有问题的键,我就寝食难安。

但是问题还是出现了!

有一个特定的时间——夏令时,如能完整地设置这一天的年月日,且将地点设置为我的家乡——罗马尼亚,则能正常运行。倘若未设置地点,仅设置年月日,日历控制器就会显示为该天的前一天,23 点整。几经测试都是同样的结果。我尝试将默认的 0 时设置为 12 时,之后这一缺陷就再也没有出现过,我猜测这可能是由于 Windows 某种类型的更新所引起的。

● Alan Myrvold 的缺陷

我碰到缺陷总会很兴奋,尤其是那些对我有益的缺陷。

几年前,我在一个商业软件公司测试数据挖掘软件。这听上去不错,尽管我大学的专业是统计,而非计算机科学,但也总算有点接近。该软件会从大量的数据源读取数据,包括 CSV 文件。我发现从某些中等大小的文件中读取数据的时间会比预期长。于是我将这个缺陷记录下来,并计划进行更多的测试。

Stephan 是开发部的领军人物,和他共事是我的荣幸。他在软件设计、编码方面都很在行,为人也很和善,总能耐心解答他人的问题,受到测试人员的尊敬。他看了看我的缺陷,又看了一下代码,坚决表示这个由第三方编写的代码看上去是正确的。当读取数据时,程序将数据列入一个红黑色的树列,从 Stephan 那里得知这是一种数据结构,用于有效地存储二进制树。当我问到它的工作原理时,Stephan 借了本书给我,是 Cormen et al 的 Introduction to Algorithms(算法入门)影印本。

程序依旧运行得不顺畅。于是我对这些文件按正序、随机以及倒序的顺序分别进行了性能测试,发现同样的文件按不同的顺序进行测试的结果竟然大相径庭。于是我开始对读取的数据进行调试,因为我不能接触到源代码,所以只能逐个分解并跟踪数据流。我在纸上仔细地画出了读取数据时所构建的树结构图,并注意到它正好与红黑色树的需求相冲突,尽管源代码看上去是没有问题的。我编制了一份正确的算法实现,待 Stephan 仔细审阅后终于得到认可。

经验总结:

◆ 手动测试时,旁人的观点很有可能帮助您发现原先被忽略的缺陷。

◆ 在没有源代码的情况下也能进行调试,尽管会比较困难。

◆ 看上去正确的代码也可能是错误的。

◆ 计算机科学的知识可以帮助测试人员。

● Eric Sink 的缺陷

我曾碰到过这样一种产品,它能使其他应用程序崩溃。

开始,我们觉得这是难以置信的。人们纷纷打电话到我们的服务中心,抱怨使用我们的产品导致了其它程序的崩溃。但是这种崩溃又是不可重现的,而且这整件事情听起来也有点荒谬。如果正巧其他的应用程序崩溃的时候,而我们的产品正在运行,这因果关系又如何能判断呢?

但最终证实这是千真万确的。当我们的一个对话框操作失败时,有时候确实会引发其他应用程序的奔溃。


加官方微信:atstudyIT  回复关键词“测试”领取限量软件测试学习资料哦~~



来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/31407649/viewspace-2659595/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2016-11-02

  • 博文量
    217
  • 访问量
    179140