51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 3252|回复: 10
打印 上一主题 下一主题

[讨论] 思考:做功能函数的时候到底要不要引入验证点

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2007-12-14 16:11:40 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
功能函数就是为了完成功能|配置|中间步骤 而提供的函数。
可是在写功能函数的时候,很多地方最后是要回头来做检查的,如果重新写检查点的代码就和功能函数,就会产生的大量的重复代码。
如果在功能函数里面加入检查点,就会影响功能函数的执行速度,每次都去做重复的检查。

在功能函数上加一个Check参数怎么样呢

Public Function initStuff(var1,var2,var3,Check)
if check then
' Add some checkpoints and output results
Else
' Do What initStuff should do
End if

这样就可以在调用的时候选择否来执行功能,选择是否引入检查点。这种检查点的优先级是比较低的,所以就在第一次full pass的时候运行,或者其他的比较重要的场合才运行。。


我在考虑这样是否冗余,考虑到一般的linux bash程序都有一个debug开关,也完成了一些log的功能。。。跟我的想法类似。。如果不在功能函数里检查相应界面上出现的检查点,那在什么时候能最省力不冗余呢?

[ 本帖最后由 walker1020 于 2007-12-14 23:48 编辑 ]
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
发表于 2007-12-14 16:33:56 | 只看该作者
自己写个解释器处理脚本中的debug代码,生成debug版本和release版本
回复 支持 反对

使用道具 举报

该用户从未签到

3#
 楼主| 发表于 2007-12-14 16:40:03 | 只看该作者
原帖由 danmy 于 2007-12-14 16:33 发表
自己写个解释器处理脚本中的debug代码,生成debug版本和release版本


解释器是一个名词,没错,技术名词,用来解析高级语言的底层环境,把高级语言翻译成机器码。
不过用在这里不合适,我不是要做debug,是要做checkpoint.即便做debug或者checkpoint的一些功能,也不需要额外解释器,谢谢。
回复 支持 反对

使用道具 举报

该用户从未签到

4#
发表于 2007-12-14 18:34:20 | 只看该作者
这个道理和手工测试是一样的。

所谓功能函数,完成某段特定功能的封装代码。在某种情况下,功能函数也是一个case
举个最简单的例子,登录过程录制成一个功能函数。显然,对登录过程来说,本身是一个很重要的测试点,应该有单独的测试用例进行详细测试。

而对于登录过程这个功能函数,我们期许的应该是要完成登录过程以便进行后期其他功能测试工作。每个测试用例都有输入和期望输出。期望输出就是我们的测试重点,我们的所有检查点都围绕此进行,而此时,登录过程的详细测试可能不能够不是这个case所关心的,我们无需把精力放在登录测试上,我们要的只是登录过程的实现。

所以,个人认为所谓功能函数重点在以完成某项逻辑功能为主。当然自动化测试相比手工测试的优势就是能不费力地完成更多的检查工作。但我认为测试思想始终还是一致的。
回复 支持 反对

使用道具 举报

该用户从未签到

5#
发表于 2007-12-14 21:56:03 | 只看该作者
不太清楚怎么会哦是~
回复 支持 反对

使用道具 举报

  • TA的每日心情
    开心
    2016-2-27 08:48
  • 签到天数: 2 天

    连续签到: 1 天

    [LV.1]测试小兵

    6#
    发表于 2007-12-14 23:49:50 | 只看该作者
    楼主有思考,有想法,支持一下!
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2016-2-27 08:48
  • 签到天数: 2 天

    连续签到: 1 天

    [LV.1]测试小兵

    7#
    发表于 2007-12-14 23:51:25 | 只看该作者
    不是很理解楼主写的功能函数里面引入的验证点 的作用是什么。 是类似于 函数的 Pre-condition 吗?还是?
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    8#
    发表于 2007-12-15 01:45:05 | 只看该作者
    测试的每个步骤都可能发生错误,都可能会有bug存在,所以功能函数都要有一定的结果检查,但不用太详细。

    比如添加一条记录,将其操作封装成一个功能函数,功能函数在添加完记录后,只要检查确实有一条记录生成了,而且id是所添加记录的id,那功能函数的检查就算通过了。

    如果功能函数完全不加检查的话,那整个Case的执行,就完全是瞎子一样的乱跑了,中间步骤是否执行正确都没有一点保证。

    如果添加一条记录本身是个Case,那检查就要更加严格了,可能记录里的每个字段的值都要检查一遍。这个可以在调用功能函数完成之后,另外加一些检查代码。

    如果两者确实有冲突,那么,添加记录的Case就不要用添加记录的功能函数了,完全自己写脚本来实现详细检查。因为写功能函数的目的,是为了让更多的Case来调用,以简化Case的开发成本,提高开发效率。

    总之一句话,添加记录Case只是一棵树木,而其他更多需要用到添加记录功能函数的Case则是一片森林。我们不能为了一棵树木,而舍弃一片森林!

    [ 本帖最后由 yabest 于 2007-12-15 01:48 编辑 ]
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    9#
    发表于 2007-12-15 15:04:20 | 只看该作者

    回复 8# 的帖子

    yabest的树木与森林相当精辟啊!学习了!
    个人认为,功能函数应该根据他所在的层来设置检查点,比如最底层的下拉框选择函数,你就需要对对象是否存在,下拉框有没有这样的值进行检查;而对于特定的功能函数,需根据功能的特点来设置检查点;而如果碰到特定功能函数进行检查会非常麻烦,则需要独立编写相应的检查点.所以我觉得检查点的设立应该根据函数的所在层进行设置,从而提高脚本的复用性,高效性,维护性,扩展性.
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    10#
     楼主| 发表于 2007-12-17 11:08:09 | 只看该作者
    原帖由 yabest 于 2007-12-15 01:45 发表
    测试的每个步骤都可能发生错误,都可能会有bug存在,所以功能函数都要有一定的结果检查,但不用太详细。

    比如添加一条记录,将其操作封装成一个功能函数,功能函数在添加完记录后,只要检查确实有一条记录生成了, ...


    照ya这么说,看来主要的检查是确保功能函数本身正确地完成了。不添加所经历界面的检查点。嗯,先这么往下走走看。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2014-11-11 09:38
  • 签到天数: 2 天

    连续签到: 2 天

    [LV.1]测试小兵

    11#
    发表于 2007-12-17 12:02:01 | 只看该作者
    学习了
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-11-9 01:49 , Processed in 0.070301 second(s), 27 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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