|
|
引用下不知道是哪位老大说的话，我们是测试员，不是测试机器，我们和测试机器的区别，在于人是活的，机器是死的。
很多刚从事测试的朋友在设计测试用例时不知道如何下手，甚至不知道怎么去测试，感觉自己找不到BUG，有一种挫折感，
实际上在一些中小型公司，测试未成为体系的公司，我们测试员常常一个人就负责了一个项目，包括需求，测试，缺陷报告等等全是我们一手操作。
仅以黑盒测试为案例
一.了解业务
如果你手上的项目没有需求，没有文档直接让你测，你是很难找到BUG的，要知道开发人员在开发的时候是会自测的，也就是在功能上很难直接找到BUG，这时，你就要多去问，多去了解业务，了解业务是设计测试用例的前提， 试问一个连业务都不了解的测试员如何去设计测试用例，如何保证测试用例的覆盖面积呢。
二.设计测试用例
对于一个项目只有一个测试员来说，设计测试用例的方法实际上就没有那么多讲究了，关于测试用例设计方法网上有很多诸如因果图，等价类甚至路径测试等我就不一一述说了，这里主要介绍一种适合新人的设计方法，这种方法理解起来简单，做起来也容易，最关键的是这种设计方法是测试的一个项目整体，也就是说在大的面积里能达到一个很客观的覆盖面积，非常适合新手，方法名为----场景分析法
场景分析法以一条基本流为主，发散出多条备选流以达到覆盖效果，设计出来的测试用例不是一个单纯的数据，而是一个完整的业务操作过程，这个地方就需要前面说过的了解业务，只有充分了解业务，在设计基本流的时候才不会有过多的遗漏，同时发散出来的备选流也能达到更多的覆盖效果。下面以添加--修改--审核--发布---删除审核---彻底删除为基本流（假设了解业务时，已经明确业务要求添加的数据可以修改，修改后要通过审核才能发布，彻底删除前页需要进行删除审核）
这里的基本流就是添加--修改--审核--发布---删除审核---彻底删除，这个基本流就是一个完整的业务流程了
那么发散出来的备选流，就可以有
1.添加--删除
2.添加--发布
3.添加--发布--删除
4.添加--修改--删除
。。。。。等等，单只是这一条基本流就能发散出很多备选流，这里的覆盖面积单独针对这条基本流就已经很好了，如果添加的数据对于其他的功能模块有关联，也可以将此功能模块加入到基本流里，比如添加的是图书信息，与他管理的还有库存管理信息，这个时候我们就可以在基本流里么加入一个库存管理信息的查看功能，
根据对业务的了解，设计多条基本流，要覆盖所有的功能模块，这样就能覆盖所有的功能模块不至于遗漏，
三.功能测试使用工具，开始简单的自动化测试
我们测试时，常常需要用到很多数据，单独的点击是行不通的，很多功能需要我们填写数据，比如添加，修改等。这时我们的工作量就很重并且很无聊，很烦闷，这时我们可以开始接触自动化了，不用把自动化想的太难，实际上最初我们只是使用一些皮毛，用自动化的工具录制脚本并回放脚本，再加入参数化设置，这样做至少会为我们节省百分之70的工作量，甚至更多，这里介绍下功能测试的工具QTP重点是QTP的参数化测试，
在第二步操作时，我们已经设置好了基本流和备选流，这时我们需要去下载一个QTP（其他工具也行，初学者建议使用QTP当然也要你的项目支持QTP才行，）至于QTP的**安装录制回放我就不说了，网上有很多资料，并且也确实很简单，参数化其实也很简单
在keyword view视图下 对应Value列 点击希望参数化的数据，数据后面会显示一个#号按钮，点击它弹出一个框，选择Paramter，这个属性后面跟着一个下拉框，下拉框里分别是Data Table,Environment,Random Number 分别代表了数据表格，环境变量，随机数
对于新人，使用Data Table,Random Number 就足够了，以Data Table为案例，选择Data Table后，下方会有Name,和Location in Data Table可以设置，name可以是中文，对应的是你所设参数的列名，比如“姓名”“账号”等。Location in Data Table,推荐使用第二个选项Current action sheet(local) 当然这里你也可以不管， 这里的设置主要是针对可能需要用到得部分循环，要做部分循环的话就需要了解一下QTP的Action 这里就不多说了
设置好参数后再QTP下方就会有一个数据表格，我们只需要在录制好脚本后，把需要输入数据的地方设置上参数化，再将下方的参数化的数据表格填上数据，就可以实现自动化了，这里有一点要注意了录制脚本时最好做到一个完整的循环，
假设 我们要新增数据，预想中的自动化：
点击新增---录入数据---点击确定（这里一定要确定页面返回到了点击新增前的页面，这样才能达到循环的效果）
这时QTP会根据我们的设置自动完成循环，假设你设置了参数化，并且设置了10组数据，那么QTP就会循环执行10次代码 ，这时你就可以泡杯咖啡 小小休息下了，
四.自动化与场景法结合
在第二步时，我们已经根据场景法设置了测试用例，如果我们设置了4条基础流，并且每条基础流有10条备选流，也就是40组测试用例，纯手工测试的话你可能需要做40次添加甚至更多的录入数据的操作，这个时候结合我们的工具，每条基本流录制一个测试脚本，也就是4个脚本，在执行备选流的时候只要在脚本中设置断点，或者直接运行脚本中你希望运行的部分让它单独执行循环，这里还是以第一步举的案例来分析
基本流就是添加--修改--审核--发布---删除审核---彻底删除，以这条基本流录制一个脚本
备选流
1.添加--删除
2.添加--发布
3.添加--发布--删除
4.添加--修改--删除
在脚本执行完添加时，因为删除不需要数据的录入，我们可以直接手动删除，（一般只需要点击就可以操作的，我们都可以自己操作，对新人来说最繁琐的还是重复数据的录入，尤其是系统对数据验证比较严格的时候，是很头大的）
这里为了说明 我们多加一条备选流，添加--发布--修改
执行完了添加的脚本，我们可以将脚本直接跳到修改让他直接执行修改的脚本，这样一来我们的工作量就大大减少了，百分之70的工作量，随随便便就减少啦。
要实现这些操作，还需要一些细节上注意下，比如说断点的设置，脚本部分循环的完整性，也就是开头到结尾，要保证结尾后就是开头
还要注意Action的设置和循环设置
五.回归测试（验收测试）
一个项目的完成期间会有很多个版本，基本上修复一次BUG就会更新一个新版本，这个时候有可能这个BUG改了因为代码覆盖或其他原因其他BUG又出现了，如果每个版本，每次开发修改你都要重新测，是不是会很烦，你做到这里的时候是不是会觉得测试真没前途
，实际上，依照上述的描述，你完全可以直接对可能有影响的功能模块选择性德去执行脚本
自动化测试最大的好处就是在于回归测试（验收测试）
六.个人的小小感悟
就犹如前言所说，我们是测试员不是测试机器，不是上司让你做什么，你就做什么，人与机器最大的不同，就是人会偷懒，机器不会
我一直认为自己是个懒惰的人，能用1小时解决的事情，为什么要用20小时解决呢，测试员不仅在设计测试用例的时候要用脑袋，在测试计划，测试执行一样要用脑袋，说实话，在项目开发过程中，我们测试的所能运用的时间是最少的，大部分情况我们无事可做，要测试需要等待版本的更新，而一个版本有可能需要一个星期才会更新，给我们的时间有时候只有一天，试想下一天的时间你要将开发人员做了一个星期的程序测试完，这个工作量，这也就是为什么测试员闲的时候很闲，忙的时候很忙了，所以我们一定要学会高效率的测试，工作是死得，人是活得，不要认为公司没有给你用自动化的待遇，也没有给你用工具的工作你就不去做了，仔细想想收益最大的人依旧是你，不管是从技术角度还是从工作量来讲。
最后补充一句，不用脑袋的测试员，与测试机器无异 |
|
/1 
关于我们
发表于 2011-9-20 12:08:21
QQ好友和群
QQ空间
腾讯微博
腾讯朋友
微信
收藏
置顶服务
换色服务
楼主
大家看了记得留言 评论下啊
为神马帖子进了精选贴，没有通知呢0 0 而且帖子名字也改了 虽然 周点击第一有点小高兴，不过还是不明白啊 话说上精选帖有奖励么0 0