създаване Препоръка на автоматизирани тестови скриптове

За да се опрости поддръжка и тест повторно използване на техния код трябва да ги структурира от самото начало. Най-вероятно ще намерите обща част от кода в няколко (ако не и всички) сценарии. Тези части трябва да бъдат идентифицирани и да споделите.

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

  • Добавяне, промяна, изтриване (най-очевидният комбинация)
  • Добавяне, изтриване, промяна
  • Добавяне, изтриване, добавяне, изтриване.
  • Добавяне, добавяйки, добавяйки.

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

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

  • Използване на клавиша TAB
  • С помощта на мишката,
  • Използване на клавишите за бърз достъп

Всеки един от тези варианти е различна съпротива срещу промяната. Например, след поставяне на нова област между другите две спре да работи изпълнение с TAB. След ремапинг клавишни комбинации не работят вече трета опция. Ако методът за определяне на областта, посочена от мишката, ще се промени, след втория метод не е подходящ. Някои инструменти тест за автоматизация позволяват да се определи Полето по-надеждни методи, например, от името на обекта, който се определя развитието на инструменти (PowerBuilder, SQLWindows или Visual Basic). В този случай, скриптове за изпитване, ще продължат да се провеждат, след като направите малки промени в тестовия софтуер (като например: смяна на позицията, текстовите надписи, украса и т.н.)

В много тестове, за да се провери поведението при различни условия, условията, съответстващи на тези данни се въвеждат в полетата на екрана. Процедурата за въвеждане на данни - е един и същ, само данните се променят. Ето защо, вместо отделни записи за изпитване на всеки набор от данни, можем да запишем тест, а след това да го копирате, промяна само въведените данни. Например, един тест "справка" може да се използва за всички набори от данни, което води до една и съща грешка (невалидни данни). Script може да бъде променен така, че входните данни са взети от файл или друг външен източник, а след това се стартира скрипт в цикъл за всеки набор от данни.

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

Тест скриптове се изпълняват последователно. Разклонение не поддържа изрично. За работа в скрипт очевидна грешка изисква допълнително логика. Например:

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

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

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

Входящ файл $ = "TIME.DAT"
Open входящ файл $ за въвеждане Като 1
Input # 1, StartTime $
Затвори # 1
Смятате Докато TIMEVALUE (StartTime $)> Време
DoEvents
контур
[Script Изпълнение]

В този пример, началния час, посочен във файла. Това ви позволява да промените часа без да е необходимо да се разбере сценарий. Време е записан в променливата $ StartTime. Смятате Докато цикъл се изпълнява до предварително определено време. Поради времето за DoEvents оператора на процесора може да бъдат изразходвани за фонови задачи. Без тази система операторът няма да отговори на приноса на потребителите преди началния час.

Когато извършвате тестови сценарии на един и същ софтуер, на които те са били записани, не би трябвало да възникне грешка (в самите скриптове). Медии и софтуер са същите, както по време на запис. Въпреки това, когато промените на теста може да се управлява правилно. За да се идентифицират тези потенциални проблеми, преди да се използва за истинското изпитание командите трябва да се тества. Освен това, се считат за два вида проблеми:

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

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