01 半个产品 半个开发

　　我认为真正的测试 = “半个产品+半个开发”。有人觉得这个有点讽刺，真正的测试？难道我们不是真正的测试，平常做的都不是测试的工作吗？其实不肯定也不否定，但这是一个包含关系，如果只是评审+用例编写执行，那么确实不是一个真正的测试。

半个产品，主要体现在理解这个需求为什么要做？其核心价值在哪里？吸引用户的特点是什么？意味着在评审阶段，你除了帮助完善功能需求外，更重要的是理解这个需求对于用户有什么价值，你是用户你会怎么想有什么感受，不能简单的走完流程就可以了。比如一个播放视频类应用，多样性、流畅度、简易性、快速性等是在评审之后可以总结出来的，那么抱着这些价值点，围绕这我们的整个测试流程，往往能够发现不一样的地方。比如还是播放类应用，在我了解个特性后，在测试过程中我会更加留意播放方面的性能，以及兼容性，在我设计测试方案的时候就会标明这几个测试重点，以便我自己或者组员能够在测试过程中多加留意这部分的测试点，然后在设计测试用例的时候会提高优先级和覆盖率。可以发现，测试有了测重点。

半个开发，其实个人认为这是偏向于灰盒测试了，体现在一个需求，你除了要明确这个需求的业务逻辑，其代码逻辑（数据流逻辑）也是需要知道的，从后台获取的json数据结构到客户端展示再到存储至本地数据，这一个流向，都是需要去了解并测试的（这部分参照之前写的测试分析文章），所以测试验证的不仅仅是功能层面的东西，还是内部的具体实现（当然，具体到类方法的测试那是测试开发的职能，不关咱测试的事），我们要保证的，就是这一阶段数据的正确性和容错性。这样做的好处是，能从内部发现缺陷，在出现问题的时候可以大概定位到问题出在哪，在出问题面对boss的质疑能够把责任丢给开发，哦不，是更好的解决问题。

那么半个开发还体现在对工具效率的提升上，能够通过小脚本，小框架去提升测试效率，这要求对于基本的语言要求是必须的，大公司面试的某一轮考研的就是你的代码能力，所以测试还是半个开发这一点是毋庸置疑滴。

　　02 职能范围

　　●评审

　　●测试方案的确立

　　●用例的编写维护

　　●技术点的分享

　　●BUG提交和总结

　　●输出测试报告

　　●集成测试

　　●发布版本

　　●论坛/其他渠道收集反馈

　　●服务器性能测试

　　●APP性能测试

　　●网页前端性能

　　●编写自动化脚本

●（暂时想到这么多，嘿）

　　03 日常的工作流程

　　至少是我，在刚接触测试的时候，除了完成领导的任务（主要是看需求，写用例，执行并回归）外，没有什么事情可做，现在回想起来，其实能做事情还有很多，只是没被安排（咳咳，我可不是说我第一份工作的领导不好），好其实是没有意识去提高而已。

　　其实就现在而言，我目前的工作流程是这样的（当然是以一个版本迭代为周期）:

　　评审新需求，记录关键点–>编写测试点（用例）–>测试之前向开发了解部分实现–>执行测试（翻阅代码，查看主逻辑走向<可选>）–>提交BUG–>回归BUG（查看BUG代码改动）–>新需求的性能评估（可选）–>发布前的系统测试（结合自动化）–>发布–>自动化用例的补充（可选）–>业务逻辑总结归总–>休息

那么基本流程就是这样了，那么可以看到一隔项目组的正真的测试人员，是要完成这么多工作的，所以这也是用来区分手工的外包人员和正式员工的区别，外包怎么样，大家都知道。

　　成长计划：

　　窃取某个大神的关于时间安排

　　时间 工作内容

　　30% 评审用例维护等准备以及后期工作

　　20% 执行测试用例，BUG回归

　　50% 自动化 & 新技术学习，引入！