Save as...功能的测试用例

ioridy

RT，一个格式转换软件的save as功能，就是支持20种格式的文件，save as功能支持这20种文件另存为15种格式。。。
现在要设置具体的测试用例来测试这个功能，问题就在格式这里，理论上肯定是完全遍历，即20*15条测试用例，但实际情况出发这些用例太多了，没有时间来执行完，所以想采用中方法来减少case，并尽量保证覆盖度····


一个出发点就是支持的20中格式里面分picture和document，在picture中按照颜色分类，黑白，灰色和彩色然后把所有的图片格式分配进去，交叉把支持另存为的15种格式遍历到，document中也一样，根据格式交叉分配，最后把另存为的15种格式遍历到。。。。

这是我个人的看法，不知道咋样，还有没有跟好的办法呢····

Jackc

你的出发点是对的，大致为：分类测试元素——正交（判定遍历）生成基本用例——补充特殊

在分类问题上，因为你没有明确说明测试工具的支持的文件类型，所以不大能帮上你。

不过从你的描述看，至少支持图片和文档
首先，图片的细分不能按照“颜色”来区别，某一类型的图片是否能被测试目标成功解析，并不会在意它是“黑白”还是“彩色”。有时因为像素问题无法解析的图片，只是因为它的算法版本不同而已，如:GIF 87a和GIF 89a。
所以，图片分类还是需要按照的设计算法来分，如：JPG、GIF、BMP、TIF、TGA、PSD、AI、CR等
——————————————
也许你会觉得这样分类的测试单元过多，那么也可以再根据用户使用需求再次分类。
比如用户使用的最多是JPG和GIF，其次是BMP和TIF，再次是TGA、PSD等。
根据用户使用需求，再分为3类：
A：JPG、GIF
B：BMP、TIF
C：TGA、PSD

当与其他测试单元组合时，
A类测试单元必须遍历；
B类测试单元必须于其他测试单元的必要测试单元遍历；
C类测试单元至少每个单元使用一次。

如，另一组测试单元也分为3类：
A1
B1
C1
那么A必须与A1、B1、C1遍历；B必须与A1,B1遍历；C则只需在整个测试中保证所有单元至少出现一次即可。

PS：如果最后的数据仍然偏多，则可按照这个思路继续分类。

——————————————————————————————————

简单来说，一句话：先按文件类型分类，再按用户需求分类。

Jackc

另外，需要注意“补充特殊”。
当分类生成用例结束后，必须要补充特殊用例，如最大转换文件大小、破损文件转换等等。