In this post, I'll try to explain how to install Test link 1.9.3 on CentOS 6.2 step by step:

Using yum to install required packages

yum install mysql-server php php-mysql php-gd php-ldap

Modify /etc/php.ini to optimize php configuration for TestLink

session.gc_maxlifetime = 2400
max_execution_time = 120

Set up web server and mysql services

 chkconfig httpd on
 chkconfig mysqld on
 service httpd start
 service mysqld start

Set a password for mysql root user

 mysqladmin -u root password NEWPASSWORD

Add port 80 to iptables, Add the following rule into /etc/sysconfig/iptables

-A INPUT -m state --state NEW …

第一次使用HTC的手機，整理一下 New HTC One的相關資訊。感覺這隻真的不錯，全鋁合金機身，而且又是找五月天代言，正港的MIT，一定要支持一下。

剛拿到手機可以先做的事

• 檢查一下沒有沒縫。這隻採鋁合金外，有很漂亮的金屬質感，但是也造成上市初期的良率太低，而傳出多起接縫問題。據說五月後的貨這方面的問題少了很多

• 把舊手機的資料傳輸到新手機 HTC 傳輸工具 - Google Play Android 應用程式 把舊Android手機(支援2.3以上，不一定要HTC)的設定，照片，簡訊等資訊透過無線網路傳輸到NewOne。用官方的方法沒辦法用Pin碼自動配對成功，之後是用新一內建的App:設定精靈。並讓舊手機連到一個特殊的基地台，就Ok了。

• 查詢 IMEI 手機的身份證字號: 撥打 *#06#

• 查詢出廠時間: HTC Support 需要輸入的IMEI跟S/N可以在包裝盒裡面的貼紙找到

• hTC硬體功能測試(HTC function Test v4.01.04g): 撥打 ##3424## 可以測試hTC的各項硬體功能，建議可以先全部都測過一遍，檢查一下是否正常

• HTC 輕鬆上手

DIY

• 使用包裝盒製作底座 New One 送原廠底座!!! (第1頁) - HTC (Android) - Mobile01

特色

• BlinkFeed, 即時動態 隨心選擇 HTC輕鬆玩 - 新HTC One : 豬血糕篇 - YouTube
• Sense TV, 互動式節目表 HTC輕鬆玩 - 新HTC One : 娘娘篇 - YouTube
• BoomSound, 雙前置立體揚聲器 HTC輕鬆玩 - 新HTC One : 潮貴人篇 - YouTube
• Sense …

s Command

s(substitue) 指令是 sed 中最常用的，可以把文件中的字串替換掉。基本的syntax s/RegEx/SubEx/，例如 s/Old/New/:

$ echo 'this is old' > input.txt
$ sed s/old/new/ input.txt

這個sed指令可以把文件中的old字串換成new

sed 執行流程

sed不像一般程式語言有 variable 的概念，但是sed有兩個特別的buffer(or workspace)可以讓sed執行較複雜的工作。這兩個buffer稱為Pattern space和Hold space。sed執行是從input stream中，每次執行一行，流程大致如下:

1. sed從input stream讀一行的內容
2. 把換行符號(trailing newlines)移除
3. 把它放到pattern sapce
4. 執行指令(上面的例子就是s command把old取代成new)
5. 把換行符號(trailing newlines)補回來
6. sed 把結果印到 output steam
7. 如果還有input的話，就繼續執行step1，否則就結束

而pattern space在每一個迴圈都會清除，但是hold space則不會，可參考‘h’, ‘H’, ‘x’, ‘g’, ‘G’指令。

s 指令的其它選項

-e: sed script，可以連接多個 sed script，如果只有一個 sed script 則 -e 可以省略。例如: $ echo 1234567890 …

iconv 可以轉換編碼, 例如想把 big5 檔換轉到 utf8:

$ iconv -f big5 -t utf8 big5_input.txt -o utf8_output

測試的重點

軟體測試在敏捷化開發一定會遇到的問題，就是原本很可能都是以“週”為單位完成的Task。如果在一個三週Sprint的情況下，測試工作很可能都要變成以“天“為單位完成的Task，我們要如何能把大部份的測試活動都在短的時間區間完成！？如同 Scrum 大師 Mike Cohn 所說的，我們需要一個健康測試金字塔。把時間投資在對的測試活動上。

金字塔有三層，由下而上分別是 Unit Test ，Acceptance Test, GUI Tests。最上面不一定大小的 Manual Tests。這邊傳達的最重要的概念就是，我們應該盡可能地把時間投資在 Unit test 上，理由很簡單，因為 Unit Test 穩定度是最高的，而且最容易被執行。如果一個測試目標能在 Unit tests level 被處理掉的話，我們應該要盡量讓它們在 Unit test level 就發生。而當測試的 Scope 愈來愈大，測試的成本就會愈來愈貴，可能會由白箱測試變黑箱測試，所需要的測試文件就需要更多來傳達資訊。

很可惜地，大部份的測試團隊，剛好相反。投入了大量人力在 Manual tests 之上。也因為有大量的 Tester 在執行 GUI Test、Manual Test 所以 Developer 在相對少的資源下，就只能把大部份可以在 unit test level 就處理掉的任務直接讓給 tester 來完成。

金字塔 與 三隻小豬的故事

Patrick Wilson-Welsh 把這個金字塔比喻成三隻小豬的故事。有做過 GUI test 的人應該都知道，我們應該最後才做 GUI test，因為他最 brittle，最容易因為一點點的改變而讓測試不通過。所以 Patrick …

看了GTAC 2011 Opening Keynote: Test is dead時注意到這本書。查了一下，發現Amazon的高評價，就馬上買了Kindle版(0.99 Usd)來看。裡面有一些不錯的觀念，在現今軟體業 Startup 風氣盛行的年代，我想值得記錄一下。

什麼是 Pretotype

Pretotype 不是 Prototype 的筆誤。這個字是作者 Alberto Savoia 自創的單字。從 Prototype 衍生而來。pre 跟 pro 都有 earier, before 的意思。一般傳統上，我們常常為了證明一些點子是否可行，都會先用少量的成本投入，來測試看看是否值得再繼續投入下去，比如說原型(Prototype)，或是POC(Prove of Concept)都是典型的例子。但是Alberto覺得Prototype還是太貴了。能否有一些更快速，省成本的方法來驗證我們做的是對的它。因為找對的它來做是非常重要的，一些常見的統計數據告訴我們：

• 90% 的 Mobile App 不賺錢
• 80% 的 Startup 把投資者的錢賠了
• 80% 的 餐廳在一年內就關門大吉

所以，愈早知道是否是對的“它”，遠比把“它”做對來得重要的多。

失敗定律

絕大多數的新物事都將會失敗， 即使被完美無瑕地執行

所以，我們常常在做一些不對的事情而不自知。當然，這邊所謂的對或是不對，其實定義可以很簡單，就是指目標市場的接受度。但是如果市場不買帳，就算他做的很完美，終究會走向失敗之路。Pretotype 是一種讓我們可以少痛一點的方式，即早發見這其實是不對的。而不是花了大把銀子跟青春才發現這不是市場要的。Pretotype 是指一種介於抽象概念(Abstract concept)跟原型(Prototype …

安裝 JDK

CentOS預設的JAVA版本和Jenkins不相容，所以要改安裝 OpenJDK 。可以用 yum search 檢查應該安裝那一個版本: yum search openjdk 會有 java-1.6.0 跟 java-1.7.0 兩個版本可供安裝，在此我選擇比較新的版本：1.7.0： yum install java-1.7.0-openjdk -y

安裝 Jenkins

sudo wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins-ci.org/redhat/jenkins.repo
sudo rpm --import http://pkg.jenkins-ci.org/redhat/jenkins-ci.org.key
sudo yum install jenkins -y

設定 Jenkins

1. 修改 iptables : 打開 80 Port，編輯/etc/sysconfig/iptables，把下面的rule加到最後一條 iptables -I INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT

2. 讓 Jenkins 開機自動啟動 chkconfig Jenkins …

Why Testopia ?

最近想研究一些時下流行的測試案例(Test Case)管理系統，之前有稍微裝一下Test Link來玩看看。因為看到《How Google Tests Software》裡面有提到一點，就是在Gogole裡，如果自動化測試測試沒過的話，會直接自動新增一筆Bug Tacker給相關人員，可見其相當重視自動化測試的品質，讓Automation的Bug提升到跟Product Bug相等重要。這也讓我重新思考 Bug Tracking System 對於Automation們的重要性。所以這讓我注意到另一套 Test Case Management System: Testopia。我覺得Testopia最大的特色，就是他是一套Bug Tracking System: Bugzilla 的延伸套件。也就是如果我們採用了Testopia來當我們的測試案例管理系統的話。也就相當於能直接擁有一套 Bug Tracking System了。這成為我想玩玩看 Testopia 的最大理由 :)

安裝 Testopia:

要玩 Testopia 之前要先安裝 Bugzilla，關於 Bugzilla 的安裝，這邊有記錄，安裝 Testopia 其實很簡單，下載 Testopia 的 tarball file : 當下最新的版本是2.5版

1. 解壓縮︰ tar zxvf testopia-2.5-BUGZILLA-4.2.tar.gz

2. 把裡面的內容丟到 bugzilla 的根目錄，例如 /var/www/html/bugzilla

3. 執行 checksetup 的 perl 檔 : ./checksetup.pl

這樣就安裝完成了。

Testopia 的架構

Testopia 手冊裡面有一張圖很清楚地表達整個 Testopia 的架構 …

這套方法是記錄在《How Google Tests Software》 一書之中，我覺得蠻不錯的，分享一下︰

Attributes-Components-Capabilities(ACC) 是Google團隊使用的測試建模的方法，可以視為快速譔寫 Test Plan 的一種方式。據 Jame Whittaker 的講法，一份ACC的完成時間約為 10~30 分鐘，如果達不到，代表自己對於要測的系統不夠了解。

目前 Google 己經把這個方法實現在 Google Test Analytics (GTA) 這套系統之上，更棒的是 GTA 目前己經 Open Source 出來了，而且有一個公開的沙箱網站，任何人都可以上去快速體驗一下ACC的魅力。

ACC 內容

ACC主要的內容就是依照產品的 Attribute(特性), Component(元件), Capability (能力) 的三者，分別依照順序，一步一步來分析我們到底要測什麼，該測什麼，什麼要先測等等問題。下面分別介紹ACC三者的意義︰

1. Attributes: 產品的特色，是產品的形容詞。例如︰快，安全，穩定，好用。這個清單說明為什麼顧客要用我們的產品，而不是其它的競爭者的。

2. Components: 產品的元件，是產品的名詞。例如︰資料庫，通知系統，使用者..等等。這個清單列舉出整個系統中的元件，約10個左右為宜。

3. Capability: 產品的功能，是產品的動詞。例如︰分享照片給朋友，新增好友，收到朋友訊息通知。

關於 Attribute 跟 Componet，這邊書中是舉Google+為例︰

Attribute :

• Social: Empowers users to share information …

這本書的作者是在軟體測試界很有名的 James Whittaker，以 How to break xxx 系列跟 Exploratory Testing 聞名。這本是他在Google期間完成的著作。可惜他己經在2012年３月左右離開了Google，發表了一篇Why I left google/中文翻譯。從微軟到Google，最後又回鍋到微軟了。文中大體的原因就是Google把創新精神丟掉，而只專注在廣告上，不再是一家是以技術優先導向的公司。但是這些還是毫不影響Google在軟體界的王者地位。

Google跟微軟在軟體測試上的策略很不一樣。傳統上，微軟的開發與測試人員比例大概是１：１左右。小弟的公司也是如此。但是Google專職在測試的人員，就明顯少得很多。我想從本書找到，如果專職測試人員少的話，那麼整個軟體開發流程會變的如何？其實，微軟在2008年也有出一本拿自己公司名稱當招牌的測試書 How We Test Software at Microsoft，這本有點厚，之後找個機會來看。以目前軟體公司的發展看來，也許之後就會看到一本以 Facebook 為主角的測試書了。

Ch1. Introduction to Google Software Testing

• 在 Google，測試工作是由一個中央的組職稱為 Engineering Productivity 來負責。包含 Developer 跟 Tester tool chain, Release engineer 。從 Unit test 包到 Exploratory testing。

• Google 在2001年時，約有200位開發工程師，但是只有3位測試工程師，那時開發工程師就必需為自己寫的程試的品質負責。那時TDD跟JUnit才準備流行，所以測試主要以 ad-hoc 為主。

• James 常給人的忠告︰「不要顧用太多測試員工」，Larry Page︰「Scarcity brings clarity (意指︰在缺乏資源的情況時，會有清楚的目標；銀彈不足，才會想辦法彈無虛發 …