自动化论坛

 找回密码
 立即注册
搜索
热搜: 变频器 PLC 伺服
查看: 2159|回复: 0
打印 上一主题 下一主题

什么样的测试才是优秀的测试

[复制链接]

7

主题

0

好友

37

积分

新手上路

Rank: 1

跳转到指定楼层
楼主
发表于 2015-10-21 14:25:28 |只看该作者 |倒序浏览
信息来源于网络,更多信息请点击:ISTQB认证 http://www.imbus.cn/cn/imbus/

优秀的测试通过包括以下要素:
·测试代码的可读性和可维护性
·代码在项目中及特定源代码中的组织方式
·测试所检查的内容
·测试的可靠性及可重复性
·测试对测试替身的使用
·可读的代码才是可维护的代码
研究表明,代码较差的可读性与缺陷密度密切相关:虽然测试是为了捕获错误,防止缺陷,但是测试代码也是代码,其可读性也很容易变差。难以阅读的代码难以测试,难以阅读的测试代码难以调试和修复错误。
结构有助于理解事物
如果是个巨大的测试方法,花了很长时间执行完测试后报错,你可能要花一段时间才能在测试代码中找到确切的出错位置。测试代码缺乏结构,无助于你理清相互的影响,某个对象是在哪里初始化的,出错时某个变量的值是多少,等等。
如果测试代码具有一个合理的结构并确保它有用,这样你才能:
·找到与手上任务相关的测试类
·从那些类中识别出合适的测试方法
·理解测试方法中对象的生命周期
要注意测试所检查的内容
用正确的方式测试正确的事物也很关键。
不要太过相信测试的名称。有时那些测试其实完全是在测试不同的东西。这与良好的结构有关——如果测试的名字错误地表达了要测试的内容,那就像是跟着错误的路标驾驶。
从可维护性角度尤其重要的是,你的测试应该检查预期行为而非具体实现。
独立的测试易于单独运行
测试代码要关注测试的独立水平,尤其是架构边界附近。在边界上容易出现代码坏味道。一看到外部信赖就特别小心,包括:时间、随机数、并发性、基础设施、现存数据、持久化、网络。
隔离和独立很重要,因为没有它们就难以运行和维护测试。
测试意外失败的最不寻常的例子之一,是一个测试作为套件的一部分时可以通过,但单独运行却神秘地失败。那些症状散发着测试相互信赖的臭气。
当编写的测试涉及时间、随机数、并发性、基础设施、持久化或网络时,你就应该格外小心。尽量避免依赖它们,将它们限制到小的隔离单元中。
在实践中要找到合适的方式做下面这些事:
·用测试替身替换对第三方库的依赖,根据需要将其包装到你自己的适配层中。
·将测试代码与其用到的资源放在一起,或许是在一个包里。
·让测试代码自己产生所需的资源,而不要让它们与源代码分开,,
·对于需要持久化的集成测试,使用内存数据库。用了干净的数据集,就能极大地简化测试的启动问题。还有,它们通常启动得超级快。
·令测试自行建立所需的上下文。不要依赖于任何之前运行的任何测试.
·将线程代码分为同步和异步两部分,所有程序逻辑都放在一个常规的同步代码单元中,将棘手的并发部分留给一小堆专用测试。
可靠的测试才是可靠的
几乎不会失败的测试就等于废物。这种测试我们称之为快乐的测试——某个测试快乐地执行一段生产代码,或者是全部的执行路径,却没有一句断言。它们根本什么都没测试。
为了让测试值得依靠,它们就需要可重复。
如果你的逻辑包含异步内容或依赖于当前时间,确保将它们隔离在一个接口之后,这样就可以用“测试替身”来替换它们从而使测试可重复。
每个行业都有其工具而测试也不例外
测试替身就是测试的工具,它是程序员熟知的stub(桩)、fake(伪造对象)、mock(模拟对象)等的总称。
使用测试替身的好处:
·通过简化要执行的代码来加速执行测试
·模拟难以出现的异常情况
·观察那些对测试代码不可见的状态和交互
但测试替身并不是行业中编写自动化测试的仅有工具,还有测试框架。


您需要登录后才可以回帖 登录 | 立即注册

社区首页| 家园首页| 群组首页|我的微博|手机版|Archiver|caisg Inc.

GMT+8, 2024-12-23 17:39 , Processed in 0.055237 second(s), 19 queries .

Powered by Discuz! Templates yeei! © 2001-2011 Comsenz Inc.

回顶部