发布新日志

  • 安卓应用自动化测试工具大汇总(转)

    2013-02-26 15:55:25

    大部分是商业工具,最后几个是开源工具。

    安卓应用自动化测试工具之一 - PerfectoMobile

    该工具的官方网址:PerfectoMobile.com
    背景:美国/以色列公司,该工具已有6年历史。
    突出特点:测试脚本可以跨平台(Android/iOS/Blackberry...)执行,号称拥有市面上所有智能机。

    接下来我们尝试从以下几个方面了解该工具:
    [b]脚本编辑器[/b]
    它有两种方式:一、纯Web的脚本制作界面;二、近年新开发的QTP插件;

    [b]脚本语言[/b]
    Web端的是基于关键字的脚本设计器“ScriptOnce”;如果用QTP插件,则是VBScript。

    [b]是否支持录制脚本[/b]
    Web端是鼠标拖拽的方式制作脚本;QTP插件是否可以支持录制就不清楚了。

    [b]结果验证[/b]
    通过对比界面图像来验证测试结果

    [b]价格[/b]
    Web端对于设备的使用是按小时收费。QTP插件的费用还不清楚。相信不会比QTP贵吧~ :-)
    --
    安卓应用自动化测试工具之二 - TestDroid

    该工具的官方网址:TestDroid.com
    背景:芬兰公司,近两年刚起步,去年年底开始做云平台。
    突出特点:测试脚本可以录制,并转成Robotium/MonkeyRunner脚本。

    接下来我们尝试从以下几个方面了解该工具:
    [b]脚本编辑器[/b]
    其实就是Eclipse插件。

    [b]是否支持录制脚本 & 脚本语言[/b]
    可以用录制的方式产生脚本,并生成Robotium or MonkeyRunner的脚本语言。但这个前提是一定要有被测应用的源代码。官方文档虽然说不用源码也能测,只是抓不到R-Class级别的对象。但笔者试了一下没有源码的apk,好像文本框的顺序还无法辨认。

    [b]结果检查[/b]
    貌似可以写判断语句。

    [b]价格[/b]
    USD99/Month,买够一年还可以打5折。云端价格暂未公开。
    --
    安卓应用自动化测试工具之三 - DroidPilot

    该工具的官方网址:DroidPilot.cn
    背景:深圳公司,今年刚起步。
    突出特点:抓取对象能力较强;工具仿制QTP,易于测试人员上手。

    接下来我们尝试从以下几个方面了解该工具:
    [b]脚本编辑器 & 脚本语言[/b]
    自己写的脚本编辑器,仿QTP使用VBScript语言。

    [b]是否支持录制脚本[/b]
    使用脚本设计器,通过抓取的对象设计脚本,然后把设计好的脚本转换成VBScript进行深加工。据开发团队声称,测试工程师在制作脚本的时候录制的效率不一定有制作的效率高,且也不一定灵活。不过他们表明会在后续版本开发录制功能。

    [b]结果检查[/b]
    有类似QTP的检查点语句Checkpoint; 也可以写条件判断语句对比属性值。

    [b]价格[/b]
    未定,目前开放试用下载,试用期限不够的话还可以跟他们谈。
    --
    安卓应用自动化测试工具之四 - LessPainful

    该工具的官方网址:lesspainful.com
    背景:丹麦公司,这两年刚起步。
    突出特点:支持iOS & Android;只需提供被测apk和脚本到他们的网站即可测试;脚本很特别。

    接下来我们尝试从以下几个方面了解该工具:
    [b]脚本语言[/b]
    脚本语言是仿真语言,很有意思。

    [b]是否支持录制脚本[/b]
    测试工程师就像写测试用例那样写脚本,都不需要录制功能了。

    [b]结果检查[/b]
    不清楚,只是说把写好的脚本提交给他们,就可以在几分钟之内收到结果。脚本中貌似没有检查点之类的语法。

    [b]价格[/b]
    按月收费。
    --
    安卓应用自动化测试工具之五 - DeviceAnywhere

    该工具的官方网址:deviceanywhere.com
    背景:美国公司,做了好几年了。
    突出特点:号称支持所有平台;与测试管理工具整合。

    接下来我们尝试从以下几个方面了解该工具:
    [b]脚本编辑器 & 脚本语言[/b]
    其实是测试流程设计器,用鼠标拖拽的方式设计测试场景。

    [b]结果检查[/b]
    通过图像对比检查结果。

    [b]工具整合[/b]
    这家公司提供的是一整套解决方案。不单有测试管理工具,设备监控工具,甚至还有移动应用开发工具。

    [b]价格[/b]
    很贵。
    --
    安卓应用自动化测试工具之六 - JamoSolutions

    该工具的官方网址:jamosolutions.com
    背景:比利时公司,做了好几年了。
    突出特点:提供QTP、Eclipse、Visual Studio插件;可以跨平台iOS/Android/Blackberry。

    接下来我们尝试从以下几个方面了解该工具:
    [b]脚本编辑器 & 脚本语言[/b]
    因为是通过插件形式工作的,脚本编辑器和脚本语言视乎开发工具(QTP、Eclipse、Visual Studio)而定。

    [b]结果检查[/b]
    应该可以通过对比属性值检查结果。

    [b]价格[/b]
    不明,估计不会比开发工具贵。
    --
    安卓应用自动化测试工具之七 - bsquare - TestQuest CountDown

    该工具的官方网址:bsquare.com
    背景:美国公司,做了好几年了。
    突出特点:跨平台;与测试管理工具整合。

    接下来我们尝试从以下几个方面了解该工具:
    [b]脚本编辑器 & 脚本语言[/b]
    不清楚,听说是根据坐标点和图像判断。

    [b]结果检查[/b]
    也不清楚。

    [b]工具整合[/b]
    整合这家公司自身的Test Designer/Test Manager/Test Runner之类的工具。

    [b]价格[/b]
    不清楚,听说有点贵。
    --
    安卓应用自动化测试工具之八 - ZAP-fiX

    该工具的官方网址:zap-fix.com
    背景:美国公司,做了好几年了。
    突出特点:QTP插件;跨平台。

    接下来我们尝试从以下几个方面了解该工具:
    [b]脚本编辑器 & 脚本语言[/b]
    其实是QTP的插件。

    [b]结果检查[/b]
    同QTP。

    [b]跨平台[/b]
    可以跨Android/iOS测试。

    [b]价格[/b]
    不详,肯定不会比QTP卖的贵。
    --
    --
    安卓应用自动化测试工具之九 - eggPlant

    该工具的官方网址:testplant.com
    背景:美国公司,做了好几年了。
    突出特点:跨平台;整合测试管理工具。

    接下来我们尝试从以下几个方面了解该工具:
    [b]脚本编辑器 & 脚本语言[/b]
    不详。由于可以跨平台,估计是坐标点或图像比较。

    [b]结果检查[/b]
    不详。

    [b]跨平台[/b]
    可以跨Android/iOS/Blackberry/Windows Phone等。

    [b]价格[/b]
    不详。由于可以与Rational Quality Manager整合,所以估计不会比Rational的工具卖的贵吧。
    --
    安卓应用自动化测试工具之十 - Testin

    该工具的官方网址:testin.cn
    背景:北京公司,近两年刚起步。
    突出特点:跨平台。

    接下来我们尝试从以下几个方面了解该工具:
    [b]脚本编辑器 & 脚本语言[/b]
    只能录制脚本,无法编辑。

    [b]结果检查[/b]
    不详。

    [b]跨平台[/b]
    可以跨Android/iOS,但是好像脚本要分开录制。

    [b]价格[/b]
    不详。应该不贵。
    --
    安卓应用自动化测试工具之十一 - ExperiTest - SeeTestMobile

    该工具的官方网址:experitest.com
    背景:美国公司,近两年刚起步。
    突出特点:可录制;跨平台。

    接下来我们尝试从以下几个方面了解该工具:
    [b]脚本编辑器 & 脚本语言[/b]
    支持不同工具的Plug-in,脚本语言视乎工具而定。

    [b]结果检查[/b]
    图像比较,OCR。

    [b]跨平台[/b]
    可以跨Android/iOS/Blackberry/Windows Phone。

    [b]价格[/b]
    SeeTestMobile - $2499USD/Year。
    --
    安卓应用自动化测试工具之十二 - AndroidTester

    该工具的官方网址:androidtester.net
    背景:上海公司,近两年刚起步。
    突出特点:可录制。

    接下来我们尝试从以下几个方面了解该工具:
    [b]脚本编辑器 & 脚本语言[/b]
    独立编辑器,Python脚本语言。

    [b]结果检查[/b]
    图像比较。

    [b]跨平台[/b]
    只支持Android。

    [b]价格[/b]
    不详,应该不贵。
    --
    安卓应用自动化测试工具之十三 - SmartRobot

    该工具的官方网址:dongzhousoft.com
    背景:北京公司,近两年刚起步。
    突出特点:可录制,与测试管理平台整合。

    接下来我们尝试从以下几个方面了解该工具:
    [b]脚本编辑器 & 脚本语言[/b]
    独立编辑器,可生成Robotium或MonkeyRunner脚本语言。

    [b]结果检查[/b]
    不详。

    [b]跨平台[/b]
    只支持Android。

    [b]价格[/b]
    不详,应该不贵。
    --
    安卓应用自动化测试工具之十四 - Others

    除了上述介绍的商业工具,Android自动化测试其实还有很多开源工具,大家可以陆续学习,这里尝试列举一些:
    1. Robotium - robotium.org - 地球人都知道。
    2. MonkeyRunner - 自己上网搜吧~
    3. WindRiver - windriver.com - 这家厂其实是做芯片的,但是他们也有一个自动化测试框架,好像是不卖的。
    4. Robolectric - http://pivotal.github.com/robolectric/index.html - 这其实是个单元测试框架。
    5. Sikuli - sikuli.org - 这家专门做图像比较的。

    汇总于http://forum.droidpilot.com/forum.php?mod=forumdisplay&fid=40&page=1
  • 软件测试人员的发展误区

    2011-03-30 12:05:49

    【IT168 技术文章】

      公司开发的产品专业性较强,软件测试人员需要有很强的专业知识,现在软件测试人员发展出现了一种测试管理者不愿意看到的景象:

      1、开发技术较强的软件测试人员转向了软件开发(非测试工具开发);

      2、业务能力较强的测试人员转向了软件需求;

      3、沟通能力较强专业能力较强的人员转向了软件实施;

      为什么不愿意看到呢,自己培养起来的优秀人员都为别的部门、别的公司干活去了,而测试这边永远都是新人,永远都是刚入门的软件测试工程师:开发水平一般、业务能力一般、沟通能力一般。而那些转行的测试同仁们,薪水并没有质的飞跃,到了‘那边’成绩平平,很快就被埋没了。这里当然要排除那些实在对开发、对业务、对实施非常感兴趣想在这些领域有所建树的狂热者们。问题就来了,那些人为什么要‘转业’呢?原因无外乎以下几点:

      1、公司的软件测试没有技术含量,没有挑战性;

      2、认为在公司能做到测试经理就已经是测试发展的最高境界了;

      3、测试人员薪水较其他低;

      4、想了解一下测试之外的其他岗位,丰富自己的阅历,为以后更好的做管理做准备。

      那么,公司的软件测试真的技术含量很低吗?工作效率已经达到最高了吗?真的不需要挑战吗?测试经理就没有高级和低级之分了吗?测试人员的薪水就不可以比开发人员高了吗?测试人员真的需要那么多吗?当然不是,也许很多年的‘旧路’不能靠自己改变,也许有人埋怨领导者们因循守旧、顽固不化,但没有人会阻挡我们去创新,去阻止我们探索新的模式、新的思路、新的工作方法去改变这种现状,没有公司是傻子,一个人的薪水和他体现出来的价值是成正比的。所以应该打破常规,去探索新的东西,这种创新不仅包括技术创新也包括管理创新。关于职业发展,仅根据公司的实际情况,和从大家那里得来的想法,谈一谈:

      1、开发技能较强的软件测试人员可以转向自动化测试工具、测试管理工具的开发,这里不仅要求开发能力较强,还需要多了解第三方测试工具,挖掘测试组内测试人员的需求,了解业务;

      2、业务能力较强的可以做测试(用例、计划)设计工程师,由于公司产品业务较强,需求人员仅能为测试人员提供需求文档,而究竟哪些是最重要的测试点,测试过程中采取什么样的测试方法能使得测试路径最短、覆盖率最全,这些都需要抓住软件业务的精髓;

      3、做到了测试经理,完全可以把管理再出神入化,每个人身上有什么特点,怎样能让每个组员的能力发挥到极致,怎么更好的争取测试人员的利益,怎样做到最好的资源调配,怎样让大家不再迷茫,另外,怎样提升自己的威信,提升执行力,领导力,怎样把管理做到让人啧啧,到了这种程度,通过横向和纵向对比,优势自然就出来了。

      另外,转做开发、需求、实施,然后又转回测试做管理,这种我是比较赞同的,但度不好掌握,而且如果自己的水平实在太高,很可能会让这类人产生英雄无用武之地的想法,公司的平台太低,而自己感觉自己的水平偏高,所以很可能导致这类人的离职,所以个人的发展和公司测试部的发展一定得保持同步,谁都不能过快,步伐不一致的的两个人怎么能走在一条道上呢?所以在个人发展的情况下,关注公司总体测试发展,先认清两者的发展方向再去‘转业’未尝不可。

      4、做到测试设计人员、自动化工具、管理工具开发人员就是极致了吗?当然不是,测试行业照样有咨询、有顾问、专家,测试管理做好了也可以去做项目经理、去做部门经理,实在不行,完全可以去创业嘛。

      总之,发展无极限,路是自己走出来的,不要只走别人踩出来的路。

  • QTP 学习视频汇总

    2011-03-30 12:00:08

    所有的QTP视频做个汇总。

    [V] 小布老师QTP系列培训视频 - 1
    http://www.boobooke.com/v/bbk1043
    本讲讲了QTP的概述,希望大家喜欢。

    [V] 小布老师QTP系列培训视频 - 2
    http://www.boobooke.com/v/bbk1044
    本讲讲了测试规划,希望大家喜欢。

    [V] 小布老师QTP系列培训视频 - 3
    http://www.boobooke.com/v/bbk1045
    本讲讲了录制测试脚本,是使用QTP的第一步。

    [V] 小布作品:QTP培训系列 - 4
    QTP录制之前的注意要点
    在线观看: http://www.boobooke.com/v/bbk3307
    视频下载: http://www.boobooke.com/v/bbk3307.zip
    [V] 小布作品:QTP培训系列 - 5
    介绍QTP录制和回放
    在线观看:
    http://www.boobooke.com/v/bbk3308
    视频下载: http://www.boobooke.com/v/bbk3308.zip
    [V] 小布作品:QTP培训系列 - 6
    介绍QTP的对象库
    在线观看:
    http://www.boobooke.com/v/bbk3309
    视频下载: http://www.boobooke.com/v/bbk3309.zip
    [V] 小布作品:QTP培训系列 - 7
    继续介绍QTP的对象库
    在线观看:
    http://www.boobooke.com/v/bbk3310
    视频下载: http://www.boobooke.com/v/bbk3310.zip
    [V] 小布作品:QTP培训系列 - 8
    介绍QTP的同步点
    在线观看:
    http://www.boobooke.com/v/bbk3311
    视频下载: http://www.boobooke.com/v/bbk3311.zip
    [V] 小布作品:QTP培训系列 - 9
    介绍QTP的检查点
    在线观看:
    http://www.boobooke.com/v/bbk3312
    视频下载: http://www.boobooke.com/v/bbk3312.zip
    [V] 小布作品:QTP培训系列 - 10
    继续介绍QTP的检查点
    在线观看:
    http://www.boobooke.com/v/bbk3313
    视频下载: http://www.boobooke.com/v/bbk3313.zip



    小强作品-零基础学习软件测试-qtp-目录
    1 qtp目录分析
    2 qtp界面分析
    3 qtp示例程序分析
    4 qtp学习指南
    5 qtp基本操作录制与回放
    6 qtp的三种录制绞?br /> 7 增强help步骤
    8 checkpoint
    9 参数化
    10 Tools下的工具介绍
    11 qtp插件分析
    12 qtp测试用例设计考题
    13 vbs
    14 recovery Scenarios
    15 虚拟对象
    16 专家视图测试脚本开发
    17 qtp描述性编程
    18 qtp测试脚本编写规范

    [V] 小强老师系列作品:QTP的安装目录分析
    http://www.boobooke.com/v/bbk1590
    在本集中,小强老师向刚刚接触QTP的朋友介绍了QTP安装后的各个目录,重点介绍了大家需要关注的东西。

    [V] 小强老师系列作品:QTP界面剖析
    http://www.boobooke.com/v/bbk1594
    本集是承接上集,小强老师向刚刚接触QTP的朋友介绍了QTP的常用界面和菜单选项。

    [V] 小强老师系列作品:QTP示例程序之研究
    http://www.boobooke.com/v/bbk1598
    本集是承接上集,小强老师向刚刚接触QTP的朋友介绍了QTP自带的示例程序-飞机订票系统,别小看这个示例程序,小程序里面有大文章,且听小强老师给你道来。

    [V] 小强老师系列作品:QTP学习指南
    http://www.boobooke.com/v/bbk1515
    在本集中,小强老师根据自己的经验和体会,向刚刚接触QTP的朋友介绍了如何学习QTP的一些方法和经验。

    [V] 小强老师系列作品:QTP脚本的录制和回放
    http://www.boobooke.com/v/bbk1591
    在本集中,小强老师向刚刚接触QTP的朋友介绍了QTP最基本的脚本录制回放的功能。

    [V] 小强老师系列作品:QTP三种录制方式
    http://www.boobooke.com/v/bbk1516
    这是该系列讲座的第三集。在本集中,小强老师向刚刚接触QTP的朋友介绍了QTP录制脚本的三种模式。

    [V] 小强老师系列作品:QTP检查点之研究
    http://www.boobooke.com/v/bbk1595
    本集是承接上集,小强老师向刚刚接触QTP的朋友介绍了QTP的重要功能 - 检查点。

    [V] 小强老师系列作品:QTP参数化之研究
    http://www.boobooke.com/v/bbk1599
    本集是承接上集,小强老师向刚刚接触QTP的朋友介绍了QTP重要的功能-参数化。

    [V] 小强老师系列作品:QTP的常用工具阐释
    http://www.boobooke.com/v/bbk1589
    在本集中,小强老师向刚刚接触QTP的朋友介绍了QTP附带的常用工具。

    [V] 小强老师系列作品:QTP插件分析
    http://www.boobooke.com/v/bbk1689
    在本集中,小强老师向刚刚接触QTP的朋友介绍了QTP插件的基本知识。

    [V] 小强老师系列作品:QTP认证考试试题分析一则
    http://www.boobooke.com/v/bbk1575
    小强老师针对想入行软件测试行业的菜鸟级别的朋友。
    在本集中,小强老师根据自己的经验和体会,向刚刚接触QTP的朋友介绍了如何QTP认证考试的一道典型题目的分析.

    [V] 小强老师系列作品:QTP中VBS介绍
    http://www.boobooke.com/v/bbk1621
    在本集中,小强老师给大家介绍了QTP脚本语言VBS的基本知识。

    [V] 小强老师系列作品:QTP之场景恢复(Recovery Scenarios)
    http://www.boobooke.com/v/bbk1692
    在本集中,小强老师向刚刚接触QTP的朋友介绍了QTP的场景恢复(Recovery Scenarios)的基本知识。

    [V] 小强老师系列作品:QTP中的虚拟对象入门
    http://www.boobooke.com/v/bbk1695
    在本集中,小强老师向刚刚接触QTP的朋友介绍了QTP中虚拟对象的基本知识。

    [V] 小强老师系列作品:QTP之专家视图和测试脚本开发
    http://www.boobooke.com/v/bbk1690
    在本集中,小强老师向刚刚接触QTP的朋友介绍了QTP的专家视图,并介绍了脚本开发的几个重要对象。

    [V] 小强老师系列作品:QTP之描述性编程
    http://www.boobooke.com/v/bbk1691
    在本集中,小强老师向刚刚接触QTP的朋友介绍了QTP的描述性编程的基本知识。

    [V] 小强老师系列作品:QTP之测试脚本开发规范
    http://www.boobooke.com/v/bbk1693
    在本集中,小强老师向刚刚接触QTP的朋友介绍了QTP脚本开发的基本规范。

    [V] 小强老师系列作品:QTP脚本的增强一则
    http://www.boobooke.com/v/bbk1592
    本集是承接上集,小强老师向刚刚接触QTP的朋友介绍了如何对录制的脚本进行增强。

    [V] QTP 9的新特性 1 - 英文视频
    http://www.boobooke.com/v/bbk1050
    是QTP 9软件中自带的视频讲座,英语讲座

    [V] QTP 9的新特性 2 - 英文视频
    http://www.boobooke.com/v/bbk1051
    QTP 9软件中自带的视频讲座,英语发音

    [V] QTP 9的新特性 3 - 英文视频
    http://www.boobooke.com/v/bbk1052
    QTP 9软件自带的视频讲座,英语发音,希望大家喜欢。

    这些视频都在QTP 9的安装目录的help目录下面。
    help目录包括了QTP全部的联机文档和帮助。


  • 需求评审注意事项

    2011-03-14 17:42:35

    一、 注意对需求规格说明的正确性进行评审
      需求规格说明的正确性通常可以从如下方面得以体现:
      1、是否有需求与其他需求相互冲突或者重复?
      2、是否清晰、简洁、无二义地表达了每个需求?
      “清晰”是让人能够读懂;“简洁”是让人愿意去读;“无二义”决定”读”的效果,是让大家对需求描述的理解能够达成一致 。
      3、是否每个需求都通过了演示、测试、评审,分析是否得到了验证?
      4、是否每个需求都在项目的范围内?
      5、是否每个需求都没有内容和语法上的错误?
      6、在现有的资源内, 是否能实现所有的需求?
      7、每一条特定的错误信息,是否都是唯一的和具有含义的?
      二、 注意对需求规格说明的实践性进行评审
      所谓实践性是指需求本身是否来源于目前企业的相关业务规则和文件制度,而非源于分析师们经验主义的臆测。实践性是判断需求规格说明是不是理论联系实践、密切和用户联系的一个关键性指标。
    本文出自51Testing软件测试网,感谢会员archonwang在每周一问(08-11-10)中的精彩回答。
    http://bbs.51testing.com/forum-157-1.html
      三、 注意对需求规格说明的完整性进行评审
      我们经常由下面的问题清单来评审需求说明书是否”完整” 。
      1、编写的所有需求,其详细程度是否一致和合适?
      2、需求是否能为设计提供足够的基础?
      3、所有对其他需求的内部引用是否正确?
      4、是否包含了每个需求的实现优先级?
      5、是否定义了功能说明的内在算法?
      6、是否包含了所有已知的客户需求或系统需求?
      7、是否遗漏了必要的信息?如果有遗漏的话,把他们标记为待确定的问题(TBD) ?
      8、是否对所有预期的错误条件所产生的系统行为都编制了文档?
      需求说明的完整性主要体现在需求说明的详细程度上,我们怎样判断该需求的描述是否详细呢?我认为需求需要精化,而不是仅仅提出精化功能、对象要考虑涉众参与者、做些什么、需要什么数据信息、受什么业务规则和条件限制、系统会有什么响应,等等。
      四、 注意对需求方案的可行性和成本预算进行评审
      五、 注意对需求的质量属性进行评审
      我们需要评审需求规格说明是否合理地确定了所有的性能目标,是否合理地确定了安全性方面要考虑到的问题。
    本文出自51Testing软件测试网,感谢会员archonwang在每周一问(08-11-10)中的精彩回答。
    http://bbs.51testing.com/forum-157-1.html
      六、 注意对需求的可实施性进行评审
      是否对每个需求都设置了惟一性并且可以正确地识别它?是否每个功能需求都可以跟踪到高层需求(比如系统需求或用例)?
      需求必须可以测试,每个需求在特定的输入条件下应当能给出已知的输出结果。同时,需求应当层次分明,需要把单个需求下面的相关需求综合在一起形成一组需求功能。
      需求的可实施性除了可跟踪性还包括可测试性。事实上, 分析人员和测试人员在编写代码以前把需求模型,分析模型和测试用例综合起来通盘考虑,检查出遗漏的、错误的和不必要的需求。软件需求在概念上的测试是一种很必要的技术,它可以在项目早期阶段发现需求的歧义和错误。
      七、 注意对需求包含的用例文档进行评审
      用例是参与者对系统和参与者的交互过程所达成的一种契约。需求说明书基于用例的分析方法是也是当前较为流行的需求开发方式。用例文档作为需求重要的成果性文档也是需求评审主体之所在。需求评审确认的重点是对关键用户的最常用和最重要的用例进行深入和细致的评审,首先要通过测试用例的主干过程。而我们是否撰写有效的用例则要从以下方面着手评审。
      1、用例的目标或价值度量是否明确?
      2、用例是否是独立的分散任务?
      3、是否明确说明可用用例会给哪些参与者带来用处?
      4、编写用例的详细程度是否恰当?是否有不必要的设计和实现细节?
      5、所有预期的分支过程是否都编写了文档说明?
      6、所有预估的异常过程是否都编写了文档说明?
      7、是否存在一些普通的动作序列可以分解成独立的用例?
      8、每个路径的步骤是否都清晰明了,无歧义而且完整?
      9、用例中的每个参与者和步骤是否都与所执行的任务有关?
      10、用例中定义的每个可选路径是否都可行和可验证?
      11、用例的前置条件和后置条件是否合理?
      分析师必须确认用例的前置条件和后置条件准确界定了用例的边界范围,区分了用例和用例之间的界限。
    本文出自51Testing软件测试网,感谢会员archonwang在每周一问(08-11-10)中的精彩回答。
    http://bbs.51testing.com/forum-157-1.html
      八、 注意需求评审会的过程和结束标准
      需求评审会的结果是对需求规格书完成了评审过程,那我们又如何判断审查的结束标准呢?请看如下几条建议:
      1、审查期间评审员们提出的所有问题都已经解决。
      2、相关文档中的所有更改都已经正确完成。
      3、修订过的文档进行了拼写检查。
      4、所有标识为TBD(待确定)的问题已经全部解决, 或者已经对每个TBD的问题的解决过程、计划解决的目标日期和责任解决人等编制了文档。
      5 需求文档正式进入了配置库。
     
  • 需求评审的建议

    2011-03-14 17:16:38

      

       建议一:分层次评审

      我们知道用户的需求是可以分层次的,一般而言可以分成如下的层次:

      * 目标性需求:定义了整个系统需要达到的目标;

      * 功能性需求:定义了整个系统必须完成的任务;

      * 操作性需求:定义了完成每个任务的具体的人机交互;

      目标性需求是企业的高层管理人员所关注的,功能性需求是企业的中层管理人员所关注的,操作性需求是企业的具体操作人员所关注的。对不同层次的需求,其描述形式是有区别的,参与评审的人员也是不同的。如果让具体的操作人员去评审目标性需求,可能会很容易地导致“捡了芝麻,丢了西瓜”的现象,如果让高层的管理人员也去评审那些操作性需求,无疑是一种资源的浪费或者就会出现案例三的情形。

        建议二:正式评审与非正式评审结合

      正式评审是指通过开评审会的形式,组织多个专家,将需求涉及到的人员集合在一起,并定义好参与评审人员的角色和职责,对需求进行正规的会议评审。而非正式的评审并没有这种严格的组织形式,一般也不需要将人员集合在一起评审,而是通过电子邮件、文件汇签甚至是网络聊天等多种形式对需求进行评审。2种形式各有利弊,但往往非正式的评审比正式的评审效率更高,更容易发现问题。因此在评审时,应该更灵活地利用这2种方式。

      建议三:分阶段评审

      应该在需求形成的过程中进行分阶段的评审,而不是在需求最终形成后再进行评审。分阶段评审可以将原本需要进行的大规模评审拆分成各个小规模的评审,降低了需求返工的风险,提高了评审的质量。比如可以在形成目标性需求后进行一次评审,在形成系统的初次概要需求后进行一次评审,当对概要需求细分成几个部分,对每个部分进行各个评审,最终再对整体的需求进行评审。

      建议四:精心挑选评审员

      需求评审可能涉及的人员包括:需方的高层管理人员、中层管理人员、具体操作人员、IT主管、采购主管;供方的市场人员、需求分析人员、设计人员、测试人员、质量保证人员、实施人员、项目经理以及第三方的领域专家等等。在这些人员中由于大家所处的立场不同,对同一个问题的看法是不相同的,有些观点是和系统的目标有关系的,有些是关系不大的,不同的观点可能形成互补的关系。为了保证评审的质量和效率,需要精心挑选评审员。首先要保证使不同类型的人员的都要参与进来,否则很可能会漏掉了很重要的需求。其次在不同类型的人员中要选择那些真正和系统相关的,对系统有足够了解的人员参与进来,否则很可能使评审的效率降低或者最终不切实际的修改了系统的范围。

      建议五:对评审员进行培训

      在很多情况下,评审员是领域专家而不是进行评审活动的专家,他们没有掌握进行评审的方法、技巧、过程等,因此需要对评审员进行,同样对于主持评审的管理者也需要进行培训,以便于参与评审的人员能够紧紧围绕评审的目标来进行,能够控制评审活动的节奏,提高评审效率,避免发生案例一和案例二中出现的现象。对评审员的培训也可以区分为简单培训与详细培训2种。简单培训可能需要十几分钟或者几十分钟,需要将在评审过程中的需要把握的基本原则,需要注意的常见问题说清楚。详细培训则可能要需要对评审的方法、技巧、过程进行正式的培训,需要花费较长的时间,是一个独立的活动。需要注意的是被评审人员也要被培训。

      建议六:充分利用需求评审检查单

      需求检查单是很好的评审工具,需求检查单可以分成2类:需求形式的检查单和需求内容的检查单。需求形式的检查可以由QA人员负责,主要是针对需求文挡的格式是否符合质量标准来提出的,需求内容的检查是由评审员负责的,主要是检查需求内容是否达到了系统目标、是否有遗漏、是否有错误等等,这是需求评审的重点。检查单可以帮助评审员系统全面地发现需求中的问题,检查单也是随着工程财富的积累逐渐丰富和优化的。

    本文出自51Testing软件测试网,感谢会员archonwang在每周一问(08-11-10)中的精彩回答。
    http://bbs.51testing.com/forum-157-1.html

      建议七:建立标准的评审流程

      对正规的需求评审会需要建立正规的需求评审流程,按照流程中定义的活动进行规范的评审过程。比如在评审流程定义中可能规定评审的进入条件,评审需要提交的资料,每次评审会议的人员职责分配,评审的具体步骤,评审通过的条件等等。通过评审流程执行可能会避免出现案例五之类的问题。

      建议八:做好评审后的跟踪工作

      在需求评审后,需要根据评审人员提出的问题进行评价,以确定哪些问题是必须纠正的,哪些可以不纠正,并给出充分的客观的理由与证据。当确定需要纠正的问题后,要形成书面的需求变更的申请,进入需求变更的管理流程,并确保变更的执行,在变更完成后,要进行复审。切忌评审完毕后,没有对问题进行跟踪,而无法保证评审结果的落实,使前期的评审努力付之东流。

      建议九:充分准备评审

      评审质量的好坏很大程度上取决于在评审会议前的准备活动。常出现的问题是,需求文档在评审会议前并没有提前下发给参与评审会议的人员,没有留出更多更充分的时间让参与评审的人员阅读需求文档。更有甚者,没有执行需求评审的进入条件,在评审文档中存在大量的低级的错误或者没有在评审前进行沟通,文档中存在方向性的错误,从而导致评审的效率很低,质量很差。对评审的准备工作,也应当定义一个检查单,在评审之前对照检查单落实每项准备工作。

  • 如何进行需求评审

    2011-03-14 17:05:05

    问题描述:我们公司快要成立测试部了,之前我们一直是研发部下的测试小组,在成立之前,我们测试组集体讨论了下测试组成立前后的一些问题。其中一个难题就是需求,我们几个都没有相关的经验,所以我在此求助大家,邀大家来讨论下:如何进行需求评审?怎样的需求评审机制才是有效的?

    精彩回答:

      关于需求评审,首先我觉得应该解决的是可用的评审可用资源问题,只有把这个问题解决了,其评审结果才可以采信,否则不过形式尔耳。

      关于需求评审的一些必备资源,我这里选列了相关角色,如下列:

      * 业务专家或是熟悉该业务的人员(通常也叫业务方代表)

      * 文档审查人员

      * 架构师

      * 需求分析师

      * 需求评审组织人员及记录人员

      当然,除了人员意外,必要的时间、场地和上层决策者的支持也是不可或缺的。

      这些资源一旦准备停当,接下来就是如何安排评审事宜的问题了。我这里简单列下以往曾做过的一轮需求评审的过程:

      * 准备阶段(P)

      o 争取上层决策者的支持与谅解

      o 筹备相关的资源,包括人力、时间计划,评审场地

      o 在正式评审之前,将相关的需求记录(文档或其他形式)发布给每个参与评审的人员手中,并确保其有足够的时间可以通阅需求并做好评审前的相关质疑与确认记录

      o 在正式评审之前,会议组织者应先收集相关评审人员的各项需求评审建议和意见,对存在争议和疑惑的需求说明必须做好讨论的安排

      o 发布经确认后的评审计划或时间表

      * 实施阶段(D)

      o 由评审组织者召集各评审人员集中评议,可以以正式的会议等形式组织,此处以会议为形式做说明

      o 与会人就某具体的问题进行讨论,讨论的优先级如下所列

      * 最重要的业务内容,一般是按流程、功能、细节来排定

      * 争议或疑问较多的地方

      * 部分有争议的地方

      * 对于没有提出疑义的地方,可以快速流过

      o 最后,要注意一定要回顾已提出问题和有结论的地方

      o 由会议记录人员整理会议的纲要,记录各与会人员的相关意见,并在会后递交纪要

      * 检查再实施阶段(C)

      o 对评审得出结论的问题进行再次确认和修正补充

      o 确定下次评审的时间

      o 按照第一阶段的流程再次进行组织,并确认结果

      o 对大多数组织,两次评审可以解决大部分的问题,对于悬而未决的问题,如影响范围有限,则可以延后讨论解决

      * 总结阶段(A)

      o 就以上内容做最后的确认,需求定稿,各方签字确认。

      o 今后的变更转入需求变更流程,其后产生的评审为小范围内评审。

      4#给出了一项检查清单,作为文档审查人员审查需求的参考检查表使用,大家可以在进行需求评审时参考使用。

    来源于:http://www.51testing.com/html/42/n-108742.html

  • 软件测试工程师指南(2)

    2010-03-22 10:00:14

    3、组织技能(Organizational Skills)

    每当执行一个软件项目的测试计划,几乎不可能不遇到至少会阻碍一些测试而必须解决的缺陷。一个测试工程师应当能灵活地停止测试产品的一部分而开始测试其他部分。有时被测软件需要做根本变动引起大量的测试结果失效,测试也许得重做不止一次。在问题被查找和改变在进行的过程中,测试工程师必须有条理,保持对执行测试的软件的前后关系的明确感受(例如目前被测试的程序特定版本的不同部分)。

    网络时代要求的动态开发和测试模式使组织性的工作方式对测试工程师越来越重要。在整个开发过程中被测试软件可能会不断地改进。测试工程师在计划和实施测试的时候必须考虑这些变化因素,必须控制测试环境来保证测试结果的有效性。

    记住计划是一个动词。作为一个软件工程师,你永远不会有你想要的所有时间和资源。你总是必须通过理解技术和产品,开发组织方式,从你和其他人的错误中学习,以及在设计必须改变和出问题的时候的迅速调整,使你的测试效果和效率最大化。如何能做到这点呢?基本代数:量化任务、目标和结果来减少方程中的变量数。把产品的功能定义成要求。在测试计划和测试中量化测试及其预期的和实际的结果,把信息提供给项目组。你东点一下西点一下是不能完成整个测试的。未来软件开发的组织模式要求有灵活的设计和不断进化的开发周期。对产品测试必须随着产品的进化而进化。

    4、实践经验(Hands-On Experience)

    这是个典型的两难问题。你需要软件测试经验来找工作,你没工作你就没经验。你该怎么办?

    Be careful! 这需要勇气和你的PC的小心备份。

    作为自愿者参与beta测试。怎样发现需要beta测试员的公司呢?首先,给你在软件公司工作的亲友打电话。偶尔有人会需要beta的测试人员。如果这不行,到你最喜欢的网络搜索引擎上去找“beta test”。你会发现很多小(和不那么小的)公司亟需beta测试员。为什么?这得感谢互联网,竞争的加剧使公司必须做出产品模型贴到他们的网址上作为“beta”版推出。这些公司希望人们不仅测试他们的产品,而且对这些免费品感兴趣进而购买他们的产品。

    你也能参与开放资源的项目,例如Mozilla,开放资源的网络浏览器是网络浏览器的基础。Mozilla缺陷跟踪系统(bugzilla.mozilla.org)允许网上任何感兴趣的人直接

    在 http://65.54.244.250/cgi-bin/linkrd...2emozilla%2eorg 的开放资源项目中直接报告和跟踪缺陷

    一句忠告:如果你要把很多beta软件下载到你家里的PC里,投资你的备份设备和防病毒组件。

    5、态度(Attitude)

    “我希望你幸福的梦想,被你打破了!”

    我打赌这句话能勾起一些人童年记忆的创伤。我不是心理学家,但我还敢说这种说法是因为我们渴望看到成功。在软件测试中,你不仅要证实软件在做它该做的,还要证实它不会做它不该做的。为了做到这一点,你得找出软件的失败之处。

    进行软件测试需要很多人的眼光要进行一百八十度的转变,因为测试的目标是要让被测软件失败,由此产生出等同于其他东西工作正确时的成功。在软件测试中,一个成功的测试揭示一个缺陷。进行软件测试也是因为互联网的来临要求人们用一种大不同以往的眼光来看待动态的开发和测试模型。

    6、必备特性(Necessary Traits)

    软件测试工程师除了技术,还要求具有否定性的创造力;探测技巧;总体理解产品的能力;用客户的眼光进行评估;怀疑的而不是敌意的态度;能经受得住坏消息而保持目标;拥抱新技术的热望等特征。

    否定性的创造力。一个软件工程师不能怕引起一个产品的瘫痪或烧毁。在软件测试中,边界意味着被超越而不是被遵从。如果一个程序对某个值的极限为10(例如,可以在一时间被打开的最大文件数),测试工程师的第一想法应当是“如果我把那个值取11,或0,或10.1,甚至不设这个值会如何?”

    在我的早期的工作生涯中,有一次我测试一个开发和QA工程师遗漏下来的PC数据库。有问题的数据库是2.01版。这本身就说明产品有问题。2.0版没解决1.0版的所有缺陷吗?或者2.0版又加入了新的缺陷?很遗憾因为时间紧我没有调查这些,只是证实了最后的缺陷修复后就告捷了。

    这是很大的错误。我应当重测开发人员所谓“没有变化”的所有产品功能。2.0版本中的缺陷确实复修了,但在修复的过程中,有人破坏了请求。事实就是如此,在数据库里不能搜索数据了,第一个收到这项产品的beta客户发现了这个缺陷。

    我宣布以前的测试无效,要求对产品进行全面测试。找到几个缺陷之后,我发现这个数据库读取写保护文件或写保护了的磁盘的时候就会引起瘫痪。开发人员很吃惊我会试着写保护一个数据库。他们的反应就是:“没人会这么干的!”产品的市场经理很快用他们的方式承认了错误。

    探测技巧。在一个理想的世界中,软件测试应当在一个经常更新的写得很清楚的功能与设计说明文件(一般被称为“specifications”)中被完整而精确地描述。不幸的是,这一完善被开发程序每一方面文件的任务,包括记录在开发中对程序不可避免的改变,要花很多的时间和精力以至于人们无法完成编程。而且花费也太大。

  • 软件测试工程师指南(1)

    2010-03-22 09:27:27

    软件工业是自动化工业的一部分。而且是最活跃发展最迅速的一个方面。到底有多迅速?任何人的想像力都不够!正如我们不会把我们的事务托付给不可靠的经纪,任何有分量的公司都不会采用没有质量保障的软件。软件测试人员,我是说有水平有经验的软件测试人员永远是供不应求的。软件测试经理不得不花很多的时间去面试有潜力的应聘者。一些应聘者在软件方面或者软件测试方面毫无实际经验,明知道软件测试工作是一个高回报的和最合适的软件工业入门,就是无法抓住一个又一个机会。这些人真正需要的是一个指南能告诉他们如何成为一个软件测试工程师。

    首先,进入软件测试需要哪些技能?

    1、软件工程技能你必须了解软件软件工程(设计、开发和简单测试),应用,系统,自动测试编程,及操作系统,数据库,网络系统和协议的设计和使用。

    2、交流技巧如果想确定软件缺陷,你应当能够指出什么时候的缺陷算是缺陷。

    3、组织技能如果你在别人都头脑发昏的时候保持清醒,你就可能是一个好的软件测试工程师。在网络时代软件测试是一项有压力的复杂性工作,但如果你能从这些纷繁中找到一种途径,它就是一项回报丰厚的事业。

    4、实践技能当一个工作需要经验,而你又需要一个工作去丰富你的经验时该怎么办?这并不完全是一个两难的问题,你可能采用几种方式去获得实际经验。

    5、态度除了技术水平,你需要理解和采取适当的态度去做软件测试。

    1、软件工程技能(Software Engineering Skills)

    软件工程技能可以分成三大块:理解软件工程的规则,了解计算机编程和操作系统知识。

    理解软件工程“规则”。有一种过时的眼光认为软件工程只是由一些在工作期限之前疯狂编程、靠着非凡的协调能力和超人般的咖啡消耗整夜不睡,不停地设计和测试程序的“专家”们组成的。这种现象确实存在,但你只有了解了软件开发的真正过程,才会是一个专业人员。

    从哪开始呢?先到图书馆去走一走。你需要建立软件测试知识的软件工程基础。我的建议是阅读Roger Pressman的软件工程:A Practitioner's Approach, fifth edition (职业入门,第五版,McGraw Hill, 2000年版)和 Glenford Myers的The Art of Software Testing(软件测试艺术,John Wiley & Sons, 1979年版)。Pressman的书是一个对软件工程原理的全面介绍。有很多关于软件技巧、项目管理、要求分析和软件设计等软件工程方面的好书,但Pressman对这些方面在一本书里作了介绍。Glenford Myers不到二百页,1979年发行,却是软件测试方面的圣经。Myers定义及诠释的测试方法论已成为软件测试的基本模块。

    Myers还考查了软件测试中的经济(缺陷的代价)和心理学方面(测试的目标就是发现失误及不成功之处),以及主导软件开发和测试的基本原则。

    对参考书进行基本研究是一个好的开端,但这只是单方对话。如果你能和上千个直接具有软件工程和测试经验的人以及想进入这一领域的人对话是不是再好不过了呢?感谢那些网络电子部落,你已经可以做到了。Comp.software-eng覆盖了设计、编程、项目管理等软件工程的各个方面。Comp.software.testing涵盖了软件测试的自动化、培训、技巧等方面。

    等等,别只停留在这里!你是不是应当经常访问这些网址呢?Bug-Net(http://65.54.244.250/cgi-bin/linkrd...%2ebugnet%2ecom)是有关软件缺陷的在线杂志。阅读有关缺陷的文章是学习如何工作及失败的极好方式。你也应当查阅软件测试及质量工程杂志(http://65.54.244.250/cgi-bin/linkrd...ww%2estqe%2ecom)。STQE 是确定网络软件测试资源很好的始发站。

    计算机编程。不能想像有的人喜欢测试产品却从不阅读、检查和理解组成产品的软件一样。

    不要误解我的意思。你不必花所有的时间去读源代码,但任何你做过的有关自己程序的设计、编写和纠错都能大大地有助于测试别人编写的程序。

    你怎样学习编程?通过编程。可以严肃地说,开始学习写计算机程序是最简单的事。记住我说的是“开始学习”。软件编程环境,例如 Microsoft Windows Foundation Classes (MFC) or Sun's Java Foundation Classes (JFC, also called "Swing")不断变得越来越复杂,越来越难跟得上。

    但我在努力超越自己。你应当怎样学习编程呢?

    首先,买Microsoft Visual Basic。不要让名字骗了你。你能用这套组件建立相当复杂的程序。而且它只要一百元左右。下一步呢?等等,是visual编程警告的时候了!

    现在你为你的PC买一个程序语言的时候,你其实是买了一个集成开发系统或称为IDE。这些IDE通过对编程的简化把开发过程流水线化。这些IDE其实会帮你写很多编码。这非常有利于尽早开发出一个产品,却不利于你学习编程。如果你用Windows产生程序,你别无选择,因为环境介入太多使你无法从头编程。如果你从Unix系统产生程序,你能自己写所有的编码。

    一旦你习惯了与参量、控制结构、对象、输入输出及更重要的Visual Basic纠错打交道的时候,你就可以开始学习C语言了。学习C能使你熟悉十六进制系统,通过指针分配和参考内存,存取个体位码及建立程序模块。

    我总是认为在学Java之前最好先学会C,因为C强迫你自己去完成许多任务而Java会自动处理(例如,释放未用的空间)。用C工作比Java难,但你能学到编程更多的基本方面。你其实能用Visual C++ IDE从头写C程序,但最好还是在Unix系统中学C。

    操作系统知识。你已经把它交给了在Redmond, Washington的那些人了。在短短的几年内,Windows NT已经成为世界上大部分计算机的标准操作系统。如果你要用NT工作,你需要了解它的寄存地址。(它是一种用于存储你的系统结构的各个方面的数据库。)我发现Peter Norton写的Inside Windows NT 4.0 (SAMS, 1998)是一本很好的介绍书。但是,如果你的应用或系统要求高的保密度、产出、可靠性及灵活性,Unix依然是最好的选择。

    如果你想成为一个成功的软件工程师,你必须能在Unix的世界里工作,如果你想从头学习编程,也要在Unix下进行。

    你的选择是什么?你可以到当地的学校或大学学习课程,或者在家建立一个Unix系统。别昏过去了,你所需要的只是一台PC和一份能让你从网络免费下载的Linux拷贝。(你大约花二十九元能买一份在一个CD-ROM中带了所有文件的拷贝。)Linux不是Unix的“玩具”版,它是真实的。它已经发行了七百万份拷贝,一些主要的PC生产商甚至先替你装载了它。

    好了,你已经到了Unix或Linux系统了。你应当学些什么?文件和目录结构,标准输入输出和错误流,背景(background,也称为"daemon")处理,从C调用系统功能,好,我可以接下去了。一个好的开端是读Arnold Robbins的Unix in a Nutshell (O'Reilly & Associates, 1999)或者是Ellen Siever的Linux in a Nutshell (O'Reilly & Associates,1999)。

    2、交流技能(Communications Skills)

    能写出计算机程序却写不出一个完整句子的软件工程师现在还有。但不幸的是,要成为一个成功的软件测试工程师,你需要清楚的交流。

    你怎么去学习写?通过写。如果文字水平太粗糙,上一门创造性写作的课。每天写工程流水记录或发email。关键是学习(或重新学习)怎样用清晰可懂的语言表达你的思想。一个好的写作参谋是William Strunk Jr.和E.B. White写的The Elements of Style(Allyn & Bacon, 2000),它一点也不象初中教科书。

    测试工程师必须把产品测试的技术写成文件。测试计划提供指导并把测试设计转化为设置、实现测试和评估结果的步骤指导。具有一般软件和产品特性不同层次经验的工程师都能使用这样一个详细的测试计划。如此测试设计者或测试方案作者之外的工程师也能能进行测试。

    测试计划也帮着佐证测试策略的正确性。项目中的每个人都应当参与审查(即市场、开发、支持、技术写作及测试人)。计划的审查是必不可少的,因为尽管测试工程师尽最大努力来达成一个对产品的全面定义,这一测试设计者所基于的定义不一定是完整或准确的。此外,就象开发者很难测试他们自己的编码一样,测试工程师也很难明确评估他们自己的测试计划。每一个计划审查者都可能根据其经验及专长建议修改,有时候审查者还能提供测试工程师在组织产品定义时不具备的信息。例如,一个市场人员可能了解到了新的客户要求,一个软件支持专家可能从有关的产品领域了解到了一个新的缺陷报告。

    测试计划强调测试计划和执行的原则。在测试计划中描述进行测试所需的测试设计和步骤是另一层关于测试设计和计划的原则。在测试设计和计划中的错误与欠缺在设计转化成测试计划中特定的结构和测试步骤后就经常是再已无法弥补。

    测试计划可作为其它项目,例如为不同的产品准备测试时的参考资料。当被测试软件找到缺陷解决并证实后,测试计划所述的测试可以用于证实缺陷的解决方案。同时,一个主要的测试设计信息来源,特别对于旧产品的新版本而言,是相关产品或前版本的测试计划。在建立新版本时,旧版本的软件测试计划都应当被重新审查。

    与功能与设计说明不同,测试计划将从测试的角度来描述产品的功能操作。从这方面说,测试计划构成了公司公共档案的一部分。随着时间的流逝人们会离开公司,带走他们的知识。以前产品的测试计划就能帮助你定义新产品的测试。

    软件测试工程师还要写测试结果报告。测试结果必须写成文档,这样就能确定被测软件的状态,提供关于必须要解决的缺陷的记录。产品测试中发现的所有缺陷的记录是测试部门最显眼、保存时间最长的文档。测试计划和测试报告在项目的最后常被遗忘,但现存缺陷的清单(或数据库)代表项目未完成的议程。这一议程没完成是因为一些缺陷必须在对原来产品的一个patch或maintenance release的时候纠正,或者它们在这个产品作为后续产品的基础之前被修复。

    在与软件产品打交道的过程中,测试工程师比其他部门的人参与项目的更多方面。测试部门应当记录项目过程中重大事件(例如设计决定)的信息。这个信息应能帮助测试部门和其他部门避免在后续项目中犯同样的错误。错误是不可避免,在一个项目中可能出问题。从这些经验中学习就可能避免问题,避免今后的同样错误。从错误中学习的第一步就是记住它们,记忆的第一步就是把它们写下来。

  • SQL PLUS命令使用大全(转,特有用)

    2010-03-16 10:49:27

    Oracle的sql*plus是与oracle进行交互的客户端工具。在sql*plus中,可以运行sql*plus命令与sql*plus语句。
       我们通常所说的DML、DDL、DCL语句都是sql*plus语句,它们执行完后,都可以保存在一个被称为sql buffer的内存区域中,并且只能保存一条最近执行的sql语句,我们可以对保存在sql buffer中的sql 语句进行修改,然后再次执行,sql*plus一般都与数据库打交道。
       除了sql*plus语句,在sql*plus中执行的其它语句我们称之为sql*plus命令。它们执行完后,不保存在sql buffer的内存区域中,它们一般用来对输出的结果进行格式化显示,以便于制作报表。
       下面就介绍一下一些常用的sql*plus命令:
     
    1. 执行一个SQL脚本文件
    SQL>start file_name
    SQL>@ file_name
    我们可以将多条sql语句保存在一个文本文件中,这样当要执行这个文件中的所有的sql语句时,用上面的任一命令即可,这类似于dos中的批处理。

    @与@@的区别是什么?
    @等于start命令,用来运行一个sql脚本文件。
    @命令调用当前目录下的,或指定全路径,或可以通过SQLPATH环境变量搜寻到的脚本文件。该命令使用是一般要指定要执行的文件的全路径,否则从缺省路径(可用SQLPATH变量指定)下读取指定的文件。
    @@用在sql脚本文件中,用来说明用@@执行的sql脚本文件与@@所在的文件在同一目录下,而不用指定要执行sql脚本文件的全路径,也不是从SQLPATH环境变量指定的路径中寻找sql脚本文件,该命令一般用在脚本文件中。
    如:在c:\temp目录下有文件start.sql和nest_start.sql,start.sql脚本文件的内容为:
    @@nest_start.sql     - - 相当于@ c:\temp\nest_start.sql
    则我们在sql*plus中,这样执行:
    SQL> @ c:\temp\start.sql


    2. 对当前的输入进行编辑
    SQL>edit
     
    3. 重新运行上一次运行的sql语句
    SQL>/
     
    4. 将显示的内容输出到指定文件
    SQL> SPOOL file_name
       在屏幕上的所有内容都包含在该文件中,包括你输入的sql语句。
     
    5. 关闭spool输出
    SQL> SPOOL OFF
       只有关闭spool输出,才会在输出文件中看到输出的内容。
     
    6.显示一个表的结构
    SQL> desc table_name
     
    7. COL命令:
    主要格式化列的显示形式。
    该命令有许多选项,具体如下:
    COL[UMN] [{ column|expr} [ option ...]]
    Option选项可以是如下的子句:
    ALI[AS] alias
    CLE[AR]
    FOLD_A[FTER]
    FOLD_B[EFORE]
    FOR[MAT] format
    HEA[DING] text
    JUS[TIFY] {L[EFT]|C[ENTER]|C[ENTRE]|R[IGHT]}
    LIKE { expr|alias}
    NEWL[INE]
    NEW_V[ALUE] variable
    NOPRI[NT]|PRI[NT]
    NUL[L] text
    OLD_V[ALUE] variable
    ON|OFF
    WRA[PPED]|WOR[D_WRAPPED]|TRU[NCATED]
     
    1). 改变缺省的列标题
    COLUMN column_name HEADING column_heading
    For example:
    Sql>select * from dept;
         DEPTNO DNAME                        LOC
    ---------- ---------------------------- ---------
             10 ACCOUNTING                   NEW YORK
    sql>col  LOC heading location
    sql>select * from dept;
        DEPTNO DNAME                        location
    --------- ---------------------------- -----------
            10 ACCOUNTING                   NEW YORK
     
    2). 将列名ENAME改为新列名EMPLOYEE NAME并将新列名放在两行上:
    Sql>select * from emp
    Department  name           Salary
    ---------- ---------- ----------
             10 aaa                11        
    SQL> COLUMN ENAME HEADING ’Employee|Name’
    Sql>select * from emp
                Employee
    Department  name           Salary
    ---------- ---------- ---------- 
             10 aaa                11
    note: the col heading turn into two lines from one line.
     
    3). 改变列的显示长度:
    FOR[MAT] format
    Sql>select empno,ename,job from emp;
          EMPNO ENAME      JOB       
    ---------- ----------     ---------
           7369 SMITH      CLERK     
           7499 ALLEN      SALESMAN  
    7521 WARD       SALESMAN  
    Sql> col ename format a40
          EMPNO ENAME                                    JOB
    ----------   ----------------------------------------         ---------
           7369 SMITH                                    CLERK
           7499 ALLEN                                    SALESMAN
           7521 WARD                                    SALESMAN
     
    4). 设置列标题的对齐方式
    JUS[TIFY] {L[EFT]|C[ENTER]|C[ENTRE]|R[IGHT]}
    SQL> col ename justify center
    SQL> /
          EMPNO           ENAME                   JOB
    ----------   ----------------------------------------       ---------
           7369 SMITH                                    CLERK
           7499 ALLEN                                    SALESMAN
    7521 WARD                                     SALESMAN
    对于NUMBER型的列,列标题缺省在右边,其它类型的列标题缺省在左边
     
    5). 不让一个列显示在屏幕上
    NOPRI[NT]|PRI[NT]
    SQL> col job noprint
    SQL> /
          EMPNO           ENAME
    ----------     ----------------------------------------
           7369 SMITH
           7499 ALLEN
    7521 WARD
     
    6). 格式化NUMBER类型列的显示:
    SQL> COLUMN SAL FORMAT $99,990
    SQL> /
    Employee
    Department Name        Salary    Commission
    ---------- ---------- --------- ----------
    30          ALLEN        $1,600    300
     
    7). 显示列值时,如果列值为NULL值,用text值代替NULL值
    COMM NUL[L] text
    SQL>COL COMM NUL[L] text
     
    8). 设置一个列的回绕方式
    WRA[PPED]|WOR[D_WRAPPED]|TRU[NCATED]
            COL1
    --------------------
    HOW ARE YOU?
     
    SQL>COL COL1 FORMAT A5
    SQL>COL COL1 WRAPPED
    COL1
    -----
    HOW A
    RE YO
    U?
     
    SQL> COL COL1 WORD_WRAPPED
    COL1
    -----
    HOW
    ARE
    YOU?
     
    SQL> COL COL1 WORD_WRAPPED
    COL1
    -----
    HOW A
     
    9). 显示列的当前的显示属性值
    SQL> COLUMN column_name
     
    10). 将所有列的显示属性设为缺省值
    SQL> CLEAR COLUMNS
     
    8. 屏蔽掉一个列中显示的相同的值
    BREAK ON break_column
    SQL> BREAK ON DEPTNO
    SQL> SELECT DEPTNO, ENAME, SAL
    FROM EMP
      WHERE SAL < 2500
      ORDER BY DEPTNO;
    DEPTNO      ENAME         SAL
    ---------- ----------- ---------
    10           CLARK        2450
    MILLER      1300
    20            SMITH       800
    ADAMS       1100
     
    9. 在上面屏蔽掉一个列中显示的相同的值的显示中,每当列值变化时在值变化之前插入n个空行。
    BREAK ON break_column SKIP n
     
    SQL> BREAK ON DEPTNO SKIP 1
    SQL> /
    DEPTNO ENAME SAL
    ---------- ----------- ---------
    10 CLARK 2450
    MILLER 1300
     
    20 SMITH 800
    ADAMS 1100
     
    10. 显示对BREAK的设置
    SQL> BREAK
     
    11. 删除6、7的设置
    SQL> CLEAR BREAKS
     
    12. Set 命令:
    该命令包含许多子命令:
    SET system_variable value
    system_variable value 可以是如下的子句之一:
    APPI[NFO]{ON|OFF|text}
    ARRAY[SIZE] {15|n}
    AUTO[COMMIT]{ON|OFF|IMM[EDIATE]|n}
    AUTOP[RINT] {ON|OFF}
    AUTORECOVERY [ON|OFF]
    AUTOT[RACE] {ON|OFF|TRACE[ONLY]} [EXP[LAIN]] [STAT[ISTICS]]
    BLO[CKTERMINATOR] {.|c}
    CMDS[EP] {;|c|ON|OFF}
    COLSEP {_|text}
    COM[PATIBILITY]{V7|V8|NATIVE}
    CON[CAT] {.|c|ON|OFF}
    COPYC[OMMIT] {0|n}
    COPYTYPECHECK {ON|OFF}
    DEF[INE] {&|c|ON|OFF}
    DESCRIBE [DEPTH {1|n|ALL}][LINENUM {ON|OFF}][INDENT {ON|OFF}]
    ECHO {ON|OFF}
    EDITF[ILE] file_name[.ext]
    EMB[EDDED] {ON|OFF}
    ESC[APE] {\|c|ON|OFF}
    FEED[BACK] {6|n|ON|OFF}
    FLAGGER {OFF|ENTRY |INTERMED[IATE]|FULL}
    FLU[SH] {ON|OFF}
    HEA[DING] {ON|OFF}
    HEADS[EP] {||c|ON|OFF}
    INSTANCE [instance_path|LOCAL]
    LIN[ESIZE] {80|n}
    LOBOF[FSET] {n|1}
    LOGSOURCE [pathname]
    LONG {80|n}
    LONGC[HUNKSIZE] {80|n}
    MARK[UP] HTML [ON|OFF] [HEAD text] [BODY text] [ENTMAP {ON|OFF}] [SPOOL
    {ON|OFF}] [PRE[FORMAT] {ON|OFF}]
    NEWP[AGE] {1|n|NONE}
    NULL text
    NUMF[ORMAT] format
    NUM[WIDTH] {10|n}
    PAGES[IZE] {24|n}
    PAU[SE] {ON|OFF|text}
    RECSEP {WR[APPED]|EA[CH]|OFF}
    RECSEPCHAR {_|c}
    SERVEROUT[PUT] {ON|OFF} [SIZE n] [FOR[MAT] {WRA[PPED]|WOR[D_
    WRAPPED]|TRU[NCATED]}]
    SHIFT[INOUT] {VIS[IBLE]|INV[ISIBLE]}
    SHOW[MODE] {ON|OFF}
    SQLBL[ANKLINES] {ON|OFF}
    SQLC[ASE] {MIX[ED]|LO[WER]|UP[PER]}
    SQLCO[NTINUE] {> |text}
    SQLN[UMBER] {ON|OFF}
    SQLPRE[FIX] {#|c}
    SQLP[ROMPT] {SQL>|text}
    SQLT[ERMINATOR] {;|c|ON|OFF}
    SUF[FIX] {SQL|text}
    TAB {ON|OFF}
    TERM[OUT] {ON|OFF}
    TI[ME] {ON|OFF}
    TIMI[NG] {ON|OFF}
    TRIM[OUT] {ON|OFF}
    TRIMS[POOL] {ON|OFF}
    UND[ERLINE] {-|c|ON|OFF}
    VER[IFY] {ON|OFF}
    WRA[P] {ON|OFF}
     
    1). 设置当前session是否对修改的数据进行自动提交
    SQL>SET AUTO[COMMIT] {ON|OFF|IMM[EDIATE]| n}
     
    2).在用start命令执行一个sql脚本时,是否显示脚本中正在执行的SQL语句
    SQL> SET ECHO {ON|OFF}
     
    3).是否显示当前sql语句查询或修改的行数
    SQL> SET FEED[BACK] {6|n|ON|OFF}
       默认只有结果大于6行时才显示结果的行数。如果set feedback 1 ,则不管查询到多少行都返回。当为off 时,一律不显示查询的行数
     
    4).是否显示列标题
    SQL> SET HEA[DING] {ON|OFF}
    当set heading off 时,在每页的上面不显示列标题,而是以空白行代替
     
    5).设置一行可以容纳的字符数
    SQL> SET LIN[ESIZE] {80|n}
       如果一行的输出内容大于设置的一行可容纳的字符数,则折行显示。
     
    6).设置页与页之间的分隔
    SQL> SET NEWP[AGE] {1|n|NONE}
    当set newpage 0 时,会在每页的开头有一个小的黑方框。
    当set newpage n 时,会在页和页之间隔着n个空行。
    当set newpage none 时,会在页和页之间没有任何间隔。
     
    7).显示时,用text值代替NULL值
    SQL> SET NULL text
     
    8).设置一页有多少行数
    SQL> SET PAGES[IZE] {24|n}
    如果设为0,则所有的输出内容为一页并且不显示列标题
     
    9).是否显示用DBMS_OUTPUT.PUT_LINE包进行输出的信息。
    SQL> SET SERVEROUT[PUT] {ON|OFF} 
    在编写存储过程时,我们有时会用dbms_output.put_line将必要的信息输出,以便对存储过程进行调试,只有将serveroutput变量设为on后,信息才能显示在屏幕上。
     
    10).当SQL语句的长度大于LINESIZE时,是否在显示时截取SQL语句。
    SQL> SET WRA[P] {ON|OFF}
       当输出的行的长度大于设置的行的长度时(用set linesize n命令设置),当set wrap on时,输出行的多于的字符会另起一行显示,否则,会将输出行的多于字符切除,不予显示。
     
    11).是否在屏幕上显示输出的内容,主要用与SPOOL结合使用。
    SQL> SET TERM[OUT] {ON|OFF}
       在用spool命令将一个大表中的内容输出到一个文件中时,将内容输出在屏幕上会耗费大量的时间,设置set termspool off后,则输出的内容只会保存在输出文件中,不会显示在屏幕上,极大的提高了spool的速度。
     
    12).将SPOOL输出中每行后面多余的空格去掉
    SQL> SET TRIMS[OUT] {ON|OFF} 
       
    13)显示每个sql语句花费的执行时间
    set TIMING  {ON|OFF}

    14). 遇到空行时不认为语句已经结束,从后续行接着读入。
    SET SQLBLANKLINES ON
    Sql*plus中, 不允许sql语句中间有空行, 这在从其它地方拷贝脚本到sql*plus中执行时很麻烦. 比如下面的脚本:
    select deptno, empno, ename
    from emp

    where empno = '7788';
    如果拷贝到sql*plus中执行, 就会出现错误。这个命令可以解决该问题

    15).设置DBMS_OUTPUT的输出
    SET SERVEROUTPUT ON BUFFER 20000
    用dbms_output.put_line('strin_content');可以在存储过程中输出信息,对存储过程进行调试
    如果想让dbms_output.put_line('     abc');的输出显示为:
    SQL>     abc,而不是SQL>abc,则在SET SERVEROUTPUT ON后加format wrapped参数。

    16). 输出的数据为html格式
    set markup html
    在8.1.7版本(也许是816? 不太确定)以后, sql*plus中有一个set markup html的命令, 可以将sql*plus的输出以html格式展现.
    注意其中的spool on, 当在屏幕上输出的时候, 我们看不出与不加spool on有什么区别, 但是当我们使用spool filename 输出到文件的时候, 会看到spool文件中出现了等tag.


    14.修改sql buffer中的当前行中,第一个出现的字符串
    C[HANGE] /old_value/new_value
    SQL> l
       1* select * from dept
    SQL> c/dept/emp
       1* select * from emp
     
    15.编辑sql buffer中的sql语句
    EDI[T]
     
    16.显示sql buffer中的sql语句,list n显示sql buffer中的第n行,并使第n行成为当前行
    L[IST] [n]
     
    17.在sql buffer的当前行下面加一行或多行
    I[NPUT]
     
    18.将指定的文本加到sql buffer的当前行后面
    A[PPEND]
    SQL> select deptno,
       2  dname
       3  from dept;
         DEPTNO DNAME
    ---------- --------------
             10 ACCOUNTING
             20 RESEARCH
             30 SALES
             40 OPERATIONS
     
    SQL> L 2
       2* dname
    SQL> a ,loc
       2* dname,loc
    SQL> L
       1  select deptno,
       2  dname,loc
       3* from dept
    SQL> /
     
         DEPTNO DNAME          LOC
    ---------- -------------- -------------
             10 ACCOUNTING     NEW YORK
             20 RESEARCH       DALLAS
             30 SALES          CHICAGO
             40 OPERATIONS     BOSTON
     
    19.将sql buffer中的sql语句保存到一个文件中
    SAVE file_name
     
    20.将一个文件中的sql语句导入到sql buffer中
    GET file_name
     
    21.再次执行刚才已经执行的sql语句
    RUN
    or
    /
     
    22.执行一个存储过程
    EXECUTE procedure_name
     
    23.在sql*plus中连接到指定的数据库
    CONNECT user_name/passwd@db_alias
     
    24.设置每个报表的顶部标题
    TTITLE
     
    25.设置每个报表的尾部标题
    BTITLE
     
    26.写一个注释
    REMARK [text]
     
    27.将指定的信息或一个空行输出到屏幕上
    PROMPT [text]
     
    28.将执行的过程暂停,等待用户响应后继续执行
    PAUSE [text]
     
    Sql>PAUSE Adjust paper and press RETURN to continue.
     
    29.将一个数据库中的一些数据拷贝到另外一个数据库(如将一个表的数据拷贝到另一个数据库)
    COPY {FROM database | TO database | FROM database TO database}
    {APPEND|CREATE|INSERT|REPLACE} destination_table
    [(column, column, column, ...)] USING query
     
    sql>COPY FROM SCOTT/TIGER@HQ TO JOHN/CHROME@WEST 
    create emp_temp
    USING SELECT * FROM EMP
     
    30.不退出sql*plus,在sql*plus中执行一个操作系统命令:
    HOST
     
    Sql> host hostname
    该命令在windows下可能被支持。
     
    31.在sql*plus中,切换到操作系统命令提示符下,运行操作系统命令后,可以再次切换回sql*plus:
    !
     
    sql>!
    $hostname
    $exit
    sql>
     
    该命令在windows下不被支持。
     
    32.显示sql*plus命令的帮助
    HELP
    如何安装帮助文件:
    Sql>@ ?\sqlplus\admin\help\hlpbld.sql ?\sqlplus\admin\help\helpus.sql
    Sql>help index
     
    33.显示sql*plus系统变量的值或sql*plus环境变量的值
    Syntax
    SHO[W] option
    where option represents one of the following terms or clauses:
    system_variable
    ALL
    BTI[TLE]
    ERR[ORS] [{FUNCTION|PROCEDURE|PACKAGE|PACKAGE BODY|
    TRIGGER|VIEW|TYPE|TYPE BODY} [schema.]name]
    LNO
    PARAMETERS [parameter_name]
    PNO
    REL[EASE]
    REPF[OOTER]
    REPH[EADER]
    SGA
    SPOO[L]
    SQLCODE
    TTI[TLE]
    USER
     
    1) . 显示当前环境变量的值:
    Show all
     
    2) . 显示当前在创建函数、存储过程、触发器、包等对象的错误信息
    Show error
    当创建一个函数、存储过程等出错时,变可以用该命令查看在那个地方出错及相应的出错信息,进行修改后再次进行编译。
     
    3) . 显示初始化参数的值:
    show PARAMETERS [parameter_name]
     
    4) . 显示数据库的版本:
    show REL[EASE]
     
    5) . 显示SGA的大小
    show SGA
     
    6). 显示当前的用户名
    show user

    34.查询一个用户下的对象
    SQL>select * from tab;
    SQL>select * from user_objects;

    35.查询一个用户下的所有的表
    SQL>select * from user_tables;

    36.查询一个用户下的所有的索引
    SQL>select * from user_indexes;


    37. 定义一个用户变量
    方法有两个:
    a. define
    b. COL[UMN] [{column|expr} NEW_V[ALUE] variable [NOPRI[NT]|PRI[NT]]
                                OLD_V[ALUE] variable  [NOPRI[NT]|PRI[NT]]

    下面对每种方式给予解释:
    a. Syntax
    DEF[INE] [variable]|[variable = text]
    定义一个用户变量并且可以分配给它一个CHAR值。

    assign the value MANAGER to the variable POS, type:
    SQL> DEFINE POS = MANAGER

    assign the CHAR value 20 to the variable DEPTNO, type:
    SQL> DEFINE DEPTNO = 20

    list the definition of DEPTNO, enter
    SQL> DEFINE DEPTNO
            ―――――――――――――――
    DEFINE DEPTNO = ”20” (CHAR)

    定义了用户变量POS后,就可以在sql*plus中用&POS或&&POS来引用该变量的值,sql*plus不会再提示你给变量输入值。

    b. COL[UMN] [{column|expr} NEW_V[ALUE] variable [NOPRI[NT]|PRI[NT]]
    NEW_V[ALUE] variable
    指定一个变量容纳查询出的列值。
    例:column col_name new_value var_name noprint
       select col_name from table_name where ……..
    将下面查询出的col_name列的值赋给var_name变量.

    一个综合的例子:
    得到一个列值的两次查询之差(此例为10秒之内共提交了多少事务):
    column redo_writes new_value commit_count

    select sum(stat.value) redo_writes
    from v$sesstat stat, v$statname sn
    where stat.statistic# = sn.statistic#
    and sn.name = 'user commits';

    -- 等待一会儿(此处为10秒);
    execute dbms_lock.sleep(10);

    set veri off
    select sum(stat.value) - &commit_count commits_added
    from v$sesstat stat, v$statname sn
    where stat.statistic# = sn.statistic#
    and sn.name = 'user commits';


    38. 定义一个绑定变量
    VAR[IABLE] [variable [NUMBER|CHAR|CHAR (n)|NCHAR|NCHAR (n) |VARCHAR2 (n)|NVARCHAR2 (n)|CLOB|NCLOB|REFCURSOR]]
    定义一个绑定变量,该变量可以在pl/sql中引用。
    可以用print命令显示该绑定变量的信息。
    如:
    column inst_num  heading "Inst Num"  new_value inst_num  format 99999;
    column inst_name heading "Instance"  new_value inst_name format a12;
    column db_name   heading "DB Name"   new_value db_name   format a12;
    column dbid      heading "DB Id"     new_value dbid      format 9999999999 just c;

    prompt
    prompt Current Instance
    prompt ~~~~~~~~~~~~~~~~

    select d.dbid            dbid
         , d.name            db_name
         , i.instance_number inst_num
         , i.instance_name   inst_name
      from v$database d,
           v$instance i;

    variable dbid       number;
    variable inst_num   number;
    begin
      :dbid      :=  &dbid;
      :inst_num  :=  &inst_num;
    end;
    /
    说明:
    在sql*plus中,该绑定变量可以作为一个存储过程的参数,也可以在匿名PL/SQL块中直接引用。为了显示用VARIABLE命令创建的绑定变量的值,可以用print命令

    注意:
    绑定变量不同于变量:
    1.        定义方法不同
    2.        引用方法不同
    绑定变量::variable_name
            变量:&variable_name or &&variable_name
    3.在sql*plus中,可以定义同名的绑定变量与用户变量,但是引用的方法不同。

    39. &与&&的区别
    &用来创建一个临时变量,每当遇到这个临时变量时,都会提示你输入一个值。
    &&用来创建一个持久变量,就像用用define命令或带new_vlaue字句的column命令创建的持久变量一样。当用&&命令引用这个变量时,不会每次遇到该变量就提示用户键入值,而只是在第一次遇到时提示一次。

    如,将下面三行语句存为一个脚本文件,运行该脚本文件,会提示三次,让输入deptnoval的值:
    select count(*) from emp where deptno = &deptnoval;
    select count(*) from emp where deptno = &deptnoval;
    select count(*) from emp where deptno = &deptnoval;

    将下面三行语句存为一个脚本文件,运行该脚本文件,则只会提示一次,让输入deptnoval的值:
    select count(*) from emp where deptno = &&deptnoval;
    select count(*) from emp where deptno = &&deptnoval;
    select count(*) from emp where deptno = &&deptnoval;

    40.在输入sql语句的过程中临时先运行一个sql*plus命令(摘自www.itpub.com)
    #
    有没有过这样的经历? 在sql*plus中敲了很长的命令后, 突然发现想不起某个列的名字了, 如果取消当前的命令,待查询后再重敲, 那太痛苦了. 当然你可以另开一个sql*plus窗口进行查询, 但这里提供的方法更简单.

    比如说, 你想查工资大于4000的员工的信息, 输入了下面的语句:

    SQL> select deptno, empno, ename
    2 from emp
    3 where
    这时, 你发现你想不起来工资的列名是什么了.

    这种情况下, 只要在下一行以#开头, 就可以执行一条sql*plus命令, 执行完后, 刚才的语句可以继续输入

    SQL>> select deptno, empno, ename
    2 from emp
    3 where
    6 #desc emp
    Name Null? Type
    ----------------------------------------- -------- --------------
    EMPNO NOT NULL NUMBER(4)
    ENAME VARCHAR2(10)
    JOB VARCHAR2(9)
    MGR NUMBER(4)
    HIREDATE DATE
    SAL NUMBER(7,2)
    COMM NUMBER(7,2)
    DEPTNO NUMBER(2)

    6 sal > 4000;

    DEPTNO EMPNO ENAME
    ---------- ---------- ----------
    10 7839 KING

    41. SQLPlus中的快速复制和粘贴技巧(摘自www.cnoug.org)
    1) 鼠标移至想要复制内容的开始
    2) 用右手食指按下鼠标左键
    3) 向想要复制内容的另一角拖动鼠标,与Word中选取内容的方法一样
    4) 内容选取完毕后(所选内容全部反显),鼠标左键按住不动,用右手中指按鼠标右键
    5) 这时,所选内容会自动复制到SQL*Plus环境的最后一行
  • Jmeter 入门使用(1)

    2009-11-09 17:19:42


    简介:
      Apache Software Foundation 的 Stefano Mazzocchi 是JMeter的最初开发人员。他编写它主要用于测试Apache JServ的性能(一个后来被Apache Tomcat项目替代的项目)。我们重新设计了JMeter,增强了它的GUI和添加了功能测试支持。

      Apache JMeter 是100%的Java桌面应用程序。用于对软件做压力测试(例如Web应用)。 它可以用于测试静态和动态资源例如静态文件、Java 小服务程序、CGI 脚本、Java 对象、数据库, FTP 服务器, 等等。JMeter 可以用于对服务器、网络或对象模拟巨大的负载,来在不同压力类别下测试它们的强度和分析整体性能。

      另外,JMeter能够对应用程序做功能/回归测试,通过创建带有断言的脚本来验证你的程序返回了你期望的结果。为了最大限度的灵活性,JMeter允许使用正则表达式创建断言。

    特点:
      在设计阶段,JMeter能够充当HTTP PROXY(代理)来记录IE/NETSCAPE的HTTP请求,也可以记录apache等WebServer的log文件来重现HTTP流量。当这些 HTTP客户端请求被记录以后,测试运行时可以方便的设置重复次数和并发度(线程数)来产生巨大的流量。JMeter还提供可视化组件以及报表工具把量服 务器在不同压力下的性能展现出来。

      相比其他HTTP测试工具,JMeter最主要的特点在于扩展性强。JMeter能够自动扫描其lib/ext子目录下.jar文件中的插件,并且将其装载到内存,让用户通过不同的菜单调用。

    测试结果字段的意义:
      1、Label: 定义的HTTP请求名称
      2、Samples: 表示这次测试中一共发出了多少个请求
      3、Average: 访问页面的平均响应时间
      4、Min: 访问页面的最小响应时间
      5、Max: 访问页面的最大响应时间
      6、Error%: 错误的请求的数量/请求的总数
      7、Throughput:每秒完成的请求数
      8、KB/Sec: 每秒从服务器端接收到的数据量

    远景:
      我们希望看到随着开发人员利用插件架构的优势,JMeter的能力能够迅速扩展。将来开发的主要目标是使得JMeter尽可能地变成一个有用的衰退测试工具,而不损失JMeter地压力测试能力。

    介绍一个简单的Http请求性能测试:

    1、添加线程组。

       选中测试计划,右键单击选择添加菜单,然后再选择线程组打开线程组配置。
     
      首先给这个线程组起一个有意义的名字,在名字域里,输入“测试”.
      然后,在线程数里输入5,下一个输入域,Ramp_Up Period,保持不变。这个值是告诉JMeter在开始各个线程之间延迟多长时间。例如,如果你输入5,JMeter将会在5秒前完成该线程里的所有操 作。因此,如果我们有5个线程和5秒Ramp_Up Period,延迟在开始线程之间会是1 秒(5个线程/5秒=1秒)。如果你设置此值为0,JMeter则会立刻开始此线程的所有操作。
    最后,清除循环次数的复选项“永远”,然后输入2。这个值是告诉JMeter你的测试重复多少次。如果你输入1,那么JMeter只会运行一次你的测试。要不停的运行你的测试计划,选中“永远”复选框。

    在大多应用里,你必须手工接受你在控制面板里做的改动,但是,在JMeter里,控制面板能自动地接受你的变动如同你改动它们一样。如果你更改元件的名字,树将在你离开控制面板后被更新,以新文本显示(例如,当选择其它树元件)。

    2、给新添加的测试线程组添加第一个HTTP请求。

       选择上面新建的线程组,右键 添加->取样器-> HTTP请求,然后填写其属性。
    说明:
    名称: HTTP 默认请求值 该元素的名称
      服务器名称或IP:l测试服务器的IP或者名字
      端口号:80 服务器提供服务的端口号,服务器是Tomcat,所以端口号是80
      协议: http 发送测试请求时使用的协议,通常都用HTTP协议
       方法:http请求中使用的方法,如get post等。你要测试服务器对http请求的相应,你首先需要确定该http请求中使用的是什么方法,确定方法:查看网页源代码或者jsp,查找“method”,代码中method后面的值就是http请求中使用到的方法
      路径: 此处填写你要测试的页面的路径,不包括服务器地址
      同请求一起发送的参数:因为我测试的是登录,故添加了四个同请求一起发送的参数。要确定同请求一起发送的参数,你也需要查看网页源代码或者jsp,查找“input”,将该标签中的name值作为参数名,而将相应的value作为参数值。

    3、添加监视。
       选择HTTP请求元件,然后添加一个图形结果监视器。 然后,你需要指定一个目录和一个输出的文件名。你可以输入到文件名域里,也可以选择“浏览”按钮来浏览目录并输入文件名。






  • Web 常用的测试方法(2)

    2009-08-19 11:42:10

      用户界面测试
    1 导航测试
       导航描述了用户在一个页面内操作的方式,在不同的用户接口控制之间,例如按钮、对话框、列表和窗口等;或在不同的连接页面之间。通过考虑下列问题,可以 决定一个Web应用系统是否易于导航:导航是否直观?Web系统的主要部分是否可通过主页存取?Web系统是否需要站点地图、搜索引擎或其他的导航帮助?
       在一个页面上放太多的信息往往起到与预期相反的效果。Web应用系统的用户趋向于目的驱动,很快地扫描一个Web应用系统,看是否有满足自己需要的信 息,如果没有,就会很快地离开。很少有用户愿意花时间去熟悉Web应用系统的结构,因此,Web应用系统导航帮助要尽可能地准确。
      导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容,内容在什么地方。
      Web应用系统的层次一旦决定,就要着手测试用户导航功能,让最终用户参与这种测试,效果将更加明显。

    2 图形测试
      在Web应用系统中,适当的图片和动画既能起到广告宣传的作用,又能起到美化页面的功能。一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有:
      (1)要确保图形有明确的用途,图片或动画不要胡乱地堆在一起,以免浪费传输时间。Web应用系统的图片尺寸要尽量地小,并且要能清楚地说明某件事情,一般都链接到某个具体的页面。
      (2)验证所有页面字体的风格是否一致。
      (3)背景颜色应该与字体颜色和前景颜色相搭配。
      (4)图片的大小和质量也是一个很重要的因素,一般采用JPGGIF压缩,最好能使图片的大小减小到 30k 以下
      (5)最后,需要验证的是文字回绕是否正确。如果说明文字指向右边的图片,应该确保该图片出现在右边。不要因为使用图片而使窗口和段落排列古怪或者出现孤行。
      通常来说,使用少许或尽量不使用背景是个不错的选择。如果您想用背景,那么最好使用单色的,和导航条一起放在页面的左边。另外,图案和图片可能会转移用户的注意力。

    3 内容测试
      内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。
       信息的正确性是指信息是可靠的还是误传的。例如,在商品价格列表中,错误的价格可能引起财政问题甚至导致法律纠纷;信息的准确性是指是否有语法或拼写错 误。这种测试通常使用一些文字处理软件来进行,例如使用Microsoft Word"拼音与语法检查"功能;信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口,也就是一般Web站点中的所谓"相关文 章列表"
      对于开发人员来说,可能先有功能然后才对这个功能进行描述。大家坐在一起讨论一些新的功能,然后开始开发,在开发的时候, 开发人员可能不注重文字表达,他们添加文字可能只是为了对齐页面。不幸的是,这样出来的产品可能产生严重的误解。因此测试人员和公关部门一起检查内容的文 字表达是否恰当。否则,公司可能陷入麻烦之中,也可能引起法律方面的问题。测试人员应确保站点看起来更专业些。过分地使用粗体字、大字体和下划线可能会让 用户感到不舒服。在进行用户可用性方面的测试时,最好先请图形设计专家对站点进行评估。你可能不希望看到一篇到处是黑体字的文章,所以相信您也希望自己的 站点能更专业一些。最后,需要确定是否列出了相关站点的链接。很多站点希望用户将邮件发到一个特定的地址,或者从某个站点下载浏览器。但是如果用户无法点 击这些地址,他们可能会觉得很迷惑。

     4
    表格测试
      需要验证表格是否设置正确。用户是否需要向右滚动页面才能看见产品的价格?把价格放在左边,而把产品细节放在右边是否更有效? 每一栏的宽度是否足够宽,表格里的文字是否都有折行?是否有因为某一格的内容太多,而将整行的内容拉长?

    整体界面测试
      整体界面是指整个Web应用系统的页面结构设计,是给用户的一个整体感。例如:当用户浏览Web应用系统时是否感到舒适,是否凭直觉就知道要找的信息在什么地方?整个Web应用系统的设计风格是否一致?
      对整体界面的测试过程,其实是一个对最终用户进行调查的过程。一般Web应用系统采取在主页上做一个调查问卷的形式,来得到最终用户的反馈信息。
      对所有的用户界面测试来说,都需要有外部人员(与Web应用系统开发没有联系或联系很少的人员)的参与,最好是最终用户的参与。
      采取措施:手动测试,参与人员最好有外部人员

     兼容性测试
    1 平台测试
       市场上有很多不同的操作系统类型,最常见的有WindowsUnixMacintoshLinux等。Web应用系统的最终用户究竟使用哪一种操 作系统,取决于用户系统的配置。这样,就可能会发生兼容性问题,同一个应用可能在某些操作系统下能正常运行,但在另外的操作系统下可能会运行失败。
      因此,在Web系统发布之前,需要在各种操作系统下对Web系统进行兼容性测试。

    2 浏览器测试
       浏览器是Web客户端最核心的构件,来自不同厂商的浏览器对Java,、JavaScript ActiveX plug-ins或不同的HTML规格有不同的支持。例如,ActiveXMicrosoft的产品,是为Internet Explorer而设计的,JavaScriptNetscape的产品,JavaSun的产品等等。另外,框架和层次结构风格在不同的浏览器中也有 不同的显示,甚至根本不显示。不同的浏览器对安全性和Java的设置也不一样。
      测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中,测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。

     
    3 分辨率测试
      页面版式在 640x400600x800 1024x768 的分辨率模式下是否显示正常? 字体是否太小以至于无法浏览? 或者是太大? 文本和图片是否对齐?

    4
    Modem/连接速率
      是否有这种情况,用户使用 28.8 modem下载一个页面需要 10 分钟,但测试人员在测试的时候使用的是 T1 专线? 用户在下载文章或演示的时候,可能会等待比较长的时间,但却不会耐心等待首页的出现。最后,需要确认图片不会太大。

    5 打印机
       用户可能会将网页打印下来。因此网也在设计的时候要考虑到打印问题,注意节约纸张和油墨。有不少用户喜欢阅读而不是盯着屏幕,因此需要验证网页打印是否 正常。有时在屏幕上显示的图片和文本的对齐方式可能与打印出来的东西不一样。测试人员至少需要验证订单确认页面打印是正常的。

    组合测试
       最后需要进行组合测试。600x800 的分辨率在 MAC 机上可能不错,但是在 IBM 兼容机上却很难看。在 IBM 机器上使用 Netscape 能正常显示,但却无法使用 Lynx 来浏览。如果是内部使用的 web 站点,测试可能会轻松一些。如果公司指定使用某个类型的浏览器,那么只需在该浏览器上进行测试。如果所有的人都使用 T1 专线,可能不需要测试下载施加。(但需要注意的是,可能会有员工从家里拨号进入系统) 有些内部应用程序,开发部门可能在系统需求中声明不支持某些系统而只支持一些那些已设置的系统。但是,理想的情况是,系统能在所有机器上运行,这样就不会 限制将来的发展和变动。
      采取措施:根据实际情况,采取等价划分的方法,列出兼容性矩阵

    安全测试
      即使站点不接受信用卡支付,安全问题也是非常重要的。Web 站点收集的用户资料只能在公司内部使用。如果用户信息被黑客泄露,客户在进行交易时,就不会有安全感。

    1 目录设置
       Web 安全的第一步就是正确设置目录。每个目录下应该有 index.html main.html 页面,这样就不会显示该目录下的所有内容。我服务的一个公司没有执行这条规则。我选中一幅图片,单击鼠标右键,找到该图片所在的路径"… com/objects/images"。然后在浏览器地址栏中手工输入该路径,发现该站点所有图片的列表。这可能没什么关系。我进入下一级目录 "…com/objects" ,点击 jackpot。在该目录下有很多资料,其中引起我注意的是已过期页面。该公司每个月都要更改产品价格,并且保存过期页面。我翻看了一下这些记录,就可以 估计他们的边际利润以及他们为了争取一个合同还有多大的降价空间。如果某个客户在谈判之前查看了这些信息,他们在谈判桌上肯定处于上风。

    2 SSL
         很多站点使用 SSL 进行安全传送。你知道你进入一个 SSL 站点是因为浏览器出现了警告消息,而且在地址栏中的 HTTP 变成 HTTPS。如果开发部门使用了SSL,测试人员需要确定是否有相应的替代页面(适用于3.0 以下版本的浏览器,这些浏览器不支持SSL。当用户进入或离开安全站点的时候,请确认有相应的提示信息。是否有连接时间限制?超过限制时间后出现什么情 况?

    3 登录
      有些站点需要用户进行登录,以验证他们的身份。这样对用户是方便的,他们不需要每次都输入个人 资料。你需要验证系统阻止非法的用户名/口令登录,而能够通过有效登录。用户登录是否有次数限制? 是否限制从某些 IP 地址登录? 如果允许登录失败的次数为3,你在第三次登录的时候输入正确的用户名和口令,能通过验证吗? 口令选择有规则限制吗? 是否可以不登陆而直接浏览某个页面?
      Web应用系统是否有超时的限制,也就是说,用户登陆后在一定时间内(例如15分钟)没有点击任何页面,是否需要重新登陆才能正常使用。

    4 日志文件
      在后台,要注意验证服务器日志工作正常。日志是否记所有的事务处理? 是否记录失败的注册企图? 是否记录被盗信用卡的使用? 是否在每次事务完成的时候都进行保存? 记录IP 地址吗? 记录用户名吗?

    5 脚本语言
       脚本语言是常见的安全隐患。每种语言的细节有所不同。有些脚本允许访问根目录。其他只允许访问邮件服务器,但是经验丰富的黑客可以将服务器用户名和口令 发送给他们自己。找出站点使用了哪些脚本语言,并研究该语言的缺陷。还要需要测试没有经过授权,就不能在服务器端放置和编辑脚本的问题。最好的办法是订阅 一个讨论站点使用的脚本语言安全性的新闻组。 

    接口测试
      在很多情况下,web 站点不是孤立。Web 站点可能会与外部服务器通讯,请求数据、验证数据或提交订单。

    1 服务器接口
      第一个需要测试的接口是浏览器与服务器的接口。测试人员提交事务,然后查看服务器记录,并验证在浏览器上看到的正好是服务器上发生的。测试人员还可以查询数据库,确认事务数据已正确保存。
      这种测试可以归到功能测试中的表单测试和数据校验测试中

    外部接口
       有些 web 系统有外部接口。例如,网上商店可能要实时验证信用卡数据以减少欺诈行为的发生。测试的时候,要使用 web 接口发送一些事务数据,分别对有效信用卡、无效信用卡和被盗信用卡进行验证。如果商店只使用 Visa 卡和 Mastercard 卡, 可以尝试使用 Discover 卡的数据。(简单的客户端脚本能够在提交事务之前对代码进行识别,例如 3 表示 American Express4 表示 Visa5 表示 Mastercard6 代表Discover)通常,测试人员需要确认软件能够处理外部服务器返回的所有可能的消息。
      这种情况在远程抄表中可能会体现到

    错误处理
       最容易被测试人员忽略的地方是接口错误处理。通常我们试图确认系统能够处理所有错误,但却无法预期系统所有可能的错误。尝试在处理过程中中断事务,看看 会发生什么情况?订单是否完成?尝试中断用户到服务器的网络连接。尝试中断 web 服务器到信用卡验证服务器的连接。在这些情况下,系统能否正确处理这些错误?是否已对信用卡进行收费?如果用户自己中断事务处理,在订单已保存而用户没有 返回网站确认的时候,需要由客户代表致电用户进行订单确认。
      采取措施:在理解需求的基础上,充分发挥想象力,尽量比较全面的列出各种异常情况

  • Web 常用的测试方法(1)

    2009-08-19 11:36:09

    1. 页面链接检查:每一个链接是否都有对应的页面,并且页面之间切换正确。
    2. 相关性检查:删除/增加一项会不会对其他项产生影响,如果产生影响,这些影响是否都正确。

    3. 检查按钮的功能是否正确:如updatecanceldeletesave等功能是否正确。

    4. 字符串长度检查:输入超出需求所说明的字符串长度的内容,看系统是否检查字符串长度,会不会出错。

    5. 字符类型检查:在应该输入指定类型的内容的地方输入其他类型的内容 (如在应该输入整型的地方输入其他字符类型) ,看系统是否检查字符类型,会否报错。

    6. 标点符号检查:输入内容包括各种标点符号,特别是空格、各种引号、回车键。看系统处理是否正确。

    7. 中文字符处理:在可以输入中文的系统输入中文,看会否出现乱码或出错。

    8. 检查带出信息的完整性:在查看信息和update信息时,查看所填写的信息是不是全部带出,带出信息和添加的是否一致。

    9. 信息重复:在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理。

    10. 检查删除功能:在一些可以一次删除多个信息的地方,不选择任何信息,按”delete”,看系统如何处理,会否出错;然后选择一个和多个信息,进行删除,看是否正确处理。

    11. 检查添加和修改是否一致:检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填;添加规定为整型的项,修改也必须为整型。

    12. 检查修改重名:修改时把不能重名的项改为已存在的内容,看会否处理,报错。同时,也要注意,会不会报和自己重名的错。

    13. 重复提交表单:一条已经成功提交的纪录,back后再提交,看看系统是否做了处理。

    14. 检查多次使用back键的情况:在有back的地方,back,回到原来页面,再back,重复多次,看会否出错。

    15. search检查:在有search功能的地方输入系统存在和不存在的内容,看search结果是否正确。如果可以输入多个search条件,可以同时添加合理和不合理的条件,看系统处理是否正确。

    16. 输入信息位置:注意在光标停留的地方输入信息时,光标和所输入的信息会否跳到别的地方。

    17. 上传下载文件检查:上传下载文件的功能是否实现,上传文件是否能打开。对上传文件的格式有何规定,系统是否有解释信息,并检查系统是否能够做到。

    18. 必填项检查:应该填写的项没有填写时系统是否都做了处理,对必填项是否有提示信息,如在必填项前加*  

    19. 快捷键检查:是否支持常用快捷键,如Ctrl+C Ctrl+V Backspace等,对一些不允许输入信息的字段,如选人,选日期对快捷方式是否也做了限制。

    20. 回车键检查:在输入结束后直接按回车键,看系统处理如何,会否报错。
  • 软件测试方法简介

    2009-08-19 11:23:44

     

    冒烟测试(smoke testing,据说是微软起的名字。在《微软项目求生法则》一书第14构建过程关于冒烟测试,就是开发人员在个人版本的软件上执行目前的冒烟测试项目,确定新的程序代码不出故障。

    冒烟测试的名称可以理解为该种测试耗时短,仅用一袋烟功夫足够了。也有人认为是形象地类比新电路板的基本功能检查。任何新电路板焊好后,先通电检查,如果存在设计缺陷,电路板可能会短路,板子冒烟了。

    冒烟测试的对象是每一个新编译的需要正式测试的软件版本,目的是确认软件基本功能正常,可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。

    在一般软件公司,软件在编写过程中,内部需要编译多个版本(Builds),但是只有有限的几个版本需要执行正式测试(根据项目开发计划),这些需要执行的中间测试版本,在刚刚编译出来后,软件编译人员需要进行基本性能确认测试,例如是否可以正确安装/卸载,主要功能是否实现,是否存在严重死机或数据严重丢失等Bug。如果通过了该测试,则可以根据正式测试文档进行正式测试。否则,就需要重新编译版本,再次执行版本可接收确认测试,直到成功。

    新版本的基本功能确认检查的测试,有的公司成为版本健康检查(Build Sanity Check)。对于编译的本地化软件新版本,除了进行上面提到的各种测试检查,还要检查是否在新的本地化版本中正确包含了全部应该本地化的文件。可以通过采用文件和目录结构比较工具,首先比较源语言版本和本地化版本的文件和目录中的文件数目文件名称和文件日期等,这个过程称为镜像检查(Build Image Check)。

     

    二:随机测试—Ad hoc testing

    在软件测试中除了根据测试样例和测试说明书进行测试外,还需要进行随机测试(Ad-hoc testing),主要根据测试者的经验对软件进行功能和性能抽查。随机测试是根据测试说明书执行样例测试的重要补充手段,是保证测试覆盖完整性的有效方式和过程。

    随机测试主要是对被测试软件的一些重要功能进行复测,也包括测试那些当前的测试样例(Test Case)没有覆盖到的部分。另外,对于软件更新和新增加的功能要重点测试。重点对一特殊情况点、特殊的使用环境、并发性、进行检查。尤其是对以前测试发现的重大Bug,进行再次测试,可以结合回归测试 (Regressive testing) 一起进行。

    理论上,每一个被测试软件版本都需要执行随机测试,尤其对于最后的将要发布的版本更要重视随机测试。随机测试最好由具有丰富测试经验的熟悉被测软件的测试人员进行测试。对于被测试的软件越熟悉,执行随机测试越容易。只有不断的积累测试经验,包括具体的测试执行和对缺陷跟踪记录的分析,不断总结,才能提高。

     

    三:黑盒测试---Black box testing

    指测试人员不关心程序具体如何实现的一种测试方法。根据软件的规格对软件进行各种输入和观察软件的各种输出结果来发现软件的缺陷的测试,这类测试不考虑软件内部的运作原理,因此软件对用户来说就像一个黑盒子。

     

    四:白盒测试---White box testing,根据软件内部的工作原理分析来进行测试,基于代码的测试,测试人员通过阅读程序代码或者通过使用开发工具中的单步调试来判断软件的质量,一般黑盒测试由项目经理在程序员开发中来实现。

    五:α测试---Alpha testing

    α测试是由一个用户在开发环境下进行了的测试,也可以是公司内部的用户在模拟实际操作环境下进行的的控制测试,Alpha测试不能由程序员或测试员完成。

     

    六:β测试---Beta testing

    测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场,Beta测试不能由程序员或测试员完成。

     

    七:自动化测试---Automated Testing

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

    八:兼容性测试---Compatibility Testing

    也称“配置测试”,测试软件是否和系统的其它与之交互的元素之间兼容,如:浏览器,操作系统,硬件等。验证测试对象在不同的软件和硬件配置中的运行情况。

     

    九:动态测试---Dynamic testing通过执行软件的手段来测试软件。

     

    十:静态测试(Static testing)不通过执行来测试一个系统。如代码检查,文档检查和评审等。

     

    十一:功能测试---Functional testing

    也称“行为测试(Behavioral testing),根据产品特征、操作描述和用户方案,测试一个产品的特性和可操作行为以确定它们满足设计需求。本地化软件的功能测试,用于验证应用程序或网站对目标用户能正确工作。使用适当的平台、浏览器和测试脚本,以保证目标用户的体验将足够好,就像应用程序是专门为该市场开发的一样。

     

    十二:安装测试(Installing testing

    确保该软件在正常情况和异常情况的不同条件下,例如,进行首次安装、升级、完整的或自定义的安装都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。核实软件在安装后可立即正常运行。安装测试包括测试安装代码以及安装手册。安装手册提供如何进行安装,安装代码提供安装一些程序能够运行的基础数据。

     

    十三:单元测试(Unit testing),指一段代码的基本测试,其实际大小是未定的,通常是一个函数或子程序,一般由开发者执行。

     

    十四:集成测试(Integrating testing

    被测试系统的所有组件都集成在一起,找出被测试系统组件之间关系和接口中的错误码。该测试一般在单元测试之后进行。

     

    十五:国际化测试(International testing

    国际化测试的目的是测试软件的国际化支持能力,发现软件的国际化的潜在问题,保证软件在世界不同区域中都能正常运行。国际化测试的重点在于执行国际字符串的输入/输出功能。国际化测试数据必须包含东亚语言、德语、复杂脚本字符和英语(可选)的混合字符。

     

    十六:本地化能力测试(Localizability testing

    本地化能力是指不需要重新设计或修改代码,将程序的用户界面翻译成任何目标语言的能力。为了降低本地化能力测试的成本,提高测试效率,本地化能力测试是通常在软件的伪本地化版本上进行。本地化能力测试中发现的典型错误包括:字符的硬编码(即软件中需要本地化的字符写在代码内部),对需要本地化的字符长度设置了国定值,在软件运行时以控件位置定位,图标和位图中包含了需要本地化的文本,软件的用户界面与文档术语不一致等。、

     

    十七:本地化测试(Localization testing

    本地化测试的对象是软件的本地化版本。本地化测试的目的是测试特定目标区域设置的软件本地化质量。本地化测试的环境是在本地化的操作系统上安装本地化的软件。从测试方法可以分为基本功能测试,安装/卸载测试,当地区域的软件硬件兼容性测试。测试的内容主要包括软件本地化后的界面布局和软件翻译的语言质量,包含软件、文档和联机帮助等部分。

     

    十八:负载测试(Load testing

    通过测试系统在资源超负荷情况下的表现,以发现设计上的错误或验证系统的负载能力。在这种测试中,将使测试对象承担不同的工作量,以评测和评估测试对象在不同工作量条件下的性能行为,以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最在预期工作量的情况下仍能正常运行。此外,负载测试还要评估性能特征,例如:响应时间、事务处理速率和其他与时间相关的方面。

     

    十九:引导测试(Pilot testing

    软件包开发中,验证系统在真实硬件和客户基础上处理典型操作的能力。在软件外包测试中,引导测试通常是客户检查软件测试公司测试能力的一种形式,只有通过了客户特定的引导测试,软件测试公司才能接受客户真实软件项目的软件测试。

     

    二十:可移植性测试(Portability testing

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

     

    二十一:健全测试(Sanity testing

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

     

    二十二:回归测试(Regression testing

    在发生修改之后重新测试先前的测试以保证修改的正确性。理论上,对软件的任何新版本,都需要进行回归测试,验证以前发现和修复的错误是否在新软件版本上再现。

    二十三:GB 18030 测试---软件支持GB 18030字符集标准能力测试,包括GB 18030字符的输入、输出、显示、存储的支持过程。

     

    二十四:User interface testing (用户界面测试),指测试用户界面的风格是否满足客户要求,文字是否正确,页面是否美观,文字,图片组合是否完美,操作是否友好等等。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。

     

    二十五:验收测试—Acceptance testing

    系统开发生命周期方法论的一个阶段,这时相关的用户和/或独立测试人员根据测试计划各结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产口是否能够满足合同或用户所规定需求的测试。这是管理必和防御性控制。

     


  • Alpha和Beta测试简介

    2009-08-19 11:21:40

    AlphaBeta测试简介

    大型通用软件,在正式发布前,通常需要执行AlphaBeta测试,目的是从实际终端用户的使用角度,对软件的功能和性能进行测试,以发现可能只有最终用户才能发现的错误。

    Alpha
    测试是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的受控测试,Alpha测试不能由程序员或测试员完 成。Alpha测试发现的错误,可以在测试现场立刻反馈给开发人员,由开发人员及时分析和处理。目的是评价软件产品的功能、可使用性、可靠性、性能和支 持。尤其注重产品的界面和特色。Alpha测试可以从软件产品编码结束之后开始,或在模块(子系统)测试完成后开始,也可以在确认测试过程中产品达到一定 的稳定和可靠程度之后再开始。有关的手册(草稿)等应该在Alpha测试前准备好。

    Beta
    测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场,Beta测试不能由程序员或测试员完成。因而, Beta测试是在开发者无法控制的环境下进行的软件现场应用。在Beta测试中,由用户记下遇到的所有问题,包括真实的以及主管认定的,定期向开发者报 告,开发者在综合用户的报告后,做出修改,最后将软件产品交付给全体用户使用。Beta测试着重于产品的支持性,包括文档、客户培训和支持产品的生产能 力。只有当Alpha测试达到一定的可靠程度后,才能开始Beta测试。由于Beta测试的主要目标是测试可支持性,所以Beta测试应该尽可能由主持产 品发行的人员来管理。

    由于AlphaBeta测试的组织难度大,测试费用高,测试的随机性强、测试周期跨度较长,测试质量和测试效率难于保证,所以,很多专业软件可能不再进 Beta测试。随着测试技术的提高,以及专业测试服务机构的大量涌现,很多软件的Beta测试外包给这些专业测试机构进行测试。

  • 【转】10款常用的JAVA测试工具

    2009-08-19 10:57:18

    1. 美国Segue公司的Silk系列产品

        Segue公司一直专注于软件质量优化领域。在Segue的产品套件中,拥有业内最强劲且最容易使用的、用于企业应用测试、调优和监测的自动化工具,能够帮助用户保障应用在其生命周期内的可靠性和性能。

     

    (1) SilkPerformer——企业级性能测试工具

    企业级自动化测试工具能够支持多种系统,如Java.NetWirelessCOMCORBAOracleCitrixMetaFrame、客户机/服务器、以及各种ERP/CRM应用

    多项专利技术精确模拟各种复杂的企业环境

    可视化脚本记录功能及自定义工具简化了测试创建工作

    SilkPerformerJava/.NET浏览器以及JUnit/NUnit测试输入功能简化了对并发访问情况下远程应用组件的早期负载测试工作

    方便易用,工作流向导会逐步引导用户完成整个测试流程

     

    (2) SilkTest International——业内唯一的Unicode功能测试工具

    u SilkBean 充分利用 Java 语言的“编写一次,随处使用”的优点,让用户不必修改现有的脚本而能够在多种基于 Unix 的系统上运行

    能够识别多种开发平台,如JavaJavaScriptHTMLActiveXVisual Basic C/C++

    一套脚本可供所有支持的语言使用

    内置的错误恢复系统不仅具有自定义功能,可进行无人看守的自动测试

    赛格瑞(Segue)公司是全球范围内专注于软件质量优化解决方案的领导者。2005年,赛格瑞(Segue)公司在中国设立了专门的销售服务公司,因此,赛格瑞(Segue)公司的软件测试产品在中国有了更好的技术支持。

    参考网站:http://www.segue.com.cn/

    推荐指数:★★★★★

     

    2. MaxQ

        MaxQ是一个免费的功能测试工具。它包括一个HTTP代理工具,可以录制测试脚本,并提供回放测试过程的命令行工具。测试结果的统计图表类似于一些较昂贵的商用测试工具。MaxQ希望能够提供一些关键的功能,比如HTTP测试录制回放功能,并支持脚本。

    参考网站:http://maxq.tigris.org/

    推荐指数:★★★☆☆

     

    3. Httpunit

        HttpUnit是一个开源的测试工具,是基于JUnit的一个测试框架,主要关注于测试Web应用,解决使用JUnit框架无法对远程Web内容进行测试的弊端。

        HttpUnit提供的帮助类让测试者可以通过Java类和服务器进行交互,并且将服务器端的响应当作文本或者DOM对象进行处理。HttpUnit还提 供了一个模拟Servlet容器,让测试者不需要发布Servlet,就可以对Servlet的内部代码进行测试。本文中作者将详细的介绍如何使用 HttpUnit提供的类完成集成测试。

    参考网站:http://www.httpunit.org/

    推荐指数:★★★☆☆

     

    4. Junit

        是通用的测试 java 程序的测试框架JUnit可以对Java代码进行白盒测试。通过JUnitk可以用mock objects进行隔离测试;用Cactus进行容器内测试;用AntMaven进行自动构建;在Eclipse内进行测试;对Java应用程序、FilterServletEJBJSP、数据库应用程序、Taglib等进行单元测试。

    参考网站:http://www.junit.org/

    推荐指数:★★★★★

     

    5. Jtest

        JtestParasoft公司推出的一款针对java语言的自动化白盒测试工具, 它通过自动实现java的单元测试和代码标准校验,来提高代码的可靠性。Jtest先分析每个java类,然后自动生成junit测试用例并执行用例,从 而实现代码的最大覆盖,并将代码运行时未处理的异常暴露出来;另外,它还可以检查以DbCDesign by Contract)规范开发的代码的正确性。用户还可以通过扩展测试用例的自动生成器来添加更多的junit用例。Jtest还能按照现有的超过350个编码标准来检查并自动纠正大多数常见的编码规则上的偏差,用户可自定义这些标准,通过简单的几个点击,就能预防类似于未处理异常、函数错误、内存泄漏、性能问题、安全隐患这样的代码问题。

        JTest最大的优势在于静态代码分析,至于自动生成测试代码,当然生成测试代码框架也是不错的,但要做好单元测试用户还要做大量的工作。

    参考网站:http://www.parasoft.com/jsp/aep/aep.jsp

    推荐指数:★★★★☆

     

    6. Hansel

        Hansel 是一个测试覆盖率的工具——与用于单元测试的 JUnit framework 相集成,很容易检查单元测试套件的覆盖情况。

    参考网站:http://hansel.sourceforge.net/

    推荐指数:★★☆☆☆

     

    7. Cactus

        Cactus是一个基于JUnit框架的简单测试框架,用来单元测试服务端Java代码。Cactus框架的主要目标是能够单元测试服务端的使用Servlet对象的Java方法如HttpServletRequest,HttpServletResponse,HttpSession

        针对外部可测试组件运行时,需要把JUnit测试运行为发送HTTP请求给组件的客户端进程。为了在服务器容器内部运行JUnit测试,可以用 Cactus框架,它是一个免费的开源框架,是Apache Jakarta项目的一部分。Cactus 包含了关于JUnit客户端如何连接到服务器,然后使测试运行的详细信息。

    参考网站:http://jakarta.apache.org/cactus/

    推荐指数:★★★★☆

     

    8. JFCUnit

        JFCUnit使得你能够为Java偏移应用程序编写测试例子。它为从用代码打开的窗口上获得句柄提供了支持;为在一个部件层次定位部件提供支持;为在部件中发起事件(例如按一个按钮)以及以线程安全方式处理部件测试提供支持。

    参考网站:http://jfcunit.sourceforge.net/

    推荐指数:★★★☆☆

     

    9. StrutsTestCase

        StrutsTestCaseSTC)框架是一个开源框架,用来测试基于 Struts Web 应用程序。这个框架允许您在以下方面进行测试:

    * ActionForm. 类中的验证逻辑(validate() 方法)

    * Action 类中的业务逻辑(execute() 方法)

    * 动作转发(Action Forwards)。

    * 转发 JSP

    STC 支持两种测试类型:

    * Mock 方法 —— 在这种方法中,通过模拟容器提供的对象(HttpServletRequest HttpServletResponse ServletContext),STC 不用把应用程序部署在应用服务器中,就可以对其进行测试。

    * Cactus 方法 —— 这种方法用于集成测试阶段,在这种方法中,应用程序要部署在容器中,所以可以像运行其他 JUnit 测试用例那样运行测试用例。

    参考网站:http:// strutstestcase.sourceforge.net/

    推荐指数:★★★★☆

     

    10. TestNG

        TestNG是根据JUnit NUnit思想而构建的一个测试框架,但是TestNG增加了许多新的功能使得它变得更加强大与容易使用比如:

    * 支持JSR 175注释(JDK 1.4利用JavaDoc注释同样也支持)

    * 灵活的Test配置

    * 支持默认的runtimelogging JDK功能

    * 强大的执行模型(不再TestSuite

    * 支持独立的测试方法

    参考网站:http://testng.org/

    推荐指数:★★★★☆

  • 测试中常用词(中、英)

    2009-08-19 10:36:40

    软件测试常用单词:


    1.静态测试: Non-Execution-Based TestingStatic 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.电机电子工程师协会IEEEThe Institute of Electrical and Electronics Engineers)  

    38.要从以下几方面测试软件:
            正确性:Correctness
            实用性:Utility
            性能:Performance
            健壮性:Robustness
            可靠性:Reliability

    关于Bug
    1Bug按严重程度(Severity)分为:
          Blocker,阻碍开发和/或测试工作
          Critical,死机,丢失数据内存溢出
          Major,较大的功能缺陷
          Normal,普通的功能缺陷
          Minor,较轻的功能缺陷
          Trivial,产品外观上的问题或一些不影响使用的小毛病,如菜单或对话框中的文字拼写或字体问题等等
          Enhancement,建议或意见
    2Bug按报告状态分类(Status
           待确认的(Unconfirmed
           新提交的(New
           已分配的(Assigned
         问题未解决的(Reopened
            待返测的(Resolved
            待归档的(Verified
            已归档的(Closed
    3Bug处理意见(Resolution
            已修改的(Fixed
            不是问题(Invalid
            无法修改(Wontfix
            以后版本解决(Later
            保留(Remind
            重复(Duplicate
            无法重现(Worksforme


    性能测试用语

    并发用户数量
    the number of concurrent users

    最佳并发用户数量
    the optimum number of concurrent users

    最大并发用户数量
    the maximum number of concurrent users

     峰值并发用户数量
    the peak number of concurrent users

    平均并发用户数量
    the average number of concurrent users

    并发呼叫

    concurrent call

    并发流
    concurrent stream


    测试用例用语

    Bug report(错误报告),也称为“Bug record(错误记录),记录发现的软件错误信息的文档,通常包括错误描述、复现步骤、抓取的错误图像和注释等。


    Bug tracking system(错误跟踪系统,BTS),也称为“Defect tracking systemDTS”,管理软件测试缺陷的专用数据库系统,可以高效率地完成软件缺陷的报告、验证、修改、查询、统计、存储等任务。尤其适用于大型多语言软件的测试管理。


    Build(工作版本),软件开发过程中用于内部测试的功能和性能等不完善的软件版本。工作版本既可以是系统的可操作版本,也可以是展示要在最终产品中提供的部分功能的部分系统。


    Crash (崩溃),计算机系统或组件突然并完全的丧失功能,例如软件或系统突然退出或没有任何反应(死机)。


    Debug (调试),开发人员确定引起错误的根本原因和确定可能的修复措施的过程。一般发生在子系统或单元模块编码完成时,或者根据测试错误报告指出错误以后,开发人员需要执行调试过程来解决已存在的错误观点。


    Deployment(部署),也称为“发布(shipment)”对内部IT系统而言,指它的第一个版本通过彻底的测试、形成产品、交付给付款客户的阶段。


    Exception(异常/例外),一个引起正常程序执行挂起的事件。


    Garbage characters(乱码字符),程序界面中显示的无意义的字符,例如,程序对双字节字符集的字符不支持时,这些字符不能正确显示。


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


    Screen shot(抓屏、截图),软件测试中,将软件界面中的错误(窗口、菜单、对话框等)的全部或一部分,使用专用工具存储成图像文件,以便于后续处理。


    Priority(优先权),从商业角度出发是指错误的重要性,尤其是从客户和用户的角度出发,是指错误对于系统的可行性和可接受性的影响。与“Severity(严重性)相对照。


    Severity(严重性),错误对被测系统的影响程度,在终端用户条件下发生的可能性,软件错误妨碍系统使用的程度。与“Priority(优先权)相对照。


    Software life cycle(软件生命周期),开始于一个软件产品的构思,结束于该产品不再被使用的这段期间。


    Structured query language(结构化查询语句,SQL),在一个关系数据库中查询和处理数据的一种语言。


    TBD(To be determined,待定),在测试文档中标是一项进行中的尚未最终确定的工作。

    Test case(测试用例),为特定目标而开发的一组测试输入、执行条件和预期结果,其目标可以是测试某个程序路径或核实是否满足某个特定的需求。


    Testing coverage(测试覆盖),指测试系统覆盖被测试系统的程度,一项给定测试或一组测试对某个给定系统或构件的所有指定测试用例进行处理所达到的程度。


    Testing environment(测试环境),进行测试的环境,包括测试平台、测试基础设施、测试实验室和其他设施。


    Testing plan(测试计划),描述了要进行的测试活动的范围、方法、资源和进度的文档。它确定测试项、被测特性、测试任务、谁执行任务,并且任何风险都要冲突计划。


    Testing procedure(测试过程),指设置、执行给定测试用例并对测试结果进行评估的一系列详细步骤。


    Testing script(测试脚本)一般指的是一个特定测试的一系列指令,这些指令可以被自动化测试工具执行。


    Testing suite(测试包),一组测试用例的执行框架;一种组织测试用例的方法。在测试包里,测试用例可以组合起来创造出独特的测试条件。


    User interface(用户界面,UI),广义是指使用户可以和计算机进行交互的硬件和/或软件。狭义是指软件中的可见外观及其底层与用户交互的部分(菜单、对话框、窗口和其它控件)。

     

  • 测试前的准备工作

    2009-08-19 10:27:34

    •  测试准备工作

    在测试工作伊始,软件测试工程师应该搞清楚软件测试工作的目的是什么。如果你把这个问题提给项目经理,他往往会这样回答:发现我们产品里面的所有 BUG ,这就是你的工作目的。作为一名软件测试新手,如何才能发现所有的 BUG ?如何开始测试工作?即便面对的是一个很小的软件项目,测试需要考虑的问题也是方方面面的,包括硬件环境、操作系统、产品的软件配置环境、产品相关的业务 流程、用户的并发容量等等。该从何处下手呢?

    • 
    走读相关产品的历史测试用例

    如果你所在的公司有测试用例管理系统,那么,走读相关产品的软件测试用例是迅速提高测试用例设计水平的一条捷径。走读测试用例也是有技巧的。测试用例写作 一般会包括测试用例项和根据测试用例项细化的测试用例,下面举例说明。测试用户登录的功能是一个测试项,该测试项的目的是测试用户登录功能是否正确,是否能够完成正常的登录功能,是否能够对非法用户名和密码做异常处理等等。因此,根据该用例 项,可以设计出若干个测试用例,大多数情况下,测试用例项和测试用例是一对多的关系。

    通过走读测试用例项目,你可以掌握应该从哪些功能点着手未来的测试工作;通过走读软件测试用例,你可以了解如何根据被测试的功能点开展软件测试用例的设计工作,包括如何确定测试用例的输入、测试用例的操作步骤和测试用例的输出结果等。


    •  学习产品相关的业务知识

    软件测试人员不仅要掌握软件测试技术相关知识,对产品相关的业务知识也要学习。这很好理解,如果从事财务软件的测试工作,一定要学习财务知识;如果从事通讯产品测试工作,那么相关的通讯理论知识也是必须的;如果从事银行软件的测试,银行的业务流程也是不可或缺的知识点。

    因此,在学习软件测试技术的同时,千万不要忽略产品相关业务知识的学习。如果你是一个软件测试技术专家,但是对产品业务知识一无所知,那么也只能测试出来纯粹的软件缺陷,而面对眼前出现的产品业务相关的缺陷,很可能是视而不见,如此这般,软件测试的效果会大打折扣。

    •  
    识别测试需求

    识别测试需求是软件测试的第一步。如果开发人员能够提供完整的需求文档和接口文档,那固然好。可以根据需求文档中描述的每个功能项目的输入、处理过程和输出,来设计测试用例。如果开发人员没有提供软件需求文档,那该如何是好?下面给出几个有效的方法:

    •  
    主动获取需求

    开发人员通常不会更好地考虑软件测试,如果没有开发流程的强制规定,他们通常是不愿意提供任何开发文档,即便有强制规定,需求文档也未必能够真正指导软件 系统测试工作。因此,需要测试人员发挥主观能动性,与相关的软件开发项目经理和软件开发人员保持沟通,了解软件实现的主要功能是什么,并记录得收集到的信 息。一般来说,开发人员即便没有提供相关需求文档,也会保存一些简单的过程文档,主动向开发人员索要这些文档,可以作为测试的参考。此外,可以与公司的技 术支持人员交流,技术支持人员是最贴近用户的人,因此,通过交流可以获取第一手的用户使用感受,在测试的过程中会更加贴近用户。  

  • 正确地做事与做正确的事同样重要

    2009-07-07 15:11:52

    正确地做事与做正确的事同样重要

    一位软件工程师的6年总结

    作者:成晓旭

    (声明:欢迎转载,请保证文章的完整性)

    “又是一年毕业时”,看到一批批学子离开人生的象牙塔,走上各自的工作岗位;想想自己也曾经意气风发、踌躇满志,不觉感叹万千……本文是自己工作6年的经历沉淀或者经验提炼,希望对所有的软件工程师们有所帮助,早日实现自己的人生目标。本文主要是关于软件开发人员如何提高自己的软件专业技术方面的具体建议,前面几点旨在确定大的方向,算是废话吧。

    谨以此文献给那个自己为你奉献3年青春与激情的开发团队。还有团队成员:PPLYTYK TYFLGLCHLCDYCBDPD   

    1、   分享第一条经验:“学历代表过去、能力代表现在、学习力代表未来。”其实这是一个来自国外教育领域的一个研究结果。相信工作过几年、十几年的朋友对这个道理有些体会吧。但我相信这一点也很重要:“重要的道理明白太晚将抱憾终生!”所以放在每一条,让刚刚毕业的朋友们早点看到哈!

    2、   一定要确定自己的发展方向,并为此目的制定可行的计划。不要说什么,“我刚毕业,还不知道将来可能做什么?”,“跟着感觉走,先做做看”。因为,这样的观点会通过你的潜意识去暗示你的行为无所事事、碌碌无为。一直做技术,将来成为专家级人物?向管理方向走,成为职业经理人?先熟悉行业和领域,将来自立门户?还是先在行业里面混混,过几年转行做点别的?这很重要,它将决定你近几年、十年内“做什么事情才是在做正确的事情!”。

    3   软件开发团队中,技术不是万能的,但没有技术是万万不能的!技术型团队中,技术与人品同等重要,当然长相也比较重要哈,尤其在MM比较多的团队中。在软件项目团队中,技术水平是受人重视和尊重的重要砝码。无论你是做管理、系统分析、设计、编码,还是产品管理、测试、文档、实施、维护,多少你都要有技术基础。算我孤陋寡闻,我还真没有亲眼看到过一个外行带领一个软件开发团队成功地完成过软件开发项目,哪怕就一个,也没有看到。倒是曾经看到过一个“高学历的牛人”(非技术型)带一堆人做完过一个项目,项目交付的第二天,项目组成员扔下一句“再也受不了啦!”四分五裂、各奔东西。那个项目的“成功度”大家可想而知了。

    4、   详细制定自己软件开发专业知识学习计划,并注意及时修正和调整(软件开发技术变化实在太快)请牢记:“如果一个软件开发人员在12年内都没有更新过自己的知识,那么,其实他已经不再属于这个行业了。”不要告诉自己没有时间。来自时间管理领域的著名的“三八原则”告诫我们:另外的那8小时如何使用将决定你的人生成败!本人自毕业以来,平均每天实际学习时间超过1.5小时。

    本人毕业6年来主要的学习计划、资料:

    时间

    目标

    经典书籍

    2000

    学习工作需要的CC++Delphi

    C++编程思想、Delphi4开发大全

    2001

    学习Windows操作系统原理、Windows程序设计(SDK)知识、系统学习信息安全、密码学知识

    打开Windows这扇窗、Windows操作系统原理、Windows核心编程、windows网络编程技术、加密与解密、应用密码学、密码编码和密码分析:原理与方法

    2002

    学习软件工程、软件系统分析、设计、测试,统一软件开发方法及Rose

    UML和模式应用、统一软件开发、Rose从入门到精通、软件工程:实践者的研究方法、系统分析与设计、

    2003

    学习Java语言及技术、设计模式、

    设计模式、JAVA 2编程指南、J2EE数据库开发指南、Master EJBEJB应用指南(第2版)

    20042005

    工作原因技术毫无进步

    用极有限的时间了解心理学、社会学、经济、教育等领域的知识

    2006

    重学Java相关技术、软件开发方法论

    重构、敏捷软件开发(原则、模式与实践)、代码大全、Spring In ActionJ2EE without EJBSpring框架高级编程

     

    5、   书籍是人类进步的阶梯,对软件开发人员尤其如此。书籍是学习知识的最有效途径,不要过多地指望在工作中能遇到“世外高人”,并不厌其烦地教你。对于花钱买书,我个人经验是:千万别买国内那帮人出的书!我买的那些家伙出的书,!00%全部后悔了,无一本例外。更气愤的是,这些书在二手市场的地摊上都很难卖掉。“拥有书籍并不表示拥有知识;拥有知识并不表示拥有技能;拥有技能并不表示拥有文化;拥有文化并不表示拥有智慧。”只有将书本变成的自己智慧,才算是真正拥有了它。

    6   不要仅局限于对某项技术的表面使用上,哪怕你只是偶尔用一、二次。“对任何事物不究就里”是任何行业的工程师所不应该具备的素质。开发Windows应用程序,看看Windows程序的设计、加载、执行原理,分析一下PE文件格式,试试用SDK开发从头开发一个Windows应用程序;用VC++、DelphiJava.Net开发应用程序,花时间去研究一下MFCVCLJ2EE.Net它们框架设计或者源码;除了会用J2EEJBossSpringHibernate等等优秀的开源产品或者框架,抽空看看大师们是如何抽象、分析、设计和实现那些类似问题的通用解决方案的。试着这样做做,你以后的工作将会少遇到一些让你不明就里、一头雾水的问题,因为,很多东西你“知其然且知其所以然”!

    7、   在一种语言上编程,但别为其束缚了思想。“代码大全”中说:“深入一门语言编程,不要浮于表面”。深入一门语言开发还远远不足,任何编程语言的存在都有其自身的理由,所以也没有哪门语言是“包治百病”的“灵丹妙药”。编程语言对开发人员解决具体问题的思路和方式的影响与束缚的例子俯拾皆是。我的经验是:用面对对象工具开发某些关键模块时,为什么不可以借鉴CC51、汇编的模块化封装方式?用传统的桌面开发工具(目前主要有VC++Delphi)进行系统体统结构设计时,为什么不可以参考来自Java社区的IoCAOP设计思想,甚至借鉴像SpringHibernateJBoss等等优秀的开源框架?在进行类似于实时通信、数据采集等功能的设计、实现时,为什么不可以引用来自实时系统、嵌入式系统的优秀的体系框架与模式?为什么一切都必须以个人、团队在当然开发语言上的传统或者经验来解决问题???“他山之石、可以攻玉”。

    8、   养成总结与反思的习惯,并有意识地提炼日常工作成果,形成自己的个人源码库、解决某类问题的通用系统体系结构、甚至进化为框架。众所周知,对软件开发人员而言,有、无经验的一个显著区别是:无经验者完成任何任务时都从头开始,而有经验者往往通过重组自己的可复用模块、类库来解决问题(其实这个结论不应该被局限在软件开发领域、可以延伸到很多方面)。这并不是说,所有可复用的东西都必须自己实现,别人成熟的通过测试的成果也可以收集、整理、集成到自己的知识库中。但是,最好还是自己实现,这样没有知识产权、版权等问题,关键是自己实现后能真正掌握这个知识点,拥有这个技能。

    9、   理论与实践并重,内外双修工程师的内涵是:以工程师的眼光观察、分析事物和世界。一个合格的软件工程师,是真正理解了软件产品的本质及软件产品研发的思想精髓的人(个人观点、欢迎探讨)。掌握软件开发语言、应用语言工具解决工作中的具体问题、完成目标任务是软件工程师的主要工作,但从软件工程师这个角度来看,这只是外在的东西,并非重要的、本质的工作。学习、掌握软件产品开发理论知识、软件开发方法论,并在实践中理解、应用软件产品的分析、设计、实现思想来解决具体的软件产品研发问题,才是真正的软件工程师的工作。站在成熟理论与可靠方法论的高度思考、分析、解决问题,并在具体实践中验证和修正这些思想与方式,最终形成自己的理论体系和实用方法论。

    10心态有多开放,视野就有多开阔。不要抱着自己的技术和成果,等到它们都已经过时变成垃圾了,才拿出来丢人现眼。请及时发布自己的研究成果:开发的产品、有创意的设计或代码,公布出来让大家交流或者使用,你的成果才有进化和升华的机会。想想自己2000年间开发的那些Windows系统工具,56年之后的今天,还是那个样子,今天流行的好多Windows系统工具都比自己的晚,但进化得很好,且有那么多用户在使用。并且,不要保守自己的技术和思想,尽可能地与人交流与分享,或者传授给开发团队的成员。“与人交换苹果之后,每个人还是只有一个苹果;但交换思想之后,每个人都拥有两种思想”,道理大家都懂,但有多少人真正能做到呢?

    11、尽量参加开源项目的开发、或者与朋友共同研制一些自己的产品,千万不要因为没有钱赚而不做。网络早已不再只是“虚拟世界”,网上有很多的开源项目、合作开发项目、外包项目,这都是涉猎工作以外的知识的绝好机会,并且能够结识更广的人缘。不要因为工作是做ERP,就不去学习和了解嵌入式、实时、通信、网络等方面的技术,反过来也是一样。如果当他别人拿着合同找你合作,你却这也不会,那也不熟时,你将后悔莫及。

    12、书到用时方恨少,不要将自己的知识面仅仅局限于技术方面。诺贝尔经济学奖得主西蒙教授的研究结果表明: “对于一个有一定基础的人来说,他只要真正肯下功夫,在6个月内就可以掌握任何一门学问。”教育心理学界为感谢西蒙教授的研究成果,故命名为西蒙学习法。可见,掌握一门陌生的学问远远没有想想的那么高难、深奥。多方吸取、广泛涉猎。极力夯实自己的影响圈、尽量扩大自己的关注圈。财务、经济、税务、管理等等知识,有空花时间看看,韬光养晦、未雨绸缪。

    13、本文的总结与反思:

    A不要去做技术上的高手,除非你的目标如此。虽然本文是关于提高软件开发知识的建议,做技术的高手是我一向都不赞同的。你可以提高自己的专业知识,但能胜任工作即止。

    B提高软件知识和技术只是问题的表面,本质是要提高自己认识问题、分析问题、解决问题的思想高度。软件专业知识的很多方法和原理,可以很容易地延伸、应用到生活的其它方面。

    C在能胜任工作的基础上,立即去涉猎其它领域的专业知识,

  • 【转】2009年上半年软件评测师下午试卷

    2009-07-07 14:32:45

    试题一 (18分)

       阅读下列说明,回答问题1至问题4,将解答填入答题纸的对应栏内。
        [
    说明]
       
    软件测试的质量决定着被测产品的质量,是企业关注的重点。

        [
    问题1]3分)
       
    请简要叙述软件测试质量包括哪些管理要素。
        [
    问题2] (2分)
       
    请简要论述软件测试质量控制的主要方法。
        [
    问题3] 4分)
       
    企业衡量软件测试的质量经常采用两个指标:测试用例覆盖率和缺陷修复率,请简述这两个指标的概念。
        [
    问题4]   (9分)
       
    企业内部测试组在测试某办公自动化系统的过程中,使用60个测试用例进行测试,共发现了20个问题。
       
    开发组对软件修改后,向测试组提交问题修改报告及修改后的软件。问题修改报告中提出:所发现问题中的5个问题是用户所要求的,无需修改,其余15个问题已修改完成。 测试组使用针对上轮测试中发现的15个问题的36个测试用例进行了回归测试,确认问题已得到修改,因此测试组做出结论:当前版本可以进入配置管理库,进行后续集成工作
       
    请简要分析测试组的做法是否存在问题并简述理由。
       
    此办公自动化系统提交给用户之后,用户在使用过程中发现了5个问题,测试项目经理打算采用缺陷探测率来对测试人员进行绩效评估。请计算此测试项目的缺陷探测率。

       试题 二(20 分)

       阅读下列说明,回答问题1至问题5,将解答填入答题纸的对应栏内。
        [
    说明]
       
    某“网站稿件管理发布系统”是采用J2EE架构开发的B/S系统,Web服务器、应用服务器以及数据库服务器部署在一台物理设备上。

       
    系统实现的功能主要包括稿件管理和文档上传下载。稿件管理模块可以对稿件进行增加、查询、删除、修改、显示和批准等操作,批准后的稿件即可在网站上发布;文档上传下载模块可以将稿件直接以Word文档的格式进行上传下载。
       
    系统性能需求如下:
       
    1)主要功能操作在5秒钟内完成;
       
    2)支持50个在线用户;
       
    3)稿件管理的主要功能至少支持20个并发用户;
       
    4)在50个用户并发的高峰期,稿件管理的主要功能,处理能力至少要达到8trans/s
       
    5)系统可以连续稳定运行12小时。
        [
    问题1]3分)
       
    简要叙述“网站稿件管理发布系统”在生产环境下承受的主要负载类型。
        [
    问题2]3分)
       
    简要叙述进行“网站稿件管理发布系统”的性能测试中应测试的关键指标。
        [
    问题3]3分)
       
    请简述访问系统的“在线用户”和“并发用户”的区别。
        [
    问题4]3
       
    系统性能需求中要求“系统可以连续稳定运行12小时”,若系统连续运行12小时完成的总业务量为1000笔,系统能够提供的最大交易执行吞吐量为200/小时,试设计测试周期,并说明理由。
        [
    问题5]8分)
       
    下图为并发50个用户执行“稿件查询”操作的测试结果。
       
    1)请判断结果是否满足系统性能需求并说明理由。
       
    2)简要说明Transactions per SecondAverage Transaction Response Time之间的关系。



       试题 三(14分)

       阅读下列说明,回答问题1至问题3,将解答填入答题纸的对应栏内。
        [
    说明]
       
    场景法是黑盒测试中重要的测试用例设计方法。目前多数软件系统都是用事件触发来控制业务流程,事件触发时的情景便形成了场景,场景的不同触发顺序构成用例。场景法通过场景描述业务流程(包括基本流(基本流程)和备选流(分支流程)),设计用例遍历软件系统功能,验证其正确性。

       
    下面是对网上银行支付交易系统的基本流和备选流的描述:



       注:假定输入的银行卡号是正确的;不考虑备选流内循环情况。
        [
    问题1]6分)
       
    使用场景法设计测试用例,指出所涉及到的基本流和备选流。基本流用字母A表示,备选流用题干中描述对应编号表示。
        [
    问题2]5分)
       
    请针对问题1设计的测试用例,依次将银行卡号、初次输入密码、最终输入密码、卡内余额、银行卡可支付额度等信息填入下述测试用例表中。表中行代表各个测试用例,列代表测试用例的输入值,用V表示有效数据元素,I表示无效数据元素,n/a表示不适用,例如C01表示“成功支付” 用例。

     

        [问题3]3分 )
       
    在上述系统中,假设银行卡号只能输入0~9的数字,请参考下表,给出用边界值法检查卡号字符合法性的关键测试数据(字符或ASCII值)。

     

       试题 四(10分)

       阅读下列说明,回答问题1至问题3,将解答填入答题纸的对应栏内。
        [
    说明]
       
    逻辑覆盖是通过对程序逻辑结构的遍历实现程序的覆盖,是设计白盒测试用例的主要方法之一。以下代码由C语言书写,请按要求回答问题。

        void cal( int n )
        {
        int g, s, b, q;
        if ( ( n > 1000 ) && ( n < 2000 ) )
        {
        g = n % 10;
        s = n % 100 / 10;
        b = n / 100 % 10;
        q = n / 1000;
        if( ( q + g ) == ( s + b ) )
        {
        printf("%-5d", n);
        }
        }
        printf("\n");
        return;
        }
        [
    问题1]3 
       
    请找出程序中所有的逻辑判断语句。
        [
    问题2]4分)
       
    请分析并给出分别满足100DC(判定覆盖)和100CC(条件覆盖)时所需的逻辑条件。
        [
    问题3]3分)
       
    假设n的取值范围是0 < n < 3000,请用逻辑覆盖法为n的取值设计测试用例,使用例集满足基本路径覆盖标准。

       试题 五(13 分)

       阅读下列说明,回答问题1至问题3,将解答填入答题纸的对应栏内。
        [
    说明]
       
    某企业信息中心委托系统集成单位开发了企业网站,将应用服务器、Web服务器和数据库服务器都部署在信息中心机房,系统集成工作完成后,集成单位对网段、防火墙、入侵检测系统、防病毒系统等进行了全面的安全检查, 向信息中心提交了安全测评报告。

       
    信息中心主管认为该测评报告不够全面,要求尽可能提供系统的、多层次的、深入的安全测评报告。
        [
    问题1] 5分)
       
    请简述系统的安全防护体系包括的层次。
        [
    问题2]4分)
       
    对于服务器操作系统的安全,应当从哪些方面进行测评?
        [
    问题3]4分))
       
    安全日志是软件被动防范的措施,是重要的安全功能,软件的安全日志应当记录哪
       
    些信息?在安全测试中应当检查安全日志的哪些方面?
  • 【转】2009年上半年软件评测师上午试卷

    2009-07-07 14:28:13

    ● 计算机的用途不同,对其部件的性能指标要求也有所不同。以科学计算为主的计算机,对(1) 要求较高,而且应该重点考虑 (2) 。
       
    1A.外存储器的读写速度       B.主机的运算速度
        C. I
    O设备的速度                D.显示分辨率
       
    2A. CPU的主频和字长,以及内存容量
        B.硬盘读写速度和字长
        C. CPU
    的主频和显示分辨率
        D.
    硬盘读写速度和显示分辨率

    ●(3是指按内容访问的存储器。
       
    3A.虚拟存储器             B.相联存储器
        C.
    高速缓存(Cache           D.随机访问存储器

       ● 处理机主要由处理器、存储器和总线组成,总线包括 (4) 。
       
    4A.数据总线、地址总线、控制总线 B.并行总线、串行总线、逻辑总线
        C.
    单工总线、双工总线、外部总线       D.逻辑总线、物理总线、内部总线

    ● 下面关于加密的说法中,错误的是 (5) 。
        A. 
    数据加密的目的是保护数据的机密性
        B.
    加密过程是利用密钥和加密算法将明文转换成密文的过程
        C.
    选择密钥和加密算法的原则是保证密文不可能被破解
        D.
    加密技术通常分为非对称加密技术和对称密钥加密技术

       ● 下面关于防火墙功能的说法中,不正确的是(6) 。
       
    6A.防火墙能有效防范病毒的入侵
        B.
    防火墙能控制对特殊站点的访问
        C.
    防火墙能对进出的数据包进行过滤
        D.
    防火墙能对部分网络攻击行为进行检测和报警

       ● 下面关于漏洞扫描系统的叙述,错误的是 (7) 。
       
    7A.漏洞扫描系统是一种自动检测目标主机安全弱点的程序
        B.
    黑客利用漏洞扫描系统可以发现目标主机的安全漏洞
        C.
    漏洞扫描系统可以用于发现网络入侵者
        D.
    漏洞扫描系统的实现依赖于系统漏洞库的完善

       ● 软件工程每一个阶段结束前,应该着重对可维护性进行复审。在系统设计阶段的复审期间,应该从 (8)出发,评价软件的结构和过程。
       
    8A.指出可移植性问题以及可能影响软件维护的系统界面
        B.
    容易修改、模块化和功能独立的目的
        C.
    强调编码风格和内部说明文档
        D.
    测试

       ● 计算机感染特洛伊木马后的典型现象是 (9) 。
       
    9A.程序异常退出            B.有未知程序试图建立网络连接
        C.
    邮箱被垃圾邮件填满           D.Window系统黑屏

       ● 关于软件著作权产生的时间,下面表述正确的是 (10) 。
       
    10A.自作品首次公开发表时
        B.
    自作者有创作意图时
        C.
    自作品得到国家著作权行政管理部门认可时
        D.
    自作品完成创作之日

       ● 程序员甲与同事乙在乙家探讨甲近期编写的程序,甲表示对该程序极不满意,说要弃之重写,并将程序手稿扔到乙家垃圾筒。后来乙将甲这一程序稍加修改,并署乙名发表。以下说法正确的是(11) 。
       
    11A.乙的行为侵犯了甲的软件著作权
        B.
    乙的行为没有侵犯甲的软件著作权,因为甲已将程序手稿丢弃
        C.
    乙的行为没有侵犯甲的著作权,因为乙已将程序修改
        D.
    甲没有发表该程序并弃之,而乙将程序修改后发表,故乙应享有著作权

       ● 零件关系P(零件名,条形码,供应商,产地,价格)中的 (12) 属性可以作为该关系的主键。查询产于西安且名称为“P2”的零件,结果以零件名、供应商及零件价格分列表示,对应的SQL语句为:
        SELECT
    零件名,供应商,价格
        FROM P
        WHERE
    零件名='P2' AND 13;
       
    12A.零件名     B.条形码    C.产地     D.供应商

       
    13A.条形码=西安           B.条形码='西安'
        C.
    产地=西安           D.产地='西安'

       ● 软件风险一般包含 (14) 两个特性。
       
    14A.救火和危机管理       B.已知风险和未知风险
       C.
    不确定性和损失             D.员工和预算

       ● 在采用面向对象技术构建软件系统时,很多敏捷方法都建议的一种重要的设计活动是 (15),它是一种重新组织的技术,可以简化构件的设计而无需改变其功能或行为。
       
    15A.精化      B.设计类     C.重构      D.抽象

       ● 一个软件开发过程描述了“谁做” 、 “做什么” 、 “怎么做”和“什么时候做” ,RUP用(16) 来表述“谁做” 。
       
    16A.角色      B.活动      C.制品      D.工作

       ● 瀑布模型表达了一种系统的、顺序的软件开发方法。以下关于瀑布模型的叙述中,正确的是 (17)。
       
    17A.瀑布模型能够非常快速地开发大规模软件项目
        B.
    只有很大的开发团队才使用瀑布模型
        C.
    瀑布模型已不再适合于现今的软件开发环境
        D.
    瀑布模型适用于软件需求确定,开发过程能够采用线性方式完成的项目

       ● 一个软件系统的生存周期包含可行性分析和项目开发计划、需求分析、设计(概要设计和详细设计)、编码、测试和维护等活动,其中 (18) 是软件工程的技术核心,其任务是确定如何实现软件系统。
       
    18A.可行性分析和项目开发计划    B.需求分析
        C.
    设计                             D.编码

       ● 程序中常采用变量表示数据,变量具有名、地址、值、作用域、生存期等属性。关于变量的叙述, (19)是错误的。
       
    19A.根据作用域规则,在函数中定义的变量只能在函数中引用
        B.
    在函数中定义的变量,其生存期为整个程序执行期间
        C.
    在函数中定义的变量不能与其所在函数的形参同名
        D.
    在函数中定义的变量,其存储单元在内存的栈区

       ● 函数调用时,基本的参数传递方式有传值与传地址两种, (20) 。
       
    20A.在传值方式下,形参将值传给实参
        B.
    在传值方式下,实参不能是数组元素
        C.
    在传地址方式下,形参和实参间可以实现数据的双向传递
        D.
    在传地址方式下,实参可以是任意的变量和表达式

       ● 已知某高级语言源程序A经编译后得到机器C上的目标程序B,则 (21) 。
       
    21A.B进行反编译,一般不能还原出源程序A
        B.
    B进行反汇编,不能得到与源程序A等价的汇编程序代码

        C.
    B进行反编译,得到的是源程序A的变量声明和算法流程
        D.
    AB进行交叉编译,可以产生在机器C上运行的动态链接库

       ● 下面关于程序语言的叙述,错误的是 (22) 。
       
    22A.脚本语言属于动态语言,其程序结构可以在运行中改变
        B.
    脚本语言一般通过脚本引擎解释执行,不产生独立保存的目标程序
        C.   php
    JavaScript属于静态语言,其所有成分可在编译时确定
        D.  C
    语言属于静态语言,其所有成分可在编译时确定

       ● 在Windows  XP操作系统中,用户利用“磁盘管理”程序可以对磁盘进行初始化、创建卷,(23) 。通常将“C:\Windows\myprogram.exe”文件设置成只读和隐藏属性,以便控制用户对该文件的访问,这一级安全管理称之为(24) 安全管理。
       
    23A.但只能使用FAT文件系统格式化卷
        B.
    但只能使用FAT 32文件系统格式化卷
        C.
    但只能使用NTFS文件系统格式化卷
        D.
    可以选择使用FAT32NTFS文件系统格式化卷
       
    24A.文件级   B.目录级    C.用户级    D.系统级

        25) 属于系统软件,它直接执行高级语言源程序或与源程序等价的某种中间代码。
       
    25A.编译程序  B.预处理程序  C.汇编程序   D.解释程序

       ● 设系统中有R类资源m个,现有n个进程互斥使用。若每个进程对R资源的最大需求为w,那么当mnw取下表的值时,对于下表中的ae五种情况,(26) 两种情况可能会发生死锁。对于这两种情况,若将 (27),则不会发生死锁。

       26A. ab    B. bc     C. cd        D. ce
       
    27A. n1w1            B. m1w
    1
        C. m
    1w1                      D. m1w1

       ● 在软件开发过程中,常采用图形表示相关的信息, (28) 不用于表示软件模块的执行过程。
       
    28A.  N-S盒图    B.  E-R    C.  PAD    D.程序流程图

       ● 软件能力成熟度模型(CMM)将软件能力成熟度自低到高依次划分为5级。目前,达到CMM3级(已定义级)是许多组织努力的目标,该级的核心是(29) 。
       
    29A.建立基本的项目管理和实践来跟踪项目费用、进度和功能特性
        B.
    使用标准开发过程(或方法论)构建(或集成)系统
        C.
    管理层寻求更主动地应对系统的开发问题
        D.
    连续地监督和改进标准化的系统开发过程

       RUP在每个阶段都有主要目标,并在结束时产生一些制品。在 (30) 结束时产生“在适当的平台上集成的软件产品” 。
       
    30A.初期阶段    B.精化阶段   C.构建阶段   D.移交阶段
       
    ● 关于软件测试,(31)的叙述是正确的。
       
    ① 测试开始越早,越有利于发现软件缺陷
       
    ② 采用正确的测试用例设计方法,软件测试可以做到穷举测试
       
    ③ 测试覆盖度和测试用例数量成正比
       
    ④ 软件测试的时间越长越好
       
    31A.④    B.①    C.②、③    D.①、③

       ● 系统功能测试过程中,验证需求可以正确实现的测试用例称为(32) 。
       
    32A.业务流程测试用例    B.功能点测试用例
        C
    .通过测试用例              D.失败测试用例

       ● (33)不属于功能测试用例构成元素。
       
    33A.测试数据  B.测试步骤   C.预期结果   D.实测结果

       ● 针对电子政务类应用系统的功能测试,为设计有效的测试用例,应(34) 。
       
    34A.使业务需求的覆盖率达到100%
        B
    .利用等价类法模拟核心业务流程的正确执行

        C
    .对一个业务流程的测试用例设计一条验证数据
        D
    .经常使用边界值法验证界面输入值

       ● (35)测试用例设计方法既可以用于黑盒测试,也可以用于白盒测试
       
    35A.边界值法  B.基本路径法  C.正交试验设计法  D.逻辑覆盖法

       ● 对“功能测试的回归测试经常要多次重复”的正确理解是(36) 。
       
    36A.回归测试应该执行初测时所用的全部测试用例
        B
    .回归测试只要执行发现缺陷的那些测试用例即可
        C
    .通过多次的回归测试可以发现所有缺陷
        D
    .回归测试就是验收测试

       ● 功能测试执行过后一般可以确认系统的功能缺陷,缺陷的类型包括(37) 。
       
    ① 功能不满足隐性需求②功能实现不正确
       
    ④ 功能易用性不好③功能不符合相关的法律法规
       
    37A.①     B.①②③    C.②③④    D.②

     

    ● 以下关于软件测试的概念,正确的是(38) 。
       
    38A.软件测试的目的是想证实在一个给定的外部环境中软件的逻辑正确性,即保证软件以正确的方式来做这个事件
        B
    .软件质量保证的基本措施就是对软件进行确认测试
        C
    .软件测试的对象不仅仅是程序,文档、数据和规程都是软件测试的对象
        D
    单元测试可检验程序单元或部件的接口关系,应能发现并排除在模块连接中可能发生的问题

       ● 以下不正确的软件测试原则是(39) 。
       
    39A.软件测试可以发现软件潜在的缺陷
        B
    .所有的软件测试都可追溯到用户需求
        C
    .测试应尽早不断地执行
        D
    .程序员应避免测试自己的程序

       ● 在编码阶段对系统执行的测试类型主要包括单元测试和集成测试,(40)属于单元测试的内容。
       
    40A.接口数据测试      B.局部数据测试
        C
    .模块间时序测试          D.全局数据测试

       ● 以下关于软件测试概念的叙述,不正确的是(41) 。
       
    41A.软件失效指软件运行时产生了一种不希望或不可接受的内部行为
        B
    .软件功能实现超出了产品说明书的规定说明软件存在缺陷
        C
    .测试目的是为了发现软件缺陷与错误,也是对软件质量进行度量和评估
        D
    .在软件生命周期各个阶段都可能产生错误

       ● 以下关于软件测试分类定义的叙述,不正确的是(42) 。
       
    42A.软件测试可分为单元测试、集成测试、确认测试、系统测试、验收测试
        B
    .确认测试是在模块测试完成的基础上,将所有的程序模块进行组合并验证其是否满足用户需求的过程
        C
    .软件测试可分为白盒测试和黑盒测试
        D
    .系统测试是将被测软件作为整个基于计算机系统的一个元素,与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起进行测试的过程

       ● 正确的集成测试描述包括(43) 。
       
    ①集成测试也叫做组装测试,通常是在单元测试的基础上,将模块按照设计说明书要求进行组装和测试的过程。
       
    ②自顶向下的增殖方式是集成测试的一种组装方式,它能较早地验证主要的控制和判断点,对于输入输出模块、复杂算法模块中存在的错误能够较早地发现。
       
    ③集成测试的目的在于检查被测模块能否正确实现详细设计说明中的模块功能、性能、接口和设计约束等要求
       
    ④集成测试需要重点关注各个模块之间的相互影响,发现并排除全局数据结构问题
       
    43A.①②    B.②③       C.①④     D.②④

       ● 以下关于软件质量特性测试的叙述,正确的是(44) 。
       
    ①成熟性测试是检验软件系统故障,或违反指定接口的情况下维持规定的性能水平有关的测试工作
       
    ②功能性测试是检验适合性、准确性、互操作性、安全保密性、功能依从性的测试工作
       
    ③易学性测试是检查系统中用户为操作和运行控制所花努力有关的测试工作
       
    ④效率测试是指在规定条件下产品执行其功能时,对时间消耗及资源利用的测试工作
       
    44A.①②③④    B.①④   C.①③④    D.②④

       ● 对软件可靠性的理解,正确的是(45) 。
       
    ①软件可靠性是指在指定条件下使用时,软件产品维持规定的性能级别的能力
       
    ②软件可靠性的种种局限是由于随着时间的推移,软件需求和使用方式发生了变化
       
    ③软件可靠性包括成熟性、有效性、容错性、易恢复性等质量子特性
       
    ④针对软件可靠性中的容错性子特性应测试软件失效防护能力
       
    45A.①③      B.②③   C.①④       D.①②③④

       ● 软件可移植性应从如下(46)方面进行测试。
       
    46A.适应性、易安装性、共存性、易替换性
        B
    .适应性、易安装性、可伸缩性、易替换性
        C
    .适应性、易安装性、兼容性、易替换性
        D
    .适应性、成熟性、兼容性、易替换性

       ● 以下关于基于V&V原理的W模型的叙述中,(47)是错误的。
       
    47AW模型指出当需求被提交后,就需要确定高级别的测试用例来测试这些需求,当详细设计编写完成后,即可执行单元测试
        B
    .根据W模型要求,一旦有文档提供,就要及时确定测试条件、编写测试用例
        C
    .软件测试贯串于软件定义和开发的整个期间
        D
    .程序、需求规格说明、设计规格说明都是软件测试的对象

       ● 以下说法不正确的选项包括(48) 。
       
    ①软件测试不仅仅指测试的执行,还包括很多其他的活动
       
    ②软件测试是一个独立的流程,贯穿产品整个生命周期,与其他流程并发地进行
       
    ③应用H模型有利于资源调配,有助于跟踪测试投入的流向
       
    H模型指出,单元测试、集成测试、系统测试不存在严格的次序关系,各层次之
       
    间的测试存在反复触发、迭代和增量关系等
       
    48A.①③    B.②③   C.①④     D.无

       ● 以下软件质量保证的目标中,(49)是错误的。
       
    49A.通过监控软件开发过程来保证产品质量
        B
    .保证开发出来的软件和软件开发过程符合相应标准与规程,不存在软件缺陷
        C
    .保证软件产品、软件过程中存在的问题得到处理,必要时将问题反映给高级管理者
        D
    .确保项目组制定的计划、标准和规程适合项目组需要,同时满足评审和审计需要

       ● (50)不会影响测试质量。
       
    50A.用户需求频繁变化    B.测试流程不规范
        C
    .采用背靠背测试方式        D.测试周期被压缩

       ● (51)不属于测试人员编写的文档。
       
    51A.缺陷报告              B.测试环境配置文档
        C
    .缺陷修复报告                D.测试用例说明文档

       GB/T 16260-2006《软件工程 产品质量》规定的软件产品使用质量特性包括:
       
    52) 。
       
    52A.适应性、生产率、可靠性、满意度
        B
    .有效性、生产率、安全性、满意度
        C
    .有效性、可靠性、适应性、满意度
        D
    .适应性、适用性、效率、满意度

       GB 17859-1999《计算机信息系统安全保护等级划分准则》中将计算机安全保护划分为(53)个级别。
       
    53A3        B4    C5      D6

       ● 假设在程序控制流图中,有12条边,8个节点,则确保程序中每个可执行语句至少执行一次所必需的测试用例数目的上限是(54) 。
       
    54A12       B8    C6      D4

       ● 关于白盒测试的测试用例设计方法叙述,正确的是(55) 。
       
    55A.完成SC(语句判定)所需的测试用例数目一定多于完成DC(逻辑判定)
       
    所需的测试用例数目
        B
    .达到100CC(条件判定)要求就一定能够满足100SC的要求
        C
    .达到100CDC(条件判定组合覆盖)要求就一定能够满足100CC的要求
        D
    .任何情况下,都可以达到100%路径覆盖的要求

       ● 以下控制流图的圈复杂度V(g)为(56)。

     

       56A4        B6      C8        D10

       ● 针对程序段:IFA||B||CTHEN  W=W/X,对于(A,B,C)的取值,(57)测试用例能够满足MCDC(修正条件逻辑判定)的要求。
       
    57A(F,T,T) (T,F,T) (T,F,F) (T,T,F)
        B
    (T,F,F) (T,T,F) (F,T,T) (F,F,F)
        C
    (T,F,F) (T,T,F) (F,T,T) (F,F,T)
        D
    (T,F,F) (F,T,F) (F,F,T) (F,F,F)

       ● 针对下列程序段,需要(58)个测试用例可以满足分支覆盖的要求。
        int IsLeap(int year)
        {
        if ( year % 4 == 0 )
        {
        if ( ( year % 100 == 0 )
        {
        if ( year % 400 == 0 )
        leap = 1;
        else
        leap = 0;
        }
        else
        leap = 1;
        }
        else
        leap = 0;
        return leap;
        }
       
    58A3        B4      C6      D7

       ● 黑盒测试中,(59)是根据输出对输入的依赖关系设计测试用例。
       
    59A.基本路径法   B.等价类    C.因果图    D.功能图法

       Web应用系统负载压力测试中,(60)不是衡量业务执行效率的指标。
       
    60A.并发请求数         B.每秒点击率
        C
    .交易执行吞吐量           D.交易执行响应时间

       ● 软件测试的基本方法包括白盒测试和黑盒测试方法,以下关于二者之间关联的叙述,错误的是(61)。
       
    61A.黑盒测试与白盒测试是设计测试用例的两种基本方法
        B
    .在集成测试阶段是采用黑盒测试与白盒测试相结合的方法
        C
    .针对相同的系统模块,执行黑盒测试和白盒测试对代码的覆盖率都能够达到100
        D
    .应用系统负载压力测试一般采用黑盒测试方法

       ● 为验证某音乐会订票系统是否能够承受大量用户同时访问,测试工程师一般采用(62)测试工具。
       
    62A.故障诊断   B.代码    C.负载压力   D.网络仿真

       ● (63)不属于网站渗透测试的内容。
       
    63A.防火墙日志审查     B.防火墙远程探测与攻击
        C
    .跨站攻击                DSQL注入

       ● 能够主动采集信息,分析网络攻击行为和误操作的实时保护策略是指(64) 。
       
    64A.安全日志    B.入侵检测   C.隔离防护   D.防火墙

       ● 下列设备和技术中,(65)不属于数据安全策略范畴。
       
    65ASAN      B.异地容灾   C. 数字证书  D. 双机容错

  • 211/212>

    数据统计

    • 访问量: 17010
    • 日志数: 33
    • 图片数: 1
    • 建立时间: 2007-11-05
    • 更新时间: 2013-02-26

    RSS订阅

    Open Toolbar