Продолжая отдавать должное вопросам психологии в процессе тестирования, мы можем определить набор витальных (читай, чертовски жизненных) принципов тестирования. Многие из них покажутся очевидными, что, однако, не мешает зачастую ими пренебрегать. Вот они, а дальше – подробное их рассмотрение:
1. Обязательная часть тестирования – определение ожидаемого результата;
2. Программистам следует избегать тестирования их собственных программ (и участков кода);
3. Организациям, создающие программы, следует избегать тестирования их собственных программ;
4. Процесс тестирования должен включать в себя тщательную проверку результатов каждого теста;
5. Тест-кейсы должны быть составлены как для корректных и ожидаемых входных условий, так и для некорректных и неожидаемых;
6. Исследование Системы на предмет того, что она не делает того, что должна, — лишь пол дела. Вторая часть – разобраться в том, чего недолжного она делает;
7. Избегайте одноразовых тест-кейсов, только если сама программа не является одноразовой. Одноразовые тест-кейсы для одноразовых программ. В остальных случаях следует избегать таковых;
Рекурсивные алгоритмы — ЕГЭ по Информатике — Задание №11
8. Не занимайтесь процессом тестирования с предустановкой, что вы не найдете ошибок;
9. Вероятность наличия ошибок в определенной части Системы пропорционально количеству уже найденных здесь ошибок;
10. Тестирование – это вызов вашим творческим и интеллектуальным способностям. Тестирование – это невероятно творческое и интеллектуальное занятие.
Принцип 1: обязательная часть тестирования – определение ожидаемого результата
Этот принцип, который типа очевидный, когда его упускают из вида, является причиной наиболее частых ошибок в процессе тестирования. Тут снова вмешивается психология. Если заранее не разобраться с тем, как должен выглядеть результат, то нечто похожее на правду, но таковым не являющееся, будет воспринято как корректный результат. Ведь «мы видим то, что хотим видеть».
Другими словами, несмотря на разрушительную природу тестирования, где-то в глубине души мы все еще храним желание увидеть корректный результат. Но с этим нужно решительно бороться. Например, путем поощрения подробного заблаговременного исследования всех выходных данных и ожидаемых результатов. А это значит, что тест-кейс должен содержать два компонента:
— описание входных данных
— точное описание корректных выходных данных для указанных входных данных.
Проблемы могут возникнуть тогда, когда мы встречаем нечто, что не имеет приемлемого описания, что выглядит странным, что не согласуется с нашими ожиданиями или предубеждениями. При встрече с чем-то подобным нам нужно иметь хотя бы какие-то обобщенные представления, поскольку если не будет даже их, легко вообще пропустить потенциальные проблемы. Нет ожидания – нет сюрпризов.
Принцип 2: программистам следует избегать тестирования их собственных программ (и участков кода)
Каждый писатель знает – или должен знать – что редактировать свою собственную работу – это плохая идея. Они знают, что именно должна сказать, к примеру, определенная глава книги, и поэтому могут не увидеть то, что она говорит нечто другое. И они как-то не хотят искать ошибки в своей работе. То же можно сказать и об авторах программных продуктов.
Разбор задачи на рекурсию «Нумеролог»
Еще одна проблема связана со сменой фокуса. В то время, как при дизайне и написании кода программист настроен созидательно, перенастроиться на разрушительную волну может быть очень сложно.
Каждый домовладелец знает, что снимать обои очень трудно. Но если эти обои еще и ты сам вешал — это невыносимо удручает. Аналогично и с ПО, большинство программистов не могут протестировать свои программы эффективно, поскольку они не могут произвести ментальные перестройки, способствующие выявлению ошибок. Более того, подсознательный страх перед наказанием со стороны коллег, руководителей, клиентов или владельцев может приводить к избеганию ошибок.
И еще одна проблема: программа может содержать ошибки, которые вызваны непониманием поставленных задач или спецификации. И если это так, то сам процесс тестирования может включать в себя производные этого непонимания.
Это не значит, что путь тестирования собственных программ для программиста закрыт. Просто лучше (эффективнее), чтобы это делал кто-то другой. Разработчики могут быть полезными участниками команды тестирования, когда проводится оценка спецификации и самого программного кода.
И еще. Речь не шла о процессе дебаггинга. В этом случае автор кода является наиболее эффективным участником процесса.
Принцип 3: организациям, создающим программы, следует избегать тестирования их собственных программ
Аргументы такие же, что и для предыдущего принципа. Организация, создающая ПО, во многих смыслах как человек: имеет психологические проблемы. Более того, в нашем лучшем из миров работа организации или ее менеджеров часто оценивается способностью производить программы в установленные сроки и за определенную стоимость.
Причиной этому то, что эти величины легко описать количественно, в противоположность надежности, которую оценить в цифрах может быть сложно. Отсюда — организациям-разработчикам сложно быть эффективными в тестировании собственных продуктов. Эта оценка может проводится на основе соблюдения графиков работ и расходов.
Следует сказать и тут, что участие организации в процессе тестирования собственных продуктов не обязательно является бессмысленным. Здесь мы говорим, что наиболее удачно с экономической точки зрения выполнять такую работу независимой стороной.
Принцип 4: процесс тестирования должен включать в себя тщательную проверку результатов каждого теста
Это очевидно, но это часто упускается. Мы знакомы с большим количеством случаев, когда ошибку не удавалось обнаружить даже тогда, когда ее симптомы были четко различимы в выходных списках (результатах). Если выразится по-другому, ошибки, которые находят в последующих тестах, часто не замечают в результатах предшествующих тестов.
Принцип 5: тест-кейсы должны быть составлены как для корректных и ожидаемых входных условий, так и для некорректных и неожидаемых
Это естественная и здравая тенденция – концентрироваться на допустимых и ожидаемых условия в процессе тестирования. Пренебрегать недопустимыми и неожиданными условиями также естественно, но не также здраво. Много ошибок может выявится, когда программный продукт используется неким новым или неожиданным путем. Невозможно определить все сценарии, какими пользователь будет работать с продуктом, однако что-то отличное от спокойного, привычного течения программы, кажется, имеет все шансы на успех (в деле поиска ошибок).
Принцип 6: исследование Системы на предмет того, что она не делает, что должна, — лишь пол дела. Вторая часть – разобраться в том, чего недолжного она делает
Это следствие предыдущего принципа. Программу нужно проверить еще и на предмет нежеланных сторонних эффектов. Например, ПО для расчета заработанной платы, которая выдает зарплатный чек корректно, все еще содержит ошибки, если она также выдает дополнительные чеки для несуществующих работников, или она переписывает первую запись в персональном деле.
Принцип 7: одноразовые тест-кейсы для одноразовых программ, в остальных случаях следует избегать таковых тестов
Эта проблема, кажется, часто проявляется в различных системах для тестирования программ. Типичная практика – сидеть у компьютера и разрабатывать тесты на лету, и далее проводить эти тест-кейсы в программе. Суть в том, что тест-кейсы представляют собой ценные инвестиции, которые в рамках конкретного окружения могут исчезнуть, как только процесс тестирования будет завершен.
И всякий раз, когда возникнет необходимость в повторном тестировании ПО (в регрессионном тестировании или при улучшении системы), тест-кейсы могут потребовать новой разработки. Это дополнительная, сложная работа, встречаясь с которой тест-инженер может волить избегать ее. Так получается, что последующие усилия на работу редко столь же объемны и качественны сколь объемны и качественны первоначальные. И если, к примеру, изменение функциональности влечет за собой ошибки, вновь разработанные тесты могут их не обнаружить.
Принцип 8: не занимайтесь процессом тестирования с предустановкой, что вы не найдете ошибок
Частая ошибка менеджеров проекта и маленький звоночек к тому, что кто-то определяет процесс тестирования некорректно. Например, как процесс демонстрации, что программа работает правильно. Мы принимаем другое определение (хотя догадываемся, что есть ребята, которые так не делают) – это процесс выполнения программы со стойким намерением найти ошибки. Мы утверждаем: это очевидно, что разработать программный продукт, совершенно не содержащий ошибок, невозможно. Даже после качественно выполненного процесса тестирования и исправления ошибок, уместно предполагать, что ошибки все еще существуют; просто их пока не нашли.
Принцип 9: вероятность наличия ошибок в определенной части Системы пропорционально количеству уже найденных здесь ошибок
Может показаться, что эта штука сомнительна, но такой феномен наблюдается во многих программах. На пальцах это вот как: предположим, что программа состоит из модулей А и Б. В модуле А было найдено 5 ошибок, а в модуле Б – всего лишь одна. И если модуль А еще не подвергся тщательному тестированию, тогда принцип говорит: вероятность найти еще больше ошибок в модуле А выше, нежели вероятность найти еще больше ошибок в модуле Б.
Другой способ проиллюстрировать указанный принцип такой: ошибки имеют волю к объединению в группы, и в типичном случае, определенные программные блоки больше подвержены ошибочности, нежели другие. Хотя это похоже на магию… ничем не подкрепленную магию. Она может быть полезна, поскольку дает некое понимание и обратную связь в процессе тестирования. Если какой-то участок программы кажется больше подверженным ошибкам, нежели другие участки, этот феномен намекает нам, что лучше бы нам потестировать здесь чуточку дольше. И это вопрос об инвестициях.
Картинка даже есть:
Принцип 10: тестирование – это вызов вашим творческим и интеллектуальным способностям. Тестирование – это невероятно творческое и интеллектуальное занятие
Бесспорно, это так. Творческие способности, необходимые для тестирования программного продукта, превышают (да там так и написано) творческие способности, необходимые для создания этого программного продукта. Существует множество методик и техник для дизайна проникновенных тестов, но все это останется не высоко, если не будут приложены творческие усилия с Вашей стороны.
- тестирование по
- психология тестирования
- фундаментализм
- Тестирование IT-систем
- Тестирование веб-сервисов
- Тестирование мобильных приложений
Источник: habr.com
Основные принципы тестирования ПО
Существует два принципа тестирования программного обеспечения — функциональное тестирование (тестирование “чёрного ящика”) и структурное тестирование (тестирование “белого ящика”).
Функциональное тестирование («чёрного ящика»).
При тестировании “чёрного ящика” рассматриваются системные характеристики программ, а их внутренняя логическая структура не рассматривается. Таким образом, функции программы считаются известными и целью тестирования является исследование работы каждой функции на всей области ее определения. Исчерпывающее тестирование, как правило, невозможно. Например, если в программе 10 входных величин и каждая принимает по 10 значений, то потребуется 10 10 тестовых вариантов. Отметим также, что тестирование “чёрного ящика” не реагирует на многие особенности программных ошибок.
Как показано на рис. 2.12, основное место приложения тестов «черного ящика» — интерфейс ПО, то есть тестирование входов и выходов программы.
Рис. 2.12. Тестирование «черного ящика»
Эти тесты демонстрируют:
· как выполняются функции программ;
· как принимаются исходные данные;
· как вырабатываются результаты;
· как сохраняется целостность внешней информации.
Структурное тестирование («белого ящика»).
Объектом тестирования здесь является не внешнее, а внутреннее поведение программы. Проверяется корректность построения всех элементов программы и правильность их взаимодействия друг с другом. Обычно анализируется управляющие связи элементов, реже — информационные связи. Тестирование по принципу “белого ящика” характеризуется степенью, в какой тесты выполняют или покрывают логику (исходный текст) программы. Исчерпывающее тестирование также затруднительно.
Таким образом, при структурном тестировании по известной структуре программы (тексту) исследуются связи между ее отдельными элементами (рис. 2.13).
Рис. 2.13. Схема тестирования «белого ящика»
Обычно тестирование “белого ящика” основано на анализе управляющей структуры программы. Программа считается полностью проверенной, если проведено исчерпывающее тестирование маршрутов (путей) ее графа управления.
Тестовые варианты должны гарантировать проверку всех независимых маршрутов программы, прохождение ветвей True, False для всех логических решений, а также выполнение всех циклов (в пределах их границ и диапазонов). Кроме этого, необходимо анализировать правильность внутренних структур данных.
К недостаткам тестирования ”белого ящика” можно отнести то обстоятельство, что количество независимых маршрутов может быть очень велико. Например, если цикл в программе выполняется k раз, а внутри цикла имеется п ветвлений, то количество маршрутов вычисляется по формуле
.
При п = 5 и k = 20 количество маршрутов т = 10 14 .
Кроме этого, исчерпывающее тестирование маршрутов не гарантирует соответствия программы исходным требованиям к ней.
Достоинства тестирования “белого ящика“ связаны с тем, что принцип “ белого ящика” позволяет учесть специфические особенности программных ошибок, такие, как неравномерность распределения ошибок в программ (количество ошибок минимально в “центре” и максимально на “периферии” программы) или то, что некоторые результаты в программе зависят не от исходных данных, а от внутренних состояний программы.
Кроме этого, многие методы этого способа тестирования достаточно формализованы, а потому могут использоваться в различных автоматизированных системах тестирования.
Примерами таких методов являются тестирование базового пути, тестирование условий, тестирование ветвей и отношений, тестирование потоков данных и ряд других. Рассмотрим подробнее первый и последний из упомянутых методов.
Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:
Источник: studopedia.ru
Применение функций. Рекурсия
Будьте внимательны! У Вас есть 10 минут на прохождение теста. Система оценивания — 5 балльная. Разбалловка теста — 3,4,5 баллов, в зависимости от сложности вопроса. Порядок заданий и вариантов ответов в тесте случайный. С допущенными ошибками и верными ответами можно будет ознакомиться после прохождения теста.
Удачи!
Система оценки: 5 балльная
Список вопросов теста
Вопрос 1
Как называется вспомогательный алгоритм, который напрямую или через другие вспомогательные алгоритмы вызывает сам себя?
Варианты ответов
- Линейный
- Разветвляющийся
- Циклический
- Рекурсивный
Вопрос 2
Как называется способ определения множества объектов через это же множество на основе заданных базовых случаев?
Варианты ответов
- Рекурсия
- Прогрессия
- Регрессия
Вопрос 3
Выберите ложные утверждения.
Варианты ответов
- Рекурсивные алгоритмы обязательно должны содержать вызов самого себя или другого вспомогательного алгоритма.
- Рекурсивные алгоритмы работают быстрее итерационных.
- Рекурсивные алгоритмы обычно короче и понятнее итерационных.
- Программный стек не ограничен
Вопрос 4
Как называется принцип, согласно которому сложные программы разрабатываются и тестируются по частям, при этом такие части программы независимы друг от друга?
Составьте слово из букв:
ОТМУЬЛЬНОСД
В ответе укажите одно слово без пробелов и каких-либо знаков препинания.
Вопрос 5
Как называется область оперативной памяти, в которой хранятся значения параметров и адреса возврата вызываемых функций?
Вопрос 6
Чему будет равно а после исполнения инструкций?
def func (num):
if num < 10:
return num
else:
return func (num % 10 + num % 100 // 10)
Вопрос 7
Из каких частей состоит рекурсивное определение?
Варианты ответов
- Индуктивная часть
- Противоречащие случаи
- Инверсная часть
- Базовые случаи
Вопрос 8
Какие из приведённых строк кода можно описать на пропущеной позиции в рекурсивной функции вычисления n-ного числа Фибоначчи? Числами Фибоначчи называется числовой ряд, в котором первые два числа равны единице, а все последующие являются суммой двух предыдущих.
def fibo (n):
if n return 1
else:
Варианты ответов
- fibo (n — 1) + fibo (n — 2)
- return fibo (n — 1) + fibo (n — 2)
- return fibo ((n — 1) + (n — 2))
- return fibo (n — 2) + fibo (n — 1)
Вопрос 9
Как называется принцип, согласно которому описанные модули стоит сохранять и расширять, чтобы не решать снова уже решённую задачу, если она встретиться повторно?
Варианты ответов
- Повторное использование кода
- Первичное использование кода
- Основное использование кода
Вопрос 10
Что произойдёт при попытке исполнения инструкций?
def rec (n):
if n > 0:
return rec (n % 10)
else:
return n
Варианты ответов
- Значение а станет равно 5
- Зацикливание
- Переполнение программного стека
- Значение а станет равно 0
Источник: videouroki.net