testlink是基于web的开源的测试用例管理工具，由于众所周知其免费的特性，所以其流行度还是比较高的，但是testlink本身有一些Bug和使用方面的不足，比如其用例导入导出只能是阅读性非常差的xml格式。所以如果有强大自我工具编写能力和内部版本流程控制要求高的公司不用testlink，我在华为工作期间，就没有使用过这套工具管理用例。
testlink的整体环境搭建我没有自己亲自操刀过，不过网上有很多的教程，大致浏览过一些文章，觉得基本靠谱，包括对testlink的版本进行升级时遇到的一些坑，网上都有说明。在工作过程中，testlink是公司使用的主要的管理工具，只从使用者的角度来对testlink的使用进行总结。
一个项目的经典的流程是这样的：
image.png
以该流程进行节奏划分，testlink本身具有需求创建，管理和测试用例创建，管理，执行以及执行完成之后的数据统计和简要测试报告生成功能。
创建测试项目
以一个独立的产品项目为划分，在testlink先创建一个测试项目：
image.png
-
进入创建界面：
image.png
-
项目创建的信息输入界面：
image.png
- 创建的测试项目如果是上个项目的继承的话，而且上个项目的需求和测试用例可以被本次的项目复用的话，可以选择"从已有测试项目创建"
image.png
测试需求管理
- 测试项目创建完成之后，可以进行测试需求的导入和编写工作了，测试需求是根据产品需求提炼出来的，测试人员从测试角度对整个产品进行宏观和微观分析得出的，既要完全覆盖产品人员已经明确写出来的产品需求，也需要符合没有写出来的常识性的需求，甚至还要考虑用户的使用习惯。
- 测试需求最好能够经过产品团队/开发团队/测试团队的评审，大家能够对测试需求的观点进行统一，而且在产品的需求或者产品的实现过程中相关需求发生了变动，测试需要积极跟踪到并更新到测试需求当中
- 通过testlink管理测试需求的步骤如下，在测试产品的主页，点击产品需求规格：
image.png
- 进入产品规格的管理界面,用户可以手动选择新建产品需求规格，也可以选择直接导入产品的需求，不过这个导入需求格式只有xml格式，testlink只是的导入导出的格式单一也是导致testlink不友好的一个原因吧。
image.png
- 手动选择“新建产品需求规格”，这里可以看到需求规范的类型有三个类型可以选择：条款/用户需求/系统需求
- 条款：我的理解是该产品需要满足那些法律条款或者和可以约定的一些条款吧。
- 用户需求：应该就是产品的面向用户的直接表达出来的产品需求吧
- 系统需求：应该就是整体的系统需要满足那些需求，比如整体的产品需要连续多少天不死机。
image.png
- 创建了需求规格之后，就可以细化对应的需求了，针对每个细化的需求需要设计多少个测试用例，界面如下：
image.png
image.png
- 创建需求的需要有清晰的标识，说明需求是哪种类型的需求，比如功能性的需求还是兼容性方面的需求
- 创建的需求有简练的标题，这个在测试方案阶段对应的需求标题就已经明确了
- 创建的需求是哪方面的需求，是功能性的还是界面上的，可以通过类型进行选择
- 创建的需求需要设计多少个用例进行覆盖可以进行明确，这个在测试方案设计阶段也基本上可以明确的，这就要求测试人员在写测试方案的时候需要很清楚整个产品的实现细节。
- 在需求和测试用例都编写完成之后，可以把需求和用例进行关联起来，点击对应的需求，在覆盖率中，填入对应的测试用例的编号。说实话，testlink的这个功能使用的频率还是比较低的，因为一切都需要手动去搞，对于大型的产品，有的测试用例好几千个，一个一个的手动去输入，真的是一件太枯燥的工作。
测试用例编写
- 测试项目的测试需求都录入完成之后，就可以进行测试用例集和测试用例的创建，编写工作了。
- 每个测试项目按道理说应该由测试项目负责人进行顶层设计测试策略和测试方案，测试方案中详细说明测试需求，测试范围和相关的测试用例设计方法，测试工程师可以依据项目的测试方案进行模块化测试用例集的创建和测试用例的编写。
- 也有的项目需求比较简单，比如本次的项目中，需求只有项目的一个评分规则，评分规则中清楚了界定了测试范围，那么本次项目的测试用例集就直接以评分规则的文档进行创建，简单直接。
image.png
- 上面的测试用例集根据评测标准划分，测试工程师可以按照评测标准进行测试用例编写，测试用例表写可以采用常用的黑盒测试用例分析方法进行测试用例设计，比如：等价类划分，边际值划分，场景分析等
- 编写测试用例的时候，可以同步指定测试用例的状态以及测试用例的级别，同时每个测试用例的摘要和前提都可以描述清楚
image.png
测试计划创建和执行
- 测试用例编写完成之后，开发发布测试版本转入到产品测试阶段时，测试就可以通过testlink创建测试计划执行对应的版本测试了。
- 测试计划创建界面如下:
image.png
- 输入测试计划的相关信息
image.png
- 一个测试计划可以包含多个迭代版本，这个迭代版本如果在一个内控流程非常好的体系中在产品开发之前会有清晰的界定，比如华为的过点制度，在某一个时间段迭代的版本是什么，实现了哪些特性等等。
- 对测试版本划分还可以有另外一种通用的划分方法，如项目的进展所处的阶段进行划分：单元测试/集成测试/系统测试/回归测试/验收测试。
image.png
- 而现在的公司的版本迭代过程还不清晰，所以我进行版本创建的时候，以产品转测试的日期为版本进行命名，默认进行的是系统测试。
image.png
- 产品的测试计划和测试版本创建完成之后，就可以针对某个特定的版本需要执行的用例进行添加/删除操作了。测试用例添加的时候可以制定到测试人员。
image.png
测试执行
- 测试人员点击左上角的游戏手柄图标就可以看到分派到自己头上需要执行的用例了。
image.png
- 测试人员在用例执行完成之后，可以直接标记用例的执行结果以及测试用例的执行用时。
- 测试用时统计作用可以辅助后续的自动化实现，自动化可以根据用例的执行时间选择需要自动化哪些用例。
- 测试人员在执行的过程中，发生了哪些和预期结果不一致的测试现象都可以记录到说明当中
测试进度和测试报告
- 通过testlink可以查看到整体的测试进度如何，使用说明都很简单，用户使用一次之后就知道如何使用了。
image.png
总结
testlink是开源的可扩展的测试用例管理工具，网上有很多指导用户如何部署testlink测试套的文档，也有很多指导用户使用的文档，用户使用起来确实挺简单。但是在使用的过程中，个人还是觉得testlink有一些不足。
- 需要手工管理，需求/用例需要手工管理，一条一条的导入，挺麻烦的。
- 适合小型或者中型的项目，原因同上面，需求和用例都需要手工一个一个搞，很考验测试人员的耐心
- 导出的用例格式很单一，批量用例的导出只能选择xml格式，单条用例的导出成doc文档时，格式相当难看。
- 报告导出的排版很难看，排版同用例的导出排版，十分难看，对于使用者来说就是鸡肋。
网友评论