其他

原文發表於2009-01-13 11:17:42     自從上次“郵件門”事件之後，整個人一下子成長了很多，不再是以前那個剛出校門的毛孩子了。在這個過程中，看了很多書，很受用。         

       原文發表於2009-01-14 11:21:23          Bug這個名詞已經很老了，從網路上查到的資料：>>>>>> 1946年，Grace Hopper在發生故障的MarkⅡ電腦的繼電器觸點裡，找到了一隻被夾扁的小飛蛾，正是這隻小蟲子“卡”住了機器的運行。Hopper順手將飛蛾夾 在工作筆記裡，並詼諧地把程式故障稱為“bug”。bug的意思是“臭蟲”，而這一奇怪的稱呼，後來演變成電腦行業的專業術語。雖然現代電腦再也不可能

原文發表於2009-01-15 11:23:21          在介紹bug的光輝曆史的時候，不經意間給bug蒙上了一層神秘的面紗，彷彿bug是一個遙遠的神秘的事物，如同金字塔之中的種種。其實bug本身並沒有那麼神秘。          首先給出一個“官方”的定義，來自Ron Patton《軟體測試》：>>>>>>          至少滿足下列五個規則之一才稱發生了一個軟體缺陷（Software bug）：1）  軟體未實現產品說明書要求的功能2） 

      原文發表於2009-01-16 13:34:58    所謂“自訂”是指標對於當前很多軟體項目中沒有“產品說明書”或者沒有合格的“產品說明書”這類現實主義情形而言的。     在上一篇文章中介紹了bug的“官方”定義和個人見解，其中涉及到了“產品說明書”這個對於當前一些軟體項目而言尚屬理想主義產物的東西，在這篇文章中，我分享給大家的就是我之前所經曆的一個類似的項目經曆，當然也要獻給大家一些我的“偏方”。    

    原文發表於2008-12-02 13:28:36      Ron Patton在他那本著名的《軟體測試》中提到了“確認”（Verification）和“驗證”（Validation）這兩個概念：       確認：是保證軟體符合產品說明書的過程；       驗證：是保證軟體滿足使用者要求的過程。    在同一小節，Ron

原文發表於：2008-04-07 11:44:51 Ranorex可以提供簡捷的GUI（圖形化使用者介面）自動化測試，我們可以使用常規開發語言如C#，C++，VB.NET或者Python來編寫測試執行指令碼，也就是說我們不必要再專門去學一門新的預言來完成測試這項工作。如果使用rannorex，應用程式和網站的測試都可以變得簡單易行。 

原文發表於2007-12-15如需轉載請與譯者聯絡chdwu@bestreme.com英文源：http://www.wilsonmar.com/perftest.htm關於效能測試，你可能會比較關心將系統從超負荷運行中解救出來所需要的時間。我們先來介紹幾種效能測試的類型。容量測試主要關心的是我們在系統容量達到什麼程度的時候需要增加系統的資源以增加可支援使用者量（註：也就是確定系統可處理同時線上的最大使用者數）負載測試為IT系統提供了一種量化其在真實環境下承受能力的的方法，便於檢驗當前所提供的IT

  原文發表於2008-11-11 15:27:58近期做一個項目的{function onclick(){function onclick(){function onclick(){tagshow(event, '%D7%D4%B6%AF%BB%AF%B2%E2%CA%D4');}}}}">自動化測試，遇到彈出的dialog的處理。當時第一印象就是應該用{function onclick(){function onclick(){function

在《漫話ID》一文中，作者提出了一個問題：為什麼在ItemCreated事件中訪問ClientID會導致MyButton無法響應事件，事實上MyButton無法響應事件是因為他在用戶端的ID被改變了，而此文從UniqueID和ClientID入手，進行較為深入的探討，展示UniqueID和ClientID是如何產生的，在何時產生，並同時解答《漫話ID》一文中作者的疑問。為什麼有UniqueID和ClientID這個我想多數使用WebForm的人已經知道了，很大原因上是因為WebForm中存在著資

   原文發表於2009-01-12 10:58:12   “撞鐘”（做一天和尚撞一天鐘）應該是一種職業現象。作為一個新人，剛進入公司的時候，什麼都是新鮮的，外面的世界與象牙塔中肯定大有不同。在這個時候，由於人的好奇心以及剛出校門時那種雄心壯志的躁動作用的結果，你我他做事情很有激情。當一段時間（這段時間長短因人而異，少則一月多則數年）過去之後，人開始變得沒有激情，大多數人也是這樣變得平庸，也開始放棄自己當初的夢想，甚至開始嘲笑自己剛出校門時候那種雄心壯志是無知、幼稚。         

     原文發表於2008-12-09 22:35:43      在上一篇文章裡面我們介紹了的分類，舉例揭示了需求覆蓋率，語句覆蓋率，分支覆蓋率很條件覆蓋率這些問題，在這篇文章裡面，則主要介紹為什麼要千方百計來找“測試覆蓋率”。(關於上一篇文章，參見測試覆蓋率之一——測試覆蓋率分類)   

    原文發表於2009-02-01 12:04:11    在前面的四篇文章泛泛而談bug相關的一些問題，只能遲到這篇文章中開始介紹bug本身相關比較實用的知識。先從bug報告開始，Bug報告的洋名似乎比中文名來的順耳——Bug Report。     一般意義上的bug Report即是將所發現的bug整理歸納起來，隨著缺陷管理工具的盛行，這種報告類型的報告已經漸漸失去了意義，但是筆者還是要從這種類型的bug

       原文發表於2009-01-19 11:21:04    “做了不該做的”bug，到底是是測試人員“狗咬呂洞賓不識好人心”還是開發人員真的“好心辦了壞事”？用當今最流行的話來說，這的確是一個“糾結”的問題。          這兩種情形在實際的測試活動中都會存在，有些時候的確是測試人員急功近利或者太死板，險些扼殺了一個很好的idea；有些時候確實又是開發人員因為這種或者那種原因，別出心裁卻導致了畫蛇添足。         

      原文發表於2008-12-04 23:14:43     配置測試的概念比較常見，一般所指的配置測試分為兩類，即配置測試和效能測試中的配置測試。配置測試    如果所有人使用相同的電腦，相同的外設，或許我們就可以不提配置測試了，可是顯然這是不可能事件，所以配置測試成為了測試中一向不可缺少的內容。配置測試的測試對象在於硬體，可是對於硬體，我們所要考慮的內容也不少：    > 電腦（品牌機），各個廠家的品牌機的配置是千差萬別的，所以要小心    >

原文發表於2008-04-07 19:28:25 今天在試著用ranorex寫測試指令碼的時候遇到了問題，發現一個dll組件不能調用導致異常，在網路上搜尋發現三個版本的解決方案：方案一將XXXX.dll(提示找不到的組件)拷貝到專案檔夾中bin目錄下方案二把XXXX.dll(提示找不到的組件)拷貝到system32目錄下

前些天在CSDN上看到一個比較老的文章，討論的是.NET中資料繫結應用什麼控制項更好。在社區中我也看到有朋友問是否應該使用這些控制項的問題。我來說說我的想法。希望對新手有協助。先來看看主要的幾個資料繫結控制項的區別：Repeater, DataList, 和GridView控制項基於同樣的編程模型。同時，每個控制項又為著不同的目標而設計，所以，選擇合適的控制項非常重要。

   原文發表於2009-02-02 13:02:16    在上一篇文章中給出bug的一個樣本，簡單介紹了bug自身的一些常用屬性，如Bug ID、狀態、原因、指派給等。按照約定，這篇文章將介紹bug重現的問題，亦即bug樣本中的“描述”部分。          細心的讀者會發現，在上面的bug“描述”一欄中又增加了幾個用方括弧標記起來的標記，這是筆者在管理的過程中添加進去的幾個標籤。一個完整的bug描述如下： 描述[Test

    原文發表於2008-12-05 18:23:15    近期查看了一些關于敏捷開發，極限編程的一些資料。在敏捷開發中有一種比較出名的方式即TDD（Test Driven Development，測試驅動開發），這些都包含測試先行的思想。細細分析一下，發現其中有一些還是很有用的思想，也就是我今天要討論的問題，用“黑-白”流程來做單元測試。     其實這隻不過是一種古老的思想了，Ron Patton的那本著名的《Software

      原文發表於2009-02-03 12:41:12         Bug的優先順序是bug管理過程中必須考慮的問題。對於優先順序的劃分，不同的軟體公司有自身的一套制度，因此筆者介紹的也僅僅是自己比較喜歡的一種方式。         

  原文發表於2008-12-08 23:10:11       關於覆蓋率，網路上最常見的兩個詞應該是“率”（Test Coverage）和”代碼覆蓋率“（Code Coverage）。今天就來探探這兩個東西。   在測試裡面，一般會將測試覆蓋率分為兩個部分，即”需求覆蓋率“和”程式碼涵蓋範圍“。可以看到，程式碼涵蓋範圍其實是測試覆蓋率的一部分而已。其中，最常討論和關心的是”程式碼涵蓋範圍“，程式碼涵蓋範圍又分為程式語句和程式碼覆蓋，分支覆蓋和條件覆蓋。對於這些概念，我們逐個解釋。