Проверки и Приемки — различия между версиями

(Новая страница: «'''Проверка''' (verification) — это проверка того, что система соответствует какому-то описанию ц…»)
 
м (См. также)
 
(не показано 10 промежуточных версий этого же участника)
Строка 1: Строка 1:
'''Проверка''' (verification) — это проверка того, что система соответствует какому-то описанию целевой системы (требованиям, архитектуре, неархитектурной части проекта).
+
'''[[Верификация]]''' (verification) — это проверка того, что система соответствует какому-то описанию целевой системы (требованиям, архитектуре, неархитектурной части проекта).
  
'''Приёмка''' (validation) — это проверка того, что использующая система соответствует желаемому стейкхолдером её описанию, если в её составе работает целевая система.
+
'''[[Валидация]]''' (validation) — это проверка того, что использующая система соответствует желаемому стейкхолдером её описанию, если в её составе работает целевая система.
  
 
Очень частая ошибка: забывают о необходимости валидации (приемке). В результате система удовлетворяет инженеров, которые эту систему сделали в соответствии со спецификациями, но не удовлетворяет стейкхолдеров: испытания должны проводиться не только для целевой системы (проверки), но и для использующей системы (приёмка!). Только после приёмки (то есть удостоверения в том, что использующая система работает как надо) системные инженеры могут считать, что их работа выполнена.  
 
Очень частая ошибка: забывают о необходимости валидации (приемке). В результате система удовлетворяет инженеров, которые эту систему сделали в соответствии со спецификациями, но не удовлетворяет стейкхолдеров: испытания должны проводиться не только для целевой системы (проверки), но и для использующей системы (приёмка!). Только после приёмки (то есть удостоверения в том, что использующая система работает как надо) системные инженеры могут считать, что их работа выполнена.  
Строка 9: Строка 9:
 
'''На V&V (проверки/приёмки/контроль/тестирование/испытания) приходится до половины всех затрат на разработку!'''
 
'''На V&V (проверки/приёмки/контроль/тестирование/испытания) приходится до половины всех затрат на разработку!'''
  
Как всегда, основной тренд в системной инженерии – это сдвиг всех проверок и приёмок влево на V-диаграмме (см. пост Donald Firesmith – «Four Types of Shift Left Testing»).
+
Как всегда, основной тренд в системной инженерии – это сдвиг всех проверок и приёмок влево на V-диаграмме (см. пост Donald Firesmith – [http://blog.sei.cmu.edu/post.cfm/four-types-shift-left-testing-082 «Four Types of Shift Left Testing»]).
  
== Ссылки ==
+
== Классическая V&V ==
 +
* [http://sebokwiki.org/wiki/System_Realization Место проверки и приёмки в ходе воплощения системы (водопад)];
 +
* [http://sebokwiki.org/wiki/System_Verification Статья про верификацию в SEBoK];
 +
* [http://sebokwiki.org/wiki/System_Validation Статья про валидацию в SEBoK];
 +
* что делает [http://en.wikipedia.org/wiki/Test_engineer инженер по испытаниям (hardware test engineer)];
 +
* чему учат: [http://www.nafems.org/events/nafems/2014/vandv3/ пример программы курса] ([http://www.tonex.com/training-courses/system-verificationvalidation ещё]);
 +
* [http://www.academia.edu/1745073/Systems_Engineering_MS_Course_Int%20egrated_Product_Verification_and_Validation пример материала (слайдов) для вузовского курса];
 +
* [http://courses.csail.mit.edu/6.141/spring2013/pub/lectures/Lec07-SystemEngineering.pdf слайды занятия: что обсуждается в «тестовых стратегиях» (и чуть-чуть про тестирование роботов)].
  
* '''Классика жанра''' (классические определения и общее понимание предмета):
+
== Разработка через тестирование ==
**место проверки и приёмки в ходе воплощения системы (водопад);
+
'''TDD (test driven development)''' разработка программного обеспечения, вариант [[agile]] методологии разработки
**проверка;
+
* [http://ailev.livejournal.com/1015692.html driven против based];
**приёмка;
+
* [http://en.wikipedia.org/wiki/Testdriven_development тестоориентированная разработка];
**что делает инженер по испытаниям (hardware test engineer);
+
* [http://david.heinemeierhansson.com/2014/tdd-is-dead-long-livetesting.html пример, как и в пользу чего отказываются от TDD] (читать нужно так «TDD очень хорош, но это явно не панацея в тестировании»);
**чему учат: пример программы курса (ещё);
+
* [http://www.ambysoft.com/essays/agileTesting.html что ещё кроме TDD бывает в agile] (а именно, developer TDD, developer regression testing, reviews/inspections, end of lifecycle testing, acceptance TDD, parallel independent testing, independent regression testing).
**пример материала (слайдов) для вузовского курса;
+
 
**слайды занятия: что обсуждается в «тестовых стратегиях» (и чуть-чуть про тестирование роботов).
+
== Тестирование на основе моделей ==
* '''TDD, test driven development''' (разработка софта, вариант agile методологии разработки)
+
'''Model-based testing''' (и по сопричастности test automation) - приходится разбираться, как устроена предметная область – т.е. что такое испытания как таковые.
driven против based:
+
* [http://en.wikipedia.org/wiki/Model-based_testing model-based testing];
**тестоориентированная разработка;
+
* [https://www.st.cs.unisaarland.de/edu/testingdebugging10/slides/19_ModelBasedTesting.pdf пример слайдов занятия по model-based testing];
**пример, как и в пользу чего отказываются от TDD (читать нужно так «TDD очень хорош, но это явно не панацея в тестировании»);
+
* [http://en.wikipedia.org/wiki/TPT_%28software%29 time partition testing];
** что ещё кроме TDD бывает в agile (а именно, developer TDD, developer regression testing, reviews/inspections, end of lifecycle testing, acceptance TDD, parallel independent testing, independent regression testing).
+
* [http://penxy.com/joso обезьянки против роботов (на русском)] ([http://penxy.com/wylo 2]) ([http://penxy.com/rygi 3]).
* '''Model-based testing''' (и по сопричастности test automation): тут очень интересно, ибо приходится разбираться, как устроена предметная область – т.е. что такое испытания как таковые.
+
 
** model-based testing;
+
== Тестирование киберфизических систем ==
** пример слайдов занятия по model-based testing;
+
* [https://www.linkedin.com/groups/Difference-between-MIL-SIL-PIL-%20109866.S.167229094 разница в Model in loop(MIL), Software in loop(SIL), Processor in loop(PIL), Hardware in loop(HIL)];
** time partition testing;
+
* [http://home.hit.no/~hansha/documents/lab/Lab%20Work/HIL%20Simulat%20ion/Background/Introduction%20to%20HIL%20Simulation.pdf hardware-in-the-loop];
** обезьянки против роботов (на русском) (2) (3).
+
* [http://www.autonomie.net/projects/engine_loop_18.html примеры испытательных стендов] (как «что-то-in-the-loop»);
* '''Test of Cyber-physical systems''' (control system engineering):
+
* [http://www.autonomie.net/references/model_based_design_defs_24.html коротенькие определения терминов в картинках].
** разница в Model in loop(MIL), Software in loop(SIL), Processor in loop(PIL), Hardware in loop(HIL);
+
 
** hardware-in-the-loop;
+
== Моделирование инженерных обоснований ==
** примеры испытательных стендов (как «что-то-in-the-loop»);
+
{{Main|Обоснование заявленных свойств}}
** коротенькие определения терминов в картинках.
+
 
* Моделирование инженерных обоснований (в том числе assurance case)
+
== См. также ==
** много-много ссылок внутри.
+
* [[Тестирование|Тестирование (компетенция)]]
 +
* [[FRACAS|Анализ отчета об отказах и система корректирующих действий]]
 +
 
 +
[[Категория:Методы]]

Текущая версия на 21:58, 17 августа 2019

Верификация (verification) — это проверка того, что система соответствует какому-то описанию целевой системы (требованиям, архитектуре, неархитектурной части проекта).

Валидация (validation) — это проверка того, что использующая система соответствует желаемому стейкхолдером её описанию, если в её составе работает целевая система.

Очень частая ошибка: забывают о необходимости валидации (приемке). В результате система удовлетворяет инженеров, которые эту систему сделали в соответствии со спецификациями, но не удовлетворяет стейкхолдеров: испытания должны проводиться не только для целевой системы (проверки), но и для использующей системы (приёмка!). Только после приёмки (то есть удостоверения в том, что использующая система работает как надо) системные инженеры могут считать, что их работа выполнена.

Основной тренд: это непрерывное автоматизированное разноуровневое тестирование, на всех этапах жизненного цикла, в том числе в ходе эксплуатации. Практики проверки и приёмки приходят сейчас главным образом из software engineering (как обычно), а потом медленно с лагом 10 лет принимаются системной инженерией. Software_testing - внизу страницы раздел Topics.

На V&V (проверки/приёмки/контроль/тестирование/испытания) приходится до половины всех затрат на разработку!

Как всегда, основной тренд в системной инженерии – это сдвиг всех проверок и приёмок влево на V-диаграмме (см. пост Donald Firesmith – «Four Types of Shift Left Testing»).

Классическая V&V

Разработка через тестирование

TDD (test driven development) — разработка программного обеспечения, вариант agile методологии разработки

Тестирование на основе моделей

Model-based testing (и по сопричастности test automation) - приходится разбираться, как устроена предметная область – т.е. что такое испытания как таковые.

Тестирование киберфизических систем

Моделирование инженерных обоснований

Основная статья: Обоснование заявленных свойств

См. также