写笔记前先吐槽一个英文单词 “tests”。这个词其实是测试脚本的意思,也就是咱们所说的测试用例,“测试用例”(testcase)是rational公司首先提出来的,咱们用这个词比较多。但是老外不认,测试大牛们只会用tests这个词,它是个静态的东西,自动化脚本,手工测试用例其实都是tests。但是发现翻译过来的书籍都直接翻译成“测试”二字,测试我们一般看成一个动作,容易引起误解。btw,老外说把测试当做动词的时候写成test,少一个s,就差远了。翻译真是个难做的活儿,3.2节最后一段话让译者郁闷了吧。

书简述了ATDD和BDD的区别。ATDD侧重于让开发目标更加明确。BDD则侧重于制定系统行为的场景。两者对防止功能退化十分重要。但是书指出,实例化需求既不是防止退化的充分条件,也不是必要条件,只是有效条件。

并且,在Estimating Software Costs 这本书中作者做了统计:通过回归测试移除缺陷的平均有效率只有23%。 也就是是说,从保证软件质量角度,实例化需求所做的长期投资并不是非常划算。但是从其它角度来说却比较合算,比如。。。blabulabula。。。。。(其实主要在说的是文档的有用性。比如说逆向工程,这好像也是我们目前面临的问题,从主机里读代码是让程序员很死脑细胞的事情,耗费了大量精力,并且有时候还会出错误。) 书中给出了SongKick公司团队使用tests来指导系统变更实现时节省了50%的时间,这个很惊人。

根据可执行的需求说明创建文档 观点: 1.由于可以快速验证,可以低成本的保持被测系统与可执行文档的一致性。 2.文档是增量式的,其它工作可以同时进行。如果编制文档较大,完全没有必要让其他人等候! 3.书中推荐了一个实用工具relish,可以尝试一下。

以文档为中心的模型所具有的好处: 交付团队应该把测试文档看做是一个单独工件,与交付的系统等同重要。把文档当成关键性交付物是以文档为中心的模型最核心的部分。 增强技术结构或者澄清测试意图不再是技术负债! 把验收测试的工作交给初级开发人员和测试人员是有问题的! (注:同意这句话,不过对测试人员比较有杀伤力,要考虑出路鸟,哈哈哈。) 把活文档看成交付过程中的单独工件,团队还可以避免对它投资过度!

Remember: 实例化需求说明的两种模型 BDD,ATDD及其应用场景。 实例化需求说明的创建是循序渐进的。 活文档是交付过程中的重要工件,与代码一样重要。 侧重于建立业务流程文档系统可以帮助你避免长期维护需求说明和测试脚本造成的大部分常见问题。