单片机（mcu）软件测试
在MCU上,常用的测试步骤如下:
1>架构平行移植(跨平台).重建.修复后的,架构测试.
2>专用硬件测试程序的,硬件测试.
3>模块移植.修复.虚拟.填充后的,模块测试.(包括的内容最多,最啰唆)
4>数据结构重建后的,动静态数据测试.(工业级编程,最繁杂的过程)
5>程序结构完成后的,软时序测试.(主要测试软件实时性,包括各模块之间的协调性及资源冲突,
工业级编程的重点)
6>程序及系统稳定性测试.(最残酷的环境模拟测试包括EMC.EMI)
7>软件整体性能评估.
8>软硬件配合性能评估.
9>a版本完成后的,整体功能测试.
10>客户意见.
不太详细,感觉一下说不完,这是一个很大的话题,跟项目开发过程关系密切.
各级测试工作并非一次性完成,重复性大,3.4.5是编滩馐灾氐?第6项是工程测试重点.具体测试
方法,请参阅软件工程的测试方法.
分功能性测试和可靠性测试！ 

测试前先做软件结构的评估！
测试时，分功能性测试和可靠性测试！
我们还做代码冗余度测试！要求代码尽量简练！
PC上那一套不适合MCU，那个好象没有EMC/EMI的测试把！
这才是MCU测试的精华所在！
正在考虑如何实现软件功能的自动测试 

初步想法: 在软件内部嵌入测试模块,PC通过串口输入测试命令.测试模块将其转换成相应的输
入: 如键盘输入,串口输入,信号输入等,以此驱动程序运转.同时监测程序的反应(即输出): 显
示,打印,控制等. 并发送结果给PC.在PC软件上,根据待测设备实际运行情况,预先设置好测试序
列,并设置运行正常时的输出.这样,即可由PC自动判定测试结果.
  
设想情形下,随着程序的开发进程,测试序列也不断增长,直至可以完成全部功能的自动测试.这样,
即使程序重构多次,或者多次修改,也可以随时测试,不必耗费大量的人工和时间.

同样思路,也可以实现单元测试.
PC上那一套……，那个好象缺EMC/EMI的测试
EMC/EMI的测试是硬件测试
程序的测试，是个好话题 

我的观点；不属于所长的大型MCU程序范围

对于大部分的MCU系统来说，最终给用户提供的不是软件本身，而是一个实物化的产品。
纯粹的软件测试大概应属于软件工程的领域，而对于MCU应用系统来说，应该是介于软件行业和电
子行业之间的东西。实际上，MCU应用系统都表现为一种电子产品的形式。它最终可能都归到电子
类行业标准的认证和测试上。和纯粹的软件行业的软件测试差别可能很大。

但是就MCU程序本身的测试，我认为基本上就是以功能测试为主，应该属于黑盒测试吧。
至于程序内部结构等方面的测试，可能没有太大必要，估计很多电子企业也没有这样做。 


程序内部测试，让程序在内部自己测试，然后加上对测试程序的控制
是不是可以说“自适应”阿 
关系程序测试，我想是不是该先分类一下。 

我公司对程序的测试过程，基本：

1.外部环境模拟测试，这主要对产品而言，与程序相关很小，就不提。

2.从产品的角度来说，通常是请非程序设计人员进行重复功能测试，找到设计中的缺陷。因为从概率的角度出发，所以比较贴近用户使用的过程。对程序来说，差不多是最后的程序测试关口了。

3.在进行到产品测试前，一般都要内测，也叫功能测试。由自己或专业的测试人员进行，这时候是大量BUG出现的时候。

4.自测。主要对程序结构的测试，重大的结构问题基本集中在这时候解决。

对1,2,3，这是大家都熟悉的，一般公司都会安排。所以，俺想最集中要解决的是4，怎么去自测才规范。

以前听过深圳旋极公司关于程序测试的一些课程，可惜都是针对PC上的大型软件。他们卖专门用来测试的软件，按照一系列的测试标准和手段，把响应程序嵌入到程序中，最后根据结果和一些相关算法理论得出分析结果。不知MCU上如何使测试标准化一些？用什么手段去测试？

关于EMC,及外部环境测试 

这两个测试正是包含在我讲的第6点中,其实我讲的测试方法也只是个人的工作习惯所穿叉顺带的
 
测试步聚.
具体实现方法每个人实现的差异是很大的.
我把编程测试工作(自测或内测)放在编程过程中来做,主要的目的是有一个保证程序随时可用的原则.
这里只是讲程序的测试问题 
其实程序中还有一道测试程序,那就是生产测试程序.在生产流程中QC环节,主要用来自动测试硬件的全部功能,判断PCB.元器件.生产工艺对本板卡造成的不良影响,功能实现是否完美.还要对产品老化度身定制.
你讲的我们叫智能测试架.就是为了取代价格昂贵的ICT.
第4.5点,对于程序员是非常重要的,这里就要涉及到手段问题,这正是软件测试工作的精华所在,每个经验丰富的人都有自己总结的方法,不知道有没有人肯拿出来交流?不要只等着收麦子,好不好呢?
看来对于测试工作没几个重视的,所长能看清第4点的重要性,已属难能可贵.正是因为程序结构的要求.测试的复杂度及工业级编程等综合因素,我花了多年时间,把MCU上使用的数据形态(权且这样称呼),总结成MCU特定的数据结构的原因,跟.NET中的封装有些类似.这种MCU的特定的数据结构跟程序结构及算法实现关系更大.所以我为什么说数据结构比程序结构更加精妙,希望能够理解.
主要是考虑到既然可以在PC上实现自动测试,那么在MCU上也可以.只是实现方法有所不同而已.而对于底层驱动的测试和硬件的测试(QC)不在我讲的范围.
第四条 对程序员来说是个关键 

4.自测。主要对程序结构的测试，重大的结构问题基本集中在这时候解决。
自测可能更多的是对程序员的自侓要求
自测阶段，最好有个标准和规范。在外部监督下实行，不然靠程序员的自侓，好象太那个点 
MCU才是个人主义放飞的地方.
只会编程,不会测试永远成不了大器.
使用了消息驱动，所以测试模块很方便的。 

关于测试，可以
1.单独编写一个小程序，在特定时间间隔中产生突发的大量等待，检测系统程度对突发事件的容忍程度。
2.使用消息结构，基本上可以不用钩子函数来检测内部特性。完全可以在不影响程序结构的条件下，按照设定的测试时间和顺序用消息向任务模块发送消息，来控制程序实现相应功能。
3.在俺的结构中，检测每个模块的使用率是很方便的。可以通过串口，将模块的使用情况上传到PC上进行分析和统计。
钩子,就是一个动态的消息驱动加数据捕捉
可以在PC上看到所有的RAM,可以改变所有的RAM,及各控制寄存器,可以模拟消息驱动,观察模块的实时动作.分析程序中有各种算法,可以跟踪分析RAM的实时变化.加上外部环境变量的配合(智能测试架可动态模拟各种环境变化,同一PC软件驱动),软件测试工作就变得精确和有效.
钩子,并不需要是串行口,可以是sio,spi,按键,或可以空闲激活的所有口线.
当然有串口可用是最好不过的了.
钩子函数,本身就是程序的一部分,并不会影响程序的结构.在重建程序架构之初,钩子就做为一个
任务,被内嵌和定义了.钩子也可以自己发布消息,但太死板.
我最近,正想用ARM7重新设计一个智能海量测试分析系统,用以应付日益复杂的测试及各种内部.
外部动态数据分析工作.