Исходный код вики Тестирование
Редактировал(а) Alexandr Fokin 2024/01/11 16:27
Последние авторы
author | version | line-number | content |
---|---|---|---|
1 | ---- | ||
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 | ---- | ||
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 | Обычно является наиболее дешевым с точки зрения выполнения. | ||
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 | Автоматизированное интеграционное тестирование ASP.NET приложения | ||
52 | https://habr.com/ru/post/174735/ | ||
53 | |||
54 | Автоматизация тестирования Web-приложений | ||
55 | https://habr.com/ru/post/178407/ | ||
56 | |||
57 | |||
58 | В чём разница Smoke, Sanity, Regression, Re-test и как их различать? | ||
59 | https://habr.com/ru/post/358142/ | ||
60 | ))) |