软件质量保证划重点期末复习总结
軟件質量保證復習總結大綱及問題
Module1 《軟件工程實踐》
1、軟件工程實踐通過解決問題的根源來指導軟件開發。
2、軟件工程實踐之間相輔相成。
3、過程指導一個團隊在什么時候做什么以及如何做。
4、軟件工程過程為實現軟件工程實踐提供了上下文和支持。
Module2 《軟件質量》
1、什么是Quality？
軟件質量是軟件符合明確敘述的功能和性能需求、文檔中明確描述的開發標準、以及所有專業開發的軟件都應具有的和隱含特征相一致的程度。
2、都有誰是Stakeholders？
用戶、客戶、開發人員、銷售人員、上層管理
3、什么是Defect？
Stakeholders眼中的缺陷可以包括任何使程序具有更低價值的程序。
4、Quality的維度都有哪一些？(FURPS)
1) Functionality
2) Usablity
3) Reliability
4) Performance
5) Supportability
5、什么是SQA?
SQA是Software Quality Assurance。
一套系統的、有計劃的行動，以保證軟件系統產品的軟件開發過程或維護過程符合既定的功能和技術要求，
以及保持進度和在預算范圍內操作的管理要求。
6、SQA都包含那些組件？
1）工作項目前期工作質量組件 Pre-project quality components
2）項目生命周期質量組件 Project life cycle quality components
3）基礎設施錯誤預防和改進組件 ?Infrastructure error preventive and improvement components
4）軟件質量管理組件 Software quality management components
5）標準化、認證和SQA評估組件 Standardization, certification and SQA assessment components
6）組織SQA人類組件 Organizing for SQA the human components
Module3 《軟件測試導論》
-1、推薦的程序是使用黑盒方法開發測試用例，然后用白盒方法開發輔助測試用例。
0、?Testing is the process of executing a program with the intent of finding errors.
1、什么是Software Testing？
軟件測試是一個過程，或者是一系列的過程，目的是確保計算機代碼做它被所設計來做的事情，
并且它不會做任何意想不到的事情。
2、軟件測試的Models是什么？
1) V模型（一般開發過程為古老的瀑布模型）
僅僅把測試過程作為在需求分析、系統設計及編碼之后的一個階段 ；
忽視了測試對需求分析,系統設計的驗證，一直到后期的驗收測試才被發現。（缺陷）
2) W模型
測試和開發活動也保持著一種線性的前后關系，上一階段完全結束，才可正式開始下一個階段工作。這樣就無法支持迭代的開發模型。（缺陷）
測試的活動與軟件開發同步進行； 測試的對象不僅僅是程序，還包括需求和設計； 盡早發現軟件缺陷可降低軟件開發的成本。（優點）
3、 什么是功能性(Functional)測試？
功能性測試是一種對除性能以外的軟件外可見的或可測量的屬性感興趣的測試，在功能性測試中，我們把程序看成是一組功能的集合。
4、什么是測試思想(Test Ideas)？
一個測試的想法是一個簡短的陳述，用來確定一個可能有用的測試。
5、測試思想(Test Ideas)與測試用例(Test Case)的區別？
測試思想與測試用例不同，測試思想不包含測試工作的規范，只是測試背后思想的本質。
測試思想是測試用例的生成器:潛在的測試用例來自于測試思想列表。
6、測試思想(Test Ideas)在什么地方有用處？
暫定
7、給出一些測試思想的例子。
8、什么是Test-Ideas Catalog？
測試思想目錄是在許多情況下可用的相關測試思想的列表。
9、說明a catalog of測試思想如何應用到測試矩陣(Test Matrix)上?
（列表頭是測試思想，行表頭是輸入框）
Module4 《RUP測試規程》
1、什么是“統一軟件開發過程”(RUP-Rational Unified Process)?
Rational統一過程(Rational Unified Process,RUP)是一個軟件工程過程框架，它
為在軟件開發組織中分配任務和職責提供了一個有序而靈活的方法。
2、RUP's goal:
在可預測的進度和預算中生產滿足最終用戶需求的高質量軟件。
3、 RUP的4個階段
1) Inception(初始階段)
2) Elaboration(細化階段)
3) Construction(構造階段)
4)?Transition(交付階段)
4、里程碑
5、角色、活動、工件。
角色:一組相關的職責，可以分配給開發組織中的個人或團隊。
活動:一個角色可以被要求執行的工作單元。
工件:一種活動產生、修改或使用的信息。
6、測試中的角色
1) Test Manager(測試經理)?測試經理角色的任務是負責測試工作的成功。
2) Test Analyst(測試分析師)??測試分析人員角色負責最初確定和定義所需的測試，然后評估測試工作的結果。
3) Test Designer(測試設計人員)?測試設計人員角色負責定義測試方法并確保其成功實現。
4) Tester (測試人員)??測試人員角色負責測試工作的核心活動，包括進行必要的測試并記錄測試結果。
7、RUP測試過程工作流（The RUP Test Discipline Workflow）
1)? Define Evaluation Mission?定義評估任務
2)?Test and Evaluate?測試和評估
3)?Achieve Acceptable Mission?達成可接受的任務
4)?Verify Test Approach??驗證測試方法?
5)?Validate Build Stability 驗證構建穩定性
6)?Improve Test Assets? 改進測試資產
8、RUP Test Discipline總結：
1) 提出了可迭代的測試過程
2) 可伸縮和可定制
3) 靈活性
Module 5 《定義評估任務》
-1、什么是 Evaluation Mission？
定義測試的目標、范圍、邊界，給出所用的測試方法，定義如何監視評估測試過程。
0、測試的目的(Purpose)？
1）找Bug。
2）評估產品的整體狀況。
1、什么是測試任務(Test Mission)?
Find defects
Maximize bug count
Block premature product releases
Help managers make ship / no-ship decisions
Assess quality
Minimize technical support costs
Conform to regulations
Minimize safety-related lawsuit risk
Assess conformance to specification
Find safe scenarios for use of the product (find
ways to get it to work, in spite of the bugs)
Verify correctness of the product
Assure quality
2、 什么是一個好的測試方法(Approach)?
1）Diversified? 多樣化的
2）Risk-focused 關注風險的
3）Product-specific 產品特異
4）Practical 現實的
5）Defensible 可辯解的
3.0、測試文檔
1）Test Plan
2）Test-design specification
3）Test-case specification
4）Test-proprocedure specification
5）Test-item transmittal report
6）Test-log
3、什么是測試文檔(Test Documentation Mission)的目標?
a）測試文檔集將主要支持我們在這個版本中發現bug、委派工作和跟蹤狀態。
b）測試文檔集將支持持續的產品和測試維護至少10年，將為新成員提供培訓材料，并將創建適合于管理或訴訟使用的檔案。
Module 6 《測試&評估》
1、有關測試(Test)
1）對于每個測試周期，該工作主要集中在:在測試和評估工作中達到適當的廣度和深度。
2）這是測試周期的核心，測試本身并分析結果。
2、測試技術的5個維度。
1）Testers（測試人員）
2）Coverage（測試什么）
3）Potential Problems（潛在問題）
4）Activities（活動）
5）Evaluation（評估）
3、十種測試方法
1）Function testing 功能測試
Coverage：每個功能和用戶可見的變量。
Testers：Any
盲點：沒有考慮功能間的交互。
評估：只要能工作就行。
2）Equivalence analysis 等價類劃分
Coverage：所有的數據字段
Testers：Any
潛在問題：數據、配置、錯誤處理。
優點：a）用較小的測試用例集合找出最可能的缺陷。b）方法直觀，概括性好。
盲點：邊界或明顯特殊情況下的錯誤。以及取值集合實際上不可知。
步驟：a）確定等價類 b）定義測試用例
評估：取決于數據選取。
3）Specification-based testing 基于規格說明書的測試
Tag Line：驗證每個需求。
Coverage：文檔需求、特性。
Testers：Any
Activities：編寫和執行基于spec的測試。審查和跟蹤管理文檔。
評估：行為符合sepc嗎。
優點：有效管理規則驅動測試的范圍。降低了技術支持成本和客戶抱怨。
盲點：沒有出現在規格說明書中或者記錄不準確的。
*用戶手冊、軟件備忘錄、產品資料等可以作為缺少spec時的替代品。
4）Risk-based testing 基于風險測試
3key meanings：
1>找到缺陷 2>管理找缺陷過程 3>管理測試項目以及由測試與整個項目的關系導致的風險。
Testers：Any
目標：按優先級排序，根據我們可以測試的問題的相對風險來改進測試
Activities：使用【服務質量】、【風險啟發式】和【缺陷模式】來識別風險
優點：最佳優先級，大功率測試。
缺點：不確定的風險可能更容易發生風險。測試人員主觀性太強。
5）Stress testing 壓力測試
Testers:Specialists
Activites：創建自動化測試套件，并針對每個(主要)構建運行
Evaluation：Varies
優點：暴露風險，暴露安全中出現的弱點。
缺點：壓力測試不會明顯暴露的一些缺陷測不到。
6）Regression testing 回歸測試
tag：變革后的自動測試
目標：發現軟件變化后不可預見的錯誤。
Testers：Varies
優點：執行成本低，配置化測試，監管友好。
壞處：**維護回歸測試套件的成本。
7）Exploratory testing 探索性測試
tag：同時學習，計劃和測試
目標：同時了解產品及其測試策略，以揭示產品及其缺陷
Activites：學習、計劃、測試
優點：以風險為中心，以客戶為中心。適應不斷變化的環境。查找其他的遺漏錯誤。
缺點：富有技巧性。受限于測試者的弱點。
Testers：Explorers
8）User testing 用戶測試
目標：整個系統上識別錯誤。
Testers：Users
Coverge：很難度量
Activites：直接由用戶進行
評估：由用戶進行評估。
缺陷百分比= 100*（1-（1-L）^n）
n是用戶人數，L是一個用戶找問題的概率。
9）Scenario testing 情景測試
目標：用具有挑戰性的案例來反應真實適用情況。
潛在問題：經驗豐富的用戶使用的復雜交互。
Activites：Interview Stakeholders，write screenplays。
Testers:any
Coverage：故事觸及到的地方。
優點：可以處理過于復雜的情況。隨著時間推移暴露缺陷。
缺點：單功能缺陷使得測試效率低下。必須仔細考慮才能達到良好的覆蓋率。
理想場景有4個特征：
a）realistic
b）easy to evaluate 容易評估測試通過與否
c）complex
d）測試不通過這個場景就會有stakeholder表示抗議。
10）Stochastic or Random testing 隨機測試
Coverage：Broad but Shaddow
Testers：Machines
Activites：Focus on test generation
Evaluation：基于狀態的
4、測試技術在項目開發中不斷改變。
5、path testing
白盒測試、結構性測試、基于代碼的測試、可以嚴格定義和數學分析
6、覆蓋結構性指標
1）DD-path路徑覆蓋 （decision-to-decision path）判定到判定路徑
2）路徑覆蓋
3）點覆蓋（語句覆蓋）
4）邊覆蓋
5）分支覆蓋
Module 7 《Analyze Test Failures》
1、Evaluate：?This module focuses on the activity Analyze Test Failures
2、變更請求（request change）的目的是什么？
變更:任何事件、缺陷或潛在改進報告要求對正在開發的軟件進行更改請求。
3、缺陷報告：缺陷報告是用來說服某人分配時間和精力來修復bug的工具。
1）Visibility? 可見性
2）Effectiveness? 有效性
4、缺陷報告格式：
1）報告ID
2）報告人
3）報告日期
4）測試項
5）版本號
6）前置條件
7）可否重現
8）嚴重程度
9）優先級
10）報告類型（例如編碼錯誤、設計問題、文檔查詢）
11）摘要
12）關鍵詞
13）復現步驟
14）建議解決方案
15）狀態（Open\closed）
16）解決方案
17）解決方案版本
18）解決者
19）解決方案測試：
20）變更版本
21）評論
22）小結
5、高級測試人員評審提交的缺陷，然后標記為Open并分配給開發人員。
Module 8 《Achieve Acceptable Mission》
1、目的：
我們將實時監控正在實現的任務，并報告測試工作的狀態。
為測試工作的利益相關者提供一個有用的評估結果。
2、在每個測試周期中，工作關注：
1）積極地優先考慮必須進行的最低限度的測試，以完成評估任務。
2）主張解決對評價任務有重大負面影響的重要問題。
3）提倡適當的質量。
4）在適當的情況下，根據評估結果修改評估任務，以便向項目團隊提供有用的信息。
3、Status Reporting 的維度
1）Product
2）Plan
3）Results
4）Effort
5）Obstacles
6）Risk
7）Quality of Testing
8）History across projects
4、常見報告的總體結構
1）Part1：Risks and responsibilities （風險和責任）
2）Part2：Progress against plan or multidimensional chart （違反計劃的過程或多維圖表）
3）part3：Project bug metrics （項目bug度量 ;bug發現曲線）
4）part4：Deferred and no-change change requests（延遲和不改變“變更請求”）
5、保持測試報告頻繁提交、簡單并且易于理解。
6、選擇一個合適的方法來度量測試范圍。
7、使用標準的報告格式使得重點鮮明。
8、“DashBoard”是一個有用的總結工具。
Module 9 《測試&評估》
1、Veryfy Test Approach（驗證測試方法）目的
達到適當的廣度和深度的測試工作，以便對目標測試項目進行充分的評估
關注點：
1）Definition of the workflow detail 工作流細節定義
2）Checking whether your approach is workable 檢查方法是否可行
3）Considerations for testability 考慮可測試性
可測性包括a）Visibility b）Control
2、風險分析是RUP中的一個基本活動。
3、Validate Build Stability （驗證構建穩定性），目的：驗證構建是否可以被測試/評估。這有助于防止浪費的測試工作。
重要：
1）Bad builds can waste an enormous amount。
2）構建驗證是配置管理過程的一部分，可以防止帶有錯誤組件的版本。
3）頻繁進行構建是一個有價值的風險管理活動。
of testing time
4、Validate Build Stability：
This work is also referred to as a smoke test, build verification test, build regression test,sanity check or acceptance into testing.
譯文：這項工作也被稱為煙霧測試、建立驗證測試、構建回歸測試、完整性檢查或驗收測試。
5、Improve Test Assets：維護和改進測試資產。
這一點很重要，特別是如果意圖是在隨后的測試周期中重用當前測試周期中開發的資產
6、測試資產都有哪些？
Test data
Test script
Test suite
Test automation architecture
Test environment configuration
Test plan
Test evaluation summary
7、?Iterations are the “heartbeat” or rhythm of the project and a governing principle for testing in RUP.
譯文：迭代是項目的心跳節奏，是RUP中測試的指導原則。
8、Each Build Is a Candidate for a Cycle of Testing。
總結
以上是生活随笔為你收集整理的软件质量保证划重点期末复习总结的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： [系统安全]使用OD编写连连看外挂
- 下一篇： 我的ACM之路-写于南宁站后