使用Testlink进行软件测试
一、Testlink概述
TestLink 是基于web的测试用例管理系统，是sourceforge的开放源代码项目之一。作为基于Web的测试管理系统主要功能是：测试需求管理、测试用例的创建、管理和执行，测试计划的制定、并且还提供大量测试数据的度量和统计功能。
test link的创始人Ronak Shah是著名的软件质量策略师/经理，QA架构师，也是为全球500强企业提供数百种“优质”软件解决方案的专家。 他擅长使用他在团队建设、能力建设和CMMi流程设计与实施方面等方面的强大能力，从零开始在组织中建立，开发和管理独立的软件测试（QA）实践/部门。 他的领导才能和管理能力为他赢得了多个组织和尊敬的客户的好评，荣誉和嘉奖。 联系邮箱ronak.quality@yahoo.com。
二、Testlink工具使用流程
下面将对使用流程的各个部分做具体描述：
用户管理
在TestLink系统中，每个用户都可以维护自己的私有信息。在用户信息中，需要设置Email地址，如果用户忘记了密码，系统可以通过mail获得。TestLink系统基于六种角色，分别授予不同的权限，分别是admin、leader、seniortester 、tester、guest、testdesigner。相对应的功能权限如下：（详见图）
图1
Guest：只有读的权限，适合于查看测试用例和测试需求，以及项目分析的用户。
Testdesigner：可以开展测试用例和测试需求的所有工作。
Tester：只能执行测试用例。
Senior tester：可以查看和维护测试用例，并且可以执行测试用例，但是不能管理测试计划、分配测试任务。
Leader：可以开展测试规格和测试需求的所有工作，还可以管理测试计划、分配测试任务。
Admin：维护产品，用户。
同时，支持不同地域用户对不同语言的需求，可以根据用户的喜好对用户提供不同的语言支持。
用户也可以根据不同的需要创建新角色并赋予其特有的权限。
图2
测试需求管理
1）初次登录系统后，页面为添加项目页面，如下图：
图3
选中“启用产品需求功能”，该测试项目的主页将会显示产品需求区域。默认未选中。“活动的”：该测试项目是否是活动的。非管理员用户只能在首页右上角的测试项目下拉选择框中看到活动的项目。点击创建，即创建项目成功。
2）如果不是初次登录系统，admin用户可以在“主页”，可以点击“产品管理”－“测试项目管理”，在打开的新界面上点击“创建”按钮，创建新项目。
创建测试需求规格对测试需求规格的描述比较简单，内容包含名称、范围。
创建测试需求 测试需求内容包含：需求ID、名称、范围、需求的状态，以及覆盖需求的案例。 TestLink提供了两种状态来管理需求：正确的（Valid）、不可测试的（not testable）。
图4
如果一个产品有两个测试团队：系统测试和集成测试，而且这两个团队需要分享一些测试用例。应该给该产品创建一个测试项目，因为不同的测试项目不能分享数据。两个团队分别根据不同的测试需求规格创建不同的测试计划，从而得到不同的测试结果。
测试用例管理
在测试管理中，测试用例对测试需求的覆盖率是我们非常关心的，从需求规格说明书中提取出测试需求之后， Testlink提供管理测试需求与测试用例的对应关系的功能。
创建Test Specification Specification的内容包括：名称、介绍、范围、相关的内容、约束。
创建Test Suite Suite的内容包括：名称、测试范围和目标、配置信息、测试数据、测试工具
创建 Test case Case的要素包括：测试用例名称、简要说明、步骤、期望结果、关键字。
点击主页上的“测试用例”－“编辑测试用例”菜单，编写测试用例。如下图：
图5
建立测试用例和测试需求的覆盖关系。 选中左侧用例树中的测试用例，再选择右侧对应的测试需求，进行Assign即可。
测试计划制定
在TestLink系统中，一个完整的测试计划包括：
测试阶段的名称（如集成测试阶段、系统测试阶段）
里程碑（明确每个测试阶段的开始和截止时间，以及完成A、B、C三种优先级的比例）
Build版本（定义本测试计划中需要测试的build版本，一般以产品名+时间来命名。）
安排测试人员 （从用户列表中选择本测试计划的参与人员。）
图6
制定优先级规则：优先级分为A、B、C三级，系统会根据用户定义的重要级别和状态级别的组合来确定优先级的归属。重要级别分为三级：Low、Medium、High；状态级别有七种：draft、ready for review、review in progress、rework、obsolete、future、final；执行种类：手动、自动
从测试用例中选择本测试计划的测试用例集
设置每个测试用例Suite的重要级别和风险级别
测试执行
执行测试用例，按照对每个build版本的执行情况，记录测试结果。测试结果有四种情况可以选择：
Not Run：还没有执行过
Pass：执行通过
Failed：执行失败
Blocked：由于其它用例失败，导致此用例无法执行，被阻塞。
测试结果分析
TestLink根据测试过程中记录的数据，提供了较为丰富的度量统计功能，可以直观的得到测试管理过程中需要进行分析和总结的数据：
测试用例对测试需求的覆盖情况：哪些需求已经通过测试，哪些需求未通过测试，哪些需求处于阻塞状态，哪些需求还未开始测试。
图7
三、Testlink的优势和局限
TestLink 作为软件测试管理类开源软件中的佼佼者，在中小型的软件测试项目组中得到了普遍应用，项目组的测试效率得到了很大的提升。在开发自动化测试框架时，基于 TestLink 进行二次开发是个很优秀的解决方案，它具有如下优势：
1.测试过程管理平台的统一：功能测试和自动化测试使用统一的平台。
使用统一的平台，可以避免测试工作复杂化。对于现有的在 TestLink 中维护的功能测试用例，如果需要执行自动化测试，很容易将其转化为自动化测试用例。在测试规约 Test Specification 页面，选择测试用例，编辑其执行类型 Execution Type, 由手工类型 Manual 改成自动化执行类型 Automated，并上传该用例的自动化测试脚本文件作为附件即可。
2.可以充分利用 TestLink 的现有特性对自动化测试用例进行管理。
比如，可以使用 TestLink 的版本管理特性，维护自动化测试用例的不同版本；可以使用 TestLink 的结果报表特性来展示自动化测试执行的结果报表。还通过扩展，借助 SOAP、REST、XML-RPC 接口，可以与第三方开源缺陷管理工具、项目管理工具进行集成，比如 Bugzilla、MantisBT、JIRA 等等。
下图是使用 TestLink 管理自动化测试过程的流程图，它包括自动化用例维护和自动化用例执行两部分。
自动化测试用例维护部分的流程图包括：
•对 TestLink 上的功能测试用例做规划，决定哪些应该被自动化执行。
•编辑其执行类型，改为自动化测试用例。
•编写自动化测试用例的脚本。
•脚本文件的编写依赖于自动化测试工具，在本文中，自动化测试用例脚本文件是业界流行的基于 XML 格式的文件，该脚本文件可以被基于 Selenium 开发的自动化测试框架识别，关于该框架请参考 IBM DeveloperWorks 文章《使用 XML 维护 Selenium 自动化测试脚本》。
•自动化测试用例脚本上传。上传自动化测试用例脚本文件到测试用例的附件部分，就可以使用 TestLink 来维护自动化测试用例的脚本文件。
•完成全部的自动化用例脚本的编写，并把脚本文件上传到 TestLink 自动化测试用例的附件部分。
•创建测试计划，把自动化用例添加到测试计划中，完成测试用例的维护。
TestLink 也提供了为测试用例设置执行顺序的特性，读者们可以根据自己项目组的实际情况进行设置。
自动化用例执行部分的流程包括：
•选取测试计划、维护构建信息，获取要执行的测试用例信息。 TestLink 中，测试用例的执行就是为测试用例标记测试结果信息，包括是否执行通过，额外的描述信息等。在执行之前，需要设置执行依赖的版本构建信息。在 TestLink 管理自动化测试时，需要首先通过 TestLink 的测试计划信息，自动化的获取该测试计划包含的测试用例信息，进而获取测试用例的脚本文件信息。
•下载测试用例的脚本文件到本地。
正如上文所述，在 TestLink 中，测试用例的执行仅仅是标记测试结果信息。测试脚本文件的具体执行需要依赖第三方自动化测试工具。需要预先把测试用例的测试脚本文件下载到本地以供自动化测试工具自动调用执行。
•执行下载到本地的测试用例脚本文件。
把下载到本地的测试用例脚本文件位置作为参数传递给第三方自动化测试工具，完成自动化测试用例的具体执行任务。执行完毕，生成测试结果信息。根据项目组使用的不同第三方自动化测试工具，灵活处理该部分，本文不再赘述。
•完成测试计划下包含的全部自动化用例脚本的下载与执行，生成测试结果信息。•向 TestLink 回传测试用例的执行结果。通过编程，自动化地完成标记测试用例的结果。完成该部分，就可以利用 TestLink 的结果报表模块查询分析测试结果。
局限：
但是，Testlink作为一款中小型团队使用的测试管理工具，并不尽善尽美。
•对于有的系统来说，Testlink不能很好的兼容。
•对于想要迁移到Testlink的团队来说，迁移的过程会花很多的时间，尽管给出了迁移的功能，但是却只能通过XML格式的文件来迁移
•在Testlink中，只有测试用例执行过后，才可以改变状态（如pass、fail或者blocked）。
•与缺陷跟踪工具集成并不容易，因此很难将缺陷与失败的测试用例联系起来。
四、 工具的改进
经过对Testlink初步的了解之后，觉得此软件存在一些可以改进的地方，大概如下：
- 测试用例的执行必须关联测试计划，而测试计划的定义太简单。一个测试计划包括创建测试计划和版本管理，在创建测试计划的过程中，需要说明的就是“名称”和“描述”，而单单这几个字太过简单，初学者根本不清楚要填写什么信息，改进的方法就是将定义描述的详细点。
- 和非测试人员的相关性不高。比如，开发人员不能查看bug对应的用例信息，如果测试人员用的测试用例存在问题，而开发人员不知道，那么修改起来就会大费周章，改进的方法就是将一些信息的查看权限扩大点。
- 只能覆盖测试用例的范围。如果当测试人员按照测试用例执行测试的过程中出现问题时，就没办法继续执行测试。改进的方法就是管理好探索性测试模块，让测试人员能够在测试的过程中改变策略。
- 测试用例和自动化测试脚本无法建立对应关系。自动化测试脚本可以大大减少人工测试的繁杂度，而且可以解决测试用例维护难的问题，改进的方法为将测试用例和自动化测试脚本建立对应关系。
五、 人员分工
1.第一组：吕德品负责人员的安排、文件的检查，并向其他人提出修改建议，和成员沟通协调，同时负责每日博客的发布，作业的提交。
2.第二组：黄攀和郝陆风同学负责testlink使用视频的录制。
3.第三组：黄云洁、陈朔涵、赵岸伟负责testlink项目管理工具的使用介绍文档的编写。