紅盒測試源碼

㈠ 軟體測試具體是做什麼的（面試人員說剛開始做的是處理一些代碼非常枯燥的事）請有做過工作的過來人指點

軟體測試定義是：為了發現程序中的錯誤而執行程序的過程

它是幫助識別開發完成（中間或最終的版本）的計算機軟體（整體或部分）的正確度(correctness) 、完全度(completeness)和質量(quality)的軟體過程；是SQA(software quality assurance)的重要子域。

軟體測試的目標：

(1)測試是為了發現程序中的錯誤而執行程序的過程；

(2)好的測試方案是極可能發現迄今為止尚未發現的錯誤的測試方案；

(3)成功的測試是發現了至今為止尚未發現的錯誤的測試。

軟體測試的內容：

軟體測試主要工作內容是驗證(verification)和確認(validation )，下面分別給出其概念：

驗證(verification)是保證軟體正確地實現了一些特定功能的一系列活動，即保證軟體做了你所期望的事情。(Do the right thing)

1.確定軟體生存周期中的一個給定階段的產品是否達到前階段確立的需求的過程；

2.程序正確性的形式證明，即採用形式理論證明程序符號設一計規約規定的過程；

3.評市、審查、測試、檢查、審計等各類活動，或對某些項處理、服務或文件等是否和規定的需求相一致進行判斷和提出報告。

確認(validation)是一系列的活動和過程，目的是想證實在一個給定的外部環境中軟體的邏輯正確性。即保證軟體以正確的方式來做了這個事件(Do it right)

1.靜態確認，不在計算機上實際執行程序，通過人工或程序分析來證明軟體的正確性；

2.動態確認，通過執行程序做分析，測試程序的動態行為，以證實軟體是否存在問題。

軟體測試的對象不僅僅是程序測試，軟體測試應該包括整個軟體開發期問各個階段所產生的文檔，如需求規格說明、概要設計文檔、詳細設計文檔，當然軟體測試的主要對象還是源程序。

從不同的角度出發，軟體測試可以劃分為不同的分類：

從是否關心軟體內部結構和具體實現的角度劃分

A.白盒測試

B.黑盒測試

C.灰盒測試

從是否執行程序的角度

A.靜態測試

B.動態測試。

從軟體開發的過程按階段劃分有

A.單元測試

B.集成測試

C.確認測試

D.驗收測試

E.系統測試

* 測試過程按4個步驟進行，即單元測試、集成測試、確認測試和系統測試及發版測試。
* 開始是單元測試，集中對用源代碼實現的每一個程序單元進行測試，檢查各個程序模塊是否正確地實現了規定的功能。

* 集成測試把已測試過的模塊組裝起來，主要對與設計相關的軟體體系結構的構造進行測試。
* 確認測試則是要檢查已實現的軟體是否滿足了需求規格說明中確定了的各種需求，以及軟體配置是否完全、正確。
* 系統測試把已經經過確認的軟體納入實際運行環境中，與其它系統成份組合在一起進行測試。
單元測試 (Unit Testing)
* 單元測試又稱模塊測試，是針對軟體設計的最小單位 — 程序模塊，進行正確性檢驗的測試工作。其目的在於發現各模塊內部可能存在的各種差錯。
* 單元測試需要從程序的內部結構出發設計測試用例。多個模塊可以平行地獨立進行單元測試。
1. 單元測試的內容
* 在單元測試時，測試者需要依據詳細設計說明書和源程序清單，了解該模塊的I/O條件和模塊的邏輯結構，主要採用白盒測試的測試用例，輔之以黑盒測試的測試用例，使之對任何合理的輸入和不合理的輸入，都能鑒別和響應。

(1) 模塊介面測試
* 在單元測試的開始，應對通過被測模塊的數據流進行測試。測試項目包括：
– 調用本模塊的輸入參數是否正確；
– 本模塊調用子模塊時輸入給子模塊的參數是否正確；
– 全局量的定義在各模塊中是否一致；

* 在做內外存交換時要考慮：

– 文件屬性是否正確；
– OPEN與CLOSE語句是否正確；
– 緩沖區容量與記錄長度是否匹配；
– 在進行讀寫操作之前是否打開了文件；
– 在結束文件處理時是否關閉了文件；
– 正文書寫／輸入錯誤，
– I／O錯誤是否檢查並做了處理。

(2) 局部數據結構測試
* 不正確或不一致的數據類型說明
* 使用尚未賦值或尚未初始化的變數
* 錯誤的初始值或錯誤的預設值
* 變數名拼寫錯或書寫錯
* 不一致的數據類型
* 全局數據對模塊的影響
(3) 路徑測試
* 選擇適當的測試用例，對模塊中重要的執行路徑進行測試。
* 應當設計測試用例查找由於錯誤的計算、不正確的比較或不正常的控制流而導致的錯誤。
* 對基本執行路徑和循環進行測試可以發現大量的路徑錯誤。
(4) 錯誤處理測試
* 出錯的描述是否難以理解
* 出錯的描述是否能夠對錯誤定位
* 顯示的錯誤與實際的錯誤是否相符
* 對錯誤條件的處理正確與否
* 在對錯誤進行處理之前，錯誤條件是否已經引起系統的干預等
(5) 邊界測試
* 注意數據流、控制流中剛好等於、大於或小於確定的比較值時出錯的可能性。對這些地方要仔細地選擇測試用例，認真加以測試。
* 如果對模塊運行時間有要求的話，還要專門進行關鍵路徑測試，以確定最壞情況下和平均意義下影響模塊運行時間的因素。

2. 單元測試的步驟
* 模塊並不是一個獨立的程序，在考慮測試模塊時，同時要考慮它和外界的聯系，用一些輔助模塊去模擬與被測模塊相聯系的其它模塊。
– 驅動模塊 (driver)
– 樁模塊 (stub) —— 存根模塊

* 如果一個模塊要完成多種功能，可以將這個模塊看成由幾個小程序組成。必須對其中的每個小程序先進行單元測試要做的工作，對關鍵模塊還要做性能測試。
* 對支持某些標准規程的程序，更要著手進行互聯測試。有人把這種情況特別稱為模塊測試，以區別單元測試。
集成測試（Integrated Testing）
* 集成測試 (集成測試、聯合測試）
* 通常，在單元測試的基礎上，需要將所有模塊按照設計要求組裝成為系統。這時需要考慮的問題是：
– 在把各個模塊連接起來的時候，穿越模塊介面的數據是否會丟失；
– 一個模塊的功能是否會對另一個模塊的功能產生不利的影響；

– 各個子功能組合起來，能否達到預期要求的父功能；
– 全局數據結構是否有問題；
– 單個模塊的誤差累積起來，是否會放大，從而達到不能接受的程度。
在單元測試的同時可進行集成測試，
發現並排除在模塊連接中可能出現
的問題，最終構成要求的軟體系統。

* 子系統的集成測試特別稱為部件測試，它所做的工作是要找出集成後的子系統與系統需求規格說明之間的不一致。
* 通常，把模塊集成成為系統的方式有兩種
– 一次性集成方式
– 增殖式集成方式

1. 一次性集成方式(big bang)
* 它是一種非增殖式組裝方式。也叫做整體拼裝。
* 使用這種方式，首先對每個模塊分別進行模塊測試，然後再把所有模塊組裝在一起進行測試，最終得到要求的軟體系統。

2. 增殖式集成方式
* 這種集成方式又稱漸增式集成
* 首先對一個個模塊進行模塊測試，然後將這些模塊逐步組裝成較大的系統
* 在集成的過程中邊連接邊測試，以發現連接過程中產生的問題
* 通過增殖逐步組裝成為要求的軟體系統。

(1) 自頂向下的增殖方式
* 這種集成方式將模塊按系統程序結構，沿控制層次自頂向下進行組裝。
* 自頂向下的增殖方式在測試過程中較早地驗證了主要的控制和判斷點。
* 選用按深度方向組裝的方式，可以首先實現和驗證一個完整的軟體功能。

(2) 自底向上的增殖方式
* 這種集成的方式是從程序模塊結構的最底層的模塊開始集成和測試。
* 因為模塊是自底向上進行組裝，對於一個給定層次的模塊，它的子模塊（包括子模塊的所有下屬模塊）已經組裝並測試完成，所以不再需要樁模塊。在模塊的測試過程中需要從子模塊得到的信息可以直接運行子模塊得到。

* 自頂向下增殖的方式和自底向上增殖的方式各有優缺點。
* 一般來講，一種方式的優點是另一種方式的缺點。
(3) 混合增殖式測試
* 衍變的自頂向下的增殖測試
– 首先對輸入／輸出模塊和引入新演算法模塊進行測試;
– 再自底向上組裝成為功能相當完整且相對獨立的子系統;
– 然後由主模塊開始自頂向下進行增殖測試。

* 自底向上-自頂向下的增殖測試
– 首先對含讀操作的子系統自底向上直至根結點模塊進行組裝和測試;
– 然後對含寫操作的子系統做自頂向下的組裝與測試。
* 回歸測試
– 這種方式採取自頂向下的方式測試被修改的模塊及其子模塊;
– 然後將這一部分視為子系統，再自底向上測試。
關鍵模塊問題
* 在組裝測試時，應當確定關鍵模塊，對這些關鍵模塊及早進行測試。
* 關鍵模塊的特徵：
① 滿足某些軟體需求；
② 在程序的模塊結構中位於較高的層次（高層控制模塊）；
③ 較復雜、較易發生錯誤；
④ 有明確定義的性能要求。

確認測試（Validation Testing）
* 確認測試又稱有效性測試。任務是驗證軟體的功能和性能及其它特性是否與用戶的要求一致。
* 對軟體的功能和性能要求在軟體需求規格說明書中已經明確規定。它包含的信息就是軟體確認測試的基礎。

1. 進行有效性測試（黑盒測試）
* 有效性測試是在模擬的環境 (可能就是開發的環境) 下，運用黑盒測試的方法，驗證被測軟體是否滿足需求規格說明書列出的需求。
* 首先制定測試計劃，規定要做測試的種類。還需要制定一組測試步驟，描述具體的測試用例。

* 通過實施預定的測試計劃和測試步驟，確定
– 軟體的特性是否與需求相符；
– 所有的文檔都是正確且便於使用；
– 同時，對其它軟體需求，例如可移植性、兼容性、出錯自動恢復、可維護性等，也都要進行測試

* 在全部軟體測試的測試用例運行完後，所有的測試結果可以分為兩類：
– 測試結果與預期的結果相符。這說明軟體的這部分功能或性能特徵與需求規格說明書相符合，從而這部分程序被接受。
– 測試結果與預期的結果不符。這說明軟體的這部分功能或性能特徵與需求規格說明不一致，因此要為它提交一份問題報告。

2. 軟體配置復查
n 軟體配置復查的目的是保證
u 軟體配置的所有成分都齊全；
u 各方面的質量都符合要求；
u 具有維護階段所必需的細節；
u 而且已經編排好分類的目錄。
n 應當嚴格遵守用戶手冊和操作手冊中規定的使用步驟，以便檢查這些文檔資料的完整性和正確性。
驗收測試（Acceptance Testing）
* 在通過了系統的有效性測試及軟體配置審查之後，就應開始系統的驗收測試。
* 驗收測試是以用戶為主的測試。軟體開發人員和QA（質量保證）人員也應參加。
* 由用戶參加設計測試用例，使用生產中的實際數據進行測試。

* 在測試過程中，除了考慮軟體的功能和性能外，還應對軟體的可移植性、兼容性、可維護性、錯誤的恢復功能等進行確認。
* 確認測試應交付的文檔有：
– 確認測試分析報告
– 最終的用戶手冊和操作手冊
– 項目開發總結報告。

系統測試（System Testing）
* 系統測試，是將通過確認測試的軟體，作為整個基於計算機系統的一個元素，與計算機硬體、外設、某些支持軟體、數據和人員等其它系統元素結合在一起，在實際運行環境下，對計算機系統進行一系列的組裝測試和確認測試。
* 系統測試的目的在於通過與系統的需求定義作比較, 發現軟體與系統的定義不符合或與之矛盾的地方。
其實軟體測試不僅僅是用工具去檢查別人的程序，他主要告訴就是保證所開發的軟體錯誤降低到最小。
其實做軟測的也要編代碼，他們編的是軟體的源程序，我們編的是測試用例，裡面的內容很多，做軟測也需要有一定的編程基礎

軟體測試是指使用人工或者自動的手段來運行或測定某個軟體產品系統的過程，其目的是在於檢驗是否滿足規定的需求或者弄清預期的結果與實際結果的區別。

一句話發現BUG
所謂「（Bug）」，是指電腦系統的硬體、系統軟體（如操作系統）或應用軟體（如文字處理軟體）出錯。硬體的出錯有兩個原因，一是設計錯誤，一是硬體部件 老化失效等。軟體的錯誤全是廠家設計錯誤。那種說用戶執行了非法操作的提示，是軟體廠商不負責的胡說八道。用戶可能會執行不正確的操作，比如本來是做加法 但按了減法鍵。這樣用戶會得到一個不正確的結果，但不會引起bug發作。軟體廠商在設計產品時的一個基本要求，就是不允許用戶做非法的操作。只要允許用戶 做的，都是合法的。用戶根本就沒有辦法知道廠家心裡是怎麼想的，哪些操作序列是非法的。
從電腦誕生之日起，就有了電腦BUG。第一個有記載的bug是美國海軍的編程員，編譯器的發明者格蕾斯·哈珀（Grace Hopper）發現的。哈珀後來成了美國海軍的一個將軍，領導了著名計算機語言Cobol的開發。
1945年9月9日，下午三點。哈珀中尉正領著她的小組構造一個稱為「馬克二型」的計算機。這還不是一個完全的電子計算機，它使用了大量的繼電 器，一種電子機械裝置。第二次世界大戰還沒有結束。哈珀的小組日以繼夜地工作。機房是一間第一次世界大戰時建造的老建築。那是一個炎熱的夏天，房間沒有空 調，所有窗戶都敞開散熱。
突然，馬克二型死機了。技術人員試了很多辦法，最後定位到第70號繼電器出錯。哈珀觀察這個出錯的繼電器，發現一隻飛蛾躺在中間，已經被繼電器打死。她小心地用攝子將蛾子夾出來，用透明膠布帖到「事件記錄本」中，並註明「第一個發現蟲子的實例。」[1]
從此以後，人們將計算機錯誤戲稱為蟲子（bug），而把找尋錯誤的工作稱為（debug）

「BUG」的由來：
Bug一詞的原意是「臭蟲」或「蟲子」。但是現在，在電腦系統或程序中，如果隱藏著的一些未被發現的缺陷或問題，人們也叫它「Bug」，這是怎麼回事呢？
原來，第一代的計算機是由許多龐大且昂貴的真空管組成，並利用大量的電力來使真空管發光。可能正是由於計算機運行產生的光和熱，引得一隻小蟲子 Bug 鑽進了一支真空管內，導致整個計算機無法工作。研究人員費了半天時間，總算發現原因所在，把這只小蟲子從真空管中取出後，計算機又恢復正常。後 來，Bug這個名詞就沿用下來，表示電腦系統或程序中隱藏的錯誤、缺陷或問題。
與Bug相對應，人們將發現Bug並加以糾正的過程叫做「Debug」，意即「捉蟲子」或「殺蟲子」。遺憾的是，在中文裡面，至今仍沒有與 「Bug」准確對應的詞彙，於是只能直接引用「Bug」一詞。雖然也有人使用「臭蟲」一詞替代「Bug」，但容易產生歧義，所以推廣不開。
所謂「（Bug）」，是指電腦系統的硬體、系統軟體（如操作系統）或應用軟體（如文字處理軟體）出錯。硬體的出錯有兩個原因，一是設計錯誤， 一是硬體部件老化失效等。軟體的錯誤全是廠家設計錯誤。那種說用戶執行了非法操作的提示，是軟體廠商不負責的胡說八道。用戶可能會執行不正確的操作，比如 本來是做加法但按了減法鍵。這樣用戶會得到一個不正確的結果，但不會引起bug發作。軟體廠商在設計產品時的一個基本要求，就是不允許用戶做非法的操作。 只要允許用戶做的，都是合法的。用戶根本就沒有辦法知道廠家心裡是怎麼想的，哪些操作序列是非法的。
從電腦誕生之日起，就有了電腦BUG。第一個有記載的bug是美國海軍的編程員，編譯器的發明者格蕾斯·哈珀（GraceHopper）發現的。哈珀後來成了美國海軍的一個將軍，領導了著名計算機語言Cobol的開發。
1945年9月9日，下午三點。哈珀中尉正領著她的小組構造一個稱為「馬克二型」的計算機。這還不是一個完全的電子計算機，它使用了大量的繼電 器，一種電子機械裝置。第二次世界大戰還沒有結束。哈珀的小組日以繼夜地工作。機房是一間第一次世界大戰時建造的老建築。那是一個炎熱的夏天，房間沒有空 調，所有窗戶都敞開散熱。
突然，馬克二型死機了。技術人員試了很多辦法，最後定位到第70號繼電器出錯。哈珀觀察這個出錯的繼電器，發現一隻飛蛾躺在中間，已經被繼電器打死。她小心地用攝子將蛾子夾出來，用透明膠布帖到「事件記錄本」中，並註明「第一個發現蟲子的實例。」[1]
從此以後，人們將計算機錯誤戲稱為蟲子（bug），而把找尋錯誤的工作稱為（debug）。
程序中隱藏的功能缺陷或錯誤。由於現在的軟體復雜程度早已超出了一般人能控制的范圍，如Win95、Win98這樣的較成熟的操作系統也會不定期地公布其中的Bug。如何減少以至消滅程序中的Bug，一直是程序員所極為重視的課題

1983年，IEEE提出了軟體工程標准術語，軟體測試定義為：
「使用人工和自動手段來運行或測試某個系統的過程，其目的在於檢驗它是否滿足規定的需求或是弄清預期結果與實際結果之間的差別。」
簡單的說，軟體測試就是對軟體中的缺陷進行檢測和預防。

㈡ 軟體測試員主要工作是做什麼

軟體測試員的主要工作內容是根據測試計劃和測試方案進行軟體測試；能夠針對軟體需求開發測試模型，制定測試方案，安排測試計劃，並對測試項目進行管理。

軟體測試主要工作內容是驗證（verification）和確認（validation）。

驗證(verification)是保證軟體正確地實現了一些特定功能的一系列活動， 即保證軟體以正確的方式來做了這個事件。

確認（validation）是一系列的活動和過程，目的是想證實在一個給定的外部環境中軟體的邏輯正確性。即保證軟體做了你所期望的事情。

(2)紅盒測試源碼擴展閱讀：

軟體測試的專業優勢：

1、就業競爭小

人才供不應求讓軟體測試人員的就業競爭壓力明顯小於同類其它職業，有利於從業者的身心健康。

另外，由於軟體測試在我國起步較晚，獨立設置測試部門、對測試人員有強烈需求的多為獨具慧眼的大中型IT企業。軟體測試人才不需要在小企業積累經驗就能獲得知名企業的入門通行證，工作起點高於同類其它職業。

2、高薪

剛入行的軟體測試人員，起步的月薪就在7000-15000元左右，平均薪資8000/月以上，隨著工作經驗的豐富以及能力的提升，這份薪水將一路看漲。

3、就業質量高

與其他IT職位相比，軟體測試人員最大的優勢就是發展方向太多了。由於工作的特殊性，測試人員不但需要對軟體的質量進行檢測，而且對於軟體項目的立項、管理、售前、售後等領域都要涉及。

在此過程中，測試人員不僅提升了專業的軟體測試技能，還能接觸到各行各業，從而為自己的多元化發展奠定了基礎。

4、無性別歧視

如果把軟體開發領域比作「男子單打」，那麼，軟體測試領域就是「混合雙打」。由於工作的特殊性，軟體測試人員更要具有認真、耐心、細致、敏感等個性元素，而這在一定程度上與女性的個性氣質相吻合。

據了解，很多IT企業中軟體測試人員的比例更趨向男女平衡，甚至出現女性員工成主流的情況。