词法/语法分析、程序分析与程序变换、代码生成、内存管理、虚拟机、函数式语言的实现与优化。。。每个话题都能出不止一本书。
用到的算法/数据结构多如牛毛：
各种树、图为主，其他如栈、队列、散列表、并查集。。。
贪心、回溯、动态规划、遗传算法、矩阵变换。。
在一个问题下很难回答好。。 先简单介绍一下和图相关的。
1. 和什么图打交道
CFG(Control Flow Graph)
控制流图是对程序中分支跳转关系的抽象，描述程序所有可能执行路径
节点是语句集合（basic block)；
每个basic block有唯一入口和出口；
如果A到B有边，表示A执行完后可能执行B
PDG(Program Dependence Graph)
PDG在编译器中用得不多，常见于软件工程/安全相关的应用（程序切片、安全信息流等）
SSA(Single Static Assignment)
SSA简化了很多数据流分析问题。
其他图
DJ Graph, Loop Nesting Forest, Program Structure Tree等等。
可参考：IR for Program Analysis。下面主要介绍CFG
2. CFG初步处理
CFG构造
dominator树生成
在CFG中，如果A是B的dominator，则从程序入口执行到B的任意路径一定经过A
控制依赖分析
根据dominator和post-dominator分析依赖关系。数据依赖、控制依赖信息在自动并行化中尤其重要（如果循环的每次迭代都没有依赖，那么可以并行处理）
控制流图化简
在复杂度相同的情况下，CFG的规模影响算法的效果。如果一个CFG仅通过如下变换能化简为一个节点，则它是可化简的：
如果节点n有唯一的前驱，那么将其和其前驱合并为一个节点
如果节点存在到自身的边，那么将该边删除
构造SSA
SSA可以由CFG构造。
3. CFG与数据流分析
下面才进入主题。。
一般的文献介绍DFA（Data flow analysis），都会用几个基础的分析为例：Constant Propagation，Range propagation，Avaliable expressions，Reaching Definition。而Reaching Definition的一个应用，就是大家喜闻乐见的“跳转到定义处”（真要做到“智能”跳转并不简单）
这部分涉及东西较多，一些算法也和”图“并不直接相关，不再展开。
PS，很多DFA问题可以用graph reachability统一建模，强烈推荐此文：
Program analysis via graph reachability
⑵ linux依赖关系及软件编译更新
脑补……
因为你没有软件，所有这些事情都要自己动手。
ldd 可以读取每个可以运行的程序依赖的 so 文件。
objmp 好像也可以读取依赖的一些内容。
之后用读取的这些内容反推程序对应的软件包，之后把这些反推出来的软件包都重新编译。
一般来说 ldd 对应的 so 文件只要正确，一般函数接口就问题不大，当然并不绝对。
所以，这种情况，最好的解决办法是把所有系统都整体的重新编译一遍。
言外之意，用 tar 源代码升级系统基本函数库是一个典型的找抽行为。
看看 gentoo 的 gentoolkit 吧。这个东西有个 revdep-rebuild 命令他就是检测函数库依赖关系并且反推软件包重新编译的。
⑶ 编译器生成的汇编语句执行顺序为什么与C代码顺序不同
不影响语义的前提下编译器可以任意重排代码顺序；
在乱序执行（Out-of-Order）的CPU里，机器码的执行也可以不按照你在“汇编”层面上看到的顺序执行，只要不影响语义。
所以说这些中间步骤的顺序，作为底层细节平时不需要那么在意——它们多半跟原始源码的顺序是不一样的。
现代优化编译器优化的思路之一是“基于依赖的优化”（dependence-based optimization）。题主引用的CSAPP的例子：
int arith(int x, int y, int z) {
int t1 = x + y;
int t2 = z * 48;
int t3 = t1 & 0xFFFF;
int t4 = t2 * t3;
return t4;
}
所有涉及运算的值都是局部标量变量（local scalar variable），这是最便于编译器做分析的情况，所有依赖都可以显式分析。
由于整个函数没有分支，这里也不需要讨论控制依赖（control dependence），只要讨论数据依赖（data dependence）就好。
把数据依赖图画出来是个DAG（这里正好是棵树，特例了）：
x y z 48
\ / \ /
t1 0xFFFF t2
\ / /
t3 /
\ /
t4
优化必须要满足的约束是：每个节点求值之前，其子节点（依赖的数据源）必须要先求了值。
显然，t1和t2之间没有依赖关系，它们的相对求值顺序怎样重排都没关系。
有本我很喜欢的书，里面讲的是各种基于依赖的优化：Optimizing Compilers for Modern Architectures - A Dependence-based Approach
以上是理论部分。
================================================================
下面来看例子。
我们可以用一个实际编译器来看看CSAPP的例子编译出来的结果：
.text
# -- Begin arith
.p2align 4,,15
.globl arith
.type arith, @function
arith:
.p2align 4,,7
/*.L0:*/ /* Block BB[54:2] preds: none, freq: 1.000 */
movl 8(%esp), %edx /* ia32_Load T[139:10] -:1:22 */
addl 4(%esp), %edx /* ia32_Add Iu[141:12] -:2:14 */
movzwl %dx, %edx /* ia32_Conv_I2I Iu[142:13] -:4:15 */
imull 12(%esp), %edx /* ia32_IMul Iu[143:14] -:5:15 */
leal (%edx,%edx,2), %eax /* ia32_Lea Iu[144:15] -:5:15 */
shll $0x4, %eax /* ia32_Shl Iu[146:17] -:5:15 */
ret /* ia32_Return X[152:23] -:6:3 */
.size arith, .-arith
# -- End arith
这里用的是libFirm。可见它跟CSAPP书里所说的汇编的顺序又有所不同。这也是完全合理的。
这个编译结果的顺序是：
edx = y;
edx += x;
edx = zeroextend dx; // edx = edx & 0xFFFF
edx *= z;
eax = edx * 3;
eax <<= 4; // eax = eax * 16
也是完全符合依赖关系的约束的一种顺序。
之所以用libFirm举例是因为它的中间表示（Intermediate Representation）是一种程序依赖图（Program Dependence Graph），可以很方便的看出控制与数据依赖。把CSAPP那里例子对应的libFirm IR画出来，是这个样子的：
（这张图跟我前面画的数据依赖图正好是左右翻转的，不过意思一样。（这张图跟我前面画的数据依赖图正好是左右翻转的，不过意思一样。
Arg 0、1、2分别代表x、y、z。白色方块是普通数据节点，黄色方块是常量节点，蓝色方块是内存相关节点，红色方块是控制流节点，粉红色方块是特殊的开始/结束节点。）
某版LLVM生成的代码：
; MoleID = '/tmp/webcompile/_16355_0.bc'
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-ellcc-linux"
; Function Attrs: nounwind readnone
define i32 @arith(i32 %x, i32 %y, i32 %z) #0 {
entry:
%add = add nsw i32 %y, %x
%mul = mul nsw i32 %z, 48
%and = and i32 %add, 65535
%mul1 = mul nsw i32 %mul, %and
ret i32 %mul1
}
attributes #0 = { nounwind readnone "less-precise-fpmad"="false" "no-frame-pointer-elim"="false" "no-infs-fp-math"="false" "no-nans-fp-math"="false" "stack-protector-buffer-size"="8" "unsafe-fp-math"="false" "use-soft-float"="false" }
!llvm.ident = !{!0}
!0 = !{!"ecc 0.1.10 based on clang version 3.7.0 (trunk) (based on LLVM 3.7.0svn)"}
最终生成的x86汇编：
.text
.file "/tmp/webcompile/_15964_0.c"
.globl arith
.align 16, 0x90
.type arith,@function
arith: # @arith
# BB#0: # %entry
movl 8(%esp), %eax
addl 4(%esp), %eax
movzwl %ax, %eax
imull 12(%esp), %eax
shll $4, %eax
leal (%eax,%eax,2), %eax
retl
.Ltmp0:
.size arith, .Ltmp0-arith
.ident "ecc 0.1.10 based on clang version 3.7.0 (trunk) (based on LLVM 3.7.0svn)"
.section ".note.GNU-stack","",@progbits
GCC 4.9.2 x86-64：
arith(int, int, int):
leal (%rdx,%rdx,2), %eax
addl %edi, %esi
movzwl %si, %esi
sall $4, %eax
imull %esi, %eax
ret
Zing VM Server Compiler x86-64：
# edi: x
# esi: y
# edx: z
movl %edx, %eax
shll $0x4, %eax
leal (%rsi, %rdi, 1), %ecx
shll $0x5, %edx
addl %edx, $eax
movzwl %ecx, %edx
imull %edx, %eax
⑷ 编译器在编译阶段，究竟做哪些事情
1. 预处理首先源代码文件（.c/.cpp）和相关头文件（.h/.hpp）被预处理器cpp预编译成.i文件（C++为.ii）。预处理命令为：gcc –E hello.c –o hello.i预编译过程主要处理那些源代码中以#开始的预编译指令，主要处理规则如下：u 将所有的#define删除，并且展开所有的宏定义；u 处理所有条件编译指令，如#if，#ifdef等；u 处理#include预编译指令，将被包含的文件插入到该预编译指令的位置。该过程递归进行，及被包含的文件可能还包含其他文件。u 删除所有的注释//和 /**/；u 添加行号和文件标识，如#2 “hello.c” 2,以便于编译时编译器产生调试用的行号信息及用于编译时产生编译错误或警告时能够显示行号信息；u 保留所有的#pragma编译器指令，因为编译器须要使用它们。2. 编译编译过程就是把预处理完的文件进行一系列词法分析，语法分析，语义分析及优化后生成相应的汇编代码文件（.s）。编译的命令为：gcc –S hello.i –o hello.s或者从源文件直接输出汇编代码文件：gcc –S hello.c –o hello.s现在版本的GCC把预编译和编译两个步骤合并成一个步骤，由程序cc1来完成（C++为cc1plus）。3. 汇编汇编就是将汇编代码转变成机器可以执行的命令，生成目标文件（.o），汇编器as根据汇编指令和机器指令的对照表一一翻译即可完成。汇编的命令为：gcc –c hello.s –o hello.o或者从源文件直接输出目标文件：gcc –c hello.c –o hello.o4. 链接链接就是链接器ld将各个目标文件组装在一起，解决符号依赖，库依赖关系，并生成可执行文件。链接的命令为：ld –static crt1.o crti.o crtbeginT.o hello.o –start-group –lgcc –lgcc_eh –lc-end-group crtend.o crtn.o一般我们使用一条命令就可以完成上述4个步骤：gcc hello.c实际上gcc只是一些其它程序的包装，它会根据不同参数去调用预编译编译程序cc1、汇编器as、链接器ld。
⑸ Linux依赖关系到底是什么怎么解决
你想知道什么？依赖关系最简单的一个理解就是Windows上你玩游戏结果提示directx版本过低无法运行。以及常见的运行某个程序之后提示mfc71.dll未找到。还有就是用个软件结果安装说明上让你先去安装.net。Linux的依赖关系因为他的整个系统都是由各个不同的开发组开发的软件集合而成（这点不知道电话是不可能理解Linux依赖关系的起因的），每个软件都有不同的功能提供和调用。而Linux因为他的软件包组成可以很灵活，某些软件包不是必须的，有些软件功能可以有很多软件进行提供。所以有些软件互相之间的功能需求就需要“依赖关系”这种描述来进行说明控制。Windows也有这个问题，只不过因为整个系统是微软统一提供的，所以他可以进行版本接口公职，以及方便的通知附带多个版本的函数库和程序进行功能提供，以及强行的提供一些用户其实根本不需要的软件来提供Windows程序的“依赖关系”。依赖关系很明显的就是一些超高精简的XP去掉的内容会导致很多软件不能运行。可以说，简单的去掉IE，就可以让很多Windows程序失去依赖关系而不能运行。Linux的软件包管理器就是有解决这个问题而设计的原因。软件包管理器通过分析软件包里面的描述信息和系统当前安装情况的数据库来确定依赖关系是否满足和如何满足依赖关系（也就是需要再安装哪些软件才行）。
⑹ 什么是编译器
编译器，是将便于人编写，阅读，维护的高级计算机语言翻译为计算机能识别，运行的低级机器语言的程序。编译器将源程序（Source program）作为输入，翻译产生使用目标语言（Target language）的等价程序。源程序一般为高级语言（High-level language），如Pascal，C++等，而目标语言则是汇编语言或目标机器的目标代码（Object code），有时也称作机器代码（Machine code）。
一个现代编译器的主要工作流程如下：
源程序（source code）→预处理器（preprocessor）→编译器（compiler）→汇编程序（assembler）→目标程序（object code）→连接器（链接器，Linker）→可执行程序（executables]）
工作原理
翻译是从源代码（通常为高级语言）到能直接被计算机或虚拟机执行的目标代码（通常为低级语言或机器言）。然而，也存在从低级语言到高级语言的编译器，这类编译器中用来从由高级语言生成的低级语言代码重新生成高级语言代码的又被叫做反编译器。也有从一种高级语言生成另一种高级语言的编译器，或者生成一种需要进一步处理的的中间代码的编译器（又叫级联）。
典型的编译器输出是由包含入口点的名字和地址以及外部调用（到不在这个目标文件中的函数调用）的机器代码所组成的目标文件。一组目标文件，不必是同一编译器产生，但使用的编译器必需采用同样的输出格式，可以链接在一起并生成可以由用户直接执行的可执行程序。
编译器种类
编译器可以生成用来在与编译器本身所在的计算机和操作系统（平台）相同的环境下运行的目标代码，这种编译器又叫做“本地”编译器。另外，编译器也可以生成用来在其它平台上运行的目标代码，这种编译器又叫做交叉编译器。交叉编译器在生成新的硬件平台时非常有用。“源码到源码编译器”是指用一种高级语言作为输入，输出也是高级语言的编译器。例如: 自动并行化编译器经常采用一种高级语言作为输入，转换其中的代码，并用并行代码注释对它进行注释（如OpenMP）或者用语言构造进行注释（如FORTRAN的DOALL指令）。
预处理器（preprocessor）
作用是通过代入预定义等程序段将源程序补充完整。
编译器前端（frontend）
前端主要负责解析（parse）输入的源程序，由词法分析器和语法分析器协同工作。词法分析器负责把源程序中的‘单词’（Token）找出来,语法分析器把这些分散的单词按预先定义好的语法组装成有意义的表达式，语句 ，函数等等。
例如“a = b + c;”前端词法分析器看到的是“a, =, b , +, c;”，语法分析器按定义的语法，先把他们组装成表达式“b + c”，再组装成“a = b + c”的语句。
前端还负责语义（semantic checking）的检查，例如检测参与运算的变量是否是同一类型的，简单的错误处理。最终的结果常常是一个抽象的语法树（abstract syntax tree，或 AST），这样后端可以在次基础上进一步优化，处理。
编译器后端（backend）
编译器后端主要负责分析，优化中间代码（Intermediate representation）以及生成机器代码（Code Generation）。
一般说来所有的编译器分析，优化，变型都可以分成两大类： 函数内（intraproceral）还是函数之间（interproceral）进行。很明显，函数间的分析，优化更准确，但需要更长的时间来完成。
编译器分析（compiler analysis）的对象是前端生成并传递过来的中间代码，现代的优化型编译器（optimizing compiler）常常用好几种层次的中间代码来表示程序，高层的中间代码（high level IR）接近输入的源程序的格式，与输入语言相关（language dependent），包含更多的全局性的信息，和源程序的结构；中层的中间代码（middle level IR）与输入语言无关，低层的中间代码(Low level IR)与机器语言类似。 不同的分析，优化发生在最适合的那一层中间代码上。
常见的编译分析有函数调用树（call tree），控制流程图（Control flow graph），以及在此基础上的 变量定义－使用，使用－定义链（define-use/use-define or u-d/d-u chain），变量别名分析（alias analysis），指针分析（pointer analysis），数据依赖分析（data dependence analysis）等等。
上述的程序分析结果是编译器优化（compiler optimization）和程序变形（compiler transformation）的前提条件。常见的优化和变新有：函数内嵌（inlining），无用代码删除（Dead code elimination），标准化循环结构（loop normalization），循环体展开（loop unrolling），循环体合并，分裂（loop fusion，loop fission），数组填充（array padding），等等。 优化和变形的目的是减少代码的长度，提高内存（memory），缓存（cache）的使用率，减少读写磁盘，访问网络数据的频率。更高级的优化甚至可以把序列化的代码（serial code）变成并行运算，多线程的代码（parallelized，multi-threaded code）。
机器代码的生成是优化变型后的中间代码转换成机器指令的过程。现代编译器主要采用生成汇编代码（assembly code）的策略，而不直接生成二进制的目标代码（binary object code）。即使在代码生成阶段，高级编译器仍然要做很多分析，优化，变形的工作。例如如何分配寄存器（register allocatioin），如何选择合适的机器指令（instruction selection），如何合并几句代码成一句等等。
⑺ 几种常见的数据依赖
如果两个操作访问同一个变量，且这两个操作中有一个为写操作，此时这两个操作之间就存在数据依赖性。数据依赖分为下列3种类型，如表3-4所示。
上面3种情况，只要重排序两个操作的执行顺序，程序的执行结果就会被改变。
前面提到过，编译器和处理器可能会对操作做重排序。编译器和处理器在重排序时，会遵守数据依赖性，编译器和处理器不会改变存在数据依赖关系的两个操作的执行顺序。
这里所说的数据依赖性仅针对单个处理器中执行的指令序列和单个线程中执行的操作，不同处理器之间和不同线程之间的数据依赖性不被编译器和处理器考虑。
注：本文源自《Java并发编程的艺术》一文。
⑻ 软件测试
软件测试知识点
一.软件测试基本概念
1.软件质量的概念
功能性：软件提供明确与隐含功能的能力
可靠性：维持规定性能的能力
易用性：被理解学习使用和吸引用户的能力
效率：相对于所用资源的数量，软件产品可提供适应性能的能力
可维护性：纠正错误，改进功能，适应环境的能力
可移植性：迁移到另一种环境的能力
2.软件测试目标和原则
目标：以最少的时间和人力，系统地找出软件潜在的各种错误和缺陷
原则：1.尽早和不断地进行软件测试；
2.测试用例应该由测试输入数据和预期输出结果构成；
3.程序员尽量避免测试自己的程序（最好是独立于开发组和客户的第三方测试组和机构）
4.测试应包括合理的和不合理的输出条件，
5。注意测试中的集群现象（测试后的程序残存的错误数目与已经发现的成正比）
6.严格执行测试计划，排除随意性7.对每一个结果做全面检查
8.妥善保管测试计划用例出错统计和分析报告
3.软件测试心理学
1)程序测试过程具有破坏性:测试是为了发现错误而执行程序的过程
2)程序员尽量避免测试自己的程序
3)程序设计组织不应测试自己的程序
4.软件测试的经济学:不能发现”所有”的缺陷和错误
1.黑盒测试(数据驱动测试/输入输出驱动测试):测试人员完全不考虑程序内部的特性,和逻辑结构,只根据程序的需求规格说明书,检查程序是否符合他的功能说明
2.白盒测试(逻辑驱动测试):对程序的逻辑结构进行检查
5.软件质量保证’
二.软件测试类型以其地位
1.软件开发阶段:
1.生存周期:制定规划(功能需求可靠性接口可行性资源，可行性报告)——系统与软件需求定义——软件设计(技术核心)——编程和单元测试——系统与集成测试——运行和维护
2.测试信息流:软件配置,测试配置,测试工具
2.规划阶段的测试:目标阐述(不太详细也不具体),需求分析,功能定义,规划阶段的测试
3.设计阶段的测试:外部设计(用户界面),内部设计(结构设计,数据设计,逻辑设计),伪代码分析
4.编程阶段的测试:白盒测试与黑盒测试，结构测试与功能测试，路径测试:覆盖准则，增量测试与大突击测试
三．代码检查、走查和评审
1.桌面检查：程序员检查自己编写的程序，是在进行单元测试之前对代码进行分析
2.代码检查：以小组为单位阅读代码，
1.协调人：主持、引导代码检查的过程
2.开发人员：检查项目的生产者
3.检查人员：检查小组每一个人都可以认为是一个检查人员，可以兼任不同的角色。
4.解说员5.记录员
项目：变量是否喂赋值或者初始化？上下标是否在界限之内？是不是整数？是否分配了数值的内存单元？变量的数据类型是否与编译器所预期的一致？
3.走查：与代码检查类似，以小组为单位进行，进行一些列规程的错误检查技术的集合
4．同行评审：通过作者的同行来确认缺陷和需要变更区域检查的方法
评审的方法和技术：
1. 临时评审：一位程序员临时请另一位花几分钟时间查找一个缺陷
2. 桌上检查或轮查：多人进行的并行桌上检查
3. 结对评审：作者请另一位同行进行桌上检查
4. 走查：5.小组评审。6.正式审查
四．覆盖率测试
1.概念：度量测试完整性的手段
覆盖率=被执行的项目数/项总数 ×100%
2.逻辑结构的覆盖测试
◇判定，□语句，○程序的开始或者结束，
1.语句覆盖率=被评价用到的语句数/可执行的语句总数 ×100%
2.指令块：不存在（会引起分支）的控制语句，IB
IB覆盖率=被执行的语句块数量/程序中的指令块总数 ×100%
3.判定覆盖率=被执行的分支数量/程序中的分支总数 ×100%
DDP覆盖率=被评价到的判定路径数量/程序中的判定路径总数 ×100%
5. 条件覆盖=被评价到的条件取值数量/条件取值总数 ×100%
3.路径测试覆盖：
1.分支结构的路径测试：①对于嵌套型分支结构，若有n个判定语句，则存在n+1条不同的路径
②对于串联型分支结构，若有n个判定语句，则有2n个路径 →减少测试用例，构造正交表P71
2.循环结构的路径测试：简单循环，嵌套循环，连锁循环，非结构循环
4.数据流测试：关注在一条路径上变量在何处赋值，在何处引用
佣金问题伪代码描述：P79
5.基于覆盖测试的数据选择
如何使用覆盖率①覆盖率不是目的，只是一种手段②不能针对所有的覆盖率指标进行测试③不能追求100%的覆盖率
五．黑盒测试
1.等价类测试：降数目极多的数据化成等价类，然后测试某类的代表值
原则：①如果确定了取值范围或者取值的个数，则可以确立一个有效等价类和两个无效等价类
②如果输入条件规定了输入值的集合，则可以有一个有效和一个无效等价类
2.边界值测试：用例：刚达到这个范围的值，比最大范围多1或者少1，如果输入输出域是有序集合，则采用边界
3.基于因果图的测试：E互斥，I包含（至少一个成立）O唯一 R要求（a→b）M屏蔽（a1则b0）
4.基于状态图的测试：P105
六．单元测试和集成测试
1.单元测试的目标和模型：
1.单元：可以编译和执行的最小软件构件、不会指派给多个设计人员开发
2.目标：验证代码是与设计相合的，跟踪需求和设计的实现和缺陷，发现编码过程中引入的错误
3.模型：（与集成，系统测试区别：P120）
2.单元测试的策略
1.自顶向下：逐层打桩 2.自底向上：自下向上打桩 3.孤立测试：为每个模块单独打桩
4.综合测试
3.单元测试分析：
1.模块接口
2.局部数据结构：保证临时存储在模块内的数据的完整正确
3.独立路径：保证每个模块的每条语句至少执行一次
4.出错处理：预见各种出错条件，进行适当的处理
5.边界条件.
4.集成测试的基本概念
1.定义：对系统接口和集成后的功能的正确性进行检验
2.与系统测试区别：
①测试对象 集成：各个模块的构件 系统：软硬件以及相关的外围设备，数据采集传输等
②测试时间 集成介于单元和系统测试之间
③ 测试方法：单元白盒，集成灰盒，系统黑盒
5.集成测试策略：
1.基于分解
①一次性集成测试②自顶向下增量式测试③自底向上的增量式集成测试④三明治集成
2.基于功能的集成：采用增量式集成测试方法
3.基于调用图的集成：成对测试，相邻测试
4.基于路径的集成 5.基于进度的集成
6集成测试分析
1.体系结构分析：
①根据需求分析，划分结构层次图
②对各个结构之间的依赖关系进行分析，确定测试模块的大小
2.模块分析 3.接口分析 4.可测试性分析
七．系统测试
1.概念：软件开发完成后，还要与系统的其他部分结合起来才能运行，系统测试的目的就是对各部分进行集成和确认测试
2.系统测试的方法：
①功能测试：是否有不正确或者遗漏的功能，能否满足系统和用户的隐式需求，能否正确接受输入
②协调一致测试
③性能测试：度量系统的性能与预先定义的目标有多大差距：压力测试：
④压力测试：测试者想要破坏程序，边界测试
⑤容量测试⑥安全性测试⑦失效恢复测试⑧备份测试GUI图形化用户接口测试⑩健壮性测试
易用性测试、安装测试、文档测试、在线帮助测试
3.系统测试的实施
①确认测试：有效性测试
②α测试和β测试：内部用户/内测
③验收测试：
④回归测试：软件变更后对其进行重新测试
八．软件性能测试和可靠性测试
1.软件性能的概念：完成某项功能时展现出来的及时性
指标：响应时间（平均，最大），吞吐量，并发用户数，资源利用率
2.性能测试的执行：
3.软件可靠性的概念：在规定时间条件内，软件不引起失效的概率
软硬件可靠性区别：
① 唯一性：软件每份拷贝都相同，硬件不能相同
② 物理退化：硬件可靠性下降
③ 逻辑复杂性：软件是纯逻辑产品，其失效也主要是逻辑错误
④ 版本更新：硬件较慢，软件较快
4.软件可靠性预计：
①软件的运行剖面与可靠性剖面一致②一旦发生故障，立即修复，不引入新的故障③故障和失效是相互独立的④每个故障发生的概率相等
九．面向对象的软件测试
1. 面向对象的软件测试的问题
1.封装：信息隐蔽，一组相关变量和方法被封装在同一个类中
2.继承：子类直接获得父类的属性和方法 充分性，误用
3.多态
2. 面向对象的软件测试模型：分析测试（OOA），设计测试（OOD）编程测试（OOP）
3. 面向对象的软件测试策略：检查分析结果是否附和相应的面向对象分析方法要求，分析检查结果是否满足软件需求
十：WEB应用测试
1. 应用服务器的分类：
① 面向的领域：通用应用服务器（提供多方面服务），专用应用服务器
② 循环的规范：
2. WEB应用的测试策略
1. 表示层的测试：拍板结构，链接结构，客户端程序，浏览器兼容性
2. 业务层的测试：单个程序（尽可能白盒测试），对一组程序
3. 数据层的测试：
3.WEB软件的测试技术：
1.功能测试：链接测试，表单测试，Cookies测试
2.性能测试：并发测试，负载测试和性能调优
3.安全性测试：服务器，客户端，Cookies，日志功能
4.接口测试：使用接口，提供接口
4.系统安全检测与防护
1.入侵检测 狭义：黑客进入一个系统 广义：窃取数据，滥用服务器，发送垃圾邮件
2.漏洞扫描 操作系统漏洞，网络漏洞，数据库漏洞
3.安全策略 ①物理破坏防护：远离火灾，人为破坏
②信息窃取防护：入网访问控制,权限控制（用户权限，操作权限），服务器和节点安全控制，网络监测控制，防火墙控制
③信息加密：保护策略，加密算法
十一.其他测试
1. 兼容性测试①不同的硬件配置影响软件性能②软件使用了硬件的特定功能
1. 软件兼容性测试：与操作系统，数据库，浏览器，中间件，其他软件 兼容性
2. 数据兼容性：不同版本数据，不同软件间兼容性
2.易用性测试
1.易安装性测试：安装手册自动化程度，灵活性，中断处理，安装和卸载，多环境安装支持
2.功能易用性测试：业务符合度，功能定制性，功能关联度，数据共享度，用户约束的合理性
3.用户界面测试：界面整体(合理一致规范)，界面元素，输入测试
3.构件测试：
4.极限测试：
1.极限编程：①特性：简单的分析设计，频繁的客户交流，增量式开发，连续的测试
②优点：随时应对新增或改变的需求
2.极限测试①单元测试：最重要的发现错误的手段，由编码人员完成，在编程之前测试
②极限测试的实施：单元测试用例的生成
5.文档测试：只能以文档审查的方式进行
内容：宣传和包装材料，用户许可说明书，手册，在线帮助，示例和模板
文档的测试