IT systems testing
Comments 5
+1

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


Теперь критика. Считаю что тема в статье не раскрыта.


Не увидел терминов "Критический путь", "классы эквивалентности". Не упомянуто применение комбинаторики в тестировании, хотя это тоже часть дискретной математики.


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

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


В разделе про теорию множеств


Используя принципы теории базовых множеств, мы можем создать псевдокод, чтобы проиллюстрировать все возможные случаи для приложения «Next Day» (программа, которая вычисляет, какой день будет следующим, используя введенную дату):

вы рисуете сову. Как именно вы использовали упомянутую теорию, чтобы сформулировать эти тестовые сценарии?
Почему требования к программе Next Day вы написали в скобках? Выглядит как будто они совсем не важны.


Использование данных в этом формате помогает увеличить скорость разработки и снижает возможность ошибки.

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


В разделе по теории графов не понятно зачем нам матрицы смежности и матрицы инцидентности. Нам ведь нужно в итоге получить тестовые сценарии. Как сформулировать тесты, используя эти матрицы?


Вы упомянули нейронные сети, но ничего не сказали про то, как их тестировать. Ну допустим там граф. Что дальше?


Вам не удалось раскрыть, как именно связана дискретная математика, миллениум тестирование и BDD.

+1
Осталось приспособить дискретную математику к тестированию
заголовков статей
image
.
+1
Похоже на какую-то курсовую работу. На три с минусом. Если взять некоторые предложения, то поверхностность жутко бросается в глаза:
Некоторые данные поступают на входной слой, а алгоритмы скрытого слоя обрабатывают эти данные и отправляют результат на выходной этап. Таким образом, нейронная сеть может выполнять действия на основе этих данных. Нейронные сети также состоят из множества похожих графов с другой логикой, поэтому они могут принимать решения на основе входных параметров.
Или
дискретная математика помогает нам визуализировать точную часть программного обеспечения, которая была реализована и покрыта тестами.

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

Надеюсь, что тестовое покрытие у вас не такое поверхностное как эта статья ;)

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

Практически, комбинаторику и графы можно применять для оптимизации тестовых данных (pairwise), для достижения взаимопонимания между участниками команды (граф состояний и переходов) по отдельно взятой части приложения. Но никак нельзя в тестировании ставить академический подход во главу угла.
Про т.н. «тестирование на основе модели» есть достатчно много статей, но я не встречал ни одного проекта где бы оно практически применялось.

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

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

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

Удивительно, но ребенок находит проблемы в системе безо всяких математических моделей:
При подготовке полета «Аполлона-8», первого пилотируемого космического корабля, добравшегося до орбиты Луны, Маргарет Гамильтон удалось обнаружить серьезную уязвимость, но никто не поверил, что она представляет реальную угрозу. Найти эту уязвимость помогла дочь Гамильтон, которая играла с симулятором компьютера «Аполлона-8», пока ее мать работала. В какой-то момент она включила последовательность P01, запускаемую перед стартом космического корабля, когда симулятор был уже в «полете». Запуск P01 в неподходящий момент привел к сбою; и хотя у космонавтов нет никаких причин допускать такую ошибку, Гамильтон решила добавить несколько строчек кода — сделать своего рода «защиту от дурака». В NASA воспротивились, сочтя, что прекрасно подготовленные астронавты никогда в жизни не смогут так ошибиться. Тогда Гамильтон включила строчку «Не запускайте P01 во время полета» в документацию, но и это показалось руководству излишней мерой предосторожности.

Вскоре после рождества в 1968 году, когда «Аполлон-8» должен был покинуть орбиту Луны и отправиться на Землю, астронавт Джеймс Ловелл сделал именно то, чего от него никак не ждали — по ошибке запустил P01
Маргарет Гамильтон: «Пацаны, я вас на Луну отправлю»

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

+1
Идеальный тестер
Любой сотрудник некрупной IT-компании подтвердит, что четверг – самый скучный день недели. В самом деле — в понедельник все разгребают пришедшую за выходные почту, ругаются с поставщиками кофе и воды для кулера, и курят на лестнице, рассказывая друг другу анекдоты для борьбы со сном и похмельем. Во вторник задачи розданы, силы свежи, и код пишется на одном дыхании. В среду количество полезной работы за единицу времени достигает своего апогея… Пятница, естественно, проходит под знаком ожидания чьего-нибудь дня рождения или просто пивной вечеринки, поэтому квака начинается с самого утра, и большинство народу даже не делает вид, что работает. Те немногие, кто затрудняется имитацией деятельности, держат Экслера или RSDN открытым в пятом окне эксплорера, чтобы в таскбаре не было видно адреса.

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

Этот четверг ничем не отличался от обычных. Часов с 12 я начал испытывать просто нестерпимое желание найти повод поотлынивать. Поэтому когда в аське всплыл вопрос шефа «Не хочешь пособеседовать тестеров?», я долго не думал.

Напрягаться я не собирался, благо «собеседников» и без меня было вполне достаточно – технический директор, директор по маркетингу и главный (он же единственный) сисадмин.

Заливая четвертую за сегодня кружку Nescafe Gold водой из кулера (наш народ зовет эту жидкость смолой, за цвет, вкус и консистенцию), я пообщался с директорами и выяснил, что, во-первых, место у нас одно, а во-вторых, кандидатов двое. Такой высокий конкурс директор по маркетингу объяснял грамотным проведением рекрутинговой кампании (он сам составлял макет объявления для нашего сайта), а технический директор – замедлением падения курса доллара. Поскольку мы работаем на заказчиков, не говорящих по-русски, за курсом доллара наши сотрудники следят пристальнее, чем ребята из Редмонда за курсом акций Microsoft.

Налив себе кофе, мы переместились в конференц-зал.

Первым кандидатом оказалась симпатичная девушка в джинсах и свитере. Я пропустил мимо ушей ее резюме, обратив внимание лишь на упоминание какого-то сертификата Quality Assurance Engineer. Во время собеседования девушка вела себя довольно-таки уверенно, то и дело поминала Transition Phase, CMM, ISO9000 и трехлетний опыт работы. Все это время я смотрел в окно и думал о том, что сидеть она будет в комнате через коридор, и что я не смогу использовать обычный лексикон при объяснении тонких моментов тест-плана.

Вторым был парень-студент, во взгляде которого читалась острейшая нужда в денежных средствах. На этот раз я принял участие в собеседовании и узнал, что он – гениальный программист и веб-дизайнер, что у него даже есть свой сайт, и что он сейчас пишет IDE для PHP на MAC. Я бы выяснил, почему он предпочитает MAC, но поймал взгляд технического директора и свернул беседу.

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

Третий кандидат выглядел немного моложе моих лет. Улыбнувшись, он представился и сел в кресло, бросив папку на стол. Маркетинговый директор порылся у себя в бумагах и спросил:

— Извините, я что-то не вижу вашего резюме. Вы не присылали его нам?

— Присылал, — ответил кандидат, с интересом оглядываясь вокруг, — Но у вас почтовый сервер глючит.

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

— Может быть, проблема все же не в сервере? Со связью что-нибудь, или почтовый клиент не сработал? Вы, кстати, не с мейл.ру отправляли?

— Нет, — ответил кандидат, продолжая оглядываться. Его внимание привлекла настольная лампа. Щелкнув пару раз выключателем, он сказал: «Смотрите-ка!» – и полез под стол. Лампа вспыхнула и перегорела. Кандидат вылез из-под стола и продолжил:

— Если оставить выключатель в промежуточном положении, а потом включить шнур в розетку, лампа перегорит!

— Спасибо. Может быть, вы принесли резюме с собой? — поинтересовался я.

— Да, конечно, вот оно, — он подал лист А4, — а вот это — распечатка ответа вашего почтового сервера, — он подал еще один лист.

Сисадмин с интересом взял его из моих рук и пробежал глазами:

— Но!.. А как?.. Странно… Я сейчас! — с этими словами он почти выбежал из комнаты.

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

— Я так и знал! Дефект в системе регулировки пневматического амортизатора. Если отогнуть ручку вверх, а потом вбок…

— Принеси ему стул, — попросил меня технический директор, и я вышел из комнаты.

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

— Что там с почтовиком? — спросил я.

— Ты будешь смеяться. В его письме MIME-boundary нарушает RFC 2046. Ничего страшного, но наш сервер падает при приеме такого текста! Измени хотя бы один символ – все пройдет нормально. Я посмотрел в логи – сервер падал четыре раза в понедельник. Судя по всему, именно из-за этого товарища.

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

— А вот стол у вас хороший, основательный! — сказал кандидат. Как говорил Оззи Осборн, «я начал понимать, что приходит время прощаться».

— Мы с вами свяжемся, до свидания.

— Можно, я от вас позвоню? — спросил этот демон разрушения.

— НЕТ! — ответил технический директор таким голосом, что кандидат мгновенно исчез.

Налив себе еще немного кофе, мы обсудили результаты собеседования. Увы, девушка не прошла.

Сертификат QA Engineer не заменит природного таланта — с таким парнем в команде нам просто не удастся сдать софт, если в нем будет хотя бы один баг.

Завтра пятница, значит – знакомство с новым членом коллектива. Пиво и бильярд в Потерянном Кластере. Пожалуй, я лучше пойду в Пива.NET — пусть попса, но мало ли что он захочет протестировать в баре…

www.rsdn.org/article/humor/tester.xml
0
Говоря о тестировании то оно в основном касается поведения системы что ортогонально структурному представлению, общему для разработчиков программного обеспечения.

Запятые пропущены перед то и перед что, из-за чего это предложение удалось понять только раза с 3-4, исправьте, пожалуйста =)
Only those users with full accounts are able to leave comments., please.