一位实习生对软件测试的看法

• 前言
• • 一、项目文档
  • 二、测试的范围
  • 三、测试环境
  • 四、逆向思维测试
  • 五、测试过程中与程序员的沟通
  • 六、如何快速、有效的汇报BUG（如何有效避免迫害程序员）
  • • 1、测试环境描述
    • 2、文档标题与目录
    • 3、内容
    • 4、个人看法
  • 七、收尾
  • 后记

前言

如果我们把一个项目比作一道菜，那么程序员就是厨师，去做这道菜；软件测试员则是试吃员，去品尝这道菜有多美味，亦或者有多难吃。

那么作为“试吃员”，我们要如何形容这道菜有多好吃，好吃在哪，什么味道，亦或者难吃在哪，然后一一列举出来，试吃员和食客的最大区别在于：食客形容这道菜只会说“好吃”或者“不好吃”，试吃员必须形容这道菜则会说“这菜有点甜”、“这菜的辣椒刚好合适”。

然后作为“试吃员”，我们又该如何告诉“厨师”，这菜有多甜，这辣椒又合适在哪里呢好借着这段实习经历来分享下我对测试员的看法，欢迎各位看官指出本文章的缺点，或者补充说明，无论是怎么样我都非常高兴，这也是给我增长见识的机会，谢谢。

一、项目文档

• 这个是重点，记下来，要考。不开玩笑，这个非常重要，一定要看这个项目的文档！！！不要一接到任务就开始放飞自我。我们是“试吃员”，不是“食客”，这盘“菜”想怎么吃就怎么吃。看完项目文档后做好规划，例如我要测试这条数据是否传到数据库，那么我首先得检查数据库是否能正常连接，然后再接着下一步。就算是写程序也是一样，先规划后上手，先确定，再行动。做好规划，效率自然的也就提高，摸鱼的时间也变多了（滑稽）
• 还有一种情况，没有文档怎么办长呢一般会告诉你这个项目是用来做什么的，然后主要的流程是什么。那这个也没说呢（嘴巴甜点）！这个项目是用来干什么的体流程又是怎么样设我做（删）了某个步骤（库），会不会影响（跑）到整个项目的正常工作（路）定要问清楚，一旦出错了至少还可以知道自己会不会被训（笑）。

二、测试的范围

1. 大多数情况下，一个项目组至少有两个以上的测试员，如果只有一个测试员那就没什么问题，从头测到尾就行。
   那么针对多个测试员这种情况，项目组主要负责人会分配好每个测试员的测试范围，有的人测试界面，有的人测试代码，还有的测试数据库的连接。这个时候非常要注意了，你只能测试你自己这块，不能动其他地方，至于为什么，哪一部分因为测试导致出现了问题，项目组长可以快速、有效的找麻烦，如果组长发现你测试过界了，那优先找你麻烦；
2. 当然多数情况我们测试某项功能的时候会“超纲”，这种情况下一定要和项目主要负责人说明，告诉项目组长：“我测试的地方设计到XXX了啊，你做好心理准备啊。”然后项目组长一般会告诉你一些注意事项，这样给组长一点心理准备，出问题的时候训斥你会稍微轻点，当然训斥你多数情况下还是希望你长记性，并没有过多的意思，当然不排除异类（上次删错了一条记录，还好有备份的习惯，不然我那屁点实习“补贴”就扣得差不多了）。

三、测试环境

众所周知，PC上的游戏不能在手机上运行（云游戏或者移植不算）那么大家也知道，在手机上跑的软件就得用手机来测试，总不可能用电脑吧（模拟器也只是搭建一个手机的环境）。这个软件开发好了，那么作为测试员的我们首先要搭建好一个环境，你可以理解为把“菜”装到合适的“盘子”里，然后配上筷子或者刀叉，你总不可能把炒菜的锅给食客：“来，这是你点的菜，锅有点烫，锅铲在旁边，请慢用！”你行不行食客当场和你真人PK。

回归话题，我们必须要搭建一个合适的环境，成功的安装，跑得起，那么就没问题了。跑不起，或者安装不了，那看下说明书是不是安装在这个环境，如果不是那就去和负责这个项目的程序员沟通吧。

四、逆向思维测试

看完文档了，测试的范围有了，环境也搭建好了，可以开始动手了么，还差一步，如何去测试真的像同事们说的“随便点点”就好了么或者看到这个项目的程序员这么厉害，应该没有BUG，随便应付过去就得了么使那位程序员再厉害，自己在迁入前检查过一遍了，那真的没有问题了么/p>

“当局着迷，旁观者清！”就算程序员在迁入的时候运行了一遍没有问题，但并不保证他所编写的代码与项目组的其他程序员代码不会冲突，当两个人编写的代码中某个字段恰好命名一样，没迁入都还好，迁入后直接出问题。所以BUG它肯定存在的，不用担心测不出BUG，只是你没找对方向罢了。

回到标题，怎么个逆向思维测试呢个例子，你要测试这个网站能否正常登录，那么正常情况下有账号就输入账号密码，没有就注册，忘记了就点击忘记账号和密码得了，一般情况下这种是没什么问题的。然后你可以试下注册的时候是不是必须要输入相对应的信息才能注册呢些字段是否能同名录的时候不输入账号或者密码直接点击登录会出现什么状况，在连续快速点击登录的时候是否有一定的限制（如果没有限制的话，连续多次提交会占用服务器资源，从而导致服务器奔溃，一个端口或许不会怎么样，那么成千上万的请求呢还有个当你浏览器放大缩小比例后是否出现画面撕裂的现象呢/p>

我们不仅仅需要测试这个软件能不能达到预期的效果，还要以近乎“搞破坏”的形式去测试，这款软件如果能经得起咱们折腾，还能正常运行，达到预期的效果，那么这款软件目前是OK的，这就是我所理解逆向思维测试。

五、测试过程中与程序员的沟通

当你需要到源码进行查看的时候，那么问题就立马出来了，对于咱们刚入行没多久的实习生来说，看别人的代码简直像是看天书一样，特别是遇到那种天煞的程序员，打代码不写注释！！！我只是的实习生，为什么要这么对我！即使我看得懂，但我得花很大一部分时间去查看你这段代码的作用，测试既要讲究准确，又要讲究效率。当你看懂代码后，一天过去了~这个时候最简单的办法就是让程序员重新打上注释，或者让他告诉你这段代码实现的功能是什么。

有的人会说，那这样会不会让别人觉得我什么都不懂呢习生嘛，不会很正常，但不懂装懂才是最致命的。你一个人专研代码的时候，很容易理解错，特别是程序员老哥用的语言我从没接触过，这个时候你得马上和程序员说明情况，让做这盘“菜”的“厨师”来为你讲明，当然说法的方式也是有讲究的，程序员经常因为项目而加班，甚至导致睡眠不足，脾气自然会差，所以说话的方式、语气也不能太过强势，我们是针对这个问题进行沟通，而不是吵架。当然你有发火的权利，但我们是否采用更有效的方式处理呢/p>

六、如何快速、有效的汇报BUG（如何有效避免迫害程序员）

熟练的程序员写代码的时间只占20%，而剩下的80%的时间则是写文档，而软件测试员则更加了，与文档“斗智斗勇”是测试阶段必不可少的环节。即便你测试的范围特别小、或者测试到的BUG屈指可数，可以直接告诉程序员BUG所在的位置，表述不清楚现场演示给他看，但你还是要写文档，因为文档可以体现你是否认真的测试过，测试得到不到位，有没有遗漏，一看就知道。（测试5分钟，文档三小时，真快乐呢。）下面我来分享下我最近一次编写的文档是怎么编写吧，由于涉及到公司的利益，在此我将以口述的形式讲述出来。

1、测试环境描述

如果你要测试一款手机APP，那么你得在开头明确标记好你是用什么牌子的手机，又是用什么系统的，系统的版本又是多少，手机的配置又如何；如果你要测试在电脑上登录的网站，那么你电脑所使用的是什么浏览器，版本又是多少；如果你测试一款游戏，你甚至得把你电脑的内存啊中央处理器之类的写在开头（至于如何查看电脑的配置，自行百度即可），哦对了，你还得标记出你在测试哪一个版本的软件，有可能在你测试的同时新发布了一个版本；

我们为什么要将测试的机子配置写出来呢，很简单，程序员编写程序的代码所使用的机子配置肯定和你的机子是不一样的。有时候这款软件在程序员老哥的机子跑得起，在你的机子就出问题了，这给程序员一个参照，让程序员能更直观的找到问题所在，所以将自己的测试环境详细的列出来是必不可少的。

2、文档标题与目录

标题和目录的关系就像是器官和血管的关系，因为目录将所有标题联系在一起，简介明了，让程序老哥能更直观的看到自己的BUG到底有多少个（更直接的让程序员秃头。。。），还有个好处，在测试过程中会出现同类型的BUG，这个时候程序员老哥可以通过目录反复查看相同类型的BUG触发“机制”是什么，多一点参照物，就更快的解决BUG。

而标题也是一门不小的学问，标题一针见血，不拖拉，程序老哥看到BUG就差不多知道BUG是什么类型的了。

3、内容

测试文档的宗旨就是告诉程序员你生产了什么BUG，而内容则是告诉你哪部分，因为什么条件触发了BUG。文档内容必须是清晰明了，一眼扫过去就知晓问题到底出在哪才是真正的专业，我第一次写文档废话有点多，因为这件事情程序员老哥当场骂了我一顿呢。

那么如何清晰明了，你就当作“新手教程”来写，用文字+图片来引导程序员快速准确的找到问题所在，一开始写文档总会出现表述不清楚的情况，没关系，写多了就好了，而且不是有现场演示嘛，就算程序员老哥不在身边，录屏配上文字发给他，直到他理解为止（老手带新生打王者的情景），当然还是得注意语气和态度，大家都很累，真的没必要因为小事而发火。

4、个人看法

还是那句话：“当局者迷，旁观者清。”在测试BUG的过程中，你可以试着思考下问题所在地方，将自己的意见分享给程序员老哥，因为每个人的思维方式是不一样的，有可能程序员老哥陷入思维误区，而这个时候你提供了新的参照物，然后顺着你的思维解决掉问题，这种情况还不少。注意！因为我们是实习生，程序员的视野更辽阔，经验更丰富，不需要我们指手划脚，所以我们只是在提供新的可能性，而不是去要求程序员一定要按照我们的思路去走！

七、收尾

做任何事情都必须有始有终，在提交玩文档给程序员后，程序员修改完要再重新测试一遍，并且着重测试之前在文档上提到的BUG，既要做到防止“旧病复发”，又必须要保证不会新蹦出一个BUG，刚修复完一个BUG，又新出一个BUG，还得继续修，这或许就是程序员的写照。程序员老哥与BUG斗智斗勇，而我们作为测试员则是作为一个信标，向程序员指出BUG所在地方，定点打击。即便是上线了这款软件，也会出现BUG。而我们要做的就是将所有影响到软件正常运行的BUG全部找出，由程序员去消灭。当复验完后，组长一般情况下会进行审核，如果审核的时候BUG太多或者出现严重BUG，肯定会先训斥测试员为什么没有认真找。这种还算好，要是上线或者交付后检测出重大BUG才叫惨，重大错误还有可能直接损失公司的利益，到时候就不是和程序员老哥或者组长讯你了，说不定你有幸会见到CEO呢哈哈，所以复验收尾真的很重要。

后记

从我上大学没多久就关注CSDN到现在有3年半了吧，才开始第一次写博客，之前都不知道写什么，迟迟未动笔，做一件事情最好的时间一个是十年前，还有个是现在，我现在写博客应该不算晚吧哈哈。不管怎么怎么说这也算是我的实习经历，学到了很多，肚子终于有东西了。其实现在想想如果在一开始上大学后就坚持写博客，不写有多高深的文章，就写今天学了什么，有什么心得体会，真的对自己帮助很大，每写一次博客可以了解自己到底会什么。

就写到这里了，感谢各位看官们看我这个初入茅庐的青涩“实习生”，说不定我的经历和你们有些相识呢，也感谢CSDN论坛给我这个机会，让我更进一步的去学习。

来源：AcrossEternal