阅读《实例化需求》13-17章有感

今天,我阅读了《实例化需求》13-17章。

这几章主要讲了几家上市公司的成功经验。它们有着许多相似之处。他们都是先改变流程。开始使用自动化可执行需求说明工具。但是有的公司并没有获得预期的效果。但是仍有一部分人相信这个实践。最后都收获很大。然后他们改善团队叫的协作。一开始他们给团队成员明确的分配相应的任务。但是这样并没有取得预期的效果。后来他们意识到是团队的工作分配出现了问题。于是他们给团队分配了端到端的任务。然后得到了不小的收获。

他们开始优化流程。之前他们用的可执行需求说明非常技术化,所以自动化层非常复杂且难以维护。然后他们每个角色都以fixure的形式在自动化层实现,并使用HTTP请求与服务器进行交互。测试结果就变得可靠多了。

时间: 2024-12-19 20:18:09

阅读《实例化需求》13-17章有感的相关文章

阅读《实例化需求》4-6章有感

今天我阅读了<实例化需求>的4-6章. 第4章主要讲的是如何着手改变过程和团队文化,以便你去实施实例化需求说明. 如何开始改变过程?首先在新项目中,我们应该将实例化需求说明当作更广阔的过程变更的一部分.其次团队应该专注于提高产品质量,而不是专注于某个特定过程.然后把功能测试自动化作为采用实例化需求说明的第一阶段并应用到现有项目.然后在测试人员负责测试自动化时, 需要引入一个可执行实例化需求分析说明的工具.最后当开发人员对测试驱动开发具有较深的认识的时候.我们可以使用测试驱动开发作为软件开发的垫

读《构建之法》第4,17章有感

读<构建之法>第4,17章有感 第四章:两人合作 原文:另外,注释(包括所有的源代码)应该只用ASCII字符,不要用中文或其他特殊字符,否则会极大地影响程序的可移植性. 我的问题和看法:对于英语水平没有那么高的人来说,不允许中文注释真的太难了.刚开始学习代码的时候,老师就教导我们编程的时候一定要写注释,但是并没有非常严格的要求我们必须要用ASCII字符.我上网查找了一些资料,发现大部分公司对于注释并没有明确的要求.注释是为了方便让别人理解你的代码的,所以简洁易懂应该才是最重要的,在水平达到的情

读13~17章 本学期最后一次

学期也快结束了,不知不觉就过了一个学期,这是最后一次阅读书本的最后几章,也是读最多章数的一次. 第13章: 这章讲的是测试,各种各样的测试,像测试的分类有着功能,非功能等.还可以按软件测试的时机或作用来分类使用等,就是说软件测试更为全面的检测软件,在最后一个阶段得知软件能否上市等.单元测试可以说是软件测试的基础,书本中也介绍了测试时需要的注重的哪些部分. 问题:对于这么多种的测试方法,怎么才能最有效的选取? 第14章: 这章讲的是质量的保障,例如软件的质量,程序的质量等. 要明白自己项目的特点,

CSS3秘笈第三版涵盖HTML5学习笔记13~17章

第13章,构建基于浮动的布局 使用的是float(浮动)属性 注:float:none值将取消所有浮动,通常只用来取消元素中已经应用的浮动. 切记:不需要给正文的div设计宽度,即使设计成固定宽度也不用 用浮动进行布局 LayoutGala网站(http://blog.html.it/layoutgala/)上提供了40种不同的CSS设计,但大多只是基本框架,里面只有<div>标签及其定位用的CSS代码 布局生成器,Cridinator(http://gridinator.com)提供了简单的

读《构建之法》第4、17章有感

    诗云:半亩方塘一鉴开,天光云影共徘徊.问渠哪得清如许?为有源头活水来. 这是宋代理学大家朱熹对阅读一本好书的感受.这几天我看了邹欣老师写的<构建之法>第4.17章之后,产生了一点点类似的感受.下面我来点评一下. 关于"第4章 两人合作"的点评: 问题一: 原文(见第68页):另外,注释(包括所有源代码)应该只用ASCII字符,不要用中文或其他特殊字符,否则会极大地影响程序的可移植性. 个人见解:可移植性是指代码在不同平台能否执行.注释会被执行吗?不会.那么,注释就与

阅读《构建之法》第13~17章及读《一个程序员的生命周期》感想

第十三章: 对于这章的测试,我们只是简单提了一下单元测试,其他测试都没有,这章相对来说,几乎为零,看了也不知道怎么做. 问题就更别说了,等周末有时间在回头看看,再更新补上问题. 第十四章: <一个程序员的生命周期>感想 一口气从第一篇的:从大山里走出的程序猿看到最后一篇:7年工作感悟,  很感谢他给我们分享他的经历,在一些方面看法也和作者有共鸣. 然而每个时代都并不容易,80后悲催,90后,00后都悲催,每个时代都有不同的困难,不只是单单只有一代人困难,有的人会自暴自弃,有 的人会迎刃而上,有

阅读13~17章

第十三章(P244) 问:集成测试该什么时候做才最合理? 第十四章(P268) 问:如何用CMMI衡量软件工程的质量?我还是不太理解CMMI. 第十五章(P293) 问:什么是事后的诸葛亮会议?书本没有给出明确解释. 第十六章(P300)  问:现在社会对创新越来越多,而且创新的东西也越来越多,我们该怎么把握创新的灵光? 第十七章(P339) 问:如何衡量个人在团队中的绩效?

阅读构建之法第一章有感

今天阅读了构建之法第一章,感觉到自己其实玩具的阶段都不到,离研究阶段更是差的有段距离.了解到程序其实只是一个藏在你电脑里的数据结构加算法,要想成为软件还得经历软件工程这一阶段,软件工程便是把系统的.有序的,可量化的方法应用到软件开发,运营和维护上的过程中.首先我要进行软件需求分析,一个成功的软件是要有市场需求作为背景的,没有需求你做的软件就是无用的东西,有了需求然后我们对软件进行设计使之安全 可行 基本满足市场的需求.然后我们便对我们的软件进行测试.最后软件在用户手中运行,但是十全十美的软件是不

《构建之法》13~17章

第十四章:问题:本章主要讲的是软件的质量和对软件质量的保障工作.而且开发过程的可见性有非常差.那么在我们接到一个项目时如果没有能力去完成它,是否放弃这个项目.但是没有挑战就没有进步,这其中如何选择?第十五章: 问题:文中(288)的例子中提到很多程序员都想在开发或是修改的时候加一些功能进去,但是这往往是不允许的,那么我们如何在这中间找平衡.即允许加进我们想加的东西? 第十六章: 问题:如今科技发达,社会进步快,相对一些科技技术更新也快.但是却很难在旧的领域有创新,而新的领域又很难开发.那么当我们