在缘份的天空下，让我静静聆听你的声音！

发布新日志

  • 测试人员应具备的七种思维方式

    2009-01-14 21:31:43

    作为软件测试人员，应具备以下七种思维方式：逆向思维方式，组合思维方式，全局思维方式，两极思维方式，简单思维方式，比较思维方式，动起来，更精彩！
    1、逆向思维方式
    ☆逆向思维在测试中用的很多，比如将根据结果逆推条件，从而得出输入条件的等价类划分
    ☆其实逆向思维在调试当中用到的也比较多，当发现缺陷时，进一步定位问题的所在，往往就是逆流而上，进行分析
    ☆逆向思维是相对的，就是按照与常规思路相反的方向进行思考，测试人员往往能够运用它发现开发人员思维的漏洞
    2、组合思维方式
    ☆很多东西单一的思考都没有问题，当将相关的事物组合在一起却能发现很多问题；如多进程并发，让程序的复杂度上了一个台阶，也让程序的缺陷率随之而增长
    ☆按照是否排序组合可以分为：排列（有序）和组合（无序）；针对不同的应用，可以酌情考虑使用“排列”或者“组合”
    ☆为了充分利用组合思维而不致于让自己的思维混乱，要注意“分维”，将相关的因素划分到不同的维度上，然后再考虑其相关性
    3、全局思维方式
    ☆事物往往存在多面性，当我们掌握了越多的层面，我们对它的认识就越清楚，越有利于我们掌握其本质，全局思维方式就是让我们从多角度分析待测的系统；试着以不同角色去看系统，分析其是否能够满足需求
    ☆其实平常我们在软件开发过程中，进行的各种评审，就是借助全局思维的方式，让更多的人参与思考，脑力激荡，尽可能的实现全方位审查某个解决方案的正确性以及其他特性
    4、两极思维方式
    ☆边界值分析是两极思维方式的典范
    ☆为了看系统的稳定性，我们采用了    压力测试
    ☆两极思维方式，是在极端的情况下，看是否存在缺陷？
    ☆注意是两极，不是一极
    ☆测试人员做久了，往往容易走极端——职业病，不利于与人沟通
    5、简单思维方式
    ☆剥离一些非关键特征，追逐事物的本质，让事物简单的只剩下“根本”
    ☆针对事物本质（解决问题的本质）的测试，让我们不至于偏离方向
    6、比较思维方式
    ☆认识事物时，人们往往都是通过和头脑中的某些概念进行比较，找出相同、相异之处，或者归类，从而将其加入大脑中的知识体系，可能的话，再建立好的搜索方式，以便以后使用
    ☆应用模式是“比较思维”很常见的例子，现在模式很火，有设计模式、体系结构模式、    测试模式、等等，一些专家针对一些相关问题的共性找出来的解决方法，取完名字后，可以让大家方便的复用
    ☆让经验在这里发挥作用，测试中经验很重要，比较思维是使用经验的方式
    7、动起来，更精彩
    ☆关注程序的运行时状态
    ☆传统的基于结构的程序可以更多的在代码中反映将来程序的运行方式；而面向对象将代码和运行时显著分离
    ☆让我们在关注代码静态结构（如类结构）的同时，也要谨慎关注其动态（对象交互网）表现
    其实这些思维方式，大家都在有意识或者无意识的使用着，它们各自都有自己的妙处，将我们的思维发散，有意识的将他们用在问题的思考上，有时可以给我们一种“柳暗花明又一村”的感觉。
    最后想说，只是知道这些原则意义不是很大，如果真能让它们成为思考的血液，才能发挥它的真正价值。那真的需要很多的历练，其实成为一名出色的测试人员，远没有那么简单，需要简单，需要（不断的学习＋不断的经历＋不断的思考）。

    查看(552) 评论(0) 收藏 分享 管理

  • 软件测试中界面测试常见规则

    2009-01-14 21:30:32

    界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。目前界面的设计引起软件设计人员的重视的程度还远远不够，直到最近网页制作的兴起，才受到专家的青睐。而且设计良好的界面由于需要具有艺术美的天赋而遭拒绝。
    　　目前流行的界面风格有三种方式：多窗体、单窗体以及资源管理器风格，无论那种风格，以下规则是应该被重视的。
    　　易用性：
    　　按钮名称应该易懂，用词准确，屏弃没楞两可的字眼，要与同一界面上的其他按钮易于区分，能望文知意最好。理想的情况是用户不用查阅帮助就能知道该界面的功能并进行相关的正确操作。
    　　易用性细则：
    　　1):完成相同或相近功能的按钮用Frame框起来，常用按钮要支持快捷方式。
    　　2):完成同一功能或任务的元素放在集中位置，减少鼠标移动的距离。
    　　3):按功能将界面划分区域块，用Frame框括起来,并要有功能说明或标题。
    　　4):界面要支持键盘自动浏览按钮功能，即按Tab键、回車鍵的自动切换功能。
    　　5):界面上首先要输入的和重要信息的控件在Tab顺序中应当靠前,位置也应放在窗口上较醒目的位置。
    　　6):同一界面上的控件数最好不要超过10个，多于10个时可以考虑使用分页界面显示。
    　　7):分页界面要支持在页面间的快捷切换，常用组合快捷键Ctrl+Tab
    　　8):默认按钮要支持Enter及选操作，即按Enter后自动执行默认按钮对应操作。
    　　9):可写控件检测到非法输入后应给出说明并能自动获得焦点。
    　　10):Tab键的顺序与控件排列顺序要一直，目前流行总体从上到下，同时行间从左到右的方式。
    　　11):复选框和选项框按选择几率的高底而先后排列。
    　　12):复选框和选项框要有默认选项，并支持Tab选择。
    　　13):选项数相同时多用选项框而不用下拉列表框。
    　　14):界面空间较小时使用下拉框而不用选项框。
    　　15):选项数叫少时使用选项框，相反使用下拉列表框。
    　　16):专业性强的软件要使用相关的专业术语，通用性界面则提倡使用通用性词眼。
    　　规范性：
    　　通常界面设计都按Windows界面的规范来设计，可以说：界面遵循规范化的程度越高，则易用性相应的就越好。小型软件一般不提供工具厢。
    　　规范性细则：
    　　1):常用菜单要有命令快捷方式。
    　　2):完成相同或相近功能的菜单用横线隔开放在同一位置。
    　　3):菜单前的图标能直观的代表要完成的操作。
    　　4):菜单深度一般要求最多控制在三层以内。
    　　5):工具栏要求可以根据用户的要求自己选择定制。
    　　6):相同或相近功能的工具栏放在一起。
    　　7):工具栏中的每一个按钮要有及时提示信息。
    　　8):一条工具栏的长度最长不能超出屏幕宽度。
    　　9): 工具栏的图标能直观的代表要完成的操作。
    　　10):系统常用的工具栏设置默认放置位置。
    　　11):工具栏太多时可以考虑使用工具箱。
    　　12):工具箱要具有可增减性，由用户自己根据需求定制。
    　　13):工具箱的默认总宽度不要超过屏幕宽度的1/5。
    　　14): 状态条要能显示用户切实需要的信息，常用的有：目前的操作、系统状态、用户位置、用户信息、提示信息、错误信息等，如果某一操作需要的时间较长，还应该显示进度条和进程提示。
    　　15)：滚动条的长度要根据显示信息的长度或宽度能及时变换，以利于用户了解显示信息的位置和百分比。
    　　16)：状态条的高度以放置五好字为宜，滚动条的宽度比状态条的略窄。
    　　17)：菜单和工具条要有清楚的界限;菜单要求凸出显示，这样在移走工具条时仍有立体感。
    　　18)：菜单和状态条中通常使用5号字体。工具条一般比菜单要宽，但不要宽的太多，否则看起来很不协调。
    19): 右键快捷菜单采用与菜单相同的准则。
    　　帮助设施：
    　　系统应该提供详尽而可靠的帮助文档，在用户使用产生迷惑时可以自己寻求解决方法。
    　　帮助设施细则：
    　　1)：帮助文档中的性能介绍与说明要与系统性能配套一致。(我们的系统帮助文档都是系统的祖先时期的说明，让人困惑)。
    　　2)：打包新系统时，对作了修改的地方在帮助文档中要做相应的修改。
    　　3)：操作时要提供及时调用系统帮助的功能。常用F1。
    　　4)：在界面上调用帮助时应该能够及时定位到与该操作相对的帮助位置。也就是说帮助要有即时针对性。
    　　5)：最好提供目前流行的联机帮助格式或HTML帮助格式。
    　　6)：用户可以用关键词在帮助索引中搜索所要的帮助，当然也应该提供帮助主题词。
    　　7)：如果没有提供书面的帮助文档的话，最好有打印帮助的功能。
    　　8)：在帮助中应该提供我们的技术支持方式，一旦用户难以自己解决可以方便的寻求新的帮助方式。
    　　合理性：
    　　屏幕对角线相交的位置是用户直视的地方，正上方四分之一处为易吸引用户注意力的位置，在放置窗体时要注意利用这两个位置。
    　　合理性细则：
    　　1)：父窗体或主窗体的中心位置应该在对角线焦点附近。
    　　2)：子窗体位置应该在主窗体的左上角或正中。
    　　3)：多个子窗体弹出时应该依次向右下方偏移，以显示窗体出标题为宜。
    　　4)：重要的命令按钮与使用较频繁的按钮要放在界面上注目的位置。
    5)：错误使用容易引起界面退出或关闭的按钮不应该放在易点击的位置。横排开头或最后与竖排最后为易点位置。
    　　6)：与正在进行的操作无关的按钮应该加以屏蔽(Windows中用灰色显示，没法使用该按钮)。
    　　7)：对可能造成数据无法恢复的操作必须提供确认信息,给用户放弃选择的机会。
    　　8)：非法的输入或操作应有足够的提示说明。
    　　9): 对运行过程中出现问题而引起错误的地方要有提示，让用户明白错误出处，避免形成无限期的等待。
    　　10): 提示、警告、或错误说明应该清楚、明了、恰当。
    　　美观与协调性：
    　　界面应该大小适合美学观点，感觉协调舒适，能在有效的范围内吸引用户的注意力。
    　　美观与协调性细则：
    　　1): 长宽接近黄金点比例，切忌长宽比例失调、或宽度超过长度。
    　　2): 布局要合理,不宜过于密集，也不能过于空旷，合理的利用空间。
    　　3): 按钮大小基本相近，忌用太长的名称，免得占用过多的界面位置。
    　　4): 按钮的大小要与界面的大小和空间要协调。
    　　5): 避免空旷的界面上放置很大的按钮。
    　　6)：放置完控件后界面不应有很大的空缺位置。
    　　7): 字体的大小要与界面的大小比例协调, 通常使用的字体中宋体9-12较为美观，很少使用超过12号的字体。
    　　8): 前景与背景色搭配合理协调，反差不宜太大，最好少用深色，如大红、大绿等。常用色考虑使用Windows界面色调。
    　　9): 如果使用其他颜色，主色调要柔和，具有亲和力与磁力，坚决杜绝刺目的颜色。
    　　10): 大型系统常用的主色有"#E1E1E1"、"#EFEFEF"、"#C0C0C0"等。
    11): 界面风格要保持一致，字的大小、颜色、字体要相同，除非是需要艺术处理或有特殊要求的地方。
    　　12): 如果窗体支持最小化和最大化或放大时，窗体上的控件也要随着窗体而缩放；切忌只放大窗体而忽略控件的缩放。
    　　13)：对于含有按钮的界面一般不应该支持缩放，即右上角只有关闭功能。
    　　14): 通常父窗体支持缩放时，子窗体没有必要缩放。
    　　15)：如果能给用户提供自定义界面风格则更好，由用户自己选择颜色、字体等。
    　　菜单位置：
    　　菜单是界面上最重要的元素，菜单位置按照按功能来组织。
    　　菜单测试细则：
    　　1): 菜单通常采用“常用--主要--次要--工具--帮助”的位置排列，符合流行的Windows风格。
    　　2): 常用的有“文件”、“編輯”，“查看”等，幾乎每個系統都有這些選項，當然要根據不同的系統有所取捨。
    　　3): 下拉菜单要根据菜单选项的含义进行分组，並且按照一定的规则进行排列，用横线隔开。
    　　4): 一组菜单的使用有先后要求或有向导作用时，应该按先后次序排列。
    　　5): 没有顺序要求的菜单项按使用频率和重要性排列，常用的放在开头， 不常用的靠后放置；重要的放在开头，次要的放在后边。
    　　6): 如果菜单选项较多，应该采用加长菜单的长度而减少深度的原则排列。
    　　7): 菜单深度一般要求最多控制在三层以内。
    　　8): 对常用的菜单要有快捷命令方式，组合原则见8。
    　　9): 对与进行的操作无关的菜单要用屏蔽的方式加以处理，如果采用动态加载方式--即只有需要的菜单才显示--最好。
    　　10): 菜单前的图标不宜太大，与字高保持一直最好。
    　　11): 主菜单的宽度要接近，字数不应多于四个，每个菜单的字数能相同最好。
    　　12): 主菜单数目不应太多，最好为单排布置。
    　　13):菜单条是否显示在合适的语境中？
    　　14):应用程序的菜单条是否显示系统相关的特性（如时钟显示）？
    　　15):下拉式操作能正确工作吗？
    　　16):菜单、调色板和工具条是否工作正确？
    　　17):是否适当地列出了所有的菜单功能和下拉式子功能？
    　　18):是否可能通过鼠标访问所有的菜单功能？
    　　19):相同功能按钮的图标和文字是否一致？
    　　20):是否能够用其他的文本命令激活每个菜单功能？
    　　21):菜单功能是否随当前的窗口操作加亮或变灰？
    　　22):菜单功能是否正确执行？
    　　23):菜单功能的名字是否具有自解释性？
    　　24):菜单项是否有帮助，是否语境相关？
    　　25):在整个交互式语境中，是否可以识别鼠标操作？
    　　26):如果要求多次点击鼠标，是否能够在语境正确识别？
    　　27):如果鼠标有多个按钮，是否能够在语境中正确识别？
    　　28):光标、处理指示器和识别指针是否随操作恰当地改变？
    　　独特性：
    　　如果一味的遵循业界的界面标准，则会丧失自己的个性.在框架符合以上规范的情况下，设计具有自己独特风格的界面尤为重要。尤其在商业软件流通中有着很好的迁移默化的广告效用。
    测试细则：
    　　1):　安装界面上应有单位介绍或产品介绍，并有自己的图标。
    　　2):　主界面，最好是大多数界面上要有公司图标。
    　　3):　登录界面上要有本产品的标志，同时包含公司图标。
    　　4):　帮助菜单的“关于”中应有版权和产品信息。
    　　5):　公司的系列产品要保持一直的界面风格，如背景色、字体、菜单排列方式、图标、安装过程、按钮用语等应该大体一致。
    　　快捷方式的组合
    　　在菜单及按钮中使用快捷键可以让喜欢使用键盘的用户操作得更快一些在西文Windows及其应用软件中快捷键的使用大多是一致的。
    　　菜单中：
    　　1):面向事务的组合有: Ctrl-D 删除 ；Ctrl-F 寻找 ；Ctrl -H替换；Ctrl-I 插入 ；Ctrl-N 新记录 ；Ctrl-S 保存 Ctrl-O 打开。
    　　2)：列表: Ctrl-R ，Ctrl-G定位；Ctrl-Tab下一分页窗口或反序浏览同一页面控件；。
    　　3):编辑:Ctrl-A全选；Ctrl-C 拷贝；Ctrl-V 粘贴；Ctrl-X 剪切；Ctrl-Z撤消操作；Ctrl-Y恢复操作。
    　　4)文件操作:Ctrl-P 打印；Ctrl-W 关闭。
    　　5):系统菜单Alt-A文件；Alt-E编辑；Alt-T工具；Alt－W窗口；Alt－H帮助。
    　　6):MS Windows保留键:Ctrl-Esc 任务列表 ；Ctrl-F4 关闭窗口； Alt-F4 结束应用；Alt-Tab 下一应用 ；Enter 缺省按钮/确认操作 ；Esc 取消按钮/取消操作；Shift-F1 上下文相关帮助。按钮中：可以根据系统需要而调节，以下只是常用的组合。Alt-Y确定(是)；Alt-C取消；Alt-N 否；Alt-D删除；Alt-Q退出；Alt-A添加；Alt-E编辑；Alt-B浏览；Alt-R读；Alt-W写。
    　　这些快捷键也可以作为开发中文应用软件的标准,但亦可使用汉语拼音的开头字母。
    　　安全性考虑：
    　　在界面上通过下列方式来控制出错几率，会大大减少系统因用户人为的错误引起的破坏。开发者应当尽量周全地考虑到各种可能发生的问题,使出错的可能降至最小。如应用出现保护性错误而退出系统,这种错误最容易使用户对软件失去信心。因为这意味着用户要中断思路,并费时费力地重新登录,而且已进行的操作也会因没有存盘而全部丢失。
    　　安全性细则：
    　　1)：最重要的是排除可能会使应用非正常中止的错误。
    　　2)：应当注意尽可能避免用户无意录入无效的数据。
    　　3)：采用相关控件限制用户输入值的种类。
    　　4)：当用户作出选择的可能性只有两个时,可以采用单选框。
    　　5)：当选择的可能再多一些时,可以采用复选框,每一种选择都是有效的,用户不可能输入任何一种无效的选择。
    　　6)：当选项特别多时，可以采用列表框，下拉式列表框。
    　　7)：在一个应用系统中,开发者应当避免用户作出未经授权或没有意义的操作。
    　　8)：对可能引起致命错误或系统出错的输入字符或动作要加限制或屏蔽。
    　　9):对可能发生严重后果的操作要有补救措施。通过补救措施用户可以回到原来的正确状态。
    　　10):对一些特殊符号的输入、与系统使用的符号相冲突的字符等进行判断并阻止用户输入该字符。
    　　11)：对错误操作最好支持可逆性处理，如取消系列操作。
    　　12):在输入有效性字符之前应该阻止用户进行只有输入之后才可进行的操作。
    　　13):对可能造成等待时间较长的操作应该提供取消功能。
    　　14)：特殊字符常有；;’”><,｀‘：“［”｛、|｝］+=)-(_*&&^%$#@!,.。?/还有空格。
    　　15)：与系统采用的保留字符冲突的要加以限制。
    　　16)：在读入用户所输入的信息时，根据需要选择是否去掉前后空格。
    　　17)：有些读入数据库的字段不支持中间有空格，但用户切实需要输入中间空格，这时要在程序中加以处理。
    　　多窗口的应用与系统资源：
    　　设计良好的软件不仅要有完备的功能，而且要尽可能的占用最底限度的资源。
    　　1)：在多窗口系统中，有些界面要求必须保持在最顶层，避免用户在打开多个窗口时，不停的切换甚至最小化其他窗口来显示该窗口。
    　　2)：在主界面载入完毕后自动卸出内存，让出所占用的WINDOWS系统资源。
    　　3)：关闭所有窗体，系统退出后要释放所占的所有系统资源 ，除非是需要后台运行的系统。
    　　4)：尽量防止对系统的独占使用。
    　　5)：窗口能否基于相关的输入或菜单命令适当地打开？
    　　6)：窗口能否改变大小、移动和滚动？
    　　7)：窗口中的数据内容能否使用鼠标、功能键、方向箭头和键盘访问？
    　　8)：当被覆盖并重调用后，窗口能否正确地再生？
    　　9)：需要时能否使用所有窗口相关的功能？
    　　10)：所有窗口相关的功能是可操作的吗？
    　　11)：是否有相关的下拉式菜单、工具条、滚动条、对话框、按钮、图标和其他控制可为窗口可用，并适当地显示？
    12)：显示多个窗口时，窗口的名称是否被适当地表示？
    　　13)：活动窗口是否被适当地加亮？
    　　14)：如果使用多任务，是否所有的窗口被实时更新？
    　　15)：多次或不正确按鼠标是否会导致无法预料的副作用？
    　　16)：窗口的声音和颜色提示和窗口的操作顺序是否符合需求？
    　　17)：窗口是否正确地关闭？

    查看(301) 评论(0) 收藏 分享 管理

  • 界面测试总结

    2009-01-14 21:29:41

    　　界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。目前界面的设计引起软件设计人员的重视的程度还远远不够，直到最近网页制作的兴起，才受到专家的青睐。而且设计良好的界面由于需要具有艺术美的天赋而遭拒绝。
    　　目前流行的界面风格有三种方式：多窗体、单窗体以及资源管理器风格，无论那种风格，以下规则是应该被重视的。
    　　易用性：
    　　按钮名称应该易懂，用词准确，屏弃没楞两可的字眼，要与同一界面上的其他按钮易于区分，能望文知意最好。理想的情况是用户不用查阅帮助就能知道该界面的功能并进行相关的正确操作。
    　　易用性细则：
    　　1):完成相同或相近功能的按钮用Frame框起来，常用按钮要支持快捷方式。
    　　2):完成同一功能或任务的元素放在集中位置，减少鼠标移动的距离。
    　　3):按功能将界面划分区域块，用Frame框括起来,并要有功能说明或标题。
    　　4):界面要支持键盘自动浏览按钮功能，即按Tab键、回車鍵的自动切换功能。
    　　5):界面上首先要输入的和重要信息的控件在Tab顺序中应当靠前,位置也应放在窗口上较醒目的位置。
    　　6):同一界面上的控件数最好不要超过10个，多于10个时可以考虑使用分页界面显示。
    　　7):分页界面要支持在页面间的快捷切换，常用组合快捷键Ctrl+Tab
    　　8):默认按钮要支持Enter及选操作，即按Enter后自动执行默认按钮对应操作。
    　　9):可写控件检测到非法输入后应给出说明并能自动获得焦点。
    　　10):Tab键的顺序与控件排列顺序要一直，目前流行总体从上到下，同时行间从左到右的方式。
    　　11):复选框和选项框按选择几率的高底而先后排列。
    　　12):复选框和选项框要有默认选项，并支持Tab选择。
    　　13):选项数相同时多用选项框而不用下拉列表框。
    　　14):界面空间较小时使用下拉框而不用选项框。
    　　15):选项数叫少时使用选项框，相反使用下拉列表框。
    　　16):专业性强的软件要使用相关的专业术语，通用性界面则提倡使用通用性词眼。
    　　规范性：
    　　通常界面设计都按Windows界面的规范来设计，可以说：界面遵循规范化的程度越高，则易用性相应的就越好。小型软件一般不提供工具厢。
    　　规范性细则：
    　　1):常用菜单要有命令快捷方式。
    　　2):完成相同或相近功能的菜单用横线隔开放在同一位置。
    　　3):菜单前的图标能直观的代表要完成的操作。
    　　4):菜单深度一般要求最多控制在三层以内。
    　　5):工具栏要求可以根据用户的要求自己选择定制。
    　　6):相同或相近功能的工具栏放在一起。
    　　7):工具栏中的每一个按钮要有及时提示信息。
    　　8):一条工具栏的长度最长不能超出屏幕宽度。
    　　9): 工具栏的图标能直观的代表要完成的操作。
    　　10):系统常用的工具栏设置默认放置位置。
    　　11):工具栏太多时可以考虑使用工具箱。
    　　12):工具箱要具有可增减性，由用户自己根据需求定制。
    　　13):工具箱的默认总宽度不要超过屏幕宽度的1/5。
    　　14): 状态条要能显示用户切实需要的信息，常用的有：目前的操作、系统状态、用户位置、用户信息、提示信息、错误信息等，如果某一操作需要的时间较长，还应该显示进度条和进程提示。
    　　15)：滚动条的长度要根据显示信息的长度或宽度能及时变换，以利于用户了解显示信息的位置和百分比。
    　　16)：状态条的高度以放置五好字为宜，滚动条的宽度比状态条的略窄。
    　　17)：菜单和工具条要有清楚的界限;菜单要求凸出显示，这样在移走工具条时仍有立体感。
    　　18)：菜单和状态条中通常使用5号字体。工具条一般比菜单要宽，但不要宽的太多，否则看起来很不协调。
    　　19): 右键快捷菜单采用与菜单相同的准则。
    系统应该提供详尽而可靠的帮助文档，在用户使用产生迷惑时可以自己寻求解决方法。
    　　帮助设施细则：
    　　1)：帮助文档中的性能介绍与说明要与系统性能配套一致。(我们的系统帮助文档都是系统的祖先时期的说明，让人困惑)。
    　　2)：打包新系统时，对作了修改的地方在帮助文档中要做相应的修改。
    　　3)：操作时要提供及时调用系统帮助的功能。常用F1。
    　　4)：在界面上调用帮助时应该能够及时定位到与该操作相对的帮助位置。也就是说帮助要有即时针对性。
    　　5)：最好提供目前流行的联机帮助格式或HTML帮助格式。
    　　6)：用户可以用关键词在帮助索引中搜索所要的帮助，当然也应该提供帮助主题词。
    　　7)：如果没有提供书面的帮助文档的话，最好有打印帮助的功能。
    　　8)：在帮助中应该提供我们的技术支持方式，一旦用户难以自己解决可以方便的寻求新的帮助方式。
    　　合理性：
    　　屏幕对角线相交的位置是用户直视的地方，正上方四分之一处为易吸引用户注意力的位置，在放置窗体时要注意利用这两个位置。
    　　合理性细则：
    　　1)：父窗体或主窗体的中心位置应该在对角线焦点附近。
    　　2)：子窗体位置应该在主窗体的左上角或正中。
    　　3)：多个子窗体弹出时应该依次向右下方偏移，以显示窗体出标题为宜。
    　　4)：重要的命令按钮与使用较频繁的按钮要放在界面上注目的位置。
    　　5)：错误使用容易引起界面退出或关闭的按钮不应该放在易点击的位置。横排开头或最后与竖排最后为易点位置。
    　　6)：与正在进行的操作无关的按钮应该加以屏蔽(Windows中用灰色显示，没法使用该按钮)。
    　　7)：对可能造成数据无法恢复的操作必须提供确认信息,给用户放弃选择的机会。
    　　8)：非法的输入或操作应有足够的提示说明。
    　　9): 对运行过程中出现问题而引起错误的地方要有提示，让用户明白错误出处，避免形成无限期的等待。
    　　10): 提示、警告、或错误说明应该清楚、明了、恰当。
    　　美观与协调性：
    　　界面应该大小适合美学观点，感觉协调舒适，能在有效的范围内吸引用户的注意力。
    　　美观与协调性细则：
    　　1): 长宽接近黄金点比例，切忌长宽比例失调、或宽度超过长度。
    　　2): 布局要合理,不宜过于密集，也不能过于空旷，合理的利用空间。
    　　3): 按钮大小基本相近，忌用太长的名称，免得占用过多的界面位置。
    　　4): 按钮的大小要与界面的大小和空间要协调。
    　　5): 避免空旷的界面上放置很大的按钮。
    　　6)：放置完控件后界面不应有很大的空缺位置。
    　　7): 字体的大小要与界面的大小比例协调, 通常使用的字体中宋体9-12较为美观，很少使用超过12号的字体。
    　　8): 前景与背景色搭配合理协调，反差不宜太大，最好少用深色，如大红、大绿等。常用色考虑使用Windows界面色调。
    　　9): 如果使用其他颜色，主色调要柔和，具有亲和力与磁力，坚决杜绝刺目的颜色。
    　　10): 大型系统常用的主色有"#E1E1E1"、"#EFEFEF"、"#C0C0C0"等。
    　　11): 界面风格要保持一致，字的大小、颜色、字体要相同，除非是需要艺术处理或有特殊要求的地方。
    　　12): 如果窗体支持最小化和最大化或放大时，窗体上的控件也要随着窗体而缩放;切忌只放大窗体而忽略控件的缩放。
    　　13)：对于含有按钮的界面一般不应该支持缩放，即右上角只有关闭功能。
    　　14): 通常父窗体支持缩放时，子窗体没有必要缩放。
    　　15)：如果能给用户提供自定义界面风格则更好，由用户自己选择颜色、字体等。
    菜单位置：
    　　菜单是界面上最重要的元素，菜单位置按照按功能来组织。
    　　菜单测试细则：
    　　1): 菜单通常采用“常用--主要--次要--工具--帮助”的位置排列，符合流行的Windows风格。
    　　2): 常用的有“文件”、“編輯”，“查看”等，幾乎每個系統都有這些選項，當然要根據不同的系統有所取捨。
    　　3): 下拉菜单要根据菜单选项的含义进行分组，並且按照一定的规则进行排列，用横线隔开。
    　　4): 一组菜单的使用有先后要求或有向导作用时，应该按先后次序排列。
    　　5): 没有顺序要求的菜单项按使用频率和重要性排列，常用的放在开头， 不常用的靠后放置;重要的放在开头，次要的放在后边。
    　　6): 如果菜单选项较多，应该采用加长菜单的长度而减少深度的原则排列。
    　　7): 菜单深度一般要求最多控制在三层以内。
    　　8): 对常用的菜单要有快捷命令方式，组合原则见8。
    　　9): 对与进行的操作无关的菜单要用屏蔽的方式加以处理，如果采用动态加载方式--即只有需要的菜单才显示--最好。
    　　10): 菜单前的图标不宜太大，与字高保持一直最好。
    　　11): 主菜单的宽度要接近，字数不应多于四个，每个菜单的字数能相同最好。
    　　12): 主菜单数目不应太多，最好为单排布置。
    　　13):菜单条是否显示在合适的语境中?
    　　14):应用程序的菜单条是否显示系统相关的特性(如时钟显示)?
    　　15):下拉式操作能正确工作吗?
    　　16):菜单、调色板和工具条是否工作正确?
    　　17):是否适当地列出了所有的菜单功能和下拉式子功能?
    　　18):是否可能通过鼠标访问所有的菜单功能?
    　　19):相同功能按钮的图标和文字是否一致?
    　　20):是否能够用其他的文本命令激活每个菜单功能?
    　　21):菜单功能是否随当前的窗口操作加亮或变灰?
    　　22):菜单功能是否正确执行?
    　　23):菜单功能的名字是否具有自解释性?
    　　24):菜单项是否有帮助，是否语境相关?
    　　25):在整个交互式语境中，是否可以识别鼠标操作?
    　　26):如果要求多次点击鼠标，是否能够在语境正确识别?
    　　27):如果鼠标有多个按钮，是否能够在语境中正确识别?
    　　28):光标、处理指示器和识别指针是否随操作恰当地改变?
    　　独特性：
    　　如果一味的遵循业界的界面标准，则会丧失自己的个性.在框架符合以上规范的情况下，设计具有自己独特风格的界面尤为重要。尤其在商业软件流通中有着很好的迁移默化的广告效用。
    　　测试细则：
    　　1):　安装界面上应有单位介绍或产品介绍，并有自己的图标。
    　　2):　主界面，最好是大多数界面上要有公司图标。
    　　3):　登录界面上要有本产品的标志，同时包含公司图标。
    　　4):　帮助菜单的“关于”中应有版权和产品信息。
    　　5):　公司的系列产品要保持一直的界面风格，如背景色、字体、菜单排列方式、图标、安装过程、按钮用语等应该大体一致。
    快捷方式的组合
    　　在菜单及按钮中使用快捷键可以让喜欢使用键盘的用户操作得更快一些在西文Windows及其应用软件中快捷键的使用大多是一致的。
    　　菜单中：
    　　1):面向事务的组合有: Ctrl-D 删除 ;Ctrl-F 寻找 ;Ctrl -H替换;Ctrl-I 插入 ;Ctrl-N 新记录 ;Ctrl-S 保存 Ctrl-O 打开。
    　　2)：列表: Ctrl-R ，Ctrl-G定位;Ctrl-Tab下一分页窗口或反序浏览同一页面控件。
    　　3):编辑:Ctrl-A全选;Ctrl-C 拷贝;Ctrl-V 粘贴;Ctrl-X 剪切;Ctrl-Z撤消操作;Ctrl-Y恢复操作。
    　　4)文件操作:Ctrl-P 打印;Ctrl-W 关闭。
    　　5):系统菜单Alt-A文件;Alt-E编辑;Alt-T工具;Alt-W窗口;Alt-H帮助。
    　　6):MS Windows保留键:Ctrl-Esc 任务列表 ;Ctrl-F4 关闭窗口; Alt-F4 结束应用;Alt-Tab 下一应用 ;Enter 缺省按钮/确认操作 ;Esc 取消按钮/取消操作;Shift-F1 上下文相关帮助。按钮中：可以根据系统需要而调节，以下只是常用的组合。Alt-Y确定(是);Alt-C取消;Alt-N 否;Alt-D删除;Alt-Q退出;Alt-A添加;Alt-E编辑;Alt-B浏览;Alt-R读;Alt-W写。
    　　这些快捷键也可以作为开发中文应用软件的标准,但亦可使用汉语拼音的开头字母。
    　　安全性考虑：
    　　在界面上通过下列方式来控制出错几率，会大大减少系统因用户人为的错误引起的破坏。开发者应当尽量周全地考虑到各种可能发生的问题,使出错的可能降至最小。如应用出现保护性错误而退出系统,这种错误最容易使用户对软件失去信心。因为这意味着用户要中断思路,并费时费力地重新登录,而且已进行的操作也会因没有存盘而全部丢失。
    　　安全性细则：
    　　1)：最重要的是排除可能会使应用非正常中止的错误。
    　　2)：应当注意尽可能避免用户无意录入无效的数据。
    　　3)：采用相关控件限制用户输入值的种类。
    　　4)：当用户作出选择的可能性只有两个时,可以采用单选框。
    　　5)：当选择的可能再多一些时,可以采用复选框,每一种选择都是有效的,用户不可能输入任何一种无效的选择。
    　　6)：当选项特别多时，可以采用列表框，下拉式列表框。
    　　7)：在一个应用系统中,开发者应当避免用户作出未经授权或没有意义的操作。
    　　8)：对可能引起致命错误或系统出错的输入字符或动作要加限制或屏蔽。
    　　9):对可能发生严重后果的操作要有补救措施。通过补救措施用户可以回到原来的正确状态。
    　　10):对一些特殊符号的输入、与系统使用的符号相冲突的字符等进行判断并阻止用户输入该字符。
    　　11)：对错误操作最好支持可逆性处理，如取消系列操作。
    　　12):在输入有效性字符之前应该阻止用户进行只有输入之后才可进行的操作。
    　　13):对可能造成等待时间较长的操作应该提供取消功能。
    　　14)：特殊字符常有;;’”><,`‘：“[”{、\|｝]+=)-(_*&&^%$#@!,.。?/还有空格。
    　　15)：与系统采用的保留字符冲突的要加以限制。
    　　16)：在读入用户所输入的信息时，根据需要选择是否去掉前后空格。
    　　17)：有些读入数据库的字段不支持中间有空格，但用户切实需要输入中间空格，这时要在程序中加以处理。
    　　多窗口的应用与系统资源：
    　　设计良好的软件不仅要有完备的功能，而且要尽可能的占用最底限度的资源。
    　　1)：在多窗口系统中，有些界面要求必须保持在最顶层，避免用户在打开多个窗口时，不停的切换甚至最小化其他窗口来显示该窗口。
    　　2)：在主界面载入完毕后自动卸出内存，让出所占用的WINDOWS系统资源。
    　　3)：关闭所有窗体，系统退出后要释放所占的所有系统资源 ，除非是需要后台运行的系统。
    　　4)：尽量防止对系统的独占使用。
    　　5)：窗口能否基于相关的输入或菜单命令适当地打开?
    　　6)：窗口能否改变大小、移动和滚动?
    　　7)：窗口中的数据内容能否使用鼠标、功能键、方向箭头和键盘访问?
    　　8)：当被覆盖并重调用后，窗口能否正确地再生?
    　　9)：需要时能否使用所有窗口相关的功能?
    　　10)：所有窗口相关的功能是可操作的吗?
    　　11)：是否有相关的下拉式菜单、工具条、滚动条、对话框、按钮、图标和其他控制可为窗口可用，并适当地显示?
    　　12)：显示多个窗口时，窗口的名称是否被适当地表示?
    　　13)：活动窗口是否被适当地加亮?
    　　14)：如果使用多任务，是否所有的窗口被实时更新?
    　　15)：多次或不正确按鼠标是否会导致无法预料的副作用?
    　　16)：窗口的声音和颜色提示和窗口的操作顺序是否符合需求?
    　　17)：窗口是否正确地关闭?

    查看(315) 评论(0) 收藏 分享 管理

  • 常规测试方法

    2009-01-14 21:28:42

    常规测试方法

    一. 功能测试
    1. 安装测试：
    1) 安装过程中对于缺省安装目录及任意指定的安装目录，是否都能正确安装；
    2) 若是选择安装，查看能否实现其相应的功能；
    3) 在所有能中途退出安装的位置退出安装程序后，验证此程序并未安装成功（没有程序组及程序项产生）；
    4) 软件安装后，对其它已经安装的软件是否有影响；
    5) 裸机安装后，各功能点是否可用；
    6) 安装前，安装程序是否判断可用磁盘空间大小，如果不能满足安装空间要求，安装程序能否继续；
    7) 安装过程中查看 版权声明、版本信息、公司名称、LOGO等是否符合标准；
    8) 安装过程中界面显示与提示语言是否准确、友好；
    9) 重复安装时系统是否有提示、是否可以覆盖安装、是否可以升级安装、是否允许多版本共存；
    10) 是否有注册码或硬件加密狗，在没有它们（或错误）存在的情况下能否顺利安装。
    2．配置测试
    1) 是否可以按照用户手册的说明，运行于多种操作系统（Windows 各版本 、Unix 、Linux 等）；
    2) 按系统最低要求进行软件的安装配置，查看能否正常实现各种功能；
    3) 数据源等信息配置不正确时能否给出提示信息；
    4) 是否可以按照用户手册的说明，支持多种数据库。
    3. 卸载测试
    1) 卸载后注册表中的注册信息及相关的程序安装目录是否能完全删除掉；
    2) 卸载过程中完全删除共享文件后，看其它程序能否正常运行；
    3) 卸载后，是否对其它已经安装的软件有影响；
    4) 系统卸载后用户建立文档是否保留；
    5) 软件卸载画面上的软件名称及版本信息是否正确；
    6) 在所有能中途退出卸载的位置是否能正确退出；
    7) 卸载过程中界面显示与提示语言是否准确、友好；
    8) 卸载后安装此系统能否打开原来保存的文件，并一切运行正常；
    9) 卸载程序如果要求重新启动机器，在重启动之间是否给用户提示以保存现有的己运行的程序的资料；
    10) 是否可以选择组件进行卸载；
    11) 卸载过程中，对意外情况的处理（掉电等）。
    12) 在卸载过程中，是否有终止或者结束按钮。
    4. 运行与关闭测试
    1) 运行时是否与其它应用程序有冲突(内存冲突)；
    2) 是否可以同时运行多个程序；
    3) 任务栏有无程序运行提示；
    4) 若有未保存的数据，关闭系统时是否有提示；
    5) 后台服务程序在点击关闭按钮时是否有确认提示；
    6) 运行时是否过份占用系统资源、退出时能否完成释放占用的系统资源。
    5. 服务程序的测试：
    1) 系统是否限制服务器程序启动的数量,如不限制,同一范围内启动多个服务是否对系统有影响；
    2) 服务程序能否长时间正常运行；
    3) 外界异常后，服务程序的自动恢复能力（服务器掉电、网络中断后恢复、数据库异常后恢复…）；
    4) 在点击关闭按钮时是否有确认提示；
    5) 应用程序与其他程序是否兼容（能否避免内存冲突）。
    6. 系统管理（参数设置）
    1) 参数设置后，能否正确的进行应用；
    2) 设置错误参数，系统的容错能力；
    3) 修改参数，对与之相关模块的影响；
    4) 系统是否有默认的参数，A 有：默认的参数是否起到作用 ；B 没有：不设置，系统能否运行或者给出提示。
    7. 用户、权限管理
    1) 赋予一个人员相应的权限后，在界面上看此人员是否具有此权限，并以此人员身份登陆，验证权限设置是否正确（能否超出所给予的权限）；
    2) 删除或修改已经登陆系统并正在进行操作的人员的权限，程序能否正确处理；
    3) 重新注册系统变更登陆身份后再登录，看程序是否能正确执行，具有权限是否正确；
    4) 在有工作组或角色管理的情况下，删除包含用户的工作组或角色，程序能否正确处理；
    5) 不同权限用户登录同一个系统，权限范围是否正确；
    6) 覆盖系统所有权限设定；
    7) 能否添加信息为空的用户(其中包括空用户名及空口令、空用户名非空口令、非空用户名及空口令)；
    8) 能否添加长用户名及长口令，如果允许，新用户能否正确登录；
    9) 系统是否允许删除系统管理员这一特殊用户或修改系统管理员口令，删除或修改后系统的实际情况；
    10) 登录用户能否修改自己的权限；
    11) 添加用户（有标识或编号）:标识相同，用户名不同；标识相同，用户名相同；标识不同，用户名相同；标识不同，用户名不同；
    12) 登录用户能否修改本人（或其他人）的信息，删除本人（或其他人）；
    13) 修改用户的信息（包括权限，口令，基本信息等），对其他模块的影响；
    14) 修改用户信息：修改后的用户信息和已经存在的用户信息相同；修改后的用户信息和已经存在的用户信息不同；
    15) 不给用户授权，是否允许登录；
    15) 改某些设置时，是否会影响具有上级权限及相同权限人员的设置；
    16) 系统管理员修改了某些数据，以其他人员身份登录时数据是否改变；
    17) 用户能否同时属于多个组，各个组的权限能否交叉；
    18) 删除后重新添加的用户是否具有以前的权限；更改用户各项属性（包括权限）看对权限是否有影响。
    8. 系统登录测试
    1) 使用合法用户登录系统；
    2) 用户名、口令错误或漏填时能否登陆；
    3) 系统是否容许多次非法登陆,是否有次数限制；
    4) 使用已登录账号登录系统系统能否正确处理；
    5) 使用禁用帐号登陆系统能否正确处理；
    6) 删除或修改后的用户用原用户登录；
    7) 不输入用户名和口令，重复点“确定”和“取消”按钮，是否允许登录。
    9. 注销
    1) 注销为原模块、新模块系统能否正确处理；
    2) 中止注销能否返回原模块、原用户；
    3) 注销为原用户、新用户系统能否正确处理；
    4) 使用错误的帐号、口令或无权限帐号、被禁用帐号进行注销。
    10. 修改口令
    1) 正常情况；
    2) 输入错误的原口令或新口令与确认口令不一致系统能否正确处理；
    3) 修改口令后，用原口令是否能登录（同时验证新口令是否有效）；
    4) 是否能修改其它用户的口令。

    11. 右键功能
    1) 右键菜单中的功能是否与菜单（或工具栏）中对应的功能一致；
    2) 右键菜单中的功能能否正确实现；
    3) 同一菜单下的热键是否相同。
    12. 记录列表
    1) 增加重复记录、空白记录，系统能否正确处理；
    2) 修改后不保存（有保存按钮），系统能否正确处理；
    3) 删除或修改正在使用信息，系统能否正确处理；
    4) 删除级联记录的上游或下游记录，系统能否正确处理；
    5) 删除记录时是否有提示；
    6) 记录中包含的缺省系统信息能否删除和修改；
    7) 记录列表能否及时反应记录的变化；
    8) 记录变化之后系统相关信息能否及时更新；
    13. 统计、查询
    1) 对非法的时间范围系统能否正确处理；
    2) 统计查询语句包含多个与或非条件时，系统能否正确处理；
    3) 条件逻辑混乱，系统能否正确处理；
    4) 多表查询统计及单表查询统计功能是否正确实现；
    5) 分类查询、精确查询、无条件查询、组合查询能否完整列出满足条件的记录；
    6) 能否按系统默认的条件进行查询；
    7) 当统计时间段为当日、跨日、跨月、跨季、跨年度时，统计查询结果是否正确；
    8) 当某些操作被别人取消后，设置条件段为取消前、取消后、包含取消操作的一段时间；
    9) 以不同的权限登录时，统计、查询是否正确；
    10) 在查询或统计大数据量时，系统是否允许终止操作；
    11) 查询、统计按钮是否允许双击或更多的点击，系统做何反映；
    12) 查询出的数据是否允许修改。
    14. 文件操作
    a）保存
    1) 文件是否能够正确保存在在缺省位置或指定位置（本地、网络）；
    2) 系统能否正确处理长文件名、特殊字符文件名保存；
    3) 文件能否保存为其它扩展名；
    4) 如应用程序对文件名区分大小写，当这些文件在导出到介质中时，系统能否正确处理；
    5) 介质空间已满时，系统是否给出提示。
    b）打开
    1) 打开文件是否正确显示上一次保存的内容；
    2) 系统能否正确处理非系统默认扩展名的文件；
    3) 文件能否被其他程序正确打开；
    4) 打开对话框中，是否有默认扩展名的文件类型；
    5) 打开对话框时，是否有默认的路径。
    c）打印输出
    1) 是否按所设置的格式打印；
    2) 是否有打印预览，能否设置打印字体，打印效果是否合乎客户要求；
    3) 打印预览的内容是否正确，内容是否能够进行拖拽操作，是否影响实际的打印；
    4) 安装或不安装打印功能模块，对其它模块是否有影响；
    5) 打印机未安装系统有无提示；
    6) 打印中途能否进行正常的打印中断，是否可以选择打印的内容。
    7) 能否进行本地或网络打印。
    d) 导入、导出功能
    1) 导入的文件格式非要求时，系统如何处理；
    2) 导入、导出的有效文件能否完整正确地显示并被使用；
    3) 导出后的文件是否允许修改，如果允许，导入后能否使用；如不允许，系统有何限制；
    4) 导入，导出是否可以选择路径；
    5) 在客户端和服务器端进行导入，导出；
    6) 在客户端和客户端之间进行导入，导出；
    7) 在本地进行导入，导出；
    8) 不同文件格式的导入，导出。
    e) 检入与检出
    1) 单文件、多文件检入与检出；
    2) 能否多次检入与检出；
    3) 文件检出后其它人能对其做何操作。
    15. 界面上对象的功能（文本框，下拉框，按钮，热键等等）
    a) 工具条
      1) 工具条能否正常显示/隐藏；
    2) 工具条按钮在不可用时是否置灰，例如在不置灰情况下，重复点击工具条上的按钮，看系统是否能够正常进行操作；
    3) 可移动工具条在窗口中间位置其形状是否正确；
    4) 工具条船坞状与非船坞状时其上按钮是否相同；
    5) 工具栏上工具按钮功能是否能正常实现；
    6) 工具按钮显示是否正确、友好、醒目易懂；
    7) 工具栏上的工具按钮是否有鼠标悬停提示；
    8) 工具栏上的工具按钮是否可以任意定制。
    b) 下拉列表
       1) 列表记录的每一行是否显示完整；
       2) 列表记录不能在一页中显示时，是否有纵向滚动栏；
       3) 列表滚动栏上滑块能否自由滑动，对应内容显示是否正确；
       4) 列表中内容能否自动排序。
    c) 窗口
       1) 打开的窗口不确认关掉，能否再调其它窗口，且连续开窗口系统能否正确处理；
       2) 窗口尺寸变化时窗口中控件能否自适应；
       3) MDI中，子窗口的平铺、重叠、排列图标功能是否正确；
       4) 窗口的标题、图标是否和菜单命令、按钮一致；
       5) 子窗口和主窗口的属性是否正确；
       6) 窗口中的上下左右滚动条是否能达到预览全部界面的效果。
    d) 文本框
       1) 对输入域的必添项处理是否正确；
       2) 输入域是否有长度限制；
       3) 输入域如对某些字符禁止输入时，限制是否成功；
       4) 中文、英文、空格，数字，字符，下划线、单引号 等所有特殊字符的组合；
       5) 口令域
    ü 口令为空格或包含空格、特殊字符（所有特殊字符的测试）时系统能否正常处理；
    ü 口令位数是否有限制；
    ü 口令与帐号相同，系统是否有提示；
    ü 口令为字典单词系统能否正确处理；
    特殊的对系统安全性要求较高应该注意：
    ü 口令应有最少位数限制；
    ü 口令应为数值、大小写字母、特殊字符的组合；
    ü 口令禁止设为空，不能和要被修改的口令一致；
    ü 口令区分大小写；
    6) 时间域
    ü 年度超过4位；
    ü 月份输入0或大于12；
    ü 日期输入0或大于当前月份的天数；
    ü 年度，月份，日期输入负数；
    ü 时间输入大于或小于边缘值的数据；
    ü 进行字符及汉字的输入，看程序能否正确处理；
    ü 系统中所涉及时间是否取服务器时间；
    ü 有范围的输入域，开始时间大于、小于、等于结束时间，系统能否正确处理；
    ü 时间范围同当前时间的关系是否正确；
    ü 是否包含缺省时间且缺省时间意义是否正确；
    ü 系统对闰年，闰月的处理；
    ü 对不同的时间格式（yyyy-dd-mm,yy-dd-mm,yyyy/dd/mm,yy/dd/mm等）是否允许输入；
    ü 输入的时间在与之有关的模块中是否能正确的起到作用及对其他模块的影响；
    ü 对时间点的测试。
                        7) 货币域
    ü 输入负值、零、特大数、小数系统能否正确处理；
    ü 系统对小数点后数位的控制是否正确；
    ü 系统能否正确处理数值计算；
    ü 输入非数值型数据（包括特殊字符），系统能否正确处理；
    ü 系统能处理货币的种类。
    8) 身份证（18或15位）：
    ü 身份证中输入非法的年月日信息（包括超界数字及字符，汉字），程序能否进行检验并正确处理；
    ü 由身份证号码计算年龄，系统对出生年份末两位数是00的身份证号码能否正常处理；
    ü 在年龄和身份证均作为用户信息输入时，是否具有关联；
    ü 在身份证的输入中，是否允许输入字符”x”。
    9) 电话号码
    ü 输入特殊的电话号码，如119，110，800等看程序是否能正确处理；
    ü 验证－，（，） *  # 是否有真正含义；
    ü 电话号码长度是否有限制；
    ü 电话号码是否允许输入汉字，英文。
      10) 关于时间的其它操作
    ü 时间的跨月份、年度操作；
    ü 12小时、24小时制的操作；
    ü 客户机与服务器时间不同的操作（包括客户机与服务器两地时差不同）；
      11) 数据字段一致性
    不同窗口中同一类数据输入域的数据接口是否一致(如添加用户及用户登录窗口对用户标识和口令的长度是否一致)。
    e) 图表曲线
        首先，在一定的时间段观察曲线走势，如果有类似的软件可对比的话可以进行对比大体趋势，然后，再找关键点，对比关键点的数据。测试中，需要找到曲线的计算公式，找关键点进行计算。（进行对比是必要的，第一，可以节省一些不必要的工作量；第二，也有可能是编码人员所用的公式本身就有问题，而你所有测试所做的计算都是徒劳了。）
    f) 列表
    1) 列表记录不能在一页中显示时，是否有纵向滚动栏；记录长度超过列表宽度时，是否有横向滚动栏；
    2) 列表滚动栏上滑块能否自由滑动，滑块滑动时，对应内容显示是否正确；
    3) 列表内容是否可直接输入；
    4) 列表中每列数据能否按升序、降序排列；
    16. 备份与恢复
    1) 备份T日的数据，进行操作，然后恢复，查看恢复的数据是否正确；
    2) 备份到不同介质上，并考虑介质空间已满的情况；
    3) 用系统提供的恢复功能进行恢复：
    ü 用数据库进行恢复；
    ü 在备份和恢复还没有结束的时候，终止（掉电，网络不通等）备份和恢复；
    ü 有操作的时候，进行备份和恢复；
    ü 没有任何操作的时候，进行备份，恢复；
    ü 部分备份，全部备份，部分恢复，全部恢复有选择的备份和恢复；
    4) 进行备份，恢复操作是否有权限限制 A 有: 分别用有权限的用户和没有权限的用户进行操作 B 没有：单个用户进行备份，恢复；多个用户同时进行备份和恢复。
    17．系统日志的处理
    1) 系统能否正确记录日志信息；
    2) 系统是否有清空日志的功能；
    3) 系统是否有导出日志的功能；
    4) 当日志数据超过容量时，系统如何处理。

    二．性能测试
    具体用例不好设计，下面列出了一些有性能要求的测试点：
    1) 查询
    2) 保存
    3) 统计
    4) 刷新
    5) 显示
    6) 传输
    7) 响应
    8) 下载
    打开网络上其它介质上的文件时，可制造网络拥挤情况下的文件打开操作。主要测试点，集中在几个点上。一是数据量小的时候主要的查询统计刷新等功能点；二是数据量积累到一定程度时的查询统计刷新时间，这里的一定程度是根据实际的项目和客户需求来定的。

    三．极限压力测试
    1）接收大数据量的数据文件时间；
    2) 大数据恢复时间；
    3) 大数据导入导出时间；
    4) 大批量录入数据时间；
    5) 大数据量的计算时间；
    6) 多客户机同时进行某一个提交操作；
    7) 采用测试工具软件；
    8) 编写测试脚本程序；
    9) 大数据量的查询统计时间。

    四. 容错测试
    1) 通过断开网线的强制性停止数据传输以及重新将网线接上，查看提示信息及对系统的影响；
    2) 系统断电，恢复后查看对系统的影响程度；
    3) 死机后，看程序如何处理；
    4) 服务器DOWN掉，客户端程序如何处理。

    五．并发测试
    1) 登录的并发操作：多人同时登录系统，使用不同或相同账号；
    2) 提交的并发操作：多人同时提交相同的工作项、不同的工作项；
    3) 对数据库操作的并发操作：多人同时从数据库中读出（或向数据库导入） 相同文件、不同文件。

    ************************
    附：一些容易出错的地方
    ************************
    一. 有关新建和修改
    1. 创建或修改的内容为已经存在的内容，系统是否有提示；
    2. 修改正在使用的数据。
    二. 删除
    1. 应有确认提示；
    2. 若删除的内容在文件或数据库中，应作实际校验；
    3. 删除正在使用的数据；
    4. 考虑删除数据的相关数据是否同时被删除；
    5. 重新使用已删除的数据。
    三．关于提示信息的验证
    有些操作系统会给出成功（有时没有成功提示）或失败的提示，一定要验证提示的正确性（尤其是一些重要操作，如修改口令），即用其它方法检查所作的操作是否真正成功或失败。
    四．关于考虑硬盘空间已满的情况
    1. 数据存储和备份；
    2. 生成文件；
    3. 拷贝文件
    五．关于修改系统时间
    对于和时间有关的业务，测试时考虑修改系统时间对系统的影响。
    六．对于响应速度慢的按钮进行连续点击；或中途取消，再继续…
    七．凡是支持并发过程的功能，一定要做并发测试（手工进行或利用工具）；
    八．打印功能（能否正确打印，打印效果与预览是否一致）
    九．系统初始化
    1) 如果系统安装后需要进行初始化，初始化过程是否正确；
    2) 如果系统安装后不需要进行初始化，安装后的默认设置是否正确、适当。
    十．版权声明是否符合标准，如果有公司的logo，图标是否正确（最容易测试的地方，也是最容易被忽略的地方）
    十一．如果捆绑硬件，如果可能的话，在测试我们的软件产品前要对硬件的性能、稳定性进行严格测试。（包括大数据量的传输入等）
    十二．备份与恢复
    1) 备份与恢复过程本身的正确性；
    2) 备份内容的正确性（通过事先准备的测试数据在恢复后验证）；
    3) 备份与恢复过程中对异常情况的处理（掉电、网络不通等）；
    4) 在原始机上的恢复；
    5) 在非原始机上的恢复；
    6) 在裸机（只有操作系统和必要的数据库或第三方产品）上的恢复；
    7) 在一台机器上进行若干次的备份与恢复；
    8) 如果是支持多数据库的软件，备份与恢复是容易出错的地方。
    需要严格把握的错误类别：
    在整个测试过程中对每条问题都制定有错误归类，现按照问题的严重程度，把问题主要分为四类：
        A：严重影响系统运行：导致系统出现不可预料的严重错误的问题，例如：运行过程中出现页
    面或页面无法显示、死机等。
    B：影响系统运行：系统中重要的功能出现运行错误，例如：导致用户必须重新登录的问题，        
    导致个别用户不可用的问题；
    C：不影响系统运行但必须修改：系统中基本的操作或功能没有实现或实现有误的问题，以及
    不符合常规的操作界面的问题。
    D：所提建议：不影响系统运行，对系统的可用性等提示的建议性的问题

    查看(306) 评论(0) 收藏 分享 管理

  • 测试用例设计白皮书－－等价类划分方法

    2008-11-20 13:33:43

    一.方法简介

    　　1.定义

    　　是把所有可能的输入数据,即程序的输入域划分成若干部分（子集）,然后从每一个子集中选取少数具有代表性的数据作为测试用例。该方法是一种重要的,常用的黑盒测试用例设计方法。

    　　2.划分等价类：

    　　等价类是指某个输入域的子集合。在该子集合中,各个输入数据对于揭露程序中的错误都是等效的，并合理地假定：测试某等价类的代表值就等于对这一类其它值的测试，因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件就可以用少量代表性的测试数据取得较好的测试结果。等价类划分可有两种不同的情况：有效等价类和无效等价类。

    　　1)有效等价类

    　　是指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。

    　　2)无效等价类

    　　与有效等价类的定义恰巧相反。无效等价类指对程序的规格说明是不合理的或无意义的输入数据所构成的集合。对于具体的问题，无效等价类至少应有一个，也可能有多个。

    　　设计测试用例时,要同时考虑这两种等价类。因为软件不仅要能接收合理的数据,也要能经受意外的考验，这样的测试才能确保软件具有更高的可靠性。

    　　3.划分等价类的标准：

    　　1)完备测试、避免冗余;

    　　2)划分等价类重要的是：集合的划分，划分为互不相交的一组子集，而子集的并是整个集合;

    　　3)并是整个集合：完备性;

    　　4)子集互不相交：保证一种形式的无冗余性;

    　　5)同一类中标识（选择）一个测试用例，同一等价类中，往往处理相同，相同处理映射到"相同的执行路径"。

    　　4.划分等价类的方法

    　　1)在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类。如：输入值是学生成绩，范围是0～100；

    　　2)在输入条件规定了输入值的集合或者规定了"必须如何"的条件的情况下,可确立一个有效等价类和一个无效等价类；

    　　3)在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类。

    　　4)在规定了输入数据的一组值（假定n个）,并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类。

    　　例：输入条件说明学历可为:专科、本科、硕士、博士四种之一，则分别取这四种这四个值作为四个有效等价类，另外把四种学历之外的任何学历作为无效等价类。

    　　5)在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）；

    　　6)在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类。

    　　5.设计测试用例

    　　在确立了等价类后,可建立等价类表,列出所有划分出的等价类输入条件：有效等价类、无效等价类，然后从划分出的等价类中按以下三个原则设计测试用例：

    　　1)为每一个等价类规定一个唯一的编号；

    　　2)设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步，直到所有的有效等价类都被覆盖为止；

    　　3)设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步，直到所有的无效等价类都被覆盖为止。

    查看(156) 评论(0) 收藏 分享 管理

  • 测试用例设计白皮书－－错误推测方法

    2008-11-20 13:29:30

    一. 方法简介

    　　1. 定义：基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法。

    　　2. 错误推测方法的基本思想：

    　　列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例。

    　　1) 例如, 输入数据和输出数据为0的情况；输入表格为空格或输入表格只有一行。 这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例。

    　　2) 例如，前面例子中成绩报告的程序，采用错误推测法还可补充设计一些测试用例：

    　　I.程序是否把空格作为回答

    　　II. 在回答记录中混有标准答案记录

    　　III.除了标题记录外，还有一些的记录最后一个字符即不是2也不是3

    　　IV.有两个学生的学号相同

    　　V. 试题数是负数。

    　　3) 再如，测试一个对线性表（比如数组）进行排序的程序，可推测列出以下几项需要特别测试的情况：

    　　I.输入的线性表为空表；

    　　II. 表中只含有一个元素；

    　　III.输入表中所有元素已排好序；

    　　IV.输入表已按逆序排好；

    　　V. 输入表中部分或全部元素相同。

    　　二. 实战演习

    　　 暂无


    查看(142) 评论(0) 收藏 分享 管理

  • 测试用例设计白皮书－－边界值分析方法

    2008-11-20 13:28:17

    一.方法简介

    　　1. 定义：边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。

    　　2. 与等价划分的区别

    　　1) 边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件。

    　　2) 边界值分析不仅考虑输入条件，还要考虑输出空间产生的测试情况。

    　　3. 边界值分析方法的考虑：

    　　长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。

    　　使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入和输出等价类的边界，就是应着重测试的边界情况。应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。

    　　4. 常见的边界值

    　　1) 对16-bit 的整数而言 32767 和 -32768 是边界

    　　2) 屏幕上光标在最左上、最右下位置

    　　3) 报表的第一行和最后一行

    　　4) 数组元素的第一个和最后一个

    　　5) 循环的第 0 次、第 1 次和倒数第 2 次、最后一次

    　　5. 边界值分析

    　　1) 边界值分析使用与等价类划分法相同的划分，只是边界值分析假定错误更多地存在于划分的边界上，因此在等价类的边界上以及两侧的情况设计测试用例。

    　　例：测试计算平方根的函数

    　　--输入：实数

    　　--输出：实数

    　　--规格说明：当输入一个0或比0大的数的时候，返回其正平方根；当输入一个小于0的数时，显示错误信息"平方根非法-输入值小于0"并返回0；库函数Print-Line可以用来输出错误信息。

    　　2) 等价类划分：

    　　I.可以考虑作出如下划分：

    　　a、输入 (i)<0 和 (ii)>=0

    　　b、输出 (a)>=0 和 (b) Error

    　　II.测试用例有两个：

    　　a、输入4，输出2。对应于 (ii) 和 (a) 。

    　　b、输入-10，输出0和错误提示。对应于 (i) 和 (b) 。

    　　3) 边界值分析：

    　　划分(ii)的边界为0和最大正实数；划分(i)的边界为最小负实数和0。由此得到以下测试用例：

    　　a、输入 {最小负实数}

    　　b、输入 {绝对值很小的负数}

    　　c、输入 0

    　　d、输入 {绝对值很小的正数}

    　　e、输入 {最大正实数}

    　　4) 通常情况下，软件测试所包含的边界检验有几种类型：数字、字符、位置、重量、大小、速度、方位、尺寸、空间等。

    　　5) 相应地，以上类型的边界值应该在：最大/最小、首位/末位、上/下、最快/最慢、最高/最低、 最短/最长、 空/满等情况下。

    　　6) 利用边界值作为测试数据

    项

    边界值

    测试用例的设计思路

    字符

    起始-1个字符/结束+1个字符

    假设一个文本输入区域允许输入1个到255个 字符，输入1个和255个字符作为有效等价类；输入0个和256个字符作为无效等价类，这几个数值都属于边界条件值。

    数值

    最小值-1/最大值+1

    假设某软件的数据输入域要求输入5位的数据值，可以使用10000作为最小值、99999作为最大值；然后使用刚好小于5位和大于5位的 数值来作为边界条件。

    空间

    小于空余空间一点/大于满空间一点

    例如在用U盘存储数据时，使用比剩余磁盘空间大一点（几KB）的文件作为边界条件。


    查看(541) 评论(0) 收藏 分享 管理

  • 测试用例设计白皮书－－因果图方法

    2008-11-20 13:24:05

    一. 方法简介

    　　1.定义：是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。

    　　2.因果图法产生的背景：

    　　等价类划分法和边界值分析方法都是着重考虑输入条件，但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了，但多个输入条件组合起来可能出错的情况却被忽视了。

    　　如果在测试时必须考虑输入条件的各种组合，则可能的组合数目将是天文数字，因此必须考虑采用一种适合于描述多种条件的组合、相应产生多个动作的形式来进行测试用例的设计，这就需要利用因果图（逻辑模型）。

    　　3.因果图介绍

    　　1) 4种符号分别表示了规格说明中向4种因果关系。

    　　2) 因果图中使用了简单的逻辑符号，以直线联接左右结点。左结点表示输入状态（或称原因），右结点表示输出状态（或称结果）。

    　　3) Ci表示原因，通常置于图的左部；ei表示结果，通常在图的右部。Ci和ei均可取值0或1，0表示某状态不出现，1表示某状态出现。

    　　4. 因果图概念

    　　1) 关系

    　　① 恒等：若ci是1，则ei也是1；否则ei为0。

    　　② 非：若ci是1，则ei是0；否则ei是1。

    　　③ 或：若c1或c2或c3是1，则ei是1；否则ei为0。“或”可有任意个输入。

    　　④ 与：若c1和c2都是1，则ei为1；否则ei为0。“与”也可有任意个输入。

    　　 2) 约束

    　　输入状态相互之间还可能存在某些依赖关系，称为约束。例如, 某些输入条件本身不可能同时出现。输出状态之间也往往存在约束。在因果图中,用特定的符号标明这些约束。

    　　A.输入条件的约束有以下4类：

    　　① E约束（异）：a和b中至多有一个可能为1，即a和b不能同时为1。

    　　② I约束（或）：a、b和c中至少有一个必须是1，即 a、b 和c不能同时为0。

    　　③ O约束（唯一）；a和b必须有一个，且仅有1个为1。

    　　④ R约束（要求）：a是1时，b必须是1，即不可能a是1时b是0。

    　　B.输出条件约束类型

    　　输出条件的约束只有M约束（强制）：若结果a是1，则结果b强制为0。

    　　5. 采用因果图法设计测试用例的步骤：

    　　1) 分析软件规格说明描述中, 那些是原因(即输入条件或输入条件的等价类),那些是结果(即输出条件), 并给每个原因和结果赋予一个标识符。

    　　2) 分析软件规格说明描述中的语义，找出原因与结果之间, 原因与原因之间对应的关系，根据这些关系,画出因果图。

    　　3) 由于语法或环境限制, 有些原因与原因之间,原因与结果之间的组合情况不可能出现，为表明这些特殊情况, 在因果图上用一些记号表明约束或限制条件。

    　　4) 把因果图转换为判定表。

    　　5) 把判定表的每一列拿出来作为依据,设计测试用例。

    查看(283) 评论(0) 收藏 分享 管理

  • WEB测试之兼容性测试

    2008-11-20 13:18:16

    1. 软件兼容性测试

    　　兼容性测试是指待测试项目在特定的硬件平台上，不同的应用软件之间，不同的操作系统平台上，在不同的网络等环境中能正常的运行的测试。

    　　兼容性测试的目的：待测试项目在不同的操作系统平台上正常运行，包括待测试项目能在同一操作系统平台的不同版本上正常运行；待测试项目能与相关的其他软件或系统的“和平共处”；待测试项目能在指定的硬件环境中正常运行；待测试项目能在不同的网络环境中正常运行。

    　　兼容性测试无法做到完全的质量保证，但对于一个项目来讲，兼容性测试是必不可少的一个步骤。

    　　2. Web兼容性测试的主要类型

    　　Web兼容性测试主要是针对不同的操作系统平台，浏览器，以及分辨率进行的测试。

    　　2.1. 操作系统兼容性测试

    　　常见的操作系统有Windows，Unix，Linux等，对于普通用户来讲，最常用的是Windows操作系统。Windows操作系统包括Windows XP，windows 2003，vista，Win2000/NT，Windows9x等等。用户使用操作系统的类型，直接决定了我们操作系统平台兼容性测试的操作系统平台数量，进行操作系统平台的兼容性测试的主要目的就是保证我们的待测试项目在该操作系统平台下能正常运行。

    　　对于一些特殊项目（比如定制项目），可以指定某一类型的操作系统版本，这些都应该在需求规格说明书中指明，针对这些指明的操作系统版本必须进行兼容性测试。

    　　大部分的其他项目，是不指定操作系统版本的，针对这样的项目，我们应当针对当前的主流操作系统版本进行兼容性测试，在确保主流操作系统版本兼容性测试的前提下在对非主流操作系统版本进行测试，尽量保证项目的操作系统版本的兼容性测试的完整性。

    　　2.2. 浏览器兼容性测试

    　　浏览器是Web系统中对核心的组成构件，来自不同厂家的浏览器对Javascrīpt、 ActiveX或不同的HTML规格有不同的支持，即使是同一厂家的浏览器，也存在不同的版本的问题。不同的浏览器对安全性和JAVA的设置也不一样。

    　　目前最为常用的浏览器为：IE 6.0 IE 7.0.但由于操作习惯的问题，还有相当一部分用户喜欢使用腾讯的TT，以及firefox浏览器，这些浏览器同样也存在各个版本的问题。这个对于Web系统来讲是一个相当大的挑战。

    　　对于一些特殊项目（比如定制项目），可以指定某一类型的浏览器（包括版本），这些都必须在需求规格说明书中指明。针对这些指明的浏览器必须进行兼容性测试。但大部分的项目，是不能指定浏览器的，针对这样的项目，那么我们必须针对当前的主流浏览器（含版本），在确保主流浏览器的兼容性测试通过的前提下，再对非主流浏览器（含版本）进行测试，尽量保证项目的浏览器的兼容性测试的完整性。

    　　2.3. 分辨率兼容性测试

    　　分辨率的测试是为了页面版式在不同的分辨率模式下能正常显示，字体符合要求而进行的测试。

    　　用户使用什么模式的分辨率，对于我们来讲是未知的。通常情况下，在我们的需求规格说明书中会建议某些分辨率。对于测试来讲，必须针对需求规格说明书中建议的分辨率进行专门的测试。现在常见的分辨率是1024×768，800×600。对于需求规格说明书中规定的分辨率，测试必须保证测试通过，但对于其他分辨率，原则上也应该尽量保证，但由于这个在需求规格说明书中没有加以约束，所以在一定程度上，开发往往会拒绝进行调整。对于需求规格说明书中没有规定分辨率的项目，测试应该在完成主流分辨率的兼容性测试的前提下，尽可能进行一些非主流分辨率的兼容性测试，在一定程度上保证大部分。

    查看(549) 评论(3) 收藏 分享 管理

  • 【Anny读书笔记】软件测试10大原则及需要牢记的观点

    2008-11-18 15:55:03

    原则1.测试用例中一个必须部分是对预期输出或结果进行定义。
        这条显而易见的原则在软件测试中是最常犯的错误之一。同样，这个问题也是基于人们的心理的。如果某个测试用例的预期结果事先没有得到定义，由于“所见即所想”现象的存在，某个似是而非，实际上是错误的结果可能会被解释成正确的结论。换句话说，尽管“软件测试是破坏性”的定义是合理的，但人们在潜意识中仍然渴望看到正确的结论。克服这种倾向的一种方法，就是通过事先精确定义程序的预期输出，鼓励人们对所有的输出进行仔细检查。因此，一个测试用例必须包括两个部分：
    1.对程序的输入数据的描述。
    2.对程序在上述输入数据下的正确输出结果的精确描述。

    原则2.程序员应当避免测试自己编写的程序。
        如果我们对软件项目关注的重点发生变化，就会产生另外一个问题。当成员“建设性”地设计和编写完程序之后，很难让他突然改变视觉角度以一种“破坏性”的眼光来审查程序。
        大多数程序员都不能有效地测试自己编写的程序，因为他们无法改变思维方式来尽力暴露自己程序中的错误。另外，程序员可能会下意思地避免找出错误来，担心受到同事、上司、客户或正在开发的程序或系统的主管的惩罚。
        由于程序员错误地理解了疑难定义或规范，导致程序中存在错误。如果情况是这样，程序员可能会带着同样的误解来测试自己的程序。
        这并不意味这着程序员测试自己的程序是不可能的。当然让其他人来测试程序会更加有效，也会更容易测试成功。
        测试不等于调试，调试由程序的编写人员来完成会有效得多。

    原则3.编写软件的组织不应当测试自己编写的软件。
        一个软件项目或变成组织是一个有机的机构，具有与各地程序员相似的心理问题。而且在大多数情况下，主要是根据其在给定时间特定成本范围内开发软件的能力来衡量编程组织或项目经理。其中的一个原因是，度量时间和成本目标比较容易，而定量地衡量软件的可靠性则极其困难。即便是合理规划和实施的测试过程，也可能被认为降低了完成进度和成本目标的可能性，因此，编程组织难以客观地测试自己的软件。
        更经济的方法是由客观、独立的第三方来进行测试。

    原则4.应当彻底检查每个测试的执行结果。
        这个原则可能是最显而易见的原则，但也同样常常被忽视。我们见过大量的例子，即便错误的症状在输出清单中可以清楚地看到，但还是没有找出那些错误来。换言之，在后续测试中发现的错误，往往是前面的测试遗漏掉的。

    原则5.测试用例的编写不仅应当根据有效和遇到的输入情况，而且也应当根据无效和未遇到到的输入情况。
        在软件测试时，有个自然的倾向，即将重点集中在有效和预期的输入情况上，而忽略了无效和未预料到的情况。此外，在软件产品中突然暴露出来的许多问题是当程序以某些新的或未预料到的方式运行时发现的。因此，针对未预料的和无效输入情况的测试用例，似乎比针对有效输入情况的那些用例更能发现问题。

    原则6.检查程序是否“未做其应该做的”仅是测试的一般，测试的另一半是检查程序是否“做了其不应该做的”
        这条原则是上条原则的必然结果。必须检查程序是否有我们不希望的负作用。比如，某个工资管理程序即便可以生成正确的工资单，但是如果也为非雇员生成工资单或者它覆盖掉了人员文件的第一条记录，这样的程序仍然是不正确的程序。

    原则7.应避免测试用例用后即弃，除非软件本身就是一个一次性的软件。
        这问题在采用交互式系统来测试软件时最常见。人们通常会坐在终端前，匆忙地编写测试用例，然后将这些测试用例交由程序执行。这样做的问题在于，饱含我们宝贵投入的测试用例，在测试结束后就消失了。一旦软件需要重新测试，又必须重新设计这些测试用例。情况往往是这样的，由于重新设计测试用例需要投入大量的工作，人们总是避免这样做。因此，对该程序的重新测试极少会同上次一样严格。这就意味着，如果对成功需的更改导致了程序某个先前可以执行的部分发生了故障，这个故障往往是不会被发现的。保留测试用例，当程序其他部分发生变动后重新执行，这就是我们所谓的“回归测试”。

    原则8.计划测试工作时不应默许假定不会发现错误。
        项目经理经常容易犯这个错误，这也是使用了不正确的测试定义的一个迹象——也就是说，假定“测试是一个证明程序正确运行的过程”。
        所谓测试，是为了发现错误而执行程序的过程。

    原则9.程序某部分存在更多错误的可能性，与该部分已发现错误的数量成正比。
        假如某个程序由两个模块、类或子程序A和B组成，模块A中已经发现了5个错误，而模块B中仅仅找到了一处错误。如果模块A所经过的测试并不是故意设计的更为严格，那么改原则告诉我们，模块A与模块B相比，存在更多错误的可能性要大。
        错误总是倾向于聚集存在，而在一个具体的程序中，某些部分要比其他部分更容易存在错误，尽管没有人能够对这种现象给出很好的解释。如果一个程序的某个部分远比其他部分更容易产生错误，那么这种现象告诉我们，为了使测试获得更大的成效，最好对这些容易存在的错误的部分进行额外的测试。

    原则10.软件测试是一向极富创造性、极具智力挑战的工作。
        测试一个大型软件所徐奥的创造性很可能超过了开发该软件所需要的创造性。要充分测试一个软件以确保所有错误都不存在是不可能的。


    牢记下述观点：
        软件测试是为了发现错误而执行程序的过程。
        一个好的测试用例具有较高的范县某个尚未发现的错误的可能性。
        一个成功的测试用例能够发现某个尚未发现的错误。

    查看(288) 评论(0) 收藏 分享 管理

  • 脚本语言（二）

    2008-10-30 18:21:02

     

    2008-10-30 17:15:07 / 个人分类：开发语言学习

    1）Javascrīpt的注释：

    “<!-- …… -->”和“//”都表示注释，前者是在不支持javascrīpt时隐藏，后者是在可补忽略的注释。这两各注释都必须在一行内使用。

    2）内置函数：document.write()，输出文本。

    3）字符串的可加性，如：document.write("A"+"  "+"B"); 则在IE中会显示“A  B”字符。

    4）<a href=" http://www.hao123.com " ōnMouseOver="window.status='已经将鼠标已经放在了该链接上，现已移开'">链接到hao123</a>

    5）语句：if－else if-else;

    <html>
    <head>
    <scrīpt language="Javascrīpt">
    var java = prompt("你喜欢JAVASCIRPT吗？","输入“Y”或者“N”");
    if (java== "Y"){alert("欢迎你，来吧，我们继续学习吧！");}
    else if(java=="N"){alert("它很有趣的，不学多可惜，唉 ：（");}
    else if(java=="123"){alert("你输入的是123～…～");}
    else {alert("这里只能输入Y和N");}
    </scrīpt>
    </head>
    <body>
    </body>
    </html>

    Today is over now.

     

    查看(193) 评论(1) 收藏 分享 管理

  • 黑盒测试方法揭密

    2008-10-17 14:15:23

    黑盒测试方法揭密

    一、黑盒测试在快速应用开发（rad）环境中的重要作用

    　　软件测试方法一般分为两种：白盒测试与黑盒测试。其中，白盒测试又称为结构测试、逻辑驱动测试或基于程序本身的测试，着重于程序的内部结构及算法，通常不关心功能与性能指标。黑盒测试又被称为功能测试、数据驱动测试或基于规格说明的测试，实际上是站在最终用户的立场上，检验输入输出信息及系统性能指标是否符合规格说明书中有关功能需求及性能需求的规定。

    　　随着rad环境的发展，软件工程面临新的挑战，其中包括：

    　　●应用系统的规模越来越庞大，结构越来越复杂；

    　　●开发团队人员越来越多，分工越来越细；

    　　●项目投资日益提高，导致投资风险增大。

    　　在这样一种背景下，软件质量面临着更大的危机，而解决问题的关键正是黑盒测试，可是由于传统的黑盒测试往往局限于手工测试，凭借工程人员的经验自发地进行，缺乏严格的测试管理机制，因而效果并不明显。

    　　在分发一个应用系统之前，若没有经过科学、周密的黑盒测试，就相当于将大量隐含的缺陷（defect）交付到最终用户手中，这对于开发团队自身、项目投资方及最终用户来说都是不负责任的表现，也将严重损害三方的利益。

    　　今天，软件的质量要求越来越受到重视，在对软件的质量监督中，黑盒测试起着重要的、不可替代的作用；而随着软件开发平台及软件设计思想的进步和发展，特别是rad技术的发展，对黑盒测试提出了更明确的要求，人们发现，必须遵循一定的测试理论，依赖于优秀的测试工具，才能进行科学、完备的测试。

    　　二、黑盒测试的操作步骤

    　　在传统的软件开发生命周期当中，测试工作往往被搁置到整个开发过程的后期进行，也就是说，当应用程序的编码工作已经基本完成，才开始进行测试，这样做的缺点在于：

    　　a）由于应用程序庞大而复杂，测试工作千头万绪，测试人员难以组织科学、全面的测试用例，从而大幅度提高了测试成本，并严重影响测试的全面性和有效性；

    　　b）由于缺陷所涉及的模块从开发到测试之间的时间间隔较长，使得程序员的修改和维护工作要付出更大的代价；

    　　c）由于受到分发日期的限制，测试工作往往是在忙碌中结束的，而将大量的缺陷遗留给最终用户，也就是说，真正的测试工作实际上是由最终用户来完成的。

    　　因此，为了保证测试工作科学、精确、全面、有序地进行，应该采取一边开发一边测试的策略，使得开发工作与测试工作平行进行，这也就是俗话所说的“越早测试越好”的概念。

    　　一套完整的测试应该由五个阶段组成：

    　　1．测试计划

    　　首先，根据用户需求报告中关于功能要求和性能指标的规格说明书，定义相应的测试需求报告，即制订黑盒测试的最高标准，以后所有的测试工作都将围绕着测试需求来进行，符合测试需求的应用程序即是合格的，反之即是不合格的；同时，还要适当选择测试内容，合理安排测试人员、测试时间及测试资源等。

    　　2．测试设计

    　　将测试计划阶段制订的测试需求分解、细化为若干个可执行的测试过程，并为每个测试过程选择适当的测试用例（测试用例选择的好坏将直接影响到测试结果的有效性）。

    　　3．测试开发

    　　建立可重复使用的自动测试过程。

    　　4．测试执行

    　　执行测试开发阶段建立的自动测试过程，并对所发现的缺陷进行跟踪管理。测试执行一般由单元测试、组合测试、集成测试、系统联调及回归测试等步骤组成，测试人员应本着科学负责的态度，一步一个脚印地进行测试。

    　　5．测试评估

    　　结合量化的测试覆盖域及缺陷跟踪报告，对于应用软件的质量和开发团队的工作进度及工作效率进行综合评价。

    　　显然，黑盒测试只有严格按照步骤进行，才可能对应用程序的质量进行把关。然而，如果没有一种优秀的测试工具的帮助，单纯凭借手工测试，不但将耗费大量的人力、物力和财力，而且有很多测试工作是难以实现甚至是无法实现的。

    　　三、手工测试与自动测试的比较

    　　手工测试无法保证黑盒测试的科学性与严密性，这是因为：

    　　●测试人员要负责大量文档、报表的制订和整理工作，会变得力不从心；

    　　●受软件分发日期、开发成本及人员、资源等诸多方面因素的限制，难以进行全面的测试；

    　　●如果修正缺陷所花费的时间相当长，回归测试将变得异常困难；

    　　●对测试过程中发现的大量缺陷缺乏科学、有效的管理手段，责任变得含混不清，没有人能向决策层提供精确的数据以度量当前的工作进度及工作效率；

    　　●反复测试带来的倦怠情绪及其他人为因素使得测试标准前后不一，测试花费的时间越长，测试的严格性也就越低；

    　　●难以对不可视对象或对象的不可视属性进行测试。

    　　因此，自动测试成为最佳的解决方案。所谓自动测试，实际上是将大量的重复性工作交给计算机去完成，一个优秀的自动测试工具，不但可以满足科学测试的基本要求，而且可以节约大量的时间、成本、人员和资源，并且测试脚本可以被重复利用（包括被不同的项目所利用）。

    查看(210) 评论(0) 收藏 分享 管理

  • Web测试方法

    2008-10-17 11:34:29

    Web测试方法

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

    本文将 web 测试分为 6 个部分：

    • 功能测试
    • 性能测试（包括负载/压力测试）
    • 用户界面测试
    • 兼容性测试
    • 安全测试
    • 接口测试

    本文的目的是覆盖 web 测试的各个方面，未就某一主题进行深入说明。

    1 功能测试

    1.1 链接测试

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

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

     

    采取措施：采用自动检测网站链接的软件来进行。

    推荐软件：

    Xenu Link Sleuth 免费 绿色免安装软件

    HTML Link Validator 共享（30天试用）

     

    1.2 表单测试

    当用户通过表单提交信息的时候，都希望表单能正常工作。

    如 果使用表单来进行在线注册，要确保提交按钮能正常工作，当注册完成后应返回注册成功的消息。如果使用表单收集配送信息，应确保程序能够正确处理这些数据，最后能让顾客能让客户收到包裹。要测试这些程序，需要验证服务器能正确保存这些数据，而且后台运行的程序能正确解释和使用这些信息。

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

    1.3 数据校验

    如果系根据业务规则需要对用户输入进行校验，需要保证这些校验功能正常工作。例如，省份的字段可以用一个有效列表进行校验。在这种情况下，需要验证列表完整而且程序正确调用了该列表(例如在列表中添加一个测试值，确定系统能够接受这个测试值)。

    在测试表单时，该项测试和表单测试可能会有一些重复。

    1.2和1.3的采取措施：第一个完整的版本采用手动检查，同时形成WinRunner（QTP）脚本；回归测试以及升级版本主要靠WinRunner（QTP）自动回放测试。

    1.4 cookies测试

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

    　　如果Web应用系统使用了Cookies，就必须检查Cookies是否能正常工作。测试的内容可包括Cookies是否起作用，是否按预定的时间进行保存，刷新对Cookies有什么影响等。如果在     cookies 中保存了注册信息，请确认该 cookie能够正常工作而且已对这些信息已经加密。如果使用 cookie 来统计次数，需要验证次数累计正确。

    采取措施：

           1 采用黑盒测试：采用上面提到的方法进行测试

    2 采用查看cookies的软件进行（初步的想法）

    可以选择采用的软件

    IECookiesView v1.50

    Cookies Manager v1.1

          

    1.5 数据库测试

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

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

     

    1.6 应用程序特定的功能需求

    最重要的是，测试人员需要对应用程序特定的功能需求进行验证。尝试用户可能进行的所有操作：下订单、更改订单、取消订单、核对订单状态、在货物发送之前更改送货信息、在线支付等等。这是用户之所以使用网站的原因，一定要确认网站能像广告宣传的那样神奇。

    采取措施：深刻理解需求说明文档

    1.7 设计语言测试

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

    暂时没有方法测试，可以多参考一点讨论组内的更新信息

    2 性能测试

    2.1 连接速度测试

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

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

    2.2 负载测试

     

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

    2.3 压力测试

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

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

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

     

    负载/压力测试应该关注什么

    测试需要验证系统能否在同一时间响应大量的用户，在用户传送大量数据的时候能否响应，系统能否长时间运行。可访问性对用户来说是极其重要的。如果用户得到“系统忙”的信息，他们可能放弃，并转向竞争对手。系统检测不仅要使用户能够正常访问站点，在很多情况下，可能会有黑客试图通过发送大量数据包来攻击服务器。出于安全的原因，测试人员应该知道当系统过载时，需要采取哪些措施，而不是简单地提升系统性能。

    瞬间访问高峰
    如果您的站点用于公布彩票的抽奖结果，最好使系统在中奖号码公布后的一段时间内能够响应上百万的请求。负载测试工具能够模拟 X 个用户同时访问测试站点。

    每个用户传送大量数据
    网上书店的多数用户可能只订购 1-5 书，但是大学书店可能会订购 5000 本有关心理学介绍的课本? 或者一个祖母为她的 50 个儿孙购买圣诞礼物(当然每个孩子都有自己的邮件地址) 系统能处理单个用户的大量数据吗?

    长时间的使用
    如果站点用于处理鲜花订单，那么至少希望它在母亲节前的一周内能持续运行。如果站点提供基于 web 的 email 服务，那么点最好能持续运行几个月，甚至几年。可能需要使用自动测试工具来完成这种类型的测试，因为很难通过手工完成这些测试。你可以想象组织100 个人同时点击某个站点。但是同时组织 100000 个人呢。通常，测试工具在第二次使用的时候，它创造的效益，就足以支付成本。而且，测试工具安装完成之后，再次使用的时候，只要点击几下。

    采取措施：采用测试工具WAS、ACT协助进行测试

    3 用户界面测试

    3.1 导航测试

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

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

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

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

    3.2 图形测试

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

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

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

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

    　　（4）图片的大小和质量也是一个很重要的因素，一般采用JPG或GIF压缩，最好能使图片的大小减小到     30k 以下

     

    （5）最后，需要验证的是文字回绕是否正确。如果说明文字指向右边的图片，应该确保该图片出现在右边。不要因为使用图片而使窗口和段落排列古怪或者出现孤行。

     

    通常来说，使用少许或尽量不使用背景是个不错的选择。如果您想用背景，那么最好使用单色的，和导航条一起放在页面的左边。另外，图案和图片可能会转移用户的注意力。

    3.3内容测试

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

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

    对 于开发人员来说，可能先有功能然后才对这个功能进行描述。大家坐在一起讨论一些新的功能，然后开始开发，在开发的时候，开发人员可能不注重文字表达，他们添加文字可能只是为了对齐页面。不幸的是，这样出来的产品可能产生严重的误解。因此测试人员和公关部门一起检查内容的文字表达是否恰当。否则，公司可能陷 入麻烦之中，也可能引起法律方面的问题。测试人员应确保站点看起来更专业些。过分地使用粗体字、大字体和下划线可能会让用户感到不舒服。在进行用户可用性方面的测试时，最好先请图形设计专家对站点进行评估。你可能不希望看到一篇到处是黑体字的文章，所以相信您也希望自己的站点能更专业一些。 最后，需要确定是否列出了相关站点的链接。很多站点希望用户将邮件发到一个特定的地址，或者从某个站点下载浏览器。但是如果用户无法点击这些地址，他们可能会觉得很迷惑。

    3.4 表格测试

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

    3.5 整体界面测试

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

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

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

     

    采取措施：手动测试，参与人员最好有外部人员

    4 兼容性测试

    4.1 平台测试

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

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

    4.2 浏览器测试

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

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

     

    4.3 分辨率测试

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

    4.4 Modem/连接速率

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

    4.5 打印机

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

    4.6 组合测试

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

    采取措施：根据实际情况，采取等价划分的方法，列出兼容性矩阵

    5 安全测试

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

    5.1 目录设置

    Web 安全的第一步就是正确设置目录。每个目录下应该有 index.html 或 main.html 页面，这样就不会显示该目录下的所有内容。我服务的一个公司没有执行这条规则。我选中一幅图片，单击鼠标右键，找到该图片所在的路径"…com/objects/images"。然后在浏览器地址栏中手工输入该路径，发现该站点所有图片的列表。这可能没什么关系。我进入下一级目录 "…com/objects" ，点击 jackpot。 在该目录下有很多资料，其中引起我注意的是已过

    查看(220) 评论(0) 收藏 分享 管理

  • WEB测试资料

    2008-10-17 11:11:14

    关于web测试
    1页面部分
    （1） 页面清单是否完整（是否已经将所需要的页面全部都列出来了）
    （2） 页面是否显示（在不同分辨率下页面是否存在，在不同浏览器版本中页面是是否显示）
    （3） 页面在窗口中的显示是否正确、美观（在调整浏览器窗口大小时，屏幕刷新是否正确）
    （4） 页面特殊效果（如特殊字体效果、动画效果）是否显示
    （5） 页面特殊效果显示是否正确

    2 页面元素部分
    （1）页面元素清单（为实现功能，是否将所需要的元素全部都列出来了，如按钮、单选框、复选框、列表框、超连接、输入框等等）
    （2）素是否显示（元素是否存在）
    （3）页面元素是否显示正确（主要针对文字、图形、签章）
    （4）页面元素的外形、摆放位置（如按钮、列表框、核选框、输入框、超连接等）
    （5） 页面元素基本功能是否实现（如文字特效、动画特效、按钮、超连接）
    （6） 页面元素的容错性列表（如输入框、时间列表或日历）
    （7） 页面元素的容错性是否存在
    （8） 页面元素的容错性是否正确

    3 功能部分
    （1） 数据初始化是否执行
    （2） 数据初始化是否正确
    （3） 数据处理功能是否执行
    （4） 数据处理功能是否正确
    （5） 数据保存是否执行
    （6） 数据保存是否正确
    （7） 是否对其他功能有影响
    （8） 如果影响其他功能，系统能否作出正确的反应
    （9） 其他错误
    （10） 对模块的具体功能进行    测试时可以列出功能模块的所有功能，进行排列组合，测试所有情况
    如：某一功能模块具有最基本的增删改查功能，则需要进行以下测试
    单项功能测试（增加、修改、查询、删除）
    增加——>增加——>增加 （连续增加测试）
    增加——>删除
    增加——>删除——>增加 （新增加的内容与删除内容一致）
    增加——>修改——>删除
    修改——>修改——>修改 （连续修改测试）
    修改——>增加 （新增加的内容与修改前内容一致）
    修改——>删除
    修改——>删除——>增加 （新增加的内容与删除内容一致）
    删除——>删除——>删除 （连续删除测试）
    （11）查询功能分为两种情况，验证操作结果。
    一、打开页面时自动显示结果，则不特别强调；
    二、需要手工操作进行查询，则每次在其他功能完成后进行。
    4 提示信息
    （1） 成功、失败提示
    （2） 操作结果提示
    （3） 确认提示
    （4） 危险操作、重要操作提示
    （5） 返回页面 提示后显示的页面
    5 容错性
    注意以下几种情况
    （1） 为空、非空
    （2） 唯一性
    （3 ）字长、格式
    （4） 数字、邮政编码、金额、电话、电子邮件、ID号、密码
    （5） 日期、时间
    （6） 特殊字符 （对    数据库）英文单、双引号，&符号
    6 权限部分
    功能权限： 指定用户可以使用那些功能，不能使用那些功能
    数据权限： 指定用户可以处理那些数据，不可以处理那些数据。可
    以合并到功能测试
    操作权限： 在逻辑关系上，操作前后顺序、数据处理情况。可以合
    并到功能测试
    权限变化： 可以合并到功能测试

    （1） 功能权限是否存在
    （2 ）功能权限是否正确
    （3） 数据权限是否存在
    （4） 数据权限是否正确
    （5）操作权限是否存在
    （6） 操作权限是否正确
    （7） 引起权限变化的功能列表
    （8） 功能权限变化还是数据权限变化，或两者兼有
    （9） 权限变化是否正确

    7 键盘操作
    （1） Tab键的使用
    （2） 上下方向键的使用
    （3） Enter键的使用
    （4） 系统设定快捷键的使用（如果设置有快捷键）

    8 测试中还应注意的其他事项
    （6） 完整性：是否是一个整体，没有功能缺损
    （7） 易用性：使用是否方便
    （8） 一致性：类似的问题用类似的方法处理
    （9） 提示信息：提示信息是否完整、正确、详细
    （10） 帮助信息：是否提供帮助信息，帮助信息的表现形式（页面文字、提示信息、帮助文件），帮助信息是否正确、详细
    （11） 兼容性：包括操作系统兼容和应用    软件兼容，可能还包括硬件兼容
    （12） 可扩展性：是否由升级的余地，是否保留了接口
    （13） 稳定性：运行所需的软硬件配置，占用资源情况，出现问题时的容错性，对数据的保护
    （14） 运行速度：运行的快慢，带宽占用情况

    有几点：
    1.功能点测试：是否满足需求所要求的功能
    2.字符串长度检查: 输入超出需求所说明的字符串长度的内容, 看系统是否检查字符串长度,会不会出错.
    3.字符类型检查: 在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型,会否报错.
    4.标点符号检查: 输入内容包括各种标点符号,特别是空格,各种引号,回车键.看系统处理是否正确.
    5.中文字符处理: 在可以输入中文的系统输入中文,看会否出现乱码或出错.
    6.信息重复: 在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理.
    7.界面测试：界面的正确性、一致性、友好性、易用性。

    用户界面测试是从最终的使用者用户的角度来看软件，软件难以理解，不易使用就是软件缺陷。可以从以下几个方面重点来检查用户界面：
    1.易用性检查：确保软件易于理解，方便使用。
    2.一致性检查：
    a.注意系统页面的风格是否一致，如字的大小、颜色、字体要相同。
    b.提示信息的表达方式是否一致。
    c.按钮排列顺序是否一致。
    d.back, cancel等按钮跳转页面处理是否一致。
    e.各字段的名称，位置、长度、类型是否和设计文档要求一致，如Employee No和LoginName不一致。
    3.正确性检查：检查页面上的form, button, table, header, footer,提示信息，还有其他文字拼写，句子的语法等是否正确。
    4.友好性检查：
    a.提示信息是否友好.
    b.系统应该在用户执行错误的操作之前提出警告，提示信息.
    c.页面分辨率检查，在各种分辨率浏览系统检查系统界面友好性。
    5.合理性检查：做delete, update, add, cancel, back等操作后，查看信息回到的页面是否合理。
    6.检查本地化是否通过：英文版不应该有中文信息，英文    翻译准确，专业。
    7.页面最大化检查：测试最大化/最小化/还原时页面是否做了对应的处理。

    查看(210) 评论(0) 收藏 分享 管理

  • 设计功能和界面测试用例

    2008-09-25 14:47:44

    .1 文本框、按钮等控件测试51Testing软件测试网$bx8Efcvv

    G)r@ ctPgJ95642 1.1.1 文本框的测试51Testing软件测试网(l-VZJ q'y:O O
    51Testing软件测试网xAn+oCS
    如何对文本框进行测试51Testing软件测试网y c/l,FgIl%M
    51Testing软件测试网e\&K y X-w
    　a,输入正常的字母或数字。
    SCR5?4l+UYV95642 　b,输入已存在的文件的名称；51Testing软件测试网2E3{[#ixPq6[t[
    　c,输入超长字符。例如在“名称”框中输入超过允许边界个数的字符，假设最多255个字符，尝试输入 256个字符，检查程序能否正确处理；
    ^#B ]OUM)a{G*nV95642 　d,输入默认值，空白，空格；
    2] O^M"Xd'}r95642 　e,若只允许输入字母，尝试输入数字；反之；尝试输入字母；
    Ns8D)k,wkj] T1[95642 　f,利用复制，粘贴等操作强制输入程序不允许的输入数据；
    8T$QQ$O r&@0c[95642 　g,输入特殊字符集，例如，NUL及\n等；
    @#W2t ]Y.p!_95642 　h,输入超过文本框长度的字符或文本，检查所输入的内容是否正常显示；51Testing软件测试网6|.M,O_WG`
    　i,输入不符合格式的数据，检查程序是否正常校验，如，程序要求输入年月日格式为yy/mm/dd，实际输入yyyy/mm/dd，程序应该给出错误提示
    S@ eK7w(AG(?95642
    G7@8e!Jp l95642 在测试过程中所用到的测试方法：
    ^5tm} U["Y:{95642
    -gw7x#GG95642 　1,输入非法数据；
    c+]"[qWt|oM95642 　2,输入默认值；
    e,DsY6u"XX r2M_95642 　3,输入特殊字符集；
    W/R#A1wCl'[/\Yj95642 　4,输入使缓冲区溢出的数据；
    3nUla;A95642 　5,输入相同的文件名； 51Testing软件测试网X4NB&K\L`v
    命令按钮控件的测试
    7@G!H4B+o/~a95642 51Testing软件测试网(ANqt!U6_T"V[
    测试方法：
    KF9N*N;D-h5@-Y1Q5BD95642
    1|ck`+n0Q)D95642 　a,点击按钮正确响应操作。如，单击确定，正确执行操作；单击取消，退出窗口；
    :U!Xe/m9X.@lr5E95642 　b,对非法的输入或操作给出足够的提示说明，如，输入月工作天数为32时，单击”确定“后系统应提示:天数不能大于31；51Testing软件测试网W INSz;T)e
    　c,对可能造成数据无法恢复的操作必须给出确认信息，给用户放弃选择的机会； 51Testing软件测试网A@2[,b6_
    单选按钮控件的测试
    S p(PZNpN:p c95642
    G5t3`(b9C$mh7_'Y95642 测试方法：
    5rzhE0[d95642 51Testing软件测试网j `GT%Ri"p
    　a,一组单选按钮不能同时选中，只能选中一个。51Testing软件测试网1D;p l}2FL4|
    　b,逐一执行每个单选按钮的功能。分别选择了“男”“女”后，保存到数据库的数据应该相应的分别为“男”“女”；51Testing软件测试网R*W w{3? k eB%w
    　c,一组执行同一功能的单选按钮在初始状态时必须有一个被默认选中，不能同时为空； 51Testing软件测试网2G8DR1m-q
    up－down控件文本框的测试
    :J{ZxG,d']U95642 51Testing软件测试网ob b}h|
    测试方法：51Testing软件测试网.T9?6vj9M T$}
    51Testing软件测试网3Y6W!j$Nn'n0`
    　a,直接输入数字或用上下箭头控制，如，在“数目”中直接输入10，或者单击向上的箭头，使数目变为10；51Testing软件测试网y(G X+ZB
    　b,利用上下箭头控制数字的自动循环，如，当最多数字为253时，单击向上箭头，数目自动变为1；反之亦适用；51Testing软件测试网 \roy!`K(| E4G
    　c,直接输入超边界值，系统应该提示重新输入；
    v/q2\2~A$aJ95642 　d,输入默认值，空白。如，“插入”数目为默认值，点击“确定”；或，删除默认值，使内容为空，单击“确定”进行测试；51Testing软件测试网X+[s/Ylm@O
    　e,输入字符。此时系统应提示输入有误。
    7mK/e5V:j3w95642 组合列表框的测试
    'I)b N@_4^95642
    e S7N1E&_U8E95642 测试方法：51Testing软件测试网;|8^}6K/HnK n%O

    "s e!q4U @F95642 　a,条目内容正确，其详细条目内容可以根据需求说明确定；51Testing软件测试网Q$p:d3Wr5o:n
    　b,逐一执行列表框中每个条目的功能；
    $ip t y;LB95642 　c,检查能否向组合列表框输入数据； 51Testing软件测试网L1s8y#bz}4M~
    复选框的测试51Testing软件测试网7k+PAAOFC'V
    51Testing软件测试网 mAz*OR?m%ocQ n3H
    测试方法：
    $Q9]MW:Z|%S$N_95642
    .G~dM0u"sdhu95642 　a,多个复选框可以被同时选中；
    rW3qk\e95642 　b,多个复选框可以被部分选中；
    )D.m lRd0A9uGP95642 　c,多个复选框可以都不被选中；51Testing软件测试网+~t7Pbf4o}a
    　d,逐一执行每个复选框的功能； 51Testing软件测试网9DASQT'z l B
    列表框控件的测试51Testing软件测试网-yK4gi k td
    51Testing软件测试网(~p"v6{g3W{ B_
    测试方法：51Testing软件测试网T} k@+k!M9hY)s

    "[_n+H1z.bG95642 　a,条目内容正确；同组合列表框类似，根据需求说明书确定列表的各项内容正确，没有丢失或错误；
    iw|8}9Qz(z3Ep2|&M95642 　b,列表框的内容较多时要使用滚动条；
    .Nk JVY1?U*kH95642 　c,列表框允许多选时，要分别检查shift选中条目，按ctrl选中条目和直接用鼠标选中多项条目的情况； 51Testing软件测试网)FpXvFh+`
    滚动条控件的测试51Testing软件测试网 bh7Bh3yB q-L
    51Testing软件测试网SFA~J1uxR&y
    要注意一下几点：51Testing软件测试网 dM1f:M2zyz JD
    51Testing软件测试网JOZ$K+} XQE-f
    　a,滚动条的长度根据显示信息的长度或宽度及时变换，这样有利于用户了解显示信息的位置和百分比，如，word中浏览100页文档，浏览到50页时，滚动条位置应处于中间；
    #Y`-g-_LpN]95642 　b,拖动滚动条，检查屏幕刷新情况，并查看是否有乱码；
    H2Z1F"Au!r95642 　c,单击滚动条；
    $W2x_ G1K(L8o%k95642 　d,用滚轮控制滚动条；
    "KtG+]Ty95642 　e,滚动条的上下按钮。 51Testing软件测试网GRoEY8A
    各种控件在窗体中混和使用时的测试51Testing软件测试网^2Q9tVl\*gd@8t
    51Testing软件测试网$_"|2R1mkX
    　a,控件间的相互作用；51Testing软件测试网9|h0e-u zX
    　b,tab键的顺序，一般是从上到下，从左到右；
    5~;N/Px*hSO95642 　c,热键的使用，逐一测试；
    u-o)l*vJV c95642 　d,enter键和esc键的使用； 51Testing软件测试网Z7Q%w"q`Dg
    在测试中，应遵循由简入繁的原则，先进行单个控件功能的测试，确保实现无误后，再进行多个控件的的功能组合的测试。51Testing软件测试网?C e7}aE k
    51Testing软件测试网(I+g/V D"I1X,["q
    ps:密码输入框测试时要特别注意进行字母大写输入的测试。51Testing软件测试网4FRPY#ja0Y cr

    0Ae%H8@ Dv95642 查找替换操作
    4zo$[{nq1tG)z95642 　案例演示:打开word中的"替换"对话框51Testing软件测试网L!|2Ppdnfk
    　测试本功能有通过测试和失败测试两种情况51Testing软件测试网u'A:M1eVr
    　通过测试:
    9o)~ |!}I0I$O+e95642 51Testing软件测试网I&Y%|/[v Q
    　1,输入内容直接查找,或查找全部
    *r,O2{9D-[*q;P"a:u(H95642 　2,在组合框中寻找已经查找过的内容,再次查找并确认文档的内容正确,如,已经查找过"测试用例\",再次进入不用重新输入查找内容,直接在文档中搜寻就可以.51Testing软件测试网*@ zw*?;p0u
    51Testing软件测试网L_ JUU{
    失败测试:51Testing软件测试网G8a-y+]5}L'xq w
    　1,输入过长或过短的查询字符串.如,假设查询的字符串长度为1到255,那么输入0,1,2,256,255和254进行测试;
    0WUWzp+j@*L95642 　2,输入特殊字符集,如,在word中.^g代表图片,^代表分栏符,可以输入这类特殊字符测试;51Testing软件测试网P-`#kJ5k
    51Testing软件测试网L WK4Dp8JD(Z/I0@
    替换测试大体相同.
    D+aI C#K7x#|}OX(E i95642 　关于编辑操作窗口的功能测试的用例:
    LKxj^Z5U95642 　1,关闭查找替换窗口.不执行任何操作,直接退出;51Testing软件测试网2bx{ Xx*`H ]
    　2,附件和选项测试.假如,设定"精确搜寻","向后"搜索等附件选项等等来测试;51Testing软件测试网w_%jgd z
    　3,控件间的相互作用.如,搜寻内容为空时,按钮"搜寻全部","搜寻","全部替换","替换"都为灰色.51Testing软件测试网(pHw"pl;kF7] a7zl
    　4,热键, Tab键.回车键的使用.51Testing软件测试网1p:r8M%a~l+k
    51Testing软件测试网T9{xm],mJN$Wa[
    插入操作51Testing软件测试网z.d*b)IhBE{
    　1,插入文件51Testing软件测试网Q?!Y6MO%?ym
    　测试的情况
    {b(r_(I&y95642 　a,插入文件;
    %[#IS!t9k+E!X95642 　b,插入图像;
    9Uo?w-Q&ZM8p95642 　c,在文档中插入文档本身;51Testing软件测试网 bK ~HY!ro!Y
    　d,移除插入的源文件;51Testing软件测试网!d_UZN${9^ Jf2Wm
    　e,更换插入的源文件的内容;51Testing软件测试网'|;lzNM%tNy
    51Testing软件测试网[|+X ~h
    2,链接文件51Testing软件测试网%t RO]/F
    　测试方法:51Testing软件测试网 S:Bo.Y;kK!R"~[
    　a,插入链接文件;
    L ?3q h9y8[7K [95642 　b,在文档中链接文档本身;51Testing软件测试网*q IS"ak9uGs'wt
    　c,移除插入的源文件;51Testing软件测试网 P7sS k+l
    　d,更换插入的源文件的内容.51Testing软件测试网%AG(x*\}%u&rD!I
    51Testing软件测试网f.a _*t_,N1Wl
    3,插入对象51Testing软件测试网Kpo1f:Z:wsr
    　要测试的内容
    ,YEJ}ca1\V95642 　a,插入程序允许的对象,如,在word中插入excel工作表;51Testing软件测试网2uh m3u2V/cS
    　b,修改所插入对象的内容.插入的对象仍能正确显示;
    j3pq&T[t95642 　c,卸载生成插入对象的程序,如,在word中插入excel工作表后卸载excel,工作表仍正常使用.
    ]x @ RVy |1fb95642
    jH!tqd95642 编辑操作51Testing软件测试网{-EV vgB1KP y
    　编辑操作包括剪切,复制,粘贴操作.
    1E$U[ld:s;R7d3u95642 51Testing软件测试网0t$?8j5N2Xu H.\
    测试剪切操作的方法51Testing软件测试网b:m_^0t2WF`s
    　a,对文本,文本框,图文框进行剪切;
    #z1M2y+m%c/\95642 　b,剪切图像
    *qU(p/fuV6U R95642 　c,文本图像混合剪切
    S D NT6A4{95642 　复制操作方法与剪切类似.51Testing软件测试网!m}V'^We"z)b)_

    A'QH'WWK k95642 测试时,主要是对粘贴操作的测试,方法是:
    9b.[&y$\pM:L95642 　a,粘贴剪切的文本,文本框及图文框;
    kv(Zzjv2gj95642 　b,粘贴所剪切的图像;
    M#t*B"N*oAyA95642 　c,剪切后,在不同的程序中粘贴
    R9n{e0EB-i,MZ95642 　d,多次粘贴同一内容,如,剪切后,在程序中连续粘贴3次;51Testing软件测试网yw(g5NS h6y
    　e,利用粘贴操作强制输入程序所不允许输入的数据.51Testing软件测试网Tk5j9VJ&@!Z)d
    51Testing软件测试网0]NQ1K'D7u(E,vGv
    界面测试用例的设计方法
    5{T8Yeo {c U95642 　1,窗体
    5h\6U/~'AsmE95642 　测试窗体的方法:
    Y%mh3i R?}Ngpc95642 　a,窗体大小,大小要合适,控件布局合理;
    ^]3rDZmqT95642 　b,移动窗体.快速或慢速移动窗体,背景及窗体本身刷新必须正确;51Testing软件测试网fb v hIWP)b
    　c,缩放窗体,窗体上的控件应随窗体的大小变化而变化;
    9Z#t{kT0^$G95642 　d,显示分辨率.必须在不同的分辨率的情况下测试程序的显示是否正常;
    #M:]g/M UF95642 　进行测试时还要注意状态栏是否显示正确;工具栏的图标执行操作是否有效,是否与菜单懒中图标显示一致;错误信息内容是否正确,无错别字,且明确等等;
    2qRZ C!C ej q/m:E95642 51Testing软件测试网G_RJ G}_ [#h
    2,控件
    ND)N^ E tN-_E95642 　测试方法:
    ;Iu w:cS&SR95642 　a,窗体或控件的字体和大小要一致;
    5T)O B;D,Jq4{F k {C95642 　b,注意全角,半角混合
    oW5idV,^;Cg7HI95642 　c,无中英文混合.51Testing软件测试网R#R'W C{0d

    8d\(bMkK95642 菜单51Testing软件测试网wT&]P"XJd#|p
    51Testing软件测试网:BZkG(K)lz#A
    进行测试时要注意51Testing软件测试网K?^p]f9z];R9n
    　a,选择菜单是否可以正常工作,并与实际执行内容一致;51Testing软件测试网 s3HT)W`Z
    　b,是否有错别字:51Testing软件测试网nSZkS+C
    　c,快捷键是否重复;
    l;Jc B+d!X5a95642 　d,热键是否重复;51Testing软件测试网e _E:ap}Do
    　e,快捷键与热键操作是否有效51Testing软件测试网|"C8Y#|C/IY
    　f,是否存在中英文混合
    /c ?^z0pG#z95642 　g,菜单要与语境相关,如,不同权限的用户登陆一个应用程序,不同级别的用户可以看到不同级别的菜单并使用不同级别的功能;
    v"K`T(}!F'@+I95642 　h,鼠标右键快捷菜单51Testing软件测试网P0J hd!aM
    51Testing软件测试网,w8D$x%J|4D!}
    特殊属性
    ITa7Y9E*^4e95642 　1,安装界面应有公司介绍或产品介绍,有公司的图标51Testing软件测试网1Ob x5{i+k-A
    　2,主界面及大多数界面最好有公司图标51Testing软件测试网,k!AwQ+l0i3F(i#_y
    　3,选择"帮助"->"关于"命令,应 看见相关版权和产品信息

     

    查看(239) 评论(0) 收藏 分享 管理

  • 开始学专业英语啦~

    2008-03-11 15:21:08

                 2008年3月10                  星期二             晴

          虽然我的英语水平一般，但因工作关系，还是自学起了英语，这两周以来，收获蛮大的。看来很有成效，我会坚持学下去，为了我的测试工作做的更好，每天虽然很忙碌，但是很充实！除了英语，我还在学习各种测试工具的使用，争取自己能越用越熟练，天天有进步，真的好开心！本来要学ASP.NET，有专业老师免费教我，我都没有认真学下去，我要找对自己的方向，为自己的测试工作定个目标，一定加油！努力，再努力！

     

    查看(390) 评论(0) 收藏 分享 管理

Open Toolbar