本期导读：专业的移动端耗电量测试设备价格是非常昂贵的，有没有性价比更高的移动端耗电量测试解决方案呢，本期刘慧众给大家带来一种性价比非常高且有效的耗电量测试解决方案。埋点测试大家都听说过，埋点测试具体怎么做，要达到什么样的效果，谭莉给大家带来埋点测试的实例。
原创文章
穷团队测试耗电量出路@刘慧众
目前输出的 app 已经出现多次因为资源释放不当导致的异常耗电,严重的影响了用户在F 产品使用中的体验。性能测试虽然引入了耗电量测试,但是当前的手段效率相对较低(通过长时间使用来观察耗电状况)。
• 软件监控 app 解决思路,目前已经有市面上的开源项目供使用,F 技术组也有针对的做了引入和优化,但是使用软件做换算,存在测试误差,且工具本身存在兼容性。
• 硬件耗电电量测量,更可靠的方案是购买安捷伦,不过太贵了,以下使用一种相对便宜的解决方案来硬件测试耗电量。
移动端的埋点及测试@谭莉
对互联网不陌生，做过移动应用的同学，都会对埋点这个词不陌生。埋点的目的很简单，就是实现app的数据收集和分析。埋点本身其实是对于自己所设计的产品的有一个可视化健康检查，通过逻辑和数据，贯穿产品的整个生命周期，使产品逐步达到最佳状态从而实现硅谷最近所谓的“Growth Hacker”的效果
移动测试技术
利用浏览器window.performance 监控页面性能
当考虑 Web 性能指标时，需要关注的目标数字应该是从您自己的用户那里获得的实际用户指标。最常见的方法是利用 Splunk 之类的工具来分析您的机器数据，该工具支持您分析和可视化您的访问权限和错误日志。利用这些工具，您可以收集某些方面的性能数据，比如读取资产的文件 I/O 时间，以及 API 请求的访问时间。但是，您仍然需要推断客户端性能数据，将信号调用方在某些高级的检查点上，或者只利用类似 WebPagetest 的工具运行综合测试。现在，W3C 已将 API 标准化，用户可以通过使用 Performance 对象（该对象对于所有现代浏览器中的 Windows 对象而言是一个本机对象）捕获并报告浏览器内的性能数据。
深入理解Android消息处理系统——Looper、Handler、Thread
熟悉Windows编程的朋友可能知道Windows程序是消息驱动的，并且有全局的消息循环系统。而Android应用程序也是消息驱动的，按道理来说也应该提供消息循环机制。实际上谷歌参考了Windows的消息循环机制，也在Android系统中实现了消息循环机制。Android通过Looper、Handler来实现消息循环机制，Android消息循环是针对线程的(每个线程都可以有自己的消息队列和消息循环)。本文深入介绍一下Android消息处理系统原理。
后端测试技术
http状态码详解
这里有各种http状态码的详细介绍
Java 内存分配和回收机制
Java的GC机制是自动进行的，和C语言有些区别需要程序员自己保证内存的使用和回收。
Java的内存分配和回收也主要在Java的堆上进行的，Java的堆中存储了大量的对象实例，所以Java的堆也叫GC堆。
Java在垃圾收集的过程中，主要用到了分代收集算法，我会先讲一下常用垃圾收集算法。
通用测试技术
软件项目的用户验收测试
随着当今技术和市场环境的变化，越来越多的企业选择将软件项目外包，同时也有更多成熟的大型软件企业加入到软件项目的承包队伍中。外包的软件项目越来越多，如何对这些外包的项目进行验收测试日益成为企业的一个关键问题。
如何编写优质的软件测试需求文档
编写需求文档，在嵌入式开发领域是非常普遍的。需求文档被用来定义开发任务，协调大规模的研发计划。对于最终的产品，需求文档扮演着开发者行为和消费者行为之间沟通纽带的角色。当需求文档书写正确的时候，便可以发挥巨大的作用。然而，如果你在嵌入式开发领域工作的时间足够长，你就会很快发现，这个领域里不合格的需求文档实在是太多了。当你尝试对这些不合格的文档进行修复时，你又会很快发现，书写正确的需求文档绝非易事。在这里，我们提出一些建议，希望能将书写正确需求文档这件事情变得清晰一些。
新技术学习－QA也疯狂
js立即执行函数
经常遇到自执行匿名函数的代码，今天我们主要就来想想说一下自执行。
ios10亮点必看! iOS10新功能全解析
iOS10新功能盘点
测试杂谈
由丰田代码事件引发的软件质量思考
2013 年 10 月，丰田公司匆匆了结了“意外突然加速” 诉讼案。经过数小时的讨论，俄克拉荷马法庭陪审团得出结论：丰田汽车制造商贸然不顾用户的安全，裁定丰田公司赔偿原告 300 万美元。
而在审阅了 2005 版的丰田凯美瑞汽车的软件开发过程和源代码之后，两位软件专家得出一致结论：丰田公司的系统不但有缺陷，而且达到了危险的程度。因为故障保护机制里充斥着错误和不一致，这是导致事故的根源。
如何做好回归测试
在总结回归测试的方法时发现，不管国内国外，这都是个头疼的话题。做是要做，也能做，但是从效率角度说可是千差万别。给我足够多的人或是时间，总是可以保证回归测试进行的彻底，可是那并不是做事情的方法和解决问题的手段。我觉得google的James Whittaker说的好“事实上，有些测试组坚持要保持一个规模相对比较大的团队主要是因为他们的假设前提就是有些事情做错了。这也意味着编码和测试之间的工作失衡。添加更多的测试人员并不能解决任何问题。”“In fact, teams that insist on having a large testing presence are generally assumed to be doing something wrong. Having too large a test team is a very strong sign that the code/test mix is out of balance. Adding more testers is not going to solve anything.”当然，google把quality交给developer去own才能将测试人员的工作真正做到是质量环节的最后确保。而不是去检查developer犯的错误。
