詞法/語法分析、程序分析與程序變換、代碼生成、內存管理、虛擬機、函數式語言的實現與優化。。。每個話題都能出不止一本書。
用到的演算法/數據結構多如牛毛：
各種樹、圖為主，其他如棧、隊列、散列表、並查集。。。
貪心、回溯、動態規劃、遺傳演算法、矩陣變換。。
在一個問題下很難回答好。。 先簡單介紹一下和圖相關的。
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.文檔測試：只能以文檔審查的方式進行
內容：宣傳和包裝材料，用戶許可說明書，手冊，在線幫助，示例和模板
文檔的測試