這種測試有時也被稱為“acceptance test”, 因為如果構建通過了這樣的測試,這一個構建就被測試團隊“接受了”。 同時,還有對系統各個方面進行的“接收”測試,如測試系統的全球化,或者針對某一語言環境做的測試。
1.7
Ad hoc Test, Exploratory Test “探索式”的測試
“Ad Hoc” 原意是指 “特定的,一次性的”。
什么叫“特定”測試?或者“探索式”的測試?
就是為了某一個特定目的進行的測試,就這一次,以后一般也不會重復測試。在軟件工程的實踐中,“ad hoc”大部分是指隨機進行的,探索性的測試。
比如:測試人員阿毛拿到了一個新的構建,按計劃是進行模塊A的功能測試,但是他靈機一動,想看看另一個功能B做得如何,或者想看看模塊A在某種邊界條件下會出現什么問題,于是他就“ad hoc”一把,居然在這一功能模塊中發現了不少小強。
“ad hoc”也意味著測試是嘗試性的,“我來試試,在這個對話框中一通亂按,然后隨意改變窗口大小,看看會出什么問題…”, 如果沒問題,那么以后也不會再這么做了。
一般情況下,測試人員不會花很多時間進行特定測試,但是在一些缺乏管理的團隊中,很多時候測試人員不知道自己此時應該做什么,只好做一些看似“ad hoc” 的測試,比如隨機測試各個功能的各個方面。這些測試理論上都應該由測試管理人員規劃好屬于各個功能模塊的測試用例中。
在一個團隊中,“ad hoc”太多是一個管理不好的標志,因為“ad hoc”是指那些一時想到要做,但是以后也沒有計劃經常重復的測試計劃。
問:我聽說有人是“ad hoc”測試的高手,這是什么意思?
答:有很多測試人員會按部就班地進行測試,但是還有一些人頭腦比較靈活,喜歡另辟蹊徑,測試一些一般人不會想到的場景,這些人往往會發現更多的小強。開發人員對這樣的“ad hoc”高手是又愛又恨。
問:同時看問題要分兩方面,有些“ad hoc”發現的小強在正常使用軟件中幾乎不會出現,我們要不要花時間“ad hoc”
答:現在一些成功的通用軟件的用戶以百萬計,按部就班的測試計劃很難包括很多實際的場景,這時,“ad hoc”測試能夠發現重要的問題;另外一些風險很大的領域,例如安全性,一旦出了問題,威脅就會相當大,這時要多鼓勵一些“ad hoc”測試,以彌補普通測試的不足。從這個意義上說,“ad hoc”測試可以用來衡量當前測試用例的完備性,如果你探索了半天,都沒有發現什么在現有測試用例之外的問題,那就說明現有的測試用例是比較完備的。
“ad hoc”測試的測試流程是不可重復的,因為它的測試都是“特定”測試,沒法重復。由于這一原因,“ad hoc”測試不能自動化,就這一點而言,還達不到CMM的第二級 – 可重復級。
作為管理人員來說,如果太多小強是在“ad hoc”出來的,那我們就要看看測試計劃是否基于實際的場景,開發人員的代碼邏輯是否完善,等等。同時,要善于把看似“ad hoc”的測試用例抽象出來,包括到以后的測試計劃中。
1.8Regression Test回歸測試
問:我聽說不少關于Regression Test的介紹,但是它到底是怎么“回歸”法?回歸到哪里去?我還是沒搞懂。
答:Regress的英語定義是:return to a worse or less developed state.? 是倒退,退化,退步的意思。
在軟件工程中,如果一個模塊或功能以前是正常工作的,但是在一個新的構建中出了問題,那這個模塊就出現了一個“退步”- regression, 從正常工作的穩定狀態退化到不正常工作的不穩定狀態。
在一個模塊的功能逐步完成的同時,和此功能有關的測試用例也同樣在完善中。一旦有關的測試用例通過,我們就得到此模塊的功能基準(baseline).?
在某某版本,某某模塊的某某測試用例是通過的!
如果測試人員發現了在新的構建版本某個測試用例失敗了,這就是一個“倒退”,在新版本上運行所有已通過的測試用例以驗證沒有“退化”情況發生,這個過程就是一個“regression test”.? 如果這樣的“倒退”是由于模塊的功能發生了正常變化(由于設計變更的原因),那么測試用例的基準就要修改,以和新的功能保持一致。
?
針對一個bug fix (拖鞋),我們也要作Regression Test,
a) 驗證新的代碼的確把缺陷改正了,
b)同時要驗證新的代碼沒有把模塊的現有功能破壞,沒有regression。
所以我不也知道“回歸測試”是如何的“回歸”,我們可以理解為“回歸到以前不正常的狀態”。
回歸測試最好要自動化,因為對于每一個構建都要運行所有回歸測試,以保證盡早發現問題。
1.9Scenario/integration/System Test? 場景/集成/系統測試
在軟件開發的一定階段,我們要對一個軟件進行全面和系統的測試,以保證軟件的各個模塊都能共同工作,在各方面都能滿足用戶的要求。這時的測試叫系統/集成測試。
問:什么時候做系統測試?是不是越快越好?
答:原則上是當一個模塊穩定的時候,就可以把它集成到系統中,和整個系統一起進行測試,通常在軟件產品需要階段性發布的時候。
問:有一種叫Scenario Test, 是什么意思?
答:就是以場景為驅動的集成測試,關于“場景”,大家可以看專門的介紹。這一方法的核心思想是:當用戶使用一個軟件的時候,他/她并不會獨立使用各個模塊,而是把軟件做為一個整體來使用的。我們在做場景測試的時候,就需要考慮在現實環境中用戶使用軟件的流程是什么樣,然后模擬這個流程,看看軟件能不能達到用戶的需求。這樣,能使軟件符合用戶使用的實際需求。