Chapter01
SE的定義、目的、方法及作用
|
定義：軟件工程即用系統科學的工程性方法解決軟件開發時遇到的問題，也就是，將系統化的、嚴格約束的、可量化的方法應用於軟件的開發、運行和維護。 目的：生產出高質量的軟件進而找到解決方案，並考慮那些對質量有影響的特性。 方法： 分析---分析問題，調查軟件正反兩方面 設計---給出解決方案 開發團隊---描述在團隊中的人員的角色和職責 開發---實現解決方案（實現對象、活動、封裝等等） 項目管理---將系統分爲小部分，逐步明確過程，控制進度，處理每個改變等 作用：付出較低的開發成本，達到要求的軟件功能，取得較好的軟件性能，開發的軟件易於移植，需要較低的維護費用，能按時完成開發工作，及時交付使用。 |
// 開發模式
|
它表示開發軟件時特定的方法或哲學。是軟件開發的全部過程，活動和任務的結構框架，它能直觀的表達軟件開發全過程，明確要完成的主要活動，任務和開發策略。 |
說明錯誤、缺陷、失敗的含義與聯繫。（舉例說明）
|
錯誤:是進行軟件開發過程中人爲出錯造成的 例如，設計人員可能誤解了某個需求，創建出與需求分析人員和用戶的實際意圖不相符的設計。這個設計故障是一種錯誤的編碼，可能導致其他故障，如不正確的代碼或用戶手冊中不正確的描述等。 故障/缺陷：方法實現時出現的問題。（靜態存在） 失效:是指程序運行中出現的問題（由於故障產生）。（動態存在） 例如，需求文檔可能會包含故障，所以即使系統按照需求規格來運行，如果它未進行應有的行爲，也稱爲失效。 聯繫：單個錯誤可能產生多個故障。故障是系統的內部視圖，這是從開發人員的角度看待系統；而失效是系統的外部視圖，它是用戶所看到的問題。並非每一個故障都對應於一個失效（不執行故障代碼就不會是代碼失效）。 |
軟件質量應從哪幾個方面來衡量？論述之。
|
產品的質量 用戶考慮產品的功能要易於使用和學習 開發人員考慮產品的內部特性。 過程的質量 有很多活動會影響到最終的產品質量。只要活動出了差錯，產品的質量就會受到影響。 商業環境背景下的質量 技術價值並不能直接轉換爲商業價值，軟件開發還需要將技術價值和商業價值統一起來 |
// 軟件系統的系統組成。
|
系統 = 實體 + 活動 + 關係 + 邊界 |
現代軟件工程大致包含的幾個階段及各個階段文檔。
|
//使現代SE實踐發生變化的（七個）關鍵因素是什麼？
|
什麼是重用、抽象等現代軟件工程主要概念？
|
重用：重複採用以前開發的軟件系統中具有共性的部件, 用到新的開發項目中去。 抽象：某種層次歸納水平的問題描述。它使我們將注意力集中在問題的關鍵方面而非細節。 |
Chapter02
什麼是軟件過程？軟件過程的重要性是什麼？軟件生命週期？
|
軟件過程： 將一組有序的任務稱爲過程，它涉及活動、約束和資源使用等一系列步驟，用於產生某種想要的需求。軟件過程是軟件開發活動中的各種組織及規範方法。 重要性：
軟件生命週期：軟件開發過程 |
瀑布模型及各階段文檔，優缺點？
|
瀑布模型：它將開發階段描述爲從一個階段瀑布般得轉換到另外一個階段。 需求分析 《SRS》軟件需求規格說明書 系統設計 系統設計文檔《SAD》 程序設計 模塊功能算法和數據描述文檔 編碼 源程序和註釋 單元測試和集成測試 單元測試報告 系統測試 系統測試報告 驗收測試 驗收測試報告 運行與維護 維護報告
優點：
缺點：
----軟件是一個創造的過程, 不是一個製造的過程。
|
原型的概念與用途。
|
原型：一種部分開發的產品，用來讓用戶和開發者共同研究，提出意見，爲最終產品定型。 用途：減少開發中的風險和不確定性 |
論述分階段開發模型的含義, 其基本分類及特點是什麼？
|
含義：系統被設計成部分提交, 每次用戶只能得到部分功能, 而其他部分處於開發過程中。 分類：增量式和迭代式 (對原型化模型的改進) 增量式開發：
迭代式開發：
|
螺旋模型四個象限的任務及四重循環的含義？
|
任務：計劃 目標/可選方案 風險評估 開發和測試 含義：操作概念 軟件需求 軟件設計 系統實現與部署運行 |
// ------ 習題2， 3。
//在所有的軟件開發過程模型中，你認爲哪些過程給予你最大的靈活性以應對需求的變更？
|
什麼是UP， RUP，進化式迭代等市場流行的過程模型?
|
統一過程（UP）可以用三句話來表達： 它是用例驅動的、以基本架構爲中心的、迭代式和增量性的軟件開發過程框架，它使用對象管理組織（OMG）的UML 並與對象管理組織（OMG）的軟件過程工程原模型（SPEM）等相兼容。 RUP是IBM提供支持和包裝的UP系統。 進化式迭代開發：
|
Chapter03
什麼是項目進度？活動？里程碑？
|
項目進度是對特定項目的軟件開發週期的刻畫。包括對項目階段、步驟、活動的分解，對各個離散活動的交互關係的描述，以及對各個活動完成時間及整個項目完成時間的初步估算。 活動：項目的一部分, 一般佔用項目進度計劃中的一段時間。 里程碑：指特定的時間點, 標誌着活動的結束, 通常伴隨着提交物。 |
如何計算軟件項目活動圖的關鍵路徑？（習題2，3）冗餘時間？最早和最遲開始時間
|
關鍵路徑法（CPM） 時差=可用時間-真實時間 時差=最晚開始時間-最早開始時間 |
// 軟件團隊人員應該具備的能力是什麼？
|
完成工作的能力，對工作的興趣，開發類似應用的經驗，使用類似工具或語言、開發環境、技術的經驗，培訓，與其他人交流的能力，與其他人共同承擔責任的能力，管理技能。 |
軟件項目團隊組織的基本結構？
|
主程序員負責制組
忘我方法 |
//專家估算法的大致含義？算式估算法的大致含義？
|
專家估算：請幾位專家做出3種預測，來形式化地表示類推過程：一個悲觀的預測（x）、一個樂觀的預測（y），和最可能的預測（z），通過公式（x+4y+z）/6計算這些數的beta概率分佈的平均值。通過使用這種技術，產生的估算是對個人估算的“規範化”。 算式估算：使用表示工作量和影響工作量的因素之間關係的模型進行估算。這些模型通常用方程式描述。大部分模型認爲項目規模是方程式中影響最大的因素，表示工作量的方程是：E = (a + bSc) m(X)。其中S是估算的系統規模，而a、b、c是常量。X是從x1到xn的一個成本因素的向量，m是基於這些因素的一個調整因子。 |
試述COCOMO模型的三個階段基本工作原理或含義。
|
階段一：項目通常構建原型以解決包含用戶界面、軟件和系統交互、性能和技術成熟性等方面在內的高風險問題。 階段二：設計人員必須研究幾種可選的體系結構和操作的概念。 階段三：開發已經開始，可以根據功能點或代碼行來進行規模估算。 |
什麼是軟件風險？瞭解主要風險管理活動？有幾種降低風險的策略？
|
軟件風險：在軟件生產過程中不希望看到的、有負面結果的事件。
|
弄懂活動圖基本原理（參考課本），找出課後練習題圖3.23和3.24的關鍵路徑。
Chapter04
需求的含義是什麼?
|
對來自用戶的關於軟件系統的期望行爲的綜合描述, 涉及系統的對象、狀態、約束，功能等。 |
需求階段作爲一個工程，其確定需求的過程是什麼？
|
原始需求->獲取問題分析->規格說明草稿->需求覈准->正式的 <SRS> |
舉例說明獲取需求時，若有衝突發生時，如何考慮根據優先級進行需求分類。
例如：信用卡記賬系統： 要求列出最近的費用（1） 要求加起來並要求在某日期前支付（2） 要求購買類型分析（3） |
// 如何使需求變得可測試？（sidebar4.4）
|
A: 針對需求確定一種量化的描述方法，避免模糊的表達方式 B: 將各種指代用詞替換爲實體的正式名稱 C: 每個名詞或款項應在需求文檔中給出唯一定義。 |
需求文檔分爲哪兩類？
|
需求定義和需求規格說明 |
什麼是功能性需求和非功能性需求/質量需求？ 設計約束？過程約束？如何區分？
|
功能性需求：描述系統內部功能或系統與外部環境的交互作用,涉及系統輸入應對,實體狀態變化,輸出結果,設計約束與過程約束等。 非功能性需求/質量需求：描述軟件方案必須具備的某些質量特徵。 設計約束：已經作出的設計決策或限制問題解決方案集的設計決策，例如平臺或構建接口的選擇。 過程約束：對於構建系統的技術和資源的限制。例如，客戶可能堅持使用敏捷方法，以便在繼續增加新特徵的時候能夠使用早期版本。 |
// 需求的特性？（正確性、一致性、完整性）。
|
正確性：我們和客戶都應該評審需求文檔，確保它們符合我們對需求的理解。 一致性：一般來講，如果不可能同時滿足兩個需求，那麼這兩個需求就是不一致的。 無二義性：如果需求的多個讀者能夠一致、有效地解釋需求，那麼需求就是無二義性的。 完備性：如果需求指定了所有約束下的、所有狀態下的、所有可能的輸入的輸出以及必需的行爲，那麼這組需求就是完備的。 可行性：當用戶要求兩個或更多的質量需求時，常常會出現可行性問題。 相關性：有時，某個需求會不必要地限制開發人員，或者會包含與客戶需要沒有直接關係的功能。 可測試性：如果需求能夠提示驗收測試（明確證明最終系統是否滿足需求），需求就是可測試的。 可跟蹤性：對需求進行精心組織並唯一標記，已達到易於引用的目的；求定義中的每一條都在需求規格說明中有對應，反之亦然。 |
瞭解DFD圖的構成及畫法。
|
數據流圖，箭頭表示數據流，數據存儲是一個正式的庫或信息庫，表示爲兩個平行的條，數據源或者數據接收器表示爲矩形，稱爲參與者。
|
// 在需求原型化方面，什麼是拋棄型原型？什麼是演化型原型？
|
拋棄型原型：爲了對問題或者提議的解決方案有更多的瞭解而開發的軟件。 在真正實現後就拋棄不用了。 演化型原型：用於瞭解問題，並作爲將來準備提交的系統的一部分而開發的軟件。 |
// 用DFD圖簡單描述ATM機的工作原理（主要功能和數據流）（習題7）
Chapter05
什麼是軟件體系結構？設計模式？設計公約？設計？ //概念設計？技術設計？
|
體系結構:一種軟件解決方案，用於解釋如何將系統分解爲單元，以及單元如何相互關聯，還包括這些單元的所有外部特性。 設計模式：編寫了設計決策以及最好的實踐，它們根據設計原則來解決一些特定的問題；它們不是拿來就可以使用的打包的解決方案，而是解決方案的模板，必須針對特定的狀況進行修改和調整。 一種針對單個軟件模塊或少量模塊而給出的一般性解決方案，它提供較低層次的設計決策。(此設計決策低於體系結構) (注: 此處爲說明,不是定義) 設計公約：一系列設計決策和建議的集合，用於提高系統某方面的設計質量。 概念設計：告訴客戶系統要做什麼，即軟件架構和功能。 技術設計：相當於程序設計，告訴程序員軟件系統將要做什麼，即程序員的參考文檔。 |
軟件設計過程模型的幾個階段？
|
初始建模->分析->文檔化->複審->輸出:正式的 <SAD> ：軟件體系結構文檔 |
// 三種設計層次極其關係？
|
體系結構設計：由軟件需求中的系統能力與系統部件關聯起來而得到軟件整體結構的過程 代碼設計：各個部件（模塊）的算法、數據結構的設計 運行設計：最底層設計—內存分配、數據格式、位模式等 |
|
關係：流程工作中，先是體系結構設計，然後是代碼設計，最後是運行設計；隨着設計人員對解決方案及其含義有更多的理解，他們就會往返於各層次之間。（程序設計由代碼設計和運行設計組成） |
|
體系結構：一種軟件設計方案，說明如何將系統分解爲單元以及這些單元的關聯方式，以及所有單元的外部可見特性。 |
|
體系結構風格: 大規模系統結構模式, 包括規則、元素、技術。 |
//什麼是模塊化？什麼是抽象？
|
模塊化：也稱作關注點分離，是一種把系統中各不相關的部分進行分離的原則，以便於各部分能夠獨立研究。 抽象：對細節的隱藏。 |
論述設計用戶界面應考慮的問題。
|
設計界面要注意解決的要素（寓意/比喻、思維模型、模型的導航規則、外觀、感覺）； 文化差異問題； 用戶愛好問題。 |
5.5節----模塊獨立性----耦合與內聚的概念及各個層次劃分？
|
耦合：兩個軟件部件之間的相互關聯程度。 耦合的六種層次： 非直接耦合：模塊相互之間沒有信息傳遞 數據耦合 ：模塊間傳遞的是數據 特徵耦合 ：模塊間傳遞的是數據結構 控制耦合 ：模塊間傳遞的是控制量 公共耦合 ：不同模塊訪問公共數據 內容耦合 ：一個模塊直接修改另一個模塊 (A模塊直接調用B模塊的私有數據, 或直接轉移到B模塊中去)
內聚：軟件部件內部各組成成分的關聯程度。 內聚的七種層次： 偶然性內聚：不相關的功能, 過程,數據等出現在同一個部件中 邏輯性內聚：邏輯上相關或相似的功能或數據放置在同一個部件內 時間性內聚：部件各部分要求在同一時間完成 通訊性內聚：各部分訪問共享數據 過程性內聚：各部分有特定次序 順序性內聚：各部分有輸入輸出關係 功能性內聚：各部分組成單一功能 |
軟件過程中複審的概念，設計複審的重要性。
|
複審： 檢查文檔是否滿足所有功能及質量需求。 設計複審的重要性： (1) 複審中批評和討論是“忘我”的， 能將開發人員更好地團結在一起， 提倡並增強了成員之間的交流 (2) 在評審過程中故障的改正還比較容易， 成本還不高， 在這時候發現故障和問題會使每一個人受益。 |
Chapter06
// 什麼是面向對象？OO有幾個基本特徵？如何使用高級語言實現這些基本特徵？掌握並使用高級語言的OO基本編程方法和技巧。
什麼是設計模式？
|
面向對象是一種軟件開發方法，它將問題及其解決方法組織成一系列獨立的對象，數據結構和動作都被包括在內 基本特徵：分類、抽象、封裝、繼承、多態、持久性、一致性 設計模式編寫了設計決策以及最好的實踐，它們根據設計原則來解決一些特定的問題；它們不是拿來就可以使用的打包的解決方案，而是解決方案的模板，必須針對特定的狀況進行修改和調整。 |
瞭解OO設計的基本原則？
|
抽象、接口、模塊化、通用性、信息隱藏、增量式開發 |
瞭解OO開發有何優勢？
|
語言具有一致性（採用相同的語義結構（類、對象、接口、屬性、行爲）描述問題和解決方案） 過程具有一致性（從需求到測試，所有的過程採用相同的語義構造）。 |
OO開發過程有幾個步驟？
|
OO需求分析+OO高層設計+OO低層設計+OO編程+OO測試 |
掌握用例圖的組成和畫法，用例的幾個要素的含義。 //掌握用例圖的實例解析方法
|
用例：描述系統提供的特定功能， 用橢圓表示 執行者：和系統交互的實體（ 用戶、 設備或其他） ， 用小人表示。 包含：對已定義用例的複用， 用以提取公共行爲， 用帶箭頭的實線表示 擴展：對一個用例的擴展使用， 用以下圖標表示 |
用例圖、類圖等針對面向對象的項目開發的意義是什麼？
|
用例：描述了應該執行或展示的特定功能 用例圖：通過建立用戶、外部項、其他實體的對話模型，而對系統將要完成的功能進行描述或刻畫。 這些表示法每種都顯現了系統的某個方面，因此相應地，這種表達也提供了對於問題或解決方案的詳細描述。 |
熟悉類圖中各個類之間的基本關係分類及其含義。 //狀態圖的含義及用途。
熟悉用例圖、類圖、狀態圖等的組成和畫法。
瞭解UML其他圖示結構的基本用途。
Chapter07
//爲什麼說編碼工作是紛繁複雜甚至令人氣餒？
|
一般性的編程原則應該從哪三個方面考慮？
|
編程標準對自身的用處 編程標準對他人的用處 設計與編程實現相匹配 |
//論述編碼階段實現某種算法時所涉及的問題。
|
編寫更快代碼的代價。可能會使代碼更加複雜，從而花費更多的時間編寫代碼。 測試代碼的時間代價。代碼的複雜度要求有更多的測試用例或測試數據。 用戶理解代碼的時間代價。 需要修改代碼時，修改代碼的時間代價。 |
在編寫程序內部文檔時，除了HCB外，還應添加什麼註釋信息？注意什麼？
|
其他程序註釋，包括： 版本註釋：隨着時間進行修改的記錄。 解釋性註釋：本段源代碼是在做什麼的註釋。 分解性註釋：通過註釋將代碼分解成多個段。 注意的問題： |
什麼是極限編程(XP)? 以及派對編程？
|
極限編程（XP）是一種輕量級的軟件開發方法論，屬於敏捷開發方法。XP是經過實踐後對實踐的總結，其主要特徵是要適應環境變化和需求變化，充分發揮開發人員的主動精神。XP承諾降低軟件項目風險，改善業務變化的反應能力，提高開發期間的生產力，爲軟件開發過程增加樂趣等等 。 派對編程屬於主要的敏捷開發方法，其開發方式是兩個程序員共同開發程序，且角色分工明確。一個負責編寫程序，另一個負責複審與測試。兩人定期交換角色。 |
Chapter08
瞭解產生軟件缺陷的原因？
|
規格說明可能是錯誤的，或者遺漏了某個需求。 對於指定的硬件和軟件，規格說明中可能包含不可能實現的需求。 系統設計中可能包含故障。 程序設計中可能包含故障。 程序代碼可能是錯誤的。 |
// 將軟件缺陷進行分類的理由？
|
當不存在明顯的故障時，我們就測試程序，通過創造一些條件，使代碼不能像計劃的那樣做出反應，看一看能否發現更多的故障。因此，知道我們正在查找什麼類型的故障是很重要的。 |
有幾種主要的缺陷類型？
|
算法缺陷，計算和精度缺陷，文檔缺陷，過載缺陷，能力缺陷 |
什麼是正交缺陷分類？
|
被分類的任何一項故障都只屬於一個類別， 則分類方案是正交的。 如果一個故障屬於不止一個類， 則失去了度量的意義。 |
測試的各個階段及其任務？（圖8.3）
|
模塊測試、構件測試或單元測試： 將每個程序構件與系統中的其他構件隔離， 對其本身進行測試。 集成測試：測試系統構件是否符合系統和程序設計規格說明中描述的功能共同工作。 功能測試：測試系統的功能是否符合需求規格說明文檔中描述的功能，其結果是一個可運轉的系統。 性能測試：測試系統的軟硬件性能是否符合需求規格說明文檔中的描述。其結果是一個確認的系統。 驗收測試：確定系統是按照用戶的期望運轉的。 安裝測試：確保系統在實際環境中按照應有的方式運轉。 系統測試：功能測試、性能測試、驗收測試和安裝測試統稱爲系統測試。 |
// 測試的態度問題？（爲什麼要獨立設置測試團隊？）
|
測試過程中難以排除個人感情，因此，通常使用獨立的測試小組來測試系統，這樣就避免了故障的個人責任與儘可能多地發現故障的需要之間的衝突。 |
掌握測試的方法----黑盒、白盒的概念？
|
黑盒：測試人員在完全不瞭解程序內部的邏輯結構和內部特性的情況下，只依據程序的需求規格及設計說明，檢查程序的功能是否符合它的功能說明。 白盒：以測試對象的內部結構爲基本依據，手工或自動的展開各種測試。 |
什麼是單元測試？
|
檢查代碼，與需求及設計比較->編譯代碼(編譯和調試)->開發測試用例並進行測試 |
//什麼是走查和檢查？
|
在走查中，程序員向評審小組提交代碼及其相關文檔，然後評審小組評論它們的正確性。 在審查中，評審小組按照一個事前準備好的關注問題清單來檢查代碼和文檔（更正式）。 |
黑盒白盒方法各自的分類？測試用例的設計和給出方法。
黑盒白盒方法的分類，各種覆蓋方法等。（課件等）
|
分類： 等價分類法 邊界值分析法 錯誤猜測法 因果圖法 邏輯覆蓋法，包括： 語句覆蓋：使被測程序的每條語句至少執行一次； 判定覆蓋：使被測程序的每一分支至少執行一次，故又稱分支覆蓋； 條件覆蓋：要求判定中的每個條件均按“真”、“假”兩種結果至少執行一次。 如果判定中僅含一個條件，條件覆蓋也就是判定覆蓋；但若判定中包含兩個或更多的條件，情況就不同了。 條件組合覆蓋：要求讓所有結果的所有可能都至少出現一次。 路徑測試法，包括： 節點覆蓋：程序的測試路徑至少經過程序圖中的每個節點一次 邊覆蓋：程序的測試路徑至少經過程序圖中的每條邊一次 路徑覆蓋： 程序的測試路徑至少經過程序圖中的每條路徑一次 完全覆蓋：同時滿足節點覆蓋和邊覆蓋的覆蓋稱爲完全覆蓋 |
如何面對一個命題，設計和給出測試用例的問題。（課件）
------課堂練習的測試題目和講解內容
集成測試及其主要方法的分類？（驅動，樁的概念）
|
分類： 由底向上集成測試 自頂向下集成測試 莽撞測試 混合方式測試（三明治測試） 驅動模塊：代替上級模塊傳遞測試用例的程序) 樁模塊：代替下級模塊的仿真程序 |
// 傳統測試和OO測試有何不同？OO測試有何困難？
|
面向對象系統的測試中更容易和更困難的部分：
(1)測試用例的充分性：對過程語言而言，當系統改變時，我們可以針對改變測試是否正確，並使用原有的測試用例來驗證剩餘的功能是否同原來一致。但是面向對象的測試中，我們可能需要編寫不同的測試用例。 (2)面向對象趨向於小粒度，並且平常存在於構件內的複雜性常常轉移到構件之間的接口上。 這意味着，其單元測試較爲容易，但是集成測試涉及面變得更加廣泛。 (3)傳統測試和麪向對象的測試主要集中在：需求分析和驗證、測試用例生成、源碼分析和覆蓋分析。 |
// 測試計劃涉及的幾個步驟？ （瞭解）
|
（1）制定測試目標 （2）設計測試用例 （3）編寫測試用例 （4）測試測試用例 （5）執行測試 （6）評估測試結果 |
Chapter09
系統測試的主要步驟及各自含義？（圖9.2）
|
功能測試：測試系統的功能是否符合需求規格說明文檔中描述的功能，其結果是一個可運轉的系統。 性能測試：測試系統的軟硬件性能是否符合需求規格說明文檔中的描述。其結果是一個確認的系統。 驗收測試：確定系統是按照用戶的期望運轉的。 安裝測試：確保系統在實際環境中按照應有的方式運轉。
|
// 什麼是系統配置？軟件配置管理？ // 基線？（或見課件）
|
系統配置：交付給特定客戶的一系列部件的集合 配置管理：對系統不同軟件配置的管理及控制方法（既有開發，也有測試），通過控制系統差別以降低風險，減少錯誤 基線：是指軟件文檔和其他資料的集合，它們代表了產品在某一時間點的情況(以及其他參考點) |
// 什麼是迴歸測試？
|
迴歸測試是用於新的版本的一種測試，以驗證與舊版本相比，它是否以同樣的方式執行相同的功能。 |
功能測試的含義極其作用？
|
功能測試：基於系統功能性需求，屬於閉盒測試。我們不必知道正在執行哪個構件，相反，必須知道系統應該做什麼。 作用：將系統的實際表現與其需求進行比較。 |
功能測試的基本指導原則？
|
A: 較高的查錯概率 B: 獨立的測試團隊 C: 瞭解預期的輸出結果 D: 對合法與非法的輸入都予以測試（假設是弱健壯等價類） E: 不能僅僅爲了測試的方便而修改系統 F: 停止測試應該有前提條件 |
性能測試的含義與作用？
|
在我們確定系統能執行需求所要求的功能之後，就要考慮這些功能執行的方式。 因此，功能測試針對的是功能需求，而性能測試針對的是非功能需求。 |
性能測試的主要分類？
|
A: 壓力測試 / 強度測試(在短時間內加載極限負荷, 以驗證系統能力) B: 巨量數據測試 / 容量測試(驗證系統處理巨量數據的能力) C: 配置測 ---構建測試用例 對系統軟硬件的各種配置(最小到最大)進行測試。 D: 兼容性測試---測試接口等 E: 迴歸測試 F: 安全測試 G: 計時測試 H: 環境測試 |
/ 什麼是可靠性、可用性和可維護性？
|
可用性：是指在給定的時間間隔，一個系統能夠按照規格說明正確運作的概率。 可靠性：是指一個軟件系統在給定的時間間隔和給定條件下運行成功的概率。 可維護性：是在給定的使用條件下，在規定的時間間隔內，使用規定的過程和資源完成維護活動的概率。 |
確認測試概念，確認測試分類？（基準測試和引導測試）
|
當功能測試和性能測試完成後，我們確信，系統滿足在軟件開發的初始階段過程中指定的所有需求，下一步要詢問客戶和用戶，他們是否持有同樣的觀點。 |
|
基準測試：客戶準備一組代表在實際安裝後系統運作的典型情況的測試用例。針對每一個測試用例，客戶評估系統的執行情況。 |
|
並行測試：當一個新系統要替代現有系統，或者該新系統是分階段開發的一部分，使用並行測試。在並行測試中，新系統與先前版本並行運轉，用戶逐漸地適應新系統，但是繼續使用與新系統功能相同的老系統。 |
|
引導測試：在假設系統已經永久安裝的前提下執行系統。它依賴系統的日常工作進行測試，相對基準測試不是非常的正式與結構化（分爲α測試和β測試兩種） |
什麼是alpha測試？β測試？
|
α測試：在客戶進行實際的試驗性測試之前先讓來自自己組織機構或公司的用戶來測試這個系統，這樣的內部測試稱爲α測試。 |
|
β測試：客戶的測試，屬於試用性質的非正式的驗收測試。 |
什麼是安裝測試？
|
即在用戶的場所安裝系統。如果驗收測試已經是在實地進行，就不一定需要安裝測試了。 |
