ການທົດສອບ

ລິງດ່ວນໄປຫາລາຍງານການທົດສອບອັດຕະໂນມັດ

stat

new-stat

stat atomic

recent builds

stat everything subset

stat fedoraserver

ການເປີດໃຊ້ງານ

ການທົດສອບອາດຖືກຂຽນໃນຫຼາຍຮູບແບບ, ແຕ່ຈະຖືກສະແດງ ແລະ ເອີ້ນໃຊ້ໃນຮູບແບບມາດຕະຖານຕາມທີ່ກຳນົດໂດຍ Standard Test Interface ໃນບ່ອນເກັບຊຸດຊອບແວ (git repository) %2A ໂດຍກົງ. ມັນຍັງສາມາດເປີດໃຊ້ pipeline ສຳລັບ namespace ຂອງການທົດສອບໄດ້, ເບິ່ງລາຍລະອຽດທີ່ Testing Tests. ເພື່ອເລີ່ມຕົ້ນເຮັດວຽກກ່ຽວກັບການທົດສອບ, ທ່ານສາມາດ clone repository ຂອງຊຸດຊອບແວໄດ້ໂດຍກົງ:

git clone https://src.fedoraproject.org/rpms/qrencode.git

ທ່ານຍັງສາມາດໃຊ້ fedpkg ເພື່ອ clone repository ໄດ້. ເບິ່ງ Package Maintenance Guide ສຳລັບຂໍ້ມູນເພີ່ມເຕີມກ່ຽວກັບເຄື່ອງມືນີ້:

fedpkg clone -a qrencode

ການທົດສອບຈະຖືກເປີດໃຊ້ໂດຍການລວມເອົາໄຟລ໌ tests.yml ໄວ້ໃນໄດເຣັກທໍຣີ tests:

cd qrencode/tests
cat tests.yml

ການທົດສອບຈະຖືກຫໍ່ຫຸ້ມ ຫຼື ຂຽນເປັນ Ansible playbooks. ນີ້ແມ່ນຕົວຢ່າງຂອງ playbook ແບບງ່າຍໆ ທີ່ເປີດໃຊ້ການທົດສອບ smoke ພຽງຢ່າງດຽວຂອງຊຸດຊອບແວ qrencode:

- hosts: localhost
  roles:
  - role: standard-test-beakerlib
    tags:
    - classic
    - container
    - atomic
    tests:
    - smoke
    required_packages:
    - qrencode
    - file

ບາດນີ້ເຮົາມາມໍ້ເບິ່ງ playbook ໂດຍຫຍໍ້ ເພື່ອເບິ່ງວ່າຕົວປ່ຽນໃດທີ່ຖືກກຳນົດໄວ້ເພື່ອເປີດໃຊ້ການທົດສອບ smoke:

role

ການທົດສອບນີ້ໃຊ້ role standard-test-beakerlib ຈາກ Standard Test Roles ເພື່ອລັນການທົດສອບ BeakerLib

tags

ທັງສາມຫົວຂໍ້ການທົດສອບ (classic rpm, docker container ແລະ atomic host) ແມ່ນກ່ຽວຂ້ອງກັບການທົດສອບນີ້

tests

ລາຍການການທົດສອບທີ່ຈະຖືກປະຕິບັດ (ໃນທີ່ນີ້ເຮົາມີພຽງການທົດສອບ smoke ດຽວ)

required_packages

ລາຍການແພັກເກດ rpm ທີ່ຈຳເປັນສຳລັບການທົດສອບ

ມັນເປັນໄປໄດ້ທີ່ຈະແຍກການທົດສອບອອກເປັນຫຼາຍ playbooks, ເຊິ່ງແຕ່ລະອັນສາມາດແທນການທົດສອບ ຫຼື ສ່ວນໃດສ່ວນໜຶ່ງຂອງການທົດສອບໄດ້. ລະບົບທົດສອບຈະລັນແຕ່ລະ playbook ທີ່ກົງກັບ glob tests/tests*.yml ແຍກກັນໃນສະພາບແວດລ້ອມທີ່ສະອາດ. ນອກຈາກນັ້ນ, ທ່ານສາມາດມີຫຼາຍ playbooks ໂດຍບໍ່ມີຄຳນຳໜ້າ tests ແລະ ເຊື່ອມໂຍງພວກມັນຈາກໄຟລ໌ tests.yml. ມາເບິ່ງຕົວຢ່າງຂອງ gzip:

> fedpkg clone -a gzip
Cloning into 'gzip'...
> cd gzip/tests/
> ls
test-simple  test_simple.yml  tests.yml
> cat tests.yml
- include: test_simple.yml

ການປະຕິບັດ

ກ່ອນຈະລັນການທົດສອບ ໃຫ້ແນ່ໃຈວ່າທ່ານໄດ້ຕິດຕັ້ງ dependencies ຕໍ່ໄປນີ້ໃນລະບົບຂອງທ່ານແລ້ວ:

dnf install ansible python2-dnf libselinux-python standard-test-roles

ເຖິງແມ່ນວ່າບາງ playbooks ອາດຈະເຮັດວຽກໄດ້ໂດຍບໍ່ຕ້ອງໃຊ້ sudo, ແຕ່ການທົດສອບຈະຖືກເອີ້ນໃຊ້ໃນຖານະ root ສະເໝີ. ຕົວການທົດສອບເອງອາດຈະຕັ້ງຄ່າຜູ້ໃຊ້ ແລະ/ຫຼື ຫຼຸດສິດທິລົງຫາກເປັນສ່ວນໜຶ່ງຂອງການທົດສອບນັ້ນ. ແຕ່ໂດຍທົ່ວໄປແລ້ວ ໃຫ້ແນ່ໃຈວ່າທ່ານເປັນ root ເມື່ອເອີ້ນໃຊ້ການທົດສອບ.

ການທົດສອບອາດຈະປ່ຽນແປງ ຫຼື ທຳລາຍສະພາບແວດລ້ອມຂອງທ່ານ
ແນະນຳໃຫ້ໃຊ້ເຄື່ອງສະເໝືອນ (virtual machine) ສຳລັບການທົດສອບ ເພື່ອປ້ອງກັນການປ່ຽນແປງທີ່ບໍ່ຕ້ອງການຈາກການທົດສອບຕໍ່ລະບົບຂອງທ່ານ.

ການລັນການທົດສອບໂດຍກົງໃນລະບົບປັດຈຸບັນແມ່ນງ່າຍດາຍ:

ansible-playbook tests.yml

ເພື່ອລັນສະເພາະການທົດສອບທີ່ເໝາະສົມກັບລະບົບແບບ classic ທີ່ຕິດຕັ້ງໂດຍ yum ຫຼື dnf ໃຫ້ໃຊ້ argument --tags:

ansible-playbook --tags=classic tests.yml

ເບິ່ງເອກະສານ Standard Test Roles ສຳລັບຄຳແນະນຳລະອຽດກ່ຽວກັບວິທີລັນການທົດສອບສຳລັບ Rpm Package, Docker Container ຫຼື Atomic Host ທີ່ສະເພາະເຈາະຈົງ.

ການຂຽນ

ຕົວໂຄ້ດການທົດສອບເອງສາມາດຖືກເກັບໄວ້ໂດຍກົງໃນ dist-git (ແນະນຳໃຫ້ເປັນຄ່າເລີ່ມຕົ້ນ) ຫຼື ດຶງມາຈາກບ່ອນເກັບອື່ນທີ່ໂຮສຢູ່ໃນໂຄງລ່າງພື້ນຖານຂອງ Fedora ເຊັ່ນ Test Namespace. ວິທີທີ່ງ່າຍທີ່ສຸດໃນການເພີ່ມການທົດສອບໃໝ່ແມ່ນການໃຊ້ໜຶ່ງໃນ Standard Test Roles ທີ່ມີຢູ່ ເຊິ່ງຈະຈັດການລາຍລະອຽດການຈັດຕັ້ງປະຕິບັດຫຼາຍຢ່າງໃຫ້. ຫາກທ່ານຕ້ອງການສ້າງການທົດສອບແບບກຳນົດເອງ ໃຫ້ປະຕິບັດຕາມຄຳແນະນຳລຸ່ມນີ້.

ເມື່ອທ່ານກຳນົດບ່ອນເກັບ dist-git ທີ່ຈະເພີ່ມການທົດສອບໃໝ່ໄດ້ແລ້ວ, ທ່ານສາມາດເລີ່ມຂຽນການທົດສອບ Ansible ໃໝ່ໄດ້. ສ້າງ Ansible playbook ດ້ວຍຊື່ໃໝ່. ໃຫ້ແນ່ໃຈວ່ານາມສະກຸນແມ່ນ .yml. ມາລອງວາງຕົວຢ່າງຕໍ່ໄປນີ້ໄວ້ໃນໄຟລ໌ test_pid_1.yml.

---
- hosts: localhost
  vars:
  - artifacts: "{{ lookup('env', 'TEST_ARTIFACTS')|default('./artifacts', true) }}"
  tags:
  - atomic
  - classic
  - container
  tasks:
  - name: Test block
    block:
      - name: Test that /proc/1 exists
        shell: |
            ls /proc > /tmp/test.log || exit 1
            grep -qw 1 /tmp/test.log && result=pass || result=fail
            echo -e "results:\n- {result: $result, test: proc}" > /tmp/results.yml

    always:
      - name: Pull out the artifacts
        fetch:
          dest: "{{ artifacts }}/"
          src: "{{ item }}"
          flat: yes
        with_items:
          - /tmp/test.log
          - /tmp/results.yml

ທຸກໆການທົດສອບຈະມີໄດເຣັກທໍຣີ artifacts ບ່ອນທີ່ພວກມັນວາງຜົນການທົດສອບ. ລະບົບການທົດສອບ ຫຼື CI ທີ່ເອີ້ນໃຊ້ການທົດສອບຈະຕື່ມຂໍ້ມູນຕົວປ່ຽນນີ້ດ້ວຍໄດເຣັກທໍຣີທີ່ຈະຖືກຈັດເກັບ. ພວກເຮົາຕ້ອງເຮັດໃຫ້ແນ່ໃຈວ່າໄດເຣັກທໍຣີນີ້ມີຢູ່ໃນການທົດສອບ.

ໂດຍການໃຊ້ tags ພວກເຮົາຈະລະບຸວ່າລະບົບປະເພດໃດທີ່ການທົດສອບນີ້ເໝາະສົມທີ່ຈະລັນ. ເມື່ອລວມເອົາ tasks ເພີ່ມເຕີມເຊັ່ນ pre_tasks ໃຫ້ແນ່ໃຈວ່າທ່ານໄດ້ຕັ້ງ tag ທີ່ເໝາະສົມເຊັ່ນກັນ. ນອກຈາກ tags ທີ່ລະບຸໄວ້ຂ້າງເທິງແລ້ວ ຍັງສາມາດໃຊ້ always ເພື່ອລະບຸວ່າ task ຄວນລັນສຳລັບທຸກສະພາບແວດລ້ອມ. ຕົວຢ່າງ:

- hosts: localhost
  pre_tasks:
  - name: Set up a test user
    tags: always
    user:
      name: test
      groups:
        - wheel
        - adm

block ແມ່ນພາກສ່ວນທີ່ລັນການທົດສອບຕົວຈິງ. ໃນຕົວຢ່າງນີ້, ພວກເຮົາໃຊ້ວິທີທີ່ຂ້ອນຂ້າງຊັບຊ້ອນໃນການກວດສອບວ່າ PID 1 ມີຢູ່ຫຼືບໍ່. ເຖິງຢ່າງໃດກໍຕາມ, ໂດຍການເຮັດເຊັ່ນນັ້ນ, ພວກເຮົາໄດ້ວາງ artifact ການທົດສອບເພີ່ມເຕີມໄວ້ໃນໄດເຣັກທໍຣີ artifacts.

ສຸດທ້າຍ, ພວກເຮົາຈະດາວໂຫຼດ artifacts. ຈົ່ງຈື່ໄວ້ວ່າການທົດສອບບໍ່ໄດ້ລັນຢູ່ໃນລະບົບດຽວກັນກັບທີ່ມັນຖືກເອີ້ນໃຊ້ສະເໝີໄປ. ລອງລັນການທົດສອບຕົວຢ່າງນີ້ກັບ Atomic Host ຫຼື Docker Container. ມັນຄວນຈະຜ່ານ. ລອງປ່ຽນ argument /proc/1 ເປັນຄ່າອື່ນ, ແລ້ວການທົດສອບກໍຄວນຈະຫຼົ້ມເຫຼວ.

ທ່ານສາມາດໃຊ້ເຕັກນິກສ່ວນໃຫຍ່ຂອງ Ansible ໃນ playbooks ຂອງທ່ານໄດ້. ໃຫ້ເບິ່ງທີ່ Standard Test Roles ສຳລັບ Ansible roles ເພື່ອເຮັດໃຫ້ການຂຽນການທົດສອບຂອງທ່ານງ່າຍຂຶ້ນ.

ການໝາຍການທົດສອບທີ່ຈະລັນ

ພຽງແຕ່ການມີໄຟລ໌ .yml ໃນໄດເຣັກທໍຣີທີ່ຖືກຕ້ອງຍັງບໍ່ໄດ້ໝາຍຄວາມວ່າມັນຈະຖືກເອີ້ນໃຊ້. ໃຫ້ແນ່ໃຈວ່າໄດ້ອ້າງອີງ ຫຼື ເພີ່ມມັນຈາກ playbook tests.yml. ນີ້ແມ່ນຈຸດເລີ່ມຕົ້ນທີ່ລະບົບການທົດສອບ ຫຼື CI ຈະໃຊ້ເພື່ອເອີ້ນໃຊ້ທຸກການທົດສອບສຳລັບແພັກເກດນັ້ນໆ.

ຫາກໄຟລ໌ tests.yml ຍັງບໍ່ມີ, ໃຫ້ສ້າງມັນຂຶ້ນມາ. ມາຕໍ່ກັບຕົວຢ່າງຂ້າງເທິງຂອງພວກເຮົາ ແລະ ສ້າງ tests.yml ດ້ວຍເນື້ອໃນດັ່ງນີ້:

- import_playbook: test_pid_1.yml

ບາດນີ້ທ່ານສາມາດລັນການທົດສອບນີ້ດ້ວຍຄຳສັ່ງມາດຕະຖານຂ້າງເທິງໄດ້ແລ້ວ.

ເບິ່ງ Quick Start Guide ເພື່ອຮັບຄຳແນະນຳໃນການປະກອບສ່ວນການທົດສອບໃໝ່.

ການຫໍ່ຫຸ້ມ

ສົມມຸດວ່າທ່ານມີສະຄຣິບທີ່ລັນການທົດສອບ. stdout ແລະ stderr ຂອງມັນແມ່ນຜົນການທົດສອບ, ແລະ ສະຖານະການອອກ (exit status) ເປັນສູນໝາຍເຖິງຄວາມສຳເລັດ. ນີ້ຄືວິທີທີ່ພວກເຮົາຈະຫໍ່ຫຸ້ມການທົດສອບນັ້ນເພື່ອໃຫ້ຖືກເອີ້ນໃຊ້. ສົມມຸດວ່າພວກເຮົາມີສະຄຣິບງ່າຍໆ ໃນໄຟລ໌ທີ່ຊື່ວ່າ test-simple:

#!/bin/sh
set -ex
# exercise installed gzip/gunzip programs
echo "Bla" > bla.file
cp bla.file bla.file.orig
gzip bla.file
gunzip bla.file.gz
cmp bla.file bla.file.orig
rm bla.file bla.file.orig

ພວກເຮົາສາມາດຂຽນຕົວຫໍ່ຫຸ້ມ Ansible ສຳລັບສະຄຣິບນີ້ໄດ້ໃນ test_simple.yml ດັ່ງນີ້:

---
- hosts: localhost
  vars:
  - artifacts: "{{ lookup('env', 'TEST_ARTIFACTS')|default('./artifacts', true) }}"
  tags:
  - atomic
  - classic
  - container
  remote_user: root
  tasks:
  - name: Install the test files
    copy: src={{ item.file }} dest=/usr/local/bin/{{ item.dest }} mode=0755
    with_items:
    - {file: test-simple, dest: test-simple }

  - name: Test block
    block:
      - name: Execute the tests
        shell: |
          /usr/local/bin/test-simple &> /tmp/test.log && result=pass || result=fail
          echo -e "results:\n- {result: $result, test: simple}" > /tmp/results.yml

    always:
      - name: Pull out the logs
        fetch:
          dest: "{{ artifacts }}/"
          src: "{{ item }}"
          flat: yes
        with_items:
          - /tmp/test.log
          - /tmp/results.yml

ທຸກໆການທົດສອບຈະມີໄດເຣັກທໍຣີ artifacts ບ່ອນທີ່ພວກມັນວາງຜົນການທົດສອບ. ລະບົບການທົດສອບ ຫຼື CI ທີ່ເອີ້ນໃຊ້ການທົດສອບຈະຕື່ມຂໍ້ມູນຕົວປ່ຽນນີ້ດ້ວຍໄດເຣັກທໍຣີທີ່ຈະຖືກຈັດເກັບ. ພວກເຮົາຕ້ອງເຮັດໃຫ້ແນ່ໃຈວ່າໄດເຣັກທໍຣີນີ້ມີຢູ່ໃນການທົດສອບ.

block ແມ່ນພາກສ່ວນທີ່ລັນການທົດສອບຕົວຈິງ.

ສຸດທ້າຍ, ພວກເຮົາຈະດາວໂຫຼດ artifacts. ຈົ່ງຈື່ໄວ້ວ່າການທົດສອບບໍ່ໄດ້ລັນຢູ່ໃນລະບົບດຽວກັນກັບທີ່ມັນຖືກເອີ້ນໃຊ້ສະເໝີໄປ.

ຫາກໄຟລ໌ tests.yml ຍັງບໍ່ມີ, ໃຫ້ສ້າງມັນຂຶ້ນມາ. ມາຕໍ່ກັບຕົວຢ່າງຂ້າງເທິງຂອງພວກເຮົາ ແລະ ສ້າງ tests.yml ດ້ວຍເນື້ອໃນດັ່ງນີ້:

- import_playbook: test_simple.yml

ລອງລັນການທົດສອບຕົວຢ່າງນີ້ກັບ Atomic Host ຫຼື Docker Container. ມັນຄວນຈະຜ່ານ.

ເບິ່ງເອກະສານ Standard Test Roles ສຳລັບຄຳແນະນຳກ່ຽວກັບວິທີຫໍ່ຫຸ້ມການທົດສອບ BeakerLib ແລະ RHTS.

ເບິ່ງ Quick Start Guide ເພື່ອຮັບຄຳແນະນຳໃນການປະກອບສ່ວນການທົດສອບໃໝ່.

ການກຽມພ້ອມ

ຫາກທ່ານຕ້ອງການປັບປຸງລະບົບໃດໜຶ່ງກ່ອນການທົດສອບ, ໃຫ້ລວມເອົາ extra ansible task ກ່ອນພາກສ່ວນການທົດສອບ. ຕົວຢ່າງ, ນີ້ຈະເປັນການອັບເກຣດທຸກແພັກເກດໃນລະບົບໃຫ້ເປັນເວີຊັນລ້າສຸດ:

- hosts: localhost
  tags:
    - classic
  tasks:
    - dnf:
        name: "*"
        state: latest

- hosts: localhost
  roles:
  - role: standard-test-basic
    tags:
    - classic
    tests:
    - smoke38:
        dir: smoke
        run: VERSION=3.8 METHOD=virtualenv ./venv.sh

Want to help? Learn how to contribute to Fedora Docs ›