Комментарий

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

Подробности

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

Содержимое

...	...	@@ -1,5 +1,29 @@
	1	+Кодовая база может быть представлена в виде точек состояний.
	2	+Каждый раз, когда мы вносим изменения в код, мы берем за основу некое состояние и добавляем. меняем строки кода, тем самым создавая новое состояние.
	3	+Условно мы можем сказать, что предыдущее состояние является корректным - в нем программа выполняет поставленные задачи, а вот состояние после изменения может содержать ошибки.
	4	+Механизмы тестирования призваны удостовериться, что новое состояние кодовой базы (версия приложения), работает корректно.
	5	+Тест описывание наши ожидания относительно поведения программы. Выполнение теста подтверждает, что код ведет себя именно так, как он него ожидается. (Это может касаться, как обязательств интерфейсов на уровне кода, так и поведение и контракт web api, UI, отправки сообщений, состояния БД, поведения отдельно взятой функции).
	6	+[[AS IS TO BE>>doc:Архитектура и модели.Про приложение.AS IS TO BE.WebHome]]
	7	+
1	1	----
2	2
	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	+
3	3	==== Внутренние ссылки: ====
4	4
5	5	====== Дочерние страницы: ======
...	...	@@ -22,35 +22,10 @@
22	22
23	23	----
24	24
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		-| |(((
37		-|=(% style="width: 224px;" %)Тип|=(% style="width: 1298px;" %)
38		-|(% style="width:224px" %)[[Unit test>>doc:.UnitTest.WebHome]].
39		-Модульное тестирование.|(% style="width:1298px" %)(((
40		-Тестирование отдельных модулей (компонентов) системы(программы) в изолированной среде, с заранее известными входными и выходными значениями тестов. Используется техника подмены реализации, когда вместо зависимостей классу передаются заглушки с заранее известным поведением и наборами данных (MOQ). Обычно предполагает изолирование от внешних систем и хранилищ данных.
41		-Обычно является наиболее дешевым с точки зрения выполнения.
	49	+Ссылки:
42	42
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		-| |(((
51	51	Автоматизированное интеграционное тестирование ASP.NET приложения
52	52	https://habr.com/ru/post/174735/
53		-
54	54	Автоматизация тестирования Web-приложений
55	55	https://habr.com/ru/post/178407/
56	56
...	...	@@ -57,4 +57,3 @@
57	57
58	58	В чём разница Smoke, Sanity, Regression, Re-test и как их различать?
59	59	https://habr.com/ru/post/358142/
60		-)))