摘要：软件配置项包括哪些内容？ CSCI是计算机软件配置项（Computer Software Configuration Item）简称，在软件设计文档中经常用到。 配置与配置项 在配置管理中，“配置”和...

软件配置项包括哪些内容？

CSCI是计算机软件配置项（Computer Software Configuration Item）简称，在软件设计文档中经常用到。

配置与配置项 在配置管理中，“配置”和“配置项”是重要的概念，“配置”是在技术文档中明确说明并最终组成软件产品的功能或物理属性。

因此“配置”包括了即将受控的所 有产品特性，其内容及相关文档，软件版本，变更文档，软件运行的支持数据，以及其他一切保证软件一致性的组成要素，相对与硬件类配置，软件产品的“配置” 包括更多的内容并具有易变性。

受控软件经常被划分为各类配置项（Configuraion items, CIs），这类划分是进行软件配置管理的基础和前提，CIs是逻辑上组成软件系统的各组成部分。

比如一个软件产品包括几个程序模块，每个 程序模块及其相关文档和支撑数据可能被命名为一个CI。

一个系统包括的CIs的数目是一个与设计密切相关的问题，关于怎样将一个软件系统划分为不同的 CIs将在以下有关章节中阐述，注意如果一个产品同时包括硬件和软件部分，一般一个CI也同时包括软件和硬件部分，一个纯软件的CI通常也称之为软件配置 项（CSCI）。

本规范的CI一般指CSCI，软硬件的配置管理有一些相通的地方，但因为软件更易于修改，所以软件配置管理是一个更应该系统化的过程。

基线与基线管理 各CIs随软件开发活动的进展，会有越来越多的部件进入受控状态。

一般地，软件开发过程从概念演绎和需求分析开始，然后是设计，各CSCIs的编码或写 作，集成测试，最后是用户手册的编写等。

软件配置管理包括了在软件生命周期的时间分散点上对各CIs进行标识并对对他们的修改进行控制的过程。

在一个开发 阶段结束或一组功能开发完成后，要对相应的CIs进行基线化并形成各类基线。

在配置管理系统中，基线就是一个CI或一组CIs在其生命周期的不同时间点上 通过正式评审而进入正式受控的一种状态，而这个过程被称为“基线化”。

每一个基线都是其下一步开发的出发点和参考点。

每个基线都将接受配置管理的严格控制，对其的修改将严格按照变更控制要求的过程进行，在一个软件开发阶段结束时，上一个基线加上增加和修改的基线内容形成下一个基线，这就是“基线管理”的过程，因此基线具有以下属性： 通过正式的评审过程建立 基线存在于基线库中，对基线的变更接受更高权限的控制 基线是进一步开发和修改的基准和出发点。

一般地，第一个基线包含了通过评审的软件需求，因此称之为“需求基线”，通过建立这样一个基线，受控的系统需求成为进一步软件开发的出发点，对需求的变更被正式初始化、评估。

受控的需求还是对软件进行功能评审的基础。

有时进行有些程序操作时,总是提供什么“源程序”“源文件”“源代...

源程序源文件源代码是一回事。

源程序一般就是可以用记事本打开的好多行英文的，用编程语言写好的软件 源程序经过编译成目标程序，才能运行。

一般目标程序不能再修改了。

我们电脑上安装的软件都是目标程序。

源程序不可能直接运行的。

提倡软件开源的人士认为应该提供源程序给用户，让用户自己修改，有利于软件行业的发展。

反对的人觉得这样不利于保护版权。

你如果不懂编程，源程序可以不管它。

不影响正常使用。

错误代码0x80070057

一、判断题1.软件测试的目的是尽可能多的找出软件的缺陷。

（Y）2.Beta 测试是验收测试的一种。

（Y）3.验收测试是由最终用户来实施的。

（N）4.项目立项前测试人员不需要提交任何工件。

（Y）5.单元测试能发现约80%的软件缺陷。

（Y）6.代码评审是检查源代码是否达到模块设计的要求。

（N）7.自底向上集成需要测试员编写驱动程序。

（Y）8.负载测试是验证要检验的系统的能力最高能达到什么程度。

（N）9.测试人员要坚持原则，缺陷未修复完坚决不予通过。

（N）10.代码评审员一般由测试员担任。

（N）11.我们可以人为的使得软件不存在配置问题。

（N）12.集成测试计划在需求分析阶段末提交。

（N）二、选折1.软件验收测试的合格通过准则是：（ABCD）A. 软件需求分析说明书中定义的所有功能已全部实现，性能指标全部达到要求。

B. 所有测试项没有残余一级、二级和三级错误。

C. 立项审批表、需求分析文档、设计文档和编码实现一致。

D. 验收测试工件齐全。

2.软件测试计划评审会需要哪些人员参加？（ABCD）A.项目经理B.SQA 负责人C.配置负责人D.测试组3.下列关于alpha 测试的描述中正确的是：（AD）A.alpha 测试需要用户代表参加B.alpha 测试不需要用户代表参加C.alpha 测试是系统测试的一种D.alpha 测试是验收测试的一种4.测试设计员的职责有：（BC）A.制定测试计划B.设计测试用例C.设计测试过程、脚本D.评估测试活动5.软件实施活动的进入准则是：（ABC）A.需求工件已经被基线化B.详细设计工件已经被基线化C.构架工件已经被基线化D.项目阶段成果已经被基线化三、添空1.软件验收测试包括：正式验收测试，alpha 测试，beta 测试。

2.系统测试的策略有：功能测试，性能测试，可靠性测试，负载测试，易用性测试，强度测试，安全测试，配置测试，安装测试，卸载测试，文挡测试，故障恢复测试，界面测试，容量测试，兼容性测试，分布测试，可用性测试，（有的可以合在一起，分开写只要写出15 就满分哦）3.设计系统测试计划需要参考的项目文挡有：软件测试计划，软件需求工件和迭代计划。

4.对面向过程的系统采用的集成策略有：自顶向下，自底向上两种。

5.（这题出的有问题哦，详细的5 步骤为~~）通过画因果图来写测试用例的步骤为：（1）分析软件规格说明描述中，哪些是原因（即输入条件或输入条件的等价类），哪些是结果（即输出条件），并给每个原因和结果赋予一个标识符。

（2）分析软件规格说明描述中的语义，找出原因与结果之间，原因与原因之间对应的是什么关系？ 根据这些关系，画出因果图。

（3）由于语法或环境限制，有些原因与原因之间，原因与结果之间的组合情况不可能出现。

为表明这些特殊情况，在因果图上用一些记号标明约束或限制条件。

（4）把因果图转换成判定表。

（5）把判定表的每一列拿出来作为依据，设计测试用例。

四、简答（资料是搜集整理的，感谢前辈的解题）无1.区别阶段评审的与同行评审同行评审目的：发现小规模工作产品的错误，只要是找错误；阶段评审目的：评审模块阶段作品的正确性可行性及完整性同行评审人数：3-7 人人员必须经过同行评审会议的培训，由SQA 指导阶段评审人数：5 人左右评审人必须是专家具有系统评审资格同行评审内容：内容小一般文档< 40 页， 代码< 500 行阶段评审内容： 内容多，主要看重点同行评审时间：一小部分工作产品完成阶段评审时间： 通常是设置在关键路径的时间点上！2.什么是软件测试为了发现程序中的错误而执行程序的过程3 简述集成测试的过程系统集成测试主要包括以下过程：1. 构建的确认过程。

2. 补丁的确认过程。

3. 系统集成测试测试组提交过程。

4. 测试用例设计过程。

5. 测试代码编写过程。

6. Bug 的报告过程。

7. 每周/每两周的构建过程。

8. 点对点的测试过程。

9. 组内培训过程。

4 怎么做好文档测试仔细阅读，跟随每个步骤，检查每个图形，尝试每个示例。

P142检查文档的编写是否满足文档编写的目的内容是否齐全，正确内容是否完善标记是否正确5 白盒测试有几种方法总体上分为静态方法和动态方法两大类。

静态：关键功能是检查软件的表示和描述是否一致，没有冲突或者没有歧义动态：语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖。

6 系统测试计划是否需要同行审批，为什么需要，系统测试计划属于项目阶段性关键文档，因此需要评审。

7Alpha 测试与beta 的区别Alpha 测试在系统开发接近完成时对应用系统的测试；测试后仍然会有少量的设计变更。

这种测试一般由最终用户或其它人员完成，不能由程序或测试员完成。

Beta 测试当开发和测试根本完成时所做的测试，最终的错误和问题需要在最终发行前找到。

这种测试一般由最终用户或其它人员完成，不能由程序员或测试员完成。

8 比较负载测试，容量测试和强度测试的区别负载测试：在一定的工作负荷下，系统的负荷及响应时间。

强度测试：在一定的负荷条件下，在较长时间跨度内的系统连续运行给系统性能所造成的影响。

容量测试：容量测试目的是通过测试预先分析出反映软件系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数等），系统在其极限值状态下没有出现任何软件故障或还能保持主要功能...

验收测试要经过用户批准才开始吗

Alpha测试和Beta测试都是由用户来进行测试，但是目的并不是项目或者产品的验收，而是属于系统测试的范畴，一般Alpha测试 也可认为是实验室测试由非专业人士参加，但是一般有专业的测试工程师配合指导，测试问题马上能的到反馈，定位准确，但是代价比较大，这种测试方法适合项目级应用； Beta测试则是开放型测试，使用于产品的测试，内部测试稳定后，发布Beta版本软件让公共用户测试，公司一般不能准确知道是哪些人使用了软件，并且他们发现的软件缺陷也不能准确有效的反馈给开发部门，需要将收集的信息经过整理得到有用的缺陷报告。

这种测试方法得到的BUG数量不可预测，但是成本较低，一般只需做信息的收集整理工作！验收测试：仅限于做项目的公司，部门内部测试稳定后，根据合同中需求由发包商进行验收测试。

如何对外包的项目进行验收测试 随着当今技术和市场环境的变化，越来越多的企业选择将软件项目外包，同时也有更多成熟的大型软件企业加入到软件项目的承包队伍中。

外包的软件项目越来越多，如何对这些外包的项目进行验收测试日益成为企业的一个关键问题。

用户验收测试的总体思路 用户验收测试是软件开发结束后，用户对软件产品投入实际应用以前进行的最后一次质量检验活动。

它要回答开发的软件产品是否符合预期的各项要求，以及用户能否接受的问题。

由于它不只是检验软件某个方面的质量，而是要进行全面的质量检验，并且要决定软件是否合格，因此验收测试是一项严格的正式测试活动。

需要根据事先制订的计划，进行软件配置评审、功能测试、性能测试等多方面检测。

用户验收测试可以分为两个大的部分：软件配置审核和可执行程序测试，其大致顺序可分为：文档审核、源代码审核、配置脚本审核、测试程序或脚本审核、可执行程序测试。

要注意的是，在开发方将软件提交用户方进行验收测试之前，必须保证开发方本身已经对软件的各方面进行了足够的正式测试（当然，这里的“足够”，本身是很难准确定量的）。

用户在按照合同接收并清点开发方的提交物时（包括以前已经提交的），要查看开发方提供的各种审核报告和测试报告内容是否齐全，再加上平时对开发方工作情况的了解，基本可以初步判断开发方是否已经进行了足够的正式测试。

用户验收测试的每一个相对独立的部分，都应该有目标（本步骤的目的）、启动标准（着手本步骤必须满足的条件）、活动（构成本步骤的具体活动）、完成标准（完成本步骤要满足的条件）和度量（应该收集的产品与过程数据）。

在实际验收测试过程中，收集度量数据，不是一件容易的事情。

软件配置审核 对于一个外包的软件项目而言，软件承包方通常要提供如下相关的软件配置内容： . 可执行程序、源程序、配置脚本、测试程序或脚本。

. 主要的开发类文档：《需求分析说明书》、《概要设计说明书》、《详细设计说明书》、《数据库设计说明书》、《测试计划》、《测试报告》、《程序维护手册》、《程序员开发手册》、《用户操作手册》、《项目总结报告》。

. 主要的管理类文档：《项目计划书》、《质量控制计划》、《配置管理计划》、《用户培训计划》、《质量总结报告》、《评审报告》、《会议记录》、《开发进度月报》。

. 在开发类文档中，容易被忽视的文档有《程序维护手册》和《程序员开发手册》。

《程序维护手册》的主要内容包括：系统说明（包括程序说明）、操作环境、维护过程、源代码清单等，编写目的是为将来的维护、修改和再次开发工作提供有用的技术信息。

《程序员开发手册》的主要内容包括：系统目标、开发环境使用说明、测试环境使用说明、编码规范及相应的流程等，实际上就是程序员的培训手册。

不同大小的项目，都必须具备上述的文档内容，只是可以根据实际情况进行重新组织。

对上述的提交物，最好在合同中规定阶段提交的时机，以免发生纠纷。

通常，正式的审核过程分为5 个步骤：计划、预备会议（可选）、准备阶段、审核会议和问题追踪。

预备会议是对审核内容进行介绍并讨论。

准备阶段就是各责任人事先审核并记录发现的问题。

审核会议是最终确定工作产品中包含的错误和缺陷。

审核要达到的基本目标是：根据共同制定的审核表，尽可能地发现被审核内容中存在的问题，并最终得到解决。

在根据相应的审核表进行文档审核和源代码审核时，还要注意文档与源代码的一致性。

在实际的验收测试执行过程中，常常会发现文档审核是最难的工作，一方面由于市场需求等方面的压力使这项工作常常被弱化或推迟，造成持续时间变长，加大文档审核的难度；另一方面，文档审核中不易把握的地方非常多，每个项目都有一些特别的地方，而且也很难找到可用的参考资料。

可执行程序的测试 在文档审核、源代码审核、配置脚本审核、测试程序或脚本审核都顺利完成，就可以进行验收测试的最后一个步骤——可执行程序的测试，它包括功能、性能等方面的测试，每种测试也都包括目标、启动标准、活动、完成标准和度量等五部分。

要注意的是不能直接使用开发方提供的可执行程序用于测试，而要按照开发方提供的编译步...

程序设计者应该具备的品质是什么？

程序员基本素质： 作一个真正合格的程序员，或者说就是可以真正合格完成一些 代码工作的程序员，应该具有的素质。

1：团队精神和协作能力 把它作为基本素质，并不是不重要，恰恰相反，这是程序员应该具备的最基本的， 也是最重要的安身立命之本。

把高水平程序员说成独行侠的都是在呓语，任何个人的力 量都是有限的，即便如linus这样的天才，也需要通过 组成强大的团队来创造奇迹，那些遍布全球的为linux写核心的高手们，没有协作精神是 不可想象的。

独行侠可以作一些赚钱的小软件发点小财，但是一旦进入一些大系统的研 发团队，进入商业化和产品化的开发任务，缺乏 这种素质的人就完全不合格了。

2：文档习惯 说高水平程序员从来不写文档的肯定是乳臭未干的毛孩子，良好的文档是正规研发 流程中非常重要的环节，作为代码程序员，30%的工作时间写技术文档是很正常的，而 作为高级程序员和系统分析员，这个比例还要高很多。

缺 乏文档，一个软件系统就缺乏生命力，在未来的查错，升级以及模块的复用时就都会遇 到极大的麻烦。

3：规范化，标准化的代码编写习惯 作为一些外国知名软件公司的规矩，代码的变量命名，代码内注释格式，甚至嵌套 中行缩进的长度和函数间的空行数字都有明确规定，良好的编写习惯，不但有助于代码 的移植和纠错，也有助于不同技术人员之间的协作。

fan s叫嚣高水平程序员写的代码旁人从来看不懂，这种叫嚣只能证明他们自己压根不配自称 程序员。

代码具有良好的可读性，是程序员基本的素质需求。

再看看整个linux的搭建， 没有规范化和标准化的代码习惯，全球的研发 协作是绝对不可想象的。

4：需求理解能力 程序员需要理解一个模块的需求，很多小朋友写程序往往只关注一个功能需求，他 们把性能指标全部归结到硬件，操作系统和开发环境上，而忽视了本身代码的性能考虑 ，有人曾经放言说写一个广 告交换程序很简单，这种人从 来不知道在百万甚至千万数量级的访问情况下的性能指标是如何实现的，对于这样的程 序员，你给他深蓝那套系统，他也做不出太极链的并访能力。

性能需求指标中，稳定性 ，并访支撑能力以及安全性都很重要，作为程序员需要 评估该模块在系统运营中所处的环境，将要受到的负荷压力以及各种潜在的危险和恶意 攻击的可能性。

就这一点，一个成熟的程序员至少需要2到3年的项目研发和跟踪经验才 有可能有心得。

5：复用性，模块化思维能力 经常可以听到一些程序员有这样的抱怨，写了几年程序，变成了熟练工，每天都是 重复写一些没有任何新意的代码，这其实是中国软件人才最大浪费的地方，一些重复性 工作变成了熟练程序员的主要工作，而这些，其实是完全可 以避免的。

复用性设计，模块化思维就是要程序员在完成任何一个功能模块或函数的时候，要 多想一些，不要局限在完成当前任务的简单思路上，想想看该模块是否可以脱离这个系 统存在，是否可以通过简单的修改参数的方式在其他系统和应用环境下直接引用，这样 就能极大避免重复性的开发工作，如果一个软件研发单位和工作组能够在每一次研发过 程中都考虑到这些问题，那么程序员就不会在重复性的工作中耽误太多时间，就会有更 多时间和精力投入到创新的代码工作中去。

一些好的程序模块代码，即便是70年代写成的，拿到现在放到一些系统里面作为功 能模块都能适合的很好，而现在我看到的是，很多小公司软件一升级或改进就动辄全部 代码重写，大部分重复性工作无谓的浪费了时间和精力。

6：测试习惯 作为一些商业化正规化的开发而言，专职的测试工程师是不可少的，但是并不是说 有了专职的测试工程师程序员就可以不进行自测；软件研发作为一项工程而言，一个很 重要的特点就是问题发现的越早，解决的代价就越低，程序 员在每段代码，每个子模块完成后进行认真的测试，就可以尽量将一些潜在的问题最早 的发现和解决，这样对整体系统建设的效率和可靠性就有了最大的保证。

测试工作实际上需要考虑两方面，一方面是正常调用的测试，也就是看程序是否能 在正常调用下完成基本功能，这是最基本的测试职责，可惜在很多公司这成了唯一的测 试任务，实际上还差的远那；第二方面就是异常调用的测试，比如高压力负荷下的稳定 性测试，用户潜在的异常输入情况下的测试，整体系统局部故障情况下该模块受影响状 况的测试，频发的异常请求阻塞资源时的模块稳定测试等等。

当然并不是程序员要对自 己的每段代码都需要进行这种完整测试，但是程序员必须清醒认识自己的代码任务在整 体项目中的地位和各种性能需求，有针对性的进行相关测试并尽早发现和解决问题，当 然这需要上面提到需求理解能力。

7：学习和总结的能力 程序员是人才很容易被淘汰，很容易落伍的职业，因为一种技术可能仅仅在三两年 内具有领先性，程序员如果想安身立命，就必须不断跟进新的技术，学习新的技能。

善于学习，对于任何职业而言，都是前进所必需的动力，对于程序员，这种要求就 更加高了。

但是学习也要找对目标，一些小coding有些codingTO就是这样的coding上只 是一些Cfans们，他们也津津乐道于...

列举网络中建站所需六种硬件设备

百万级访问量网站的技术准备工作 当今从纯网站技术上来说，因为开源模式的发展，现在建一个小网站已经很简单也很便宜，所以很多人都把创业方向定位在互联网应用。

这些人里大多数不是很懂技术，或者不是那么精通，而网站开发维护方面的知识又很分散，学习成本太高，所以这篇文章将这些知识点结合起来，系统的来说，一个从日几千访问的小小网站，到日访问一两百万的小网站，中间可能会产生什么问题，以及怎么才能在一开始做足工作尽量避免这些问题。

你的网站因为努力经营，访问量逐渐升高，在升高的过程中，问题也可能开始显现了。

因为带宽的增加、硬件的扩展、人员的扩张所带来的成本提高是显而易见的，而还有相当大的一部分成本是因为代码重构、架构重构，甚至底层开发语言更换引起的，最坏的情况就是数据丢失，所有努力付之一炬。

这类成本支出大多数在一开始就可以避免，先打好基础，往后可以省很多精力，少操很多心。

对于不同的初期投资成本，技术路线的选择是不同的。

这里假设网站刚刚只是一个构想，计划第一年服务器硬件带宽投入5万左右。

对于这个资金额度，有很多种方案可选择，例如租用虚拟主机、租用单独服务器，或者流行的私有云，或者托管服务器。

前两种选择，网站发展到一定规模时需迁移，那时再重做规划显然影响更大。

服务器托管因为配置自主、能完全掌握控制权，所以有一定规模的网站基本都是这种模式。

采用自己托管服务器的网站，一开始要注意以下几点——一、开发语言 一般来说，技术人员（程序员）都是根据自己技术背景选择自己最熟悉的语言，不过不可能永远是一个人写程序，所以在语言的选择上还要是要费些心思。

首先明确一点，无论用什么语言，最终代码质量是看管理，因此我们从前期开发成本分析。

现在国内流行的适用于网站的语言，大概有java、php、.net、 python、ruby这五大阵营。

python和ruby因为在国内流行的比较晚，现在人员还是相对难招一些。

.net平台的人相对多，但是到后期需要解决性能问题时，对人员技能的要求比较高。

剩余的java、php用人可以说是最多的。

java和php无法从语言层面做比较，但对于初期，应用几乎都是靠前端支撑的网站来说，php入门简单、编写快速，优势相对大一点。

至于后端例如行为分析、银行接口、异步消息处理等，等真正需要时，就要根据不同业务需求来选择不同语言了。

二、代码版本管理 稍微有点规模的网站就需要使用代码版本管理了。

代码版本管理两点最大的好处，一是方便协同工作，二是有历史记录可查询比较。

代码版本管理软件有很多，vss/cvs/svn/hg等，目前国内都比较流行，其中svn的普及度还是很高的。

假设选了svn，那么有几点考虑。

一是采用什么树结构。

初期可能只有一条主干，往后就需要建立分支，例如一条开发分支，一条上线分支，再往后，可能要每个小组一个分支。

建议一开始人少时选择两条分支，开发和线上，每个功能本地测试无误后提交到开发分支，最后统一测试，可以上线时合并到上线分支。

如果每人都建自己的分支，合并时会浪费很大精力，对于几乎每天都要修改几次的WEB应用来说，所费时间太多。

向服务器部署代码，可以手工部署也可以自动部署。

手工部署相对简单，一般可直接在服务器上svn update，或者找个新目录svn checkout，再把web root给ln -s过去。

应用越复杂，部署越复杂，没有什么统一标准，只是别再用ftp上传那种形式，一是上传时文件引用不一致错误率增加，二是很容易出现开发人员的版本跟线上版本不一致，导致本来想改个错字结果变成回滚。

如果有多台服务器还是建议自动部署，更换代码的机器从当前服务池中临时撤出，更新完毕后再重新加入。

三、服务器硬件 在各个机房里，靠一台服务器孤独支撑的网站数不清，但如果资金稍微充足，建议至少三台的标准配置，分别用作web处理、数据库、备份。

web服务器至少要8G内存，双sata raid1，如果经济稍微宽松，或静态文件或图片多，则15k sas raid10。

数据库至少16G内存，15k sas raid 10。

备份服务器最好跟数据库服务器同等配置。

硬件可以上整套品牌，也可以兼容机，也可以半品牌半组装，取决于经济能力。

当然，这是典型的搭配，有些类型应用的性能瓶颈首先出现在web上，那种情况就要单独分析了。

web服务器可以既跑程序又当内存缓存，数据库服务器则只跑主数据库（假如是MySQL的话），备份服务器所承担就相对多一些，web配置、缓存配置、数据库配置都要跟前两台一致，这样WEB和数据库任意一台出问题，很容易就可以将备份服务器切换过去临时顶替，直到解决完问题。

要注意，硬件是随时可能坏掉的，特别是硬盘，所以宁可WEB服务器跟数据库服务器放在一起，也一定不能省掉备份，备份一定要异机，并且有异步，电力故障、误操作都可能导致一台机器上的所有数据丢失。

很多的开源备份方案可选择，最简单的就是rsync，写crontab里，定时同步。

备份和切换，建议多做测试，选最安全最适合业务的，并且尽可能异地备份。

四、机房 三种机房尽量不要选：联通访问特别慢的电信机房、电信访问特别慢的联通...