關(guān)鍵字：過(guò)程檢測 測試自動(dòng)化
首先談?wù)?STRONG>軟件測試。這可以說(shuō)是一個(gè)非常令人捉摸不定的領(lǐng)域�！皯撛鯓訉ξ覀兊漠a(chǎn)品進(jìn)行測試？”和“怎樣才算對產(chǎn)品進(jìn)行了足夠的測試？”等問(wèn)題，對于不同企業(yè)的不同類(lèi)產(chǎn)品、同一企業(yè)的不同類(lèi)產(chǎn)品、或不同企業(yè)的同一類(lèi)產(chǎn)品，實(shí)際操作上都會(huì )有很大的不同。 SEI的SW-CMM在它的成熟度第三級的“軟件產(chǎn)品工程”關(guān)鍵過(guò)程域中，把軟件開(kāi)發(fā)周期中不同階段的測試作為實(shí)施活動(dòng)中的關(guān)鍵實(shí)踐。（在SW-CMM版本2.0 的討論過(guò)程中，曾經(jīng)有過(guò)提議，在成熟度第二級設立一個(gè)關(guān)鍵過(guò)程域“軟件測試管理”。但在版本2.0 的討論稿C 中，并沒(méi)有這樣做。從這里我們也可以看出，SW-CMM本身也是一個(gè)人為地制定的“軟件”。）
一般地，基于開(kāi)發(fā)周期中不同階段對不同對象所進(jìn)行的測試，可劃分為：
單元測試（unit test ）：
由編程的開(kāi)發(fā)人員自行計劃與完成的，針對單個(gè)或相關(guān)聯(lián)的一組程序單元的測試。
組裝測試（inegration test ）：
計劃于設計階段，由開(kāi)發(fā)人員與測試人員合作完成的，針對結合起來(lái)的不同單元以及它們的接口的測試。
系統測試（system test ）：（可認為包括“可用性與圖形用戶(hù)界面測試”）
測試整個(gè)系統，以證實(shí)它滿(mǎn)足要求所規定的功能、質(zhì)量和性能等方面的特性。
回歸測試（regression test ）：
用于驗證改變了的系統或其組件仍然保持應有的特性。
驗收測試（acceptance test ）：
測試整個(gè)系統，以保證其達到可以交付使用的狀態(tài)。
關(guān)于上述各階段的測試的具體內容及實(shí)現的方法，讀者可參考SW-CMM及有關(guān)軟件工程和軟件測試的書(shū)籍。千萬(wàn)不要停留在只參考SW-CMM，因為該文件只講述要做些什么，而沒(méi)有介紹怎樣做。同時(shí)，所有的資料中談及的內容及方法，都是一般化的。對于一個(gè)特定軟件的測試，必須經(jīng)過(guò)使用者對通用的測試方法的改變及改進(jìn)，才能有效和達到高效率。
下面，談?wù)勡浖䴗y試的其他方面的一些問(wèn)題。
一個(gè)被人忽略的軟件測試目的
在談到測試時(shí)，許多作者都引用了Grenford J. Myers 就軟件測試目的提出的以下觀(guān)點(diǎn)：
1.測試是程序的執行過(guò)程，目的在于發(fā)現錯誤；
2.一個(gè)好的測試用例在于能發(fā)現至今未發(fā)現的錯誤；
3.一個(gè)成功的測試是發(fā)現了至今未發(fā)現的錯誤的測試。
這是一種比較狹窄的觀(guān)點(diǎn)。作為一個(gè)清醒的、縱觀(guān)全局的軟件開(kāi)發(fā)人員或管理者，我們應當從軟件過(guò)程的角度來(lái)看測試。
一個(gè)被人忽略的軟件測試目的是：測試可以幫助發(fā)現當前開(kāi)發(fā)工作所采用的軟件過(guò)程（也是一個(gè)“軟件”）的缺陷，以便進(jìn)行改進(jìn)。（在以下的討論中，“錯誤”與“缺陷”基本上認為代表相同意義。）
怎樣理解這種說(shuō)法呢？
首先，測試并不僅僅是為了要找出錯誤。分析錯誤產(chǎn)生的原因和錯誤在開(kāi)發(fā)的哪一個(gè)階段產(chǎn)生，具有非常重要的意義。
通過(guò)分析錯誤的原因，我們可以立即在開(kāi)發(fā)行動(dòng)中對其進(jìn)行改正。同時(shí)，這種分析也能幫助我們推理出與所分析的錯誤有關(guān)聯(lián)的潛在錯誤，從而有針對性地設計出檢測的方法。
通過(guò)分析錯誤產(chǎn)生于哪一個(gè)開(kāi)發(fā)階段、而又在哪一個(gè)階段被發(fā)現，我們可以判斷從錯誤的產(chǎn)生到錯誤的發(fā)現，跨越了多少個(gè)開(kāi)發(fā)階段。軟件開(kāi)發(fā)的一條重要原則是盡早發(fā)現與修正錯誤。（當然，更高的一條原則是盡量預防錯誤的出現。）一個(gè)錯誤能夠超越本開(kāi)發(fā)階段而不被發(fā)現，就指明了該開(kāi)發(fā)階段的檢測手段有缺陷，從而也不難有針對性地制定出加強的措施與辦法。這也就是軟件過(guò)程改進(jìn)的一項重要內容。如果能做到在同一開(kāi)發(fā)階段發(fā)現及修正錯誤，該開(kāi)發(fā)機構就可以預期有一個(gè)高質(zhì)量的產(chǎn)品及一個(gè)低成本、高效率的軟件過(guò)程。
有些項目的主持人，認為以盡快的速度把測試之前的所有開(kāi)發(fā)階段完成（實(shí)際并沒(méi)有完成），早日開(kāi)始測試，以圖達到快速和高質(zhì)量（因為似乎有更長(cháng)的時(shí)間可用于測試）。實(shí)際的效果將會(huì )是俗語(yǔ)所說(shuō)的“欲速不達”。從常識就可以知道，花開(kāi)發(fā)時(shí)間去繼續擴大發(fā)展前面階段引入的錯誤，得出的只能是更大量的需要耗時(shí)修正的錯誤。
因此，正確分析與利用測試的結果，我們可以非常有效地進(jìn)行軟件過(guò)程改進(jìn)。
軟件開(kāi)發(fā)全過(guò)程檢測，力爭本階段修正錯誤
從上面的討論，我們很自然的就能領(lǐng)會(huì )到，軟件錯誤的發(fā)現絕不能等到測試才開(kāi)始（按常規，最早的測試就是編碼后的單元測試）。因此，筆者提出一個(gè)軟件工程的守則：軟件開(kāi)發(fā)全過(guò)程檢測，力爭本階段修正錯誤。單元測試是在軟件開(kāi)發(fā)的“實(shí)現階段”才開(kāi)始的，在此之前的“可行性研究與計劃階段”，“需求分析階段”，“概要設計階段”，和“詳細設計階段”，都必須有非常明確切實(shí)的手段與措施對開(kāi)發(fā)結果進(jìn)行檢驗，以保證階段的正確完成。
怎樣判斷一個(gè)軟件過(guò)程的優(yōu)劣，怎樣進(jìn)行軟件過(guò)程改進(jìn)，都可以在這個(gè)守則的指導下進(jìn)行。這個(gè)守則是簡(jiǎn)單明確的，但因企業(yè)背景、條件的不同，開(kāi)發(fā)環(huán)境條件的不同，項目產(chǎn)品的不同，實(shí)際的軟件過(guò)程的實(shí)現方法就會(huì )變化無(wú)窮�？紤]實(shí)現這個(gè)原則的方法的時(shí)候，可以盡量多參考各種理論及經(jīng)驗，但在選擇制定本企業(yè)開(kāi)發(fā)實(shí)踐中使用的軟件過(guò)程時(shí)，就必須處處根據是否能給自身的項目帶來(lái)好處，以及自身的條件進(jìn)行考慮。千萬(wàn)不要僅僅為了滿(mǎn)足某個(gè)“標準”的提法而做一些無(wú)實(shí)際意義的工作。要盡量避免煩瑣，爭取做到簡(jiǎn)單、有條理和有最大的效果。
軟件測試的自動(dòng)化
軟件測試的工作量很大（據統計，會(huì )用到40% 的開(kāi)發(fā)時(shí)間；一些可靠性要求非常高的軟件，測試時(shí)間甚至占到總開(kāi)發(fā)時(shí)間的60% ），但測試卻是在整個(gè)軟件過(guò)程中極有可能應用計算機進(jìn)行自動(dòng)化的工作，原因是測試的許多操作是重復性的、非智力創(chuàng )造性的、需求細致注意力的工作。計算機就最適合于代替人類(lèi)去完成這些任務(wù)。企業(yè)在這方面的投資，會(huì )對整個(gè)開(kāi)發(fā)工作的質(zhì)量、成本、和周期帶來(lái)非常明顯的效果。
一些適于考慮進(jìn)行自動(dòng)化的測試操作為： 1.測試個(gè)案的生成（包括測試輸入，標準輸出，測試操作指令等）。
2.測試的執行寫(xiě)控制（包括單機與網(wǎng)絡(luò )多機分布運行；夜間及假日運行。測試個(gè)案調用控制；測試對象、范圍、版本控制等。）。
3.測試結果與標準輸出的對比。
4.不吻合的測試結果的分析、記錄、分類(lèi)、和通報。
5.總測試狀況的統計，報表的產(chǎn)生。
測試自動(dòng)化與軟件配置管理是密不可分的。與測試有關(guān)的資源都應在配置管理中進(jìn)行統一的計劃考慮。另外，測試工具的采用也是一個(gè)提高質(zhì)量的關(guān)鍵，有些專(zhuān)用的測試工具能幫助發(fā)現一些用任何測試個(gè)案都難以觸及的錯誤。
延伸閱讀
文章來(lái)源于領(lǐng)測軟件測試網(wǎng) http://kjueaiud.com/