软件工程估计错误总数的方法

1. 软件测试如何估计程序中的错误总数

解：
答案1:
(25+30-15)/(80%)=50
先算出两组发现的bug总数，再根据测试的2/8定律（即测试只能查到系统中80%的错误）
结果当然是50了

答案2:
设错误总数为X，那么甲发现错误的概率P(甲)为 25 / X，乙发现错误的概率P(乙)为 30 / X ，甲乙同时发现错误的概率P(同)为 15 / X 。
因为 P(甲)*P(乙)=P(同) ，所以(25 / X) * (30 / X) = 15 / X
计算而得X=50

2. 在excel表中我只知道一个总数 用什么方法能知道这个总数是哪几个的数相加的

这个属于最简单的条件规划求解，去看看这个
http://..com/question/98107620.html

3. 软件规模估算有哪些方法

现实中常见的软件成本估算方法包括经验法（专家法）、类推法，类比法、方程法，交叉验证法。除估算方法外，还需要估算数据库的支持才能继续度量分析，从而得出估算目标。估算数据基础可以是企业历史数据库，也可以是行业基准数据库。
《软件研发成本度量规范》中软件成本估算的思路分三步骤：规模估算、工作量估算、成本估算。

4. 软件工程中的数据定义怎么做

软件工程
软件工程一直以来都缺乏一个统一的定义，很多学者、组织机构都分别给出了自己的定义：

Boehm：运用现代科学技术知识来设计并构造计算机程序及为开发、运行和维护这些程序所必需的相关文件资料。

IEEE：软件工程是开发、运行、维护和修复软件的系统方法。

Fritz Bauer：建立并使用完善的工程化原则，以较经济的手段获得能在实际机器上有效运行的可靠软件的一系列方法。

软件工程(SoftWare Engineering)的框架可概括为：目标、过程和原则。

(1)软件工程目标：生产具有正确性、可用性以及开销合宜的产品。正确性指软件产品达到预期功能的程度。可用性指软件基本结构、实现及文档为用户可用的程度。开销合宜是指软件开发、运行的整个开销满足用户要求的程度。这些目标的实现不论在理论上还是在实践中均存在很多待解决的问题，它们形成了对过程、过程模型及工程方法选取的约束。

(2)软件工程过程：生产一个最终能满足需求且达到工程目标的软件产品所需要的步骤。软件工程过程主要包括开发过程、运作过程、维护过程。它们覆盖了需求、设计、实现、确认以及维护等活动。需求活动包括问题分析和需求分析。问题分析获取需求定义，又称软件需求规约。需求分析生成功能规约。设计活动一般包括概要设计和详细设计。概要设计建立整个软件系统结构，包括子系统、模块以及相关层次的说明、每一模块的接口定义。详细设计产生程序员可用的模块说明，包括每一模块中数据结构说明及加工描述。实现活动把设计结果转换为可执行的程序代码。确认活动贯穿于整个开发过程，实现完成后的确认，保证最终产品满足用户的要求。维护活动包括使用过程中的扩充、修改与完善。伴随以上过程，还有管理过程、支持过程、培训过程等。

(3)软件工程的原则是指围绕工程设计、工程支持以及工程管理在软件开发过程中必须遵循的原则。

软件工程必须遵循什么原则

围绕工程设计、工程支持以及工程管理已提出了以下四条基本原则：

(1)选取适宜的开发模型

该原则与系统设计有关。在系统设计中，软件需求、硬件需求以及其它因素间是相互制约和影响的，经常需要权衡。因此，必需认识需求定义的易变性，采用适当的开发模型，保证软件产品满足用户的要求。

(2)采用合适的设计方法

在软件设计中，通常需要考虑软件的模块化、抽象与信息隐蔽、局部化、一致性以及适应性等特征。合适的设计方法有助于这些特征的实现，以达到软件工程的目标。

(3)提供高质量的工程支撑

工欲善其事，必先利其器。在软件工程中，软件工具与环境对软件过程的支持颇为重要。软件工程项目的质量与开销直接取决于对软件工程所提供的支撑质量和效用。

(4)重视软件工程的管理

软件工程的管理直接影响可用资源的有效利用，生产满足目标的软件产品以及提高软件组织的生产能力等问题。因此，仅当软件过程予以有效管理时，才能实现有效的软件工程。

软件工程是指导计算机软件开发和维护的工程学科。

采用工程的概念、原理、 技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够 得到的最好的技术方法结合起来，这就是软件工程。

软件工程强调使用生存周期方法学和各种结构分析及结构设计技术。它们是

在七十年代为了对付应用软件日益增长的复杂程度、漫长的开发周期以及用户对

软件产品经常不满意的状况而发展起来的。人类解决复杂问题时普遍采用的一个策

略就是“各个击破”，也就是对问题进行分解然后再分别解决各个子问题的策略

。软件工程采用的生存周期方法学就是从时间角度对软件开发和维护的复杂问题

进行分解，把软件生存的漫长周期依次划分为若干个阶段，每个阶段有相对独立

的任务，然后逐步完成每个阶段的任务。采用软件工程方法论开发软件的时候，

从对任务的抽象逻辑分析开始，一个阶段一个阶段地进行开发。前一个阶段任务

的完成是开始进行后一个阶段工作的前提和基础，而后一阶段任务的完成通常是

使前一阶段提出的解法更进一步具体化，加进了更多的物理细节。每一个阶段的开

始和结束都有严格标准，对于任何两个相邻的阶段而言，前一阶段的结束标准就

是后一阶段的开始标准。在每一个阶段结束之前都必须进行正式严格的技术审查

和管理复审，从技术和管理两方面对这个阶段的开发成果进行检查，通过之后这

个阶段才算结束；如果检查通不过，则必须进行必要的返工，并且返工后还要再

经过审查。审查的一条主要标准就是每个阶段都应该交出“最新式的”（即和所

开发的软件完全一致的）高质量的文档资料，从而保证在软件开发工程结束时有

一个完整准确的软件配置交付使用。文档是通信的工具，它们清楚准确地说明了

到这个时候为止，关于该项工程已经知道了什么，同时确立了下一步工作的基础

。此外，文档也起备忘录的作用，如果文档不完整，那么一定是某些工作忘记做

了，在进入生存周期的下一阶段之前，必须补足这些遗漏的细节。在完成生存周

期每个阶段的任务时，应该采用适合该阶段任务特点的系统化的技术方法——结

构分析或结构设计技术。

把软件生存周期划分成若干个阶段，每个阶段的任务相对独立，而且比较简

单，便于不同人员分工协作，从而降低了整个软件开发工程的困难程度；在软件

生存周期的每个阶段都采用科学的管理技术和良好的技术方法，而且在每个阶段

结束之前都从技术和管理两个角度进行严格的审查，合格之后才开始下一阶段的

工作，这就使软件开发工程的全过程以一种有条不紊的方式进行，保证了软件的

质量，特别是提高了软件的可维护性。总之，采用软件工程方法论可以大大提高

软件开发的成功率，软件开发的生产率也能明显提高。

目前划分软件生存周期阶段的方法有许多种，软件规模、种类、开发方式、

开发环境以及开发时使用的方法论都影响软件生存周期阶段的划分。在划分软件

生存周期的阶段时应该遵循的一条基本原则就是使各阶段的任务彼此间尽可能相

对独立，同一阶段各项任务的性质尽可能相同，从而降低每个阶段任务的复杂程

度，简化不同阶段之间的联系，有利于软件开发工程的组织管理。一般说来，软

件生存周期由软件定义、软件开发和软件维护三个时期组成，每个时期又进一步

划分成若干个阶段。下面的论述主要针对应用软件，对系统软件也基本适用。

软件定义时期的任务是确定软件开发工程必须完成的总目标；确定工程的可行

性，导出实现工程目标应该采用的策略及系统必须完成的功能；估计完成该项工程

需要的资源和成本，并且制定工程进度表。这个时期的工作通常又称为系统分析

，由系统分析员负责完成。软件定义时期通常进一步划分成三个阶段，即问题定

义、可行性研究和需求分析。

开发时期具体设计和实现在前一个时期定义的软件，它通常由下述四个阶段组

成：总体设计，详细设计，编码和单元测试，综合测试。

维护时期的主要任务是使软件持久地满足用户的需要。具体地说，当软件在

使用过程中发现错误时应该加以改正；当环境改变时应该修改软件以适应新的环境

；当用户有新要求时应该及时改进软件满足用户的新需要。通常对维护时期不再

进一步划分阶段，但是每一次维护活动本质上都是一次压缩和简化了的定义和开

发过程。

下面扼要介绍软件生存周期每个阶段的基本任务和结束标准。

1问题定义

问题定义阶段必须回答的关键问题：“要解决的问题是什么？”如果不知道

问题是什么就试图解决这个问题，显然是盲目的，只会白白浪费时间和金钱，最

终得出的结果很可能是毫无意义的。尽管确切地定义问题的必要性是十分明显的

，但是在实践中它却可能是最容易被忽视的一个步骤。

通过问题定义阶段的工作，系统分析员应该提出关于问题性质、工程目标和

规模的书面报告。通过对系统的实际用户和使用部门负责人的访问调查，分析员

扼要地写出他对问题的理解，并在用户和使用部门负责人的会议上认真讨论这份

书面报告，澄清含糊不精的地方，改正理解不正确的地方，最后得出一份双方都

满意的文档。

问题定义阶段是软件生存周期中最简短的阶段，一般只需要一天甚至更少的

时间。

2可行性研究

这个阶段要回答的关键问题：“对于上一个阶段所确定的问题有行得通的解

决办法吗？”为了回答这个问题，系统分析员需要进行一次大大压缩和简化了的

系统分析和设计的过程，也就是在较抽象的高层次上进行的分析和设计的过程。

可行性研究应该比较简短，这个阶段的任务不是具体解决问题，而是研究问题的范

围，探索这个问题是否值得去解，是否有可行的解决办法。

在问题定义阶段提出的对工程目标和规模的报告通常比较含糊。可行性研究

阶段应该导出系统的高层逻辑模型（通常用数据流图表示），并且在此基础上更

准确、更具体地确定工程规模和目标。然后分析员更准确地估计系统的成本和效

益，对建议的系统进行仔细的成本／效益分析是这个阶段的主要任务之一。

可行性研究的结果是使用部门负责人做出是否继续进行这项工程的决定的

重要依据，一般说来，只有投资可能取得较大效益的那些工程项目才值得继续进

行下去。可行性研究以后的那些阶段将需要投入要多的人力物力。及时中止不值

得投资的工程项目，可以避免更大的浪费。

3需求分析

这个阶段的任务仍然不是具体地解决问题，而是准确地确定“为了解决这个问题，

目标系统必须做什么”，主要是确定目标系统必须具备哪些功能。

用户了解他们所面对的问题，知道必须做什么，但是通常不能完整准确地表

达出他们的要求，更不知道怎样利用计算机解决他们的问题；软件开发人员知道

怎样使用软件实现人们的要求，但是对特定用户的具体要求并不完全清楚。因此系统

分析员在需求分析阶段必须和用户密切配合，充分交流信息，以得出经过用户确

认的系统逻辑模型。通常用数据流图、数据字典和简要的算法描述表示系统的逻

辑模型。

在需求分析阶段确定的系统逻辑模型是以后设计和实现目标系统的基础，因

此必须准确完整地体现用户的要求。系统分析员通常都是计算机软件专家，技术

专家一般都喜欢很快着手进行具体设计，然而，一旦分析员开始谈论程序设计的

细节，就会脱离用户，使他们不能继续提出他们的要求和建议。较件工程使用的结

构分析设计的方法为每个阶段都规定了特定的结束标准，需求分析阶段必须提供完

整准确的系统逻辑模型，经过用户确认之后才能进入下一个阶段，这就可以有

效地防止和克服急于着手进行具体设计的倾向。

4总体设计

这个阶段必须回答的关键问题是：“概括地说，应该如何解决这个问题？”

首先，应该考虑几种可能的解决方案。列如，目标系统的一些主要功能是用

计算机自动完成还是用人工完成；如果使用计算机，那么是使用批处理方式还是

人机交互方式；信息存储使用传统的文件系统还是数据库……。通常至少应该考虑

下述几类可能的方案：

低成本的解决方案。系统只能完成最必要的工作，不能多做一点额处的工

作。

中等成本的解决方案。这样的系统不仅能够很好地完成预定的任务，使用

起来很方便，而且可能还具有用户没有具体指定的某些功能和特点。虽然用户没

有提出这些具体要求，但是系统分析员根据自己的知识和经验断定，这些附加的

能力在实践中将证明是很有价值的。

高成本的“十全十美”的系统。这样的系统具有用户可能希望有的所有功

能和特点。

系统分析员应该使用系统流程图或其他工具描述每种可能的系统，估计每种

方案的成本和效益，还应该在充分权衡各种方案的利弊的

5. 软件测试的方法一共有几种

1、从是否关心内部结构来看

（1）白盒测试：又称为结构测试或逻辑驱动测试，是一种按照程序内部逻辑结构和编码结构，设计测试数据并完成测试的一种测试方法。

（2）黑盒测试：又称为数据驱动测试，把测试对象当做看不见的黑盒，在完全不考虑程序内部结构和处理过程的情况下，测试者仅依据程序功能的需求规范考虑，确定测试用例和推断测试结果的正确性，它是站在使用软件或程序的角度，从输入数据与输出数据的对应关系出发进行的测试。

（3）灰盒测试：是一种综合测试法，它将“黑盒”测试与“白盒”测试结合在一起，是基于程序运行时的外部表现又结合内部逻辑结构来设计用例，执行程序并采集路径执行信息和外部用户接口结果的测试技术。

2、从是否执行代码看

（1）静态测试：指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。

(2)动态测试：是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率、正确性和健壮性等性能指标。

3、从开发过程级别看

（1）单元测试：又称模块测试，是针对软件设计的最小单位----程序模块或功能模块，进行正确性检验的测试工作。其目的在于检验程序各模块是否存在各种差错，是否能正确地实现了其功能，满足其性能和接口要求。

(2)集成测试：又叫组装测试或联合，是单元测试的多级扩展，是在单元测试的基础上进行的一种有序测试。旨在检验软件单元之间的接口关系，以期望通过测试发现各软件单元接口之间存在的问题，最终把经过测试的单元组成符合设计要求的软件。

（3）系统测试：是为判断系统是否符合要求而对集成的软、硬件系统进行的测试活动、它是将已经集成好的软件系统，作为基于整个计算机系统的一个元素，与计算机硬件、外设、某些支持软件、人员、数据等其他系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列的组装测试和确认测试。

在系统测试中，对于具体的测试类型有：

（1）功能测试：对软件需求规格说明书中的功能需求逐项进行的测试，以验证功能是否满足要求。

（2）性能测试：对软件需求规格说明书的功能需求逐项进行的测试，以验证功能是否满足要求。

（3）接口测试：对软件需求规格说明中的接口需求逐项进行的测试。

（4）人机交互界面测试：对所有人机交互界面提供的操作和显示界面进行的测试，以检验是否满足用户的需求。

（5）强度测试：强制软件运行在异常乃至发生故障的情况下（设计的极限状态到超出极限），验证软件可以运行到何种程序的测试。

（6）余量测试：对软件是否达到规格说明中要求的余量的测试。

（7）安全性测试：检验软件中已存在的安全性、安全保密性措施是否有效的测试，

（8）可靠性测试：在真实的或仿真的环境中，为做出软件可靠性估计而对软件进行的功能（其输入覆盖和环境覆盖一般大于普通的功能测试）

（9）恢复性测试：对有恢复或重置功能的软件的每一类导致恢复或重置的情况，逐一进行的测试。

（10）边界测试：对软件处在边界或端点情况下运行状态的测试。

（11）数据处理测试：对完成专门数据处理功能所进行的测试。

（12）安装性测试：对安装过程是否符合安装规程的测试，以发现安装过程中的错误。

（13）容量测试：检验软件的能力最高能达到什么程度的测试。

（14）互操作性测试：为验证不同软件之间的互操作能力而进行的测试。

（15）敏感性测试：为发现在有效输入类中可能引起某种不稳定性或不正常处理的某些数据的组合而进行的测试。

（16）标准符合性测试：验证软件与相关国家标准或规范（如军用标准、国家标准、行业标准及国际标准）一致性的测试。

（17）兼容性测试：验证软件在规定条件下与若干个实体共同使用或实现数据格式转换时能满足有关要求能力的测试。

（18）中文本地化测试：验证软件在不降低原有能力的条件下，处理中文能力的测试。

4、从执行过程是否需要人工干预来看

（1）手工测试：就是测试人员按照事先为覆盖被测软件需求而编写的测试用例，根据测试大纲中所描述的测试步骤和方法，手工地一个一个地输 入执行，包括与被测软件进行交互（如输入测试数据、记录测试结果等），然后观察测试结果，看被测程序是否存在问题，或在执行过程中是否会有一场发生，属于比较原始但是必须执行的一个步骤。

（2）自动化测试：实际上是将大量的重复性的测试工作交给计算机去完成，通常是使用自动化测试工具来模拟手动测试步骤，执行用某种程序设计语言编写的过程（全自动测试就是指在自动测试过程中，不需要人工干预，由程序自动完成测试的全过程；半自动测试就是指在自动测试过程中，需要手动输入测试用例或选择测试路径，再由自动测试程序按照人工指定的要求完成自动测试）

5、从测试实施组织看

（1）开发测试：开发人员进行的测试

（2）用户测试：用户方进行的测试

（3）第三方测试：有别于开发人员或用户进行的测试，由专业的第三方承担的测试，目的是为了保证测试工作的客观性

6、从测试所处的环境看

（1）阿尔法测试：是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试

（2）贝塔测试：是用户公司组织各方面的典型终端用户在日常工作中实际使用贝塔版本，并要求用户报告

(5)软件工程估计错误总数的方法扩展阅读

软件测试的内容：

1 得到需求、功能设计、内部设计说书和其他必要的文档

2 得到预算和进度要求

3 确定与项目有关的人员和他们的责任、对报告的要求、所需的标准和过程 ( 例如发行过程、变更过程、等等 )

4 确定应用软件的高风险范围，建立优先级、确定测试所涉及的范围和限制

5 确定测试的步骤和方法 ── 部件、集成、功能、系统、负载、可用性等各种测试

6 确定对测试环境的要求 ( 硬件、软件、通信等 )

7 确定所需的测试用具 (testware) ，包括记录 / 回放工具、覆盖分析、测试跟踪、问题 / 错误跟踪、等等

8 确定对测试的输入数据的要求

9 分配任务和任务负责人，以及所需的劳动力

10 设立大致的时间表、期限、和里程碑

11 确定输入环境的类别、边界值分析、错误类别

12 准备测试计划文件和对计划进行必要的回顾

13 准备白盒测试案例

14 对测试案例进行必要的回顾 / 调查 / 计划

15 准备测试环境和测试用具，得到必需的用户手册 / 参考文件 / 结构指南 / 安装指南，建立测试跟踪过程，建立日志和档案、建立或得到测试输入数据

16 得到并安装软件版本

17 进行测试

18 评估和报告结果

19 跟踪问题 / 错误，并解决它

20 如果有必要，重新进行测试

21 在整个生命周期里维护和修改测试计划、测试案例、测试环境、和测试用具

6. 软件工程的题请帮忙坐下

CCCDC DBADB第4题不太确定