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

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

Комментарий

Подробности

Свойства страницы
Содержимое
... ... @@ -1,55 +1,30 @@
1 -----
1 +Кодовая база может быть представлена в виде точек состояний.
2 +Каждый раз, когда мы вносим изменения в код, мы берем за основу некое состояние и добавляем. меняем строки кода, тем самым создавая новое состояние.
3 +Условно мы можем сказать, что предыдущее состояние является корректным - в нем программа выполняет поставленные задачи, а вот состояние после изменения может содержать ошибки.
4 +Механизмы тестирования тестирования призваны удостовериться, что новое состояние кодовой базы (версия приложения), работает корректно.
5 +Тест описывание наши ожидания относительно поведения программы. Выполнение теста подтверждает, что код ведет себя именно так, как он него ожидается. (Это может касаться, как обязательств интерфейсов на уровне кода, так и поведение и контракт web api).
2 2  
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 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 -| |(((
9 +Функциональное и нефункциональное тестирование.
10 +
36 36  |=(% style="width: 224px;" %)Тип|=(% style="width: 1298px;" %)
37 -|(% style="width:224px" %)[[Unit test>>doc:.UnitTest.WebHome]].
38 -Модульное тестирование.|(% style="width:1298px" %)(((
12 +|(% style="width:224px" %)UnitTest (модульный)|(% style="width:1298px" %)(((
39 39  Тестирование отдельных модулей (компонентов) системы(программы) в изолированной среде, с заранее известными входными и выходными значениями тестов. Используется техника подмены реализации, когда вместо зависимостей классу передаются заглушки с заранее известным поведением и наборами данных (MOQ). Обычно предполагает изолирование от внешних систем и хранилищ данных.
40 40  Обычно является наиболее дешевым с точки зрения выполнения.
41 41  
42 42  MOQ - объекты, выполняющий роль заглушки, замещающей реальны объекты, с заранее известными входами и выходами.
43 43  )))
44 -|(% style="width:224px" %)[[Интеграционное тестирование>>doc:.Интеграционное тестирование.WebHome]]|(% style="width:1298px" %)Тестирование взаимодействия между собой различных модулей системы. По сравнению с UnitTest более приближено к реальному виду системы.
18 +|(% style="width:224px" %)Интеграционное тестирование|(% style="width:1298px" %)Тестирование взаимодействия между собой различных модулей системы. По сравнению с UnitTest более приближено к реальному виду системы.
45 45  |(% style="width:224px" %)Регрессионное тестирование|(% style="width:1298px" %)Проверка функционала, который уже существовал в системе и не является новым для нее. Суть в том, чтобы убедиться, что в рамках доработок системы старые функции/варианты использования не были повреждены/некорректно изменены.
46 -|(% style="width:224px" %)[[Нагрузочное тестирование>>doc:.Нагрузочное тестирование.WebHome]]|(% style="width:1298px" %)Проверка, что инфраструктура системы справляется с предполагаемой нагрузкой.
47 -Проверка производительности компонентов системы.
48 -)))
49 -| |(((
20 +|(% style="width:224px" %)Нагрузочное тестирование|(% style="width:1298px" %)Проверка, что инфраструктура системы справляется с предполагаемой нагрузкой.
21 +
22 +----
23 +
24 +Ссылки:
25 +
50 50  Автоматизированное интеграционное тестирование ASP.NET приложения
51 51  https://habr.com/ru/post/174735/
52 -
53 53  Автоматизация тестирования Web-приложений
54 54  https://habr.com/ru/post/178407/
55 55  
... ... @@ -56,4 +56,3 @@
56 56  
57 57  В чём разница Smoke, Sanity, Regression, Re-test и как их различать?
58 58  https://habr.com/ru/post/358142/
59 -)))
XWiki.XWikiComments[1]
Автор
... ... @@ -1,1 +1,0 @@
1 -XWiki.cccc1808
Комментарий
... ... @@ -1,2 +1,0 @@
1 -Тестируем базу данных на [[MSTest>>doc:Разработка.NET.Библиотеки.Тестирование.MSTest.WebHome]]
2 -[[https:~~/~~/habr.com/ru/post/481474/>>url:https://habr.com/ru/post/481474/]]
Дата
... ... @@ -1,1 +1,0 @@
1 -2023-02-03 17:56:06.225
XWiki.XWikiComments[2]
Автор
... ... @@ -1,1 +1,0 @@
1 -XWiki.cccc1808
Комментарий
... ... @@ -1,2 +1,0 @@
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,1 +1,0 @@
1 -2023-05-21 10:44:37.6