admin管理员组文章数量:1530909
2024年3月4日发(作者:)
User Manual
TestLink 1.6
Copyright © 2004,2005 TestLink Development Team
Permission is granted to copy, distribute and/or modify this document under the
terms of the GNU Free Documentation License, Version 1.2 or any later version
published by the Free Software Foundation; with no Invariant Sections, no
Front-Cover Texts, and no Back-Cover Texts. The license is available in "GNU
Free Documentation License" homepage.
1. General information
TestLink is web based Test Management system. This manual should serve as source
for users to understand processes and organization of testing with TestLink.
See to Installation manual for more information about system requirements,
installation steps and configuration. The latest documentation is available on
or .
See an example of TestLink workflow:
1. Administrator create a product “Fast Foo” and a user Adam with rights
“leader” and Bela with rights “Senior tester”.
2. Adam imports Software Requirements and for part of these requirements
generates empty Test cases.
3. Bela describe test sneario of these Test cases that are organized
according to Components and Categories.
4. Adam creates Keyword: “Regression” and assignes this keyword to ten
of these test cases.
5. Adam creates a Test Plan “Fish & Chips”, Build “Fish 0.1” and add
Test Cases with keywords “Regression”.
6. Adam and Bela execute and record the testing with result: 5 passed, 1
failed and 4 are blocked.
7. Developers make a new build “Fish 0.2” and Bela tests the failed and
blocked test cases only. Exceptionaly all these five Test cases passed.
8. Manager would like to see results. Administrator explain him that he can
create account himself on the login page. Manager do it. He has “Guest”
rights and could see results and Test cases. He can see that everything
passed in overal report ;-) and problems in build “Fish 0.1” in a report
for particular Build. But he can change nothing.
2. Overall structure
There are three cornerstones: Product, Test Plan and User. All other data are
relations or attributes for this base. First, definition of a couple of terms
that are used throughout the documentation.
2.1 Products and Test Plans
Product: A product is something that will exist forever in TestLink. Products
will undergo many different versions throughout their life times. Product
includes Test Specification with Test Cases and should be sorted via Keywords.
Test Plan: Test Plans are created when you'd like to execute test cases. Test
plans can be made up of the test cases of one or many products. Test Plan includes
Builds, Test Case Suite and Test Results.
2.2 Test Case Categorization
TestLink breaks down the test case structure into three levels components,
categories, and test cases. These levels are persisted throughout the
application.
Component: Components are the parents of categories. Each component can have
many categories.
Category: Categories are the parents of test cases. Each category can have many
test cases.
Test Case: Test cases are the fundamental piece of TestLink.
Test Specification: All components, categories and test cases within Product.
Test Case Suite: All components, categories and test cases within Test Plan.
2.3 Users
An User has a Role, that defines available TestLink features. See more in chapter
User Administration.
The next picture shows common activity according to user roles:
Illustration 1: Functionality overview
3. Test Specification
3.1 Creating Test Cases
Tester must follow this structure: component, category and test case. At first
you create component(s) for your product. You can fill description which can
be printed then. Component includes categories. Category has the similar meaning
but is second level of Test Specification and includes just Test Cases.
User can also copy or move Test Cases.
Test Cases has next parts:
Title: could include either short description or abbreviation (e.g.
TL-USER-LOGIN)
Summary: should be really short; just for overview.
Steps: describe test scenario (input actions); can also include
precondition and cleanup information here.
Expected results: describe checkpoints and expected behaviour a tested
product or system.
3.2 Deleting Test Cases
Test cases, categories, and components may be deleted from a test plan by users
with lead permissions from the "delete test cases" screen. Deleting data may
be useful when first creating a test plan since there are no results. However,
Deleting test cases will cause the loss of all results associated with them.
Therefore, extreme caution is recommended when using this functionality.
3.3 Requirements relation
Test cases could be related with software/system requirements as n to n. The
functionality must be enabled for a product. User can assign Test Cases and
Requirements via link Assign Requirements in the main screen.
4. Keywords
4.1 Using keywords
Keywords were created to give users another level of depth when categorizing
test cases. Keywords serve as a collection of Test cases with some attribute
within a Test specification. You can use it to
Regression or Sanity set
Reviewed Test cases
Set of test cases valid for one platform
4.2 Keyword Creation
At this time keywords can only be created by users with the
mgt_modify_key rights.
These rights are currently held only by Leaders. Once a keyword or grouping of
keywords have been created users may assign them to test cases.
4.3 Assigning Keywords
Keywords may be assigned to test cases either from the assign keyword screen
(in batch) or via the test case management (individually).
4.4 Filter by Keyword
Users have the ability to filter by Keywords for:
Search Test Cases in Test Specification.
Add groups of Test cases in a Test case Suite (Test plan).
Execute test screen.
5. Requirement based testing
5.1 Introduction
To proof that a system is build as specified, testers use requirement based
testing. For every requirement, they design one or more test cases. At the end
of the test execution a test manager reports on the tests that are executed and
the requirements that are covered. Based on this information the client and the
various stakeholders decide whether a system can be transferred to the next test
phase or can go live. To ensure that a system is build as specified, test managers
use a combination of risk and requiremetn-based testing to ensure that a system
is build as specified from the customer and stakeholders perspective. As a result,
this complete testing delivers the following advantages:
Linking risks and requirements will reveal vague or missing requirements.
This is especially interesting for risks with a high priority.
Testing can be focused on the most important parts of an information
system first: covering the risks with the highest priority.
Communicating in the same language as the client and the stakeholders.
This makes it easier to report on the status of the test project. Beside
that a better founded decision can be made whether to invest more in
testing or take the risk.
The risks and their priority make negotiating on the test project in times
of pressure easier. What risks have to be covered within this test project
and which ones can be postponed. Risk and requirement-based testing
results in a better controlled test project. The communication with the
client and the stakeholders improved. The test manager begins testing
with risks with the highest priority. The process is streamlined and the
end result is higher quality.
5.2 Availability
The functionality is available on product level. I.e. Administrator should
enable it for a specified product (Edit Product link in Main window). Otherwise
links are not shown.
There are two user levels for this feature. The most of roles can view requirement
but not modify. Refer to User section for more.
5.3 Requirements Specification
Requirements are bunched to one or more System/Software/User Requirement
Specifications.
Illustration 2: Dependencies between requirement related objects
Create a document with Requirements:
1. Click Requirements Specification in Main window. The List of Requirement
Specification window is shown.
2. Press Create button to create a document.
3. Adjust
Title,
Scope and eventually
Count of Test cases. The last
parameter is used for statistics. Use only if you have a valid Requirement
document but not all requirements are available at the moment in TestLink.
Default value 'n/a' means that the current count of requirements in a
specification is used.
4. Press Create button to add data to database. You can see the title of
your new created document in the table of List of Requirement
Specification window.
5. Click the title of document for next work. The Requirement Specification
window is shown.
Each Requirement Specification has own statistics and report related to included
data.
All Specification could be printed via Print button in the Requirement
Specification window. Administrator can define company, copyright and confident
text via configuration files.
5.4 Requirements
Each requirement has Title, Scope (html format) and Status.
Title must not be
unique and has max. 100 characters.
Scope paramter is text in HTML format.
Status
can have vale VALID or NOT_TESTABLE. A NOT_TESTABLE requirements are not counted
to metrics.
Requirements could be created/modified or deleted manually via TestLink
interface or imported as CSV file.
5.4.1 Import requirements
TestLink support two types of CSV. The first 'simple' is composed from title
and scope in each row. The second 'Export from Doors' try to detect header and
chooses correct fields. Import compare titles and allow to solve conflicts. There
are three ways: update, create requirements with same title and skip adding the
conflicted ones).
5.4.2 Requirements to Test Case relation
Test cases are related with software/system requirements as * to *. I.e. you
can assign more Test cases to one Requirement and more requirements could be
covered by one Test Case. User can assign Requirements to Test Cases via the
Assign Requirements link in the Main window.
A coverage of Test Specification could be view via pressing the button Analyse
in the Requirement Specification window.
5.4.3 Requirement based Report
Navigate to Reports and Metrics menu. There is Requirements based Report link.
Requirements in currect Requirement Specification and Test Plan are analysed
for this report. All the latest result of test cases (available in Test Plan)
are proceeded for each requirement. The result with the highest priority is
applied for the requirement. Priority from the highest are: Failed, Blocked,
Not Run and Passed.
Example of requirement coverage
A requirement is covered by three Test Cases. Two of them are included
in the current Test Suite. One passed and one was not tested for the Build
1. Now Requirement has overall result: Not Run. Second test case was tested
with Build 2 and passed. So Requirement passed too.
6. Products
6.1 Overview
Products are the cornerstone of TestLink. Products are releases of your company
that may change their features and functionality over time but for the most part
remain the same.
6.2 Creating new products
Create a new product is admin right. You cannot create products with the same
name. You can assign a color of backgroung to product for a better lucidity.
Things to note when creating a new product:
Deleting Products themselves is not recommended from the system, because
the deletion of products would either orphan lots of test plan cases or
lead to their deletion.
Test Plans represent the testing of a product at a certain point of time.
What this means is that All Test Plans are created from Product test cases.
TestLink has the ability to import your data into a product. Data is read
in CSVs form and is explained further in the import section.
7. Test Plans
7.1 Creating a new Test Plan
Test plans are the basis for test case execution. Test plans are made up of test
cases imported from products at a specific point of time. Test plans can only
be created by leads. Test plans may be created from other test plans. This allows
users to create test plans from test cases that at a desired point in time. This
may be necessary when creating a test plan for a patch. In order for a user to
see a test plan they must have the propper rights. Rights may be assigned (by
leads) in the define User/Project Rights section. This is an important thing
to remember when users tell you they can't see the project they are working on
7.2 Builds
Builds are a specific release of software. Each project in a company is most
likely made up of many different builds. In TestLink execution is made up of
both builds and test cases. If there are no builds created for a project the
execution screen will not allow you to execute. The metrics screen will also
be completely blank. Builds currently cannot be edited or deleted.
7.3 Deleting TestPlans
Test plans may be deleted from the main page by users with lead permissions.
Deleting test plans permanently erases the test plan and all of its corresponding
data (test cases, results, etc). The deleting of data is a scary prospect and
should be reserved to extreme cases. TestLink also allows users to deactivate
test plans so that they no longer appear as a menu option.
8. Test Case Suite
8.1 Adding new Test Cases
Test Case Suite is set of test cases which are defined to be run within Test
Plan. Test case Suite is created via Add Test Cases from Test Specification to
Test Plan. Test cases are added including Steps and Expected result. So, you
must use 'Update modified Test Cases' page to update test scenario (version of
test case).
Data from multiple products can be added into one test plan. Test Specification
data can be filtered by keywords (adjusted in navigation pane).
Once data has been imported into a test plan it will be marked with checkmark.
If a test case has already been imported it will be ignored if it is imported
again.
8.2 Removing Test Cases from Test Case Suite
Test cases, categories, and components may be deleted from a test plan by users
with Leader permissions from the "Remove test cases" page. Deleting data may
be useful when first creating a test plan since there are no results. However,
Deleting test cases will cause the loss of all results associated with them.
Therefore, extreme caution is recommended when using this functionality.
8.3 Priority
TestLink gives users with Leader rights the ability to assign ownership and
priority to test cases. General Risk/Ownership is done at the category level.
TestLink currently does not allow users to assign risk or ownership at the
individual test case level.
Risk levels are low, medium, high and Importance levels are 3, 2, 1. Users can
rank the combinations of risk and importance (L1, L2, L3, M1, H2, M3, H1, H2,
H3) as priority A,B,C.
Assigning risk, importance, ownership, and priority are all optional and will
default to priority B in the metrics screen.
8.4 Ownership
Ownership affects both the execution and metrics screens. In the execution screen
users have the ability to sort the executable test cases by the ones they have
ownership of. In the main metrics screen there is a table that shows the remaining
test cases by ownership. If there are no test case owners it defaults to none.
A Tester can also see a metrics of own executed tests in main page if these metrics
are enabled (see Installation manual).
9. Test Execution
9.1 General
Test execution is available when:
1. A Test Specification is written.
2. A Test Plan is created.
3. Test Case Suite (for the Test Plan) is defined.
4. A Build is created.
5. The Test plan is assigned to testers (otherwise they cannot navigate to
this Test Plan).
Select a required Test Plan in main page and navigate to the 'Execute tests'
link. Left pane serves for navigation in Test Case Suite via tree menu, filtering
and define a tested build.
9.2 Navigation
The navigation pane consists from a 'Filter & Settings' box and a tree menu with
Test Case Suite.
9.2.1 Filtering Test Cases
This table allows the user to filter test cases for smart navigation before they
are executed.
Owner: Users can filter test cases by their owner. Ownership is
determined at the category level, is determined by leads, and can be
changed at the Assign Risk and Ownership page under metrics.
Keyword: Users can filter test cases by keyword. Keywords are set either
using the Create/Edit/Delete Test Cases or by the Assign Keywords To
Multiple Cases. Keywords can only be created, edited, or deleted by leads
but may be assigned to test cases by testers.
Result: Users can filter test cases by results. Results are what happened
to that test case during a particular build. Test cases can pass, fail,
be blocked, or not be run.
9.2.2 Define a tested build
Users can filter test cases by builds. Builds are the basic component for how
test cases are tracked. Each test case may be run once and only once per build.
Builds can be created by leads using the Create New Build page.
9.2.3 Tree menu
The tree menu in navigation pane includes Test Case Suite colored by results.
Menu colored: By default the tree will be sorted by the results for the defined
build that is chosen from the dropdown box.
Example TC colored according to the build
User selects build 2 from the dropdown box and doesn't check the "most
current" check box. All test cases will be shown with their status from
build 2. So, if test case 1 passed in build 2 it will be colored green.
Second possibility Last result is that menu is colored according to the latest
test result.
Example TC colored according to the latest result
User selects build 2 from the dropdown box and this time checks the "most
current" check box. All test cases will be shown with most current status.
So, if test case 1 passed in build 3, even though the user has also selected
build 2, it will be colored green.
9.3 Execution
9.3.1 Test Status
Execution is the process of assigning a result (pass, fail, blocked) to a test
case for a specific build. 'Blocked' test case is not possible to test for some
reason (e.g. a problem in configuration disallows to run a tested functionality).
9.3.2 Insert Test results
Test Results screen is shown via click on an appropriate component, category
or test case in navigation pane. The title shows the current build and owner.
The colored bar indicate status of the test case. Yellow box includes test
scenario of the test case.
The indication that the test case was updated or deleted in test Specification
is not supported in 1.5 version.
Updated Test Case: Users will see the American flag if the original version of
the test case (on the management side) has been updated. If users have the proper
rights they can go to the update/delete test case page either through clicking
on the test case number next to the flag or through the link on main page. It
is not necessary for users to update test cases if there has been a change. They
simply have the option of doing so if they wish.
Deleted Test Case: Users will see the "x" symbol if the original version of the
test case (on the management side) has been deleted. If users have the proper
rights they can go to the update/delete test case page either through clicking
on the test case number next to the "x" or through the link on main page.
10. Test Reports and Metrics
The metrics pages sum up the results of execution into reports. Metrics are broken
down by both individual builds and across all builds.
10.1 General Test Plan Metrics
This page shows you only the most current status of a test plan. For instance,
you have test case 1 which was executed in builds 1,2, and 3. Build 1 2 3 Status
Pass Fail Blocked Since the most recent result of the test case is blocked the
result on the "Across All Builds" page would be blocked. If a user would go and
change the status of build 3 to something else or not run the current result
would be fail.
(in TL 1.0.4: View Project Status Across All Builds)
10.2 Metrics of active Build
This report shows the detailed results for a particular build defined in
navigation pane.
(in TL 1.0.4: View Status by an Individual Build)
10.3 The Overall Build Status
View The Overall Build Status This report show a high level view of each build's
result.
10.4 Query Metrics
Query results for specific test cases based on keyword, component, owner, last
result, and 1 or more builds. For example if you wanted to know if a test case
has failed, passed, blocked, or has not been run in builds 2, 3, and 4 you would
want to use this query functionality. Additionally you could determine if test
cases assigned to a tester have been executed in a set of builds. This is important
because test passes may occur over multiple builds, and multiple test passes
may occur during the development cycle. This is especially handy at the end of
a development cycle when you want to know if certain cases have been run over
the past few builds of the product. This functionality differs from other reports
which display results on a specific build, or all builds.
Export to MS Excel is also available.
10.5 Test Report
View Status By Individual Test Cases This report shows each test case's result
for every build. An user can navigate to Test Execution screen via link for each
test Status.
Export to MS Excel is also available.
10.6 Blocked/Failed Test Cases
These reports show all of the currently blocked or failing test cases.
10.7 Total Bugs For Each Test Case
This report shows each test case with all of the bugs filed against it for the
entire project. This metrics are available only if Bug Tracking System is
connected.
10.8 E-mail Test report
Email Test Plan Info This page allows users to email the results of the entire
test Plan or for a particular build. It also allows users to email the status
of a component
11. User Administration
11.1 Account settings
Every user on the system will also be able to edit their own information via
the Account settings window (link Personal in menu bar).
TestLink allows users with administrator rights to create, edit, and delete users
within the system. However, TestLink does not allow administrators to view or
edit user's passwords. If users forget their passwords there is link on the login
screen, that will mail the user their password based upon their user name and
the email address they entered.
11.2 Role Permissions
TestLink is built with 6 different default permission levels built in. Changing
of these rights is handled by the user administration link which is accessible
by admins. These permission levels are as follows:
Guest: A guest only has permission to view test cases and project metrics.
Test Executor: A tester outside of the company that only has permissions
to run tests allotted to them. (initially in 1.0.4 - otester)
Test Designer: A user can fully work with Test Specification and
Requirements.
Test Analyst: A tester can view,create, edit, and delete test cases as
well as execute them. Testers lack the permissions to manage test plans,
manage products, create milestones, or assign rights. (initially tester,
senior tester)
Test Leader: A lead has all of the same permissions as a Tester but also
gains the ability to manage test plans, assign rights, create milestones,
and manage keywords
Admininstrator: An admin has all of the same permissions as a lead but
gains the ability to manage products
Note: Test plan related features needs also assign a Test Plan to be
available. See Test Plan Assignment.
11.2.1 User Roles
There are predefined user roles. Adminstrator gives appropriate ability to
modify data within TestLink. Each user has assigned just one of these roles.
If you view the table you will see rows for each of the permissions levels
(guest ,tester, senior tester, leader, admin). The column next to the row holds
all of the different rights levels which will be defined below. These levels
have been determined as standard for the use but they are free to be edited or
define a new roles (for experienced administrator). The user table contains a
foreign key that points to the appropriate permission level in the rights table.
Role
Guest
List of Rights
mgt_view_tc, mgt_view_key, tp_metrics
Ability
Browse data only.
Execute test only. Test Executor tp_execute,tp_metrics
tp_execute,
Test Analyst mgt_view_tc,
mgt_view_req
tp_metrics, tp_create_build,
Edit test Specification
mgt_modify_tc, mgt_view_key,
and execute tests.
tp_metrics, mgt_view_tc, mgt_modify_tc, Edit Test Specification
Test Designer
mgt_view_key, mgt_modify_req, mgt_view_req and Requirements.
tp_metrics,
All Test Plan right, edit
tp_planning, tp_assign_rights, mgt_view_tc,
Test Leader test Specification and
mgt_modify_tc, mgt_view_key, mgt_modify_key,
execute tests.
mgt_view_req, mgt_modify_req
tp_metrics,
Everything possible.
tp_planning, tp_assign_rights, mgt_view_tc,
Only this role can
Administrator mgt_modify_tc, mgt_view_key, mgt_modify_key,
maintain products and
mgt_view_req, mgt_modify_req,
users.
mgt_modify_product, mgt_users
tp_execute, tp_create_build,
tp_execute, tp_create_build,
Table 1: Role description
11.2.2 Rights Definitions
Next tables list keywords used for definition of role abilities.
Right
mgt_view_tc
Description
Viewing Test Specification (data of component, category, and test
case)
Edit Test Specification (create,modify,delete,order, move, and copy
components, categories, and test cases)
Viewing keywords
mgt_modify_tc
mgt_view_key
Right
mgt_modify_key
Description
Modifying keywords
mgt_modify_product Create,edit and delete products
mgt_view_req
mgt_modify_req
View requirements
Create,edit, associate and delete requirements
Table 2: Product related Rights
Right
tp_execute
Description
Ability to execute test cases (insert test results)
tp_create_build Ability to create builds
tp_metrics
tp_planning
Viewing metrics
create, edit, delete Test Plans, assign risk/ownership, milestones,
edit Tes Case Suite
tp_assign_rights Assigning the rights to view projects
Table 3: Test Plan related Rights
11.3 Test Plan Assignment
Users can see only assigned Test Plans. In order to gain test plan permissions
a user with lead or admin status must give them rights through the “Define
user/project rights” link under “Test Plan Management”.
All users in the system will by default not have permissions to view newly created
test plans (except for the test plan creator who can give themselves permissions
at creation). Zero test plan permissions means that users will not see any Test
Plans in the Test Plan dropdown box on main screen.
There is a table with Test Plan rights (i.e. which users can see which Test plan).
This table is made up of a combined user id and project id. The main page contains
code which checks to see if the logged in user has the appropriate permissions
(and then shows the allowed projects. It is not recommended that this be hacked
with.
版权声明:本文标题:推荐一款开源的测试用例管理工具Testlink用户手册 内容由热心网友自发贡献,该文观点仅代表作者本人, 转载请联系作者并注明出处:https://m.elefans.com/dongtai/1709505890a228394.html, 本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容,一经查实,本站将立刻删除。
发表评论