Category: Working

算算上篇關於工作的文章《進階測試人員》也十天之前，扣掉假日有八天我都在與那兩張票奮戰…囧rz 花這麼多時間竟然還沒有搞定是怎麼回事？對整個系統前後端運作不熟悉，很慘。 經過這麼多工時，多少瞭解到兩張票的原因： 前端的設計當初沒有想到後來新加進來的功能，某些階段的測試並沒有發現這樣的錯誤或沒有將這樣的測試案例放進去。 新加的功能讓原來的某個功能模式變得不太一樣，結果就與原來的預期有差。 但，仍然想不出來怎麼解…（默） 週五下班時這樣碎碎唸： [work] 有頭緒還是搞不懂，是說不能同時搞兩個問題，下禮拜先專心搞定一個問題先，要是修第二個第一個也有問題再回來？唉… #

很久沒有寫工作上面的事情，一方面是沒什麼特別，產品一個版本一個版本慢慢地做，新功能沒有特別多。為了讓它可以適應新版伺服器或是新標準，修修改改補這邊修那邊，時間就這麼過去。 測試人員的工作就是蹂躪產品（進行測試），期望在不同階段透過不同測試把問題都找出來，免得到時候讓客戶回報錯誤就很虧。 讓我想寫文的起因是最近被開兩張票（臭蟲回報、ticket…），符合工作流程的內容： 問題簡述 回報給哪個元件 開給誰…（掩面） 哪個產品版本 測試環境：伺服器配置、平台與語言，登入用帳號密碼 如何重現（recreate）的步驟 期望結果應為何 Log 檔案 應該有足夠資訊讓開發人員去找出問題在哪裡？而問題就在於「太多資訊」…囧rz 附上的 log 檔案共有 110 個檔案，大小為 14.8MB (15,548,509 Bytes)。這代表什麼？若以純文字檔案一行 80 個字元，那代表著將近 20 萬行。 原因出現！（好久）測試大爺您行行好，您要我看 20 萬行程式碼還 OK，至少它有結構可以跳著看。20 萬行以時間順序進行的 log 檔…有等於沒有啊啊啊啊～ 剛開始從事測試工作時，會這樣做很正常。測試人員不是開發人員，技術領域與開發人員不一樣，這就是標題為何要加上「進階」二字。 就以往也曾進行過測試工作的經驗，簡略地把測試人員劃分一下： 初級的測試人員會模擬各種可能的環境、規範內（或規範外）的操作，把自己當作客戶來對產品進行測試，並回報。 進階的測試人員在回報時，會回報對開發人員有用的資訊而非資料。 如果我是測試人員，我會重複地「重現」該問題發生的動作，以篩選出靠近問題發生點的 Log 檔案們。依據以往經驗，可以從幾十萬行縮減到幾千行 Log，甚至可以馬上跟開發人員指出哪裡有問題。 那…開發人員碰到這樣子的例子呢？只好摸摸鼻頭，忽略那些 Log 檔案，從重現步驟開始做吧！XD 歐～我得先去搞懂那個環境的配置操作…Orz 後記一：最後採取另一個方式，說明 log 檔案資料太多的情況，請測試人員清除後重現問題。XD 後記二：然後拿到的是 23 個檔案 12.9MB (13,627,392 Bytes) 的 log（默）…看樣子體積極大的…

替文章想標題不容易，妥協後以手法稱之。 身為公司主管（所謂「經理人」）的角色，有時候為自己的利益所做的某些行動，其實有相對好的方式以避開落人口實。 例子一： 公司於勞退新制後已將薪資制度改為可以看見拿到的就是那十二個月，沒有所謂年終這個名目。每年號稱會檢視該年業績狀況給予業績獎勵，至於標準如何無相關明文規定。 去年某日，員工信箱中收到一只公告，內容為受到公司獎勵的員工名單。而身為公司出資者（老闆，董事長，總經理）名列第一位… 例子二： 公司於週末舉行年度的吃吃喝喝盛會尾牙，老闆因業務因素未出席，也無幾位主管出席。員工最期待主管放送時間，最後只推拖拉了一位高層主管加碼數千元並抽出得主。 隔週上班日，該主管交待財會部門將該加碼獎金，自所謂餐費科目支出（抵扣）。該項報銷後再發給該位得獎員工。 具工作幾年經驗的人都知道這種事情在合理性上皆可執行，而其他？皆可自行判斷之。 只是同標題，手法拙劣與高明程度，抑或是臉皮厚度不同。

最近很少寫一些技術性的東西，剛好這幾天工作上解決一個問題，就順手寫一下。 產品安裝程式用 InstallShield 撰寫，最近發現 32-bit 安裝程式在 64-bit Windows 無法安裝在預設給 32-bit 用的 C:\Program Files (x86) 路徑下面，想當然是安裝程式把括號視為無效的字元給擋住。 修改了判斷用的正則表示式（Regular Expression）重新編譯之後丟上測試機器去安裝。Done! 通常，測試員在測試安裝程式的時候，會在路徑這種欄位輸入一堆有的沒的字元（有效與無效）做測試。其實，Windows 或 Linux 下面使用括號是有效的。 Windows 下頭無效的字元除了 ASCII/Unicode 1~31 編碼字母外還有引號（”）、小於（<）、大於（>）、管線（|）、Backspace (\b)、null (\0) 與 tab (\t)（資料來源為 MSDN – Path.GetInvalidPathChars Method (System.IO)）。 安裝程式在設計安裝案例時，當然希望使用者輸入比較正常一點的字元，例如只有大小寫、數字以及幾種符號，沒把括號納入。但…當初誰知道 Windows 64-bit 會來個 C:\Program Files (x86) 這樣的設計呢？XD