Upstream/harbor
1
0
Fork 0
mirror of https://github.com/goharbor/harbor.git synced 2024-11-22 10:15:35 +01:00
Code Issues Projects Releases Wiki Activity

group 2 test cases of image management

Browse Source
This commit is contained in:
Henry Zhang 2016-10-25 22:38:39 +08:00
parent 4653f48a8f
commit 60bbafcde5
16 changed files with 544 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

42
tests/testcases/Group2-image-management/2-01-DB-user-create-project.md Normal file
View File

@ -0,0 +1,42 @@
Test 2-01 - User Create Project (DB Mode)
=======
# Purpose:
To verify that a non-admin user can create projects when users are managed locally by Harbor (DB mode).
# References:
User guide
# Environment:
* This test requires that a Harbor instance is running and available.
* Harbor is set to authenticate against a local database. ( auth_mode is set to **db_auth** .) The user data is stored in a local database.
* A linux host with Docker CLI installed (Docker client).
* At least two non-admin users are in Harbor.
# Test Steps:
**NOTE:**
In below test, user A and B are non-admin users. User A, B and project X, Y should be replaced by longer and meaningful names.
1. Log in to UI as user A (non-admin).
2. Create a new project X with publicity is off (default).
3. Create another new project Y with publicity is on .
4. While keeping user A logging on, in another browswer log in as user B (non-admin).
5. User B checks his/her public projects to see if project Y is listed and project X is not listed.
6. User A changes project X's publicity to on, project Y's publicity to off.
7. User B refreshes his/her public projects to see if project X is listed and project Y is not listed.
8. On a Docker client host, use `docker login <harbor_host>` to log in as user A.
9. User A runs `docker push` to push an image to project X, push an image to project Y.
10. User A checks in the browser that the images had been successfully pushed to project X and Y.
11. On a Docker client host, use `docker login <harbor_host>` to log in as user B.
12. User B runs `docker pull` to an image of project X, and an image of project Y.
# Expected Outcome:
* Step 5, user B should see project Y is listed and project X is not listed.
* Step 7, user B should see project X is listed and project Y is not listed.
* Step 9,10, images should be pushed to project X and Y successfully and can be viewed from UI.
* Step 11,12, user B can pull the image of project X, cannot pull from project Y.
# Possible Problems:
None

38
tests/testcases/Group2-image-management/2-02-DB-user-push-multiple-images.md Normal file
View File

@ -0,0 +1,38 @@
Test 2-02 - User Push Multiple Images (DB Mode)
=======
# Purpose:
To verify that a non-admin user can push multiple images to a project when users are managed locally by Harbor (DB mode).
# References:
User guide
# Environment:
* This test requires that a Harbor instance is running and available.
* Harbor is set to authenticate against a local database. ( auth_mode is set to **db_auth** .) The user data is stored in a local database.
* A linux host with Docker CLI installed (Docker client).
* At least a non-admin user and the user has at least a project as project admin.
# Test Steps:
**NOTE:**
In below test, user A is non-admin user. User A and project X should be replaced by longer and meaningful names.
1. Log in to UI as user A (non-admin).
2. Verify User A has at least a project X with the role of project admin.
3. On a Docker client, log in as User A and run `docker push` to push an image with tag (e.g. nginx:1.5) to project X.
4. Continue to push at least 5 images with different tags, for example, nginx:1.6, nginx:1.7, nginx:1.8, nginx:release .
5. In the UI, go to "My Projects" to see if all images/tags are properly displayed.
6. Checks the detail info of each tag.
7. Enter keyword to search(filter) images/tags of a project.
8. On a Docker client, log in as User A and run `docker pull` to pull images with different tags from project X.
# Expected Outcome:
* Step 3-5, images can be pushed to project X and can be shown in UI.
* Step 6, image/tag info should be correct.
* Step 7, image/tag should be filtered and results should be matched the search criteria.
* Step 8, images can be pulled from project X.
# Possible Problems:
None

31
tests/testcases/Group2-image-management/2-03-DB-user-push-multiple-projects.md Normal file
View File

@ -0,0 +1,31 @@
Test 2-03 - User Create Multiple Projects (DB Mode)
=======
# Purpose:
To verify that a non-admin user can create multiple projects when users are managed locally by Harbor (DB mode).
# References:
User guide
# Environment:
* This test requires that a Harbor instance is running and available.
* Harbor is set to authenticate against a local database. ( auth_mode is set to **db_auth** .) The user data is stored in a local database.
* A linux host with Docker CLI installed (Docker client).
* At least a non-admin user.
# Test Steps:
**NOTE:**
In below test, user A is non-admin user. User A should be replaced by a longer and meaningful name.
1. Log in to UI as user A (non-admin).
2. Create 16 or more projects so that the pagination control has multiple pages.
3. Go through multiple pages of the list and click on a few projects to see if pagination work properly.
4. Search projects with keywords to see if the list and pagination update accordingly.
# Expected Outcome:
* As descirbed in step 3-4.
# Possible Problems:
None

33
tests/testcases/Group2-image-management/2-04-DB-user-view-projects.md Normal file
View File

@ -0,0 +1,33 @@
Test 2-04 - User View Projects (DB Mode)
=======
# Purpose:
To verify that a non-admin user can view projects when users are managed locally by Harbor (DB mode).
# References:
User guide
# Environment:
* This test requires that a Harbor instance is running and available.
* Harbor is set to authenticate against a local database. ( auth_mode is set to **db_auth** .) The user data is stored in a local database.
* There is at least a non-admin user.
* The user has at least 3 private projects.
* The registry has at least 3 public repositories.
# Test Steps:
**NOTE:**
In below test, user A is non-admin user. User A should be replaced by a longer and meaningful name.
1. Log in to UI as user A (non-admin).
2. Create at least 3 projects if he/she has less than 3 projects.
3. Switch a few times between "My Projects" and "Public projects" tab, view listed projects and click to check details of images.
4. Check logs of projects in "My Projects".
# Expected Outcome:
* Step 3, verify the information listed of projects are correctly displayed, such as creation time and role.
* Step 4, should see logs of the project.
# Possible Problems:
None

39
tests/testcases/Group2-image-management/2-05-DB-user-delete-image.md Normal file
View File

@ -0,0 +1,39 @@
Test 2-05 - User Delete Images (DB Mode)
=======
# Purpose:
To verify that a non-admin user can delete images when users are managed locally by Harbor (DB mode).
# References:
User guide
# Environment:
* This test requires that a Harbor instance is running and available.
* Harbor is set to authenticate against a local database. ( auth_mode is set to **db_auth** .) The user data is stored in a local database.
* A linux host with Docker CLI installed (Docker client).
* At least a non-admin user.
# Test Steps:
**NOTE:**
In below test, user A is non-admin user. User A and project X, Y should be replaced by longer and meaningful names.
1. Log in to UI as user A (non-admin).
2. Create a project X so that the user has the project admin role.
3. On a Docker client, log in as User A and run `docker push` to push an image to the project X, e.g. projectX/myimage:v1.
4. Push a second image with different tag to project X, e.g. projectX/myimage:v2 .
5. Push an image with different name to project X, e.g. projectX/newimage:v1 .
6. Run `docker pull` to verify images can be pushed successfully.
7. In UI, delete the three images one by one.
8. On a Docker client, log in as User A and run `docker pull` to pull the three deleted images of project X.
9. In UI, delete project X.
10. Run `docker pull` to pull the three deleted images of the project X.
# Expected Outcome:
* Step 7, images should be deleted successfully.
* Step 9, project X should be deleted successfully.
* Step 8,10, docker client should report error message.
# Possible Problems:
None

51
tests/testcases/Group2-image-management/2-06-DB-user-delete-projects.md Normal file
View File

@ -0,0 +1,51 @@
Test 2-06 - User Delete Projects (DB Mode)
=======
# Purpose:
To verify that a non-admin user can delete projects when users are managed locally by Harbor (DB mode).
# References:
User guide
# Environment:
* This test requires that two(2) Harbor instances are running and available.
* Harbor is set to authenticate against a local database. ( auth_mode is set to **db_auth** .) The user data is stored in a local database.
* A linux host with Docker CLI installed (Docker client).
* At least a non-admin user.
# Test Steps:
**NOTE:**
* In below test, user A is non-admin user. User A and project X should be replaced by longer and meaningful names.
* Must use two kinds of browsers at the same time to ensure independent sessions. For example, use Chrome and Firefox, or Chrome and Safari.
* DO NOT use the same browser to log in two users in different windows(tabs).
1. Log in to UI as user A (non-admin).
2. Create a project X so that the user has the project admin role.
3. On a Docker client, log in as User A and run `docker push` to push an image to project X, e.g. projectX/myimage:v1.
4. Push an image with different name to project X, e.g. projectX/newimage:v1 .
5. Run `docker pull` to verify images can be pushed successfully.
6. In UI, delete project X directly. (should fail with errors)
7. While keeping the current user A logged on, in a different browser, log in as admin user.
8. Under "Admin Options", create a replication policy of project X to another Harbor instance. (Do not need to activate this policy.)
9. Switch to the UI of User A, delete all images under project X.
10. In user A's UI, delete project X directly. (should fail with errors)
11. Switch to the UI of admin user, delete the replication policy of project X.
12. In user A's UI, delete project X.
13. In user A's UI, recreate project X,
14. On a Docker client, log in as User A and run `docker push` to push an image to project X, e.g. projectX/anotherimage:v1. The image name should not be the same as those deleted in previous steps.
15. Switch to the UI of admin user, view images under the re-created project X.
16. As an admin user, view the log in dashboard and should see delete and create operaions of project X.
# Expected Outcome:
* Step 6, deleting project X should fail because there are images under it.
* Step 10, deleting project X should fail because there is an image replication policy under it.
* Step 12, deleting project X should succeed.
* Step 13, re-creation of project X should succeed.
* Step 14, push should succeed.
* Step 15, project X should contain newly pushed image. The old images should not be displayed.
* Step 16, there should be logs for delete and create of project X, notice the project name of the deleted operation is displayed differently.
# Possible Problems:
None

25
tests/testcases/Group2-image-management/2-11-LDAP-user-create-project .md Normal file
View File

@ -0,0 +1,25 @@
Test 2-11 - User Create Project (LDAP Mode)
=======
# Purpose:
To verify that a non-admin user can create projects in (LDAP mode).
# References:
User guide
# Environment:
* This test requires that a Harbor instance is running and available.
* Harbor is set to authenticate against an LDAP or AD server. ( auth_mode is set to **ldap_auth** .) The user data is stored in an LDAP or AD server.
* A linux host with Docker CLI installed (Docker client).
* At least two non-admin users are in Harbor.
# Test Steps:
Same as Test 2-01 except that users are from LDAP/AD.
# Expected Outcome:
* Same as Test 2-01.
# Possible Problems:
None

25
tests/testcases/Group2-image-management/2-12-LDAP-user-push-multiple-images.md Normal file
View File

@ -0,0 +1,25 @@
Test 2-12 - User Push Multiple Images (LDAP Mode)
=======
# Purpose:
To verify that a non-admin user can push multiple images to a project in (LDAP mode).
# References:
User guide
# Environment:
* This test requires that a Harbor instance is running and available.
* Harbor is set to authenticate against an LDAP or AD server. ( auth_mode is set to **ldap_auth** .) The user data is stored in an LDAP or AD server.
* A linux host with Docker CLI installed (Docker client).
* At least a non-admin user and the user has at least a project as project admin.
# Test Steps:
Same as Test 2-02 except that users are from LDAP/AD.
# Expected Outcome:
* Same as Test 2-02.
# Possible Problems:
None

25
tests/testcases/Group2-image-management/2-13-LDAP-user-push-multiple-projects.md Normal file
View File

@ -0,0 +1,25 @@
Test 2-13 - User Create Multiple Projects (LDAP Mode)
=======
# Purpose:
To verify that a non-admin user can create multiple projects in (LDAP mode).
# References:
User guide
# Environment:
* This test requires that a Harbor instance is running and available.
* Harbor is set to authenticate against an LDAP or AD server. ( auth_mode is set to **ldap_auth** .) The user data is stored in an LDAP or AD server.
* A linux host with Docker CLI installed (Docker client).
* At least a non-admin user.
# Test Steps:
Same as Test 2-03 except that users are from LDAP/AD.
# Expected Outcome:
* Same as Test 2-03.
# Possible Problems:
None

26
tests/testcases/Group2-image-management/2-14-LDAP-user-view-projects.md Normal file
View File

@ -0,0 +1,26 @@
Test 2-14 - User View Projects (LDAP Mode)
=======
# Purpose:
To verify that a non-admin user can view projects in (LDAP mode).
# References:
User guide
# Environment:
* This test requires that a Harbor instance is running and available.
* Harbor is set to authenticate against an LDAP or AD server. ( auth_mode is set to **ldap_auth** .) The user data is stored in an LDAP or AD server.
* There is at least a non-admin user.
* The user has at least 3 private projects.
* The registry has at least 3 public repositories.
# Test Steps:
Same as Test 2-04 except that users are from LDAP/AD.
# Expected Outcome:
* Same as Test 2-04.
# Possible Problems:
None

25
tests/testcases/Group2-image-management/2-15-LDAP-user-delete-image.md Normal file
View File

@ -0,0 +1,25 @@
Test 2-15 - User Delete Images (LDAP Mode)
=======
# Purpose:
To verify that a non-admin user can delete images in (LDAP mode).
# References:
User guide
# Environment:
* This test requires that a Harbor instance is running and available.
* Harbor is set to authenticate against an LDAP or AD server. ( auth_mode is set to **ldap_auth** .) The user data is stored in an LDAP or AD server.
* A linux host with Docker CLI installed (Docker client).
* At least a non-admin user.
# Test Steps:
Same as Test 2-05 except that users are from LDAP/AD.
# Expected Outcome:
* Same as Test 2-05.
# Possible Problems:
None

25
tests/testcases/Group2-image-management/2-16-LDAP-user-delete-projects.md Normal file
View File

@ -0,0 +1,25 @@
Test 2-16 - User Delete Projects (LDAP Mode)
=======
# Purpose:
To verify that a non-admin user can delete projects in (LDAP mode).
# References:
User guide
# Environment:
* This test requires that two(2) Harbor instances are running and available.
* Harbor is set to authenticate against an LDAP or AD server. ( auth_mode is set to **ldap_auth** .) The user data is stored in an LDAP or AD server.
* A linux host with Docker CLI installed (Docker client).
* At least a non-admin user.
# Test Steps:
Same as Test 2-06 except that users are from LDAP/AD.
# Expected Outcome:
* Same as Test 2-06.
# Possible Problems:
None

48
tests/testcases/Group2-image-management/2-21-admin-view-project.md Normal file
View File

@ -0,0 +1,48 @@
Test 2-21 - Admin View Projects (DB Mode)
=======
# Purpose:
To verify that an admin user can view all projects when users are managed locally by Harbor (DB mode).
# References:
User guide
# Environment:
* This test requires that a Harbor instance is running and available.
* Harbor is set to authenticate against a local database. ( auth_mode is set to **db_auth** .) The user data is stored in a local database.
* A linux host with Docker CLI installed (Docker client).
* At least a non-admin users is in Harbor.
# Test Steps:
**NOTE:**
In below test, user A is non-admin user. User A and project X, Y should be replaced by longer and meaningful names.
1. Log in to UI as user A (non-admin).
2. Create a new project X with publicity is off (default).
3. Create another new project Y with publicity is on.
4. On a Docker client host, use `docker login <harbor_host>` to log in as user A.
5. Push an image to project X, push another image to project Y.
6. In UI, logs out and log in as admin user.
7. Check "Public Projects" to verify that project Y is listed and project X is not listed.
8. Verify that project "library" is listed.
9. Click project Y and view the newly pushed image in project Y.
10. Click "Users" to view the members of project Y.
11. Check "My projects" to verify that both project X and project Y are listed.
12. Verify that project "library" is listed.
13. Click project X and view the newly pushed image in project X.
14. Click "Users" to view the members of project X.
# Expected Outcome:
* Step 7, admin should see project Y is listed and project X is not listed.
* Step 8, project library should be listed.
* Step 9, the image pushed by user A should be listed under project Y.
* Step 10, user A should be project admin of project Y.
* Step 11, admin should see project X and Y are both listed.
* Step 12, project library should be listed.
* Step 13, the image pushed by user A should be listed under project X.
* Step 14, user A should be project admin of project X.
# Possible Problems:
None

33
tests/testcases/Group2-image-management/2-22-admin-search-projects.md Normal file
View File

@ -0,0 +1,33 @@
Test 2-22 - Admin User Search Projects (DB Mode)
=======
# Purpose:
To verify that a non-admin user can search projects when users are managed locally by Harbor (DB mode).
# References:
User guide
# Environment:
* This test requires that a Harbor instance is running and available.
* Harbor is set to authenticate against a local database. ( auth_mode is set to **db_auth** .) The user data is stored in a local database.
* A linux host with Docker CLI installed (Docker client).
* At least a non-admin user.
# Test Steps:
**NOTE:**
In below test, user A is non-admin user. User A should be replaced by a longer and meaningful name.
1. Log in to UI as user A (non-admin).
2. Create at least 5 projects with different names.
3. Log out and log in again as admin user.
4. Search projects with keywords to see if projects of user A can be matched by criteria.
5. Click on a few projects to toggle publicity on and off.
6. Check in "Public Projects" to verify the projects with publicity on can be listed.
# Expected Outcome:
* As descirbed in step 4,6.
# Possible Problems:
None

37
tests/testcases/Group2-image-management/2-23-admin-delete-images.md Normal file
View File

@ -0,0 +1,37 @@
Test 2-22 - Admin User Delete Images (DB Mode)
=======
# Purpose:
To verify that an admin user can delete images owned by other users when users are managed locally by Harbor (DB mode).
# References:
User guide
# Environment:
* This test requires that a Harbor instance is running and available.
* Harbor is set to authenticate against a local database. ( auth_mode is set to **db_auth** .) The user data is stored in a local database.
* A linux host with Docker CLI installed (Docker client).
* At least a non-admin user.
# Test Steps:
**NOTE:**
In below test, user A is non-admin user. User A and project X should be replaced by longer and meaningful names.
1. Log in to UI as user A (non-admin).
2. Create a project X so that the user has the project admin role.
3. On a Docker client, log in as User A and run `docker push` to push an image to the project X, e.g. projectX/myimage:v1.
4. Push an image with different name to project X, e.g. projectX/newimage:v1 .
5. Run `docker pull` to verify images can be pushed successfully.
6. In UI, log out user A's session.
7. Log in as admin user.
8. Under project X, delete the two images one by one.
9. On a Docker client, log in as User A and run `docker pull` to pull the two deleted images of project X.
# Expected Outcome:
* Step 8, admin user can delete images of project X.
* Step 9, docker client should report errors.
# Possible Problems:
None

41
tests/testcases/Group2-image-management/2-24-admin-delete-projects.md Normal file
View File

@ -0,0 +1,41 @@
Test 2-24 - Admin User Delete Projects (DB Mode)
=======
# Purpose:
To verify that an admin user can delete other user's projects when users are managed locally by Harbor (DB mode).
# References:
User guide
# Environment:
* This test requires that two(2) Harbor instances are running and available.
* Harbor is set to authenticate against a local database. ( auth_mode is set to **db_auth** .) The user data is stored in a local database.
* A linux host with Docker CLI installed (Docker client).
* At least a non-admin user.
# Test Steps:
**NOTE:**
* In below test, user A is non-admin user. User A and project X should be replaced by longer and meaningful names.
* Must use two kinds of browsers at the same time to ensure independent sessions. For example, use Chrome and Firefox, or Chrome and Safari.
* DO NOT use the same browser to log in two users in different windows(tabs).
1. Log in to UI as user A (non-admin).
2. Create a project X so that the user has the project admin role.
3. On a Docker client, log in as User A and run `docker push` to push an image to project X, e.g. projectX/myimage:v1.
4. Run `docker pull` to verify images can be pushed successfully.
5. In UI, log out user A.
6. Log in as admin user.
7. Delete project X. (should fail with errors)
8. Delete all images of project X.
9. Delete project X.
10. As an admin user, view the log in dashboard and should see delete operaion of project X and its images.
# Expected Outcome:
* Step 7, deleting project X should fail because there are images under it.
* Step 8-9, deleting images of project X and then deleting project X should succeed.
* Step 10, there should be logs for delete and create of project X, notice the project name of the deleted operation is displayed differently.
# Possible Problems:
None