如何有效地测试具有许多开关和参数的命令行软件
命令行实用程序/软件可能包含许多不同的开关和参数。
假设您的软件名为 CLI,并且 CLI 具有以下功能:
- CLI 的一般语法是:
CLI <数据结构> <操作> <必需的参数> [可选参数]
<数据结构>
可以是'矩阵'、'复数'、'int'、'浮点'、'log'
可能是'add', 'subtract', 'multiply', 'divide'
- 我想不出任何必需和可选的参数,但可以说你的软件确实支持它
现在您想测试这个软件。并且您希望测试界面本身,而不是逻辑。本质上,该接口必须返回正确的成功代码和错误代码。
本质上,许多真实的软件仍然提供带有多个选项的命令行界面。我很好奇是否有为此建立任何正式的测试方法。我的一个想法是构建一种语法(如 EBNF)并描述界面的“语言”。但我没能推动这个想法。在这种情况下,语法有什么用呢?它如何能够生成许多组合。
我很想了解更多有关可应用于此类问题的理论模型的信息,或者这里是否有人实际上已经完成了此类测试且覆盖范围令人满意
A command line utility/software could potentially consist of many different switches and arguments.
Lets say your software is called CLI and lets say CLI has the following features:
- The general syntax of CLI is:
CLI <data structures> <operation> <required arguments> [optional arguments]
<data structures>
could be'matrix', 'complex numbers', 'int', 'floating point', 'log'
<operation>
could be'add', 'subtract', 'multiply', 'divide'
- I cant think of any required and optional arguments, but lets say your software does support it
Now you want to test this software. And you wish to test interface itself, not the logic. Essentially the interface must return the correct success codes and error codes.
Essentially a lot of real word software still present a Command Line interface with several options. I am curious if there is any formal testing methodology established for this. One idea i had was to construct a grammar (like EBNF) and describing the 'language' of the interface. But I fail to push this idea ahead. What good is a grammar for in this case? How does it enable the generation of many many combinations .
I am curious to learn more about any theoretical models which could be applied to such a problem or if anyone in here has actually done such testing with satisfying coverage
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
我维护的产品中有一个命令行工具,我遇到的情况与您所描述的非常相似。我所做的是采用单元测试框架,并将每个参数组合编码为测试方法。
该程序是在 c#/.NET 中实现的,因此我使用 Visual Studio 内置的微软测试框架,但该方法适用于任何单元测试框架。
每个测试都会调用一个实用程序函数,该函数启动进程并发送输入并收集输出。然后,每个测试负责验证 CLI 的输出是否与预期相符。在某些情况下,有一系列测试用例可以通过单个测试方法执行,其中包含 for 循环。该逻辑需要运行 CLI 并检查每次迭代的输出。
我的测试集并没有涵盖参数的所有排列,但它涵盖了 80% 的情况,如果有任何缺陷,我可以添加新的测试。
There is a command-line tool as part of a product i maintain, and i have a situation thats very similar to what you describe. What i did was employ a unit testing framework, and encode each combination of arguments as a test method.
The program is implemented in c#/.NET, so i use microsoft's testing framework that's builtin to Visual Studio, but the approach would work with any unit testing framework.
Each test invokes a utility function that starts the process and sends in the input and cole ts the output. Then, each test is responsible for verifying that the output from the CLI matches what was expected. In some cases, there's a family of test cases that can be performed by a single test method, wih a for loop in it. The logic needs to run the CLI and check the output for each iteration.
The set of tests i have does not cover every permutation of arguments, but it covers the 80% cases and i can add new tests if there are ever any defects.
使用递归语法来生成开关是一个有趣的想法。如果您要尝试此操作,那么您需要首先以可以使用所有开关的方式编写语法,然后对语法进行随机游走。
这提供一种随机遍历语法并输出结果的简单方法。
Using a recursive grammar to generate switches is an interesting idea. If you where to try this then you would need to first write the grammar in such a way that all switches could be used, and then do a random walk of the grammar.
This provides an easy method of randomly walking a grammar and outputting the result.