51Testing软件测试论坛

标题: 怎么设计音频播放器的测试用例，如mp3？ [打印本页]

作者: chrisyang2008 时间: 2008-12-8 16:54
标题: 怎么设计音频播放器的测试用例，如mp3？
怎么设计音频播放器的测试用例，请各位大侠指教一下，比如mp3播放器。音乐模块怎么来设计测试用例才可以把功能点覆盖呢？

作者: jackie_li 时间: 2011-4-7 10:44
我也想知道

作者: Jackc 时间: 2011-4-7 17:38
建议使用用例设计之“狗皮膏药”：我分我分，再分类
（玩笑而已，切入正题）
——————————————

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

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

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

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

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

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

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)