「转载」为什么现在的移动应用测试还不够敏捷?

Coness · · 939 次点击 · 开始浏览    置顶
这是一个创建于 的主题,其中的信息可能已经有所发展或是发生改变。

「转载」为什么现在的移动应用测试还不够敏捷? 做移动端的都知道吧,测试的重要性。严格的测试是移动应用的保证质量,那么敏捷测试就是保证可以持续、及时的对移动应用质量情况进行全面的反馈。由于在敏捷开发过程中每个迭代都会增加功能、修复缺陷或重构代码,所以在完成当前迭代新增特性测试工作的同时,还要通过回归测试来保证历史功能不受影响。 要怎么才能实现敏捷测试 测试范围足够广: • 测试用例要覆盖所有功能; • 要在各种可能的环境下作兼容性测试; • 系统的稳定性、性能都要测试; 测试频率足够高: • 每日构建产生的版本要保证可用; • 每个迭代都需要对历史功能做回归测试; • 释放前或上线后如果打了补丁,就需要回归; 但实际情况: 实际测试周期变短: • 上线时间提前确定,研发进度延期,测试计划被迫延后; • 最后阶段经常会临时增加测试任务; • 所有人都知道还需要再经过一轮测试,但时间没有了; 有效测试资源稀缺: • 临时从其他项目抽调的测试人员不能立刻有效的开展测试工作; • “搞不清楚”本项目的研发人员到底是不会做测试还是不愿做测试; 因此由于客观上的资源和时间限制,完整的、及时回归测试在人工测试情况下,往往是不可能完成的任务。导致团队内部产生各种争执,比如: • 提交给测试的版本为什么研发人员不先做通过性测试? • 这次代码改动量不大,有必要再花那么多时间回归么? • 当初不是承诺这次修改肯定不会影响以前的功能么? • 怎么不早说要支持Chrome浏览器,现在哪还有时间测试啊? • 怎么能让现场出现这种低级的Bug,打补丁后为什么不仔细回归一遍? 争执越演越烈,最终有团队成员爆发了:“这简直不是人干的活!”。 用更理性的语言翻译一下就是“有些工作不应该以人工的方式来完成”,比如: • 大量机械的、重复性的回归测试; • 结果的正确性不依赖主观判断的测试; • 需要模拟大量数据、大量并发量的测试; • 需要不间断执行的测试(比如7*24小时持续执行); • 需要短时间内完成的大量测试用例执行(比如完整的功能回归测试); 到这里就很明确了,通过自动化测试可以极大的提升回归测试、稳定性测试以及兼容性测试的工作效率,在保障产品质量和持续构建等方面起到举足轻重的作用。特别是在敏捷开发模式下,自动化测试是必不可少的。 下一期,我将以在自动测试平台TestBird完成的一个实例讲解如何让回归测试变得轻便快捷

有疑问加站长微信联系(非本文作者)

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889

939 次点击  
加入收藏 微博
暂无回复
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传