http://blog.knowno.cn/ zh-cn PBlog2 v2.4 http://blog.knowno.cn/images/logos.gif http://blog.knowno.cn/ Bluedreams http://blog.knowno.cn/default.asp?id=168 knowno@foxmail.com(senlin) Thu,19 Apr 2007 11:19:06 +0800 http://blog.knowno.cn/default.asp?id=168 1. 在一条街上，有5座房子，喷了5种颜色
2. 每个房子里住着不同国籍的人
3. 每个人喝不同的饮料，抽不同品牌的香烟，养不同的宠物。
问题：谁养鱼？
提示：1、英国人住红色房子
2、瑞典人养狗
3、丹麦人喝茶
4、绿色房子在白色房子左面
5、绿色房子主人喝咖啡
6、抽PALL MALL香烟的人养鸟
7、黄色房子的主人抽DUNIILL香烟
8、住在中间房子的人喝牛奶
9、挪威人住第一间房
10、抽BLENDS香烟的人住在养猫人的隔壁
11、养马的人住在抽DUNHILL香烟的人隔壁
12、抽BLUE MASTER的人喝啤酒
13、德国人抽BRINCE的香烟
14、挪威人住蓝色房子的隔壁
15、抽BLENDS香烟的人有一个喝水的邻居


答案：
]]> http://blog.knowno.cn/default.asp?id=166 knowno@foxmail.com(senlin) Wed,18 Apr 2007 10:39:37 +0800 http://blog.knowno.cn/default.asp?id=166
  QTP安装后，在 程序 > QuickTest Professional下点击QuickTest Plus，然后按照提示一步步往下安装即可，
  其中要求输入序列号，输入和QTP安装时相同的序列号就可以了（8888-8888888888）。

二、提示和技巧

  plus不仅提供了一些工具，还在它的帮助手册里给出了一些提示和技巧，以及一些实用的Function。
  在这里我把一些比较常用的好东东贴出来，其他的就看plus的帮助吧。

1、创建action template.
    当希望在每一个新建action时都增加一些头部说明，比如作者、创建日期、说明等，用action template
    来实现最简单快捷。
    方法：用记事本等文本编辑器，输入如下类似的内容：
          'Company: xxxx
          'Author: xxx
          'Product: xxx
          'Date: xx
         然后将文件保存为ActionTemplate.mst，并存放到QTP安装目录下的dat目录，重启QTP，新建一个action试试，新建的action会包含以上信息。

2、关于设置测试报告里只显示error的信息。
    帮助中说：修改安装目录下bin\QTReport.ini文件，增加以下内容：
         [FilterDialog]
         ReportAppDefaultFilter=1 # for error only
         ReportAppDefaultFilter=3 # shows all messages (default)
    但根据我的测试结果，不尽其然：
     1)当ReportAppDefaultFilter＝1时，如果Object Repository中缺少对象，在报告中会在相应的
       action前打叉，但不会提示具体错误，而成功的步骤都有具体信息显示。
     2)用Reporter.ReportEvent测试的结果是：
        ReportAppDefaultFilter＝1时，只显示micDone的具体信息；
        ReportAppDefaultFilter＝2时，只显示micFail的具体信息；
        ReportAppDefaultFilter＝3时，只显示micDone和micFail的具体信息；
        ReportAppDefaultFilter＝4时，只显示micPass的具体信息；

    似乎无规律可寻，所以我的结论暂时是：不要设置这个参数，用默认的，显示所有信息，更多的信息有利于分析结果。

3. 启动IE的语句：SystemUtil.Run "iexplore.exe", "http://www.mercuryinteractive.com" 
4. 关闭IE或其他程序的语句：SystemUtil.CloseProcessByName "app.exe"
     or  SystemUtil.CloseProcessByWndTitle "Some Title"

三、Function Libraries

    plus的帮助中提供了一些常用的Function，把这些function copy到文本编辑器中保存为.vbs文件，并添加到Resources中就可以直接调用了，
  或直接copy到你的action中，就可以在当前的action中调用。更推荐第一种方法，所有的action都可以调用。

1、文件操作相关的function，如下，望名则可生意：
    Function CreateFile(sFilename, bOverwrite)；
    Function OpenFile(sFilename, iomode, create)；
    Function AppendToFile(sFilename, sLine)；
    Function WriteToFile(sFilename, sLine)；
    
2、Function NormalizeString(OrgStr)； （将字符串变成regular express）

3、GlobalDictionary的使用，这是另外一种可以共享全局变量的方法，在所有的action中，包括local和external action中都可以访问。

4、使用文件系统相关的function:
    Function ReadLineFromFile (byref FileRef);
    Sub FileDelete ( FilePath);
    Function FileCompare (byref FilePath1, byref FilePath2, byref FilePathDiff, ignoreWhiteSpace);
    Function CheckFileExists (FilePath)

5. web table相关的function:
    Function ItemByKeyColumn(): 根据table中某列的值，得到同一行中另一列的对象。（这个功能非常有用。）
    Function ObjectsByMicClass(Obj, micClass): 得到table中所有的micClass类型的对象集合。


四、工具
  
  1、Automation Generator Utility
     添加一系列动作，然后自动完成。如：启动QTP，然后执行test1, test2, test3...，最后关闭QTP，还可以连接或断开Quality center.
     值得注意的是，每个test都可以分别指定test result文件，这样可以把所有test result指定到同一个目录下，所有test执行完成后，
     用Test Result Viewer就可以快速的查看测试报告。

  2、External Action Call Modifier Utility
     外部Action调用修改工具。当删除一个Reusable action前，如果没有先删除其他test中对它的调用，则打开其他test时，会提示找不到某某
     action，这种情况下启用该工具，工具会列出test下所有调用的外部action（如果调用的action是使用相对路径，则不会列出来），如果外部
     action找不到，会用红色的问号表示，删除它并保存后就OK了。
     也可以在此处修改外部action的来源，修改后原来的action parameter仍会保留。
  
  3、Repository Merge Utility
     合并多个对象库文件中的对象，如果出现冲突，可以选择忽略，或手工合并，或自动合并。
     对象库文件是Action目录下的Resource.mtr文件。

  4. Report Analyzer
     Test Result的另一个查看工具，提供了一些过滤条件，比如只查看failed step, 或只查看checkpoints，或只查看某个action。 ]]> http://blog.knowno.cn/default.asp?id=165 knowno@foxmail.com(senlin) Thu,12 Apr 2007 14:03:56 +0800 http://blog.knowno.cn/default.asp?id=165
文本框的测试

如何对文本框进行测试
a,输入正常的字母或数字。
b,输入已存在的文件的名称；
c,输入超长字符。例如在“名称”框中输入超过允许边界个数的字符，假设最多255个字符，尝试输入     256个字符，检查程序能否正确处理；
d,输入默认值，空白，空格；
e,若只允许输入字母，尝试输入数字；反之；尝试输入字母；
f,利用复制，粘贴等操作强制输入程序不允许的输入数据；
g,输入特殊字符集，例如，NUL及\n等；
h,输入超过文本框长度的字符或文本，检查所输入的内容是否正常显示；
i,输入不符合格式的数据，检查程序是否正常校验，如，程序要求输入年月日格式为yy/mm/dd，实际输入yyyy/mm/dd，程序应该给出错误提示

在测试过程中所用到的测试方法：

1,输入非法数据；
2,输入默认值；
3,输入特殊字符集；
4,输入使缓冲区溢出的数据；
5,输入相同的文件名；

命令按钮控件的测试

测试方法：

a,点击按钮正确响应操作。如，单击确定，正确执行操作；单击取消，退出窗口；
b,对非法的输入或操作给出足够的提示说明，如，输入月工作天数为32时，单击”确定“后系统应提示:天数不能大于31；
c,对可能造成数据无法恢复的操作必须给出确认信息，给用户放弃选择的机会；

单选按钮控件的测试

测试方法：

a,一组单选按钮不能同时选中，只能选中一个。
b,逐一执行每个单选按钮的功能。分别选择了“男”“女”后，保存到数据库的数据应该相应的分别为“男”“女”；
c,一组执行同一功能的单选按钮在初始状态时必须有一个被默认选中，不能同时为空；

up－down控件文本框的测试

测试方法：

a,直接输入数字或用上下箭头控制，如，在“数目”中直接输入10，或者单击向上的箭头，使数目变为10；
b,利用上下箭头控制数字的自动循环，如，当最多数字为253时，单击向上箭头，数目自动变为1；反之亦适用；
c,直接输入超边界值，系统应该提示重新输入；
d,输入默认值，空白。如，“插入”数目为默认值，点击“确定”；或，删除默认值，使内容为空，单击“确定”进行测试；
e,输入字符。此时系统应提示输入有误。

组合列表框的测试

测试方法：

a,条目内容正确，其详细条目内容可以根据需求说明确定；
b,逐一执行列表框中每个条目的功能；
c,检查能否向组合列表框输入数据；

复选框的测试

测试方法：

a,多个复选框可以被同时选中；
b,多个复选框可以被部分选中；
c,多个复选框可以都不被选中；
d,逐一执行每个复选框的功能；

列表框控件的测试

测试方法：

a,条目内容正确；同组合列表框类似，根据需求说明书确定列表的各项内容正确，没有丢失或错误；
b,列表框的内容较多时要使用滚动条；
c,列表框允许多选时，要分别检查shift选中条目，按ctrl选中条目和直接用鼠标选中多项条目的情况；

滚动条控件的测试

要注意一下几点：

a,滚动条的长度根据显示信息的长度或宽度及时变换，这样有利于用户了解显示信息的位置和百分比，如，word中浏览100页文档，浏览到50页时，滚动条位置应处于中间；
b,拖动滚动条，检查屏幕刷新情况，并查看是否有乱码；
c,单击滚动条；
d,用滚轮控制滚动条；
e,滚动条的上下按钮。

各种控件在窗体中混和使用时的测试

a,控件间的相互作用；
b,tab键的顺序，一般是从上到下，从左到右；
c,热键的使用，逐一测试；
d,enter键和esc键的使用；

在测试中，应遵循由简入繁的原则，先进行单个控件功能的测试，确保实现无误后，再进行多个控件的的功能组合的测试。]]> http://blog.knowno.cn/default.asp?id=159 knowno@foxmail.com(senlin) Mon,02 Apr 2007 11:32:39 +0800 http://blog.knowno.cn/default.asp?id=159 1234-5858585858 

TestDirector 7.0.1 
w000000-0000000-0000000-0000000 

TestDirector 7.2 
18AM9CA-H98RD98-P398P38-A3J8AI0 

LoadRunner 6.5 20H-4D82-7F 
license 20H-4D82-7F 

LoadRunner 7.5 AEAMAUIK-YAFEKEKJJKEEA-BCJGI 
Global 100 

LoadRunner 7.5 AEABEXFR-YTIEKEKJJMFKEKEKWBRAUNQJU-KBYGB 
WEB 10000 
dummy8 10 

Serial: 
KWC500R6538415-885 

loadrunner 7.51 
License: BGAUGLIX-AJGI-AEIEKEKJJKEAFJP-BDFHW 


LoadRunner v6.0 SP1 S/n: 9606-4774477437 Key: 20H-4D82-7F 
LoadRunner v5.01 S/n: 9876-5432102521 Key: 218-1-EA1-BB-AD 
LoadRunner Addin for SAP v2.1 S/n: 9876-5432102521 
LoadRunner for DOS S/n: 856464092302113 
LoadRunner v7.0.0 S/nLicense: FNCU-CVBQ-BEFQ 


Quicktest 1.5 & Astra Site Manager v1.08: 
Name: Pirate Company: Pentium Inc. s/n: 999000023AS09128c354 


Astra LoadTest 4.5 
s/n: AEAJIVII-AKEAE-AVEG 

Astra LoadTest 5.4.3 
s/n: BKANCFCV-YKEAF-GJUEG 
(Note: Install as in evalution version and after that goto LoadTest Controller and use this maintena
nce s/n) 

Astra Loadtest 5.4.1.7 
s/n: BKANCFCV-YKEAF-GJUEG 

Astra QuickTest 5.0 
Code: 7972-1234567890 Key: AEAJDDFR-Y-AQBK 

MI注册码大全
WinRunner 7.0.1
1234-5858585858
MercuryInteractive WinRunner v7.60.03 完全版
Install Number:0123-4567890124
Maintenance Number:FF2VLB3CX43FE7GRYIB3W96MVFUFK7UX5IM6DTS2WL4YR8JS4N27M6DWEM9
license:SYFVDM44F9WA76YE4N67L4MHSBUIEAR6IYUZNGA9O6I736DBJPIZCVOCPOUIPACDY22
TestDirector 7.0.1
w000000-0000000-0000000-0000000
TestDirector 7.2
18AM9CA-H98RD98-P398P38-A3J8AI0
TestDirector 7.6
7FFFK-A2722-FF7AC-A6KKN
安装之前将日期往后改几年，如2006-04-02，安装完成后使用期限自然是到2006-06-02.
成功后，在将当前日期改回来，2004-04-02，再进去看看License的使用期限，还是2006-06-02。

TD 7.6 /8.0 License Code 日期限制 合作 缺陷 需求 TestPlan-TestLab
--------------------------------------------------------------------------
7DFDM-8EFEE-EA68C-A6KKN 4个月 无限 25 25 25
NPPPF-WGGGG-RPHWS-UH330 无限 无限 32 16 16
B343P-44B44-43444-6444S (无任何限制)
点击下载此文件
]]> http://blog.knowno.cn/default.asp?id=158 knowno@foxmail.com(senlin) Tue,27 Mar 2007 15:03:47 +0800 http://blog.knowno.cn/default.asp?id=158 1．静态测试：Non-Execution-Based Testing或Static testing
 代码走查：Walkthrough
代码审查：Code Inspection 
技术评审：Review
2．动态测试：Execution-Based Testing
3．白盒测试：White-Box Testing
4．黑盒测试：Black-Box Testing
5．灰盒测试：Gray-Box Testing
6．软件质量保证SQA：Software Quality Assurance
7．软件开发生命周期：Software Development Life Cycle 
8．冒烟测试：Smoke Test
9．回归测试：Regression Test
10．功能测试：Function Testing
11．性能测试：Performance Testing
12．压力测试：Stress Testing
13．负载测试：Volume Testing
14．易用性测试：Usability Testing
15．安装测试：Installation Testing
16．界面测试：UI Testing
17．配置测试：Configuration Testing 
18．文档测试：Documentation Testing
19．兼容性测试：Compatibility Testing
20．安全性测试：Security Testing
21．恢复测试：Recovery Testing
22．单元测试：Unit Tes
23．集成测试：Integration Test
24．系统测试：System Test
25．验收测试：Acceptance Test
26．测试计划应包括：
测试对象：The Test Objectives,
测试范围： The Test  Scope, 
测试策略： The Test  Strategy 
测试方法： The Test  Approach, 
测试过程： The test procedures, 
测试环境： The Test Environment, 
测试完成标准：The test Completion criteria
测试用例：The Test Cases
测试进度表：The Test Schedules
风险：Risks 
  Etc
27．主测试计划： a master test plan
28．需求规格说明书：The Test Specifications
29．需求分析阶段：The Requirements Phase 
30．接口：Interface
31．最终用户：The End User
31．正式的测试环境：Formal Test Environment
32．确认需求：Verifying The Requirements
33．有分歧的需求：Ambiguous Requirements
34．运行和维护：Operation and Maintenance. 
35．可复用性：Reusability
36．可靠性： Reliability/Availability
37．电机电子工程师协会IEEE：The Institute of Electrical and Electronics Engineers)  
38．要从以下几方面测试软件：
正确性：Correctness
实用性：Utility 
性能：Performance
健壮性：Robustness
可靠性：Reliability

关于Bugzilla：
1．Bug按严重程度（Severity）分为：
Blocker，阻碍开发和/或测试工作
Critical，死机，丢失数据，内存溢出
Major，较大的功能缺陷
Normal，普通的功能缺陷
Minor，较轻的功能缺陷
Trivial，产品外观上的问题或一些不影响使用的小毛病，如菜单或对话框中的文字拼写或字体问题等等
Enhancement，建议或意见
2．Bug按报告状态分类（Status）
待确认的（Unconfirmed）
新提交的（New）
已分配的（Assigned）
问题未解决的（Reopened）
待返测的（Resolved）
待归档的（Verified）
已归档的（Closed）
3．Bug处理意见（Resolution）
 已修改的（Fixed）
 不是问题（Invalid）
 无法修改（Wontfix）
 以后版本解决（Later）
 保留（Remind）
 重复（Duplicate）
 无法重现（Worksforme）
]]> http://blog.knowno.cn/default.asp?id=157 knowno@foxmail.com(senlin) Mon,26 Mar 2007 20:23:01 +0800 http://blog.knowno.cn/default.asp?id=157 基本原则是录制脚本要分开、gui文件要合并、批调用回放验证、可移植回放验证。
1.1.1 录制脚本要分开：
脚本太大，不仅不利于以后的维护，并且会导致WinRunner的不可预测的错误产生（具体可以参考WinRunner 的Readme文档）。录制时，可以根据测试用例的流程，拆分为几个小流程，对每个小流程分别录制成不同的脚本。
1.1.2 gui文件要合并：
首先，要在系统参数中，设置gui的录制模式为“Global GUI Map File
录制过程中，WinRunner会自动产生gui文件，一个测试用例要确保生成一个公用gui文件。用一个gui文件主要是为了以后gui对象的维护，脚本回放时gui对象的查找。但是由于我们的测试用例是分开录制的，每个小流程录制时都会产生一个gui临时文件，因此录制完脚本后要把临时gui文件合并到该测试用例的公用gui文件中。但是也要注意，开始新的录制前，一定要先手工加载测试用例的公用gui文件。
如果划分的子流程超过20个，则按每20个子流程录制一个gui文件的方式。Gui文件太大，会影响WinRunner的回放效率。
1.1.3 批调用回放验证：
为了提高脚本的正确性，每录制完成一个子流程后，都要恢复数据库，其他初始环境进行回放，以近早发现脚本错误。
单个测试用例脚本录制完成后，要专门写一个主脚本，进行各子脚本的主次调用处理，然后恢复数据库和其他初始环境进行回放，以验证整个脚本是否可以正确回放。
1.1.4 可移植回放验证：
由于WinRunner 工具的限制，在本机回放成功后，如果把脚本移植到其他机器上，往往无法成功。这其中既有自己编写的脚本问题，又有WinRunner录制自动生成的脚本问题。
自己编写脚本问题：往往是编写的可移植性较差，如加载gui文件时用的是绝对地址，如gui_load(“c:\\aa\\aa.gui”)，这样的脚本换到其他机器必然出错。
WinRunner录制自动生成的脚本问题： WinRunner的录制脚本往往和机器的环境有关，如果换了其他机器环境，往往回放不成功，这就需要手工修改脚本。
因此，可移植性回放是非常必要的。
1.1.5 脚本中使用的ODBC数据源名称统一命名为WR。
1.1.6 录入中文数据时统一使用简体。
1.1.7 数据表列名称规定
录入数据驱动的脚本时，数据表列名称统一采用英文，使用PB数据窗口中列对象的名称。数据表列名称下的第一行用中文对英文列名称做注释，使用PB数据窗口中列对象的中文标签，这一行不作为有效的录入数据。与数据表相关的循环语句请修改脚本从数据表的第二行开始读取数据。典型的例子是将数据驱动脚本中For循环的第一个表达式改为table_Row = 2。
1.1.8 脚本成功回放判定规定
一个子测试录制完成后，一定要及时回放测试，直到测试报告显示测试结果为OK，且子测试明细报告中没有红色的出错提示。如果是回放主测试，回放成功的标准是：主测试的结果报告显示为OK，同时所有子测试的结果报告也为OK,且子测试明细报告中没有红色的出错提示。
1.1.9 WinRuner主脚本中关于设置系统日期时间设置的规定，以保证脚本所描述的业务过程按业务逻辑在时间上有序。
因为脚本回放与脚本录制时的系统日期时间不一致，会导致与系统时间关系密切的测试脚本回放时失败。
为了消除时间差导致的回放错误,要求每一个测试用例的主测试在第一个子测试前加上date_set_system_date(年,月,日,时,分,秒)函数,以修改本地机器的日期时间等于这个主测试在接力式验收回放成功执行后的日期时间.这样再次回放时系统的日期时间就和上一次成功回放时的日期时间一致。

1.2 测试脚本存放规范：
各子测试脚本必须放到同一目录下，即环境目录下的Script目录下。这样便于批调用时引用。
1.3 Gui文件的存放：
Gui 文件，必须和测试脚本放到同一目录下，即环境目录下的Script目录下。
1.4 WinRunner使用规范：
（1） 必须写上清楚的注释：编写测试脚本，要进行详细的标注，每测试一小段，就要写一段备注，以便于将来修改，格式可以参考如下：
   功能描述：描述脚本的功能
   前置条件：该脚本在满足什么条件下才可以被执行
   步骤描述：描述脚本录制的动作
   检查点描述：描述作了对什么的检查，检查条件。
   录入人：录制人
   录入时间：
   备注：
（2） gui文件的加载保存：
每次开始测试用例的录制脚本前，如果该测试用例已经存在gui文件，一定要手工打开gui文件，再开始录制。如果不想手工打开，可以写段自动加载gui的脚本，每次录制前运行一下该脚本。录入脚本后，要注意保存GUI文件，如果测试用例已经存在gui文件，一定要把临时的gui文件合并到该用例的公用gui文件中，然后保存。
（3） 如果机器数据较慢，或者网络较慢、或者数据库运行较慢，需要把等待打开窗口的时间设长。或者在脚本中插入同步点来处理。
（4） WinRunner不支持Fomular One，目前不可以用wr测试Fomular One
使用WinRunner录制时不可以切换不同输入法录制，仅可以用一种输入法。 
（5） WinRunner 对shift 键无法纪录，需要特殊处理 ，可以加入如下处理 
obj_type "dw_1.fslipbugno","<kShift_L>-";（告诉WinRunner按下Shift键）
中间是选择行的脚本
obj_type ("dw_1.FBugNo","<kShift_L>+";（告诉WinRunner释放Shift键）
（6） 保证录制的脚本干净性：
在录制过程中，不可避免的要进行其他动作，如打开邮件、打开非录制程序等，这些动作也会被WinRunner录制下来，这些动作会严重影响测试脚本的回放（除非作这些动作前停止录制）。
因此，为了保证脚本的干净，在WinRunner的参数中进行如下设置：设置Recode 的“Selected Applications” 为要录制的程序。 
（7） 录制脚本时，不允许同时打开两个运行程序（指进行wr测试的程序）
（8） 变量的声明：WinRunner有auto \public \static \extern 四个类型的变量作用域声明，其中public为默认的类型。由于public 是全局的，只要在一个脚本中声明了，在任何其他脚本都可以引用，这就带来一个问题，如果其他的脚本修改了这个public 变量的值，将会引发问题。因此变量声明时必须明确的加上类型（auto \public \static \extern），public 的一般不要使用，推荐使用static \auto 。
2. 异常处理规范：
在录制或者编写测试脚本时，必须进行异常的错误处理。以提高程序的错误检查能力。
2.1 函数异常检测：
对于一些常用函数，必须进行函数执行异常的处理。至少进行如下函数的异常检测：et_window、win_activate、menu_select_item、ddt_open。
发现异常后，要终止程序的执行，并发邮件通知相关人员。
2.2 返回值规范：
模块、函数的返回值约定如下，0 表示成功 ，其他失败。
对于一些函数的返回值，需要进行判断处理：
（1） 每一个call语句都应该检查它的返回值是否为0, 如果不为0则报错退出。
所有GUI检查点、数据库检查点都应做返回值检查。如果不为0则报错退出。 
]]> http://blog.knowno.cn/default.asp?id=156 knowno@foxmail.com(senlin) Mon,26 Mar 2007 17:26:14 +0800 http://blog.knowno.cn/default.asp?id=156
嵌入式计算机系统同通用型计算机系统相比具有以下特点： 

    1.嵌入式系统通常是面向特定应用的嵌入式CPU与通用型的最大不同就是嵌入式CPU大多工作在为特定用户群设计的系统中，它通常都具有低功耗、体积小、集成度高等特点，能够把通用CPU中许多由板卡完成的任务集成在芯片内部，从而有利于嵌入式系统设计趋于小型化，移动能力大大增强，跟网络的耦合也越来越紧密。 

    2.嵌入式系统是将先进的计算机技术、半导体技术和电子技术与各个行业的具体应用相结合后的产物。这一点就决定了它必然是一个技术密集、资金密集、高度分散、不断创新的知识集成系统。 

    3.嵌入式系统的硬件和软件都必须高效率地设计，量体裁衣、去除冗余，力争在同样的硅片面积上实现更高的性能，这样才能在具体应用中对处理器的选择更具有竞争力 

    4.嵌入式系统和具体应用有机地结合在一起，它的升级换代也是和具体产品同步进行，因此嵌入式系统产品一旦进入市场，具有较长的生命周期。 

   5.为了提高执行速度和系统可靠性，嵌入式系统中的软件一般都固化在存储器芯片或单片机本身中，而不是存贮于磁盘等载体中。 

    6.嵌入式系统本身不具备自举开发能力，即使设计完成以后用户通常也是不能对其中的程序功能进行修改的，必须有一套开发工具和环境才能进行开发
]]> http://blog.knowno.cn/default.asp?id=149 knowno@foxmail.com(senlin) Wed,07 Mar 2007 13:34:26 +0800 http://blog.knowno.cn/default.asp?id=149
条件:
有三个开关对应三个密室的三个灯泡,开关可以随意控制,只能进去一次密室

问题:
如何判断每个开关与密室的灯泡是一一对应?]]> http://blog.knowno.cn/default.asp?id=139 knowno@foxmail.com(senlin) Thu,25 Jan 2007 14:47:14 +0800 http://blog.knowno.cn/default.asp?id=139
  一般由用户/客户进行的确认是否可以接受一个产品的验证性测试。

  actual outcome－－实际结果

  被测对象在特定的条件下实际产生的结果。

  Ad Hoc Testing－－随机测试

  测试人员通过随机的尝试系统的功能，试图使系统中断。

  algorithm－－算法

  （1）一个定义好的有限规则集，用于在有限步骤内解决一个问题；（2）执行一个特定任务的任何操作序列。

  algorithm analysis－－算法分析

  一个软件的验证确认任务，用于保证选择的算法是正确的、合适的和稳定的，并且满足所有精确性、规模和时间

  方面的要求。

  Alpha Testing－－Alpha测试

  由选定的用户进行的产品早期性测试。这个测试一般在可控制的环境下进行的。

  analysis－－分析

  （1）分解到一些原子部分或基本原则，以便确定整体的特性；（2）一个推理的过程，显示一个特定的结果是假

  设前提的结果；（3）一个问题的方法研究，并且问题被分解为一些小的相关单元作进一步详细研究。

  anomaly－－异常

  在文档或软件操作中观察到的任何与期望违背的结果。

  application software－－应用软件

  满足特定需要的软件。

  architecture－－构架

  一个系统或组件的组织结构。

  ASQ－－自动化软件质量（Automated Software Quality）

  使用软件工具来提高软件的质量。

  assertion－－断言

  指定一个程序必须已经存在的状态的一个逻辑表达式，或者一组程序变量在程序执行期间的某个点上必须满足的

  条件。

  assertion checking－－断言检查

  用户在程序中嵌入的断言的检查。

  audit－－审计

  一个或一组工作产品的独立检查以评价与规格、标准、契约或其它准则的符合程度。

  audit trail－－审计跟踪

  系统审计活动的一个时间记录。

  Automated Testing－－自动化测试

  使用自动化测试工具来进行测试，这类测试一般不需要人干预，通常在GUI、性能等测试中用得较多。

  第120贴【2004－10－13】：常见测试术语二

  Backus-Naur Form－－BNF范式

  一种分析语言，用于形式化描述语言的语法

  baseline－－基线

  一个已经被正式评审和批准的规格或产品，它作为进一步开发的一个基础，并且必须通过正式的变更流程来变更

  。

  Basic Block－－基本块

  一个或多个顺序的可执行语句块，不包含任何分支语句。

  basis test set－－基本测试集

  根据代码逻辑引出来的一个测试用例集合，它保证能获得100%的分支覆盖。

  behaviour－－行为

  对于一个系统的一个函数的输入和预置条件组合以及需要的反应。一个函数的所有规格包含一个或多个行为。

  benchmark－－标杆/指标/基准

  一个标准，根据该标准可以进行度量或比较。

  Beta Testing－－Beta测试

  在客户场地，由客户进行的对产品预发布版本的测试。这个测试一般是不可控的。

  big-bang testing－－大锤测试/一次性集成测试

  非渐增式集成测试的一种策略，测试的时候把所有系统的组件一次性组合成系统进行测试。

  Black Box Testing－－黑盒测试

  根据软件的规格对软件进行的测试，这类测试不考虑软件内部的运作原理，因此软件对用户来说就像一个黑盒子

  。

  bottom-up testing－－由低向上测试

  渐增式集成测试的一种，其策略是先测试底层的组件，然后逐步加入较高层次的组件进行测试，直到系统所有组

  件都加入到系统。

  boundary value－－边界值

  一个输入或输出值，它处在等价类的边界上。

  boundary value coverage－－边界值覆盖

  通过测试用例，测试组件等价类的所有边界值。

  boundary value testing－－边界值测试

  通过边界值分析方法来生成测试用例的一种测试策略。

  Boundry Value Analysis－－边界值分析

  该分析一般与等价类一起使用。经验认为软件的错误经常在输入的边界上产生，因此边界值分析就是分析软件输

  入边界的一种方法。

  branch－－分支

  在组件中，控制从任何语句到其它任何非直接后续语句的一个条件转换，或者是一个无条件转换。

  branch condition－－分支条件

  branch condition combination coverage－－分支条件组合覆盖

  在每个判定中所有分支条件结果组合被测试用例覆盖到的百分比。

  branch condition combination testing－－分支条件组合测试

  通过执行分支条件结果组合来设计测试用例的一种方法。

  branch condition coverage－－分支条件覆盖

  每个判定中分支条件结果被测试用例覆盖到的百分比。

  branch condition testing－－分支条件测试

  通过执行分支条件结果来设计测试用例的一种方法。

  branch coverage－－分支覆盖

  通过测试执行到的分支的百分比。

  branch outcome－－分支结果

  见判定结果（decision outcome）

  branch point－－分支点

  见判定（decision）

  branch testing－－分支测试

  通过执行分支结果来设计测试用例的一种方法。

  Breadth Testing－－广度测试

  在测试中测试一个产品的所有功能，但是不测试更细节的特性。

  bug－－缺陷

  第121贴【2004－10－14】：常见测试术语三

  capture/playback tool－－捕获/回放工具

  参考capture/replay tool

  Capture/Replay Tool－－捕获/回放工具

  一种测试工具，能够捕获在测试过程中传递给软件的输入，并且能够在以后的时间中，重复这个执行的过程。这

  类工具一般在GUI测试中用的较多。

  CASE－－计算机辅助软件工程（computer aided software engineering）

  用于支持软件开发的一个自动化系统。

  CAST－－计算机辅助测试

  在测试过程中使用计算机软件工具进行辅助的测试。

  cause-effect graph－－因果图

  一个图形，用来表示输入（原因）与结果之间的关系，可以被用来设计测试用例。

  certification －－证明

  一个过程，用于确定一个系统或组件与特定的需求相一致。

  change control－－变更控制

  一个用于计算机系统或系统数据修改的过程，该过程是质量保证程序的一个关键子集，需要被明确的描述。

  code audit －－代码审计

  由一个人、组或工具对源代码进行的一个独立的评审，以验证其与设计规格、程序标准的一致性。正确性和有效

  性也会被评价。

  Code Coverage－－代码覆盖率

  一种分析方法，用于确定在一个测试套执行后，软件的哪些部分被执行到了，哪些部分没有被执行到。

  Code Inspection－－代码检视

  一个正式的同行评审手段，在该评审中，作者的同行根据检查表对程序的逻辑进行提问，并检查其与编码规范的

  一致性。

  Code Walkthrough－－代码走读

  一个非正式的同行评审手段，在该评审中，代码被使用一些简单的测试用例进行人工执行，程序变量的状态被手

  工分析，以分析程序的逻辑和假设。

  code-based testing－－基于代码的测试

  根据从实现中引出的目标设计测试用例。

  coding standards－－编程规范

  一些编程方面需要遵循的标准，包括命名方式、排版格式等内容。

  Compatibility Testing－－兼容性测试

  测试软件是否和系统的其它与之交互的元素之间兼容，如：浏览器、操作系统、硬件等。

  complete path testing －－完全路径测试

  参考穷尽测试（exhaustive testing）

  completeness－－完整性

  实体的所有必须部分必须被包含的属性。

  complexity －－复杂性

  系统或组件难于理解或验证的程度。

  Component－－组件

  一个最小的软件单元，有着独立的规格

  Component Testing－－组件测试

  参考单元测试

  computation data use－－计算数据使用

  一个不在条件中的数据使用。

  computer system security－－计算机系统安全性

  计算机软件和硬件对偶然的或故意的访问、使用、修改或破坏的一种保护机制。

  condition－－条件

  一个不包含布尔操作的布尔表达式，例如：A

  condition coverage－－条件覆盖

  通过测试执行到的条件的百分比。

  condition outcome－－条件结果

  条件为真为假的评价。

  configuration control－－配置控制

  配置管理的一个方面，包括评价、协调、批准、和实现配置项的变更。

  configuration management－－配置管理

  一套技术和管理方面的原则用于确定和文档化一个配置项的功能和物理属性、控制对这些属性的变更、记录和报

  告变更处理和实现的状态、以及验证与指定需求的一致性。

  conformance criterion－－ 一致性标准

  判断组件在一个特定输入值上的行为是否符合规格的一种方法。

  Conformance Testing－－ 一致性测试

  测试一个系统的实现是否和其基于的规格相一致的测试。

  consistency －－ 一致性

  在系统或组件的各组成部分和文档之间没有矛盾，一致的程度。

  consistency checker－－ 一致性检查器

  一个软件工具，用于测试设计规格中需求的一致性和完整性。

  control flow－－控制流

  程序执行中所有可能的事件顺序的一个抽象表示。

  control flow graph－－控制流图

  通过一个组件的可能替换控制流路径的一个图形表示。

  conversion testing－－转换测试

  用于测试已有系统的数据是否能够转换到替代系统上的一种测试。

  corrective maintenance－－故障检修

  用于纠正硬件或软件中故障的维护。

  correctness －－正确性

  软件遵从其规格的程度。

  correctness －－正确性

  软件在其规格、设计和编码中没有故障的程度。软件、文档和其它项满足需求的程度。软件、文档和其它项满足

  用户明显的和隐含的需求的程度。

  coverage －－覆盖率

  用于确定测试所执行到的覆盖项的百分比。

  coverage item－－覆盖项

  作为测试基础的一个入口或属性：如语句、分支、条件等。

  crash－－崩溃

  计算机系统或组件突然并完全的丧失功能。

  criticality－－关键性

  需求、模块、错误、故障、失效或其它项对一个系统的操作或开发影响的程度。

  criticality analysis－－关键性分析

  需求的一种分析，它根据需求的风险情况给每个需求项分配一个关键级别。

  cyclomatic complexity－－循环复杂度

  一个程序中独立路径的数量。

  第122贴【2004－10－19】：常见测试术语四

  data corruption－－数据污染

  违背数据一致性的情况。

  data definition－－数据定义

  一个可执行语句，在该语句上一个变量被赋予了一个值。

  data definition C-use coverage－－数据定义C-use覆盖

  在组件中被测试执行到的数据定义C-use使用对的百分比。

  data definition C-use pair－－数据定义C-use使用对

  一个数据定义和一个计算数据使用，数据使用的值是数据定义的值。

  data definition P-use coverage－－数据定义P-use覆盖

  在组件中被测试执行到的数据定义P-use使用对的百分比。

  data definition P-use pair－－数据定义P-use使用对

  一个数据定义和一个条件数据使用，数据使用的值是数据定义的值。

  data definition-use coverage－－数据定义使用覆盖

  在组件中被测试执行到的数据定义使用对的百分比。

  data definition-use pair －－数据定义使用对

  一个数据定义和一个数据使用，数据使用的值是数据定义的值。

  data definition-use testing－－数据定义使用测试

  以执行数据定义使用对为目标进行测试用例设计的一种技术。

  data dictionary－－数据字典

  （1）一个软件系统中使用的所有数据项名称，以及这些项相关属性的集合。（2）数据流、数据元素、文件、数据基础、和相关处理的一个集合。

  data flow analysis－－数据流分析

  一个软件验证和确认过程，用于保证输入和输出数据和它们的格式是被适当定义的，并且数据流是正确的。

  data flow coverage－－数据流覆盖

  测试覆盖率的度量是根据变量在代码中的使用情况。

  data flow diagram－－数据流图

  把数据源、数据接受、数据存储和数据处理作为节点描述的一个图形，数据之间的逻辑体现为节点之间的边。

  data flow testing－－数据流测试

  根据代码中变量的使用情况进行的测试。

  data integrity－－数据完整性

  一个数据集合完全、正确和一致的程度。

  data use－－数据使用

  一个可执行的语句，在该语句中，变量的值被访问。

  data validation－－数据确认

  用于确认数据不正确、不完整和不合理的过程。

  dead code－－死代码

  在程序操作过程中永远不可能被执行到的代码。

  Debugging－－调试

  发现和去除软件失效根源的过程。

  decision－－判定

  一个程序控制点，在该控制点上，控制流有两个或多个可替换路由。

  Decision condition－－判定条件

  判定内的一个条件。

  decision coverage－－判定覆盖

  在组件中被测试执行到的判定结果的百分比。

  decision outcome－－判定结果

  一个判定的结果，决定控制流走哪条路径。

  decision table－－判定表

  一个表格，用于显示条件和条件导致动作的集合。

  Depth Testing－－深度测试

  执行一个产品的一个特性的所有细节，但不测试所有特性。比较广度测试。

  design of experiments－－实验设计

  一种计划实验的方法，这样适合分析的数据可以被收集。

  design-based testing－－基于设计的测试

  根据软件的构架或详细设计引出测试用例的一种方法。

  desk checking－－桌面检查

  通过手工模拟软件执行的方式进行测试的一种方式。

  diagnostic－－诊断

  检测和隔离故障或失效的过程。

  dirty testing－－肮脏测试

  参考负面测试（negative testing）

  disaster recovery－－灾难恢复

  一个灾难的恢复和重建过程或能力。

  documentation testing －－文档测试

  测试关注于文档的正确性。

  domain－－域

  值被选择的一个集合。

  domain testing－－域测试

  参考等价划分测试（equivalence partition testing）

  dynamic analysis－－动态分析

  根据执行的行为评价一个系统或组件的过程。

  Dynamic Testing－－动态测试

  通过执行软件的手段来测试软件。

  第123贴【2004－10－20】：常见测试术语五

  embedded software－－嵌入式软件

  软件运行在特定硬件设备中，不能独立于硬件存在。这类系统一般要求实时性较高。

  emulator－－仿真

  一个模仿另一个系统的系统或设备，它接受相同的输入并产生相同的输出。

  End-to-End testing－－端到端测试

  在一个模拟现实使用的场景下测试一个完整的应用环境，例如和数据库交互，使用网络通信等。

  entity relationship diagram－－实体关系图

  描述现实世界中实体及它们关系的图形。

  entry point －－入口点

  一个组件的第一个可执行语句。

  Equivalence Class－－等价类

  组件输入或输出域的一个部分，在该部分中，组件的行为从组件的规格上来看认为是相同的。

  equivalence partition coverage－－等价划分覆盖

  在组件中被测试执行到的等价类的百分比。

  equivalence partition testing－－等价划分测试

  根据等价类设计测试用例的一种技术。

  Equivalence Partitioning－－等价划分

  组件的一个测试用例设计技术，该技术从组件的等价类中选取典型的点进行测试。

  error－－错误

  IEEE的定义是：一个人为产生不正确结果的行为。

  error guessing－－错误猜测

  根据测试人员以往的经验猜测可能出现问题的地方来进行用例设计的一种技术。

  error seeding－－错误播种/错误插值

  故意插入一些已知故障（fault）到一个系统中去的过程，目的是为了根据错误检测和跟踪的效率并估计系统中遗

  留缺陷的数量。

  exception－－异常/例外

  一个引起正常程序执行挂起的事件。

  executable statement－－可执行语句

  一个语句在被编译后会转换成目标代码，当程序运行是会被执行，并且可能对程序数据产生动作。

  Exhaustive Testing－－穷尽测试

  测试覆盖软件的所有输入和条件组合。

  exit point－－出口点

  一个组件的最后一个可执行语句。

  expected outcome－－期望结果

  参考预期结果（predicted outcome）。

  第124贴【2004－10－21】：常见测试术语六

  failure－－失效

  软件的行为与其期望的服务相背离。

  fault－－故障

  在软件中一个错误的表现。

  feasible path－－可达路径

  可以通过一组输入值和条件执行到的一条路径。

  feature testing－－特性测试

  参考功能测试（Functional Testing）

  FMEA－－失效模型效果分析（Failure Modes and Effects Analysis）

  可靠性分析中的一种方法，用于在基本组件级别上确认对系统性能有重大影响的失效。

  FMECA－－失效模型效果关键性分析(Failure Modes and Effects Criticality Analysis)

  FMEA的一个扩展，它分析了失效结果的严重性。

  FTA－－故障树分析(Fault Tree Analysis)

  引起一个不需要事件产生的条件和因素的确认和分析，通常是严重影响系统性能、经济性、安全性或其它需要特

  性。

  functional decomposition－－功能分解

  参考模块分解（modular decomposition）

  Functional Specification －－功能规格说明书

  一个详细描述产品特性的文档。

  Functional Testing－－功能测试

  测试一个产品的特性和可操作行为以确定它们满足规格。

  第125贴【2004－10－22】：常见测试术语七

  glass box testing－－玻璃盒测试

  参考白盒测试（White Box Testing）

  IEEE－－美国电子与电器工程师学会（Institute of Electrical and Electronic Engineers）

  incremental testing－－渐增测试

  集成测试的一种，组件逐渐被增加到系统中直到整个系统被集成。

  infeasible path－－不可达路径

  不能够通过任何可能的输入值集合执行到的路径。

  input domain－－输入域

  所有可能输入的集合。

  inspection－－检视

  对文档进行的一种评审形式。

  installability testing－－可安装性测试

  确定系统的安装程序是否正确的测试。

  instrumentation－－插装

  在程序中插入额外的代码以获得程序在执行时行为的信息。

  instrumenter－－插装器

  执行插装的工具

  Integration Testing－－集成测试

  测试一个应用组合后的部分以确保它们的功能在组合之后正确。该测试一般在单元测试之后进行。

  interface－－接口

  两个功能单元的共享边界。

  interface analysis－－接口分析

  分析软件与硬件、用户和其它软件之间接口的需求规格。

  interface testing－－接口测试

  测试系统组件间接口的一种测试。

  invalid inputs－－无效输入

  在程序功能输入域之外的测试数据。

  isolation testing－－孤立测试

  组件测试（单元测试）策略中的一种，把被测组件从其上下文组件之中孤立出来，通过设计驱动和桩进行测试的

  一种方法。

  第126贴【2004－10－25】：常见测试术语八

  Job－－工作

  一个用户定义的要计算机完成的工作单元。

  job control language－－工作控制语言

  用于确定工作顺序，描述它们对操作系统要求并控制它们执行的语言。

  LCSAJ－－线性代码顺序和跳转（Linear Code Sequence And Jump）

  包含三个部分：可执行语句线性顺序的起始，线性顺序的结束，在线性顺序结束处控制流跳转的目标语句。

  LCSAJ coverage－－LCSAJ覆盖

  在组件中被测试执行到的LCSAJ的百分比。

  LCSAJ testing－－LCSAJ测试

  根据LCSAJ设计测试用例的一种技术。

  Load Testing－－负载测试

  通过测试系统在资源超负荷情况下的表现，以发现设计上的错误或验证系统的负载能力。

  logic analysis－－逻辑分析

  （1）评价软件设计的关键安全方程式、算法和控制逻辑的方法。（2）评价程序操作的顺序并且检测可能导致灾难的错误。

  logic-coverage testing－－逻辑覆盖测试

  参考结构化测试用例设计（structural test case design）

  maintainability－－可维护性

  一个软件系统或组件可以被修改的容易程度，这个修改一般是因为缺陷纠正、性能改进或特性增加引起的。

  maintainability testing－－可维护性测试

  测试系统是否满足可维护性目标。

  modified condition/decision coverage－－修改条件/判定覆盖

  在组件中被测试执行到的修改条件/判定的百分比。

  modified condition/decision testing －－修改条件/判定测试

  根据MC/DC设计测试用例的一种技术。

  Monkey Testing－－跳跃式测试

  随机性，跳跃式的测试一个系统，以确定一个系统是否会崩溃。

  MTBF－－平均失效间隔实际（mean time between failures）

  两次失效之间的平均操作时间。

  MTTF－－平均失效时间 （mean time to failure）

  第一次失效之前的平均时间

  MTTR－－平均修复时间（mean time to repair）

  两次修复之间的平均时间

  multiple condition coverage－－多条件覆盖

  参考分支条件组合覆盖（branch condition combination coverage）

  mutation analysis－－变体分析

  一种确定测试用例套完整性的方法，该方法通过判断测试用例套能够区别程序与其变体之间的程度。

  第127贴【2004－10－26】：常见测试术语九

  Negative Testing－－逆向测试/反向测试/负面测试

  测试瞄准于使系统不能工作。

  non-functional requirements testing－－非功能性需求测试

  与功能不相关的需求测试，如：性能测试、可用性测试等。

  N-switch coverage－－N切换覆盖

  在组件中被测试执行到的N转换顺序的百分比。

  N-switch testing－－N切换测试

  根据N转换顺序设计测试用例的一种技术，经常用于状态转换测试中。

  N-transitions－－N转换

  N＋1转换顺序

  operational testing－－可操作性测试

  在系统或组件操作的环境中评价它们的表现。

  output domain－－输出域

  所有可能输出的集合。

  第128贴【2004－10－27】：常见测试术语十

  partition testing－－分类测试

  参考等价划分测试（equivalence partition testing）

  path－－路径

  一个组件从入口到出口的一条可执行语句顺序。

  path coverage－－路径覆盖

  在组件中被测试执行到的路径的百分比。

  path sensitizing－－路径敏感性

  选择一组输入值强制组件走一个给定的路径。

  path testing－－路径测试

  根据路径设计测试用例的一种技术，经常用于状态转换测试中。

  performance testing－－性能测试

  评价一个产品或组件与性能需求是否符合的测试。

  portability testing－－可移植性

  测试瞄准于证明软件可以被移植到指定的硬件或软件平台上。

  Positive Testing－－正向测试

  测试瞄准于显示系统能够正常工作。

  precondition－－预置条件

  环境或状态条件，组件执行之前必须被填充一个特定的输入值。

  predicate－－谓词

  一个逻辑表达式，结果为‘真’或‘假’。

  predicate data use－－谓词数据使用

  在谓词中的一个数据使用。

  program instrumenter－－程序插装

  参考插装（instrumenter）

  progressive testing－－递进测试

  在先前特性回归测试之后对新特性进行测试的一种策略。

  pseudo-random－－伪随机

  看似随机的，实际上是根据预先安排的顺序进行的。

  第129贴【2004－10－28】：常见测试术语十一

  QA－－质量保证（quality assurance）

  （1）已计划的系统性活动，用于保证一个组件、模块或系统遵从已确立的需求。（2）采取的所有活动以保证一

  个开发组织交付的产品满足性能需求和已确立的标准和过程。

  QC－－质量控制（quality control）

  用于获得质量需求的操作技术和过程，如测试活动。

  Race Condition－－竞争状态

  并行问题的根源。对一个共享资源的多个访问，至少包含了一个写操作，但是没有一个机制来协调同时发生的访问。

  recovery testing－－恢复性测试

  验证系统从失效中恢复能力的测试。

  regression analysis and testing－－回归分析和测试

  一个软件验证和确认任务以确定在修改后需要重复测试和分析的范围。

  Regression Testing－－回归测试

  在发生修改之后重新测试先前的测试以保证修改的正确性。

  release－－发布

  一个批准版本的正式通知和分发。

  reliability－－可靠性

  一个系统或组件在规定的条件下在指定的时间内执行其需要功能的能力。

  reliability assessment－－可靠性评价

  确定一个已有系统或组件的可靠性级别的过程。

  requirements-based testing－－基于需求的测试

  根据软件组件的需求导出测试用例的一种设计方法。

  review－－评审

  在产品开发过程中，把产品提交给项目成员、用户、管理者或其它相关人员评价或批准的过程。

  risk－－风险

  不期望效果的可能性和严重性的一个度量。

  risk assessment－－风险评估

  对风险和风险影响的一个完整的评价。

  第130贴【2004－10－29】：常见测试术语十二

  safety－－（生命）安全性

  不会引起人员伤亡、产生疾病、毁坏或损失设备和财产、或者破坏环境。

  safety critical－－严格的安全性

  一个条件、事件、操作、过程或项，它的认识、控制或执行对生命安全性的系统来说是非常关键的。

  Sanity Testing－－理智测试

  软件主要功能成分的简单测试以保证它是否能进行基本的测试。参考冒烟测试

  SDP－－软件开发计划（software development plan）

  用于一个软件产品开发的项目计划。

  security testing－－安全性测试

  验证系统是否符合安全性目标的一种测试。

  security.－－（信息）安全性

  参考计算机系统安全性（computer system security）

  serviceability testing－－可服务性测试

  参考可维护性测试（maintainability testing）

  simple subpath－－简单子路径

  控制流的一个子路径，其中没有不必要的部分被执行。

  simulation－－模拟

  使用另一个系统来表示一个物理的或抽象的系统的选定行为特性。

  simulation－－模拟

  使用一个可执行模型来表示一个对象的行为。

  simulator－－模拟器

  软件验证期间的一个设备、软件程序、或系统，当它给定一个控制的输入时，表现的与一个给定的系统类似。

  第131贴【2004－11－1】：常见测试术语十三

  SLA－－服务级别协议（service level agreement）

  服务提供商与客户之间的一个协议，用于规定服务提供商应当提供什么服务。

  Smoke Testing－－冒烟测试

  对软件主要功能进行快餐式测试。最早来自于硬件测试实践，以确定新的硬件在第一次使用的时候不会着火。

  software development process－－软件开发过程

  一个把用户需求转换为软件产品的开发过程。

  software diversity－－软件多样性

  一种软件开发技术，其中，由不同的程序员或开发组开发的相同规格的不同程序，目的是为了检测错误、增加可靠性。

  software element－－软件元素

  软件开发或维护期间产生或获得的一个可交付的或过程内的文档。

  software engineering－－软件工程

  一个应用于软件开发、操作和维护的系统性的、有纪律的、可量化的方法。

  software engineering environment－－软件工程环境

  执行一个软件工程工作的硬件、软件和固件。

  software life cycle－－软件生命周期

  开始于一个软件产品的构思，结束于该产品不再被使用的这段期间。

  SOP－－标准操作过程（standard operating procedures）

  书面的步骤，这对保证生产和处理的控制是必须的。

  source code－－源代码

  用一种适合于输入到汇编器、编译器或其它转换设备的计算机指令和数据定义。

  source statement－－源语句

  参考语句（statement）

  第132贴【2004－11－2】：常见测试术语十四

  specification－－规格

  组件功能的一个描述，格式是：对指定的输入在指定的条件下的输出。

  specified input－－指定的输入

  一个输入，根据规格能预知其输出。

  spiral model －－螺旋模型

  软件开发过程的一个模型，其中的组成活动，典型的包括需求分析，概要设计，详细设计，编码，集成和测试等活动被迭代的执行直到软件被完成。

  SQL－－结构化查询语句（structured query language）

  在一个关系数据库中查询和处理数据的一种语言。

  state－－状态

  一个系统、组件或模拟可能存在其中的一个条件或模式。

  state diagram－－状态图

  一个图形，描绘一个系统或组件可能假设的状态，并且显示引起或导致一个状态切换到另一个状态的事件或环境。

  state transition－－状态转换

  一个系统或组件的两个允许状态之间的切换。

  state transition testing －－状态转换测试

  根据状态转换来设计测试用例的一种方法。

  statement－－语句

  程序语言的一个实体，是典型的最小可执行单元。

  statement coverage－－语句覆盖

  在一个组件中，通过执行一定的测试用例所能达到的语句覆盖百分比。

  statement testing－－语句测试

  根据语句覆盖来设计测试用例的一种方法。

  Static Analysis－－静态分析

  分析一个程序的执行，但是并不实际执行这个程序。

  第133贴【2004－11－3】：常见测试术语十五

  Static Analyzer－－静态分析器

  进行静态分析的工具。

  Static Testing－－静态测试

  不通过执行来测试一个系统。

  statistical testing－－统计测试

  通过使用对输入统计分布进行分析来构造测试用例的一种测试设计方法。

  stepwise refinement－－逐步优化

  一个结构化软件设计技术，数据和处理步骤首先被广泛的定义，然后被逐步的进行了细化。

  storage testing－－存储测试

  验证系统是否满足指定存储目标的测试。

  Stress Testing－－压力测试

  在规定的规格条件或者超过规定的规格条件下，测试一个系统，以评价其行为。类似负载测试，通常是性能测试

  的一部分。

  structural coverage－－结构化覆盖

  根据组件内部的结构度量覆盖率。

  structural test case design－－结构化测试用例设计

  根据组件内部结构的分析来设计测试用例的一种方法。

  structural testing－－结构化测试

  参考结构化测试用例设计（structural test case design）

  structured basis testing－－结构化的基础测试

  根据代码逻辑设计测试用例来获得100％分支覆盖的一种测试用例设计技术。

  structured design－－结构化设计

  软件设计的任何遵循一定纪律的方法，它按照特定的规则，例如：模块化，有顶向下设计，数据逐步优化，系统

  结构和处理步骤。

  structured programming－－结构化编程

  在结构化程序开发中的任何包含结构化设计和结果的软件开发技术。

  structured walkthrough－－结构化走读

  参考走读（walkthrough）

  第134贴【2004－11－4】：常见测试术语十六

  stub－－桩

  一个软件模块的框架或特殊目标实现，主要用于开发和测试一个组件，该组件调用或依赖这个模块。

  symbolic evaluation－－符号评价

  参考符号执行（symbolic execution）

  symbolic execution－－符号执行

  通过符号表达式来执行程序路径的一种静态分析设计技术。其中，程序的执行被用符号来模拟，例如，使用变量

  名而不是实际值，程序的输出被表示成包含这些符号的逻辑或数学表达式。

  symbolic trace－－符号轨迹

  一个计算机程序通过符号执行是经过的语句分支结果的一个记录。

  syntax testing－－语法分析

  根据输入语法来验证一个系统或组件的测试用例设计技术。

  system analysis－－系统分析

  对一个计划的或现实的系统进行的一个系统性调查以确定系统的功能以及系统与其它系统之间的交互。

  system design－－系统设计

  一个定义硬件和软件构架、组件、模块、接口和数据的过程以满足指定的规格。

  system integration－－系统集成

  一个系统组件的渐增的连接和测试，直到一个完整的系统。

  System Testing－－系统测试

  从一个系统的整体而不是个体上来测试一个系统，并且该测试关注的是规格，而不是系统内部的逻辑。

  第135贴【2004－11－7】：常见测试术语十七

  technical requirements testing－－技术需求测试

  参考非功能需求测试（non-functional requirements testing）

  test automation－－测试自动化

  使用工具来控制测试的执行、结果的比较、测试预置条件的设置、和其它测试控制和报告功能。

  test case－－测试用例

  用于特定目标而开发的一组输入、预置条件和预期结果。

  test case design technique－－测试用例设计技术

  选择和导出测试用例的技术。

  test case suite－－测试用例套

  对被测软件的一个或多个测试用例的集合。

  test comparator－－测试比较器

  一个测试工具用于比较软件实际测试产生的结果与测试用例预期的结果。

  test completion criterion－－测试完成标准

  一个标准用于确定被计划的测试何时完成。

  test coverage－－测试覆盖

  参考覆盖率（Coverage）

  test driver－－测试驱动

  一个程序或测试工具用于根据测试套执行软件。

  test environment－－测试环境

  测试运行其上的软件和硬件环境的描述，以及任何其它与被测软件交互的软件，包括驱动和桩。

  第136贴【2004－11－8】：常见测试术语十八

  test execution－－测试执行

  一个测试用例被被测软件执行，并得到一个结果。

  test execution technique－－测试执行技术

  执行测试用例的技术，包括手工、自动化等。

  test generator－－测试生成器

  根据特定的测试用例产生测试用例的工具。

  test harness－－测试用具

  包含测试驱动和测试比较器的测试工具。

  test log－－测试日志

  一个关于测试执行所有相关细节的时间记录。

  test measurement technique－－测试度量技术

  度量测试覆盖率的技术。

  Test Plan－－测试计划

  一个文档，描述了要进行的测试活动的范围、方法、资源和进度。它确定测试项、被测特性、测试任务、谁执行

  任务，并且任何风险都要冲突计划。

  test procedure－－测试规程

  一个文档，提供详细的测试用例执行指令。

  test records－－测试记录

  对每个测试，明确的记录被测组件的标识、版本，测试规格，和实际结果

  test report－－测试报告

  一个描述系统或组件执行的测试和结果的文档。

  Test Script－－测试脚本

  一般指的是一个特定测试的一系列指令，这些指令可以被自动化测试工具执行。

  Test Specification－－测试规格

  一个文档，用于指定一个软件特性、特性组合或所有特性的测试方法、输入、预期结果和执行条件。

  第137贴【2004－11－9】：常见测试术语十九

  test strategy－－测试策略

  一个简单的高层文档，用于描述测试的大致方法，目标和方向。

  test suite－－测试套

  测试用例和/或测试脚本的一个集合，与一个应用的特定功能或特性相关。

  test target－－测试目标

  一组测试完成标准。

  testability－－可测试性

  一个系统或组件有利于测试标准建立和确定这些标准是否被满足的测试执行的程度。

  Testing－－测试

  IEEE给出的定义是：1）一个执行软件的过程，以验证其满足指定的需求并检测错误。2）一个软件项的分析过程

  以检测已有条件之间的不同，并评价软件项的特性。

  thread testing－－线程测试

  自顶向下测试的一个变化版本，其中，递增的组件集成遵循需求子集的实现。

  time sharing－－时间共享

  一种操作方式，允许两个或多个用户在相同的计算机系统上同时执行计算机程序。其实现可能通过时间片轮转、

  优先级中断等。

  top-down design－－由顶向下设计

  一种设计策略，首先设计最高层的抽象和处理，然后逐步向更低级别进行设计。

  top-down testing－－自顶向下测试

  集成测试的一种策略，首先测试最顶层的组件，其它组件使用桩，然后逐步加入较低层的组件进行测试，直到所

  有组件被集成到系统中。

  traceability－－可跟踪性

  开发过程的两个或多个产品之间关系可以被建立起来的程度，尤其是产品彼此之间有一个前后处理关系。

  traceability analysis－－跟踪性分析

  （1）跟踪概念文档中的软件需求到系统需求；（2）跟踪软件设计描述到软件需求规格，以及软件需求规格到软

  件设计描述；（3）跟踪源代码对应到设计规格，以及设计规格对应到源代码。分析确定它们之间正确性、一致性

  、完整性、精确性的关系。

  traceability matrix－－跟踪矩阵

  一个用于记录两个或多个产品之间关系的矩阵。例如，需求跟踪矩阵是跟踪从需求到设计再到编码的实现。

  第138贴【2004－11－10】：常见测试术语二十

  transaction－－事务/处理

  （1）一个命令、消息或输入记录，它明确或隐含的调用了一个处理活动，例如更新一个文件。（2）用户和系统

  之间的一次交互。（3）在一个数据库管理系统中，完成一个特定目的的处理单元，如恢复、更新、修改或删除一

  个或多个数据元素。

  transform analysis－－事务分析

  系统的结构是根据分析系统需要处理的事务获得的一种分析技术。

  trojan horse－－特洛伊木马

  一种攻击计算机系统的方法，典型的方法是提供一个包含具有攻击性隐含代码的有用程序给用户，在用户执行该

  程序的时候，其隐含的代码对系统进行非法访问，并可能产生破坏。

  truth table－－真值表

  用于逻辑操作的一个操作表格。

  Unit Testing－－单元测试

  测试单个的软件组件，属于白盒测试范畴，其测试基础是软件内部的逻辑。

  Usability Testing－－可用性测试

  测试用户使用和学习产品的容易程度。

  validation－－确认

  根据用户需要确认软件开发的产品的正确性。

  verification－－验证

  评价一个组件或系统以确认给定开发阶段的产品是否满足该阶段开始时设定的标准。

  version－－版本

  一个软件项或软件元素的一个初始发布或一个完整的再发布。

  volume testing－－容量测试

  使用大容量数据测试系统的一种策略。

  Walkthrough－－走读

  一个针对需求、设计或代码的非正式的同行评审，一般由作者发起，由作者的同行参与进行的评审过程。

  waterfall model－－瀑布模型

  软件开发过程模型的一种，包括概念阶段、需求阶段、设计阶段、实现阶段、测试阶段、安装和检查阶段、操作

  和维护阶段，这些阶段按次序进行，可能有部分重叠，但很少会迭代。

  White Box Testing－－白盒测试

  根据软件内部的工作原理分析来进行测试。
]]> http://blog.knowno.cn/default.asp?id=90 knowno@foxmail.com(senlin) Fri,08 Dec 2006 11:50:14 +0800 http://blog.knowno.cn/default.asp?id=90

  在Web工程过程中，基于Web系统的测试、确认和验收是一项重要而富有挑战性的工作。基于Web的系统测试与传统的软件测试不同，它不但需要检查和验证是否按照设计的要求运行，而且还要测试系统在不同用户的浏览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。然而，Internet和Web媒体的不可预见性使测试基于Web的系统变得困难。因此，我们必须为测试和评估复杂的基于Web的系统研究新的方法和技术。 


一般软件的发布周期以月或以年计算，而Web应用的发布周期以天计算甚至以小时计算。Web测试人员必须处理更短的发布周期，测试人员和测试管理人员面临着从测试传统的C/S结构和框架环境到测试快速改变的Web应用系统的转变。 

一、功能测试 

1、链接测试 

链接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先，测试所有链接是否按指示的那样确实链接到了该链接的页面；其次，测试所链接的页面是否存在；最后，保证Web应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面，只有知道正确的URL地址才能访问。 

链接测试可以自动进行，现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成，也就是说，在整个Web应用系统的所有页面开发完成之后进行链接测试。 

2、表单测试 

当用户给Web应用系统管理员提交信息时，就需要使用表单操作，例如用户注册、登陆、信息提交等。在这种情况下，我们必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。如果使用了默认值，还要检验默认值的正确性。如果表单只能接受指定的某些值，则也要进行测试。例如：只能接受某些字符，测试时可以跳过这些字符，看系统是否会报错。 

3、Cookies测试 

Cookies通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用Cookies访问了某一个应用系统时，Web服务器将发送关于用户的信息，把该信息以Cookies的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登陆等信息。 

如果Web应用系统使用了Cookies，就必须检查Cookies是否能正常工作。测试的内容可包括Cookies是否起作用，是否按预定的时间进行保存，刷新对Cookies有什么影响等。 

4、设计语言测试 

Web设计语言版本的差异可以引起客户端或服务器端严重的问题，例如使用哪种版本的HTML等。当在分布式环境中开发时，开发人员都不在一起，这个问题就显得尤为重要。除了HTML的版本问题外，不同的脚本语言，例如Java、JavaScript、 ActiveX、VBScript或Perl等也要进行验证。 

5、数据库测试 

在Web应用技术中，数据库起着重要的作用，数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中，最常用的数据库类型是关系型数据库，可以使用SQL对信息进行处理。 

在使用了数据库的Web应用系统中，一般情况下，可能发生两种错误，分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的，针对这两种情况，可分别进行测试。 

二、性能测试 

1、连接速度测试 

用户连接到Web应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长（例如超过5秒钟），用户就会因没有耐心等待而离开。 

另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。 

2、负载测试 

负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。例如：Web应用系统能允许多少个用户同时在线？如果超过了这个数量，会出现什么现象？Web应用系统能否处理大量用户对同一个页面的请求？ 

3、压力测试 

负载测试应该安排在Web系统发布以后，在实际的网络环境中进行测试。因为一个企业内部员工，特别是项目组人员总是有限的，而一个Web系统能同时处理的请求数量将远远超出这个限度，所以，只有放在Internet上，接受负载测试，其结果才是正确可信的。 

进行压力测试是指实际破坏一个Web应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃。黑客常常提供错误的数据负载，直到Web应用系统崩溃，接着当系统重新启动时获得存取权。 

压力测试的区域包括表单、登陆和其他信息传输页面等。 

三、可用性测试 

1、导航测试 

导航描述了用户在一个页面内操作的方式，在不同的用户接口控制之间，例如按钮、对话框、列表和窗口等；或在不同的连接页面之间。通过考虑下列问题，可以决定一个Web应用系统是否易于导航：导航是否直观？Web系统的主要部分是否可通过主页存取？Web系统是否需要站点地图、搜索引擎或其他的导航帮助？ 

在一个页面上放太多的信息往往起到与预期相反的效果。Web应用系统的用户趋向于目的驱动，很快地扫描一个Web应用系统，看是否有满足自己需要的信息，如果没有，就会很快地离开。很少有用户愿意花时间去熟悉Web应用系统的结构，因此，Web应用系统导航帮助要尽可能地准确。 

导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容，内容在什么地方。 

Web应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。 

2、图形测试 

在Web应用系统中，适当的图片和动画既能起到广告宣传的作用，又能起到美化页面的功能。一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有： 

（1）要确保图形有明确的用途，图片或动画不要胡乱地堆在一起，以免浪费传输时间。Web应用系统的图片尺寸要尽量地小，并且要能清楚地说明某件事情，一般都链接到某个具体的页面。 

（2）验证所有页面字体的风格是否一致。 

（3）背景颜色应该与字体颜色和前景颜色相搭配。 

（4）图片的大小和质量也是一个很重要的因素，一般采用JPG或GIF压缩。

3、内容测试 

内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。 

信息的正确性是指信息是可靠的还是误传的。例如，在商品价格列表中，错误的价格可能引起财政问题甚至导致法律纠纷；信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行，例如使用Microsoft Word的"拼音与语法检查"功能；信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口，也就是一般Web站点中的所谓"相关文章列表"。 

4、整体界面测试 

整体界面是指整个Web应用系统的页面结构设计，是给用户的一个整体感。例如：当用户浏览Web应用系统时是否感到舒适，是否凭直觉就知道要找的信息在什么地方？整个Web应用系统的设计风格是否一致？ 

对整体界面的测试过程，其实是一个对最终用户进行调查的过程。一般Web应用系统采取在主页上做一个调查问卷的形式，来得到最终用户的反馈信息。 

对所有的可用性测试来说，都需要有外部人员（与Web应用系统开发没有联系或联系很少的人员）的参与，最好是最终用户的参与。 

四、客户端兼容性测试 

1、平台测试 

市场上有很多不同的操作系统类型，最常见的有Windows、Unix、Macintosh、Linux等。Web应用系统的最终用户究竟使用哪一种操作系统，取决于用户系统的配置。这样，就可能会发生兼容性问题，同一个应用可能在某些操作系统下能正常运行，但在另外的操作系统下可能会运行失败。 

因此，在Web系统发布之前，需要在各种操作系统下对Web系统进行兼容性测试。 

2、浏览器测试 

浏览器是Web客户端最核心的构件，来自不同厂商的浏览器对Java，、JavaScript、 ActiveX、 plug-ins或不同的HTML规格有不同的支持。例如，ActiveX是Microsoft的产品，是为Internet Explorer而设计的，JavaScript是Netscape的产品，Java是Sun的产品等等。另外，框架和层次结构风格在不同的浏览器中也有不同的显示，甚至根本不显示。不同的浏览器对安全性和Java的设置也不一样。 

测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中，测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。

五、安全性测试 

Web应用系统的安全性测试区域主要有： 

（1）现在的Web应用系统基本采用先注册，后登陆的方式。因此，必须测试有效和无效的用户名和密码，要注意到是否大小写敏感，可以试多少次的限制，是否可以不登陆而直接浏览某个页面等。 

（2）Web应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内（例如15分钟）没有点击任何页面，是否需要重新登陆才能正常使用。 

（3）为了保证Web应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。 

（4）当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。 

（5）服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。 

六、总结 

本文从功能、性能、可用性、客户端兼容性、安全性等方面讨论了基于Web的系统测试方法。 

基于Web的系统测试与传统的软件测试既有相同之处，也有不同的地方，对软件测试提出了新的挑战。基于Web的系统测试不但需要检查和验证是否按照设计的要求运行，而且还要评价系统在不同用户的浏览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。]]>