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

Тест, который мы вам предложим, основан на тесте швейцарского психолога Германа Роршаха . В его основе лежали 10 аморфных пятен-клякс, которые предлагалось рассмотреть испытуемым. Вариации этого визуального теста широко известны. И сегодня подобные задания используют в самых разных целях, начиная от диагностики депрессии и заканчивая проверкой на силу воображения.

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

Картинка-основа нашего теста выглядит так.

А теперь узнаем результаты и проверим, кто настроен на позитивное и созидательное начало, а кому пора избавляться от негативной энергетики .

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

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

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

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

Краб. Краб, рак или другое членистоногое (возможно, даже паук или осьминог). Эту ассоциацию трудно отнести к приятной, однако не спешите делать выводов. Прислушайтесь к себе. Если розоватое, крабообразное пятно вызывает у вас мысли о крабе где-нибудь на лазурном побережье, скорее всего, вы обладаете богатой фантазией, но ни о чем тревожном эта ассоциация не говорит. А вот если чувства, которые вызваны у вас подобным сходством, негативны (вы боитесь клешней, вам неприятны жвала, которые воображение уже нарисовало за вас) — время задуматься и настроиться на позитивную волну .

Головы. Головы диких животных, горгулий, бычья голова — все это довольно угрожающие символы. К этой же категории можно отнести маску. Подобное деление на части может быть вызвано внутренним разладом.

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

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

Желаем вам удачи в познании своей личности и внутреннего Я. Заглядывайте в и не забывайте нажимать на кнопки и

12.10.2016 03:32

Всем известно, что события, происходящие с нами, во многом обусловлены нашими мыслями. И даже если...

Статья была переработана с учётом полученной в форуме критики и рекомендаций.

Этой статьей я хотел бы описать своё понимание тестирования программного обеспечения - процесса не тривиального, как мне всегда казалось, и, я даже не мог себе представить, весьма интересного.

Меня всегда интересовало, что такое тестирование ПО. Зачем нанимать кого-то для тестирования программного продукта, если разработчик и сам может потратить пару часов на такое не значительное по приоритету задание. И, наконец-то, зачем вообще тестировать? Ведь программисты ребята умные - пишут правильно. Но

не все так просто как мне казалось.

Перейдя из программистов в тестеры, не имея достаточного количества теории за пазухой, я достаточно долго пытался «поломать» программный продукт, давая на вход заведомо неверные входные данные. И, как не странно, ломалось. Создавалось сообщение об ошибке, и очередной день считался прожитым не зря.

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

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

1. Изучение спецификации. Эта стадия самая важная, её ещё называют анализом дизайна и/или требований. Иногда применяют название «тестирование спецификации», чуть ниже мы поймём, почему именно «тестирование». Тут надо внимательно прочитать документацию (спецификацию) по приложению.
2. Дымовое тестирование. На этой стадии надо проверить работает ли система вообще (правильно ли работает, правильно ли «ругается» при не правильной отработке и т.д.). Это делается для того, чтоб понять пригодно ли приложение для дальнейшего тестирования или оно вообще не работает (работает не правильно).
3. «Позитивное» тестирование. На этой, третей стадии, надо проверить результат работы приложения при получении им «правильных» входных данных.
4. «Негативное» тестирование. Это четвертая, завершающая, стадия начального тестирования. Тут надо посмотреть, как ведет себя приложение, получая на вход «неправильные» данные. Это делается для того, чтоб определить, как ведет себя приложение в таком случае. Если такой вариант описан в спецификации, а он должен быть описан, то сравнить ожидаемый результат с полученным результатом.

Итак, рассмотрим все по порядку.

Спецификация, требования, SRS.

Как определить когда и как должно работать само приложение, когда и как оно должно «ломаться» (то есть как система или её модуль должен реагировать на невалидные данные или неверное поведение пользователя)? Что должно быть в результате правильной отработки, при каких условиях и входных данных правильная отработка должна иметь место? Что должно быть в результате не правильной отработки тестируемого приложения, при каких условиях она должна иметь место?

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

Документация дает возможность понять для себя основные ступеньки проверки приложения, где и как должно приложение работать, где «ломаться». И, что не мало важно, как ломаться. Что «говорить» при успешной отработке, какие сообщения на ошибку могут/должны появляться при отработке.

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

Процесс тестирования

Этот процесс можно описать следующими шагами:

1. Проверить, как работает приложение, когда оно получает на вход «правильные» данные (чтоб узнать «что такое хорошо и что такое плохо» читаем документацию);
2. Если все работает и работает правильно (т.е. именно так как описано в спецификации), следующим шагом является проверка граничных значений (т.е. там, где начинаются «правильные» данные и там где они заканчиваются);
3. Проверка работы приложения при вводе данных, которые не входят в область допустимых значений (опять таки, смотрим спецификацию).

В первом и втором пункте описан процесс, который называется «позитивным» тестированием. «Позитивное» тестирование - это тестирование на данных или сценариях, которые соответствуют нормальному (штатному, ожидаемому) поведению тестируемой системы.

Третий же пункт описывает противоположный «позитивному» процесс - «негативное» тестирование. Это тестирование на данных или сценариях, которые соответствуют нештатному поведению тестируемой системы - различные сообщения об ошибках, исключительные ситуации, «запредельные» состояния и т.п.

Однако предшествовать «позитивному» и «негативному» тестированию должны работы по выполнению «дымового» тестирования.

Информационный словарь дает достаточно четкое определение термина «дымовое тестирование»:

• рудиментарная форма тестирования программного продукта после изменения его конфигурации либо после изменения его (программного продукта) самого. В процессе дымового тестирования тестировщик проверяет ПО на наличие «дыма», т.е. ищет какие-либо критические ошибки программы;
• первый запуск программы после её критического изменения или «сборки».

Приоритеты в тестировании

Почему «позитивное» тестирование считается на порядок более важным, чем «негативное»?

Предположим, что система не слишком устойчива к «плохим» вводимым данным. Это страшно? Зачастую не слишком. Пользователи рано или поздно научатся обходить «подводные камни», не будут делать «опасные» или «неразрешённые» действия, служба технической поддержки скоро запомнит, какие проблемы обычно возникают у пользователей и будет давать советы типа «ни в коем случае не оставляйте это поле пустым, а то...».

Но - всего этого не будет вовсе, если система не выполняет свое основное предназначение, если пользователи (заказчики) не могут решить свои бизнес задачи, если они все делают правильно, вводят хорошие данные, но не получают результата. И посоветовать им ничего в этой ситуации нельзя. И они уходят...

Именно поэтому «позитивное» тестирование гораздо, гораздо важнее «негативного».

Впрочем, это не означает, что «негативными» тестами можно пренебречь, т.к. не на всех этапах жизненного цикла ПО приоритеты ценностей сохраняются неизменными.

Резюме

Теперь, сделав первые удачные шаги в тестировании приложения и получив положительный результат, можно думать о более мудреных способах протестировать приложение, как говорится: «Дальше - больше». Все зависит от глубины необходимого уровня тестирования, желания и возможности проверить приложение. Естественно, описанные выше четыре стадии не покрывают полного цикла тестирования приложения, однако являются обязательными для начального тестирования.

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

По объекту тестирования

• · Функциональное тестирование. Функциональное тестирование на сегодняшний день является одним из наиболее часто применяемых видов тестирования. Задача такого тестирования - это установить на сколько соответствует разработанное программное обеспечение (ПО) требованиям заказчика с точки зрения функционала. Иначе говоря, проведение функциональных тестов позволяет проверить способность информационной системы решать задачи пользователей.
• · Нефункциональное тестирование. Позволяет проверить соответствие свойств программного обеспечения с поставленными нефункциональными требованиями. Таким образом, нефункциональное тестирование - это тестирование всех свойств программы, не относящихся к функциональности системы. Такими свойствами могут быть предъявленные характеристики с точки зрения таких параметров как:
• - Надежность (способность системы реагировать на непредвиденные ситуации).
• - Производительность (способность системы работать под большими нагрузками).
• - Удобство (исследование удобства работы пользователя с приложением).
• - Масштабируемость (возможность масштабировать приложение как вертикально, так и горизонтально).
• - Безопасность (исследование возможности нарушения работы приложения и кражи пользовательских данных злоумышленниками).
• - Портируемость (возможность перенести приложение на определенный набор платформ)

И много других качеств.

• · Тестирование пользовательского интерфейса. Это тестирование корректности отображения элементов пользовательского интерфейса на различных устройствах, правильности реагирования их на совершение пользователем различных действий насколько и оценка того, насколько ожидаемо ведет себя программа в целом. Такое тестирование дает возможность оценить, насколько эффективно пользователь сможет работать с приложением и насколько внешний вид приложения соответствует утвержденным документам, созданными дизайнерами. При проведении тестирования пользовательского интерфейса основной задачей тестировщика является выявление визуальных и структурных недостатков в графическом интерфейсе приложения, проверке возможности и удобства навигации в приложении и корректность обработки приложением ввода данных с клавиатуры, мыши и других устройств ввода. Тестирование пользовательского интерфейса необходимо для того, чтобы убедиться в том, что интерфейс соответствует утвержденным требованиям и стандартам, и гарантировать возможность работы пользователя с графическим интерфейсом приложения.
• · Тестирование удобства использования. Это способ тестирования, позволяющий оценить степень удобства использования приложения, скорость обучения пользователей при работе с программой, а также насколько пользователи разрабатываемого продукта находят ее понятной и привлекательной в контексте заданных условий. Такое тестирование необходимо для обеспечения максимально положительного пользовательского опыта при работе с приложением.
• · Тестирование защищенности. Позволяет выявить главные уязвимости программного обеспечения по отношению к различным атакам со стороны злоумышленников. Компьютерные системы довольно часто подвергаются кибер атакам с целью нарушения работоспособности информационной системы либо кражи конфиденциальных данных. Тестирование безопасности дает возможность проанализировать реальную реакцию и действенность защитных механизмов, использованных в системе, при попытке проникновения. В процессе тестирования безопасности тестировщик пытается выполнять те же действия, которые выполнял бы настоящий взломщик. При попытке тестировщиком взломать систему могут использоваться любые средства: атаки системы при помощи специальных утилит; попытки узнать логины и пароли с помощью внешних средств; DDOS атаки; целенаправленная генерация ошибок для обнаружения возможности проникновения в систему в процессе её восстановления; использование известных незакрытых уязвимостей системы.
• · Инсталляционное тестирование. Под этим термином подразумевают тестирование корректности установки (инсталляции) определенного программного продукта. Такое тестирование обычно происходит в искусственно созданных средах с целью выявить степень готовности программного обеспечения к эксплуатации. Основные причины проведения таких тестов связаны с необходимостью проверить корректность поведения программного продукта при автоматизированном развертывании либо обновлении. Обеспечение правильной и стабильной установки программного обеспечения является очень важным фактором при создании программного продукта, поскольку позволяет пользователям быстрее и с меньшими усилиями начать использовать продукт, при этом обеспечивая одинаково корректное поведение этого продукта во всех протестированных программных средах.
• · Конфигурационное тестирование. Конфигурационное тестирование предназначено для оценки работоспособности программного обеспечения при разнообразных конфигурациях системы. В зависимости от типа тестируемого программного продукта, конфигурационное тестирование может преследовать разные цели. Обычно это либо определение оптимальной конфигурации оборудования, обеспечивающего достаточные для работы ПО параметры производительности, либо проверка определенной конфигурации оборудования (или платформы, включающей в себя помимо оборудования, стороннее ПО, необходимое для работы программы) на совместимость с тестируемым продуктом. Если речь идет о клиент-серверном программном обеспечении, то конфигурационное тестирование проводится отдельно для сервера и отдельно для клиента. Обычно при тестировании совместимости сервера с определенной конфигурацией стоит задача найти оптимальную конфигурацию, поскольку важна стабильность работы и производительность сервера. В то время как при тестировании клиента, наоборот, пытаются выявить недостатки ПО при любых конфигурациях и по возможности устранить их.
• · Тестирование надежности и восстановления после сбоев (стрессовое тестирование). Такой вид тестирования довольно часто проводится для программного обеспечения, работающего с ценными пользовательскими данными, бесперебойность работы и скорость восстановления после сбоев которого критичны для пользователя. Тестирование на отказ и восстановление осуществляет проверку способности программы быстро и успешно восстанавливаться после отказа оборудования, перебоев сети или критических ошибок в самом программном обеспечении. Это дает возможность оценить возможные последствия отказа и время, необходимое для последующего восстановления системы. На основе полученных в ходе тестирования данных может быть оценена надежность системы в целом, и, при условии неудовлетворительных показателей, соответствующие меры, направленные на улучшение систем восстановления, могут быть приняты
• · Тестирование локализации. Тестирование локализации дает возможность выяснить насколько хорошо приспособлен продукт для населения определенных стран и насколько он соответствует ее культурным особенностям. Обычно, рассматриваются культурный и языковой нюансы, а именно перевод пользовательского интерфейса, сопутствующей документации и файлов на определенный язык, также тестируется правильность форматов валют, чисел, времени и телефонных номеров.
• · Нагрузочное тестирование. Нагрузочное тестирование позволяет выявить максимальное количество однотипных задач, которые программа может выполнять параллельно. Самая популярная цель нагрузочного тестирования в контексте клиент-серверных приложений - это оценить максимальное количество пользователей, которые смогут одновременно пользоваться услугами приложения.
• · Тестирование стабильности. Тестирование стабильности проверяет работоспособность приложения при длительном использовании на средних нагрузках. В зависимости от типа приложения, формируются определенные требования к длительности его бесперебойной работы. Тестирование стабильности стремится выявить такие недочеты приложения как утечки памяти, наличие ярко выраженных скачков нагрузки и прочие факторы, способные помешать работе приложения в течение длительного периода времени.
• · Объемное тестирование. Задачей объемного тестирования поставлено выявление реакции приложения и оценка возможных ухудшений в работе ПО при значительном увеличении количества данных в базе данных приложения. Обычно в такое тестирование входит:
• - Замер времени выполнения операций, связанных с получением или изменением данных БД при определенной интенсивности запросов.
• - Выявление зависимости увеличения времени операций от объема данных в БД.
• - Определение максимального количества пользователей, которые имеют возможность одновременно работать с приложением без заметных задержек со стороны БД.
• Тестирование масштабируемости. Это вид тестирования программного обеспечения, предназначенный для проверки способности продукта к увеличению (иногда к уменьшению) масштабов определенных нефункциональных возможностей. Некоторые виды приложений должны легко масштабироваться и, при этом, разумеется, оставаться работоспособными и выдерживать определенную пользовательскую нагрузку .

Тестирование, связанное с изменениями

• · Санити является одним из видов тестирования, целью которого служит доказательство работоспособности конкретной функции или модуля в соответствии с техническими требованиями, заявленными заказчиком. Санитарное тестирование довольно часто используется при проверке какой-то части программы или приложения при внесении в нее определенных изменений со стороны факторов окружающей среды. Данный вид тестирования обычно выполняется в ручном режиме.
• · Дымовое тестирование представляет собой короткий цикл тестов, целью которых является подтверждение факта запуска и выполнения функций устанавливаемого приложения после того как новый или редактируемый код прошел сборку. По завершении тестирования наиболее важных сегментов приложения предоставляется объективная информация о присутствии или отсутствии дефектов в работе тестируемых сегментов. По результатам дымового тестирования принимается решение об отправке приложения на доработку или о необходимости его последующего полного тестирования.
• · Регрессионное тестирование - тестирование, направленное на обнаружение ошибок в уже протестированных участках. Регрессионное тестирование проверяет продукт на ошибки, которые могли появиться в результате добавления нового участка программы или исправления других ошибок. Цель данного вида тестирования - убедиться, что обновление сборки или исправление ошибок не повлекло за собой возникновения новых багов .

По уровню тестирования

• · Модульное тестирование (Unit тесты). Заключается в проверке каждого отдельного модуля (самобытного элемента системы) путем запуска автоматизированных тестов в искусственной среде. Реализации таких тестов часто используют различные заглушки и драйверы для имитации работы реальной системы. Модульное автоматизированное тестирование - это самая первая возможность запустить и проверить исходный код. Создание Unit тестов для всех модулей системы позволяет очень быстро выявлять ошибки в коде, которые могут появиться в ходе разработки.
• · Интеграционное тестирование. Это тестирование отдельных модулей системы на предмет корректного взаимодействия. Основная цель интеграционного тестирования - найти дефекты и выявить некорректное поведение, связанное с ошибками в интерпретации или реализации взаимодействия между модулями.
• · Системное тестирование. Это тестирование программы в целом, такое тестирование проверяет соответствие программы заявленным требованиям.
• · Приемочное тестирование. Это комплексное тестирование, определяющее фактический уровень готовности системы к эксплуатации конечными пользователями. Тестирование проводится на основании набора тестовых сценариев, покрывающих основные бизнес-операции системы .

По исполнению кода

• · Статическое тестирование. Это выявление артефактов, появляющихся в процессе разработки программного продукта путем анализа исходных файлов, таких как документация или программный код. Такое тестирование проводится без непосредственного запуска кода, качество исходных файлов и их соответствие требованиям оцениваются вручную, либо с использованием вспомогательных инструментов. Статическое тестирование должно проводиться до динамического тестирования, таким образом, ошибки, обнаруженные на этапе статического тестирования, обойдутся дешевле. С точки зрения исходного кода, статическое тестирование выражается в ревизии кода. Обычно ревизия кода отдельных файлов производится после каждого изменения этих файлов программистом, сама же ревизия может проводиться как другим программистом, так и ведущим разработчиком, либо отдельным работником, занимающимся ревизией кода. Использование статического тестирования дает возможность поддерживать качество программного обеспечения на всех стадиях разработки и уменьшает время разработки продукта.
• · Динамическое тестирование. В отличии от статического тестирования, такой вид тестирования предполагает запуск исходного кода приложения. Таким образом, динамическое тестирование содержит в себе множество других типов тестирования, которые уже были описаны выше. Динамическое тестирование позволяет выявить ошибки в поведении программы с помощью анализа результатов ее выполнения. Получается, что почти все существующие типы тестирования соответствуют классу динамического тестирования .

По субъекту тестирования

• · Альфа-тестирование. Это тестирование проводится для самых ранних версий компьютерного программного обеспечения (или аппаратного устройства). Альфа-тестирование почти всегда проводится самими разработчиками ПО. В процессе альфа-тестирования разработчики приложения находят и исправляют ошибки и проблемы, имеющиеся в программе. Обычно, во время Альфа-тестирования происходит имитация работы с программой штатными разработчиками, реже имеет место реальная работа как потенциальных пользователей, так и заказчиков с продуктом. Как правило, альфа-тестирование проводится на самом раннем этапе разработки ПО, однако в отдельных случаях может быть применено для законченного или близкого к завершению продукта, например, в качестве приёмочного тестирования.
• · Бета-тестирование. Тестирование продукта, по-прежнему находящегося в стадии разработки. При бета-тестировании этот продукт предоставляется для некоторого количества пользователей, для того чтобы изучить и сообщить о возникающих проблемах, с которыми сталкиваются пользователи. Такое тестирование необходимо чтобы найти ошибки, которые разработчики могли пропустить. Обычно бета-тестирование проводится в две фазы: закрытый бета-тест и открытое бета-тестирование. Закрытый бета-тест - это тестирование на строго ограниченном кругу избранных пользователей. Такими пользователями могут выступать знакомые разработчиков, либо их коллеги, не связанные напрямую с разработкой тестируемого продукта. Открытое бета-тестирование заключается в создании и размещении в открытом доступе публичной бета-версии. В данном случае любой пользователь может выступать бета-тестером. Обратная связь от таких бета-тестеров осуществляется с помощью отзывов на сайте и встроенных в программу систем аналитики и логирования пользовательских действий, эти системы необходимы для анализа поведения пользователей и обнаружения трудностей и ошибок, с которыми они сталкиваются .

По позитивности сценария

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

По степени автоматизации

• · Ручное тестирование. Ручное тестирование проводится без использования дополнительных программных средств, оно позволяет проверить программу или сайт с помощью имитации действий пользователя. В этой модели тестировщик выступает в качестве пользователя, следуя определенным сценариям, параллельно анализируя вывод программы и ее поведение в целом.
• · Автоматизированное тестирование. Такое тестирование позволяет за счет использования дополнительного программного обеспечения для автоматизации тестов значительно ускорить процесс тестирования. Такое дополнительное ПО позволяет контролировать и управлять выполнением тестов и сравнивать ожидаемый и фактический результаты работы программы. Более подробно будет рассмотрено позже .

Терминология Quality assurance

В этой статье мы будем рассматривать QA (Quality Assurance) в разработке программного обеспечения. Все это относиться к тестированию программного обеспечения, но в этой статье мы не будем изучать тонкости, а лишь разберемся с терминологией. Терминология в QA очень важна, без неё не возможно будет провести тестирования продукта. Как уже могли догадаться, QA расшифровывается как Quality Assurance что в переводе - обеспечение качества (контроль качества). Перейдём непосредственно к терминологии:

Позитивное тестирование (positive testing)

Это тестирование на данных или сценариях, которые соответствуют нормальному (штатному, ожидаемому) поведению системы. Основной целью “позитивного” тестирования является проверка того, что при помощи системы можно делать то, для чего она создавалась.

Негативное тестирование (negative testing)

Это тестирование на данных или сценариях, которые соответствуют нештатному поведению. Основной целью “негативного” тестирования является проверка устойчивости системы к воздействиям различного рода, валидация неверного набора данных.

Функциональное тестирование (functional testing)

Это тестирование в целях проверки реализуемости функциональных требований для решения задачи пользователя.

Функциональные тестирование включают в себя:

• Функциональная пригодность (suitability)
• Точность (accuracy)
• Способность к взаимодействию (interoperability)
• Соответствие стандартам и правилам (compliance)
• Защищённость (security)

Тестирование производительности (performance testing)

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

Тестирование производительности включают в себя:

• Нагрузочное тестирование (load testing)
• Стресс-тестирование (stress testing)
• Тестирование стабильности (stability / endurance / soak testing)

Тестирование удобства использования (usability testing)

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

Тестирование пользовательского интерфейса (UI testing)

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

Тестирование безопасности (security testing)

Процесс оценки уязвимости программного обеспечения к различным атакам.

Тестирование локализации (localization testing)

Это процесс тестирования локализованной версии программного продукта. Проверка правильности перевода элементов интерфейса пользователя, проверка правильности перевода системных сообщений и ошибок, проверка перевода раздела “Помощь”/“Справка” и сопроводительной документации.

Тестирование совместимости (compatibility testing)

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

Окружение может включать в себя следующие элементы:

• Аппаратная платформа;
• Сетевые устройства;
• Периферия (принтеры, CD/DVD-приводы, веб-камеры и и.т.д);
• Операционная система (Unix, Windows, MacOS, …)
• Базы данных (Oracle, MS SQL, MySQL, …)
• Системное программное обеспечение (веб-сервер, файрвол, антивирус, …)
• Браузеры (Internet Explorer, Firefox, Opera, Chrome, Safari)

Тестирование чёрного ящика (black box)

Метод тестирования функционального поведения объекта (программы, системы) с точки зрения внешнего мира, при котором не используется знание о внутреннем устройстве тестируемого объекта.

Тестирование белого ящика (white box)

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

Тестирование серого ящика (grey box)

Представляет собой сочетание тестирования белого ящика и черного ящика. Целью данного тестирования является поиск дефектов, если таковые из-за неправильного структуры или неправильного использования приложений.

Ручное тестирование (manual testing)

Это процесс поиска дефектов в работе программы, когда происходит тестирования работоспособность всех компонентов программы, как если бы он был пользователем.

Автоматизированное тестирование (automated testing)

Этот процесса тестирования использует программные средства для выполнения тестов и проверки результатов выполнения, что помогает сократить время тестирования и упростить его процесс.

Модульное тестирование (component/unit testing)

Процесс позволяющий проверить на корректность отдельные модули исходного кода программы.

Интеграционное тестирование (integration testing)

Тестирования программного обеспечения, при которой отдельные программные модули объединяются и тестируются в группе. Интеграционное тестирование проводится после модульного тестирования и предшествует системному тестированию.

Системное тестирование (system/end-to-end testing)

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

Мы рассмотрели лишь небольшую часть терминологии, но достаточно важную в QA. Возможно, мы еще затронем тему тестирования, а на сегодня это все.

Похожие статьи:

Решение проблем Adobe Flash на примере YouTube - Читать

1. pidval сделал(а) реблог этого от
2. alexruzhyk понравилось это
3. anko-777 сделал(а) реблог этого от
4. понравилось это
5. maryarti понравилось это
6. dfdor44f понравилось это
7. eridi сделал(а) реблог этого от
8. seonoptik понравилось это

Вольный перевод статьи "Top 10 Negative Test Cases" Steve Miller.

Негативные тест кейсы используются для проверки работоспособности приложения при условии поступления на его вход «неправильных» данных. Такие тест кейсы должны обязательно использоваться в ходе тестирования. Ниже приведены десять самых популярных негативных тестовых сценариев:

Внутренние одинарные кавычки (Embedded Single Quote) - У большинства SQL баз данных возникают проблемы при наличии одинарных кавычек в запросе (например, Jones’s car).
Используйте одинарные кавычки при проверке каждого поля ввода работающего с базой данных.

Обязательный ввод (Required Data Entry) - В спецификации вашего приложения должны быть четко определены поля требующие обязательного ввода данных.
Проверяйте, что формы, которые имеют поля, определенные как обязательные для ввода, не могут быть сохранены при отсутствии данных в них.

Типы данных полей (Field Type Test) - В спецификации вашего приложения должны быть четко определены типы данных для каждого из полей (поля даты/времени, числовые поля, поля для ввода номера телефона или почтового кода и т.д.)
Проверяйте, что каждое из полей позволяет вводить или сохранять данные только определенного спецификацией типа (например, приложение не должно позволять вводить или сохранять буквы или специальные символы в числовых полях).

Размер поля (Field Size Test) - В спецификации вашего приложения должно быть четко определено максимально допустимое количество символов в каждом из полей (например, количество символов в поле с именем пользователя не должно привышать 50).
Проверяйте, что приложение не позволяет вводить или сохранять большее количество символов, нежели указано в спецификации. Не забывайте и о том, что данные поля, не только должны правильно функционировать, но и предупреждать пользователя об ограничениях, например, с помощью пояснительных надписей или сообщений об ошибках.

Числовые граничные значения (Numeric Bounds Test) - Числовые поля вашего приложения могут иметь ограничения допустимых числовых значений. Эти ограничения могут быть указаны в спецификации вашего приложения либо вытекать из логики работы программы (например, если вы тестируете функциональность связанную с начислением процентов на счет, то вполне логичным будет предположение, что начисленные проценты не могут принимать отрицательное значение).
Проверяйте, что приложение выдает сообщение об ошибке в случае, если значения лежат за пределами допустимого диапазона (например, сообщение об ошибке должно появляться при вводе значений 9 или 51 в поле с допустимым диапазоном значений от 10 до 50, либо при вводе отрицательного значения в поле, значения которого должны быть положительными).

Числовые ограничения (Numeric Limits Test) - Большинство баз данных и языков программирования определяют числовые значения как переменные с некоторым типом (например, integer или long integer), которые, в свою очередь, имеют ограничения допустимых числовых значений (например, значения integer должны находиться в диапазоне от -32768 до 32767, а long integer от -2147483648 до 2147483647).
Проверяйте граничные значения используемых переменных, для числовых полей, граничные значения которых четко не определены спецификацией.

Граничные значения даты (Date Bounds Test) - Очень часто в приложениях существуют логические ограничения для полей содержащих дату и время. Например, если вы проверяете поле содержащее дату рождения пользователя, то вполне логичным будет запрет ввода еще не наступившей даты (т.е. даты в будущем), либо ограничение на ввод даты отличающейся от сегодняшней более, чем на 150 лет.

Валидность даты (Date Validity) - Поля даты всегда должны иметь проверку валидности введенных значений (например, 31-11-2009 - не валидная дата). Также, не забывайте и о проверке дат в високосном году (годы кратные 4м и кратные 100 и 400 одновременно - високосные).

Веб сессии (Web Session Testing) - Множество веб приложений используют браузерные сессии для отслеживания пользователей вошедших в систему, применения специфических настроек приложения для конкретного пользователя и т.д. При этом, многие функциональные части системы не могут или не должны работать без предварительного входа в систему. Проверяйте, что функциональность или страницы, находящиеся за паролем, недоступны пользователю не прошедшему авторизацию.