Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1702154
  • 博文数量: 98
  • 博客积分: 667
  • 博客等级: 上士
  • 技术积分: 1631
  • 用 户 组: 普通用户
  • 注册时间: 2009-04-27 15:59
个人简介

一沙一世界 一树一菩提

文章分类

全部博文(98)

文章存档

2021年(8)

2020年(16)

2019年(8)

2017年(1)

2016年(11)

2015年(17)

2014年(9)

2013年(4)

2012年(19)

2011年(1)

2009年(4)

分类: 敏捷开发

2019-11-15 16:22:52

这几天,看了一本书:代码整洁之道 程序员的职业素养。深有感触,记录如下。

1 验收测试和单元测试
      单元测试是程序员写给程序员的,它是正式的设计文档,描述验证了底层结构及代码的行为。关心单元测试结果的是程序员而不是业务人员。
      验收测试是正式的需求文档,描述了业务方认为系统应该如何运行,关心验收测试结果的除了程序员外,业务方更在乎这个结果。
      尽管单元测试和验收测试的对象通常是相同的,但是绝对不是“重复劳动”。
      首先,尽管两者测试的对象可能是同一个对象,其机制和路径却是不同的。单元测试是深入系统内部进行,调用特定类的方法,验收测试则是在系统外部,通常是在API或者UI级别进行。所以,两者的执行路径是截然不同的。不过,这两种测试更深层系的不同在于测试本身,它们的主要功能其实不是测试,测试只是它们的附属职能。单元测试和验收测试首先是文档,然后才是测试。他们的主要目的是如实描述系统的设计,结构,行为是否达到了具体指标,所以它们真正的价值不再测试上,而在于具体指标上。

2 图像界面的测试
   预先制定详细的GUI很难,因为美是主观的,会不断变化。所以编写GUI的测试很麻烦。但是如果把gui当成api来处理,而不是看成按钮,滚动条,菜单。。。。那验收测试就简单多了。布局,格式,工作流都会因为效率和美观的原因而变化,但是GUI背后的功能却不会因此变化,所以在编写GUI验收测试的时候,必须使用GUI背后相对稳定的抽象元素。比如页面有多个按钮,写测试的时候,就不应当根据按钮的坐标来点击,而是根据名字,或者给每个按钮加一个ID。更好的办法是赋予ID明确的意义,如某个测试选择的是ID为ok_botton的按钮,而不是控制区域内第四行第三列的按钮。更好的办法是,应当调用真实的API,而不是GUI。要把GUI和业务逻辑分开。测试程序应当调用GUI使用的API。

3 持续集成
      请务必确保在持续集成过程中,单元测试和验收测试每天都能运行好几次,整套持续集成系统由代码管理系统来触发。只要有人提交了代码,持续集成系统会自动开始构建,并运行所有的测试,测试结果会用电子邮件发送给团队所有人。
      请务必确保持续集成系统随时都可以运行,持续集成不应该失败,如果失败了,团队所有人都应该立刻停下手里的活,看如何让测试通过。在持续集成系统里,失败的集成应该视为紧急情况,也就是“立刻中止”型事件。

4 验收测试
      首先,我们把验收测试定义为业务方和开发方合作编写的测试,其目的在于确定需求已经完成。
      交流细节是一件很麻烦的事情。尤其是开发方和业务方交流关于程序的细节时,更是如此。同常,双方坐下握手言欢,以为对方都明白自己的意思,取得了共识,然后带着截然不同的理解和想法离开。眼解决这种开发方和业务方沟通的问题,一个吐血推荐的有效的办法就是编写自动化验收测试。这些测试住够正式,所以结果也足够权威。这些测试不会造成模糊,也不会与真实脱节。这就是无可挑剔的正式的需求文档。









阅读(814) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~