OK--就是Pass，測試通過的意思。
POK - 部分通過，表示測試中有很多檢查點，比如其中兩個檢查點通過，一個沒有通過，就是POK
NG - 是Not Good的意思，不同的公司叫法不盡相同，有些公司也叫Fail
NT - Not Test，表示沒有測試，并不是所有的測試用例在每一測試輪次都是需要測試的，沒進行測試的就是NT

 

一開始聽講課的老師說，性格會隨著信念和經(jīng)驗而改變，還覺得難以相信，因為似乎我多年來的性格變化不大。

而如今經(jīng)過兩年多的嚴格要求自己，以及參加了一系列的培訓(xùn)之后，我再次的性格類型測試已然跟從前不同了，確實以下的這個答案更是像現(xiàn)在的我了。

您的性格類型傾向是“ ENTJ ”(外向 直覺 思維 判斷)

坦誠、果斷，有天生的領(lǐng)導(dǎo)能力。能很快看到公司/組織程序和政策中的不合理性和低效能性，發(fā)展并實施有效和全面的系統(tǒng)來解決問題。善于做長期的計劃和目標的設(shè)定。通常見多識廣，博覽群書，喜歡拓廣自己的知識面 并將此分享給他人。在陳述自己的想法時非常強而有力。

ENTJ型的人是偉大的領(lǐng)導(dǎo)者和決策人。他們能輕易地看出事物具有的可能性，很高興指導(dǎo)別人，使他們的想象成為現(xiàn)實。他們是頭腦靈活的思想家和偉大的長遠規(guī)劃者。因為ENTJ型的人很有條理和分析能力，所以他們通常 對要求推理和才智的任何事情都很擅長。為了在完成工作中稱職，他們通常會很自然地看出所處情況中可能存在的缺陷，并且立刻知道如何改進。他們力求精通整個體系，而不是簡單地把它們做為現(xiàn)存的接受而已。 ENTJ型 的人樂于完成一些需要解決的復(fù)雜問題，他們大膽地力求掌握使他們感興趣的任何事情。 ENTJ型的人把事實看得高于一切，只有通過邏輯的推理才會確信。 ENTJ型的人渴望不斷增加自己的知識基礎(chǔ)，他們系統(tǒng)地計劃和研 究新情況。他們樂于鉆研復(fù)雜的理論性問題，力求精通任何他們認為有趣的事物。他們對于行為的未來結(jié)果更感興趣，而不是事物現(xiàn)存的狀況。 ENTJ型的人是熱心而真誠的天生的領(lǐng)導(dǎo)者，他們往往能夠控制他們所處的任何 環(huán)境。因為他們具有預(yù)見能力，并且向別人傳播他們的觀點，所以他們是出色的群眾組織者。他們往往按照一套相當(dāng)嚴格的規(guī)律生活，并且希望別人也是如此。因此他們往往具有挑戰(zhàn)性，同樣艱難地推動自我和他人前進。

 

 

目標確定后，我第一步要做的就是找資料，找資料的工作都是春節(jié)在家里完成的（其間還帶爸媽瀏覽了一下公司的網(wǎng)站），找開源的工具，主要是看大眾的評價和普及度。

軟件的易用度很重要，否則無法達到優(yōu)化測試管理的目的。……（此處省略n字baidu和google），主流的開源測試管理工具如下：

缺陷管理工具

1．    Mantis（http://mantisbt.sourceforge.net/）

2．    Bugzilla（http://www.mozilla.org/projects/bugzilla/

3．    Bugfree (http://www.bugfree.cn/)

測試管理工具

1．    TestLink（http://testlink.sourceforge.net/docs/testLink.php）

2．    Bugzilla Test Runner （http://sourceforge.net/projects/testrunner/）

最開始的時候特別侵向于2&2，因為Bugzilla Test Runner 就是基于Bugzilla的測試用例管理系統(tǒng)。本打算把前者改造一下讓它支持更多測試計劃（上篇提到的需求1），可惜工作量有點大，另外它的網(wǎng)絡(luò)支持也較少，決定Pass。

到這時，測試管理工具就剩下Testlink了，缺陷管理工具開始也是想用2，比較熟悉，這個沒有兌現(xiàn)則純粹是緣分問題，現(xiàn)在懷疑是當(dāng)時下載的Bugzilla的包是個壞的，感興趣的同學(xué)可以再試試。

最終Testlink和Bugfree的結(jié)合就是順理成章了。這樣確定的時候，有點無奈，因為二者是PHP＋mysql＋Apache的，我對PHP了解太少，沒有寫過程序，不知道遇到問題能不能改。新發(fā)布的Bugfree2.0增加了測試用例和測試結(jié)果的管理，“冗余”了，還是用1.1.

 服務(wù)器啟來，Testlink和Bugfree分別執(zhí)行了一下，總的來說挺幸運，除了Testlink的亂碼比較多，兩個都能獨立順利跑起來。亂碼的問題最后改，根據(jù)經(jīng)驗，這一定是個minor的bug，應(yīng)該就是配置的問題。先嘗試能把兩個連接起來重要些。

找到配置文件，鏈接按鈕也照著葫蘆畫瓢編碼進去并且正確顯示了，只是點擊按鈕后就會異常退出。找Bug是咱測試人員的強項，分析跟這個bug相關(guān)的第一嫌疑是testlink和bugfree的主程序，次嫌疑是相關(guān)的兩個配置文件，主程序很短，兩個index.php 從頭至尾看過一遍，最可能出bug的就是幾個if語句了，分支走錯了退出，太常見了。果然就是少了一個！的問題。亂碼是鍵值沒有內(nèi)容，逐個配置上就解決了。

試著模擬了一次CCI回歸測試，從建計劃到執(zhí)行到指派相關(guān)人員處理臨時問題，可以滿足上篇的需求，也可以勝任小型項目的測試管理工作。CCI的同學(xué)可以連到我的機器玩玩http://10.1.1.187/testlink/index.php test/123456(senior tester). 目前自動化測試管理剩下一些修補的工作，像是郵件配置，明確權(quán)限管理、測試流程等，需要在業(yè)余時間慢慢做完，只是繁瑣，應(yīng)該不難。另外計劃在4月份可以準備一次《基于Testlink&Bugfree的測試管理工具UserGuide》的內(nèi)部交流。

最后總結(jié)一下整個自動化測試管理的過程，最大的感觸就是“選擇比努力更重要”，和人生一樣，永遠不只是A和B的選擇，應(yīng)該還有C。另外一個感觸是，很多實驗沒有做徹底有些遺憾（主要是時間成本），無法確切定位問題，疏漏難免，因此非常歡迎大家的建議和指導(dǎo)！來電來函均有來必復(fù)～

     摘要: 白盒測試的測試方法有代碼檢查法、靜態(tài)結(jié)構(gòu)分析法、靜態(tài)質(zhì)量度量法、邏輯覆蓋法、基本路徑測試法、域測試、符號測試、Z路徑覆蓋、程序變異。

　　其中運用最為廣泛的是基本路徑測試法。

　　基本路徑測試法是在程序控制流圖的基礎(chǔ)上，通過分析控制構(gòu)造的環(huán)路復(fù)雜性，導(dǎo)出基本可執(zhí)行路徑集合，從而設(shè)計測試用例的方法。

　　設(shè)計出的測試用例要保證在測試中程序的每個可執(zhí)行語句至少執(zhí)行一次。

  閱讀全文  

節(jié)日里我們總會送出也會收到很多的祝福，總覺得最實在的其實不過一句，那就是祝你健康。

節(jié)前公司體檢的時候，我告訴大夫我的背坐久了就會痛，最后的體檢報告只多了一條診斷：自訴背痛，沒有給出什么原因。這一次回老家, 父親給我施了3次針就好了。說實話，過年最大的收獲，最大的感觸，都來自于父親。

中醫(yī)是我家祖?zhèn)鞯模彩歉赣H畢生的理想，都說命運愛捉弄人，為了我們姐弟更好的生活和自由追求我們的理想，20年前，父親辭去村里赤腳醫(yī)生的工作，成為了一名市政府公務(wù)員，負責(zé)鄉(xiāng)鎮(zhèn)環(huán)衛(wèi)工人的管理工作。在全新的崗位上他依舊出色，且為了改善自己工人的工作狀況，父親還發(fā)明了一種低成本的掃路機?，F(xiàn)在這項掃路機已經(jīng)申請了專利。而父親，是一個根本沒有學(xué)過機械的人，他用自己的成績告訴我們，多替別人著想并不會吃虧。父親更加身體力行，即使是自己不喜歡的工作，既然在這個崗位上，就一定要做到最好。

這20年間，父親一直不輟鉆研中醫(yī)，理所當(dāng)然地成了鄰里鄉(xiāng)親的家庭醫(yī)生，也有鄰里鄉(xiāng)親介紹來的親戚朋友，甚至有專程從哈爾濱前來求醫(yī)的。父親說自己不是掛牌的醫(yī)生，所以從來不收費。如今就快要退休了，政府單位的工作也成了閑職，父親在家里辟出一間屋做診室。我這次春節(jié)在家，前來就診的人也是絡(luò)繹不絕。

想做什么，想學(xué)什么，只要開始并且堅持，永遠都不會太晚。到如今父親已經(jīng)找到了許多常見病的根治辦法（中醫(yī)方法），比如偏癱和面癱，鼻竇炎，過敏性鼻炎，扁桃體炎等。憑我有限的了解，只能列舉這些，實際當(dāng)然遠遠不止。昨天打電話想問問爸爸還有些什么，我想寫到作文里。弟弟接的，弟弟說，爸爸不說，爸爸就是臉皮薄。：）

 

不得不說，在自動化測試研究的工作中，確實學(xué)到了很多。除了測試技術(shù)之外，更多的是在業(yè)務(wù)，還有對于工作流程的一些思索。

自動化測試的測試管理這一塊，一開始的時候先是想用TD(TestDirect測試屆很流行的一款測試管理軟件，比較成熟，包括測試需求、計劃管理，Bug管理，報告生成等)的，QC（Quality Center，其實和TD是一家，目前TD已經(jīng)不再升級了）直接淘汰，主要是目前為止，我還沒有看見過unlimited的破解碼，而沒有看到效果直接讓公司掏錢買當(dāng)然更不合理。

經(jīng)過仔細評估，TD也淘汰了。因為我們CCI的工作流程已經(jīng)非常成熟，早就有了一整套的開發(fā)測試的工作流程，也有管理bug的軟件。所以自動化的測試管理實際上CCI已經(jīng)做到夠用，當(dāng)然從長遠來看，有一個穩(wěn)定且強大的自動化測試管理系統(tǒng)是非常必要的。而目前改革的必要則不大。不要為了自動化而自動化，就是這個道理啦！

需要進行自動化測試管理的范圍最終縮小在回歸測試，這是測試工作最辛苦的部分?；貧w測試需要保證測試環(huán)境的穩(wěn)定，保證新增功能正常，還要驗證舊的功能，主要原因是在于永遠都是一個非常緊迫的Deadline，枯燥而又緊張，能否充分測試是個永遠的問題。不光是在我們部門，整個測試界都為之頭痛。而我考慮這個問題也真的是很久很久了，假期的某一天我突然想到，為什么不用開源的工具來為CCI的回歸測試定制一套自動化的管理工具呢？

這樣做的好處有很多，首先是免費，因為免費，公司就不需要承擔(dān)用盜版軟件侵權(quán)的風(fēng)險，也便于給其他的部門推廣；第二是開源，因為開源，就可以定制真正適合我們的管理工具；第三還是開源，使用的時候有什么問題，或軟件有Bug，都可以通過改寫調(diào)試來解決。

我同樣考慮了這樣做的風(fēng)險，最大的自然就是技術(shù)上的，能不能找到合適的開源軟件是第一個問題，畢竟開源的工具不會像主流的商業(yè)工作做得那樣完善。能不能去改代碼適應(yīng)我們是第二個問題，如果將來多數(shù)的功能沒有現(xiàn)成的全部要自己來寫，成本會不會太高？至于第三個也是最關(guān)鍵的問題，在CCI使用后會不會有我預(yù)期的效果，我倒是不太擔(dān)心，如果不好用，就沒有使用的必要了，最差也就是維持現(xiàn)狀。所以我覺得還是值得一試，只要遇到問題盡最大努力去解決。

再下面我就仔細考慮回歸測試中的具體問題了，以爭取在后面的工作中能夠全部或者大部分的改進。在這里再一次給大家推薦“思維導(dǎo)圖”的方法，和很多同事分享過，這一次我又使用這個方法快速地鎖定要解決的問題。畫了好多，經(jīng)過篩選，按照角色挑出來三個主要問題：

1、測試組長：現(xiàn)階段回歸測試的任務(wù)管理是測試組長獨立承擔(dān)，通過發(fā)送郵件給大家分配工作；工作進行后會通過詢問跟進每個人的完成情況，了解存在問題等；全憑組長的責(zé)任心記清問題，提交給相關(guān)人員解決。弊端顯而易見，耗時，費事，任務(wù)較繁重時難免焦頭爛額。

2、網(wǎng)管：要保證測試環(huán)境的穩(wěn)定真的不是一件輕松的工作，特別是我們這樣一個功能完善的系統(tǒng)，有這么多人使用，有些配置被改動可能就會影響正常的測試；回歸測試中很常見這樣的情況，一個又一個測試工程師給網(wǎng)管說，“給我看看XX配置，我等著測哪！”“那個XX功能還沒好，先給我看看好不好？”“啊，那個功能改好了，怎么不告訴我一聲，等半天了。”同樣的，如果配置不穩(wěn)定，網(wǎng)管的工作效率很容易成為整個回歸測試的瓶頸。

3、項目經(jīng)理：需要了解進度時也是通過詢問的方式；還有如果測試組需要項目經(jīng)理協(xié)調(diào)解決一些問題時，同樣是詢問。

將測試工程師排除出來不是說沒有問題，而是1，2，3已經(jīng)包括。針對1，需建立測試計劃分配、以及任務(wù)跟進的機制。針對2，需要包括任務(wù)優(yōu)先級定義設(shè)置；針對3，需要建立自動生成測試進度報告；1，2，3都需要建立自動通知的機制。

 

(歡迎繼續(xù)關(guān)注下篇 實踐篇) <<士兵突擊>>看完了，每個人身上都有一些值得我們學(xué)習(xí)的東西。
 
喜歡許三多的堅持不懈。鐵棒磨成針就是說的他吧。
 
喜歡史今的對自己人生負責(zé)。我猜他復(fù)員回家一定是和他的那個生離死別的可愛同桌在一起。
 
喜歡伍六一的挑戰(zhàn)自我，他相信自己會活的更好！特別是放棄了一次之后的伍六一，他會在他的人生中有取也有舍得。
 
喜歡成才，喜歡成長之后懂得珍惜了的那個成才，有了失去，才有了再一次的爭取；有了年少的輕狂，和目空一切，才有了后來的沉淀、成熟、更加清晰目標的未來。
 
喜歡連長高城，當(dāng)7連被瓜分殆盡，他那么短的時間，煎熬中那么快速的成長。人無完人，要像他一樣，快速地發(fā)現(xiàn)自己的不足，快速地成長。

[

     摘要:   閱讀全文      摘要:   閱讀全文      摘要:   閱讀全文

今天發(fā)生一件事情很不爽。

因為服務(wù)器的原因，我提交的Test Case沒有更新，美國的工程師照著舊的Test Case將該單元fail了。

這件事完全由于我的失誤，作為一名測試工程師，一定要在Pass之前Confirm所有相關(guān)的內(nèi)容。

這應(yīng)該是最起碼的責(zé)任心。

 

之所以寫在這里，是我希望自己一定要記住這點，不要忘了！切記！

＝＝＝

2008年1月10日 追加

第二點，還是今天實實在在發(fā)生的哦！差一點犯錯～記??！
上一輪的回歸測試之中，發(fā)現(xiàn)了不少bug，有好多是serious的，
而這一個是medium的級別，開發(fā)工程師Confirm的時候，說是一個配置的原因
如果配置項修改了，就不會出現(xiàn)，所以不是bug。并且說他嘗試了多組數(shù)據(jù)，都沒有再出現(xiàn)。

于是我按照他說的，用了幾組數(shù)據(jù)來試，看上去真的是配置的問題。
因為在測試的時候，確實沒有注意到這個配置項是相關(guān)的。
幸好自己又多試了一組數(shù)據(jù)，只是一組，發(fā)現(xiàn)這個配置根本不起作用！??！
然后后面再試的，就是又證明了而已！原來這還是個bug?。?br /> 我都差一點給Close了！

于是跟工程師道歉，告訴他測試的時候確實沒有關(guān)注到這個配置項，他能給指出真是很了不起。
同時也跟他講，可能這個問題還需要我們一起進一步來研究看問題出現(xiàn)在什么地方，于是他很爽快地答應(yīng)了！！！

     摘要:   閱讀全文      摘要:   閱讀全文      摘要:   閱讀全文      摘要:   閱讀全文      摘要:   閱讀全文      摘要:   閱讀全文      摘要:   閱讀全文      摘要:   閱讀全文