一個好的 Bug Report 應該要提供明確的資訊，可以讓 Developer 快速重視問題，減少分析問題的成本。而管理階層的人從報告可了解問題的嚴重性，進而決定解決這個Bug時間表。

Bug Report 應該要有的欄位

1. 標題
   說明要明確，直指問題核心，說明問題發生的模組

不好的標題: 照片無法上傳
比較好的標題: 當照片尺寸大於10MB，手機無法使用自動上傳照片

1. 問題重現步驟(Steps to reproduce)
   除了要找出可以重視問題的Steps之外，還要盡量縮小(narrow down)步驟，找出重現問題的關鍵步驟。通常最後一步會寫"預期的結果"(expected result)，實際發生的結果有什麼不同。

   1. 安裝 APP
   2. 使用 Google 帳號登入
   3. 點選登入按鈕
      預期結果: 登入成功，進入活動列表
      實際結果: 登入失敗，出現伺服器連接錯誤

2. 嚴重性
   Blocker: 產生無法使用，要立即解決，像是產品無法安裝
   Criticl: 嚴重的問題，需要儘早解決
   Major: 重要的問題，需要在產品上線前解決
   Minor: 次要的問題，不一定要解決，有列入已知問題(kownn Issue)的空間
   Trival: 不直接影響使用者使用，像是打錯字，等等

3. 問題發生的版本號

4. 發生的頻率
   每次/常常/偶爾/很少

5. 附件: 錯誤畫面的截圖，相關Log檔案以及任何可以幫助分析問題的檔案

一些原則

1. 如果測試一次發現多個問題，不要把多個 bug 寫在同一筆issue裡，分開一筆一筆記錄，這樣才可以獨立被解決跟驗證(Verify)
2. 確認這個 bug 是否已經記錄過了？ 不要重覆發。

Bug Workflow

這是一張在網路上找到一個比較簡單的 bug workflow

1. Install JRE 32-bit

2. Install Sikuli

   https://launchpad.net/sikuli/sikuli-api/1.0.0/+download/Sikuli-IDE-1.0.0-Win32.zip

3. Set Environment

   JYTHONPATH=C:\jython2.5.1\Lib;C:\Sikuli-IDE-1.0.0-Win32\sikuli-script.jar\Lib CLASSPATH=C:\Sikuli-IDE-1.0.0-Win32\sikuli-script.jar PATH=C:\Program Files\Java\jre7\bin;C:\jython2.5.1\bin;C:\Sikuli-IDE-1.0.0-Win32\libs SIKULI_HOME=C:\Sikuli-IDE-1.0.0-Win32

4. Sikuli sciprt

example:

from sikuli.Sikuli import *
doubleClick(r"C:\siku.sikuli\1370345639170.png")

Install Sikuli-IDE on Ubuntu 12.04

sudo apt-get install sikuli-ide
sudo apt-get install libopencv-*

Reference :

• [Installation Guide] RobotFramework 2.7.4 + Sikuli + DatabaseLibrary +SSHLibrary …

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 …

測試的重點

軟體測試在敏捷化開發一定會遇到的問題，就是原本很可能都是以“週”為單位完成的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 …

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 (意指︰在缺乏資源的情況時，會有清楚的目標；銀彈不足，才會想辦法彈無虛發 …

Install required packages

$ yum install perl* httpd* mysql-server* mod_perl-devel -y

Download the latest bugzilla 4.2.2 (2012/8)

$ cd /var/www/html
$ wget http://ftp.mozilla.org/pub/mozilla.org/webtools/bugzilla-4.2.2.tar.gz
$ tar zxvf bugzilla-4.2.2.tar.gz
$ mv bugzilla-4.2.2 bugzilla

Start mysql server

$ service mysqld start

Set mysql root password via mysql_secure_installation**

$ sudo /usr/bin/mysql_secure_installation

Create a DB for bugzilla mysql login with root

$ mysql -u root -p

> CREATE DATABASE bugs ;
> exit

Run checksetup script to find needed modules

$ ./checksetup.pl

Install required modules

$  /usr/bin/perl install-module.pl &ndash …

之前讀了一本軟體測試的書《贏在測試》，裡面主要以訪談的形式來訪問中國界的軟體測試界的前輩，像是Google的段念，IBM的陳雅麗等。詳細誰講了什麼，我記不清了。但是裡面有前輩提到做軟體測試的人很容易忘了讓自己持續的進步，而漸漸地失去競爭力。這也難怪，因為做軟體測試畢竟永遠不是公司內最核心的研發主力，普遍來說技術水平比開發人員要求來得低一些。

之前讀到一篇James Bach老兄的文章，覺得還不錯。James Bach是軟體測試界的名人，他最著名的就是在Exploratory Testing的貢獻。有一位軟體測試的菜鳥問他說軟體測試工作者的每日家庭作業是什麼。Bach提出了四點：

Write every day

隨身帶筆記本，隨時記下任何對測試的想法

Watch yourself think ever day

工作時，當有任何測試的點子，嘗試去追蹤自己的想法。這是一種訓練Self-observation的方法

Question something about how you work every day

問問題，例如：何時需要寫下一個測試，那些步驟需要被記下。而不是只討論那些案例"Passing"或是"Failing"

Explain testing every day

解釋測試方法(Methodology)，不要只說自己在做黑箱測試，更深入些，並解釋為什麼你去做？

我相信更了解測試案例的分類，可以加速測試案例的設計與開發，並且讓開發人員對於測試目標能更了解。一般而言，測試案例種類至少可分成以下幾種：

• Release Acceptance Test(RAT)
• Functional Acceptance Simple Test(FAST)
• Task-Oriented Function Test(TOFT)
• Force-Error Test(FET)
• Boundary Test
• Volume Test
• Stress Test

之前在學著開測試案例的時侯，前輩有教過各種測試案例種類的差別。網路上也有一些文章討論。最容易讓人分不清大概就是RAT和FAST的差別了。RAT跟FAST都是Acceptance Test。就字面上的意思的確讓人很容易分不清。對我而言，其實測試案例就分成兩類，一種是測正常軟體正向的Test case，或是測試Error handle的FET兩種。然後測Positive Test Case 又依照不同的屬性又可以分成 RAT、FAST、TOFT、Boundary、Volume、Stress。但由於一個軟體建構出來之後。一般而言，皆需通過測試案例的測試，才代表其品質有一定程度的保障。然而，什麼先測，什麼後測？當然是重要的先測。而重要性粗分的話，大概可以分成：

RAT > FAST > TOFT = Boundary = FET > Volume = Stress 

RAT是用來評斷這個Build是否能被測試，在某些流程中，如果RAT Test cases Fail的話，QA人員可以要求不要測這個Build，繼續測試之前的Build。因為這個Build存在著重大的Defect，無法進行接下來的測試。所以RAT Testcase理論上數量應該很少，例如安裝的部份就一定至少會有一條RAT，畢竟如果軟體都沒辦法安裝起來的話，接下來就沒辦法測試了。

FAST可視為某個Module最重要的TestCase，如果不能Pass的話，很可能就會影響到接下來TOFT沒辦法繼續測試。所以可以把某個Module當中最重要的幾個Testcase挑出來當成FAST。 TOFT基本上只要不是被拿去當RAT跟FAST的Positive Test Case的剩下就可以當Test Case。FET是故意製造出一些情況讓程式出錯，測Error Handle是否有處理得當的Test Case，這種TestCase通常可以找到不少的Defect，因為畢竟Developer會比較容易忽略一些Error Handle Boundary Test專測一些臨界情況 …