ТПО. ТПО (копия). Понятие тестирование, его эволюция

• Название: Понятие тестирование, его эволюция
• Дата: 07.06.2022
• Размер: 95.07 Kb.
• Имя файла: ТПО (копия).docx
• Тип: Документы; #576272

1. 
   Понятие тестирование, его эволюция.
   

Тестирование программного обеспечения — процесс анализа программного средства и сопутствующей документации с целью выявления дефектов и повышения качества продукта.

На протяжении десятилетий развития разработки ПО к вопросам тестирования и обеспечения качества подходили очень и очень по-разному. Можно выделить несколько основных «эпох тестирования».

В 50-60-е фактически тестирование представляло собой скорее отладку программ.

В 90-х годах произошёл переход от тестирования как такового к более всеобъемлющему процессу, который называется «обеспечение качества

В нулевые годы нынешнего века развитие тестирования продолжалось в контексте поиска всё новых и новых путей, методологий, техник и подходов к обеспечению качества

2. 
   Цели тестирования.
   

Цель тестирования — проверка соответствия ПО предъявляемым требованиям, обеспечение уверенности в качестве ПО, поиск очевидных ошибок в программном обеспечении, которые должны быть выявлены до того, как их обнаружат пользователи программы.

Можно определить такие основные цели тестирования программного обеспечения:

– Предоставление информации о качестве ПО конечному заказчику;

– Повышение качества ПО;

– Предотвращение появления дефектов.

3. 
   Место тестирования в жизненном цикле ПО.
   

Тестирование ПО представляет из себя процесс проверки того, насколько поведение реального ПО соответствует требованиям и ожиданиям. Проводимые для этого тесты основаны на задокументированных требованиях заказчика.

Жизненный цикл разработки состоит из следующих этапов:
 1. Анализ требований
 2. Дизайн
 3. Разработка
 4. Тестирование и дебаггинг
 5. Эксплуатация и поддержка

На шаге тестирования должны быть проведены полное функциональное тестирование и тестирование пользовательских интерфейсов, а все обнаруженные дефекты должны быть задокументированы в системе баг-трекинга.

4. 
   Социальные аспекты деятельности тестировщика.
   

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

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

1) повышенная ответственность и исполнительность; 2) хорошие коммуникативные навыки, способность ясно, быстро, чётко выражать свои мысли; 3) терпение, усидчивость, внимательность к деталям, наблюдательность; 4) хорошее абстрактное и аналитическое мышление; 5) способность ставить нестандартные эксперименты, склонность к исследовательской деятельности.

5. 
   Уровни тестирования.
   

https://qalabs.com.ua/urovni-testirovanija.html

Уровни тестирования

• 
  Модульное тестирование (Unit testing)
  
• 
  Интеграционное тестирование (Integration testing)
  
• 
  Системное тестирование (System testing)
  
• 
  Приемочное тестирование (Acceptance testing)
  
• 
  Тестирование методом черного ящика (Black-box testing)
  
• 
  Тестирование методом белого ящика (White-box testing)
  
• 
  Тестирование методом серого ящика (Gray-box testing)
  

6. 
   Виды и группы тестирования характеристик программной системы.
   

Анализ ПО с позиции его ключевых или вспомогательных функций определяет тип тестирования:

• 
  Функциональное
  
• 
  Нефункциональное
  

В зависимости от того, используют ли тестировщики дополнительные программные средства для тестирования приложений или программ, тестирование бывает:

• 
  Мануальное (ручное) – без использования дополнительных программных средств, т. е. «вручную».
  
• 
  Автоматизированное – с использованием программных средств (более детально в описании курса по автоматизации тестирования ПО).
  

Позитивность сценария

Этот подход определяет поведение системы в привычных и экстремальных условиях.

• 
  Позитивная проверка – оценка ожидаемого поведения. Это тестирование проводится в первую очередь, ведь позволяет определить корректность работы программы.
  
• 
  Негативная – определение устойчивости системы в нестандартной ситуации. Например, неожиданный сценарий взаимодействия пользователя с интерфейсом.
  

Уровень

Этот пункт определяет объект тестирования.

• 
  Модульное / юнит-тестирование – проверка корректной работы отдельных единиц ПО, модулей. Этот вид тестирования могут выполнять сами разработчики.
  
• 
  Интеграционное тестирование – проверка взаимодействия между несколькими единицами ПО.
  
• 
  Системное – проверка работы приложения целиком.
  
• 
  Приёмочное – оценка соответствия заявленным требованиям к программному продукту.
  

От объекта тестирования движемся к его субъекту. Вы могли слышать об альфа- и бета-тестировании. А поучаствовать в одном из них можно, даже не будучи тестировщиком. Итак, по исполнителю тестирование делится на:

• 
  Альфа-тестирование – проверка программного продукта на поздней стадии разработки. Проводится разработчиками или тестировщиками.
  
• 
  Бета-тестирование – оценка ПО перед выходом на рынок в фокус-группе или добровольцами. Отзывы собираются, анализируются и учитываются при внесении правок.
  

7. 
   Планирование процесса тестирования.
   

Планирование (planning326) — непрерывный процесс принятия управленческих решений и методической организации усилий по их реализации с целью обеспечения качества некоторого процесса на протяжении длительного периода времени.

К высокоуровневым задачам планирования относятся:

• снижение неопределённости;

• повышение эффективности;

• улучшение понимания целей;

• создание основы для управления процессами.

8. 
   Требования. Выявление требований.
   

Требования к программному обеспечению — совокупность запросов/утверждений относительно атрибутов, свойств или качеств программной системы, подлежащей реализации. Создаются в процессе проработки (анализа и синтеза) задания на разработку/модернизацию программного обеспечения (ПО).

Стадию создания или разработки требований условно можно разделить на 4 этапа.
 1. Выявление требований (сбор информации).
 2. Анализ требований.
 3. Спецификация (документация) требований.
 4. Проверка требований.

Выявление требований — самый трудный, важный, подверженный ошибкам и требующий интенсивного общения этап разработки ПО.
Выявление требований – это творческий процесс, и каждый использует свои инструменты для получения результата, т.е. требований.

9. 
   Уровни и виды требований.
   

Виды требований по уровням:

• 
  Бизнес-требования — определяют назначение ПО, описываются в документе о видении (vision) и границах проекта (scope).
  
• 
  Пользовательские требования — определяют набор пользовательских задач, которые должна решать программа, а также способы (сценарии) их решения в системе. Пользовательские требования могут выражаться в виде фраз утверждений, в виде сценариев использования (англ. use case), пользовательских историй (англ. user stories), сценариев взаимодействия (scenario).
  
• 
  Функциональный уровень (функции).
  

Бизнес-правила (business rules75) описывают особенности принятых в предметной области (и/или непосредственно у заказчика) процессов, ограничений и иных правил. Эти правила могут относиться к бизнес-процессам, правилам работы сотрудников, нюансам работы ПО и т.д.

Атрибуты качества (quality attributes76) расширяют собой нефункциональные требования и на уровне пользовательских требований могут быть представлены в виде описания ключевых для проекта показателей качества (свойств продукта, не связанных с функциональностью, но являющихся важными для достижения целей создания продукта — производительность, масштабируемость, восстанавливаемость).

Нефункциональные требования (non-functional requirements79) описывают свойства системы (удобство использования, безопасность, надёжность, расширяемость и т.д.), которыми она должна обладать при реализации своего поведения.

10. 
    Характеристики качественных требований.
    

Выделяют 9 критериев качества требований:

1) корректность;

2) недвусмысленность;

3) полнота;

4) непротиворечивость;

5) упорядоченность по важности и стабильности;

6) проверяемость;

7) модифицируемость;

8) трассируемость;

9)Корректные требования.

11. 
    Техники тестирования требований. Типичные ошибки при разработке и анализе требований.
    

Тестирование документации и требований относится к разряду нефункционального тестирования (non-functional testing103). Основные техники такого тестирования в контексте требований таковы.

Взаимный просмотр (peer review104).

Взаимный просмотр («рецензирование») является одной из наиболее активно используемых техник тестирования требований и может быть представлен в одной из трёх следующих форм (по мере нарастания его сложности и цены): • Беглый просмотр • Технический просмотр • Формальная инспекция

Вопросы. Следующей очевидной техникой тестирования и повышения качества требований является (повторное) использование техник выявления требований, а также (как отдельный вид деятельности) — задавание вопросов.

Тест-кейсы и чек-листы. Мы помним, что хорошее требование является проверяемым, а значит, должны существовать объективные способы определения того, верно ли реализовано требование.

12. 
    Аксиомы тестирования.
    

Аксиомы тестирования

• 
  Хороший тест тот, который позволяет обнаружить ошибку, а не тот, который демонстрирует правильную работу программы.
  
• 
  Тесты, не способствующие обнаружению ошибок и только подтверждающие корректность функционирования программного обеспечения, являются неэффективными, т.к. приводят к бесполезным затратам ресурсов и времени.
  
• 
  Одна из самых сложных проблем при тестировании - решить, когда нужно его закончить.
  
• 
  Невозможно тестировать свою собственную программу. Тестирование должно быть в высшей степени разрушительным процессом, но программист не может относиться к своей прог­рамме как разрушитель (психологические причины, жесткий график, давление коллектива и т.д.).
  
• 
  Необходимая часть всякого теста — описание ожидаемых выходных данных или результатов. Ожидаемые результаты нужно определять заранее.
  
• 
  Избегайте невоспроизводимых тестов, не тестируйте «с лету».
  
• 
  Никогда не используйте тестов, которые тут же выбрасываются. Более того, тесты следует документировать и хранить в такой форме, чтобы каждый мог использовать их повторно.
  
• 
  Готовьте тесты, как для правильных, так и для непра­вильных входных данных.
  
• 
  По мере того как растет количество найденных ошибок, так же растет вероятность такого же количества не найденных ошибок.
  
• 
  Тест удаляется из дальнейшей работы, если он отработал правильно, т.к. его повторный пропуск не дает ничего нового.
  
• 
  Тест возвращается в работу, если вносились изменения в блоки, работающие при этом тесте.
  
• 
  Составляя календарный план разработки программного обеспечения, разумно всегда настаивать на выделении необходимого времени для обеспечения надлежащего качества его тестирования.
  
• 
  Если программное обеспечение правильно ведет себя для солидного набора тестов, нет оснований утверждать, что в нем нет ошибок.
  

13. 
    Тест-кейсы, их структура.
    

Тест-кейс (test case286) — набор входных данных, условий выполнения и ожидаемых результатов, разработанный с целью проверки того или иного свойства или поведения программного средства. Под тест-кейсом также может пониматься соответствующий документ, представляющий формальную запись тест-кейса.

Высокоуровневый тест-кейс (high level test case287) — тест-кейс без конкретных входных данных и ожидаемых результатов.

Низкоуровневый тест-кейс (low level test case288) — тест-кейс с конкретными входными данными и ожидаемыми результатами.

Тест-сценарий (test scenario295 , test procedure specification, test script) — документ, описывающий последовательность действий по выполнению теста (также известен как «тест-скрипт»).

Каждый тест кейс должен иметь 3 части:

PreConditions	Список действий, которые приводят систему к состоянию пригодному для проведения основной проверки. Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния.
Test Case Description	Список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям
PostConditions	Список действий, переводящих систему в первоначальное состояние (состояние до проведения теста - initial state)

14. 
    Наборы тест-кейсов, их классификация.
    

Набор тест-кейсов — совокупность тест-кейсов, выбранных с некоторой общей целью или по некоторому общему признаку.
Наборы тест-кейсов можно разделить на свободные (порядок выполнения тест-кейсов не важен) и последовательные (порядок выполнения тест-кейсов важен)

Классификация:

14. 
    Классификация методов тестирования.
    

По запуску кода на исполнение:

o Статическое тестирование — без запуска.

o Динамическое тестирование — с запуском.

• По доступу к коду и архитектуре приложения:

o Метод белого ящика — доступ к коду есть.

o Метод чёрного ящика — доступа к коду нет.

o Метод серого ящика — к части кода доступ есть, к части — нет.

• По степени автоматизации:

o Ручное тестирование — тест-кейсы выполняет человек.

o Автоматизированное тестирование — тест-кейсы частично или полностью выполняет специальное инструментальное средство.

• По уровню детализации приложения (по уровню тестирования):

o Модульное (компонентное) тестирование — проверяются отдельные

небольшие части приложения.

o Интеграционное тестирование — проверяется взаимодействие между

несколькими частями приложения.

o Системное тестирование — приложение проверяется как единое целое.

• По (убыванию) степени важности тестируемых функций (по уровню функционального тестирования):

o Дымовое тестирование— проверка самой важной, самой ключевой

функциональности.

Тестирование критического пути — проверка функциональности, используемой типичными пользователями в типичной повседневной деятельности.

o Расширенное тестирование — проверка всей (остальной) функциональности, заявленной в требованиях.

• По принципам работы с приложением:

o Позитивное тестирование — все действия с приложением выполняются строго по инструкции без никаких недопустимых действий, некорректных данных и т.д. Можно образно сказать, что приложение исследуется в «тепличных условиях».

o Негативное тестирование — в работе с приложением выполняются

(некорректные) операции и используются данные, потенциально приводящие к ошибкам (классика жанра — деление на ноль).

14. 
    Методы функционального тестирования.
    

При функциональном тестировании различают следующие методы формирования тестовых наборов:

• эквивалентное разбиение;

• анализ граничных значений;

• анализ причинно-следственных связей(Метод функциональных диаграмм);
Суть техники эквивалентного разбиения в том, чтобы:

1. 
   Разделить данные на группы (классы эквивалентности), которые, как предполагается, обрабатываются системой схожим образом (то есть ведут систему к одному состоянию);
   
2. 
   Из каждой группы (класса) выбрать одно значение и проверить его.
   

Техника анализа граничных значений основана на проверке значений на переходах из одних границах классов эквивалентности в другие. Для применения этой техники нужно знать минимальные и максимальные значения классов.
Метод функциональных диаграмм — метод, в котором функциональная диаграмма формально является текстом, в который транслируется спецификация. В диаграмму включаются причины (входные условия) и следствия (выходные условия или преобразование системы).
17.Методы структурного тестирования.

Для получения эффективных тестовых наборов данных при структурном тестировании используются следующие критерии:

1. 
   Покрытие операторов. Этот критерий предполагает выбор такого тестового набора данных, который вызывает выполнение каждого оператора в программе хотя бы один раз.
   
2. 
   Покрытие узлов ветвления (покрытия решений). Этот критерий предполагает разработку такого количества тестов, чтобы в каждом узле ветвления был обеспечен переход по веткам "истина" и "ложь" хотя бы один раз.
   
3. 
   Покрытие условий. Если узел ветвления содержит более одного условия (сложное условие), тогда нужно разрабатывать число тестов, достаточное для того, чтобы возможные результаты каждого условия в решении выполнялись по крайней мере 1 раз.
   
4. 
   Комбинаторное покрытие условий. Этот критерий требует создания такого числа тестов, чтобы все возможные комбинации результатов условия в каждом решении выполнялись хотя бы 1 раз
   

18. 
    Методы направленного поиска ошибок.
    

Предугадывание ошибок- техника тестирования, в которой тесты разрабатываются на основе опыта тестировщика и его знаний о том, какие дефекты типичны для тех или иных компонентов или областей функциональности приложения.

Эвристическая оценка - техника тестирования удобства использования{85} , направленная на поиск проблем в интерфейсе пользователя, представляющих собой отклонение от общепринятых норм.

Добавления ошибок- техника тестирования, в которой в приложение специально добавляются заранее известные, специально продуманные ошибки с целью мониторинга их обнаружения и устранения и, таким образом, формирования более точной оценки показателей процесса тестирования.

Мутационное - техника тестирования, в которой сравнивается поведение нескольких версий одного и того же компонента, причём часть таких версий может быть специально разработана с добавлением ошибок (что позволяет оценить эффективность тест-кейсов — качественные тесты обнаружат эти специально добавленные ошибки)

18. 
    Процедуры исследовательского тестирования.
    

Исследовательское тестирование предполагает параллельную разработку и выполнение кейсов, то есть отсутствие четкого сценария тестирования. Исследовательское тестирование используется в тех случаях, когда выполнение следующего теста неочевидно.
исследовательское тестирование — это тесно взаимосвязанные изучение, планирование и тестирование.

18. 
    Сущность метода эквивалентного разбиения.
    

Метод эквивалентного разбиения заключается в следующем. Область всех возможных наборов входных данных программы по каждому параметру разбивают на конечное число групп - классов эквивалентности. Наборы данных такого класса объединяют по принципу обнаружения одних и тех же ошибок: если набор какого-либо класса обнаруживает некоторую ошибку, то предполагается, что все другие тесты этого класса эквивалентности тоже обнаружат эту ошибку и наоборот. Разработку тестов методом эквивалентного разбиения осуществляют в два этапа: на первом выделяют классы эквивалентности, а на втором - формируют тесты.

18. 
    Сущность метода анализа граничных значений.
    

Техника анализа граничных значений основана на проверке значений на переходах из одних границах классов эквивалентности в другие. Для применения этой техники нужно знать минимальные и максимальные значения классов.

18. 
    Использование метода таблиц решений.
    

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

Таблица решений – это табличное представление входных данных в сравнении с правилами / случаями / условиями испытаний.

23.Метод функциональных диаграмм.

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

24. Метод тестирования переходов между состояниями.

Тестирование перехода между состояниями определяется как методика тестирования программного обеспечения, при которой изменения условий ввода вызывают изменения состояния в тестируемом приложении (AUT).

Это метод тестирования черного ящика, в котором тестировщик анализирует поведение тестируемого приложения для различных входных условий в последовательности. В этом методе тестер предоставляет как положительные, так и отрицательные входные значения теста и записывает поведение системы.

25. 
    Процедура разбиения входного пространства на категории.
    

Позволяет обнаруживать ошибки еще до создания кода, потому что источником ввода является спецификация, и тестирование основано на ее анализе. Недоработки в спецификациях можно обнаружить на ранних стадиях, часто до ее реализации в коде.
Эквивалентное тестирование с разделением — это метод тестирования программного обеспечения, который делит входные тестовые данные приложения на каждый раздел, по крайней мере, один раз из эквивалентных данных, из которых могут быть получены тестовые примеры. Этот метод тестирования позволяет сократить время, необходимое для тестирования программного обеспечения.

25. 
    Методы, основанные на анализе кода
    

По запуску кода на исполнение:

o Статическое тестирование — без запуска.

o Динамическое тестирование — с запуском.

По доступу к коду и архитектуре приложения:

o Метод белого ящика — доступ к коду есть.

o Метод чёрного ящика — доступа к коду нет.

o Метод серого ящика — к части кода доступ есть, к части — нет.

27.Методы направленного поиска ошибок.

Предугадывание ошибок- техника тестирования, в которой тесты разрабатываются на основе опыта тестировщика и его знаний о том, какие дефекты типичны для тех или иных компонентов или областей функциональности приложения.

Эвристическая оценка - техника тестирования удобства использования{85} , направленная на поиск проблем в интерфейсе пользователя, представляющих собой отклонение от общепринятых норм.

Добавления ошибок- техника тестирования, в которой в приложение специально добавляются заранее известные, специально продуманные ошибки с целью мониторинга их обнаружения и устранения и, таким образом, формирования более точной оценки показателей процесса тестирования.

Мутационное - техника тестирования, в которой сравнивается поведение нескольких версий одного и того же компонента, причём часть таких версий может быть специально разработана с добавлением ошибок (что позволяет оценить эффективность тест-кейсов — качественные тесты обнаружат эти специально добавленные ошибки)

28.Методы, основанные на использовании

Тестирование  Black-Box

Тестирование серых коробок

Тестирование белого ящика

29.Тестирование Web-приложений

Тестирование веб-приложений – процесс проверки клиент-серверных продуктов, размещаемых в доступе посредством сети, зачастую включающий поддержку большого кол-ва взаимозависимых элементов.

В процессе тестирования веб-приложений QA-инженеры учитывают особенности архитектуры проекта и механику взаимодействия базы данных, серверной части приложения, веб-сервисов, сторонних компонентов и пользовательского интерфейса.

30.Классификация дефектов, обнаруженных при тестировании

Blocker. Ошибка, которая приводит программу в нерабочее состояние. 

Critical. Критический дефект, приводящий некоторый ключевой функционал в нерабочее состояние. Major. Весьма серьезная ошибка, свидетельствующая об отклонении от бизнес логики или нарушающая работу программы. Не имеет критического воздействия на приложение.

Minor. Незначительный дефект, не нарушающий функционал тестируемого приложения, но который является несоответствием ожидаемому результату.(ошибка дизайна)

Trivial. Баг, не имеющий влияние на функционал или работу программы, но который может быть обнаружен визуально. (ошибка в тексте)

Градация дефектов, с точки зрения приоритетности исправления (Priority):

High. Баг должен быть исправлен как можно быстрее, т.к. он критически влияет на работоспособность программы.

Medium. Дефект должен быть обязательно исправлен, но он не оказывает критическое воздействие на работу приложения.

Low. Ошибка должна быть исправлена, но она не имеет критического влияния на программу и устранение может быть отложено, в зависимости от наличия других более приоритетных дефектов.

31.Термин «дефект» и связанные с ним понятия.

Дефект — отклонение фактического результата от ожиданий наблюдателя, сформированных на основе требований, спецификаций, иной документации или опыта и здравого смысла.

Связанные понятия:

Аномалия или инцидент — любое отклонение наблюдаемого (фактического) состояния, поведения, значения,результата, свойства от ожиданий наблюдателя, сформированных на основе требований, спецификаций, иной документации или опыта и здравого смысла.

Сбой или отказ — отклонение поведения системы от ожидаемого

32. Жизненный цикл дефекта



33.Структура отчета о дефекте

1. Заголовок ошибки

2. Описание ошибки

3. Начальные условия

4. Шаги воспроизведения

5. Ожидаемый результат

6. Фактический результат

7. Вложения
34.Структура итогового отчета о результатах тестирования

Отчёт о результатах тестирования - документ, обобщающий результаты работ по тестированию и содержащий информацию, достаточную для соотнесения текущей ситуации с тест-планом и принятия необходимых управленческих решений.

Отчёт о результатах тестирования включает следующие разделы:

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

 35.Метрики оценивания программных продуктов

В настоящее время в мировой практике используется несколько сотен метрик программ. Существующие измерения качества программ можно сгруппировать по шести направлениям:
1) измерения топологической и информационной сложности программ (производятся с помощью соответствующих метрик и представляют собой косвенные оценки надежности);

• 
  2) оценки функциональной надежности программных систем, позволяющие прогнозировать проявление ошибок в программе (производятся непосредственно с помощью моделей надежности);
  
• 
  3) измерения производительности ПО и оценки повышения его эффективности путем выявления ошибок проектирования;
  
• 
  4) измерения уровня языковых средств и оценки их применения;
  
• 
  5) измерения восприятия и понимания программных текстов, ориентированные на психологические факторы, существенные для сопровождения и модификации программ;
  
• 
  6) измерения производительности труда программистов для прогнозирования сроков разработки программ и планирования работ по созданию программных комплексов.
  
  36.Критерии завершения тестирования
  
  Следует выделить 3 основных критерия для остановки, завершения тестирования:
  

• 
  Время
  
• 
  Бюджет
  
• 
  Все тест кейсы пройдены, найденные баги исправлены и перепроверены
  
  37.Основные тесты производительности
  

В тестировании производительности различают следующие направления:

• 
  нагрузочное (load)
  
• 
  стресс (stress)
  
• 
  тестирование стабильности (endurance or soak or stability)
  
• 
  конфигурационное (configuration)
  

 

    38.Этапы проведения тестирования производительности



Обычно, тестирование функционала включает в себя:

• 
  определение выполняющегося в программе функционала
  
• 
  поэтапная проверка ввода данных и вывода результата
  
• 
  выполнение предписанных действий для проверки правильности работы функционала (тест-кейсы)
  
• 
  анализ полученного результата работы функционала программы
  

39. Области автоматизации тестирования.

 

Область автоматизации — это область вашего тестируемого приложения, которая будет автоматизирована. Следующие пункты помогают определить область:

• 
  Особенности, которые важны для бизнеса
  
• 
  Сценарии с большим объемом данных
  
• 
  Общие функции в приложениях
  
• 
  Техническая осуществимость
  
• 
  Степень повторного использования бизнес-компонентов
  
• 
  Сложность тестовых случаев
  
• 
  Возможность использовать одни и те же тесты для кросс-браузерного тестирования
  

 

40. Достоинства и недостатки автоматизации тестирования

 

Преимущества:

• Проверка состояния

• Быстрый отчёт

• Экономия человеческого ресурса

• Возможность разработчикам внести свой вклад в тесты
  
  
  
  

Недостатки автоматизации тестирования:

Ложная уверенность в качестве

Ненадежность.

Автоматизация не является тестированием.

Техническое обслуживание тестов

Медленная обратная связь