测试基础四

嵌入式软件的测试方法      手机软件测试       手机现在在社会上应用很广，同时针对手机上的功能增加也非常快，例如，蓝牙，例如，短信，例如，信息下载，手机游戏等，这说明在未来发展中，手机将人们带在一个孤独的社会中去。
       简单回想，我们的上辈人开始用手机，那是后简单的目的：就是通讯，而且还必须在既定范围内，价格高昂等，这些只有很富有的人才能染指的东西现在在社会中的每个角落都可能。放羊的。。。。
       那么手机软件怎么测试呢？测试什么呢？怎么组织呢？
       那么我做简单的分析：首先确定手机软件是嵌入式软件，那么我们抛开IC测试，抛开盲区，耐久性，耐碰撞性测试不提，就软件本身测试需要考虑的内容。
       我们说了这么多，我们整理出来手机软件测试的核心是数据的时效性，怎么理解呢？不能说我发了个短信，对方一天都无法收到？或者我打电话，对方没有任何反映，这就说明有问题。
       在例如，通过手机的红外线，能把地址薄中的资料传送的电脑中，如果在传送的过程中出错，或者对操作系统有要求，或者在传输的过程造成数据丢失，导出来的数据是无法识别的格式等，都会造成该功能无效。
       再如，手机信息的存储问题，因为手机本身有自己的系统，有自己处理信息的方式和格式，那就牵掣到的问题和外界信息交互的问题，外界需要了解其格式，阅读其格式，就需要和外界有比较信任的通讯。      
       其次，是测试本身的功能，例如，能够正常拨打电话，能够正常编辑信息，能够正常保存朋友电话，能够有历史记录，能够正常闹钟和各种设置，能够正常有提示信息等。
       我再举个例子，手机中游戏软件的测试，我们先了解手机中游戏开发语言Java，其次，由于手机中的内存大小优先，所以游戏的大小以及运行的各种指标都很小，所以用KJava。还有一个特点，手机中的游戏是回合制，所以类似的同步要求不是很高，所以测试重点就有所改变。
       那么像手机游戏的测试点在那里呢？了解这个方面的测试，需要了解几个问题，运营商对产品的要求：
运营商对开发商提出的要求，一般情况有这么几种。第一，应用程序的大小；第二，应用程序的命名规则；第三，应用程序版本控制规则；第四，明确提出所支持的机器的类型；第五，采用的编码格式UTF _8的编码还是其他的编码；第六，外部中断的处理逻辑；第七，比对压缩后的文件和先前文件的比较。
       上面我提出了手机软件测试的七个重点，下面我逐步添加详细介绍各个部分的细节。
第一，应用程序的大小。由于应用程序在被下载时百宝箱会根据需要插入5K的程序代码，因此要求SP提交的应用程序其大小不能超过手机最大下载尺寸减5K，下表列出了目前市场上部分JAVA手机对JAR文件下载的字节数限制情况（未列入机型请SP咨询手机厂家）

手机型号	最大可下载JAR文件大小	百宝箱限制JAR文件大小	备注
Nokia 60系列	无限制	无限制	目前由于WAP网关不能下载超过100K的JAR文件，因此对于WAP方式下载应用的手机（T720除外），百包箱限制JAR文件大小不能超过95K。
Nokia 40系列	64K	59K
Motorola T720	无限制	无限制
Motorola 388	无限制	无限制
Motorola 388C	无限制	无限制
Siemens 3118/2128/S57/M55	无限制	无限制
NEC N800	60K	55K

其次，由于应用程序在被下载时百宝箱会根据需要插入程序代码，这段代码在手机上执行时要占用10K左右的堆内存，因此要求SP提交的应用程序在运行时要预留至少10K的堆内存。
第二，应用程序的命名规则。应用程序的命名规则的字符长度不能超过12个字符长度，而且命名有一定的规则，需要SP和提供商商定，但是必须依照行业标准。另外，在提交的时候，需要了解一些要求，由于各个SP开发商开发环境，编译环境等问题，所以运营商都提出严格的打包要求。
SP递交应用程序打包要求：
1.    JDK使用1.3.1版本（国际版）；
2.    打包工具使用SUN公司提供的J2ME Wireless Toolkit (midp1.0版本，1.0.3或1.0.4)；
由于SUN公司的WTK只支持标准的midp1.0，不支持各手机扩展的API，需要SP对所使用的WTK进行扩充才可以支持手机扩展的API，方法是：将扩展API加到D:\WTK104\lib\midpapi.zip（假设WTK安装在D:\WTK104目录下）中即可。
3.    不做扰码或使用RetroGuard进行扰码，不得使用别的扰码工具。
说明：1. SP在开发时仍然可以使用原来的工具进行开发，但递交应用时请使用SUN公司的WTK进行打包；
2. 如果SP不按照要求进行打包，出现百宝箱不能识别API的情况时将按照测试未通过的情况处理。
第三，版本控制要求是，版本控制的格式x.x.x，应该严格遵守这个规则。
      MP3软件测试通用软件的测试方法      办公类产品测试办公类产品的延续性相对较长，所以部分模块有利于自动化测试。我在这里介绍办公类产品的测试重点在那里？
       办公类产品的特点是人们在办公中经常要用到，频率很高，所以简单，易用，方便操作容易理解成为办公类产品的首要要求。
       其次办公类产品考虑的机器的硬件配置，例如显卡，打印机等外设
       第三，办公类产品还需要测试兼容性，因为自身延续性长的特点。
       第四，办公类产品需要保证数据安全
       第五，办公类产品本身的功能逻辑
那么怎么才能做好办公类软件的测试呢？
       首先办公软件的核心是办公，日常生活中要用到，那么按照各种排版格式自己去排版就好了，在这个过程中详细得出一些结论：第一可操作性；第二，各个模块的使用逻辑，例如：在文件中插入对象，对象能否体现出来，设置对象的绕排方式，能否设置成功，能否体现，设置对象是否打印；第三，存盘，数据安全考虑，看存盘后对象是否保存，各种字体设置是否保存，绕排方式是否保存等。第四，兼容性，因为用户使用的办公类软件很多，需要文件共享兼容。其次是本身高低版本的兼容性，需要着重考虑。第五，文件大小和不同文件格式的存盘信息。第六，各种性能指标，包括启动速度，占用磁盘大小，在使用的过程中CPU的占有情况；第七，快捷键的设定和检查，不要和系统的快捷键冲突，并且支持系统的各种设置支持系统剪贴板功能；第八，支持网络传输，能够自由的通讯和共享，能够支持协同工作，能够充分体现修改数据的同步信息。
      杀毒类产品测试       杀毒类软件是一种工具类软件，随着网络的普及，杀毒软件也越发显得重要，那么杀毒软件的测试重点是：
       能够发现病毒
       操作系统检查
       能够正确的报告并且查杀病毒
       占有的CPU占有情况
       查杀病毒的内存使用情况  
       数据安全
       软件冲突
       病毒库升级
       自动更新      
那么在杀毒软件的时候，还有一个重要的东西，就是用户的数据安全，当杀毒软件能够清除含毒文件中的毒的时候，一定要包含用户文件的可靠性。
ERP软件的测试方法验证测试测试管理工作       我没有读过管理方面，只是看了一些书而已，在几个团队中应用，效果还可以，所以拿出来和大家交流。
       其实无论是开发管理和测试管理，其核心应该是“理”，如果理都不通，那么管只能是强制性质，那么在软件行业，创造性的企业中，可能不能维持的很久，所以需要先“理”清楚了，然后我们来管，到那个时候也就不用管了，因为理顺了，所以大家都知道该怎么样做，什么时候做了。
       那么谈到“理”，我们需要理什么呢？理事情，把要做的事情理清楚；理目标，把要达到的目的说清楚；理思路，把做事情的思路和方法理清楚；理资源，把合理的资源调配到合适的位置上，让兴趣和能力结合。我觉得从大的方面就需要先将这些事情理清楚了，才可能使得一个团队具有非常的战斗力。
       其次，还需要和善的沟通，做到无所不晓，因为在一个团队中，气氛非常重要，也许一个人的今天心情不好，造成跟他配合的几个人都无法工作顺心，也许是感应。所以需要和大家开诚布公，把能讲的问题，能讲的事情讲清楚，让大家觉得你可以依靠，可以把心思告诉你，你尽力为大家解决后患问题，让他们能够开心踏实的做事情。
       另外，需要换位思考，充分让大家提出意见，因为如果一个团队要发展，是需要大家一起努力的，这是大家都熟知的道理，但是做起来很难。避免一言堂，让大家充分参与到设计中，在其中找到自我的感觉，找到这里没有他是不可以的，这样每一个人才能关心项目的每一个角落，而不是为了工作而工作了。
       其二，需要在“理”的基础上帮助大家总结，大家在什么地方容易犯错误，犯什么类型的错误，犯错误的原因是由于我们的思想老化了，需要改进做事情的方式，还是由于工作能力或者经验的问题。那么就需要对各种错误进行统计，以找到问题的根本原因。就问题而讨论问题，问题的实质出在那里，然后帮大家改进，自己同时也会进步。 给大家讲我现实中的例子吧，我曾经带的一个测试组，大家做事情都很卖力，而且成绩也非常显著，但是在做的过程中总是会有问题发生，问题到底出在那里呢？后来找到了原因，就是由于工作环节中出现问题了，所以他总是在那里犯错误，因为他是把工作当成工作来做了，所以他就改这个地方，我后来找到他，也找到了问题的原因，一起把问题解决了。后来我就告诉他们，如果谁在同一个地方犯同样的错误，我们的结论是他不懂，教他，共同学习，直到他告诉我可以了；如果第二次犯错误，那么我们给的结果是，他忘记了，好再学，直到他告诉我，他可以了；第三次犯同样的错误，我们给的结论是故意犯错误的，那么就要全组请喝可乐一灌。
       这个例子在现实生活中很多，主要是引导，因为如果把工作当成工作来作，可能不会用“心”，因为如果是用“心”工作他会找窍门，会找方法，否则他会厌烦；如果把工作当成自己未来的事业来做，那么就会用心工作，这样就需要我们正确的引导。
开发方面
      开发分析       因为我们是第一次做MP3的产品，所以从技术上还处于摸索阶段，第二我们对产品的质量意识还存在一点问题，第三，四方沟通或者说回馈不够.
问题分析目前存在的问题进度问题       四方配合问题，因为在任何一家公司做嵌入式软件的企业，存在硬件、软件开发，市场开发，测试准备四个方面的组织需要开展工作，所以那个组织的进度耽误都会严重影响产品的发布周期，在现在竞争日益剧烈的市场中，必须把握市场机会，所以需要对进度进行把握。
       建议采用作战图的形式，对各个阶段点进行有利的把握，以给各个方面赢取更多的时间，明确职责范围，则权利的有利结合，激发各个方面的积极性。采用利益共同体的原则，将各个方面合理的结合，让开发关心测试工作，让测试关心开发工作，这样形成一个有利的整体，让市场及时反馈信息，使得项目顺利进展。
沟通问题       SPEC设计完成后，各个方面在限定的时间内做出反馈，以及时跟进，以便对产品有个明确的定位，各个方面对方案认可后，切实执行，如果出现技术问题，及时通知有关人士，以便进度和方案进行合理的修改和微调。在产品开发阶段，需要及时的总结可能遇到的问题和对问题的解决方案，通知相关人士，使得项目组的人有一种归宿感觉。
       开发需要给每个Bug做出合理的解释，或者对我们的测试人员进行相关培训，以便测试人员能够深切的理解产品，能够对产品进行合理严格的测试。
       这里提出一个建议,在测试人员提出Bug以后,知道表现,一定要弄清楚问题发生在那里,是什么导致这个Bug发生,才能有效的分析结构,有效的进行案例的补偿和测试.
跟踪问题       跟踪问题牵扯到Bug的跟踪和进度跟踪，Bug的跟踪需要一套流程，及时的出来Bug,使得发现Bug和解决问题形成一个完整的流程。
       进度跟踪的方法，建议采用阶段点产品，定义明确的时间点，明确各个时间点上完成的功能点，保证产品可以编译，可以抽查，可以运行以完成的相关功能。这样使得大家在各个时期能够看到大家都在进步，产品在进步，有利于整个团队的士气。
版本控制问题       定制严格的产品发布流程，降低由于时间问题，压缩测试时间，给产品发布带来的风险。建议采用的方法，由项目组定制编译计划，然后有相关人士进行讨论，各个方面达成共识之后，坚决执行。
       版本控制和进度控制密切相关。
       进行严格的代码管理，以保证公司机密资料，在代码Check in 和Check Out的时候建议由专人进行审核后方能入库，以免误操作或者敌意的操作造成代码冲刷。控制版本有几个好处和优点。
       关于Bug的回馈优点
第一、  开发方面回馈速度快
第二、  解决速度快
关于测试情况的总结
第一、  涵盖情况
第二、  Bug的质量问题
开发体系问题
第一、  设计的分析做吗？技术难度？设计的合理行，进度的可行性？
第二、  单元测试做了吗？
第三、  CVS的Check In控制了吗？
第四、  进度风险预估了吗？
第五、  进度控制如何进行的？

产品方面：
       产品分析：整个产品在开发前期，市场已经找到了市场切入点，但是在现在产品要发布了，我们不能或者说很难用一系列的数据做说明，告诉高层这个产品可以发布了或者说不能发布，因为分析的数据太少了。因为数据是说明问题的基础，但是现在定了产品发布的标准，只是一个现存数据，没有预估分析可能性，对产品投入市场可能存在风险。
       建议：
第一、  案例执行率
第二、  案例发现bug率
第三、  重复bug率
第四、  KLOC
第五、  产品日测试汇总图（察看历史曲线）

对产品研发整体改进思路

第一步、增强开发质量意识       做法：这个是个长远任务，但是我们可以做具体的事情，例如：检查开发单元测试情况或者单元测试代码等活动
       对设计的模块案例检查回馈情况，把质量和开发邦定，不要让测试单独承担这个压力。
活动方式：宣讲，制度，执行，邦定
第二步、增强测试本身素质       做法：因为测试不成型，这是现状，所以我们通过提供一些数据来提高案例设计的能力或者说告诉测试人员我们的缺陷在那里。这个是长远的事情，因为需要人力去做这个事情。提供如下数据：重复报告率，案例和Bug的比率等。加强程序概念的培训或者框架的了解，尽力从程序的概念上理解产品，尽量避免例冗余。
活动方式：培训，数据，比较
第三步、对产品开发过程中版本编译的控制       做法：CVS库权限控制，所有的Check in和Check out需要控制，检查代码后方可入库。另外需要制订完整的开发计划和编译计划，使得项目跟踪超向正规。
活动方式：专人控制，以面冲掉原来的代码
第四步、进度控制做法：在产品开发周期中定制完整的编译计划，对阶段性产品进行测试或者抽查。以保后期测试时间的争取和质量的保证。
活动方式：认可，执行，调整
第五步、控制进度问题       做法：明确开发模式，列举详细的开发进度，详细提出开发的功能情况，树立作战详细进度表或者叫作战牌，以鼓舞士气，让每个参与者了解进度
活动方式：承诺，监督，跟踪
16   做法：统一平台，统一流程，统一做事方式，实现任务单跟踪
活动方式：准则，平台，优化。