Design pattern for handling frequent logic changes in extending classes

I have a processor class - AbstractProcessor and multiple concrete classes (that extend this base class) which get called in order of the business logic.

public Abstract class AbstractProcessor {
   public void doProcess(){}
}

The logic in my concrete classes keeps on changing depending on the business requirements. This leads to a change in the corresponding test classes and seems to be a tightly coupled approach.

Is there a better way to design such classes.