小攻城師的戰場筆記

做了一個 Excel 2007 的範本 (*.xlsx)，原本這樣載入：
using (FileStream fsIn = new FileStream(strXlsTemplate, FileMode.Open))
{
  // open Excel
  HSSFWorkbook workbook = new HSSFWorkbook(fsIn);
  fsIn.Close();
}

重拾好久沒寫的 C#，連個 Oracle 狀況萬千，記錄一下。
 

故事是這樣：有個客戶給了我一個子網域（假設它叫 ap.veronica.idv.tw 好了），讓我放一個活動網站在上頭。隔了一陣子以後，客戶覺得這個子網域不夠望文生義，所以又設了一個子網域（假設叫做 coolsite.veronica.idv.tw），同時給我另一個空間，要我把網站複製一份過去，這麼一來如果 coolsite.veronica.idv.tw 運作有問題，他只要把首頁上的活動網站連結改成指向 ap.veronica.idv.tw 就好了。

過去都是透過資料庫備分，將客戶端資料庫主機的資料打包回開發端使用。但是從去年開始，客戶新採購的機器都已經是 SQL server 2008，但我手邊部分機器上頭執行的還是 SQL server 2005，若將 SQL server 2008 備分的檔案直接還原到 SQL server 2005，會發生新版中匯出的資料無法匯入至舊版的錯誤。
參考保哥的《如何利用「資料庫發行精靈」將新版 SQL 資料庫降級成舊版》，發現可以利用 SQL server 內建的工具「資料庫發行精靈」，將資料轉換成 SQL 語法（包括產生資料表、將既有資料串接為 INSERT INTO 語句以供還原匯入）。

這天第一個 section 要談的是測試概論與單元測試。雖然 VS 2005 & 2008 也都有測試的功能，但 VS 2010 增加了更多測試類型。
---------------------現場對話實錄的分隔線---------------------
「一般如果沒有專職的測試人員，都由誰來做測試？」
『PM!』
「對，因為這個時間點他最閒。XD
　那如果 PM 不測，會由誰來測？」
『User!』
「這最正確，台灣都是客戶用一用有問題寄信給你，
　那誰最不適合做測試？」
『工程師自己！』
「不錯嘛，妳很熟啊。」
『因為我就是 PM。XD』
「那剛剛那位 PM，妳們什麼時候開始測試？」
『程式寫完以後呀，我收到建構就開始測。』
「那你們開發的時間大概多久？」
『有一個禮拜也有一個月的耶。』
「那假設你們開發一個月，妳們大概會開發多久？」
『開發大約兩週，然後測試一週，沒問題就給客戶。』
---------------------對話結束的分隔線---------------------
上面的對話中隱藏了一個問題：一開始 developer 都挑簡單的 bug 修，但影響到核心的 bug 怕一改下去全都要改，所以都不動。
此外，有些 bug 不太容易透過自動測試測出問題來，比方說某政府機關網站，因為使用了 open source 的 CMS，版位與內容是流水號，有人就刻意使用不同的版位套用了其他版位中的內容，使得標題區塊與內容區塊看起來牛頭不對馬嘴。像這種問題用自動化程式很難測出，但專業的測試人員看到網址有 query string，就會手動去調整；顯然這個機關的網站在開發時，沒有配置專職的測試人員。
（我個人認為有配置也沒什麼用，因為回到上面講的──developer 都會挑簡單的 bug 改，這種東西測出來以後說不定 PM & developer 也一起睜一隻眼閉一隻眼。）
「如果測試測到問題以後，developer 修正了，那接下來會？」
『全部重測啊！』
問題來了：如果有 4000 個 test case，人家改一行你就重測一次，如果不是同一個平台或語系（假設要測 IE6~IE9 好了），實務上不太可能全部重測。所以在大型的測試流程會做 smoke test：先把基本的流程都測過，沒問題的話才進入下一階段的測試，不會做全面測試。
測試如果在期末才做測試報告，這種測試報告都是假的，因為已無法完整測試、徹底修復；屆時安全、效能、壓力、功能都無法確保。
有些大型系統，若將內容上線後才發現錯誤，損失就很大，所以很在意資訊系統的正確度。講師舉例來說：有一個賣票系統，在測試時只測了 login，沒有測完整的商業邏輯，以至於後端整個鎖死就掛點了。
測試案例應該要能夠累積、收集、整合。並且要弄清楚，到底測試案例應該怎樣才有代表性？比方說，每次 SQL server 升級時，都會辦一個舊版與新版相容的一日營，會請各家廠商帶自己的系統的錄製過來，其中有一家提供了一份很大的錄製檔，一執行就掛了，細看內容是一大堆重複的 insert。事實上，相容性是要把所有功能都執行一遍，而不是把一個功能執行很多遍，因此應該對每一個功能都列舉一兩個代表例，而不是針對一個功能，把所有想到的可能值都塞進去試玩看看。
（這讓我想到做水果的甜度檢測時把每一個蘋果都拿起來咬一口的故事……）
在 Visual Studio 設定測試：solution items -> "*.testsettings"，預設在 local.testsettings 是什麼都不測試的。
涵蓋程式行與區塊可以以視覺化的方式觀察出涵蓋率：如果測試的對象是原始碼，可以顯示出涵蓋的行數；如果測試的是 dll，則會顯示為測試的區塊；預設配色下，測試有涵蓋到的部分是淺藍色的、未涵蓋的部分是橘紅色的。
雖然不可能每一次都全部重測，但週期性的全部重測仍是必要的。
自動化測化測試：一定要先裝 TFS，才能使用 test manager，建立測試專案。測試人員要清楚描述自己的測試環境，developer 才能夠 build 相同環境、重現問題。
在使用 test manager 進行測試時，必須先連結到 TFS 建立一個 team project；一個 team project 上可以建置許多 test project。
測試案例可以在 Visual Studio 或 test Manager 新增，但其步驟無法直接在 Visual Studio 裡編輯，要在 Test Manager 才能設定。
在寫測試步驟時應該要寫每一個步驟的動作是什麼、期待的結果、實際的結果；要在 Test Manager 插入多筆步驟時，游標不可以停在 "動作" 的 cell 裡，要在外圍點一下（會顯示為選取該儲存格的虛線框），此時從 Excel 或他處複製多筆時才能夠一次貼上為多筆，否則會被貼進同一個儲存格之中。
在錄製網頁的測試時，如果不希望首頁或一些雜七雜八的東西被錄進去，可以先把環境設乾淨一點。最好不要讓雜七雜八的東西被錄進去，舉例而言，輸入帳號密碼 login 以後，瀏覽器問你要不要儲存密碼，如果你第一次有錄進去，那之後每一次重新播放這個錄製都會重播這個視窗，並且會等待你點選，以至於重播的內容就一直卡在那視窗上。
報表管理員大概每半小時收集一次資訊，所以測試完畢的結果要稍後才會送進去。
測試案例要寫到所有人都可以看得懂，並且寫得詳盡，比方說允入原則是怎樣的條件啦、怎樣才是正確結果啦，等等之類的。舉個講師在顧問案中看到的印度外包商來作為詳細與不詳細的例子，來比較一下：
    * 印度人的 test case: "開啟瀏覽器→在網址列輸入網址→按下 enter"...etc.，將所有動作盡可能拆解到最詳細，讓任何人都能在不會遺漏任何步驟的情況下重新執行一次。
    * 台灣人的 test case: "瀏覽這個網址"。沒了。
UI test 只支援 IE 7 up 還有 firefox 3，無法支援 chrome, safari 等瀏覽器。
規劃功能時要想像屆時如何測試；就算不能做 TDD，也最好有類似 TDD 的概念，在設計需求時順便思考如何測試。
有人形容 monkey test 是：「你給一千隻鍭子一人一台打字機，他們會寫出一本莎士比亞來。」自動測試想要給定亂數測試時，Visual Studio 的內建測試工具，可以讓我們定義邊界值後，所有的 input 在不斷隨意組合的情況下，把所有可能的情況都測完。
自動化最大的好處是可以迴歸測試、反覆執行。但自動化測試有盲點：我們通常不會去測試「測試程式碼」（比方 unit test 的 code），但測試程式碼本身可能就有 bug。
錄製會依照應用程式 process 執行的速度來運作，不會依照你實際錄製時的時間；例如，你等待了很久才輸入下一個儲存格，但是實際上在重播錄製內容時，test manager 會等到 UI process 運作完畢後立即進入下一個步驟，不會真的等候。如果希望系統在運作自動測試時可以等待一段時間可以在 CodeUI 裡增加 Playback.PlaybackSettings.DelayBetweenActions 這個設定。若是等一段時間無回應就想送出自動 time out 的訊號，則是設定 Playback.PlaybackSettings.WaitForReadyTimeOut。
Coude UI 會根據 *.uitest 的 XML 自動產生程式碼。如果直接手動改 *.uitest 的 *.vb，在補錄動作或移除動作時，剛才修改的 *.vb 又會被改回來，因為 Code UI 的 test code 是根據 *.uitest 的 XML 產生的，所以應該要透過 UI actions 編輯器去去修改 uitest XML。
自動測試無法完美錄製完整情形，例如：錄製計算機的使用，可以很正常地把所有步驟錄起來；但錄製在小畫家上繪製的曲線，它只存取頭尾的座標，所以曲線畫出來會變直線。
由於這兩天所講的課程中提到的東西，事實上在執行時需要太多 agent，若要一台主機就支援全部的工作，要在上頭同時裝 AD、裝 TFS 等等，記憶體至少要 8G（理想狀況下是 12 G 比較好），不然怕跑不動。
就胡老師顧問服務的公司沒有一間導入 unit test。所有的團隊開發，很難導入 unit test，因為要一群人做一件事情很容易意見分歧。
「網頁如果要求不能超過兩秒，那大家的技術會變很好，因為會有一秒的時間浪費在 IE，你的 DBA 要控制在 0.5 秒以內回應。 XD」
這時候有人問到如何調整網頁效能，胡老師的建議是：啟動 IIS 壓縮、viewstate on session (沒有 viewstate，減少回傳內容)。重點是，要讓測試環境變成可控制的，否則變因會太多，調整校能無法聚焦。
新增 Web 效能測試時要注意，若有啟動 IE 延伸安全的話，會無法錄製 AJAX（會出現「目前在 Internet Explorer 中已停用瀏覽器延伸...」的錯誤訊息），在不同的 OS，關閉 IE 延伸安全的方式都不同。
Web 效能測試是對網站送出 HTTP request，所以後端不一定要是 ASP.NET，也可以是 PHP 等其他語言撰寫的網站。
講師在錄製 google 的回應時，看到很多 HTTP 204 (No Content)，我拜了 Google 查到 josephj 寫的文章，看起來是一種 AJAX 的應用。
       
"回應URL的錯誤"：以今日範例而言，querystring 是帶一組具唯一性的訂單編號，因此前後兩次送出的 request 得到的回應會不相同，就會發出錯誤。若想忽略這個錯誤，可以把「預期的回應URL」刪除，或乾脆把這條 request 刪除。
在做測試時，可以設定各種檢證條件，例如：在幾秒內回應才OK、回應內容要包括特定文字...etc.
Web 效能測試也能 databind：先設定 data source，再把欄位指定為 data source 的特定欄位。data bind 也可以設定成特定格式，例如 NT$ {{DataSource1.Row.i}}，如果想要更進階的處理（例如，要為數字增加千分號），可以先把測試的 code 轉出來，或是把 data source 設定成一個 view（view 在欄位 select 時就將之設定成特定的格式）。
負載測試設計時要注意，必須要提出足夠大的壓力，但不要把自己操死、卻沒有得到壓測結果，例如：使用 Code UI 來測，光是 UI 的部分就把效能都耗光光了，根本沒有測到程式本身。為什麼不要用 UI？講師舉了個例子，在 SSMS 裡頭執行以下指令：
            set statistics io on
            set statistics time on
            select * from person.person
            select count(*) from person.person with(index(0))
在 MSSMS 下這樣的 SQL statement 做查詢，兩者的查詢成本是差不多的，但前者存取會花比較多的時間 (1647ms)、後者就只要 4ms，原因是因為前者要畫很多 grid 才能顯示資料結果，後者只畫一格而已，所以速度快很多。
「所以 UI 是很浪費的，你看好萊塢電影裡面用 3D 在破解密碼那種畫面都是假的，大概 99% 的效能都在畫 UI、只有 1% 在算密碼。XD」
在 msdn 可以下載 test controller，不過要注意一下，輸入 liscense 時要自己補 dash。
負載測試前要先有 Web 效能測試（因為負載測試是加入現有的 Web 效能測試來執行的），測試的報告會在「測試→管理測試控制器」。測試報告會存在一個系統建置的 DB，如果想調整儲存標的的話，也可以在[開啟和管理負載測試結果]調整 connection string。
Visual Studio 會在 Excel 裡安裝 Team Foundation Add-in，所以也可以從 Excel 的負載測試頁籤看負載測試報告。若執行了多個回合的負載測試，可以設定一個回合為基準、另一回合為比較，Excel 會藉由 Team Foundation Add-in 撈出來做比較。

「Visual Studio 2010 Ultimate 軟體開發生命週期管理實作營」就是以前的 VSTS 二日營，這份筆記是第一天 (2011/05/23) 的內容。
在 Visual Studio 2008 之前，Visual Studio 所提供的塑模工具只有 DSL。DSL 可以用來描述 IIS 設定等等內容，若是要繪製其他圖形，通常都會使用 Visio。一直到 Visual Studio 2010 才完整支援 UML。
沒有文件對溝通是不利的，即使你不需要和他人溝通，你也必須和未來的自己溝通。文件是最好的輔助，撰寫文件時只要達到可以瞭解的程度就好，不需要寫得過於鉅細靡遺。
若想描述多個專案之間的互動，可以使用「模型專案」。其中的「圖層圖表」與「有向圖形文件」是微軟自己的標準。
導入新技術不難，但導入團隊文化很困難。
可以在 UML 圖右鍵→「連結至工作項目」，設定與 TFS 的 workitem 的連結。但是 Visual Studio 2010 預設無法使用這個功能，要先安裝 feature pack。透過這個設定可以關聯需求來源、瞭解這個工作項由誰負責。
專案進行時，應該先發展文件、程式越晚開始寫越好。至少要先把 activity diagram 畫出來，以瞭解功能與功能之間的關聯。
《約耳趣談軟體》提到工程師們普遍有「寧可重寫也不要維護之前的系統」的心態，要減輕維護系統的痛苦感，最好的做法就是留下足資說明架構的文件。產生架構圖有兩種選擇，若選擇依組件產生，會依照專案來產生架構圖；若依命名空間產生，則是會將跨專案、擁有相同命名空間 (namespace) 的內容繪製在一起。
上課的投影片裡有展示一些 demo 影片，這些影片的來源是 MSDN 的 Channel 9。
Tier & tier 之間，最好是由上往下、或由前往後呼叫，如果有反向呼叫會相互牽動得亂七八糟，通常我們就會稱呼這樣的 code 是義大利麵式的 code。例如，我們應該從 business layer 去呼叫 data layer，但反過來就不是很適合。
Visual Studio 2010 之中，自己拉圖例進來繪製 layer diagram 時，如果遺漏了架構中真正存在的內容，可以利用「驗證架構」檢證出來，但是多畫的部分就不會顯示錯誤訊息。

今天的作業是寫 console 程式，要帶一些參數。可是如果只能在命令提示字元視窗輸入參數，就不方便進入 debug 模式了，我想要的是可以在偵錯模式中輸入參數。所以上網查了一下找到這篇："debug Console Application"。
1. 「專案(P)」→「屬性(P)」，或在方案總管視窗上對專案按右鍵→「屬性」。
2. 點選「偵錯」頁籤。
3. 在「起始選項」的「命令列的引數」，輸入你要提供的參數。
這麼一來，進入偵錯模式時，在 static void Main(string[] args){ } 裡面，args 就會被賦予剛才的值了。

剛才遇到一件很痛苦的事：在編輯泛型處理常式 (*.ashx) 時，無法把程式碼摺疊起來。在 Google 找到《視覺工作室 ASP.Net 展開和摺疊 ashx 泛型處理程序中的問題》：「工具 (T)」→「選項 (O)」，打開選項設定左側的「文字編輯器」→「副檔名」，新增副檔名 "ashx"、選擇對應的編輯器（我選 Visual Studio C#），按下「加入 (D)」，就完成了。
設定的畫面：
設定完成之後，程式碼左側就會出現可收摺的符號，方便摺疊大塊的函式、以利於閱讀其他程式碼。
 

透過程式操作 Word 物件，把值塞進去。可是在程式運行的過程裡，Word 視窗一直跳出來。雖然未來這個視窗應該只會出現在 server side，但總覺得怪怪的，所以想想還是把它關掉的好。找了一下，在這篇《是否可以在背景開啟 Word 文件》得到提示：要改變開啟檔案時的參數值。
這個參數塞得很裡面，在第 12 個參數。懶得記的話也可以看程式碼提示 (intellisence) 的參數說明。
' 欲開啟的 word 檔名
Dim oldFileName As String = "test.doc"
' Word 物件相關變數
Dim paramMissing As Object = Type.Missing
Dim wordApp As WORD.ApplicationClass = New WORD.ApplicationClass()
Dim wordDoc As WORD.Document = Nothing
' 在開啟檔案的第 12 個參數設定 false，表示不顯示應用程式
wordDoc = wordApp.Documents.Open(oldFileName, paramMissing, paramMissing, paramMissing, paramMissing, paramMissing,paramMissing, paramMissing, paramMissing, paramMissing, paramMissing, False, paramMissing, paramMissing, paramMissing, paramMissing)

有時候會寫一些讓系統發送 E-Mail 的程式，可是總不能每次測試大砲都直接發射吧？這時候在 Web.Config 做個簡單的設定，就可以把測試信留在 Server 的本機資料夾裡，避免測試發信動作時真的把信寄送到使用者信箱。
<!--在 Web.Config 找到 <configuration> 這個節點-->
<configuration>
    <!--在裡面增加 <system.net> 這一整段的內容-->
    <system.net>
        <mailSettings>
            <smtp deliveryMethod="SpecifiedPickupDirectory">
                <!--pickupDirectoryLocation 屬性的值就填寫想要存放測試信的本機資料夾。
                      **注意**必須先建立資料夾，
                            否則會拋出 System.Net.Mail.SmtpException 例外錯誤。-->
                <specifiedPickupDirectory pickupDirectoryLocation="D:\mailtesting" />
            </smtp>
        </mailSettings>
    </system.net>
</configuration>