Исходный код вики Тестирование

Редактировал(а) Alexandr Fokin 2024/01/11 16:27

version	line-number	content
5.2	1	----
	2
5.4	3	==== Внутренние ссылки: ====
	4
	5	====== Дочерние страницы: ======
	6
	7	{{children/}}
	8
	9	====== Обратные ссылки: ======
	10
	11	{{velocity}}
	12	#set ($links = $doc.getBacklinks())
	13	#if ($links.size() > 0)
	14	#foreach ($docname in $links)
	15	#set ($rdoc = $xwiki.getDocument($docname).getTranslatedDocument())
	16	* [[$escapetool.xml($rdoc.fullName)]]
	17	#end
	18	#else
	19	No back links for this page!
	20	#end
	21	{{/velocity}}
	22
	23	----
	24
5.16	25	\| \|(((
	26	1. Кодовая база может быть представлена в виде снимков состояний.
	27	1. Каждый раз, когда мы вносим изменения в код, мы берем за основу некое состояние и добавляем. меняем строки кода, тем самым создавая новое состояние.
	28	1. Условно, мы можем сказать, что предыдущее состояние является корректным - в нем программа выполняет поставленные задачи, а вот состояние после изменения может содержать ошибки.
	29	1. Механизмы тестирования призваны удостовериться, что новое состояние кодовой базы (версия приложения), работает корректно.
	30	1. Тест описывание наши ожидания относительно поведения программы. Выполнение теста подтверждает, что код ведет себя именно так, как он него ожидается.
	31	(Это может касаться, как обязательств интерфейсов на уровне кода, так и поведение и контракт web api, UI, отправки сообщений, состояния БД, поведения отдельно взятой функции).
	32	)))
	33	\| \|[[AS IS TO BE>>doc:Архитектура и модели.Про приложение.AS IS TO BE.WebHome]]
5.17	34	\| \|Вопрос стоимости создания и поддержания тестов.
5.16	35	\| \|Функциональное и нефункциональное тестирование.
	36	\| \|(((
	37	\|=(% style="width: 224px;" %)Тип\|=(% style="width: 1298px;" %)
	38	\|(% style="width:224px" %)[[Unit test>>doc:.UnitTest.WebHome]].
	39	Модульное тестирование.\|(% style="width:1298px" %)(((
	40	Тестирование отдельных модулей (компонентов) системы(программы) в изолированной среде, с заранее известными входными и выходными значениями тестов. Используется техника подмены реализации, когда вместо зависимостей классу передаются заглушки с заранее известным поведением и наборами данных (MOQ). Обычно предполагает изолирование от внешних систем и хранилищ данных.
	41	Обычно является наиболее дешевым с точки зрения выполнения.
4.1	42
5.16	43	MOQ - объекты, выполняющий роль заглушки, замещающей реальны объекты, с заранее известными входами и выходами.
	44	)))
	45	\|(% style="width:224px" %)[[Интеграционное тестирование>>doc:.Интеграционное тестирование.WebHome]]\|(% style="width:1298px" %)Тестирование взаимодействия между собой различных модулей системы. По сравнению с UnitTest более приближено к реальному виду системы.
	46	\|(% style="width:224px" %)Регрессионное тестирование\|(% style="width:1298px" %)Проверка функционала, который уже существовал в системе и не является новым для нее. Суть в том, чтобы убедиться, что в рамках доработок системы старые функции/варианты использования не были повреждены/некорректно изменены.
	47	\|(% style="width:224px" %)[[Нагрузочное тестирование>>doc:.Нагрузочное тестирование.WebHome]]\|(% style="width:1298px" %)Проверка, что инфраструктура системы справляется с предполагаемой нагрузкой.
	48	Проверка производительности компонентов системы.
	49	)))
	50	\| \|(((
4.1	51	Автоматизированное интеграционное тестирование ASP.NET приложения
	52	https://habr.com/ru/post/174735/
5.16	53
4.1	54	Автоматизация тестирования Web-приложений
	55	https://habr.com/ru/post/178407/
	56
5.1	57
	58	В чём разница Smoke, Sanity, Regression, Re-test и как их различать?
	59	https://habr.com/ru/post/358142/
5.16	60	)))