Методы тестирования программного обеспечения. Степанченко И.В. - 18 стр.

UptoLike

Составители: 

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

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

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

 Вероятность наличия необнаруженных ошибок в части програм-
 мы пропорциональна числу ошибок, уже обнаруженных в этой
 части.
     Этот принцип, не согласующийся с интуитивным представлением, ил-
люстрируется рис. 2. На первый взгляд он лишен смысла, но, тем не менее,
подтверждается многими программами. Например, допустим, что некото-
рая программа состоит из модулей или подпрограмм A и B. К определен-
ному сроку в модуле A обнаружено пять ошибок, а в модуле B – только
одна, причем модуль A не подвергался более тщательному тестированию.
     Тогда из рассматриваемого принципа следует, что вероятность не-
обнаруженных ошибок в модуле A больше, чем в модуле В. Справедли-

                                  20