Меню

Как да се подготвите за писане на тестови казуси (Съвети за производителност)

how prepare yourself

Опитайте Нашия Инструмент За Премахване На Проблемите

Как да се подготвите за писане на тестови казуси и да подобрите производителността си:

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

Първо, те трябва да се подготвят професионално и психологически с някои от ключовите моменти, необходими за всеки успешен софтуерен тестер в ИТ индустрията. Това ще се третира като „ Входове ”За тестер, преди да започнете да пишете тестови случаи.

писане на тестови казуси

След това те трябва да разберат показателите за качество, включени в проекта, който се използва като инструмент за оценка на ефективността на тестера в различни фази от жизнения цикъл на тестването. Това ще се третира като „ Изходи ”За тестер след попълване писане на тестови казуси .

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

Какво ще научите:

java уеб услуги интервю въпроси и отговори за опитни

Подгответе се за писане на тестови казуси

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

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

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

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

5) Разберете подробно домейна на приложението .Например, тестването на уебсайт е по-лесно от тестването на финансов софтуер, разработен за фондова борса, който се използва от хиляди хора едновременно. Опростената функционалност на уебсайта може да бъде разбираема от всеки тестер, докато финансовите условия и функционалности не могат да бъдат разбираеми от всички тестери, докато и освен ако те не имат съответното образование или обучение или опит на домейн .

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

6) Изискванията на проекта и видовете тестове, които трябва да се извършат, варират в зависимост от проекта. Трябва да бъде подготвен тестер за извършване на всякакъв вид тестване. Не ограничавайте възможностите си на вашите умения и специалитети. Бъдете готови да поемете отговорности и предизвикателства, за да пишете и изпълнявате тестови случаи за всякакъв вид тестване.

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

7) Определете видовете тестове да бъдат изпълнени и уменията, необходими за тестване на AUT. Например, някои проекти изискват само тестване на черна кутия, а други изискват умения за тестване на бяла кутия. Знанието за „ скриптове ”Или опит в„ SQL ”Или работа с„ маркиращ език ”Като HTML / XML и т.н., или дори системни познания за това как да инсталирате / отстраните неизправности при инсталирането на софтуера и т.н. са някои специфични за проекта изисквания, които трябва да научите сами или да получите обучение за същото.

8) Уверете се, че тестовите случаи покриват Видове тестване на производителността, тестване на сигурността и регресия. Например, за да влезете в приложението, като използвате екрана за вход по-долу:

Ефективност на тестовия случай 2

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

9) Преглед на тестовия случай : Една от най-важните и най-пренебрегваните фази на всяко разработване на софтуер и жизнения цикъл на тестване е „ ПРЕГЛЕД ”. Когато проектният план включва достатъчно време за a процес на преглед на всеки етап от развитието на проекта, най-качествените резултати и резултати, които можем да очакваме едни и същи.

Например, преди да започнат да пишат тестови случаи, тестерите трябва да проверят дали документът „спецификация на изискванията“ е прегледан и всички точки за преглед са разгледани и актуализирани в документа. Ако организацията следва правилен и зрял процес, всички шаблони за документи трябва да съдържат тази информация за промяна на първата страница на самия документ.

Документите за тестови случаи трябва да бъдат прегледани поне 3 пъти чрез:

i) Самопроверка
ii) Партньорска проверка
iii) Преглед от други за пълнота, обхват на теста, проследимост и дали тестовият случай е проверяем или не.

10) И накрая, разбирам как да оценявам и планирайте тестовите задачи . Планирайте да работите само за планираното очаквано време в ден. Това може да се постигне чрез започване и изпълнение на задачите навреме и оставяне за деня с плановете за задачите на следващия ден.

Избягвайте да оставате късно вечер и да прекарвате уикендите в офиса. В наши дни са на разположение ефективни подходи за управление на проекти и проектите се изпълняват в гъвкава среда. Ако крайните етапи не бъдат постигнати от екипите по проекта, това ще се третира като неефективно управление на проекти, а не като неефективност от екипите по проекта.

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

Качествени показатели

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

Намерете по-долу няколко важни показателя на теста следвани от повечето организации за по-добра производителност на тестерите и ефективността на фазите на тестване.

Също вижтедруги полезни тестови показатели, използвани във фазите на тестване:

=> Важни показатели и измервания на теста на софтуера и Процес на живо за проследяване на грешки в проекта, метрични тестове и процес на излизане от теста.

1) Средна ефективност на тестване

  • Грешки за човекомесеци от усилията за тестване.
  • Изчислено като средно (Общо грешки по време на тестовите усилия в човекомесеци).
  • Да се ​​изчислява след всяко вътрешно освобождаване, както и след приключване на теста.
  • Граница за приемане: трябва да бъде по-малко от 50

2) Средна плътност на дефекта на клиента

c ++ конвертира масива от char в int
  • Грешки, съобщени от клиента след доставката Vs общо усилие за тестване в човекомесеци.
  • Изчислено като средно (Общо грешки след доставка / усилие за тестване в човекомесеци).
  • Да се ​​изчисли след външно пускане и завършване на проекта.
  • Граница за приемане: трябва да бъде по-малко от 1

3) Неуспехи при функционални тестове

  • Брой неуспешни функционални тестови случаи / Общ брой изпълнени функционални тестови случаи.
  • Да се ​​изчислява месечно или двуседмично.

4) Грешки с ниво на сериозност 1

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

5) Грешки с ниво на сериозност 2

  • Общият брой грешки, идентифицирани с ниво на сериозност 2 (основни грешки).
  • Тестването не може да продължи за характеристиката поради големите грешки, но може да продължи с други части на системата.
  • Да се ​​изчислява на седмична база.

6) Грешки с ниво на сериозност 3

  • Общият брой грешки, идентифицирани с ниво на сериозност 3 (незначителни грешки).
  • Тестването може да продължи, тъй като идентифицираната грешка е незначителна и не спира тестването.
  • Да се ​​изчислява на седмична база.

7) Грешки с ниво на сериозност 4

  • Общият брой грешки, идентифицирани с ниво на сериозност 4 (козметични проблеми).
  • Тестването може да завърши без никакви проблеми, тъй като идентифицираните грешки са свързани с козметиката и ще бъдат поправени за следващото издание.
  • Да се ​​изчислява на седмична база.

Отчитане на грешки

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

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

За да научите подробно процеса на докладване на грешкипрочетете следните статии:

=> Как да напиша добър доклад за грешка? Съвети и трикове
=> Примерен доклад за грешка
=> Защо докладването на грешки е изкуство, което трябва да се научи от всеки тестер?
=> Жизнен цикъл на бъгове
=> Примерни отчети за грешки за уеб и продуктови приложения

Доклади от тестовете

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

По-долу има един такъв прост протокол от теста:

Също така прочетете следните полезни уроци заефективно отчитане на теста:

=> Ръководство за създаване на ефективен обобщен доклад на теста
=> Как да отчитате интелигентно изпълнение на теста (Изтегляне на шаблон за отчет на състоянието)

конвертирате YouTube в wav файл безплатно

победител

jaya1

Заключение

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

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

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

  • Преминали ли сте през функционалните изисквания / изискванията на потребителите / документите за делови случаи?
  • Прегледан ли е документът за функционалните изисквания и актуализиран ли е правилно с коментари за преглед?
  • Получихте ли прототипите на екрана за всички функции, които ще бъдат тествани?
  • Удобно ли ви е да пишете тестови случаи, които могат да бъдат проверени и проследими през целия жизнен цикъл на тестването?
  • Имате ли необходимите умения и знания за домейн, за да тествате тестваното приложение?
  • Имате ли нужда от обучение или технически познания, необходими за изпълнение на тестовите случаи?
  • Имате ли график за писане, преглед и изпълнение на тестови случаи, който обхваща времето за изготвяне на качествени документи?
  • Имате ли връстници за преглед на вашите тестови случаи и упълномощен експерт по темата за проверка на пълнотата и обхвата на характеристиките и функционалностите, които ще бъдат тествани?
  • Имате ли достатъчно тестови случаи за всички функционални изисквания?
  • Имате ли достатъчно тестови случаи за изпълнение, тестване на натоварване и тестване на сигурността?
  • Имате ли достатъчно тестови случаи за инсталиране и регресивно тестване?
  • Имате ли контактна точка за ескалиране на проблемите или докладване на грешки?
  • Инструментът за проследяване на грешки конфигуриран ли е правилно с необходимото разрешение за всички?
  • Удобно ли ви е да следвате всички процеси, дефинирани в тестовия план?
  • Участвате ли във всички срещи за преглед и получавате ли възможност да говорите с екипа за разработка или управление?
  • Подобрени ли са вашата производителност и ефективност или трябва да предприемете някакви мерки за същото?

Препоръчително четене = >> Най-добрите онлайн курсове за творческо писане

Има много подобни въпроси, които тестерите могат да си зададат за анализ на самоусъвършенстването, в зависимост от вида на проекта или организацията, с която работят. Най-важното е, че всички тези дейности не трябва да се следват само с цел проследяване на процесите, а трябва да бъдат направени като вашите ежедневни навици, които могат да бъдат постигнати чрез СТРАСТ ЗА ИЗПИТВАНЕ само.

PREV Урок | СЛЕДВАЩ урок

Препоръчително четене

^