🏅 Как работи GPU копаенето?

GPU е важна единица на компютъра, която отговаря за изобразяването и показването на изображения и видеоклипове. Графичните процесори са оптимизирани за обработка на големи блокове от данни. Следователно, той е по-добър от процесора за копаене. Ако копаете криптовалута с GPU, не е необходимо често да превключвате между две задачи. Така че може да обработва повече хешове едновременно.

✅ Доклад за грешка в софтуерното тестване

Докладът за грешка в софтуерното тестване е подробен документ за откритите грешки в софтуерното приложение. Докладът за грешки съдържа всяка подробност за грешки като описание, дата на откриване на грешка, име на тестер, който я е открил, име на програмист, който я е поправил и т.н. Докладът за грешка помага да се идентифицират подобни грешки в бъдеще, така че да могат да бъдат избегнати. Defect_ID – Уникален идентификационен номер за дефекта. дефект Descriptйон – Подробно описание на Дефекта, включително информация за модула, в който е открит Дефектът. Версия – Версия на приложението, в което е открит дефект. Стъпки - Подробни стъпки заедно със снимки на екрана, с които разработчикът може да възпроизведе дефектите. Дата на повдигане – Дата на повдигане на дефекта справка– къде във вас Предоставете препратка към документи като . изисквания, дизайн, архитектура или може би дори екранни снимки на грешката, за да помогнете да разберете дефекта Открит от – Име/ID на тестера, който е повдигнал дефекта Състояние - Състояние на дефекта, повече за това по-късно Поправено от – Име/ID на разработчика, който го е поправил Дата на затваряне – Дата на затваряне на дефекта Суровост който описва въздействието на дефекта върху приложението Приоритет което е свързано със спешността на отстраняване на дефекта. Приоритетът на сериозност може да бъде висок/среден/нисък въз основа на спешността на въздействието, при която дефектът трябва да бъде отстранен съответно

Процес на управление на дефекти при тестване на софтуер

Какво е процес на управление на дефекти?

Управлението на дефекти е систематичен процес за идентифициране и коригиране на грешки. Цикълът на управление на дефекти съдържа следните етапи 1) Откриване на дефект, 2) Категоризиране на дефекта 3) Коригиране на дефект от разработчици 4) Проверка от изпитатели, 5) Закриване на дефект 6) Доклади за дефект в края на проекта

Тази тема ще ви напътства как да приложите процеса на управление на дефекти към уебсайта на проекта Guru99 Bank. Можете да следвате стъпките по-долу, за да управлявате дефекти.

Стъпка 1) Откриване

Във фазата на откриване екипите на проекта трябва да открият като много дефекти като възможен, преди крайният клиент да го открие. Казва се, че дефектът се открива и променя статуса си общоприет когато е признато и прието от разработчиците

В горния сценарий тестерите откриха 84 дефекта в уебсайта Guru99.

Нека да разгледаме следния сценарий; вашият екип за тестване откри някои проблеми в уебсайта на Guru99 Bank. Те ги считат за дефекти и докладват на екипа за разработка, но има конфликт –

В такъв случай, като мениджър на тестовете, какво ще направите?

A) Съгласете се с тестовия екип, че това е дефект

B) Мениджърът на теста поема ролята на съдия, за да реши дали проблемът е дефект или не

C) Съгласете се с екипа за разработка, че това не е дефект

правилен

InCorrect

В такъв случай трябва да се приложи процес на разрешаване на конфликта, като вие поемате ролята на съдия, за да решите дали проблемът с уебсайта е дефект или не.

Стъпка 2) Категоризация

Категоризирането на дефектите помага на разработчиците на софтуер да приоритизират своите задачи. Това означава, че този вид приоритет помага на разработчиците първо да поправят онези дефекти, които са изключително важни.

Дефектите обикновено се категоризират от ръководителя на теста –

Нека направим малко упражнение, както следва

Плъзнете и пуснете приоритета на дефекта по-долу

1) Производителността на уебсайта е твърде бавна
2) Функцията за влизане в уебсайта не работи правилно
3) GUI на уебсайта не се показва правилно подвижен устройства
4) Уебсайтът не можа да запомни потребителската сесия за влизане
5) Някои връзки не работят

Ето препоръчителните отговори

Не.	Descriptйон	Приоритет	Обяснение
1	Производителността на уебсайта е твърде бавна	Високо	Грешката в производителността може да причини огромно неудобство на потребителя.
2	Функцията за влизане в уебсайта не работи правилно	критичен	Входът е една от основните функции на уебсайта на банката, ако тази функция не работи, това са сериозни грешки
3	GUI на уебсайта не се показва правилно на мобилни устройства	Среден	Дефектът засяга потребителя, който използва смартфон, за да разглежда уебсайта.
4	Уебсайтът не можа да запомни потребителската сесия за влизане	Високо	Това е сериозен проблем, тъй като потребителят ще може да влезе, но няма да може да извършва други транзакции
5	Някои връзки не работят	ниско	Това е лесна поправка за разработчиците и потребителят все още може да има достъп до сайта без тези връзки

Стъпка 3) Решаване на дефекти

Разрешаване на дефекти в софтуерното тестване е стъпка по стъпка процес на отстраняване на дефектите. Процесът на разрешаване на дефекти започва с възлагане на дефекти на разработчиците, след което разработчиците планират дефектът да бъде коригиран според приоритета, след това дефектите се коригират и накрая разработчиците изпращат доклад за разрешаването на тестовия мениджър. Този процес помага за лесно отстраняване и проследяване на дефекти.

Можете да следвате следните стъпки, за да коригирате дефекта.

Задание: Възложено на разработчик или друг техник за коригиране и промяна на състоянието на В отговор.
Фиксиране на графика: Разработчиците поемат отговорността в тази фаза. Те ще създадат график за коригиране на тези дефекти в зависимост от приоритета на дефекта.
Отстранете дефекта: Докато екипът за разработка коригира дефектите, Мениджърът на тестовете проследява процеса на коригиране на дефекта в сравнение с горния график.
Докладвайте резолюцията: Вземете отчет за резолюцията от разработчиците, когато дефектите бъдат коригирани.

Стъпка 4) Проверка

След екипа за разработка фиксиран намлява съобщи дефектът, екипът за тестване одитирания че дефектите действително са отстранени.

Например, в горния сценарий, когато екипът за разработка докладва, че вече е коригирал 61 дефекта, вашият екип ще тества отново, за да провери дали тези дефекти наистина са коригирани или не.

Стъпка 5) Затваряне

След като дефектът бъде разрешен и потвърден, статусът на дефекта се променя като затворен. Ако не, трябва да изпратите известие до разработката, за да провери отново дефекта.

Стъпка 6) Докладване на дефекти

Докладване на дефекти в софтуерното тестване е процес, при който мениджърите на тестове подготвят и изпращат доклада за дефекти до мениджърския екип за обратна връзка относно процеса на управление на дефектите и състоянието на дефектите. След това мениджърският екип проверява доклада за дефект и изпраща обратна връзка или осигурява допълнителна поддръжка, ако е необходимо. Докладването на дефекти помага за по-добра комуникация, проследяване и обяснение на дефектите в детайли.

Управителният съвет има право да знае състоянието на дефекта. Те трябва да разбират процеса на управление на дефекти, за да ви подкрепят в този проект. Следователно трябва да им докладвате текущата ситуация с дефект, за да получите обратна връзка от тях.

Защо ви е необходим процес за управление на дефекти?

Вашият екип откри грешки, докато тества проекта Guru99 Banking.

След седмица разработчикът отговаря –

Следващата седмица тестерът отговаря

Както в горния случай, ако дефектната комуникация се извършва устно, скоро нещата стават много сложни. За да контролирате и управлявате ефективно грешки, имате нужда от жизнен цикъл на дефекта.

Важни показатели за дефекти

Обратно на горния сценарий. Разработчиците и тестовите екипи прегледаха докладваните дефекти. Ето резултата от тази дискусия

Как да измерим и оценим качеството на изпълнение на теста?

Това е въпрос, който всеки Тест мениджър иска да знае. Има 2 параметъра, които можете да разгледате както следва

В горния сценарий можете да изчислите коефициент на отхвърляне на дефекти (DRR) е 20/84 = 0.238 (23.8 %).

Друг пример, предполага се, че уебсайтът на Guru99 Bank има общо 64 дефекти, но вашият тестващ екип само открива 44 дефекти, т.е. пропуснати са 20 дефекти. Следователно можете да изчислите коефициента на изтичане на дефект (DLR) е 20/64 = 0.312 (31.2%).

Заключение, качеството на изпълнение на теста се оценява чрез следните два параметъра

Колкото по-малка е стойността на DRR и DLR, толкова по-добро е качеството на изпълнение на теста. Какъв е диапазонът на съотношението, който е приемлив? Този диапазон може да бъде определен и приет като база в целта на проекта или можете да препратите към показателите на подобни проекти.

В този проект препоръчителната стойност на приемливо съотношение е 5 ~ 10%. Това означава, че качеството на изпълнение на теста е ниско. Трябва да намерите противодействие, за да намалите тези съотношения, като напр

Подобряване на уменията за тестване на члена.
Прекарвайте повече време за изпълнение на теста, особено за преглед на резултатите от изпълнението на теста.

Въпроси и Отговори

Грешка е следствие/резултат от грешка в кодирането.

A Дефект в софтуерното тестване е вариант или отклонение на софтуерното приложение от изискванията на крайния потребител или първоначалните бизнес изисквания. Софтуерният дефект е грешка в кодирането, която причинява неправилни или неочаквани резултати от софтуерна програма, която не отговаря на действителните изисквания. Тестерите могат да се натъкнат на такива дефекти, докато изпълняват тестовите случаи.

Тези два термина имат много тънка разлика. В индустрията и двата са грешки, които трябва да бъдат коригирани и така взаимозаменяемо използвани от някои от Тестване отбори.

Когато тестерите изпълнят тестовите случаи, те могат да се натъкнат на такива резултати от тестове, които са в противоречие с очакваните резултати. Тази вариация в резултатите от теста се нарича софтуерен дефект. Тези дефекти или вариации се наричат с различни имена в различни организации като проблеми, проблеми, грешки или инциденти.

Докладът за грешка в софтуерното тестване е подробен документ за откритите грешки в софтуерното приложение. Докладът за грешки съдържа всяка подробност за грешки като описание, дата на откриване на грешка, име на тестер, който я е открил, име на програмист, който я е поправил и т.н. Докладът за грешка помага да се идентифицират подобни грешки в бъдеще, така че да могат да бъдат избегнати.

Defect_ID – Уникален идентификационен номер за дефекта.
дефект Descriptйон – Подробно описание на Дефекта, включително информация за модула, в който е открит Дефектът.
Версия – Версия на приложението, в което е открит дефект.
Стъпки - Подробни стъпки заедно със снимки на екрана, с които разработчикът може да възпроизведе дефектите.
Дата на повдигане – Дата на повдигане на дефекта
справка– къде във вас Предоставете препратка към документи като . изисквания, дизайн, архитектура или може би дори екранни снимки на грешката, за да помогнете да разберете дефекта
Открит от – Име/ID на тестера, който е повдигнал дефекта
Състояние - Състояние на дефекта, повече за това по-късно
Поправено от – Име/ID на разработчика, който го е поправил
Дата на затваряне – Дата на затваряне на дефекта
Суровост който описва въздействието на дефекта върху приложението
Приоритет което е свързано със спешността на отстраняване на дефекта. Приоритетът на сериозност може да бъде висок/среден/нисък въз основа на спешността на въздействието, при която дефектът трябва да бъде отстранен съответно

Кликнете тук ако видеото не е достъпно

Ресурси:

Изтеглете примерен шаблон за докладване на дефекти