功能測試心得多篇文章

1、接觸功能測試已經(jīng)有三年之久，對功能測試也有自己的一些感觸和心得，下面就說說功能測試那點(diǎn)事。一、從測試前期工作開始談起當(dāng)接到一個(gè)新項(xiàng)目時(shí)，首先需要做的就是了解該項(xiàng)目的測試內(nèi)容，測試范圍，項(xiàng)目周期以及項(xiàng)目目前 的進(jìn)度。根據(jù)對項(xiàng)目的了解，綜合測試資源，制定出項(xiàng)目的測試計(jì)劃和測試策略。當(dāng)項(xiàng)目開發(fā)的已經(jīng)比較 完整，可以直接進(jìn)行系統(tǒng)測試，基本上采取常規(guī)測試，系統(tǒng)測試和回歸測試進(jìn)行交替。有些項(xiàng)目，只完成 部分模塊的開發(fā)時(shí)，則適合加入集成測試。如果項(xiàng)目時(shí)間比較緊張，而資源條件又允許的條件下，也可以 進(jìn)行敏捷測試。根據(jù)項(xiàng)目各自的特點(diǎn)，采取最佳的測試策略。二、關(guān)于模塊劃分和用例編寫關(guān)于weJ測試，大家也都知道，有

2、些功能是基于頁面的。當(dāng)功能和頁面相互融合的時(shí)候，對于模塊的 劃分就不是那么容易了。如果按頁面進(jìn)行劃分，比較容易進(jìn)行任務(wù)的分配，操作起來也比較容易控制。但 是，每個(gè)頁面上會(huì)出現(xiàn)重復(fù)的或類似的功能，出現(xiàn)問題后，容易產(chǎn)生冗余和重復(fù)的bug。如果按照功能去 劃分，可能需要在每個(gè)頁面上進(jìn)行重復(fù)操作，并且對于web頁面的測試，功能也不是很好區(qū)分，不是很明 顯，并且比較散，可能一個(gè)操作會(huì)對多個(gè)頁面產(chǎn)生影響。我的經(jīng)驗(yàn)是，一般情況下，頁面劃分優(yōu)先級高于 功能模塊劃分。當(dāng)然，具體情況還要具體分析。關(guān)于用例如何編寫，我想大部分的測試工程師都會(huì)比較了解，什么等價(jià)類劃分，邊界值分析法，因果 圖法，等等，大家只管去網(wǎng)上查

3、吧，介紹的有很多。只要有用例的標(biāo)題，操作步驟，期望結(jié)果，基本上都 是可用的。三、測試過程當(dāng)用例編寫完成，項(xiàng)目組進(jìn)行了用例評審后就可以直接進(jìn)入測試執(zhí)行階段了。（對于如何進(jìn)行用例評 審，曾經(jīng)嘗試過兩種方法，一種是每條逐個(gè)評價(jià)，一種是只評價(jià)用例框架。前者耗時(shí)太多，后者細(xì)節(jié)不夠， 總是無法找到最佳的方式。不知各位看官是否有這方面的經(jīng)驗(yàn)。）在這個(gè)階段，曾經(jīng)做過一個(gè)關(guān)于交叉測 試的實(shí)驗(yàn)。項(xiàng)目中，有測試工程師A編寫完的用例，分配給B來執(zhí)行，或者，在項(xiàng)目接近收尾的階段，讓 團(tuán)隊(duì)人員進(jìn)行互相補(bǔ)充的交叉測試。發(fā)現(xiàn)，后者的結(jié)果比前者要好。因?yàn)榍罢呤菍⒔徊鏈y試放在項(xiàng)目比較 靠前的階段進(jìn)行，一般情況下，工程師會(huì)嚴(yán)格按照

4、測試用例進(jìn)行測試，很難有時(shí)間去挖掘深層次的缺陷。 而后者是將交叉測試安排到項(xiàng)目比較靠后的階段進(jìn)行，此時(shí)，大部分的缺陷已經(jīng)被挖掘出，可能在進(jìn)行測 試時(shí)，有助于思維的發(fā)散。四、測試風(fēng)險(xiǎn)評估在測試整體完成后，需要測試負(fù)責(zé)人對該項(xiàng)目進(jìn)行總結(jié)，編寫測試報(bào)告，其中必須要做的功課就是進(jìn) 行風(fēng)險(xiǎn)評估。測試環(huán)境和線上的正式環(huán)境還是存在不少差異，有些模塊在測試環(huán)境下可能無法進(jìn)行完善的 測試，比如數(shù)據(jù)遷移的問題，比如第三方接口的不穩(wěn)定。對于測試覆蓋不到的地方，盡量在此列出，提醒 相關(guān)人員的注意，將上線后可能出現(xiàn)問題的風(fēng)險(xiǎn)降到最低點(diǎn)。對于功能測試的流程以及每個(gè)階段如何開展，網(wǎng)上的資料已經(jīng)很多很多，就不細(xì)說了，上面幾點(diǎn)

5、是在 工作中，覺得值得注意的幾點(diǎn)，希望大家可以共同探討。第一篇文章總結(jié)：測試用例執(zhí)行時(shí)實(shí)行交叉測試方法，A設(shè)計(jì)的測試用例給B完成，B設(shè)計(jì)的給A完成， 一般是在項(xiàng)目后期進(jìn)行效果比較好第一篇文章測試用例是測試執(zhí)行的關(guān)鍵，它直接指導(dǎo)如何測試。測試用例的產(chǎn)生源于測試需求，所以在此之前需要把 測試需求做好。根據(jù)測試需求的分類，在系統(tǒng)功能方面，我把它分成三個(gè)集合：界面功能，通用功能，業(yè) 務(wù)功能。任何一個(gè)頁面的元素都可以分解成這三個(gè)集合中的子集或元素。根據(jù)這三個(gè)集合的特點(diǎn)選擇不同 的測試用例設(shè)計(jì)方式。具體的設(shè)計(jì)可以參考不同的用例模板，對于界面功能，選擇簡單的模版，甚至列表 都可以，因?yàn)樗鼈兊脑匾话愣急容^獨(dú)

6、立。通用功能指在很多系統(tǒng)中都會(huì)出現(xiàn)的一些常規(guī)功能，比如：“上 一頁”，“返回”，“返回主界面”等，它們有頁面的動(dòng)態(tài)變化。在數(shù)據(jù)庫里的反映，就是最多只涉及單個(gè)表格 的改動(dòng)，并不引起表與表之間的連鎖反應(yīng)。它所使用的用例模式可采用現(xiàn)在常用的描述法表示。不過對具 體系統(tǒng)中的某些功能點(diǎn)還需要具體再考慮。測試用例設(shè)計(jì)的重點(diǎn)就是業(yè)務(wù)功能。對于一個(gè)熟練的測試人員來說，界面和通用功能的檢查，用例已 在他們的心中，并不需要文檔指導(dǎo)。業(yè)務(wù)功能是一個(gè)系統(tǒng)的核心，它往往也代表了一個(gè)管理軟件的價(jià)值。 業(yè)務(wù)功能的測試用例模版，我現(xiàn)在比較支持場景法。對主業(yè)務(wù)流的設(shè)計(jì)采取全路徑的檢測，因?yàn)樗麄兊墓?jié) 點(diǎn)不是特別多，其它的不再累述

7、。除了對系統(tǒng)正確業(yè)務(wù)流執(zhí)行的設(shè)計(jì)外，還有其它一些設(shè)計(jì)方法，根據(jù)測 試人員的不同特點(diǎn)，他們的設(shè)計(jì)也會(huì)有所不同。業(yè)務(wù)功能的設(shè)計(jì)在我看來是最能反映出測試設(shè)計(jì)人員的專 業(yè)水平。因?yàn)樗坏枰玫臏y試技術(shù)還需要好的系統(tǒng)相關(guān)行業(yè)知識(shí)。這種用例分類的想法，是為公共用例庫的建立策化。為了方便測試文檔管理，培養(yǎng)新人，特別是將熟 練的測試人員從重復(fù)繁重的文檔工作中脫離出來，重點(diǎn)放在如何檢查系統(tǒng)上。這種分離是有必要的。此外 還有一個(gè)特別操作集，源于某些測試人員的非常規(guī)操作，范圍超出三個(gè)集合，但錯(cuò)誤對系統(tǒng)的影響很大。 這個(gè)集合比較小，可以單獨(dú)管理，用于對系統(tǒng)穩(wěn)定性的考察。我有時(shí)候覺得系統(tǒng)就跟人一樣，沒有完美的人，也沒

8、有完美的系統(tǒng)，我們只是努力做得更好。第二篇文章總結(jié)：業(yè)務(wù)測試是功能測試中的重點(diǎn)，比較支持場景法第二篇文章萬科項(xiàng)目的功能測試已經(jīng)接近尾聲，作為常規(guī)項(xiàng)目，與產(chǎn)品化項(xiàng)目存在一定差異，從測試來說，對常規(guī)項(xiàng) 目與產(chǎn)品化項(xiàng)目所提缺陷的尺度與側(cè)重點(diǎn)也應(yīng)該是存在差異的，在這一點(diǎn)上，我對自己在萬科項(xiàng)目中表現(xiàn) 的并不滿意。首先，并未理解常規(guī)項(xiàng)目與產(chǎn)品化項(xiàng)目的區(qū)別，往往以產(chǎn)品化項(xiàng)目的尺度來要求萬科項(xiàng)目在一些方面 做出改進(jìn)。其次，測試過程中沒有所謂的側(cè)重點(diǎn)，基本上是廣撒網(wǎng)的形式。那么，作為測試應(yīng)該如何應(yīng)對常規(guī)項(xiàng)目與產(chǎn)品化項(xiàng)目的差異，并做好功能測試呢？常規(guī)項(xiàng)目由于是由客戶提需求，那么從業(yè)務(wù)層面上講，測試人員的業(yè)務(wù)經(jīng)驗(yàn)應(yīng)

9、該是服從于客戶的業(yè)務(wù)需求的， 不能作為評判功能是否合理的依據(jù)或標(biāo)準(zhǔn)（凍結(jié)的業(yè)務(wù)需求是唯一的標(biāo)準(zhǔn)）。常規(guī)項(xiàng)目的測試側(cè)重點(diǎn)則應(yīng) 該放在客戶真實(shí)的業(yè)務(wù)場景上，要明白客戶如何使用我們的軟件，使用軟件的哪個(gè)功能解決什么樣的問題， 我們的軟件是否真的能很好地為客戶解決這些問題？個(gè)人認(rèn)為常規(guī)項(xiàng)目的功能測試安排兩輪為好。第一輪，以主流用戶（即客戶）的角度測試功能的正確性，在這一輪中，需明確列出客戶使用軟件的 各個(gè)業(yè)務(wù)場景，測試點(diǎn)覆蓋所有的業(yè)務(wù)場景。理論上來說，這一輪發(fā)現(xiàn)的問題將會(huì)主要集中在跨模塊的業(yè) 務(wù)場景中，所以需重點(diǎn)關(guān)注跨模塊的業(yè)務(wù)場景。這一輪中發(fā)現(xiàn)的問題一般都是功能上的，嚴(yán)重級和優(yōu)先級 都很高，開發(fā)和測

10、試需要盡快修復(fù)和驗(yàn)證，以保證第二輪功能測試的展開。第一輪的測試效果很大程度上 依賴于測試人員對客戶需求、真實(shí)業(yè)務(wù)場景的理解和掌握，所以測試人員如何更好地掌握客戶的需求和業(yè) 務(wù)場景很關(guān)鍵。第二輪，以專家用戶（即測試人員）的角度對軟件的健壯性及容錯(cuò)性進(jìn)行驗(yàn)證，在這一環(huán)節(jié)中的側(cè)重 點(diǎn)是對異常情況的考慮，例如功能并發(fā)、不符合條件的輸入、邊界值等等。第二輪測試最好能夠安排交叉 測試，測試人員重點(diǎn)測試自己負(fù)責(zé)的模塊，對其他模塊的關(guān)注度可適當(dāng)降低（在工作量上體現(xiàn)），這樣的 交叉測試的好處是能很輕易地覆蓋由于不同人看問題的聚焦點(diǎn)不同而帶來的測試盲點(diǎn)。產(chǎn)品化項(xiàng)目個(gè)人認(rèn)為產(chǎn)品化項(xiàng)目對測試來說有著更高的要求，因?yàn)閷?/p>

11、產(chǎn)品化項(xiàng)目來說，面向的客戶并不是固定的， 因此就不會(huì)有非常明確的業(yè)務(wù)場景，也不像常規(guī)項(xiàng)目那樣，有任何不明確的地方可以直接找一線確認(rèn)，然 后按照客戶提的需求實(shí)現(xiàn)即可。所以對測試來說，在功能的合理性方面也是需要增加關(guān)注度的，這樣，對 測試也就會(huì)有更高的要求，對業(yè)務(wù)的熟悉，對公司管理理念的理解，這些都將直接影響到測試的深度。個(gè)人認(rèn)為，產(chǎn)品化項(xiàng)目功能測試流程基本可以參照常規(guī)項(xiàng)目的兩輪測試，而根據(jù)其差異，需增加關(guān)注 點(diǎn)、調(diào)整測試尺度。在第一輪中，需要增加對功能合理性的考慮，加強(qiáng)對各種異常的業(yè)務(wù)場景的驗(yàn)證，思考功能的實(shí)現(xiàn)是 否遵守先進(jìn)的管理理念，這些看似并不屬于測試的范疇，但個(gè)人恰恰認(rèn)為正是這些對產(chǎn)品的完

12、善和個(gè)人能 力的提升有著很積極的意義。在第二輪中，與常規(guī)項(xiàng)目相比，測試應(yīng)該提高對產(chǎn)品的要求。真正讓客戶覺得產(chǎn)品是否專業(yè)的，往往 是細(xì)節(jié)。大膽的制定嚴(yán)格的尺度，面對吹毛求疵、雞蛋里面挑骨頭的評價(jià)必須hold??！關(guān)于產(chǎn)品化項(xiàng)目，說句題外話，賣產(chǎn)品的同時(shí)也是在賣你的管理理念，先進(jìn)的管理理念才能真正成就 客戶并得到客戶的認(rèn)可，也在不知不覺中提升了客戶對我們產(chǎn)品的滿意度。功能測試國別差異之我見發(fā)布時(shí)間：2011-9-23 14:19作者：Sean Liu來源：51Testing軟件測試網(wǎng)采編字體：小中大|上一篇下一篇|打印|我要投稿|推薦標(biāo)簽：軟件測試功能測試作為黑盒測試的一個(gè)重要階段，功能測試毋庸置疑

13、是不可缺失的。功能測試的相關(guān)話題很多，無論是 測試的形式，例如手動(dòng)測試和自動(dòng)化測試，還是測試方法，例如數(shù)據(jù)驅(qū)動(dòng)和關(guān)鍵字驅(qū)動(dòng)，都有大量的研究 文章。我這篇博文里卻打算從國別不同的角度來討論一下功能測試的差異，原創(chuàng)文章可能有一些謬誤的地 方，請讀者指摘。日式循規(guī)蹈矩日本人給世界其他民族的印象是做事認(rèn)真嚴(yán)謹(jǐn)，對待問題一絲不茍，犯了錯(cuò)誤按嚴(yán)重程度該下跪的下 跪，該剖腹的剖腹。他們的這種一貫行事方式也帶到了軟件行業(yè)，而軟件行業(yè)的摩爾定律，技術(shù)的日新月 異，代碼、框架的多變，都似乎與他們的性格格格不入。日本制造的東西一向以堅(jiān)固耐用著稱，給我映像 最深的一個(gè)細(xì)節(jié)是，在日本工作的時(shí)候，發(fā)現(xiàn)他們的垃圾袋居然都堅(jiān)

14、固無比，用來逛超市買東西拎重物也是屢用不壞。然而，對于遵從摩爾定律的計(jì)算機(jī)行業(yè)來說，投入大量的精力來盡可能的發(fā)現(xiàn)bug以及解決 問題是否很值，這真的是有待商榷的問題。但，話雖如此，日企采用的測試用例的設(shè)計(jì)方法還是非常值得我們學(xué)習(xí)的，這其中又首先要提一下要 因分析法（網(wǎng)上有些說法把魚骨圖等同于要因分析法，我并不贊同此說，后面會(huì)有詳述）。要因分析法的精髓在于，以產(chǎn)品的某一特性為因子，以這個(gè)特性的不同表現(xiàn)（根據(jù)等價(jià)類劃分、邊界 值分析等方法）為狀態(tài)，一一列舉后，采用二維組合的方式來確定測試用例。下面我舉一個(gè)簡單的例子“我打算從南京去北京”來說明。因子。交通方式天氣情沿出發(fā)時(shí)辰一狀態(tài)氐飛機(jī)*晴點(diǎn)白天/

15、狀態(tài)2二火軍*雨#夜晚二?狀態(tài)3汽車e爭表1這即是一張簡單的要因表，值得注意的是，因子和狀態(tài)的確定是必須規(guī)定范圍的，而這個(gè)范圍在這個(gè) 例子中則為“正常人的思考”范圍。譬如說，“交通方式”我沒有寫“步行”，因?yàn)檫@不符合常人從南京去北京的 思考方式，當(dāng)然有人為了挑戰(zhàn)吉尼斯紀(jì)錄，這里非要采用步行方式從南京前往北京，那么狀態(tài)里添加這項(xiàng) 顯然是可以的。此外，因子和狀態(tài)的另一個(gè)隱性的確定方針為詳細(xì)度，這個(gè)度如何把握，我們可以從下表來理解:因子砂飛機(jī)火車/汽車F天氣情沅出發(fā)時(shí)叵狀態(tài)0南方航空動(dòng)車* :;豪華臥鋪晴點(diǎn)白天/ 狀態(tài)2“東方航空口高斑.普通臥鋪口夜晚中.狀態(tài)p特此爭狀態(tài)心普快弟表2表2將表1的“交

16、通方式”進(jìn)一步細(xì)化，此時(shí)狀態(tài)的選擇將進(jìn)一步增多。如果要求詳細(xì)度更加提高，例如因子為“動(dòng)車”，那么可以加上狀態(tài)為“一等座”和“二等座”，這種組合很靈活，取決于我所需的詳細(xì)級別。要因確定之后，便是組合，以表1所列要因?yàn)槔?，二維組合有下列共18種：飛機(jī)-晴-白天，飛機(jī)-雨-白天，飛機(jī)-雪-白天，飛機(jī)-晴-夜晚，飛機(jī)-雨-夜晚，飛機(jī)-雪-夜晚火車-晴-白天，火車-雨-白天，火車-雪-白天，火車-晴-夜晚，火車-雨-夜晚，火車-雪-夜晚汽車-晴-白天，汽車-雨-白天，汽車-雪-白天，汽車-晴-夜晚，汽車-雨-夜晚，汽車-雪-夜晚對于表2來說，二維組合則有2*4*2*3*2=96種，貌似有點(diǎn)多，當(dāng)然你想分

17、析的越詳細(xì)，那么組合數(shù)量 自然會(huì)相應(yīng)的增加?；氐奖?得出的18種用例，假如我的通過條件是從南京到北京的時(shí)間越短越好，在實(shí)際的外界環(huán)境 下（例如晴天，預(yù)期花費(fèi)有限額），這18個(gè)用例中，就會(huì)出現(xiàn)有的測試通過，有的測試失敗的情況了。在 不同的實(shí)際外界環(huán)境下，測試通過的情況還會(huì)發(fā)生變化（例如下雪天，飛機(jī)會(huì)發(fā)生班次延誤）。要因分析法的好處在于“事無巨細(xì)，滴水不漏”，壞處在于過程“繁瑣冗長，枯燥乏味”。即使如此細(xì)致的要因 分析，依然存在一定的用例遺漏的風(fēng)險(xiǎn)，這個(gè)風(fēng)險(xiǎn)來自于對因子和狀態(tài)潛在的考慮不周。隨著詳細(xì)級別要 求或者系統(tǒng)復(fù)雜度的提高，使用要因分析法組合出詳盡的測試方案則成為了QA的一種折磨，每一個(gè)QA

18、 遇到復(fù)雜的測試對象，都將成為酷刑下折翼的天使，欲哭無淚的在心中默默吶喊“坑爹啊”（因此要對要因 法做一定程度的改良，如何改良，后文將詳述）。前文伏筆“要因分析法不是魚骨分析法”，魚骨分析法的另一個(gè)更加正式的書面稱呼是“根本原因分析法” （日本管理大師石川馨先生發(fā)展出來的，故又名石川圖）。根本原因分析法同樣有著折磨常人的地方（題 外話：為什么日本人使用的方法總是那么坑爹？），它要求分析者們集中精力尋求發(fā)生問題的任何一種可 能性（頭腦風(fēng)暴），將這些可能性繪制在魚骨圖上，再尋求所有可能性的根源，其本質(zhì)上不是一種用于設(shè) 計(jì)測試方案的方法（僅僅用于追溯問題，例如發(fā)現(xiàn)bug后追溯引起bug的根源）。關(guān)于

19、根本原因分析法的 討論，由于和本文的重點(diǎn)有偏離，因此不做進(jìn)一步描述，題外話就此打住。歐美式頭腦風(fēng)暴眾所周知，歐美企業(yè)的風(fēng)格是強(qiáng)調(diào)人性和自由，對于測試來說，自然不可能采納日式那種條條框框的 做法。測試方案設(shè)計(jì)的基本方法和準(zhǔn)則，例如邊界值分析、等價(jià)類劃分、因果圖等，被QA們牢牢的記在 心中，功能測試方案設(shè)計(jì)時(shí)，根據(jù)需求分析或用戶手冊，眾人在一起集中進(jìn)行頭腦風(fēng)暴，此時(shí)包括RD也 將參與進(jìn)來，對于測試合理或者不合理的地方提出建議。因此，方案設(shè)計(jì)的時(shí)候，更強(qiáng)調(diào)的是經(jīng)驗(yàn)和閱歷 以及對需求的關(guān)注程度。測試方案設(shè)計(jì)是有偏重的，對于一些重要的feature強(qiáng)烈關(guān)注，用例也將根據(jù)feature 的重要性而詳略有別

20、。頭腦風(fēng)暴式的測試用例設(shè)計(jì)的輔助工具往往以思維導(dǎo)圖為主，還是以“我打算從南京去北京”為例，其 中一種思維導(dǎo)圖設(shè)計(jì)如下：交通玉機(jī)東航大車:東航&初 1南航交虹具高鐵火車動(dòng)車特怏飛機(jī)南航交諼：具蟲車思維導(dǎo)圖的靈活性很高，因此設(shè)計(jì)出的導(dǎo)圖每次都會(huì)有所不同，跟隨著與會(huì)者偏重點(diǎn)的不同而產(chǎn)生不同的 設(shè)計(jì)方案。好比歐洲的菜肴大多以整塊烹制為主，而中國人的菜肴則基本上都是切碎的。這是因?yàn)槭芟抻趥鹘y(tǒng)使 用的餐具。而測試方案的設(shè)計(jì)方法也同樣受到西方和東方文化差異的影響，例如Agile首先在歐美出現(xiàn)并 迅速得到推廣和應(yīng)用，而Agile絕對不會(huì)首先出現(xiàn)于日本。對于頭腦風(fēng)暴式的測試方案設(shè)計(jì)，這頗有Agile 的風(fēng)格，項(xiàng)

21、目參與者進(jìn)行充分的思想交流，QA們將每一個(gè)閃現(xiàn)于頭腦的想法都記錄在案，同時(shí)根據(jù)別的 QA和RD的建議來不斷地修正或彌補(bǔ)方案，直到完成設(shè)計(jì)。這種設(shè)計(jì)方法的好處是擁有很好的靈活性，且可以避免精力被耗費(fèi)到旁枝末節(jié)上。用例可以是很多步 驟組合起來的（表現(xiàn)為思維導(dǎo)圖的層次較多），通過一個(gè)用例測到多個(gè)feature，這在進(jìn)行具體的自動(dòng)化測試代碼編寫時(shí)可以節(jié)省大量勞動(dòng)力。由于交流足夠充分，某些不易被想到的測試用例也可以被挖掘出來（好 比繪制清晰的思維導(dǎo)圖）。然而，這種方法的缺點(diǎn)也是顯而易見的，某些測試用例有可能在頭腦風(fēng)暴中被 忽視或遺忘，且受限于人的思維的不嚴(yán)密性，未設(shè)計(jì)在案的測試用例，往往也沒有人會(huì)關(guān)注到

22、為什么這些 測試用例不用測”這個(gè)問題。歐美與日式的比較其實(shí)從上述的兩個(gè)篇章，我已經(jīng)闡述了二者之間的差異。日式苦行僧般的要因分析法，幾乎可以遍歷 窮舉所有可能的組合方式（除非因子有遺漏），設(shè)計(jì)完畢后，到了具體測試實(shí)施階段，無論是手動(dòng)測試還 是自動(dòng)化測試，對于QA來說，都是一個(gè)比拼耐力的考驗(yàn)，測試用例數(shù)動(dòng)輒過千，大量的測試用例之間甚 至只有細(xì)微的差別。QA將完全體驗(yàn)不到創(chuàng)作的樂趣，轉(zhuǎn)而成為一名不折不扣的體力勞動(dòng)者。一個(gè)測試對 象的測試周期也被大大拉長，所需的人月數(shù)也很多。完成這些繁瑣的工作之后，測試對象將趨于完美，細(xì) 微的bug也將被找出并修正。此時(shí)不排除測試對象可能已經(jīng)是一個(gè)落后的甚至被淘汰的產(chǎn)

23、品了。當(dāng)然，這 對于用戶忠誠度極高的日本人來說，這不算什么問題，他們不厭其煩的強(qiáng)調(diào)產(chǎn)品品質(zhì)，但是對于這顆星球 上的其他民族來說，大多寧可忍受一些小bug，也不愿使用一個(gè)過期的技術(shù)落后的產(chǎn)品。對于歐美式的測試設(shè)計(jì)，顯然比較契合當(dāng)前的飛速發(fā)展的計(jì)算機(jī)業(yè)，但產(chǎn)品中留下的bug數(shù)量往往也 會(huì)比日式測試法多的多。這尤其表現(xiàn)在產(chǎn)品的一些局部的、次要的功能上，這些功能往往將成為bug集中 營。兩者融合的思考?xì)W美與日本，兩者采用的方法各有長處。一者的缺點(diǎn)往往恰是另一者的長處。那么該如何從兩者中取 長補(bǔ)短，去粗取精以至互相融合呢？這也是我在工作中一直不斷思考的一個(gè)問題。我認(rèn)為有一種可行的解決方案可以按照如下的做

24、法進(jìn)行：1、列出要因表，因子和狀態(tài)的列舉方式可以采用思維導(dǎo)圖進(jìn)行2、根據(jù)deadline來劃分測試的詳略程度，制訂測試計(jì)劃3、頭腦風(fēng)暴，將要因表的二維組合放在參與者的頭腦中進(jìn)行4、在列舉測試用例的同時(shí)，對不測的用例也要追究一下不測的原因5、歸納測試用例之間的共性，對于差別較小的測試用例，要考慮如何整合到一起，對于可以串行的用 例，要考慮是否可以合并為一個(gè)多步驟的用例通過以上5個(gè)步驟，我想既可以避免要因分析法的要因組合階段帶來的讓人抓狂的繁瑣和用例數(shù)量過 多的缺陷，又可以避免頭腦風(fēng)暴帶來的某些用例的考慮不周。是否還有其他更好的取長補(bǔ)短的方法呢？這個(gè)問題將依然縈繞在我的日常測試工作中，吾將上下求索

25、， 并期待您對本文的看法能夠給予我茅塞頓開的啟迪。第五篇文章今天boss問我們對于公司當(dāng)前功能測試是否有完善意見，突然覺得這個(gè)話題離我們很近，卻總來沒深入總 結(jié)過。還好要求明天上交報(bào)告，先在此做些總結(jié)，到時(shí)候拼裝下給boss.接觸測試三年了，從測試工程師到測試組長兼sepg，然后跳槽繼續(xù)測試工程師。一路下來都在跟需求 跟業(yè)務(wù)打交道。做好測試首先要做好需求、理解業(yè)務(wù)，這個(gè)不用多說了，相信很多人都總結(jié)過。當(dāng)然也聽 到過一些言論“換單位了，那業(yè)務(wù)不是沒用了”，換單位后，業(yè)務(wù)沒用這是必然的，我也是從易制毒換到當(dāng) 前的稅務(wù)，但有一點(diǎn)都是跟政府行業(yè)，其實(shí)我們要做的是摸索和總結(jié)如何快速獲取和掌握新業(yè)務(wù)，內(nèi)容

26、不 同，但方法是可以通用的。對于需求處理，就我接觸的有以下三種情況。A、有需求說明，無設(shè)計(jì)文檔。B、有需求分析文檔，快完成時(shí)臨時(shí)補(bǔ)充設(shè)計(jì)文檔。C、有需求分析文檔和設(shè)計(jì)文檔。A這種情況一般分工不是很明確的小團(tuán)隊(duì)都會(huì)出現(xiàn)，需求來源為客戶或者區(qū)域客服（特點(diǎn)是太簡單了 沒經(jīng)過提取，或者太自我了，很難實(shí)現(xiàn)），這時(shí)候在不規(guī)范的過程也會(huì)弄一次需求討論。這個(gè)時(shí)候測試務(wù) 必要做到這點(diǎn)爭取參加需求討論會(huì)議，不用發(fā)言，只要聽就可以。因?yàn)檫@里沒有寫文檔的習(xí)慣，很多 測試標(biāo)準(zhǔn)、需求處理細(xì)點(diǎn)都會(huì)在口頭上體現(xiàn)，你得眼疾手快，參加會(huì)議很好的一點(diǎn)就是測試過程中，碰到 不一致的地方，可以有足夠的重語氣讓開發(fā)修改，因?yàn)槟阌凶C據(jù)，而

27、不用去問開發(fā)這點(diǎn)是不是要改，如何 實(shí)現(xiàn)。B這種情況其實(shí)是最頭痛的，在時(shí)間緊和維護(hù)項(xiàng)目中經(jīng)常出現(xiàn)。軟件需求功能在界面上都實(shí)現(xiàn)了，但 開發(fā)只是考慮實(shí)現(xiàn)需求，卻沒有把需求與當(dāng)前業(yè)務(wù)（其他模塊的邏輯），后臺(tái)數(shù)據(jù)處理（例如某個(gè)字段更 新）這些弄好。因?yàn)楣δ軠y試時(shí)，測試人員大都會(huì)跑流程或者數(shù)據(jù)庫測試，這時(shí)候模糊無標(biāo)準(zhǔn)的問題就來 了，頭痛。另外一些開發(fā)人員就會(huì)以功能實(shí)現(xiàn)，進(jìn)入測試、或者邊設(shè)計(jì)邊改，測試就大工作量了。這個(gè)時(shí) 候測試有這些可以扭轉(zhuǎn)一些局面一一版本驗(yàn)收流程、開發(fā)人員給測試人員培訓(xùn)。版本驗(yàn)收：像前面提出的， 設(shè)計(jì)不全面等，很容易導(dǎo)致只完成需求，破壞了原有功能或流程功能，在拿到版本后，進(jìn)行初步的重要流

28、 程驗(yàn)收，可以減少很多測試工作量。開發(fā)人員講解培訓(xùn)：這個(gè)很好的解決了由于沒設(shè)計(jì)文檔導(dǎo)致的測試不 了解內(nèi)部，被動(dòng)，另外也是給開發(fā)壓力，逼他們做單元和集成自測，從中測試也可以提問，不要覺得這是 浪費(fèi)時(shí)間，好處你試了才知道。我很壞，呵呵。C這種情況一般實(shí)行Cmmi3之后的企業(yè)都很規(guī)范。這里我講下自己的幾個(gè)方法，更好的理解需求：模 塊間邏輯圖、數(shù)據(jù)流向圖、需求用例矩陣。模塊間邏輯圖：其實(shí)就usecase圖、流程圖，只要能讓自己摸 清楚模塊間的業(yè)務(wù)聯(lián)系即可，為自己的業(yè)務(wù)測試用例做準(zhǔn)備。數(shù)據(jù)流向圖：目的是搞清楚，該某塊功能涉 及哪些表、存儲(chǔ)過程，數(shù)據(jù)表見關(guān)系如何，其實(shí)有點(diǎn)像數(shù)據(jù)庫模型的小型版，很多問題在界

29、面上實(shí)現(xiàn)了， 但后臺(tái)sql處理卻有錯(cuò)誤。例矩陣這個(gè)主要是對覆蓋率進(jìn)行校驗(yàn)，其實(shí)就是一個(gè)execl，針對某個(gè)需求點(diǎn)有 哪些用例。這些文檔我稍后上轉(zhuǎn)。另外在閱讀需求時(shí)，多寫一些為什么（例如：文檔上寫著某輸入框有默 認(rèn)值，那你注明下：默認(rèn)值可以修改嗎？）或許你們覺得讓測試參加會(huì)議，讓開發(fā)講解這些有點(diǎn)難，但記住一點(diǎn)：做測試的一定要“主動(dòng)”。在做功能測試過程中，經(jīng)常會(huì)碰到其他的問題。例如：對于web，所用控件的ie兼容性，標(biāo)簽值顯示 格式、長度，提示信息風(fēng)格、內(nèi)容，按鈕大小，名稱等這些，當(dāng)前項(xiàng)目和開發(fā)人員都習(xí)慣最后處理。更多 時(shí)候測試跟開發(fā)還不能達(dá)成一致，維護(hù)時(shí)還有“這是以前開發(fā)人員弄的，當(dāng)前不予修改這

30、些。” 一些通用的 界面要求可以定個(gè)標(biāo)準(zhǔn)并維護(hù)，這個(gè)初步難的話，在項(xiàng)目測試計(jì)劃里能注明下，并達(dá)成統(tǒng)一。這樣避免項(xiàng) 目后期，開發(fā)人員改動(dòng)，測試人員由于對工作負(fù)責(zé)又得全部測試一遍，減少工作量。功能測試，先抓主干，在測分支這是恒定的原則。但如何完善功能測試這個(gè)值得討論，測試前如何分 析需求，編寫用例，測試通過準(zhǔn)則。測試中確定測試版本，選擇用例，測試優(yōu)先級。項(xiàng)目后期的測試分析， 用例優(yōu)化等等。第六篇文章本文是InfoQ中文站特邀編輯滕振宇采訪了微軟亞太研發(fā)集團(tuán)服務(wù)器與開發(fā)工具事業(yè)部的部門經(jīng)理 Ramesh Rajagopal的作品。在采訪中，Ramesh從項(xiàng)目管理、需求管理以及技術(shù)架構(gòu)控制等方面分享了

31、 他所帶領(lǐng)Visual Studio軟件生命周期管理工具團(tuán)隊(duì)使用敏捷方式組織管理大規(guī)模軟件團(tuán)隊(duì)方面的經(jīng)驗(yàn)。注：本文是依據(jù)郵件采訪整理而成，為保持現(xiàn)場感，文中使用第一人稱指代微軟亞太研發(fā)集團(tuán)服務(wù)器 與開發(fā)工具事業(yè)部。微軟Office產(chǎn)品組最早引入了功能小組模型，并采用這個(gè)模式開發(fā)、發(fā)布了幾個(gè)Office版本。之后， 微軟其它部門也開始采用，包括Windows部門和開發(fā)工具事業(yè)部門（后者負(fù)責(zé)開發(fā)Visual Studio系列產(chǎn) 品）。這些部門都擁有數(shù)千名工程師，我們需要在具有數(shù)百萬行代碼的代碼庫上工作，并且多次成功發(fā)布 了這些產(chǎn)品，可以說，功能小組模型在項(xiàng)目管理、需求管理、以及技術(shù)及構(gòu)架控制等方面

32、有著很好的擴(kuò)展 性。首先簡單介紹一下我們是如何進(jìn)行產(chǎn)品計(jì)劃。進(jìn)入產(chǎn)品開發(fā)前，高層管理團(tuán)隊(duì)要確定新版本將帶來的 商機(jī)（Business Opportunity）。（注意：為了能夠確定這些商機(jī)，高層管理團(tuán)隊(duì)會(huì)從在整個(gè)部門收集數(shù)據(jù) 和征詢反饋意見。）然后，起草對應(yīng)這些商機(jī)的高層目標(biāo)。這些目標(biāo)會(huì)被分解為多個(gè)用戶價(jià)值主張（U ser Value Propositions,可以將它們看作是Agile術(shù)語中的“epic故事）。接下來它們又會(huì)被細(xì)分為用戶體驗(yàn)（User Experience,可以將他們理解為Agile術(shù)語中的“主題，Themes）。功能小組于是會(huì)定義實(shí)現(xiàn)這些 用戶體驗(yàn)的用戶故事。實(shí)現(xiàn)這一整套用

33、戶體驗(yàn)也就是實(shí)現(xiàn)了用戶價(jià)值主張，從而達(dá)到商業(yè)目標(biāo)（BusinessObjectives）o我們會(huì)為每個(gè)產(chǎn)品的發(fā)布設(shè)計(jì)一個(gè)計(jì)劃里程碑（通常情況下一個(gè)里程碑需要12個(gè)星期）。在這個(gè)階段， 產(chǎn)品負(fù)責(zé)人會(huì)為這個(gè)產(chǎn)品發(fā)布制定一組要達(dá)到的商業(yè)目標(biāo)和目的。接下來每個(gè)下屬團(tuán)隊(duì)（它們是整個(gè)產(chǎn)品， 如Visual Studio,開發(fā)的一部分）要?jiǎng)?chuàng)建出符合一個(gè)或多個(gè)商業(yè)目標(biāo)的產(chǎn)品待開發(fā)事項(xiàng)（Product Backlog）。下面讓我們來看一個(gè)具體的例子。對于微軟開發(fā)工具部門而言，我們的使命是：“讓每一個(gè)使用微軟工 具和平臺(tái)的軟件項(xiàng)目獲得成功”。我們每個(gè)產(chǎn)品以及其中所包含的功能都是圍繞這個(gè)使命來開發(fā)的。例如， 早期的

34、Visual Studio主要是集中在核心的開發(fā)活動(dòng)上，如：編碼、編譯和調(diào)試。后來我們意識(shí)到軟件項(xiàng)目 要成功，需要提供對整個(gè)開發(fā)周期的支持。這直接導(dǎo)致了 Team Foundation Server和Visual Studio ALM（Application Lifecycle Management，軟件應(yīng)用生命周期管理）工具的產(chǎn)生，以支持項(xiàng)目管理、構(gòu)架、設(shè) 計(jì)和測試等開發(fā)活動(dòng)。Visual Studio 2010的一個(gè)商業(yè)目標(biāo)是：“使軟件開發(fā)團(tuán)隊(duì)采用正確的方法來編寫軟件”。從這個(gè)高層主 題可以創(chuàng)建出幾個(gè)價(jià)值主張。其中一個(gè)主張就是：“使軟件開發(fā)團(tuán)隊(duì)通過構(gòu)架和模型工具來管理軟件的復(fù)雜 性”。它還

35、可以再進(jìn)一步細(xì)分為：“使軟件開發(fā)團(tuán)隊(duì)能夠理解和分析已有的代碼”、“使軟件開發(fā)團(tuán)隊(duì)能夠驗(yàn)證 它們的代碼是否符合指定的構(gòu)架設(shè)計(jì)”、“使軟件開發(fā)團(tuán)隊(duì)能夠理解他們所在的領(lǐng)域和需求，并設(shè)計(jì)出期望 的構(gòu)架”等主題。這些主題分配給各個(gè)功能小組。在設(shè)計(jì)計(jì)劃里程碑最后階段，功能小組和產(chǎn)品負(fù)責(zé)人（負(fù) 責(zé)某一特定的價(jià)值主張）相互協(xié)作一起定義出產(chǎn)品待開發(fā)事項(xiàng)。它包含了一組劃分好優(yōu)先級的用戶故事， 期間會(huì)充分聽取團(tuán)隊(duì)成員的意見和反饋，并最終與產(chǎn)品負(fù)責(zé)人進(jìn)行確認(rèn)。這實(shí)質(zhì)上就是產(chǎn)品的發(fā)布計(jì)劃， 并用它來進(jìn)行跟蹤和管理產(chǎn)品的開發(fā)。產(chǎn)品待開發(fā)事項(xiàng)中的用戶故事也是以工作項(xiàng)的形式保存在TFS上的（TFS 2010的MSF Agile Template定義了用戶故事工作項(xiàng)類型）。每個(gè)產(chǎn)品待開發(fā)事項(xiàng)可能會(huì)覆蓋多個(gè)價(jià)值主張，而關(guān)于同一個(gè)價(jià)值主張的主題也