周報是按周出版的報紙， 以下是為大家整理的關于軟件測試周報總結3篇 , 供大家參考選擇。

軟件測試周報總結3篇

軟件測試周報總結篇1

1.軟件質量保證包括軟件質量管理方法、有效的軟件工程技術（方法、工具）、在整個軟件工程中采用的正式技術復審、多層次的測試策略、對軟件文檔及其修改的控制、保證軟件遵從軟件開發標準的規程以及度量、報告機制。

2.21世紀計算機軟件發展的大方向是質量優于性能改進。

3.軟件測試定義：軟件測試是使用人工或自動手段來運行或測定某個系統的過程，檢驗是否滿足規定需求，或者弄清預期結果與世紀結果之間的差別。

4.測試是程序執行的過程，目的在于發現錯誤，一個好的測試用例可以發現至今尚未發現的錯誤，一個成功的測試能發現至今未發現的錯誤。

5.軟件測試方法：（1）從是否需要執行被測試軟件的角度分為靜態測試和動態測試；（2）從測試是否針對系統的內部結構和具體實現算法的角度分為黑盒測試和白盒測試。

6.靜態測試無需執行被測代碼，而是借助專用的軟件測試工具評審軟件文檔或程序，度量程序靜態復雜度，通過分析或檢查程序的文法，結構、過程、接口等來檢查程序的正確性，借此發現程序不足之處減少錯誤概率。

7.黑盒測試也稱功能測試或數據驅動測試，是已知軟件所需功能，通過測試來檢測每個功能是否能正常使用。

8.白盒測試也稱結構測試或邏輯驅動測試，知道軟件內部的工作過程，可通過測試來檢測軟件產品內部的動作是否按照規格說明書的規定要求正確運行，并且按照程序內部的結構測試程序來檢驗程序中的每條通路是否都能按照預定的要求正常工作，而不考慮功能是否正確。

9.軟件質量控制是一組由開發組織使用的程序和方法，可在規定的資金投入和時間限制的條件下提供滿足客戶質量要求的軟件產品并持續不斷地改善開發過程和開發組織本身以提高將來生產高質量軟件產品的能力。

10.軟件質量控制是對開發過程中軟件產品（包括階段性產品）的質量信息進行連續的收集，反饋。

11.詳細描述PDCA：（1）計劃Plan：確定參數要求；（2）實施Do：根據要求開展活動（3）檢查Check：通過評審、度量、測試確認滿足要求；（4）改進Action：糾正參數要求再開發。

12.軟件質量控制的實施過程：

1、預開發階段

2、開發階段

3、維護階段

13.軟件質量保證的目的是使軟件過程對于管理人員來說是可見的，通過對軟件產品和活動進行評審和審計來驗證軟件是符合標準的。軟件質量保證組在項目開始時就一起參與建立計劃，標準和過程。這些將使軟件項目滿足機構方針的要求。

14.軟件質量度量的根本目的是為了管理的需要利用度量來改進軟件過程。

15.軟件度量是對軟件開發項目、過程、產品、進行數據定義、收集、分析的持續性定量化過程，目的在于對此加以理解、預測、評估、控制、改善。

16.通過軟件度量可以改進軟件開發過程。促進項目成功，開發高質量的軟件產品。

17.軟件度量作用：

18.對于軟件質量，CMM的定義如下：一個系統、組件、過程符合特定需求的程度；一個系統、組件、過程、符合客戶或用戶的要求或者期望程度。

19.軟件質量的要素指以下兩個方面：

（1）從技術角度講，對軟件整體質量影響最大的是那些質量屬性才是質量要素；

（2）從商業角度講。客戶最關心的、能成為賣點的質量屬性才是質量要素。

20.影響軟件質量的因素：人（M）、過程（P）、技術（T）。

21.軟件質量保證模型：McCall模型，Boehm模型、FURPS模型、ISO9126。

22.軟件過程度量不是單一的活動，而是一組活動的集合，本身也是一個系統的過程。

23.軟件過程度量的目標：是對軟件過程的行為進行目標管理，并在度量的基礎上對軟件過程進行控制、評價、改善。

24.軟件過程度量就其對象而言主要包括3個，即工作產品、軟件項目、過程。

25.軟件過程度量的方法包括常用的采集方法和常用的數據分析方法。

26.軟件質量度量的常見問題：

（1）度量的太多、太頻繁。

（2）度量的太少、太遲。

（3）度量了不正確的事物或屬性

（4）度量的定義不精確。

（5）手機了數據卻沒有利用。

（6）錯誤地解釋度量數據。

（7）自動化工具欠缺。

27.基于目標的軟件過程度量方法（GQM）是一種層次狀結構，分層次解釋，一個目標有多個問題，每個問題可進一步分為幾個度量。

28.軟件可靠性的定義：在規定條件下，在規定時間內，軟件不引起系統失效的概率。

29.軟件可靠性產生的軟件差錯包括以下幾種：

（1）需求分析定義錯誤

（2）設計錯誤

（3）編碼錯誤

（4）測試錯誤

（5）文檔錯誤

30.軟件質量標準分五個級別：國際標準、國家標準、行業標準、企業標準、項目規范。

31.CMM（軟件過程成熟度模型）是對軟件組織在定義、實施、度量、控制和改善其軟件過程中各個發展段的描述；包括5個等級，18個過程域、52個目標、300多個關鍵實踐。5個等級分為，優化級、已管理級、已定義級、可重復級、初始級。

32.CMM是一種用于評價軟件承保能力并幫助其改善軟件質量方法，側重于軟件開發過程的管理及工程能力的提高與評估。

33.CMMI（軟件能力成熟度模型）是CMM中一種單一的模型。

34.軟件評審是一些用于開發過程早起檢查和糾正缺陷的有效方法，也可以用來檢查未成形執行代碼的文檔的缺陷。

35.軟件評審的方法：特別檢查，檢查，走查，團隊評審，檢視。

36.全面質量管理是一種由顧客的需要和期望驅動的管理哲學，是以質量為中心，建立在全員參與基礎上的一種管理方法，其目的在于長期獲得顧客滿意、組織成員和社會的利益。

37.全面質量管理包括以下定義：

（1）強烈關注顧客

（2）精確度量

（3）堅持不斷的改進

（4）向員工授權

（5）改進組織中每項工作的質量

38.軟件測試：是軟件質量保證的關鍵階段，是對軟件設計和編碼的最終審查。

39.廣義的軟件測試包括驗證、確認。

40.軟件測試就是在軟件投入運行前對軟件的需求分析、設計、實現編碼進行最終審查。

41.軟件測試的目的：

（1）在于發現錯誤；

（2）測試用例在于能發現至今未發現的錯誤；

（3）發現了至今未發現的錯誤的測試。

42.軟件測試原則：

（1）在整個開發過程中要盡早地不斷地進行軟件測試。

（2）在開始測試時不應默認程序中不存在錯誤。

（3）在設計測試用例時要給出測試的預期結果。

（4）測試工作應避免由系統開發人員或開發機構本身來承擔。

（5）對合理的和不合理的輸入數據都要進行測試。

（6）重點測試錯誤集群的程序區段。

（7）除檢查程序功能是否完備外，還要檢查程序功能是否多余。

（8）用窮舉測試是不可能的。

（9）長期完整地保留所有的測試用例和測試文件，直則該軟件產品被廢止為止。

43.軟件測試過程概述：由于軟件錯誤的復雜性，在軟件工程范圍內要綜合應用測試技術，根據定義域中的取值，通過執行和觀察將預期的行為和實際的行為做比較，以確認測試結果。

44.軟件測試的5個要素：質量、人員、技術、資源、流程。

45.綜合測試分為四步：單元測試、集成測試、系統測試、驗收測試，在所有的測試過程中始終貫穿著回歸測試。

46.單元測試指對軟件中最小可測試單元或基本組成單元進行檢查和驗證。

47.單元測試測試方法：

驅動模塊：用來模擬被測模塊的上級調用模塊，功能比真正的上級模塊簡單得多，僅僅是接受測試數據，并向被測模塊傳送測試數據，啟動被測模塊，回收并輸出測試結果。

樁模塊：用來模擬被測模塊在執行過程中所需要調用的模塊，接受被測模塊輸出的數據并完成它所指派的任務。

48.集成測試（重點）：

定義：集成測試在單元測試的基礎上將所有已經通過單元測試的模塊按照概要設計的要求組裝為子系統或系統。

49.集成測試測試內容：

（1）將各模塊連接起來時穿越模塊接口的數據是否會丟失。

（2）各子功能模塊組合起來能否達到預期要求的父功能；

（3）模塊的功能是否會對其他模塊的功能產生不利影響。

（4）全局數據結構是否有問題，是否會被異常修改。

50.集成測試測試方法：

1.非增量式集成測試方法

2.增量式集成測試方法

（1）自頂向下增量式集成測試

（2）自底向上增量式集成測試

比較：

51.驗收測試是一種有效性測試或合格性測試，是以用戶為主，軟件開發人員、實施人員和質量保證人員共同參與的測試。

52.驗收測試測試技術：

α測試：內部人員模擬各類用戶行為對即將面世的軟件產品進行測試。

β測試：用戶在日常實際使用β版本。

把α測試看成是對一個早期的、不穩定的軟件版本所進行的驗收測試。而把β測試看成是對一個晚期的、更加穩定的軟件版本所進行的驗收測試。

53.回歸測試指修改了舊代碼后重新進行測試以確認修改沒有引入新的錯誤或導致其他代碼產生錯誤。

54.

55.

56.黑盒測試法是把程序看作一個黑盒子，完全不考慮程序的內部結構和處理過程。

57.等價類劃分法是一種黑盒測試技術，不考慮內部結構，把所有可能的輸入數據（即程序的輸入域）劃分成若干部分（子集），然后從每一個子集中選取少數具有代表性的數據作為測試用例。

58.劃分等價類：（1）有效等價類（2）無效等價類

59.設計測試用例原則：

（1）每一個等價類規定性一個唯一的編號

（2）設計一個新的測試用例，使其盡可能多地覆蓋尚未被覆蓋的有效等價類，然后重復這一步，知道酥油的有效等價類都被覆蓋為止。

（3）設計一個引得測試用例，使其僅覆蓋一個尚未被覆蓋的無效等價類，然后重復這一步，直到所有的無效等價類都被覆蓋為止。

60.邊界值選擇法：

61.因果圖設計法：

（1）分析程序規格說明的描述中那些是原因，哪些是結果。

（2）分析程序規格說明的描述中語義的內容，并將其表示成連接各個原因與各個結果的“因果圖”

（3）表明約束條件

（4）把因果圖轉換成判定表

（5）為判定表每一列表示的情況設計測試用例。

62.白盒測試法與黑盒測試法相反，前提是可以把程序看成裝在一個透明的白盒子里，測試者完全知道程序的結構和處理算法。

63.白盒測試實施步驟：

（1）測試計劃階段（2）測試設計階段（3）測試執行階段（4）測試總結階段

64.白盒測試的方法在總體上分為靜態方法和動態方法。

65.軟件失效處理機制（陳述）

（1）軟件錯誤：指在軟件生存期內的不希望或不可接受的人為錯誤，其結果是導致軟件缺陷的產生，軟件錯誤是一種人為過程，相對于軟件本身是一種外部行為。

（2）軟件缺陷：存在于軟件（文檔、數據或程序）之中的那些不希望或不可接受的偏差。結果是軟件運行于某一特定條件時出現軟件故障，這時稱軟件缺陷被激活。

（3）軟件故障：指軟件運行過程中出現的一種不希望或不可接受的內部狀態。

（4）軟件失效：指軟件運行時產生的一種不希望或不可接受的外部行為結果。

66.軟件缺陷管理就是在軟件開發過程中對發現的缺陷進行跟蹤，并確保每個被發現的軟件缺陷被關閉。

67.嚴重性是軟件缺陷對軟件質量的破壞程度，反應其對產品、用戶的影響，即此軟件缺陷的存在將對軟件的功能和性能產生怎樣的影響。

68.優先級表示修復缺陷的重要程度和應該何時修復，他是表示處理和修正軟件缺陷的先后順序的指標，即哪些缺陷需要優先修正，那些缺陷可以稍后修正。

69.嚴重性和優先級并不總是一一對應的。

70.

71.軟件缺陷的有效描述規則主要如下：（1）單一準確（2）可以再現（3）完整統一（4）短小精練（5）特定條件（6）補充完善（7）不做評價

72.軟件缺陷生命周期指的是一個軟件缺陷被發現、報告到這個缺陷被修復、驗證直至將缺陷最終解決的一個完整過程。

73.

74.集成測試是在單元測試的基礎上將多個模塊組合在一起進行測試的過程，主要檢查各個軟件單元之間的相互接口是否正確，是介于單元測試和系統測試之間的過渡階段，是單元測試的擴展和延伸。

75.單元測試主要關注模塊的內部，集成測試查看接口時主要關注穿越接口的數據、信息是否正確。

76.集成測試分為三個層次；即模塊內集成測試、子系統內集成測試和子系統間集成測試。對于面向對象的應用系統來說，可以把集成測試分為兩個階段即類集成測試和類間集成測試。

77.驅動模塊自底向上，樁模塊自頂向下。

78.非漸增式集成測試采用一步到位的方法進行測試，即對所有模塊進行個別的單元測試后按程序結構圖將各模塊連接起來，連接后的程序當做一個整體進行測試。

79.自頂向下增式集成測試表示逐步集成和逐步測試，是按照程序結構圖自上而下進行的，即從頂層主控模塊開始測試，對以后如何選擇下一個要測試的模塊并沒有一個統一的方法，唯一的原則是下一次要測試的模塊至少有一個調用的模塊已經測試過。

80.自頂向上增式集成測試是從軟件結構的最下層模塊開始測試，在測試較高的高層模塊時所需的下層模塊功能都已具備，所以不在需要樁模塊。

81.自底向上缺點是在于直到最后一個模塊被加進去以后才能看到整個程序的框架，三明治集成測試彌補自底向上缺點。

82.系統測試是對已經集成好的軟件系統進行徹底的測試，已驗證軟件系統的正確性和性能是否滿足需求分析所指定的要求，系統測試通常是消耗測試資源最多的地方，一般可能會在一個相當長的時段內由獨立的測試小組進行。

83.系統測試的主要方法：（選擇、填空）

（1）性能測試

（2）強度測試

（3）安全性測試

（4）兼容性測試

（5）恢復測試

（6）用戶圖形界面測試

（7）安裝測試

（8）可靠性測試

（9）配置測試

（10）可用性測試

（11）文檔資料測試

（12）網站測試

84.測試方法的應用：集成測試及其后的測試階段一般采用黑盒測試方法，策略如下：

（1）用邊值分析法或等價類法提出基本測試用例

（2）用猜測法補充新的測試用例

（3）如果程序的功能說明中含有輸入條件的組合，需要在一開始就用因果圖法，然后再按以上兩步進行。

85.軟件測試文件描述被執行的軟件測試及測試的結果。

86.測試管理者的工作原則

（1）雇測試工作最合適的員工

（2）與每個小組成員定期一一談話

（3）假定員工能勝任各自的測試工作

（4）對待員工以他們能接受的方式

（5）重視結果而不是時間

（6）承認自己的錯誤

87.軟件調試方法：（1）蠻力法（2）回溯（3）原因排除法

88.軟件測試自動化最根本的意義是解決手工勞動的復雜性，成為代替某些重復性行為模式的最佳工具。

89.軟件測試自動化事實理由：

（1）提高測試效率和降低測試成本

（2）對于功能性邊界測試，人工測試非常耗費時間，而自動化測試很快并且很準確。

（3）項目測試人員的任務都是手工處理的，而實際上很大一部分重復性強的測試工作是可以獨立開來自動實現的。

（4）自動測試可以避免人工測試容易犯的錯誤，如錯誤測試、漏測試、多測試和重復測試等

（5）典型應用，例如多用戶并發注冊，并發交易請求，并發交易應答，人工測試幾乎辦不到，但是自動測試卻很容易實現。

90.

軟件測試周報總結篇2

1、為什么要測試？軟件測試的目的？軟件測試的重要性？

A、發現缺陷BUG/Defect

B、評估軟件、項目、產品上線風險？

C、滿足客戶要求、改善軟件質量

D、幫助開發發現問題、定位問題、修改問題

E、軟件驗收、也包括第三方的驗收（驗收測試、UAT）

F、通過缺陷分析，從而預防同類缺陷的發生。

G、錯的：軟件測試能縮短開發周期。也不能直接降低開發成本。

H、改善軟件的用戶體驗（易用性、性能、穩定性）12306訂票

角度：系統性思維（1、2、3、4、5、6、7+=100: 1+2+34+56+7=100）門薩測試

角色：用戶：發現缺陷、改善用戶體驗

：開發：證明軟件GoodEnough，定位缺陷，從而減少開發修改問題的時間

歷史：證明程序是正確？--》發現功能缺陷、錯誤--》發現不足（易用性、性能、穩定性）--》缺陷預防

現實：驗收、評估質量風險、第三方評測、為了盈利而測試（商業成功）（測試成本《《軟件缺陷導致成本）

2、什么是軟件測試？

IEEE（國際電器電子工程協會）：目的：驗證系統是否滿足需求、驗證實際結果跟期望結果的差異？

xll：在一定的軟件、硬件、網絡環境下（搭建測試環境LAMP），遵循相對規范的測試流程，使用合適的測試工具，合理的測試方法，測試或運行軟件，其目的是為了驗證系統是否滿足需求、驗證實際結果跟期望結果的差異。

3、軟件測試的工作內容？

BAT：Baidu、Alibaba、Tecent

4、測試與調試的區別：

對象：代碼、文檔；代碼

人：測試工程師；開發

流程：有規范的流程（除了隨機測試和探索性測試外）；無流程

目的：發現問題；定位和解決問題

5、測試的七大原則：

A、測試只能證明軟件存在缺陷，不能證明軟件沒有缺陷（證偽不證真）

B、測試是無法窮舉？（輸入數據是無法窮舉、處理邏輯路徑是無法窮舉），學習測試用例的設計方法。

C、測試應該盡早測試？（發現缺陷和修改的成本越早越低。需求-設計-代碼-測試-運行）

測試應該在需求之后？設計之后？編碼之后？測試應該盡早介入，測試應該貫穿整個軟件生命周期。

D、缺陷的80/20原則（群集效應）。如果測試發現某個模塊有問題？繼續深入測試。刨根問底？破案？

E、殺蟲劑悖論（軟件對用例會免疫力）不斷更新測試用例、更新的測試思維

F、測試依賴于商業背景（與行業知識相關）結合專業和工作經歷和準備相關的項目。優點 SWOT

優勢、劣勢、機會、威懾（競爭對手）準備行業軟件

G、不存在缺陷的軟件并不代表是有用的系統。

一個合格、優秀、卓越、偉大的測試工程師的能力與素質的要求？

素質、性格、能力、管理、英語、行業六大維度回答

答

6、測試與開發的關系（獨立性）

未來趨勢：3大趨勢：1、測試與開發的結合越來越緊密；2、測試與行業背景結合越來越緊密

3、專項測試（測試分工會越來越精細），大數據測試（數據庫，用戶工程） IT，DT。

比較分析不同網站的購物流程：亞馬遜、當當網、京東、淘寶（CDC）聯眾游戲、QQ游戲

1、測試人員也開發，開發也做測試（Google：吃狗糧的文化）

2、測試人員獨立與項目（在項目中有專職的測試人員：客觀）

3、測試人員獨立部門（有專門的測試部門：權威）

4、測試人員獨立技術（測試工具部、測試技術部）

5、測試人員獨立于公司（測試服務機構或者公司）

缺點：溝通越困難，對產品或者項目的熟悉越少。感情色彩：這是個非常嚴重的bug！！！！！

測試人員發現了BUG，開發人員不愿意修改，該怎么辦？

加班？敏感問題？三方思考：對方、客觀中立、自己

地鐵自動售貨機 PM

1、計劃階段：可行性分析：A、經濟可行性分析；B、技術可行性分析（外包）

計劃項目里程碑：計劃、需求SRS、概要設計HLD、詳細設計LLD、編碼、測試、運行與維護

輸出軟件項目計劃 SPP（Software Project Plan）PM

輸出軟件確認與驗證計劃 SVVP(Software verfication Validation Plan)軟件測試計劃 TPM

2、需求階段：產品（金蝶）：調研與項目（用戶） SE 系統工程師 what to develop？黑盒

TSE 分析測試需求挖掘用戶的隱性需求

需求規格SRS：功能需求：1、接受貨幣 2、選擇商品 3、計算功能 4、輸出商品和找零、5、商品管理

性能需求：30S之內輸出商品和找零

可靠性需求：7X24小時

易用性需求：良好易用性，不需要培訓。最好用的軟件baidu

需求分析的技術：UML建模（需求工程）

3、設計階段：概要設計HLD （High Level Design 高層設計）：模塊分解與接口的定義。

1、接受貨幣（識別真偽、識別面額、識別類別）分解原則？高內聚低耦合？（百度）

（無直接耦合、數據耦合、印記耦合、控制耦合、公共耦合、內容耦合）回歸測試

2、接口：函數接口、消息接口、文件接口（QQ修改頭像）、數據庫接口

詳細設計LLD（Low Level Design 底層設計）：算法的描述（程序=數據結構+算法/思路（各種排序））流程圖、偽碼。白盒

4、編碼階段：熟悉一門編程語言的語法 C、Java、PHP和一個開發工具或者平臺 VC、Eclipse等

熟悉一門腳本語言：python、ruby、perl、tcl、shell BAT

5、測試階段：測試工具、方法、流程

6、運行與維護：技術支持

測試應該貫穿整個軟件生命周期。

1、測試應該在SRS之后？

HLD

LLD

CODE

瀑布模型：缺點：不適應需求變更頻繁的項目。適合產品開發的項目。測試滯后于開發。

V模型：

用戶需求URS-----------------------------------------驗收測試UAT（User Acceptance Testing）

需求規格SRS---------------------------------系統測試ST（System Testing）

概要設計HLD-------------------------集成測試IT（Integration Testing）

詳細設計LLD-----------------單元測試UT（Unit Testing）

編碼CODE------------代碼評審CODE Review

H模型、X模型。

1、方法的背景？2、方法的操作步驟、3、優缺點、4、適用范圍、5與其他方法怎么樣配合、6重點、要點、難點

等價類：

1、背景：why？輸入無法窮舉，我們不能測試所有情況，必選選擇有代表數據來驗證

2、操作步驟：

1、分析被測試對象輸入條件以及子條件（關鍵點：考慮隱性子條件，條件正交完備）

2、根據等價類劃分原則劃分有效等價類和無效等價類

原則：1、規定范圍或者格式，譬如長度6~18位，可以劃分1個有效、2個無效等價類

2、規定的集合或者滿足某個條件，譬如一些下拉列表的選擇，可以劃分1有效、1個無效

3、規定了必須如何，譬如組成、開頭，可以劃分1個有效和若干個無效。

4、規定是布爾量，譬如是否已經注冊，可以劃分1個有效和1個無效

5、規定是多種選擇（還有不同的處理方式），譬如163郵箱注冊的后綴，可以劃分成若干個有效，和1個無效。

3、根據等價類設計用例原則：（1、用一個用例覆蓋盡可能多的有效等價類；

2、為每一個無效等價類單獨設計用例：為了更好定位問題）設計數據

原則：同樣效果情況下用例數盡可能少，精確定位問題。

3、優缺點：適用范圍廣、能以有限用例達到比較好覆蓋無法窮舉的輸入。

缺點：方法沒有刻意考慮邊界，只能針對單個輸入條件，沒有考慮輸入之間組合以及輸入與輸出的關系。

4、適用范圍：只要有業務規則的情況下，最好是有清晰的業務規則

5、與其他方法怎么樣配合：一般情況下會跟邊界值方法結合使用。

6、要點：等價類劃分的原則：尤其是要注意隱性條件（完整性，不要遺漏）

思考：微信發送圖片、上傳QQ頭像、導入文件這類如何使用等價類

邊界值：

1、背景：why？：很多錯誤通常都發生在邊界上。

2、操作步驟：

1、分析被測試對象輸入條件以及子條件

2、分析上點、離點和內點

3、根據邊界值設計用例的原則設計數據去覆蓋可能上點、離點和內點

3、優缺點：優點：能夠比較高效發現問題

缺點：不能考慮輸入與輸出之間的關系

4、適用范圍：規定了大小、長度、值的范圍、分辨率（廣義）

5、與其他方法怎么樣配合：與等價類配合

6、要點：找到邊界（隱含的邊界）

航空行李托運：重量不能超過30公斤，如果超過就要收費，正常人4元每公斤，外國人收6塊，頭等艙是其他艙的2倍

殘疾人是正常人的1/2.

判定表/決策表：

1、背景：why？：輸入條件很多情況（要么滿足、要么不滿足），不同條件組合下輸出結果也很多，希望條件跟結果的一一對應的關系

它可以把復雜的邏輯關系和多種條件組合的情況表達得既具體又明確

2、操作步驟：

1、分析被測試對象的輸入條件，同時分析各種可能的輸出結果（）

2、列出所有的條件和動作（）

3、填寫條件項和動作項

4、合并相似規則

3、優缺點：優點：能解決復雜條件之間邏輯組合，比較清晰列出所有的組合

缺點：一旦條件數過多，組合數會很龐大，合并存在漏測的風險（很難精確定位問題）。

對于條件，只能是有兩種取值（為真、為假）

4、適用范圍：條件只有兩種取值的多條件組合的例子

5、與其他方法怎么樣配合：與因果圖

6、要點：找出業務條件規則，列出各種可能輸出結果。（測試象棋馬走日這個規則）當條件比較多>5 要考慮是否有中間結果（簡化）

正交試驗法

1、背景：彌補判定表方法可能導致用例規模非常龐大，多條件組合的數量非常巨大。

根據伽羅瓦理論，條件之間的兩兩組合如果不出問題，三三組合以上出問題的概率小，這樣

一來，可以用非常少的用例來達到比較好的測試效果。

2、操作步驟：

1、分析輸入條件以及條件的取值范圍。（篩選出來的條件之間沒有約束關系）

2、選擇合適的正交表（計算需要最小正交表的試驗數，然后分兩種：

1、單一水平：去挑選比需要大但是是最接近的正交表，直接套用；合并去匹配正交表-->分解

2、混合水平：）

保證試驗數最少

3、根據正交表（拆分之后）設計測試數據（每一列行是一個測試項），如果是空的地方，可以根據實際需要加權處理。

3、優缺點：優點：在保證一定均勻覆蓋率的前提下可以大大降低試驗次數（測試項），缺點：可能有一定的遺漏

4、適應范圍：配置類需求的分析，多條件多取值的業務測試。

5、與其他方法配合：等價類和邊界值（輸入框）

6、要點：選擇合適正交表以及如何去合并和分拆！

Use Case法/場景法/流程分析法

1、背景：在實際工作中，我們很業務功能是通過工作流來實現，需要站在流程角度（用戶角度），譬如購物流程

安裝測試、轉賬流程、游戲場景

2、操作步驟：1、分析業務的基本事件流和備選事件流（正常備選事件流和異常事件流（退出））擔心備選流有遺漏

2、畫出事件流圖（Use Case圖用例圖）

3、根據圖設計場景

4、根據場景來設計測試數據

3、優缺點：優點：站在用戶的角度來測試（），可以很好地與開發配合，直接通過用例圖轉化，效率比較高

4、適應范圍：驗收測試用例的設計，只要流程

5、與其他方法配合：等價類、邊界值（選多少個備選流）

6、要點：事件流分析，尤其是備選流的分析是最關鍵的地方。思路比較清晰，比較廣

網銀轉賬：寫出基本流和備選，并且畫出事件流圖。

影響軟件質量的因素：

技術：1.現有的技術：人

2. 技術沉淀：技術文檔，專利技術，指導書，問題庫，經驗庫

流程：流程可以提高軟件透明度，控制項目的進度，幫助項目組預防風險。

組織：組織體現的是管理

1. 讓合適的人去做合適的事情

2. 流程的推動需要組織強有力的保障

軟件質量管理體系

1. ISO9000

八項質量管理原則：

以顧客為中心：以用戶的角度去思考問題（UAT）

下游環節為上游環節的客戶

領導的作用：有激情，有謀略，演講才能，身先士卒

全員參與：團隊合作信任

基于事實的決策方法：個人能力基線（PCB）（量化管理）

持續改進（持續改善）：最初是日本的一個管理理念，從初級員工到高級管理者都需要參與

互利的供方關系：共贏，共同創造利潤

過程方法：

過程：輸入轉化為輸出的活動

過程方法：過程的識別，相互作用以及管理

管理的系統方法：全局化的管理策略

2. CMM

-- 初始級：

手工作坊式，個人英雄主義，沒有相關過程，不可預測并且缺乏控制。

-- 可重復級：特點 ->可以重復以往的項目經驗

證券項目（招商證券）

國信證券：

SRS

HLD

LLD

Code

test case

模板

關鍵過程域（KPA）（key process area）：

需求管理

配置管理

軟件質量保證

--已定義級

統一標準，一致的過程（軟件工程小組SEPG）

關鍵過程域：同行評審

--已管理級：可預測的過程

量化管理，通過數據量化，來實現預測項目

Gompertz模型

--優化級：對過程的持續改進

新技術或新思想的引入

關鍵過程域：缺陷分析-》預防缺陷 -》質量標準

CMM與CMMI的區別

CMM：階段式表示

CMMI：階段式、連續式

3. 六西格瑪

六西格瑪管理法原則：

注重客戶

注重流程

全員參與

預防為主

事實依據的決定

持續和突破性改進

六西格瑪的實施方式：

DMAIC (define, measure, analysis, improve, control)

軟件質量模型：

功能性

適合性：軟件產品為指定任務或用戶目標提供一組合適的功能的能力

準確性：軟件產品提供所需要的精確度或和結果相符的能力

互操作性：軟件產品與一個或更多的其他系統進行交互的能力

保密安全性：保護信息和數據的能力，不同權限的人可以操作不同的數據

功能性的依從性：遵守與功能性相關的標準，約定或法規的能力（國際標準，國家標準，行業標準，企業內部標準）

可靠性

成熟性：軟件產品為避免由于軟件中的錯誤而導致失效的能力

容錯性：由于用戶操作錯誤，軟件可以處理相應的錯誤，而不是死機或崩潰

易恢復性：在失效已經發生的情況下，軟件產品如何快速恢復使用的能力

可靠性的依從性：軟件產品遵循與可靠性相關的標準或約定或法律法規

易用性

易理解性：軟件產品使用用戶能理解軟件是否合適以及如何能將軟件用于特定任務和使用環境的能力。

易學性：軟件產品使得用戶能學習其功能的能力（操作手冊，幫助文檔）

易操作性：軟件產品使用戶能操作和控制它的能力

吸引性：軟件產品吸引用戶的能力。界面美觀，易用性要好

易用性的依從性：軟件產品的易用性遵循相關的標準或法律法規

效率

時間特性：在規定的條件下，軟件產品執行其功能時，提供適當的響應和處理時間以及吞吐率的能力。也就是完成用戶的某個功能需要的時間

資源利用率：在規定的條件下，軟件產品執行其功能時，使用合適的資源數量（CPU，內存占用）

效率依從性：軟件產品遵守與效率相關的法規

維護性

易分析性：軟件產品診斷軟件中的缺陷或失效原因或識別待修改部分的能力。（日志記錄）

易改變性：修改缺陷的能力，實現功能的能力。（代碼要高內聚，低耦合）目的在于降低修改軟件的成本

穩定性：軟件產品避免由于軟件修改而造成意外結果的能力

易測試性：軟件產品的問題能被確認的能力。定位問題的能力

維護性的依從性：軟件產品的維護性遵循相關的標準

可移植性：

適應性：軟件產品適應不同的環境的能力

易安裝性：被安裝的能力（一鍵安裝）

共存性：和其他軟件共同安裝或存在的能力

易替換性：升級時替換文件的能力

可移植性的依從性：軟件產品的可移植性遵循相關的標準

軟件質量活動：

軟件質量保證（ＳＱＡ）：從流程方面保證軟件質量

　測試：從技術方面保證軟件質量

度量：

作用：理解，預測，評估和改進

度量的分類：四個基本度量項：規模工作量進度缺陷

BUG屬性：

發現人 reporter

發現時間 date

缺陷狀態 status (new, open, resolved, reopened, closed) （fixed, duplicated, Invalid, won"t fix, postpone）

缺陷版本 version

缺陷所屬的產品/項目/模塊 product, project, feature

缺陷編號 no

缺陷嚴重程度serverity

缺陷優先級 priority

標題 title

詳細描述 description

系統環境 OS (服務器環境和客戶端環境)

測試環境（用戶名/密碼）test environment

重現率 repository

預置條件pre condition

步驟 steps

實際結果 actual result

期望結果 expected result

其他信息 additional information

用例編號testcase no

*附件 attachment

==================

缺陷引發的原因 root cause

缺陷解決方案 resolution (改代碼，數據庫，環境問題)

代碼改動范圍

影響范圍

==================

驗證人

驗證環境

驗證范圍

結果

軟件測試周報總結篇3

報告總結參考范本

軟件測試個人總結

撰寫人：__________________

部 門：__________________

時 間：__________________

軟件質量越來越受到人們的關注，軟件測試作為新興行業有很多不完善的地方。很多從事軟件測試工作的同行處于迷茫之中，如何提高，如何解決測試工作中的實際問題，困惑著每一個人。本文總結了一下個人經驗，希望對大家有幫助。

我最初參加測試工作的時候，不知道什么是軟件測試，集成測試和系統測試的概念經常混淆， cmm 是什么就更加不知道了。那時候最簡單的開關機也是通過直接拔插電源完成，安裝系統對我來說簡直是有史以來人類的技能，對于那些拿著螺絲刀安裝機器的人就認為是宇內超級高手，身具殺人于無形之絕世秘技。拿破侖說不想當將軍的士兵不是好士兵，我最初的夢想就是想成為軟件測試的高手，傲視天下。所以不斷偷師，總結經驗，自認為掌握了成為高手的幾個秘技，這幾年混跡 “ 江湖 “ 還算無往而不利。不敢獨享，望與吾輩測試人員切磋，早日總結成功密技之大成，助新進人員早日入門，也算不愧對東北活雷鋒的稱號。

第一招 學會利用網絡

剛參加工作面對浩瀚的網絡世界，當時如劉姥姥進大觀園，什么都新奇，什么都想要，從網上下載很多源程序的代碼，軟件技術文檔之類，恨不得把所有的好東西收集到手中，其實有些在他人看起來就是垃圾一堆。當時覺得有了這些 “ 武林秘籍 “ ，成為高手指日可待。最初參加工作由于自己工作努力有幸轉為開發，加入項目組后我的習慣還是沒有改，反而變本加厲，手中的資源更加多，上網的時間更加頻繁。

一次項目經理分配任務，覺得依靠手中的秘籍加上自己的 “ 聰明才智 “ 很快會完成，不料短短的時間，所有的一切變成了馬奇諾防線。解決問題很慢，思路不清晰，項目經理在對我施壓的過程中教會了我終身難忘的一招，學會利用網絡尋找要解決問題的答案，從此 google 成了我的最愛，關鍵字成了我變化的招數。在軟件測試工作中，他幫我解決了很多疑難問題，解答了很多令我迷惑的地方。也是我幫助測試同行解決問題手段之一，很多軟件測試新手，甚至老手都沒有意識到自己手上就握有 “ 無敵秘籍 “ ，所以只要你耐心找，答案就在身邊。

推薦訪問： 周報 通用 測試