Комментарий

• Свойства страницы (1 изменено, 0 добавлено, 0 удалено)

Подробности

Свойства страницы

Содержимое

...	...	@@ -1,29 +8,5 @@
1		-Кодовая база может быть представлена в виде точек состояний.
2		-Каждый раз, когда мы вносим изменения в код, мы берем за основу некое состояние и добавляем. меняем строки кода, тем самым создавая новое состояние.
3		-Условно мы можем сказать, что предыдущее состояние является корректным - в нем программа выполняет поставленные задачи, а вот состояние после изменения может содержать ошибки.
4		-Механизмы тестирования призваны удостовериться, что новое состояние кодовой базы (версия приложения), работает корректно.
5		-Тест описывание наши ожидания относительно поведения программы. Выполнение теста подтверждает, что код ведет себя именно так, как он него ожидается. (Это может касаться, как обязательств интерфейсов на уровне кода, так и поведение и контракт web api, UI, отправки сообщений, состояния БД, поведения отдельно взятой функции).
6		-[[AS IS TO BE>>doc:Архитектура и модели.Про приложение.AS IS TO BE.WebHome]]
7		-
8	8	----
9	9
10		-Функциональное и нефункциональное тестирование.
11		-
12		-|=(% style="width: 224px;" %)Тип|=(% style="width: 1298px;" %)
13		-|(% style="width:224px" %)[[Unit test>>doc:.UnitTest.WebHome]].
14		-Модульное тестирование.|(% style="width:1298px" %)(((
15		-Тестирование отдельных модулей (компонентов) системы(программы) в изолированной среде, с заранее известными входными и выходными значениями тестов. Используется техника подмены реализации, когда вместо зависимостей классу передаются заглушки с заранее известным поведением и наборами данных (MOQ). Обычно предполагает изолирование от внешних систем и хранилищ данных.
16		-Обычно является наиболее дешевым с точки зрения выполнения.
17		-
18		-MOQ - объекты, выполняющий роль заглушки, замещающей реальны объекты, с заранее известными входами и выходами.
19		-)))
20		-|(% style="width:224px" %)Интеграционное тестирование|(% style="width:1298px" %)Тестирование взаимодействия между собой различных модулей системы. По сравнению с UnitTest более приближено к реальному виду системы.
21		-|(% style="width:224px" %)Регрессионное тестирование|(% style="width:1298px" %)Проверка функционала, который уже существовал в системе и не является новым для нее. Суть в том, чтобы убедиться, что в рамках доработок системы старые функции/варианты использования не были повреждены/некорректно изменены.
22		-|(% style="width:224px" %)[[Нагрузочное тестирование>>doc:.Нагрузочное тестирование.WebHome]]|(% style="width:1298px" %)Проверка, что инфраструктура системы справляется с предполагаемой нагрузкой.
23		-Проверка производительности компонентов системы.
24		-
25		-----
26		-
27	27	==== Внутренние ссылки: ====
28	28
29	29	====== Дочерние страницы: ======
...	...	@@ -46,10 +46,34 @@
46	46
47	47	----
48	48
49		-Ссылки:
	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]]
	34	+| |Функциональное и нефункциональное тестирование.
	35	+| |(((
	36	+|=(% style="width: 224px;" %)Тип|=(% style="width: 1298px;" %)
	37	+|(% style="width:224px" %)[[Unit test>>doc:.UnitTest.WebHome]].
	38	+Модульное тестирование.|(% style="width:1298px" %)(((
	39	+Тестирование отдельных модулей (компонентов) системы(программы) в изолированной среде, с заранее известными входными и выходными значениями тестов. Используется техника подмены реализации, когда вместо зависимостей классу передаются заглушки с заранее известным поведением и наборами данных (MOQ). Обычно предполагает изолирование от внешних систем и хранилищ данных.
	40	+Обычно является наиболее дешевым с точки зрения выполнения.
50	50
	42	+MOQ - объекты, выполняющий роль заглушки, замещающей реальны объекты, с заранее известными входами и выходами.
	43	+)))
	44	+|(% style="width:224px" %)[[Интеграционное тестирование>>doc:.Интеграционное тестирование.WebHome]]|(% style="width:1298px" %)Тестирование взаимодействия между собой различных модулей системы. По сравнению с UnitTest более приближено к реальному виду системы.
	45	+|(% style="width:224px" %)Регрессионное тестирование|(% style="width:1298px" %)Проверка функционала, который уже существовал в системе и не является новым для нее. Суть в том, чтобы убедиться, что в рамках доработок системы старые функции/варианты использования не были повреждены/некорректно изменены.
	46	+|(% style="width:224px" %)[[Нагрузочное тестирование>>doc:.Нагрузочное тестирование.WebHome]]|(% style="width:1298px" %)Проверка, что инфраструктура системы справляется с предполагаемой нагрузкой.
	47	+Проверка производительности компонентов системы.
	48	+)))
	49	+| |(((
51	51	Автоматизированное интеграционное тестирование ASP.NET приложения
52	52	https://habr.com/ru/post/174735/
	52	+
53	53	Автоматизация тестирования Web-приложений
54	54	https://habr.com/ru/post/178407/
55	55
...	...	@@ -56,3 +56,4 @@
56	56
57	57	В чём разница Smoke, Sanity, Regression, Re-test и как их различать?
58	58	https://habr.com/ru/post/358142/
	59	+)))