51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 13335|回复: 36
打印 上一主题 下一主题

单元测试做好的关键是什么?(2011-6-20)(获奖名单已公布)

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2011-6-20 09:46:45 | 只看该作者 回帖奖励 |正序浏览 |阅读模式
单元测试做好的关键是什么?

如果你也有问题想提出来和大家一起讨论,请点击此处>>
说不定下期讨论的问题就是由你提出的哦,请快快参与吧!


获奖名单

奖项

获奖名单

奖励

答案链接

三等奖

   becky07

100论坛积分

15#

三等奖

iceriver999

100论坛积分

10#

分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

37#
发表于 2011-9-22 14:20:11 | 只看该作者
我也正在开展单元测试的工作
测试用例咋写呢
输入是一个数据,经过一些列的运算得到一个输出
这个用例应该怎么写呢,难道就是把代码翻一下,自己手动计算一个值作为预期结果?
高手指点下。。。
回复 支持 反对

使用道具 举报

该用户从未签到

36#
发表于 2011-9-20 14:45:58 | 只看该作者
单元测试的用例不知道要怎么写
回复 支持 反对

使用道具 举报

该用户从未签到

35#
发表于 2011-8-29 10:17:54 | 只看该作者
我的意见是:
需求明确,业务熟悉
测试要点明确
测试范围清楚
在实践允许的情况下路径测试覆盖率高
回复 支持 反对

使用道具 举报

该用户从未签到

34#
发表于 2011-8-26 09:39:44 | 只看该作者
受益匪浅啊。。。
回复 支持 反对

使用道具 举报

  • TA的每日心情
    开心
    2017-6-9 15:04
  • 签到天数: 2 天

    连续签到: 1 天

    [LV.1]测试小兵

    33#
    发表于 2011-7-26 15:36:08 | 只看该作者
    1、测试人员最好有开发经验或者有看懂代码逻辑的能力,了解被测试的产品知识。
    2、要求要明确,测试用例文档要写得好,即将程序设计文档中的每个要素都覆盖到。必须有评审的过程。
    3、测试时,测试每天需要给开发发送错误修改要求,保证第二天有回答(修改或是查找到问题的原因)。
    单元测试方法有需要改进时,开发人员应支持。
    4、领导要重视,定期(如每周或每天)花一点时间开发人员和测试人员开个短会,说明项目进度、测试中
    发生的需要警示的问题。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    32#
    发表于 2011-7-25 15:01:20 | 只看该作者
    所谓单元测试,是指对某一功能或模块的单一逻辑结构的测试,其过程不涉及业务,而主要是测试程序对逻辑结构的实现是否正确。所以我认为单元测试要做好,首先要有良好的详细设计文档,然后测试人员根据详细设计文档去验证程序的实现是否正确就可以了。另外,做单元测试的测试人员最好对程序可采用的逻辑结构或算法有较深刻的理解,那么在程序的逻辑结构正确但不是最优的情况下,测试人员就可以帮助设计人员和程序员改进程序的逻辑或算法。
        综上所述:1、要有高质量的详细设计文档;
                  2、测试人员对程序逻辑结构和算法有一定程度的理解。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    31#
    发表于 2011-7-25 14:46:38 | 只看该作者
    学习学习
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    30#
    发表于 2011-7-25 09:23:46 | 只看该作者
    单元测试要能够满足需求上写好的关键功能点的实现。这部分有由各模块编程的开发人员完成的。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    29#
    发表于 2011-7-22 17:54:09 | 只看该作者
    从效率、质量考虑,开发做白盒单元测试,测试做黑盒单元测试。
    不考虑效率,只考虑质量,测试做白盒单元测试+黑盒单元测试。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    28#
    发表于 2011-7-22 15:05:35 | 只看该作者
    感觉测试不是想象中的那么简单哦 !!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    27#
    发表于 2011-7-20 11:50:08 | 只看该作者
    本帖最后由 windone 于 2011-7-20 13:06 编辑

    最近正在看关于单元测试的知识。整理在这篇帖子里供大家参考。
    1、很多情况下,单元测试大家理解就是白盒测试。白盒测试不能检测到未实现的需求或者遗漏的需求;要在单元测试阶段完成对功能的检查,同时要用到黑盒测试技术。
    2、白盒测试展开的基础是:掌握系统运行的相关知识。比如数据流,控制流的分析,需要熟悉编程语言;最好是有相关的编程经验。了解常见的系统异常,错误处理;常见的操作模式和异常的操作模式等。
    3、白盒测试可以在代码开发出来后的任何一个阶段进行,不过最好是在单元测试阶段展开。有些公司就是在完成系统功能测试,等代码版本基本稳定后展开代码级别白盒测试的。
    4、在软件安全测试领域,可以使用白盒技术发现系统的脆弱点,然后在黑盒测试阶段对这些区域进行狂轰乱炸。
    5、任何有利于促进对程序了解的所有文档都应当开放给白盒测试人员。代码是最基本的,设计文档和需求文档也是必须的。有些公司没有这些文档,则需要开发与测试之间展开大量的Q&A。做的好的公司,还会产生风险分析文档。
    6、单元测试技术:
    --- 数据流测试:关注变量的所有出现,从定义(初始化)到每一次使用。分析变量对程序运行的影响。
    最简单的方法是:分析一个变量,从它的某一次定义开始到这一次定义的结束。分析这段运行过程中程序的可疑代码,以及实际运行时的效果。
    ---代码级别的故障注入:通过注入程序代码来强制改变程序的运行状态,扰乱程序状态的方法。一般用来制造错误场景,以检查error handling code,改变执行路径,输入异常值,检查其返回值。
    ---覆盖度分析:一方面可以检测到执行不到的代码;另一方面,可以发现冗余test cases(不能增加覆盖度的cases),在随机测试过程中,通过覆盖度分析,能有效的提高测试的效率。
    覆盖度的度量方式有很多,比如语句覆盖,分支覆盖,条件覆盖等。
    特别需要注意的是:覆盖度分析仅用于对测试覆盖度进行分析,而不能用于设计测试用例。如果执行完测试用例后,发现覆盖度没有满足要求,需要去确认的是:这些代码路径需要被覆盖吗?为什么test cases错过了这些路径?通过风险分析的方法,确认是否需要增加测试。
    完全的覆盖并不能说明代码就是安全的,但是没有覆盖到的代码,一定要仔细检查。这些看起来无辜的未被执行的代码,极有可能成为被攻击的对象。
    ---除了依据安全规范之外,测试是个很大的挑战。依据一些非正常的,非功能性的操作,来检查系统的安全性,可靠性。多角度来检查系统,不同的配置,错误处理,等等。
    ---模糊测试:是一个通过向软件重复发送不同输入值来挖掘该软件漏洞的过程,试图使目标程序中断或崩溃。一般用于黑盒测试。微软的25%的Bug 是通过这样的方式发现的。
    ---环境配置测试:软件的安全需要考虑所有的可以运行的环境。包括各种各样的环境变量,选项,配置等。
    ---接口测试:与其他系统的借口测试,比如服务接口,数据交换等。
    ---配置测试:缺省配置与所有的其他配置,不同配置项之间的交叉测试。
    ---错误处理测试:包括异常处理,错误恢复,错误容忍。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    26#
    发表于 2011-7-18 10:47:19 | 只看该作者
    单元测试针对程序的模块,从程序内部出发设计用例,因此要要覆盖所有的情况。单元测试内容包括模块接口测试、局部数据结构测试、路径测试、错误处理测试等;重点是单元测试的结束条件,即所有的BUG都得到了修正。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    25#
    发表于 2011-7-14 16:28:12 | 只看该作者
    个人认为,对项目业务熟悉,对详细设计文档熟悉,加上自己的细心
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2018-5-18 16:44
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    24#
    发表于 2011-7-14 10:11:00 | 只看该作者
    熟悉需求,熟悉软件要达到的业务逻辑,做好代码审查,单元测试在于一个一个的单元,一个一个的功能点,摸清每个点,有的放矢
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    23#
    发表于 2011-7-8 15:52:50 | 只看该作者
    主要要有合理的管理体系,要确保测试提出的问题开发能改掉,不要退却责任这才是真理。不然测试累死开发不理一切都是浮云了。至于测试过程应该怎样楼上已经说的很详细了。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    22#
    发表于 2011-7-8 15:52:35 | 只看该作者
    主要要有合理的管理体系,要确保测试提出的问题开发能改掉,不要退却责任这才是真理。不然测试累死开发不理一切都是浮云了。至于测试过程应该怎样楼上已经说的很详细了。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    21#
    发表于 2011-7-7 17:56:42 | 只看该作者
    代码,接口,业务
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    20#
    发表于 2011-7-4 22:04:43 | 只看该作者
    需求要明确,关键点要确认好。测试用例的覆盖面要广。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    19#
    发表于 2011-7-1 21:54:55 | 只看该作者
    需求分析要明确,测试用例覆盖率要全面。最好有业务背景。
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-11-23 17:15 , Processed in 0.081215 second(s), 28 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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