Продолжим рассматривать примеры из книги Ли Копланда, начало в предыдущей статье. Общий обзор книги в этой статье. Автор иначе называет проектирование и тестирование на основе требований. Для него это "тестирование по контракту", когда заданы предусловия и постусловия работы модуля, модуль является отдельным элементом системы в понимании объектно-ориентированного подхода.
Сам автор указывает на несовременность такого видения, т.к. модулем теперь считается не отдельный метод, а определенный функционал, который разрабатывается одновременно и может содержать несколько взаимосвязанных методов. Это связано с тем, что раньше программы разрабатывались как единое целое, а теперь распространен микросервисный подход, объединяющий ряд методов для решения одной задачи.
Автор предлагает на основе постусловий конструировать предусловия. Например, если модуль должен открывать файл, то предусловиями будут: наличие файла, имя и путь к файлу, файл не должен быть открыт в другом процессе, иначе мы не сможем с ним работать, и должны быть права доступа к файлу. Как мы видим, для выполнения простого действия может быть много предусловий.
Далее создаются только тест-кейсы, соответствующие предусловиям. Если какое-то действие не предусмотрено требованиями, то оно и не проверяется. Например, если не существует требование работоспособности модуля при отсутствии файла, то этот модуль не проверяется.
Это может казаться нелогичным для тестировщиков, отказ от проверки модуля. С другой стороны, для разрабатываемой системы необходимо предусмотреть и такие случаи, когда отсутствуют отдельные элементы, файл, чтобы не возникало ситуаций, когда система не может продолжить свою работу, т.к. не знает, что делать. В таком случае нужно дополнять требования к системе, предусматривать, какое поведение должно быть у системы при возникновении таких ситуаций, какие сообщения об ошибке должны выводиться и в какой режим должна возвращаться система после неудачной попытки выполнить неработающий функционал.
Ли Копланд предлагает не проверять тесты с не валидными значениями, не числовыми, отрицательными и т.д., если мы применяем подход тестирование на основе требований, но на практике такие тесты все равно проводятся и выделены в отдельный класс, негативные тесты. А в тестировании классов эквивалентности все по задумке автора, применяются только тестовые значения, соответствующие классам, т.е. при которых поведение системы одинаковое.
Автор также предлагает методику для тестирования классов эквивалентности:
- определить классы;
- создать тестовый сценарий для каждого класса.
Как правило, для каждого класса создается один тестовый сценарий, т.к. дополнительные сценарии не выявляют ошибок.
Если система должна обрабатывать все возможные входные данные, при использовании подхода, который Ли Копланд назвал "оборонительным проектированием и тестированием", то входные данные являются являются источником большого количества ошибок. Для чего же тогда применяют этот метод? Ведь можно выполнять действия, предусмотренные требованиями, когда данные корректны, и не выполнять ничего, когда данные некорректны?
При проектировании и тестировании на основе требований такой подход используется, но если в поле введена SQL-инъекция, то при попытке ее обработки выполнится какое-то вредоносное действие, так что обрабатывать некорректные данные все равно придется, чтобы не заразить систему вирусом.
Классы эквивалентности могут быть дискретными, т.е. числа с заданной точностью, например, целые числа. Тогда не валидными данными будут числа с большей точностью, т.е. дробные. На практике, такие числа можно округлять до заданной точности и обрабатывать любые значения заданного диапазона, т.е. класса эквивалентности. Числа не входящие в данный диапазон, обрабатываться не будут.
Если список дискретных значений мал, то можно создать тест для каждого значения. Если список значений большой, например, все регионы РФ или все страны мира, то мы ведь не будем проводить тест для каждого значения? В этом случае делается выборочная проверка, в зависимости от времени, которое можно потратить на тестирование, и рисков, связанных с пропуском ошибки. В зависимости от этих условий и принимается решение о том, сколько тестов нужно провести на заданном диапазоне класса эквивалентности.
Таким образом, мы рассмотрели конкретные вопросы, которые возникают у тестировщиков при использовании техники классы эквивалентности. На практике, вопросов возникает значительно больше. Могут применяться последовательно различные техники, ведь главным критерием тестирования является качество программного продукта, наличие в нем как можно меньшего количества ошибок.
Подписывайтесь, чтобы изучить техники тестирования на практических примерах и для лучшего усвоения вопросов теории.