《數(shù)據(jù)庫系統(tǒng)原理》課程總結與復習大綱

《數(shù)據(jù)庫系統(tǒng)原理》課程總結與復習大綱

一、要求熟讀的章節(jié)：

注意：所有SQL語句遵循老師講課和實驗所采用的、SQLSERVER201*支持的SQL。第一章：緒論第二章：關系數(shù)據(jù)庫

第三章：關系數(shù)據(jù)庫標準語言SQL第四章：數(shù)據(jù)庫安全性第五章：數(shù)據(jù)庫完整性第六章：關系數(shù)據(jù)理論第七章：數(shù)據(jù)庫設計第八章：數(shù)據(jù)庫編程

第九章：關系查詢處理和查詢優(yōu)化第十章：數(shù)據(jù)庫恢復技術第十一章：并發(fā)控制

二、要求掌握的主要內(nèi)容

要求熟悉數(shù)據(jù)庫的基本概念、基本理論和基本技術：1.數(shù)據(jù)、數(shù)據(jù)庫、數(shù)據(jù)庫管理系統(tǒng)的概念，DBMS提供的功能，數(shù)據(jù)語言（DDL,DML,DCL）。2.數(shù)據(jù)管理的發(fā)展階段及每個階段的特點。

3.數(shù)據(jù)模型的概念P12，組成數(shù)據(jù)模型的三要素。

4.概念模型、實體、屬性、碼、候選碼、外碼、域、實體型、實體集的概念。5.實體間的聯(lián)系及E-R模型。

6.實際的數(shù)據(jù)庫系統(tǒng)支持的主要數(shù)據(jù)模型是哪幾種，什么是基本層次聯(lián)系，層次模型、網(wǎng)狀模型的數(shù)據(jù)結構。

7.數(shù)據(jù)庫系統(tǒng)的三級模式結構、兩級映象功能、數(shù)據(jù)的物理獨立性和邏輯獨立性。8.數(shù)據(jù)庫系統(tǒng)的組成。

9.關系的定義及關系的特性，關系模式的表示，元組、屬性、主屬性、碼、候選碼、非碼屬性、全碼、外碼的概念

10.關系模型的三類完整性：實體完整性、參照完整性和用戶定義完整性

11.掌握關系代數(shù)的運算：傳統(tǒng)的集合運算（并、交、差、笛卡兒積）和專門的關系運算（選擇、投影、連接、除法）

12.關系數(shù)據(jù)語言的特點，關系操作的特點13.SQL語言的概念、四個特點

14.SQL語言的數(shù)據(jù)定義（CREAT,DROP,ALTER）功能：包括對基本表、索引和視圖的建立、修改和刪除，語法格式。

15.掌握數(shù)據(jù)查詢（SELECT）語句功能和應用（單表、多表連接、嵌套、集函數(shù)count,sum,avg,max,min）

（where子句,bwteen…and…,in,like,is[not]null,orderby,groupby,having,any,all,exists,top,selectinto,比較運算符）

16.掌握數(shù)據(jù)操縱功能：修改（UPDATE）、刪除（DELETE）和插入（INSERT）語句的應用17.數(shù)據(jù)安全性是指保護數(shù)據(jù)庫以防止不合法用戶的使用所造成的數(shù)據(jù)泄露、更改或破壞。三類安全性問題，基本的數(shù)據(jù)安全控制措施。SQL數(shù)據(jù)控制功能（GRANT、REVOKE）18.基本表、視圖的概念，了解視圖的作用。

19.數(shù)據(jù)庫的完整性是指數(shù)據(jù)的正確性和相容性。完整性約束涉及的對象及其狀態(tài)。三類完整性約束（主鍵、外鍵、缺省、非空、唯一、CHECK）的定義、修改和刪除。觸發(fā)器的定義、激活和刪除。

20.（平凡與非平凡的）函數(shù)依賴、完全函數(shù)依賴、部分函數(shù)依賴、傳遞函數(shù)依賴、函數(shù)依賴（集）

21.關系規(guī)范化：了解第一范式、第二范式、第三范式、BC范式的定義，將一個非規(guī)范化的表轉化為三范式的表的步驟（非規(guī)范→1NF,1NF→2NF,2NF→3NF,3NF→BCNF）。掌握把一個非規(guī)范的表轉化為三范式的表的方法。

22.數(shù)據(jù)庫設計的概念、特點、方法步驟，每個階段所做的工作。（尤其要掌握概念設計、邏輯設計的工作內(nèi)容和步驟及基本技術）

23.[宿]主語言，嵌入式SQL的處理過程，存儲過程

24.查詢處理步驟（4個階段），查詢優(yōu)化概述P265例，了解關系系統(tǒng)查詢優(yōu)化一般策略，什么是代數(shù)優(yōu)化，物理優(yōu)化。

25.事務的概念和特性、了解故障種類、恢復原理和技術（尤其掌握日志文件的作用和工作方式）、恢復策略（尤其掌握具有檢查點的恢復技術）。

26.并發(fā)控制的技術（并發(fā)操作及引起的數(shù)據(jù)不一致，解決辦法P305習題）、基本封鎖的種類（S鎖，X鎖）、死鎖的預防、封鎖協(xié)議、兩段鎖協(xié)議。27.數(shù)據(jù)倉庫的概念、特征和功能P4

擴展閱讀：第17講-復習大綱與課程總結

第軟件測試概述

1、

軟件缺陷的定義正式定義

軟件未達到需求規(guī)格說明書中指明的功能

軟件出現(xiàn)了需求規(guī)格說明書中指明不會出現(xiàn)的錯誤軟件功能超出需求規(guī)格說明書中指明的范圍

軟件未達到需求規(guī)格說明書中雖未指出但應達到的目標

軟件測試員認為軟件難以理解、不易使用、運行速度緩慢，或者最終用戶認為不好2.

軟件測試的目的和意義

“使用人工或自動手段來運行或測定某個系統(tǒng)的過程，其目的在于檢驗它是否滿足規(guī)定的需求或是弄清預期結果與實際結果之間的差別”。3、

軟件測試原則

軟件測試應追溯到用戶需求應盡早和不斷地測試

窮盡測試是不可能的GoodEnough原則具有良好的測試態(tài)度避免測試自己的程序增量測試測試分級

測試有重點：80/20原則避免測試的隨意性4、

對待缺陷的基本原則缺陷的群集現(xiàn)象缺陷有免疫力缺陷關聯(lián)和依賴測試結果的處理原則對缺陷進行復查和確認測試結果的全面檢查出錯統(tǒng)計和分析

妥善保存測試過程文檔5、

軟件測試與質量保證的區(qū)別：

相同點：都是貫穿于整個軟件開發(fā)生命周期的。

不同點：軟件質量保證（SQA）側重于對流程中各過程的管理與控制，是一項管理工作，側重于流程和方法；而軟件測試是對流程中各過程管理與控制策略的具體執(zhí)行和實施，其對象是軟件產(chǎn)品（包括階段性的產(chǎn)品）。即軟件測試是對軟件產(chǎn)品的檢驗，是一項技術性工作。軟件測試，常常被認為是質量控制的最主要手段。6、

v模型和w模型的區(qū)別：

V模型是軟件開發(fā)完了之后才開始測試活動。而W模型則是軟件測試活動伴隨著軟件開發(fā)活動。和軟件開發(fā)同時開展W模型更加敏捷，對于軟件的交付期和品質的保證能力更強。7、

測試用例的定義

測試用例=輸入+輸出+測試環(huán)境

測試用例是針對軟件產(chǎn)品的功能、業(yè)務規(guī)則和業(yè)務處理所設計的測試方案。對軟件的每個特定功能或運行操作路徑的測試構成了一個測試用例。8、

測試用例的重要性技術層面

指導測試的實施規(guī)劃測試數(shù)據(jù)的準備

編寫測試腳本的“設計規(guī)格說明書”降低工作強度管理層面團隊交流重復測試

檢驗測試員進度質量評估

分析缺陷的標準9、

測試用例設計的基本原則測試用例的代表性正常數(shù)據(jù)邊界數(shù)據(jù)錯誤數(shù)據(jù)

測試結果的可判定性測試結果的可再現(xiàn)性10、

測試用例的評價標準有效性經(jīng)濟性可仿效性可修改性獨立性可跟蹤性

11、軟件測試人員應具備哪些素養(yǎng)

作為一名開發(fā)人員：熟悉屬于開發(fā)人員自己的測試任務和測試技術作為一名測試人員：熟悉屬于測試人員自己的測試任務和測試技術作為一名測試項目經(jīng)理：組織測試人員進行項目測試作為一名測試部門經(jīng)理：根據(jù)公司發(fā)展的不同階段，設計公司測試流程和進行測試團隊建設

第三章禪道系統(tǒng)

1、

禪道項目管理系統(tǒng)是什么？

禪道項目管理系統(tǒng)(ZenTaoPMS)是一款國產(chǎn)的，基于LGPL協(xié)議，開源免費的項目管理軟件，它集產(chǎn)品管理、項目管理、測試管理于一體，同時還包含了事務管理、組織管理等諸多功能，是中小型企業(yè)項目管理的首選。2、

為什么選擇禪道系統(tǒng)？

第一款完整涵蓋產(chǎn)品管理、任務管理、測試管理的開源管理軟件，使用一個軟件解決項目管理核心問題。

基于國際流行的敏捷管理方式scrum。B/S架構，方便部署、使用。概念簡單，容易上手。

開源的項目管理軟件，可自由進行定制，修改。免費的項目管理軟件，降低企業(yè)的投入成本。

自主的開發(fā)框架，預留擴展機制，通過第三方的插件擴展獲得更多的功能。有完善的開發(fā)團隊，特別適合中小企業(yè)的管理。3、

禪道系統(tǒng)的功能列表組織管理

部門管理、用戶管理、分組管理、權限管理產(chǎn)品管理

產(chǎn)品管理、需求管理、計劃管理、發(fā)布管理、路線圖項目管理

項目管理、任務管理、項目需求管理、團隊管理、工時管理、build管理、燃燒圖。

質量管理

Bug管理、測試用例管理、測試任務管理。我的地盤TODO管理、我的需求、我的bug、我的任務4、

禪道項目管理的基本流程

首先產(chǎn)品人員維護需求列表，需求有優(yōu)先級和預計工時。

召開產(chǎn)品計劃會議，與會人員有產(chǎn)品、研發(fā)和測試，大家就當前項目（固定的時間和人）所需要完成的需求達成一致，形成項目的需求列表。項目團隊對需求進行WBS任務分解，開始開發(fā)。

測試人員根據(jù)需求創(chuàng)建自己的測試用例。當有版本提交以后，建立相應的測試任務，記錄缺陷。研發(fā)人員修復bug。

項目結束之后，大家召開演示會議，團隊向相關人員（產(chǎn)品人員及所有感興趣的人）展示該項目所取得的成果。大家提出的反饋由產(chǎn)品人員整理成為需求。開始下一輪的循環(huán)。5、

一、禪道里面bug的基本處理流程

禪道里面缺陷處理的基本流程是：測試提交bug=>開發(fā)解決bug=>測試驗證bug=>測試關閉bug。如果bug驗證沒有通過，可以激活：測試提交bug=>開發(fā)解決bug=>測試驗證bug=>測試激活bug=>開發(fā)解決bug=>測試驗證=>測試關閉。

還有一個流程就是bug關閉之后，又發(fā)生了。測試提交bug=>開發(fā)解決bug=>測試驗證bug=>測試關閉bug=>測試激活bug=>開發(fā)解決bug=>測試驗證=>測試關閉。二、第四章軟件測試計劃與策略

1、測試計劃是對每個產(chǎn)品，或是對各個開發(fā)階段的產(chǎn)品開展測試的策略。一個完整的測試計劃應該包含以下幾個方面：對測試范圍的界定；時間表的制定；資源的規(guī)劃；風險的確定；

2、制定測試計劃的原則：制定測試計劃應盡早開始保持測試計劃的靈活性保持測試計劃簡潔和易讀盡量爭取多渠道評審測試計劃計算測試計劃的投入

通常在測試需求分析前制定總體測試計劃書，在測試需求分析后制定詳細測試計劃書。3、

制定測試計劃，步驟：(1)產(chǎn)品基本情況調研(2)測試需求說明(3)測試的策略和記錄(4)測試資源配置(5)計劃表

(6)問題跟蹤報告(7)測試計劃評審4、

靜態(tài)測試與動態(tài)測試

根據(jù)是否運行程序，軟件測試技術可以分為靜態(tài)測試與動態(tài)測試。1.靜態(tài)測試包括：（1）代碼檢查

（2）編碼風格與規(guī)范（3）代碼審查（4）靜態(tài)結構分析（5）代碼質量度量2.動態(tài)測試包括：（1）單元測試（2）集成測試（3）系統(tǒng)測試（4）驗收測試（5）回歸測試5、

白盒測試與黑盒測試：

動態(tài)測試一般分為白盒測試和黑盒測試。白盒測試：也稱為結構測試或邏輯驅動測試。白盒測試方法：

程序控制流分析、數(shù)據(jù)流分析、邏輯驅動測

試、域測試、符號測試、路徑測試、程序插樁及程序變異。黑盒測試：也稱功能測試或數(shù)據(jù)驅動測試。黑盒測試方法：

等價類劃分、邊界值分析、因果圖、錯誤推測等。6、

單元測試

目的:檢測程序模塊中有無故障存在

對象:軟件設計的最小單位，與程序設計和編程實現(xiàn)關系密切集成測試

目的:發(fā)現(xiàn)與接口有關的模塊之間的問題方法：非增式集成測試法和增式集成測試法集成測試

非增式集成測試法

對每一個模塊進行單元測試

在此基礎上按程序結構圖將各模塊連接起來，把連接后的程序當作一個整體進行測試增式集成測試法不斷地把待測模塊連接到已測模塊集(或其子集)上，對待測模塊進行測試，直到最后一個模塊測試完畢

確認測試

目的：對軟件產(chǎn)品進行評估以確定其是否滿足軟件需求的過程系統(tǒng)測試

目的：針對系統(tǒng)中各個組成部分進行的綜合性檢驗，證明系統(tǒng)的性能測試人員要求：

系統(tǒng)開發(fā)人員不能進行系統(tǒng)測試。系統(tǒng)開發(fā)組織不能負責系統(tǒng)測試。7、

軟件測試在軟件開發(fā)中的作用

項目規(guī)劃階段：負責整個測試階段的監(jiān)控。

需求分析階段：確定測試需求分析，制定系統(tǒng)測試計劃。測試需求分析是指產(chǎn)品生存周期中測試所需的資源、配置、各階段評審通過的標準等。概要設計和詳細設計階段：制定集成測試計劃和單元測試計劃。編碼階段：開發(fā)相應的測試代碼或測試腳本。測試階段：實施測試，并提交相應的測試報告。8、

搭建軟件測試環(huán)境還應注意以下幾點：小題盡量模擬用戶的真實使用環(huán)境；

測試環(huán)境中盡量不要安裝其它與被測軟件無關的軟件，但最好安裝殺毒軟件，以確保系統(tǒng)沒有病毒；

測試環(huán)境應與開發(fā)環(huán)境獨立。

第五章黑盒測試

1、

黑盒測試

又叫功能測試，數(shù)據(jù)驅動測試或基于規(guī)格說明的測試。2、黑盒測試的目標

盒測試試圖發(fā)現(xiàn)以下類型的錯誤：功能錯誤或遺漏；界面錯誤，不美觀；外部信息訪問錯誤；性能錯誤；

初始化和終止錯誤

在接口上，能否正確地接受輸入數(shù)據(jù)，能否產(chǎn)生正確地輸出信息；3、

黑盒測試的測試用例設計方法邊界值分析等價類劃分

基于決策表的測試因果圖錯誤推測4、

等價類測試的基本思想等價類測試的假設：

測試某等價類的代表值，就等效于對這個等價類中其他值的測試。等價類測試的思想：

把全部的輸入數(shù)據(jù)劃分成若干個等價類，在每一個等價類中取一個數(shù)據(jù)來進行測試。

等價類的分類有效等價類

對于程序的規(guī)格說明來說，是合理的、有意義的輸入數(shù)據(jù)所構成的集合；無效等價類

對于程序的規(guī)格說明來說，是不合理的、沒有意義的輸入數(shù)據(jù)所構成的集合；5、

用等價類設計測試用例

(1)劃分等價類，形成等價類表

(2)設計一新的測試用例，使其盡可能多地覆蓋尚未覆蓋的有效等價類，重復這一步驟，直到所有的有效等價類都被覆蓋為止；

(3)設計一新測試用例，使其只覆蓋一個無效等價類，重復這一步驟直到所有無效等價類均被覆蓋；6、

邊界值分析獲得測試用例的方法：

使所有變量取正常值，只使一個變量取極值；

對于一個n變量函數(shù)，邊界值分析會產(chǎn)生4n+1個測試用例。7、

2．加法器邊界值測試用例設計

【例】加法器程序計算兩個1～100之間整數(shù)的和。

對于加法器程序，根據(jù)輸入要求可將輸入空間劃分為三個等價類，即1個有效等價類（1～100之間），兩個無效等價類（100）。但這種等價類劃分不是很完善，我們只考慮了輸入數(shù)據(jù)的取值范圍，而沒有考慮輸入數(shù)據(jù)的類型，我們認為輸入應為整數(shù)，但用戶輸入什么都有可能。邊界值分析法的測試運用

為此，我們可綜合考慮輸入數(shù)據(jù)的取值范圍和類型劃分等價類，其結果如下表所示。

輸入條件1～100之間整數(shù)100整數(shù)小數(shù)所屬類別有效等價類無效等價類無效等價類無效等價類編號5678輸入條件非數(shù)值（字母）非數(shù)值（特殊字符）非數(shù)值（空格）非數(shù)值（空白）所屬類別無效等價類無效等價類無效等價類無效等價類號測試用例Test1Test2Test3Test4Test5Test6Test7Test8Test9Test10Test11Test12Test13測試用例Test14Test15Test16Test17Test18Test19Test20Test21輸入數(shù)據(jù)加數(shù)1129910050505050050101500.2輸入數(shù)據(jù)加數(shù)150A50@50空格5050加數(shù)20.250A50@50空格50加數(shù)25050505012991005005010150預期輸出和51521491505152149150提示“請輸入1～100間的整數(shù)”提示“請輸入1～100間的整數(shù)”提示“請輸入1～100間的整數(shù)”提示“請輸入1～100間的整數(shù)”提示“請輸入1～100間的整數(shù)”預期輸出和提示“請輸入1～100間的整數(shù)”提示“請輸入1～100間的整數(shù)”提示“請輸入1～100間的整數(shù)”提示“請輸入1～100間的整數(shù)”提示“請輸入1～100間的整數(shù)”提示“請輸入1～100間的整數(shù)”提示“請輸入1～100間的整數(shù)”提示“請輸入1～100間的整數(shù)”提示“請輸入1～100間的整數(shù)”Test228、決策表

決策表（DecisionTable），又叫判定表

決策表是分析和表達多邏輯條件下執(zhí)行不同操作的工具。在程序設計發(fā)展的初期，決策表被當作編寫程序的輔助工具。

決策表的組成

條件樁（ConditionStub）列出問題的所有條件動作樁（ActionStub）列出可能采取的操作

條件項（ConditionEntity）列出條件樁的取值

動作項（ActionEntity）

列出條件項各種取值下應該采取的動作

決策表建立步驟根據(jù)軟件規(guī)格說明

①列出所有的條件樁和動作樁；②確定規(guī)則的個數(shù)；

n

假如有n個條件，每個條件有兩個取值（0,1）,則有2種規(guī)則；③填入條件項；

④填入動作項，得到初始決策表；⑤簡化，合并相似規(guī)則（相同動作）。9、

維修機器問題問題描述：

“對于功率大于50馬力的機器，并且維修記錄不全或已運行10年以上的機器，應給予優(yōu)先的維修處理”請建立決策表。

（1）列出所有的條件樁和動作樁條件樁

C1：功率大于50馬力嗎？C2：維修記錄不全嗎？C3：運行超過10年嗎？動作樁

A1：進行優(yōu)先處理A2：作其他處理（2）確定規(guī)則個數(shù)輸入條件個數(shù)：3；

每個條件的取值：“是”或“否”；規(guī)則個數(shù)：2*2*2=8；3）填入條件項；1234功率大于50馬力嗎？YYYYN條件維修記錄不全嗎？YYNNY運行超過10年嗎？YNYNY進行優(yōu)先處理動作作其他處理（4）填入動作項；1234567功率大于50馬力嗎？YYYYNNN條件維修記錄不全嗎？YYNNYYN運行超過10年嗎？YNYNYNY進行優(yōu)先處理動作作其他處理功率大于50馬力嗎？(1)Y(2)Y(3)Y(4)N維修記錄不全嗎？條件運行超過10年嗎？YNNYNY進行優(yōu)先處理動作作其他處理化簡(1)(2)(3)功率大于50馬力嗎？YYY維修記錄不全嗎？條件運行超過10年嗎？YNNYN進行優(yōu)先處理動作作其他處理10、

因果圖（Cause-EffectGraphics）分析方法因果圖分析法最終生成的是判定表，適合于檢查程序輸入條件的各種組合情況。因果圖分析依據(jù)

需求規(guī)格說明中的因果關系作用

能夠按一定步驟，高效率地選擇測試用例指出程序規(guī)約描述中存在著的問題

利用因果圖設計測試用例

1.分析程序規(guī)格說明的描述中，哪些是原因，哪些是結果原因常常是輸入條件或是輸入條件的等價類;結果是輸出條件;

2.分析程序規(guī)約的描述中語義的內(nèi)容，并將其表示成連接各個原因與各個結果的“因果圖”

3.在因果圖上使用若干個特殊的符號標明約束條件4.把因果圖轉換成判定表

5.把判定表中每一列表示的情況寫成測試用例第五章白盒測試

1、

白盒測試，也稱為結構化測試、基于代碼的測試，是一種測試用例設計方法，它從程序的控制結構導出測試用例。2、

黑盒測試只能觀察軟件的外部表現(xiàn)，即使軟件的輸入輸出都是正確的，卻并不能說明軟件就是正確的。因為程序有可能用錯誤的運算方式得出正確的結果，例如“負負得正，錯錯得對”，只有白盒測試才能發(fā)現(xiàn)真正的原因。

白盒測試能發(fā)現(xiàn)程序里的隱患，象內(nèi)存泄漏、誤差累計問題。在這方面，黑盒測試存在嚴重的不足。3、

白盒測試中的邏輯覆蓋方法有以下6種：1.語句覆蓋2.判定覆蓋3.條件覆蓋

4.判定－條件覆蓋5.條件組合覆蓋6.路徑覆蓋4、

1.語句覆蓋

基本思想是：設計若干測試用例，運行被測程序，使程序中每個可執(zhí)行語句至少執(zhí)行一次。2.判定覆蓋

基本思想是：設計若干測試用例，運行被測程序，使得程序中每個判斷的取真分支和取假分支至少經(jīng)歷一次，即判斷真假值均曾被滿足。3.條件覆蓋基本思想是：設計若干測試用例，執(zhí)行被測程序以后要使每個判斷中每個條件的可能取值至少滿足一次。4.判定－條件覆蓋基本思想是：設計足夠的測試用例，使得判斷條件中的所有條件可能至少執(zhí)行一次取值，同時，所有判斷的可能結果至少執(zhí)行一次。5.條件組合覆蓋基本思想是：設計足夠的測試用例，使得所有可能的條件取值組合至少執(zhí)行一次6.路徑覆蓋

基本思想是：設計所有的測試用例，來覆蓋程序中的所有可能的執(zhí)行路徑。5、

白盒測試和黑盒測試的比較

白盒測試只關注軟件產(chǎn)品的測試，不能夠確保產(chǎn)品已經(jīng)實現(xiàn)了規(guī)格說明中的所有功能。黑盒測試則只關注規(guī)格說明中的功能測試，不能夠保證已經(jīng)實現(xiàn)的各個部分都被測試到。

與黑盒測試相比，白盒測試的成本要高一些。黑盒測試故意不考慮控制結構，而只注意信息域。白盒測試只考慮測試軟件產(chǎn)品，它不保證完整的需求規(guī)格是否被滿足。黑盒測試是一種確認技術，回答“我們在構造一個正確的系統(tǒng)嗎？白盒測試是一種驗證技術，回答“我們在正確地構造一個系統(tǒng)嗎？”

建議測試人員在進行測試的過程中，可以考慮先使用黑盒測試，然后統(tǒng)計相應的覆蓋率，再設計適當?shù)陌缀袦y試用例作為補充以保證測試的完整性。6、

白盒測試工具

Java語言：Junit，

C++：CppUnit、VisualUnit等

第六章單元測試

1、

1.單元測試的定義

單元測試又稱模塊測試，是針對軟件設計的最小單位程序模

塊，進行正確性檢驗的測試工作。

單元測試的內(nèi)容包括單元的內(nèi)部結構、單元的功能和可觀測的行

為。

2.單元測試方法

功能性測試結構性測試

3.目標

(1)檢查代碼實現(xiàn)是否符合設計測試依據(jù)是詳細設計描述(2)盡早發(fā)現(xiàn)錯誤4.測試對象：“單元”

結構化編程語言

單元測試對象是函數(shù)或者子過程。

面向對象語言

單元測試對象是類或者類的方法。如一個菜單、屏幕顯示界面或對話框等2、

驅動模塊(Driver)

被測基本單元的主程序，它接收測試數(shù)據(jù)，并把數(shù)據(jù)傳送給被測單元，最后輸出實測結果。樁模塊(Stub)

用來代替被測基本單元調用的其他基本單元。3、

你認為驅動模塊、樁模塊中哪一種類型模塊開發(fā)較為容易些，并給出理由？4、

單元測試主要對模塊的五個基本特性進行評價模塊接口

局部數(shù)據(jù)結構邊界條件

重要的執(zhí)行路徑錯誤處理5、

單元測試策略

自頂向下的單元測試自底向上的單元測試孤立單元測試方法：不考慮每個單元與其它單元之間的關系，為每個單元設計樁模塊或驅動模塊。每個模塊進行獨立的單元測試。

優(yōu)點：簡單、容易操作，可達到高的結構覆蓋率。缺點：不提供一種系統(tǒng)早期的集成途徑�？偨Y：最好的單元測試策略。6、

主要單元測試方法人工靜態(tài)分析自動靜態(tài)分析自動動態(tài)測試人工動態(tài)測試7、

測試過程中各種人員的作用系統(tǒng)分析設計人員

進行需求跟蹤，確保系統(tǒng)需求的實現(xiàn)和更新。進行軟件單元可測性分析，確定單元測試的對象、范圍和方法。軟件開發(fā)人員

負責編碼和單元測試過程，完成單元測試計劃、方案和報告。軟件測試人員

參與單元測試計劃、方案和報告的評審，對單元測試的計劃、設計和執(zhí)行質量進行監(jiān)控。根據(jù)實際情況，可選擇參與由開發(fā)人員負責的代碼檢視、單元測試等活動。

配置管理人員

對代碼及單元測試文檔進行配置管理。質量保證（QA）人員

參與編碼與單元測試評審，對編碼和單元測試過程進行審計。8、

單元測試重點內(nèi)容靜態(tài)測試代碼檢查

靜態(tài)結構分析代碼質量度量白盒測試語句覆蓋測試判定覆蓋測試條件覆蓋測試

判定條件覆蓋測試條件組合測試路徑覆蓋測試黑盒測試

等價類劃分方法邊界值分析方法錯誤推測方法

第七章集成測試

1、集成測試的概念

集成（Integration）是指把多個單元組合起來形成更大的單元。

集成測試（IntegrationTesting）是在假定各個軟件單元已經(jīng)通過了單元測試的前提下，檢查各個軟件單元之間的相互接口是否正確。2、集成測試主要關注下列問題：（1）模塊間的數(shù)據(jù)傳遞是否正確？

（2）一個模塊的功能是否會對另一個模塊的功能產(chǎn)生錯誤的影響？（3）全局數(shù)據(jù)結構是否有問題，會不會被異常修改？（4）塊組合起來的功能能否滿足要求？

（5）集成后，各個模塊的累積誤差是否會擴大，是否達到不可接受的程度？3、集成測試與單元測試的區(qū)別小題1)測試對象有所區(qū)別;

2)集成測試關注的是模塊間的接口，接口之間的數(shù)據(jù)傳遞關系，單元組合后是

否實現(xiàn)預計的功能。

3)集成測試組裝的對象比單元測試的對象級別要高。4、集成測試與系統(tǒng)測試的區(qū)別小題

1)系統(tǒng)測試對象是整個系統(tǒng)以及與系統(tǒng)交互的硬件和軟件平臺。系統(tǒng)測試更多

程度上是站在用戶的角度上對系統(tǒng)做功能性的驗證，同時還對系統(tǒng)進行一些非功能性的驗證，包括系統(tǒng)測試測試、壓力測試、安全性測試、恢復性測試等。系統(tǒng)測試的依據(jù)來自用戶的需求規(guī)格說明書和行業(yè)的已成文的或事實上的標準。

2)集成測試所測試的對象是模塊間的接口，其目的是要找出在模塊接口上面，

包括整體體系結構上的問題。其測試的依據(jù)來自系統(tǒng)的高層設計（架構設計或概要設計）。

3)軟件的集成測試工作最好由不屬于該軟件開發(fā)組的軟件設計人員承擔，以提

高集成測試的效果。5、集成測試目的

在把各個模塊連接起來的時侯，穿越模塊接口的數(shù)據(jù)是否會丟失；一個模塊的功能是否會對另一個模塊的功能產(chǎn)生不利的影響；各個子功能組合起來，能否達到預期要求的父功能；全局數(shù)據(jù)結構是否有問題；

單個模塊的誤差累積起來，是否會放大，從而達到不能接受的程度。在單元測試的同時可進行集成測試，發(fā)現(xiàn)并排除在模塊連接中可能出現(xiàn)的問題，最終構成要求的軟件系統(tǒng)。6、集成測試與開發(fā)的關系

集成測試是和軟件開發(fā)過程中的概要設計階段相對應的，而在軟件概要設計中關于整個系統(tǒng)的體系結構就是集成測試用例輸入的基礎。集成測試的層次與原則1．集成測試的層次

對于傳統(tǒng)軟件來說，按集成粒度不同，可以把集成測試分為3個層次，即：（1）模塊間集成測試（2）子系統(tǒng)內(nèi)集成測試（3）子系統(tǒng)間集成測試

對于面向對象的應用系統(tǒng)來說，按集成粒度不同，可以把集成測試分為2個層次：

（1）類內(nèi)集成測試（2）類間集成測試集成測試的原則

（1）所有公共接口必須被測試到；（2）關鍵模塊必須進行充分測試；（3）集成測試應當按一定層次進行；（4）集成測試策略選擇應當綜合考慮質量、成本和進度三者之間的關系；（5）集成測試應當盡早開始，并以概要設計為基礎；

（6）在模塊和接口的劃分上，測試人員應該和開發(fā)人員進行充分溝通；（7）當測試計劃中的結束標準滿足時，集成測試才能結束；

（8）當接口發(fā)生修改時，涉及到的相關接口都必須進行回歸測試；（9）集成測試應根據(jù)集成測試計劃和方案進行，不能隨意測試；（10）項目管理者應保證測試用例經(jīng)過審核；（11）測試執(zhí)行結果應當如實的記錄。7、

集成測試過程

一個測試從開發(fā)到執(zhí)行遵循一個過程，不同的組織對這個過程的定義會有所不同。根據(jù)集成測試不同階段的任務，可以把集成測試劃分為5個階段：計劃階段、設計階段、實施階段、執(zhí)行階段、評估階段。8、

集成測試用例設計

1．為系統(tǒng)運行設計用例

可使用的主要測試分析技術有：（1）等價類劃分。（2）邊界值分析。

（3）基于決策表的測試。2．為正向測試設計用例

可使用如下幾種主要測試分析技術：（1）輸入域測試。（2）輸出域測試。（3）等價類劃分。（4）狀態(tài)轉換測試。（5）規(guī)范導出法。3．為逆向測試設計用例

可使用的主要測試分析技術有：（1）錯誤猜測法。（2）基于風險的測試。（3）基于故障的測試。（4）邊界值分析。（5）特殊值測試。（6）狀態(tài)轉換測試。

第八章系統(tǒng)測試

1、系統(tǒng)測試（systemtesting）是指測試整個系統(tǒng)已經(jīng)確定是否能夠提供用戶的所有需求行為。選擇

系統(tǒng)測試主要分為功能性測試和非功能性測試兩大類。

功能性測試包括：功能測試、用戶界面測試、安裝/卸載測試、可適用性測試。非功能性測試包括：性能測試、壓力測試、兼容性測試、可靠性測試、安全性測試、健壯性測試。2、功能測試方法：

有兩種：鏈接或界面切換測試和業(yè)務流程測試。3、業(yè)務流程測試主要測試內(nèi)容：1.主要是系統(tǒng)應用功能的測試。2.基于用例場景設計測試用例。

3.用例場景是通過描述流經(jīng)用例的路徑來確定的過程，這個流經(jīng)過程要從用例開始到結束遍歷其中所有基本流和備選流。

4、性能測試：

性能測試主要檢驗軟件是否達到需求規(guī)格說明書中規(guī)定的各類性能指標，并滿足一些性能相關的約束和限制條件。

目標：對產(chǎn)品的性能進行測試，檢驗是否達標、是否能夠保持。方法：覆蓋系統(tǒng)的性能需求，一般和負載測試結合使用。工具：在需要大訪問量時尤其需要使用工具。

測試內(nèi)容：評估系統(tǒng)的能力、識別系統(tǒng)中的弱點、系統(tǒng)調優(yōu)。

5、壓力測試

壓力測試（StressTesting）是指模擬巨大的工作負荷，以查看系統(tǒng)在峰值使用情況下是否可以正常運行。

壓力測試是通過逐步增加系統(tǒng)負載來測試系統(tǒng)性能的變化，并最終確定在什么負載條件下系統(tǒng)性能處于失效狀態(tài)，以此來獲得系統(tǒng)性能提供的最大服務級別的測試。6、

壓力測試與性能測試的聯(lián)系與區(qū)別：

1)壓力測試是用來保證產(chǎn)品發(fā)布后系統(tǒng)能否滿足用戶需求，關注的重點是系統(tǒng)

整體；

2)性能測試可以發(fā)生在各個測試階段，即使是在單元層，一個單獨模塊的性能

也可以進行評估。

3)壓力測試是通過確定一個系統(tǒng)的瓶頸，來獲得系統(tǒng)能提供的最大服務級別的

測試。

4)性能測試是檢測系統(tǒng)在一定負荷下的表現(xiàn)，是正常能力的表現(xiàn)；而壓力測試

是極端情況下的系統(tǒng)能力的表現(xiàn)。壓力測試和負載測試（LoadTest）：

負載測試是通過逐步增加系統(tǒng)工作量，測試系統(tǒng)能力的變化，并最終確定在滿足功能指標的情況下，系統(tǒng)所能承受的最大工作量的測試。壓力測試實質上就是一種特定類型的負載測試。

壓力測試和并發(fā)性測試：

并發(fā)性測試是一種測試手段，在壓力測試中可以利用并發(fā)測試來進行壓力測試。

7、容量測試

所謂的容量測試（VolumeTesting）是指，采用特定的手段測試系統(tǒng)能夠承載處理任務的極限值所從事的測試工作。這里的特定手段是指，測試人員根據(jù)實際運行中可能出現(xiàn)極限，制造相對應的任務組合，來激發(fā)系統(tǒng)出現(xiàn)極限的情況。容量測試的目的

容量測試的目的是使系統(tǒng)承受超額的數(shù)據(jù)容量來發(fā)現(xiàn)它是否能夠正確處理，通過測試，預先分析出反映軟件系統(tǒng)應用特征的某項指標的極限值（如最大并發(fā)用戶數(shù)、數(shù)據(jù)庫記錄數(shù)等），確定系統(tǒng)在其極限值狀態(tài)下是否還能保持主要功能正常運行。容量測試還將確定測試對象在給定時間內(nèi)能夠持續(xù)處理的最大負載或工作量。

8、容量測試與壓力測試的區(qū)別

1)與容量測試十分相近的概念是壓力測試。二者都是檢測系統(tǒng)在特定情況下，

能夠承擔的極限值。

2)然而兩者的側重點有所不同，壓力測試主要是使系統(tǒng)承受速度方面的超額負

載，例如一個短時間之內(nèi)的吞吐量。

3)容量測試關注的是數(shù)據(jù)方面的承受能力，并且它的目的是顯示系統(tǒng)可以處理

的數(shù)據(jù)容量。

9、壓力測試、容量測試和性能測試的區(qū)別

更確切的說，壓力測試可以看作是容量測試、性能測試和可靠性測

試的一種手段，不是直接的測試目標。壓力測試的重點在于發(fā)現(xiàn)功能性測試所不易發(fā)現(xiàn)的系統(tǒng)方面的缺

陷，而容量測試和性能測試是系統(tǒng)測試的主要目標內(nèi)容，也就是確定軟件產(chǎn)品或系統(tǒng)的非功能性方面的質量特征，包括具體的特征值。容量測試和性能測試更著力于提供性能與容量方面的數(shù)據(jù)，為軟件

系統(tǒng)部署、維護、質量改進服務，并可以幫助市場定位、銷售人員對客戶的解釋、廣告宣傳等服務。壓力測試、容量測試和性能測試的測試方法相通，在實際測試工作

中，往往結合起來進行以提高測試效率。一般會設置專門的性能測試實驗室完成這些工作，即使用虛擬的手段模擬實際操作，所需要的客戶端有時還是很大，所以性能測試實驗室的投資較大。對于許多中小型軟件公司，可以委托第三方完成性能測試，可以在很大程度上降低成本。

10、安全性測試

安全性測試時檢查系統(tǒng)對非法侵入的防范能力，其目的是發(fā)現(xiàn)軟件系統(tǒng)中是否存在安全漏洞。

安全性一般分為兩個層次，級應用程序級的安全性和系統(tǒng)級別的安全性。安全性測試方法:1.功能驗證2.漏洞掃描

3.模擬攻擊實驗

11、回歸測試

回歸測試是指對某些已經(jīng)被測試過的內(nèi)容進行重新測試。

第九章驗收測試

1、

驗收測試分為用戶驗收測試和操作驗收測試。

1)用戶驗收測試的目標是確認被測應用能滿足業(yè)務需求，并在將軟件正式交付

給最終用戶之前，確保系統(tǒng)正常工作并可以使用。用戶驗收測試在測試組的協(xié)助下由一個或多個用戶代表執(zhí)行的。

2)操作驗收測試的目標是確認被測應用滿足其操作需求，并確保系統(tǒng)正式工作

并可以使用。操作驗收測試在測試組的協(xié)助下由一個或多個操作代表執(zhí)行的。

3)用戶驗收測試與操作驗收測試的不同之處在于，操作驗收測試是用于驗證被

測應用在操作和管理方面的情況（例如更新后的被測應用的安裝，對被測應用極其數(shù)據(jù)的備份、歸檔和恢復以及注冊新用戶并為其分配權限）。用戶驗收測試用來驗證被測應用符合其業(yè)務需求，并在正式提交給最終用戶之前確信系統(tǒng)工作正確并可用。實際上，如果被測應用僅支持一些簡單的系統(tǒng)管理功能，用戶驗收測試與操作測試通常會合并為一個測試活動。2、Alpha測試和Beta測試的區(qū)別？

第十章軟件測試管理

1、如何組織軟件測試團隊？構建高效的測試團隊

第一步：選擇先進的方法論構筑指導流程第二步：選擇合適的人才建設測試團隊第三步：選擇強大的技術平臺搭建環(huán)境第四步：制訂標準和規(guī)范，穩(wěn)步提高質量

2、如何進行測試人員的培養(yǎng)？

一個高效的測試團隊要有人才培養(yǎng)計劃，不斷加強測試人員的職業(yè)技能。人才培養(yǎng)涉及人員選擇、培訓與培養(yǎng)和其職業(yè)發(fā)展規(guī)劃。3、軟件bug有哪些類型？其管理流程是什么？軟件bug的類型如下：

需求類bug、分析設計類bug、程序功能錯誤、程序運行時錯誤、編碼規(guī)范類錯誤、數(shù)據(jù)庫類錯誤、接口類錯誤、界面類錯誤、配置類bug、建議性bug。

友情提示：本文中關于《《數(shù)據(jù)庫系統(tǒng)原理》課程總結與復習大綱》給出的范例僅供您參考拓展思維使用，《數(shù)據(jù)庫系統(tǒng)原理》課程總結與復習大綱：該篇文章建議您自主創(chuàng)作。

來源：網(wǎng)絡整理 免責聲明：本文僅限學習分享，如產(chǎn)生版權問題，請聯(lián)系我們及時刪除。

《《數(shù)據(jù)庫系統(tǒng)原理》課程總結與復習大綱》由互聯(lián)網(wǎng)用戶整理提供,轉載分享請保留原作者信息,謝謝!
鏈接地址：http://m.hmlawpc.com/gongwen/712526.html

• 上一篇：數(shù)據(jù)庫概念總結1
• 下一篇：access重點總結