音频转换通项目案例简单过程分享

文章目录

音频通转换

1、要求

2、BUG分享

3、问题

4、总结

5、二轮测试

6、音屏转换通项目收获

---

音频通转换

1、要求

1. 测试音频转换通软件，采用尽可能的测试方法去测试软件，找出更多的缺陷
2. 不少于10条缺陷
3. 把缺陷记录下来，记录到本地文件中

2、BUG分享

1. 系统不够安全，容易被杀毒软件误判。
2. 软件时常出现崩溃。
3. 软件的滑动条功能不能使用。
4. 有些音视频格式不支持。
5. 用户无法注册。
6. rmvb转MP3格式，会显示加载real引擎错误。
7. 合并转换功能界面的上移下移没有默认操作对象。
8. 放大，缩小按钮图形界面不符合用户的使用习惯，没有友好提示，用户体验差。
9. wma格式转ogg格式之后，不能正常打开。
10. ogg，ape音频文件再播放的时候时间进度不能正常跳转。
11. 在进行截取转换的时候，起始时间可以大于结束时间。

3、问题

1. 提交缺陷报告单的时候，具体的复现步骤一定要描述清楚
2. 测试的时候一定要确认测试需求，测试需求不明确就不能测试
3. 测试的时候对于需求有歧义的时候，可以跟需求分析人员或开发去沟通确认
4. 不同的操作系统，不同的浏览器，不同的系统版本等在不同的平台上同样的操作可以出现不同的结果
5. 有些问题有时候会出现，有时候又不会出现，是偶发性
6. 描述缺陷的时候，描述不清，具体的操作步骤，测试使用的测试数据，操作环境

4、总结

1. 测试的实际结果要跟需求文档中的预期结果保证一致
2. 对于测试需求不明确的软件，在测试的时候站在用户的角度去使用操作，进行测试（用户体验）
3. 测试的时候要考虑不同的系统，不同的版本，不同的浏览器的兼容测试
4. 测试的时候要采用一些非常规的测试手段进行测试，要扩散思维，尽可能多的覆盖测试点
5. 针对偶发性的问题在测试的时候要多测几次，把出现的频率找出来，测试10次，出现问题2次。
6. 对于每一条测试用例，在测试的时候至少保证测试3次以上。如果3次都没有问题，认为是没有缺陷的，如果出现一两次问题，就是偶发性缺陷，要多测几次，参照上一条总结。
7. 提交缺陷报告的时候，格式要规范统一，内容：缺陷id编号，功能模块，前置条件，复现步骤，预期结果，附件，缺陷的严重等级

5、二轮测试

1. 遍历系统的所有功能模块，所有输入域，帮助文档度可以进行测试
2. 采用一些非常规的测试手段，扩散测试思维，验证系统的稳定性，健壮性，容错性
3. 采用一些超大、超多、超长文件进行测试
4. 多次重复不间断的操作，稳定性测试，性能测试
5. 考虑功能测试之外，补充其他的多一些非功能测试（兼容、稳定性、健壮性、性能测试、UI测试--界面）

6、音频转换通项目收获

1. 1.提交缺陷报告的时候要规范格式，统一标准：测试模块，缺陷标题，前置条件，缺陷复现步骤，实际结果，预期结果，测试类型。。。
2. 2.测试的时候对于一些偶发性的问题，多测几次，找出发生的概率，测试10次，发生3次
3. 3.对于每一个测试点，测试用例，至少测试3轮以上
4. 4.测试的时候需要先确定需求，根据需求提取测试需求点（测试需求跟踪矩阵，测试需求点），再根据测试需求执行测试
5. 5.团队协作的重要性，个人的能力是有限的，发现的缺陷也是有限的，团队协作，大家可以相互学习，相互帮助，从而找出更多的BUG
6. 6.测试本身来讲并没有太大的难度，难点在于如何保质保量的完成测试任务，去尽量的覆盖所有的产品需求，提升产品质量这是测试的重点