Writing the parser is easier in the long run, because it allows the testers to define their own "functions"

Could you clarify what you mean by this? The only meaning I can make out for it requires them to learn Perl. I assume that's not what you meant, since it was expressly stated they don't want to do that, and also because your use of quotation marks around "functions" seems to indicate a different a different meaning, but I'm not sure what. How could non-programmers define their own "functions"?

$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,".rekcah lreP rehtona tsuJ";$\=$ ;->();print$/
[download]

Essentially, you'd create your own macro language. Something along the lines of:

SUB my_func
    COMMAND1
    COMMAND2
ENDSUB

... Elsewhere ...

CALL my_func
[download]

Using JZ and JNZ (and a simple stack), it is very simple to implement this, but allows for your users to rapidly improve their testing scripts, especially when combined with a LoadCommands or #include or whatever.

------
We are the carpenters and bricklayers of the Information Age.

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

SUB my_func
    COMMAND1
    COMMAND2
ENDSUB
CALL my_func
[download]

Oh, macros. How, exactly, is this easier for them to learn to do than the following:

sub my_func {
   command1;
   command2;
}
my_func;
[download]

In your case, they're learning a very simple language; in my case they're learning a very simple language that just happens to be an extremely limited subset of Perl but is not fundamentally more complicated than the language you want to teach them. (The syntax is very marginally more involved (mainly, the need for semicolons between commands), but there are no extra concepts at all.)

They only have to learn the bare minimum they want to use. If they don't want to call macros with arguments, then they don't need to be able to write macros that take arguments, then they don't have to know about @_. If they don't need to maintain state either (apart from state your procedures maintain automagically, like the current web page or whatever), then they don't have to know about variables either (much less hashes, references, and so on). They don't need to learn about control flow unless they start asking things like, "How can I make this happen twenty times in a row, without just copy and pasting it twenty times?" or "How can I make something only happen under certain circumstances". As long as they're content to stick to a strictly procedural paradigm, they don't need to know about return values, context, list transformations, or a a whole mess of other things that an actual Perl programmer would need to know.

So far, I've only introduced them to two Perl builtins (include and sub), and one of those only because they (err, you) asked for the ability to write macros. They don't need to know ANY other Perl keywords, unless they start asking things like, "How can I output a message to the person running the test script, to tell them what it's about to test?". If they did that, I'd teach them to write print "Message Text Here";, but they wouldn't need to know anything else about the print operator (for example, that it's an operator, or that it operates on a list, or that it flattens the list and evaluates the arguments in string context, or that it can optionally take a filehandle, or what it returns, or any of the other stuff you'd learn about print if you were actually learning Perl, which they're not).

An advantage of my approach is that if they do ask for certain more advanced capabilities, you don't have to extend your language; all you have to do is show them the feature they're asking for. Plus, it saves you from needing to write a parser. I don't think it's worth inventing a language and writing a parser just to avoid the need for semicolons between commands.

If they want to learn to write functions (i.e., subroutines that return meaningful values, as opposed to procedures or macros, which are executed only for their side-effects), there are, irrespective of what language and syntax you teach them, some extra concepts that they would have to learn. Even macros are a concept, but not so advanced a concept as functions. (Though, when you start wanting to pass arguments to your macros, you probably need variables, which puts you almost halfway to what you need for functions. But these QA people don't want to learn Perl, so they are probably not going to be wanting to write macros that take args in the immediate future, much less functions that return values. That smacks almost of being borderline on real programming. Throw in conditionals and it might even be Turing-complete.)

---

$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,".rekcah lreP rehtona tsuJ";$\=$ ;->();print$/
[download]