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