Как да персонализирате проект в HP ALM (Център за качество)
⚡ Умно обобщение
Персонализирането на проект в HP ALM позволява на администратора на проекта да контролира кой има достъп до проекта и какво може да прави всеки човек в него. Тази статия разглежда потребителските свойства, потребителите на проекта, групите и разрешенията, достъпа до модули, обектите на проекта, списъците, автоматичната поща, правилата за предупреждения, работния процес и редактора на скриптове.

Какво е персонализиране на проекти в HP ALM?
- Персонализирането на проекти позволява на администраторите на проекти да контролират достъпа до проекта, като дефинират потребителите, които имат достъп до проекта, а също така има възможности за персонализиране на типа задачи, които всеки потребител може да изпълнява.
- Можете също така да персонализирате проект, за да отговаря на специфичните изисквания на вашата организация.
- Също така помага при добавянето и редактирането на нови персонализирани потребителски полета, които могат да бъдат добавени към всеки един от модулите в ALM.
Персонализацията се постига от Инструменти> Персонализиране в рамките на проект и е отделно от „Администриране на сайта“. „Администриране на сайта“ създава домейни, проекти и потребители на ниво сайт, докато „Персонализиране на проекта“ решава какво могат да правят тези потребители, след като са в рамките на определен проект.
Прозорецът за персонализиране на проекта е разделен на областите, изброени по-долу. Нека ги разгледаме една по една.
| Зона за персонализиране | Какво контролира |
|---|---|
| Потребителски свойства | Данните за профила и паролата на влезлия потребител |
| Потребители на проекта | Кои акаунти принадлежат към този проект |
| Групи и разрешения | Какво може да създава, актуализира или изтрива всяка група |
| Достъп до модула | Кои модули може да вижда всяка група |
| Субекти на проекта | Системни и потребителски дефинирани полета за всеки обект |
| Списъци с проекти | Избираемите стойности зад списъчните полета |
| Автоматична поща | Известие по имейл за промени в полетата за дефекти |
| Правила за предупреждение | Сигнали за различни изисквания, тестове и дефекти |
| Редактор на работен процес и скриптове | Оформление на диалоговия прозорец и разрешени действия за всяка група |
💡 Съвет: Продуктът на тези екранни снимки е сменял собственика си повече от веднъж. Започна като HP Quality Center, стана HPE, а след това Micro Focus ALM, а сега се издава от OpenText като ALM / Център за качество. Екраните за персонализиране и моделът на скриптове за работен процес, описани тук, остават същите.
Потребителски свойства
Потребителят, който е влязъл в профила си, може да редактира данните на собствения си профил, а страницата му позволява и да промени паролата си.
ЗабележкаСамо паролата на текущо вписания потребител може да бъде променена тук, дори ако потребителят е от тип „Администратор на проект“.
Стъпка 1) Кликнете върху връзката „Инструменти“ и изберете „Персонализиране“, както е показано по-долу.
Стъпка 2) Показва се диалоговият прозорец за персонализиране на проекта, както е показано по-долу.
Стъпка 3) За да промените паролата на текущия потребител, щракнете върху „Промяна на паролата“ в раздела „Свойства на потребителя“.
Стъпка 4) Отваря се диалоговият прозорец за промяна на паролата.
- Въведете стара парола
- Въведете нова парола
- Въведете Потвърждаване на паролата
- Щракнете върху „OK“
Стъпка 5) На потребителя ще бъде показано съобщението за състоянието.
Стъпка 6) Потребителят може също да редактира следните данни за профила.
- Имейл ID
- Пълно име
- Телефонен номер
- Кликнете върху „Запазване“
Забележка: Потребителите няма да могат да редактират потребителското си име, дори ако потребителят е от тип „Администратор на проект“.
Стъпка 7) Статусът се показва на потребителя, както е показано по-долу.
Потребители на проекта
Този модул позволява на потребителите да добавят и премахват потребители за текущия ALM проект. Можете също така да присвоявате потребители на потребителски групи, за да ограничите правата им за достъп.
Стъпка 1) Сега нека добавим потребители към областта „Проект“.
- Отидете до Потребители на проекта
- Щракнете върху падащото меню „Добавяне на потребител“.
Стъпка 2) След като щракнете върху падащото меню „Добавяне на потребител“, на потребителя се показват следните методи, както е показано по-долу.
- Добавете потребител по име – Администраторът на проекта може да добави съществуващ ALM потребител към този проект, като предостави потребителското му име.
- Добавете нов потребител към сайта – Добавете нов потребител към сайта, като въведете всички данни, по същия начин, по който потребителите се добавят от „Администрация на сайта“.
- Добавете потребители от сайта – Добавете съществуващ потребител, като потърсите по неговото име или ID.
Нека разгледаме всеки един от тези методи.
Стъпка 3) Нека добавим потребител въз основа на име. Уверете се, че този потребител вече съществува в базата данни за администратор на ALM, т.е. потребител, създаден с помощта на Модул за администриране на сайта.
- Изберете „Потребители на проекта“ от прозореца „Персонализиране на проекта“.
- Кликнете върху „Добавяне на потребител“
- Въведете потребителско име
- Щракнете върху „OK“
Стъпка 4) Добавеният потребител се показва, както е показано по-долу.
Стъпка 5) Сега нека добавим потребител, използвайки опцията „Добавяне на нов потребител към сайта“.
Стъпка 6) След като щракнете върху „Добавяне на нов потребител към сайта“ от „Добавяне на потребител“, се показва следният диалогов прозорец.
- Въведете потребителско име
- Въведете Email
- Въведете пълно име
- Въведете телефонен номер
- Щракнете върху „OK“
Стъпка 7) Потребителят вече е добавен към текущия проект. Той се показва в „Потребители на проекта“, както е показано по-долу.
Стъпка 8) Сега нека добавим потребители на проекта, използвайки опцията „Добавяне на потребители от сайта“. Уверете се, че потребителят вече е в базата данни за администратор на ALM.
Стъпка 9) Показва се следният диалогов прозорец.
- Въведете потребителското име и щракнете върху иконата за търсене
- Показва се потребителското име
- Щракнете върху „OK“
Стъпка 10) Потребителят е добавен към проекта и се показва, както е показано по-долу.
Стъпка 11) Администраторът на проекта може също да премахне потребител от модула „Потребители на проекта“.
- Изберете потребителя
- Кликнете върху „Премахване на потребител“
Стъпка 12) Показва се диалогов прозорец за потвърждение. Кликнете върху „Да“.
Стъпка 13) След щракване върху „Да“ потребителят се премахва от списъка с потребители на проекта.
Стъпка 14) Всеки потребител в „Потребители на проекта“ има свързано с него членство.
Забележка: По подразбиране всеки добавен потребител има само разрешения за „Преглед“.
- Изберете потребителско име
- Изберете раздела „Членство“
- Показва се членството за избрания потребител. Новодобавеният потребител „Кати“ има разрешение за „Преглеждане“.
Групи и разрешения
Този модул позволява на администратора на проекта да присвоява привилегии на потребителски групи, като задава разрешения.
В ALM има 5 предварително дефинирани групи и всяка от тези потребителски групи има различно ниво на разрешения.
- Софтуерен Инженер
- Ръководител на проекта
- QA тестер
- TD Admin
- Viewer
Забележка: По подразбиране всеки потребител, добавен към областта на проекта, има само разрешение за „Преглед“.
Стъпка 1) Нека видим списъка с потребители в групата „TDAdmin“.
- Изберете „TDAdmin“
- В раздела „Членство“ ще видите потребители, които не са в групата
- В секцията „В групата“ ще видите списъка с потребителите в групата. В този случай се показва само „Администратор“.
Стъпка 2) Предварително дефинираните групови разрешения не могат да бъдат редактирани.
- Изберете „TDAdmin“
- Отидете до раздела „Разрешения“
- Изберете произволен модул (в този случай Дефекти)
- Разрешенията не могат да бъдат редактирани, дори ако текущият потребител е администратор на проекта.
Стъпка 3) Предварително дефинираните групи не могат да бъдат преименувани или изтривани.
Стъпка 4) За да промени разрешението на група, администраторът на проекта трябва да добави нова група. Да кажем, че трябва да създадем нова потребителска група, чиито членове имат разрешение за „Редактиране“ за модула „Дефекти“ и разрешение за преглед за всичко останало. Това означава, че всички разрешения трябва да са същите като на потребител с право на „Преглед“, с изключение на това, че потребителят трябва да може да актуализира дефекти. За да направите това,
- Кликнете върху „Нова група“
- На потребителя се показва диалогов прозорец за потвърждение. Кликнете върху „Да“.
Стъпка 5) След като щракнете върху „Да“, се показва диалоговият прозорец „Нова група“.
- Въведете името на групата
- Въведете профила, на който трябва да се базира
Стъпка 6) Потребителската група е създадена, както е показано по-долу. Можете също да видите, че можем да преименуваме или изтрием тази група, тъй като тя е създадена от нас. Предварително дефинираните групи в ALM не могат да бъдат редактирани или изтривани.
Стъпка 7) За да промените разрешението,
- Отидете до раздела „Разрешения“
- Кликнете върху раздела „Дефекти“
- Активиране на флага „Актуализация“ за дефекти
- Активиране на флага „Актуализиране“ за връзки
Достъп до модула
Този модул позволява на администраторите на проекти да контролират модулите, до които всяка потребителска група има достъп. Това предотвратява достъпа на потребителите до ограничени модули.
Да кажем, че разработчиците нямат нищо общо с тестовите случаи. Следователно, те могат да бъдат лишени от достъп до План за тестване намлява Тестова лаборатория модули.
Стъпка 1) Достъпът до модулите по подразбиране е показан по-долу. Всички потребителски групи имат достъп до всички модули по подразбиране.
Стъпка 2) За демонстрационни цели, нека премахнем целия достъп до модули от потребител тип VIEW, с изключение на модула Defects. Махнете отметката от всички квадратчета за достъп до модули до потребителя View, с изключение на Defects, както е показано по-долу.
Стъпка 3) Сега нека влезем, използвайки един от потребителските идентификатори „View“, за да проверим дали промените са приложени правилно. От снимката по-долу е видно, че настройките са приложени по предназначение, защото за потребителя на изгледа „Jim“ се показва само модулът „Defects“.
⚠️ Предупреждение: Достъпът до модули и разрешенията за групи са два различни контрола. Премахването на достъпа до модули скрива модула от менюто, но само по себе си не отменя съответните разрешения. Задайте и двете, когато ограничавате група.
Субекти на проекта
- Проектните обекти позволяват на администраторите на проекти да променят поведението на полетата на ALM системата или да дефинират потребителски дефинирани полета.
- Например, ако изпълняваме тестове на различни компилации и бихме искали да добавим поле „Версия на компилация“ в модула „Добавяне на дефект“, можем да го направим, използвайки модула „Проектни обекти“.
Стъпка 1) Потребителски дефинирани полета не могат да се добавят към системните полета, които са само за четене.
- Изберете „Проектни обекти“
- Изберете „Дефект“ и след това подпапката „Системни полета“.
- Обърнете внимание, че няма да можем да добавяме „Ново поле“ или да изтриваме такова, защото системните полета са само за четене.
Стъпка 2) За да добавите дефинирано от потребителя поле,
- Изберете подпапката „Потребителски полета“ в модула „Дефекти“.
- Кликнете върху „Ново поле“
- Детайлите на полето се показват, както е показано по-долу, и могат да бъдат редактирани.
Стъпка 3) Подробностите за полето също могат да се редактират, както е показано по-долу.
- Преименувайте етикета на „Номер на сборка“.
- Отбележете „Задължително“, което означава, че това поле става задължително при публикуване на нов дефект.
- Кликнете върху Запазване
Стъпка 4) Сега можем да видим промяната в модула „Дефекти“. Отидете до модула „Дефекти“ и потребителят ще види новосъздаденото поле „Номер на сборка“ като част от диалоговия прозорец „Нов дефект“.
Списъци с проекти
- Списъците с проекти позволяват на администраторите на проекти да добавят персонализирани списъци към проект. Списъкът съдържа стойности, които потребителят може да въведе в системни или потребителски дефинирани полета.
- Например, списъкът със статуси на грешки има шест предварително дефинирани статуса, а именно Нов, Отворен, Поправен, Повторно отворен, Затворен и Отхвърлен. Ако искаме да добавим още един статус, например Дубликат, можем да го направим с помощта на този модул.
Стъпка 1) За да добавите елемент от предварително дефиниран списък,
- Кликнете върху „Списъци с проекти“
- Изберете „Състояние на грешка“
- Щракнете върху „Нов елемент“. Отваря се диалоговият прозорец „Нов елемент“.
- Въведете името на елемента.
- Щракнете върху „OK“
Стъпка 2) След като щракнете върху OK, новият елемент се създава, както е показано по-долу.
Стъпка 3) Сега трябва да запазим промените.
- Кликнете върху бутона „Запазване“.
- Показва се изскачащ прозорец. Кликнете върху „OK“.
Стъпка 4) Сега отидете до модула „Дефекти“ и проверете дали полето за статус съдържа новодобавения елемент. Добавянето на статус също влияе на жизнен цикъл на дефекта, така че съгласувайте новата стойност с екипа, преди да я въведете.
Автоматична поща
Този модул позволява на администраторите на проекти да настройват правила за автоматично уведомяване по имейл, за да уведомяват потребителите по имейл за промени, направени по определени дефекти. Функцията за автоматично изпращане по имейл е достъпна само за модула „Дефекти“.
Стъпка 1) За да активирате автоматичните известия по имейл, изпълнете следните стъпки.
- Отидете до връзката „Автоматична поща“.
- Потребителят може да задейства имейл, като избере произволен брой налични полета в списъка.
- Тази таблица показва списъка с полета, за които потребителят е избрал да му изпраща имейл.
- Администраторът на проекта може също да избере настройките за имейл за всеки наличен потребител.
- Щракнете върху „Запазване“.
Стъпка 2) Показва се изскачащ прозорец. Щракнете върху OK.
Правила за предупреждение
Този модул позволява на администраторите на проекти да активират правила за предупреждения за текущия проект. Тази функция създава предупреждения и изпраща имейли, когато настъпят промени в проекта. Тя се отнася за изисквания, свързани тестове и дефекти.
Стъпка 1) За да активирате правилата за предупреждения,
- Отидете до „Правила за предупреждения“.
- Поставете отметка в квадратчето „Предупреждение, свързано с“
- Активирайте „Изпращане на имейл до“ и добавете съответния тестер или дизайнер.
- Кликнете върху „Запазване“
- Първо предупреждение: дизайнерът на тестове бива предупреждаван, когато изискване е модифициран, така че свързаните тестове да могат да бъдат актуализирани.
- Второ предупреждение: тестерът бива предупреден, когато дефект променя статуса си на „Поправен“, така че отговорният тестер да може да го вземе отново за повторно тестване.
Workflow
- Този модул позволява на администраторите на проекти да генерират скриптове, които помагат за персонализирането на модула „Дефекти“, т.е. диалоговия прозорец „Добавяне на дефект“ или диалоговия прозорец „Преглед на дефект“.
- С помощта на този модул, администраторите на проекти могат също да пишат скриптове за персонализиране на диалогови прозорци в други модули и да контролират действията, които потребителите могат да извършват.
Сега нека персонализираме диалоговия прозорец „Добавяне на дефект“ за потребителския тип група „TDAdmin“.
Стъпка 1) Под „Персонализиране на проекта“,
- Кликнете върху „Работен процес“.
- Изберете „Скрипт“ Generator – Добавяне на връзка „Персонализиране на полето за дефекти“
Стъпка 2) Отваря се диалоговият прозорец за персонализиране на полето „Добавяне на дефект“.
- Изберете потребителската група.
- Изберете полетата, които не искате да се показват в диалоговия прозорец „Добавяне на дефект“.
- Щракнете върху връзката „<“, за да изместите полетата от списъка с видими полета.
Забележка: Задължителните полета не могат да бъдат преместени извън списъка с видими полета.
Стъпка 3) След като премахнете всички неподходящи полета от списъка с видими полета, диалоговият прозорец за персонализиране се показва, както е показано по-долу.
- Полетата, които са изместени от списъка с видими полета.
- Полетата, които ще бъдат част от диалоговия прозорец „Добавяне на дефект“.
- Приложете промените в скрипта.
Забележка: Въпреки че персонализирахме това чрез потребителския интерфейс, промените се прилагат чрез генериране на скриптове във фонов режим. Ще разгледаме и редактирането на скриптове чрез пример в следващия раздел.
Стъпка 4) Сега влезте като потребител от тип „TDAdmin“ и щракнете върху „Нов дефект“ от модула „Дефекти“. Полетата, избрани като видими, се показват в прозореца „Нов дефект“.
Редактор на скриптове
Редакторът на скриптове помага на потребителите да пишат скриптове за персонализиране на диалогови прозорци в различните модули и за контрол на действията, които потребителите могат да извършват във всеки модул.
Нека променим начина, по който диалоговият прозорец „Преглед на дефекта“ се показва на потребителя с помощта на редактора на скриптове.
Стъпка 1) За да получите достъп до редактора на скриптове,
- Отидете до раздела „Работен процес“
- Кликнете върху „Редактор на скриптове“.
Стъпка 2) Редакторът на скриптове се показва на потребителя, както е показано по-долу.
- Изберете „Скрипт на модул за дефекти“
- Коментарът показва областта, където трябва да направим промени, защото изрично е посочено „персонализиране на полето за подробности за дефекта“.
- Скриптира се отделно за всяка потребителска група. Блокът, който разглеждаме, съответства на потребителската група „Разработчик“. Трябва да направим промени в потребителската група „TDAdmin“.
Стъпка 3) Сега превъртете надолу до потребителската група „TDAdmin“, където трябва да направим промени. Текущите настройки за „TDAdmin“ са показани, както е показано по-долу.
Стъпка 4) Нека разберем скрипта. Разгледайте следния ред код:
SetFieldApp "BG_ACTUAL_FIX_TIME", True, False, 0, 0
Ето и подробностите:
| Параметър | Значение |
|---|---|
| SetFieldApp | Извикването на функция, направено с 5 параметъра |
| Име на полето | BG_ACTUAL_FIX_TIME – името на полето, чиито настройки ще променим |
| Видим флаг | Ако е True, полето ще бъде видимо. |
| Задължителен флаг | Проверява дали полето е задължително. Ако е True, полето е задължително. |
| Флаг № на страница | Започва с 0. Ако има много полета, те могат да бъдат конфигурирани да се показват страница по страница. |
| ViewOrder | Задава реда на полето. Започва с 0 и се увеличава с 1. |
Стъпка 5) Нека направим промени в първото поле, „BG_ACTUAL_FIX_TIME“. Скриптът за това поле в редактора на скриптове е показан по-долу.
SetFieldApp "BG_ACTUAL_FIX_TIME", True, False, 0, 0
С горния скрипт, диалоговият прозорец „Подробности за дефекта“ се показва на потребителя, както е показано по-долу.
Редактирайте този ред от код, както е показано по-долу.
SetFieldApp "BG_ACTUAL_FIX_TIME", False, False, 0, 16
Задаването на флага „visible“ на „False“ скрива полето. Изходът от скрипта се отразява в диалоговия прозорец „Defect Details“, както е показано по-долу.
Стъпка 6) Нека направим промени във всички налични полета.
- Променете параметрите на извикванията на функции, както е обяснено в предишната стъпка за всяко поле, както е показано по-долу.
- Щракнете върху „Запазване“.
Стъпка 7) Сега влезте като потребител от тип „TDAdmin“ и отворете един от дефектите, така че да се отвори диалоговият прозорец „Преглед на подробности за дефекта“. Диалоговият прозорец сега се показва, както е показано по-долу.
Най-добри практики за персонализиране на HP ALM проекти
Персонализирането е лесно за започване и трудно за отмяна, така че няколко навика спестяват значителна преработка по-късно.
- Никога не редактирайте първо активен проект. Приложете промените в копие на проекта, потвърдете ги и едва след това повторете промяната в продукцията.
- Създавайте персонализирани групи, вместо да се борите с предварително зададените. Създайте нова група на базата на най-близкия предварително дефиниран профил и коригирайте само разрешенията, които трябва да се различават.
- Сведете до минимум дефинираните от потребителя полета. Всяко допълнително задължително поле забавя регистрирането на дефекти и често се оставя с безсмислена стойност по подразбиране.
- Коментирайте всяка промяна в скрипта на работния процес. Редакторът на скриптове съдържа по един дълъг файл на модул и е трудно да се направи некоментирана редакция. tracе месеца по-късно.
- Архивирайте скрипта на работния процес, преди да го редактирате. Копирайте съществуващия скрипт в текстов файл, защото в редактора няма история на версиите.
- Тествайте с реален акаунт от всяка група. Разрешенията често се държат различно от това, което предлага мрежата с квадратчета за отметка.
За да продължите с администрирането на HP ALM, прочетете как да създадете домейн, проект и потребител в Администрацията на сайта, Въведение в HP ALMи пълното Урок за HP ALMЗа модулите, засегнати от тези настройки, вижте изисквания, план за изпитване, и филтри, флагове и история.





















































