目录
前言
大家好！很高兴能有机会给大家做这个报告。
通过这些日子的BREW学习，新来的同事对BREW应该都有了一定的理解，相信上手快的同事都已经开始写程序了，这真的是令人高兴的事。还有我们在坐的老同事，都是BREW界高手了，呵呵！今天之所以要给大家做这个报告，是为了大家更好的了解我公司应用测试流程，以使我们开发部门与质管部门衔接的更好，提高我们整体工作效率。
您的努力牵动着我们的效率，我们的努力更关乎着您的成绩！您的认真负责、严格按照测试流程执行的态度使我们测到的问题大幅减少，使中间的疏忽错误为零（最好），这样我们自测一次性通过，当然我们的测试效率会极大提高，提前测试计划结束测试任务那该多好！同样，您也有您的制作与移植任务，高的通过率也会节省您的时间。因此，做这个报告目的是希望能对您以后的工作有所帮助，有所指导。
关于我们质管部门内部工作流程请您一定要看，要了解。因为您要直接参与与本部门联系、提交测试包，因此按照流程执行能使工作更加高效。相关流程图已在附录中列出。
第1章资源编辑
1.1 图像
就目前为止我们制作过程中用到的图片信息都是bmp或png格式的，后来推出的某个别手机支持gif、jpeg等格式，但我们没用过。图片采用什么样的格式很影响应用包的大小，影响大小的另一个因素是图片的色深，就目前来说，手机BREW空间有限，内存有限。因此我们在制作应用使用图片过程中要掌握一些原则，其实这些别处都没说到过，这只是本人的一些经验而已，本处提出谨供参考。
⑴图片色深最高为8位，即256色，所有高于本色的图片都要改为本色或更低。当色深还可以再降时要尽量向下降。例如图片为某纯色的，那么16色即4位就满可以表达了，这时要是用8位即256色表达图片大小肯定要增加1倍。
⑵图片大小处理：无用的边要除掉，比如我们要用的是该图片内部的图形，那么多余的无用的边就剔除掉。
⑶想办法减少重复性图片。比如：扑克游戏，黑红梅方四种，如果每种都各做一张图片就要54张，但是如果通过更好的处理只用18张小图片就可以了，想想这样要省掉多少空间。
⑷高色深的大图片用png格式。
等等吧，这些只是一些小经验，其实在实际制作过程中主要是灵活些。还有就是要有一些简单处理图像的技术，这些很有益处的，比如自己通过某软件简单修改一下存储就好的问题，一旦要美工去修改可能要半天，为什么那，因为美工可能正忙其他的工作暂时放不下或当天没来上班，如果你等就不知要等多久了，因此有一些编辑处理图像的基本功是很重要的。
1.2 文字
通过资源编辑器编辑的字串信息都要采用unicode格式，这样在程序中调用显示才能正常。还有就是资源字串的命名要采用程序中变量命名原则，这样当你想编辑修改时比较容易查找到，而且源代码可读性也高。有些文字可以直接写在程序中，而不需要写在资源中，这样调用起来会比较直接比较简单，否则会很烦，这点可根据经验来定。
1.3 对话框控件
BREW资源编辑器中提供了好多控件，在制作应用过程中可以根据实际选用。但说句实话我从来没用过，个人感觉不是很好用。比如：如果我们用到菜单，我们可以通过图片或自己制定颜色条上面嵌字来处理。还有就是我们在程序中可以定义一个IMenuCtl接口，通过本接口函数来创建、显示一些菜单。
1.4 资源文件bar
资源编辑器编辑出来的bar文件存放了应用中所有的资源信息。如果应用中要用到好多图片、文字等，为了防止bar文件过大程序员需要作些调整。可在应用编制过程中将整体的bar信息分开来放在几个bar文件中，这样在应用包中包含几个bar文件是可以的。倘若只用一个整体的bar文件很可能遇到某款手机测试不通过被打回来。“王牌战机”在测试lg8380、lg930、lg950这组时当测到lg8380时就遇到了问题，其他手机都测试通过了，唯独测lg8380时联通那边测试人员无法将bar文件通过数据线下载到手机中，导致测试失败。后来将bar文件分成几个文件提交后就通过了。这是想不到的问题，但是我们可以避免的，因此我们在应用制作过程中一定要注意单个文件大小。除了mod文件我们无法拆分为多个文件之外，其他类型的文件又要限制在150k之内，最好限制在100k之内。以后如果我们测试过程中发现了这个问题将作为错误返回。
第2章 mif编辑
2.1 CLASSID
MIF编辑器中要用到的ClassID序列号，我们无论是做新应用还是移植，都要从高通网站下载ClassID号，同一个ClassID号不可重复使用。移植中要更换ClassID号，这点一定要记住，否则出现后续问题自己负责，因为测试过程中是无法知道在此之前本ClassID号有没有被使用过，倘若用了已经使用的ClassID号，即使应用已经通过联通测试也会被返回重换ClassID号的，这样还需要重新测试。
2.2 应用中文名称
MIF中“Name”一项要添应用中文名称，应少于6个汉字，否则应用程序中文名称可能在手机上显示不全面。
2.3 应用类型
即MIF文件中的“Applet”一项，点开会发现所有应用可选的类型，我们目前用到的基本是“game”和“tool”两种，比如“极品图片”应用不属于game，而应该属于tool；“超级玛丽”属于game而不是tool；如果是屏保应用应该选“Hidden”。因此在编辑MIF本项时要注意选对。
2.4 图标
图标有三种大小规格，16X16、26X26、65X42，注意16X16、26X26两种图片四周要至少有一个象素的紫色边环，否则我们测试将不予通过。还有就是图片不要使用顺序错误，比如该使用16X16规格图片处使用了26X26规格的图片。
2.5使用优先级
MIF中各优先级的选用是要根据实际情况选取的，如果在应用运行过程中对文件进行操作（创建、读取、写入、删除等）要选“file”，“position location”是用于定位应用的。联网应用如果是socket连接，“Network”和“Tapi”要选，如果是Web联网，“web access”要选。要写数据或读取数据于共享目录需要将“write access to shared direction”。要将铃声保存到铃声目录需选中“write access to ringer direction”。要对地址薄进行读取操作需选中“write access to address book”。“access to sector information”，获得象限信息，本项没选过，也没有涉及到。
应用中用到了哪部分就选相应项，多选了就要增加测试点，因此测试出错或问题的几率也大。
2.6 作者、版权
MIF中作者都写“ilink”，版权一项写“ilink copyright”，不要写个人。其实这块儿即使写个人也没什么关系，在联通那边来说也可以测试通过。但因为是在公司工作期间开发的产品，因此版权应该归属公司所有。为统一起见都用以上写法。
2.7版本号
本处大家要特别注意，本处版本号要与应用提交包命名中的版本信息及submit文档中版本信息一致。否则将被返回重新修改提交。
通过编程实践，我认为应用中不要在资源文件中人为手动输入版本信息，否则修改的地方比较多，稍有疏忽就出错被返回。ISHELL_GetAppVersion()函数即可读到MIF中的版本信息。因此在关于页面的版本信息最好通过本函数来读取，这样将来一旦涉及到修改版本信息只需修改MIF和submit文档及包文件名称即可。
版本号定制原则：新应用第一款版本命名1.0.1，第二款1.1.1，依次下排，一组提交包只需一个版本号。不同包版本命名只需中间变动即可，当本款一次未通过重新提交的包版本号只需最后一位向上加1即可。
第3章测试提交
3.1包命名格式
应用包应该这样命名：XXX_YYY_Va.b.c_p.rar。其中XXX(公司英文名称)；YYY（应用英文名称）；Va.b.c(应用包版本号)； p(平台号码)， 如果是一组提交版本号处应写Multiple;包用RAR压缩格式。
3.2包内容
本RAR压缩包经过解压缩后要有三个文件夹：arm、doc、win；其中arm包存放的是应用要下载到手机中的所有文件，但签名文件不能放入。Doc包中存放三个文件：Mnl_ilink_YYY.ppt（YYY是应用英文名称），spec_ilink_YYY.doc（YYY是应用英文名称），Submit_ilink_ YYY.doc（YYY是应用英文名称）。arm包存放的是应用在模拟器中运行所用到的所有文件。
3.3 doc文件夹
Mnl_ilink_YYY.ppt（YYY是应用英文名称）是一个介绍公司、应用的文档，介绍应用时只写中文介绍和操作介绍等。
spec_ilink_YYY.doc（YYY是应用英文名称）是提交文档中最不好写也是值得注意的地方最多的文件，因此在书写本文档时要按要求填写，同时填写内容要和应用实际统一，没有的不要写，有的要介绍到（秘笈除外）。每次移植时应用可能修改了某处，因此本文档一定要记得修改过来，比如本来应用是有音效的，但移植中发现某款手机加了音效可能测试出现麻烦，因此就把音效拿去了；此中情况下本文档中就应该将与音效有关的东西都拿去。
3.3.3 submit文档
本文档也非常重要，因此在提交时要认真填写不可有误，否则会直接导致错误被退回来。本文档中的“中文描述”一栏要填写应用的中文描述、定价方案、应用申请位置、关于中的内容。大家在初次填写本文档时要向我索要参考文档以备参考，其他有关本文档的东西本处就不提了。
3.4包放置
包打好后要放在OA/文件共享/产品测试提交区/部门文件夹/应用文件夹下，包格式为XXX_YYY_Va.b.c_p.rar
3．5提交给质管部测试的必备条件：
⑴按屏幕尺寸来说必须完成两个屏幕尺寸的准备，之所以这样规定是因为目前手机资源缺乏，如果同时有几个应用要测，单单准备一个屏幕尺寸手机资源分配不开。还有就是尽量让测试人员每天都有东西测，减少测试人员等程序员移植所耗费的时间。
⑵首先可玩性上要通过夏海江评估，评估没有通过的不予测试。
⑶DEBUG完毕需夏海江检测，检测通过需部门乃至项目负责人填写“产品测试申请表”
⑷从测试开始，要测的应用包要在OA上放好。
以上条件都具备者才能测试。
3．6程序员需注意的几点：
1、Mif中图片格式、尺寸、边际透明问题：图片分三种尺寸，16×16、26×26、65×42，一定要用BMP格式，色深不得高于256色，而且在MIF中依次应为26×26、65×42、16×16。
2、Mif中可选项的正确选择问题：Applet一项如果是游戏要选Game，是工具类的要选Tool；Privilege Level下面用到了哪项就选哪项，不要多选；License下面始终为None。
3、Mif与mod的对应问题：最后给我的提交包中Mif与Mod要对应，要确保应用下载到手机中能正常运行起来。
4、包里文件问题：arm和win包中文件名中不能有大写字母，更不能有0字节文件存在，BAR文件不得超过150K，太大的需拆成两个或多个。
5、音效、图片手机支持问题：哪款手机支持什么音效格式在移植中一定要认真看移植表中的手机性能，不支持的音效在应用中要拿掉。图片来说开发人员和美工要得图片应要BMP格式，需要在应用中用PNG的自己通过ACDSEE来转。
6、有关程序上模板性质的共同处理的方面，请大家都用统一的程序代码，比如fstest处理，关于中的版本读mif处理等，不要在资源中写，否则经常会发生mif与关于中版本不对应问题。