Как и обещал, моя активность в данном проекте сводится к минимуму.
Итак, новости проекта:
обновленный сайт - http://www.softwaretesting.ru
Теперь вы не найдете там Системы (она полностью ушла из продажи) и тренингов.
На главной странице находится список наиболее полезных книг о тестировании.
Электронную версию моей книги вы по-прежнему можете приобрести.
Также доступна аудиозапись о введение в тестирование - бесплатно.
Добавились услуги тестирования команды профессиональных тестировщиков.
Сообщения в блоге скорее всего будут появляться, но не часто.
Вы можете подписаться на них как по RSS, так и по e-mail.
You can comment here or there.
С Наступающим Новым Годом, коллеги!
Желаю вам добиться своих целей, не забывая о радостях жизни!
P.S. Все праздники буду вне сети, поэтому сайт обновлю только в январе. Как будет выглядеть в точности не решил. Пожалуй, в продаже останется только моя электронная книга.
Original published at Блог Тестировщика.You can comment here or there.
С Наступающим Новым Годом, коллеги!
Желаю вам добиться своих целей, не забывая о радостях жизни!
P.S. Все праздники буду вне сети, поэтому сайт обновлю только в январе. Как будет выглядеть в точности не решил. Пожалуй, в продаже останется только моя электронная книга.
Original published at Блог Тестировщика.You can comment here or there.
Итак, о насущном.
Слово “кризис” слышать уже сильно поднадоело. Тем не менее в блоге об этом написать стоит.
Тезисно:
1) Большинства из нас кризис коснулся\коснётся (как бы не тешили себя надеждами IT-шники, что кризис не для них).
2) Причины этого явления (а еще важнее - </b>последствия</b> ) нужно хотя бы примерно осознавать (эта информация может непосредственно быть полезной рядовому сотруднику). Хорошо и подробно эта тема разбирается на форуме Авантюриста. Читать тысячестраничные топики дело неблагодарное, поэтому гораздо интереснее выжимка мыслей - FAQ.
3) В кризис работать очень некомфортно - доходы сокращаются, объем работы и напряженность - возрастают.
4) Несмотря на п.3 главный совет для большинства - не дергаться в поисках лучшей доли. Обстановка будет только ухудшаться. Смена работы в таком случае может обернуться быстрым увольнением (с новым работником расстаться психологически гораздо проще, чем со старым зарекомендованным). Поэтому лучший выход - закрепить свои позиции на текущем месте работы.
5) О смене работы - все же есть несколько ситуаций, когда она может быть выгодна:
5.1. У вас есть хорошие запасы, чтобы переждать год-два (можно отдыхать и саморазвиваться).
5.2. Вы можете рисковать (стабильность роли не играет, есть запасы на жизнь в течение 3-6мес) - известно, что кризис - это не только негатив, но и время больших возможностей. Работа в динамичной перспективной компании в таком случае может вынести вас на вершину волны.
5.3. Вы на плохом счету на текущем месте работы.
6) О п. 5.3 - очень полезно анализировать ситуацию на вашей работе - и делать выводы заранее. О признаках, по которым можно отследить своё будущее увольнение, хорошо пишет Макс Крайнов - Когда катятся головы.
Также его статьи: Стратегия выживания в кризисе,
Кризис и потеря/смена работы.
7) Не забывайте о саморазвитии даже в этот тяжелый период. Рано или поздно обстановка наладится, и тогда вас ожидает взрывной рост.
Original published at Блог Тестировщика.You can comment here or there.
Простите за долгое отсутствие на блоге.
Много чего происходит: и кризис, и приближение Нового Года.
Впрочем, о кризисе я еще скажу пару слов.
А сейчас о НГ.
Кроме планирования праздников и отдыха (что тоже немаловажно!), я считаю необходимым большое внимание уделить подведению итогов уходящего года, а также составлению планов на год следующий.
Относительно своих планов - могу сказать, что большинство намеченных целей было достигнуто (или почти достигнуто). Что же касается этого проекта - то в планах на следующий год он у меня отсутствует.
Посему - объявляю распродажу!
Систему к НГ вы можете приобрести всего за 2900руб!
Но есть 3 оговорки:
1) она не будет включать в себя консультации;
2) скидка действует только при заказе до 30 декабря 2008г;
3) все гарантии на Систему и мои обязательства по ней остаются в силе несмотря на то, что после НГ Система продаваться больше не будет.
Блог оставляю открытым. По мере настроения иногда буду писать.
You can comment here or there.
Вы можете приобрести книгу целиком и сразу в электронном виде (99руб) или сделать предзаказ бумажной книги (250руб).
Заключение
Что Вы узнали из этой книги?
В этой книге Вы познакомились с видами программного обеспечения, операционными системами, клиент-серверной технологией.
Вы узнали основы языка запросов SQL.
Вы поняли, что такое тестирование ПО, его цели и задачи.
Кроме того, Вы узнали и о практике тестирования, о его реалиях.
Я познакомил Вас с тестировщиком – кто он, как он думает, чем занимается.
Я рассказал о документации тестировщика.
Вы узнали о видах тестирования, его классификациях.
Вы прочли обзор инструментов тестирования.
Теперь Вы знаете и что такое автоматизация.
Я рассказал об отчетности, как важной составляющей работы тестировщика.
После прочтения этой книги Вы имеете начальное представление о сфере тестирования программного обеспечения. Теперь Вы можете решить – интересна Вам эта область или она не для Вас. А если же интересна – то Вы узнали основные вещи, необходимые для работы в тестировании.
Если Вы хотите узнать что-то еще о тестировании ПО, добро пожаловать на мой сайт: www.softwaretesting.ru , а также на мой блог: www.softwaretesting.ru/blog .
C вопросами и предложениями обращайтесь на support@softwaretesting.ru .
Вы можете приобрести книгу целиком и сразу в электронном виде (99руб) или сделать предзаказ бумажной книги (250руб).
You can comment here or there.
Вы можете приобрести книгу целиком и сразу в электронном виде (99руб) или сделать предзаказ бумажной книги (250руб).
Тезисы к главе №6
- Написать хороший отчет - очень важно.
- Количество заявленных дефектов не должно превосходить их качество.
- Перепроверяем дефекты, прежде чем о них заявить.
- Если обнаружили ошибку – сразу же по ней отчет!
- Обращаем внимание на минорные баги.
- Регистрируем невоспроизводимые ошибки.
- Один баг – один отчет.
- Схема отчета.
- Задача тестировщика – найти и описать проблему.
Вы можете приобрести книгу целиком и сразу в электронном виде (99руб) или сделать предзаказ бумажной книги (250руб).
You can comment here or there.
Вы можете приобрести книгу целиком и сразу в электронном виде (99руб) или сделать предзаказ бумажной книги (250руб).
Домашнее задание.
Каждый из этих трех дефектов должен иметь свой тип: ошибка кодирования, предложение, расхождение с документацией.
По одному дефекту на каждый из этих типов.
Достаточно написать заголовок проблемы, ее описание, шаги воспроизведения и вывод.
Можно написать и предлагаемое исправление.
Вы можете приобрести книгу целиком и сразу в электронном виде (99руб) или сделать предзаказ бумажной книги (250руб).
You can comment here or there.
Вы можете приобрести книгу целиком и сразу в электронном виде (99руб) или сделать предзаказ бумажной книги (250руб).
Если Вы хотите заработать себе дополнительный очки, авторитет, то можно писать предлагаемое исправление.
Если Вы понимаете, как это должно функционировать – написать кусок кода, то это неплохо. Но с этим надо быть аккуратным, смотреть, как это принято в Вашей компании. Если такое предложение будет воспринято негативно, то в будущем лучше воздерживаться от такого пункта описании. Если же будет похвала – естественно продолжаем в том же духе. Если промолчали – то все равно, это наверняка, кто-то видел, можно сказать – молчаливо одобрил.
Это можно практиковать, самому решать найденные проблемы.
Но приоритет в Вашей работе для этого должен быть самым низким.
Главное внимание уделяете тому, чтобы найти ошибки и их описать.
Претендовать на роль эксперта не нужно. Не стоит пытаться выглядеть крутым экспертом, который умеет и тестировать, и писать код лучше разработчиков. Смотреть свысока на программистов тоже не надо. Просто можно в качестве помощи предлагать Вашу точку зрения на исправление проблемы.
Прежде чем заявить ошибку, при возможности – скажите о ней программисту лично.
Если Вы не уверены, что это ошибка – Вы заодно выясните это. Может быть, Вы неправильно установили программу, не зарегистрировали какие-то библиотеки, эти сомнения Вам поможет развеять программист. Такое общение сэкономит Вам много времени, т.к. после заявления бага, пока он проходит по всем инстанциям, по всем участникам процесса – может пройти до нескольких суток. Это задержка времени, и если эта задержка времени необоснованна, если она произошла по Вашей вине – это не очень здорово. Поэтому если есть сомнения или хотя бы подозрения – лучше спросить программиста.
Естественно, по мелочам бегать и отвлекать не надо, но по серьезным вещам это допускается и даже поощряется.
Тестировщик использует в своей работе целую систему по отчетности и документированию ошибок.
Это система баг-треккинга – система отслеживания ошибок.
Очень удобная программа, которая осуществляет доступ к хранилищу информации о зарегистрированных дефектах.
С ее помощью всегда можно посмотреть зарегистрированные ошибки по программе, какие из них еще не исправлены. Можно посмотреть какие из ошибок исправлялись и сколько раз, чтобы учесть это при регрессионном тестировании.
Вы можете приобрести книгу целиком и сразу в электронном виде (99руб) или сделать предзаказ бумажной книги (250руб).
You can comment here or there.
Вы можете приобрести книгу целиком и сразу в электронном виде (99руб) или сделать предзаказ бумажной книги (250руб).
Как должен выглядеть отчет?
Схема:
1)Заголовок.
Одним предложением, одной строкой пишем самое важное: специфика ошибки, ее пределы, ее влияние. Надо писать так, чтобы по заголовку можно было примерно понять, что это за ошибка, в какой области программы она содержится.
>2)Реальный приоритет ошибки.
Не надо драматизировать обстановку, чтобы на Вас обратили внимание или, наоборот, скромничать, недооценивать ситуацию. Это приходит с опытом.
Обычно приоритет, серьезность ошибки делятся на 3 класса: 1) фатальные ошибки – критические, при которых программа просто падает, либо не работают важнейшие функции программы; 2) серьезные дефекты, когда некорректно работает, например, одна функция программы; 3) незначительные, минорные баги – недочеты, неточности, мелкие ошибки.
3)Описание ошибки.
Подробно, пошагово описываем ошибку – краткий и понятный список шагов, которые приводят к сбою.
Кстати, сбой – это не ошибка.
Сбой – это то, что мы видим, когда происходит ошибка. Ошибка – это причина сбоя, это то, что его вызвало. Например, ошибка кодирования - неправильно написан оператор в коде программы, в результате чего происходит сбой.
4)Результат.
Напишите, что произошло в результате выполнения шагов из предыдущего пункта, а также что Вы ожидали, что произойдет. Должен присутствовать в описании краткий вывод, краткий результат.
Решать проблему – не Ваша задача.
Вы тестировщик и Ваша задача – найти проблему и ее описать.
Решать проблему – хлеб программиста, если это ошибка кодирования, либо хлеб аналитика, технического писателя – если это ошибка в требованиях, инструкции.
Главное – найти ошибку и ее описать.
Вы можете приобрести книгу целиком и сразу в электронном виде (99руб) или сделать предзаказ бумажной книги (250руб).
You can comment here or there.
Вы можете приобрести книгу целиком и сразу в электронном виде (99руб) или сделать предзаказ бумажной книги (250руб).
Также надо регистрировать и невоспроизводимые ошибки.
Существует такой класс ошибок, которые трудно воспроизвести. Каким-то образом Вы наткнулись на ошибку, а затем воспроизвести ее не получается. Непонятно, при каких условиях она возникает.
Если у Вас есть много времени, лучше ее локализовать, обнаружить условия, при которых она возникает. Но если всё-таки не выходит, или для этого требуются большие ресурсы, или большие временные затраты, тогда надо писать отчеты о невоспроизводимой ошибке.
Такие ошибки надо регистрировать, и не надо забывать о них. В качестве доказательства используем либо запись, либо скриншот, т.к. для заявления таких ошибок должно быть какое-либо доказательство.
Может быть множество различных ситуаций, и лучше понять причину ошибки. Если же не получается, всё равно невоспроизводимые баги мы регистрируем!
При формировании отчета по багу, лучше делать на каждую ошибку отдельный отчет.
Один баг – один отчет.
Иначе получается путаница, когда в одном отчете заявлено несколько ошибок. Потом они исправляются не пакетом, а по отдельности.
Одну исправили – потом эта проблема перенаправляется друг другу, возникает путаница. Лучше таких ситуаций избегать, но если всё же она возникла, то при исправлении хотя бы одного дефекта внутри этого отчета, надо этот отчет закрыть, а оставшиеся неисправленными ошибки заявить в новые отчеты, со ссылкой на старый.
Вы можете приобрести книгу целиком и сразу в электронном виде (99руб) или сделать предзаказ бумажной книги (250руб).
Original published at Блог Тестировщика.You can comment here or there.
Вы можете приобрести книгу целиком и сразу в электронном виде (99руб) или сделать предзаказ бумажной книги (250руб).
Количество не должно довлеть над качеством.
Поэтому сомнительные баги лучше несколько раз перепроверить. «Семь раз отмерь – один отрежь!».
Если Вы не уверены, что ошибка – это, действительно, ошибка программы, то лучше проверьте еще раз. Такие ситуации встречаются довольно часто.
Например, программа работает с базой данных. Ошибка может быть не в самой программе, а в наборе входных данных, которые содержатся в базе. В таком случае сходу можно не понять, подумать, что это ошибка программы, но в дальнейшем выяснится, что тестирование проводилось на некорректных данных, а поэтому – регистрация дефекта необоснованна.
Поэтому лучше несколько раз перепроверить, прежде чем регистрировать дефект.
Лучше спросить непосредственно у исполнителя, или у того, кто разрабатывает требования для ПО, у тех, кто в курсе, как именно должна работать программа. После того, как Вы это выясните, Вам будет намного проще понять, действительно ли найденная ошибка является ошибкой программы.
Откладывать найденные дефекты в долгий ящик не надо!
Даже если исполнителя нет на рабочем месте, дефект откладывать не надо. Он либо забудется, либо так и останется лежать в ящике, потому что у Вас появились новые срочные дела. Дефект будет похоронен. Если не у кого спросить, то лучше дефект зарегистрировать, чем его отложить.
Если обнаружили ошибку – сразу же по ней отчет!
Естественно, выяснив подробности, если не уверены. Не надо откладывать ошибки, потому что они очень быстро забываются.
Иногда Вы будете чувствовать, что Вы боитесь зарегистрировать ошибку.
Бывают ситуации, когда тестировщик подвергается критике за то, что регистрировал ошибки, которые на самом деле таковыми не являлись. Тогда у некоторых тестировщиков возникает чувство боязни.
На самом деле, это чувство губительно для тестировщика!
Если Вы ему поддадитесь, это будет означать Вашу профессиональную смерть.
Надо учитывать критику, но не боятся регистрировать новые ошибки.
В этом случае лучше переусердствовать, чем наоборот.
Также надо обращать внимание и на мелкие ошибки, минорные баги.
Они оказывают влияние на удовлетворенность потребителя. Когда мелочи в интерфейсе, в оформлении раздражают пользователя, в конечном счете это губительно сказывается и на спросе продукта. Так что мелочей в нашем деле не бывает.
Мелкие баги тоже надо регистрировать, просто указывать соответствующую степень важности, серьезность ошибки.
Не надо путать серьезность ошибки и приоритет ее исполнения. Это разные вещи. Ошибка может быть серьезной, но отложена к исполнению. Или наоборот ошибка может быть мелкой, но исправить ее надо срочно.
Вы можете приобрести книгу целиком и сразу в электронном виде (99руб) или сделать предзаказ бумажной книги (250руб).
Original published at Блог Тестировщика.You can comment here or there.
Вы можете приобрести книгу целиком и сразу в электронном виде (99руб) или сделать предзаказ бумажной книги (250руб).
Глава № 6 – Отчеты об ошибках.
Как написать хороший отчёт и заслужить себе авторитет.
Эта глава посвящена отчетности об ошибках.
Отчетность - важная часть любой работы, в частности - тестировщика. Тестировщику зачастую необходимо отчитаться о проведенном тестировании продукта.
Написать хороший отчет - очень важно.
Если представить себе необработанный алмаз – он выглядит не очень привлекательно, по крайней мере, не впечатляет. А ограненный – становится настоящей драгоценностью.
Так и с работой.
Когда Вы уже нашли ошибки, дефекты – Ваша самооценка как тестировщика повышается. Вы уже понимаете, что на что-то способны и чего-то стоите. Но если проделанную работу еще и правильно преподнести, она ценится намного больше. Как ограняют алмаз, так и Вы ограняете свою работу в красивый, хороший и подробный отчет.
Судить о Вашей работе будут именно по Вашему отчету. Когда всё красиво, понятно и подробно изложено, тогда и работа выглядит более полно и правильно проделанной. Она выглядит более привлекательно.
Зачастую бывает ситуация, когда о проделанной работе судят не только по отчетам, но и по количеству заявленных дефектов.
Считается, что чем больше багов заявлено, тем лучше.
Этот подход не очень правильный.
Встречаются различные ситуации. Возможно, программа уже хорошо протестирована и отлажена, тогда в ней будет обнаружено мало ошибок, даже при большом объеме проделанной работы.
Напротив, возможно, программа новая, абсолютно не протестирована. По ней будут заявляться сотни мелких, незначительных багов.
В таком случае один критический баг, найденный в отлаженной версии программы, стоит сотни мелких багов, найденных в новой версии программы, которые очень сомнительны или вообще мало влияют на работоспособность программы.
Вы можете приобрести книгу целиком и сразу в электронном виде (99руб) или сделать предзаказ бумажной книги (250руб).
Original published at Блог Тестировщика.You can comment here or there.
Вы можете приобрести книгу целиком и сразу в электронном виде (99руб) или сделать предзаказ бумажной книги (250руб).
Тезисы к главе №5
Когда целесообразно применять автоматизацию.
Стратегия автоматизации, требования к тестированию.
Автоматизация далеко не всегда хороша!
Минусы автоматизации на примере регрессионного тестирования.
Скорость, надёжность и масштабируемость как плюсы автоматизации.
Инструменты тестировщика.
Вы можете приобрести книгу целиком и сразу в электронном виде (99руб) или сделать предзаказ бумажной книги (250руб).
Original published at Блог Тестировщика.You can comment here or there.
Вы можете приобрести книгу целиком и сразу в электронном виде (99руб) или сделать предзаказ бумажной книги (250руб).
Теперь я хочу сделать небольшой обзор рынка инструментов тестирования, которые широко используются в среде тестировщиков. Например, продукты IBM Rational.
Итак, Rational Robot – с его помощью проводим функциональное тестирование, которое выполняется на основе объектно-ориентированной технологии.
С помощью Robot тестируются свойства объектов, в том числе и скрытые. С его помощью мы можем протестировать логику работы приложения через пользовательский интерфейс (использование GUI – скриптов ), а также выполнить нагрузочное тестирование (VU –virtual users скрипты ).
Rational Functional Tester – название говорит само за себя.
Это средство автоматизации функционального тестирования.
Это пакет программ, который включает в себя и Rational Manual Tester – средство проведения ручного тестирования.
Functional Tester тестирует приложения на Java, а также с его помощью можно протестировать Web приложения. Тестовый сценарий также пишется на Java.
IBM Rational Perfomance Tester – средство функционального и нагрузочного тестирования.
С его помощью мы можем выявлять проблемы производительности еще до того, как мы выпустили продукт. До развёртывания мы можем эффективно оценить его производительность приложения.
Он предназначен для тестирования Web – приложений. Тесты представляют собой записи – как пользователь выполняет действия в браузере. Для пользования Perfomance Tester не требуется знание программирования. Достаточно простой и удобный в пользовании продукт.
IBM Rational XDE Tester – с его помощью тестируем Java-приложения и Web- сайты. В качестве языка тестовых сценариев опять же используем Java.
IBM Rational Purify Plus – пакет программ, включающий в себя: Purify, Pure Coverage, Quantify.
Rational Purify тестирует программу на наличие runtime – ошибок. С его помощью также можно отследить утечки памяти.
Purify тесно интегрируется с Pure Coverage.
C помощью Rational Pure Coverage мы находим те участки кода в программе, которые не были затронуты при тестировании. Т.е. программа отслеживает, что при тестировании проверяется в коде. Те участки, которые не были проверены, обнаруживаются.
Quantify позволяет собирать информацию: время исполнения функций, статистику обращения к функциям. Анализируя эту информацию, можно на основании того, как долго выполняется тот или иной участок кода, делать выводы, что и где оптимизировать.
Rational Test Manager – этот продукт помогает нам управлять тестированием в целом. Из одной графической оболочки мы управляем всем процессом тестирования. Можно писать тест-планы, все члены рабочей группы могут вносить в него сценарии. Все данные хранятся в унифицированном виде.
Последнее в списке, но не последнее по важности - Rational Clear Quest – баг-треккинг система (система отслеживания ошибок).
В этой системе мы регистрируем ошибки, описываем их, по каждой ошибке вводим подробную информацию. Затем зарегистрированные дефекты проходят через всех людей, участвующих в жизненном цикле бага.
На рынке также есть очень популярные продукты – от HP Mercury, Borland (Segue), AutomatedQA, Compuware.
Если подытожить, то по функциональному тестированию – существует WinRunner и Quick Test Professional от Mercury, Robot и Functional Tester от Rational, Silk Test от Segue, TestComplete от AutomatedQA, TestPartner от Compuware.
Для нагрузочного тестирования – LoadRunner от Mercury, от Rational есть Robot и PerfomanceTester.
</div>
Вы можете приобрести книгу целиком и сразу в электронном виде (99руб) или сделать предзаказ бумажной книги (250руб).
Original published at Блог Тестировщика.You can comment here or there.
Вы можете приобрести книгу целиком и сразу в электронном виде (99руб) или сделать предзаказ бумажной книги (250руб).
Стратегия автоматизации.
Во-первых, надо определить требования к тестированию. А они в автоматизации таковы, что – надо:
1)автоматизировать проверку ключевых функций;
2)проанализировать архитектуру программного обеспечения: какие существуют компоненты программы, какие функции, как они между собой связываются. Отсюда выявить возможность автоматизации – насколько она будет целесообразна;
3)учесть опыт тестирования, т.к. различные программные продукты требуют различного уровня, опыта тестировщика. Если тестировщик создаст сложный скрипт автоматизации, то не факт, что менее опытный затем в нем сможет разобраться и его повторить, правильно проанализировать его результаты.
Советы:
- Не надо пытаться автоматизировать всё. Болезнь автоматизации присуща программистам. На самом деле, автоматизация далеко не всегда хороша!
- Автоматизация не заменяет ум, интеллект тестировщика. Она только помогает сделать тестирование более быстрым, надёжным и т.д. Но ум она никогда не заменит!
- Автоматизации не всегда следует доверять. Во-первых, скрипт может быть написан ошибочно. Во-вторых, скрипт может устареть. Программа изменилась, обновилась, дополнилась – и скрипт уже может не работать вовсе или работать некорректно.
В регрессионном тестировании автоматизация находит лишь 15% ошибок от их общего количества.
В конфигурационном же тестировании с помощью автоматизации выявляют от 30 до 80 процентов ошибок.
Поэтому
- В конфигурационном тестировании крайне рекомендуется использовать автоматизацию.
- После обнаружения бага с помощью автоматизированных средств, обязательно проверьте его вручную!
Проверьте, действительно ли имеет место быть найденная ошибка, возможно, ошибки в программе нет, а что-то не в порядке с автоматизированным тестом.
У автоматизации есть довольно много минусов.
Особенно это показательно на регрессионном тестировании.
- При изменение в программе, тест уже не понимает, где произошло улучшение – дополнение, нововведение, а где ошибка.
- При изменении компонентов в программе, ресурсов – тест будет выдавать ошибки.
- Если ошибка неверно определяется в автоматизированном скрипте, тогда она влечет за собой другие «ошибки», которые на самом деле ошибками не являются. Это может внести значительную сумятицу в процесс тестирования.
- Оператор теста должен обладать соответствующими знаниями: как использовать тест, как его конфигурировать, как его анализировать. Если оператора сменить, то результат автоматизации получится совсем другой.
Вы можете приобрести книгу целиком и сразу в электронном виде (99руб) или сделать предзаказ бумажной книги (250руб).
Original published at Блог Тестировщика.You can comment here or there.
Вы можете приобрести книгу целиком и сразу в электронном виде (99руб) или сделать предзаказ бумажной книги (250руб).
Глава № 5 – Автоматизация и инструменты тестирования.
Сделай свою работу более интеллектуальной!
Сэкономь время с автоматизацией!
Сегодня я расскажу в общих чертах об автоматизации. Упомяну некоторые продукты, которые существуют на рынке.
Что автоматизируют прежде всего?
Автоматизируют прежде всего smoke – тесты, о которых я уже много говорил, т.е. тесты, которые быстро проверяют основы функциональности программы.
От версии к версии программы всегда будет тестирование основных ключевых функций. Поэтому если программа регулярно обновляется, дополняется и изменяется, то лучше автоматизировать такие тесты. Их потом можно расширять, добавлять, но главное – автоматизировать проверку основных функций.
Как понять, целесообразно ли использовать автоматизацию?
Надо посмотреть, сколько времени занимает создание автоматизированного скрипта, а сколько Вы тратите на ручное тестирование времени в сумме.
Один раз протестировали вручную, вышла следующая версия программы, следующий билд, и Вы снова протестировали программу. Сколько раз Вам понадобится сделать это вручную? Сколько в общем времени это займет?
На другую чашу весов положите – сколько времени займет создание автоматизированного скрипта.
Также надо учесть опыт тестировщика.
Не каждый тестировщик знаком с автоматизацией.
Также надо учитывать стоимость программ, которые помогут автоматизировать скрипт. Стоимость может колебаться от сотен долларов до тысяч и даже десятков тысяч вечнозеленых.
В среднем, если тест нужно повторить более 10 раз, то его, как правило, автоматизируют. Это получается проще и выгоднее.
В каких еще случаях полезна автоматизация?
Обычно ее используют в юнит-тестах, в модульном тестировании, когда на проверку каждой отдельной функции есть свой автоматизированный скрипт, свой тест. Это очень удобно, т.к. юнит-тестирование проводится после выхода каждой версии, изменении каждой функции.
Совершенно необходима автоматизация в нагрузочном тестировании.
Представьте, что Вам надо смоделировать одновременное подключение нескольких сотен пользователей. Скажем, 500 человек подключаются к серверу одновременно.
В реальности создать такую ситуацию довольно проблематично, особенно если версия еще не вышла в массы, а находится на стадии тестирования внутри компании. С помощью средств автоматизации это сделать довольно просто.
В конфигурационных тестах очень полезно применение автоматизации.
Когда мы выполняем тестирование на отдельной конфигурации, его можно сделать вручную. Бывают ситуации, когда надо масштабировать до 10 конфигураций: различные операционные системы, различная среда окружения, различные браузеры, различное аппаратное обеспечение. В этом случае проще сделать автоматизированный тест, привязать его к интерфейсу и запустить на разных конфигурациях. Тестирование будет проходить намного быстрее, проблем с ним будет меньше.
Тестирование в течение долгого времени (endurance test) – еще один кандидат на автоматизацию.
В комплексном тестировании, когда тестируются различные функции в различных комбинациях, также можно применить автоматизацию.
Вы можете приобрести книгу целиком и сразу в электронном виде (99руб) или сделать предзаказ бумажной книги (250руб).
Original published at Блог Тестировщика.You can comment here or there.
Вы можете приобрести книгу целиком и сразу в электронном виде (99руб) или сделать предзаказ бумажной книги (250руб).
Тезисы к главе №4.
- Статическое и динамическое тестирование.
- тестирование черного ящика. Цель - проверить расхождение поведения программы с документацией.
- Тестирование белого ящика. Цель – проверить код.
- тестирование серого ящика.
- Восходящая и нисходящая стратегии тестирования.
- Классификация по уровням тестирования: модульное, интеграционное, системное.
- Регрессионное тестирование.
- Конфигурационное тестирование.
- Usability – тестирование.
- Приёмочное тестирование.
- Тестирование производительности.
- Нагрузочное тестирование.
- Объёмное тестирование.
- Стресс – тестирование.
Вы можете приобрести книгу целиком и сразу в электронном виде (99руб) или сделать предзаказ бумажной книги (250руб).
Original published at Блог Тестировщика.You can comment here or there.
Вы можете приобрести книгу целиком и сразу в электронном виде (99руб) или сделать предзаказ бумажной книги (250руб).
Приёмочное тестирование – это тестирование продукта на соответствие требованиям. Требования могут выдвигаться заказчиками. Если же заказчика нет, то в его качестве можно представить себя, ведь определенные требования к продукту всегда существуют. Программный продукт обязан проходить приёмку.
Продукт создан с какой-то определенной целью, имеет определенные функции, должен выполнять предписанные требования. Есть ожидания, которым он должен соответствовать. Поэтому нужно проверить основной функционал, соответствие основным требованиям. Для этого проводят приёмочное тестирование, которое также называют функциональным. Здесь очень хорошо работает автоматизация, когда каждую версию автоматически проверяют на соответствие основным требованиям.
Лучше, чтобы такие тесты включали только ожидания заказчиков. Не надо концентрироваться на механизмах реализации. Не надо зацикливаться на языке программирования, на том, какая база данных используется, какая архитектура. В таком случае, при каждом изменении реализации, придётся менять и тесты.
Лучше отталкиваться от ожиданий, они меняться не будут, поэтому тестирование будет проводить гораздо проще. Один раз создается тест, а затем много раз прогоняется при приёмке каждой версии.
Теперь рассмотрим нагрузочное тестирование или тестирование производительности.
Иногда эти виды тестирования разделяют, иногда включают друг в друга, но наиболее удачными формулировками я считаю такие.
Тестирование производительности – тестирование системы при идеальных условиях и максимальной нагрузке. Наверняка вы видели тесты производительности, например, обзоры аппаратной части компьютера (процессоров, видео-карт, жестких дисков и др.) на www.ixbt.com, когда в качестве нагрузки работают программные приложения, после чего анализируются получаемые результаты.
Нагрузочное тестирование – это то же самое, что тестирование производительности, за исключением того, что система подвергается различным нагрузкам.
Цель этого вида тестирования – определить, как поведет себя система в случае, когда планируемая нагрузка превышена.
Объёмное тестирование – тестирование при большом количестве данных.
Его цель – определить, при каких объёмах данных система перестаёт работать.
Стресс – тестирование – тестирование при недостатке ресурсов, когда не хватает ресурсов железа, например, оперативной памяти, места на жестком диске, ширины пропускного канала сети и т.д.
Как правило, тестирование производительности делают на стадии тестирования жизненного цикла продукта. Меряют максимальную нагрузку: сколько пользователей может подключиться к программе, как она себя ведет при увеличении нагрузки.
Но этот вид тестирования желательно проводить и на других стадиях разработки продукта.
На проектной стадии нужно выбирать язык программирования, базу данных, ее архитектуру, исходя из требуемой производительности.
Затем, на стадии программирования, необходимо определиться, как строить базу данных, например, на таблицах, либо на представлениях. Что оптимизировать в первую очередь.
Ответы на эти вопросы даёт тестирование производительности.
После стадии тестирования следует поставка продукта. На этом этапе надо учитывать настройки и архитектуру сети, где будет использоваться программный продукт.
Поэтому тестирование производительности имеет большую важность и выполняется всегда, хоть и часто ограничивается лишь стадией тестирования.
В результате тестирования производительности, она либо удовлетворяет требованиям, либо ее нужно увеличить.
Увеличивают обычно двумя способами: либо улучшают аппаратную часть – железо (добавляют оперативку, ширину канала и т.д.), либо усовершенствуют, оптимизируют код, чтобы приложение работало быстрее.
Метод тестирования производительности: запускают несколько потоков с определенными запросами и фиксируют время их выполнения. Данной методики обычно достаточно.
Вы можете приобрести книгу целиком и сразу в электронном виде (99руб) или сделать предзаказ бумажной книги (250руб).
Original published at Блог Тестировщика.You can comment here or there.
Profile
![[info]](http://l-stat.livejournal.com/img/userinfo.gif)
software_tester- Тестирование Программ Как Стиль Жизни
- Тестирование программ
Syndicate
