求助!!查询项比较多怎么办?
:s现在在做功能测试,查询模块这里有40多项查询项,还有and,or的关系,有些项还分模糊和精确查询,有的有大于、小于和等于。。。。还有排序。请问如何设计测试用例,大家帮我想想办法:,( 用等价类试试。虽然条件有很多,但多数情况都是差不多的。
或者因果图也可以! 可是查询项该怎么划分等价类呢?比如有姓名、年龄、性别、政治面貌。。。。。。根据什么划分等价类呢?望举例说明,谢谢。。。 你的这些过滤条件是下拉列表选择,还是手工输入的? 若是B/S或C/S的系统直接测试这些杂项的数据源,可以在用例脚本或驱动数据中直接定义其输出,然后用独立的外部程序(需要的话要自主开发,不过较整个被测系统来说代价小得多,而且也有利于回归测试)来加以验证~~ Originally posted by Tender at 2005-8-15 05:34 PM:
你的这些过滤条件是下拉列表选择,还是手工输入的?
所有查询选项都是从下拉列表中选择的,共40多项,其中象姓名、简历等查询条件是有手工输入,有很多查询条件是从下拉列表中选择的。楼上的那位高手说的好抽象哦,可以再具体一点不:$ 关注中。。。。 Originally posted by dongcs at 2005-8-15 08:31 PM:
所有查询选项都是从下拉列表中选择的,共40多项,其中象姓名、简历等查询条件是有手工输入,有很多查询条件是从下拉列表中选择的。楼上的那位高手说的好抽象哦,可以再具体一点不:$
偶不是高人啊,汗……偶的意思是说要看你被测系统是以何种系统架构来开发的,而基于B/S或C/S的系统可以很好的实现数据层与服务层的分离。同时,还要看你所说的功能测试是处于哪个阶段:若是系统阶段,那你可以根据功能的需求规则来进行用例预定义后利用合适的测试工具直接在某一个(子)系统加工的数据源处进行自动验证,无需用手工肉眼的方式去一一比对,这样代价太高;若处于验收阶段,那通常系统已经以产品的方式发布,那测试员作为假想用户可能是直接面对产品的GUI模块,则这时你可以用自动化的GUI测试工具(比如WinRunner等)来完成这些烦杂琐碎的细项部件测试。当然,上面的这些也要求测试人员的综合能力较高才能实现,不然作为新手且没有合适的外部环境的话只有自己在老老实实工作的同时努力踏实地学习与提高吧~~ 谢谢!很有收获!看来手工已经跟不上发展形势了,偶要好好学习自动化测试工具的应用了。:) 楼主,手工测试在一段时间内还将必然存在并且可能是长期存在,不能因为某些情况下手工测试不合适而否定了手工测试的作用!请三思!:) 嗯,同意楼上朋友说的,手工测试是非常重要且必要的,理论上也没有纯自动化测试的概念,通常所说的自动化测试都是“手工+自动”也就是半自动的方式来驱动的。因此,想让自动化测试更好的为手工测试服务,那你也得更加重视与精通手工测试,呵呵~~ :$谢谢大家提醒,看来我还是别好高骛远了,扎扎实实地学吧 原帖由 dongcs 于 2005-8-15 20:31 发表 http://bbs.51testing.com/images/common/back.gif
所有查询选项都是从下拉列表中选择的,共40多项,其中象姓名、简历等查询条件是有手工输入,有很多查询条件是从下拉列表中选择的。楼上的那位高手说的好抽象哦,可以再具体一点不:$
我有一个类似的问题,查询逻辑条件有:与、或,查询方式分为:精确查找、模糊查找。查询关键字分为:ID、姓名、出生日期、检查日期、实例日期、性别。请帮忙解答,如何设计测试用例。 关注。。。 正交试验法 原帖由 willsmas 于 2008-12-2 22:28 发表 http://bbs.51testing.com/images/common/back.gif
正交试验法
请问可以详细点说明吗? 不可能做到全覆盖,可以简化些用例,但是都是有风险的,原本这个我算了下case怎么都上K了,简化了也就十几个了。 关注 1、从功能测试角度讲
各类方法都可以,什么等价类、正交实验法等等都可以,找出关键用例
2、从整体测试角度讲
考虑白盒测试+黑盒探索性验证会好测试一些
3、从性能测试讲
这个就是害人,功能能出来,我就不信性能也能出来,如果40多个条件还能保证性能,云计算小小意思了。。
4、从需求上讲
去问下自己什么情况需要这么多、这么多的条件?这样的页面客户友好性好么?客户会用么?是否能拆分成几个需求?
5、从设计上讲
这个是否用的公司的什么标准的灵活查询组件?如果是的话,测试用例就不用那么多了。。
个人意见:测试时多怀疑,你不好测,别人也不好用,有的时候需求、设计本身就是错误的
页:
[1]