关于如果自己一个人负责测试一个app的思考

其实有时候自己会思考，假如有一天需要自己负责一个新的apk，整个测试组只有我一个人，那么我会怎么办。

这个问题也是挺有意思的，之所以会思考写出来，是因为我知道如果面对这个问题，我一定会手足无措的，所以先来玩玩 :)

整个立项到发布的整体流程以后再写吧，这里从开发的预研开始。

其实我还是建议测试了解开发逻辑是从有一个成品的apk开始，因为如果从预研就去深入的话，中间变动太大，前期app还没开发出来测试应该思考针对这一类的app(某类的应用其实界面元素都是蛮像的)怎么做性能和自动化测试，比如需要什么性能指标，自动化框架哪个适合并深入研究，针对开发预研的大体方向学习一下应用的技术，例如我们大家都在用的微信，前期可以思考到的性能指标为，耗电，CPU，内存，如果保证消息的时效性，避免后台被杀的方案，自动化是以界面为主，所以主流的框架都可以用，当然腾讯自己肯定有自己的框架的。

前期就这么友好地度过了，接下来就是常规测试，测试方法前面文章已经说过了，看个人吧，我的方法并不一定适合所有人了。第一个版本发布药做好兼容性和跟踪外网问题，基本就差不多了。
其实重点还是项目的持续性迭代，包括我以及大多数产品都是在这个阶段的吧，我认为这个阶段就是这几个部分组成的：
1.新功能模块的功能测试
2.测试用例的编写
3.自动化用例编写和完善
4.重要模块的性能(我认为这不应该单独列出来了，因为平时测试功能模块的时候也要关注一下自己模块的内存时延，单独拿出来让一个人测试那个人也没有比测的人了解逻辑)
5.周期发布前的全面功能测试和安装覆盖安装
6.回归BUG
7.想到再添加上去吧 @.@
要做的其实也就这么多吧，等等，时间好像没加上，于是列个excel表格出来看下(仅供参考，如有雷同，你抄我的吧 ->.->)

阶段时间优先级说明新功能马上最高 测试用例完善新功能测试完成，开发在修改BUG的过程中中也可以边测试边完善，看时间和人员充裕情况，但是测试前必须拟定测试点回归BUG间歇性，一般改好有时间就验证，这个不怎么费时中这个只要描述清楚，也可以给非负责这个模块的人回归，因为不涉及太多逻辑，不过可能会回归发现新的逻辑性BUG自动化用例有时间再弄低前期只需要大体的框架自动化，项目稳定再实现小细节，省时性能有时间再弄低非新手还是把性能柔和在普通测试中吧，因为更具有针对性全面功能测试发布前N天高N自己定，但是最少也要预留3天吧，毕竟开发也要改BUG了，理论当然越多天越好新安装/覆盖安装发布前中高基本没问题测试的学习提高any time高嘿嘿，个人技术的提高是必要的，因为自动化和性能没必要每个版本都测试对吧，项目稳定后空闲时间还不少的，一个公司的好坏在于流程的规范，意味这任务完成有更多的时间给你提高，给你学习，bat都看中个人技术啦

最后，项目的持续性迭代过程中，可以考虑持续继承，比如在jenkins中每日执行monkey稳定性脚本，git代码发生变化的时候自动构建apk并执行静态代码扫描，针对常用模块完成UI自动化编写，定时跑跑，最后，接口测试没几个小时跑一遍

好了，写了这么多，最后总结一下

如果一个人开始负责一个新项目：
1.前期确定产品特性，规划大概一个测试方案
2.持续迭代过程中，根据时间规划新功能测试和用例编写，剩余时间技术性的自动话，性能和学习提高

如果又来了一个测试，那就合理分配测试任务，不过要考虑关联模块分配(再来多几个人是不是就变成小组了呢，呵呵)

3.持续性方案的继承，首选当然kenkins啦

还有一个矛盾的地方，有时候测一个功能，明明测试完了，不自信，或者别人突然帮你找出了一个bug，你就一直在那里持续性地测试，没完没了，加班加点，领导表扬...然后自己的提高时间也没有，但是在领导面前确实很忙很忙，囧...所以还是应该有规划，有目的测试，累了就玩玩找bug，这样才像话嘛。