嵌入式API测试套生成方法和技术
软件学报ISSN 1000-9825, CODEN RUXUEW E-mail: jos@https://www.wendangku.net/doc/5916262985.html,
Journal of Software,2014,25(2):373?385 [doi: 10.13328/https://www.wendangku.net/doc/5916262985.html,ki.jos.004541] https://www.wendangku.net/doc/5916262985.html,
+86-10-62562563 ?中国科学院软件研究所版权所有. Tel/Fax:
?
嵌入式API测试套生成方法和技术
赵会群, 孙晶, 张爆, 王同林
(北方工业大学信息工程学院,北京 100144)
通讯作者: 赵会群, E-mail: zhaohq6625@https://www.wendangku.net/doc/5916262985.html,
摘要: 随着嵌入式计算机系统应用的不断扩展,嵌入式系统的可靠性引起了学术界和工业界的广泛关注,也提
出了很多增进可靠性的方法和技术.然而,现有的方法和技术在测试套生成方面论述不多,所以在处理大批量嵌入式
系统测试工作中遇到了挑战.讨论抽象测试套生成方法和适配技术,提出了LTS(labeled transition system)到
BT(behavior tree)的转换算法,从而使TTCN(test and testing control notation)测试套可以通过转换嵌入式软件的LTS
描述产生.还介绍了基于上述转换算法的嵌入式软件测试工具包,以及一个嵌入式物联网识读器测试案例研究.
关键词: 嵌入式软件;软件测试;测试与测试控制语言;标签转换系统
中图法分类号: TP311文献标识码: A
中文引用格式: 赵会群,孙晶,张爆,王同林.嵌入式API测试套生成方法和技术.软件学报,2014,25(2):373?385.http://www.jos.
https://www.wendangku.net/doc/5916262985.html,/1000-9825/4541.htm
英文引用格式: Zhao HQ, Sun J, Zhang B, Wang TL. Method and technique of test suite generation for embedded API. Ruan Jian
Xue Bao/Journal of Software, 2014,25(2):373?385 (in Chinese).https://www.wendangku.net/doc/5916262985.html,/1000-9825/4541.htm
Method and Technique of Test Suite Generation for Embedded API
ZHAO Hui-Qun, SUN Jing, ZHANG Bao, WANG Tong-Lin
(School of Information Engineering, North China University of Technology, Beijing 100144, China)
Corresponding author: ZHAO Hui-Qun, E-mail: zhaohq6625@https://www.wendangku.net/doc/5916262985.html,
Abstract: With the rapid increase of embedded computer system applications, the reliability of embedded software has drawn particular
attention from researchers and industries. Many methods for testing and verifying reliability of embedded software have been discussed.
However, the existing methods are weak in test suite automatic generation and therefore difficult in tackling large numbers of embedded
computer applications. In this paper, the method and the technique of generating abstract test suite and their adaptation to a computer
platform are presented. An algorithm for translating a LTS (labeled transition system) into BT (behavior tree) is proposed. Consequently,
the TTCN (test and testing control notation) abstract test suite that employs BT as logical structure can automatically be generated with
respect to the LTS description of embedded software. A TTCN tool set based on the translation algorithm for testing embedded software is
introduced, and case study of testing embedded system of Internet of things device is presented.
Key words: embedded software; software testing; TTCN (test and testing control notation); LTS (labeled transition system)
随着计算机系统应用的不断扩展,计算机嵌入式系统在一些关键领域中已经发挥了作用,如物联网、移动
计算、信息物理融合等嵌入式系统应用等等.由于嵌入式系统对资源的限制、对实时性的高要求以及嵌入式软
件与硬件的相关性,使得嵌入式软件的设计、开发和维护遇到了很多新的挑战,其中之一是嵌入式软件分析与
测试方法和技术方面的挑战.
与传统的软件测试方法和技术不同,由于嵌入式软件的运行环境相对封闭,软件发布后维护的代价会很高,
所以在软件发布之前,需要模拟嵌入式运行环境仿真测试软件的可靠性和一致性[1,2].由于运行环境与仿真环境
?基金项目: 国家自然科学基金(61070030, 61370051); 北京市教委人才创新团队计划(4062012)
收稿时间:2013-04-28; 修改时间: 2013-09-29, 2013-12-05; 定稿时间: 2013-12-17
374 Journal of Software 软件学报 V ol.25, No.2, February 2014
存在差异,所以仿真测试的效果往往受到质疑.为了在软件运行过程中实时监控和分析嵌入式系统的运行状态,通常采用插桩式的监控手段,即,在嵌入式软件中插入侦听代码,以便及时报告系统运行状态[3,4].由于嵌入式系统对资源和实时性要求高,所以插桩测试与分析方法在一定程度上受到限制.
随着软件规模的增大,软件测试的代价也在急剧增加.通常,软件测试费用要占软件开发周期总投入的50%
以上[5].为了降低测试环节的成本,测试用例(套)的自动生成、
测试用例的简化成为技术关键,也引起了学术界的关注,成为热点研究问题.目前,对测试用例生成的研究比较多,也取得了显著的研究成果,如,王林章等人[6]基于UML 协作图设计了一种测试用例生成方法,不仅根据协作图中的消息,而且还对消息后继中对象可能的实现和
调用场景产生测试用例;张智秩等人[7]针对测试用例由于软件演化而失效的问题,研究如何从测试用例选择、
修复和扩增这3个方面解决测试用例演化的问题;聂长海等人[8]针对被测计算机系统测试各种参数组合测试中测试表生成的效率问题,提出最佳配置点决策的贪心算法,解决了因影响因素多而不容易配置决策点的问题; Fraser 等人[9]提出了一种基于模型检测反例自动生成测试套的方法,给出模型检测和软件测试相结合的软件可靠性保障的方法.嵌入式软件的测试用例生成研究也是如此[10,11].
测试套不仅是测试用例的集合,同时还包括测试用例执行环境的配置参数、测试用例执行的步骤和指 令[12].在基于模型的测试(model based test,简称MBT)[13]方法中,为了优化测试用例,往往只关注测试用例的效能,而把测试环境的配置和执行步骤等细节留在执行测试过程中进行,这样可以提高测试用例的效能,也给测试套增加了可伸缩性,这种测试套称为抽象测试套.TTCN 是ISO/ETSI 颁布的测试与测试控制语言,用于描写抽象测试套[14].
测试套生成是一项具有挑战性的技术,一方面需要根据软件规范说明生成某种抽象测试套描述语言程序,另一方面需要将抽象测试套配置到具体的执行环境中.鉴于测试用例自动生成已经有很好的研究成果,本文将结合物联网软件测试需求,集中讨论嵌入式软件测试套生成的方法和技术.采用LTS 图作为嵌入式系统软件规格说明描述工具,采用TTCN-3作为抽象测试套描述语言,研究LTS 到TTCN-3自动转换的算法;采用嵌入式系统API 函数反向插入技术,解决TTCN 抽象测试套的适配问题.
本文第1节讨论基于LTS 的TTCN-3测试套生成算法以及测试用例的生成算法.第2节结合物联网识读器测试需求,讨论嵌入式软件抽象测试套的适配方法和技术.第3节应用上述研究结论、案例研究物联网识读器测试套生成实现.第4节介绍相关研究工作并给出本文研究结论.
1 基础知识
简单介绍测试套生成算法的基础知识,给出标签转换系统、μ-演算和行为树的概念.
1.1 标签转换系统(LTS )
标签转换系统LTS [15,16]由状态集合、状态之间转换集合和转换使能活动集合构成,定义如下:
定义1. 设A 和P 分别为活动和谓词集合,一个基于A 和P 的标签转换系统是一个四元组?S ,I ,→,B ?.其中, 1)
S 是状态集合. 2)
I ∈S 是状态集合中一个可区分的状态,称为初态. 3)
→是一个二元关系结合,a S S ??→?×称为转换,记为.a s t ??→其中,s ,t ∈S ;a ∈A 是一个转换使能活动. 4) B 是一个二元关系集合B ?S ×P ,记为:s B p ,称谓词p ∈P 在状态s ∈S 被满足.
LTSs 也称为Kripke 结构,是经典的模态逻辑模型,常用于并行理论中表达系统状态在活动的作用下实现系统进化的过程.
定义2. 设LTS =(S ,I ,→,B )是一个标签转化系统,称集合L (LTS )?A ×S ×P ={?a ,s ,p ?|a t s ??
→,t ,s ∈S ,a ∈A ,p ∈P }是 一个标签类,记为L .特别地,当L 用μ-calculus 状态公式编码时,称L 为LTS 的一个实例,记为LI .
例如,S ={0,1,2},I ={0},→={?0,1?,?1,1?*,?1,2?},P ={True,False},A ={a 0,a 1,a 2,…,a 9}是用数字表示的活动编号. L (LTS )={?a 0,0,True ?,?a 1,1,True ?*,?a 3,2,False ?}表达了一个活动a 0,a 1执行的实例.
赵会群 等:嵌入式API 测试套生成方法和技术
375
1.2 μ-calculus μ-calculus [17]是一种命题模态逻辑,通常用于描述一个LTS 应该满足的性质,并用于模型检验.不仅如此,许多时态逻辑都可以用μ-calculus 进行编码,比如计算树逻辑CTL(computation tree logic,简称CTL)[18].
μ-calculus 中使用状态公式(STATE FORMULAS)描述应该满足逻辑条件.它的产生式定义如下:
F ::=“true”|“false”|“not” F |F 1 “or” F 2|F 1 “and” F 2|F 1 “implies” F 2|F 1 “equ” F 2|“<” R “>” F |
“[” R “]” F |“@” “(” R “)”|X |“mu” X “.” F |“nu” X “.” F .
其中,F 是逻辑公式;R 是正则表达式,产生式定义如下:
R ::=A |“nil”|R 1 “.” R 2|R 1 “|” R 2|R “*”|R “+”.
其中,A 是活动公式,定义如下:
A ::=string |regexp |“true”|“false”|“not” A |A 1 “or” A 2|A 1 “and” A 2|A 1 “implies” A 2|A 1 “equ” A 2.
例如,一个安全性质“没有故障发生”可以表示为[true *.“OPEN!1”.(not “CLOSE!1”)*.“OPEN !2”]false.
1.3 TTCN 行为树
行为树(behavior tree,简称BT)是一种用图形表示的形式化建模语言,通常用于软件工程的系统建模[19].作为一个主流软件测试技术,TTCN 采用行为树描述被测系统的行为.如图1所示,左侧是行为树结构,表示通过控制观察点(point of control and observation,简称PCO)观测到的TTCN 测试套与被测系统之间的交互过程. A
H I C
F J G
E D B Trees
y
y y y y y y y
y y
A
C
F G J D E H I B y y
T i m e r Timer
Fig.1 TTCN behavior trees
图1 TTCN 行为树
所有同一棵子树的姊妹节点表示一个可替换的行为,如图1所示,各个替换集为{A ,B },{C ,D ,E },{F ,G }, {H ,I },{J },但不在同一棵子树的节点不属于同一个替换集合.下面给出行为树和实例的形式化定义.
定义3. 一个TTCN 行为树是一个三元组T =(N ,Φ,r ),其中,
1)
N 是有限行为节点n 1,n 2,…,n m 的集合,节点不一定唯一,因为同一个行为可以发生在不同的情景下. 2)
r 是一个可区分的节点,称为根. 3)
Φ:N →N 是一个函数,对任意的一个节点n 0∈N ,一定有一个节点序列n 1,n 2,…,n k (0≤k ≤m ),称其为n 0的孩子节点,并称n 1,n 2,…,n k 是兄弟节点,或者为同一个替换集合的节点. 4) 每一个节点n i 是一个三元组(ID ,Beha ,Qual ),其中,ID 是节点标示,Beha 表示节点上的操作,Qual 表示
操作的约束.
下面给出行为树实例的概念.
376
Journal of Software 软件学报 V ol.25, No.2, February 2014
定义4. 设T =(N ,Φ,r )是行为树,称B ?Beha ×Qual 是一个行为类,其中,Beha ={Beha 1,Beha 2,…,Beha m ?1,Beha m }, Qual ={Qual 1,Qual 2,…,Qual m ?1,Qual m }.特别地,如果Beha ×Qual 用TTCN 编码,则称B (BT )是行为树的一个实例,记为BI (BT ).
例如,假设Beha ={L !N -DATArequest ,{L ?N -DATAindication ,L ?OTHERwise }},Qual ={pass ,fail ,none }.一个行为树实例为{?L !N -DATArequest ,pass ?,?L ?N -DATAindication ,pass ?},或者{?L !N -DATArequest ,pass ?;?L ?OTHERwise , none ?}.
2 基于LTS 的TTCN -3测试套生成算法
本节讨论TTCN 测试套生成算法.首先给出标签转换系统LTS 到行为树BT 的等价性证明.
2.1 LTS 到BT 的等价变换
首先论证LTS 与BT 的等价性,然后给出LTS 到BT 的转化算法.
定理1. 设LTS =(S ,I ,→,B )是一个标签转换系统,二元关系B 用μ-calculus 编码,则一定存在一个从LTS 实例 到BT 实例的一一映射.
证明:建立一一映射如下:
建立一个BT 的根节点“r ”,让其与LI 中的初始节点“i ”对应.对?l ∈LI (LTS )的所有标签做如下映射和演绎:
? 如果l =a (a ∈A ),则映射L (LTS )?A ×S ×P ={?a ,s ,p ?|a t s ??
→}到{?a ,p ?s },其中,让逻辑值{True,False}分别 映射成行为裁决{pass ,fail };
? 如果l =R 1 “.” R 2,则映射L (LTS )?A ×S ×P ={?l ,s ,p ?|12.R R t s ???→}到{?R 1,p 1?s 1,{?R 2,p 2?s 2}},其中,s 2是s 1的子
树,s 1=s ,p =p 1∧p 2;
? 如果l =R 1 “|” R 2,则映射L (LTS )?A ×S ×P ={?l ,s ,p ?|12|R R t s ???→}到{{?R 1,p 1?s 1},{?R 2,p 2?s 2}},其中,s 1和s 2
属于同一个替换集,s 1和s 2是S 的子树,p =p 1∨p 2;
? 如果l =R 1 “*” R 2,则映射L (LTS )?A ×S ×P ={?t ,s ,p ?|12*R R t s ???→}到{{?R 1,p 1?s 1}*,{?R 2,p 2?s 2}},其中,{?R 1,
p 1?s 1}*表示至少重复1次或者无重复,s 2是s 1的子树,s 1=s ,p =p 1∧p 2;
? 如果l =R 1 “+” R 2,则映射L (LTS )?A ×S ×P ={?l ,s ,p ?|12R R t s +???→}到{{?R 1,p 1?s 1}+,{?R 2,p 2?s 2}},其中,+表示
{?R 1,p 1?s 1}+至少重复1次,s 2是s 1的子树,s 1=s ,p =p 1∧p 2.
因此,定理成立.
定理2. 令BT =(N ,Φ,r )是一个行为树,BI 是它的行为实例,则一定存在一个BI 到LI 的一一映射,使得LI 中 的B 可以用μ-calculus 编码.
证明:根据定理1证明中建立的一一映射可知,可以找到一个逆映射,使得BI 映射到LI 也是一一映射,并且LI 可以用μ-calculus 编码.证毕.
□
根据定理1和定理2可知,LTS 与BT 等价.
2.2 TTCN 抽象测试套生成算法
本节给出TTCN 抽象测试套生成算法.算法分3个部分:
(1) 编辑LI ,建立LTS 描述;
(2) 根据LI (LTS )与BI (BT )的等价关系,生成TTCN 抽象测试套框架;
(3) 根据LI 二元关系B 的μ-calculus 规格说明,提取被测系统测试用例.
算法1. TTCN 抽象测试套生成算法.
(1) 图形输入LTS,编辑LTS 约束
(2) 生成TTCN 抽象测试套框架
Input: LI (LTS )
Output: BI (BT )
赵会群 等:嵌入式API 测试套生成方法和技术
377
Begin
Generate a root node, let r ∈BI
Read a element of LI to record R =?l ,s ,p ?
For each R Do
If l =a then rewrite ?a ,s ,p ? to ?a ,p ?s replace True with pass and False with fail.
If l =R 1 “.” R 2, then rewrite ?R 1.R 2,s ,p ? to 1211122{,,{,}}s s s R p R p ?????
If l =R 1 “|” R 2, then rewrite ?R 1|R 2,s ,p ? to 121122{{,},{,}}s s s s R p R p ??????
If l =R 1 “*” R 2, then rewrite ?R 1*R 2,s ,p ? to 121*1122{{,},{,}}s s s R p R p ?????
If l =R 1 “+” R 2, then rewrite ?R 1+R 2,s ,p ? to 1211122{{,},{,}}s s s R p R p +?????
end
end
(3) 测试用例生成
Input: BI (BT )
Output: Set of Test Case
Begin
Read a element of BI to record N i ={?R i ,p i ?s i }
For each N i Do
If R i =a then ?a ,p i ?∈TC
If R i =R 1 “.” R 2, then ?R 1,p 1?∈TC and ?R 2,p 2?∈TC
If R i =R 1 “|” R 2, then ?R 1,p 1?∈TC and ?R 2,p 2?∈TC
If R i =R 1 “*” R 2, then ?R 1,p 1?}∈TC and ?R 2,p 2?∈TC
//去除重复的测试用例 If R i =R 1 “+” R 2, then ?R 1,p 1?∈TC and ?R 2,p 2?∈TC //去除重复的测试用例 end
end 算法的第1部分可以通过图形编辑方式输入软件系统运行状态描述的LTS 图.第2部分生成TTCN 抽象测试套,用替换集表示BT .为了明确表示替换子集合,采用集合包含符号加以区分.第3部分用?R i ,p i ?s i 表示测试用例.其中,R i 是测试输入;p i 是设计输出,用μ-calculus 的状态公式来表示.按照算法的设计,测试用例可以实现基本路径覆盖.算法的第2部分、第3部分可以同时执行,因此,该算法的时间复杂性应该为O (log n ),n 为LI (LTS )节点个数.
例:一个通信系统的LTS 如图2所示.依照算法2,其BT 和测试用例求解如下:
建立的一一映射,二者之间的对应关系为
LI (LTS )={?Start ,Initial ,True ?,?L !DATArequest ,1,True ?*,?L ?N -DATAindication ,2,True ?,
?L ?OTHERwise ,3,False ?,?L !DATA ,4,True ?*,?L !Disconnect ,5,False ?}.
用μ-calculus 编码LI (LTS )得到:
{?L !DATArequest *.L ?N -DATAindication .L !DATA ?True,?L !DATArequest *.L ?OTHERwise ?False}.
编码后的LI 经过一一映射得到BI 如下:
Map (LI )=BI ={r ,{L !DATArequest ,psaa }1},{{L ?N -DATAindication ,pass }2,{L ?OTHERwise ,Fail }3},
{{L !DATA ,pass }4}.
上述算法为实现TTCN 测试套自动生成提供了支撑.然而,TTCN 测试套仅仅给出了测试执行的逻辑步骤,在测试执行前,还需要针对被测实现进行参数配置,通常把这些工作称为TTCN 适配器实现.一般有两类适配器:平台适配器和被测系统适配器,前者实现对TTCN 运行平台的支持,后者为被测系统配置具体通信方式.下面给出嵌入式系统的适配策略和物联网识读器API 函数测试适配器实现的方法和技术.
378
Journal of Software 软件学报 V ol.25, No.2, February 2014
Fig.2 LTS and BT for communication dialog
图2 一个通信系统的LTS 和BT
3 可伸缩的嵌入式系统适配器实现技术
作为一个国际标准,ISO/ETSI 并没有给出TTCN 适配器的具体实现环节,也没有具体限制平台的结构.本节讨论嵌入式系统软件测试适配器的实现技术.
3.1 TTCN 适配器的结构
按照ISO/ETSI 定义的TTCN 规范,TTCN 测试套需要通过被测系统(system under test,简称SUT)适配器和平台适配器(platform adapter,简称PA)来实现测试套与被测系统的通信,如图3中实线部分所示. MTC
PTC System under test Platform adapter
IN OUT
IN OUT
OUT IN
Test system adapter
OUT IN API-OUT API-IN Fig.3 Architecture of TTCN system
图3 TTCN-3系统体系结构
被测系统适配器的主要任务是完成测试组件端口与被测试系统端口的连接,通过测试组件端口向被测试系统端口发送测试用例,并接收被测系统的反馈.平台适配器是将测试系统适配到网络平台上,同时实现测试系统对被测系统外部函数的同步调用.PA 中的一个重要的部件就是时钟,由它来协调和控制测试套与被测系统的
赵会群等:嵌入式API测试套生成方法和技术379
通信过程.图3中的主测试组件MTC(master testing component,简称MTC)可以同时协调和控制多个并行测试组件PTC(parallel testing component,简称PTC).适配器结构如图3所示.
3.2 嵌入式系统软件测试适配器的设计
为了支持二次开发,嵌入式系统软件一般暴露可供调用的API函数,物联物识读器也为开发商提供了嵌入式API函数.按照EPC Global技术标准[20],EPC识读器API函数应该满足如下基本要求: ? 函数名与参数应该与相关标准一致;
? 函数完成的功能应该与标准一致;
? 函数执行效能虽然与平台有关,但应符合标准的基本要求;
? API函数可以包含非标准规定函数集合,但与标准规定的函数集的交不能为空.
上述基本要求也构成了嵌入式系统软件的测试目的.为了检验嵌入式系统的可靠性和依照标准的一致性,需要逐一对API进行验证.一个具有挑战性的工作是:如何设计嵌入式系统适配器,使其对一类基于标准的API 函数进行自动适配.为此,设计了如图3所示(虚线部分)的嵌入式系统测试适配器.一个关键技术是:在原来的测试系统结构中增加了两个反嵌入式接口,把嵌入式系统软件的API插入平台适配器中,当测试系统通过调用API函数进行测试进程时,可以直接驱动嵌入式系统软件,并反馈测试结果给测试系统.下节将通过一个案例解释该项技术的具体应用和实现.
4 工具开发与实验分析
本节结合美国Impinj公司研发的第二代超高频RFID读写器UQC-R420(A),介绍嵌入式软件测试套测试工具开发与实验测试的分析过程,进一步支持提出方法和技术.
4.1 物联网识读器嵌入式软件抽象测试套的生成
为了方便TTCN抽象测试套设计,ISO/ETSI在发布TTCN核心语言的同时,也给出了与核心语言等价的其他表现形式,其中,GFT(graphical presentation format)图就是TTCN的一种图形化表示,与核心语言的对应关系可以在文献[14]中查到,这里不再赘述.比较LTS图和GFT图,二者之间的等价映射十分简单,而且其逻辑等价性可以根据第1节的论证以及ISO/ETSI标准间接得出,所以,实际开发TTCN抽象测试套的过程中可以采取下面的步骤:
1) 建立LTS到GFT的映射;
2) 建立GFT图到TTCN抽象测试套的映射;
3) 提取LTS状态公式描述的规格说明,并用GFT图的消息序列表述;
4) 提取消息序列,产生测试用例.
经过多年的努力,北方工业大学软件工程研究室开发了一款基于ISO/ETSI的TTCN-3测试工具TTRun1.1.该工具包括:
? 编辑环境,可实现GFT图和TTCN核心语言文本的编辑;
? TTCN核心语言编译器,可以实现GFT到TTCN生成,并把TTCN核心语言程序编译成Java语言执行代码(编译器根据开源代码改写);
? TTCN核心语言适配器库,用于管理各种测试专用适配器.
按照EPC Global标准[20],UQC-R420(A)嵌入了所有LLRP(low level reader protocol)协议规定的识读器管理软件模块,并通过API函数提供二次开发调用接口.图4是物联网识读器的LTS,表现了识读器在接到外部函数调用后,其工作状态的迁移.它共有4个状态,分别是CONNECT,DISABLE,INACTIVE,ACTIVE.图5是与之对应的GFT图编辑器截图,其中,LTS图中的标签对应于GFT图的消息和消息箭头;LTS图中的状态节点对应GFT 图中的控制观察点的消息队列,并按照时间轴依次排列.
380
Journal of Software 软件学报 V ol.25, No.2, February 2014
Fig.4 An LTS of IoT reader system
图4 物联网识读器系统的LTS
Fig.5 Interface copy of GFT model
图5 GFT 模型界面
4.2 物联网识读器嵌入式软件测试适配器的实现
TTRun1.1设计实现了一个适配器库,用于管理各类适配器的配置、维护以及测试用例的编码/解码.针对物联网识读器嵌入式软件API 测试的特点,开发了一个专用的适配器,采用第2节中的适配器结构设计思想,把被测系统的API 函数反嵌入适配器中,嵌入的API 函数有:
demo .connect (“speedwayr -10-61-c 0.local ”);
demo .enableImpinjExtensions (?);
demo .factoryDefault (?);
demo .setReaderConfiguration (?);
demo .deleteAccessSpecs (?);
demo .getReaderConfiguration (?);
赵会群 等:嵌入式API 测试套生成方法和技术
381
demo .addRoSpec (?);
demo .enableRoSpec (?);
demo .startRoSpec (?);
demo .stopRoSpec (?);
demo .disableRoSpec (?);
demo .deleteRoSpec (?);
demo .disconnect (?); 上述API 函数通过import 语句自动加载到适配器中,再经过环境参数配置,如IP 地址等,即可实现识读器被测API 函数的调用,从而完成测试任务.
4.3 测试实验结果分析
针对UQC-R420(A)识读器设计了两个测试实验,分别测试识读器的识读率和状态切换的可靠性.
实验1.
? 测试目的:测试识读器软件ACTIVE 状态下对EPC 标签的识度率.
? 测试方法:选择部分识读器,分别对多个EPC 标签的识读率进行测试.为了得到大样本数据,每个实验重
复10次(表1仅列出5次),根据每次实验所读取的标签个数统计每个识读器的识度率.
? 测试输入:30个EPC 标签,4个识读器.
? 测试工具:TTRun1.1.
? 测试输出:表1和图6.
Table 1 Statistic table of reading rate of UQC-R420
表1 UQC-R420识读器识度率统计表
Reader T1 T2 T3 T4 T5 Reader1 26 25 25 25 25
Reader2 25 25 25 25 25
Reader3 25 26 26 25 26 Reader4 24 27 26 26 26
Fig.6 A statistic chart of reading rate
图6 识读器识读率统计图
? 测试结论:4个被测识读器系统均发生漏读故障,平均识读率约为80%.
? 故障发现:对被测识读器进行冗余测试,即,一个识读器同时附加多个天线对EPC 标签进行识读操作,
并在EPC 标签的上、左、右分别放置天线,这时,识读器的识读率接近100%.因此,漏读故障归结为识读过程中多标签重叠、相互屏蔽干扰所致,并非软件故障.该故障可以通过适当增加天线数来解决
.
10读取次数
0.920.900.880.860.840.820.80准确率 86420识读器读取准确率测试
382
Journal of Software 软件学报 V ol.25, No.2, February 2014
实验2. ? 测试目的:测试识读器工作状态CONNECT,DISABLE,INACTIVE 和ACTIVE 的可靠性.
? 测试方法:选择部分识读器,分别对其进行状态驱动测试,通过连续切换状态20次(表中仅列出5次),获
得状态转换的响应时间,反馈状态的可靠性.
? 测试输入:CONNECT,DISCONNECT,ADD_ROSPECT,DISABLE_ROEPEC,START_ROSPECT,STOP_
ROSPEC 等消息对象测试用例.
? 测试工具:TTRun1.1.
? 测试输出:表2和图7.
Table 2 Feedback time of UQC-R420 reader
表2 UQC-R420识读器响应时间 Reader T1 T2 T3 T4 T5 Reader1 687 297 281 282 297
Reader2 596 282 282 281 281
Reader3 565 297 547 281 297 Reader4 596 282 297 281 297
Fig.7 Feedback time of UQC-R420 reader
图7 识读器UQC-R420响应时间
? 测试结论:4个识读器表现出不一致的工作状态,启动的响应时间不一致.
? 故障发现:在测试过程中,采用网络流量监控机制观察网络状态变化,发现被测识读器的上述功能与网
络状态变化有密切关系;当网络状态不稳定时,会造成输出响应时间不一致的现象.
5 相关研究比较与结论
随着计算机嵌入式系统应用领域的不断扩展,嵌入式系统软件质量保障方法和技术遇到了新的挑战,同时也得到了业界的关注,近期的相关研究也体现得比较明显,主要集中在嵌入软件测试用例生成、模拟测试方法和嵌入式软件代码分析等.
嵌入式软件测试用例生成的研究主要还是沿用传统软件测试方法:首先建立被测系统软件模型,再把模型状态的迁移条件作为测试用例.殷永峰等人[21]针对嵌入式系统软件在实时性和反应式等方面的特点,采用UML 分别建立嵌入式软件的静态和动态测试模型,并基于UML 图提出了嵌入式软件测试用例生成算法.杨广华等 人[22]提出了一种将场景和模式方法用于嵌入式软件测试用例的设计与生成的方法,通过对被测软件系统需求进行分析建模,将建立的场景模型划分到不同的场景模式中,依据场景模式构建测试场景的状态图,遍历场景状态图以获取测试执行路径,确定相关的测试数据,设计并生成测试用例.Conrad 等人[23]结合基于模型的开发方法讨论如何产生测试用例,借助分类树的概念,在逻辑层面辅助测试脚本的生成;再把生成的测试脚本映射到实际识读器响应时间测试20读取次数
800700600500400300200响应时间(m s ) 161284
赵会群等:嵌入式API测试套生成方法和技术383
执行测试中,从而实现从逻辑设计到物理执行的测试过程,文中通过大量实际例子支持测试脚本生成方法.Malte Lochau,Ursula Goltz[24]针对嵌入式软件中人(环境)与设备交互时容易产生错误的现象,建立了交互特性模型——特性网络(feature network),在充分肯定基于模型测试方法在嵌入式软件测试中的作用基础上,提出了基于特性模型的嵌入式软件测试用例生产算法,有效地控制了测试用例的数量,为嵌入式系统测试降低了测试代价.
与传统的白箱测试方法相似,当已知嵌入式系统软件代码的逻辑结构,同时在嵌入式软件系统资源允许的情况下,可以采用插桩的方法,即,通过在源代码中嵌入一段侦听程序来获得嵌入式系统的运行状态信息,从而分析软件系统的可靠性、一致性和性能等特性.程晓菊等人[25]提出了一种基于函数切片的嵌入式软件回归测试用例简约方法,基于函数代码影响域的概念,建立影响域相关的函数依赖图(函数切片),并给出了全局函数依赖到函数切片的转换算法.Hsiung等人[3]提出了一个嵌入式系统验证框架(verifiable embedded real-time application framework,简称VERTAF),生成宿主的模型检验程序代码,实时完成系统的检测任务,框架中采用UML中的类图、时序图和扩展序列作为嵌入式系统的模型描述,VERTAF根据上述描述产生模型检验器的代码.Ganesan等人[4]提出了一个嵌入式系统插桩框架,其主要特点是可以在嵌入式软件开发过程中对代码进行实时的单元测试,从而及早发现代码的缺陷.把该嵌入式系统插桩框架应用于NASA飞机软件生产线,取得了良好的效果.Chae等人[10]发现,随着嵌入式系统的广泛使用,开发实时编译器成为一个不断增长的需求,重定位技术成为嵌入式系统程序编译器的主流技术,然而在执行代码检测时,通常的做法是以源语言代码作为测试用例产生的依据,从而造成测试套冗长.因此,他们提出了一种基于中间代码的测试用例生成方法,可以有效地减少测试用例的数量.Seo等人[11]针对嵌入式系统的限制,开发了一个轻型测试模型,并实现了相应的工具,利用该模型,可以有效地采集测试数据,为分析和评价系统性能提出支持.Suri等人[26]针对嵌入式系统中资源限制、软件功能对资源需求过载等特点,提出了一种容错框架,通过区分功能关键等级,屏蔽次要功能的错误,保证关键功能的执行,从而保证系统的可靠性等级.
与上述研究工作不同,本文主要研究测试套自动生成方法以及利用该方法解决嵌入式软件API函数自动测试问题.虽然测试套包含测试用例选择内容,但本文的重点在测试逻辑执行部分,而在测试用例的选择方面,采用黑箱测试法中的边界值方法,对测试用例选择没有做过多的讨论.案例介绍了美国Impinj公司生产的UQC- R420(A)超高频RFID读写器API函数的可靠性测试工作,虽然该API函数设计符合EPC Global规范,但实现代码并不开放,所以本文也没有涉及代码插桩方法方面的内容,与上述同类研究的内容也有很大的区别.
本文提出了LTS到行为树转换的理论方法,为TTCN抽象测试套生成算法的提出奠定了理论基础.本文还提出了嵌入式系统TTCN测试套自动生成的技术方案,并实际检验了该方案的可行性.该方案的具体步骤为:
1) 根据LTS自动生成嵌入式系统的TTCN抽象测试套,该测试套包含了测试步骤和测试指令.本文第
2.2节中提出的算法阐述了该技术内容.
2) 根据L(LTS)类实例LI中的μ-calculus状态公式编码,自动提取测试例生成.本文第2.2节提出的算法
的第2部分给出了技术细节.
3) 测试环境适配器的设计,实现抽象测试套与被测系统的通信和测试监控.本文第3节给出了完整的技
术实现细节介绍.
由于存在实现技术细节的挑战,所以目前测试套自动生成的方法和技术研究不多见.本文尝试把测试套分成抽象测试套、测试用例和测试适配器这3个步骤来实现,解决了测试套自动生成中技术细节不易实现的难题,对业界有参考价值,对学术界有贡献.
本文仅对LLRP协议实现了物联网识读器测试适配器的通用设计,还不能实现其他嵌入式系统测试的适配工作,为此,我们将在抽象测试套适配器方法和技术方面进一步开展研究工作.
References:
[1] Yin YF, Wang YC, Liu B. Design and implementation of embedded software simulation test script language. Computer
Engineering and Design, 2006,27(12):2130?2132 (in Chinese with English abstract).
384 Journal of Software软件学报 V ol.25, No.2, February 2014
[2] Jiang CW, Yang SK, Liu B. Simulation and modeling for embedded software test. Computer Engineering, 2008,34(4):87?89 (in
Chinese with English abstract).
[3] Hsiung PA, Lin SW. Automatic synthesis and verification of real-time embedded software for mobile and ubiquitous systems.
Computer Languages, Systems & Structures, 2008,34:153?169. [doi: 10.1016/j.cl.2007.06.002]
[4] Ganesana D, Lindvall M, McComas D, Bartholomew M, Slegel S, Medina B, Krikhaar R, Verhoef C, Montgomery LP. An analysis
of unit tests of a flight software product line. Science of Computer Programming, 2012. https://www.wendangku.net/doc/5916262985.html,/com/locate/scico [doi: 10.1016/j.scico.2012.02.006]
[5] Amman P, Offutt J. Introduction to Software Testing. Beijing: China Machine Press, 2010. 1?20.
[6] Wang LZ, Li XD, Zheng GL. An approach to generate integration test cases based on UML collaboration diagrams. Acta
Electronica Sinica, 2004,32(8):1290?1296 (in Chinese with English abstract).
[7] Zhang ZY, Chen ZY, Xu BW, Yang R. Research progress on test case evolution. Ruan Jian Xue Bao/Journal of Software, 2013,
24(4):663?674 (in Chinese with English abstract). https://www.wendangku.net/doc/5916262985.html,/1000-9825/4379.htm [doi: 10.3724/SP.J.1001.2013.
04379]
[8] Nie CH, Jiang J. Optimization of configurable greedy algorithm for covering arrays generation. Ruan Jian Xue Bao/Journal of
Software, 2013,24(7):1469?1483 (in Chinese with English abstract). https://www.wendangku.net/doc/5916262985.html,/1000-9825/4326.htm [doi: 10.3724/ SP.J.1001.2013.04326]
[9] Fraser G, Wotawa F, Ammann P. Issues in using model checkers for test case generation. Journal of Systems and Software, 2009,
82:1403?1418. [doi: 10.1016/j.jss.2009.05.016]
[10] Chae HS, Woo G, Kim TY, Bae JH, Kim WY. An automated approach to reducing test suites for testing retargeted C compilers for
embedded systems. The Journal of Systems and Software, 2011,84:2053?2064. [doi: 10.1016/j.jss.2011.04.023]
[11] Jooyoung Seo, Byoungju Choi, Sueng-wan Yang. Lightweight embedded software performance analysis method by kernel hack
and its industrial field study. The Journal of Systems and Software, 2012,85:28?42. [doi: 10.1016/j.jss.2011.03.049]
[12] Kahlouche H, Viho C, Zendri M. An industrial experiment in automatic generation of executable test suites for a cache coherency
protocol. In: Proc. of the Int’l Workshop on Testing of Communicating Systems (IWTCS’98). Chapman and Hall, 1998. 1?8.
[13] Utting M, Legeard B. Practical Model-Based Testing: A Tools Approach. San Francisco: Morgan Kaufmann Publishers, 2010.
1?456.
[14] ETSI Standard. ETSI ES 201 873-1 V2.2.1-TTCN-3. 2003. https://www.wendangku.net/doc/5916262985.html,/doc/es_20187301v020201p.doc
[15] Tretmans J. Model based testing with labeled transition system, formal methods and testing. Lecture Notes in Computer Science,
2008,4949:1?38. [doi: 10.1007/978-3-540-78917-8_1]
[16] van Glabbeek RJ. Bisimulation. 1993. https://www.wendangku.net/doc/5916262985.html,.au/~rvg/pub/Bisimulation.pdf
[17] Mateescu R. Local model-checking of modal mu-calculus on acyclic labeled transition systems. In: Proc. of the 8th Int’l Conf. on
Tools and Algorithms for the Construction and Analysis of Systems (TACAS 2002). Springer-Verlag, 2002. 1?36.
[18] Antonik A, Huth M. Efficient patterns for model checking partial state spaces in CTL∩LTL. Electronic Note in Theoretical
Computer Science, 2006,58:41?57. [doi: 10.1016/j.entcs.2006.04.004]
[19] Colvin R, Grunske L, Winter K. Probabilistic timed behavior trees, in integrated formal methods. In: Proc. of the 6th Int’l Conf.
(IFM 2007). LNCS 4591,Oxford): Springer-Verlag, 2007. 157?175. [doi: 10.1007/978-3-540-73210-5_9]
[20] EPCglobal. EPC tag data standards. Version 1.1, Rev.1.24, EPCglobal Standard Specification, 2004. https://www.wendangku.net/doc/5916262985.html,/
standards_technology/EPCTagDataSpecification.124.pdf
[21] Yin YF, Liu B, Jiang TM. Test cases generation of embedded software testing based on UML technique. Application Research of
Computers, 2008,25(10):3018?3021 (in Chinese with English abstract).
[22] Yang GH, Qi X, Shi YS. Design of embedded software test cases based on scenario pattern. Computer Engineering, 2010,36(15):
89?91 (in Chinese with English abstract).
[23] Conrad M, Fey I, Sadeghipour S. Systematic model-based testing of embedded automotive software. Electronic Notes in
Theoretical Computer Science, 2005,111:13?26. [doi: 10.1016/j.entcs.2004.12.005]
[24] Lochau M, Goltz U. Feature interaction aware test case generation for embedded control systems. Electronic Notes in Theoretical
Computer Science, 2010,264:37?52. [doi: 10.1016/j.entcs.2010.12.013]
赵会群等:嵌入式API测试套生成方法和技术385
[25] Cheng XJ, Li RF. Study of embedded software regression test based on function slice. Computer Engineering, 2012,38(2):54?56
(in Chinese with English abstract).
[26] Suri N, Jhumka A, Hiller M, Pataricza A, Islam S, Sarbu C. A software integration approach for designing and assessing
dependable embedded systems. The Journal of Systems and Software, 2010,83:1780?1800. [doi: 10.1016/j.jss.2010.04.063]
附中文参考文献:
[1] 殷永峰,王轶辰,刘斌.嵌入式软件仿真测试脚本语言的设计与实现.计算机工程与设计,2006,27(12):2130?2132.
[2] 蒋崇武,杨顺昆,刘斌.面向嵌入式软件测试的仿真建模.计算机工程,2008,34(4):87?89.
[6] 王林章,李宣东,郑国梁.一个基于UML动作图的集成测试用例生成方法.电子学报,2004,32(8):1290?1296.
[7] 张智轶,陈振宇,徐宝文,杨瑞.测试用例演化研究进展.软件学报,2013,24(4):663?674. https://www.wendangku.net/doc/5916262985.html,/1000-9825/4379.htm
[doi: 10.3724/SP.J.1001.2013.04379]
[8] 聂长海,蒋静.覆盖表生成的可配置贪心算法优化.软件学报,2013,24(7):1469?1483. https://www.wendangku.net/doc/5916262985.html,/1000-9825/4326.htm
[doi: 10.3724/SP.J.1001.2013.04326]
[21] 殷永峰,刘斌,姜同敏.基于UML的嵌入式软件测试用例生成方法研究.计算机应用研究,2008,25(10):3018?3021.
[22] 杨广华,齐璇,施寅生.基于场景模式的嵌入式软件测试用例设计.计算机工程,2010,36(15):89?91.
[25] 程晓菊,李仁发.基于函数切片的嵌入式软件回归测试研究.计算机工程,2012,38(2):54?56.
赵会群(1960－),男,辽宁沈阳人,博士,教授,CCF高级会员,主要研究领域为软件工程,物联网.
E-mail: zhaohq6625@https://www.wendangku.net/doc/5916262985.html,
张爆(1990－),男,硕士,主要研究领域为软件测试.
E-mail: 373169359@https://www.wendangku.net/doc/5916262985.html,
孙晶(1968－),女,副教授,主要研究领域为
软件工程.
E-mail: sunjing8248@https://www.wendangku.net/doc/5916262985.html,
王同林(1990－),男,硕士,主要研究领域为
物联网.
E-mail: wangtonglin54@https://www.wendangku.net/doc/5916262985.html,
嵌入式软件测试与一般软件测试之异同研究
嵌入式软件测试与一般软件测试之异同研究 作者：网络转载发布时间：[ 2013/3/5 9:09:17 ]推荐标签： 摘要：随着计算机技术的普及，软件系统已经深入到生活的各个方面，从普通的计算机软件，到银行或超市的终端系统，甚至到手机的软件系统。对软件的质量要求也在不断提高，软件测试及其技术也有了飞速发展。在对软件测试技术相关基本概念研究解析的基础上，分析软件测试起源与发展，保证软件产品的质量、提高产品的可靠性。对于嵌入式软件系统，因其多样性，基于操作系统，使用的开发环境，微控制器都是日益繁多的，所以嵌入式软件测试与普通软件测试相比有其自身的特点。 关键字：软件测试；嵌入式测试；软件质量 1、引言 嵌入式软件的开发和测试也就与普通软件的开发和测试策略有了很大的不同，嵌入式软件系统是一种针对特殊任务、特殊环境而进行特殊设计的定制产品，有其专门的开发环境、软硬件紧密结合、严格的实时要求等特点。使得嵌入式软件测试与普通软件测试虽有相似之处，但有也有其自身独特的特点。 2、软件测试和嵌入式软件测试 2.1 软件测试的定义及目的 软件测试，即Software Testing。软件测试的定义有很多，在1979年出版的一本经典著作《软件测试艺术》（The art of software testing）中，GLEMFORD J.MYERS曾经对软件测试下过如下定义：软件测试就是为了发现错误而执行程序或系统的过程。虽然它不太完善，但放在当时的情况下是可以说的通的。 随着计算机和软件技术的发展，软件应用的复杂性和规模的不断扩大，软件测试技术的研究也取得了很大的突破。早期的定义已经不适用了，许多专家对软件测试提出了各种各样的定义。综合起来，我们可以定义“软件测试是由一个程序的行为在有限测试用例集合上，针对期望的行为的动态验证组成，测试用例是从通常的无限执行域中适当选取的”。
嵌入式系统及应用 实验大纲
《嵌入式系统及应用》课程实验 一、实验课程的性质、目的和任务 性质：《嵌入式系统及应用》课程是自动化专业的专业基础课程，本实验课是该课程教学大纲中规定必修的实验教学内容。 目的和任务：通过实验环节来巩固和加深学生对嵌入式系统的理解，使学生掌握MCS51单片机和ARM的基本原理和应用技术。通过熟悉MCS51开发环境和ARM集成开发环境，使学生掌握嵌入式系统开发的一般规律和方法。在集成开发环境下，进行系统功能程序的编写和调试的训练，掌握嵌入式系统软硬件调试的一般方法和系统设计的能力。 二、实验内容、学时分配及基本要求
三、考核及实验报告 （一）考核 本课程实验为非独立设课，实验成绩占课程总成绩的15%，综合评定实验成绩。（二）实验报告 实验报告应包括： 实验名称 实验目的 实验内容与要求 设计思路（如：分析、程序流程图等） 实验步骤 实验代码（含必要注释） 实验结果分析 实验小结（本题调试过程中遇到的问题和解决方法、注意事项、心得体会等）注：综合型实验需写出系统功能、设计过程 实验报告的要求： 实验报告以文本形式递交，实验报告要书写规范、文字简练、语句通顺、图表清晰。 四、主要仪器设备 硬件：微型计算机；嵌入式系统开发平台。 软件：Keil C51；ADT 五、教材及参考书 教材
[1] 高锋．单片微型计算机原理与接口技术（第二版）．北京：科学出版社，2007 [2] 自编．嵌入式系统及应用 参考书 [1] 王田苗．嵌入式系统设计与实例开发．北京：清华大学出版社，2003 [2] 陈赜．ARM9 嵌入式技术及Linux高级实践教程．北京：北京航空航天大学出版社，2005 [3] 李忠民等．ARM嵌入式VxWorks实践教程．北京：北京航空航天大学出版社，2006
组合测试模型方法
组合测试模型方法 1 基本信息 好的测试都是基于模型的。 由于软件输入空间的无限性，使得测试人员不可能遍历软件的所有输入。其实，遍历软件的所有输入一般也是没有必要的。优秀的测试设计，往往能够从繁多的测试用例中挑选出有效的用例，用尽可能少的测试输入，覆盖尽可能多的软件需求，这离不开合适的测试模型的支持。 所谓测试模型（Test Model）,是测试和测试对象的基本特征、基本关系的抽象。它是测试理论家们根据大量的实际测试应用总结出来的，能够代表某一类应用的内在规律，并对应于适合此类应用的一组测试框架性的东西。 2 组合测试模型 一种相对简单，并且应用十分广泛的模型是组合模型，具有如下特点： 1）、输出是由输入变量之间的逻辑关系决定的。 2）、输出结果不依赖于变量的先后顺序。这一特点是我们理解组合模型的关键。 对于符合组合模型的输入而言，测试用例设计时要注意： 1）、考虑输入变量的不同取值以及这些取值之间的不同组合。 2）、从应用系统中抽象出正确的逻辑表达式，不要遗漏任何一种逻辑组合关系。 在组合模型中最常用的两种测试技术分别为正交设计技术和组合覆盖测试技术。 2.1 正交设计技术介绍： 正交实验设计方法:依据Galois理论,从大量的（实验）数据（测试例）中挑选适量的、有代表性的点（例）,从而合理地安排实验（测试）的一种科学实验设计方法。 采用正交设计法设计测试用例主要包括以下步骤： 确定影响因素。这里的影响因素指对软件运行结果有影响的软件运行条件，一般情况下是指软件的输入以及其它软件运行的环境。这些因素可以通过对软件需求规格、软件概要设计、软件详细设计等文档分析而获得。 确定因素的取值范围或集合。因素的取值范围指软件输入的取值范围或集合以及可用的硬件资源。同样，要通过分析软件需求规格等文档获取这些信息。 确定每个因素的水平。根据因素的取值范围或集合，采用等价类划分、边界值分析等软件测试技术，在每个因素的取值范围或集合里挑选出有效等价类、无效等价类、正好等于、刚刚大于或刚刚小于边界值等有代表性的测试点。例如：对于用下拉框进行输入的字段，下拉框的所有取值都构成了该因素的水平集合。 选择正交表。根据确定的因素和水平，选择合适的正交表。如果没有合适的正交表可用或需要的测试用例个数太多，则要对因素和水平进行调整。 设计测试用例。 2.2 组合覆盖测试技术介绍：
软件测试方法和技术重点和试题与答案
太原理工大学软件测试技术 适用专业：软件工程2011级考试日期：2014.1 时间：120 分钟 一、判断题 1. 测试是调试的一个部分（╳） 2. 软件测试的目的是尽可能多的找出软件的缺陷。（√ ） 3. 程序中隐藏错误的概率与其已发现的错误数成正比（√ ） 4. Beta 测试是验收测试的一种。（√ ） 5. 测试人员要坚持原则，缺陷未修复完坚决不予通过。（√ ） 6. 项目立项前测试人员不需要提交任何工件。（╳） 7. 单元测试能发现约80%的软件缺陷。（√ ） 8. 测试的目的是发现软件中的错误。（√ ） 9. 代码评审是检查源代码是否达到模块设计的要求。（√ ） 10. 自底向上集成需要测试员编写驱动程序。（√ ） 11. 测试是证明软件正确的方法。（╳） 12. 负载测试是验证要检验的系统的能力最高能达到什么程度。（√ ） 13. 测试中应该对有效和无效、期望和不期望的输入都要测试。（√ ）验收测试是由最终用户来实施的。（√ ） 14. 测试人员要坚持原则，缺陷未修复完坚决不予通过。（√ ）黑盒测试也称为结构测试。（╳）集成测试计划在需求分析阶段末提交。（╳） 15. 软件测试的目的是尽可能多的找出软件的缺陷。(√) 16. 自底向上集成需要测试员编写驱动程序。(√) 17. 负载测试是验证要检验的系统的能力最高能达到什么程度。(╳) 18. 测试程序仅仅按预期方式运行就行了。(╳) 19. 不存在质量很高但可靠性很差的产品。(╳) 20. 软件测试员可以对产品说明书进行白盒测试。(╳) 21. 静态白盒测试可以找出遗漏之处和问题。(√) 22. 总是首先设计白盒测试用例。(╳) 23. 可以发布具有配置缺陷的软件产品。(√) 24. 所有软件必须进行某种程度的兼容性测试。(√) 25. 所有软件都有一个用户界面，因此必须测试易用性。(╳) 26. 测试组负责软件质量。(╳) 27. 按照测试实施组织划分，可将软件测试分为开发方测试、用户测试和第三方测试。(√) 28. 好的测试员不懈追求完美。(×) 29. 测试程序仅仅按预期方式运行就行了。( ×) 30. 在没有产品说明书和需求文档的条件下可以进行动态黑盒测试。( √) 31. 静态白盒测试可以找出遗漏之处和问题。( √) 32. 测试错误提示信息不属于文档测试范围。( ×)
嵌入式系统测试方法
GSM手机测试基础知识 测试手机的主要参数有： 1）发射功率等级TX power level（5～19） 2）频率误差frequency FER 3）相位误差Phase PER 4）射频频谱RF Spectrum 5）开关谱SwitchSpectrum 6）接受灵敏度RX Sensitivity 7）调制谱Modulation Spectrum 测试系统需要的主要设备： 1）模拟基站的综合测试仪如德国罗德-史瓦茨公司的CMU200 2）通信专用电源如2304A双通道移动通讯高速电源，该电源在脉冲负载变化时展现了他显著的电压稳定性，同时能够测量负载电流。对于测试需电池供电的无线通讯设备（例如便捷式电话），在非常短的时间间隔内经历真实的负载变化而言，这种电源是最优化的。 3）手机夹具等 4）测试开发软件labview或VB等labview快速方便 测试过程 实际测量系统的工作过程是首先手机开机，寻找与模拟基站CMU之间的频率同步；然后对PS（电源）与CMU进行初始化；初始化正确完成后在MSC上注册手机IMSI号；建立MS对BS（基站）的呼叫；当呼叫成功时，开始测量手机GSM900参数；首先测量信道1三个功率等级（Lv5，Lv10，Lv15）的发射功率；若符合标准，进入信道1的FER（频率误差）与PER（相位误差）测量；按同样的步骤测量信道62、123的发射功率、FER与PER；测量GSM900的Modulation Spectrum（调制谱）、SwitchSpectrum（开关谱）；从GSM900切换到DCS1800；测量信道512，69 8，885的各发射功率，FER，PER，ModulationSpectrum和SwitchSpectrum；在测量过程中如果任何参数不符合标准，立即显示FAIL并生成报告退出，全部测试完毕显示PASS并生成报告退出。
嵌入式系统实验报告
实验报告 课程名称：嵌入式系统 学院：信息工程 专业：电子信息工程 班级： 学生姓名： 学号： 指导教师： 开课时间：学年第一学期
实验名称：IO接口（跑马灯） 实验时间：11.16 实验成绩： 一、实验目的 1.掌握 STM32F4 基本IO口的使用。 2.使用STM32F4 IO口的推挽输出功能，利用GPIO_Set函数来设置完成对 IO 口的配置。 3.控制STM32F4的IO口输出，实现控制ALIENTEK 探索者STM32F4开发板上的两个LED实现一个类似跑马灯的效果。 二、实验原理 本次实验的关键在于如何控制STM32F4的IO口输出。IO主要由：MODER、OTYPER、OSPEEDR、PUPDR、ODR、IDR、AFRH和AFRL等8个寄存器的控制，并且本次实验主要用到IO口的推挽输出功能，利用GPIO_Set函数来设置，即可完成对IO口的配置。所以可以通过了开发板上的两个LED灯来实现一个类似跑马灯的效果。 三、实验资源 实验器材: 探索者STM32F4开发板 硬件资源: 1.DS0(连接在PF9) 2.DS1(连接在PF10) 四、实验内容及步骤 1.硬件设计 2.软件设计 （1）新建TEST工程，在该工程文件夹下面新建一个 HARDWARE文件夹，用来存储以后与硬件相关的代码。然后在 HARDWARE 文件夹下新建一个LED文件夹，用来存放与LED相关的代码。 （2）打开USER文件夹下的test.uvproj工程，新建一个文件，然后保存在 LED 文件夹下面，保存为 led.c，在led.c中输入相应的代码。
（3）采用 GPIO_Set 函数实现IO配置。LED_Init 调用 GPIO_Set 函数完成对 PF9 和 PF10 ALIENTEK 探索者 STM32F407 开发板教程 119 STM32F4 开发指南(寄存器版) 的模式配置，控制 LED0 和 LED1 输出 1（LED 灭），使两个 LED 的初始化。 （4）新建一个led.h文件，保存在 LED 文件夹下，在led.h中输入相应的代码。 3.下载验证 使用 flymcu 下载（也可以通过JLINK等仿真器下载），如图 1.2所示： 图1.2 运行结果如图1.3所示：
测试用例八大设计方法和实例
测试用例设计方法 1等价类划分 1.1 理论知识 等价类划分是一种典型的黑盒测试方法。这一方法完全不考虑程序的内部结构，只依据程序的规格说明来设计测试用例。 等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭示程序中的错误都是等效的。 等价类合理地假设：某个等价类的代表值，与该等价类的其他值，对于测试来说是等价的。 因此，可以把全部的输入数据划分成若干的等价类，在每一个等价类中取一个数据来进行测试。这样就能以较少的具有代表性的数据进行测试，而取得较好的测试效果。 等价类划分是把所有可能的输入数据,即程序的输入域划分成若干部分（子集）,然后从每一个子集中选取少数具有代表性的数据作为测试用例.该方法是一种重要的,常用的黑盒测试用例设计方法. 1) 分类： 划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类. 有效等价类:是指对于程序的规格说明来说是合理的,有意义的输入数据构成的集合.利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能. 无效等价类:与有效等价类的定义恰巧相反. 设计测试用例时,要同时考虑这两种等价类.因为,软件不仅要能接收合理的数据,也要能经受意外的考验.这样的测试才能确保软件具有更高的可靠性. 2）划分等价类的方法: 下面给出六条确定等价类的原则： ①在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类. ②在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下,可确立一个有效
《嵌入式系统与开发》测试题 - 答案
测试题0及参考答案 （1）ARM汇编程序由指令、指令和指令构成。 （2）ARM C____（A.0X12 B.0X34 C.0X56 D.0X78）（采用小端模式进行存储） （4）一般情况下，ARM微处理器异常处理模式共有___7___种，机器启动后第一条指令执行的是__A___（A.复位异常处理函数指令 B.中断异常处理指令 C.IRQ 异常处理指令 D.指令预取终止异常）。 （5）调用函数FUN(X,Y,Z)，则实参值分别通过__r0__、_r1___、_r2__寄存器来进行传递，如果参数超过4个，则参数传递规则为____通过栈进行传递________。 （6）举例列出一款ARM7TDMI微内核的嵌入式微处理器_S3C44B0X_，ARM920T微内核的嵌入式微处理器_S3C2410_，ARM11内核的嵌入式微处理器__S3C6410____，并列举2款64位ARM微内核_Cortex-A53 __、__Cortex-A57________。 （7）利用汇编和C混合编程，设计代码完成求a,b,c中最大值功能，要求写出汇编启动代码和C代码。 （略）此知识点不需要掌握 测试题1及参考答案 1.嵌入式Linux操作系统包括 bootloader 、内核、文件系统三部分组成。 2.在PC机上Linux系统编译使用的编译器名为 gcc ，ARM处理器嵌入式编译器名为 arm-linux-gcc 。 3.bootloader的功能：①引导操作系统内核启动②提供辅助命令工具。 4.列出最常用的bootloader：、、、、、。 5.在uboot中，打印开发板上环境变量值的命令为 printenv setenv ，假如嵌入式内核名为vmlinux，通过tftp加载内核的命令为
南邮嵌入式系统B实验报告2016年度-2017年度-2
_* 南京邮电大学通信学院 实验报告 实验名称：基于ADS开发环境的程序设计 嵌入式Linux交叉开发环境的建立 嵌入式Linux环境下的程序设计 多线程程序设计 课程名称嵌入式系统B 班级学号 姓名 开课学期2016/2017学年第2学期
实验一基于ADS开发环境的程序设计 一、实验目的 1、学习ADS开发环境的使用； 2、学习和掌握ADS环境下的汇编语言及C语言程序设计； 3、学习和掌握汇编语言及C语言的混合编程方法。 二、实验内容 1、编写和调试汇编语言程序； 2、编写和调试C语言程序； 3、编写和调试汇编语言及C语言的混合程序； 三、实验过程与结果 1、寄存器R0和R1中有两个正整数，求这两个数的最大公约数，结果保存在R3中。 代码1：使用C内嵌汇编 #include
printf("gcdnum:%d\n",a); return 0; } 代码2：使用纯汇编语言 AREA example1,CODE,readonly ENTRY MOV r0, #4 MOV r1, #9 start CMP r0, r1 SUBLT r1, r1, r0 SUBGT r0, r0, r1 BNE start MOV r3, r0 stop B stop END 2、寄存器R0 、R1和R2中有三个正整数，求出其中最大的数，并将其保存在R3中。 代码1：使用纯汇编语言 AREA examp,CODE,READONL Y ENTRY MOV R0,#10 MOV R1,#30 MOV R2,#20 Start CMP R0,R1 BLE lbl_a CMP R0,R2 MOVGT R3,R0 MOVLE R3,R2 B lbl_b lbl_a CMP R1,R2 MOVGT R3,R1 MOVLE R3,R2 lbl_b B . END 代码2：使用C内嵌汇编语言 #include
软件测试用例参考文件
一、功能测试 1、对话框测试输入进行测试。包括中文字符、英文字符、数字字符、特殊字符、及几种字符的组合。 2、对界面可操作按钮进行测试。包括【新增(N)】【保存(S)】【修改(M)】【查询(A)】【打印(P)】【退出(X)】。同时需要对鼠标右键的菜单进行测试。 3、数据保存测试。将1 和2 进行组合。 4、必要条件控制测试。在做了3 时将必要条件(如：a、编号、姓名不可为空b、编号、姓名不可重复)控制测试联合起来。 二、图形界面测试 1.窗体是否能够基于相关的输入或菜单命令适当的打开 2.窗体是否能够改变大小、移动和滚动 3.窗体的数据是否能够利用鼠标、功能键、方向箭头和键盘操作 4.当窗体被覆盖并重新调用后，窗体是否能够正确再生 5.窗体相关的功能是否可以操作 6.是否显示相关的下拉菜单、工具条、滚动条、对话框、按钮、图标和其他控制，既能正确显示又能调用 7.显示多窗体时，窗体名称是否能够正确表示 8.活动窗体是否能够被反显加亮 9.多用户联机时所有窗体是否能够实时更新 10.鼠标无规则点击时是否会产生无法预料的结果 11.窗体声音及提示是否符合既定编程规则 12.窗体是否能够被关闭 13.窗体控件的大小、对齐方向、颜色、背景等属性的设置值是否和程序设计规约相一致 14.窗体控件布局是否合理、美观 15.窗体控件TAB 顺序是否从左到右，从上到下 16.窗体焦点是否按照编程规范落在既定的控件上 17.窗体画面文字（全、半角、格式、拼写）是否正确 18.鼠标有多个形状时是否能够被窗体识别（如漏斗状时窗体不接受输入）
三、功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。常用的测试方法如下： 1.页面链接检查：每一个链接是否都有对应的页面，并且页面之间切换正确。 2.相关性检查：删除/增加一项会不会对其他项产生影响，如果产生影响，这些影响是否都正确。 3.检查按钮的功能是否正确：如update, cancel, delete, save 等功能是否正确。 4.字符串长度检查: 输入超出需求所说明的字符串长度的内容, 看系统是否检查字符串长度,会不会出错. 5.字符类型检查: 在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型,会否报错. 6.标点符号检查: 输入内容包括各种标点符号,特别是空格,各种引号,回车键.看系统处理是否正确. 7.中文字符处理: 在可以输入中文的系统输入中文,看会否出现乱码或出错. 8.检查带出信息的完整性: 在查看信息和update 信息时,查看所填写的信息是不是全部带出.,带出信息和添加的是否一致 9.信息重复: 在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理. 10.检查删除功能:在一些可以一次删除多个信息的地方,不选择任何信息,按”delete”,看系统如何处理,会否出错;然后选择一个和多个信息,进行删除,看是否正确处理. 11.检查添加和修改是否一致: 检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填;添加规定为整型的项,修改也必须为整型. 12.检查修改重名:修改时把不能重名的项改为已存在的内容,看会否处理,报错.同时,也要注意,会不会报和自己重名的错. 13.重复提交表单：一条已经成功提交的纪录，back 后再提交，看看系统是否做了处理。 14.检查多次使用back 键的情况: 在有back 的地方,back,回到原来页面,再back,重复多次,看会否出错. 15.search 检查: 在有search 功能的地方输入系统存在和不存在的内容,看search 结果是否正确.如果可以输入多个search 条件,可以同时添加合理和不合理的条件,看系统处理是否
嵌入式软件测试(参考答案)
一、填空题:（10题,每题2分,共20分）1、嵌入式系统是计算机技术、通信技术、半导体技术、微电子技术、语音图像数据传输技术,甚至传感器等先进技术和具体应用对象相结合后的更新换代产品。 2、ARM 处理器当前主要有6个系列产品:ARM7、ARM9、ARM9E、 ARM10E SecurCore及最新的ARM11 系列。 3 、实时是嵌入式系统的主要特征, 根据截止时间的要求,可将实时分为硬实时和软实时。 4、嵌入式应用软件典型的开发方式是宿主机/ 目标机方式。 5、MISRA C已经被越来越多的企业接受，成为用于嵌入式系统的C语言标准, 特别是对安全性要求极高的嵌入式系统，其软件应完全符合MISRA标准。 6、插桩也称为打点,是在程序中插入额外的代码来获得程序在执行时有关行为信息的一种重要手段,属于动态测试的一种常用技术。 7、等价类划分的目的就是为了在有限的测试资源的情况下,用少量有代表性 的数据得到比较好的测试效果。 8、测试报告是把测试的过程和结果写成文档,并对发现的问题和缺陷进行分析,为纠正软件的存在的质量问题提供依据,同时为软件验收和交付打下基础。 9、TEmb作为一种全新的嵌入式软件结构化测试方法，覆盖了测试过程中的一些关键步骤,回答了“做什么、什么时候做、如何做、用什么方法做和谁去做”的问题。10、嵌入式软件测试自动化就是希望能够通过嵌入式软件测试自动化工具或其他的实现手段,按照测试人员预订的计划进行自动地嵌入式软件测试工 作。 二、选择题:（10题,每题2分,共20分） 1、嵌入式系统是集软硬件于一体的可独立工作的“器件”主,要包括 ___ A___、__ B___、__C _ 、___D___。 A 嵌入式微处理器
嵌入式系统综合实验一
实验名称： 姓名： 学号： 装 订 线 P.1 实验报告 课程名称： 嵌入式系统设计 指导老师：马永昌 成绩：________________ 实验名称：综合实验一dht11和人体感应传感器 实验类型：验证型 同组学生姓名：孙凡原 一、实验目的和要求（必填） 二、实验内容和原理（必填） 三、主要仪器设备（必填） 四、操作方法和实验步骤 五、实验数据记录和处理 六、实验结果与分析（必填） 七、讨论、心得 一、实验目的和要求 1.掌握字符设备驱动程序的基本结构和开发方法 2.掌握用户空间调用设备驱动的方法 3.掌握用户和内核的交互 二、实验内容和原理 1.编写温湿度传感器DHT11驱动，传输打印温湿度信息 2.编写人体感应传感器驱动，控制LED 灯亮灭 原理： 温湿度传感器DHT11： 1.引脚图 实际使用传感器没有NC 引脚 2.数据采集 a.数据总时序 用户主机发送一次开始信号后，DHT11 从低功耗模式转换到高速模式，待主机开始信号结束后，DHT11 发 专业：测控技术与仪器 姓名：颜睿 学号：3130103850 日期：2018.4.28 地点：创客空间
装订线送响应信号，送出40bit 的数据，幵触发一次信采集。 b.主机发送起始信号 连接DHT11的DATA引脚的I/O口输出低电平，且低电平保持时间不能小于18ms，然后等待DHT11 作出应答信号。 c.检测从机应答信号 DHT11 的DATA 引脚检测到外部信号有低电平时，等待外部信号低电平结束，延迟后DHT11 的DATA引脚处于输出状态，输出80 微秒的低电平作为应答信号，紧接着输出80 微秒的高电平通知外设准备接收数据。 d.接收数据 （1）数据判定规则 位数据“0”的格式为：50 微秒的低电平和26-28 微秒的高电平，位数据“1”的格式为：50 微秒的低电平加70微秒的高电平。 接收数据时可以先等待低电平过去，即等待数据线拉高，再延时60us，因为60us大于28us且小于70us，再检测此时数据线是否为高，如果为高，则数据判定为1，否则为0。
组合测试用例工具讲解
组合测试用例工具介绍 绿光 根据我自己使用的情况，给大家介绍两款组合用例测试工具，pict和allpairs。Pict和allpairs都是基于组合分析的测试用例用具，在测试某些功能时，我们会面对庞大测试用例组合情况，通过pict和allpairs工具可以减少我们的测试用例数，并且可以保持较高的测试覆盖率。 1.PICT 微软开发的工具PICT（Pairwise Independent Combinatorial Testing tool）类似AETG的方法选择候选测试用例，它是基于Pairswise算法程序的工具，可以有效地按照组合原理进行测试用例设计。 1.1 PICT参数文件格式 PICT模型文件，文件中至少包含参数定义。子模型定义及约束定义可选。如下所示：[parameter definitions] 参数定义格式：
c语言单元测试用例全自动生成软件wings介绍
wings是一款用于单元测试测试用例驱动框架自动生成工具，简单来说这款工具主要是全自动生成单元测试驱动代码与测试数据。 下面我们尝试使用wings来完成单元测试框架与测试数据的自动生成。 首先准备好需要测试的C语言工程,本文以大型开源软件Mysql为例。 第一步：打开wings工具，选择被测工程的主要目录。 第二步：点击工程操作中的分析生成，对工程目录下的.c文件进行解析，保存为XML 的格式，生成的文件保存在工程目录下的FunXml与GlobalXml中，分别是函数信息与全局变量的信息，点击驱动文件结构图，即可看到对应文件的函数结构信息。
上图可以查看所有.c文件的驱动函数，以及函数所对应的参数信息与全局变量的信息。 第三步：点击功能操作驱动生成，完成项目的驱动框架自动生成，驱动文件保存在wings_projects下的Driver文件夹下。点击驱动文件，即可看到对应.c文件的驱动生成代码。 点击单个函数，可以高亮定位到函数所在位置，并且双击函数参数，可以定位到每个参数的赋值单元，查看每个参数的具体驱动赋值代码。 第四步：点击值功能操作的值生成按钮，则对应生成测试数据。
界面上显示为单个函数的测试数据，可依据需要修改测试次数，重新生成测试数据文件，也可依据需要修改特定的测试数据。 第五步：将驱动文件加载到所在工程目录，与源文件一起编译，即可运行。 如果想查看对应的函数信息与全局变量信息，则右键对应打开对应的Parameter Struture Description（函数信息结构体）与Global Parameter Struture Description(全局变量结构图)。 Parameter Struture Description（函数信息结构体）:显示函数的名称，参数个数，参数类型以及复杂类型的展开形式。 Global Parameter Struture Description(全局变量结构图)：显示全局变量的结构信息。 使用过程中注意事项： （1）编译源文件过程中，需要手动注释调源文件中的main函数，wings将自动生成调用驱动函数的主函数。 （2）遇到特殊类型的赋值或者系统变量的驱动构造，可自行添加模板赋值方式，添加之后，再次生成驱动文件即可。 例如：遇到FILEL类型的赋值，可在模板中添加对应的赋值方式。
嵌入式系统设计实验四
实验报告 课程名称： 嵌入式系统设计 指导老师：马永昌 成绩：________________ 实验名称：实验四C 语言裸机编程 实验类型：验证型 同组学生姓名：__孙凡原_______ 一、实验目的和要求（必填） 二、实验内容和原理（必填） 三、主要仪器设备（必填） 四、操作方法和实验步骤 五、实验数据记录和处理 六、实验结果与分析（必填） 七、讨论、心得 一、实验目的和要求 ? 初步了解C 运行库 ? 初步了解gcc arm 常用编译选项 ? 了解ARM 中断处理过程 二、实验内容和原理 ? 编写C 裸机代码实现跑马灯，通过控制Timer 中断实现 ? 通过控制uart 串口进行调试打印 三、主要仪器设备 树莓派、PC 机 四、操作方法和实验步骤 1 通过定时器产生中断，控制gpio ，实现跑马灯 2 控制uart 控制器，产生调试打印。 五、实验数据记录和处理 1.主程序arm.c 注释 //包含头文件 #include
软件测试方法和技术练习题与答案
一、判断题 1. 测试是调试的一个部分（╳） 2. 软件测试的目的是尽可能多的找出软件的缺陷。（√） 3. 程序中隐藏错误的概率与其已发现的错误数成正比（√） 4. Beta 测试是验收测试的一种。（√） 5. 测试人员要坚持原则，缺陷未修复完坚决不予通过。（√） 6. 项目立项前测试人员不需要提交任何工件。（╳） 7. 单元测试能发现约80%的软件缺陷。（√） 8. 测试的目的是发现软件中的错误。（√） 9. 代码评审是检查源代码是否达到模块设计的要求。（√） 10. 自底向上集成需要测试员编写驱动程序。（√） 11. 测试是证明软件正确的方法。（╳） 12. 负载测试是验证要检验的系统的能力最高能达到什么程度。（√） 13. 测试中应该对有效和无效、期望和不期望的输入都要测试。（√）验收测试是由最终用户来实施的。（√） 14. 测试人员要坚持原则，缺陷未修复完坚决不予通过。（√） 黑盒测试也称为结构测试。（╳） 集成测试计划在需求分析阶段末提交。（╳） 15. 软件测试的目的是尽可能多的找出软件的缺陷。(√) 16. 自底向上集成需要测试员编写驱动程序。(√) 17. 负载测试是验证要检验的系统的能力最高能达到什么程度。(╳) 18. 测试程序仅仅按预期方式运行就行了。(╳)19. 不存在质量很高但可靠性很差的产品。(╳) 20. 软件测试员可以对产品说明书进行白盒测试。(╳) 21. 静态白盒测试可以找出遗漏之处和问题。(√) 22. 总是首先设计白盒测试用例。(╳) 23. 可以发布具有配置缺陷的软件产品。(√) 24. 所有软件必须进行某种程度的兼容性测试。(√) 25. 所有软件都有一个用户界面，因此必须测试易用性。(╳) 26. 测试组负责软件质量。(╳) 27. 按照测试实施组织划分，可将软件测试分为开发方测试、用户测试和第三方测试。(√) 28. 好的测试员不懈追求完美。(×) 29. 测试程序仅仅按预期方式运行就行了。( ×) 30. 在没有产品说明书和需求文档的条件下可以进行动态黑盒测试。( √) 31. 静态白盒测试可以找出遗漏之处和问题。( √) 32. 测试错误提示信息不属于文档测试范围。( ×) 33. 代码评审是检查源代码是否达到模块设计的要求。(√) 34. 总是首先设计黑盒测试用例。( √) 35. 软件测试是有风险的行为，并非所有的软件缺陷都能够被修复。（∨） 36. 软件质量保证和软件测试是同一层次的概念。（x ） 37. 程序员兼任测试员可以提高工作效率。（x ） 38. 在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。（∨）
嵌入式系统测试方法
目前嵌入式系统的应用领域越来越广泛，与人们的生活也越来越密切。随着嵌入式产品更新换代的加快，软件规模急速膨胀，软件的开发周期却越来越短。硬件发展日益稳定，而软件故障却日益突出，这些故障不仅会造成重大经济损失，甚至危及人的生命安全。软件的重要性逐渐引起人们的重视，提高嵌入式软件的测试质量势在必行。 为什么嵌入式产品发布后，还残留了许多软件缺陷？原因可能很多，我们试列举以下几种： ①嵌入式软件本身特点，如实时性，与硬件结合紧密等导致软件测试难度大。 ②在代码规模巨大、开发周期短等客观条件下，软件测试不足。 ③在测试阶段，要动态覆盖所有条件、所有状况的测试几乎是不可能的。 ④嵌入式软件开发主要使用C语言，而C语言非常灵活，容易造成编码错误。 ⑤项目团队未有效建立/遵守编码规范，留用有缺陷代码等导致可移植性、可维护性方面存在缺陷。 ⑥项目团队的惯性思维，不良编码/测试习惯等因素的影响等。 软件测试的分类方法有很多种，如静态测试、动态测试；单元测试、集成测试、系统测试、确认测试；模拟测试、实机测试等。各种测试方法其对测试阶段、测试环境等要求也各具特点，本文就软件代码检查这种静态测试方法进行探讨。 1.什么是代码检查 代码检查团队以第三方的角度，运用工具/人工的方式对代码进行静态检查。 软件开发团队根据代码检查团队的检查报告，进行缺陷原因分析、影响范围调查、缺陷修改、修改后验证、缺陷预防措施实施及效果确认活动。 2.代码检查种类 ①代码规范（MISRA等C、C++规范）符合性检查 使用MISRA、QAC等代码规范检查工具，对代码规范的符合性进行检查，然后人工对工具输出的警告进行确认。 ②代码逻辑检查 针对代码规范检查工具不能检查的项目，如公用变量的初始化、函数返回值的使用等方面进行人工检查。 ③中断冲突检查。 对因中断或多任务共同访问全局变量而引起的冲突进行人工检查。 ④功能符合性检查。 对看门狗、AD/DA转换等与硬件相关部分的代码进行人工检查。 3.代码检查的特点 ①可在编码～产品发布这一期间内的任何阶段进行。在项目前期通过代码检查可尽可能多地发现缺陷，从而可削减开发成本，提高产品质量。 ②利用第三方的经验、看问题的角度，可以找出自己开发团队因惯性思维、不良编码/测试习惯等因素造成的而自己难于发现的缺陷。 ③不受测试环境、测试设备等客观因素的制约，费用较低。 4.从事代码检查业务的要求 ①拥有一套检查理论、方法和流程。 ②需要一些辅助工具的配合，以提高检查质量和效率。 ③代码检查人员应熟练掌握C/C++编码规则，熟悉编译器原理。对于功能性检查还应熟悉
《单片机系统设计》实验报告
短学期实验报告 （单片机系统设计） 题目： 专业： 指导教师： 学生姓名： 学号： 完成时间： 成绩：
基于单片机的交流电压表设计 目录 1系统的设计要求 (2) 2系统的硬件要求 (2) 2.1真有效值转换电路的分析 (2) 2.2放大电路的设计 (3) 2.3A/D转换电路的设计 (3) 2.4单片机电路的分析 (4) 2.5显示电路 (4) 3 软件设计 (5) 3.1 软件的总流程图 (5) 3.2 初始化定义与定时器初始化流程图 (5) 3.3 A/D转换流程图 (6) 3.4 数据处理流程图 (6) 3.5 数据显示流程图 (7) 4 调试 (7) 4.1 调试准备 (7) 4.2 关键点调试 (7) 4.3 测试结果 (8) 4.4 误差分析 (8) 5结束语 (8) 5.1 总结 (9) 5.2 展望 (9) 附录1 总原理图 (10) 附录2 程序 (10) 附录3 实物图 (14)
基于单片机的交流电压表设计 ****学院 ****专业 姓名 指导老师：******* 1 设计要求 （1）运用单片机实现真有效值的检测和显示。 （2）数据采集使用中断方式，显示内容为有效值与峰值交替进行。 2 硬件设计 本系统是完成一个真有效值的测量和显示，利用AD737将交流电转换成交流电压的有效值，用ADC0804实现模数转换，再通过单片机用数码管来显示。系统原理框图如图2-1所示。系统框图由真有效值转换电路、放大电路、A/D 转换电路、单片机电路、数码管显示电路五部分。 图2-1 原理框图 2.1 真有效值转换电路 真有效值转换电路主要是利用AD737芯片来实现真有效值直流变换的，即将输入的交流信号转换成直流信号的有效值，其原理图如图2-2所示。 图2-2 真有效值转换电路 由于AD737最大输入电压为200mV, 所以需要接两个二极管来限制输入电压，起到限幅的作用。如图中D1、D2，由IN4148构成，电容C6是耦合电容，电阻R1是限流电阻。 2.2 放大电路设计 放大电路主要是利用运放uA741来进行放大，电路原理图如图2-3所示。 A/D 转换 单片机 电路 显示 电路 转换 电路 交流 信号 放大 电路
软件测试方法和技术练习题与答案
一、判断题 1.测试是调试的一个部分（╳） 2.软件测试的目的是尽可能多的找出软件的缺陷。（√） 3.程序中隐藏错误的概率与其已发现的错误数成正比（√） 测试是验收测试的一种。（√） 5.测试人员要坚持原则，缺陷未修复完坚决不予通过。（√） 6.项目立项前测试人员不需要提交任何工件。（╳） 7.单元测试能发现约80%的软件缺陷。（√） 8.测试的目的是发现软件中的错误。（√） 9.代码评审是检查源代码是否达到模块设计的要求。（√） 10.自底向上集成需要测试员编写驱动程序。（√） 11.测试是证明软件正确的方法。（╳） 12.负载测试是验证要检验的系统的能力最高能达到什么程度。（√） 13.测试中应该对有效和无效、期望和不期望的输入都要测试。（√）验收测试是由最终用户来实施的。（√） 14.测试人员要坚持原则，缺陷未修复完坚决不予通过。（√） 黑盒测试也称为结构测试。（╳） 集成测试计划在需求分析阶段末提交。（╳）15.软件测试的目的是尽可能多的找出软件的缺陷。(√) 16.自底向上集成需要测试员编写驱动程序。(√) 17.负载测试是验证要检验的系统的能力最高能达到什么程度。(╳) 18.测试程序仅仅按预期方式运行就行了。(╳) 19.不存在质量很高但可靠性很差的产品。(╳) 20.软件测试员可以对产品说明书进行白盒测试。(╳) 21.静态白盒测试可以找出遗漏之处和问题。(√) 22.总是首先设计白盒测试用例。(╳) 23.可以发布具有配置缺陷的软件产品。(√)24.所有软件必须进行某种程度的兼容性测试。(√) 25.所有软件都有一个用户界面，因此必须测试易用性。(╳) 26.测试组负责软件质量。(╳) 27.按照测试实施组织划分，可将软件测试分为开发方测试、用户测试和第三方测试。(√) 28.好的测试员不懈追求完美。(×) 29.测试程序仅仅按预期方式运行就行了。(×) 30.在没有产品说明书和需求文档的条件下可以进行动态黑盒测试。(√) 31.静态白盒测试可以找出遗漏之处和问题。(√) 32.测试错误提示信息不属于文档测试范围。(×) 33.代码评审是检查源代码是否达到模块设计的要求。(√) 34.总是首先设计黑盒测试用例。(√) 35.软件测试是有风险的行为，并非所有的软件缺陷都能够被修复。（∨） 36.软件质量保证和软件测试是同一层次的概念。（x） 37.程序员兼任测试员可以提高工作效率。（x） 38.在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。（∨） 39.传统测试是在开发的后期才介入，现在测试活动已经扩展到了整个生命周期。（∨）40.传统测试以发现错误为目的，现在测试已经扩展到了错误预防的范畴。∨ 41.软件测试的生命周期包括测试计划、测试设计、测试执行、缺陷跟踪、测试评估。（∨）42.软件生存周期是从软件开始开发到开发结束的整个时期。（x） 43.测试用例的数目越多，测试的效果越好。（x） 44.只要能够达到100％的逻辑覆盖率，就可以保证程序的正确性。（x） 45.单元测试属于动态测试。（∨） 46.验收测试是以最终用户为主的测试。（∨） 47.没有发现错误的测试是没有价值的。（∨） 48.可以把不合格的开发人员安排做测试。（x）