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

UptoLike

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

69
редать методу класса такой текст, который бы соответствовал каждой
предварительно описанной ситуации на входе класса Н. Во-вторых, даже
если есть возможность передать все тесты, то из-за «дистанции» между
классом Н и точкой ввода в программу возникает довольно трудная ин-
теллектуальная задачаоценить, какими должны быть данные на входе
метода класса J, чтобы они соответствовали требуемым тестам класса Н.
Третья проблема состоит в том, что результаты выполнения теста
демонстрируются классом, расположенным довольно далеко от класса,
тестируемого в данный момент. Следовательно, установление соответст-
вия между тем, что демонстрируется, и тем, что происходит в классе на
самом деле, достаточно сложно, а иногда
просто невозможно. Допустим,
мы добавляем к схеме рис. 14 класс Е. Результаты каждого теста опреде-
ляются путем анализа выходных результатов методов класса I, но из-за
стоящих между классами Е и I промежуточных классов трудно восстано-
вить действительные выходные результаты методов класса Е (т. е. те ре-
зультаты, которые он передает в методы класса
В).
В нисходящем тестировании в связи с организацией его проведения
могут возникнуть еще две проблемы. Некоторые программисты считают,
что тестирование может быть совмещено с проектированием программ.
Например, если проектируется программа, изображенная на рис. 12, то
может сложиться впечатление, что после проектирования двух верхних
уровней следует перейти к кодированию и тестированию классов
А и В, С
и D и к разработке классов нижнего уровня. Как отмечается в работе [1],
такое решение не является разумным. Проектирование программпро-
цесс итеративный, т. е. при создании классов, занимающих нижний уро-
вень в архитектуре программы, может оказаться необходимым произвести
изменения в классах верхнего уровня. Если же классы верхнего уровня
уже
закодированы и оттестированы, то скорее всего эти изменения внесены не
будут, и принятое раньше не лучшее решение получит долгую жизнь.
Последняя проблема заключается в том, что на практике часто пере-
ходят к тестированию следующего класса до завершения тестирования
предыдущего. Это объясняется двумя причинами: во-первых, трудно
вставлять тестовые данные
в заглушки и, во-вторых, классы верхнего
уровня используют ресурсы классов нижнего уровня. Из рис. 12 видно,
что тестирование класса А может потребовать несколько версий заглуш-
ки класса В. Программист, тестирующий программу, как правило, решает
так: «Я сразу не буду полностью тестировать Асейчас это трудная за-
дача. Когда подключу класс J, станет
легче представлять тесты, и уж то-
гда я вернусь к тестированию класса А». Конечно, здесь важно только не
забыть проверить оставшуюся часть класса тогда, когда это предполага-
лось сделать. Аналогичная проблема возникает в связи с тем, что классы
верхнего уровня также запрашивают ресурсы для использования их клас-
сами нижнего уровня (
например, открывают файлы). Иногда трудно оп-
редать методу класса такой текст, который бы соответствовал каждой
предварительно описанной ситуации на входе класса Н. Во-вторых, даже
если есть возможность передать все тесты, то из-за «дистанции» между
классом Н и точкой ввода в программу возникает довольно трудная ин-
теллектуальная задача – оценить, какими должны быть данные на входе
метода класса J, чтобы они соответствовали требуемым тестам класса Н.
     Третья проблема состоит в том, что результаты выполнения теста
демонстрируются классом, расположенным довольно далеко от класса,
тестируемого в данный момент. Следовательно, установление соответст-
вия между тем, что демонстрируется, и тем, что происходит в классе на
самом деле, достаточно сложно, а иногда просто невозможно. Допустим,
мы добавляем к схеме рис. 14 класс Е. Результаты каждого теста опреде-
ляются путем анализа выходных результатов методов класса I, но из-за
стоящих между классами Е и I промежуточных классов трудно восстано-
вить действительные выходные результаты методов класса Е (т. е. те ре-
зультаты, которые он передает в методы класса В).
     В нисходящем тестировании в связи с организацией его проведения
могут возникнуть еще две проблемы. Некоторые программисты считают,
что тестирование может быть совмещено с проектированием программ.
Например, если проектируется программа, изображенная на рис. 12, то
может сложиться впечатление, что после проектирования двух верхних
уровней следует перейти к кодированию и тестированию классов А и В, С
и D и к разработке классов нижнего уровня. Как отмечается в работе [1],
такое решение не является разумным. Проектирование программ — про-
цесс итеративный, т. е. при создании классов, занимающих нижний уро-
вень в архитектуре программы, может оказаться необходимым произвести
изменения в классах верхнего уровня. Если же классы верхнего уровня уже
закодированы и оттестированы, то скорее всего эти изменения внесены не
будут, и принятое раньше не лучшее решение получит долгую жизнь.
     Последняя проблема заключается в том, что на практике часто пере-
ходят к тестированию следующего класса до завершения тестирования
предыдущего. Это объясняется двумя причинами: во-первых, трудно
вставлять тестовые данные в заглушки и, во-вторых, классы верхнего
уровня используют ресурсы классов нижнего уровня. Из рис. 12 видно,
что тестирование класса А может потребовать несколько версий заглуш-
ки класса В. Программист, тестирующий программу, как правило, решает
так: «Я сразу не буду полностью тестировать А – сейчас это трудная за-
дача. Когда подключу класс J, станет легче представлять тесты, и уж то-
гда я вернусь к тестированию класса А». Конечно, здесь важно только не
забыть проверить оставшуюся часть класса тогда, когда это предполага-
лось сделать. Аналогичная проблема возникает в связи с тем, что классы
верхнего уровня также запрашивают ресурсы для использования их клас-
сами нижнего уровня (например, открывают файлы). Иногда трудно оп-
                                  69