Перейти к содержимому

Фотография

Книга по SilkTest: ваши пожелания


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 23

#21 KaNoN

KaNoN

    АЦЦКИЙ СОТОНА

  • Members
  • PipPipPipPipPipPip
  • 1 260 сообщений
  • ФИО:Колесник Николай
  • Город:Днепропетровск > Киев > Лондон

Отправлено 14 апреля 2006 - 11:29

Было бы неплохо предупредить читателя о вредности тотального пользования Record. Далеко ведь не все можно записать, и много багов в Силке есть по этому поводу. Например, некоторые элементы окошка не подсвечиваются, используя Record Window Declarations диалог, хотя и прекрасно распознаются. Вообще, надо приучаться к автоматизации в слепую, без всяких там визардов - просто смотришь на приложение и пишешь код, так как знаешь, как Silk это видит. После нескольких месяцев непрерывной автоматизации я и мои коллеги к этому пришли. Конечно, бывает полезно знать мнение Silk'a на этот счёт, но последнее слово всегда за тобой :).

Естественно, что все будет ориентировано на написание кода вручную. Но это не значит, что мы не используем визарды совсем. Например, для описания фреймов очень удобно использовать Record Window Declarations, а затем вручную подправить, переименовать объекты, ненужное удалить и т.д. А сами тесткейсы, естественно ручками и только.

Какого они будут нужны, если GUI приложения меняется каждый билд? Кто-то скажет, зачем такое автоматизировать вообще, нужно иметь стабильный GUI, однако это бывает только в сказках и в Tutorial'aх.

GUI приложения меняются, но как правило незначительно. А если имеет место значительное изменение интерфейса, то что тогда можно проверять скриптом, если даже нет стабильных требований к продукту и в частности к его внешнему виду? А ведь это тоже тестируется

Поэтому один из принципов - писать минимум кода для работы теста. Перекликается с принципом экстремального программирования - "вам это не понадобится".

А это уже смотря что пишешь. Если это какая-то общая функциональность, то тут минимумом не обойтись. Тут нужно задумываться над сферой применения той или иной функциональности.

Простейшее решение работающее сейчас - вот что нужно.

Если скрипты пишутся для регрессионки, то такой подход приносит множество проблем. Работать-то оно сейчас может и будет, а потом что? Будет другая версия или даже просто другие условия - и все. Думать надо хотя бы на шаг вперед.
Я бы предложил другой принцип: "Простейшее решение, которое будет работать в ближайший промежуток времени - вот то, что нам нужно"
  • 0

#22 KaNoN

KaNoN

    АЦЦКИЙ СОТОНА

  • Members
  • PipPipPipPipPipPip
  • 1 260 сообщений
  • ФИО:Колесник Николай
  • Город:Днепропетровск > Киев > Лондон

Отправлено 14 апреля 2006 - 11:45

Да, еще один момент хотелось бы уяснить.
Книга построена так, что основные вопросы написания скриптов освещаются во время написания некоторого тестового скрипта, то есть мы взяли некоторое приложение (одно из тех, что идет в поставке с СилкТестом), описали сценарий тестирования (который нужно автоматизировать) и описали все действия, которые проделали для этого (от создания фрейма до обработки результатов тестирования). То есть освещение тех или иных вопросов происходит параллельно с разработкой скрипта. Ну там могут быть лирические отступления, так как есть проблемы достаточно общего характера.

Как вы считаете, вот потенциальному читателю удобно будет изучать СилкТест, если освещение этого средства происходит таким образом? Может быть как-то по-другому это все организовать?
  • 0

#23 VegaX

VegaX

    Активный участник

  • Members
  • PipPip
  • 85 сообщений

Отправлено 14 апреля 2006 - 12:06

Из моего опыта разработки на меняющимся GUI, я понял что надо старатся править декларацию так, что бы она по возможности работала на всех версиях билдов.

Это даст возможность "предугадать" возможные будущие изменения. Так довольно часто сталкивался, когда клиент при разработке GUI делает какие-то изменения, а потом их откат.
  • 0

#24 VegaX

VegaX

    Активный участник

  • Members
  • PipPip
  • 85 сообщений

Отправлено 14 апреля 2006 - 12:17

Как вы считаете, вот потенциальному читателю удобно будет изучать СилкТест, если освещение этого средства происходит таким образом? Может быть как-то по-другому это все организовать?


Я думаю, что подход правильный. Среднестатистический пользователь хочет быстрее перейти на разработку скрипта и увидеть свои результаты, а не читать 4 главы о типах, оперциях и т.д. А так как без этого не обойтись, то по этим вопросам должен быть общий обзор с таким подходом, что человек, который раньше стыкался с програмированием, мог бы просто проипустить этот раздел и перейти непосредственно к конструкциям Силк Теста и написанию скриптов.
  • 0


Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных