文章目录
音频通转换
1、要求
2、BUG分享
3、问题
4、总结
5、二轮测试
6、音屏转换通项目收获
音频通转换
1、要求
- 测试音频转换通软件,采用尽可能的测试方法去测试软件,找出更多的缺陷
- 不少于10条缺陷
- 把缺陷记录下来,记录到本地文件中
2、BUG分享
- 系统不够安全,容易被杀毒软件误判。
- 软件时常出现崩溃。
- 软件的滑动条功能不能使用。
- 有些音视频格式不支持。
- 用户无法注册。
- rmvb转MP3格式,会显示加载real引擎错误。
- 合并转换功能界面的上移下移没有默认操作对象。
- 放大,缩小按钮图形界面不符合用户的使用习惯,没有友好提示,用户体验差。
- wma格式转ogg格式之后,不能正常打开。
- ogg,ape音频文件再播放的时候时间进度不能正常跳转。
- 在进行截取转换的时候,起始时间可以大于结束时间。
3、问题
- 提交缺陷报告单的时候,具体的复现步骤一定要描述清楚
- 测试的时候一定要确认测试需求,测试需求不明确就不能测试
- 测试的时候对于需求有歧义的时候,可以跟需求分析人员或开发去沟通确认
- 不同的操作系统,不同的浏览器,不同的系统版本等在不同的平台上同样的操作可以出现不同的结果
- 有些问题有时候会出现,有时候又不会出现,是偶发性
- 描述缺陷的时候,描述不清,具体的操作步骤,测试使用的测试数据,操作环境
4、总结
- 测试的实际结果要跟需求文档中的预期结果保证一致
- 对于测试需求不明确的软件,在测试的时候站在用户的角度去使用操作,进行测试(用户体验)
- 测试的时候要考虑不同的系统,不同的版本,不同的浏览器的兼容测试
- 测试的时候要采用一些非常规的测试手段进行测试,要扩散思维,尽可能多的覆盖测试点
- 针对偶发性的问题在测试的时候要多测几次,把出现的频率找出来,测试10次,出现问题2次。
- 对于每一条测试用例,在测试的时候至少保证测试3次以上。如果3次都没有问题,认为是没有缺陷的,如果出现一两次问题,就是偶发性缺陷,要多测几次,参照上一条总结。
- 提交缺陷报告的时候,格式要规范统一,内容:缺陷id编号,功能模块,前置条件,复现步骤,预期结果,附件,缺陷的严重等级
5、二轮测试
- 遍历系统的所有功能模块,所有输入域,帮助文档度可以进行测试
- 采用一些非常规的测试手段,扩散测试思维,验证系统的稳定性,健壮性,容错性
- 采用一些超大、超多、超长文件进行测试
- 多次重复不间断的操作,稳定性测试,性能测试
- 考虑功能测试之外,补充其他的多一些非功能测试(兼容、稳定性、健壮性、性能测试、UI测试--界面)
6、音频转换通项目收获
- 1.提交缺陷报告的时候要规范格式,统一标准:测试模块,缺陷标题,前置条件,缺陷复现步骤,实际结果,预期结果,测试类型。。。
- 2.测试的时候对于一些偶发性的问题,多测几次,找出发生的概率,测试10次,发生3次
- 3.对于每一个测试点,测试用例,至少测试3轮以上
- 4.测试的时候需要先确定需求,根据需求提取测试需求点(测试需求跟踪矩阵,测试需求点),再根据测试需求执行测试
- 5.团队协作的重要性,个人的能力是有限的,发现的缺陷也是有限的,团队协作,大家可以相互学习,相互帮助,从而找出更多的BUG
- 6.测试本身来讲并没有太大的难度,难点在于如何保质保量的完成测试任务,去尽量的覆盖所有的产品需求,提升产品质量这是测试的重点