51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 2039|回复: 3
打印 上一主题 下一主题

问个问题,测试方法模型化的

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2010-10-14 10:15:07 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
我想表达的意思是:
比如:
1.表单:测试方法:组合测试
2.流程:测试方法:场景法
3.关联功能:因果图?

把这些方法模型化,比如还有些功能:
报表
查询功能

想把我公司产品的功能分类,同类功能用某些方法模型测试,找到最好的测试方法或帮助新人,节省时间,提高效果等等的目的。

我自己都不知道自己在说什么?你们能听懂不?
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
发表于 2010-10-15 17:36:07 | 只看该作者
把测试分类?节省时间。
回复 支持 反对

使用道具 举报

该用户从未签到

3#
发表于 2010-10-21 14:10:06 | 只看该作者
首先,我们要了解测试方法的定义,LZ所讲的是黑盒测试用例设计方法,这个概念不要搞混淆,当然LZ的整体思想是好的,但是如果硬要给功能点套上这些方法模板其实是行不通的,因为方法要理解和灵活运用才能取到好的效果。
当然,在所有项目中套用一种模式行不通不代表这个想法就是错误的,其实在很多参考文档都有指出,在测试方案生成的过程中,LZ的想法是可以融合进去的,针对单个的项目,由资深测试工程师将需求文档中流程、状态转换、因果关联甚至边界和组合等种种测试点予以方法标注,作为测试用例编写时的参考,那么基线后的测试方案就可以取到LZ所讲的帮助新人、节省时间等作用。毕竟新人在写用例的过程中去思考这些方法,才会令新人成长。
回复 支持 反对

使用道具 举报

该用户从未签到

4#
发表于 2010-12-14 11:21:43 | 只看该作者
单纯的测试方法是不能满足要求的。还是重点对测试的对象设计组合的测试策略可靠。
回复 支持 反对

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-11-6 23:22 , Processed in 0.067085 second(s), 27 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表