高通对brew的定义就是：brew是一种无线移动网络中的端到端的解决方案。brew是一种解决方案。“B－”针对j２me的虚拟机（解释）而言，说明brew的目标文件是二进制代码，不是中间解释程序。“R－”说明brew是动态加载机制，只有当需要运行的时候，代码才加载运行。“E－”代表BREW不仅仅是一些接口API，BREW有自身的内核，有自身的执行环境（AEE环境）。“W－”代表BREW是专门针对无线移动的解决方案。
BREW，你可以把它看作是软件，至于是什么编出来的，不考虑。虽然BREW环境的实现是用C语言，但是BREW应用的开发，“理论”上来说应该可以任何语言，目前主要是c，c＋＋。其实，如果拿BREW和J２me作比较，那才具有可比性（联通和移动也比较倡导支持）他们都是中间件技术。brew是中间件！
中间件位于操作系统（以及native软件）与上层应用之间。通过它，可以使得应用的开发变得可扩展，灵活和“标准”。
首先，我们看看没有中间件出现时的手机开发模式。
此时，整个手机的开发都是oem厂商完成的。他们在手机的操作系统上编写一个个的task代码，编写一个个特定功能的底层api函数和服务（我们称之为native），然后再利用这些native的代码编写一些手机应用，比如电话簿，短信等等。此时，任何第三方都将无法进入这个行业，因为他们需要了解这个手机的系统，以及这些native的api，才能开发上层应用。但是，通常这些都是保密的。所以，那个时候，几乎没有develop的存在，只有oem。
而中间件技术出现后，整个手机开发模式被改变了，我们以brew为例。
我们把上面所讲的开发模式称之为纯native开发模式。而一旦handset被porting brew之后，那么在native之上就多了一个中间层，即中间件。中间件（brew）定义了一套标准的接口（环境），这套标准的接口（环境）是面向上层的，面向develop的。而这套接口（或者环境）的实现则是调用了native（以及操作系统）的服务，我们称之为porting。这样，中间件屏蔽了底层的差异性和具体实现，对上提供标准的接口。从而催生了手机develop这个行业的出现。因为，他们无需考虑具体手机，只需要利用中间件提供的标准接口（环境）来开发可移植的应用。这种可移植性的本质是因为，对于develop所呈现的“共性”是通过oem的“个性”来呈现的，并且通过中间件这样一种模式，屏蔽了这种共性和个性之间的联系。使得使用和实现分离。达到了可移植性！
说到中间件技术，其实现在最多提到的就是j２me，brew，mhp。j２me是通过jvm在不同平台上的porting来提供通用的java接口。mhp是机顶盒上现在用的很多的中间件标准，具体的我就不是很清楚。另外，brew和j２me还是有区别的，因为j２me仅仅是一个瘦client型的中间件技术，不涉及端到端的整套方案。而brew不仅仅指handset上的中间件（brew）同时还包括ads（服务器端），所以brew不仅仅是中间件，完整的说，就是高通的定义，是一种端到端的解决方案。
再说说brew应用的测试测试。记得5年前我还是愤青的时候，就学BREW应用开发，那时C基础不是很好，通过BREW后，还真有点提高。那时，老是埋怨测试的人，老是提一些莫名奇妙的问题，现在好了，自己的队员也被埋怨提一些莫名其妙的问题。现在做BREW的人少，比较难找，找到一些，水平不是很高，很难伺候。真是实在不行，我还真想操刀来解决bug。
不过，想想也是，brew不像MTK那样，整套的不多，做的难度大一些。我不是很清楚，做w为何要选高通选BREW，也许自有好处。不管怎样，竟然做了，还是整理一下思路，发发牢骚而已。
1.界面和资源测试
这个测试稍微简单一点，改也好改。主要是对应一下规格说明书，没有什么争议。有些资源过大会引发重启，也是可以人工测试出来的。顺着菜单覆盖，对我们来说没有问题。
2.需求变化
软件需求会变化，是很正常的。人家需求部门给咱们写剧本，也要删改一番。怎么删改，那就看看测试提供的数据了。测试这边，还是尽量在某段时间内，总结一些有用数据，提供给兄弟部队，别让他们像“羊拉屎”。MTK那边好像是“4n+1”模式，我什么时候再去看看，讨教一下。
还包含用户的易用性测试。往往用户的需求是不断的变化的，而其中的一部份变化的原因，是有用户操作上不方便引起的。这是测试过程中斟酌需求变化的一个重要数据。
3.着重内存泄露勘察
对于释放操作，要强调反复的去做，比如，按“返回”键，一定要多按几次。我正在想一种方法，搞一个工具，记录键值，然后回放，一下做个几万次。我就不明白，模拟器上有内存使用记录，开发就不在意，后面要跟他们商量一下。我这边查了一下相关资料，还真有这记录键值这回事，后面再研究研究。
4.差异化分析
人家是3G，有些应用变了，要注意做好测试分析
5.测试跟踪
要求他们写releasenotes了。在程序员刚修复Bug之后的地方,再找一找，往往程序员只修复报告出来的缺陷而不去考虑别的功能在修改时可能会重新造成错误，总之，还是看看你们的记录再说。
6.加强内置第三方软件测试
坚决保留精华应用，打击那种烂东西。对于存在收费陷阱的，坚决不要。对于影响系统的，要督促修改。
7.对于分支版本
这东西，能够少搞点最好。只是有时不得以，事情不是都是想象的那么顺利啊！尽量都监控吧，做好人员沟通。
8.性能问题
从用户的角度出发，模拟用户进行性能评估。使用好对比机数据，要努力督促改善。代码测试组要配合进行优化。
9.人员培养
要培养测试人员习惯拿来问题就分析，问题到你那里就终止。倡导主动测试，想想，手机测试业界，走手工路线就很poor，要是再不引进“主动”这思想，估计也真是走到了头，没戏了。还要学会沟通。还要加强软件基础，艾，断点还很多，慢慢来吧。
做好手机测试，不要自暴自弃。不管别人怎么认为，我们需要自己做好做强，要是还是沉浸在单纯的传统测试上，不去技术革新，不去想提高效率，不去创造价值，那永远是这样，永远是辅助性职业。只有自强不息，努力的为企业创造更大价值。我将和我的小弟们一起，孜孜不倦，以超越的方式去面对这个行业。你本身没有价值，又不做好，又不思进取，谁在乎你？大家振作起来，光明在前。
虽然测试brew，问题很多，但是后面还有很多路，方法通过积累也会更多，同时，要放出多几个心眼，看看业界先进做法。
