Пси тестирование в ит что это
Объявления
Если вы интересуетесь релейной защитой и реле, то подписывайтесь на мой канал
ПМИ и ПСИ
Чтобы отправить ответ, вы должны войти или зарегистрироваться
Сообщений 10
1 Тема от BenGan 2013-08-28 08:06:16
Тема: ПМИ и ПСИ
2 Ответ от Yuriy82 2013-08-28 08:21:24
Re: ПМИ и ПСИ
3 Ответ от BenGan 2013-08-30 12:46:35
Re: ПМИ и ПСИ
4 Ответ от _vlad 2013-09-09 13:56:21
Re: ПМИ и ПСИ
Коллеги, немного заблуждаетесь.
Стадии сдачи заказчику:
1. Заводская приемка (Заводские ПСИ).
2. Приемка в опытную эксплуатацию.
3. Приемка в пром. эксплуатацию.
5 Ответ от BenGan 2013-09-11 07:16:27 (2013-09-11 07:18:51 отредактировано BenGan)
Re: ПМИ и ПСИ
Теперь осталось понять, что описывается в ПМИ, все три стадии:
1. Заводская приемка (Заводские ПСИ).
2. Приемка в опытную эксплуатацию.
3. Приемка в пром. эксплуатацию.
или только последние две, или на каждую стадию своя ПМИ?
6 Ответ от Yuriy82 2013-09-11 09:11:16
Re: ПМИ и ПСИ
На каждый вид испытаний свое ПМИ. Вы же когда собираетесь испытывать что-то, должны представлять как именно и что вы испытываете, вот это и пишется в ПМИ.
Содержание документов на системы автоматизации, как правило регламентируются ГОСТ 34
Если интересуют ПМИ для объектов ФСК, то на сайте ФСК должны быть типовые ПМИ.
7 Ответ от BenGan 2013-09-12 11:04:08
Re: ПМИ и ПСИ
Теперь понятно, Спасибо!
8 Ответ от lik 2013-09-12 12:13:41
Re: ПМИ и ПСИ
9 Ответ от last_hero 2014-01-10 10:59:58
Re: ПМИ и ПСИ
Нет коллега протокол вам могут выдать на шкаф или на конкретный терминал, а вот испытания системы в целом (сеть, шторма и прочее) это уже ПМИ. По крайней мере я так всегда делаю на терминалы, шкафы, интеграции по цифре оформляются протоколы, после чего проводятся комплексные испытания.
10 Ответ от TapakaH 2015-01-30 16:32:49
Re: ПМИ и ПСИ
Сообщений 10
Тему читают: 1 гость
Чтобы отправить ответ, вы должны войти или зарегистрироваться
Как инженеры a1qa проводили приёмо-сдаточные испытания ПО: Часть 1. Теоретическая
Вот уже более двух лет команда a1qa работает на проекте по созданию платежной системы для одного крупного банка. Поначалу задачи нашей команды сводились только к тестированию системы, однако через некоторое время заказчик поручил нам подготовку и проведение приёмо-сдаточных испытаний.
Задача эта нетипичная для тестировщиков. Поэтому мы решили поделиться своим опытом и рассказать, как её грамотно выполнить, оправдав доверие заказчика.
Что такое приёмо-сдаточные испытания (ПСИ)?
Прежде чем выпускать продукт на рынок, заказчик должен убедиться в возможности использования разработанного решения, в его безопасности, надёжности, корректном функционировании и проверить другие характеристики, описанные в требованиях к продукту.
ПСИ особенно актуальны для проектов, на которых выпуск некачественного продукта может привести к значительным финансовым потерям (к слову, наш проект именно к таким и относится).
Итак, цели проведения ПСИ:
Избежать хаоса в подготовке и проведении ПСИ, развеять сомнения в методах убеждения и их эффективности помогают различные нормативно-правовые документы, которые стандартизируют процессы разработки и тестирования.
Один из таких документов, обязательный для любых приёмо-сдаточных испытаний, – это «Программа и методика испытаний».
Документ «Программа и методика испытаний»: что нужно знать тестировщику
Написанием и форматированием данного документа обычно занимаются специально обученные люди, например, технические писатели.
Однако знать, из чего состоит документ, тестировщику не помешает. Кроме того, подготовка одного из разделов может быть поручена именно тестировщикам.
Обратимся к официальной документации. Согласно межгосударственному стандарту ГОСТ 19.301-79, документ «Программа и методика испытаний» должен иметь следующую структуру:
Какой из разделов под силу подготовить функциональному тестировщику? Конечно же, «Методы испытаний». Об этом поговорим позже, а пока ещё немного теории.
Критерии успешности приёмо-сдаточных испытаний
Как правило, успешность ПСИ определяется на этапе заключения контракта. Одним из таких критериев может быть процент успешно пройденных во время демонстрации проверок. Например, если на проверку выносятся 100 тест-кейсов и критерий pass-rate составляет 80%, то 80 тест-кейсов должно быть успешно пройдено, иначе считается, что продукт приёмку не прошел, а значит, не может быть допущен к опытной и промышленной эксплуатации.
На практике же успешность приёмо-сдаточных испытаний чаще определяется не одним критерием, а совокупностью нескольких. Например, учитывается процент реализованных требований от общего числа и ограничение по количеству дефектов того или иного приоритета. Оперируя данными по этим критериям, принимается решение об успешности ПСИ.
На этом необходимая теория заканчивается. В следующей части расскажем, как приёмо-сдаточные испытания проводила команда a1qa и какие трудности ей пришлось преодолеть.
Корпоративный троллинг — 3, или сдача работ без лишних забот
В предыдущих статьях (первая, вторая) мы бегло и в шутливой форме прошлись по примерам противодействия, которое оказывают нам сотрудники заказчика на различных этапах проекта. Сегодня предметом рассмотрения будет сдача работ, и мы подойдем к этому этапу во всеоружии, чтобы ни один тролль не прорвался. Получилось много букв, но, надеюсь оно того стоит.
Сдача результатов работы является одним из самых драматических этапов проекта. Человеко-месяцы, потраченные на разработку, отладку, тестирование и внедрение вашего решения, не должны быть потрачены зря. Если сдача работ поручена вам, то ваша роль в команде весьма значительна, а доверие руководства велико, даже если начальники вам этого никогда не говорили. Облажаться на сдаче работ иногда означает конец вашей блистательной карьеры. Так что лучше этого не делать.
Процесс приемо-сдаточных испытаний должен быть строго формализован. Всем понятно, что в конце этого процесса должен появиться протокол и акт, на основании которого выпускается приказ о переводе системы в опытную или промышленную эксплуатацию. Акт также является формальным поводом для выставления счета на оплату очередного этапа проекта.
В этой статье я без лишних шуток (какие уж тут шутки!) и максимально последовательно (ну, для блога, конечно) опишу процесс сдачи проектных работ. Разумеется, многие вещи опытным коллегам покажутся очевидными. Пусть. Зато менее опытные коллеги или желающие примерить ответственную роль сдающего на себя найдут эту публикацию полезной и познавательной.
Направления троллинга в ходе испытаний
Программа и методика испытаний
Документ ПМИ, или программа и методика испытаний, на мой взгляд, более важен, чем даже ТЗ. От качества этого документа зависит половина, если не две третьих успеха испытаний.
Протокол испытаний
На основе тестов ПМИ вы должны подготовить протокол испытаний. Протокол будет являться документом, подтверждающим то, что ваша система выполнена в соответствии с ТЗ, о чем делается соответствующая запись в акте. Не доверяйте подготовку протокола никому другому, если не хотите иметь бледный вид перед комиссией. Обычно протокол является «копипастом» из ПМИ, так что его подготовка много времени у вас не займет.
Протокол испытаний состоит из общей части, таблицы тестов и списка замечаний.
Генеральная репетиция
Без нее нельзя. Только так вы можете отловить все шероховатости в тестах, выявить тесты, крадущие время и тесты, результаты которых сомнительны. Помните, что визуальная составляющая должна быть безупречна. Постарайтесь забить в систему данные, которые выглядят натурально и похожи на то, с чем имеет дело клиент. Проследите, чтобы имена пользователей и другие поля не содержали ненормативную лексику (любимая шутка внедренцев и программеров). Эти «шуточки» иногда действуют на комиссию как красная тряпка на быка.
Не бойтесь переписать ПМИ с нуля. Один раз мы пожалели время и перекомпоновали тесты вместо того, чтобы переписать их. В итоге мы просто успокоили сами себя, не изменив общей плачевной картины. За что и огребли.
Если вы сдаете вдвоем, гоняйте тесты вместе. Приглашайте коллег, пусть они придираются, изображая из себя комиссию. Потраченное на эти игры время в итоге позволит всем вам получить деньги от довольного заказчика.
Эффективный дуэт
Оптимальной командой для сдачи является пара из внедренца (или программиста) и бизнес-аналитика (консультанта).
Точно так же, если консультант скажет глупость, а заказчик нахмурится в ответ, программист может с лицом оскорбленной невинности продемонстрировать очередную фишку системы и тогда заказчик проникнется к нему симпатией, так как поймет, кто тут настоящий профи, а кто клоун в галстуке.
В особенно напряженные моменты можно устроить дружескую перепалку, разрядив тем самым обстановку и отведя внимание аудитории от не совсем корректной работы системы.
Не зря же западные «айтишные евангелисты» любят работать парами.
Процесс пошел!
Когда вы приступили к испытаниям, не смейте лезть в систему сразу! Постарайтесь пройти сначала всю формальную часть. Сверьте коды документации, носителей информации, откройте ТЗ, положите на стол Руководство пользователя. Пройдитесь по нефункциональным требованиям. ОС Windows — галочка. Поддерживаемые версии браузеров — раз, два, три, галочка. Язык разработки, архитектура, база данных, да мало ли что там в ТЗ понаписано! Все нужно показать в документации. Хотя бы там всего лишь одно предложение, оно обязано там быть! Не пренебрегайте этой бюрократией, тролли только этого и ждут. Вам хочется получить в протоколе, что «Исполнитель не продемонстрировал, что язык java является кроссплатформенным языком высокого уровня. Требования ТЗ 1.2.3 и 3.2.1 не выполнены»? А ведь это не придуманный маразм, это сама жизнь.
Когда вы закончили с формальной стороной дела, тоже не спешите лезть в систему! Следующая группа тестов заключается во включении монитора и демонстрации рабочего стола, иконок и запуска программы (если запуск нужно тестировать). Вход в систему с неправильным паролем, галочка, вход с правильным — опять галочка, галочка, галочка. Меню — эка невидаль! Главная форма, список чего-нибудь. Галочка.
Когда дойдет дело до нажатия кнопок в системе, комиссия уже порядком устанет и проголодается. А вы в первый день сможете проскочить, к примеру, основные справочники и базовые функции. А на другой день оставить бекапирование, администрирование и еще какую-нибудь ерунду.
Замечания
Они будут, можете не сомневаться. Нет такой системы, к которой не было бы замечаний. Ваша задача — заставить заказчика поделить все замечания на критические и не критические. Первые должны быть исправлены для успешного перевода в опытную эксплуатацию. Вторые могут быть исправлены в ходе опытной эксплуатации. Соответственно, лучше, чтобы первых вообще не было или были только те, исправить которые не представляет особого труда.
Когда заказчик делает замечание, вы фиксируете его формулировку в протоколе. Обязательно проговорите записанные слова, убедитесь, что вы друг друга поняли. Будет лучше, если в ходе испытаний будет работать диктофон. Постарайтесь сделать так, чтобы формулировка замечания была конструктивной, то есть, было понятно, что нужно сделать, чтобы замечание было снято. Слов «все», «ничего», «каждый», «любой», а также неизмеряемых качественных оценок «плохо», «медленно», «слишком быстро» и т.п. в замечании быть не должно! Если «система работает медленно», то должно быть написано «запрошенная форма должна отображаться в течении 5 сек». Если «символы на схеме плохо различимы», то должно быть написано «увеличить символы на схеме до 18 пунктов». И так далее.
Конкретизация позволит минимизировать возможность необоснованного перетаскивания того или иного замечания в ранг критического. Заказчик может утверждать, что отработка запроса за 6 секунд для него неприемлема, а за 5 секунд — в самый раз. Пусть это появится в протоколе! Но что-то мне подсказывает, что не появится. Или замечание будет признано некритическим.
Все замечания, признанные критическим фиксируются в акте: «Комиссия постановила, что система соответствует ТЗ и рекомендует принять ее в опытную эксплуатацию при условиях отработки следующих замечаний. » При этом список некритических замечаний лучше непосредственно в акт не включать. Их обычно много и они могут напугать ответственного сотрудника, ставящего подпись. Если заказчик беспокоится, что вы не будете отрабатывать некритические замечания, успокойте его при помощи документа «Методика проведения опытной эксплуатации», котрый настоятельно рекомендуется подготовить. Там вы в простой и доступной форме должны описать как будет проходить опытная эксплуатация, как будут отрабатываться найденные баги и как будет заполняться журнал опытной эксплуатации, являющийся гарантом безболезненного окончания ОЭ, ввода системы в промышленную эксплуатацию и салюта с шампанским по причине окончания проекта.
Что делать, если все пропало
Когда вы понимаете, что испытания идут неудовлетворительно, система безобразно глючит, а заказчик уже исчерпал запас ругательств, не нужно сдаваться! Караван должен продолжать идти вперед, будет новый релиз, новые испытания. И даже если проект будет завален, ничего в этом страшного для вас нет. В условиях острого дефицита толковых исполнителей вы быстро найдете работу, тем более, что я бы на вашем месте не стал бы работать в компании, допускающей подобные ситуации.
Чтобы не терять время в бесплотных препирательствах, я бы рекомендовал применить тактику «бей своих, чтобы чужие боялись». Начните вместе с заказчиком ругать «этих криворуких программеров», «жадное руководство», а когда накал страстей уменьшится, предложите заказчику собрать максимум багов «этого глюкалова», чтобы показать этим нехорошим людям какие они нехорошие.
Тогда активные сотрудники заказчика во главе с троллем-киллером начнут собирать баги и радостно наполнять протокол сотнями замечаний. Фактически, за свои собственные деньги они проведут вам высокоуровневое функциональное тестирование, на которое, судя по результатам испытаний, ваши разработчики так и не сподобились.
По хорошему, описанной безобразной ситуации вообще быть не должно. Но проектный бизнес отличается иногда странными флуктуациями, когда первый прототип пытаются сдать как полноценную систему, начальство врет подчиненным и самим себе, все вокруг делают хорошую мину при плохой игре и уверяют друг друга в обязательном и непременном успехе.
Вторым советом в подобной ситуации было бы, как я уже говорил, сразу уволиться из конторы, допускающей подобные «косяки». Потому что по всем меркам настоящему профессионалу не стоит портить свою репутацию подобным образом.
Заключение
Итак, коллеги, на этом я спешу завершить трилогию о корпоративных троллях, которых не нужно бояться, а нужно уважать и даже некоторым образом любить, так как они не дают ленивым обезьянам ИТ бизнеса падать от обжорства с деревьев, держат нас в тонусе и даже привносят некоторый интерес в безумно скучные, но крайне необходимые проектные работы.
UPD от 23.06.2011. Пользователь igendo добавляет в комментариях, что неплохо бы уже на этапе заключения договора утвердить формы официальных документов проекта.
Добавлю, что очень помогает в работе, когда формы актов, протоколов и прочих формальных документов зафиксированы в контракте. Дабы не было необходимости их предварительно согласовывать, пересогласовывать и переделывать\переподписывать в середине проекта.
От себя тоже могу добавить, что в совсем уж тяжелых и масштабных проектах принято составлять устав проекта, некий документ о глубинном смысле которого можно говорить часами. Там, кроме всего прочего, можно обговорить и формы документов проекта, и процедуры контроля хода проекта, и высокоуровневые бизнес-задачи. Но это, опять же, тема для другого поста.
Пользователь ЖЖ ryzhij_papa Добавляет, что существует практика ранжирования замечаний по степени их влияния на бизнес, методика ранжирования также заносится в ПМИ.
Нужно формально описать что является замечаниями крического, высокого, среднего и низкого приоритета. Описание делается в терминах бизнеса. Если утрировать, то так: критический приоритет при потере 1000$, высокий если 100$, средний когда сотрудники в мыле, но убытков у нас нет, низкий — возможны случаи легкого умопомрачения на 5-6 году жизни с такой багой.
Фундаментальная теория тестирования
В тестировании нет четких определений, как в физике, математике, которые при перефразировании становятся абсолютно неверными. Поэтому важно понимать процессы и подходы. В данной статье разберем основные определения теории тестирования.
Перейдем к основным понятиям
Тестирование программного обеспечения (Software Testing) — проверка соответствия реальных и ожидаемых результатов поведения программы, проводимая на конечном наборе тестов, выбранном определённым образом.
Цель тестирования — проверка соответствия ПО предъявляемым требованиям, обеспечение уверенности в качестве ПО, поиск очевидных ошибок в программном обеспечении, которые должны быть выявлены до того, как их обнаружат пользователи программы.
Для чего проводится тестирование ПО?
Принципы тестирования
QC (Quality Control) — Контроль качества продукта — анализ результатов тестирования и качества новых версий выпускаемого продукта.
К задачам контроля качества относятся:
К задачам обеспечения качества относятся:
Верификация и валидация — два понятия тесно связаны с процессами тестирования и обеспечения качества. К сожалению, их часто путают, хотя отличия между ними достаточно существенны.
Верификация (verification) — это процесс оценки системы, чтобы понять, удовлетворяют ли результаты текущего этапа разработки условиям, которые были сформулированы в его начале.
Валидация (validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, его требованиям к системе.
Пример: когда разрабатывали аэробус А310, то надо было сделать так, чтобы закрылки вставали в положение «торможение», когда шасси коснулись земли. Запрограммировали так, что когда шасси начинают крутиться, то закрылки ставим в положение «торможение». Но вот во время испытаний в Варшаве самолет выкатился за пределы полосы, так как была мокрая поверхность. Он проскользил, только потом был крутящий момент и они, закрылки, открылись. С точки зрения «верификации» — программа сработала, с точки зрения «валидации» — нет. Поэтому код изменили так, чтобы в момент изменения давления в шинах открывались закрылки.
Документацию, которая используется на проектах по разработке ПО, можно условно разделить на две группы:
Этапы тестирования:
Программный продукт проходит следующие стадии:
Требования
Требования — это спецификация (описание) того, что должно быть реализовано.
Требования описывают то, что необходимо реализовать, без детализации технической стороны решения.
Отчёт о дефекте (bug report) — документ, который содержит отчет о любом недостатке в компоненте или системе, который потенциально может привести компонент или систему к невозможности выполнить требуемую функцию.
Атрибуты отчета о дефекте:
Жизненный цикл бага
Severity vs Priority
Серьёзность (severity) показывает степень ущерба, который наносится проекту существованием дефекта. Severity выставляется тестировщиком.
Градация Серьезности дефекта (Severity):
Градация Приоритета дефекта (Priority):
Тестовые среды
Основные фазы тестирования
Основные виды тестирования ПО
Вид тестирования — это совокупность активностей, направленных на тестирование заданных характеристик системы или её части, основанная на конкретных целях.
Автор книги «A Practitioner’s Guide to Software Test Design», Lee Copeland, выделяет следующие техники тест-дизайна:
Методы тестирования
Тестирование белого ящика — метод тестирования ПО, который предполагает, что внутренняя структура/устройство/реализация системы известны тестировщику.
Согласно ISTQB, тестирование белого ящика — это:
Тестирование чёрного ящика — также известное как тестирование, основанное на спецификации или тестирование поведения — техника тестирования, основанная на работе исключительно с внешними интерфейсами тестируемой системы.
Согласно ISTQB, тестирование черного ящика — это:
Тестовая документация
Тест план (Test Plan) — это документ, который описывает весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков.
Тест план должен отвечать на следующие вопросы:
Чаще всего чек-лист содержит только действия, без ожидаемого результата. Чек-лист менее формализован.
Тестовый сценарий (test case) — это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Атрибуты тест кейса:
Типы тестирования производительности
С моей точки зрения, тестирование производительности – это не тип тестирования, а общее описание для множества типов тестов, дающих информацию о поведении системы при различных условиях.
Те, о которых я хочу поговорить, перечислены ниже (спасибо Марку Томлинсону за графики).
Нагрузочное тестирование
Цель: убедиться в способности системы справиться с поддерживаемой на определенном уровне нагрузкой (к примеру, 2 часа прогоняется 1000 транзакций в секунду).
Нагрузочное тестирование – это тип теста производительности, проверяющий, как система ведет себя при постоянной нагрузке. Этот тест может указать на предел возможностей вашей системы, за которым она начнет деградировать.
Говоря о создании нагрузки, мы имеем в виду количество пользователей, одновременно пользующихся системой, и поведение транзакций.
Нагрузочное тестирование используется для уточнения и определения:
Стресс-тестирование
Цель: постепенно, непрерывно повышать нагрузку на систему, пока она не выдаст ошибку или отказ (например, повышать количество виртуальных пользователей, пока система не упадет).
Стресс-тестирование часто выполняется для проверки, как система обращается с нарастающей нагрузкой (количеством одновременных пользователей). Оно может дать информацию о стабильности ПО, когда ресурсы железа недостаточны – например, не хватает процессорной мощности, памяти, пространства на диске.
Этот тип тестирования производительности используется для выявления или валидации поведения приложения, вынужденного работать за пределами нормальной или пиковой нагрузки. Это похоже на нагрузочное тестирование, но идея тут в том, что приложение надо вытолкнуть за пределы его возможностей, довести до «стресса». Нам надо выяснить, когда оно откажет, как оно это сделает, и понаблюдать, как оно восстановится (если оно может или должно это сделать).
Прогоняя стресс-тест, вы можете узнать о:
Можно также выявить:
Продолжительное тестирование/тестирование выносливости
Цель: имитировать стандартную нагрузку в течение длительного времени, чтобы убедиться, что использование ресурсов остается на том же уровне (дисковое пространство, утечки памяти, условия разгона).
Продолжительное тестирование/тестирование выносливости – это тестирование системы с нормальной нагрузкой длительное время. В некоторых компаниях это невозможно, но при помощи этой техники мы обнаружили утечку памяти всего лишь через два часа. Некоторые компании могут прогонять такие тесты двое суток. Помните – нагрузка, как правило, невелика, фокус в длительности теста.
Этот подход поможет найти:
И теперь самое веселое!
Пиковое тестирование
Цель: измерить способность системы обращаться с кривой экстремального спроса, удерживать высокую нагрузку короткое время, и эффективно восстановить ресурсы после этого всплеска.
Пиковый тест проводится для валидации характеристик производительности, когда тестируемая система регулярно подвергается высокой нагрузке. Распространенный шаблон – проверить повышение и снижение нагрузки неоднократно в течение определенного времени. Это полезно для тестирования масштабирования системы вверх и вниз.
Пиковое тестирование поможет выявить:
Это те типы тестирования производительности, с которыми я сталкивалась и которые использовала.