$g_tpl [ ' tcView ' ]
$g_tpl [ ' tcSearchView ' ]
$g_tpl [ ' tcEdit ' ]
$g_tpl [ ' tcNew ' ]
$g_tpl [ ' execSetResults ' ]
配置
配置檔案
<testlink installation directory>/config.inc.php － 主要的配置檔案，後面會做詳細介紹
<testlink installation directory>/config_db.inc.php － 包含通路資料庫的所有配置參數。這個檔案在安裝或更新過程中産生。通常不必做手工修改
<testlink installation directory>/cfg/<bug_tracking_system>.cfg.php
/cfg/bugzilla.cfg.php
/cfg/mantis.cfg.php
/cfg/jira.cfg.php
包含通路bugzilla、mantis或者jira等缺陷跟蹤系統的配置參數。如果想從TestLink直接通路這些系統，需要手工修改這些檔案，另外這個功能需要在config.inc.php檔案中修改一個配置參數。
必須修改的參數
DB_SUPPORTS_UTF8
MySQL4.1以前的版本不支援utf8，是以所有的頁面使用ISO-8859-1字元集而資料則以latin1字元集存入資料庫，令DB_SUPPORTS_UTF8 = FALSE；
MySQL4.1及以後的版本，令DB_SUPPORTS_UTF8 = TRUE，使全部頁面支援UTF-8而資料以utf8字元集存入資料庫。
可能需要修改的參數
TL_LOG_LEVEL_DEFAULT
日志記錄的預設級别，日志級别有（NONE、ERROR、INFO、DEBUG）。DEBUG級别隻在開發或者與bug系統內建時使用
TL_LOG_PATH
日志檔案的檔案名和路徑
MAIN_PAGE_METRICS_ENABLED
這個參數控制矩陣表格是否顯示在首頁上，允許“TURE”和“FALSE”兩個值
TL_INTERFACE_BUGS
設定testlink和缺陷跟蹤系統的接口。允許的值為：“NO”、“BUGZILLA”、“MANTIS”
與BUGZILLA的接口配置參見cfg/bugzilla.cfg.php，支援0.19.1
與MANTIS的接口配置參見cfg/mantis.cfg.php，支援1.0.0.a3
TL_TREE_KIND
這個參數用于配置testlink所使用的樹形菜單，允許的值為“LAYERSMENU”、“JTREE”、“DTREE”
LAYERSMENU 是預設值；在這裡，JTREE的性能最好；其他的兩種樹形菜單，可以記住上一次的位置。
TL_IMPORT_LIMIT
最大可以上傳的檔案的大小，機關是bytes。預設值是200000。如果需要上傳一個更大的檔案，你可以加大這個值。另外還有一個參數：TL_IMPORT_ROW_MAX，使用者規定導出檔案一行最長可以有多長字元，10000字元已經足夠了。
$g_fckeditor_toolbar
TL_TPL_CHARSET
中文使用者隻需要設定：define('TL_TPL_CHARSET','gb2312')；這樣就定義了正确的html字元集。其他的語言可以不必修改這個參數
TL_DEFAULT_LOCALE
置預設語言，必須是$g_locales的一個值。預設值是en_GB。
TL_COMPANY,TL_DOC_COPYRIGHT，TL_DOC_CONFIDENT
用于文檔擡頭，如果不用寫擡頭，就置這些參數為空。
自定義參數
級聯樣式表
可以編寫你自己的級聯樣式表改變TestLink的外觀。
你必須修改以下定義：
define('TL_LOGIN_CSS','gui/css/tl_login.css'); - 登入、登出的CSS檔案
define('TL_TESTLINK_CSS','gui/css/testlink.css'); - 首頁的CSS檔案
define('TL_DOC_BASIC_CSS','gui/css/tl_doc_basic.css'); - 用于測試報告
重要：CSS檔案的路徑是相對于<TestLink的安裝目錄>的路徑，是相對路徑
如果要使用自己的CSS檔案，建議進行如下操作：
1. 在gui目錄下建立一個新的目錄，例如 “gui/css/my_css/”
2. 複制testlink原檔案到新的目錄
3. 按你的想法修改它們
4. 編輯config.inc.php檔案：
// Original configuration
//define('TL_LOGIN_CSS','gui/css/tl_login.css');
//define('TL_TESTLINK_CSS','gui/css/testlink.css');
//define('TL_DOC_BASIC_CSS','gui/css/tl_doc_basic.css');
define('TL_LOGIN_CSS','gui/css/my_css/tl_login_acqua.css');
define('TL_TESTLINK_CSS','gui/css/my_css/testlink_acqua.css');
define('TL_DOC_BASIC_CSS','gui/css/my_css/tl_doc_basic.css');
當産品、部件、分類、測試用例重名時的處理
當從一個已經複制一個産品、部件、分類、測試用例時，經常會發生重名的情況。
你可以配置如何處理複制：
如果你設定$g_check_names_for_duplicates=TRUE，那麼系統就會進行以下的檢查
1. 産品名是否唯一
2. 産品下的部件名是否唯一
3. 部件下的分類名是否唯一
4. 分類下的測試用例名是否唯一
一旦置$g_check_names_for_duplicates=TRUE，你可以配置如果進行操作，如果發現重名的情況，就使用$g_action_on_duplicate_name，選項如下：
'allow_repeat'：允許重名（可以和1.0.4、1.5.x相容）
'generate_new'：生成新名稱，将"$g_prefix_name_for_copy"的值和原名合并，成為一個新名字
'block'：傳回一個錯誤
例如：
$g_action_on_duplicate_name='allow_repeat';
$g_prefix_name_for_copy= strftime("%Y%m%d-%H:%M:%S", time());
允許重複，并将目前時間以（年月日－時分秒）的格式做為原來的名字的字首。
測試計劃和産品的關聯
從1.6版開始，當建立一個測試計劃（Test Plan）時，預設情況下測試計劃會和目前所選擇的産品相關聯。這意味着你可以以産品為關鍵字過濾測試計劃（Test Plan）。在1.6版本之前，Test Plan沒有和指定的産品相關聯，當從1.5.x更新到1.6時，安裝程式不能将測試計劃和産品相關聯進而将測試計劃的product ID項置為0。這樣做将導緻老的測試計劃将不能被看到。要解決這個問題，必須添加以下參數：
$g_show_tp_without_prodid=TRUE;
你也可以通過在資料庫中手工關聯，以便使用以前的資料。
通過産品過濾測試計劃
使用以下參數：
$g_ui_show_check_filter_tp_by_product
你可以：
允許使用者通過界面來使能測試計劃過濾功能。$g_ui_show_check_filter_tp_by_product = TRUE時，在測試計劃之前顯示了一個複選框。
$g_ui_show_check_filter_tp_by_product = FALSE時。強制測試計劃的過濾，并且使用者不能修改
關鍵字管理
如果不想為同一個産品建立相同的關鍵字：
$g_allow_duplicate_keywords=FALSE;
日期和時間本地化
設定日期和時間的顯示方式。使用兩個關聯的數組進行配置：$g_locales_date_format 和
$g_locales_timestamp_format.
$g_locales_date_format = array(
'en_GB' => "%d/%m/%Y", 'it_IT' => "%d/%m/%Y",
'es_AR' => "%d/%m/%Y", 'es_ES' => "%d/%m/%Y",
'de_DE' => "%d.%m.%Y", 'fr_FR' => "%d/%m/%Y",
'pt_BR' => "%d/%m/%Y" );
$g_locales_timestamp_format = array(
'en_GB' => "%d/%m/%Y %H:%M:%S",
'it_IT' => "%d/%m/%Y %H:%M:%S",
'es_AR' => "%d/%m/%Y %H:%M:%S",
'es_ES' => "%d/%m/%Y %H:%M:%S",
'de_DE' => "%d.%m.%Y %H:%M:%S",
'fr_FR' => "%d/%m/%Y %H:%M:%S",
'pt_BR' => "%d/%m/%Y %H:%M:%S", );
如果在上述數組中沒有找到比對的本地化格式，以下配置參數将被使用：$g_date_format 和 $g_timestamp_format
$g_date_format ="%d/%m/%Y";
$g_timestamp_format = "%d/%m/%Y %H:%M:%S";
從需求生成測試用例
在建立需求SRS之後，可以選擇為每個測試需求建立測試用例（部件和分類也同時被建立）
使用配置參數：$g_reg_cfg,你可以配置：
建立的部件的名字：$g_req_cfg->default_component_name="Component Created by Requirement - Auto";
部件的範圍：$g_req_cfg->scope_for_component="Component/Category/Test Cases generated from Requirements";
建立的分類的名字：$g_req_cfg->default_category_name="TODO";
分類的目标描述：$g_req_cfg->objective_for_category="Category/Test Cases generated from Requirements";
分類的名字可以作如下配置：
$g_req_cfg->use_req_spec_as_category_name=TRUE;
将需求名稱做為分類名稱
$g_req_cfg->use_req_spec_as_category_name=FALSE;
那麼$g_req_cfg->default_category_name将做為分類的名稱
使用自己的Smarty模闆（GUI定義）
使用自定義模闆，要用到以下參數：$g_tpl
允許建立新的模闆，而且新的模闆采用不同于原始TestLink模闆的名字，以避免在下次更新過程中被覆寫
注意：不是所有的TestLink頁面都可以進行這樣的配置
标準配置如下：
$g_tpl [ ' tcView ' ] = " tcView.tpl " ;
$g_tpl [ ' tcSearchView ' ] = " tcSearchView.tpl " ;
$g_tpl [ ' tcEdit ' ] = " tcEdit.tpl " ;
$g_tpl [ ' tcNew ' ] = " tcNew.tpl " ;
$g_tpl [ ' execSetResults ' ] = " execSetResults.tpl " ;