价值观的7个等级

1、反应型：照着自己基本的生理需要做出反应，而不顾其他任何条件。

2、部落型：依赖成性，服从于传统习惯和权势。

3、自我中心型：信仰冷酷的个人主义，自私和爱挑衅，主要服从于权力。

4、坚持已见型：对模棱两可的意见不能容忍，难于接受不同的价值观。

5、玩弄权术型：通过摆弄别人，篡改事实，以达到个人目的，非常现实。

6、社交中心型：把被人喜爱和与人善处看作重于自己的发展，受现实主义、权力主义和坚持已见者的排斥。

7、存在主义型：能高度容忍模糊不清的意见和不同的观点。

在杂志上看到了，觉得像那么回事，就贴过来。

    拿到这本书的时候，我比较惊诧于快递的速度，比淘宝网快多了。机械工业出版社出版的计算机类书籍，印刷和装订的质量是很有保证的，醒目的橙红色封面上，一只虫子爬行的痕迹揭示着BUG的的生命周期，是个不错的创意。虽然这只虫子让我一下子就联想到了正在家里横行的蟑螂。
    《测试之美》这本书从测试者之美到过程之美再到测试工具之美，整书的结构很清晰。有着很美的理念和值得借鉴的经验，比如说“测试经理甚至根据发现严重缺陷的数量来支付资金或衡量测试人员的年度业绩”。事实上测试人员的绩效一直是个难题，也总是有领导理所当然地把BUG数量当成一个指标，这个做法我也是颇不情愿的。再如，我们的自动化道路是坎坷的，其实自动化这回事，在国内大部分企业还是在“雷声大、雨点小”的境界，自动化测试实验室的提出，给我们如何开始着手做自动化，有很好的启迪。

    回到这本译著上来，任何两种语言的翻译，都要充分考虑到语言的表达习惯和使用环境，按照另一种语言的表达方式把意思翻译出来。而不仅仅是一种单词到另一种单词的简单兑换。但很遗憾，这本译著在这方面的表现差强人意，这群译者或许都有一流的英文水平，但中文表述能力显然差了一些。书中类似“测试人员不应该是拿着工资却告诉你一切正常”这种有语法错误的句子不在少数，而且所有的段落开头都没有缩进两格，这种按照英方排版方式排出来的中文，至少我是不怎么习惯的。如果看中文和看英文原版一样吃力，我想，这并不是件愉快的事。

四、萍萍的错误

萍萍新学会了一个词---“袅袅婷婷”，不管看到谁走过来，都会眉飞色舞地赞叹一声：“真是袅袅婷婷啊。”硬件部的小晓穿了件短旗袍，萍萍照样来了这么一句。胖胖的小晓却并不受用，瞪了萍萍一眼，回到自己座位上了。小晓的白眼似乎并没有影响萍萍的心情，两人的座位挨在一块，算是同桌，等小晓坐回去时，萍萍仍然凑了过去，对她的旗袍产生了浓厚的兴趣。

过了个周末，萍萍也弄了件旗袍穿了来，据说还是真丝面料的，在当时看来价格不菲。虽然穿着还算昂贵的真丝旗袍，萍萍的脸色却并不好看。一上午都没有听到她说什么话，也不打听什么事了。中午饭也只吃了一点点，就呆在座位上了，双眼没有一丝神采，完全不像她刚刚学会“袅袅婷婷”的时候。大家关心的围过去，萍萍有气无力的，说她生病了。不是什么大病，也就是点感冒，她去买了瓶药，看瓶上的说明写着：“一天12片”，就倒出12片来吃了，完了觉得不大对劲，什么药一次要吃12片这么多啊，就接着看说明，这时候看到说明还有一句话：“分三次服用”。但是看到这里时已经晚了，她已经一次把一天的药全吃了。吃多了药并不见得病能好的快，反倒是感冒药的副作用，让她很犯困，所以没什么精神。小吴哭笑不得，说：“这还是做测试工作的哪，怎么看说明书都不看完的，还好不是安眠药”。阿芬道：“这个也怪那写说明书的，直接写明一次多少，一天几次就好了嘛。”在大家的笑声中，萍萍终于撑不住，睡过去了。而这天小吴似乎心情不错，到了上班时间也没有叫醒她。

萍萍的糊涂成了一个反面教案，小吴后来总是教育我们说，做测试工作要仔细，再仔细，要能考虑到产品的关的方方面面。不过话说回来，如果那说明书写得简单直接一些，把重要的东西交待在前面，估计也不会出这么个乌龙事件。

三、用例

开始的一周，并没有太多的事情。无非是熟悉环境，知道怎么测试而已。周日的时候，老远跑到书城，在书架前找了一圈又一圈，才在一个角落里发现了一本叫《软件测试指南》的书，刚刚在国内兴起的一个职业，理论匮乏如此。这本书后来捐献给公司的图书室了，在后来的几年里，关于测试的书籍层出不穷，而鱼龙混杂也越来越多。不是怕没有书看，而是不知道该看那本了。

这本书虽然名字叫指南，前面大部分也就是讲什么测试的定义、测试的阶段等等纯理论的东西，对实际工作并没有什么太大的作用，只是让我对测试这回事有了个系统的概念，后来跳槽在其他公司面试时，很多面试题的答案就是这本书上看来的。

过了些时候，测试部出了点事，有一批样机总是莫名其妙的死机，但是我们根本找不到产生死机的原因在哪里。 因为每次死机前的操作都可能是不同的，结果却只有一个，机器黑屏了，或者按键不灵了。虽然这个故障后来是硬件部的工程师查出来是电池问题，但大辨子小吴却固执地认为我们的测试能力不够，于是新招了一个工程师进来，希望能给我们一些指导。工程师据说是在中国移动做过手机测试的，当她走进办公室的时候，我就非常反感她大拇指上那颗硕大的戒指，但是怀着对在大公司做过测试的人的景仰，我还是热心的凑了过去，希望能从她那里知道一点点新东西。

工程师只呆了一天就走了，原因竟然是，和阿芬合不来，她在进移动之前曾经和阿芬是同事。但是她却给大辨子小吴灌输了一个极为重要的概念，叫测试用例。在这之前我们做测试一直是信马由僵地点鼠标，点到哪里是哪里，发现问题了，就扔一份报告给开发的。小吴本身是做开发的，因为在公司有些成绩，升成了测试部经理，对测试并不在行。谁知道这次在面试工程师时，怎么能得到这么专业的回答，并且坚定的认为我们需要测试用例。因为“人家大公司都是这么做的”。于是，小吴给每个人下达任务：开始写测试用例，用EXCEL表，一周后评审。我赶忙回去翻我的书，大概知道了写测试用例的几个方法，然后挑自己负责的模块写了几个交了过去。

到了评审的时间，那时候公司还没有投影仪，五个人凑在办公室那台电脑之前，把每个人的用例都打开来看。仅仅是看而已，所有的人都不知道自己写的是对是错，也不知道别人写的是对是错，因为根本没有人知道什么是对什么是错，连大辨子小吴也提不出什么意见来。看完了，小吴开了个总结会，结论是：“用例我们是一定要坚持写的。”至于写成什么样，天知道。

我看到云霞在打瞌睡，估计又是熬夜打游戏了。

为做某事而做某事，这样的行为估计不在少数。就像那个年代我们为写用例而写用例一样。现在测试用例已经产生了一整套的方法论，基本上规范起来。但是对那些起不到太大作用的用例，诸如“点击保存按钮，保存界面全部录入信息”之类的，我仍然不大爱写。可能就是初学的时候没有得到正确方法的缘故吧。

二、加班

    这个公司的测试部门是一个典型的娘子军队伍。直到现在，测试行业走过了十多个年头，队伍的构成仍然是以女性为主。这大概是因为女性在写程序这方面的思维能力受先天条件所限有关。

    大辨子姓吴，也就是测试部的经理，下属除了我之外，另外还有三个，阿芬，算比较资深的，虽然那时候软件测试在国内出现也没多久。湘妹子云霞，一个很爱睡觉、爱打游戏的胖女孩，还有彝族的萍萍，据说是饱受感情创伤的人， 虽然年龄比我还小些。

    国内小型的软件公司，测试部门的工作职责大多比较繁杂，即使到现在，这点也并没有太大改观。公司做电子辞典的，用C语言写代码，然后在电脑上做一个仿真的环境来测软件，测完之后把代码写入芯片，做样机，然后测成品。而录语音，校对资料，写手册、对外解释问题等等，所有除了写代码之外的事情，全都是测试部门的事情。这时候还完全没有测试管理工具的概念，缺陷报告写在纸上，每个问题或几个问题写一页，然后拿到开发那里去，开发改完了，再把报告送回来。所以测试部虽然不是行政部门，每个人的桌子上仍然有一堆文件夹。

    第一天下班的时候，我发现这家公司有一个很奇怪的现象，六点多了，到了下班时间，但所有的人都不走，全部保持着在电脑前敲键盘的姿势。我四处张望着，看看有没有人走，我好跟着出去。然后就看到萍萍在对着我笑，接着凑过来，说：“新来的啊？”“嗯。”“下班了，不过走太早了小吴会不高兴的，我们一般都八点才走，反正回去也是一个人呆着，在这玩会儿吧。”我只好又回过神来，把仿真软件打开，漫无目的的胡乱点着鼠标。这时候我看到斜前方的云霞正在聚精会神地打游戏，游戏的女主人公有一身漂亮的连衣裙。我在后面偷偷看着云霞的游戏，终于熬到大家都离开的时间。

    加班文化是个由来已久的东西，一如某大企业常常被人诟病的“地垫文化”。直到现在，面试的时候常常会被问道：“你对加班有什么看法？”，但在那个时候，加班似乎是个顺理成章的事情，领导也爱把这个做为员工工作积极的一种表现。而员工对此也并没有很强的反抗意识，在那个上网费昂贵，电视节目也没多少的年代里，一群单身，孤单地回到环境简陋的出租屋，似乎并不比在写字楼里舒服多少。于是，在公司里做点工作，没事时打游戏或者学习新技术，成了大家普遍的兴趣。

不知道是不是人老了的缘故，最近有点喜欢回忆往事了，又有些许闲时间，于是梳理出一些记忆，也算是对自己测试人生的另一种诠释。

一、入行

回到十年前，不知道有多少人听过“软件测试”这名词。我也没听过，从学校计算机应用专业学出来，我曾经固执的认为，程序员就是计算机专业的唯一路径。

来到这座城市的第十六天，同学给了我一个电话号码，说这家公司在招测试员，让我去试试。而此时的我，在人山人海的人才市场内艰难混迹了十五天，花掉了从家里带来的全部的钱。本来已经不想再在这个城市里流浪下去，同学给我这个号码的时候，我告诉她，我准备回去了，她答应第二天送我去车站。

第二天一大早，我在约好的地方等她，但是不知道为什么，她一直没来。南方的四月虽然不太热，但站在太阳下的站台等人的滋味仍然是难熬的，于是，我躲进了旁边一个公用电话亭里，遮遮太阳。这时候，我看到了包里那个写着公司电话的纸条，百无聊赖中，我试着拨通了这个电话。接电话的女生居然什么都没问，直接告诉我地址让我过去面试。

在约定的时间里，我到达了这家做电子辞典的公司，一个有着一米多长大辨子的女生接待了我。或许那时候还没有现在这么多HR的理论，也没有笔试、复试这么复杂的流程，大辨子只是看了我带的简历，就说：“我们这个岗位急需人，你明天来吧。”没有任何面试过程，甚至连薪资都没有谈过，我晕晕乎乎就成了这家公司的一名测试员。而那时候，我连测试是干什么的都不知道。

后来，我知道了同学那天一直没来的原因：她的工厂在关外，那天在布吉关，遇到了大塞车，两个小时才进了来，而在那个手机尚不普及的年代，我们没办法立刻联系上。我似乎应该感谢布吉关的这次塞车，感谢同学的这次迟到，不然，我可能不会去拨通那个电话。我的职业生涯也会是另外一种轨迹。

   中小企业市场的井喷令厂商发现了新的聚宝盆；融资、并购大戏不断；SOA继续深化落地，成功的被用户实施；SaaS不再是空中楼阁，一家家网站遍地开花……   

    然而面对越来越理性的用户，管理软件商们也面临着前所未有的挑战和压力。
    • 如何满足业务那实时变化的复杂需求，如何从根本上提高柔性，使企业IT能够“听话”的随需应变？SOA可以吗？
    • 如何衡量企业IT那玄妙莫测的绩效，如何降低企业IT居高不下的成本，让企业信息化“平易近人”？SaaS可以吗？
    • 如何降低企业那居高不下的能耗和成本，如何实现CIO和企业对社会责任做出的承诺，让IT变成“绿色”？虚拟化可以吗？

    我一直在想，测试在很多公司不被重视，甚至于被视为可有可无的角色，是不是因为测试工作不能产生看得见的经济效益？如果一个系统到了客户手里，很少出现问题，则所有的人会认为那是理所当然的，看不出测试有什么重要作用。而如果软件未完成测试就交给客户使用，通常的做法就是反馈—>修改—>升级，现在通讯方式发达，这个过程的可见成本也是很低的，测试的好坏似乎并没有直接的现金收入和损失。

    但那一次我却真实地看到了一起直接损失。我们给一个物业管理处开发了一套物业管理软件。老实说，这个软件还是通过了一定程度的测试，不过物业收费名目繁多，计算方式复杂，在有限的时间里，测试覆盖率值得怀疑。这个软件在管理处用了一个多月，也比较正常，没出现所谓的严重缺陷。然而，一个多月后，管理处反映说他们根据系统算出来的水电费少了1千多块。这问题有些难以置信，计费用例被划为重点用例，有点个位数上的误差是可能的，但差这么多就不是个小问题了。我们再对这个功能再反复测试，结合客户的真实数据，结果吓了所有人一跳：一个极为常用的功能，却漏掉一条十分正常的测试路径，而就在这条路径上，心存侥幸导致损失惨重。在当时的物业管理中，水费是按三段收费的，例如一段用水是1.9/吨，二段用水是2.85/吨，三段用水是3.8/吨，这个用水吨数分段值可以用系统设定，如第一段设成0-5，第二段5-15，第三段15以上，这个用例说起来还有些复杂，吨数在第一段、第二段、第三段分别是三个计算公式，然后考虑边界值和异常值。当吨数在第一段时，最容易计算，直接单价*数量，在第三段时比较麻烦，要把三段的值加起来。现在，第一段和第三段都没有错误，我们的系统在第二段出问题了：当吨数在第二段时，总金额是第一段和第二段的金额相加，而开发者写程序时，拷贝了第一段的公式，却没有加上第二段。测试者对这个功能也测试过，但是，她只看到系统得出了结果，刚好第一段和第三段的结果又都是正确的，就没有手工用计算器再算一次。当用户的吨数刚好落在第二段时，金额就算少了。

    管理处已经找业主收完水电费，在与水公司缴费时才发现这个问题，因怕业主会闹又不太可能补收，只好他们自己承担了这1千多块的损失，因为其他的原因，这个客户并未找我们公司赔偿，但是却让我看到了测试疏忽产生的可见损失， 在以后的软件缺陷分类中，“计算错误尤其是计费金额错误”列入了严重缺陷之列，虽然它看起来并不影响到系统功能的使用。

    题外话，最近看到几起因银行ATM机故障造成储户多取款的事情，最近一起，多取款的那个人被判无期，实在是天大的冤枉，他用人生替ATM的生产商承担了“莫须有”的责任。后来听说ATM的生产商赔付了银行的所有损失，这个也应该算是软件质量问题产生的可见成本吧。但是，银行，真黑！

 有些问题，在技术上可能不能称之为缺陷，但确确实实是一种错误，这种错误对系统的运行也未必有多大影响，却让客户感觉到不专业，或者不仔细，对团队的实力产生怀疑。

 我们给客户做了一个财务结算功能，客户的财务人员试用后，提出一条意见：未收帐款记录用红色显示。乍一看，这条意见目的很明确：用颜色给相关人员一些业务操作提醒。 “给记录着色以起到提示作用”是我们做软件提醒功能时的一个常用手段，于是，我们的开发人员未加思索，便将未收帐款所有记录的底色都变成红色，没有人发现其中的问题，这问题似乎太容易了，所有人都未感觉到有什么不妥，然后就得意满满地给客户升级了。谁知紧接着客户就打来电话：“我们是想未收帐款用红色的字显示，不是红底显示，现在一打开界面就是一大片红色，更看不清了。”随后又问道：“你们以前没有做过财务功能吗？”。有财务知识的人应该都知道红字在财务帐面上的含义，而我们却就在是这么一个常识性问题上犯了一个啼笑皆非的错误，不得不再重新改过。

 无独有偶，我们做了一套英文版的系统，其中“已发送（Sent）”的按钮写成“Sending”，客户说：“这个过去分词你们也写错？”

       应该说软件功能测试是一个要求广度的行业，除了测试技术和正在测试的业务之外，还需要很多相关业务的常识，财务、法律、外语……虽不要求上知天文，下知地理，前后知上下五千年，左右知中外发展史，但类似的笑话还是少发生为好吧。

       那一年，我所在的公司是做掌上电脑的，一次有个客户订了两百台机器，这些机器他们预备在周年庆典上给来宾做礼品，因此要求在掌上电脑开启时显示的封面是他们公司的Logo及名称。这个功能并不难实现，因为我们的产品本来就有自定义封面的功能，只要把客户发过来的Logo图片及名称换掉就行了。时间原因，来不及用软件批量换掉再下到工厂生产，所以产品工程部就拿了两百台成品过来，希望我们协助逐台换掉封面再测试通过，直接就可以发给客户了。

      当时测试部门有4个人，机器拿过来时已经下午5点了，晚上大家都加班到10点钟，更换和测试都没有问题，第二天一早就把机器发走了。很简单的一件事情，但是，麻烦很快就来了，客户打电话来说我们把Logo图片弄错了，他们有换新的Logo，图片发给产品工程部了，而我们换上的图片是旧的。原因很快查明，原来客户一直是和产品工程部联系的，他们新的Logo也发给了产品工程部，当时这个任务安排下来时，经理一再交待负责此事的同事去找产品工程部拿图片，而这个同事在之前也给这个客户换过一次封面，因为数量少，之前那次是她一个人做的，所以她就有一个旧的Logo图。而机器拿过来时，产品工程部负责的同事正好出去了，测试部的这个同事就没再去拿图，自以为是的把以前的旧图发给大家了。

        后来我们和客户做了很多解释，客户还比较通情达理，谅解了我们，但内部的责任追究下来，当事人罚款200，经理连带罚款200，我至今还清楚地记得经理站在那个同事面前欲苦无泪的表情，最后只是很无奈地说了句：“我交待过很多次让你去***那里要Logo的”。

        后来我也做了测试负责人，也经常会和其他部门打交道，经常会给客户发布最终版本，“只有一个来源”成为我做版本控制的原则之一。这个来源最好的当然是用版本控制工具，方便且安全。如果团队的人少，也可以使用服务器共享目录。但我一直很反对开发和测试之间使用即时通讯工具，比如MSN、QQ之类的来传输软件更新的版本，哪怕开发和测试都各只是一个人在做。虽然在某种程度上这样更快，但隐患无穷。而且在发给客户之前，就算我手头上有最新的软件版本，也一定会再去来源地取一次版本，并用几小时的时间做最终的版本确定。如果有疑问，也要找到发布测试版本的开发同事问清楚，不让大家辛苦的成果毁在发布这个环节上。

        有一天，客户反馈了一个奇怪的问题：他们的系统上午、下午都是正常的，但是在中午的时候，数据就无法保存，总是提示“保存失败”，我们接到问题的第一个反应通常是：中午的网络或服务器出现故障导致无法保存，但事实上这个答复客户是不满意的，因为做为一个业务操作系统的网络和服务器不会总是在中午出问题，况且只是“保存失败”，查询的功能都可以使用，这说明客户端和数据库的连接是正常的。

        这现象有些怪异，客户的数据库异常日志中报出“字段长度被截断”的记录，但究竟是哪个字段只会在中午被截断呢？我们反复在测试环境中模拟，都没有出现类似的现象，有些一筹莫展，以至于都怀疑是客户的电脑神经了。

        但是问题一直是存在的，客户中午都不能正常做业务，情绪越来越大，于是我不得不重新配了一套新的测试环境，和客户的真实环境基本相仿。说来也怪，到中午的时候，现象真的出现了，因为是在开发环境中出现的，我们很容易跟踪到了被截断的字段，是一个时间控件。本来，如果使用数据库的日期时间类型，所有的时间字段都不会出错的。但数据库设计者为了查询的方便用了字符型，10位字符，按常理来说足够了，为什么出了长度溢出的错误呢？

        后来我想起这个问题出在操作系统上，我们刚开始的测试环境用的是中文版本的Windows2000，中文操作系统默认的时间格式如“10：10：10”，是八位。但是，我们的客户是一家做国际业务的公司，统一使用英文版本的Windows2000，而英文操作系统默认的时间格式是英国的12小时制表示方法如“10：10：10 AM”，加上空格有11位，而11位的情况只在10、11、12点这三个时间会出现，如果是“9：10：10 AM”，刚好是十位。这也正是只有在中午才会保存失败的真正原因。如果在控制面板中把时间的格式调回24小时制的，这个问题不用改就解决了。但是想到客户的每台客户端都要去调这个格式，我们还是升级了数据库，把字段长度放到12位，彻底解决此问题。

        这个问题出现后，我想起来以前读到过的一个“Impossible=I'm possible!”的小故事，这个故事印象深刻，大意是这样的：有一天美国通用汽车公司的庞帝雅克（Pontiac）部门收到一封客户抱怨信，上面是这样写的：“这是我为了同一件事第二次写信给你，我不会怪你们为什么没有回信给我，因为我也觉得这样别人会认为我疯了，但这的确是一个事实。 “我们家有一个传统的习惯，就是我们每天在吃完晚餐后，都会以冰淇淋来当我们的饭后甜点。由于冰淇淋的口味很多，所以我们家每天在饭后才投票决定要吃哪一种口味，等大家决定后我就开车去买。”“但自从最近我买了一部新的庞帝雅克后，在我去买冰淇淋的这段路程问题就发生了。“你知道吗？每当我买的冰淇淋是香草口味时，我从店里出来车子就发不动。但如果我买的是其他的口味，车子发动就顺得很。我要让你知道，我对这件事情是非常认真的，尽管这个问题听起来很猪头。“为什么这部庞帝雅克当我买了香草冰淇淋它就秀逗，而我不管什么时候买其它口味的冰淇淋，它就一尾活龙？为什么？为什么？”

事实上庞帝雅克的总经理对这封信还真的心存怀疑，但他还是派了一位工程师去查看究竟。当工程师去找这位仁兄时，很惊讶的发现这封信是出之于一位事业成功、乐观、且受了高等教育的人。

工程师安排与这位仁兄的见面时间刚好是在用完晚餐的时间，两人于是一个箭步跃上车，往冰淇淋店开去。那个晚上投票结果是香草口味，当买好香草冰淇淋回到车上后，车子又秀逗了。

这位工程师之后又依约来了三个晚上。

第一晚，巧克力冰淇淋，车子没事。

第二晚，草莓冰淇淋，车子也没事。

第三晚，香草冰淇淋，车子“秀逗”。

这位思考有逻辑的工程师，到目前还是死不相信这位仁兄的车子对香草过敏。因此，他仍然不放弃继续安排相同的行程，希望能够将这个问题解决。工程师开始记下从头到现在所发生的种种详细资料，如时间、车子使用油的种类、车子开出及开回的时间……，根据资料显示他有了一个结论，这位仁兄买香草冰淇淋所花的时间比其它口味的要少。为什么呢？

        原因是出在这家冰淇淋店的内部设置的问题。因为，香草冰淇淋是所有冰淇淋口味中最畅销的口味，店家为了让顾客每次都能很快的取拿，将香草口味特别分开陈列在单独的冰柜，并将冰柜放置在店的前端；至于其它口味则放置在距离收银台较远的后端。

现在，工程师所要知道的疑问是，为什么这部车会因为从熄火到重新激活的时间较短时就会秀逗？原因很清楚，绝对不是因为香草冰淇淋的关系，工程师很快地由心中浮现出，答案应该是“蒸气锁”。因为当这位仁兄买其它口味时，由于时间较久，引擎有足够的时间散热，重新发动时就没有太大的问题。但是买香草口味时，由于花的时间较短，引擎太热以至于还无法让“蒸气锁”有足够的散热时间。

即使有些问题看起来真的是疯狂，但有时候它还是真的存在；做为一个测试者，我们每次在看待任何问题都要秉持着宽量的思考并去寻找寻解决的方法，碰到问题时模拟不出现象时不要直接就说那是不可能的，而更应投入一些真诚的努力。而我从遇到那个问题以后，再次遇到在客户反馈回问题而测试环境中无法遇到的现象时，不再以“测试没有发现”为解决的理由，而是会进一步去搭建尽量接近真实操作环境的测试环境或者去客户现场看一看，因此抓住了不少隐蔽的BUG。