Изменения документа Тестирование

Редактировал(а) Alexandr Fokin 2024/01/11 16:27
<
От версии < 5.3 >
отредактировано Alexandr Fokin
на 2022/09/14 22:04
К версии < 5.17
отредактировано Alexandr Fokin
на 2024/01/11 16:27
Изменить комментарий: К данной версии нет комментариев

Комментарий

Подробности

Свойства страницы
Содержимое
... ... @@ -1,30 +7,56 @@
1 -Кодовая база может быть представлена в виде точек состояний.
2 -Каждый раз, когда мы вносим изменения в код, мы берем за основу некое состояние и добавляем. меняем строки кода, тем самым создавая новое состояние.
3 -Условно мы можем сказать, что предыдущее состояние является корректным - в нем программа выполняет поставленные задачи, а вот состояние после изменения может содержать ошибки.
4 -Механизмы тестирования тестирования призваны удостовериться, что новое состояние кодовой базы (версия приложения), работает корректно.
5 -Тест описывание наши ожидания относительно поведения программы. Выполнение теста подтверждает, что код ведет себя именно так, как он него ожидается. (Это может касаться, как обязательств интерфейсов на уровне кода, так и поведение и контракт web api).
6 -
7 7  ----
8 8  
9 -Функциональное и нефункциональное тестирование.
3 +==== Внутренние ссылки: ====
10 10  
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 +
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 +| |(((
11 11  |=(% style="width: 224px;" %)Тип|=(% style="width: 1298px;" %)
12 -|(% style="width:224px" %)UnitTest (модульный)|(% style="width:1298px" %)(((
38 +|(% style="width:224px" %)[[Unit test>>doc:.UnitTest.WebHome]].
39 +Модульное тестирование.|(% style="width:1298px" %)(((
13 13  Тестирование отдельных модулей (компонентов) системы(программы) в изолированной среде, с заранее известными входными и выходными значениями тестов. Используется техника подмены реализации, когда вместо зависимостей классу передаются заглушки с заранее известным поведением и наборами данных (MOQ). Обычно предполагает изолирование от внешних систем и хранилищ данных.
14 14  Обычно является наиболее дешевым с точки зрения выполнения.
15 15  
16 16  MOQ - объекты, выполняющий роль заглушки, замещающей реальны объекты, с заранее известными входами и выходами.
17 17  )))
18 -|(% style="width:224px" %)Интеграционное тестирование|(% style="width:1298px" %)Тестирование взаимодействия между собой различных модулей системы. По сравнению с UnitTest более приближено к реальному виду системы.
45 +|(% style="width:224px" %)[[Интеграционное тестирование>>doc:.Интеграционное тестирование.WebHome]]|(% style="width:1298px" %)Тестирование взаимодействия между собой различных модулей системы. По сравнению с UnitTest более приближено к реальному виду системы.
19 19  |(% style="width:224px" %)Регрессионное тестирование|(% style="width:1298px" %)Проверка функционала, который уже существовал в системе и не является новым для нее. Суть в том, чтобы убедиться, что в рамках доработок системы старые функции/варианты использования не были повреждены/некорректно изменены.
20 -|(% style="width:224px" %)Нагрузочное тестирование|(% style="width:1298px" %)Проверка, что инфраструктура системы справляется с предполагаемой нагрузкой.
21 -
22 -----
23 -
24 -Ссылки:
25 -
47 +|(% style="width:224px" %)[[Нагрузочное тестирование>>doc:.Нагрузочное тестирование.WebHome]]|(% style="width:1298px" %)Проверка, что инфраструктура системы справляется с предполагаемой нагрузкой.
48 +Проверка производительности компонентов системы.
49 +)))
50 +| |(((
26 26  Автоматизированное интеграционное тестирование ASP.NET приложения
27 27  https://habr.com/ru/post/174735/
53 +
28 28  Автоматизация тестирования Web-приложений
29 29  https://habr.com/ru/post/178407/
30 30  
... ... @@ -31,3 +31,4 @@
31 31  
32 32  В чём разница Smoke, Sanity, Regression, Re-test и как их различать?
33 33  https://habr.com/ru/post/358142/
60 +)))
XWiki.XWikiComments[1]
Дата
... ... @@ -1,0 +1,1 @@
1 +2023-02-03 17:56:06.225
Автор
... ... @@ -1,0 +1,1 @@
1 +XWiki.cccc1808
Комментарий
... ... @@ -1,0 +1,2 @@
1 +Тестируем базу данных на [[MSTest>>doc:Разработка.NET.Библиотеки.Тестирование.MSTest.WebHome]]
2 +[[https:~~/~~/habr.com/ru/post/481474/>>url:https://habr.com/ru/post/481474/]]
XWiki.XWikiComments[2]
Автор
... ... @@ -1,0 +1,1 @@
1 +XWiki.cccc1808
Комментарий
... ... @@ -1,0 +1,2 @@
1 +Use Coded UI tests to test your code
2 +[[https:~~/~~/learn.microsoft.com/en-us/visualstudio/test/use-ui-automation-to-test-your-code?view=vs-2022>>https://learn.microsoft.com/en-us/visualstudio/test/use-ui-automation-to-test-your-code?view=vs-2022]]
Дата
... ... @@ -1,0 +1,1 @@
1 +2023-05-21 10:44:37.6