关于如果自己一个人负责测试一个app的思考
2016-02-22 12:33
246 查看
其实有时候自己会思考,假如有一天需要自己负责一个新的apk,整个测试组只有我一个人,那么我会怎么办。
这个问题也是挺有意思的,之所以会思考写出来,是因为我知道如果面对这个问题,我一定会手足无措的,所以先来玩玩 :)
整个立项到发布的整体流程以后再写吧,这里从开发的预研开始。
其实我还是建议测试了解开发逻辑是从有一个成品的apk开始,因为如果从预研就去深入的话,中间变动太大,前期app还没开发出来测试应该思考针对这一类的app(某类的应用其实界面元素都是蛮像的)怎么做性能和自动化测试,比如需要什么性能指标,自动化框架哪个适合并深入研究,针对开发预研的大体方向学习一下应用的技术,例如我们大家都在用的微信,前期可以思考到的性能指标为,耗电,CPU,内存,如果保证消息的时效性,避免后台被杀的方案,自动化是以界面为主,所以主流的框架都可以用,当然腾讯自己肯定有自己的框架的。
前期就这么友好地度过了,接下来就是常规测试,测试方法前面文章已经说过了,看个人吧,我的方法并不一定适合所有人了。第一个版本发布药做好兼容性和跟踪外网问题,基本就差不多了。
其实重点还是项目的持续性迭代,包括我以及大多数产品都是在这个阶段的吧,我认为这个阶段就是这几个部分组成的:
1.新功能模块的功能测试
2.测试用例的编写
3.自动化用例编写和完善
4.重要模块的性能(我认为这不应该单独列出来了,因为平时测试功能模块的时候也要关注一下自己模块的内存时延,单独拿出来让一个人测试那个人也没有比测的人了解逻辑)
5.周期发布前的全面功能测试和安装覆盖安装
6.回归BUG
7.想到再添加上去吧 @.@
要做的其实也就这么多吧,等等,时间好像没加上,于是列个excel表格出来看下(仅供参考,如有雷同,你抄我的吧 ->.->)
最后,项目的持续性迭代过程中,可以考虑持续继承,比如在jenkins中每日执行monkey稳定性脚本,git代码发生变化的时候自动构建apk并执行静态代码扫描,针对常用模块完成UI自动化编写,定时跑跑,最后,接口测试没几个小时跑一遍
好了,写了这么多,最后总结一下
如果一个人开始负责一个新项目:
1.前期确定产品特性,规划大概一个测试方案
2.持续迭代过程中,根据时间规划新功能测试和用例编写,剩余时间技术性的自动话,性能和学习提高
如果又来了一个测试,那就合理分配测试任务,不过要考虑关联模块分配(再来多几个人是不是就变成小组了呢,呵呵)
3.持续性方案的继承,首选当然kenkins啦
还有一个矛盾的地方,有时候测一个功能,明明测试完了,不自信,或者别人突然帮你找出了一个bug,你就一直在那里持续性地测试,没完没了,加班加点,领导表扬...然后自己的提高时间也没有,但是在领导面前确实很忙很忙,囧...所以还是应该有规划,有目的测试,累了就玩玩找bug,这样才像话嘛。
这个问题也是挺有意思的,之所以会思考写出来,是因为我知道如果面对这个问题,我一定会手足无措的,所以先来玩玩 :)
整个立项到发布的整体流程以后再写吧,这里从开发的预研开始。
其实我还是建议测试了解开发逻辑是从有一个成品的apk开始,因为如果从预研就去深入的话,中间变动太大,前期app还没开发出来测试应该思考针对这一类的app(某类的应用其实界面元素都是蛮像的)怎么做性能和自动化测试,比如需要什么性能指标,自动化框架哪个适合并深入研究,针对开发预研的大体方向学习一下应用的技术,例如我们大家都在用的微信,前期可以思考到的性能指标为,耗电,CPU,内存,如果保证消息的时效性,避免后台被杀的方案,自动化是以界面为主,所以主流的框架都可以用,当然腾讯自己肯定有自己的框架的。
前期就这么友好地度过了,接下来就是常规测试,测试方法前面文章已经说过了,看个人吧,我的方法并不一定适合所有人了。第一个版本发布药做好兼容性和跟踪外网问题,基本就差不多了。
其实重点还是项目的持续性迭代,包括我以及大多数产品都是在这个阶段的吧,我认为这个阶段就是这几个部分组成的:
1.新功能模块的功能测试
2.测试用例的编写
3.自动化用例编写和完善
4.重要模块的性能(我认为这不应该单独列出来了,因为平时测试功能模块的时候也要关注一下自己模块的内存时延,单独拿出来让一个人测试那个人也没有比测的人了解逻辑)
5.周期发布前的全面功能测试和安装覆盖安装
6.回归BUG
7.想到再添加上去吧 @.@
要做的其实也就这么多吧,等等,时间好像没加上,于是列个excel表格出来看下(仅供参考,如有雷同,你抄我的吧 ->.->)
阶段 | 时间 | 优先级 | 说明 |
新功能 | 马上 | 最高 | |
测试用例完善 | 新功能测试完成,开发在修改BUG的过程中 | 中 | 也可以边测试边完善,看时间和人员充裕情况,但是测试前必须拟定测试点 |
回归BUG | 间歇性,一般改好有时间就验证,这个不怎么费时 | 中 | 这个只要描述清楚,也可以给非负责这个模块的人回归,因为不涉及太多逻辑,不过可能会回归发现新的逻辑性BUG |
自动化用例 | 有时间再弄 | 低 | 前期只需要大体的框架自动化,项目稳定再实现小细节,省时 |
性能 | 有时间再弄 | 低 | 非新手还是把性能柔和在普通测试中吧,因为更具有针对性 |
全面功能测试 | 发布前N天 | 高 | N自己定,但是最少也要预留3天吧,毕竟开发也要改BUG了,理论当然越多天越好 |
新安装/覆盖安装 | 发布前 | 中高 | 基本没问题 |
测试的学习提高 | any time | 高 | 嘿嘿,个人技术的提高是必要的,因为自动化和性能没必要每个版本都测试对吧,项目稳定后空闲时间还不少的,一个公司的好坏在于流程的规范,意味这任务完成有更多的时间给你提高,给你学习,bat都看中个人技术啦 |
好了,写了这么多,最后总结一下
如果一个人开始负责一个新项目:
1.前期确定产品特性,规划大概一个测试方案
2.持续迭代过程中,根据时间规划新功能测试和用例编写,剩余时间技术性的自动话,性能和学习提高
如果又来了一个测试,那就合理分配测试任务,不过要考虑关联模块分配(再来多几个人是不是就变成小组了呢,呵呵)
3.持续性方案的继承,首选当然kenkins啦
还有一个矛盾的地方,有时候测一个功能,明明测试完了,不自信,或者别人突然帮你找出了一个bug,你就一直在那里持续性地测试,没完没了,加班加点,领导表扬...然后自己的提高时间也没有,但是在领导面前确实很忙很忙,囧...所以还是应该有规划,有目的测试,累了就玩玩找bug,这样才像话嘛。
相关文章推荐
- android graphic(8)—surface申请GraphicBuffer过程
- Unity 4.6.x内存优化纪要
- android:descendantFocusability
- ANDROID_MARS学习笔记_S04_007_从服务器获取微博数据时间线
- java.lang.RuntimeException: Unable to start activity ComponentInfo{com.ex.activity/com.ex.activity.LoginActivity}: android.view.InflateException: Binary XML file line #1: Error inflating class
- <NSCoding>存储数据 archivedDataWithRootObject unarchiveObjectWithData
- android studio创建代码库分上传到jcenter,使大家一行代码引用
- android开发launcher
- 有关android.view.View
- 详解android:scaleType属性
- Android编程之fill_parent、wrap_content和match_parent的区别
- android:layout_weight的真实含义
- Android开发之TimePicker控件用法实例详解
- android自动化(appium)
- iOS-多线程开发学习(一)
- 那两年炼就的Android内功修养
- Android中使用SDcard进行文件的读取
- 仿ios时间,日期选择和三级联动控件
- Android实现广告图片轮播效果
- IOS 结合个推实现推送问题