1.4软件测试<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
对源程序最基本的质量要求是正确性和可靠性，此外还很注重软件的易使用性、易维护性和易移植性。软件测试的工作量约占软件开发总工作量的40%以上，其目的是尽可能多的发现软件产品（主要是指程序）中的错误和缺陷。
软件测试是自底向上，逐步集成的过程，低一级测试为上一级测试准备条件；
测试的关键是测试用例的设计，其方法可分为两类。
白盒测试：
白盒测试是根据程序的内部逻辑来设计测试用例，常用的技术是逻辑覆盖，即考察用例测试数据运行被测程序时对程序逻辑的覆盖程度。主要的覆盖标准有6种：
<?xml:namespace prefix = st1 ns = "urn:schemas-microsoft-com:office:smarttags" />I. 语句覆盖
指选择足够的测试用例，使被测语句的每个语句至少执行一次。
II.判定覆盖
指选择足够的测试用例，使每个判定的所有可能结果至少出现一次。
III.条件覆盖
指选择足够的测试用例，使判定中的每个条件的所有可能结果至少出现一次。
IV. 判定/条件覆盖
指选择足够的测试用例，使判定中的每个条件的所有可能结果至少出现一次，并且每个判定中条件结果的所有可能组合也至少出现一次。
V. 条件组合覆盖
指选择足够的测试用例，使每个判定中条件结果的所有可能组合至少出现一次。
VI. 路径覆盖
指选择足够的测试用例，使流程图中的每条路径至少经过一次。
黑盒测试：
黑盒测试时根据规格说明所规定的功能来设计测试用例，它不考虑程序的内部结构和处理过程。常用的黑盒测试技术有：
Ø 等价类划分
Ø 边值划分
Ø 错误猜测
软件测试的主要步骤有单元测试、集成测试和确认测试。
单元测试：
主要用来发现编码和详细设计中产生的错误，一般在编码阶段，采用白盒测试。
集成测试（也称组装测试）：
主要用来发现设计阶段产生的错误，是对各模块组装而成的程序进行测试，主要检查模块间的接口和通信，采用黑盒测试。
集成测试按集成方式又可分成非渐增式集成和渐增式集成，而渐增式集成又可分成自顶向下集成和自底向上集成。
确认测试：
检查软件的功能、性能和其他特征是否与用户需求一致，它以需求规格说明书作测试为依据，采用黑盒测试
Alpha测试是在开发者的现场由客户来实施的，从用户角度和环境下进行；
Beta测试是在开发者不在现场下测试，由软件最终用户实施；
使用各种测试方法的综合策略：
n 在任何情况下都必须使用边界值分析方法，用这种方法设计出测试用例发现程序错误的能力最强；
n 必要时用等价类划分方法补充一些测试用例；
n 用错误推测法再追加一些测试用例
n 对照程序逻辑，检查已有测试用例的逻辑覆盖程度
n 如果程序的功能说明中含有输入条件的组合情况，则选用因果图法
例题：
软件测试的目的是A 。通常B是在代码编写阶段可进行的测试，它是整个测试工作的基础。
逻辑覆盖标准主要用于C 。它主要包括条件覆盖、条件组合（多重条件）覆盖、判定覆盖、条件及判定覆盖、语句覆盖和路径覆盖等几种，其中除路径覆盖外最弱的覆盖标准是D ，最强的覆盖标准E 。
A： ①表明软件的正确性 ②评价软件质量
③尽可能发现软件中错误 ④判定软件是否合格
B： ①系统测试 ②安装测试 ③验收测试 ④单元测试
C： ①黑盒测试方法 ②白盒测试方法 ③灰盒测试方法 ④软件验收方法
D、E： ①条件覆盖 ②条件组合覆盖 ③判定覆盖
④条件及判定覆盖 ⑤语句覆盖
A：③ B：④ C：② D：⑤ E：②
用来辅助软件开发、运行、维护、管理和支持等过程中的活动的软件称为软件工具，通常也称为CASE（计算机辅助软件工程）工具。
整个软件开发过程要使用很多开发工具，其中包括分析工具、设计工具、编程工具、测试工具、维护工具等等。
软件开发工具是指支持软件产品开发的软件系统，它由软件工具集和环境集成机智构成。工具集包括支持软件开发相关过程、活动、任务的软件工具；环境集成机智为工具集成和软件开发、维护和管理提供统一的支持。
软件开发环境是把一组相关的工具集成在环境中，提供数据集成、控制集成和界面集成等机制。其中：
Ø 数据集成机制：提供统一的数据模式和数据接口规范，需要相互协同的工具通过这种统一的规范交换数据。数据集成可由共享文件、共享数据结构或共享信息库等不同的层次；
Ø 控制集成机制：支持各工具或各开发活动之间的通信、切换、调度和协同工作，并且支持软件开发过程的描述、执行和转接；通常消息传送的方式实现控制的集成。
Ø 界面集成机制使这些工具具有统一的界面风格，从而为软件开发、维护、管理等过程的各项活动提供连续的、一致的全方位支持。
集成型软件开发环境由工具集和环境集成机制组成，这种环境应该具有开放性和可剪裁性；
环境集成机制的核心是环境数据库。
软件开发项目管理基础知识（时间管理、成本管理、质量管理、人力资源管理、风险管理等）及其常用管理工具
软件维护阶段是指从软件交付使用到软件被淘汰为止的整个时期，它是在软件交付使用后，为了改正软件中隐藏的错误，或者为了使软件适应新的环境，或者为了扩充和完善软件的功能或性能而修改软件的过程。根据引起软件维护的原因，软件维护通常可分成改正性维护、适应性维护、完善性维护、预防性维护。
软件管理工作涉及到软件开发工作的方方面面，其直接对象包括人、财、物，简单地说，人就是指软件开发人员，财就是指项目经费，物就是指软件项目。也许还没有关于这方面的专门理论，但在工商管理领域已经有十分成熟的管理学理论，他山之石，可以攻玉，所以我们完全可以引进到软件项目方面的管理。
作为软件管理人员，应该站在高处来俯瞰整个项目，如果有不识庐山真面目的感觉就不太好了。有了俯瞰全局的意识这一前提，采用适当的管理技术，项目开展就容易罗。软件项目的管理工作可以分位四个方面：软件项目的计划、软件项目的组织、软件项目的领导和软件项目的控制.
1 软件项目的计划
软件开发项目的计划包括定义项目的目标，以及达到目标的方法。他涉及到项目实施的各个环节，带有全局的性质，是战略性的。计划应力求完备，要考虑到一些未知因素和不确定因素，考虑到可能的修改。计划应力求准确，尽可能提高所依据的数据的可靠程度。主要工作集中在软件项目的估算、软件开发成本的估算和软件项目进度安排。软件项目计划的目标是提供一个能使项目管理人员对资源、成本和进度做出合理估算的框架。这些估算应在软件项目开始时的一段有限时间内作出，并随着项目的进展进行更新。
2 软件项目的估算
软件项目管理过程开始于项目的计划，在做项目计划时，第一项活动是估算。现在已经使用的使用技术是时间和工作量的估算。因为估算是其他项目计划活动的基石，而且项目计划又未软件工程过程提供了工作方向，所以我们不能没有计划就着手开发，否则就会陷入盲目性。
估算本身带有风险，估算资源、成本和项目进度时需要经验、有用的历史信息、足够的定量数据和作定量度量的勇气。估算的精确程度受到多方面的影响。首先，项目的复杂性对于增加软件计划的不确定性影响很大，复杂性越高，估算的风险就越高。复杂性是相对度量的，他与项目参加人员的经验有关，比如如果让搞MIS的项目组去搞操作系统设计显然增加了复杂性。其次，项目的规模对于估算的精确性和功效的影响也比较大，因为随着软件规模的扩大，软件相同元素之间的相互依赖、相互影响也迅速增加，因而估算时进行问题分解也会变得更加困难。还有项目的结构化程度也影响项目估算的风险，这里的结构性是指功能分解的简便性和处理信息的层次性，结构化程度提高，进行精确估算的能力就提高，相应风险将减少。此外，历史信息的有效性也影响估算的风险，在对过去的项目进行这综合的软件度量之后，就可以借用来比较准确地进行估算。影响估算的因素远不止这些，比如用户需求的频繁变更给估算带来非常大的影响。
估算的依据是软件的范围，包括功能，性能、限制、接口和可靠性。在估算开始之前，应对软件的功能进行评价，并对其进行适当的细化以便提供更详细的细节。由于成本和进度的估算都与功能有关，因此常常采用功能分解的办法。性能的考虑主要包括处理和响应时间的需求。约束条件则标识外部硬件、可用存储和其他现有系统对软件的限制。
另外软件项目计划还要完成资源估算，包括人力资源、硬件资源和软件资源。在考虑各种软件开发资源时最重要的是人，必须考虑人员的技术水平、专业、人数以及在开发过程各阶段对各种人员的需要。硬件资源作为一种工具投入。软件资源包括各种帮助开发的软件工具，比如编程工具、管理工具、测试工具，还有操作系统和数据库等。
工作两估算是最普遍使用的技术。经过功能分解之后，可以估计出每一个项目任务的分解都需要花费若干人年，总计之后就知道软件项目总体工作量。下面就是一个示意性工作量估算表。
表格 1 某软件系统工作量估算表（单位：人日）
|
任务 |
需求分析 |
设计 |
编码 |
测试 |
小计 |
|
用户定义 |
2 |
5 |
1 |
0.5 |
8.5 |
|
系统定义 |
2 |
5 |
1 |
0.5 |
8.5 |
|
广告预定 |
4 |
10 |
2 |
0.5 |
16.5 |
|
划版 |
5 |
20 |
10 |
0.5 |
35.5 |
|
制作和组版 |
3 |
5 |
3 |
1 |
12 |
|
总计 |
16 |
45 |
17 |
3 |
81 |
软件开发成本的估算
软件开发成本主要是指软件开发过程所花费的工作量及其相应的代价。它不同于其他物理产品的成本，它主要包括人的劳动的消耗，人的劳动的消耗所需的代价就是软件产品的开发成本。
开发成本的估算方法有很多种，象简单的代码行技术，任务分解技术，自动估计成本技术，专家判定技术，还有参数方程法，标准值法，以及COCOMO模型法。其中COCOMO (Constructive Cost Model)模型法是一种精确、易于使用的成本估算方法，该模型按其详细程度分为三级：基本COCOMO模型、中间COCOMO模型和详细COCOMO模型
软件项目进度安排
软件项目的进度安排主要是考虑软件交付用户使用的这一段开发时间的安排。进度安排的准确程度可能比成本估计的准确程度更重要。软件产品可以靠重新定价或者靠大量的销售来弥补成本的增加，但进度安排的落空会导致市场机会的丧失或者用户不满意，而且也会导致成本的增加。因此在考虑进度安排时要把人员的工作量与花费的时间联系起来，合理分配工作量，利用进度安排的有效分析方法严密监视软件开发的进展情况，以使得软件开发的进度不致被拖延。
在进行进度安排时要考虑的一个主要问题是任务的并行性问题。当参加项目的人数不止一人是软件开发工作就会出现并行情况。因为并行任务是同时发生的所以进度计划表必须决定任务之间的从属关系，确定各个任务的先后次序和衔接，确定各个任务完成的持续时间。另外还应注意关键路径的任务，这样可以确定在进度安排中应保证的重点。常用的进度安排方法有两种，即甘特图（Gantt Chart）法和工程网络法。
3.软件项目的组织
参加软件开发的人员如何组织起来，使他们发挥最大的工作效率，对成功地完成软件项目极为重要。
组织结构
开发组织采用什么形式由软件项目的特点决定，同时也与参加人员的素质有关。通常有三种组织结构模式：
1. 按课题组划分的模式：把开发人员按课题组成小组，小组成员自始至终承担课题的各项任务。该模式适用于规模不大的项目，并且要求小组成员在各方面有技术专长。
2. 按职能划分的模式：把开发项目的软件人员按任务的工作阶段划分为若干工作小组。要开发的软件在每个专业小组完成阶段加工后沿工序流水线向下传递。这种流水作业的方式使用于多项目并行的情况。
3. 矩阵形模型：这种模式是以上两种模式的复合。一方面按工作性质成立一些专门小组，另一方面每一个项目都有它的经理人员负责。每一个软件开发人员属于某一个专门小组，有参加某一个项目的工作。该模式的优点有一方面参加专门组的成员可以在组内交流在各个项目中取得的经验，这更有利于发挥专业人员的作用；另一方面，各个项目有专门的人员负责，有利于软件项目的完成。这种模式比较适合于规模比较大的项目。
组织结构的最后一层是程序设计小组的组织形式。通常认为程序设计工作是按独立的方式进行的，程序人员独立地完成任务。但这并不意味着相互之间没有联系。一般在人数比较少时组员之间的联系比较简单，但随着人数的增加，相互之间的联系变得负责起来。小组内部人员的组织形式对对生产率有着十分重要的影响。
常见的小组组织形式有三种，这三种形式可以灵活使用。
1. 主程序员制小组：相当于组长负责制，小组的核心由一位主程序员，另外配备两到三位技术员、一位后援工程师组成。这种组织结构突出主程序员的领导，强调主程序员与其他技术人员的联系。
2. 民主制小组：在民主制小组中，遇到问题可以在组员之间平等地交换换意见，工作组目标的制定以及决定的作出都由全体人员参加。这种组织形式强调发挥每个成员的积极性，并要求每个成员发挥主动精神和协作精神。
3. 层次式小组：在层次式小组中，组内人员分位三级：组长（项目负责人）一人负责全组工作，他直接领导两到三名高级程序员，每位高级程序员通过基层小组，管理若干位程序员。这种结构比较适合于项目本身就是层次结构的课题。
人员配备
合理地配备人员是成功地完成软件项目的切实保证。所谓合理地配备人员应包括按不同阶段适时运用人员，恰当掌握用人标准。一般来说，软件项目不同阶段不同层次技术人员的参与情况是不一样的。下图是典型的软件开发人员参与情况曲线。
<?xml:namespace prefix = v ns = "urn:schemas-microsoft-com:vml" />
在人力配备问题上，由于配置不当，很容易造成人力资源的浪费，并延误工期。特别是采用恒定人员配备方案时在项目的开始和最后都会出现人力过剩，而在中期又会出现人力不足的情况。
4.软件项目的领导
5.软件项目的控制
对后面两个主题以后再讨论。其实本文所讨论的东西大多还没有涉及太多管理学方面的内容，但这方面确实有许多值得研究的东西，由于时间关系不能深入下去。姑且作为一个引子吧！
转载自：《系统分经典教材》
扫一扫
2365
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
