1.系统测试

系统测试是为了发现错误而执行程序的过程，成功的测试是发现了至今尚未被发现的错误的测试。
测试原则：
1）应尽早并不断的进行测试
2）测试工作应避免由原开发软件的人或小组承担
3）在 设计测试方案时，不仅要确定输入数据，而且要根据系统功能确定预期的输出结果
输出结果：
1）既包含有效、合理的测试用例，也包含不合理、失效的用例
2）检验程序是否做了不该做的事，且是否做了不该做的事
3）严格按照测试计划进行
4）妥善保存测试计划和测试用例
5）测试用例可以重复使用或追加测试

1.1.静态测试和动态测试

静态测试：被测试的程序不在机器上运行，而采用人工检测和计算机辅助静态分析的手段对程序进行检测，包括对文档的静态测试和对代码的静态测试。对文档的静态测试主要以检查单的形式进行，而对的代码的静态测试，包括桌前检查、代码审查、代码走查的方式。

动态测试：被测程序在机器上运行
动态测试方法：
1）黑盒测试，功能性测试，不了解软件代码结构，根据功能设计用例，测试软件功能。
2）白盒测试，结构性测试，明确代码流程，根据代码逻辑设计用例，进行用例覆盖。
3）灰盒测试，黑盒+白盒

1.2.测试阶段

1）单元测试：模块测试，测试对象是可独立编辑或汇编的程序模块、软件构建、OO软件种的类，测试依据是软件详细设计说明书。
2）集成测试：目的是检查模块之间，以及模块和以集成的软件之间的接口关系，并验证已集成的软件是否符合设计要求。测试依据是软件概要设计文档。
3）确认测试：主要用于验证软件的功能、性能和其他特性是否与用户需求一致。根据用户的参与程度，通常包括以下类型：
a.内部确认测试：主要由软件开发组织内部按照SRS进行测试。
b.Alpha测试：用户在开发环境下进行测试。
c.Beta测试：用户实际环境下进行测试，通过该测试后，产品才能交付用户。
d.验收测试：针对SRS（软件需求规格说明书），在交付之前以用户为主进行的测试。其测试对象为完整的、集成的计算机系统。验收测试的目的是，在真实的用户工作环境下，检验软件系统是否满足开发技术合同或SRS。验收测试的结论是用户确定是否接收该软件的主要依据。除应满足一般测试的准入条件外，在进行验收测试之前，应确认被测软件已通过系统测试。
4）系统测试：测试对象是完整的、集成的计算机系统；测试的目的是在真实系统工作环境下，验证完成的软件配置项和系统正确连接，并满足系统/子系统设计文档和软件开发合规格要求。测试依据是用户需求或开发合同。主要内容包括功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、安装与反安装测试等，其中最重要的工作是进行功能测试与性能测试。功能测试主要采用黑盒测试，性能测试主要指标有响应时间、吞吐量、并发用户数和资料员利用率等。
5）配置项测试：测试对象是软件配置项，测试目的是检验软件配置项SRS的一致性。测试依据是SRS，在此之前，应确认被测软件配置项已通过单元测试和集成测试。
6）回归测试：测试的目的是测试软件变更之后，变更的部分的正确性和对变更需求的符合性，以及软件原有的、正确的功能、性能和其他规定的要求的不损害性。

1.3.测试策略

1）自底向上：从最底层模块开始测试，需要编写测试驱动程序，而后开始逐一合并模块，最终完成整个系统的测试。优点是较早的验证了底层模块。
2）自顶向下：先测试整个系统，需要编写桩程序，而后逐步向下直到最后测试最底层模块。优点是较早的验证了系统的主要控制和判断点。
3）三明治：既有自底向上也有自顶向下的测试方法，二者都包括。兼有二者的优点，缺点是测试工作量大。

1.4.测试用例

1.4.1.黑盒测试用例

1）等价类划分：把所有数据按某种特性进行归类，而后在每类数据里选一个即可。等价类测试的用例设计原则：设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖的有效等价类，重复这一步，直到所有有效等价类都被覆盖位置。设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直到所有的无效等价类都被覆盖为止。
2）边界值划分：将每类的边界值作为测试用例，边界值的范围一般为范围两端值以及在此范围之外的与此范围间隔最小的两个值。如年龄范围 在0-150时，边界值由0,150，-1,151
3）错误推测：没有固定方法，凭经验而言，推测可能有问题的地方。
4）因果图：由一个结果来反推原因的方法，具体结果具体分析。

1.4.2.白盒测试用例

1）语句覆盖SC：逻辑代码中所有语句都要执行一遍覆盖级别最低，因为执行了所有的语句，不代表执行了所有的判断条件。
2）判定覆盖DC：逻辑代码中所有判断语句的条件的真假分支都要覆盖一次。
3）条件覆盖CC：针对每个判断条件内的每一个独立条件都要执行一遍真和假。
4）条件判定组合覆盖CDC：同时满足判定覆盖和条件覆盖。
5）路径覆盖：逻辑代码中的所有可行路径都覆盖了，，覆盖级别最高。

1.5.调试

找出错误的代码和原因
方法：蛮力法、回溯发、原因排除法（演绎法、归纳法、二分法）

1.6.软件度量

软件有两种属性：外部属性和内部属性。
外部属性：面向管理者和用户的属性，可直接测量，一般为性能指标。
内部属性：软件产品本身的属性，如可靠性等，只能间接测量。

McCabe度量法：又称环路复杂度，假设有向图中有向边数为m，节点数为n，则此有向图的环路复杂度为m-n+2

2.系统运行维护

2.1.系统转换

遗留系统是指任何基本上不能进行修改和演化以满足新的变化了的业务需求的信息系统，它通常具有一下特点：
1）系统虽然完成企业中许多重要的业务管理工作，但仍不能完全满足需求。
2）系统性能上已经落后，采用的技术已经过时。
3）通常是大型软件系统，已经融入企业的的业务运作和决策管理机制中，维护工作十分困难。
4）没有使用现代化系统建设方法进行管理和开发，现在基本上已经没有文档，很难理解。

系统转换是指新系统开发完毕，投入运行，取代现有系统的过程。三种转换计划：
1）直接转换：现有系统被新系统直接取代了。节省成本，风险大。
2）并行转换：新系统和老系统并行工作了一段时间。风险小，耗费人力资源、时间资源，难以控制两个系统之间的数据转换。
3）分段转换：分期分批逐步转换。将大型系统分为多个子系统。耗时，需要协调好接口问题。

数据迁移与转换：将数据从就数据库迁移到新数据库。三种方式：
1）系统切换前通过工具迁移
2）系统切换前采用手工录入
3）系统切换后通过新系统生成

2.2.系统维护

可维护性：维护人员理解、改正、改动和改进这个软件的难易程度。评价指标：
1）易分析性：软件产品诊断软件中的缺陷或失效原因或识别待修改部分的能力。
2）易改变性：软件产品使指定修改可以被实现的能力，实现包括编码、设计和文档的更改。
3）稳定性：软件产品避免由于软件修改而改造成意外结果的能力。
4）易测试性：软件产品使已修改软件能被确认的能力。
5）维护性的依从性：软件产品遵循与维护性相关的指标或约定的能力。

系统维护包括：硬件维护、软件维护和数据维护，其中软件维护类型有：
1）正确性维护：发现了bug而进行的修改。
2）适应性维护：由于外部环境发生了改变，别动进行的对软件的修改和适应。
3）完善性维护：基于用户主动对软件提出更多的需求，修改软件，增加更多功能，使其比之前的软件功能更多、性能更高、更加完善。
4）预防性维护：对未来可能发生的bug进行预防性的修改。

2.3.净室软件工程CSE

定义：是一种应用数学与统计学理论以经济的方式生产高质量软件的工程技术。力图通过严格的工程化软件的过程达到开发中的零缺陷或接近零缺陷。净室方法不是先制作一个产品，再去消除缺陷，而是要求在规约和设计中消除错误，然后以净的方式制作，可以降低软件开发中的风险，以合理的成本开发出高质量的软件。

哲理：通过在第一次正确地书写代码增量，并在测试前验证它们的正确性，来避免对成本很高对的错误消除过程的依赖。它的过程模型是在代码增量积聚到系统的过程的同时，进行代码增量的统计质量验证。它甚至提倡开发者不需要进行单元测试，而是进行正确性验证和统计质量控制。它甚至提倡开发者不需要进行单元测试，而是进行正确行验证和统计质量控制。

理论基础：函数理论和抽样理论。

应用技术手段：
1）统计过程控制下的增量式开发
2）基于函数的规范和设计
3）正确性验证-CSE的核心
4）统计测试和软件认证

缺点：
1）太理论化，需要更多的数学知识。其正确性验证的步骤比较困难且比较耗时
2）CSE开发小组不进行传统的模块测试，不现实
3）本身也会带有传统软件工程的弊端。

2.4.基于构建的软件工程CBSE

2.4.1.CBSE

基于分布对象技术，强调通过可复用构件设计与构造软件系统的软件复用途径。CBSE体现了“购买而不是重新构造”的哲学，将软件开发的重点从程序编写转移到了基于已有构建的组装。用于CBSE的构件应具备一下特征：
1）可组装性，对于可组装的构件，所有外部交互必须通过公开定义的接口进行。同时它还必须对自身信息的外部访问。
2）可部署性，软件必须是自包含的，必须能作为一个独立实体在提供其构建模型实现的构建平台上运行。构件是二进制形式，无须在部署前编译。
3）文档化，构件必须是完全文档化的，用户根据文档来判断构件是否满足需求。
4）独立化，构件应该是独立的，应该可以在无其他特殊构件的情况下进行组装和部署，如确实需要其他构件提供的服务，则应显示声明。
5）标准化，构件标准化意味着在CBSE过程中使用的构件必须符合某种标准化的模型。

构件模型定义了构件实现、文档化以及开发的标准，其包含的模型要素为：
1）接口，构件通过构件接口来定义，构件模型规定应如何定义构件接口以及在接口定义中应该包含的要素，如操作名、参数以及异常等。
2）使用信息，为使构件的远程分布和访问，必须给构件一个特定的、全局唯一的名字或句柄。构件元数据是构件本身相关的数据，比如构件的接口和属性信息。
3）部署，构件模型包括一个规格说明，指出应该如何打包构件使其部署成一个独立的可执行实体。部署信息中包含有关包中内容的信息和它的二进制构成的信息。

构件模型提供了一组被构件使用的通用服务，包括以下两种：
1）平台服务，允许构件在分布式环境下通信和互操作
2）支持服务，这是很多构件需要的共性服务。例如，构件都需要的身份认证服务。中间件实现共性的构建服务，并提供这些服务的接口。

CBSE的六个主要活动：
系统需求概览、识别候选构件、根据发现的构件修改需求、体系结构设计、构件定制与适配、组装构件创建系统。

CBSE过程与传统软件开发过程的不同点：
1）CBSE早期需要完整的要求，以便尽可能多地识别出可复用的构件。
2）在过程早期阶段可利用的构件来细化和修改需求。如果可利用的构件不能满足用户需求，就应该考虑由复用构件支持的相关需求。
3）在系统体系结构设计完成后，会有一个进一步的对构件搜索及设计精化的活动。可能需要为某些构件寻找备用构件，或者修改构件以适应功能和架构的要求。
4）开发就是将已经找到的构件集成在一起的组装过程。

2.4.2.构件组装

是指构件相互直接集成或是用专门编写的胶水代码将它们整合在一起来创造一个系统或另一个构件的过程。常见的组装构件有以下三种方式：
1）顺序组装，通过按顺序调用已存在的构件，可以用两个已经存在的构件来创造一个新的构件。上一个构件的输出为下一个构件的输入。
2）层次组装，一个构件直接调用自另一个构件所提供的服务。被调用的构件为调用的构件提供所需的服务。两者之间接口匹配兼容。
3）叠加组装，这种情况发生在两个或两个以上构件放在一起来创建一个新构件的时候。这个新构建合并了元构建的功能，从而对外提供了新的接口。外部应用可以通过新接口来调用原有构件的接口，而原有构件不互相依赖，也不互相调用。这种组装类型适合于构件是程序单元或构件是服务的情况。

构件组装的三种不兼容问题（通过编写适配器解决）：
1）参数不兼容，接口每一侧的操作有相同的名字，但是参数的类型和参数的个数不一样
2）操作不兼容，提供接口和请求接口的操作名不同
3）操作不完备，一个构件的提供接口是另一个构件请求接口的一个子集，或相反。