Как тестировать программу


❶ Как тестировать программы

Вам понадобится

  • - тестируемая программа с исходным кодом;
  • - документация на программу;
  • - план тестирования;
  • - несколько наборов входных данных (как корректных, так и заведомо неправильных);
  • - единомышленники в лице коллег.

Инструкция

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

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

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

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

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

Полезный совет

Если вновь написанная программа работает без ошибок, то ее плохо тестировали.

Источники:

  • «Методы и средства инженерии программного обеспечения », В.А. Петрухин, Е.М. Лаврищева
  • CPU Stress Test

Тестирование программ - процесс обнаружения ошибок в программном продукте

При разработке программного обеспечения значительная часть производственного процесса опирается на тестирование программ. Что это такое и как осуществляется подобная деятельность обсудим в данной статье.

Что называют тестированием?

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

Эффективность

То, насколько хорошо и быстро находятся ошибки, существенным образом влияет на стоимость и длительность разработки программного обеспечения необходимого качества. Так, несмотря на то, что тестеры получают заработную плату в несколько раз меньшую, чем программисты, стоимость их услуг обычно достигает 30 – 40 % от стоимости всего проекта. Это происходит из-за численности личного состава, поскольку искать ошибку – это необычный и довольно трудный процесс. Но даже если программное обеспечение прошло солидное количество тестов, то нет 100 % гарантии, что ошибок не будет. Просто неизвестно, когда они проявятся. Чтобы стимулировать тестеров выбирать типы проверки, которые с большей вероятностью найдут ошибку, применяются различные средства мотивации: как моральные, так и материальные.

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

Что такое тест?

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

Программы часто нацелены на работу с огромным массивом данных. Неужели его необходимо создавать полностью? Нет. Широкое распространение приобрела практика «миниатюризации» программы. В данном случае происходит разумное сокращение объема данных по сравнению с тем, что должно использоваться. Давайте рассмотрим такой пример: есть программа, в которой создаётся матрица размером 50x50. Иными словами – необходимо вручную ввести 2500 тысячи значений. Это, конечно, возможно, но займёт очень много времени. Но чтобы проверить работоспособность, программный продукт получает матрицу, размерность которой составляет 5x5. Для этого нужно будет ввести уже 25 значений. Если в данном случае наблюдается нормальная, безошибочная работа, то это значит, что всё в порядке. Хотя и здесь существуют подводные камни, которые заключаются в том, что при миниатюризации происходит ситуация, в результате которой изменения становятся неявными и временно исчезают. Также очень редко, но всё же случается и такое, что появляются новые ошибки.

Преследуемые цели

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

Проверка в различных условиях

Как правило, тестирование программ происходит в объемах, которые необходимы для минимальной проверки функциональности в ограниченных пределах. Деятельность ведётся с изменением параметров, а также условий их работы. Процесс тестирования можно поделить на три этапа:

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

Тестирование ПО: виды

Создавать программное обеспечение без ошибок весьма трудно. Это требует значительного количества времени. Чтобы получить хороший продукт часто применяются два вида тестирования: «Альфа» и «Бета». Что они собой представляют? Когда говорят об альфа-тестировании, то под ним подразумевают проверку, которую проводит сам штат разработчиков в «лабораторных» условиях. Это последний этап проверки перед тем, как программа будет передана конечным пользователям. Поэтому разработчики стараются развернуться по максимуму. Для легкости работы данные могут протоколироваться, чтобы создавать хронологию проблем и их устранения. Под бета-тестированием понимают поставку программного обеспечения ограниченному кругу пользователей, чтобы они смогли поэксплуатировать программу и выявить пропущенные ошибки. Особенностью в данном случае является то, что часто ПО используется не по своему целевому назначению. Благодаря этому неисправности будут выявляться там, где ранее ничего не было замечено. Это вполне нормально и переживать по этому поводу не нужно.

Завершение тестирования

Если предыдущие этапы были успешно завершены, то остаётся провести приемочный тест. Он в данном случае становиться простой формальностью. Во время данной проверки происходит подтверждение, что никаких дополнительных проблем не найдено и программное обеспечение можно выпускать на рынок. Чем большую важность будет иметь конечный результат, тем внимательней должна проводиться проверка. Необходимо следить за тем, чтобы все этапы были пройдены успешно. Вот так выглядит процесс тестирования в целом. А теперь давайте углубимся в технические детали и поговорим о таких полезных инструментах, как тестовые программы. Что они собой представляют и в каких случаях используются?

Ранее считалось, что динамический анализ разработанного ПО – это слишком тяжелый подход, который неэффективно использовать для обнаружения дефектов. Но из-за увеличения сложности и объема программ появился противоположный взгляд. Автоматическое тестирование применяется там, где самыми важными приоритетами является работоспособность и безопасность. И они должны быть при любых входных данных. В качестве примера программ, для которых целесообразным является такое тестирование, можно привести следующие: сетевые протоколы, веб-сервер, sandboxing. Мы далее рассмотрим несколько образцов, которые можно использовать для такой деятельности. Если интересуют бесплатные программы тестирования, то среди них качественные найти довольно сложно. Но существуют взломанные «пиратские» версии хорошо зарекомендовавших себя проектов, поэтому можно обратиться к их услугам.

Avalanche

Этот инструмент помогает обнаружить дефекты, проходя тестирование программ в режиме динамического анализа. Он собирает данные и анализирует трассу выполнения разработанного объекта. Тестеру же предоставляется набор входных данных, которые вызывают ошибку или обходят набор имеющихся ограничений. Благодаря наличию хорошего алгоритма проверки разрабатывается большое количество возможных ситуаций. Программа получает различные наборы входных данных, которые позволяют смоделировать значительное число ситуаций и создать такие условия, когда наиболее вероятным является возникновение сбоя. Важным преимуществом программы считается применение эвристической метрики. Если есть проблема, то ошибка приложения находится с высокой вероятностью. Но эта программа имеет ограничения вроде проверки только одного помеченного входного сокета или файла. При проведении такой операции, как тестирование программ, будет содержаться детальная информация о наличие проблем с нулевыми указателями, бесконечными циклами, некорректными адресами или неисправностями из-за использования библиотек. Конечно, это не полный список обнаруживаемых ошибок, а только их распространённые примеры. Исправлять недочеты, увы, придётся разработчикам – автоматические средства для этих целей не подходят.

KLEE

Это хорошая программа для тестирования памяти. Она может перехватывать примерно 50 системных вызовов и большое количество виртуальных процессов, таким образом, выполняется параллельно и отдельно. Но в целом программа не ищет отдельные подозрительные места, а обрабатывает максимально возможное количество кода и проводит анализ используемых путей передачи данных. Из-за этого время тестирования программы зависит от размера объекта. При проверке ставка сделана на символические процессы. Они являются одним из возможных путей выполнения задач в программе, которая проверяется. Благодаря параллельной работе можно анализировать большое количество вариантов работы исследуемого приложения. Для каждого пути после окончания его тестирования сохраняются наборы входных данных, с которых начиналась проверка. Следует отметить, что тестирование программ с помощью KLEE помогает выявлять большое количество отклонений, которых не должно быть. Она может найти проблемы даже в приложениях, которые разрабатываются десятилетиями.

Тестирование. Фундаментальная теория

Недавно был на собеседовании на Middle QA на проект, который явно превышает мои возможности. Уделил много времени тому, чего не знал вообще и мало времени повторению простой теории, а зря.

Ниже основы основ для повторения перед собеседованием для Trainee and Junior: определение тестирования, качество, верификация / валидация, цели, этапы, тест план, пункты тест плана, тест дизайн, техники тест дизайна, traceability matrix, test case, чек-лист, дефект, error/deffect/failure, баг репорт, severity vs priority, уровни тестирования, виды / типы, подходы к интеграционному тестированию, принципы тестирования, статическое и динамическое тестирование, исследовательское / ad-hoc тестирование, требования, жизненный цикл бага, стадии разработки ПО, decision table, qa/qc/test engineer, диаграмма связей.

Все замечания, корректировки и дополнения очень приветствуются.

Тестирование программного обеспечения — проверка соответствия между реальным и ожидаемым поведением программы, осуществляемая на конечном наборе тестов, выбранном определенным образом. В более широком смысле, тестирование — это одна из техник контроля качества, включающая в себя активности по планированию работ (Test Management), проектированию тестов (Test Design), выполнению тестирования (Test Execution) и анализу полученных результатов (Test Analysis).

Качество программного обеспечения (Software Quality) — это совокупность характеристик программного обеспечения, относящихся к его способности удовлетворять установленные и предполагаемые потребности. [Quality management and quality assurance]

Верификация (verification) — это процесс оценки системы или её компонентов с целью определения удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого этапа[IEEE]. Т.е. выполняются ли наши цели, сроки, задачи по разработке проекта, определенные в начале текущей фазы.

Валидация (validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе [BS7925-1]. Также можно встретить иную интерпритацию: Процесс оценки соответствия продукта явным требованиям (спецификациям) и есть верификация (verification), в то же время оценка соответствия продукта ожиданиям и требованиям пользователей — есть валидация (validation). Также часто можно встретить следующее определение этих понятий: Validation — ’is this the right specification?’. Verification — ’is the system correct to specification?’.

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

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

Этапы тестирования:

1. Анализ продукта 2. Работа с требованиями 3. Разработка стратегии тестирования и планирование процедур контроля качества 4. Создание тестовой документации 5. Тестирование прототипа 6. Основное тестирование 7. Стабилизация 8. Эксплуатация

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

Отвечает на вопросы: Что надо тестировать? Что будете тестировать? Как будете тестировать? Когда будете тестировать? Критерии начала тестирования. Критерии окончания тестирования.

Основные пункты тест плана

В стандарте IEEE 829 перечислены пункты, из которых должен (пусть — может) состоять тест-план: a) Test plan identifier; b) Introduction; c) Test items; d) Features to be tested; e) Features not to be tested; f) Approach; g) Item pass/fail criteria; h) Suspension criteria and resumption requirements; i) Test deliverables; j) Testing tasks; k) Environmental needs; l) Responsibilities; m) Staffing and training needs; n) Schedule; o) Risks and contingencies; p) Approvals.

Тест дизайн – это этап процесса тестирования ПО, на котором проектируются и создаются тестовые сценарии (тест кейсы), в соответствии с определёнными ранее критериями качества и целями тестирования.

Роли, ответственные за тест дизайн: • Тест аналитик — определяет «ЧТО тестировать?» • Тест дизайнер — определяет «КАК тестировать?»

Техники тест дизайна

• Эквивалентное Разделение (Equivalence Partitioning — EP). Как пример, у вас есть диапазон допустимых значений от 1 до 10, вы должны выбрать одно верное значение внутри интервала, скажем, 5, и одно неверное значение вне интервала — 0.

• Анализ Граничных Значений (Boundary Value Analysis — BVA). Если взять пример выше, в качестве значений для позитивного тестирования выберем минимальную и максимальную границы (1 и 10), и значения больше и меньше границ (0 и 11). Анализ Граничный значений может быть применен к полям, записям, файлам, или к любого рода сущностям имеющим ограничения.

• Причина / Следствие (Cause/Effect — CE). Это, как правило, ввод комбинаций условий (причин), для получения ответа от системы (Следствие). Например, вы проверяете возможность добавлять клиента, используя определенную экранную форму. Для этого вам необходимо будет ввести несколько полей, таких как «Имя», «Адрес», «Номер Телефона» а затем, нажать кнопку «Добавить» — это «Причина». После нажатия кнопки «Добавить», система добавляет клиента в базу данных и показывает его номер на экране — это «Следствие».

• Предугадывание ошибки (Error Guessing — EG). Это когда тестировщик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку. Например, спецификация говорит: «пользователь должен ввести код». Тестировщик будет думать: «Что, если я не введу код?», «Что, если я введу неправильный код? », и так далее. Это и есть предугадывание ошибки.

• Исчерпывающее тестирование (Exhaustive Testing — ET) — это крайний случай. В пределах этой техники вы должны проверить все возможные комбинации входных значений, и в принципе, это должно найти все проблемы. На практике применение этого метода не представляется возможным, из-за огромного количества входных значений.

• Попарное тестирование (Pairwise Testing) — это техника формирования наборов тестовых данных. Сформулировать суть можно, например, вот так: формирование таких наборов данных, в которых каждое тестируемое значение каждого из проверяемых параметров хотя бы единожды сочетается с каждым тестируемым значением всех остальных проверяемых параметров.

Допустим, какое-то значений (налог) для человека рассчитывается на основании его пола, возраста и наличия детей — получаем три входных параметра, для каждого из которых для тестов выбираем каким-то образом значения. Например: пол — мужской или женский; возраст — до 25, от 25 до 60, более 60; наличие детей — да или нет. Для проверки правильности расчётов можно, конечно, перебрать все комбинации значений всех параметров: № пол возраст дети
1 мужчина до 25 детей нет
2 женщина до 25 детей нет
3 мужчина 25-60 детей нет
4 женщина 25-60 детей нет
5 мужчина старше 60 детей нет
6 женщина старше 60 детей нет
7 мужчина до 25 дети есть
8 женщина до 25 дети есть
9 мужчина 25-60 дети есть
10 женщина 25-60 дети есть
11 мужчина старше 60 дети есть
12 женщина старше 60 дети есть
А можно решить, что нам не нужны сочетания значений всех параметров со всеми, а мы хотим только убедиться, что мы проверим все уникальные пары значений параметров. Т.е., например, с точки зрения параметров пола и возраста мы хотим убедиться, что мы точно проверим мужчину до 25, мужчину между 25 и 60, мужчину после 60, а также женщину до 25, женщину между 25 и 60, ну и женщину после 60. И точно так же для всех остальных пар параметров. И таким образом, мы можем получить гораздо меньше наборов значений (в них есть все пары значений, правда некоторые дважды): № пол возраст дети
1 мужчина до 25 детей нет
2 женщина до 25 дети есть
3 мужчина 25-60 дети есть
4 женщина 25-60 детей нет
5 мужчина старше 60 детей нет
6 женщина старше 60 дети есть
Такой подход примерно и составляет суть техники pairwise testing — мы не проверяем все сочетания всех значений, но проверяем все пары значений.

Traceability matrix — Матрица соответствия требований — это двумерная таблица, содержащая соответсвие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases). В заголовках колонок таблицы расположены требования, а в заголовках строк — тестовые сценарии. На пересечении — отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки.

Матрица соответсвия требований используется QA-инженерами для валидации покрытия продукта тестами. МСТ является неотъемлемой частью тест-плана.

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

Пример: Action Expected Result Test Result (passed/failed/blocked) Open page «login» Login page is opened Passed Каждый тест кейс должен иметь 3 части: PreConditions Список действий, которые приводят систему к состоянию пригодному для проведения основной проверки. Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния. Test Case Description Список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям PostConditions Список действий, переводящих систему в первоначальное состояние (состояние до проведения теста — initial state) Виды Тестовых Сценариев: Тест кейсы разделяются по ожидаемому результату на позитивные и негативные: • Позитивный тест кейс использует только корректные данные и проверяет, что приложение правильно выполнило вызываемую функцию. • Негативный тест кейс оперирует как корректными так и некорректными данными (минимум 1 некорректный параметр) и ставит целью проверку исключительных ситуаций (срабатывание валидаторов), а также проверяет, что вызываемая приложением функция не выполняется при срабатывании валидатора.

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

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

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

Error — ошибка пользователя, то есть он пытается использовать программу иным способом.

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

Bug (defect) — ошибка программиста (или дизайнера или ещё кого, кто принимает участие в разработке), то есть когда в программе, что-то идёт не так как планировалось и программа выходит из-под контроля. Например, когда никак не контроллируется ввод пользователя, в результате неверные данные вызывают краши или иные «радости» в работе программы. Либо внутри программа построена так, что изначально не соответствует тому, что от неё ожидается.

Failure — сбой (причём не обязательно аппаратный) в работе компонента, всей программы или системы. То есть, существуют такие дефекты, которые приводят к сбоям (A defect caused the failure) и существуют такие, которые не приводят. UI-дефекты например. Но аппаратный сбой, никак не связанный с software, тоже является failure.

Баг Репорт (Bug Report) — это документ, описывающий ситуацию или последовательность действий приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата.

Шапка Короткое описание (Summary) Короткое описание проблемы, явно указывающее на причину и тип ошибочной ситуации. Проект (Project) Название тестируемого проекта Компонент приложения (Component) Название части или функции тестируемого продукта Номер версии (Version) Версия на которой была найдена ошибка Серьезность (Severity) Наиболее распространена пятиуровневая система градации серьезности дефекта: • S1 Блокирующий (Blocker) • S2 Критический (Critical) • S3 Значительный (Major) • S4 Незначительный (Minor) • S5 Тривиальный (Trivial) Приоритет (Priority) Приоритет дефекта: • P1 Высокий (High) • P2 Средний (Medium) • P3 Низкий (Low) Статус (Status) Статус бага. Зависит от используемой процедуры и жизненного цикла бага (bug workflow and life cycle) Автор (Author) Создатель баг репорта Назначен на (Assigned To) Имя сотрудника, назначенного на решение проблемы Окружение ОС / Сервис Пак и т.д. / Браузера + версия /… Информация об окружении, на котором был найден баг: операционная система, сервис пак, для WEB тестирования — имя и версия браузера и т.д. … Описание Шаги воспроизведения (Steps to Reproduce) Шаги, по которым можно легко воспроизвести ситуацию, приведшую к ошибке. Фактический Результат (Result) Результат, полученный после прохождения шагов к воспроизведению Ожидаемый результат (Expected Result) Ожидаемый правильный результат Дополнения Прикрепленный файл (Attachment) Файл с логами, скриншот или любой другой документ, который может помочь прояснить причину ошибки или указать на способ решения проблемы

Severity vs Priority

Серьезность (Severity) — это атрибут, характеризующий влияние дефекта на работоспособность приложения. Приоритет (Priority) — это атрибут, указывающий на очередность выполнения задачи или устранения дефекта. Можно сказать, что это инструмент менеджера по планированию работ. Чем выше приоритет, тем быстрее нужно исправить дефект. Severity выставляется тестировщиком Priority – менеджером, тимлидом или заказчиком Градация Серьезности дефекта (Severity)

S1 Блокирующая (Blocker)

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

S2 Критическая (Critical)

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

S3 Значительная (Major)

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

S4 Незначительная (Minor)

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

S5 Тривиальная (Trivial)

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

P1 Высокий (High)

Ошибка должна быть исправлена как можно быстрее, т.к. ее наличие является критической для проекта.

P2 Средний (Medium)

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

P3 Низкий (Low)

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

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

1. Модульное тестирование (Unit Testing)

Компонентное (модульное) тестирование проверяет функциональность и ищет дефекты в частях приложения, которые доступны и могут быть протестированы по-отдельности (модули программ, объекты, классы, функции и т.д.).

2. Интеграционное тестирование (Integration Testing)

Проверяется взаимодействие между компонентами системы после проведения компонентного тестирования.

3. Системное тестирование (System Testing)

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

4. Операционное тестирование (Release Testing).

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

5. Приемочное тестирование (Acceptance Testing)

Формальный процесс тестирования, который проверяет соответствие системы требованиям и проводится с целью: • определения удовлетворяет ли система приемочным критериям; • вынесения решения заказчиком или другим уполномоченным лицом принимается приложение или нет.

Виды / типы тестирования

Функциональные виды тестирования
• Функциональное тестирование (Functional testing) • Тестирование пользовательского интерфейса (GUI Testing) • Тестирование безопасности (Security and Access Control Testing) • Тестирование взаимодействия (Interoperability Testing)
Нефункциональные виды тестирования
• Все виды тестирования производительности: o нагрузочное тестирование (Performance and Load Testing) o стрессовое тестирование (Stress Testing) o тестирование стабильности или надежности (Stability / Reliability Testing) o объемное тестирование (Volume Testing) • Тестирование установки (Installation testing) • Тестирование удобства пользования (Usability Testing) • Тестирование на отказ и восстановление (Failover and Recovery Testing) • Конфигурационное тестирование (Configuration Testing)
Связанные с изменениями виды тестирования
• Дымовое тестирование (Smoke Testing) • Регрессионное тестирование (Regression Testing) • Повторное тестирование (Re-testing) • Тестирование сборки (Build Verification Test) • Санитарное тестирование или проверка согласованности/исправности (Sanity Testing)

Функциональное тестирование рассматривает заранее указанное поведение и основывается на анализе спецификаций функциональности компонента или системы в целом.

Тестирование пользовательского интерфейса (GUI Testing) — функциональная проверка интерфейса на соответствие требованиям — размер, шрифт, цвет, consistent behavior.

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

Тестирование взаимодействия (Interoperability Testing) – это функциональное тестирование, проверяющее способность приложения взаимодействовать с одним и более компонентами или системами и включающее в себя тестирование совместимости (compatibility testing) и интеграционное тестирование

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

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

Объемное тестирование (Volume Testing). Задачей объемного тестирования является получение оценки производительности при увеличении объемов данных в базе данных приложения

Тестирование стабильности или надежности (Stability / Reliability Testing). Задачей тестирования стабильности (надежности) является проверка работоспособности приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки.

Тестирование установки направленно на проверку успешной инсталляции и настройки, а также обновления или удаления программного обеспечения.

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

User eXperience (UX) — ощущение, испытываемое пользователем во время использования цифрового продукта, в то время как User interface — это инструмент, позволяющий осуществлять интеракцию «пользователь — веб-ресурс».

Тестирование на отказ и восстановление (Failover and Recovery Testing) проверяет тестируемый продукт с точки зрения способности противостоять и успешно восстанавливаться после возможных сбоев, возникших в связи с ошибками программного обеспечения, отказами оборудования или проблемами связи (например, отказ сети). Целью данного вида тестирования является проверка систем восстановления (или дублирующих основной функционал систем), которые, в случае возникновения сбоев, обеспечат сохранность и целостность данных тестируемого продукта.

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

Дымовое (Smoke) тестирование рассматривается как короткий цикл тестов, выполняемый для подтверждения того, что после сборки кода (нового или исправленного) устанавливаемое приложение, стартует и выполняет основные функции.

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

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

В чем разница между regression testing и re-testing? Re-testing — проверяется исправление багов Regression testing — проверяется то, что исправление багов, а также любые изменения в коде приложения, не повлияли на другие модули ПО и не вызвало новых багов.

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

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

Подходы к интеграционному тестированию:

• Снизу вверх (Bottom Up Integration) Все низкоуровневые модули, процедуры или функции собираются воедино и затем тестируются. После чего собирается следующий уровень модулей для проведения интеграционного тестирования. Данный подход считается полезным, если все или практически все модули, разрабатываемого уровня, готовы. Также данный подход помогает определить по результатам тестирования уровень готовности приложения.

• Сверху вниз (Top Down Integration)

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

• Большой взрыв («Big Bang» Integration)

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

Принципы тестирования

Принцип 1 – Тестирование демонстрирует наличие дефектов (Testing shows presence of defects)

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

Принцип 2 – Исчерпывающее тестирование недостижимо (Exhaustive testing is impossible)

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

Принцип 3 – Раннее тестирование (Early testing)

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

Принцип 4 – Скопление дефектов (Defects clustering)

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

Принцип 5 – Парадокс пестицида (Pesticide paradox)

Если одни и те же тесты будут прогоняться много раз, в конечном счете этот набор тестовых сценариев больше не будет находить новых дефектов. Чтобы преодолеть этот “парадокс пестицида”, тестовые сценарии должны регулярно рецензироваться и корректироваться, новые тесты должны быть разносторонними, чтобы охватить все компоненты программного обеспечения, или системы, и найти как можно больше дефектов.

Принцип 6 – Тестирование зависит от контекста (Testing is concept depending)

Тестирование выполняется по-разному в зависимости от контекста. Например, программное обеспечение, в котором критически важна безопасность, тестируется иначе, чем сайт электронной коммерции.

Принцип 7 – Заблуждение об отсутствии ошибок (Absence-of-errors fallacy)

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

Cтатическое и динамическое тестирование

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

Исследовательское / ad-hoc тестирование

Простейшее определение исследовательского тестирования — это разработка и выполнения тестов в одно и то же время. Что является противоположностью сценарного подхода (с его предопределенными процедурами тестирования, неважно ручными или автоматизированными). Исследовательские тесты, в отличие от сценарных тестов, не определены заранее и не выполняются в точном соответствии с планом. Разница между ad hoc и exploratory testing в том, что теоретически, ad hoc может провести кто угодно, а для проведения exploratory необходимо мастерство и владение определенными техниками. Обратите внимание, что определенные техники это не только техники тестирования.

Требования – это спецификация (описание) того, что должно быть реализовано.

Требования описывают то, что необходимо реализовать, без детализации технической стороны решения. Что, а не как.

Требования к требованиям:

• Корректность • Недвусмысленность • Полнота набора требований • Непротиворечивость набора требований • Проверяемость (тестопригодность) • Трассируемость • Понимаемость

Жизненный цикл бага

Стадии разработки ПО — это этапы, которые проходят команды разработчиков ПО, прежде чем программа станет доступной для широко круга пользователей. Разработка ПО начинается с первоначального этапа разработки (стадия «пре-альфа») и продолжается стадиями, на которых продукт дорабатывается и модернизируется. Финальным этапом этого процесса становится выпуск на рынок окончательной версии программного обеспечения («общедоступного релиза»).

Программный продукт проходит следующие стадии: • анализ требований к проекту; • проектирование; • реализация; • тестирование продукта; • внедрение и поддержка. Каждой стадии разработки ПО присваивается определенный порядковый номер. Также каждый этап имеет свое собственное название, которое характеризует готовность продукта на этой стадии.

Жизненный цикл разработки ПО:

• Пре-альфа • Альфа • Бета • Релиз-кандидат • Релиз • Пост-релиз

Таблица принятия решений (decision table) – великолепный инструмент для упорядочения сложных бизнес требований, которые должны быть реализованы в продукте. В таблицах решений представлен набор условий, одновременное выполнение которых должно привести к определенному действию.

QA/QC/Test Engineer

Таким образом, мы можем построить модель иерархии процессов обеспечения качества: Тестирование – часть QC. QC – часть QA.

Диаграмма связей – это инструмент управления качеством, основанный на определении логических взаимосвязей между различными данными. Применяется этот инструмент для сопоставления причин и следствий по исследуемой проблеме.

Источники: www.protesting.ru, bugscatcher.net, qalight.com.ua, thinkingintests.wordpress.com, книга ISTQB, www.quizful.net, bugsclock.blogspot.com, www.zeelabs.com, devopswiki.net, hvorostovoz.blogspot.com.

Ресурсы рекомендованные в комментах Sofiya Novachenko: istqbexamcertification.com www.testingexcellence.com

Теги:

Тестирование программ

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

Статическое – анализ текста программы

Динамическое – анализ контролируемого выполнения

Методы тестирования – совокупность правил, регламентирующих последовательность шагов по тестированию

Критерии тестирования – оценки, позволяющие судить о достаточности выполненного тестирования

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

Тест – набор входных данных, набор ожидаемых результатов, набор условий, разработанных для проверки определенного пути выполнения программы.

Особенности

1) Частое отсутствие полностью определенного эталона, которому должны соответствовать результаты

2) Высокая сложность программ исключает исчерпывающее тестирование (проверка всех возможных маршрутов выполнения)

3) Невысокая формализация критериев завершения тестирования

Основные принципы тестирования

1) Нельзя планировать тестирование в предположении, что ошибки отсутствуют

2) Следует избегать тестирования программы ее автором

3) Описание предполагаемых значений результатов должно быть неотъемлемой частью теста

4) Тесты для неправильных входных данных следует разрабатывать также тщательно, как и для правильных

5) Следует понимать, сто вероятность наличия необнаруженных ошибок пропорциональна числу уже обнаруженных

6) Не следует выбрасывать тесты, даже если программа уже не используется

Объекты тестирования. Категории тестов

1) Спецификации программных модулей, групп программ и программных комплексов

- полнота и согласованность функций программных компонент

- согласованность интерфейсов программных компонент (для групп программ и комплексов)

2) Программные модули

- структура

- преобразование данных, выполняемое модулем

- полнота функций, выполняемых модулем

3) Группы программ, объединенные для решения законченной функциональной задачи

- то же, что и для модулей

- интерфейс между программами

- тестирование потребления ресурсов

4) Программный комплекс, используемый для решения нескольких функциональных задач

- полнота решения функциональных задач

- функционирование программ в критических ситуациях

- тестирование потребления ресурсов

- оценка надежности работы комплекса

- эффективность защиты от искажения общих данных

5) Программное средство, сдаваемое в опытную эксплуатацию

- то же, что и для 4)

- удобство инсталляции рабочей версии программы

- проверка работы при изменении конфигурации оборудования

- проверка наличия и корректности документации

- испытание на соответствие техническому заданию

6) Программное средство на стадии сопровождения

- удобство модификации, типа расширения функциональности и повышения эффективности

1 – Спецификации

2 – Модули

3 – Группы программ

4 – Программные комплексы на стадии отладки

5 – Программные комплексы как продукты

Виды и методы тестирования

Особенности нисходящего тестирования:

Достоинства:

- с самого начала выполняется проверка главных функций – концептуальная проверка

Недостатки:

- необходимость разработки заглушек, часто достаточно интеллектуальных

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

Особенности восходящего тестирования

Достоинства:

- для тестирования используются готовые модули нижних уровней

Недостатки:

- необходимость разработки тест-драйверов для управления работой нижних уровней с верхних

- отложенная проверка основной концепции функционирования комплекса

1) Модульное тестирование. Включает проверку:

- корректности структуры модуля

- корректности основных конструктивных компонент

- полноты и качества реализации функций обработки данных

Структурная корректность проверяется структурными методами по принципу «белого ящика»

2) Интеграционное тестирование. Проверка:

- корректности объединения модулей в группу или комплекс программ

Проводится на основе 2-х подходов:

- монолитное тестирование, при котором модули сразу объединяются в единый комплекс и после этого вместе тестируются

- инкрементальное (пошаговое), модули подключаются друг к другу последовательно (снизу вверх или сверху вниз)

Использует структурную проверку подключаемых модулей и функциональную проверку полноты и качества реализации функций. Функциональные проверки осуществляются по принципу «черного ящика»

3) Системное тестирование. Обеспечивает проверку соответствия программного средства специфицированным требованиям в заданной среде и режимах функционирования. Предусматривает следующие виды тестирования:

- тестирование функциональности

- стрессовое тестирование (тестирование на повышенных нагрузках по использованным ресурсам)

- тестирование безопасности (защита от несанкционированного доступа)

- тестирование восстановления при сбоях

В последнее время стало широко применяться альфа и бета тестирование – это виды тестирования, выполняемые с участием заказчика. Альфа тестирование выполняется на территории разработчика в условиях ограниченного времени (не более недели). Бета тестирование выполняется после введения программы в опытную эксплуатацию на территории заказчика, проводится достаточно долго (норма 1 год).

Статистика ошибок в программных продуктах по типам.

Ошибки спецификации

8.1

Структурные ошибки

25.2

Ошибки представления и обработки данных

22.4

Полнота и корректность функций

16.2

Кодирование

9.9

Интеграция

9.0

Системные

3.0

Прочие

остальные

Методы тестирования

Все методы делятся на две неравнозначных группы:

- статическое (ручное)

- динамическое (машинное)

Основные методы ручного:

- инспекция кода

- сквозной просмотр

Методы динамического:

- структурные

- функциональные

Методы статического тестирования

Общая черта – они используют визуальный контроль программы по ее тексту группой из 3-4 человек, один из которых автор программы. Целью проверки является обнаружение ошибок, но не их устранение. Основная концепция – наличие ошибок не есть вина автора программы, а несовершенство средств разработки программы и сложность программы как некоторой системы. При нормальном проведении статические методы тестирования позволяют обнаруживать 30-70% первоначальных ошибок в программе. Они, в отличие от машинных, позволяют обнаруживать типовые группы ошибок автора.

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

2 этапа:

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

2) программа анализируется по типовому списку часто встречающихся ошибок:

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

- ошибки описания данных, соответствие заданных типов и значений

- ошибки вычислений

- ошибки передач управления (зацикливание, корректность завершения программы)

- ошибки интерфейса (ошибки, связанные с взаимодействием частей друг с другом)

- ошибки ввода/вывода

Результат инспекции кода:

- обнаруженные ошибки

- обучение автора улучшенным методам кодирования программ

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

Динамическое тестирование

Структурное тестирование программных модулей

При структурном тестировании проверяется

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

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

Тестирование на основе потока управления

Вводят критерии отбора элементов для тестирования:

1) покрытие операторов (покрытие вершин УГП, покрытие строк кода). Необходимо проверить выполнение каждого оператора хотя бы один раз. Нужно реализовать путь a-c-e (например при тестовом наборе a=2, b=0, x=3, результат x=2.5). Не проверяется прохождение пути a-b-d. Не проверяются отдельные условия, например OR вместо &. Является самым слабым критерием и используется только при первоначальной проверке.

2) Покрытие ветвей (решений). Необходимо проверить каждую дугу выполнения программы. Этот критерий включает в себя предыдущий.

1) Покрытьдугиa-c-e, a-b-d

2) Покрытьдугиa-c-d, a-b-e. A=3, B=0, X=3иA=2, B=1, X=1

Не выполняет обнаружения всех ошибок, например, если вместо x>1 будет x1, B=0, A=2, x>1. Нужно реализовать проверки: A>1, A1, x1, B=0

(2) A>1, B!=0

(3) A

10 лучших бесплатных программ для тестирования компьютера

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

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

10 программ для тестирования и диагностики

3D Mark – проверка видеокарты

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

3D Mark предлагает различные тесты, в том числе, с поддержкой DirectX 12 и DirectX 11. В программе есть также стресс-тест. Бесплатна только версия Basic.

Ссылка на программу

Альтернативные программы: Catzilla, Unigine Superposition, Unigine Heaven, 3D Mark 11

PC Mark 10 – тест производительности компьютера

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

В последней версии отказались, однако, от теста носителей (SSD или HDD). Бесплатна только версия Basic.

Скачать программу

Альтернативные программы: PCMark 8, SysMark

VR MARK – производительность виртуальной реальности

Если вы хотите проверить, как ваш компьютер справляется с задачей виртуальной реальности и обслуживает игры, предназначенные для очков Oculus Rift или HTC Vive, Вам пригодится VR Mark. Как и в случае других программ компании Futuremark, бесплатной является только версия Basic.

Инструмент оснащен тремя тестами, из которых один базовый (Orange), для VR игр, использующих DirectX 12 (Cyan) и самых требовательных (Blue).

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

Скачать программу

Альтернативная программа: SteamVR Performance Test

CPU-Z – для идентификации оборудования

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

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

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

Скачать программу

Альтернативные программы: Crystal CPU ID, Speccy

GPU-Z – для оценки видеокарты

GPU-Z – это основная программа для определения видеокарт и их характеристик, в том числе их текущей частоты. В приложении доступен базовый тест, который позволяет «быстро» убедиться, что видеокарта работает правильно.

Стоит, однако, отметить, что тест в этой программе не даст уверенности в том, что, например, при разгоне видеокарта будет работать полностью стабильно. Для этого стоит использовать более продвинутые продукты, например, стресс-тест в программе 3D-Mark.

Скачать программу

Альтернативная программа: GPU Caps Viewer

Cinebench R15 – для проверки производительности процессора

Cinebench – это средство тестирования, основанное на движке Cinema 4D, и предназначенное для проверки производительности процессора. Он делает это путем создания 3D-сцены – тест можно проводить с использованием всех потоков центрального процессора или только одного потока. Это даёт хорошее представление о возможностях процессорах.

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

Скачать программу

Альтернативные программы: LuxMark (рендеринг 3D-графики с помощью CPU или GPU), CompuBench (рендеринг 3D-графикой при помощи GPU)

OCCT 4.5.1 – проверка стабильности и температур

Отличная программа для проверки стабильности и температур компьютера через максимальные нагрузки процессора или видеокарты. OCCT создаёт автоматические диаграммы записи температур, частоты, а также напряжения узлов во время теста.

Примечание – если блок питания или другой компонент в вашем компьютере неисправен, но всё ещё работает, то максимальная нагрузка через OCCT может привести к его повреждению, точнее, программа ускорит выход из строя (ибо компонент уже был неисправен)!

Скачать программу

Альтернативные программы: FurMark, Prime95 или для мониторинга температуры SpeedFan, RealTemp и CoreTemp.

MemTest86 – оценка памяти компьютера

MemTest86 – это отличная программа для проверки правильности работы оперативной памяти. Это один из тех компонентов, стабильная работа которого очень важна для производительности компьютера.

Программа запускается с загрузочной флешки (или CD/DVD если кто-то их ещё использует).

Скачать программу

Альтернативная программа: Prime95

Prime95 – тест стабильности или температур под нагрузкой

Ещё одна отличная программа для тестирования стабильности или температур компонентов компьютера под высокой нагрузкой. Мы можем выбирать между тестами, которые сильнее всего нагружают, например, оперативную память или процессор.

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

Скачать программу

Программы, альтернативные: OCCT, MemTest86

CrystalDiskMark – для проверки носителей данных

Трудно указать одну, лучшую программу для проверки производительности носителей данных (жесткие диски HDD и SSD), но если уже приходится делать, то фаворитом будет CrystalDiskMark. Он позволяет проверить производительность носителей, как в случае чтения/записи последовательных данных, так и для небольших файлов.

Он дает хорошее представление о реальных характеристиках тестируемого узла. Если Вас интересует не только производительность (а, например, также показания SMART, возможность загружать новые прошивки или выполнять операции Secure Erase), стоит поинтересоваться приложениями, прилагаемыми к дискам производителей. Например, в случае SanDisk доступна программа SanDisk SSD Dashboard, а Samsung – Samsung Magician.

Скачать программу

Альтернативные программы: AS, AS SSD, программы производителя в комплекте

Как правильно тестировать программы для бизнеса

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

Что имеет смысл делегировать ИТ-персоналу? Три вещи.

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

И наконец, о подведении итогов. Соберите всех, кто участвовал в тестировании, выслушайте каждого, но постарайтесь перевести разговор в русло обсуждения функционала программы. Она генерирует отчеты? Обсудите, хорошо ли она их генерирует, чего не хватает, есть ли это в программах конкурентов, если они тоже тестировались. И если внедрение программы генерации отчетов уже принято, жестко пресекайте отзывы с мест типа «жили без отчетов и дальше проживем», «да я вам эти отчеты за те же деньги руками сгенерирую», особенно если они идут от ИТ-отдела.

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

А вот дальше решение принимаете уже вы. Посмотрите на скорость окупаемости, на нематериальный эффект, на критичность для вашего бизнеса – и тянитесь за кошельком. Или не тянитесь. Но решать вам. И только вам.

Теги:
  • безопасность
  • программы для бизнеса
  • тестиро


Смотрите также