2016-09-27 3 views
-1

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

Пожалуйста, помогите! Благодарю.

+1

Хм ... А? Я не знаю, что вы просите, и я уверен, что другие люди могут иметь такую ​​же проблему. Как вы думаете, вы могли бы прояснить немного? :) –

+0

Я считаю, что это классический «как я могу узнать, является ли мое программное обеспечение без ошибок». – Schwern

ответ

1

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

Прежде всего, это просто не проверка кода. Это можно проверить, проверив тест coverage. Даже если вы достигаете покрытия на 100%, все еще могут быть недостатки.

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

  • Слово в начале строки.
  • Слово в конце строки.
  • Слово в середине строки.
  • Строка без слова.
  • Пустая строка.

Они известны как boundary conditions и включают в себя такие вещи, как:

  • Отрицательные числа
  • Пустые строки
  • Null
  • Очень большие значения
  • Decimals
  • Unicode
  • Пустые файлы
  • Очень большие файлы

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

Если вы выполняете параллельную обработку, вы должны проверить любое количество возможностей для взаимоблокировок или коррупции, возникающих в результате попытки сделать то же самое в одно и то же время. Например, два процесса, пытающихся записать в один и тот же файл. Или два процесса, ожидающих блокировки на одном ресурсе. Блокируют ли они только то, что им нужно? Они бросают свои замки как можно скорее?

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

Например, если вы переводите деньги с одного счета на другой, вы могли бы написать:

my $from_balance = get_balance($from); 
my $to_balance = get_balance($to); 

set_balance($from, $from_balance - $amount); 
set_balance($to, $to_balance + $amount); 

Что произойдет, если программа падает после первого set_balance? Что произойдет, если другой процесс изменит либо баланс между get_balance и set_balance? Такие проблемы параллелизма должны быть рассмотрены и протестированы.

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

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

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

Если ваше тестирование использует много насмешек, ваши издевательства могут не отражать то, как на самом деле что-то издевается.

И так далее.

Для всех этих недостатков динамическое тестирование остается лучшим для тестирования более чем нескольких десятков строк кода.