test granularity - best practice

[mrbean]

We're struggling with a couple issues.  We want to write our LabVIEW in a generic fashion such that they simply perform a task, and unless it's a very simple task, they don't make the determination of pass/fail - we want to leave that upto TestStand.  We don't want any of our LabVIEW tests to have hard-coded ranges in them.  This brings up a number of questions.  Since we (mostly) want TestStand to ochestrate the parameter ranges, test sequence, pass/fail, etc.- Is there a best/suggested method of capturing test scenarios.  Obviously, at some point, you have to identify the parameters/ranges for the various tests.  Is it best to hard-code them into the TestStand sequence file associated with a particular LRU - OR - Is there a nice XML, .ini, .txt format that TestStand can read to populate a series of local variables.  Hopefully someone understands my babble and can provide a starting point.

[Dennis_Knutson]

TestStand provides the property loader step type that you can use to modify limits for a particular board type. Whether you use that or hard code limits into a test sequence is really application specific. If you have an LRU (or what I would call a UUT or Unit Under Test) that has a large number of different varieties, it would often be simpler to use the property loader. Doing this, you would only have to write a single sequence file. For a new board, you would then just create a new .txt, .xls, etc. and distribute that. I don't happen to be in that sort of situation. The vast majority of boards that I have to test are unique and the limits are fixed in the sequence file. I do have several board types where stuffing options make certain whole tests optional and I find it more convenient to use pre-conditions in the sequence file for that situation. For example, perform this step if serial number prefix = 'abc'.

You are correct in removing any pass/fail criteria from the LabVIEW code and letting TestStand do that work but the actual mechanics of how TestStand does it should be approached on a case-by-case basis. It helps to be in touch with the product development teams to see what other flavors of a particular product are planned. The extra overhead of loading limits from an external file would not be justified for something that is a one-off and you are trying to optimize the test time.