51Testing软件测试论坛
标题:
本人刚参加公司,求有关应用程序的测试用例的设计
[打印本页]
作者:
小不点蜗牛
时间:
2010-5-27 12:42
标题:
本人刚参加公司,求有关应用程序的测试用例的设计
如题,本人现在刚刚参加工作,刚接触一些应用程序的软件的测试工作请问高人指点,如何进行一般的通用的应用程序的测试用例的设计,就是你拿到一个应用程序软件,你一般的设计测试用例的思路,如何着手,如何进行分类设计,很希望高手同仁们,过来的朋友们,可以给予本人一些思路,再次先谢过了!!!!
本人这样理解测试用例的设计,不知可否:
可以讲一下通用的应用程序,例如一个迅雷客户端,我是先在主界面里面,给我们的菜单栏进行测试用例的一些设计,再设计主界面的工具栏的测试用例,再设计左面的一个窗口的测试用例,然后再设计中间的窗口的测试用例,之后再设计我们的一些其他的交互功能的测试用例,再然后设计我们的服务器性能的一些测试用例,再然后进行一些简单的猴子测试,不知道我的这个思路对于我的这个软件的黑盒测试工作怎么样?这只是本人的一些个人看法,还请高人指正,谢谢了!!!!
作者:
小不点蜗牛
时间:
2010-5-27 19:44
为什么没有人给我个回音啊,求大家了
作者:
Jackc
时间:
2010-5-28 09:32
首先,其实好的需求文档本身就提供了一套较为完整的测试用例框架。
然后,如果抛开需求文档结构,则主要考虑通过划分子功能和各自优先级来搭建用例框架。至于怎么划分与组合,每个人的方式都不同,比如有些人喜欢按照不同界面划分,比如主界面有什么?一级界面有什么?;有些人喜欢按照功能分布区域来划分,比如上方Tool Bar提供了什么?中间的显示区域提供了什么?;还有的人喜欢按照功能实现来划分,比如怎么新建数据?怎么删除数据等等。
最好能根据软件实际情况来选择组合方式,当然,很多时候搭建框架的方式是混合型的,只是其中某一种方式占主导地位而已。
还是以迅雷为例,在脱离需求文档框架的情况下,最常使用的是
功能点或界面逐级向下划分测试点
的方式来构建整个框架:
首先,将功能测试、交互测试和性能测试这三个一级测试点划出来。(其后主要描述一些功能测试,其他两大测试就不涉及了)
然后,在功能测试上,可以分为:安装/卸载、运行两个部分。
对于任何软件,建议增加一个“风格”的部分。其主要职能是批处理软件中的各个公共模块和公共界面的测试。这部分用例可以先写一部分(可能一次性也不完整),在其后写其他部分用例的时候,再补充。
A、安装/卸载过程较为简单,主要是考虑正常流程、平台兼容、异常纠错以及一些后期维护升级等方面
B、Run是主要的测试部分,可以分为:未启动、运行中、启动/关闭
PS: 你的这个问题有些复杂,昨天想了一些,今天刚起一个头,手里来了一个case,看下午有没时间把剩下的补齐
作者:
小不点蜗牛
时间:
2010-5-28 12:11
版主,我的想法跟你的大致一样,可以这样我总是感觉有点太一般了,好像不能最大的覆盖测试的路径,也应该找不到开发部的那边的一些确切的错误,因为软件在开发部那边一出手,他们就已经对于功能大致的进行了一些测试的工作,所以结果是执行了这些功能性测试用例后,仍然不能治根,所以也就找不到一些特别的bug了,版主,我不急,你帮我看看,我等你的回音,谢谢了!!!
作者:
小不点蜗牛
时间:
2010-5-30 18:31
标题:
回复 3# 的帖子
版主,今天有空吗,帮我解决这个大难题吧。。。。。。。。我等你喔。。。。。。。。
作者:
Jackc
时间:
2010-6-2 11:50
呵呵,蜗牛,看来你们公司确实很锻炼人,一年多的测试就已经在涉及测试框架和模式的东西了
测试用例对于新人来说是指导规范,对于熟手来说,更多的作用是构建框架,在宏观上控制整个测试执行,保证测试结果不远离测试目标。
测试用例设计的思想其实也只有普通的这几种,但是想把某一种做细,还是很难的。
现在我主要使用的还是NOKIA式的框架:
1、先划分不同的测试类。主要分为“应用”、“框架”和“附件”三部分
“应用”包括测试实体提供的各种独立的主要功能:比如迅雷的新建链接、设置等
“框架”包括UI风格和公共功能:比如编辑框、存储、查找、退出等
“附件”包括一些次要功能:比如广告栏、登录窗口
2、再根据划分好的不同测试类各自设计用例。
这时会出现很多用例出现相互调用的情况,比如,“应用”类新建链接的用例,必然会调用到“框架”类的一种编辑框(编辑框应该存在N种类型)。这里的预期输出就看实际项目对测试粒度的要求了,要求高,就直接套用编辑框的用例;要求低,可以忽略编辑框的测试,只测试新建部分的流程,而编辑框单独测试。
3、错误推断。
这个没什么好说的了,想到多少写多少吧。
至于“交互测试”部分,其实是通过第2点中对不同类型的用例调用处理来实现的。
小结:这种方法的好处在于可以细化需求,并在可控的范围内适当调整测试粒度的弹性。如果测试范围放大到整个产品,也同样可以使用这种方法设计产品测试的框架。
主要的缺点在于对第1点的要求比较高,要求设计人员很熟悉各个功能点,并能逐一列举出来。
当然,换成是对流程比较熟悉,也可以使用UML图来做一个路径覆盖,不过稍微大一点的系统流程都比较复杂,也需要逐层分步来做。
作者:
小不点蜗牛
时间:
2010-6-5 00:16
标题:
回复 6# 的帖子
嗯,讲的很有道理,我待好好把你的思想整理整理,我想好好研究研究,真是高人啊!!!太感激了!
的确我们公司很注重我们新员工的培养,给我们的发展空间很大,我也感觉在公司里面好像是在学校里面一样,天天也是在学习,但是却不是那么的繁琐和累,每天都是感觉很充实,我真的很喜欢我现在这个公司!谢谢你的指导!
作者:
525guyue
时间:
2010-6-25 11:55
问下LZ是哪家公司呀?
作者:
小不点蜗牛
时间:
2010-7-8 18:35
原帖由
525guyue
于 2010-6-25 11:55 发表
问下LZ是哪家公司呀?
什么意思?你是做调查的吗?呵呵,我们是同行,我就是做调查取证的。
作者:
楠族开心果
时间:
2010-7-9 16:42
为Web应用程序创建测试用例
http://publish.itpub.net/m/2008-04-29/200804291617959.shtml
欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)
Powered by Discuz! X3.2