7.1. Способы локализации
После
того, как с помощью контрольных тестов
(или каким либо другим путем) установлено,
что в программе или в конкретном ее
блоке имеется ошибка, возникает задача
ее локализации, то есть установления
точного места в программе, где находится
ошибка.
Процесс
локализации ошибок состоит из следующих
трех компонент:
1.
Получение на машине тестовых результатов.
2.
Анализ тестовых результатов и сверка
их с эталонными.
3.
Выявление ошибки или формулировка
предположения о характере и месте ошибки
в программе.
По
принципам работы средства локализации
разделяются на 4 типа :
1.
Аварийная печать.
2.
Печать в узлах.
3.
Слежение.
4.
Прокрутка.
АВАРИЙНАЯ
ПЕЧАТЬ
осуществляется один раз при работе
отлаживаемой программы, в момент
возникновения аварийной ситуации в
программе, препятствующей ее нормальному
выполнению. Тем самым, конкретное место
включения в работу аварийной печати
определяется автоматически без
использования информации от программиста,
который должен только определить список
выдаваемых на печать переменных.
ПЕЧАТЬ
В УЗЛАХ
включается в работу в выбранных
программистом местах программы; после
осуществления печати значений данных
переменных продолжается выполнение
отлаживаемой программы.
СЛЕЖЕНИЕ
производится или по всей программе, или
на заданном программистом участке.
Причем слежение может осуществляться
как за переменными (арифметическое
слежение), так и за операторами (логическое
слежение). Если обнаруживается, что
происходит присваивание заданной
переменной или выполнение оператора с
заданной меткой, то производится печать
имени переменной или метки и выполнение
программы продолжается. Отличием от
печати в узлах является то, что место
печати может точно и не определяться
программистом (для арифметического
слежения); отличается также и содержание
печати.
ПРОКРУТКА
производится на заданных участках
программы, и после выполнения каждого
оператора заданного типа (например,
присваивания или помеченного) происходит
отладочная печать.
По
типам печатаемых значений (числовые и
текстовые или меточные) средства
разделяются на арифметические и
логические.
7.2. Классификация средств локализации ошибок
Ниже
дана классификация средств локализации.
ТИПЫ
СРЕДСТВ ЛОКАЛИЗАЦИИ ОШИБОК :
1.
Языковые.
1.1.
Обычные.
1.2.
Специальные.
2.
Системные.
(3.
Пакетные)
СРЕДСТВА
ЛОКАЛИЗАЦИИ:
1.
Аварийная печать (арифметическая).
1.1.
Специальные средства языка.
1.2.
Системные средства.
2.
Печать в узлах (арифметическая).
2.1.
Обычные средства языка.
2.2.
Специальные средства языка.
3.
Слежение (специальные средства).
3.1.
Арифметическое.
3.2.
Логическое.
4.
Прокрутка (специальные средства).
4.1.
Арифметическая.
4.2.
Логическая.
8. Технология отладки программы автоматизации учета движения товаров на складе малого предприятия
При
отладке программы использовались
следующие методы контроля и локализации
ошибок (обзор методов см. в теоретической
части раздела) :
1.
Просмотр текста программы и прокрутка
с целью обнаружения явных синтаксических
и логических ошибок.
2.
Трансляция программы (транслятор выдает
сообщения об обнаруженных им ошибках
в тексте программы).
3.
Тестирование.
Тестирование
проводилось посредством ввода исходных
данных, с дальнейшей их обработкой,
выводом результатов на печать и экран.
Результаты работы программы сравнивались
заданными в техническом задании.
4.
При локализации ошибок преимущественно
использовалась печать в узлах, которыми
являлись в основном глобальные переменные,
переменные, используемые при обмене
данными основной программы с подпрограммами.
Отладка
программы производилась по следующему
алгоритму :
1.
Прогонка программы с набором тестовых
входных данных и выявление наличия
ошибок.
2.
Выделение области программы, в которой
может находиться ошибка. Просмотр
листинга программы с целью возможного
визуального обнаружения ошибок. В
противном случае — установка контрольной
точки примерно в середине выделенной
области.
3.
Новая прогонка программы. Если работа
программы прервалась до обработки
контрольной точки, значит, ошибка
произошла раньше. Контрольная точка
переносится, и процесс отладки возвращается
к шагу 2.
4.
Если контрольная точка программы была
обработана, то далее следует изучение
значений регистров, переменных и
параметров программы с тем, чтобы
убедиться в их правильности. При появлении
ошибки — новый перенос контрольной точки
и возврат к шагу 2.
5.
В случае не обнаружения ошибки продолжение
выполнения программы покомандно, с
контролем правильности выполнения
переходов и содержимого регистров и
памяти в контрольных точках. При
локализации ошибки она исправляется и
процесс возвращается к шагу 1.
В
качестве тестовых входных данных
использовалась последовательность
частотных выборок, генерируемых
имитатором в режиме 1. (Каждому интервалу
соответствует фиксированное значение
выборок.)
Соседние файлы в папке 4Diplom
- #
16.04.201332.77 Кб9A4.vsd
- #
- #
- #
- #
- #
#1
single player
-
- Members
-
- 11 сообщений
Новый участник
Отправлено 21 сентября 2006 — 17:34
найти ошибку недостаточно. нужно ее качественно локализовать. делимся опытом:)
я себе представляю процесс поиска возможных причин примерно так:
Рассматривается классическая схема:
на входе есть некий набор данных, некая последовательность шагов, скрытый от Вас черный ящик, в котором происходит, что-то неизвестное и набор выходных данных.
В процессе тестирования Вы получаете не тот результат, который ожидали увидеть. После того как Вы убедитесь, что в таком
нехорошем положении вещей виновата именно тестируемая программа, можно считать, что в программе найдена очередная ошибка.
Следующий шаг — добиться четкого повторения ошибки. Обычно это удается сделать по памяти. Если память Вас подводит, то
полезно иметь тетрадку по записям из которой можно воспроизвести багу еще раз. Многие программы записывают логи.
Исследование логов также может позволить Вам воспроизвести ошибку.
Отступление:
сложнее обстоит дело с «плавающими ошибками»…(не будем здесь про них).
Вы добились четкого повторения ошибки. Настало время заняться анализом набора входных данных и имеющейся
последовательности шагов.
Здесь основной принцип — чем проще, тем лучше. Т. е. наша задача повторить эту же ошибку за минимальное кол-во шагов и на
наиболее простом наборе входных данных(под наиболее простым понимается тот набор, на котором программа должна работать с
высокой степенью вероятности).
Следующий шаг — анализ выходных данных. Сравнивая разницу между наблюдаемым и ожидаемым выходом, нужно постараться понять
из-за чего эта разница могла возникнуть.
После этого нужно попытаться найти наиболее простой путь(несколько путей), с помощью которого можно обойти найденную
ошибку и получить требуемый результат. Возможно, это поможет программисту в исправлении ошибки, ну а в крайнем случае у Вас
будут рекомендации для отдела тех. поддержки:)
Далее обобщаем результаты исследований, оставляем нужное, отсекаем лишнее и заносим новый баг в базу данных ошибок.
Тоже самое коротко:
-действительно ошибка?
-анализ и упрощение входа.
-анализ выхода
-поиск обходных путей
-оформление в базу данных ошибок.
-
0
- Наверх
#2
serega
Отправлено 22 сентября 2006 — 06:13
Слов много, а по сути…. 
найти ошибку недостаточно. нужно ее качественно локализовать. делимся опытом:)
Тоже самое коротко:
-действительно ошибка?
Попробуйте занести программисту несколько раз минимую ошибку баг трекинг -моментально научитесь проверять
-анализ и упрощение входа.
Никто с вами и разговаривать не будет, если вы будете описывать баги нечетко — баг будет возвращаться на уточнение, пока не научитесь
-анализ выхода
-поиск обходных путей
У Вас всегда есть на это время?
Если вы знаете внутреннюю логику программы, то можно потратить 5 мин, иначе какой смысл
-оформление в базу данных ошибок.
А какой еще результат нужен от тестирования?
С моей точки зрения локализация ошибки — это способ сузить облась её поиска раработчиком, т.е. постараться максимально отсечь все лишнее в описании.
Для этого надо обладать достаточными знаниями о внутренней логике программы и уметь анализировать код. Даже в этом случае Вы не всегда сможете точно указать проблемное место, тока рекомендации.
-
0
- Наверх
#3
Rost
Rost
- ФИО:Rostyslav Boruk
- Город:Украина, Киев
Отправлено 22 сентября 2006 — 07:03
Тоже самое коротко:
-действительно ошибка?
-анализ и упрощение входа.
-анализ выхода
-поиск обходных путей
-оформление в базу данных ошибок.
Я согласен с serega в том, что на
«-анализ и упрощение входа.
-анализ выхода
-поиск обходных путей»
чаще всего нет времени. На самом деле это довольно редко надо делать. Вы нашли ошибку, воспроизвели ее и подробно описали. Можете двигаться дальше.
С моей точки зрения локализация ошибки — это способ сузить облась её поиска раработчиком, т.е. постараться максимально отсечь все лишнее в описании.
Для этого надо обладать достаточными знаниями о внутренней логике программы и уметь анализировать код. Даже в этом случае Вы не всегда сможете точно указать проблемное место, тока рекомендации.
Согласен с максимальным отсечением. Не согласен, в данном контексте, с анализом кода. Предлагался черный ящик.
Рассматривается классическая схема:
на входе есть некий набор данных, некая последовательность шагов, скрытый от Вас черный ящик, в котором происходит, что-то неизвестное и набор выходных данных.
Так что грамотного детального описания (в разумных пределах) достаточно.
-
0
Ростислав Борук,
Консультант по процессам тестирования
- Наверх
#4
Clauster
Clauster
- ФИО:Худобородов Валерий
- Город:Espoo
Отправлено 22 сентября 2006 — 08:14
Это краткий пересказ какой-то книжки по тестированию или что?
-
0
- Наверх
#5
Rost
Rost
- ФИО:Rostyslav Boruk
- Город:Украина, Киев
Отправлено 22 сентября 2006 — 08:18
Это краткий пересказ какой-то книжки по тестированию или что?
Очень похоже на обсуждение содержания краткого пересказа основной идеи локализации и описания ошибки. 
-
0
Ростислав Борук,
Консультант по процессам тестирования
- Наверх
#6
single player
single player
-
- Members
-
- 11 сообщений
Новый участник
Отправлено 22 сентября 2006 — 15:13
«Это краткий пересказ какой-то книжки по тестированию или что?»
— я же написал, что основано на своем опыте, получилось книжно, потому что хотелось рассказать самое основное.
(статья была написана по просьбе руководства для начинающих тестировщиков. после каждого пункта запланирован небольшой пример непосредственно из тестирования боевых программ).
«Слов много, а по сути….»
поэтому и хотелось что бы народ поделился своим опытом.
«Попробуйте занести программисту несколько раз минимую ошибку баг трекинг -моментально научитесь проверять»
— а зачем пробовать? не лучше ли сразу научиться проверять?
«Никто с вами и разговаривать не будет, если вы будете описывать баги нечетко — баг будет возвращаться на уточнение, пока не научитесь»
— про четкое описание бага нужно говорить отдельно (если коротко, то в описании должны быть 3 вещи: последовательность шагов, наблюдаемое поведение, ожидаемое поведение). описание ошибкилокализация ошибки — это разные понятия, ИМХО.
«А какой еще результат нужен от тестирования?»
— Вы считаете, что единственным результатом тестирования, является запись об ошибке в базе?
-
0
- Наверх
#7
serega
Отправлено 25 сентября 2006 — 12:05
«Попробуйте занести программисту несколько раз минимую ошибку баг трекинг -моментально научитесь проверять»
— а зачем пробовать? не лучше ли сразу научиться проверять?
меня смущает словосочетание «научиться проверять» — мне кажется, невелика наука делать все адекватно
«Никто с вами и разговаривать не будет, если вы будете описывать баги нечетко — баг будет возвращаться на уточнение, пока не научитесь»
— про четкое описание бага нужно говорить отдельно (если коротко, то в описании должны быть 3 вещи: последовательность шагов, наблюдаемое поведение, ожидаемое поведение). описание ошибкилокализация ошибки — это разные понятия, ИМХО.
Вы забыли: название, версия, в которой найден, требования, ответсвенного, важность….и т.д.
Тоже будем учить? или заведем баг-трекинг?
«А какой еще результат нужен от тестирования?»
— Вы считаете, что единственным результатом тестирования, является запись об ошибке в базе?
Не стоит выдергивать вопрос из контекста.
Найти и зафиксировать ошибку в базу — основная задача тестирования. Кому то надо доказывать, что найденную ошбику необходимо зарегистрировать?
-
0
- Наверх
#8
Imbecile
Отправлено 25 сентября 2006 — 12:26
Следующий шаг — анализ выходных данных. Сравнивая разницу между наблюдаемым и ожидаемым выходом, нужно постараться понять
из-за чего эта разница могла возникнуть.
Так недолго и до того, что: «Открыл исходники и пофиксил». Понять из-за чего возникла ошибка может (в первую очередь) только программист.
-
0
In Test we trust.
- Наверх
#9
Imbecile
Отправлено 25 сентября 2006 — 12:32
Не стоит выдергивать вопрос из контекста.
Найти и зафиксировать ошибку в базу — основная задача тестирования. Кому то надо доказывать, что найденную ошбику необходимо зарегистрировать?
По поводу основной задачи тестирования:
ИМХО: Процесс тестирования является неотъемлемой частью процесса обеспечения качества (в данном случае программного продукта). Никому не нужно тестирование, если в результате этого процесса качество не изменится (улучшится). Следовательно, при процессе тестирование важно не нахождение ошибки, как таковой, а нахождение ошибок, нахождение (простите за тавтологию) которых, повлечёт изменение качества продукта (в лучшую сторону).
-
0
In Test we trust.
- Наверх
#10
ea_rx
ea_rx
-
- Members
-
- 10 сообщений
Новый участник
- ФИО:Evgeny Bartashevich
Отправлено 25 сентября 2006 — 14:16
найти ошибку недостаточно. нужно ее качественно локализовать. делимся опытом:)
я себе представляю процесс поиска возможных причин примерно так:
[..]
Следующий шаг — добиться четкого повторения ошибки. Обычно это удается сделать по памяти. Если память Вас подводит, то
полезно иметь тетрадку по записям из которой можно воспроизвести багу еще раз. Многие программы записывают логи.
Исследование логов также может позволить Вам воспроизвести ошибку.
для того, чтобы не воспроизводить по памяти (а если ошибка из-за данных, введенных 20 шагов назад?), можно записывать видео с производимыми действиями.
-
0
- Наверх
#11
single player
single player
-
- Members
-
- 11 сообщений
Новый участник
Отправлено 25 сентября 2006 — 14:45
«Так недолго и до того, что: «Открыл исходники и пофиксил». Понять из-за чего возникла ошибка может (в первую очередь) только программист.»
понять может только программист. мы можем только высказать свои предположения.
собственно что имелось в виду: допустим есть конечное состояние «A»(успешное выполнение) и конечное состояние «B»(ошибка). Далее представим себе, что «A» является успешным при выполнении более простых a1, a2, a3. А «B» является ошибкой, т.к. например вместо a2 мы получили х. Непосредственно проверить функцию, влиюящую на a2, мы не можем (у нас есть только доступ к функции, которая результатом которой является все «A» ), но предположить, что сбой произошел из-за того, что некорректно отработала функция, ответственная за a2, мы можем.
«ИМХО: … а нахождение ошибок, нахождение (простите за тавтологию) которых, повлечёт изменение качества продукта (в лучшую сторону).»
угу. тоже ИМХО: более качественным продукт делает нахождение ошибок и их исправление. соответственно быстрому исправлению ошибки должна помочь хорошо выполненная локализация.
2serega:
не хочется спорить и ругаться 
. мне не интересно как заносить ошибки в базу — интересно как их локализовывать.
-
0
- Наверх
#12
Rost
Rost
- ФИО:Rostyslav Boruk
- Город:Украина, Киев
Отправлено 25 сентября 2006 — 15:53
угу. тоже ИМХО: более качественным продукт делает нахождение ошибок и их исправление. соответственно быстрому исправлению ошибки должна помочь хорошо выполненная локализация.
Все правильно если Вы не тратите на локализацию пол дня. 
Если Вы тратите на локализацию больше времени чем можно просто, подробно описать ошибку, это совсем не БЫСТРОЕ исправление. Исправление в себе содержит нахождение и изменение, а не только изменение.
-
0
Ростислав Борук,
Консультант по процессам тестирования
- Наверх
#13
single player
single player
-
- Members
-
- 11 сообщений
Новый участник
Отправлено 25 сентября 2006 — 16:04
«Все правильно если Вы не тратите на локализацию пол дня.»
угу 
во всем нужно чувство меры.
offtopic:
для меня в работе всегда было интересно сначала поломать что-нить, а потом уже разобраться из-за чего же оно сломалось. если же тупо тестировать по сценариям, то и самому отупеть не долго
-
0
- Наверх
#14
Imbecile
Отправлено 26 сентября 2006 — 07:48
«ИМХО: … а нахождение ошибок, нахождение (простите за тавтологию) которых, повлечёт изменение качества продукта (в лучшую сторону).»
угу. тоже ИМХО: более качественным продукт делает нахождение ошибок и их исправление. соответственно быстрому исправлению ошибки должна помочь хорошо выполненная локализация.
А это уже зависит от специфики продукта. Я не спорю, что выявление дефектов и их справление — это важный процесс в достижении качества продукта, но далеко не единственный.
-
0
In Test we trust.
- Наверх
#15
Imbecile
Отправлено 26 сентября 2006 — 07:51
offtopic:
для меня в работе всегда было интересно сначала поломать что-нить, а потом уже разобраться из-за чего же оно сломалось. если же тупо тестировать по сценариям, то и самому отупеть не долго
Открою страшную тайну, т-с-с-с, никому не говорите: чтобы люди не сидели и тупо не тестировали по тестовым сценариям и, следовательно, не тупели, придумали автоматизацию тестирования. Во как.
-
0
In Test we trust.
- Наверх
#16
Clauster
Clauster
- ФИО:Худобородов Валерий
- Город:Espoo
Отправлено 26 сентября 2006 — 08:14
offtopic:
для меня в работе всегда было интересно сначала поломать что-нить, а потом уже разобраться из-за чего же оно сломалось. если же тупо тестировать по сценариям, то и самому отупеть не долгоОткрою страшную тайну, т-с-с-с, никому не говорите: чтобы люди не сидели и тупо не тестировали по тестовым сценариям и, следовательно, не тупели, придумали автоматизацию тестирования. Во как.
В ответ открываю ещё более страшную тайну: далеко не во все проекты имеет смысл внедрять автоматизацию. 
-
0
- Наверх
#17
serega
Отправлено 26 сентября 2006 — 08:40
По поводу основной задачи тестирования:
ИМХО: Процесс тестирования является неотъемлемой частью процесса обеспечения качества (в данном случае программного продукта). Никому не нужно тестирование, если в результате этого процесса качество не изменится (улучшится). Следовательно, при процессе тестирование важно не нахождение ошибки, как таковой, а нахождение ошибок, нахождение (простите за тавтологию) которых, повлечёт изменение качества продукта (в лучшую сторону).
Очень толково. Только обясните мне, чем отличаются ошибки, которые влекут изменение качества продукта, от остальных ошибок?
Вы правильно заметили, что тестирование — неотъемлимая часть процесса управления качеством, в который помимо тестирования входят еще куча дисциплин.
Поэтому я считаю ошибочным вывод «Никому не нужно тестирование, если в результате этого процесса качество не изменится (улучшится).»
Тестирование может обеспечивать выполнение своих задач, но при этом хромать остальные дисциплины, начиная от управления проектов и заканчивая Help Desk
-
0
- Наверх
#18
serega
Отправлено 26 сентября 2006 — 08:46
2serega:
не хочется спорить и ругаться
Как локализовавать ошибки — слишком общий вопрос.
Учите преметную область и овладевайте широкими познаниями в области IT.
Пример из личного опыта. Разрабатывалась система электронной передачи документов с локальных мест в общую базу при помощи почтового сервиса.
Система состояла из 4-х модулей: локальный клиент, почтовый клиент, дешифратор со стороны сервера, парсер на центральном сервере.
Появляется ошибка — письмо не приходит, вот и локализуешь на каком сегменте произошел сбой, без знания логики всех сегментов никуда:(
-
0
- Наверх
#19
Rost
Rost
- ФИО:Rostyslav Boruk
- Город:Украина, Киев
Отправлено 26 сентября 2006 — 09:09
Поэтому я считаю ошибочным вывод «Никому не нужно тестирование, если в результате этого процесса качество не изменится (улучшится).»
Тестирование может обеспечивать выполнение своих задач, но при этом хромать остальные дисциплины, начиная от управления проектов и заканчивая Help Desk
А зачем тратить ресурсы на то, что не приносит никаких изменений? Просто потому что в цепочке разработки ПО обязано быть тестирование?
-
0
Ростислав Борук,
Консультант по процессам тестирования
- Наверх
#20
serega
Отправлено 26 сентября 2006 — 10:37
Поэтому я считаю ошибочным вывод «Никому не нужно тестирование, если в результате этого процесса качество не изменится (улучшится).»
Тестирование может обеспечивать выполнение своих задач, но при этом хромать остальные дисциплины, начиная от управления проектов и заканчивая Help DeskА зачем тратить ресурсы на то, что не приносит никаких изменений? Просто потому что в цепочке разработки ПО обязано быть тестирование?
ага, и виновато тестирование.. под нож
будем строить дом, монтажные чертежи опустим — так дешевле 
-
0
- Наверх
Регистрация на курс
Плавающий баг?
Ох уж эти мистические «плавающие ошибки». Сколько вокруг них мифов! Но, когда причина найдена, всегда оказывается, что нет плавающих багов, а есть недолокализованные.
Поэтому мы будем учиться локализовывать баги, которые «не воспроизводятся». Учиться искать причину проблемы без помощи разработчика. Учиться смотреть в код и искать причину снаружи. Делить бисекционно и читать логи. В общем, всё, что нужно для воспроизведения!
Воспроизведение ошибки
Если вы не можете вопроизвести ошибку, то:
- Прочитайте логи — если есть доступ к логам, всегда в первую очередь смотрим туда! Если у нас веб-приложение, проверьте, что ушло с клиента на сервер.
- Проверьте граничные значения — баги часто тусят на границах.
- Попробуйте пойти «от обратного» — подумать, как получить саму проблему. Этот метод хорошо работает для багов с кэшом
- Составьте таблицу отличий — у вас то все работает. Что отличает ваш кейс от падающего?
Что записывать в таблицу отличий:
- Состояние объекта.
- Действия, которые с ним выполняли.
- Устройство, на котором воспроизводится.
- Время выполнения действия (какой релиз?).
- Способ воспроизведения (GUI, API).
- Количество открытых вкладок в браузере.
В отлове багов помогает понимание того, где копятся баги и какого рода: как влияет на работу системы concurrency, миграция данных, перетипизация переменной внутри кода… Зная последствия, вы будете понимать, что именно записать в таблицу отличий.
Локализация ошибки
Если вы можете воспроизвести баг, но не можете локализовать (слишком много шагов воспроизведения / слишком большой файл, внутри которого есть ошибка), то:
- Посмотрите код — возможно, это будет самым быстрым решением.
- Используйте бисекционное деление.
- Придумайте теорию (на баг влияет то и то) — подтвердите ее, а потом попробуйте опровергнуть.
- Выкиньте лишнее из шагов — возможно, именно это сбивает вас с толку
На курсе мы будем рассматривать каждую из техник. Вы сможете сразу применить ее на практике на специально подобранных домашних заданиях, которые показывают именно данную технику или конкретную проблему (миграции данных, стыка интеграции и т.д.)
О курсе
Это практический курс: теории минимум. Типичная лекция — на 10-15 минут. Короткая лекция «как это применять» и тут же практика! Конечно, есть и сложные лекции (на 30 минут). Есть и короткие, на 7 минут. Нет жесткой привязки ко времени лекции. Сколько надо дать теории, столько и говорю, а дальше уже практикуйтесь.
Для локализации багов мы будем применять техники:
- Черного ящика — как понять, что происходит, если нет доступа в код.
- Белого ящика — куда можно посмотреть в коде? Смотреть будем на примере приложения folks с открытым исходным java-кодом. Разумеется, у вас на проекте код будет выглядеть по-другому, но зато вы получите представление, где там могут вылезти баги. Баги, которые мы будем рассматривать на курсе, не были внесены в приложение нарочно — так что все приближено к реальности.
Лекции идут в моем фирменном стиле, с картинками. Посмотрите примеры видео на моем youtube-канале, чтобы понять, подходит ли вам такой стиль изложения.
Если вы переживаете, что не сможете что-то сделать (например, задания на просмотр кода), вот вам задача для самопроверки — соберите проект folks и запустите тесты. Инструкция есть, есть даже видео-инструкция по установке java, maven на Windows, Если справитесь, то и все остальное будет вам по плечу!
Программа курса
0. Введение
Что такое локализация и зачем она вообще нужна тестировщику.
Как умение локализовывать задачи экономит время команды и убирает панику.
Как знание о типовых проблемах помогает воспроизводить баги, которые «не воспроизводятся».
1. Уточнение устройств, на которых есть баг
На что обращать внимание при багах «поехала верстка», «текст вылезает за пределы экрана».
Как понять, в какой момент едет верстка? Какие инструменты использовать:
— как замерить размер окна;
— какие есть линейки;
— как посмотреть размер окна в консоли.
2. Исследование состояний
Изучим разные состояния объекта. Если проблема при сохранении — а кого мы вообще сохраняем?
— свежесозданную карточку
— отредактированную
— удаленную
…
Если у нас есть пользователь, то какой он? А как регистрировался? Как это может повлиять на воспроизведение бага?
3. Использование классов эквивалентности и граничных значений
Что такое классы эквивалентности.
Почему на границах встречаются баги.
Зачем тестировать ноль и как его найти, если у нас не строка ввода?
4. Опровержение своих теорий
Как опровергать свои теории и зачем это нужно.
— таблица отличий;
— метод «найди 5 отличий»;
— принцип минимализма (отсеивание лишнего).
5. Метод бисекционного деления
Что такое бисекционное деление.
Как его использовать тестировщику для локализации бага.
Как оно используется в разработке и к каким проблемам может привести.
6. Чтение логов
Что такое логи. Что в них записывается?
Как читать логи. Как читать стектрейс ошибки.
Логи на сервере и на клиенте.
7. Просмотр запросов с клиента на сервер
На клиенте помимо JS-логов можно смотреть, что вообще ушло на сервер.
Это помогает понять, где произошла ошибка и кто виноват: клиент или сервер. Учимся это делать.
8. Воспроизведение «от обратного»
Техника расследования закрытой комнаты. Наиболее актуальна для багов с кэшом.
Вот есть баг, из кэша достаются неправильные данные. Как воспроизвести? Идем от обратного, пытаемся получить “плохие данные” разными путями.
9. Проверка по коду
Как читать код, при условии, что разработчики идут вам на встречу и разделяют потроха логики и описание объектов.
Читаем java-объект и схему создания БД. Выверяем их на соответствие друг другу.
Внимание: у вас на проекте может быть не java, но принцип все тот же. На примере домашнего задания вы увидите, как можно найти баг, исследуя код
10. Проверка соответствия типов данных
Если поле встречается в коде несколько раз:
— в объектной модели;
— в схеме создания БД;
— где-то еще
Важно проверять соответствие типов. Смотрим, какие встречаются баги на несоответствие типов.
11. Проверка стыка интеграции
Какая бывает интеграция между системами.
Какие бывают баги на стыке интеграции.
Куда смотреть в первую очередь.
12. Проверка данных после миграции
Зачем тестировщику нужна как чистая база, так и база, живущая веками?
Примеры ошибок, вылезающих после миграции и почему они не ловятся на свежей тестовой БД.
13. Проверка concurrency
Типичная ошибка — выполнение CRUD над одним пользователем. Тестировщик может найти баги, переключаясь между вкладками интерфейса. Но это про поиск багов, а не про локализацию, казалось бы, да?
Но о concurrency важно знать, так как параллельная работа может быть и на другом уровне:
- Идет забор данных из базы по 1000 записей за раз. Что, если в этой 1000 встретились 2 одинаковых клиента? Строка базы заблокирована первым изменением — второе разваливается.
- Интеграция по SOAP REST. Если запросов много, там тоже можно влететь на изменение одного и того же клиента.
И в этом случае к вам придут “у меня тут ошибка”, а вы понять не можете, откуда она взялась, так как текст невразумительный. Надо помнить про параллельную работу, чтобы локализовать причину.
14. Заключение
Подводим итоги.
Вопросы и ответы
1. Можно ли проходить курс на Linux или Mac?
Да, он не зависит от вашей OS
2. Какие знания нужны для курса?
Общие знания о тестировании — что это вообще такое, как составлять тесты, что такое классы эквивалентности.
Если будете делать ДЗ с просмотром кода (необязательные), то:
- Базовое понимание языка программирования (любого) — вы не должны падать в обморок от слов string или «тип данных». Но все, что будет нужно для ДЗ, я объясню.
- Умение устанавливать новые программы — мы будем смотреть в код, а для этого нужно будет установить java, mercurial, maven. Вот инструкция, соберите проект перед записью на курс.
3. Будет ли мне интересно, если я проходил другие ваши курсы?
Если вы прошли «Школу для начинающих тестировщиков» в группе, то встречались с багами в коде folks — но эти задания на курсе необязательные! Так что сильно не влияют на интерес.
Если вы прошли «Логи как инструмент тестировщика», то уже сделали пару обязательных заданий. Но всё равно будет много нового и полезного
4. А скидку то дадут мне за эти ДЗ?
Да, покажите ваш сертификат и получите скидку:
- Логи как инструмент тестировщика → 20%
- Школа для начинающих, пройденная в группе → 10%
Как записаться
Регистрация и дата ближайшего запуска
Способы оплаты