怎么设计音频播放器的测试用例，如mp3？

chrisyang2008

怎么设计音频播放器的测试用例，请各位大侠指教一下，比如mp3播放器。音乐模块怎么来设计测试用例才可以把功能点覆盖呢？

jackie_li

我也想知道

Jackc

建议使用用例设计之“狗皮膏药”：我分我分，再分类
（玩笑而已，切入正题）
——————————————

1.先构建测试类型：
   功能：基础功能（播放器主界面）、辅助功能（其他界面，如播放列表界面）
   非功能：交互、性能（多次，长时，响应）、兼容功能（应用平台，“注意，因产品指定编码格式为MP3，故无需其他编码格式的兼容测试”）、容错功能（非法字符、存储空间、有损音频、非法音频编码、中断恢复。。。）
————————————————————————
2.逐个逐层针对各个测试类型中的测试元素分为，搭建各自的用例设计用例框架，如下图“音乐随声听”

2.1基础功能

    F_1. 常识用例
           做为一个标准应用程序，自然包括 启动/关闭 两个基础用例

    F_2.  UI布局
            如播放器log，整体外观风格，按钮分布位置。这些用例的预期输出最好能使用效果图片代替。若无图片，那只能。。只能文字了。如：换台按钮突出显示在播放器右上角，按钮名为加粗宋体“换台”中文字符。
PS：有一些同学喜欢将UI用例放在功能操作用例中，这样也不是不行，只要保证覆盖就行。如上图中的播放器log没有挂载任何功能，则可以把它放到“播放器启动”用例的预期输出中。

     F_3.功能用例
           继续分类，可操作/非操作
           如上图红色圈出的部分，都属于此播放器基础功能。其中，歌曲名/进度条 属于非操作类，也就是说，它在其涉及的用例中，只能做为“预期输出”出现，而非“输入步骤”。所以，设计用例时，可将非操作类功能筛选出来，做为“补充用例”的因素。
            接下来，则只关注于“可操作部分”:播放、暂停、停止、音量、切歌、链接.........
            再根据各个因素间的逻辑关系分类，只有“播放/暂停/停止”三者存在逻辑关系，划为一个类（即它们与其他因素共同设计用例时，做为一个整体看待）。
            然后，先单独设计只考虑“播放/暂停/停止”的用例组。
            最后，剩下的因素因为没有逻辑关系，可以逐个单独设计用例。
PS：此部分无需设计各个元素复杂交互用例，这部分想到的交互用例点可以先记录下来，放到非功能的交互测试中统一设计，这样比较节约用例数。

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

就写这些，LZ先看看，然后想想接下来怎么测，有具体的想法，大家再交换看看。