GroupBlog

软件工程是指导计算机软件开发和维护的工程学科。采用工程的概念、原理、技术和方法来开发和维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来，以经济地开发出高质量的软件并有效地维护它，这就是软件工程。
软件工程是研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件，以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来的学科。

软件工程与计算机科学有什么不同？

1、计算机科学与技术：涉及大数据技术导论、数据采集与处理实践（Python）、Web前/后端开发、统计与数据分析、机器学习、高级数据库系统、数据可视化、云计算技术、人工智能、自然语言处理、媒体大数据案例分析、网络空间安全、计算机网络、数据结构、软件工程、操作系统等方面

2、软件工程：涉及程序设计语言、数据库、软件开发工具、系统平台、标准、设计模式等方面。

二、软硬件不同

1、计算机科学与技术：既有软件技术，也包括硬件技术。

2、软件工程：偏向软件技术。

三、就业领域不同

1、计算机科学与技术：主要就业领域是从事网络工程领域的设计、维护等工作和软件信息技术领域的技术开发、教学、科研及管理等工作。

2、软件工程：主要就业领域是软件信息技术领域的技术开发工作和金融领域的经济管理工作。

软件的生命周期

一个软件从定义，使用，开发，维护，直到最终被废弃为止的整个过程。

软件生命周期方法学

基本思想：从时间角度对软件开发和维护的复杂问题进行分解，把软件生命的漫长周期依次分为若干个阶段，每个阶段有相对独立的任务，然后逐步完成每个阶段的任务。
前阶段任务的完成是后阶段工作开始的前提与基础，后阶段任务是前阶段的具体与细化。
优点：各阶段任务相对独立，便于分工协作，降低开发工作的难度，便于科学组织与管理；保证了产品的质量，提高了可维护性。

软件工程的基本原理

用分阶段的生命周期计划严格管理

这一条是吸取前人的教训而提出来的。统计表明，50%以上的失败项目是由于计划不周而造成的。在软件开发与维护的漫长生命周期中，需要完成许多性质各异的工作。这条原理意味着，应该把软件生命周期分成若干阶段，并相应制定出切实可行的计划，然后严格按照计划对软件的开发和维护进行管理。 Boehm 认为，在整个软件生命周期中应指定并严格执行6类计划：项目概要计划、里程碑计划、项目控制计划、产品控制计划、验证计划、运行维护计划。

坚持进行阶段评审

统计结果显示：大部分错误是在编码之前造成的，大约占63%; <2> 错误发现的越晚，改正它要付出的代价就越大，要差2到3个数量级。因此，软件的质量保证工作不能等到编码结束之后再进行，应坚持进行严格的阶段评审，以便尽早发现错误。

实行严格的产品控制

开发人员最痛恨的事情之一就是改动需求。但是实践告诉我们，需求的改动往往是不可避免的。这就要求我们要采用科学的产品控制技术来顺应这种要求。也就是要采用变动控制，又叫基准配置管理。当需求变动时，其它各个阶段的文档或代码随之相应变动，以保证软件的一致性。

采纳现代程序设计技术

从六、七时年代的结构化软件开发技术，到最近的面向对象技术，从第一、第二代语言，到第四代语言，人们已经充分认识到：方法大似气力。采用先进的技术即可以提高软件开发的效率，又可以减少软件维护的成本。

结果应能清楚地审查

软件是一种看不见、摸不着的逻辑产品。软件开发小组的工作进展情况可见性差，难于评价和管理。为更好地进行管理，应根据软件开发的总目标及完成期限，尽量明确地规定开发小组的责任和产品标准，从而使所得到的标准能清楚地审查。

开发小组的人员应少而精

开发人员的素质和数量是影响软件质量和开发效率的重要因素，应该少而精。这一条基于两点原因：高素质开发人员的效率比低素质开发人员的效率要高几倍到几十倍，开发工作中犯的错误也要少的多；当开发小组为N人时，可能的通讯信道为N(N-1)/2, 可见随着人数N的增大，通讯开销将急剧增大。

承认不断改进软件工程实践的必要性

遵从上述六条基本原理，就能够较好地实现软件的工程化生产。但是，它们只是对现有的经验的总结和归纳，并不能保证赶上技术不断前进发展的步伐。因此，Boehm提出应把承认不断改进软件工程实践的必要性作为软件工程的第七条原理。根据这条原理，不仅要积极采纳新的软件开发技术，还要注意不断总结经验，收集进度和消耗等数据，进行出错类型和问题报告统计。这些数据既可以用来评估新的软件技术的效果，也可以用来指明必须着重注意的问题和应该优先进行研究的工具和技术。

软件的伦理道德

公众感：软件工程师要始终与公众利益一致。
客户&雇主：软件工程师要在与公众利益一致的情况下保证雇主和公众的最大利益。
产品：软件工程师要保证其产品即相关组件达到尽可能高的行为标准。
判断力：软件工程师要具备公正独立的职业判断力。
管理：软件工程管理者和领导者应当维护并提倡合乎道德的软件的管理方法。
职业感：软件工程师要弘扬正义感和荣誉感，维护公众利益。
同事：软件工程师要公平的对待和协助每一位同事。
个人：软件工程师应当毕生学习专业知识，倡导合乎职业道德的职业方式。

2. 软件的过程

软件过程活动

在这里插入图片描述

软件过程模型的概念

软件过程模型（software process model）是软件开发全部过程，活动和任务的结构框架，它能直观表达软件开发全过程，明确规定要完成的主要活动，任务和开发策略。

瀑布模型（waterful model）

优点：

为项目提供了按阶段划分的检查点。
当前一阶段完成后，您只需要去关注后续阶段。
可在迭代模型中应用瀑布模型。

缺点：

不适应需求变化，只能用于需求不改变或很少改变的场合。
最终才可以见到可执行系统，风险较大。
“瀑布模型是由文档驱动的“这个事实也是它的一个主要缺点。在可运行的软件产品交付给用户之前，用户只能通过文档来了解产品是什么样的。要求用户不经过实践就提出完整准确的需求，在许多情况下都是不切实际的。总之，由于瀑布模型几乎完全依赖于书面的规格说明，很可能导致最终开发出的软件产品不能真正满足用户的需要。

增量模型（Increment Model）

在大型软件开发中存在着很多的不确定因素，需求的变更不可避免，所以积极应对变更对于一个软件过程模型来说尤为重要。

先完成一个系统子集的开发，再按同样的开发步骤增加功能（系统子集），如此递增下去直至满足全部的系统需求。

在这里插入图片描述

优点：

软件逐次交付，每次增量交付过程中获取的经验，有利于后面的改进，客户也有机会对建立好的模型作出反应。
用户可以更好的获得收益。
核心功能先被开发，降低了项目失败的可能性。
风险分布到几个更小的增量中，而不是集中于一个大型开发中。

缺点：

系统体系结构非常重要，需要良好的可扩展性架构设计，这是增量开发成功的基础。

原型模型（Prototype Model）

原型模型是一个软件系统的初期版本，用于展示概念，验证设计方案，发现存在的问题和寻找可能的解决方法。
在这里插入图片描述

克服了瀑布模型的缺点，使它更好的满足用户并减少由于需求不明确带来的项目风险；
适合预先不能确切定义需求的软件系统的开发。
不适合开发大型的软件系统，只适合开发小型的
前提是要有一个展示性的原型，因此在一定程度上限制了开发人员的创新。

螺旋模型（spiral model）

优点
对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标。
减少了过多测试（浪费资金）或测试不足（产品故障多）所带来的风险。
在螺旋模型中维护只是模型的另一个周期，在维护和开发之间并没有本质区别。

缺点

采用螺旋模型需要具有相当丰富的风险评估经验和专门知识，在风险较大的项目开发中，如果未能够及时标识风险，势必造成重大损失。
过多的迭代次数会增加开发成本，延迟提交时间。

RUP的基本策略与特点

RUP（Rational Unified Process，统一软件开发过程）

在这里插入图片描述

敏捷开发

传统的开发方法有详细的项目规划，受控的过程管理和严格的质量保证，在规划，设计及文档编写方面投入句法，适合大型，长寿命周期的软件开发，无法满足中小型软件的开发需要。

敏捷开发适合系统需求在开发过程中快速变化的应用类型。

敏捷开发基本原则：

我们的最高目标是通过尽早和持续第交付有价值的软件来满足客户。
欢迎对需求提出变更 - 即使在项目开发后期，要善于利用需求变更，帮助客户获得竞争优势。
要不断交付可用的软件，周期从几周到几个月不等，越短越好。
项目过程中，业务人员与开发人员必须在一起。
要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。
无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。
可用的软件是衡量进度的主要指标。
敏捷过程提倡可持续的开发，项目方，开发人员和用户应该能够保持恒久稳定的进展速度。
对技术的精益求精以及对设计的不断完善将提升敏捷性。
要做到简洁，尽可能减少不必要的工作，这是一门艺术。
最佳的架构，需求和设计出自于自组织的团队。
团队要定期反省如何能够做到更有效，并相应调整团队的行为。

在这里插入图片描述

极限编程（XP Extreme Programming， Kent Beck 2000）

极限编程是目前最为流行的敏捷开发方法。该方法推行最佳工程实践，如迭代式开发，结对编程，测试驱动开发等，致力于积极响应用户需求变化，并能高效率的开发出高质量软件。XP适合于小团队开发。

XP是一个轻量级的、灵巧的软件开发方法；同时它也是一个非常严谨和周密的方法。它的基础和价值观是交流、朴素、反馈和勇气；即，任何一个软件项目都可以从四个方面入手进行改善：加强交流；从简单做起；寻求反馈；勇于实事求是。XP是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期；通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。

具体可以点击这里–>极限编程

结对编程

两个程序员在一个计算机上共同工作。一个人输入代码，而另一个人审查他输入的每一行代码。且角色一直互换。
项目开发中会不断的更换合作伙伴。

优点：

编码，设计和测试至少被另外一个人检查过，代码，设计和测试的质量提高。
增强了彼此之间的沟通。

测试团队和开发团队是否应该处在一个团队中，应该是怎样一种管理结构？

不应该，软件的成功不仅需要开发人员的设计和实现。而且还需要测试人员去做测试找出bug，避免在用户使用时出现较多错误，影响用户体验度。在一个团队中，大家均是为了完成这个软件，难免会有漏洞，只有独立开，专以找出软件的漏洞为职责，才能更好地修复软件。

3. 软件需求

软件需求是待开发系统特征的描述，即提供的服务及运行时满足的约束条件。

可行性研究

可行性研究的主要任务是”了解客户的要求及现实环境，从技术，经济和社会因素等三方面研究并论证本软件项目的可行性，编写可行性研究报告，制定初步项目的开发计划。“

技术可行性：对待开发的项目的功能，性能和限制条件进行分析，确认现有的资源（硬件，软件，技术人员水平，已有的工作基础）条件下，项目能否实现。
经济可行性：对待开发的项目的开发成本与预期收益进行评估，确定该项目是否值得去投资开发。考虑的问题主要是成本和效益的估算。
社会可行性：待开发项目是否存在着违反法律的（合同，责任，侵权）的潜在因素以及待开发的项目在用户组织内是否行的通，现有的管理体制，人员素质和操作方式是否可行。

在这里插入图片描述

需求工程概述

清楚的理解用户要解决的问题，完整准确的获取用户的需求，并用《软件需求规格说明书》规范的形式准确的表达用户的想法。

所面临的挑战是：

问题空间理解。
人与人之间的通信。
需求的不断变化。

需求工程对人员的要求：

概括能力，分析能力和社交能力。
一定的软，硬件系统开发经验。
能理解用户提出的要求。
善于在用户和软件开发机构之间进行良好的通讯。

在这个阶段，重要的是什么，而不是怎么做。

需求工程有三个层次：

业务需求 Business Requirements：描述了企业对项目的高层次目标，从宏观上描述开发系统的必要性，意义和目标。
用户需求 User Requirements：描述了用户对于系统的期望和目标，即用户要让系统做什么，产生什么样的业务价值，这是需求获取阶段的产物。具有离散型（用户从不同角度，不同层面，不同粒度提出需求）和矛盾性（用户处于不同的工作岗位，难免有局限性和矛盾性）的特点。
系统需求：描述软件产品要实现的软件服务以及需要满足的约束条件。用户利用这些服务来完成工作任务，满足业务需求。这是需求分析和建模的产物，对UR进行分析得到。

需求规约与建模（Requirements specification）

在需求文档中撰写用户需求与系统需求的过程，需求要求具有清晰性，明确性，易读性，完整性和一致性的特点。

用户需求：从用户角度描述体统功能及非需求功能，只涉及外部功能，不涉及内部设计，用自然语言及图形描述。
系统需求：如何让系统满足用户的需求，是系统的一个完备，详尽的描述，也是系统设计的起点。

基本步骤如下：
在这里插入图片描述

需求的获取

目标：完整的获取系统必须提供的服务，以及需要满足的约束条件。

主要方法：

用户访谈。
用户调查（针对于无法访谈的涉众，发放调查问卷进行需求获取）。
参与，观察业务流程。
情景串联（结合原型/ppt等方法展示业务处理场景和流程）。
现有的产品和竞争对手文档（取长补短）。

需求分析

对需求获取得到的用户第一手需求资料进行综合整理分析，从而得到系统需求的过程。

主要任务：

建立系统用例模型。
业务流程分析。
编制用例说明。
查询报表分析。
非功能需求分析。

需求验证与确认

需求验证：检测需求是否正确，完备和一致，且为后续设计开发和测试提供了足够的基础。
需求确认：确认建立的需求正确的反映了用户对软件的要求，通常由软件公司和客户共同完成。

主要方法：

快速原型。
需求评审。

讨论快速原型与需求评审

在这里插入图片描述
快速原型是建造一个模型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么。快速原型模型需要迅速建造一个可以运行的软件原型，以便理解和澄清问题，使开发人员与用户达成共识，最终在确定的客户需求基础上开发客户满意的软件产品。快速原型模型允许在需求分析阶段对软件的需求进行初步而非完全的分析和定义，快速设计开发出软件系统的原型，该原型向用户展示待开发软件的全部或部分功能和性能；用户对该原型进行测试评定，给出具体改进意见以丰富细化软件需求；开发人员据此对软件进行修改完善，直至用户满意认可之后，进行软件的完整实现及测试、维护。

在这里插入图片描述

需求管理

组织记录软件需求，控制变更，并确保软件开发与软件需求一致的一系列方法与活动。

需求标识
建立基线
变更控制
需求追踪

4. 面向对象范型

耦合是影响软件复杂程度和设计质量的一个重要因素，为提高模块的独立性，应建立模块间尽可能松散的系统，在设计上我们应采用以下原则：若模块间必须存在耦合，应尽量使用数据耦合，少用控制耦合，慎用或有控制地使用公共耦合，并限制公共耦合的范围，尽量避免内容耦合。

内聚有如下的种类，它们之间的内聚度由弱到强排列如下：
（1） 偶然内聚：一个模块内的各处理元素之间没有任何联系，只是偶然地被凑到一起。这种模块也称为巧合内聚，内聚程度最低。
（2） 逻辑内聚：这种模块把几种相关的功能组合在一起，每次被调用时，由传送给模块参数来确定该模块应完成哪一种功能。
（3） 时间内聚：把需要同时执行的动作组合在一起形成的模块称为时间内聚模块。
（4） 过程内聚：构件或者操作的组合方式是，允许在调用前面的构件或操作之后，马上调用后面的构件或操作，即使两者之间没有数据进行传递。简单的说就是如果一个模块内的处理元素是相关的，而且必须以特定次序执行则称为过程内聚。
（5） 通信内聚：指模块内所有处理元素都在同一个数据结构上操作或所有处理功能都通过公用数据而发生关联（有时称之为信息内聚）。即指模块内各个组成部分都使用相同的数据数据或产生相同的数据结构。
（6） 顺序内聚：一个模块中各个处理元素和同一个功能密切相关，而且这些处理必须顺序执行，通常前一个处理元素的输出时后一个处理元素的输入。
（7） 功能内聚：模块内所有元素的各个组成部分全部都为完成同一个功能而存在，共同完成一个单一的功能，模块已不可再分。即模块仅包括为完成某个功能所必须的所有成分，这些成分紧密联系、缺一不可。

对于低耦合，粗浅的理解是:一个完整的系统，模块与模块之间，尽可能的使其独立存在。也就是说，让每个模块，尽可能的独立完成某个特定的子功能。模块与模块之间的接口，尽量的少而简单。如果某两个模块间的关系比较复杂的话，最好首先考虑进一步的模块划分。这样有利于修改和组合。

软件架构设计的目的简单说就是在保持软件内在联系的前提下，分解软件系统，降低软件系统开发的复杂性，而分解软件系统的基本方法无外乎分层和分割。但是在保持软件内在联系的前提下，如何分层分割系统，分层分割到什么样的程度，并不是一件容易的事，这方面有各种各样的分解方法，比如:关注点分离，面向方面，面向对象，面向接口，面向服务，依赖注入，以及各种各样的设计原则等。

耦合可以分为以下几种，它们之间的耦合度由高到低排列如下:

(1) 内容耦合:一个模块直接访问另一模块的内容，则称这两个模块为内容耦合。

若在程序中出现下列情况之一，则说明两个模块之间发生了内容耦合:

一个模块直接访问另一个模块的内部数据。
一个模块不通过正常入口而直接转入到另一个模块的内部。
两个模块有一部分代码重叠(该部分代码具有一定的独立功能)。
一个模块有多个入口。

内容耦合可能在汇编语言中出现。大多数高级语言都已设计成不允许出现内容耦合。这种耦合的耦合性最强，模块独立性最弱。

(2) 公共耦合:一组模块都访问同一个全局数据结构，则称之为公共耦合。公共数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等。如果模块只是向公共数据环境输入数据，或是只从公共数据环境取出数据，这属于比较松散的公共耦合;如果模块既向公共数据环境输入数据又从公共数据环境取出数据，这属于较紧密的公共耦合。

公共耦合会引起以下问题:

无法控制各个模块对公共数据的存取，严重影响了软件模块的可靠性和适应性。
使软件的可维护性变差。若一个模块修改了公共数据，则会影响相关模块。
降低了软件的可理解性。不容易清楚知道哪些数据被哪些模块所共享，排错困难。

一般地，仅当模块间共享的数据很多且通过参数传递很不方便时，才使用公共耦合。

(3) 外部耦合:一组模块都访问同一全局简单变量，而且不通过参数表传递该全局变量的信息，则称之为外部耦合。

(4) 控制耦合:模块之间传递的不是数据信息，而是控制信息例如标志、开关量等，一个模块控制了另一个模块的功能。

(5) 标记耦合:调用模块和被调用模块之间传递数据结构而不是简单数据，同时也称作特征耦合。标记耦合的模块间传递的不是简单变量，而是像高级语言中的数据名、记录名和文件名等数据结果，这些名字即为标记，其实传递的是地址。

(6) 数据耦合:调用模块和被调用模块之间只传递简单的数据项参数。相当于高级语言中的值传递。

讨论面向对象范型

面向对象范型主要是基于将数据和操作绑定到一起;，或者说形成对象, 利用对象来绑定操作。要点如下：面向对

（1）面向对象的软件系统是由对象组成的，软件中的任何元素都是对象，复杂的软件对象由简单的软件对象组合而成。

（2）所有对象划分成各种对象类，每个对象都定义了一组数据和一组方法。

（3）按照子类（派生类）和父类（基类）的关系，把若干个对象类组成一个层次结构的系统（类等级）。在派生类中对某些特性又做了重新描述，则在派生类中的这些特性将以新描述为准，也就是说，低层的特性将屏蔽高层的同名特性。

（4）对象彼此之间仅能通过传递消息互相联系。

面向对象的特点：对象对自己负责；找到变化并封装之；优先使用对象聚集，而不是类继承：相比这下，继承类需要深入了解父类，有可能带来冗余和职责不清的问题。针对接口编程，而不是实现；相同功能下，减少了代码的数量，也减少了出错的机率。代码越少，问题越少。约定优于配置。

UML（Unified Modeling Language 统一建模语言）

在这里插入图片描述

讨论用例图（case diagram）

用例图是指由参与者（Actor）、用例（Use Case），边界以及它们之间的关系构成的用于描述系统功能的视图。用例图（User Case）是外部用户（被称为参与者）所能观察到的系统功能的模型图。用例图是系统的蓝图。用例图呈现了一些参与者，一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。

一个类可能有多于一个状态图？

状态图用来描述一个特定的对象所有可能的状态,以及由于各种事件的发生而引起的状态之间的转移和变化。

并不是所有的类都需要画状态图，有明确意义的状态，在不同状态下行为有所不同的类才需要画状态图。

5. 软件生命周期

你认为哪种软件生命周期模型最好？为什么？

要根据情况而决定，不同情况使用不同的模型。目前有瀑布模型、快速原型模型、增量模型、螺旋模型

瀑布模型，也称软件生存周期模型。
优点：（1）在软件工程中占有重要地位，它提供了软件开发的基本框架，这比依靠“个人技艺”开发软件好得多。（2）有利于大型软件开发过程中人员的组织、管理，有利于软件开发方法和工具的研究与使用，从而提高了大型软件项目开发的质量和效率。
缺点：（1）阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；（2）由于开发模型是线性的用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险；（3）早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重后果。适用：（1）在开发时间内需求没有或很少变化；（2）分析设计人员应对应用领域很熟悉；（3）低风险项目（对目标、环境很熟悉）；（4）用户使用环境很稳定；用户除提出需求以外，很少参与开发工作。
快速原型模型
优点：（1）可以得到比较良好的需求定义，容易适应需求的变化；（2）有利于开发与培训的同步；（3）开发费用低、开发周期短且对用户更友好。
缺点：（1）客户与开发者对原型理解不同；（2）准确的原型设计比较困难；（3）不利于开发人员的创新。适用：（1）对所开发的领域比较熟悉而且有快速的原型开发工具；（2）项目招投标时，可以以原型模型作为软件的开发模型；（3）进行产品移植或升级时，或对已有产品原型进行客户化工作时，原型模型是非常适合的。
增量模型
优点：（1）采用增量模型的优点是人员分配灵活，刚开始不用投入大量人力资源；（2）如果核心产品很受欢迎，则可增加人力实现下一个增量；（3）可先发布部分功能给客户，对客户起到镇静剂的作用。
缺点：（1）并行开发构件有可能遇到不能集成的风险，软件必须具备开放式的体系结构；（2）增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软件过程的控制失去整体性。适用：（1）进行已有产品升级或新版本开发，增量模型是非常适合的；（2）对完成期限严格要求的产品，可以使用增量模型；（3）对所开发的领域比较熟悉而且已有原型系统，增量模型也是非常适合的。
螺旋模型
优点：（1）设计上的灵活性,可以在项目的各个阶段进行变更；（2）以小的分段来构建大型系统,使成本计算变得简单容易；（3）客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性；（4）随着项目推进,客户始终掌握项目的最新信息 , 从而他或她能够和管理层有效地交互。
缺点：（1）采用螺旋模型需要具有相当丰富的风险评估经验和专门知识，在风险较大的项目开发中，如果未能够及时标识风险，势必造成重大损失；（2）过多的迭代次数会增加开发成本，延迟提交时间。适用：只适合于大规模的软件项目

6. 软件测试

软件测试是保证软件质量，提高软件可靠性的关键。

狭义的软件测试定义：为发现软件缺陷而执行程序或系统的过程

广义的软件测试定义：人工或自动地运行或测定某系统的过程，目的在于检验它是否满足规定的需求或弄清预期结果和实际结果间的差别

为什么要做软件测试？

发现软件缺陷
- 功能错
- 功能遗漏
- 超出需求部分（画蛇添足）
- 性能不符合要求
软件质量高低：是否符合用户习惯、符合用户需求

测试的任务

找出
定位
修改
修改后要做回归测试，对已修改的部分进行再次的测试，避免引入新的错误

软件测试原则

软件测试的原则

所有的测试都应追溯到用户的需求
尽早地和不断地进行软件测试（缺陷具有放大的特点，测试成本随阶段深入而上升）
8-2原则
- 测试中发现的错误80%很可能起源于程序中的20%
- 提前测试可发现80%，系统测试找出剩余bug的80%（总体的16%），最后的4%可能只有用户大范围长时间使用后才暴露出来
- 80%的工程用在20%的需求上（即关键需求）
软件缺陷的寄生虫性：找到的缺陷越多说明软件遗留的缺陷越多
避免自己测试自己的程序
回归测试：避免引入新的错误