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

UptoLike

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

73
тально понять работу алгоритма. Бывают случаи, когда при ручном про-
счете предполагаемых выходных значений находят ошибки в логике ра-
боты программы.
Четвертый этап является практически механическим. На этом этапе
не нужно думать, а только строго следовать предписанию и аккуратно
фиксировать полученные значения.
Если исполнение теста приносит результаты, не соответствующие
предполагаемым
, то это означает, что либо имеется ошибка, либо невер-
ны предполагаемые результаты (ошибка в тесте). Для устранения такого
рода недоразумений нужно тщательно проверять набор тестовтестиро-
вать» тесты).
Применение автоматизированных средств позволяет снизить трудо-
емкость процесса тестирования. Например, существуют средства, кото-
рые позволяют избавиться от потребности в драйверах. Средства анализа
потоков дают возможность пронумеровать маршруты в программе, опре-
делить неисполняемые операторы, обнаружить места, где переменные
используются до присвоения им значения. Также существуют программы
позволяющие выполнять функции с набором параметров, которые варьи-
руются в заданных пределах, что в общем случае, позволяет методом пе-
ребора проверить работу функции или метода.
При подготовке к
тестированию модулей целесообразно еще раз пере-
смотреть психологические и экономические принципы, обсуждавшиеся в
гл. 1. При исполнении теста следует обращать внимание на побочные эф-
фекты, например, если метод делает то, чего он делать не должен. В общем
случае такую ситуацию обнаружить трудно, но иногда побочные эффекты
можно выявить, если проверить не
только предполагаемые выходные пе-
ременные, но и другие, состояние которых в процессе тестирования изме-
ниться не должно. Поэтому при его исполнении наряду с предполагаемы-
ми результатами необходимо проверить и эти переменные.
Во время тестирования возникают и психологические проблемы,
связанные с личностью тестирующего. Программистам полезно поме-
няться кодом, чтобы не тестировать свой
собственный. Так, программист,
сделавший функцию вызова метода, является хорошим кандидатом для
тестирования вызываемого метода. Заметим, что это относится только к
тестированию, а не к отладке, которую всегда должен выполнять автор
класса или модуля.
Не следует выбрасывать результаты тестов; представляйте их в такой
форме, чтобы можно было повторно воспользоваться ими в
будущем. Если
в некотором подмножестве классов обнаружено большое число ошибок, то
эти классы, по-видимому, содержат еще большее число необнаруженных
ошибок. Такие классы должны стать объектом дальнейшего тестирования;
желательно даже дополнительно произвести контроль или просмотр их
тально понять работу алгоритма. Бывают случаи, когда при ручном про-
счете предполагаемых выходных значений находят ошибки в логике ра-
боты программы.
     Четвертый этап является практически механическим. На этом этапе
не нужно думать, а только строго следовать предписанию и аккуратно
фиксировать полученные значения.
     Если исполнение теста приносит результаты, не соответствующие
предполагаемым, то это означает, что либо имеется ошибка, либо невер-
ны предполагаемые результаты (ошибка в тесте). Для устранения такого
рода недоразумений нужно тщательно проверять набор тестов («тестиро-
вать» тесты).
     Применение автоматизированных средств позволяет снизить трудо-
емкость процесса тестирования. Например, существуют средства, кото-
рые позволяют избавиться от потребности в драйверах. Средства анализа
потоков дают возможность пронумеровать маршруты в программе, опре-
делить неисполняемые операторы, обнаружить места, где переменные
используются до присвоения им значения. Также существуют программы
позволяющие выполнять функции с набором параметров, которые варьи-
руются в заданных пределах, что в общем случае, позволяет методом пе-
ребора проверить работу функции или метода.
     При подготовке к тестированию модулей целесообразно еще раз пере-
смотреть психологические и экономические принципы, обсуждавшиеся в
гл. 1. При исполнении теста следует обращать внимание на побочные эф-
фекты, например, если метод делает то, чего он делать не должен. В общем
случае такую ситуацию обнаружить трудно, но иногда побочные эффекты
можно выявить, если проверить не только предполагаемые выходные пе-
ременные, но и другие, состояние которых в процессе тестирования изме-
ниться не должно. Поэтому при его исполнении наряду с предполагаемы-
ми результатами необходимо проверить и эти переменные.
     Во время тестирования возникают и психологические проблемы,
связанные с личностью тестирующего. Программистам полезно поме-
няться кодом, чтобы не тестировать свой собственный. Так, программист,
сделавший функцию вызова метода, является хорошим кандидатом для
тестирования вызываемого метода. Заметим, что это относится только к
тестированию, а не к отладке, которую всегда должен выполнять автор
класса или модуля.
     Не следует выбрасывать результаты тестов; представляйте их в такой
форме, чтобы можно было повторно воспользоваться ими в будущем. Если
в некотором подмножестве классов обнаружено большое число ошибок, то
эти классы, по-видимому, содержат еще большее число необнаруженных
ошибок. Такие классы должны стать объектом дальнейшего тестирования;
желательно даже дополнительно произвести контроль или просмотр их
                                  73