一个小人物的一次测试经历（原创1）_说说前面有那些弊端，猜猜后来会怎样？

fyxu333

大家评一评。:p

fyxu333

连载1        
这一次的测试是跨域漫游的新模型，我们这个组以前从来没有这样的环境，据可靠消息称，我们这个组也不可能搭建这样的环境。写case的时候我心里就在窃喜，既然没有环境，哈哈，那我的Test Case可以写的尽可能多，尽可能达到很高的覆盖率，尽可能好看，尽可能让领导满意，反正也不用我来测试了！

我们的开发人员有一个习惯，在需求分析的时候很少想到我们这些测试人员，我写case的时候需求规格说明已经现成了，所以，我必须自己从头看起，不过这样也好，节省了我去参加会议的时间。

因为最近公司做的是北美的项目，所以这些文档都是用英文书写的，我很沮丧，中国人看中国人写的英语，是一件很痛苦的事情，首先，写的人难以确切的表达自己的意思，其次，即使写的人表达了自己的意思，看的人也难以确切的理解他的意思，两样加起来，我看文档的时间超出了去参加会议的时间，我不禁幻想要，是参加了需求讨论会就该好的多，并不断安慰自己，即使用中文，也同样存在这些问题，只不过没有这么多罢了。

在看需求的过程中，我改正了作者N＋1处的语法和用词错误，当然这都不是什么了不起的大事，关键是我要明白需求说了一件什么样的事情，而且我作的这些改动也只限于我自己看罢了，因为我这种小人物对于需求说明的语法错误哪能提什么意见呢？

在我的苦心经营下，case到最后总算完工了，期间我找了三个开发人员协调，询问相关模糊的地方，其中一个是需求规格说明的作者A，一个是HLD的作者B，另一个不用说，是代码的编写人C了。

具体的情况是，需求规格说明的作者A是一个Team Leader级的人物，而我，PIT组的一个小人物，我的造访是不受欢迎的，第一个给他的电话，他就让我去找代码的编写人C了，当然，那是他的属下。

我找到C，C是个刚到公司不久的新人，我很高兴，因为C没有一般的开发人员那种在测试人员面前的架子，我们很有共同语言，不过，遗憾的是，C懂的东西似乎并不比我多，对需求的理解似乎也远远没有达到一个代码编写人的水平，除了可以从他那里得到同病相怜的好感之外，我觉得找他并没有给我带来任何益处，相反，到后来，我才醒悟，被人误导是件多么痛苦和追悔莫及的事情。

不管怎样，C还是让我解脱了一时的困惑，C向我讲述了他自己对需求的理解，给我的case书写提了他自己的意见，由于我没有其他的人可以求助，所以我在犹豫中参考了C的意见，很快就构思好了我的case大纲。

当中，一些疑问，我都是向C咨询的，因为我觉得向C打电话很轻松，他乐于解答我的疑问，不像那些开发人员一样，永远一幅忙的不可开交的架势。好不容易，我的case总算完工了，我举行了一个case的review会议，其中，参与的人有HLD的作者B、代码的编写人C，还有我们组暂时负责本次版本发布测试的人员D，其他的组内成员都没能请动，大家都在忙着自己的事情，身为Team Leader的A当然更不能到会。

Review的进程令我意想不到的艰难，我和C的case方案为B所不齿，B陈述了他自己的观点，觉得case应该按照他的说法来写，而不是像我所写的那样，主要理由就是我的case写的太多了，很多是完全没有必要的，如果是以前，我会暗自高兴，并欣然接受他的更改意见，因为case越少就意味着我的工作量越小，可是这一次，我心里暗自着急，我不愿自己的辛苦劳动化为灰烬，况且由于我坚信我们组不会有这样的测试环境，我的case再多也没有关系。

可是，看着B说得眉飞色舞，唾沫横飞，我发觉自己渐渐有些动摇了，觉得B说的很有一些道理，我就要投降了。

我在心里开始埋怨B，为什么没有早点对我提出这些意见？在开会之前，我是把自己的大纲给所有的成员发了邮件的，可是……也许他根本就没有事先看过，他的这些意见只是一时冲动罢了！我猛地从就要投降的状态清醒过来。

……在我和C的据理力争下，B反而有些妥协了，他终于说，其实我的case已经包括了他所有认为该测试的地方，只是也许有些冗余而已，我和C长舒了一口气，我们终于胜利了！

会议结束了，接下来，我就要例行公事，更新我的case了，我坐在电脑前，不得不承认，自己是个很容易受人影响的人，B在会议上所提的意见我都一一做了记录，我看着这些修改记录，终于觉得，我应该改变我case的布局，我彻底的后悔自己曾经听了C的意见，把我的case搞成了现在这种让自己看了都生厌的样子，我决定实施自己的想法，把case来个天翻地覆的改动。

改动还算迅速，是的，这次改动让我坚信了一点，兼听则明，偏信则暗，我结合了大家的意见，写出了我case的update版，随后把它发布到了全组，我想，我这个更新版的case到现在为止再也没有人看过，因为大家没有这个习惯，开完review会议之后，所有人的指责也尽完了。至于update这件事情，只有写case这个人记得罢了，至于到底update成什么样子，也没有人去过问了，

如果没有后来的测试，我想到现在还会认为我的case多么完美，没有任何瑕疵，可是，偏偏我们组坚持要搭建这样的环境，测试任务毫无疑问落在了我的肩上，恶梦还没结束，反而才刚刚开始。

luming

HLD、PIT是啥，不要说别人听不明白的黑话，要不说中文，要不给全称，最讨厌给不明白意义的缩写了。

[[i] Last edited by luming on 2005-5-20 at 11:05 [/i]]

kpxl

这是很多公司都存在的问题，里面提到了很多的可以说是毛病的地方

首先就是大人物一般不愿意在小问题上跟你解释，等到出了问题才会来找你麻烦，例如A和B
其次，测试用例的评审，大人物一般也不会“有时间”参加，因为他们都很忙
第三，大家都是在看到一个问题的时候，你一言我一语，但是总是说不到点子上，而且没有人会关注这个问题是否真的已经解决
第四，项目一开始，大家对自己的职责和权利并没有非常清楚

当然笔者也有一个毛病，就是在需求不清楚的时候，去问了开发，虽然是没有办法的办法，但是可想而知，用开发人员的理解来设计测试用例，然后还来测试这个开发人员的代码，系统上的偏差可想而知，不过如果你请教的是一个比较资深的开发，或者说行业知识比较强的开发，可能会好一些，但是你恰恰请教的是一个新手，看了之后，后面的测试结果已经基本上可以猜得出来，测试用例会跟实际的需求有很大的偏差。

jackei

楼主真的是很写实，很贴切，从一个侧面反应了国内IT人的个人素养和职业水平。

zension

难道我们就要向这样的环境低头吗？

songfun

to  luming:

请不要激动，HLD是概要设计文档——High Level Design。这是在很多公司做项目中必须用到的缩写。

至于PIT是什么，连我也不得而知，不过有些都是部门已有的缩写，在他们公司内部就这么叫的，你何必非得让人把它硬生生的翻译成中文呢？

就好像问你是不是搞IT的，你不会非要人家翻译成“信息技术”吧？习惯就好，不必太在意这些东西。

适者生存，呵呵

songfun

也提提我的读后感——最后一段的感触很深。
我们目前的评审也存在这样的问题——虎头蛇尾。
评审的时候大家真的是挺认真的，评审会结束后，进行复审就很敷衍，也只有靠tester自己的责任心了。

这方面确实还得加强，感谢楼主的帖子。

archonwang

简单来说，从需求开始评审，可能就不会出现需求不明确的问题了。
正确地理解了需求，也就是走好了测试用例设计的第一步。

其次，个人觉得笔者完全没有必要由于自己听取了C的建议而懊恼，毕竟C提供了帮助，尽管最后事实可能证明了一些帮助是无益的，然还是具有参考的价值。测试人员在工作时需要努力保持自身的客观公正性，不能在感情上偏袒任何一方。论辩的结果是为了得到一个更加合理、正确的结果，而不仅仅只是谁说服了谁。

再者，从笔者的角度来讲，觉得有理由相信目前国内软件业存在的一种通病：评审形式化。－－“好不容易，我的case总算完工了，我举行了一个case的review会议，其中，参与的人有HLD的作者B、代码的编写人C，还有我们组暂时负责本次版本发布测试的人员D，其他的组内成员都没能请动，大家都在忙着自己的事情，身为Team Leader的A当然更不能到会。”这样的评审可能得不到好的效果，尤其是身为需求提供者的A不到场。

fyxu333

luming：
实在是不好意思，由于在公司里用惯了这些简称，所以没有记得给大家一个解释

Test Case：测试用例
HLD：        High Level Design
PIT：         部分集成测试（也许是我们公司特有的）
Update：    更新
Review：    评审

fyxu333

由于这几天有别的事情，所以没有继续我的连载，真是对不起。

今天看了大家的评论，我觉得好感动，大家说得都很有道理，

不过我觉得有一个问题大家没有指出，就是我这个测试人员，在一开始的时候心态就摆错了，我认为没有环境，所以写测试用例就很不现实，导致了测试用例的不可用。

反正文章里面那个小小的测试人员就是我了，我会努力的把自己的感想再写出来给大家分享的！谢谢大家的鼓励！

luming

谢谢songfun和fyxu333的解释。

fyxu333

过了几个星期风平浪静的日子，我早就把自己写的关于跨域漫游的case忘记了，直到有一天，我的主管发布了近期的工作安排，我才发现，自己的名字和跨域漫游的测试任务赫然地摆在一起！

沮丧显然无济于事，我只好硬着头皮开始工作，当我真正要实施测试的时候，才体会到，理论其实多么的有用。我曾经在无数的书本里看过这样的告诫，测试用例要具备可执行性，可是直到这一刻，我才发现，我对这句话的理解是多么的肤浅！

看着自己近乎完美的用例，无从下手，我不知道环境到底应该怎么搭建，我也不知道哪些用例是可以执行的，哪些是不可以执行的，因为我写case的时候根本就没有考虑过这些，这个时候才发现自己做了一个多大的无用功，我开始痛恨自己的完美构架。

可是痛恨归痛恨，我必须化悲恸为力量，向组内的老测试人员讨教如何搭建测试环境。我不得不说，这一次，我经历了人生的冷暖百态，也许工作中就是这样的。

这种环境的搭建一无文档可以参考，二没有人员指导我，三我搞不清楚谁可以帮我。

我最先学会的就是抱怨，我不知道该怎么办，但是更糟糕的是我并没有和主管建立多么良好的关系，在这种困境到来的时候，我无人可以求助！

日子一天天过去，离测试应该完成的日子越来越近，我一筹莫展。这期间，我找过资深的测试人员E询问如何搭建跨域漫游环境，他似乎知道，似乎又不知道，总之，我没有从他那里得到我想要的答案，也许是每个人都有自己的任务，所以，依赖别人只是徒劳。

fyxu333

我决心自力更生，在得到别人的稍许提示以后，我着手开始筹备所需的资源。

这是个多么艰难的过程，这次的筹备是我作为测试员的整个生涯都难以忘怀的！

我们测试小组属于开发人员内部的测试组，很多资源并不如公司的系统测试部门那么充足，而这一次测试，我们就只好借用别人的服务器，而我的测试则需要三个这样的服务器。

终于，这种要求被拒绝了――没有人愿意提供这么多的服务器给我们！但是两个服务器还是可以提供的。

从我个人立场上来说，没有足够的服务器不是我的错，反而可以给我减轻很大的负担，因为我的测试用例中有大量需要三个服务器的情况。

现在，剩下的就是测试两个服务器的情况了，我以为局势变得可以控制，暗自欢喜。

日子一天天过去，两个服务器的承诺并没有得到兑现，我的环境理所当然也没有搭建起来。

中间，我做了很多努力，说四处奔走一点也不夸张，我以差不多公司前台小姐的话物量呼叫着答应给我们提供服务器的开发人员，我有时候甚至担心他会不会在我的电话里彻底爆发，不过还好，事情没有我想象的那样糟糕。

开通几个电话号码，对于我们通信的测试人员来说应该是轻而易举的事情，可是，当服务器掌握在别人手里的时候，你将意识到，这是件多么不可思议的事情！

“喂，您好，我是xx组的xx，麻烦您在xx服务器上帮我放几个号码……”

“喂，您好，我是刚刚让你放号的xx，请问您可不可以帮我把这几个号码的归属域该到xx？……”

“喂，您好，不好意思，打扰了，您刚刚给我放的号码怎么不能打电话啊？是不是付费方式不对？……”

“喂，您好，实在是太不好意思了，还是我，您那些号码怎么不能漫游啊？……”

“……”

终于有一次，电话那头的家伙对我说“请问你们可不可以用自己的服务器？”

我无语，如果可以，如果我们有，为什么还要那么低声下气求你？
后来我们的频繁骚扰终于导致了TS的所有者忍无可忍，他们收回了我的使用权，这样，我将近一个星期的努力完全白费了！

我欲哭无泪，只好等着别人安装我们自己的服务器。

fyxu333

kpxl
告诉你，我们公司所有的测试用例几乎都是和开发人员共同完成的，因为需求的时候几乎没有人会想起我们测试人员。

fyxu333

今天没有人回我的帖子了，自己顶一下！:p

dracul

写得很好啊！顶上去先！

onepeace

ding！

fyxu333

呵呵，没有人发表意见？还是大家觉得文章描述的测试惨不忍睹？:p

fyxu333

呵呵，没有人发表意见？还是大家觉得文章描述的测试惨不忍睹？:p