嵌入式软件测试的十大秘诀
HOME 登录┆注册┆搜索┆
帮助
embeddedsoft 的BLOG 活力地带
个人首页 给我留言 我的文章 我的相册 控制面板 我的文章分类■我的所有文章■embedded c ■embedded OS ■embedded app ■embedded English ■embedded hardware ■embedded project management ■colorful life of golden ages ■sooin literals 最近更新的BLOG 列表■祝福的BLOG ■XHP 的会客厅 ■畅索的BLOG ■不烟不酒BLOG ■小楼一夜听春雨 ■幻想无烟的心情家园 ■秋风拂苇的BLOG ■
艾雪晗烟的BLOG 发表文章
嵌入式软件测试的十大秘诀
2006-09-06 00:25:04
大 中 小
在嵌入式软件开发过程中，一般来说，花在测试和花在编码的时间比为3:1(实际上可能更多)。这个比例随着你的编程和测试水平的提高而不断下降，但不论怎样，软件测试对一般人来讲很重要。很多年前，一位开发人员为了对嵌入式
有更深层次的理解，向Oracle 询问了这样的一个问题:我怎么才能知道并懂得我的
系统到底在干些什么呢? Oracle 面对这个问题有些吃惊，因为在当时没有人这么问过，而同时代的嵌入式开发人员问的最多的大都围绕“我怎么才能使程序跑的更快”、“什么编译器最好”等肤浅的问题。所以，面对这个不同寻常却异乎成熟的问题，Oracle 感到欣喜并认真回复了他:你的问题很有深度很成熟，因为只有
不断地去深入理解才有可能不断地提高水平。并且Oracle 为了鼓励这位执着的程
序员，把１０条关于嵌入式软件开发测试的秘诀告诉了他:
1.懂得使用工具
2.尽早发现内存问题
3.深入理解代码优化
4.不要让自己大海捞针
5.重现并隔离问题
6.以退为进
7.确定测试的完整性
8.提高代码质量意味着节省时间
9.发现它，分析它，解决它
10.利用初学者的思维
这十条秘诀在业界广为流传，使很多人受益。本文围绕这十条秘诀展开论述。
１.懂得使用工具
通常嵌入式系统对可靠性的要求比较高。嵌入式系统安全性的失效可能会导
致灾难性的后果，即使是非安全性系统，由于大批量生产也会导致严重的经济损
失。这就要求对嵌入式系统，包括嵌入式软件进行严格的测试、确认和验证。随
着越来越多的领域使用软件和微处理器控制各种嵌入式设备，对门益复杂的嵌入
式软件进行快速有效的测试愈加显得重要。
■一四九一八○九一一一
■圆圆的月亮在地上 就象修车需要工具一样，好的程序员应该能够熟练运用各种软件工具。不同
的工具，有不同的使用范围，有不同的功能。使用这些工具，你可以看到你的系
统在干些什么，它又占用什么资源，它到底和哪些外界的东西打交道。让你郁闷
好几天的问题可能通过某个工具就能轻松搞定，可惜你就是不知道。那么为什么
那么多的人总是在折腾个半死之后才想到要用测试工具呢？原因很多，主要有两
个。一个是害怕，另一个是惰性。害怕是因为加入测试用具或测试模块到代码需
要技巧同时有可能引入新的错误，所以他们总喜欢寄希望于通过不断地修改重编
译代码来消除bug,结果却无济于事。懒惰是因为他们习惯了使用printf之类的简单
测试手段。下面来介绍一些嵌入式常用的测试工具。
.源码级调试器[Source-level Debugger]
这种调试器一般提供单步或多步调试、断点设置、内存检测、变量查看等功能，
是嵌入式调试最根本有效的调试方法。比如VxWorks TornadoII提供的gdb就属于
这一种。
.简单实用的打印显示工具[printf]
printf或其它类似的打印显示工具估计是最灵活最简单的调试工具。打印代码执行
过程中的各种变量可以让你知道代码执行的情况。但是，printf对正常的代码执行
干扰比较大(一般printf占用CPU比较长的时间)，需要慎重使用，最好设置打印开
关来控制打印。
.ICE或JTAG调试器[In-circuit Emulator]
ICE是用来仿真CPU核心的设备，它可以在不干扰运算器的正常运行情况下，实时
的检测CPU的内部工作情况。像桌面调试软件所提供的：复杂的条件断点、先进
的实时跟踪、性能分析和端口分析这些功能，它也都能提供。ICE一般都有一个
比较特殊的CPU，称为外合(bond-out)CPU。这是一种被打开了封装的CPU，并且
通过特殊的连接，可以访问到CPU的内部信号，而这些信号，在CPU被封装时，
是没法“看到”的。当和工作站上强大的调试软件联合使用时，ICE就能提供你
所能找到的最全面的调试功能。但ICE同样有一些缺点：昂贵；不能全速工作；
同样，并不是所有的CPU都可以作为外合CPU的，从另一个角度说，这些外合CP
U也不大可能及时的被新出的CPU所更换。JTAG(Joint Test Action Group)虽然它最
初开发出来是为了监测IC和电路连接，但是这种串行接口扩展了用途，包括对调
试的支持。AD公司为Blackfin设计的Visual Dsp++就支持高速的JTAG调试。
.ROM监视器[ROM Monitor]
ROM监控器是一小程序，驻留在嵌入系统ROM中，通过串行的或网络的连接和运
行在工作站上的调试软件通信。这是一种便宜的方式，当然也是最低端的技术。
它除了要求一个通信端口和少量的内存空间外，不需要其它任何专门的硬件。并
提供了如下功能：下载代码、运行控制、断点、单步步进、以及观察、修改寄存
器和内存。因为ROM监控器是操作软件的一部分，只有当你的应用程序运行时，
它才会工作。如果你想检查CPU和应用程序的状态，你就必须停下应用程序，再
次进入ROM监控器。
.Data监视器[Data Monitor]
这种监视器在不停止CPU运行的情况下不仅可以显示指定变量内容，还可以收集
并以图形形式显示各个变量的变化过程。
.OS监视器[Operating System Monitor]
操作系统监视器可以显示诸如任务切换、信号量收发、中断等事件。一方面，这些监视器能够为你呈现事件之间的关系和时间联系；另一方面，还可以提供对信号量优先级反转、死锁和中断延时等问题的诊断。
.性能分析工具[Profiler]
可以用来测试CPU到底耗在那里。profiler工具可以让你知道系统的瓶颈在那里、CPU的使用率以及需要优化的地方。
.内存测试工具[Memory Teseter]
可以找到内存使用的问题所在，比如内存泄露、内存碎片、内存崩溃等问题。如果发现系统出现一些不可预知的或间歇性的问题，就应该使用内存测试工具测测看。
.运行跟踪器[Execution Tracer]
可以显示CPU执行了哪些函数、谁在调用、参数是什么、何时调用等情况。这种工具主要用于测试代码逻辑，可以在大量的事件中发现异常的那些。
.覆盖工具[Coverage Tester]
主要显示CPU具体执行了那些代码，并让你知道那些代码分支没有被执行到。这样有助于提高代码质量并消除无用代码。
.GUI测试工具[GUI Tester]
很多嵌入式应用带有某种形式的图形用户界面进行交互，有些系统性能测试足根掘用户输入响应时间进行的。GUI测试工具可以作为脚本工具有开发环境中运行测试用例，其功能包括对操作的记录和回放、抓取屏幕显示供以后分析和比较、设置和管理测试过程(Rational公司的robot和Mercury的Loadrunner工具是杰出的代表)。很多嵌入式设备没有GUI，但常常可以对嵌入式设备进行插装来运行GUI测试脚本，虽然这种方式可能要求对被测代码进行更改，但是节省了功能测试和回归测试的时间。
.自制工具[Home-made tester]
在嵌入式应用中，有时候为了特定的目的，需要自行编写一些工具来达到某种测试目的。本人曾经编写的视频流录显工具在测试视频会议数据流向和变化上帮了大忙,帮公司找到了几个隐藏很深的bug。
２.尽早发现内存问题
内存问题危害很大，不容易排查，主要有三种类型:内存泄露、内存碎片和内存崩溃。对于内存问题态度必须要明确，那就是早发现早“治疗”。在软件设计中，内存泄露的“名气”最大，主要由于不断分配的内存无法及时地被释放，久而久之，系统的内存耗尽。即使细心的编程老手有时后也会遭遇内存泄露问题。有测试过内存泄露的朋友估计都有深刻地体验，那就是内存泄露问题一般隐藏很深，很难通过代码阅读来发现。有些内存泄露甚至可能出现在库当中。有可能这本身是库中的bug，也有可能是因为程序员没有正确理解它们的接口说明文档造成错用。
在很多时候，大多数的内存泄露问题无法探测，但可能表现为随机的故障。程序员们往往会把这种现象怪罪于硬件问题。如果用户对系统稳定性不是很高，那么重启系统问题也不大；但，如果用户对系统稳定很高，那么这种故障就有可能使用户对产品失去信心，同时也意味着你的项目是个失败的项目。由于内存泄
露危害巨大，现在已经有许多工具来解决这个问题。这些工具通过查找没有引用或重复使用的代码块、垃圾内存收集、库跟踪等技术来发现内存泄露的问题。每个工具都有利有弊，不过总的来说，用要比不用好。总之，负责的开发人员应该去测试内存泄露的问题，做到防患于未然。
内存碎片比内存泄露隐藏还要深。随着内存的不断分配并释放，大块内存不断分解为小块内存，从而形成碎片，久而久之，当需要申请大块内存是，有可能就会失败。如果系统内存够大，那么坚持的时间会长一些，但最终还是逃不出分配失败的厄运。在使用动态分配的系统中，内存碎片经常发生。目前，解决这个问题最效的方法就是使用工具通过显示系统中内存的使用情况来发现谁是导致内存碎片的罪魁祸首，然后改进相应的部分。
由于动态内存管理的种种问题，在嵌入式应用中，很多公司干脆就禁用mallo c/free的以绝后患。
内存崩溃是内存使用最严重的结果，主要原因有数组访问越界、写已经释放的内存、指针计算错误、访问堆栈地址越界等等。这种内存崩溃造成系统故障是随机的，而且很难查找，目前提供用于排查的工具也很少。
总之，如果要使用内存管理单元的话，必须要小心，并严格遵守它们的使用规则，比如谁分配谁释放。
３.深入理解代码优化
讲到系统稳定性，人们更多地会想到实时性和速度，因为代码效率对嵌入式系统来说太重要了。知道怎么优化代码是每个嵌入式软件开发人员必须具备的技能。就象女孩子减肥一样，起码知道她哪个地方最需要减，才能去购买减肥药或器材来减掉它。可见，代码优化的前提是找到真正需要优化的地方，然后对症下药，优化相应部分的代码。前面提到的profile(性能分析工具，一些功能齐全IDE 都提供这种内置的工具)能够记录各种情况比如各个任务的CPU占用率、各个任务的优先级是否分配妥当、某个数据被拷贝了多少次、访问磁盘多少次、是否调用了网络收发的程序、测试代码是否已经关闭等等。
但是，profile工具在分析实时系统性能方面还是有不够的地方。一方面，人们使用profile工具往往是在系统出现问题即CPU耗尽之后，而profile工具本身对CP U占用较大，所以profile对这种情况很可能不起作用。根据Heisenberg效应，任何测试手段或多或少都会改变系统运行，这个对profiler同样适用！
总之，提高运行效率的前提是你必须要知道CPU到底干了些什么干的怎么样。
４.不要让自己大海捞针
大海捞针只是对调试的一种生动比喻。
经常听到组里有人对自己正在调试的代码说shit！可以理解，因为代码不是他写的，他有足够的理由去shit bug百出的代码，只要他自己不要写出这种代码，否则有一天同组的其它人可能同样会shit他写的代码。为何会有大海捞针呢？肯定是有人把针掉到海里咯；那针为何会掉在海里呢？肯定是有人不小心或草率呗。所以当你在抱怨针那么难找的时候，你是否想过是你自己草率地丢掉的。同样，当你调试个半死的时候，你是否想过你要好好反省一下当初为了寻求捷径可能没有
严格地遵守好的编码设计规范、没有检测一些假设条件或算法的正确性、没有将一些可能存在问题的代码打上记号呢？关于如何写高质量请参考林锐的《高质量c ++/c编程指南》或《关于C的0x8本“经书”》(https://www.wendangku.net/doc/2f14889602.html,/u/4a317b79010004 mc)。
如果你确实已经把针掉在海里是，为了防止在找到之前刺到自己，你必须要做一些防范工作，比如戴上安全手套。同样，为了尽能地暴露和捕捉问题根源，我们可以设计比较全面的错误跟踪代码。怎么来做呢？尽可能对每个函数调用失败作出处理，尽可能检测每个参数输入输出的有效性包括指针以及检测是否过多或过少地调用某个过程。错误跟踪能够让你知道你大概把针掉在哪个位置。
５.重现并隔离问题
如果你不是把针掉在大海了，而是掉在草堆里，那要好办写。因为至少我们可以把草堆分成很多块，一块一块的找。对于模块独立的大型项目，使用隔离方法往往是对付那些隐藏极深bug的最后方法。如果问题的出现是间歇性的,我们有必要设法去重现它并记录使其重现的整个过程以备在下一次可以利用这些条件去重现问题。如果你确信可以使用记录的那些条件去重现问题，那么我们就可以着手去隔离问题。怎么隔离呢？我们可以用#ifdef把一些可能和问题无关的代码关闭，把系统最小化到仍能够重现问题的地步。如果还是无法定位问题所在，那么有必要打开“工具箱”了。可以试着用ICE或数据监视器去查看某个可疑变量的变化；可以使用跟踪工具获得函数调用的情况包括参数的传递；检查内存是否崩溃以及堆栈溢出的问题。
６.以退为进
猎人为了不使自己在森林里迷路，他常常会在树木上流下一些标记，以备自己将来有一天迷路时可以根据这些标记找到出路。对过去代码的修改进行跟踪记录对将来出现问题之后的调试很有帮助。假如有一天，你最近一次修改的程序跑了很久之后忽然死掉了，那么你这时的第一反映就是我到底改动了些什么呢，因为上次修改之前是好的。那么如何检测这次相对于上次的修改呢？没错，代码控制系统SCS或称版本控制系统VCS(Concurrent Version Control,CVS是VCS的演化版本)。将上个版本check in下来后和当前测试版本比较。比较的工具可以是SCS/VC S/CVS自带的diff工具或其它功能更强的比较工具，比如BeyondCompare和ExamDi ff。通过比较，记录所有改动的代码，分析所有可能导致问题的可疑代码。
７.确定测试的完整性
你怎么知道你的测试有多全面呢？覆盖测试(coverage testing)可以回答这个问题。覆盖测试工具可以告诉你CPU到底执行了那些代码。好的覆盖工具通常可以告诉你大概20%到40%代码没有问题，而其余的可能存在bug。覆盖工具有不同的测试级别，用户可以根据自己的需要选择某个级别。即使你很确信你的单元测试已经很全面并且没有dead code,覆盖工具还是可以为你指出一些潜在的问题，看下面的代码:
if (i >= 0 && (almostAlwaysZero == 0 || (last = i)))
如果almostAlwaysZero为非０,那么last=i赋值语句就被跳过，这可能不是你所期望
的。这种问题通过覆盖工具的条件测试功能可以轻松的被发现。
总之，覆盖测试对于提高代码质量很有帮助。
８.提高代码质量意味着节省时间
有研究表明软件开发的时间超过80%被用在下面几个方面:
.调试自己的代码(单元测试)
.调试自己和其他相关的代码(模块间测试)
.调试整个系统(系统测试)
更糟糕的是你可能需要花费10-200倍的时间来找一个bug,而这个bug在开始的时候
可能很容易就能找到。一个小bug可能让你付出巨大的代价，即使这个bug对整个
系统的性能没有太大的影响，但很可能会影响让那些你可以看得到的部分。所以
我们必须要养成良好的编码和测试手段以求更高的代码质量，以便缩短调试的代码。
９.发现它，分析它，解决它
这世界没有万能的膏药。profile再强大也有力不从心的时候；内存监视器再好，也有无法发现的时候；覆盖工具再好用，也有不能覆盖的地方。一些隐藏很
深的问题即使用尽所有工具也有可能无法查到其根源，这时我们能做的就是通过
这些问题所表现出来的外在现象或一些数据输出来发现其中的规律或异常。一旦
发现任何异常，一定要深入地理解并回溯其根源，直到解决为止。
１０.利用初学者的思维
有人这样说过：“有些事情在初学者的脑子里可能有各种各样的情况，可在
专家的头脑里可能就很单一”。有时候，有些简单的问题会被想的很复杂，有些
简单的系统别设计的很复杂，就是由于你的“专家思维”。当你被问题难住时，
关掉电脑，出去走走，把你的问题和你的朋友甚至你的小狗说说，或许他们可以
给你意想不到的启发。
总结:嵌入式调试也是一门艺术。就想其它的艺术一样，如果你想取得成功，你必须
具备智慧、经验并懂得使用工具。只要我们能够很好地领悟Oracle这十条秘诀，我相
信我们在嵌入式测试方面就能够取得成功。
评论(12)┆引用┆阅读(621)┆打印文章评论
以下网友留言只代表其个人观点，不代表新浪网的观点或立场
[匿名] 小馒头
2006-09-06 11:43:29
一直比较关注你的文章．版本控制有时候确实很有用．
[匿名] 游客
2006-09-07 13:29:13
熟练使用工具是人区分于动物的一大特点，也是高水平程序员区别于普通程序员的一大特
点
[匿名] Cer
2006-09-07 14:34:43文章中许多比喻很生动，嵌入式软件测试是一门很高深的学问。有时候自己为了赶时间，
写代码时对重量的要求就不再象往常那么高，结果后来花很长的时间去调试，有时候郁闷
很久最终找出的bug简直可以说无知。
[匿名] 铁了心
2006-09-07 14:38:02很多工具确实很有用，遗憾的是很少有可以实践的机会。
公司小了没办法啊。
[匿名] embeddeds
2006-09-07 16:16:44在嵌入式系统使用内存管理单元的几点建议:
1.尽量少用，而不是禁用；
2.能用静态的就不要使用动态的；
3.如果静态内存的使用超出了ROM/FALSH的大小，建议
使用动态分配一大块内存(动态内存分配在堆heap中，一般在RAM/SDRAM上,不站用ROM
内存)，然后当静态使用．
[匿名] embeddeds
2006-09-07 16:43:20
根据Heisenberg效应，任何测试手段或多或少都会改变系统运行，所以你在使用工具或自行
在代码中加入测试程序时必须要：
1.严格书写测试代码
测试代码也需要严格对待，测试代码本身也需要按编码规范书写，否则你很可能会把大量
时间花在排除测试代码本身的错误上，这是不应该的。
2.尽量书写独立的块代码(independent block code),尽量减少对原有模块的干扰，比如尽量使
用#ifdef来启闭调式代码
void module_func()
{
unsigned char* ptr;
...
#ifdef __INDEPENDENT_BLOCK_CODE
{
unsigned int var1;
static int var2;
...
}
#endif
}
这方面可以参考
Writing Clean Code-----Microsoft Techiniques
for Developing Bug-free C Programs
《编程精粹--Microsoft 编写优质无错Ｃ程序秘诀》
3.尽量减少全局变量的使用，除了开关之外
使用全局变量会引入许多潜在的问题，所以尽量少用，
而且调试代码中使用全局变量会增加对原有代码的干扰，因为
测试代码与原有代码的耦合增加。一个例外就是，测试代码的全局开关变量，因为它们是
不可避免的，但也要尽量少用。
比如：
unsigned int g_var;
void module_func()
{
unsigned char* ptr;
...
#ifdef __INDEPENDENT_BLOCK_CODE
{
unsigned int var1;
static int var2;
if(g_nVar>0 && g_nVar-->0)
{/*打印g_nVar次var1和var2*/
printf("var1 %d,var2 %d\n",var1,var2);
}
...
}
#endif
}
3.
[匿名] embeddeds
2006-09-07 23:32:43开发人员间的效率差在哪里？[转博友]
熟练人员经过多年的积累加上自己的CodeSnip的总结，基本不用额外再查找资料。而一般
的开发人员在开发过程中会花掉10-20%时间去查找资料。
熟练人员注意代码复用，并且时刻注意重构和抽取公用代码。一般开发人员是代码拷来拷
去完成功能。
熟练人员非常注意查找，定位，标签等各种快捷键的使用，定位查找方便快捷，IDE环境也
根据习惯定义到最方便状态。
熟练人员编码前先思考清楚整个流程，在头脑或纸张上规划好整个实现方式和方法函数的
划分。一般人员想到哪里写到哪里。
熟练人员写了50行以上或更多代码才Debug一两次，一般人员写了几行代码就要Debug多
次，完全通过Debug来验证代码正确性。
熟练人员注重代码的质量，单元测试和可维护性，注重各种业务逻辑的验证和边界条件的
校验。一般人员只注重简单功能的简单完成。
熟练人员提交测试的代码BUG很少，返工工作量很小。一般开发人员由于自测不完善BUG
较多，造成大量的返工工作量。
熟练人员合理分配自己的时间，规划好每天工作任务，开发过程各位专注。一般开发人员
一心多用，边开发边聊Q。
熟练人员善于知识的总结和积累，形成自我的知识库和经验库。
熟练人员善于发现问题，分析不足而自我持续改进。一般人员在外力干预侠被动改进。
熟练开发人员开发重点已经专业到对业务的深刻理解，一般开发人员考虑的是开发上编程
的语言和工具。
熟练人员善于从各种影响自己开发效率的因素中挤时间，善于使用各种辅助开发工具。而
一般人员则不善于这种总结。
[匿名] 心血来潮
2006-09-08 09:33:53博主用心了．不过发现它，分析它，解决它没有实质内容，如果能举个例子就更好了
[匿名] embeddeds
2006-09-08 22:01:53嵌入式软件的基本测试方法[来自网络]
随着制造行业的再一次崛起，嵌入式软件目前在软件行业中越来越多，2004年软件行业最
火爆的三个项目是：嵌入式开发，软件培训以及软件外包。由于嵌入式软件与其他产品息
息相关，这给嵌入式软件的测试工作带来了极大的困难，软件的测试工作不能够等程序烧
到或者固化到芯片中才开始进行测试，这就太晚了，本文结合自己的一些经验提出自己的
看法，希望大家一起讨论。
１．搞好开发前的原型设计
原型开发目前在开放流程中受到了更多的重视，同样嵌入式软件也是非常需要的。比如说
一个录音机版面的设计，可以定义好版面上面的按键以及每个按键的功能。然后画出状态
转化图，写清楚每个按键何时可以触发，触发后由哪个状态转入别的其他状态。原型设计
好了，组织专家，工程师进行评审，尽可能多的找出原型中不合理需要改进的地方；改进
以后，有必要可以进行再一次的评审工作。每一次评审工作需要记录评审建议是否需要解
决？如何解决以及实际解决情况。
２．进行设计和开发工作
设计和开发工作需要设立里程碑。每个里程碑结束前都需要进行评审工作。由于嵌入式软
件的运行环境不同，受到很大的限制，所以在进行开发之前需要进行编程规范工作，编码
的时候需要严格按照编码要求进行工作，每一个条款都需要认真执行和审查。现在业界提
供许多关于嵌入式软件开发的标准，大家可以通过网站搜索，最好能够购买业界一些比较
著名的标准。目前市场上也提供许多关于代码检验的工具。为什么一直提出代码编码规
范？这是因为嵌入式软件的质量与代码规范是十分重要的。举个例子，著名的阿里亚火箭
失事，专家进行详细的调查工作，最后发现问题出在代码上。代码是符合标准C语言的，
但是在运行过程中由于程序员将一个长整形变量赋给了一个短整形变量，造成内存溢出，
这是导致火箭失事的关键所在。
（
int8 a;
int32 b;
…
a=b;
）
代码测试
当程序开发完毕，需要进行测试工作，但是在程序烧入或固化芯片之前如何进行测试呢？
这里介绍一种方法：比如程序时使用C语言进行开发的，请将所有的操作都封入在函数
中，函数的定义都在相应的头文件中定义(.h),然后设计测试用例，书写测试代码，测试代码
包含相应头文件，可以对函数进行检测。测试案例往往分为两类：一种是功能测试，主要
测试函数的功能；另外一种是错误参数测试，主要检查程序对进行错误参数进行检验。 ３．功能测试
这种测试的运行往往需要通过仿真器辅助完成，比如类似录音机软件程序，分别测试播
放，加大（减小）音量，停止，暂停（取消暂停），快速前进，快速后退，录音对应的功
能是否能够正常运行。
错误测试
主要测试函数在调用参数无效的时候，系统是否会按照规定返回正确的错误代码。比如function test(int Tid)
测试的时候给出一个错误的序列号(Tid),看程序是否返回正确的错误代码。
对于函数function test1(int t)需要进行特出的处理
t 定义为1-100
我们可以按照边界值法和等价分类法进行测试
上边界:-1,0,1
下边界：99，100，101
中边界：50
所以测试用例集合为（-1,0,1,50,99,100,101）,其中-1，101为错误测试用例，其他为正确测
试用例
４．功能组合测试
在进行完功能测试后，我们可以进行功能组和测试，还是拿录音机程序做个例子。我们可
以定义将音量增加到10，快速前进，检查音量，看是否还是为10；播放，暂停，试图调整
音量，检查调整音量的功能是否可以被成功执行。
５．烧入固化测试
当以上测试都通过后可以将程序烧入芯片或者固化，进行最后在实际环境中进行测试工
作。
[匿名] embeddeds
2006-09-08 22:33:40关于嵌入式系统的自动化测试工具的几点看法[来自网络]
在过去二年半里，我主要从事收款机的测试工作，由刚入门的手工测试，到对自动化
测试的需求中，我曾经尝试过寻找好的测试工具，但是，后来，由于各种原因，我还是将
眼光投向我们的开发人员身上。
在收款机的测试中，除基本功能测试外，最重要的就是PLU链和电子日子链，这两大
块的测试，而针对这两条链他们有很多关联之处，也存在一个问题，就是压力测试，如何
让自己轻松的实现对这两条链的测试呢？
刚开始，我们测试组想到了用设置条码的自动销售模式来进行，后来，觉得这样还不
够，我们又想到让开发人员为我们做一个自动销售软件，只是一个小小的软件，就解脱了
我们手中的重复工作，而且，也实现了这两条链的压力测试，测出了许多致命问题，让我
们的产品在数据保存方面更加可靠！
但是，后来，我们觉得回归测试也是一个非常重要的测试，因为，我们知道，当bug A
解决之后，会由于开发者修改问题而导致另一个bug，或者更多bug，如何在有限的测试时
间里，用最短的时间完成回归测试，又成了我心里的一个问题。在开发部经理的帮助下，
我们又一次实现的整个收款机的自动化回归测试，保证最基本的正常功能测试。
现在，离开了原来的公司，但心里依然还有许多东西放不下，在对自动化测试的一般
了解下，我知道用自创的自动化测试工具来测试本公司的产品，也会隐藏着某些危机，我
甚至在想，如何看待嵌入式系统的自动化测试工具？
我个人觉得，嵌入式系统的自动化测试工具，应该做得比较小，主要针对某个重要模
块进行测试，因为只有小的软件，它所存在的bug才不会影响到测试的可靠性。
但是，在关于回归测试这一方面，我始终有种莫名的担忧，有些东西一直想不明白，
在规定统一的数据库中对系统进行自动化回归测试，会不会因为在编写例子欠缺而出现遗
漏，在进行完回归测试后，我们还应该注意些什
-----------------------------------------------
嵌入式软件多数要完全回归测试
由于程序的复杂性，各个模块及元素（变量、函数、类）之间存在着相互关联性，所
以对于改正的错误，还要进行再测试。一方面检查此错误是否真的修改了，另一方面检查
此错误的修改是否引入新的错误，这就需要将测过的测试用例拿来重新进行测试，这就是
回归测试。
回归测试可以应用于软件测试和软件维护阶段，用来验证错误修改情况，这称为改错性回
归测试；同时在软件的增量式开发过程中，通过重测已有的测试用例和设计新的测试用
例，来测试改动（增加或删除）的程序，这称为增量性回归测试。
回归测试在重用已有的测试用例时，有两种方案：一是完全回归测试；另一种方法是选择
性回归测试。采用选择性的方法，会大大减少时间和人员的开销，同时又能保证系统的质
量。其中Rothermel的选择性回归测试方法总结的最具代表性，可查询相关专著
[匿名] embeddeds
2006-09-08 23:06:07偶然性不可重现BUG怎么处理？[来自网络]
一、一定要提交！！
1． 记得有这么个缺陷，以后再遇到的时候可能就会了解发生的原因。
2． 尽力去查找出错的原因，比如有什么特别的操作，或者一些操作环境等。
3． 程序员对程序比测试人员熟悉的多，也许你提交了，即使无法重新，程序员也会了解问题所在。
4． 无法重现的问题再次出现后，可以直接叫程序员来看看问题。
5． 对于测试人员来说，没有操作错误这条.既然遇到，就是问题。即使真的操作错了，也要推到程序员那里，既然测试人员犯错误，用户也可能会犯同样的错误。错误发生的时候，Tester最大。
二、程序不是测试人员写的，出问题也不是测试人员的原因。
至于无法重现，可能的原因很多，因为测试人员看到的只是程序的外部，无法深入程序内部，所以把责任推给测试人员是不对的。
测试人员的任务只是尽力重现问题，而不是必须重现！！
三、下次再遇到的时候，拉他们来看就可以了。
因为问题如果无论如何无法重现，程序员确实也没有什么好的解决方法。
而且此类问题即使程序员说修改了，测试员也没有好的方法去验证是不是。 : )
四、你可以告诉程序员，测试过程是没有错误的。
测试人员只是检查程序中可能存在的问题，虽然测试人员使用一定的手段方法努力去覆盖所有的情况，但这些都是理论的推测。在实际中，可能因为人员、环境、配置等种种原因出现各种各样的问题，在测试人员这里发现问题是公司内部的事情，程序发到外面可就是公司的形象问题了。
需要让程序员理解，测试人员是帮助他们的，不是害他们的。
客户那里发现问题比测试员发现问题结果要严重的多。
五、测试部门是独立与开发部门的呀，真的打交道，也是经理对经理。
在我们这里，工作上面的事情，和程序员相互只能商议解决，并没有谁高谁低。
问题无法重现，也要提出，程序员那里可以回复无法再现。问题放在那里，等到再次出现的时候，就立刻叫程序员过来查看。
实在没有再次出现，最后可以写到报告中，说出现了什么现象，但无法再现（比较严重的问题才如此处理，小问题经理之间商量商量可能就算了）。
至于测试人员必须重现bug，你杀了我好了，我每次测试项目都有无法重现的问题，很多我能找到大概的原因，有些根本无法重现（仅仅出现一次）。
这种事情是无法避免的，并不能说测试人员无法重现问题，就是工作不到位（哼，程序有b ug，是否可以说程序员工作不到位的呀）。
六、测试部门要独立，最好不受开发的制约。其实真正要重视，就应该有否决的权利。
我们公司就是项目承包，要拿最后的项目尾款，就要测试部签字通过，这样就避免了很多的问题。
其实只要自己尽到心就可以了，管别人怎么说呢。
七、我们使用的状态有：
程序员处理的状态（由测试员提交的Action）：等待处理的，再次出现的。
测试员处理的状态（由程序员提交的Action）：已经修改的，暂不修改的，系统限制的，使用错误的，无法再现的。测试员可以修改记录。
经理处理的状态（由测试员提交Action）：管理员处理的。经理还可以删除记录。
按照比较标准的说法，其实对于缺陷还应该有“等待确认的”、“已经确认的”和“重复提交的”的状态，我们为了省事，统一使用了“等待处理的”。
最后结项的时候，缺陷的状态对我们来说有两种，“已经关闭的”（由测试员或经理确认）和“暂不修改的”（比如下一个版本处理等）。
呵呵，状态多，有些烦琐，特别是程序员很多的时候都不清楚应该回复什么状态，但我个人觉得对测试人员来说，这些状态比较清晰明了，容易处理。
八、一个叫doer_ljy(可战)的网友回复了一些内容，我个人认为不很妥当，就回复了一些内容，绿颜色的是doer_ljy(可战)的内容：
关于“无法重现”我看是有这么个问题存在。
首先如果你在测试之前有严格的测试计划，就很难出现“无法重现”这种现象。“无法重现”的意思是不知道怎么操作才能再次看见这个BUG。那么这个BUG多半是“计划外”的。
不清楚你是否是测试人员。“计划外”这个词，对测试员来说应该不存在。测试用例的粒度一直是个在讨论中的问题，测试人员很难有时间和精力写出包含内容、数据、步骤等等全部操作一切的测试用例（说白了，只要一个长手识字的人，按照测试单做，就能发现所有的问题，呵呵，有软件蓝领的感觉了）。即使真的有，意义也不大，测试很多的时候，是发散性的思维，带点创造性，想事先考虑完全，很难。所以更多时候，是在测试过程中逐步对用例等进行完善，所以说“计划外”最好不要提。
说说我现在测试的一个项目，有一个业务，首先查询出人员，有个“全选”按钮，“全选”后，再用鼠标一个一个取消选择，这个时候进行业务办理的时候，就会提示“没有选择人员”，至今为止一切都正常，但是这个时候再次点选人员进行业务处理，仍然会提示“没有选择人员”，这就是一个缺陷了。这个问题我想一般人都不会在测试用例中考虑到
吧，因为发生的条件很苛刻：不用“全选”按钮的时候不会发生；全选后点击“取消全选”按钮再办理业务不会发生；全选全消后，先点击人员再办理业务也不会发生。
其次，成熟的测试人员及时无法再现BUG，也能准确的描述出BUG发生之前几个步骤的操作方法，测试用例情况。这些对开发人员分析BUG原因很重要。所谓的BUG发现环境。
呵呵，看来我不是成熟的测试人员。手工测试，比较熟练的时候，和打字可以说差不多，应该进行到哪里，心中是有数的，但让我完全从头到尾的重复，不容易呀。写测试缺陷报告单的时候，也只是说明操作步骤和发生的现象。其实无法重现的问题，既然说“无法重现”，也就是测试人员已经对这个现象进行了多次的验证，一般从程序外部来说，测试人员的操作比程序员要熟练的。
最后，我不同意测试人员不假思索把发现的“问题”直接推给编码人员的做法。毕竟是大家合作，目标是一致的。测试人员总是处在BUG发生的第一现场，应该帮助分析出现问题的原因。确认是不是自己的此时Miss.
测试人员提交任何一个问题，都会经过反复的验证，如果容易重现，早就提出来了。绝对不是在推脱责任，还是那句话，对程序的结构，做的人当然比不做的人要清楚。另外，除非程序员询问，否则我不会给程序员提出修改分析和建议！！测试人员的任务是发现问题，解决问题是程序员的事情。这么做可能会影响程序员思考问题的思路；而且测试人员做的多了，程序员不但不感激，可能反而会反感（好像程序员对测试人员有好印象的不多）。
再说两个我这两天遇到的问题。第一个就是我们的程序有一个锁定数据的功能。锁定后，在其它的业务，此数据将不能再使用。我当时发现这个功能无效，而且经过了几次的验证都不行，我当然就提出了。但是程序员那里说此功能好使，我再验证的时候，就没有问题了，这个问题当时可以重现（但是我不可能遇到问题就拉程序员来看吧），后来却没有了，只能放在那里，最后关闭掉。第二个就是在一个界面中，录入有顺序要求，必须先选择一个ListBox（必填）再进行Edit的录入，但一次操作我没有选择 ListBox就录入的Edit，也正常保存了。后来无论我怎么操作此问题都没有出现（不够成熟呀），我就放弃了，也没有提交记录（为了避免麻烦）。
测试人员的时间是有限的，进度给的都很少，一般连用例都没有时间写，还要去花很多时间验证“无法重现”的问题？反正10分钟如果试验不出来，我就会放弃。严重的就提交，不影响的就当不知道。
下面是其它一些人的观点：
doublefalse(散诸怀抱)：如果不能重现的bug确实比较麻烦，但最好在测试过程中注意干净环境、正确的操作、相同的数据源，只要真的有问题，一定能否复现的。呵呵，多试试！！！我们以前一直有客户反映入库的数据经常有无关数据，但在家里测试没有问题，后来才发现是汉字编码错位，这样同样的字，错位后就变成另外的东西了。
liuxiaoyuzhou(蟀哥)：遇到过同样的问题!主要是记住BUG出现的环境!测试的时候这是关键!在我们这里不能从现的BUG,是测试人员的工作不到位!我们这里程序员比测试人员说话有力度!郁闷呀!
ericzhangali(另一个空间)：首先一定要提交bug；其次不要企图RD一定去解这个bug；某些时候还得关闭这个bug。如果RD认为是测试错误，（不明白什么叫测试错误，是不是说他从测时要告诉你千万不要怎么怎么做，否则后果自负啊，）那也没什么办法，如果沟通解决不了，爱咋认为就咋认为吧。
darkcat_c(错了重来)：没有bug是不可以重现的，bug本事是建立在标准的规程上所出现的异常，如果你按test case步骤做的话不太可能出现此类bug。作为测试人员一定要具备良好的
记忆能力，一旦出现一些不知如何产生的bug，至少你要知道刚才你大致进行了那些操作。
良好的分析能力，尽管你只是测试，但你应该全面的了解程序的架构，和一些重要的内部
细节，不然你这个测试就是不合格的。定位bug是开发的事情，而重现一个bug是测试的本
职工作，不要把所有的事情推给开发，不然你的确比开发要低一等。（编者按：这种话，
不愿意去辩驳，标准开发人员的看法，也许应该让他们也来做做测试）
liyan_1014(雁子)：我觉得应该是这么处理：
1、一定提交bug，必须由负责bug的tester详细描述测试操作步骤，bug发生的症状，并将bug
发生的具体环境也描述清楚；这样对于再次重现也有一定的参考性。
2、测试和开发之间是需要良好沟通的，如果得到的回复是操作错误，那么请开发人员解
释，为什么会允许存在操作错误，一般来说，对于错误控制，开发那边应该能很好的把
握。
3、沟通方面是需要方式的，开发人员对于自己完成的程序有一种满足感，一般来说是不允
许别人来破坏他的这种感觉，如果沟通的时候尽可能是一种建议的形式，让开发人员自己
指出自己的程序缺陷，这样对于开发人员来说是可以接受。
以上仅是个人工作中的经验，呵呵~~~~
embeddedsoft
2006-09-11 10:31:12微软软件开发测试工程师面试题：
Microsoft software development engineer in test (SDET) interview questions
１．How would you deal with changes being made a week or so before the ship date?
２．How would you deal with a bug that no one wants to fix? Both the SDE and his lead have sai
d they won’t fix it.
３．Write a function that counts the number of primes in the range [1-N]. Write the test cases for t
his function.
４．Given a MAKEFILE (yeah a makefile), design the data structure that a parser would create an
d then writ
e code that iterates over that data structure executing commands i
f needed.
５．Write a function that inserts an integer into a linked list in ascending order. Write the test case
s for this function.
６．Test the save dialog in Notepad. (This was the question I enjoyed the most).
７．Write the InStr function. Write the test cases for this function.
８．Write a function that will return the number of days in a month (not using System.DateTim
e).
９．You have 3 jars. Each jar has a label on it: white, black, or white&black. You have 3 sets of marbles: white, black, and white&black. One set is stored in one jar. The labels on the jars are gu aranteed to be incorrect (i.e. white will not contain white). Which jar would you choose from to gi
ve you the best chances of identifying the which set of marbles in is in which jar.
１０．Why do you want to work for Microsoft?
１１．Write the test cases for a vending machine. (Those were the questions I was asked. I had a l
ot of discussions about how to handle situations. Such as a tester is focused on one part of an SD
K. During triage it was determined that that portion of the SDK was not on the critical path, and th
e tester was needed elsewhere. But the tester continued to test that portion because it is his baby. H
ow would you get him to stop testing that portion and work on what needs to be worked on? Other
situations came up like arranging tests into the different testing buckets (functional, stress, perf, et
c.).)
第 (1/1) 页1
发表评论
昵 称：
主 页：
验证码：图案：
内 容：
发表评论
新浪BLOG意见反馈留言板 不良信息反馈 电话：95105670 提示音后按2键（按当地市话标准计费） 欢迎批评指正新浪简介 | About Sina | 广告服务 | 联系我们 | 招聘信息 | 网站律师 | SINA English | 会员注册 | 产品答疑
Copyright ? 1996 - 2006 SINA Corporation, All Rights Reserved
新浪公司 版权所有
4.软件测试的十大原则
软件测试的十大原则 文章出处：博客作者：朱少民发布时间：2006-08-16 原则是最重要的，方法应该在这个原则指导下进行。软件测试的基本原则是站在用户的角度，对产品进行全面测试， 尽早、尽可能多地发现Bug, 并负责跟踪和分析产品中的问题，对不足之处提出质疑和改进意见。 零缺陷(Zero-Bug) 是一种理念，足够好（Good-Enough）是测试的基本原则。 在软件测试过程中，应注意和遵循的具体原则，可以概括为十大项： 1.所有测试的标准都是建立在用户需求之上。正如我们所知，软件测试的目标就是验证 产品的一致性和确认产品是否满足客户的需求，所以测试人员要始终站在用户的角度 去看问题、去判断软件缺陷的影响，系统中最严重的错误是那些导致程序无法满足用 户需求的缺陷。 2.软件测试必须基于“质量第一”的思想去开展各项工作，当时间和质量冲突时，时间 要服从质量。质量的理念和文化（如零缺陷的“第一次就把事情做对”）同样是软件 测试工作的基础。 3.事先定义好产品的质量标准。有了质量标准，才能依据测试的结果对产品的质量进行 正确的分析和评估，例如，进行性能测试前，应定义好产品性能的相关的各种指标。 同样，测试用例应确定预期输出结果，如果无法确定测试结果，则无法进行校验。 4.软件项目一启动，软件测试也就是开始，而不是等程序写完，才开始进行测试。在代 码完成之前，测试人员要参与需求分析、系统或程序设计的审查工作，而且要准备测 试计划、测试用例、测试脚本和测试环境，测试计划可以在需求模型一完成就开始， 详细的测试用例定义可以在设计模型被确定后开始。应当把“尽早和不断地测试”作 为测试人员的座右铭。 5.穷举测试是不可能的。甚至一个大小适度的程序，其路径排列的数量也非常大，因此， 在测试中不可能运行路径的每一种组合，然而，充分覆盖程序逻辑，并确保程序设计 中使用的所有条件是有可能的。 6.第三方进行测试会更客观，更有效。程序员应避免测试自己的程序，为达到最佳的效 果，应由第三方来进行测试。测试是带有”挑剔性” 的行为，心理状态是测试自己 程序的障碍。同时对于需求规格说明的理解产生的错误也很难在程序员本人测试时被 发现。 7.软件测试计划是做好软件测试工作的前提。所以在进行实际测试之前，应制定良好的、 切实可行的测试计划并严格执行，特别要确定测试策略和测试目标。 8.测试用例是设计出来的，不是写出来的，所以要根据测试的目的，采用相应的方法去 设计测试用例，从而提高测试的效率，更多地发现错误，提高程序的可靠性。除了检 查程序是否做了应该做的事，还要看程序是否做了不该做的事；不仅应选用合理的输 入数据，对于非法的输入也要设计测试用例进行测试。 9.不可将测试用例置之度外，排除随意性。特别是对于做了修改之后的程序进行重新测
嵌入式软件测试报告(内部)
软件（内部）测试报告 XXX系统 测试分析报告评审 V1.0 编写人: 编写日期: 审核人: 审核日期:
修订页
目录 目录 (1) 软件测试报告(内部) (2) 安装及使用测试 (3) 运行环境 (3) 安装易用性 (3) XXX测试 (4) 安装、使用问题及建议 (4) 功能单元测试 (5) 串口指令响应功能测试 (5) 1.测试方法及工具 (5) 2.功能测试 (5) 3.性能测试 (6) 4.稳定及安全性测试 (6) 5.BUG及建议 (6) xxx功能测试 (7) 整机测试 (8) 长时间工作稳定性整机测试 (8) 1.测试方法及工具 (8) 2.测试步骤及结果 (8) xxx整机测试 (8) 整机测试问题及建议 (8) 安装及使用测试附件 (10) 功能单元测试附件 (11) 整机测试附件 (12)
软件测试报告(内部) CRABXLAB-0628-15 TA/0001 软件测试报告编写：首先做对产品的安装及使用测试，如从运行环境、软件安装、故障指示、用户可操作性、界面友好性等方面来检测是否合理可靠；其次从功能完整性上测试，并对每个功能单元进行功能测试、性能测试、安全及稳定性测试，保证每个功能单元都稳定可靠；最后做整机测试，整机测试主要从长时间工作稳定性、异常处理（如网络、电量异常）合理可靠性等方面检查整机稳定可靠性。
安装及使用测试 开发出来的软件要基于对客户或者量生产上考虑产品的使用及安装环境的易用、安全、可操作性、友好性等。 运行环境 安装易用性
XXX测试 章节同安装及使用测试范例，由开发人员完善其他需要的测试项安装、使用问题及建议
《嵌入式软件可靠性测试方法》-编制说明
国家标准《嵌入式软件可靠性测试方法》（征求意见稿） 编制说明 一、制定标准的背景 大多数软件测试方法都可以直接或间接地用于嵌入式软件的测试，但嵌入式软件可靠性测试与通用软件可靠性测试有着较大差别，当前“后PC时代”的来临及3C融合加速趋势的彰显，给中国以嵌入式软件为核心的嵌入式系统产业的高速增长带来了千载难逢的契机，嵌入式软件产业现已成为中国IT产业中的一个重要新兴产业和增长点，嵌入式软件可靠性测试对嵌入式系统产业的发展显得尤为重要。嵌入式软件软件对硬件的依赖性和专用性较强，对可靠性要求较高，目前针对嵌入式软件的测试和调试工具较少，这些都使得嵌入式软件的测试比通用计算机软件测试的复杂性、可继承性较差。嵌入式系统可靠性、安全性的失效可能会导致灾难性的后果,或者大批量生产也会导致严重的经济损失。因此，需要制订针对嵌入式系统软件的可靠性测试方法。鉴于现状制定《嵌入式软件可靠性测试方法》是非常必要的。 二、任务来源 根据国家标准化管理委员会2008年下达的国家标准制修订计划，国家标准《嵌入式软件可靠性测试方法》由中国电子技术标准化研究所、珠海南方软件产品测试中心、珠海许继电气有限公司、珠海炬力集成电路设计有限公司等单位负责起草，其项目计划号为20080488-T-469。 三、标准编制原则 本标准主要依据《软件可靠性工程》、GB/T 15532-2008《计算机软件测试规范》和GJB 899 《可靠性鉴定和验收试验》和一些企业的嵌入式软件可靠性测试相关方法和经验而制定的。 四、编制过程 计划下达后，首先成立了标准起草工作组，在珠海的一些嵌入式软件开发企业开展调研，收集相关资料，在此基础上起草了《嵌入式软件可靠性测试方法》初稿，然后召集国内嵌入式软件研发、测试专家，标准化专家研讨、审查、修改后形成征求意见稿。 五、有关技术说明 5．1测试目的说明 由于本方法是可靠性测试，所以定义的测试目的有两个，一是通过可靠性增长测试，查找软件错误，实现嵌入式软件的可靠性增长，估计失效强度；二是通过可靠性确认测试，验证嵌入式软件是否达到可靠性目标。 5．2测试环境的说明
软件测试体系建设
软件测试体系建设 1、概述 体系的建设可以从软件测试的管理体系和技术体系两方面上进行作手，从团队组织、环境建设、标准制定、人员培养、、流程等方面进行建设。公司里有一个规范的软件测试体系，能有效提高软件质量和软件过程能力，能极大提高员工工作效率和降低员工工作强度。 2、测试团队组织 软件测试团队的组织根据公司规模，可以是一个部门也可以是一个测试组，其主要职责是负责整个公司软件项目的测试工作，团队内设一名负责人，负责测试人员的组织和管理工作。测试团队对测试工具，文档等进行管理，团队中设试人员若干名，每个测试人员有自己的发展和研究方向，有的发展方向是基于需求的测试，有的是基于安全的测试，有的是基于接口的测试，有的基于界面的测试等等，各测试人员必须精通自己测试发展方向，并要求熟悉人的测试技术。 3、环境建设 硬件环境 在环境建设上，主要从软硬件环境两方面着手。在硬件方面，保证了每个工作人员有自己的PC 机，PC机硬件配置能保证软件，测试工具，管理工具等安装运行的最低要求。 软件环境 在基于PC 机上的环境，根据项目软件对运行环境的需求，保证测试人员有单独的测试PC 机环境，如等，服务器环境等。 同时，测试相关文档的管理（如需求分析，测试计划，CHECKLIST，，测试报告，分析报告等）是一个复杂和繁琐的工作，通过测试管理系统对计划、用例、过程、缺陷、过程等文档进行有效的管理。对于测试团队来说，利用测试工具可以大幅提高测试质量，根据公司产品特点和经济条件，可以使用免费工具和自己书写自动化工具，如对于代码审查和或以通过开发平台或用一些常用的测试工具如C++ TEST进行测试；对于回归测试、压力测试通常使用自己书写的工具或一些免费的测试工具进行测试，对于比较复杂环境的或利用一些收费测试软件测试如LR或外包给专门的测试公司来做，以便减少测试成本和保证测试质量。
嵌入式软件测试简介
一、嵌入式系统与嵌入式操作系统 1、嵌入式系统 嵌入式系统是以嵌入式计算机为技术核心，面向用户、面向产品、面向应用，软硬件可裁减的；适用于对功能、可靠性、成本、体积、功耗等综合性能有严格要求的专用计算机系统。 嵌人式系统应具有的特点是：高可靠性；在恶劣的环境或突然断电的情况下，系统仍然能够正常工作；许多嵌人式应用要求实时性，这就要求嵌入式操作系统具有实时处理能力；嵌入式系统和具体应用有机地结台在一起，它的升级换代也是和具体产品同步进行；嵌入式系统中的软件代码要求高质量、高可靠性；一般都固化在只读存储器中或间存中，也就是说软件要求固态化存储，而不是存储在磁盘等载体中。 2、嵌入式操作系统 嵌入式操作系统EOS（Embedded Operating System）是一种用途广泛的系统软件，过去它主要应用于工业控制和国防系统领域。EOS负责嵌人系统的全部软、硬件资源的分配、调度工作，控制。 协调并发活动；它必须体现其所在系统的特征，能够通过装卸某些模块来达到系统所要求的功能。目前，已推出一些应用比较成功的EOS产品系列。随着Internet技术的发展、信息家电的普及应用及EOS的微型化和专业化，EOS开始从单一的弱功能向高专业化的强功能方向发展。嵌人式操作系统在系统实时高效性、硬件的相关依赖性、软件固态化以及应用的专用性等方面具有较为突出的特点。EOS是相对于一般操作系统而言的，它除具备了一般操作系统最基本的功能，如任务调度、同步机制、中断处理、文件功能等外，还有以下特点： (1)可装卸性。开放性、可伸缩性的体系结构。 (2)强实时性。EOS实时性一般较强，可用于各种设备控制当中。 (3)统一的接口。提供各种设备驱动接日。 (4)操作方便、简单、提供友好的图形GUI，图形界面，追求易学易用。 (5)提供强大的网络功能，支持TCP门P协议及其它协议，提供TCP／UDP／IP／PPP协议支持及统一的MAC访问层接口，为各种移动计算设备预留接口。 (6)强稳定性，弱交互性。嵌入式系统一旦开始运行就不需要用户过多的干预，这就要负责系统管理的EOS臭有较强的稳定性。嵌入式操作系统的用户接日一般不提供操作命令，它通过系统调用命令向用户程序提供服务。 (7)固化代码。在嵌入系统中，嵌入式操作系统和应用软件被固化在嵌入式系统计算机的ROM中。辅助存储器在嵌入式系统中很少使用，因此，嵌入式操作系统的文件管理功能应该能够很容易地拆卸，而用各种内存文件系统。 (8)更好的硬件适应性，也就是良好的移植性。 二、三种常用的嵌入式操作系统 1. PALM OS Palm是3Corn公司的产品，其操作系统为Palm OS。Palm OS是一种32位的嵌入式操作系统。Palm提供了串行通信接口和红外线传输接口；利用它可以方便地与其它外部设备通信、传输数据；拥有开放的OS应用程序接口，开发商可根据需要自行开发所需的应用程序。Palm OS是一套具有极强开放性的系统，现在有大约数千种专门为Palm OS编写的应用程序，从程序内容上看，小到个人管理、游戏，大到行业解决方案，Palm OS无所不包。在丰富的软件支持下，基干Palm OS的掌上电脑功能得以不断扩展。 Palm OS是一套专门为掌上电脑开发的OS。在编写程序时，Palm OS充分考虑了掌上电脑内存相对较小的情况，因此它只占有非常小的内存。由于基干Palm OS编写的应用程序占用的空间也非常小（通常只有几十KB），所以，基于Palm OS的掌上电脑（虽然只有几MB的RAM）可以运行众多应用程序。 由于Palm产品的最大特点是使用简便、机体轻巧；因此决定了Palm OS应具有以下特点。 (1)操作系统的节能功能。由于掌上电脑要求使用电源尽可能小，因此在Palm OS的应用程序中，如果没有事件运行，则系统设备进人半休眠（doze）的状态；如果应用程序停止活动一段时间，则系统自动进人休眠（sleep）状态。 (2)合理的内存管理。Palm的存储器全部是可读写的快速RAM，动态RAM（Dynamic RAM）类似于PC机上的RAM，它为全局变量和其它不需永久保存的数据提供临时的存储空间；存储RAM（Storage RAM）类似于PC机上的硬盘，可以永久保存应用程序和数据。 (3)Palm OS的数据是以数据库（database）的格式来存储的。数据库是由一组记录（records）和一些数据库头信息组成的。为保证程序处理速度和存储器空间，在处理数据的时候，Palm OS不是把数据从存储堆（Storage Heap）拷贝到动态堆（Dynamic Heap）后再进行处理，而是在存储堆中直接处理。为避免错误地调用存储器地址，Palm OS规定，这一切都必须调用其内存管理器里的API来实现。 Palm OS与同步软件（Hotsync）结合可以使掌上电脑与PC机上的信息实现同步，把台式机的功能扩展到了掌上电脑。Palm应用范围相当广泛，如：联络及工作表管理、电子邮件及互联网通信。 销售人员及组别自动化等等。Palm外围硬件也十分丰富，有数码相机、GPS接收器、调制解调器、GSM无线电话、数码音频播放设备、便携键盘、语言记录器、条码扫描、无线寻呼接收器、探测仪。 其中Palm与GPS结合的应用，不但可以作导航定位，还可以结合GPS作气候的监测、地名调查等。 2. Windows CE
软件测试发展方向
软件测试发展方向
软件测试职业发展方向 最近准备研究一下软件测试职业的发展方向，一是增长自己的知识，二是为自己的职业规划做个参考，在网上找到一篇很好的东东，将它整理了一下，放上来吧，以备以后查看。 软件测试职业发展方向，大体上可以分为管理路线、技术路线、管理+技术路线。 测试初级阶段： 测试工程师，属于软件测试职业生涯的初级域，其适用范围是入行软件测试3年内的常规测试从业者，其主要工作内容是按照测试主管（即直接上司）分配的任务计划，编写测试用例、执行测试用例、提交软件缺陷，包括提交阶段性测试报告、参与阶段性评审等。 管理+技术路线： 首先是常规路线，这条发展路线要求管理与技术并重，因为软件测试的行业特点决定了这个因素：测试工程师向上晋升到测试主管、测试经理、测试总监，直至咨询域的更高方向！ 测试主管是企业项目级主管，对于中小型软件公司也可以是企业级主管，属于中级发展域，适用范围是2到5年职业经验的测试从业者。其工作内容是根据项目经理或测试经理的计划安排，调配测试工程师执行模块级或项目级测试工作，并控制与监督软件缺陷的追踪，保证每个测试环节与阶段的顺利进行。严格来说，这个级别更多属于测试的设计者，因为企业的测试流程搭建是由更高级别的测试经理或相关管理者来做的，测试主管负责该流程的具体实施；而更多的工作，是思考如何对软件进行更加深入、全面的测试。测试主管比较有创造性的工作内容就是测试设计，而恰恰很多公司忽略了或没有精力来执行此工作内容！应该说，在一个企业里做了3年左右测试工作的人员，很容易晋升到该职位，而之所以晋升，是与个人测试技术的过硬、测试方法的丰富，加上对测试流程的监控力与执行力的职业素质息息相关！ 测试经理是更高级别的测试管理者，属于高级测试方向域。对于大中型软件公司，该职位尤为重要，并且对其职业要求也比较高，一般适合4到8年的测试从业者，在管理与技术能力双双比较成熟的情况下，可以结合具体环境晋升到该级别。测试经理负责企业级或大型项目级总体测试工作的策划与实施。测试经理除了需要统筹整个企业级或项目级测试流程外，还要对于不同软件架
【调研问卷模板】软件测试能力素质测试
【调研问卷模板】软件测试能力素质测试 1. 请填写个人信息 姓名 ____________ 手机号 ____________ 岗位 ____________ 面试时间 ____________ 实操分数 ____________ 技术复核分数 ____________ 面试人 ____________ 2. 你为什么选择这个专业？为什么选择这个行业？本题考察兴趣、动机，只有感兴趣的事情，你才可以把它做到最好。 1分 2分 3分 4分 5分 3. 你想过什么样的人生？本题考察人生观. －排除贪图安逸、只想享乐的人－排除找工作混日子的人－重点挖掘想实现人生价值，为社会做出贡献的人 1分 2分 3分 4分 5分
4. 你在3到5年的职业生涯规划是什么？你打算怎样达到自己的目标？本题考察自我管理能力，自我管理能力强的人，具有以下行为. －设置SMART的目标－勤奋努力，并展现出高水平的创造力－自发完成目标，而不需要太多的监管－为结果负责 1分 2分 3分 4分 5分 5. 匹配度指个人职业生涯规划，与公司的目标的契合度。如. 某人希望成为一名服装设计师，那UI／UE的岗位就不适合他 1分 2分 3分 4分 5分 6. 你认为一个人要获得事业上或工作上的成功，最重要的素质是什么？本题考察的是勤奋刻苦的品质，对个人成功的影响。俗话说勤能补拙、愚公移山，没有付出，就没有收获。 1分 2分 3分 4分 5分
7. 假设你发现你的上司的一个工作举措是有违公司规章制度的，你会怎么处理？你不会因为担心你的上司会因为这件事而对你有看法吗？本题考察诚信正直，诚信正直的人表现出以下行为. －维护企业的廉正－显示高标准的道德行为－理解违反诚信正直对个人或 他人的影响－值得信赖 1分 2分 3分 4分 5分 8. 请描述你最满意的项目，你在项目中的角色和贡献，项目中用到的技术，学到的知识及克服的困难本题考察诚信正直，诚信正直的人表现出以下行为. －维护企业的廉正－显示高标准的道德行为 －理解违反诚信正直对个人或他人的影响－值得信赖 1分 2分 3分 4分 5分 9. 请给出你做得失败的一个项目的例子？你从中学到了什么？本题考察学习能力，失败是成功之母，只有从失败中不断总结经验教训，才可能通往成功 1分 2分 3分
嵌入式软件测试工程师
嵌入式软件测试工程师 一、嵌入式软件测试工程师任职条件 1、自动化、计算机、电子通信以及相关学科，硕士以上学历； 2、熟悉嵌入式Linux、Android、Windows CE或其它嵌入式操作系统下的开发和调试; 3、具有良好汇编语言和C语言的编程能力； 4、了解流行的处理器架构ARM/MIPS/POWERPC/ColdFire等；熟悉嵌入式系统的体系结构，熟悉嵌入式操作系统下的应用程序编写；熟练使用1种以上脚本开发,Lua。 5、3年以上嵌入式操作系统开发或测试经验； 有良好的编码习惯，能够按照代码规范进行编码及文档工作； 具有吃苦精神，能够承受较大的工作压力，自学能力强； 富于团队合作精神，工作责任心强；较强的英语阅读 5、熟悉测试基本理论、包括黑盒、白盒测试技术；熟悉功能测试和性能测试方法，熟悉软件测试流程和质量保证体系优先； 能力； 6、熟悉大型数据库，SQLSERVER、Oracle等。 .根据系统需求与设计能够编制测试方案，制定测试计划与测试用例；
7、具备系统测试环境的搭建与维护能力； 具备较强的设计文档的理解能力，口头和文字表达能力强； 8、熟悉C、C++ 编程，掌握gcc/make等相关开发工具；能够熟练掌握ADS、KeilC等嵌入式软件设计调试工具；熟悉TCP/IP网络协议，熟悉socket编程；掌握多种软件测试工具。 9、掌握常用的linux命令，熟悉数据库(SQL和Oracle)的基本操作; 10、.要有良好的组织沟通能力，具有团队协助精神； 二、嵌入式软件测试工程师职责 1、组建软件测试团队，制定相关测试流程及技术管理体系； 2、带领测试团队展开测试工作，负责产品的质量保证体系的建立； 3、规划测试策略，制定测试方案和计划，并负责计划的管理；负责按照测试计划组织实施软件测试；包括测试需求文档编写，测试用例设计，测试脚本执行；完整地记录测试结果，编写完整的测试报告等相关的技术文档； 4.对测试中发现的问题进行详细分析和准确定位，与开发人员讨论缺陷解决方案。 5.提出对产品的进一步改进的建议，并评估改进方案是否合理，对测试结果进行总结与统计分析，对测试进行跟踪，并提出反馈意见。 6.为业务部门提供相应技术支持，确保软件质量指标。 7、制定和实行测试相关的培训计划，提高测试团队的整体工作能； 8、做好测试和软硬件部门的沟通和协调工作。
软件测评能力提升方案-
软件测评工程能力提升方案 咨询方将在上述调研报告基础上，提出详细的测评工程能力建设方案。方案的主要包括以下方面： 1软件测试实用规程 1.1软件测试的认识 如前所述，目前软件测试领域的理论体系仍然不算成熟，软件测评专业能力建设本身是一个复杂的系统工程，牵涉的人员和环节众多，从调研结果来看，部分研发人员对测试的认识存在一些偏差，这将给软件测评专业建设带来风险。 软件测评工程能力，首先是测试意识的提升。技术保障，观念先行，一个研发项目涉及的人员尤其是大多数的开发人员的测试意识是决定性的，只有将软件测试放到软件全生命周期的大背景下来考察，使全体人员对软件质量全程保证的角度来重新认识测试，具体的测试方法、测试技能提升才有普遍意义。 基础理论和方法论的普及，软件测试的本质、含义、定位和作用的深入认识，将是项目能否顺利开展的前提。 软件测试本质上是一个证伪而不是证明的过程。因此，从广义上来说，只要是对软件本身质量保证相关的，都可以纳入软件测试的范围。无论是在软件研发的需求分析、架构设计、详细设计、代码实现还是后面的测试阶段，都可以开展测试活动；无论是系统设计人员、软件编程人员或者验证人员、服务人员、市场人员，都可以成为测试人员；也无论是文档评审、代码审查、功能调试、系统验证等等活动，都可以是一种测试活动；无论是人工验证、形式证明、代码静态分析工具、单元测试工具还是自动化测试工具等手段，都可以成为有效的测试手段。 只要有确定的人员，采用某种确定的方法手段，按照确定的项目内容，对影响软件质量的相关文档、代码、程序、数据等进行验证，都是执行了有意义的测试。经过这些验证活动之后，我们得出有条件的结论，这个条件是在这些项目内容验证之下，
软件测试10大原则
10. 软件测试十大原则 原则是最重要的，方法应该在这个原则指导下进行。软件测试的基本原则是站在用户的角 度，对产品进行全面测试， 尽早、尽可能多地发现Bug,并负责跟踪和分析产品中的问题，对不足之处提岀质疑和改 进意见。 零缺陷(Zero-Bug )是一种理念，足够好( Good-Enough )是测试的基本原则。 在软件测试过程中，应注意和遵循的具体原则，可以概括为十大项： 1. 所有测试的标准都是建立在用户需求之上。正如我们所知，软件测试的目标就是验证产 品的一致性和确认产品是否满足客户的需求，所以测试人员要始终站在用户的角度去看 问题、去判断软件缺陷的影响，系统中最严重的错误是那些导致程序无法满足用户需求的缺陷。 2. 软件测试必须基于“质量第一”的思想去开展各项工作，当时间和质量冲突时，时间要 服从质量。质量的理念和文化(如零缺陷的“第一次就把事情做对”)同样是软件测试工作的基础。 3. 事先定义好产品的质量标准。有了质量标准，才能依据测试的结果对产品的质量进行正 确的分析和评估，例如，进行性能测试前，应定义好产品性能的相关的各种指标。同样, 测试用例应确定预期输岀结果，如果无法确定测试结果，则无法进行校验。 4. 软件项目一启动，软件测试也就是开始，而不是等程序写完，才开始进行测试。在代码 完成之前，测试人员要参与需求分析、系统或程序设计的审查工作，而且要准备测试计 戈y、测试用例、测试脚本和测试环境，测试计划可以在需求模型一完成就开始，详细的测试用例 定义可以在设计模型被确定后开始。应当把“尽早和不断地测试”作为测试人员的座右铭。 5. 穷举测试是不可能的。甚至一个大小适度的程序，其路径排列的数量也非常大，因此，在测试中不 可能运行路径的每一种组合，然而，充分覆盖程序逻辑，并确保程序设计中使用的所有条件是有可 能的。 6. 第三方进行测试会更客观，更有效。程序员应避免测试自己的程序，为达到最佳的效果， 应由第三方来进行测试。测试是带有”挑剔性”的行为，心理状态是测试自己程序的 障碍。同时对于需求规格说明的理解产生的错误也很难在程序员本人测试时被发现。 7. 软件测试计划是做好软件测试工作的前提。所以在进行实际测试之前，应制定良好的、 切实可行的测试计划并严格执行，特别要确定测试策略和测试目标。 8. 测试用例是设计岀来的，不是写岀来的，所以要根据测试的目的，采用相应的方法去设 计测试用例，从而提高测试的效率，更多地发现错误，提高程序的可靠性。除了检查程 序是否做了应该做的事，还要看程序是否做了不该做的事；不仅应选用合理的输入数据， 对于非法的输入也要设计测试用例进行测试。 9. 不可将测试用例置之度外，排除随意性。特别是对于做了修改之后的程序进行重新测试 时，如不严格执行测试用例，将有可能忽略由修改错误而引起的大量的新错误。所以， 回归测试的关联性也应引起充分的注意，有相当一部分最终发现的错误是在早期测试结果中遗漏的。 对发现错误较多的程序段，应进行更深入的测试。一般来说，一段程序中已发现的错误数越多， 其中存在的错误概率也就越大。错误集中发生的现象，可能和程序员的编程水平和习惯有很大的关 系。
嵌入式软件测试基础知识
嵌入式软件测试基础知识 测试是传统软件开发的最后一步。整个软件开发过程，需要收集要求、进行高层次的设计、详细设计、创建代码、进行部分单元测试，然后集成，最后才开始最终测试。最佳的开发实践应包含代码检查这个步骤。然而代码检查一般只能找出70%的系统错误，因此完美的测试环节绝对必不可少。测试就像个复式记帐系统，可以确保将缺陷扼杀在最终推出的产品之前。在所有其它的工程实践中，测试都被视为基本环节。比如，在美国，每一座联邦政府出资修建的桥都必须经过大量的风洞测试。而在软件领域，测试并没有很受重视。尽管测试是所有工程实践准则的关键部分，但编写测试程序却感觉是在浪费时间。好在嵌入式系统设计界内的许多领域已经将测试作为其工作的核心部分，他们认识到将这个关键步骤放在项目末期极不明智，因而主张同步地编写测试程序和应用程序。嵌入式系统软件测试在诸多方面都与应用软件测试一样。不过，应用测试与嵌入式系统测试之间还是存在一些重要差异。嵌入式开发人员一般会用到基于硬件的测试工具，而这类工具通常不会用于应用开发过程中。此外，嵌入式系统一般都有些独一无二的特性，这些特性应该在测试计划中得以体现。本文将介绍测试和测试案例开发的基础知识，并指出整个嵌入式系统测试工作的特有细节。何时测试以及如何测试从图1可以看出，在可行的条件下，测试应尽早展开。一般来讲，最早的测试是由最初的开发人员进行的模块或单元测试。遗憾的是，开发人员大多对如何建构一整套测试例程以进行测试所知不足。由于精心设计的测试例程通常直到集成测试时才能使用，因此许多在单元测试过程中就能找出的缺陷直到集成测试时才会被发现。比如，硅谷的一家大型网络设备厂商为找出其软件集成问题的关键原因，进行了一项研究。这家厂商发现，在项目集成阶段找出的缺陷中，有70%是由在集成之前从没被执行过的程序所产生的。 2012-3-16 11:05:05 上传 下载附件 (9.94 KB) 图1：改正问题的成本。单元测试：开发人员在单独进行模块级测试时一般是编写存根代码(stub code)取代余下的系统软硬件。在开发周期的这个环节，测试主要侧重于代码的逻辑性能。通常，开发人员会分别使用某些平均值、高值或低值、以及某些超出范围的值(以测试代码的异常处理功能)进行测试。但这些基于“黑匣子”的测试仅能对模块中整个代码的一部分进行测试。回归测试：测试不应是一劳永逸的。每次修改程序后都应该重新进行测试，以确保这些更改不会无意中“误伤”某些不相关的行为。称为回归测试的这类测试，一般是通过测试脚本自动进行的。比如，如果你设计了一组100个输入/输出(I/O)测试，回归测试脚本会自动执行这100个测试，然后将输出与一组“黄金标准”输出进行对比。每次对代码的任何部分进行修改时，都要对包含被修改代码的整个程序运行整套回归测试程序包，以确保修改过程中不会“误伤”其余代码。测试什么因为没有一个实际的测试集可以证明一个程序是正确的，因此关键问题变成了哪个测试子集最有可能检测到最多的错误。选择合适的测试例程的问题被称为测试例程设计。虽然存在数十种测试案例的设计方法，但它们通常可归为两种截然不同的方法：功能测试和覆盖测试。功能测试(也称为黑匣子测试)选择可评估实现与需求规格符合程度的测试。覆盖测试(也称为白匣子测试)选择可执行代码某些部分的测试例程。(过后，将详细讨论这两种方法。)这两种测试都是对嵌入式设计进行严格测试所必需的。其中，覆盖测试表示代码的稳定性，所以这种测试是用于已经完成或将近完成的产品的。另一方面，可在编写要求文档时，同时编写功能测试。事实上，从功能测试开始入手，可以最大限度地降低重复劳动和重写测试案例的工作。因此，在我看来，要先考虑功能测试。每个人都同意先编写功能测试这个观点，有人认为，功能测试在系统集成阶段(而不是在单元测试时)最有用。以下是整合功能测试和覆盖测试方
软件测试技术建设实施方案
南京信息职业技术学院 骨干专业课程建设方案 《软件测试技术基础》 课程代码：【M01F031】 适用专业：软件技术 编制单位：计算机与软件学院
《软件测试技术基础》 骨干专业课程建设方案 课程编码[M01F031] 课程承担单位[计算机与软件学院] 制定人[ ] 制定日期[ ] 审核人[ ] 审核日期[批准人[ ] 批准日期[一、指导思想 深入贯彻《关于全面提高高等职业教育教学质量的若干意见》和《教育部关 于推进高等职业教育改革创新引领职业教育科学发展的若干意见》精神，落实实 施《南京信息职业技术学院国家骨干高职院校建设方案》，提高岗位能力课程与实 际工作岗位的匹配程度，提高教育教学质量，制定此建设方案。 二、课程建设目标 1.通过典型软件企业的岗位分析，明确目前软件测试工程师岗位的工作任务 及职业能力，获取软件测试应用领域的具体需求，根据工作任务和职业能力要求 确定课程目标； 2.依据课程目标选择典型企业的项目案例，并对案例进行裁剪和优化以适应 课程需求； 3.以优化后的案例为基础优化、修订现有教材； 4.完善和优化网络教学资源库，包括教学课件、教学视频、习题库、软件测 试项目案例代码及软件测试相关文档； 5.引入典型企业的软件测试管理模式，模拟企业软件软件测试流程来组织课 程的实施，让学生对未来自己的工作岗位和工作情境具有直观感受； 6.探索基于过程的课程考核方式，发挥评价的功能，提高学生学习积极性； 7.倡导学生主动参与，乐于研究，勤于动手的学习态度，在项目案例测试过 程中培养学生交往与合作能力； 三、组织实施 负责人：顾海花 组员：董志勇、雷雁、史海峰、周乃富、季飞、何蓓、
软件测试的原则
软件测试的原则： 1所有的测试都应追溯到用户需求2应当把“尽早和不断地测试”作为座右铭3测试工作应该由独立的专业的软件测试机构来完成4 Pareto原则，测试发现的错误中80%很可能起源于20%的模块中。5设计测试用例时，应该考虑各种情况。6对测试出的错误结果一定要由一个确认的过程。7制定严格的测试计划8完全测试是不可能的，测试需要终止。9注意回归测试的关联性。10妥善保存一切测试过程文档。 软件测试的分类：1按测试方式分类：静态测试（不需要执行所测试的程序，查询代码十分符合规范，对程序的数据流和控制流进行分析），动态测试（选择实际测试用例运行测试程序，模拟用户输入）2、按测试方法分类：白盒测试（结构测试，基于代码的测试或基于设计的测试）黑盒测试（行为测试，功能测试或基于需求的测试，基于系统应该完成的功能进行测试）3按测试过程分类：单元测试集成测试系统测试验收测试.4按测试目的分类：功能测试，健壮性测试，接口测试，性能测试，强度测试，压力测试，用户界面测试安全测试靠性测试安装/反安装测试文档测试恢复测试兼容性测试。 软件测试流程：1制定测试计划：软件测试背景，软件测试依 据，测试范围的界定，风险的确定，测试资源，测试策略，时 间表的制定，其他。2设计测试方案3测试准备和测试环境的 建立4执行测试5测试评估6测试总结 软件测试人员的基本素质：1具有良好的计算机编程基础2具 有创新精神和超前意识3不懈努力，追求完美4具有很强的沟 通和交流能力5具有整体观念，对细节敏感6团队合作精神 如何制定软件测试计划：1认真做好测试资料的搜集整理工作： 软件的类别及其构成，软件的用户界面，在所测试的软件设计 第三方软件的情况下，必须对这个第三方软件的功能及其与所 要测试的软件之间的联系有一定的了解2明确测试的目标，增强测试计划的实用性3检查“5W”规则，明确内容与过程4采用评审和更新机制，保证测试计划满足实际需求。 白盒测试：一种被广泛使用的逻辑测试技术，也称为结构测试或逻辑驱动测试。对象基本是源程序，是以程序的内部逻辑为基础的一种测试技术。分为：静态测试（一种不通过执行程序而进行测试的技术，关键是检查软件的表示和描述是否一致，是否存在冲突。找出源代码的语法错误，编译器和人工检测方法如代码检测法，静态结构分析法）动态测试（需要软件执行，当软件系统在模拟的或真实的环境中执行之前，之中和之后，对软件系统行为的分析是主要特点） 黑盒测试：数据驱动测试，穷举输入测试，只有把所有可能的输入都作为测试数据使用，才能查出程序中所有的错误。分为功能测试（方法：等价类划分，边值分析，因果图，错误推测，功能图法等，主要用于软件确认测试）和非功能测试（性能测试，强度测试，兼容性测试，配置测试，安全测试等） 等价类划分概述（所谓等价类是指摸个输入域的子集，等价类划分是一种典型的、常用的黑盒测试方法。使用这一方法时，把所有可能的输入数据（即将程序的输入域划分成若干部分（子集），然后从每一个子集中选取少数具有代表性的数据）作为测试用例。 有效等价类(指对于程序规格说明来说，由合理的、有意义的输入数据构成的集合。利用它，可以检验程序是否实现了规格说明预先规定的功能和性能) 无效等价类（指对于程序规格说明来说，由不合理的、无意义的输入数据构成的集合） 单元测试：对软件设计的最小单元——模块进行正确性检验的测试工作，主要测试模块在语法，格式和逻辑上的错误。主要采用白盒测试技术，辅之以黑盒测试技术
嵌入式软件测试与一般软件测试之异同研究
嵌入式软件测试与一般软件测试之异同研究 作者：网络转载发布时间：[ 2013/3/5 9:09:17 ]推荐标签： 摘要：随着计算机技术的普及，软件系统已经深入到生活的各个方面，从普通的计算机软件，到银行或超市的终端系统，甚至到手机的软件系统。对软件的质量要求也在不断提高，软件测试及其技术也有了飞速发展。在对软件测试技术相关基本概念研究解析的基础上，分析软件测试起源与发展，保证软件产品的质量、提高产品的可靠性。对于嵌入式软件系统，因其多样性，基于操作系统，使用的开发环境，微控制器都是日益繁多的，所以嵌入式软件测试与普通软件测试相比有其自身的特点。 关键字：软件测试；嵌入式测试；软件质量 1、引言 嵌入式软件的开发和测试也就与普通软件的开发和测试策略有了很大的不同，嵌入式软件系统是一种针对特殊任务、特殊环境而进行特殊设计的定制产品，有其专门的开发环境、软硬件紧密结合、严格的实时要求等特点。使得嵌入式软件测试与普通软件测试虽有相似之处，但有也有其自身独特的特点。 2、软件测试和嵌入式软件测试 2.1 软件测试的定义及目的 软件测试，即Software Testing。软件测试的定义有很多，在1979年出版的一本经典著作《软件测试艺术》（The art of software testing）中，GLEMFORD J.MYERS曾经对软件测试下过如下定义：软件测试就是为了发现错误而执行程序或系统的过程。虽然它不太完善，但放在当时的情况下是可以说的通的。 随着计算机和软件技术的发展，软件应用的复杂性和规模的不断扩大，软件测试技术的研究也取得了很大的突破。早期的定义已经不适用了，许多专家对软件测试提出了各种各样的定义。综合起来，我们可以定义“软件测试是由一个程序的行为在有限测试用例集合上，针对期望的行为的动态验证组成，测试用例是从通常的无限执行域中适当选取的”。
史上最全面!!软件测试(知识点整理)
软件测试 第1章软件工程概述 1.1软件工程起源 1.1.1软件的发展及特点 1.1.1.1计算机硬件的发展 1.1.1.2计算机软件的发展 1.1.1.3计算机软件特点 1.2软件危机 1.2.1软件危机的表现 1.2.2软件危机的形成条件 1.2.3软件工程的提出 1.3软件工程概述 软件工程 是研究和应用如何以系统性的、规范性的、可定量的过程化方法去开发和维护软件，以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来。 1.3.1软件工程三要素 方法、过程和工具。 1.方法 （1）结构化方法（模块化方法） 将系统分解为具有层次结构的模块或过程，在设计和实现模块的内容时候，不同
考虑其他模块的内部实现细节，而只需要考虑本模块的实现和与其他模块实现的接口。 （2）面向对象方法 面向对象方法的核心概念是“类”，类是对具有相同属性和行为的一个或多个对象的抽象描述。 （3）形式化方法 形式化方法是描述系统性质的基于数学的技术，此技术提供了一个框架，可以在框架中以系统的方式刻画。开发和验证系统。 （4）基于构件的方法 构件是可复用的软件组成成分，可以独立地制造、分发、销售和装配的二进制软件单元，是可执行软件的一个物理封装，他有良好的接口，可被用来构造其他软件涉及三个子过程，构件开发、构件管理、基于构件的应用组装。 （5）基于Agent 的方法 面向多Agent的观点认为现实世界是由许多自主的或非自主的实体组成，它们按照各种关系组织起来，彼此间进行各种交互与通信，完成各种复杂的任务。 （6）基于敏捷技术的方法 敏捷方法汲取众多轻型方法的“精华”，恰当的表达这些方法的最根本之处 2.过程 RUP软件生命周期四过程：初始、细化、构造、交付
软件测试笔试题
一、选择题 1.软件可靠性是指在指定的条件下使用时，软件产品维持规定的性能级别的能 力，其子特性（C）是指在软件发生故障或者违反指定接口的情况下，软件产品维持规定的性能级别的能力。 A．成熟性； B．易恢复性；C．容错性； D．可靠性依从性 2.关于软件质量的描述，正确的是__B____ A．软件质量是指软件满足规定用户需求的能力； B．软件质量特性是指软件的功能性、可靠性、易用性、效率、可维护性、可移植性； C．软件质量保证过程就是软件测试过程； D．以上描述都不对 3.____B__方法根据输出对输入的依赖关系设计测试用例。 A．路径测试B．等价类 C．因果图D．边界值 4.下列关于软件验收测试的合格通过准则错误的是：___C___ A．软件需求分析说明书中定义的所有功能已全部实现，性能指标全部达到要求； B．所有测试项没有残余一级、二级和三级错误； C．立项审批表、需求分析文档、设计文档和编码实现不一致； D．验收测试工件齐全 5.测试设计员的职责有：___B___ ①制定测试计划②设计测试用例③设计测试过程、脚本④评估 测试活动 A.①④B．②③ C．①③D．以上全是 6.对于业务流清晰的系统可以利用D场景法贯穿整个测试用例设计过程广在用 例中综合使用各种测试方法，对于参数配置类的软件，要用C正交试验法选择较少的组合方式达到最佳效果，如果程序的功能说明中含有输入条件的组合情况，则一开始就可以选用B因果图法和判定表驱动法 A．等价类划分B．因果图法C．正交试验法D．场景法、 7.下列软件实施活动的进入准则描述错误的是：__D____ A．需求工件已经被基线化 B．详细设计工件已经被基线化 C．构架工件已经被基线化 D．项目阶段成果已经被基线化 8.正式的技术评审FTR(Formal Technical Review)是软件工程师组织的软件质 量保证活动，下面关于FTR指导原则中错误的是__C____ A．评审产品，而不是评审生产者的能力 B．要有严格的评审计划，并遵守日程安排
软件测试职业发展方向(最正统)(精)
软件测试职业发展方向(最正统)(精)
现在关于软件测试领域的群体就有4种情况: …低管理,低技术? …低管理,高技术? …高管理,低技术? …高管理,高技术? 好多人对自己测试的职业发展很迷茫,个人觉得这篇文章不错,转给大家分享下,希望能给迷茫的人一点帮助..... 软件测试职业发展方向,大体上可以分为管理路线、技术路线、管理+技术路线。测试初级阶段: 测试工程师,属于软件测试职业生涯的初级域,其适用范围是入行软件测试3年内的常规测试从业者,其主要工作内容是按照测试主管(即直接上司分配的任务计划,编写测试用例、执行测试用例、提交软件缺陷,包括提交阶段性测试报告、参与阶段性评审等。 管理+技术路线: 首先是常规路线,这条发展路线要求管理与技术并重,因为软件测试的行业特点决定了这个因素:测试工程师向上晋升到测试主管、测试经理、测试总监,直至咨询域的更高方向! 测试主管是企业项目级主管,对于中小型软件公司也可以是企业级主管,属于中级发展域,适用范围是2到5年职业经验的测试从业者。其工作内容是根据项目经理或测试经理的计划安排,调配测试工程师执行模块级或项目级测试工作,并控制与监督软件缺陷的追踪,保证每个测试环节与阶段的顺利进行。严格来说,这个级别更多属于测试的设计者,因为企业的测试流程搭建是由更高级别的测试经理或相关管理者来做的,测试主管负责该流程的具体实施;而更多的工作,是思考如何对软件进行更
加深入、全面的测试。测试主管比较有创造性的工作内容就是测试设计,而恰恰很多公司忽略了或没有精力来执行此工作内容!应该说,在一个企业里做了3年左右测试工作的人员,很容易晋升到该职位,而之所以晋升,是与个人测试技术的过硬、测试方法的丰富,加上对测试流程的监控力与执行力的职业素质息息相关! 测试经理是更高级别的测试管理者,属于高级测试方向域。对于大中型软件 公司,该职位尤为重要,并且对其职业要求也比较高,一般适合4到8年的测试从业者,在管理与技术能力双双比较成熟的情况下,可以结合具体环境晋升到该级别。测试经理负责企业级或大型项目级总体测试工作的策划与实施。测试经理除了需要统筹整个企业级或项目级测试流程外,还要对于不同软件架构、不同开发技术下的测试方法进行研究与探索,为企业的测试团队成员提供指导与解决思路,同时还要合理调配不同专项测试的人力资源(如业务测试工程师、自动化测试工程师、白盒测试工程师、性能测试工程师,对软件进行全面的测试;另外,一些企业里,测试经理还需要与客户交流与沟通,负责部分的销售性或技术支持性工作。 测试总监,属于常规发展路线的最高域,该职位一般在大型或跨国型软件企业,或者专向于测试服务型企业有所设立,一般设立测试总监的企业,该职位都相当于CTO 或副总的级别,是企业级或集团级测试工作的最高领导者,驾驭着企业全部的测试与测试相关资源,管理着企业的全部测试及质量类工作。而其职业要求,也是技术与管理双结合。 技术路线: 技术路线中级域: 技术路线,划分为三个半方向,分别是自动化测试工程师、白盒测试工程师、性能测试工程师和认证测试工程师;前三者适用于通用软件测试领域,认证测试工程师乃嵌入式测试领域职位,至少目前仅出现在嵌入式领域。