|
|
|
|
|
|
|
|
|
|
|
WiFi全称Wireless Fidelity，又称802.11b标准，它的最大优点就是传输速度较高，可以达到11Mb/s；另外它的有效距离也很长，同时也与已有的各种802.11 DSSS设备兼容。
|
|
|
|
WiFi第一个版本发表于1997年，其中定义了介质访问接入控制层（MAC层）和物理层。物理层定义了工作在2.4GHz的ISM频段上的两种无线调频方式和一种红外传输的方式，总数据传输速率设计为2Mb/s。两个设备之间的通信可以自由直接（ad hoc）的方式进行，也可以在基站BS（Base Station）或访问点AP（Access Point）的协调下进行。
|
|
|
|
1999年增加了两个补充版本：802.11a定义了在5GHz的ISM频段上的数据传输速率可达54 Mb/s的物理层；802.11b定义了在2.4GHz的ISM频段上但数据传输速率高达11 Mb/s的物理层。2.4GHz的ISM频段为世界上绝大多数国家通用，因此802.11b得到了最为广泛的应用。
|
|
|
|
|
|
（1）较广的局域网覆盖范围：WiFi的覆盖半径可达100m左右，相比于蓝牙技术覆盖范围较广，可以覆盖整栋办公大楼。
|
|
|
|
（2）传输速度快：WiFi技术传输速度非常快，可以达到11Mb/s（802.11b）或者54Mb/s（802.11a），适合高速数据传输的业务。
|
|
|
|
（3）无须布线：WiFi主要的优势在于不需要布线，可以不受布线条件的限制，因此非常适合移动办公用户的需要。在机场、车站、咖啡店、图书馆等人员较密集的地方设置“热点”，并通过高速线路将因特网接入上述场所。
|
|
|
|
（4）健康安全：IEEE 802.11规定的发射功率不可超过100mW，实际发射功率约60～70mW，而手机的发射功率约200mW～1W间，手持式对讲机高达5W。与后者相比，WiFi产品的辐射更小。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ZigBee这个名字来源于蜂群的通信方式：蜜蜂之间通过跳Zigzag形状的舞蹈来交互消息，以便共享食物源的方向、位置和距离等信息。借此意义ZigBee作为新一代无线通信技术的命名。ZigBee是基于IEEE 802.15.4标准的低功耗局域网协议。根据国际标准规定，ZigBee技术是一种短距离、低功耗的无线通信技术。主要适合用于自动控制和远程控制领域，可以嵌入各种设备。
|
|
|
|
ZigBee是一种高可靠的无线数传网络，类似于CDMA和GSM网络。ZigBee数传模块类似于移动网络基站。ZigBee是一个由可多到65 000个无线数传模块组成的一个无线网络平台，在整个网络范围内，每一个网络模块之间可以相互通信，每个网络结点间的距离可以从标准的75米无限扩展。通信距离从标准的75米到几百米、几千米，并且支持无限扩展（依靠结点数增加）。与移动通信的CDMA网或GSM网不同的是，ZigBee网络主要是为工业现场自动化控制数据传输而建立，因而，它必须具有简单，使用方便，工作可靠，价格低的特点；而移动通信网主要是为语音通信而建立，每个基站价值一般都在几十万甚至上百万元人民币，而每个ZigBee网络“基站”（结点）却不到1000元人民币。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
在给定了软件设计规格说明书后，下一步的工作就是编写代码。一般来说，编码工作可以分为四个步骤：
|
|
|
|
|
|
（2）准备编程环境，包括软硬件平台的选择，包括操作系统、编程语言、集成开发环境等。
|
|
|
|
|
|
（4）进行代码审查，以提高编码质量。为提高审查的效率，在代码审查前需要准备一份检查清单，并设定此次审查须找到的bug数量。在审查时，要检查软件规格说明书与编码内容是否一致；代码对硬件和操作系统资源的访问是否正确；中断控制模块是否正确等。
|
|
|
|
|
|
在嵌入式系统中，由于资源有限，且实时性和可靠性要求较高，因此，在开发嵌入式软件时，要注意对执行时间、存储空间和开发／维护时间这三种资源的使用进行优化。也就是说，代码的执行速度要越快越好，系统占用的存储空间要越小越好，软件开发和维护的时间要越少越好。
|
|
|
|
|
|
.保持函数短小精悍。一个函数应该只实现一个功能，如果函数的代码过于复杂，将多个功能混杂在一起，就很难具备可靠性和可维护性。另外，要限制函数的长度，一般来说，一个函数的长度最好不要超过100行。
|
|
|
|
.封装代码。将数据以及对其进行操作的代码封装在一个实体中，其他代码不能直接访问这些数据。例如，全局变量必须在使用该变量的函数或模块内定义。对代码进行封装的结果就是消除了代码之间的依赖性，提高了对象的内聚性，使封装后的代码对其他行为的依赖性较小。
|
|
|
|
.消除冗余代码。例如，将一个变量赋给它自己，初始化或设置一个变量后却从不使用它，等等。研究表明，即使是无害的冗余也往往和程序的缺陷高度关联。
|
|
|
|
.减少实时代码。实时代码不但容易出错、编写成本较高，而且调试成本可能更高。如果可能，最好将对执行时间要求严格的代码转移到一个单独的任务或者程序段中。
|
|
|
|
|
|
.遵守代码编写标准并借助检查工具。用自动检验工具寻找缺陷比人工调试便宜，而且能捕捉到通过传统测试检查不到的各种问题。
|
|
|
|
|
|
|
|
在嵌入式软件开发过程中，遵守编程规范，养成良好的编程习惯，这是非常重要的，将直接影响到所编写代码的质量。
|
|
|
|
|
|
.命名规则。从编译器的角度，一个合法的变量名由字母、数字和下画线三种字符组成，且第一个字符必须为字母或下画线。但是从程序员的角度，一个好的名字不仅要合法，还要载有足够的信息，做到“见名知意”，并且在语意清晰、不含歧义的前提下，尽可能地简短。
|
|
|
|
.编码格式。在程序布局时，要使用缩进规则，例如变量的定义和可执行语句要缩进一级，当函数的参数过长时，也要缩进。另外，括弧的使用要整齐配对，要善于使用空格和空行来美化代码。例如，在二元运算符与其运算对象之间，要留有空格；在变量定义和代码之间要留有空行；在不同功能的代码段之间也要用空行隔开。
|
|
|
|
.注释的书写。注释的典型内容包括：函数的功能描述；设计过程中的决策，如数据结构和算法的选择；错误的处理方式；复杂代码的设计思想等。在书写注释时要注意，注释的内容应该与相应的代码保持一致，同时要避免不必要的注释，过犹不及。
|
|
|
|
|
|
由于嵌入式系统对实时性的要求较高，因此一般要求对代码的性能进行优化，使代码的执行速度越快越好。以算术运算为例，在编写代码时，需要仔细地选择和使用算术运算符。一般来说，整数的算术运算最快，其次是带有硬件支持的浮点运算，而用软件来实现的浮点运算是非常慢的。因此，在编码时要遵守以下准则：
|
|
|
|
.尽量使用整数（char、short、int和long）的加法和减法。
|
|
|
|
|
|
|
|
|
|
下图是一个例子，其中两段代码的功能完全一样，都是对一个结构体数组的各个元素进行初始化，但采用两种不同的方法来实现。下图（a）采用数组下标的方法，在定位第i个数组元素时，需要将i乘以结构体元素的大小，再加上数组的起始地址。下图（b）采用的是指针访问的方法，先把指针fp初始化为数组的起始地址，然后每访问完一个数组元素，就把fp加1，指向下一个元素。在一个奔腾4的PC上，将这两段代码分别重复10 700次，右边这段代码需要1ms，而左边这段代码需要2.13ms。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
由于嵌入式软件的特点，决定了嵌入式软件测试比通用软件困难，根本原因在于一般测试技术和测试工具的实施缺乏基本条件。由于嵌入式软件运行环境的特定性及专用外部设备的连接，使嵌入式软件在相应的嵌入式计算机系统未开发完成前不能真正运行，动态测试技术不能应用；嵌入式计算机系统的有限资源和专用接口使运行监测和观察输出变得很困难，嵌入式软件的输入／输出涉及计算机系统专用的端口、外部设备，以及各种不同的信号量形式，如数字量、电压量、电流量、脉冲量、开关量等，各种输入／输出量电气特性也不一样，加上实时性要求输入／输出的时序特性，使嵌入式软件的测试输入和结果获得都很困难。
|
|
|
|
面临以上嵌入式软件测试的难点，使得嵌入式软件的测试环境相对与一般的应用软件比较特殊。
|
|
|
|
|
|
宿主机模拟环境就是采用模拟技术在宿主机上建立嵌入式软件的运行环境，从而使嵌入式软件的运行脱离目标机便于进行测试。目前，宿主机模拟测试环境按其实现的方法可分为两类，一类是基于目标机芯片的模拟测试环境；一类是采用交叉编译的方法将被测软件编译为在宿主机上执行代码的方法。
|
|
|
|
基于目标机芯片的模拟测试环境通过对处理器（CPU）、存储器、外围可编程芯片以及各器件连接的模拟，构造目标机硬件环境。基于目标机芯片的模拟测试环境如下图所示。
|
|
|
|
|
|
|
|
处理器模拟包括对处理器指令集、寄存器、中断处理机制的模拟；内存模拟包括内存寻址、读、写模拟；外围可编程芯片模拟包括对工作模式、命令字的响应、输入／输出特性、功能特性的模拟；器件间连接模拟包括为这些芯片的数据端口、控制端口设置I/O地址，并决定其间的输入／输出关系。
|
|
|
|
基于交叉编译的模拟测试环境不用构造嵌入式软件的运行环境，其模拟的重点是模拟被测试程序的输入／输出。首先对被测试程序进行硬件依赖性分析，然后将输入／输出命令用API函数替换，最后采用使用交叉编译的方法将被测软件编译为在宿主机上可运行的执行代码。基于交叉编译的模拟测试环境如下图所示。
|
|
|
|
|
|
|
|
|
|
交联式测试环境是逼近真实环境的一种运行环境，实际上是对整个系统（而非仅对软件）进行考察的测试。交联式测试环境可以接入若干个研制完成的产品（实物）或设备模拟器。不同的系统，交联式模拟测试环境接入实物的多少不一样，但对软件来说，目标机硬件环境、相应外围设备接口、输入的指令、数据等全都是真实的。交联式模拟测试环境与真实系统有一致的映射关系。例如具有相同的接口，相同的I/O传输格式、方式和速率，相同的时序和相同的工作方式、状态等。交联式模拟测试环境不仅适用于对软件功能的验证，而且可以对软件的外部接口、实时特性进行较真实的验证。交联式测试环境如下图所示。
|
|
|
|
|
|
|
|
交联式模拟测试环境一般包括目标机、模拟器、控制盒和测试输入及测试输出分析设备四个部分。被测试程序在目标机中运行，宿主机运行测试程序及处理测试结果，控制盒连接控制宿主机与目标机之间的总线，模拟器主要模拟一些特殊的信号。
|
|
|
|
由于嵌入式系统的特殊性，在进行配置项和系统测试时，要求或者在真实目标机中运行，或者在仿真环境下运行时必须说明仿真环境与真实环境的差异，并进行影响分析。而交联式模拟测试环境由于搭建较为方便，运行环境与真实环境一致，是目前嵌入式软件测试环境中使用最多的环境。所以在软件配置项和系统测试阶段，其实也是软件与硬件的集成测试阶段，虽然在进行软件测试，但是软件与硬件的协调性、一致性也进行了验证。
|
|
|
|
|
|
即将嵌入式软件完全置于真实的实物环境中进行测试，是系统测试阶段常用的测试环境。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
单元测试的对象是软件单元。软件单元测试的目的是检查每个软件单元能否正确地实现设计说明中的功能、性能、接口和其他设计约束等要求，发现单元内可能存在的各种错误。一般由软件的供方组织并实施软件单元测试，也可委托第三方进行软件单元测试。软件单元测试可根据软件单元的重要性、安全性关键等级等对如下技术要求内容进行剪裁，但必须说明理由。单元测试一般应符合以下的技术要求：
|
|
|
|
（1）在对软件单元进行动态测试之前，应对软件单元的源代码进行静态测试。
|
|
|
|
（2）应建立测试软件单元的环境，如桩模块和驱动模块，其测试环境应通过评审。
|
|
|
|
（3）对软件设计文档规定的软件单元的功能、性能、接口等应逐项进行测试。
|
|
|
|
（4）软件单元的每个特性应至少被一个正常测试用例和一个被认可的异常测试用例覆盖。
|
|
|
|
（5）测试用例的输入应至少包括有效等价类值、无效等价类值和边界数据值。
|
|
|
|
|
|
|
|
|
|
软件单元测试一般应采用静态测试方法和动态测试方法。通常静态测试先于动态测试。软件单元测试完成后形成的文档有：软件单元测试计划；软件单元测试说明；软件单元测试报告；软件单元测试记录；软件单元测试问题报告。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
配置项测试的对象是计算机软件配置项（CSCI，以下简称配置项），软件配置项是为独立的配置管理而设计的并且能满足最终用户功能的一组软件。软件配置项测试的目的是检验软件配置项与软件需求规格说明的致一性。配置项测试可根据软件配置项的重要性、安全性关键等级等对如下技术要求内容进行剪裁，但必须说明理由。配置项测试一般应符合以下技术要求：
|
|
|
|
|
|
（2）应逐项测试软件需求规格说明规定的配置项的功能、性能等特性。
|
|
|
|
（3）配置项的每个特性应至少被一个正常测试用例和一个被认可的异常测试用例所覆盖。
|
|
|
|
（4）测试用例的输入应至少包括有效等价类值、无效等价值和边界数据值。
|
|
|
|
|
|
（6）应测试人机交互界面提供的操作和显示界面，包括用非常规操作、误操作、快速操作测试界面的可靠性。
|
|
|
|
（7）应测试运行条件在边界状态和异常状态下，或在人为设定的状态下，配置项的功能和性能。
|
|
|
|
（8）应按软件需求规格说明的要求，测试配置项的安全性和数据的安全保密性。
|
|
|
|
（9）应测试配置项的所有外部输入、输出接口（包括和硬件之间的接口）。
|
|
|
|
（10）应测试配置项的全部存储量、输入／输出通道的吞吐能力和处理时间的余量。
|
|
|
|
（11）应按软件需求规格说明的要求，对配置项的功能、性能进行强度测试。
|
|
|
|
（12）应测试设计中用于提高配置项的安全性和可靠性的方案，如结构、算法、容错、冗余、中断处理等。
|
|
|
|
（13）对安全性关键的配置项，应对其进行安全性分析，明确每一个危险状态和导致危险的可能原因，并对此进行针对性的测试。
|
|
|
|
（14）对有恢复或重置功能需求的配置项，应测试其恢复或重置功能和平均恢复时间，并且对每一类导致恢复或重置的情况进行测试。
|
|
|
|
|
|
应保证软件配置项测试工作的独立性。软件配置项测试一般由软件的供方组织，由独立于软件开发的组织实施。软件配置项测试一般应采用黑盒测试方法。
|
|
|
|
软件配置项测试完成后形成的文档有：软件配置项测试计划；软件配置项测试说明；软件配置项测试报告；软件配置项测试记录；软件配置项测试问题报告。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
对设计部分是否完整地实现了需求中规定的功能、性能等要求，设计方法的可行性，关键的处理及内外部接口定义的正确性、有效性、各部分之间的一致性等都一一进行评审。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
总体设计阶段以比较抽象概括的方式提出了解决问题的办法。详细设计阶段的主要任务就是对每个模块完成的功能进行具体描述，也就是回答下面这个关键问题：“应该怎样具体地实现这个系统？”因此，详细设计阶段的任务是设计出模块的详细规格说明，该说明应该包含必要的细节，可以根据它们对模块进行单独实现。通常采用HIPO（层次加输入／处理／输出图）或PDL语言（过程设计语言）描述详细设计的结果。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
需求分析阶段的任务不是具体地解决问题，而是准确地确定产品必须做什么，确定系统的功能、性能、数据和界面等要求，从而确定系统的逻辑模型。嵌入式软件需求需要说明硬件接口的必要特征、细节以及输入／输出等。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
GSM俗称“全球通”，是一种起源于欧洲的移动通信技术标准，是第二代移动通信技术，其开发目的是让全球各地可以共同使用一个移动电话网络标准，让用户使用一部手机就能行遍全球。
|
|
|
|
GSM系统包括GSM 900（900MHz）、GSM1800（1800MHz）及GSM1900（1900MHz）等几个频段。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
V模型是最具有代表意义的测试模型，如下图所示。V模型最早是由Paul Rook在20世纪80年代后期提出的，V模型在英国国家计算中心文献中发布，旨在改进软件开发的效率和效果。
|
|
|
|
在传统的开发模型中，比如瀑布模型，人们通常把测试过程作为在需求分析、概要设计、详细设计和编码全部完成之后的一个阶段，尽管有时测试工作会占用整个项目周期一半的时间，但是有人仍然认为测试只是一个收尾工作，而不是主要的过程。V模型的推出就是对此种认识的改进。V模型是软件开发瀑布模型的变种，它反映了测试活动与分析和设计的关系，从左到右，描述了基本的开发过程和测试行为，非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系，如模型图（下图）中所示，图中的箭头代表了时间方向，左边下降的是开发过程各阶段，与此相对应的是右边上升的部分，即各测试过程的各个阶段。
|
|
|
|
|
|
|
|
V模型的软件测试策略既包括低层测试又包括了高层测试，低层测试是为了源代码的正确性，高层测试是为了使整个系统满足用户的需求。
|
|
|
|
V模型指出，单元和集成测试是验证的程序设计，开发人员和测试组应检测程序的执行是否满足软件设计的要求；系统测试应当验证系统设计，检测系统功能、性能的质量特性是否达到系统设计的指标；由测试人员和用户进行软件的确认测试和验收测试，追溯软件需求说明书进行测试，以确定软件的实现是否满足用户需求或合同的要求。
|
|
|
|
V模型存在一定的局限性，它仅仅把测试过程作为在需求分析、概要设计、详细设计及编码之后的一个阶段。容易使人理解为测试是软件开发的最后的一个阶段，主要是针对程序进行测试寻找错误，而需求分析阶段隐藏的问题一直到后期的验收测试才被发现。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
①一般能力：包括表达、交流、协调、管理、质量意识、过程方法、软件工程等；
|
|
|
|
②测试技能及方法：包括测试基本概念及方法、测试工具及环境、专业测试标准、工作成绩评估等；
|
|
|
|
③测试规划能力：包括风险分析及防范、软件放行/接收准则制定、测试目标及计划、测试计划和设计的评审方法等；
|
|
|
|
④测试执行能力：包括测试数据/脚本/用例、测试比较及分析、缺陷记录及处理、自动化工具；
|
|
|
|
⑤测试分析、报告和改进能力：包括测试度量、统计技术、测试报告、过程监测及持续改进。
|
|
|
|
|
|
|
|
|
|
. Y理论：经理的职能不是督促人们工作，而是使人们有可能工作。
|
|
|
|
|
|
|
|
|
|
. 社会需要——团队归属感，互相认同、理解和支持；
|
|
|
|
. 自尊需要——具有受人尊重/赏识的能力或/和业绩；
|
|
|
|
|
|
|
|
. 管理者习惯用对自己有效的因素激励测试人员，很可能发现无效；
|
|
|
|
. 过多使用权力、资金或处罚手段很可能导致项目失败；
|
|
|
|
. 行业领先企业采取卓有成效的非货币形式的激励措施；
|
|
|
|
. 在项目进行过程中，而不仅是在项目结束时实施激励措施；
|
|
|
|
|
|
. 对人员的工作表现出真诚的兴趣是对他们最好的奖励；
|
|
|
|
. 激励因素是因人而异、因时而异的。已经满足的需要很可能不再成为激励因素。
|
|
|
|
|
|
测试工作的快乐哲学：选择积极的态度，把工作当作游戏，让别人快乐，全身心投入工作。
|
|
|
|
注意测试工作的7条效率原则：主动思考，积极行动；一开始就牢记目标，不迷失方向；重要的事情放在首位（但常常把紧急的事情放在首位）；先理解人，后被人理解；寻求双赢；互相合作，追求1＋1>2；终生学习，自我更新，不断进步。
|
|
|
|
|
|
|
|
. 1~2年，测试技能：熟悉整个测试过程及产品业务领域，学习和掌握自动测试工具，学习测试自动化编程技术；开发和执行测试脚本，承担系统测试实施任务；掌握编程语言、操作系统、网络与数据库方面的技能。
|
|
|
|
. 3~4年，测试过程：深入了解测试过程，掌握测试过程设计及改进，参与软件工作产品的同行评审；进一步了解产品业务领域，改进测试自动化编程技术；能指导初级测试工程师；加强编程语言、操作系统、网络与数据库方面的技能。
|
|
|
|
. 4~5年，测试组织工作：管理1~3名测试工程师，担任任务估算、管理及进度控制；进一步培养在软件项目管理及支持工具方面的技能。
|
|
|
|
. 5~6年，技术管理：管理4~8名测试工程师，提高任务估算、管理及进度控制能力，完成测试规划并制定测试计划；研究测试的技术手段，保持使用项目管理及支持工具的技能；用大量时间为其他测试工程师提供技术及过程方面的指导；开始与客户打交道并做演示推介。
|
|
|
|
. 6~12年，测试管理：管理8名以上测试工程师，负责一个或多个项目的测试工作；与客户打交道并做演示推介；保持使用项目管理及支持工具的技能。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
目的：对运行维护服务能力进行整体策划并提供必要的资源支持，以确保供方有能力提供运行维护服务。
|
|
|
|
|
|
.根据自身业务定位和能力，策划运行维护服务对象的服务内容与要求，并形成服务目录。
|
|
|
|
.依据组织的业务发展需要来建立组织结构和管理制度，支持服务目录的实施或实现。
|
|
|
|
.对人员、资源、技术和过程进行规划，建立相适应的指标体系和服务保障体系。
|
|
|
|
.策划如何管理、审核并改进服务质量，建立内部审核评估机制。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
设计软件系统总体结构的基本任务是采用某种设计方法，将一个复杂的系统按功能划分成模块；确定每个模块的功能；确定模块之间的调用关系；确定模块之间的接口，即模块之间传递的信息；评价模块结构的质量。
|
|
|
|
|
|
（1）数据结构的设计。在需求分析阶段，已经通过数据字典对数据的组成、操作约束和数据之间的关系等方面进行了描述，确定了数据的结构特性，在概要设计阶段要加以细化，详细设计阶段则规定具体的实现细节。在概要设计阶段，宜使用抽象的数据类型。
|
|
|
|
（2）数据库的设计。数据库的设计是指数据存储文件的设计，主要指以下几个方面。
|
|
|
|
①概念设计。在数据分析的基础上，采用自底向上的方法从用户角度进行视图设计，一般用ER模型来表述数据模型。
|
|
|
|
②逻辑设计。ER模型是独立于数据库管理系统（DBMS）的，要结合具体的DBMS特征来建立数据库的逻辑结构。
|
|
|
|
③物理设计。物理设计就是设计数据模式的一些物理细节，如数据项存储要求、存取方法和索引的建立等。
|
|
|
|
|
|
文档主要有概要设计说明书、数据库设计说明书、用户手册以及修订测试计划。
|
|
|
|
|
|
对设计部分是否完整地实现了需求中规定的功能、性能等要求，设计方法的可行性，关键的处理及内外部接口定义的正确性、有效性以及各部分之间的一致性等都一一进行评审。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
主要包括故障监控和性能、流量、负载等状态监控，这些监控关系到集群的健康运行及潜在问题的及时发现与干预。
|
|
|
|
（1）服务故障、状态监控：主要是对服务器自身、上层应用、关联服务数据交互监控；例如针对前端Web Server，就可以有很多种类型的监控，包括应用端口状态监控，便于及时发现服务器或应用本身是否崩溃、通过ICMP包探测服务器健康状态，更上层可能还包括应用各频道业务的监控，这些只是一部分，还有多种监控方式，依应用特点而定。还有一些问题需解决，如集群过大，如何高性能地进行监控也是一个现实问题。
|
|
|
|
（2）集群状态类的监控或统计，为合理管理调优集群提供数据参考，包括服务瓶颈、性能问题、异常流量、攻击等问题。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
电子商务应用系统开发模型是描述系统开发过程中各种活动如何执行的模型。系统生命周期模型确立了开发和演绎中各阶段的次序限制以及各阶段或机动的准则，确立开发过程所遵守的规定和限制，便于各种活动的协调，便于各种人员的有效通信，有利于活动重用，有利于活动管理。常见的生命周期模型有如下5个模型。
|
|
|
|
|
|
瀑布模型是将软件生命周期各个活动规定为依线性顺序连接的若干阶段的模型。它包括可行性分析、项目开发计划、需求分析、概要设计、详细设计、编码、测试和维护。它规定了由前至后、相互衔接的固定次序，如同瀑布流水，逐级下落。
|
|
|
|
瀑布模型为软件的开发和维护提供了一种有效的管理模式，根据这一模式制定开发计划，进行成本预算，组织开发力量，以项目的阶段评审和文档控制为手段有效地对整个开发过程进行指导，所以它是以文档作为驱动、适合于软件需求很明确的软件项目的模型。
|
|
|
|
但是，瀑布模型在大量的软件开发实践中也逐渐暴露出它的严重缺点。它是一种理想的线性开发模式，缺乏灵活性，特别是无法解决软件需求不明确或不准确的问题。
|
|
|
|
快速原型模型（Rapid Prototype Model）
|
|
|
|
快速原型模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么。
|
|
|
|
第二步则在第一步的基础上开发客户满意的软件产品。显然，快速原型方法可以克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险，具有显著的效果。
|
|
|
|
快速原型的关键在于尽可能快速地建造出软件原型，一旦确定了客户的真正需求，所建造的原型将被丢弃。因此，原型系统的内部结构并不重要，重要的是必须迅速建立原型，随之迅速修改原型，以反映客户的需求。
|
|
|
|
|
|
增量模型又称演化模型。大量的软件开发实践表明，许多开发项目在开始时对软件需求的认识是模糊的，因此很难一次开发成功。为了减少因对软件需求的了解不够确切而给开发工作带来的风险，可以在获取了一组基本的需求后，通过快速分析构造出该软件的一个初始可运行版本，这个初始的软件通常称为原型，然后根据用户在使用原型的过程中提出的意见和建议对原型进行改进，获得原型的新版本。在使用增量模型时，第一个增量往往是实现基本需求的核心产品。核心产品交付用户使用后，经过评价形成下一个增量的开发计划，它包括对核心产品的修改和一些新功能的发布。这个过程在每个增量发布后不断重复，直到产生最终的完善产品。增量模型特别适用于对软件需求缺乏准确认识的情况。
|
|
|
|
|
|
对于复杂的大型软件，开发一个原型往往达不到要求。螺旋模型将瀑布模型和增量模型结合起来，加入了两种模型均忽略的风险分析，弥补了这两种模型的不足。
|
|
|
|
螺旋模型将开发过程分为几个螺旋周期，每个螺旋周期大致和瀑布模型相符合。在每个螺旋周期分为如下四个工作步骤。
|
|
|
|
①制订计划。确定软件的目标，选定实施方案，明确项目开发的限制条件。
|
|
|
|
|
|
|
|
④用户评估。评价开发工作，提出修正建议，建立下一个周期的开发计划。
|
|
|
|
喷泉模型（Water Fountain Model）
|
|
|
|
喷泉模型是一种以用户需求为动力，以对象作为驱动的模型，适合于面向对象的开发方法。它克服了瀑布模型不支持软件重用和多项开发活动集成的局限性。喷泉模型使开发过程具有迭代性和无间隙性。迭代意味着模型中的开发活动常常需要重复多次，在迭代过程中不断地完善软件系统。无间隙是指在开发活动（如分析、设计、编码）之间不存在明显的边界，也就是说，它不像瀑布模型那样，需求分析活动结束后才开始设计活动，设计活动结束后才开始编码活动，而是允许各开发活动交叉、迭代地进行。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
GB/T 11457—2006对配置项的定义为：“为配置管理设计的硬件、软件或二者的集合，在配置管理过程中作为一个单个实体来对待。”配置项的例子有：交付的软件产品和数据，用于创建或支持软件产品的支持工具，供应商提供的软件和客户提供的设备/软件，各类文档，源代码，可执行代码，测试用例，运行软件所需的各种数据等。
|
|
|
|
在信息系统的开发过程中需加以控制的配置项可以分为基线配置项和非基线配置项两类。例如，基线配置项可能包括所有的设计文档和源程序等；非基线配置项可能包括项目的各类计划和报告等。所有配置项的操作权限应由CMO（配置管理员）严格管理，基本原则是：基线配置项向开发人员开放读取的权限；非基线配置项向PM、CCB及相关人员开放。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
在进行需求获取之前，首先要明确需要获取什么，也就是需求包含哪些内容。软件需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。通常，这些需求包括功能需求、性能需求、用户或人的因素、环境需求、界面需求、文档需求、数据需求、资源使用需求、安全保密需求、可靠性需求、软件成本消耗与开发进度需求等，并预先估计以后系统可能达到的目标。此外，还需要注意其他非功能性的需求。具体内容如下。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
需求分析主要是确定待开发软件的功能、性能、数据、界面等要求。具体来说有下面几点。
|
|
|
|
（1）确定软件系统的综合要求，包括系统界面、功能、性能、安全性、保密性、可靠性、运行等方面的要求。
|
|
|
|
（2）分析软件系统的数据要求，包括基本数据元素、数据元素之间的逻辑关系、数据量、峰值等。
|
|
|
|
（3）导出系统的逻辑模型，在结构化方法中可用数据流图来描述；在面向对象分析方法中可以用类模型来描述。
|
|
|
|
|
|
（5）如有必要，可开发一个原型系统以验证用户的需求。
|
|
|
|
|
|
|
|
（1）功能需求。所开发的软件必须具备什么样的功能。
|
|
|
|
（2）非功能需求。它是指产品必须具备的属性或品质，如可靠性、性能响应时间、容错性和可扩展性等。
|
|
|
|
（3）设计约束。其也称为限制条件、补充规约，这通常是对解决方案的一些约束说明。
|
|
|
|
|
|
需求分析方法由对软件的数据域和功能域的系统分析过程及其表示方法组成。它定义了表示系统逻辑视图和物理视图的方式。大多数的需求分析方法是由数据驱动的，数据域具有数据流、数据内容和数据结构3种属性。通常一种需求分析方法总要利用其中一种或几种属性。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
（1）了解建设单位的建设需求和对信息系统安全性的要求，协助建设单位制定项目质量目标规划和安全目标规划。
|
|
|
|
|
|
（3）进行设计过程跟踪，及时发现质量问题，并及时与承建单位协调解决。审查阶段性成果，并提出监理意见。审查承建单位提交的总体设计方案，审查承建单位对关键部位的测试方案。
|
|
|
|
|
|
|
|
（6）组织设计文件及设计方案交底会，制定质量要求标准。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
计算机机房室内湿度也要适当并维持在稳定状态，湿度过高或过低同样会影响计算机系统的正常工作。在计算机开关机和工作期间，若空气中的湿度过高，会引起电路板涨大变形，难以插拔；高温潮湿的条件还会使金属生锈、腐蚀而发生漏电、短路故障；湿度过高还会增加触点的接触电阻，影响机器的正常运行，使机器提前老化。若湿度过低，则极易产生静电，在低湿度的机房中，人在地板上行走、触摸设备、机械的摩擦部分等都会产生静电感应，对机器设备的正常工作带来不利影响。工作室里的湿度应保持在20%～80%为宜，在雨水季节要特别注意防水、防潮，对于长期间不使用的计算机要定期开机一段时间，以驱除机器内部的潮气，防止结露。为此计算机机房应配备湿度检测仪、除湿机、增湿机，定时测试空气中的湿度，以保证计算机在安全适宜的环境中工作。
|
|
|
|
电子计算机机房内温、湿度应满足下列要求，开机时主机房的温、湿度应执行A级，基本工作间可根据设备要求按A、B两级执行，其他辅助房间应按工艺要求确定。
|
|
|
|
（1）开机时电子计算机机房内的温、湿度，应符合下表的规定。
|
|
|
|
|
|
|
|
（2）停机时电子计算机机房内的温、湿度，应符合下表的规定。
|
|
|
|
|
|
|
|
（3）记录介质库的温、湿度应符合下列要求，常用记录介质库的温、湿度应与主机房相同，其他记录介质库的要求应按下表的规定。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
视频是动态的画面序列，这些画面以超过每秒24帧的速度播放，便可以使观察者产生平滑、连续的视觉效果。视频类似于我们熟知的电影和电视，有声有色。电影采用了每秒24幅画面的播放速度，电视采用了每秒25幅或30幅画面的播放速度。视频图像可来自于录像带、影碟、电视、摄像机等，这些模拟视频信号可通过视频采集卡转换成数字视频信号，以便计算机进行处理和存储。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
无线传感器网络（Wireless Sensor Networks, WSN）是一种分布式传感网络，它的末梢是可以感知和检查外部世界的传感器。WSN中的传感器通过无线方式通信，因此网络设置灵活，设备位置可以随时更改，还可以与互联网进行有线或无线方式的连接，通过无线通信方式形成一个多跳自组织网络。
|
|
|
|
无线传感器网络是由大量静止或移动的传感器以自组织和多跳的方式构成的无线网络，以协作地感知、采集、处理和传输网络覆盖地理区域内被感知对象的信息，并最终把这些信息发送给网络的所有者。
|
|
|
|
无线传感器网络所具有的众多类型的传感器可以探测包括地震、电磁、温度、湿度、噪声、光强度、压力、土壤成分、移动物体的大小、速度和方向等周边环境中多种多样的现象。潜在的应用领域为军事、航空、防爆、救灾、环境、医疗、保健、家居、工业、商业等。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
这方面的应用更加贴近人们的生活，这是关系到人们生活起居、与生命安全息息相关的应用，我们可以通过智能家居的物联网络，进行室内到室外的电控、声控、感应控制、健康预警、危险预警等，比如声控电灯、窗帘按时间自动挂起、感应器感应到煤气泄漏、空气污染指数过高、室内的光线被家具遮挡严重、室内家居摆放设计、马桶漏水、电量煤气不足报警、车库检测、室外摄像检测、未来天气预测、提醒带雨伞、生活备忘录电子智能提醒等多方面的功能应用。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
测试环境是由测试数据、硬件配置、软件、接口、网络、人员、手册、设备等所有用于支持测试工作的元素组成的集合。一个好的测试环境应该是稳定的、可重复的，它不仅能达到测试执行的技术要求，并且能够得到正确的、可重复的测试结果。下面介绍部分环境的配置。
|
|
|
|
硬件环境指测试必需的服务器、客户端、网络连接设备以及打印机／扫描仪等外部设备所构成的环境。硬件配置必须要达到系统运行的最低要求，确保能支持软件正常运行。另一方面，由于不同的用户可能会在硬件方面存在细微的差别，但要在测试环境中对每一种环境进行设计是不现实的。因此，实际的做法是通过抽样调查等方式得出一系列配置文件，归纳出一些常见的配置分情况进行测试。
|
|
|
|
软件环境指被测软件运行时的操作系统、数据库及其他应用软件构成的环境。与硬件环境类似，在测试时应尽量选择几种比较普遍的软件平台（操作系统、数据库及其他支持系统运行的应用软件），对每种配置分别进行测试，检验系统的兼容性，同时要保证测试的软件环境是无病毒的。需要注意的是，为了更好地模拟系统运行的真实环境，软件环境中还应当包括用户常用的驻留于测试环境之中的其他应用程序，这些共驻软件可能并不与被测程序进行交互。
|
|
|
|
测试中的人员主要有测试经理、测试文档审核师、测试设计师和测试工程师。进行测试时，需要有不同人员的参与，包括具有一定开发经验的计算机专业人员、业务人员及非专业人员。
|
|
|
|
|
|
|
|
.系统测试由于工作量非常大，其测试队伍包括开发员、QA人员、用户、技术文员、售后服务人员、培训人员等；
|
|
|
|
.验收测试应当主要由使用系统的人来完成，包括用户、客户服务代表、培训员、市场营销员及其他测试人员等。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
简而言之，就是将我们日常手动进行的一些工作通过工具，系统自动来完成，解放我们的双手，例如：没有工具前，我们安装系统需要一台一台裸机安装，如2000台，可能需要10人/10天，而现在通过自动化工具，只需几个简单命令就能解决这个问题。还有如机器人类程序，自动完成以往每天人工干预的工作，使其自动完成、汇报结果，并具备一定的专家系统能力，能做一些简单的是／非判断、优化选择等。应该说，自动化运维是运维工程师职业化的一个追求，利己利公，虽然这是一个异常艰巨的任务，不断变更的业务、不规范化的应用设计、开发模式、网络架构变更、IDC变更、规范变动等因素，都可能会对现有自动化系统产生影响，所以需要模块化、接口化等工作。自动化相关工作，是运维工程师的核心重点工作之一，也是价值的体现。
|
|
|
|
总结一下运维中关键技术：大量高并发网站的设计方案；高可靠、高可伸缩性网络架构设计；网站安全问题，如何避免被黑？南北互联问题，动态CDN解决方案；海量数据存储架构。
|
|
|
|
|
|
|
|
|
|
|
|
|
.png)
