За прошедшую неделю в Оренбурге, где ваш покорный слуга имеет свойство жить, был замечен небывалый взрыв по показателям «одной IT-конференции за сутки». Тут и Softline с их семинарами и вебинарами, и результат инициативы руководителя фонда «Покровитель» Антона Солодикова, тот самый трёхдневный Orencamp, о коем сейчас пойдёт речь.

Что бы хотелось отметить в целом, так это мою радость по поводу того, что наконец-то и в нашем городе начались подобные мероприятия в массовом порядке. Это хорошая тенденция, она нужна и должна быть пущена на поток. Огромное спасибо организаторам, в частности Борису Вольфсону. Благодарности розданы, позитив наметился, теперь по делу.


Читать дальше →

Работа с PreferenceActivity в Android

Введение

Что есть activity? Руководство разработчика дает нам следующее описание:
«Активити представляет собой визуальный пользовательский интерфейс для одного конкретного действия, который может предпринять пользователь». По сути, активити – это экран (страничка), позволяющая выполнить пользовательское действие: просмотреть текущее состояние, отредактировать свойства чего-нибудь, прочитать сообщение. Про редактирование каких-либо свойств мы сегодня и поговорим.
Часто нам приходится заполнять какие-либо формы. Это и добавление контактов, и настройка соединения, и выставление будильника. В одном маленьком проекте нам нужно было заполнять информацию о задаче, успех которой будет отслеживать пользователь. Первоначально мы сделали это просто накидав полей для ввода на экран. Выглядело это отвратительно, поля не были выровнены относительно друг друга ни по высоте, ни по ширине. Пользоваться было трудно и неприятно.
Чуть позже обнаружилось, что есть правильный способ реализовывать такие диалоги, и это – PreferenceActivity.


Читать дальше →

Хочу рассказать, как относительно быстро восстановить работоспособность умершего freebsd сервера, либо перенести полностью сервер с одной машины на другую. Для этого нам понадобится программа для архивации fsbackup и live-cd с freebsd. Сразу предупреждаю, что это не how to, нужен некоторый уровень знания и понимания freebsd.

Первым делом сделаем сам архив. Для архивирования любых данных я использую простую и удобную программу fsbackup. Подробнее о ней можно узнать тут. В конфиге комментарии на русском языке, так что с настройкой проблем быть не должно. Архив можно хранить локально, на удаленном ftp, либо заливать через ssh на другой сервер. Поддерживается шифрование, создание инкрементных бэкапов. Программа живет в портах /usr/ports/sysutils/fsbackup Для бэкапа системы я использую следующий конфиг:

$cfg_backup_name = «srv12_domain_local»;
$cfg_cache_dir = "/usr/local/fsbackup/cache";
$prog_md5sum = «md5sum -b»;
$prog_tar = "/usr/bin/tar";
$prog_ssh = "/usr/bin/ssh";
$prog_rm = "/bin/rm";
$prog_gzip = "/usr/bin/gzip";
$prog_pgp = «gpg»;
$cfg_checksum = «timesize»;
$cfg_backup_style = «backup»;
$cfg_increment_level = 7;
$cfg_save_old_backup = 1;
$cfg_type = «remote_ftp»;
$cfg_remote_ftp_mode = 0;
$cfg_remote_password = «password»;
$cfg_local_path = "/mnt/backup/srv12/system";
$cfg_time_limit = 0;
$cfg_size_limit = 0;
$cfg_maximum_archive_size = 0;
$cfg_root_path = "/";
$cfg_verbose = 2;
$cfg_stopdir_prune=0;

1;

__DATA__
#Архивируем весь сервер с корня
/
#Указываем папки исключения, которые бэкапить не нужно
!/dev
!/mail
!/mnt
!/usr/ports
!/var/db/portsnap
!/usr/local/fsbackup/cache
!/web/squidcache
!/web/mysql
!/usr/src
!/usr/local/www/data-dist/netams

Я архивирую весь сервер, за исключением некоторых папок, которые указаны отдельно.

Архив мы получили, теперь нужно подготовить сервер, на который будет осуществляться перенос. Для этого на исходном сервере необходимо открыть /etc/fstab

/dev/ar0s1b none swap sw 0 0
/dev/ar0s1a / ufs rw 1 1
/dev/ar0s1f /mail ufs rw 2 2
/dev/ar0s1d /tmp ufs rw 2 2
/dev/ar0s1e /usr ufs rw 2 2
/dev/ar0s1g /var ufs rw 2 2
/dev/ar0s1h /web ufs rw,suiddir,noatime 2 2
/dev/acd0 /cdrom cd9660 ro,noauto 0 0

запомнить существующие разделы и затем создать такие же разделы на другом сервере. Размер разделов может не совпадать, достаточно просто наличие таких же разделов. Я разбиваю диск с помощью установочного диска freebsd и custom install на нем: разбиваю непосредственно диск и ставлю загрузчик freebsd. После того, как создали разделы, копируем наш бэкап куда-нибудь, чтобы потом можно было его забрать на второй сервер, загрузившись с live-cd. Можно скопировать на ftp, можно на флешку, можно просто в виндовую шару положить и потом ее подмонтировать. Вместе с архивом нужно скопировать скрипт fsrestore.sh, который лежит в /usr/local/fsbackup/scripts. Этот скрипт будет выполнять непосредственно восстановление системы.

Теперь берем live-cd, я использую Frenzy, и грузимся с него. В принципе, пользоваться можно чем угодно, любым live-cd с freebsd, но мне нравится именно Frenzy. После загрузки имеем полноценную систему, которая автоматически подмонтировала созданные нами ранее разделы. Подмонтированы они в режиме чтения, так что сначала отмонтируем их.

umount /dev/ad4s1a

и так далее со всеми разделами.

Затем в папке /mnt создадим папки с именами разделов нашей системы, которую мы переносим. В моем случае это папки /mnt/tmp, /mnt/usr, /mnt/var, /mnt/web, /mnt/mail.

Далее монтируем разделы в только что созданные папки, при этом раздел / монтируем в /mnt

mount /dev/ad4s1a /mnt
mount /dev/ad4s1f /mnt/mail
mount /dev/ad4s1d /mnt/tmp
mount /dev/ad4s1e /mnt/usr
mount /dev/ad4s1g /mnt/var
mount /dev/ad4s1h /mnt/web

Теперь нужно подмонтировать флешку с архивом:

mount_ntfs /dev/da0s1 /mnt/backup

Не забываем заменить /dev/da0s1 на то устройство, каким является флешка у вас.

Можно вместо флешки подмонтировать виндовую шару. Перед монтированием шары стоит не забыть настроить сеть либо через sysinstall, либо сразу c помощью ifconfig:

ifconfig eth0 192.168.0.15 netmask 255.255.255.0
ifconfig eth0 up

Монтируем шару:

mount_smbfs -I 192.168.0.2 -E koi8-r:cp866 //user@comp/shara /mnt/backup

user – имя пользователя шары, comp – имя компьютера в сети shara – имя шары

Итак, у нас есть бэкап, есть подмонтированные разделы будущей системы. Теперь можно начать восстановление. Для этого редактируем скрипт fsrestore.sh. В нем нужно изменить только две строчки:

# Директория где находится бэкап.
backup_path="/mnt/backup"
# Корневая директория куда будут помещены данные восстановленные из бэкапа.
restore_path="/mnt"

После этого запускаем скрипт и ждем завершения. Лучше бэкап скопировать куда-нибудь локально, и затем запускать восстановление. Так будет быстрее и надежнее. После завершения восстановления, проверяем файлы. В данный момент в папке /mnt должна находиться копия нашего сервера.

Сейчас нужно внести некоторые изменения в конфигурацию. Первым делом обязательно нужно отредактировать файл /mnt/etc/fstab так как имена дисков в разных серверах могут быть разными. На исходном сервере у меня было зеркало ar0, перенес же я на одиночный хард ad4. Соответственно, меняем в fstab ar0 на ad4. Тут же можно поменять сетевые и прочие настройки в rc.conf но это уже не критично. Все остальное можно будет изменить загрузившись в системе. Если же не отредактировать fstab, то, скорее всего, мы не загрузимся.

После восстановления перезагружаем компьютер, вытаскиваем live-cd, логинимся в систему. Осталось выполнить последнее действие. Вместе с непосредственно архивом fsbackup создает файлик с правами доступа и владельцами на все файлы и папки в архиве. Файл этот имеет расширение .dir Во время восстановления скрипт не отработал и не расставил нужные права, так как путь восстановления был не в / а в /mnt, поэтому пути в файле не совпадали с путем восстановления. Так что теперь нам нужно вручную исполнить этот файл, чтобы полностью восстановить все права и владельцев. Для этого ставим ему права на исполнение и запускаем. После его исполнения мы имеем точную копию системы.

Не так давно появившаяся статья про внедрение проверки подписи для приложений на уровне процессора вызвала бурю возмущений. Чем это вызвано? Прежде всего непониманием вызовов нового времени и общего развития информационной безопасности. Вторая причина — это «советская» ментальность и отсутствие привычки покупать программное обеспечение. Я вас разозлил? Считаете что это не так? Аргументы ниже.

Читать дальше →

Надо заметить, что синтаксис языков програмирования достиг невиданного прогресса. Если сравнить количество текста и читабельность таких языков как, например, ADA и последняя версия C#, то разница будет разительной. Есть множество языков на все вкусы. Perl мало что пишет, но многое держит в уме. Haskell пишет достаточно, но это мало кому помогает…

К сожалению, SQL вообще и TSQL в частности не могут похвастаться такими же успехами. Долгое время TSQL вообще не развивался. Выходили новые версии сервера, а язык оставался практически тем же. Возьмем простой пример, объявим и присвоим переменную.

declare @var int, @var2 int
set @var = 100
set @var2 = 50

На мой взгляд, это слишком длинно и неудобно. Если в скрипте используется много переменных, то несколько первых экранов будут заняты только их объявлением и присваиванием. Это, согласитесь, каменный век.

Если нужно увеличить переменную на некоторое значение, то нужно писать так:

set @var = @var + 10

Да, старое доброе винрарное присваивание.

Но с выходом SQL Server 2008 ситуация изменилась. Синтаксис языка наконец-то поменялся. Теперь можно не испытывать боли при написании простейших конструкций языка. Теперь можно писать так:

declare @var int = 100,
@var2 int = 50

При иннициализации можно использовать другие переменные (и вообще любые скалярные выражения):

declare @var int = 100
declare @var2 int = @var — 50

А вот в одном declare этого сделать не получится:

declare @var int = 100,
@var2 int = @var — 50

Также был расширен оператор присваивания. Инкремент теперь можно записать так:

set @var += 10

Всего доступно 8 таких операторов: +=, -=, *=, /=, %=, &=, ^=, |=.

Не думаю, что кто-то будет часто пользоваться оператором «двоичное ИЛИ и присвоение», но для полноты языка он есть.

Вспомним, что SELECT на самом деле еще и оператор множественного присваивания. Можем записать так:

select @var *= 2, @var +=1

Вычисления производятся слева направо, и в нашем случае получится 201. Теперь на собеседованиях можно спрашивать такие же дурацкие вопросы, как и у программистов.

Конечно, подобные нововведения нельзя воспринимать без улыбки. Во-первых, уже сто лет как они стали нормой жизни. Они давно есть у конкурентов. Это не более чем синтаксический сахар, а для того чтобы их реализовать ушло чуть не 15 лет. В то же время множество других проблем остались без внимания. Зачем вообще писать set в присваиваниях, у нас все равно переменные выделяются с помощью @? Зачем выделять специальным образом переменные? Да, есть стандарт. Но если стандарт устарел, его нужно поменять… Думаю, еще лет через 15 на очередной конференции Microsoft представит нам новые революционные достижения в синтаксисе SQL. Тогда я напишу еще одну статью.

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

Многие уже наверное слышали о популярной парадигме доступа к данным map\reduce. Кто-то даже наверное слышал о Apache CouchDB. Это документ-ориентированная БД с доступом по REST интерфейсу. Авторы позиционируют её как БД созданную для нужд создателей сайтов.

Но вот беда, хоть сама база и отдельно разрабатываемый движок поиска couchdb-lucene являются кроссплатформенными, установить их на windows машину оказалось не так легко. Если у вас есть опыт работы под linux и компиляции Java, то вы наверное и сами быстро справитесь. Если же нет, приглашаю под хабракат.

Установка базы данных

Говоря «установить их» я немного слукавил. Установить саму CouchDB не сложно, благо на сайте есть windows intaller, находится он по этому адресу.

Установка couchdb-lucene

Для чего это нужно? Дело в том, что сама couchDB не поддерживает полнотекстового поиска. Эта задача целиком делегируется внешним приложениям. И правильно, зачем делать то, для чего уже существует Apache Lucene?

Couchdb-lucene это приложение-индексатор, написанное на Java и полностью интегрируемое в базу данных. Интересным фактом является то, что помимо собственно Lucene в индексатор встроена библиотека Apache Tika позволяющая реализовывать полнотекстовый поиск не только по полям документов, но и по бинарным вложениям (Attachments). CouchDB-lucene распространяется через git. Для linux есть простая (всего три пункта) инструкция и несколько необходимых скриптов, для windows же ничего нет.

Итак как же собрать все это воедино под windows:

1. Скачать исходники.

Думаю тут проблем не возникнет. Идем на страницу проекта, жмем download и выбираем zip.

2. Исходники нужно собрать.

Вот тут то и начались проблемы. Дело в том, что лично я никогда раньше не писал на java и тем более не имел дело с её компиляцией. Собирать лучше не на «боевом» сервере. Зачем захламлять его лишним софтом?

2a. Устанавливаем компилятор
Компилятор называется javac и живет он на сайте компании Sun. Туда и отправимся. Нужен нам JDK (Java Development Kit).

2b. Устанавливаем Apache Maven

Уже интереснее. Это фреймворк автоматизирующий сборку проектов. Для нас важен тот факт, что он автоматически скачает все библиотеки, указанные в зависимостях у CouchDB-lucene и соберет проект. Идем на страницу загрузки. И скачиваем apache-maven-x.x.x-bin.zip. На момент написания топика версия 2.2.1
Там же можно найти инструкцию по установке. Приведу вольный перевод основных мыслей:
1. Разархивируйте в произвольную директорию
2. Внесите пути к Maven и компилятору Java в системные переменные.
Для этого нажмте WinKey + Pause (Свойства системы). Для Vista и Seven выберите «Дополнительные параметры системы», Дополнительно, Переменные среды.
Там добавьте в список переменных пользователя:
M2_HOME = C:\путь\к\директории\maven
JAVA_HOME = C:\путь\к\директории\JDK
JRE_HOME = C:\путь\к\директории\JRE
(JRE это ява машина, необходимая для запуска ява приложений, ставится либо автоматически вместе с JDK либо уже давно установлена)
Path = %M2%;%JAVA_HOME%\bin;%JRE_HOME%\bin
3. Проверьте корректность установки набрав в командной строке mvn --version

2c. Собираем

Теперь имея все необходимое открываем окно консоли и идем в директорию куда разархивированы исходники (cd C:\some\dir для тех кто забыл) и запускаем сборку командой mvn. Процесс идет, можем откинуться на спинку кресла.

3. Достаем собранное приложение

В папке исходников появилась директория target. Из неё забираем couchdb-lucene-0.6-SNAPSHOT-dist.zip это и есть то-что нам нужно. Разархивируем на той машине где собираемся запускать базу.

4a. Заменяем скрипт запуска

Скрипт запуска написан на Shell. Нужен аналог на bat. Кладем в bin рядом с файлом run файл run.bat со следующим содержимым

@echo off
setlocal EnableDelayedExpansion 
SET OLDCD=%CD%
cd %~dp0..
SET JAVA_OPTS=-server -Xmx1g
SET CLASS=com.github.rnewson.couchdb.lucene.Main
SET CLASSPATH="conf"
for %%i in ("lib\*.jar") do SET CLASSPATH=!CLASSPATH!;"%%~dpfi"
java.exe %JAVA_OPTS% -cp %CLASSPATH% %CLASS%
cd %OLDCD%

4b. Создаем скрипт запуска обработчика сигналов от БД, написанного на питоне

Дело в том, что CouchDB никак не хотела запустить интерпретатор питона с необходимыми параметрами. Обходным вариантом является создать файл hook.bat со следующим содержимым:

@echo off
C:\путь\к\питону\python.exe "C:\путь\к\скрипту\couchdb-external-hook.py"

5. Для запуска нужен питон

Я не знаю чем руководствовался разработчик, но CouchDB-lucene написана на трех языках: Java, Python и shell. Делать нечего, идем на сайт питона и скачиваем версию 2.7 (на версии 3.2 необходимый скрипт лично у меня не заработал). Здесь также есть инсталлятор. Питон ставим уже на «боевой» сервер.

6. Если на боевом сервере нет Java машины то её нужно поставить.

Если вы собирали приложение на той машине где собираетесь запускать, то java машина у вас уже есть. Скачать её можно тут.

7. Проверяем

Запустите run.bat если увидите что-нибудь похожее на
2010-09-19 23:13:54,781 INFO [Main] Index output goes to: C:\путь\к\приложению\couch-lucene\indexes
2010-09-19 23:13:55,031 INFO [Main] Accepting connections with SelectChannelConnector@localhost:5985
То все идет хорошо.

8. Последний рывок

Настраиваем CouchDB.
[couchdb]
os_process_timeout=60000; increase the timeout from 5 seconds.

[external]
fti=«C:\путь\к\hook.bat»

[httpd_db_handlers]
_fti = {couch_httpd_external, handle_external_req, <<«fti»>>}

9. Не забудьте перезапустить CouchDB

Теперь создав соответствующий _design документ вы можете осуществлять полнотекстовый поиск. О формате _design документа написано на странице проекта в разделе Document Indexing.

Удачного использования!

«Компьютерра»-offline

Журнал «Компьютерра» был моим любимым компьютерным еженедельником. Прекращение существования его бумажной версии в конце 2009 года стало для меня большим разочарованием.

Оказалось, что я совершенно не приспособлен читать online-версию журнала. Во-первых, свободное время для чтения журнала у меня почти всегда находится либо в дороге, либо тогда, когда я нахожусь далеко от компьютера. Во-вторых, заходя на сайт, мне неудобно искать новые статьи среди уже прочитанных. Короче говоря, я привык покупать новый номер журнала и с удобством читать его от начала до конца.

Мне не оставалось ничего другого, как написать скрипт, выкачивающий с сайта «Компьютерры» все новые статьи и выдающий их на одной HTML-странице. Так возник проект «Компьютерра»-offline.


Читать дальше →

Я, как и многие люди моего поколения, интересуюсь новыми разработками высокотехнологичной продукции. В моём случае, это набирающие популярность различные смартфоны, тачпады, уже немного устаревающие ноутбуки, и соответственно, операционные системы к ним.

Зачастую, читая комментарии к подобным статьям, поражаюсь тем пафосу и насмешкам, которые слышатся про разработки российских проектов. Многие считают, что не стоит выбрасывать кучу наших денег на разработки компьютерных ОС, да и, как новость сезона, смартфонов российского производства. Предлоги бывают разные, от «всё равно только деньги разворуют», «ничего путного у нас не получается» до «такая продукция будет следить за нами для ФСБ».

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

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


Читать дальше →

Автотест (автоматизированный тест) – это скрипт, имитирующий взаимодействия пользователя с приложением, цель которого – локализация ошибок в работе программного обеспечения.

Конечная цель автоматизации тестирования представляет собой некий набор автотестов, которые, при нажатии на кнопку «GO!», будут поочередно запускаться. Ну или всегда можно запустить какой-либо автотест отдельно, если для этого есть необходимость. Каждый такой скрипт проверяет правильность работы определенной части приложения и фиксирует ошибки в случае, если что-то работает не так.
О том, насколько выгоднее использовать автоматизированное тестирование чем ручное, а так же о плюсах автоматизированного тестирования хорошо написано в этой статье. Я же хочу описать возможные проблемы, с которыми может столкнуться тестировщик, решивший использовать автоматизированные тесты.

Отбор тестов для автоматизации

Проблемы возникают уже при выборе тест кейсов, которые необходимо автоматизировать. Не все тест кейсы поддаются автоматизации, и бывают ситуации, когда некоторые из них лучше оставить в ручном тестировании. Другими словами, если у вас есть 1000 тестовых сценариев, то очень мал шанс, что из них 1000 возможно автоматизировать. Очень редко удается перейти полностью от ручного тестирования к автотестам. Не стоит забывать что ручное и автоматизированное тестирование – это не взаимоисключающие, а взаимодополняющие методы.
Например, невозможно (читай: очень сложно) автоматизировать тестирование таких вещи как:

• установка операционной системы
• проверка напечатанного принтером документа
• проверка содержимого картинки, видео

Стоимость

Далеко не всегда оказывается, что разработка и сопровождение автоматизированных тестов будет дешевле ручного тестирования. Необходимо потратиться на среду разработки, системных администраторов, наем программистов, их информационную поддержку (имеется ввиду поддержка при возникновении вопросов относительно тестируемой системы и тест кейсов), обеспечить им рабочие места. Все это выльется в немалую сумму и окупится только при тестировании больших систем, когда есть возможность автоматизировать довольно большое количество тестов. После разработки скриптов их нужно кому-то запускать и анализировать результаты. Не получится проводить тестирование по схеме «запустил – подождал – получил конечный результат». Нужен человек, который сможет анализировать выполнение автотестов: определять, нужно ли отправлять тест на доработку, действительно ли существует ошибка, найденная автотестом, подготавливать данные для тестирования. На подготовку среды для разработки, саму разработку уйдет масса времени.

Отдельная статья расходов на автоматизацию – это поддержка автотестов.

Поддержка

Автотесты всегда требуют поддержки. Так как написание автотестов – это программирование, то чтобы изменить\исправить логику автотеста нужно лезть в исходный код. Для этого нужно нанимать дополнительных специалистов, которые будут сопровождать написанные скрипты. Это новые расходы, без которых не обойтись и которые значительно повышают стоимость автотестов. Есть 2 основных случая, при которых может понадобиться вмешательство в исходный код:

1. Изменение входных данных к тесту

Хорошо, если при выполнении нескольких итераций тестирования приложения можно всегда подавать автотестам на вход одни и те же данные. Например, проверка занесения записи в базу данных, или проверка открытия какого-либо меню, где входные данные вообще не требуются.
Но бывает и так, что перед каждым запуском автотестов данные нужно готовить заново. При большом количестве тестов подготовка входных данных может занять много времени. Например, при тестировании банковской системы могут потребоваться счета в рублях, долларах, евро; счета с разными суммами, принадлежащими как физическим лицам, так и организациям. После прогона серии автотестов на всех счетах может остаться нулевой баланс, некоторые из них будут закрыты, некоторые заблокированы. При последующем тестировании необходимо будет использовать другие счета. В некоторых случаях данные могут быть хардкодом прописаны в скриптах автотестов, и происходить это может не из-за того что разработчику было лень сделать свой скрипт более гибким, а просто потому что такого хардкода требовал тест кейс. Через некоторое время тест кейс изменится (например название банка изменится с «хабрабанк» на «хабракредитбанк»), и потребуется изменение скрипта.

2. Изменение функционала

Особенно актуально для регрессионного тестирования – тестирования новых версий. При каждом обновлении интерфейса или функционала тестируемого ПО потребуется доработка автотестов. Автотесты не могут сами адаптироваться под новый интерфейс, и для продолжения их корректной работы приходится все изменять вручную. Чем больше количество тестов, и чем больше произошло нововведений в ПО, тем больше времени понадобится на актуализацию.
Пример: в старой версии программы было меню «Файл -> Опции», в новой версии этот пункт разделили на два: «Файл -> Настройки» и «Файл — > Параметры». Автотест по прежнему будет искать пункт «Опции», и хоть ты тресни, не найдет «Настройки».
Либо может измениться например время загрузки тестируемой страницы. Если раньше она загружалась моментально, то теперь на это уходит минута. Допустим, теперь скорость соединения слабая, или база тормозит. Автотест же этого не знает, ждет загрузки страницы 10-15 секунд и выдает сообщение «Ошибка: страница не загрузилась». Опять же понадобится доработка исходного кода скрипта.

В обоих случаях многое зависит от разработчиков: процесс написания автотестов требует не меньших знаний и усилий чем процесс создания любого другого ПО. Следовательно, тут проявляются все проблемы, связанные с разработкой: сложность контроля качества и надежности, перенос сроков, изменение бюджета и многие другие.

И всё-таки

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



Еще несколько плюсов автоматизации:

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