01軟體研發流程

1．軟體產品

軟體產品是指向使用者提供的計算機軟體、資訊系統或裝置中嵌入的軟體或在提供計算機資訊系統整合、應用服務等技術服務時提供的計算機軟體。

2．軟體工程

軟體工程，英文名SoftwareEngineering，是一門研究用工程化方法構建和維護有效的、實用的和高質量的軟體的學科。

“軟體工程是開發、執行、維護和修復軟體的系統方法。”這個定義相當概括，它主要強調軟體工程是系統方法而不是某種神祕的個人技巧。 

3．軟體開發過程

軟體產品從最初構思到公開發行的過程，稱為軟體開發過程。

開發過程有各種不同的方法，沒有所謂最好的模式。

最常見的4種：

瀑布模式

螺旋模式

快速原型

4．軟體生命週期

5．軟體研發流程

6．軟體測試流程

需求分析

測試計劃

測試方案

測試用例

測試執行

測試報告

7．軟體專案成員

• 專案經理

驅動整個專案的運轉，負責制定計劃，安排人力，管理進度，協調團隊，進行重大決策。

•  架構師 / 系統工程師

技術專家，經驗豐富，負責整個系統的體系架構的設計以及關鍵模組的設計。

• 程式設計師 / 開發人員

設計、編寫軟體，並修復軟體中的缺陷。

• 測試工程師

負責找出軟體產品存在的問題並報告。

• 資料工程師

負責編寫軟體產品附帶的檔案和聯機幫助文件

• 配置管理員

負責管理程式設計師寫的程式碼和資料工程師寫的文件資料，並組合成一個軟體包

• QA

質量監管人員

02軟體測試基礎

1．軟體測試概念以及目的（掌握）

測試的目的不僅僅是為了發現軟體缺陷與錯誤，而且也是對軟體質量進行度量和評估，以提高軟體的質量。

測試是程式的執行過程，目的在於發現錯誤；

一個好的測試用例在於能發現至今未發現的錯誤；

一個成功的測試是發現了至今未發現的錯誤的測試。

2．軟體測試質量（瞭解）

軟體質量就是“軟體與明確的和隱含的定義的需求相一致的程度”   

   明確的需求指：軟體符合明確敘述的功能和效能需求、文件中明確描述的開發標準；隱含的需求指：所有專業開發的軟體都應具有的隱含特徵的程度。

3．軟體測試原則（掌握）

基於測試是為了尋找軟體的錯誤與缺陷，評估與提高軟體質量，因此我們提出了這樣的一組測試原則,如下所示。

1)        所有的軟體測試都應追溯到使用者需求。

2)        應當把“儘早地和不斷地進行軟體測試”作為軟體測試者的座右銘。

3)        完全測試是不可能的，測試需要終止。

4)        測試無法顯示軟體潛在的缺陷。

5)        充分注意測試中的群集現象。

6)        程式設計師應避免檢查自己的程式。

7)        儘量避免測試的隨意性

4．軟體測試物件（掌握）

1)        根據軟體的定義，軟體包括程式、資料、文件，所以軟體測試並不僅僅是程式測試。軟體測試貫穿於整個軟體生命週期中。

2)        由於在整個軟體生命週期中，各階段有不同的測試物件，形成了不同開發階段的不同型別的測試。需求分析、概要設計、詳細設計以及程式編碼等各階段產生的文件，包括需求規格說明、概要設計規格說明、詳細設計規格說明以及源程式，都應作為“軟體測試”的物件。

5．軟體測試分類（掌握）

1)        按照開發階段劃分軟體測試：單元測試、整合測試、系統測試、驗收測試

2)        按照測試實施組織劃分軟體測試：開發方測試、使用者測試(Beta測試)、第三方測試

3)        按照測試技術劃分：白盒測試、黑盒測試、灰盒測試。

軟體測試方法和技術的分類與軟體開發過程相關聯，它貫穿了整個軟體生命週期。

6．軟體測試風險（掌握）

軟體測試中的軟體風險分析是根據預測軟體將出現的風險，制定軟體測試計劃並排列優先等級，風險分析是對軟體中潛在的問題進行識別、估計和評價的過程。

風險也包括進度風險、質量風險、人員風險、變更風險、成本風險等

7．軟體測試工程師（瞭解）

具備的技能：

1)       計算機相關知識，能夠熟練使用常用的管理工具

2)       開發語言：C,Java,JavaScript,VBScript,Shell。

3)       資料庫：SQLServer, Oracle,MySQL等資料庫知識

4)       作業系統,如Windows 2003以及2008,UNIX,Linux,MAC,Solaris等

5)       網路基本知識，能夠獨立完成測試環境的搭建。

6)       軟體基礎知識：軟體工程,軟體生命週期,測試理論和測試方式有較深的理解。

7)       軟體測試技術,方法,流程,測試文件編寫,能獨立設計和執行測試用例,提交完整的缺陷報告單, 編寫測試報告。

8)       測試工具，能夠熟練使用至少一種功能/效能自動化測試工具。

9)       質量管理知識，如CMM,CMMI以及ISO 9001等。

職責：

1)        配置測試環境

2)        執行軟體測試

3)        報告軟體缺陷

4)        更新缺陷報告內容

5)        驗證修正的缺陷

6)        報告測試狀態

7)        完成測試相關的其它任務

03軟體測試型別

1.       軟體測試分類

按階段劃分

1)        單元測試：是指對軟體中的最小可測試單元進行檢查和驗證。

2)        整合測試：在單元測試的基礎上，將所有模組按照設計要求（如根據結構圖〕組裝成為子系統或系統，進行整合測試。

3)        系統測試：將已經確認的軟體、計算機硬體、外設、網路等其他元素結合在一起，進行資訊系統的各種組裝測試和確認測試.

4)        驗收測試（а、ß測試）：

a.它是一項確定產品是否能夠滿足合同或使用者所規定需求的測試。這是管理性和防禦性控制

b.主要確認軟體是否按合同要求進行工作，既是否滿足軟體需求規格說明書中的要求。

按是否執行程式劃分

1)        靜態測試：不執行被測試的軟體，而只是靜態的檢查程式碼、介面或者文件

2)        動態測試：實際執行被測試的軟體，輸入相應的測試資料，檢查世界的輸出結果是否和預期結果相一致的過程。

按是否檢視程式碼劃分

黑盒測試：把軟體看成一個黑盒子，不管內部邏輯和內部特性，只依據規格說明書檢查程式的功能是否符合功能說明

白盒測試：又稱為結構測試。著重於程式內部結構和演算法，不關心功能和效能指標。

灰盒測試：介於白盒和黑盒測試之間，基於程式執行時刻的外部表現同時又結合程式內部邏輯結構來設計用例，執行程式並採集程式路徑執行資訊和外部使用者介面結果的測試技術。

其他劃分

迴歸測試：對軟體的新版本測試時，重複執行上一個版本測試時使用的測試用例。防止出現“以前應用沒有的問題現在出問題了”。

冒煙測試（BVT測試（BuildVerification Test ））：冒煙測試的物件是每一個新編譯需要正式測試的版本，目的是確認軟體基本功能正常，可以進行後續的正式測試工作。

隨機測試（又名猴子測試）：測試資料是隨機產生的，在測試用例之外。只能作為一個測試的補充。

敏捷測試（敏捷開發引發）：敏捷測試(Agiletesting)是測試的一種，原有測試定義中通過執行被測系統發現問題，通過測試這種活動能夠提供對被測系統提供度量等概念還是適用的。

TDD（測試驅動開發）

                   測試驅動開發的基本思想就是在開發功能程式碼之前，先編寫測試程式碼。也就是說在明確要開發某個功能後，首先思考如何對這個功能進行測試，並完成測試程式碼的編寫，然後編寫相關的程式碼滿足這些測試用例。然後迴圈進行新增其他功能，直到完全部功能的開發。

04質量

1．什麼是質量

對於不同型別的產品，評價質量好壞的關注點不同

2．軟體質量有何價值？

軟體質量的價值，取決於其應用情景的重要程度，以及該應用情景對於該軟體產品的依賴程度。

3．軟體質量模型

內部質量：它是從內部觀點出發的軟體產品特性的總體。內部質量是針對內部質量需求被測量和評價的質量。

外部質量：外部質量是從外部觀點出發的軟體產品特性的總體。它是當軟體執行時，更典型地是使用外部度量在模擬環境中，用模擬資料測試時，所被測量和評價的質量。

使用質量：是從使用者觀點出發，來看待軟體產品用於特定環境和條件下的質量。它測量使用者在特定環境中達到其任務目標的程度，而不是測量軟體自身的性質。

4．什麼是質量保證

為保證產品和服務充分滿足消費者要求的質量而進行的有計劃、有組織的活動。

5. QC與QA的區別

QC和QA的主要區別：前者是保證產品質量符合規定,後者是建立體系並確保體系按要求運作,以提供內外部的信任

QC就是測試人員，職責是儘可能早地發現軟體的缺陷，並確保缺陷得到修復（有些企業裡，測試人員被稱為SQA）

QA是流程的監督者，職責是建立和執行 改進軟體開發過程，並防止軟體缺陷發生 的標準和方法

6.  ISO9000與CMMI的介紹

ISO：國際標準化組織

ISO9000：國家質量管理體系標準

7. CMMI是什麼？

Capability Maturity Model Integration (能力成熟度模型綜合)

該模型提供一套可供公眾使用的準則；這些準則描述那些成功地實施了過程改進的組織的特性。

該模型用“軟體能力成熟度”來衡量這種軟體綜合能力

面試：杯子怎麼測？1

         功能測試(Functiontest)

                   能否裝水，

                   除了裝水， 能否裝其他液體。比如可樂，酒精

                   能裝多少ML的水

                   杯子是否有刻度表

                   杯子能否泡茶，跑咖啡

                   杯子是否能放冰箱，做冰塊

                   杯子的材質是什麼（玻璃，塑料,黃金做的）

         介面測試(UI Test)

                   外觀好不好看。

                   什麼顏色

                   杯子的形狀是怎麼樣的。

                   杯子的重量是多少

                   杯子是否有異味

                   杯子的圖案是否合理

         效能測試(performancetest)

                   能否裝100度的開水 (泡茶)

                   能否裝0度冰水

                   裝滿水，放幾天後，是否會漏水

                   杯子內壁上的塗料是否容易脫落。

                   杯子上的顏色是否容易褪色或者脫落

                   被我坦克壓下，是否會碎 (這條是開玩笑的哈)

         安全性測試(Securitytest)

                   製作杯子的材料，是否有毒

                   放微波爐裡轉的時候，是否會爆炸, 或者杯子是否會熔化。

                   從桌子上掉到水泥地上是否會摔碎。

                   杯子是否容易長細菌

                   杯子是否有缺口，會劃壞嘴巴

                   杯子內壁上的材料，是否會溶解到水中

                   杯子破碎後，是否會對使用者造成傷害

         可用性測試(UsabilityTest)

                   杯子是否容易燙手

                   杯子是否好端，好拿

                   杯子的水是否容易喝到

                   杯子是否有防滑措施

面試：杯子怎麼測？2

         需求測試: 檢視杯子使用說明書

         介面測試: 檢視杯子外觀

         功能度：用水杯裝水看漏不漏；水能不能被喝到

         安全性：杯子有沒有毒或細菌

         可靠性：杯子從不同高度落下的損壞程度

         可移植性：杯子在不同的地方、溫度等環境下是否都可以正常使用

         相容性：杯子是否能夠容納果汁、白水、酒精、汽油等

         易用性：杯子是否燙手、是否有防滑措施、是否方便飲用

         使用者文件：使用手冊是否對杯子的用法、限制、使用條件等有詳細描述

疲勞測試：將杯子盛上水（案例一）放24 小時檢查洩漏時間和情況；盛上汽油（案例二）放24 小時檢查洩漏時間和情況等

         壓力測試：用根針並在針上面不斷加重量，看壓強多大時會穿透

         跌落測試: 杯子加包裝( 有填充物), 在多高的情況摔下不破損

震動測試: 杯子加包裝( 有填充物), 六面震動, 檢查產品是否能應對惡劣的鐵路\ 公路\ 航空運輸

測試資料：測試資料具體編寫此處略。其中應用到：場景法、等價類劃分法、因果圖法、錯誤推測法、邊界值法等方法

         期望輸出：該期望輸出需查閱國標、行標以及使用使用者的需求

05測試需求分析

1．測試需求

         什麼是測試需求

                   測試需求主要解決“測什麼”的問題 ，即指明被測物件中什麼需要測試。

測試需求通常是以軟體開發需求為基礎進行分析，通過對開發需求的細化和分解，形成可測試的內容。

測試需求應全部覆蓋已定義的業務流程，以及功能和非功能方面的需求。

         測試需求的特徵

制定的測試需求項必須是可核實的。即，它們必須有一個可觀察、可評測的結果，無法核實的需求不是測試需求；

測試需求應指明滿足需求的正常的前置條件，同時也要指明不滿足需求時的出錯條件；

                   測試需求不涉及具體的測試資料，測試資料設計是測試設計環節應解決的內容；

         為什麼要測試需求

                    軟體測試需求是開發測試用例的依據；

                    有助於保證測試的質量與進度；

                    測試需求是衡量測試覆蓋率的重要指標；

2．測試需求分析過程

         需求採集

                   需求採集的過程是將軟體開發需求中的那些具有可測試性的需求或特性提取出來，形成原始測試需求；

         測試需求分析

                   測試要點是對原始測試需求表每一條開發需求的細化和分解，形成的可測試的分層描述的軟體需求；

3．測試需求評審

                   完整性審查：應保證測試需求能充分覆蓋軟體需求的各種特徵，重點關注功能要求、資料定義、介面定義、效能要求、安全性要求、可靠性要求、系統約束等方面，同時還應關注是否覆蓋開發人員遺漏的、系統隱含的需求；

                   準確性審查：應保證所描述的內容能夠得到相關各方的一致理解，各項測試需求之間沒有矛盾和衝突，各項測試需求在詳盡程度上保持一致，每一項測試需求都可以作為測試用例設計的依據。

06 測試計劃

1．測試計劃的定義

測試計劃就是描述所有要完成的測試工作，包括被測試專案的背景、目標、範圍、方式、資源、進度安排、測試組織，以及與測試有關的風險等方面。

2．測試計劃的作用

                   1）測試過程提供指導

                             測試目標

                             測試內容

                             測試方法

                             測試時間週期

                   2）改善測試任務與測試過程的關係

                   3）提高測試的組織、規劃和管理能力

3．如何制定測試計劃

• 認真做好測試資料的蒐集整理工作；
• 明確測試的目標，增強測試計劃的實用性；
• 堅持“5W”規則，明確內容與過程；
• 採用評審和更新機制，保證測試計劃滿足實際需求

4．測試計劃的內容

1)      測試專案簡介

2)      需要測試的特徵

3)      不需要測試的特徵

4)      測試的方法（測試人員、測試工具、測試流程）

5)      測試環境（軟體、硬體、網路）

6)      測試環境是測試人員為進行軟體測試而搭建的環境

7)      測試開始條件和結束條件

8)      測試者的任務、培訓

9)      測試進度與跟蹤

10)  測試風險與解決

11)  測試計劃的審批與變更方式

5．測試風險與解決

07測試方案

1．  測試方案的目的

在方向上明確要測什麼、怎麼測，以及達到什麼樣質量標準。

2．  測試計劃與方案的區別

3．  如何制定有效測試方案

1)        測試需求分析

2)        測試策略

3)        測試資源

4)        測試進度計劃

5)        風險管理

6)        質量

4．  測試策略

制定測試策略：測試資源、測試進度計劃、風險管理、質量

測試型別：

1)        功能測試

2)        介面測試

3)        安全測試

4)        本地/國際化測試

5)        資料庫測試

6)        可靠性測試

7)        整合測試

8)        相容性測試

9)        自動化測試

10)    效能測試

11)    迴歸測試

08 黑盒用例設計方法

1. 黑盒測試的概念

黑盒測試又稱功能測試、資料驅動測試或基於規格說明書的測試，是一種從使用者觀點出發的測試。

2.       黑盒測試主要測試的錯誤型別有

                   ①不正確或遺漏的功能；

                   ②介面、介面錯誤；

                   ③效能錯誤；

                   ④資料結構或外部資料訪問錯誤；

                   ⑤初始化或終止條件錯誤等等。

3.       黑盒測試的實施過程

                   測試計劃階段

                   測試設計階段

                   測試執行階段

                   測試總結階段

4.       黑盒用例設計技術（重點）

                    1）等價類劃分方法（重點）

                    2）邊界值分析方法（重點）

                    3）場景法 （重點）流程分析法，是業務流程

                                     基本流（正常流）

                                     備選流（異常流）

                    4）錯誤推測方法

基於經驗和直覺推測程式中所有可能存在的各種錯誤, 從而有針對性的設計測試用例的方法。

                    5）因果圖方法

考慮輸入條件之間的相互組合,可能會產生一些新的情況. 但要檢查輸入條件的組合不是一件容易的事情, 即使把所有輸入條件劃分成等價類,他們之間的組合情況也相當多.

                    6）判定表驅動分析方法

判定表（Decision Table）是分析和表達多邏輯條件下執行不同操作的工具，它可以把複雜的邏輯關係和多種條件組合的情況表達得既具體又明確。

                    7）規則及規則合併

規則合併有兩條或多條規則具有相同的動作，並且其條件項之間存在著極為相似的關係

                    8）正交試驗設計方法

它是根據正交性從全面試驗中挑選出部分有代表性的點進行試驗，這些有代表性的點具備了“均勻分散，齊整可比”的特點，是一種高效率、快速、經濟的實驗設計方法。

5.      等價類劃分方法

可以把全部輸入資料合理劃分為若干等價類,在每一個等價類中取一個數據作為測試的輸入條件,就可以用少量代表性的測試資料.取得較好的測試結果.

                            有效等價類

                                               滿足輸入條件

                   無效等價類

                                     不滿足輸入條件

                                     超範圍數值

                                     空值

                                     特殊字元

                                     空格  （trim 去除空格）

6.       邊界值分析方法：是對等價類劃分方法的補充

7.       測試方法選擇的綜合策略

1)        首先進行等價類劃分，包括輸入條件和輸出條件的等價劃分，將無限測試變成有限測試，這是減少工作量和提高測試效率最有效方法。

2)        在任何情況下都必須使用邊界值分析方法。經驗表明用這種方法設計出測試用例發現程式錯誤的能力最強。

3)        用錯誤推測法再追加一些測試用例。

4)        對照程式邏輯，檢查已設計出的測試用例的邏輯覆蓋程度。如果沒有達到要求的覆蓋標準，應當再補充足夠的測試用例。

5)        對於業務流清晰的系統，可以利用場景法貫穿整個測試案例過程，在案例中綜合使用各種測試方法。

                   在實際測試中，往往是綜合使用各種方法才能有效提高測試效率和測試覆蓋度

09 測試用例設計

1. 測試用例的主要構成要素

測試用例是一份測試文件，它描述輸入、動作、和一個期望的結果，其目的是確定應用程式的某個特性是否正常的工作

2. 設計測試用例的原則

                   用語簡潔清晰，但不能過於簡單

                   用語無歧義，儘量少用過長的句子

                   用例的各個基本要素要齊備，不能缺失

                   用例的步驟應該足夠詳細，操作應該明確

                   容易被其它測試工程師讀懂，並能順利執行

3. 用例的粒度

1)        粒度，指的是粗細程度。粒度大，就是說一個用例所涵蓋的關注內容比較多，反之同理

2)        用例的粒度大，則總的用例數就少，用例看起來也簡潔

3)        用例的粒度小，則單條用例關注的測試點很集中，不容易遺漏，並且執行需要的時間比較好估計

4. 執行結果

1)        當用例還尚未被執行時，是New未執行狀態

2)        當執行結果與預期結果相符時，是Pass通過狀態

3)        當執行結果與預期結果不符時，是Fail失敗狀態

4)        當因為軟體有缺陷而妨礙了用例步驟的執行，且該缺陷並不是我們的測試點，則用例是Block阻礙狀態。

5)        當用例正在執行中，但是需要耗較多時間去觀察其結果，是Investigate觀察中狀態。

5. 編寫元素

                   用例編號、用例標題、用例級別、前提條件、操作步驟、預期結果、編寫人、備註

11 測試執行

1.測試執行

         1）什麼是執行測試用例

根據已有的測試用例，按照裡面的步驟一步一步的執行，檢視預期結果與實際結果是否一致。

         2）測試執行過程注意事項

ü  搭建測試環境事項

ü  注意前提條件和特殊說明

ü  測試用例要全部執行

ü  不要忽視任何偶然現象

ü  加強測試過程記錄

ü  詳細預期與實際的不一致

ü  提交缺陷時與開發的關係處理

ü  提交一份優秀的問題報告單

ü  及時更新測試用例

2. 軟體缺陷

                   缺陷又名為BUG（臭蟲）

                   並非所有的缺陷都需要修復

a)        沒有足夠的時間

b)        不算真正的軟體缺陷

c)        修復的風險太大

d)        不值得修復

3. 缺陷的流程

4. 缺陷生命週期—狀態             

5. 缺陷的等級      

6. 測試報告

                   測試報告的主要內容

                            資料統計

                            遺留bug情況

                            測試風險

                            測試物件評估

                            測試結論        

測試總結：回顧整個專案的測試過程，總結個人成長經驗，取得了什麼成績、有哪些不足、有什麼好的經驗或者方法可以和大家分享呢？對工作進行一個理性的分析和思考。