构建之法第13、14章学习

第十三章的内容是关于各种测试方法和测试的设计方法。

一个软件开发团队统一思想首先要从基本名词解释开始,第一节为我们解释了一些基本名词并进行分类(例:Bug是指软件的缺陷,可以分解为症状(Symptom)、程序错误(Fault)、根本原因(Root Cause));在对这些基本名词进行分类时,可以按测试设计的方法分类(分为黑箱和白箱),也可以按测试的目的(分为功能测试和非功能测试)或者测试的时机和作用分类。

在第二节中,详细介绍了各种测试方法——单元测试、代码覆盖率测试、构建验证测试、验收测试.....

第三节介绍了实战中的测试,实战中的测试是在项目的稳定阶段执行的。这一节为我们纠正了几个似是而非的测试观念;在测试工作的过程中,要写很多的文档——计划阶段的测试计划(Test Plan)、测试设计说明书(TDS)、测试用例(Test Case)、程序错误报告(Bug Report)和测试报告(Test Report)。

第四节向我们介绍了该如何运用测试工具。利用测试工具,我们可以记录手工测试、记录自动测试,还可以进行效能测试、负载测试、压力测试。

第五节向我们说明了在软件开发的不同阶段我们该做的测试工作并介绍了测试工作中可能遇到的一些问题。

第十四章的内容是关于软件的质量保障。

第一节说明了什么是软件的质量,根据国际标准组织最近的定义可知软件要符合用户以及利益相关者的需求,用一个公式表示就是:软件质量=程序质量+软件工程质量。其中,程序的质量体现在软件外在功能的质量:而软件工程方面的质量就与“快”“便宜”比较相关,它体现在软件开发过程中的可见性、风险控制、成本控制等等,软件工程的质量需要长期的过程来提高;衡量软件工程质量的一套比较成熟的理论是CMMI,它的实施能够提高企业的管理水平降低企业的成本,CMMI分为五个等级,每一个级别都是更高一级的基石;SWEBOK定义了软件质量成本,包括预防、评审、内部故障、外部故障,还有流程分析改进、投资改进等等,这些成本既有被动响应的,也有主动行动的。

第二节介绍的是软件质量保障工作的相关内容。软件的质量保障(QA)和软件测试(Testing)是有很大的区别的,但目前IT业界还是有很多人将它们混在一起。软件测试(Test)是指运用一定的流程和工具,验证软件能实现预先设计的功能和特性,工作的流程和结果通常是可量化的;软件质量保障(Quality Assurance)是指软件团队为了让软件达到事先定义的质量标准而进行的所有活动,包括测试工作。在本节当中,对“测试的角色要独立出来吗”进行了讨论,同时也介绍了和测试角色有关的一些问题。

时间: 2024-10-13 17:40:32

构建之法第13、14章学习的相关文章

《构建之法》第三章学习心得

这周我学习了<构建之法>第三章,讲述了软件工程师的成长.软件系统的绝大部分模块都是由个人开发或维护的.在软件工程的术语中,这些单个的成员叫做Individ-ual Contributor(IC).IC在团队中的流程是怎么样的呢?以开发人员为例,流程如下. 1.通过交流.实验.快速原型等方法,理解问题.需求或任务 2.提出多种解决办法并估计工作量 3.其中包括寻找以前的解决方案,因为很多工作是重复性的 与相关角色交流解决问题的提案,决定一个可行的方案 执行,把想法变成实际中能工作的代码,同时验证

《构建之法》13,14,15,16,17章读后感

1.13章说的是软件测试,怎么样去测试是最有效率的? 2.14章说到质量保障,具体的花费是多少? 3.15章说到ZBB,如果一个软件遇到了不可修复的bug,还算是一个稳定的软件么? 4.16章说到创新,有实际例子吗? 5.17章的职业道德指的是什么?

2018-2019-1 20189215 《构建之法》第三章学习总结

第3章 软件工程师的成长 教材学习内容总结 软件工程的术语中,单个的成员叫做Individual Contributor(IC). 软件开发流程不光指团队的流程,还包括个人开发流程,因为软件团队是由个人组成的,个人在团队中有独立的流程 IC在团队中的流程 通过交流.实验.快速原型等方法,理解问题.需求或任务 提出多种解决办法并估计工作量(其中包括寻找以前的解决方案,因为有很多工作是重复性的) 与相关角色交流解决问题的提案,决定一个可行的方案 执行,想法变成代码 合作,测试实现方案,修复BUG 发

《构建之法》第十三章学习总结

第十三章的内容是关于各种测试方法和测试的设计方法. 一个软件开发团队统一思想首先要从基本名词解释开始,第一节为我们解释了一些基本名词并进行分类(例:Bug是指软件的缺陷,可以分解为症状(Symptom).程序错误(Fault).根本原因(Root Cause)):在对这些基本名词进行分类时,可以按测试设计的方法分类(分为黑箱和白箱),也可以按测试的目的(分为功能测试和非功能测试)或者测试的时机和作用分类. 在第二节中,详细介绍了各种测试方法--单元测试.代码覆盖率测试.构建验证测试.验收测试..

《构建之法》13~17章

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

阅读《构建之法》13=1章

第十三章:软件测试 怎么样才能全方位的测试一个程序?又怎么样确定这个程序测试没有遗漏? 第十四章:质量保障 程序质量好,那么软件工程的质量有影响吗? 第十五章:稳定和发布阶段 推迟发布行不行? 第十六章 :IT行业的创新 有需要就有创新,如何创新? 第十七章:人,绩效和职业道德 一个人说:我在这工作了十年,有了十年的经验,我要加薪! 老板说:你只不过是一个经验用了十年而已! 怎么判断谁是正确的? 博客<连载<一个程序员的生命周期>17.最后的项目,抑郁了>读后感: 作为一个程序员,

《构建之法》第15章学习心得

软件开发过程是痛苦的,但是完成之后并不是就结束了.经历了计划.设计.开发等阶段,达到了代码完成这一目标之后,团队内部还要学会去发现修正已有的缺陷之后才发布.但是我觉得软件的隐藏bug会随着时间的延迟发掘出来更多的.在此之中,我们就需要构造一个会症小组,小组内部成员最好就包括了各个团队的一员,因为不清楚具体的缺陷会发生在哪一块地方,如果需要重写或重构的时候有具体版块负责人在会方便很多.除此之外,我觉得还能进行用户内测,选择一部分用户进行软件测试,之后进行问卷调查,整合问卷调查内容,总结缺点,进行软

读《构建之法》第四章 、第十七章

第四章    两人合作 通过对于<构建之法>第四章的阅读使我对代码规范 . 代码复审 . 以及结对编程有了更加深刻的认识,所谓代码规范可以分为两个部分,代码风格规范和代码设计规范,代码风格规范的原则是:简明 . 易读 . 无二义性,代码书写的形式,变量命名的方法,注释程序如何工作都有详细的介绍,令我受益颇多.代码设计规范不光是程序书写的格式问题,而且牵涉到咸亨需设计 . 模块之间的联系 . 设计模式等方方面面,函数的设计,语句的使用,错误的处理,这些都是我们在进行程序设计的时候需要注意的地方.

构建之法五、六章读后感

在本周我主要学习了构建之法的第五章和第六章,第五章主要讲述团队和流程,第六章主要讲述敏捷流程: 软件团队的模式有:主治医师模式.明星模式.社区模式.业余剧团模式.秘密团队.特工团队.交响乐团模式.爵士乐模式.功能团队模式.官僚模式: 开发流程包括:写了再改模式.瀑布模型.瀑布模型的变形(生鱼片模型.大瀑布带着小瀑布): Rational Unified Process统一流程(RUP):包括业务建模.需求.分析和设计.实现.测试.部署.配置和变更管理.项目管理.环境: RUP的四个阶段包括:初始

《构建之法》第四章读后感--软件工程

<构建之法>第四章读后感--两人合作 1.代码风格很重要,因为良好的代码风格,有益于两人的合作甚至多人的合作. 个人认为 : 良好的代码风格的培养就是 多去阅读别人的优秀代码 ,用于提高并且培养自己的代码风格. 2.关于结对编程的重要性 2.1 结对编程能提高设计质量与代码质量 2.2 结对有益于学习交流 3.如何结对编程 3.1 主动参与讨论,提出设计方案或者问题的解决方案 4.代码的复审 复审可以提高代码质量,优化项目性能.