发布新日志

  • selenium 定位元素方法

    2014-02-24 22:38:01

    # -*- coding: utf-8 -*-
    from selenium import webdriver
    from selenium.webdriver.common.by import By
    from selenium.webdriver.common.keys import Keys
    from selenium.webdriver.support.ui import Select
    from selenium.common.exceptions import NoSuchElementException
    import unittest, time, re
    import time
    import os

    class Checkbox(unittest.TestCase):
        def setUp(self):
            self.driver = webdriver.Chrome()
            self.driver.implicitly_wait(30)
            '''
            self.base_url = "F:\fanxr\Selenium\test\train\test.html"
    '''
            self.verificationErrors = []
            self.accept_next_alert = True
       
        def test_baidu(self):
            driver = self.driver
            file_path =  'file://' + os.path.abspath('checkbox.html')
            driver.get(file_path)
            inputs = driver.find_elements_by_tag_name('input')
            '''
            print len(inputs)
    #打印input的个数
            for input in inputs:
                if input.get_attribute('type') == 'checkbox':
                    input.click()
            time.sleep(2)
            inputs=driver.find_elements_by_tag_name('input')
            for input in inputs:
                if input.get_attribute('type') == 'radio':
                    input.click()
            time.sleep(2)
            for input in inputs:
                if input.get_attribute('type') == 'checkbox':
                    input.click()
    #选择复选框以后，在click（就是取消选择。）
            time.sleep(5)
            '''
            '''
            checkboxs=driver.find_elements_by_css_selector('input[type=checkbox]')
            for checkbox in checkboxs:
                checkbox.click()
            time.sleep(5)
            '''
         # 选择最后一个checkbox并click pop() 方法用于删除并返回数组的最后一个元素。
            driver.find_elements_by_css_selector('input[type=checkbox]').pop().click()
            time.sleep(2)

    ==============================================================
    #通过CSS方式定位 browser.find_element_by_css_selector("#kw").send_keys("selenium") #通过xphan方式定位

    browser.find_element_by_xpath("//input[@id='kw']").send_keys("selenium") 

    <a href="http://news.baidu.com" name="tj_news">新 闻</a>

    driver.find_element_by_css_selector("a[name=\"tj_news\"]").click()


    <a onclick="queryTab(this);" mon="col=502&pn=0" title="web" href="http://www.baidu.com/">网页</a>

    driver.find_element_by_css_selector("a[title=\"web\"]").click()


    <a class="RecycleBin xz" href="javascript.:void(0);"> 

    driver.find_element_by_css_selector("a.RecycleBin").click()


    xpath:idRelative （id相关性）

    driver.find_element_by_xpath("//div[@id='fm']/form/span/input").send_keys("selenium") #在/form/span/input 层级标签下有个div标签的id=fm的元素
    driver.find_element_by_xpath("//tr[@id='check']/td[2]").click() # id为'check' 的tr ，定闪他里面的第2个td
    xpath:position （位置） driver.find_element_by_xpath("//input").send_keys("selenium") driver.find_element_by_xpath("//tr[7]/td[2]").click() #第7个tr 里面的第2个td
    xpath: href （水平参考） driver.find_element_by_xpath("//a[contains(text(),'网页')]").click()


    xpath:link

    driver.find_element_by_xpath("//a[@href='http://www.baidu.com/']").click()

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

  • Python 学习日志

    2014-01-07 17:31:41

    读取某一个文件夹下的文件并写到一个不存在的文件中：
     
    import os
    os.mkdir("D:/2")  // 创建文件夹
    f=open("D:/2/1.txt","w")  创建文件（存在就打开， 不存在就创建）
    for filename in os.listdir("D:\Python27"): （读取文件夹下的文件名）
        print filename
        f.writelines(filename +"\n")  //写入文件中。
    f.close()
     
    =====================
    在一个文本文件中插入10个0到9 的随机数 并共插入十行
    并读取改文本文件中的内容并打印。
     
    import random
    f= open("D:/2/1.txt","w")
    for i in range( 0,10):
        for i in range(0,10): f.write(str(random.randint(0,9)))
        f.write('\n')
    f.close()
    a=open("D:/2/1.txt")
    s=a.read()
    print s

    ======================================
    在指定的文件夹中生成N多个txt文件：

    def creatfiles(x):
        i = 0
        while i < x:
         bb = "fds"+str(i)+".txt" 
         f = open("D:\\Python27\\test\\"+bb,"w")
         f.write("today is 2009-1-7\n")
         f.write("I am very happy!")
         f.close()
         i = i+1


    if __name__ == "__main__":
        m = int(input('creatfile_numbers: '))
        creatfiles(m)
     

     

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

  • 工具

    2013-06-03 11:16:51

    bitnami-redmine-2.3.1-1-windows-installer.exe
     
     
    FreeMind-Windows-Installer-1.0.0_Beta_8-max.exe
     
    bitnami-redmine-1.4.7-2-windows-installer.exe
     
     
    XMiand2002 画思维简图的。

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

  • 用户名和密码的测试方法：（转载）

    2011-02-16 15:19:10

    别小看了这个用户名密码这么简单的输入框。可测试的内容还是很多的，并且引发的问题也有很多种类。下面就说一说他的测试方法。

    一、用户注册

    只从用户名和密码角度写了几个要考虑的测试点，如果需求中明确规定了安全问题，Email，出生日期，地址，性别等等一系列的格式和字符要求，那就都要写用例测了~

    以等价类划分和边界值法来分析

    1.填写符合要求的数据注册： 用户名字和密码都为最大长度（边界值分析，取上点）

    2.填写符合要求的数据注册 ：用户名字和密码都为最小长度（边界值分析，取上点）

    3.填写符合要求的数据注册：用户名字和密码都是非最大和最小长度的数据（边界值分析，取内点）

    4.必填项分别为空注册

    5.用户名长度大于要求注册1位（边界值分析，取离点）

    6.用户名长度小于要求注册1位（边界值分析，取离点）

    7.密码长度大于要求注册1位（边界值分析，取离点）

    8.密码长度小于要求注册1位（边界值分析，取离点）

    9.用户名是不符合要求的字符注册（这个可以划分几个无效的等价类，一般写一两个就行了，如含有空格，#等，看需求是否允许吧~）

    10.密码是不符合要求的字符注册（这个可以划分几个无效的等价类，一般写一两个就行了）

    11.两次输入密码不一致（如果注册时候要输入两次密码，那么这个是必须的）

    12.重新注册存在的用户

    13.改变存在的用户的用户名和密码的大小写，来注册。（有的需求是区分大小写，有的不区分）

    14.看是否支持tap和enter键等；密码是否可以复制粘贴；密码是否以* 之类的加秘符号显示

    备注：边界值的上点、内点和离点大家应该都知道吧，呵呵，这里我就不细说了~~

    二、修改密码

    当然具体情况具体分析哈~不能一概而论~

    实际测试中可能只用到其中几条而已，比如银行卡密码的修改，就不用考虑英文和非法字符，更不用考虑那些ＴＡＰ之类的快捷键。而有的需要根据需求具体分析了，比如连续出错多少次出现的提示，和一些软件修改密码要求一定时间内有一定的修改次数限制等等。

    1.不输入旧密码，直接改密码

    2.输入错误旧密码

    3.不输入确认新密码

    4.不输入新密码

    5.新密码和确认新密码不一致

    6.新密码中有空格

    7.新密码为空

    8.新密码为符合要求的最多字符

    9.新密码为符合要求的最少字符

    10.新密码为符合要求的非最多和最少字符

    11.新密码为最多字符-1

    12.新密码为最少字符+1

    13.新密码为最多字符+1

    14.新密码为最少字符-1

    15.新密码为非允许字符（如有的密码要求必须是英文和数字组成，那么要试汉字和符号等）

    16.看是否支持tap和enter键等；密码是否可以复制粘贴；密码是否以* 之类的加秘符号

    17.看密码是否区分大小写，新密码中英文小写，确认密码中英文大写

    18.新密码与旧密码一样能否修改成功

    另外一些其他的想法如下：

    1要测试所有规约中约定可以输入的特殊字符，字母，和数字，要求都可以正常输入、显示正常和添加成功

    2关注规约中的各种限制，比如长度，大否支持大小写。

    3考虑各种特殊情况，比如添加同名用户，系统是否正确校验给出提示信息，管理员帐户是否可以删除，因为有些系统管理员拥有最大权限，一旦删除管理员帐户，就不能在前台添加，这给最终用户会带来很多麻烦。比较特殊的是，当用户名中包括了特殊字符，那么对这类用户名的添加同名，修改，删除，系统是否能够正确实现，我就遇到了一个系统，添加同名用户时，如果以前的用户名没有特殊字符，系统可以给出提示信息，如果以前的用户名包含特殊字符，就不校验在插入数据库的时候报错。后来查到原因了，原来是在java中拼SQL语句的时候，因为有"_"，所以就调用了一个方法在“_”，前面加了一个转义字符，后来发现不该调用这个方法。所以去掉就好了。所以对待输入框中的特殊字符要多关注。


    4数值上的长度 之类的，包括出错信息是否合理
    5特殊字符：比如。 / ' " \ </html> 这些是否会造成系统崩溃

    6注入式bug：比如密码输入个or 1=1

    7登录后是否会用明文传递参数

    8访问控制（不知道这个算不算）：登录后保存里面的链接，关了浏览器直接复制链接看能不能访问。

    查看(877) 评论(4) 收藏 分享 管理

  • 测试方法大全（转载）

    2011-02-16 15:17:47

    本文转自:http://www.51testing.com/html/95/n-148195.html

    　　β测试_Beta测试

    　　β测试，英文是Betatesting。又称Beta测试，用户验收测试（UAT）。

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

    　　当开发和测试根本完成时所做的测试，而最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其他人员员完成，不能由程序员或测试员完成。

    　　α测试_Alpha测试

    　　α测试，英文是Alpha testing。又称Alpha测试.

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

    　　在系统开发接近完成时对应用系统的测试;测试后，仍然会有少量的设计变更。这种测试一般由最终用户或其他人员来完成，不能由程序员或测试员完成。

    　　可移植性测试

    　　可移植性测试，英文是Portability testing。又称兼容性测试。

    　　可移植性测试是指测试软件是否可以被成功移植到指定的硬件或软件平台上。

    　　用户界面测试-UI测试

    　　用户界面测试，英文是User interface testing。又称UI测试。

    　　用户界面，英文是User interface。是指软件中的可见外观及其底层与用户交互的部分（菜单、对话框、窗口和其它控件）。

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

    　　用户界面测试用户分析软件用户界面的设计是否合乎用户期望或要求。它常常包括菜单，对话框及对话框上所有按钮，文字，出错提示，帮助信息 (Menu 和Help content)等方面的测试。比如，测试Microsoft Excel中插入符号功能所用的对话框的大小，所有按钮是否对齐，字符串字体大小，出错信息内容和字体大小，工具栏位置/图标等等。

    　　冒烟测试

    　　冒烟测试，英文是Smoke testing。

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

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

    　　随机测试

    　　随机测试，英文是Ad hoc testing。

    　　随机测试没有书面测试用例、记录期望结果、检查列表、脚本或指令的测试。主要是根据测试者的经验对软件进行功能和性能抽查。随机测试是根据测试说明书执行用例测试的重要补充手段，是保证测试覆盖完整性的有效方式和过程。

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

    　　本地化测试

    　　本地化测试，英文是Localization testing。

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

    　　本地化能力测试

    　　本地化能力测试，英文是Localizability testing。

    　　本地化能力测试是指不需要重新设计或修改代码，将程序的用户界面翻译成任何目标语言的能力。为了降低本地化能力测试的成本，提高测试效率，本地化能力侧是通常在软件的伪本地化版本上进行。

    　　本地化能力测试中发现的典型错误包括：字符的硬编码（即软件中需要本地化的字符写在了代码内部），对需要本地化的字符长度设置了国定值，在软件运行时以控件位置定位，图标和位图中包含了需要本地化的文本，软件的用户界面与文档术语不一致等。

    　　国际化测试

    　　国际化测试，英文是International testing。又称国际化支持测试。

    　　国际化测试的目的是测试软件的国际化支持能力，发现软件的国际化的潜在问题，保证软件在世界不同区域都能正常运行。国际化测试使用每种可能的国际输入类型，针对任何区域性或区域设置检查产品的功能是否正常，软件国际化测试的重点在于执行国际字符串的输入/输出功能。国际化测试数据必须包含东亚语言、德语、复杂脚本字符和英语（可选）的混合字符。

    　　国际化支持测试是指验证软件程序在不同国家或区域的平台上也能够如预期的那样运行，而且还可以按照原设计尊重和支持使用当地常用的日期，字体，文字表示，特殊格式等等。比如，用英文版的 Windows XP 和 Microsoft Word 能否展示阿拉伯字符串?用阿拉伯版的 Windows XP 和 阿拉伯版的Microsoft Word 能否展示阿拉伯字符串?又比如，日文版的Microsoft Excel对话框是否显示正确翻译的日语?一旦来说执行国际化支持测试的测试人员往往需要基本上了解这些国家或地区的语言要求和期望行为是什么。

    　　安装测试

    　　安装测试，英文是Installing testing。

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

    　　白盒测试-结构测试-逻辑驱动测试

    　　白盒测试，英文是White Box Testing。又称结构测试或者逻辑驱动测试。

    　　白盒测试是把测试对象看作一个打开的盒子。利用白盒测试法进行动态测试时，需要测试软件产品的内部结构和处理过程，不需测试软件产品的功能。

    　　白盒测试法的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试。其中逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。

    　　白盒测试是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。

    　　白盒测试常用工具有：Jtest、VcSmith、Jcontract、C++Test、CodeWizard、logiscope。

    　　黑盒测试-功能测试-数据驱动测试

    　　黑盒测试，英文是Black Box Testing。又称功能测试或者数据驱动测试。

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

    　　软件测试人员以用户的角度，通过各种输入和观察软件的各种输出结果来发现软件存在的缺陷，而不关心程序具体如何实现的一种软件测试方法。

    　　黑盒测试常用工具有：AutoRunner、winrunner、loadrunner。

    　　自动化测试

    　　自动化测试，英文是Automated Testing。

    　　使用自动化测试工具来进行测试，这类测试一般不需要人干预，通常在GUI、性能等测试和功能测试中用得较多。通过录制测试脚本，然后执行这个测试脚本来实现测试过程的自动化。国内领先的自动化测试服务提供商是泽众软件。自动化测试工具有AutoRunner和TAR等。

    　　回归测试

    　　回归测试，英文是Regression testing。

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

    　　根据修复好了的缺陷再重新进行测试。回归测试的目的在于验证以前出现过但已经修复好的缺陷不再重新出现。一般指对某已知修正的缺陷再次围绕它原来出现时的步骤重新测试。通常确定所需的再测试的范围时是比较困难的，特别当临近产品发布日期时。因为为了修正某缺陷时必需更改源代码，因而就有可能影响这部分源代码所控制的功能。所以在验证修好的缺陷时不仅要服从缺陷原来出现时的步骤重新测试，而且还要测试有可能受影响的所有功能。因此应当鼓励对所有回归测试用例进行自动化测试。

    　　验收测试

    　　验收测试，英文是Acceptance testing。

    　　验收测试是指系统开发生命周期方法论的一个阶段，这时相关的用户或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。

    　　验收测试一般有三种策略：正式验收、非正式验收活Alpha 测试、Beta 测试。

    　　动态测试

    　　动态测试，英文是Moment Testing。

    　　动态测试是指通过运行软件来检验软件的动态行为和运行结果的正确性。

    　　根据动态测试在软件开发过程中所处的阶段和作用，动态测试可分为如下几个步骤：

    　　1、单元测试

    　　2、集成测试

    　　3、系统测试

    　　4、验收测试

    　　5、回归测试

    　　探索测试

    　　探索测试，英文是Exploratory Testing。

    　　探索测试是指通常用于没有产品说明书的测试，这需要把软件当作产品说明书来看待，分步骤逐项探索软件特性，记录软件执行情况，详细描述功能，综合利用静态和动态技术来进行测试。探索测试人员只靠智能、洞察力和经验来对bug的位置进行判断,所以探索测试又被称为自由形式测试。

    　　单元测试

    　　单元测试，英文是Unit Testing。

    　　单元测试是最微小规模的测试;以测试某个功能或代码块。典型地由程序员而非测试员来做，因为它需要知道内部程序设计和编码的细节知识。这个工作不容易做好，除非应用系统有一个设计很好的体系结构; 还可能需要开发测试驱动器模块或测试套具。

    　　集成测试

    　　集成测试，英文是Integration Testing。

    　　集成测试是指一个应用系统的各个部件的联合测试，以决定他们能否在一起共同工作并没有冲突。部件可以是代码块、独立的应用、网络上的客户端或服务器端程序。这种类型的测试尤其与客户服务器和分布式系统有关。一般集成测试以前，单元测试需要完成。

    　　集成测试是单元测试的逻辑扩展。它的最简单的形式是：两个已经测试过的单元组合成一个组件，并且测试它们之间的接口。从这一层意义上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合成程序的更大部分。方法是测试片段的组合，并最终扩展进程，将您的模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试。此外，如果程序由多个进程组成，应该成对测试它们，而不是同时测试所有进程。

    　　集成测试识别组合单元时出现的问题。通过使用要求在组合单元前测试每个单元，并确保每个单元的生存能力的测试计划，可以知道在组合单元时所发现的任何错误很可能与单元之间的接口有关。这种方法将可能发生的情况数量减少到更简单的分析级别

    　　系统测试

    　　系统测试，英文是System Testing。

    　　系统测试是基于系统整体需求说明书的黑盒类测试，应覆盖系统所有联合的部件。系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不相符合或与之矛盾的地方。

    　　系统测试的对象不仅仅包括需要测试的产品系统的软件，还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。因此，必须将系统中的软件与各种依赖的资源结合起来，在系统实际运行环境下来进行测试。

    　　端到端测试

    　　端到端测试，英文是End to End Testing。

    　　端到端测试类似于系统测试，测试级的“宏大”的端点，涉及整个应用系统环境在一个现实世界使用时的模拟情形的所有测试。例如与数据库对话，用网络通讯，或与外部硬件、应用系统或适当的系统对话。端到端架构测试包含所有访问点的功能测试及性能测试。端到端架构测试实质上是一种"灰盒"测试，一种集合了白盒测试和黑盒测试的优点的测试方法。

    　　健全测试

    　　健全测试，英文是Sanity testing。

    　　健全测试是指一个初始化的测试工作，以决定一个新的软件版本测试是否足以执行下一步大的测试努力。例如，如果一个新版软件每5分钟与系统冲突，使系统陷于泥潭，说明该软件不够“健全”，目前不具备进一步测试的条件。

    　　衰竭测试

    　　衰竭测试，英文是Failure Testing。

    　　衰竭测试是指软件或环境的修复或更正后的“再测试”。可能很难确定需要多少遍再次测试。尤其在接近开发周期结束时。自动测试工具对这类测试尤其有用。

    　　接受测试

    　　接受测试，英文是Accept Testing。

    　　接受测试是基于客户或最终用户的规格书的最终测试，或基于用户一段时间的使用后，看软件是否满足客户要求。一般从功能、用户界面、性能、业务关联性进行测试。

    　　负载测试

    　　负载测试，英文是Load testing。

    　　负载测试是测试一个应用在重负荷下的表现。例如测试一个 Web 站点在大量的负荷下，何时系统的响应会退化或失败，以发现设计上的错误或验证系统的负载能力。在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。

    　　负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其他与时间相关的方面。

    　　强迫测试

    　　强迫测试，英文是Force Testing。

    　　强迫测试是在交替进行负荷和性能测试时常用的术语。也用于描述象在异乎寻常的重载下的系统功能测试之类的测试，如某个动作或输入大量的重复，大量数据的输入，对一个数据库系统大量的复杂查询等。

    　　压力测试

    　　压力测试，英文是Stress Testing。和负载测试差不多。

    　　压力测试是一种基本的质量保证行为，它是每个重要软件测试工作的一部分。压力测试的基本思路很简单：不是在常规条件下运行手动或自动测试，而是在计算机数量较少或系统资源匮乏的条件下运行测试。通常要进行压力测试的资源包括内部内存、CPU 可用性、磁盘空间和网络带宽等。一般用并发来做压力测试。

    　　性能测试

    　　性能测试，英文是Performance Testing。

    　　性能测试是在交替进行负荷和强迫测试时常用的术语。理想的“性能测试”(和其他类型的测试)应在需求文档或质量保证、测试计划中定义。性能测试一般包括负载测试和压力测试。

    　　通常验证软件的性能在正常环境和系统条件下重复使用是否还能满足性能指标。或者执行同样任务时新版本不比旧版本慢。一般还检查系统记忆容量在运行程序时会不会流失(memory leak)。比如，验证程序保存一个巨大的文件新版本不比旧版本慢。

    　　可用性测试

    　　可用性测试，英文是Practical Usability Testing。

    　　可用性测试是对“用户友好性”的测试。显然这是主观的，且将取决于目标最终用户或客户。用户面谈、调查、用户对话的录象和其他一些技术都可使用。程序员和测试员通常都不宜作可用性测试员。

    　　卸载测试

    　　卸载测试，英文是Uninstall Testing。

    　　卸载测试是对软件的全部、部分或升级卸载处理过程的测试。主要是测试软件能否卸载，卸载是否干净，对系统有无更改，在系统中的残留与后来的生成文件如何处理等。还有原来更改的系统值是否修改回去

    　　恢复测试

    　　恢复测试，英文是Recovery testing。

    　　恢复测试是测试一个系统从如下灾难中能否很好地恢复，如遇到系统崩溃、硬件损坏或其他灾难性问题。恢复测试指通过人为的让软件（或者硬件）出现故障来检测系统是否能正确的恢复，通常关注恢复所需的时间以及恢复的程度。

    　　恢复测试主要检查系统的容错能力。当系统出错时，能否在指定时间间隔内修正错误并重新启动系统。恢复测试首先要采用各种办法强迫系统失败，然后验证系统是否能尽快恢复。对于自动恢复需验证重新初始化（reinitialization）、检查点(checkpointing mechanisms)、数据恢复(data recovery)和重新启动 (restart)等机制的正确性；对于人工干预的恢复系统，还需估测平均修复时间，确定其是否在可接受的范围内。

    　　安全测试

    　　安全测试，英文是Security Testing。

    　　安全测试是测试系统在防止非授权的内部或外部用户的访问或故意破坏等情况时怎么样。这可能需要复杂的测试技术。安全测试检查系统对非法侵入的防范能力。安全测试期间，测试人员假扮非法入侵者，采用各种办法试图突破防线。例如：

    　　①想方设法截取或破译口令；

    　　②专门定做软件破坏系统的保护机制；

    　　③故意导致系统失败，企图趁恢复之机非法进入；

    　　④试图通过浏览非保密数据，推导所需信息，等等。理论上讲，只要有足够的时间和资源，没有不可进入的系统。因此系统安全设计的准则是，使非法侵入的代价超过被保护信息的价值。此时非法侵入者已无利可图。

    　　兼容性测试

    　　兼容测试，英文是Compatibility Testing。

    　　兼容测试是测试软件在一个特定的硬件/软件/操作系统/网络等环境下的性能如何。向上兼容向下兼容，软件兼容硬件兼容。软件的兼容性有很多需要考虑的地方。

    　　比较测试

    　　比较测试，英文是Compare Testing。

    　　比较测试是指与竞争伙伴的产品的比较测试，如软件的弱点、优点或实力。来取长补短，以增强产品的竞争力。

    　　可接受性测试

    　　可接受性测试，英文是Acceptability Testing。

    　　可接受性测试是在把测试的版本交付测试部门大范围测试以前进行的对最基本功能的简单测试。因为在把测试的版本交付测试部门大范围测试以前应该先验证该版本对于所测试的功能基本上比较稳定。必须满足一些最低要求。比如不会很容易程序就挂起或崩溃。如果一个新版本没通过可测试性的验证，就应该阻拦测试部门花时间在该测试版本上测试。同时还要找到造成该版本不稳定的主要缺陷并督促尽快加以修正

    　　边界条件测试

    　　边界条件测试，英文是Boudary Testing。又称边界值测试。

    　　一种黑盒测试方法，适度等价类分析方法的一种补充,由长期的测试工作经验得知，大量的错误是发生在输入或输出的边界上。因此针对各种边界情况设计测试用例，可以查出更多的错误。

    　　边界条件测试是环绕边界值的测试。通常意味着测试软件各功能是否能正确处理最大值，最小值或者所设计软件能够处理的最长的字符串等等。

    　　强力测试

    　　强力测试，英文是Mightiness Testing。

    　　强力测试通常验证软件的性能在各种极端的环境和系统条件下是否还能正常工作。或者说是验证软件的性能在各种极端环境和系统条件下的承受能力。比如，在最低的硬盘驱动器空间或系统记忆容量条件下，验证程序重复执行打开和保存一个巨大的文件1000次后也不会崩溃或死机。

    　　装配/安装/配置测试

    　　装配/安装/配置测试是验证软件程序在不同厂家的硬件上，所支持的不同语言的新旧版本平台上，和不同方式安装的软件都能够如预期的那样正确运行。比如，把英文版的 Microsoft Office 2003安装在韩文版 的Windows Me 上，再验证所有功能都正常运行。

    　　静态测试

    　　静态测试，英文是Static Testing。

    　　静态测试指测试不运行的部分，例如测试产品说明书，对此进行检查和审阅.。静态方法是指不运行被测程序本身，仅通过分析或检查源程序的文法、结构、过程、接口等来检查程序的正确性。静态方法通过程序静态特性的分析，找出欠缺和可疑之处，例如不匹配的参数、不适当的循环嵌套和分支嵌套、不允许的递归、未使用过的变量、空指针的引用和可疑的计算等。静态测试结果可用于进一步的查错，并为测试用例选取提供指导。

    　　静态测试常用工具有：Logiscope、PRQA；

    　　隐藏数据测试

    　　隐藏数据测试在软件验收和确认阶段是十分必要和重要的一部分。程序的质量不仅仅通过用户界面的可视化数据来验证，而且必须包括遍历系统的所有数据。

    　　假设一个应用程序要求用户两条信息-----用户名和密码来创建帐户。这个用户输入这两条数据后保存。最后，一个确认窗口将通过数据库中找到这条数据来显示用户名和密码给用户。为了验证所有的数据保存是否正确，一个QA测试人员会在这个确认窗口简单的查看下用户名和密码。如果他们成功了？假设数据库记录了第三条信息----创建日期，它可能不会出现在确认窗口，而只在存档中才出现。如果创建日期保留的不正确，而QA测试人员只验证屏幕上的数据，那么这个问题就不可能被发现。创建日期可能就是一个bug，由于一个用户帐户保存了一个错误的日期到数据库中，这个问题也不可能会被引起注意，因为它被用户界面所隐藏。这只是一个简单的例子，但是它却演化出了一点：隐藏数据测试的重要性。


    查看(256) 评论(2) 收藏 分享 管理

  • Web 测试技巧

    2011-01-21 08:42:06

    3、添加、修改功能

    （1）是否支持tab键

    （2）是否支持enter键

    （3）不符合要求的地方是否有错误提示

    （4）保存后，是否也插入到数据库中？

    （5）字段唯一的，是否可以重复添加

    （6）对编辑页列表中的每个编辑项进行修改，点击保存，是否保存成功？

    （7）对于必填项，修改为空、空格或其他特殊符号，是否可以编辑成功

    （8）在输入框中，直接回车

    （9）是否能够连续添加

    （10）在编辑的时候，要注意编辑项的长度限制，有时，添加时有长度限制，但编辑时却没有（添加和修改规则是否一致）

    （11）添加时，字段是唯一的，不允许重复，但有时，编辑时，却可以修改为相同字段（相同字段包括是否区分大小写以及在输入内容的前后输入空格）

    （12）添加含有特殊符号或空格的内容

    （13）对于有图片上传功能的编辑框，对于没有上传的图片，查看编辑页面时，是否显示默认图片，如果上传了图片，是否显示为上传图片？

     

    4、删除功能

    （1）输入正确数据前加空格，看是否能正确删除？

    （2）是否支持enter键

    （3）是否能连续删除多个产品？当只有一条数据时，能否成功删除？

     

     

    （4）删除一条数据后，能否再添加相同的数据？

    （5）当提供能一次删除多条信息的功能时，注意，删除的数据是否正确？

    （6）不选择任何信息，直接点击删除按钮，看有什么错误提示？

    （7）删除某条信息时，应该有错误提示信息

     

    5、注册、登录模块

    （1）注册成功，但登录失败：注册时，密码设置为一些特殊符号，但登录时，失败

    （2）注册时，连续点击提交按钮

    （3）注册成功后，页面应该以登录状态跳转到首页

    （3）登录时，没区分大小写，注册时，是小写字母，但登录时，用大写字母也能登录进去

    （4）登录时，当页面刷新或重新输入新数据时，验证码是否也随之更新

    （5）对密码的修改，当把密码修改为很长，或含有特殊符号时，能够修改成功，但却不能成功登录。

     

    6、上传图片测试

     （1）文件类型正确，文件大小合适

    （2）文件类型正确，文件大小不合适

    （3）文件类型错误，文件大小合适

    （4）文件类型和大小都合适，上传一个正在使用中的图片

    （5）文件类型和大小合适，手动输入一个存在的图片地址来上传

    （6）文件类型和大小合适，手动输入一个不存在的图片地址上传

    （7）文件类型和大小都合适，手动输入图片名称来上传

     

    7、返回键检查

    （1）一条已经成功提交的记录，返回后再提交，看系统是否做了处理

    （2）检查多次使用返回键的情况，在有返回键的地方，返回到原来页面重复多次，看是否会出错

    8、回车键检查

    在输入结束后，直接按回车键，看系统处理如何，是否会报错

    9、刷新键检查

    在web系统中，使用浏览器的刷新键，看系统处理如何，是否会报错

    10、直接URL链接检查

    在web系统中，直接输入各功能页面的URL地址，看系统如何处理

    11、其他

    （1）在测试时，有与网络有关的步骤必须考虑到断网的情况

    （2）每个页面都有相应的页面title

    （3）在测试的时候要尽量考虑在页面出现滚动条时（滚动条上下滚动下），页面显示是否正常

    （4）URL不区分大小写

     

    12、测试中，并发情况的考虑

    总结了以下两种情况：

    （1）某个字段是唯一的，当多个用户并发点击产生该字段时，检查系统是怎么处理的

    （2）对于电子商务网站，当两个或多个用户并发购买量总和大于产品库存量时，能否购买成功

    二、界面和易用性测试

    1、界面测试，主要测试网站的界面是否和设计一致，是否有错别字，页面布局是否合理，格式是否正确，是否有相应的错误提示信息等。

    2、易用性测试，主要是考察所开发出的功能是否人性化，是否易用，是否符合大多数用户的使用习惯等。

    3、对Tab和Enter键的测试。

    三、兼容性测试

    兼容性测试不只是指界面在不同操作系统或浏览器下的兼容，有些功能方面的测试，也要考虑到兼容性，比如涉及到ajax 、jquery、javascript等技术的，都要考虑到不同浏览器下的兼容性问题。

    四、链接测试

    主要是保证链接的可用性和正确性，它也是网站测试中比较重要的一个方面。

    五、业务流程测试

    业务流程，一般会涉及到多个模块的数据，所以在对业务流程测试时，首先要保证单个模块功能的正确性，其次就要对各个模块间传递的数据进行测试，这往往是容易出现问题的地方，测试时一定要设计不同的数据进行测试。

    六、安全性测试

    （1）SQL注入

    （2）XSS 跨网站脚本攻击：程序或数据库没有对一些特殊字符进行过滤或处理，导致用户

    所输入的一些破坏性的脚本语句能够直接写进数据库中，浏览器会直接执行这些脚本语句，破坏网站的正常显示，或网站用户的信息被盗,构造脚本语句时，要保证脚本的完整性。

    document.write("abc")

    <script>alter("abc")</script>

    （3）URL地址后面随便输入一些符号

    (4) 验证码更新问题

     

    以上就是对Web测试的一个总结，相信一定还存在某些的遗漏，欢迎大家指正、补充。

     

     

    -------------------

     

    看了别人的东西后自己的终结：

     

    1. 在购物网站中如果就剩一个商品了 然后多个人同时去点击购买的时候会怎么处理。

     

    2. 搜索功能

    （1）比较长的名称是否能查到？

    （2）空格 或空

    （3）名称中含有特殊字符，如：' $ % & *以及空格等

    （4）关键词前面或后面有空格

    （5）如果支持模糊查询，搜索名称中任意一个字符是否能搜索到

    （6）输入系统中不存在与之匹配的条件

    （7）两个查询条件是否为2选1，来回选择是否出现页面错误

    （8）输入脚本语言,如：<script>alter(“abc”)</script>等

     

    3. 添加、修改功能

    （1）是否支持tab键

     

    4. 安全测试：

     

    在输入框中输入 >'><script>alert(“XSS”)</script>后，竟然能执行，记录下来.......

     

     

    ============

     

     

    以下总结中，输入一些特殊符号进行查询，是我没有想到的：

    查询输入

    　　（1）分别对单条件进行精确查询

    　　（2）输入长度的检验，输入允许的最长值进行查询，是否支持

    　　（3）两个查询条件是否为2选1，来回选择是否出现页面错误

    　　（4）输入字符

    　　（5）输入特殊字符

    　　（6）输入数字

    　　（7）输入汉字

    　　（8）输入关系表达式 与、或、异或、非、等于

    　　（9）输入空格

    　　（10）条件中含有空格

    　　（11）输入超长字符

    　　（12）输入全角字符

    　　（13）输入单引号

    　　（14）输入单引号引起来的数据

    　　（15）输入双引号

    　　（16）输入双引号引起来的数据

    　　（17）如果支持模糊查询，输入部分查询条件

    　　（18）输入系统中不存在与之匹配的条件

    　　查询结果检查

    　　（1）查询结果按什么顺利排序

    　　（2）查询结果是否根据字段显示排序功能

    　　（3）查询结果是否有分页，如果有，每页最多包含多少记录

    　　（4）查询结果是否匹配

    　　（5）查询结果是否与数据库一致

    　　（6）查询结果是精确查询还是模糊查询

    　　UI验证

    　　（1）文字显示是否正确

    　　（2）页面是否有错别字

    　　（3）输入框大小、文字大小是否合适

    　　（4）页面是否美观

    　　（5）查询结果字段显示是否与需求一致

    　　性能方面

    　　（1）查询处理时间是否能接受

    　　（2）数据库中存在大数据量数据时，查询时间是否能接受

    　　（3）当多个用户同时查询时，输入相同或不同的查询条件系统响应是否及时

    以下是我自己总结的：

    对于查询功能，同样可以从以下几个方面来进行用例的设计：

    1、功能方面考虑：应用边界值和等价类划分法进行用例的设计

    边界值：输入最大长度的文本，能否搜出来？输入空格或空，能否搜索出来？

    等价类：要考虑到一些特殊符号的输入查询。

    2、易用性方面

    3、界面方面

    4、安全角度：比如输入一些脚本语言，看是否执行，主要是防XSS攻击问题

    5、性能角度：查询效率、并发、响应时间问题的考虑

     

    ==========================

     

    网页安全缺陷

    　　现在网站开发已经注意到：登陆网站进入其内部网页后，直接拷贝网址，然后粘贴到另一IE窗口输入，可以绕过登陆直接访问。也许商业网站很关注这个问题，但是很多行业软件却很容易忽略。

    　　网页安全缺陷还可能存在于IE弹出的子窗口。有些设计不严格的软件，在主页面关闭的时候子页面还可以运行，这是一个明显的漏洞，而且还大大增加了错误发生的几率。
    ================================

     

    判断顺序/逻辑缺陷

    　　对界面进行多个输入判断的时候，非常容易出现这种问题。例如判断年月顺序，判断长度，判断非空等。假如操作员仅仅满足单个条件，保存不能成功;而按界面从上之下顺序一一满足条件之后，保存是没有问题的。但是，改变一下输入的次序，校验失效。例如，一一满足条件之后，不保存，倒过来将上面的输入改成非法输入，然后保存，结果居然也能成功，这是因为原先的判断由于发生过，或者根据语句顺序只检查最后一个判断，所以没有报错。这种错误尤其在Java scrīpt脚本的页面中要注意。能够保存不能保证数据正确，有可能引起系统崩溃或者后续数据错误。所以，在测试的时候，不要按照正常的顺序输入，而是要打乱步骤，看看代码是否强健，是否在判断逻辑上没有错误。良好的代码应该经得起折腾，至少保存时会再此全部进行判断，而不只是简简单单走到判断的最后一行。

     

    ==============

     

    调试语句和冗余信息

    　　维护项目和升级改造的推广系统最容易潜伏这类缺陷。典型表现在没有删除或者屏蔽调试语句。弹出一个界面不友好的提示信息，会使不明真相的用户产生误以为系统发生了严重故障，从而引起对软件的不信任感。页面中某个角落存在当前客户不需要的冗余按钮和功能也是一种缺陷。多余的功能会使用户以为是额外附加部分而去使用，其结果可想而知;而多余的按钮会误导好奇心强的用户操作，产生不必要的错误。

    　　同样值得关注的还有参数设置，由于没有实际数据，开发人员在调试或者单元测试的时候，习惯性的进行自我设定而忘了删除，软件测试人员可能会忽略掉了这部分测试，也可能导致在客户现场发生错误而影响系统发布和验收。

    ===========================================================

    不可重现的故障

    　　新参加软件测试的人员或者新来的开发人员总是要问，不可重现的缺陷是否需要记录，有必要吗?回答是肯定的。测试必须如实的记录发生的问题，也许不能重现，或者使非软件系统本身问题，但是，可能这些偶然性背后是有规律的，不记录这些，就不可能发现这些规律。

    ===============================================================
    多节点的逆向流转缺陷

    　　当前软件不少喜欢使用工作流来驱动。工作流的问题，就是可能出现多个流向分支。测试容易忽略的部分，就是工作流多节点的逆向流转。例如，通过不通过涉及两个分支，但是流程逆转的时候，有可能不是回到上一节点而是平级的另一个节点去了。软件测试要格外注意这类用例的设计。另外，有些时候默认分支在向前的时候是有默认值的，例如默认通过，那么保存的时候要提示用户是否通过，否则可能由于操作疲劳而走错了节点，引起回退。

    ===============================================================

    输入框缺陷

    　　试过往输入框粘贴数据而不是直接输入吗?可能这里会出现问题。按Ctrl+V的时候，输入框会根据长度大小自动截断输入长度。但是用鼠标，截断可能会失效。有一次测试人员就是用这种方法把一篇Word文档输入进去了，保存的时候，数据库崩溃。有些网站登陆的口令****可以拷贝下来的，只要放在剪贴板里面马上明文显示。（在以后的测试中需要注意的）

    ================================================================

     





     

    查看(3572) 评论(9) 收藏 分享 管理

  • Web 安全测试： SQL注入——学习

    2011-01-20 10:07:12

    http://wenku.baidu.com/view/a7141087bceb19e8b8f6bac6.html
    http://sec.chinabyte.com/230/8863730_2.shtml
    http://www.ltesting.net/html/89/92689-166810.html

    后来找了很多有关这方面的东西，于是概括一下，主要就是测试下面那些内容了(一些文绉绉的理论就不讲啦，我只是总结测试动作)：

    一、没有进行xss过滤的情况:

    a、url中的所有参数值用  '"></script><script>alert("hello,my girl!")</script> 代替测试:

    现象：跳出“hello，my girl!”提示框；

    b、text框输入 '"></script><script>alert("hello,my girl!")</script>，点击提交：

    现象：没有正常写入数据库；或查看阅览页面或者从数据库显示时，没有被转义；

    c、副文本编辑器输入<img nerror = "alert(123)" src=http://xxx.com>;

    现象：没有正常写入数据库；查看阅览页面或从数据库显示时，出现js错误或者排版出现问题；

    d、在数据库字段中写入'"></script><script>alert("hello,my girl!")</script>，查看页面显示：

    现象：跳出alert；或者页面出现js问题等；查看源代码时，没有进行转义；

    注意点：

    1、很多时候，html代码的<title >和<meta  >中的参数会显示数据库的产品名呀，或者其他有可能显示乱码的参数，所以这种地方也需要注意，以'"/></script><script>alert("hello,my girl!")</script>为例，就会跳出alert值，或者显示</script><script>alert("hello,my girl!")</script>不应该显示的值，因为被",或者/>拦截了。

    2、有些html链接，如果url是×××.产品名.html的时候，如果产品名或者其他参数有可能会是乱码的时候，它会把前面的一些单引号或者双引号先优先使用了，以'"/></script><script>alert("hello,my girl!")</script>为例，url = "×××.'"/></script><script>alert("hello,my girl!")</script>"，这样的情况的话，页面就会显示/></script><script>alert("hello,my girl!")</script>"这样的不应该显示的值。

    3、如果你的网站有搜索框，那就用包含这样的值的产品名进行搜索，有可能搜索不出来，有可能是页面跳出alert值，或者页面出现了不该出现的代码行等。

    4、主要点就是输入框，显示，链接，url输入，搜索等。

    二、关于crsf：

    1、搜索在所有我数据提交的地方，是否都加了token值；

    2、修改数据提交出的crsf，再提交，是否能正常提交，是否提示数据超时；

    3、每个不同的用户登录后，token值是否都是新值。

    注意点：

    a、虽然加token貌似看起来不难，看到有什么提交按钮就加上token就好了，所以很多时候开发会忘记软更新的时候加上token。比如说，删除这个动作是每条数据产生的时候，跟在数据后面的url链接。我在测试这个的时候，对应的开发就忘记了所有软更新的token添加。所以这个地方需要特别注意；

    b、还有一点是，每个用户登录后的token是不一致的。比如说a用户这一次登录后token值是1111，b用户这一次登录后2222.但登录后，不管什么操作，token值就是一致了。意思是比如a用户产生的token值是1111，那这个值将伴随他直到他下一次重新登录。

    这次我测试的部分只有这两个部分，关于sql注入等，还没有涉及，下次有机会整理。

    另一个就是在URL最后随意输入一些字符或数字，结果，新闻模块那出现了问题，暴露了网站的一些信息，又一个bug，高兴下。。。。。。。

     

        下面把今天看到的有关sql注入方面的知识整理如下：

     

        SQL 注入是一种攻击方式，在这种攻击方式中，恶意代码被插入到字符串中，然后将该字符串传递到 SQL Server 的实例以进行分析和执行。任何构成 SQL 语句的过程都应进行注入漏洞检查，因为 SQL Server 将执行其接收到的所有语法有效的查询。一个有经验的、坚定的攻击者甚至可以操作参数化数据。

     

        SQL 注入的主要形式包括直接将代码插入到与 SQL 命令串联在一起并使其得以执行的用户输入变量。一种间接的攻击会将恶意代码注入要在表中存储或作为元数据存储的字符串。在存储的字符串随后串连到一个动态 SQL 命令中时，将执行该恶意代码。

        注入过程的工作方式是提前终止文本字符串，然后追加一个新的命令。由于插入的命令可能在执行前追加其他字符串，因此攻击者将用注释标记“--”来终止注入的字符串。执行时，此后的文本将被忽略。

     

        以下脚本显示了一个简单的 SQL 注入。此脚本通过串联硬编码字符串和用户输入的字符串而生成一个 SQL 查询：

      var Shipcity;

        ShipCity = Request.form. ("ShipCity");

        var sql = "select * from OrdersTable where ShipCity = '" + ShipCity + "'";

     

    用户将被提示输入一个市县名称。如果用户输入 Redmond，则查询将由与下面内容相似的脚本组成： 

     

        SELECT * FROM OrdersTable WHERE ShipCity = 'Redmond'

    但是，假定用户输入以下内容：

     

        Redmond'; drop table OrdersTable--

     

    此时，脚本将组成以下查询：

     

        SELECT * FROM OrdersTable WHERE ShipCity = 'Redmond';drop table OrdersTable--'

     

       分号 (;) 表示一个查询的结束和另一个查询的开始。双连字符 (--) 指示当前行余下的部分是一个注释，应该忽略。如果修改后的代码语法正确，则服务器将执行该代码。SQL Server 处理该语句时，SQL Server 将首先选择 OrdersTable 中的所有记录（其中 ShipCity 为 Redmond）。然后，SQL Server 将删除 OrdersTable。

     

         只要注入的 SQL 代码语法正确，便无法采用编程方式来检测篡改。因此，必须验证所有用户输入，并仔细检查在您所用的服务器中执行构造 SQL 命令的代码。本主题中的以下各部分说明了编写代码的最佳做法。

     

         验证所有输入

        

        始终通过测试类型、长度、格式和范围来验证用户输入。实现对恶意输入的预防时，请注意应用程序的体系结构和部署方案。请注意，设计为在安全环境中运行的程序可能会被复制到不安全的环境中。以下建议应被视为最佳做法：

     

        如果一个用户在需要邮政编码的位置无意中或恶意地输入了一个 10 MB 的 MPEG 文件，应用程序会做出什么反应？

     

        如果在文本字段中嵌入了一个 DROP TABLE 语句，应用程序会做出什么反应？

        测试输入的大小和数据类型，强制执行适当的限制。这有助于防止有意造成的缓冲区溢出。

        

    输入字符

    在 Transact-SQL 中的含义

    ;

    查询分隔符。

    '

    字符数据字符串分隔符。

    --

    注释分隔符。

    /* ... */

    注释分隔符。服务器不对 /* 和 */ 之间的注释进行处理。

    xp_

    用于目录扩展存储过程的名称的开头，如 xp_cmdshell。

     

    举例说明对数据库防SQL注入


    SQL注入是防止数据库攻击的一个有效策略。攻击者将注入一个SQL语句到另外一个语句中，这个通常会损坏你的数据库。有数据库接口的Web站点通常在SQL注入的时候容易受到攻击，因为它们是基于动态的SQL；下面是一个简单的例子：
    在一个ASP页面中会请求用户输入名字和密码，然后将下面的字符串发送到数据库中：

    SELECT FROM users WHERE username =
    ’whatever’ AND password = ’mypassword’

    这看起来很安全，实际上不是，一个用户可能会这样输入他的名字：

    ’ OR 1>0 --

    当把这个输入到SQL语句中的时候，结果可能会象这样：

    SELECT FROM users WHERE username
    = ’’ OR 1>0 -- AND password = ’’

    这个注入语言将通过语句暴露密码。这将导致所有的用户名都会在用户列表中，所以，任何用户都可以进入到你的系统中。

    最简单阻止注入分类是分析SQL串并移动语句之前的任何“--”的发生。

    同时，你要小心注入的时候含有分号，因为分号是给SQL语句分界。如果一个用户的名字是下面这个：

    ’ OR 1>0 ; DELETE Customers ; --
     
     
     
    WEB攻击

    Windows SQL injection (site contain /admin/login.asp or just login.asp page)

    Instead password use one of this string

    ' or 1=1--

    " or 1=1--

    or 1=1--

    ' or 'a'='a

    " or "a"="a

    ') or ('a'='a

    ") or ("a"="a


    如果一个用户怀有恶意，那么他可以使用多种方法看穿你的系统，但是，最简单的方法就是避免动态的SQL，用存储过程来代替。使用SQL来遍历参数，注入上面所提到的将会产生进程错误，并且存储进程将不会被执行。

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

  • SQL 语句 基础：学习

    2011-01-20 09:11:34

    创建新表
    　　create table tabname(col1 type1 [not null] [primary key],col2 type2 [not null],..)
    删除新表
    　　drop table tabname
    增加一个列
    　　Alter table tabname add column col type
    几个简单的基本的sql语句
    　　选择：select * from table1 where 范围 　　
    插入：insert into table1(field1,field2) values(value1,value2) 　
    　删除：delete from table1 where 范围 　
    　更新：update table1 set field1=value1 where 范围
    　查找：select * from table1 where field1 like ’%value1%’ （所有包含‘value1’这个模式的字符串）---like的语法很精妙，查资料!
    　排序：select * from table1 order by field1,field2 [desc] 　
    　总数：select count(*) as totalcount from table1 　
    　求和：select sum(field1) as sumvalue from table1 　　
         平均：select avg(field1) as avgvalue from table1 　
    　最大：select max(field1) as maxvalue from table1 　
    　最小：select min(field1) as minvalue from table1[separator]

    几个高级查询运算词
    　　A： UNION 运算符 　
    　UNION 运算符通过组合其他两个结果表（例如 TABLE1 和 TABLE2）并消去表中任何重复行而派生出一个结果表。当 ALL 随 UNION 一起使用时（即 UNION ALL），不消除重复行。两种情况下，派生表的每一行不是来自 TABLE1 就是来自 TABLE2。 　　
    B： EXCEPT 运算符 　　EXCEPT 运算符通过包括所有在 TABLE1 中但不在 TABLE2 中的行并消除所有重复行而派生出一个结果表。当 ALL 随 EXCEPT 一起使用时 (EXCEPT ALL)，不消除重复行。 　　C： INTERSECT 运算符 　　INTERSECT 运算符通过只包括 TABLE1 和 TABLE2 中都有的行并消除所有重复行而派生出一个结果表。当 ALL 随 INTERSECT 一起使用时 (INTERSECT ALL)，不消除重复行。 　　注：使用运算词的几个查询结果行必须是一致的。
    使用外连接
    　　A、left outer join： 　　左外连接（左连接）：结果集既包括连接表的匹配行，也包括左连接表的所有行。 　　SQL: select a.a, a.b, a.c, b.c, b.d, b.f from a LEFT OUT JOIN b ON a.a = b.c 　
        　B：right outer join: 　　右外连接(右连接)：结果集既包括连接表的匹配连接行，也包括右连接表的所有行。 　　C：full outer join： 　　全外连接：不仅包括符号连接表的匹配行，还包括两个连接表中的所有记录。

    子查询
    　　(表名1：a 表名2：b) 　　select a,b,c from a where a IN (select d from b 或者: select a,b,c from a where a IN (1,2,3)
    外连接查询
    　　(表名1：a 表名2：b) 　　select a.a, a.b, a.c, b.c, b.d, b.f from a LEFT OUT JOIN b ON a.a = b.c
    between的用法
    　　between限制查询数据范围时包括了边界值,not between不包括 　　select * from table1 where time between time1 and time2 　　select a,b,c, from table1 where a not between 数值1 and 数值2
    in 的使用方法
    　　select * from table1 where a [not] in (‘值1’,’值2’,’值4’,’值6’)

    Insert: 请注意所有的整形十进制数都不需要用单引号引起来，而字符串和日期类型的值都要用单引号来区别。为了增加可读性而在数字间插入逗号将会引起错误。记住，在SQL中逗号是元素的分隔符。

    　　同样要注意输入文字值时要使用单引号。双引号用来封装限界标识符。

    　　对于日期类型，我们必须使用SQL标准日期格式（yyyy-mm-dd），但是在系统中可以进行定义，以接受其他的格式。当然，2000年临近，请你最好还是使用四位来表示年份。

    INSERT INTO EMPLOYEES VALUES

    　　 ('Jones','Indiana','1992-02-01',

    　　 'Chicago',NULL,NULL);

    我们不知道Jones先生的工薪级别和年薪，所以我们输入NULL（不要引号）。NULL是SQL中的一种特殊情况，我们以后将进行详细的讨论。现在我们只需认为NULL表示一种未知的值。

    INSERT INTO EMPLOYEES(

    　　 FIRST_NAME, LAST_NAME,

    　　 HIRE_DATE, BRANCH_OFFICE)

    　　VALUE(

    　　 'Indiana','Jones',

    　　 '1992-02-01','Indianapolis');

    这样，我们先在表名之后列出一系列列名。未列出的列中将自动填入缺省值，如果没有设置缺省值则填入NULL。请注意我们改变了列的顺序，而值的顺序要对应新的列的顺序。如果该语句中省略了FIRST_NAME和LAST_NAME项（这两项规定不能为空），SQL操作将失败。

    SELECT语句

    现在已经消除了重复的行，但结果并不是按照顺序排列的。如果你希望以字母表顺序将结果列出又该怎么做呢？只要使用ORDER BY子句就可以按照升序或降序来排列结果：

    　　SELECT DISTINCT BRANCH_OFFICE

    　　FROM EMPLOYEES

    　　ORDER BY BRANCH_OFFICE ASC;

    将一个很长的表中的所有列名写出来是一件相当麻烦的事，所以SQL允许在选择表中所有的列时使用*号：

    逻辑连接符:为了进一步定义一个WHERE子句，用户可以使用逻辑连接符AND，OR和NOT
    关键字NOT后面跟着用圆括号括起来的比较表达式。其结果是对结果取否定:WHERE NOT(BRANCH_OFFICE = 'Boston');
    断言可以与其他的断言嵌套使用。为了保证它们以正确的顺序进行求值，可以用括号将它们括起来：

    首先，在断言中进行NULL判断时需要特殊的语法。例如，如果用户需要显示所有年薪未知的职员的全部信息，用户可以使用如下SELECT语句：

    　　SELECT * FROM EMPLOYEES

    　　WHERE SALARY IS NULL;

    　　相反，如果用户需要所有已知年薪数据的职员的信息，你可以使用以下语句：

    　　SELECT * FROM EMPLOYEES

    　　WHERE SALARY IS NOT NULL;

    　　请注意我们在列名之后使用了关键字IS NULL或IS NOT NULL，而不是标准的比较形式：COLUMN = NULL、COLUMN <> NULL或是逻辑操作符NOT（NULL）。

    从而需要使用特殊的操作符IS NULL和IS NOT NULL。

    UPDATE语句

    　　UPDATE语句允许用户在已知的表中对现有的行进行修改。

    　　例如，我们刚刚发现Indiana Jones的等级为16，工资为$40,000.00，我们可以通过下面的SQL语句对数据库进行更新（并清除那些烦人的NULL）。

    　　UPDATE EMPLOYEES

    　　SET GRADE = 16, SALARY = 40000

    　　WHERE FIRST_NAME = 'Indiana'

    　　 AND LAST_NAME = 'Jones';

    　　上面的例子说明了一个单行更新，但是UPDATE语句可以对多行进行操作。满足WHERE条件的所有行都将被更新。如果，你想让Boston办事处中的所有职员搬到New York，你可以使用如下语句：

    　　UPDATE EMPLOYEES

    　　SET BRANCH_OFFICE = 'New York'

    　　WHERE BRANCH_OFFICE = 'Boston';

    　　如果忽略WHERE子句,表中所有行中的部门值都将被更新为'New York'。

    　　UPDATE语句的语法流图如下面所示：

    　　UPDATE table

    　　SET column = value [{, column = value}]

    　　[ WHERE predicate [ { logical-connector predicate}]];

    　　DELETE语句

    　　DELETE语句用来删除已知表中的行。如同UPDATE语句中一样，所有满足WHERE子句中条件的行都将被删除。由于SQL中没有UNDO语句或是“你确认删除吗？”之类的警告，在执行这条语句时千万要小心。如果决定取消Los Angeles办事处并解雇办事处的所有职员，这一卑鄙的工作可以由以下这条语句来实现：

    　　DELETE FROM EMPLOYEES

    　　WHERE BRANCH_OFFICE = 'Los Angeles';

    　　如同UPDATE语句中一样，省略WHERE子句将使得操作施加到表中所有的行。

    　　DELETE语句的语法流图如下面所示：

    　　DELETE FROM table

    　　[WHERE predicate [ { logical-connector predicate} ] ];

     

     


     

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

  • QTP Index

    2011-01-19 10:36:43

    在需要唯一识别一个对象时，index属性有时候可能非常有用。index属性是对象在源代码中出现的顺序，第1次出现时，index值为0。

    Index属性是object-specific的。因此，当你用index属性值“3”来描述一个WebEdit对象时，QTP会在被测程序的当前页面中查找第4个WebEdit对象。

    如果你使用index属性值3来描述一个WebElement对象时，QTP会在被测程序的当前页面中查找第4个Web对象。

    例如，当前页面中存在下面的对象：

    • 一个名为Qpple的Image对象
    • 一个名为UserName的Image对象
    • 一个名为UserName的WebEdit对象
    • 一个名为Password的Image对象
    • 一个名为Password的WebEdit对象

    下面的语句中指的是列表中的第3个对象，因为它要求指向的是第1个名为UserName的WebEdit对象。

    WebEdit("Name:=UserName", "Index:=0")

    下面的语句中指的是列表中的第2个对象，因为它要求指向的是第1个名为UserName的WebElement对象。

    WebElement("Name:=UserName", "Index:=0")

    注：如果当前只有一个对象，使用index=0将无法查找到对象，因此就不能在对象描述中使用index属性。

     

     

      之前使用QTP测试的VB程序，知道了Index在对象识别时候起到一个很重要的主用，和条街的门牌号一样。某某街某某号，然后QTP就通过这个东西去找出来，而且也是固定不变，因此，大家就开始偏向对描述性编程的喜好与拥护。优势如下：可移植性强，对对象库的依赖减少（一会有人丢我焦皮说我扯蛋，对象库是QTP精华什么的话一句句就出来，等我说完先）
        为什么说到它的移植性强呢，首先，通过对象库去识别对象并保存对象，会出现因为机器环境不同的情况，对象在不同机器上识别为不同类别而导致脚本可移植差。关于对象库的依赖，与上边那点有点类似。
         随着时间的推移，对QTP的了解加深。现在主要是在web方面写的脚本，发现了在web的page里面，对象标示用的index是会随着对象的变化而变化着，并非一成不变（我对这个观点一直很质疑，虽然是自己发现的，但还是反复的试验着）。
         首先说下自己的质疑点：
         1，关于index的生成。在VB里面，大家知道，这是开发远自己就可以定义的，但是在web里面呢？如果是可以有开发自己定义的，哪么为什么对象的标示index却在变动。
         2，这个Index是否是QTP自己在运行程序过程中，自己对该程序做的标示，也就是非window的自己标示方法，才会导致这个值在变化着。
         
         自己研究了下，后来发现，当我们添加某一个web元素时候，这个对象会对应自己的一个index，这个是window或者是web程序自己对控件的标示。而我们使用description描述出来webelemenet的对象的index，这个是QTP自己对对象的标示方法。但这样是否会冲突和矛盾呢？其实是不会的。在对象库中添加的对象，我们在代码中直接编写，QTP就自己去对象库中查找这个东西，自然这个对象的标示是web或者window自己做的。而当我们用webelement去查找这个东西时候，QTP就在网页元素自己做好了标示，类似active Screen事先把对象页面存储起来一样，已经对它们分别做好了身份识别。

         好了，说了这么多，说说用处先吧。
         大家在测试web过程，最担心的问题就是，对象识别不到，或者识别到了，不是自己理想的类型，哎，委曲求全，来个低级录制吧....
        eg:之前看到论坛有人在求救一些关于无法识别的，类似view tree之类的东西，感到很郁闷...
        哪么，根据上边的那个原理，大家可以看到，其实我们通过描述的方法做到这样：以下是一棵可以张开的树，有3个可以张开的，并且QTP对他们分别节点标示 index为1，2，3，而我们把节点张开后...

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

  • GUI 测试点

    2010-04-15 09:47:39

    窗口

    　　* 窗口能否基于相关的输入或菜单命令适当的打开

    　　* 窗口能否改变大小、移动和滚动

    　　* 窗口中的数据能否用鼠标、功能键、方向箭头和键盘操作

    　　* 当被覆盖的窗口重新调用后，所有相关功能是否可操作

    　　* 能否使用所有窗口的相关功能，所有相关功能是否可操作

    　　* 相关的下拉式菜单，工具条，滚动条，对话框，按钮，图标和其它控制有否？能否正常显示？完全可用？

    　　* 显示多窗口时，窗口名能否正确显示，活动窗口是否加亮

    　　* 使用多用户时，所有窗口是否能实时更新

    　　* 多次或不正确按鼠标是否会产生无法预测的结果

    　　* 窗口的声音、颜色提示和窗口的操作顺序是否符合需求

    　　* 窗口能否正确关闭


    数据项

    　　* 字母、数据能否正确显示且输入系统

    　　* 图象方式数据项（如滚动条）是否正常工作

    　　* 数据输入、消失是否可以理解，能否识别非法数据

    　　下列式菜单和鼠标操作

    　　* 菜单条显示在合适语言环境中

    　　* 应用程序的菜单是否显示系统相关特性

    　　* 下拉式操作是否正确，功能是否正确

    　　* 菜单、调色板和工具条是否能正常的工作

    　　* 能否列出所有菜单功能和下拉式功能

    　　* 能否通过鼠标操作所有菜单的功能，通过文本命令激活每个菜单功能

    　　* 菜单功能随当前窗口操作加亮或变灰

    　　* 如果要求多次点击鼠标或鼠标有多个按钮时能否正确识别

    　　* 光标、处理指示器和识别指针能否随操作而适当改变

    -----------------------------------------------------------------------------------------------------------


    UI测试常见BUG


    　　录入界面

    　　1. 输入字段要完整，且要与列表字段相符合（参照数据库进行检查）

    　　2. 必填项一律在后面用*表示（必填项为空在处理之前要有相关的提示信息）

    　　3. 字段需要做校验，如果校验不对需要在处理之前要有相关的提示信息

    　　 (1) 长度校验

    　　 (2) 数字、字母、日期等等的校验

    　　 (3) 范围的校验

    　　4. 录入字段的排序按照流程或使用习惯，字段特别多的时候需要进行分组显示

    　　5. 下拉框不选值的时候应该提供默认值

    　　6. 相同字段的录入方式应该统一（手动输入 、点选 、下拉选择、参照）

    　　7. 录入后自动计算的字段要随着别的字段修改更新（如单价变后，金额也变）

    　　8. 日期参照应该既能输入，又能从文本框选择


    　　界面格式

    　　1. 字体颜色、大小、对齐方式（根据字段的性质确定）、加粗的一致性

    　　2. 文本框、按钮、滚动条、列表等控件的大小、对齐、位置的一致性

    　　3. 所有新增、修改、查看页面加上页面说明（如：XXX新增、XXX编辑、XXX查看等说明字样），（弹出的）界面要有标题，标题与内容要一致

    　　4. 不同界面显示相同字段的一致性（如列表界面和编辑界面）

    　　5. 界面按钮显示要求（查询、新增、删除顺序）

    　　6. 列表的顺序排列应该统一（按照某些特定条件排序）

    　　7. 下拉框中的排列顺序需要符合使用习惯或者是按照特定的规则排定

    　　8. 所有弹出窗口居中显示或者最大化显示

    　　9. 信息列表中如果某个字段显示过长用“…”或者分行显示

    　　10. 人员、时间的缺省值一般取当前登录人员和时间

    　　11. 对于带有单位的字段，需要字段的标签后面添加如下内容：“（单位）”


           功能问题

    　　1. 按钮功能的实现（如返回按钮能否返回）

    　　2. 信息保存提交后系统给出“保存/提交成功”提示信息，并自动更新显示

    　　3. 所有有提交按钮的页面都要有保存按钮（每个界面风格一致）

    　　4. 凡是点选或者下拉选择的界面，如果一旦选择完了无法回到不选择的情况，需要加上“清除选择”功能按钮

    　　5. 没有选择记录点击删除/修改按钮要提示“请先选择记录”

    　　6. 选择记录后点击删除按钮要提示“确实要删除吗？”

    　　7. 需要考虑删除的关联性，即删除某一个内容需要同时删除其关联的某些内容

    　　8. 界面只读的时候（查询、统计、导入）等，应该不能编辑


    　　查询问题

    　　1. 查询条件缺少一些可以查询的字段

    　　2. 有些查询条件需要支持模糊查询

    　　3. 需要考虑有些查询条件本身的关联性（即某个查询条件的取值范围是依赖于其它查询条件的取值）

    　　4. 查询条件名称与信息列表及信息编辑页面相应的字段名称完全统一

    　　5. 不同模块相同字段的查询方式应该统一（手动输入 、点选 、下拉选择）

    　　6. 出报表的时候，查询条件需要显示在报表标题的下面，这样看报表的时候知道数据的依据是什么

    　　7. 对于范围的查询采用全闭的形式

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

  • 页面测试点

    2010-01-25 11:50:14

    1、页面链接检查： 每一个链接是否都有对应的页面，并且页面之间切换工具，如LinkBotPro、File-AIDCS、HTML Link Validater、Xenu等工具。LinkBotPro不支持中文，中文字符显示为乱码；HTML Link Validater只能测试以Html或者htm结尾的网页链接；Xenu无需安装，支持asp、do、jsp等结尾的网页，同时能够生成html格式的测试报告。

    2、相关性检查：删除/增加一项会不会对其他项产生影响，如果产生影响，这些影响是否都正确检查按钮的功能是否正确 如新建、编辑、删除、关闭、返回、保存、导入等功能是否正确。

    3、字符类型检查：在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型。

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

    2）特殊字符检查：输入特殊符号，如@、#、$、%、!等，看系统处理是否正确。

    3)字符串长度检查: 输入超出需求所说明的字符串长度的内容, 看系统是否检查字符串长度。

    4、中文字符处理：在可以输入中、英文的系统输入中文,看会否出现乱码或出错。

    检查信息的完整性 在查看信息和更新信息时,查看所填写的信息是不是全部更新,更新信息和添加信息是否一致。

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

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

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

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

    9、重复提交表单：一条已经成功提交的纪录，返回后再提交，看看系统是否做了处理。对于Web系统检查多次使用返回键的情况   在有返回键的地方,返回到原来页面,重复多次，看会否出错

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

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

    12、上传下载文件检查：上传下载文件的功能是否实现，上传文件是否能打开。对上传文件的格式有何规定，系统是否有解释信息，并检查系统是否能够做到。下载文件能否打开或者保存，下载的文件是否有格式要求，如需要特殊工具才可以打开等。

    13、必填项检查：应该填写的项没有填写时系统是否都做了处理，对必填项是否有提示信息，如在必填项前加“*”；对必填项提示返回后，焦点是否会自动定位到必填项。

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

    15、回车键检查：在输入结束后直接按回车键,看系统处理如何,会否报错。

    16、刷新键检查：在Web系统中，使用浏览器的刷新键，看系统处理如何，会否报错。  

    17、回退键检查：在Web系统中，使用浏览器的回退键，看系统处理如何，会否报错。对于需要用户验证的系统，在退出登录后，使用回退键，看系统处理如何；多次使用回退键，多次使用前进键，看系统如何处理。

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

  • 网站测试点

    2010-01-25 11:26:33

     
    网站测试关注点
     
     

    UI测试

    UI测试包括的内容有如下几方面：

    1）各个页面的样式风格是否统一；

    2）各个页面的大小是否一致；同样的LOGO图片在各个页面中显示是否大小一致；页面及图片是否居中显示；

    3）各个页面的title是否正确；

    4）栏目名称、文章内容等处的文字是否正确，有无错别字或乱码；同一级别的字体、大小、颜色是否统一；

    5）提示、警告或错误说明应清楚易懂，用词准确，摒弃模棱两可的字眼；

    6）切换窗口大小，将窗口缩小后，页面是否按比例缩小或出现滚动条；各个页面缩小的风格是否一致（按比例缩小或出现滚动条，不可二者兼有）；

    7）父窗体或主窗体的中心位置应该在对角线焦点附近；子窗体位置应该在主窗体的左上角或正中；多个子窗体弹出时应该依次向右下方偏移，以显示出窗体标题为宜；

    8）按钮大小基本相近，忌用太长的名称，免得占用过多的界面位置；避免空旷的界面上放置很大的按钮；按钮的样式风格要统一；按钮之间的间距要一致；

    9）页面颜色是否统一；前景与背景色搭配合理协调，反差不宜太大，最好少用深色或刺目的颜色；

    10）若有滚动信息或图片，将鼠标放置其上，查看滚动信息或图片是否停止；

    11）导航处是否按相应的栏目级别显示；导航文字是否在同一行显示；

    12）所有的图片是否都被正确装载，在不同的浏览器、分辨率下图片是否能正确显示（包括位置、大小）；

    13）文章列表页，左侧的栏目是否与一级、二级栏目的名称、顺序一致；

    14) 调整分辨率验证页面格式是否错位现象；

    15）鼠标移动到Flash焦点上特效是否实现，移出焦点特效是否消失；

    链接测试

    链接测试主要分为以下几个方面：

    1）页面是否有无法连接的内容；图片是否能正确显示，有无冗余图片，代码是否规范，页面是否存死链接（可以用HTML Link Validator工具查找）；

    2）图片上是否有无用的链接；点击图片上的链接是否跳转到正确的页面；

    3）首页点击LOGO下的一级栏目或二级栏目名称，是否可进入相应的栏目；

    4）点击首页或列表页的文章标题的链接，是否可进入相应的文章的详细页面；

    5）点击首页栏目名称后的【更多】链接，是否正确跳转到相应页面；

    6）文章列表页，左侧的栏目的链接，是否可正确跳转到相应的栏目页面；

    7）导航链接的页面是否正确；是否可按栏目级别跳转到相应的页面；

    （例：【首页->服务与支持->客服中心】，分别点击“首页”、“服务与支持”、“客服中心”，查看是否可跳转到相应页面；）

    搜索测试

    搜索测试主要分为以下几个方面：

    1）搜索按钮功能是否实现；

    2）输入网站中存在的信息，能否正确搜索出结果；

    3）输入键盘中所有特殊字符，是否报错；特别关注：_ ？ ’ . · \  / -- ；特殊字符

    4）系统是否支持键盘回车键、Tab键；

    5）搜索出的结果页面是否与其他页面风格一致；

    6）在输入域输入空格，点击搜索系统是否报错；

    7）本站内搜索输入域中不输入任何内容，是否搜索出的是全部信息或者给予提示信息；

    8）精确查询还是模糊查询，如果是模糊查询输入：中%国。查询结果是不是都包含中国两个字的信息；

    9）焦点放置搜索框中，搜索框内容是否被清空；

    10）搜索输入域是否实现回车键监听事件；

    表单测试

    表单测试主要分为以下几个方面：

    1）注册、登录功能是否实现；

    2）提交、清空按钮功能是否实现；

    3）修改表单与注册页面数据项是否相同，修改表单是否对重名做验证；

    4）提交的数据是否能正确保存到后台数据库中（后台数据库中的数据应与前台录入内容完全一致，数据不会丢失或被改变）；

    5）表单提交，删除，修改后是否有提示信息；

    6）浏览器的前进、后退、刷新按钮，是否会造成数据重现或页面报错；

    7）提交表单是否支持回车键和Tab键；

    8）下拉列表功能是否实现和数据是否完整（例如：省份和市区下拉列表数据是否互动）；

    输入域测试

    输入域测试主要分为以下几个方面：

    1）对于手机、邮箱、证件号等的输入是否有长度及类型的控制；

    2）输入中文、英文、数字、特殊字符（特别注意单引号和反斜杠）及这四类的混合输入，是否会报错；

    3）输入空格、空格+数据、数据+空格，是否报错；

    4）输入html语言的<head>，是否能正确显示；

    5）输入全角、半角的英文、数字、特殊字符等，是否报错；

    6）是否有必填项的控制；不输入必填项，是否有友好提示信息；

    7）输入超长字段，页面是否被撑开；

    8）分别输入大于、等于、小于数据表规定字段长度的数据，是否报错；

    9）输入非数据表中规定的数据类型的字符，是否有友好提示信息；

    10）在文本框中输入回车键，显示时是否回车换行；

    11）密码输入域输入数据显示是否可见；

    分页测试

    分页测试主要分为以下几个方面：

    1）当没有数据时，首页、上一页、下一页、尾页标签全部置灰；

    2）在首页时，“首页”“上一页”标签置灰；在尾页时，“下一页”“尾页”标签置灰；在中间页时，四个标签均可点击，且跳转正确；

    3）翻页后，列表中的数据是否扔按照指定的顺序进行了排序；

    4）各个分页标签是否在同一水平线上；

    5）各个页面的分页标签样式是否一致；

    6）分页的总页数及当前页数显示是否正确；

    7）是否能正确跳转到指定的页数；

    8）在分页处输入非数字的字符（英文、特殊字符等），输入0或超出总页数的数字，是否有友好提示信息；

    9）是否支持回车键的监听

     

    查看(819) 评论(2) 收藏 分享 管理

  • 网站的测试点

    2010-01-25 10:44:54

    测试工作总结：

    Livebookings（about three mounth）

    1.       Title of the page：每个页面中都需要有页面的title

    2.       Regiester page：

    register successful ，then the page should be turn to the login in page, and the new user should be inputed but the password  should not be input in the login in page

    Register faield , the page should be in the regiester page, the information should be still in the page.

    3.       Button : the style. should be same in the system, 在测试的时候 button 必须实现他的真正的功能。

    4.       前台和 后天 should be same,

    5.       互相影响的地方需要同步更新。If add the new items, in the same page, the new item should be displayed after the new item has been added successfully. If the item is delete the item should be deleted from the same page,

    6.       更具客户的需求， 如果现在要求保存住search 的 查询条件的话， 所有的查询前的条件都要记录住，包括被张开的部分和 所有的被影响的可以变化的字体都要记录着。

    7.       Search functions, 需要查询查询结果是不是真的正确。 在一个条件下或是在多个条件下在查询的都应该显示的是正确的结果。

    8.       Test case： 以后在写test case 的时候需要注意覆盖面的问题，需要全部覆盖到，并且要严格的采取测试的等价类划分的技巧， 以方便开发人员开发驱动测试（TDD）.并在写test case 的时候要明确什么时候 正确的结果 什么时候不正确的， 都要明确的写在 testcase 中。

    9.       在测试的时候 要尽早的发现 bugs，这样及早的解决这些问题。

    10.   Email 和search 的条件中都是不区分大小写的，。

    11.   在测试的时候 要尽量考虑在页面不是最大的时候 页面现在的是不是有问题。（特别是在页面最大化到出现滚动条， 或是由有滚动条状态到 最大化的状态的时候是不是页面还是有问题。 ）

    12.   注意浏览器本身的特性对页面显示效果的影响（firefox3.0: 有的时候会记录住页面的密码， IE6 有些功能是在ie6中不能正常的显示的。Safari 中的 文本框是可以拉升的。 ）

    13.   测试中测试功能应该是浏览器为主，测试界面时要多个浏览器并用。（这个现在需要考虑如何更好的完成测试中的任务。）

    14.   本地化测试的时候 要注意小的细节的地方 是否被本地化了。 在客户那边改变功能的时候是不是 相应的东西也本地化了。 

    15.   提交按钮不可以连续点击。 以免系统响应时间长， 导致系统崩溃-----现在这个开发人员还是没有时间这个问题， 需要在以后的测试中注意。

    16.   为了方便用户的正真的使用，在点击back按钮的时候以前添加的信息需要保存----这个是在book 中所有添加的信息在back 到后一页或是proceeds 到前一页的时候都是需要保存的-----所以在以后测试的时候需要考虑到类似的问题，以方便

    17.   在点击了back按钮 然后 在点击proccede 按钮的时候， 系统还是需要保存住原来已经添加的信息， 减少用户的重复的输入工作。

    18.   测试的时候 发现的bug 要坚定自己的原则。并在测试的早期尽量多的发现bug， 特别要主要逻辑上的bug。 不要到最后的时候才发现出这些主要的逻辑的bug。

    19.    

     

     

    测试弱点：

    在测试的早期发现bug 少。

    不是把主要的注意力放在主要的功能上。

    虽然测试时间很匆忙但是测试效率不高。这个项目很注重UI ，但是在客户发现的bug 很多是UI issue

    在以后的工作中， 如发现问题尽量的提交bug 在PMS上。 减少和开发人员的沟通，尽量做到少个开发人员在bug 上的沟通。

    在以后每次提交的时候 都要总结一下，看看自己的不足之处，并在以后的测试中改正，提高测试效率。

     

     

    在测试的时候 界面上的任何的元素不能因为设计别的界面而是 其他的界面或是元素变形。（转动的ajax ）

    1.     在测试的时候要考虑方便用户是应用， 尽量减少用户的操作。

    2.     在website 中需要考虑到 tab键 的功能

    3.       要严格的按照测试用例来执行测试。---- 现在要把每次提交的东西放到PMS上去。 以后要在pms 中查找测试结果， 在测试之前要把test case 更新到Pms 上。 

    4.     每次提交的时候都要 在email 中都要有测试总结。 把自己以测试过的和没有测试过的，那个主要的bug还有没有修改都需要总结一下。--------在每个迭代中测试出来的bug 数， 还有多少bug 还没有修改， 有没有严重的bug 还没有修改。

     

    5.       在每次客户反馈后都要自己总结 什么功能改变了， 需要update test case 都要及时的更新到testcase 中， 并分析是什么原因造成客户issue。 并做记录，在以后的测试过程中不要犯同样的错误。 ---------明确的分清那个是自己的问题

    6.     要在客户发现问题之前找到bug。 这个是最终的目的。------这个问题很需要注意

    7.       在测试的时候，在search 中 所有的查询的条件都要验证，特别是一些小的查询的条件和非必填项都需要验证，并且需要验证查询的结果是不是正确。--------在测试的时候都要测试到以防一些bug 没有找到

    8.     在测试的时候 需要考虑到分页功能是不是正常的显示， 是不是正确的本地化。 是不是由于分页功能而影响到了页面的显示。 -------分页功能需要注意本地化， 在一页的时候 previous  是不可点击的， 在最后一页的时候Next 应该是灰色的或是不可点击的。

    9.       在测试的时候有与网络有关的 步骤必须考虑到断网的情况----- 一些加载的东西需要测试

    10.  控件TAB顺序是否从左到右，从上到下

    11.   日期的显示的格式： 是否接受正确的日期格式， 是否接受错误的日期格式，是否显示正常的日期格式。

    12.  文本框或是其他的控件在拒绝输入和选中的时候 显示区域是否变灰或是别的规则

    13.  在注册的页面中， 密码输入框是否按掩码的方式显示，Cancel之类的按钮按下后，控件中的数据是否清空复原或按既定规约处理，Submit之类的按钮按下后，数据是否得到提交或按既定规约处理。

    测试的时候 需要注意的问题：

    1.       用户在退出系统后重新登陆时应考虑是否需要自动返回到上次退出系统时的界面;

    2.       页面的转向的问题

    3.       URL不区分大小写

    4.       某些重要信息在输入、修改、删除时应有“确认”提示信息;

    5.       界面内容更新后系统应提供刷新功能。

    6.       v在多个业务功能组成的一个业务流程中，如果各个功能之间的执行顺序有一定的制约条件，应通过界面提示用户

    7.       在对任何配置信息修改后，都应该在用户退出该界面时提示用户保存(如果用户没有主动保存的情况下);

    8.       界面测试时，应考虑用户使用的方便性：
    　　a) 在某些对数据进行处理的操作界面，应考虑用户可能对数据进行处理的频繁程度和工作量，考虑是否可以进行批量操作。
    　　8.界面测试时，应考虑界面显示及处理的正确性：

    9.       界面测试时，应考虑界面显示及处理的正确性：
    　　a) 界面测试时应验证所有窗体中的对象状态是否正常，是否符合相关的业务规则需要。
    　　b) 应验证各种对象访问方法(Tab 健、鼠标移动和快捷键)是否可正常使用，并且在一个激活界面中快捷键无重复;
    　　c) 界面测试不光要考虑合理的键盘输入，还应考虑是否可以通过鼠标拷贝粘贴输入。
    　　d) 对于统计查询功能的查询结果应验证其是否只能通过界面上的查询或刷新按键人工触发，应避免其他形式的触发。
     查看(741) 评论(1) 收藏 分享 管理

  • 求职技巧

    2009-04-22 11:30:01

    本人是05年应届本科毕业生,目前在上海从事测试工作,对测试工作有强烈的兴趣，希望能进入北京的重视测试工作的公司.
    熟悉软件开发过程，测试步骤及报告编写，理解测试流程、测试统计及测试软件的开发
    熟悉测试理论及方法，熟悉CMMI模型
    可以根据功能说明书和测试说明书，创建测试案例
    具有设计编写、执行和评估测试用例的能力，具有对测试结果进行分析、总结的能力
    具备管理测试小组的能力、沟通能力和文字表达能力，有很强沟通能力和团队合作精神
    具有java程序开发经验，熟悉Linux、UNIX等操作系统，Tomcat等应用服务器.
    能熟练的使用英文编写文档

     

    考官从办公室（面试现场）随意选取一个简单物品，假定是一个喝水的带广告图案的花纸杯，让应聘人对它设计出尽可能多的测试用例。

    测试项目：杯子

    需求测试:查看杯子使用说明书

    界面测试:查看杯子外观

    功能度：用水杯装水看漏不漏；水能不能被喝到

    安全性：杯子有没有毒或细菌

    可靠性：杯子从不同高度落下的损坏程度

    可移植性：杯子再不同的地方、温度等环境下是否都可以正常使用

    兼容性：杯子是否能够容纳果汁、白水、酒精、汽油等

    易用性：杯子是否烫手、是否有防滑措施、是否方便饮用

    用户文档：使用手册是否对杯子的用法、限制、使用条件等有详细描述

    疲劳测试：将杯子盛上水（案例一）放24小时检查泄漏时间和情况；盛上汽油（案例二）放24小时检查泄漏时间和情况等

    压力测试：用根针并在针上面不断加重量，看压强多大时会穿透

    跌落测试:   杯子加包装(有填充物),在多高的情况摔下不破损

    震动测试: 杯子加包装(有填充物),六面震动,检查产品是否能应对恶劣的铁路\公路\航空运输

    测试数据：

    测试数据具体编写此处略（最讨厌写测试数据了）。其中应用到：场景法、等价类划分法、因果图法、错误推测法、边界值法等方法

    期望输出：

    该期望输出需查阅国标、行标以及使用用户的需求

    说明书测试: 检查说明书书写准确性

    给大家提三个产品:1.手机 2.电饭锅 3.电梯

     

    网上解答之一：

     
    测试项目：手机

    需求测试:查看手机使用说明书

    界面测试:机身有没有裂痕或损伤，
            液晶屏有没有坏点，
            操作系统的一致性、易用性、色彩搭配……
            （一般界面测试有专门的界面测试人员测试，涉及到界面设计、人机交互的 内容，给大家推荐个网，有兴趣的可以上去看看，www.chinaui.com,）
           
    功能度：手机应有的功能……好多哦！开机、关机、发短信、通话、铃声………………
            （我手机有个问题……就是通话过程中按键无效，所以拨打不了分机号码，也不能给自己手机充值……）

    安全性：会不会漏电、辐射程度、机身会不会有比较尖锐的地方、

    可*性：从不同高度落下、平抛等的损坏程度，掉水里后还能不能用，

    可移植性：在不同的地方、温度等环境下是否都可以正常使用

    兼容性：对不同国家地区、不同型号的卡、非原装的电池和充电器是否同样适用

    易用性：（这个是属于界面测试吧）
            手机是否适合面向的客户的手形（中西男女各不同）、
            是否有防滑措施、按键的设计是否符合习惯等……

    用户文档：使用手册是否对手机的用法、限制、使用条件等有详细描述

    疲劳测试：可以不停的拨打电话（我们寝通用的费电方法，拨打1860，嫌打自己寝室太吵了……呵呵）

    压力测试：换不同的重量压吧（……我一同学对索爱的机子一坐，液晶屏坏了……）

    跌落测试:   ……………………

    震动测试: 加包装(有填充物),六面震动,检查产品是否能应对恶劣的铁路\公路\航空运输

    该期望输出需查阅国标、行标以及使用用户的需求

    说明书测试: 检查说明书书写准确性，多种语言

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

  • 界面测试

    2009-03-08 21:37:01

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

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

  • 安装测试指南

    2009-02-05 11:15:43

    操作系统
    测试类型
    测试内容
    Windows 95
    Pass   Fail   
    Windows 98
    Pass   Fail  
    Windows NT
    Pass   Fail       
    Windows 2000 
    Pass   Fail
    启动安装程序（Launch setup）
    如果安装了CD-ROM, 插入安装盘后自动启动安装程序
    或
    在CD盘中突出显示setup.exe文件，双击文件启动安装程序
     
    Windows 95
    Pass   Fail         
    Windows 98
    Pass   Fail
    Windows NT
    Pass   Fail       
    Windows 2000 
    Pass   Fail
    闪屏（Splash screen）
    “载入安装程序”对话框出现后，检查：
    1．   内容是否正确；
    2．   拼写是否正确；
    3．   在安装过程中，随着载入安装程序界面的出现，闪屏也随即出现。
    Windows 95
    Pass   Fail         
    Windows 98
    Pass   Fail
    Windows NT
    Pass   Fail       
    Windows 2000 
    Pass   Fail
    弹出框（Pop up box）
    弹出框出现时，检查：
    1．   内容是否正确；
    2．   拼写是否正确。
    Windows 95
    Pass   Fail         
    Windows 98
    Pass   Fail
    Windows NT
    Pass   Fail       
    Windows 2000 
    Pass   Fail
    中途退出（X、Exit or Cancel）
    1．   点击右上角的X按钮关闭时是否出现询问退出的对话框，如“您确定要退出吗？”；
    2．   选择取消按钮是否出现询问退出的对话框，如“您确定要退出吗？”    
    ·  “是”后出现提示应用系统没有被正确地安装，用户必须重新安装的信息；
    “是”后出现提示应用系统没有被正确地安装，用户必须重新安装的信息；
    ·  “是”后出现提示应用系统没有被正确地安装，用户必须重新安装的信息；
    ·         单击“否”后关闭对话框且返回到先前的界面；
    Windows 95
    Pass   Fail         
    Windows 98
    Pass   Fail
    Windows NT
    Pass   Fail       
    Windows 2000 
    Pass   Fail
    安装导航（Navigation）
    1．   安装导航引导用户到正确的屏幕，例如下一步（Next），返回（Back），取消（Cancel）按钮
    2．   焦点停留的按钮能够引导到下一个合理的操作，例如stand alone安装类型将引导到stand alone安装中的下一个屏幕；
    3．   使用键盘导航。
    Windows 95
    Pass   Fail         
    Windows 98
    Pass   Fail
    Windows NT
    Pass   Fail       
    Windows 2000 
    Pass   Fail
    目的地文件（File destination）
    1．   程序可以选择“C：”以外的目录
    2．   通过单击“…”按钮可以选择其他的安装路径。
    3．   可以通过以下方法选择路径：
            · 焦点在“确定”按钮上，按“Enter”键
            · 焦点在“确定”按钮上，点击“确定”按钮
            · 从浏览文件夹中双击选择路径
            · 直接输入路径
    4．   当文本框中输入的路径不存在时，系统可以创建。
    Windows 95
    Pass   Fail         
    Windows 98
    Pass   Fail
    Windows NT
    Pass   Fail       
    Windows 2000 
    Pass   Fail
    安装过程（Start Installation）
    1.          无异常出现
    2.          所有的文字可以正常显示（无截断）
    3.          界面上的版本信息，公司信息（图标，时间，地址等）正确
    4          许可证协议信息完整、正确
    Windows 95
    Pass   Fail         
    Windows 98
    Pass   Fail
    Windows NT
    Pass   Fail       
    Windows 2000 
    Pass   Fail
    安装完毕（Installation complete）
    1．   有弹出窗口显示安装完毕
    2．   所有的文件都安装在选择的目录下
    3．   要求的.dll全部安装；
    4．   帮助文件安装在指定的文件夹下；
    5．   检查.exe和.dll文件的版本号是否正确；
    6．   检查Ini文件是否记载了正确的路径和IP地址信息；
    7．   检查需注册信息在注册表中是否存在且在正确的地方；
    8．   快捷方式创建在选择的文件夹/启动菜单中，例如：C:\WINNT\Profiles\xs564gb\Start Menu\Programs\Executive Workbench
    9． 日志文件（Log）中的信息完整、正确
    Windows 95
    Pass   Fail         
    Windows 98
    Pass   Fail
    Windows NT
    Pass   Fail       
    Windows 2000 
    Pass   Fail
    启动应用程序（Launch application）
    可以通过以下方式启动应用程序：
    1．   双击目录中的应用程序图标
    2．   从开始菜单中选择
    3．   焦点放在exe文件上，敲“Enter”键
    4．   双击exe文件
    5．   运行命令下启动
    6．   双击桌面上的快捷方式
    Windows 95
    Pass   Fail         
    Windows 98
    Pass   Fail
    Windows NT
    Pass   Fail       
    Windows 2000 
    Pass   Fail
    重启后启动应用程序（Restart to use application）
    如果有对话框提示需重启计算机才能完成安装，重启机器再启动应用程序是否可以正常工作。
    Windows 95
    Pass   Fail         
    Windows 98
    Pass   Fail
    Windows NT
    Pass   Fail       
    Windows 2000 
    Pass   Fail
    卸载(Uninstall)
    通过Uninstall程序或控制面板卸载应用程序
    卸载后，检查安装的文件/文件夹/注册表信息是否被删除

     

    ）安装过程中对于缺省安装目录及任意指定的安装目录，是否都能正确安装；

    2)     若是选择安装，查看能否实现其相应的功能；

    3)     在所有能中途退出安装的位置退出安装程序后，验证此程序并未安装成功（没有程序组及程序项产生）；

    4)     软件安装后，对其它已经安装的软件是否有影响；

    5)     裸机安装后，各功能点是否可用；

    6)     安装前，安装程序是否判断可用磁盘空间大小，如果不能满足安装空间要求，安装程序能否继续；

    7)     安装过程中查看 版权声明、版本信息、公司名称、LOGO等是否符合标准；

    8)     安装过程中界面显示与提示语言是否准确、友好；

    9)     重复安装时系统是否有提示、是否可以覆盖安装、是否可以升级安装、是否允许多版本共存；

    10)  是否有注册码或硬件加密狗，在没有它们（或错误）存在的情况下能否顺利安装。

    2. 卸载测试

    1)     卸载后注册表中的注册信息及相关的程序安装目录是否能完全删除掉；

    2)     卸载过程中完全删除共享文件后，看其它程序能否正常运行；

    3)     卸载后，是否对其它已经安装的软件有影响；

    4)     系统卸载后用户建立文档是否保留；

    5)     软件卸载画面上的软件名称及版本信息是否正确；

    6)     在所有能中途退出卸载的位置是否能正确退出；

    7)     卸载过程中界面显示与提示语言是否准确、友好；

    8)     卸载后安装此系统能否打开原来保存的文件，并一切运行正常；

    9)     卸载程序如果要求重新启动机器，在重启动之间是否给用户提示以保存现有的己运行的程序的资料；

    10)  是否可以选择组件进行卸载；

    11)  卸载过程中，对意外情况的处理（掉电等）。

    12)  在卸载过程中，是否有终止或者结束按钮。

     

    3. 运行与关闭测试

    1)     运行时是否与其它应用程序有冲突(内存冲突)；

    2)     是否可以同时运行多个程序；

    3)     任务栏有无程序运行提示；

    4)     若有未保存的数据，关闭系统时是否有提示；

    5)     后台服务程序在点击关闭按钮时是否有确认提示；

    6)     运行时是否过份占用系统资源、退出时能否完成释放占用的系统资源。

     

    14、众多web服务，会不会有冲突等；

        a 是否可以识别大部分的硬件；对串口硬盘的支持；常见的显卡/声卡的支持；

        b 确认打包程序的特性，比如installshield,不同的打包发布程序所支持的系统都是不一样的，一个软件应该只能在确认的适应的系统上安装；

        c.空间不足的情况，安装过程中如果像安装盘放入大量文件；

        d.卸载过程不得删除系统应该保留的用户数据；

    卸载状态－－程序在运行/暂停/终止等状态时的卸载；

    卸载测试

        文件：安装目录里的文件及文件夹（如：程序安装在几处的)；

        非安装目录（向系统其它地方添加的文件及文件夹）；

        它们包括（exe,dll,配置文件等)

        快捷方式－（桌面，菜单，任务栏，系统栏,控件面板，系统服务列表等）；

        复原方面－卸载后，系统能否恢复到软件安装前的状态（包含目录结构、动态库,注册表，系统配置文件,驱动程序,关联情况等）(专门的测试工具regsnap)

        卸载方式－－程序自带卸载程序/系统的控件面板卸载/其它自动卸载工具（如:优化大师)；

        卸载状态－－程序在运行/暂停/终止等状态时的卸载；

        非正常卸载情况－卸载软件过程中，取消卸载进程，然后，观察软件能否继续正常使用；

       

    非正常卸载情况－卸载软件过程中，取消卸载进程，然后，观察软件能否继续正常使用；

        冲击卸载－－在卸载的过程中，中断电源，然后，启动计算机后，重新卸载软件，如果软件无法卸载，则重新安装软件，安装之后再重新卸载；

        卸载环境－－不同的(操作系统，硬件环境，网络环境等)下进行卸载；

        卸载后,该系统是否对其他的应用程序造成不正常影响（如操作系统,应用软件等)；

     

    如果不是自动安装，而是选择安装，要选择不同的安装组件进行组合，查看是否安装成功；

    2、安装成功后，确认应用程序是否可以正常启动、运行；

    3、如果系统提供自动卸载功能，卸载之后检查是否所有的文件都删除干净，还要检查是否注册表也删除了相应的注册信息

    4、至少要在一台笔记本上安装测试，很多产品会在笔记本中出现问题；

    5、安装完成之后，要在简单的操作之后再卸载

    6、如果是c/s的，可以先安装客户端，再安装服务器，查看是否存在问题

    7、安装之后是否会对其他系统造成影响。

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

  • 数据库测试

    2009-02-04 11:50:31

    数据库测试


    随着软件业的迅猛发展，我们的开发也从以前的单层结构进入了三层架构甚至现在多层架构的设计，而数据库从以前一个默默无闻的后台仓库，逐渐成为了数据库系统，而数据库开发设计人员成为了炙手可热的核心人员。以前我们往往把数据库操作写在应用层，从而提高各个模块的独立性和易用性，而现在越来越多的数据库操作被作为存储过程直接放在数据库上进行执行来提高执行效率和提高安全性。

    数据库开发既然在软件开发的比重逐步提高，随之而来的问题也突出。我们以前往往重视对代码的测试工作，随着流程技术的日益完善，软件质量得到了大幅度的提高，但数据库方面的测试仍然处于空白。我们从来没有真正将数据库作为一个独立的系统进行测试，而是通过对代码的测试工作间接对数据库进行一定的测试。随着数据库开发的日益升温，数据库测试也需要独立出来进行符合自身特点的测试工作。数据库开发和应用开发并没有实质上的区别，所以软件测试的方法同样适用于数据库测试

     

    从测试过程的角度来说我们也可以把数据库测试分为

    系统测试

    传统软件系统测试的测试重点是需求覆盖，而对于我们的数据库测试同样也需要对需求覆盖进行保证。那么数据库在初期设计中也需要对这个进行分析,测试.例如存储过程，视图，触发器，约束，规则等我们都需要进行需求的验证确保这些功能设计是符合需求的.另一方面我们需要确认数据库设计文档和最终的数据库相同，当设计文档变化时我们同样要验证改修改是否落实到数据库上。

    这个阶段我们的测试主要通过数据库设计评审来实现。

     

    集成测试

    集成测试是主要针对接口进行的测试工作，从数据库的角度来说和普通测试稍微有些区别对于数据库测试来说，需要考虑的是

    数据项的修改操作

    数据项的增加操作

    数据项的删除操作

    数据表增加满

    数据表删除空

    删除空表中的记录

    数据表的并发操作

    针对存储过程的接口测试

    结合业务逻辑做关联表的接口测试

    同样我们需要对这些接口考虑采用等价类、边界值、错误猜测等方法进行测试

     

    单元测试

    单元测试侧重于逻辑覆盖，相对对于复杂的代码来说，数据库开发的单元测试相对简单些，可以通过语句覆盖和走读的方式完成

     

    系统测试相对来说比较困难，这要求有很高的数据库设计能力和丰富的数据库测试经验。而集成测试和单元测试就相对简单了。

     

    而我们也可以从测试关注点的角度对数据库进行分类

    功能测试

    对数据库功能的测试我们可以依赖与工具进行

    DBunit

    一款开源的数据库功能测试框架，可以使用类似与Junit的方式对数据库的基本操作进行白盒的单元测试，对输入输出进行校验

    QTP

    大名鼎鼎的自动测试工具，通过对对象的捕捉识别，我们可以通过QTP来模拟用户的操作流程，通过其中的校验方法或者结合数据库后台的监控对整个数据库中的数据进行测试。个人觉得比较偏向灰盒。

    DataFactory

    一款优秀的数据库数据自动生成工具，通过它你可以轻松的生成任意结构数据库，对数据库进行填充，帮助你生成所需要的大量数据从而验证我们数据库中的功能是否正确。这是属于黑盒测试

     

     

    数据库性能

    虽然我们的硬件最近几年进步很快，但是我们需要处理的数据以更快的速度在增加。几亿条记录的表格在现在是司空见惯的，如此庞大的数据量在大量并发连接操作时，我们不能像以前一样随意的使用查询，连接查询，嵌套查询，视图，这些操作如果不当会给系统带来非常巨大的压力，严重影响系统性能

    性能优化分4部分

    1物理存储方面

    2逻辑设计方面

    3数据库的参数调整

    4SQL语句优化.

    我们如何对性能方面进行测试呢，业界也提供了很多工具

     

    通过数据库系统的SQL语句分析工具，我们可以分析得到数据库语句执行的瓶颈，从而优化SQL语句

    Loadrunner

    这个不用多说，我们可以通过对协议的编程来对数据库做压力测试

    Swingbench（这是一个重量级别的feature，类似LR，而且非常强大，只不过专门针对oracle而已）

    数据库厂商也意识到这点，例如

    oracle11g已经提供了real application test，提供数据库性能测试，分析系统的应用瓶颈。

    还有很多第三方公司开发了SQL语句优化工具来帮助你自动的进行语句优化工作从而提高执行效率。

     

    安全测试

    软件日益复杂，而数据又成为了系统中重中之重的核心，从以往对系统的破坏现在更倾向于对数据的获取和破坏。而数据库的安全被提到了最前端

    自从SQL 注入攻击被发现，冒失万无一失的数据库一下从后台变为了前台，而一旦数据库被攻破，整个系统也会暴露在黑客的手下，通过数据库强大的存储过程，黑客可以轻松的获得整个系统的权限。而SQL的注入看似简单缺很难防范，对于安全测试来说，如何防范系统被注入是测试的难点。

    业界也有相关的数据库注入检测工具，来帮助用户对自身系统进行安全检测。

     

    对于这点来说业界也有标准，例如ISO IEC 21827，也叫做SSE CMM 3.0，是CMM和ISO的集成的产物，专门针对系统安全领域的

     

    另外一方面，数据库的健壮性，容错性和恢复能力也是我们测试的要点

     

    我们也可以发现功能测试，性能测试，安全测试，是一个由简到繁的过程，也是数据库测试人员需要逐步掌握的技能，这也是以后公司对数据库测试人员的要求。

     

     

     

         很幸运能上这节'云'老师的课，一是在数据库测试、测试这方面听到了很多思路，一天的课一定不会涉及到很多具体的内容，思路就在足够了；另外更了解了自己一个很严重的缺陷，就是不擅长把简单的问题考虑周全，做深做好，学习也一样，不善于把东西学得更深入一些，不好的本性，得改；还有就是上课本身也很愉快～

            数据库测试

            范式
            范式：范式是关系数据库在设计的时候要遵守的一些规则，最常用的有1NF,2NF,3NF，还有BCNF
            1NF:数据库的每个字段都是单一属性，不可再分。（很好理解）
            2NF：数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖，也就是任何的非关键字段都依赖于任何一组关键字段。（也就是当骷辛礁鲆陨献侄问保渲幸桓霾荒艿ザ谰龆ㄎㄒ环侵骷侄危?BR>3NF：在2NF的基础上，不存在任意非关键字段对其他非关键字段的函数依赖（所有非关键字段都必须是由主键来决定的，而不能一部分非关键字段有某个非关键字段决定）

            数据库建模
            待学习…………
            想要发现数据库设计的问题，必须要很好的了解数据库设计，这是必然。

            数据库系统测试的对象
            数据库设计是否与实现相同。这是最容易做到的一点。如果没有数据库设计文档怎么办？逆向工程，可以用工具将数据库sql导出，再转换成关系图
            数据库设计是否符合范式
            数据库设计是否合理 经验
            数据库安装、配置测试

            数据库集成测试对象
            数据库的增删改操作
            数据表加满（这里的加满是指加满数据文件所在磁盘空间，可以为其分配一个小的磁盘空间，逆向思维）
            数据表空
            删除空表记录
            数据表的并发操作（即使数据库做了主键约束，在并发很多的时候也会导致插入重复主键的数据，就会导致数据库的死锁，down掉）
            针对存储过程的接口测试：也可以编写驱动和桩
            结合业务逻辑做关联表的接口测试

            数据库单元测试的重点
            语句覆盖
            走读
            eg：已知yx表，包括id，salary字段，中间2～10省略，另有yg表中的salary字段与yx.id有外键约束，要更新yg中的salary，为每个人加1级，如何写sql语句
            update yg set salary = salary + 1 对吗？


             id
              salary
             0  面议
             1  1500以下
            …   …
             11  20000以上

     

            1）11不能再加
            2）0不能加  update yg set salary = salary + 1 where salary > 0 and salary < 11;
            3）如果有4.5这样的数据怎么办？
            update yg set salary = salary + 1 where salary in (1,2,3,4,5,6,7,8,9,10);
            4）如果更新错了怎么办？写成一个事务，可以commit，rollback
            5）假设yx表中的数据发生变化了怎么办？还需要修改sql语句

            （讨厌，死机了）
            最后俺写的是
            select * from yg;
            update yg set salary = salary + 1
            where salary in ( select id from yx)
            and salary > ( select min(id) from yx)
            and salary < ( select max(id) from yx);
            关于第4）数据库事务，sqlserver有三种事务类型，隐式，显示，自动提交，默认为自动提交，可以设置
            set implicit_transactions on设置为隐式事务，就是需要另外输入commit 或rollback 来结束事务
            http://kyle.itpub.net/post/1626/10699

            数据库功能测试
            DataFactory 自动数据库数据生成器

            数据库性能测试
            Loadrunner
            Swingbench 专门针对Oracle

            性能优化考虑的顺序
            磁盘存储
            数据库设置
            数据库设计
            sql语句

            数据库安全测试
            sql注入
            数据库的健壮性  严格的检查约束，主外键约束等
            数据库的容错性
            数据库自身的恢复能力

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

  • bug 生命周期

    2009-02-04 11:23:57

    bug生命周期中的各种状态

    所有软件开发过程的目的都是为客户（软件产品的终端用户）提供一个解决问题的方案（软件产品），以帮助客户更加高效地工作或生活（从时间和费用上来讲）。一个成功的软件开发过程就是为客户提供了所有他所要求的需求。

    一个没有软件测试的软件开发过程是不完善的。软件测试是为了寻找并修复软件中的bug/错误，它可以帮助提高软件的质量，以保证用户可以正常使用软件产品。

    什么是一个bug/错误？
    软件中的bug 或者错误就是所有会影响软件整体或者部分功能的正常运行的软件行为。

    怎样找到bug/错误？
    我们主要依靠运行测试脚本或用例来找出那些软件产品中的不想看到的行为。

    什么是测试用例？
    测试用例是一类文档，测试用例中包含有用于执行的步骤或行为，而我们需要严格地按照这些步骤来执行以确认软件是否按照我们对它的期望执行。

    发现bug或者错误后该怎么办？
    一般在我们发现bug或者错误后，应该和开发人员交流以修复它。

    从一个bug被发现到这个bug被关闭这一段时间，bug可能会有以下状态：new ，open Postpone，Pending Retest，Retest,Pending Reject,Reject,Deferred,closed.(请注意这里有很多种状态，我们需要根据不同情况来决定怎样或者是否需要跟开发人员沟通)

    从一个bug被发现到这个bug被关闭这一段时间，bug可能会有以下状态：new ，open Postpone，Pending Retest，Retest,Pending Reject,Reject,Deferred,closed.(请注意这里有很多种状态，我们需要根据不同情况来决定怎样或者是否需要跟开发人员沟通)
    下面就对这几种状态进行以下解释：

    New:（新的）
    当某个“bug”被发现的时候（第一次），测试人员需要与项目负责人沟通以确认发现的的确是一个bug，如果被确认是一个bug，就将其记录下来，并将bug的状态设为New

    Assigned（已指派的）
    当一个bug被指认为New之后，将其将给开发人员，开发人员将确认这是否是一个bug，如果是，开发组的负责人就将这个bug指定给某位开发人员处理，并将bug的状态设定为“Assigned”

    Open（打开的）

    一旦开发人员开始处理bug的时候，他（她）就将这个bug的状态设置为“Open”，这表示开发人员正在处理这个“bug”

    Fixed（已修复的）

    当开发人员进行处理（并认为已经解决）之后，他（她）就可以将这个bug的状态设置为“Fixed”并将其提交给开发组的负责人，然后开发组的负责人将这个bug返还给测试组

    Pending Reset（待在测试的）

    当bug被返还到测试组后，我们将bug的状态设置为“Pending Reset”

    Reset(再测试)

    测试组的负责人将bug指定给某位测试人员进行再测试，并将bug的状态设置为“Reset”

    Closed（已关闭的）

    如果测试人员经过再次测试之后确认bug已经被解决之后，就将bug的状态设置为“Closed”

    Reopen（再次打开的）

    如果经过再次测试发现bug（指bug本身而不是包括因修复而引发的新bug）仍然存在的话，测试人员将bug再次传递给开发组，并将bug的状态设置为“Reopen”

    Pending Reject（拒绝中）

    如果测试人员传递到开发组的bug被开发人员认为是正常行为而不是bug时，这种情况下开发人员可以拒绝，并将bug的状态设置为“Pending Reject”

    Rejected(被拒绝的)

    测试组的负责人接到上述bug的时候，如果他（她）发现这是产品说明书中定义的正常行为或者经过与开发人员的讨论之后认为这并不能算作bug的时候，开发组负责人就将这个bug的状态设置为“Rejected”

    Postponed（延期）

    有些时候，对于一些特殊的bug的测试需要搁置一段时间，事实上有很多原因可能导致这种情况的发生，比如无效的测试数据，一些特殊的无效的功能等等，在这种情况下，bug的状态就被设置为“Postponed”

    Deferred（延期的）bug生命周期中的各种状态

    有些情况一些特殊的bug显得不那么重要，同时也是可以消除的，这个时候我们可以将bug的状态设置为“Deferred”

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

  • 测试的种类

    2009-02-03 18:02:23

    系统测试的定义：
       系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不相符合或与之矛盾的地方。

    系统测试的对象：
      系统测试的对象不仅仅包括需要测试的产品系统的软件，还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。因此，必须将系统中的软件与各种依赖的资源结合起来，在系统实际运行环境下来进行测试

    系统测试的设计
       系统测试过程包含了测试计划、测试设计、测试实施、测试执行、测试评估这几个阶段，而整个测试过程中的测试依据主要是产品系统的需求规格说明书、各种规范、标准和协议等。在整个测试过程中，首先需要对需求规格进行充分的分析，分解出各种类型的需求（功能性需求、性能要求、其他需求等），在此基础之上才可以开始测试设计工作，而测试设计又是整个测试过程中非常重要的一个环节，测试设计的输出结果是测试执行活动依赖的执行标准，测试设计的充分性决定了整个系统过程的测试质量。因此，为了保证系统测试质量，必须在测试设计阶段就对系统进行严密的测试设计。这就需要我们在测试设计中，从多方面来综合考虑系统规格的实现情况。通常需要从以下几个层次来进行设计：用户层、应用层、功能层、子系统层、协议层

    3.1、用户层：
         主要是面向产品最终的使用操作者的测试。这里重点突出的是在操作者角度上，测试系统对用户支持的情况，用户界面的规范性、友好性、可操作性，以及数据的安全性。主要包括：
    3.1.1、用户支持测试
         用户手册、使用帮助、支持客户的其他产品技术手册是否正确、是否易于理解、是否人性化。
    3.1.2、用户界面测试
         在确保用户界面能够通过测试对象控件或入口得到相应访问的情况下，测试用户界面的风格是否满足用户要求，例如：界面是否美观、界面是否直观、操作是否友好、是否人性化、易操作性是否较好。
    3.1.3、可维护性测试
        可维护性是系统软、硬件实施和维护功能的方便性。目的是降低维护功能对系统正常运行带来的影响。例如：对支持远程维护系统的功能或工具的测试。
    3.1.4、安全性测试
        这里的安全性主要包括了两部分：数据的安全性和操作的安全性。核实只有规格规定的数据才可以访问系统，其他不符合规格的数据不能够访问系统；核实只有规格规定的操作权限才可以访问系统，其他不符合规格的操作权限不能够访问系统；

     

    3.2、应用层：
         针对产品工程应用或行业应用的测试。重点站在系统应用的角度，模拟实际应用环境，对系统的兼容性、可靠性、性能等进行的测试。
    3.2.1、系统性能测试
         针对整个系统的测试，包含并发性能测试、负载测试、压力测试、强度测试、破坏性测试。并发性能测试是评估系统交易或业务在渐增式并发情况下处理瓶颈以及能够接收业务的性能过程；强度测试是在资源情况低的情况下，找出因资源不足或资源争用而导致的错误；破坏性测试重点关注超出系统正常负荷N倍情况下，错误出现状态和出现比率以及错误的恢复能力。
    3.2.2、系统可靠性、稳定性测试
         一定负荷的长期使用环境下，系统可靠性、稳定性。
    3.2.3、系统兼容性测试
         系统中软件与各种硬件设备兼容性，与操作系统兼容性、与支撑软件的兼容性。
    3.2.4、系统组网测试
         组网环境下，系统软件对接入设备的支持情况。包括功能实现及群集性能。
    3.2.5、系统安装升级测试
         安装测试的目的是确保该软件在正常和异常的不同情况下进行安装时都能按预期目标来处理。例如，正常情况下，第一次安装或升级、完整的或自定义的安装都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。还有一个目的是核实软件在安装后可立即正常运行。另外对安装手册、安装脚本等也需要关注。

     

    3.3、功能层
         针对产品具体功能实现的测试。
    3.3.1、业务功能的覆盖
         关注需求规格定义的功能系统是否都已实现。
    3.3.2、业务功能的分解
         通过对系统进行黑盒分析，分解测试项及每个测试项关注的测试类型。
    3.3.3、业务功能的组合
         主要关注相关联的功能项的组合功能的实现情况。
    3.3.4、业务功能的冲突
         业务功能间存在的功能冲突情况。比如：共享资源访问等。

     

    3.4、子系统层
         针对产品内部结构性能的测试。关注子系统内部的性能，模块间接口的瓶颈。
    3.4.1、单个子系统的性能
         应用层关注的是整个系统各种软、硬件、接口配合情况下的整体性能，这里关注单个系统。 3.4.2、子系统间的接口瓶颈
         例如：子系统间通讯请求包的并发瓶颈。
    3.4.3、子系统间的相互影响
         子系统的工作状态变化对其他子系统的影响。

     

    3.5、协议/指标层
         针对系统支持的协议、指标的测试。
    3.5.1、协议一致性测试
    3.5.2、协议互通测试

     

     

    计算机软件是基于计算机系统的一个重要组成部分，软件开发完毕后应与系统中其它成分集成在一起，此时需要进行一系列系统集成和确认测试。对这些测试的详细讨论已超出软件工程的范围，这些测试也不可能仅由软件开发人员完成。在系统测试之前，软件工程师应完成下列工作：

    　　（1） 为测试软件系统的输入信息设计出错处理通路；

    　　（2） 设计测试用例，模拟错误数据和软件界面可能发生的错误，记录测试结果，为系统测试提供经验和帮助；

    　　（3） 参与系统测试的规划和设计，保证软件测试的合理性。　　

    　　系统测试应该由若干个不同测试组成，目的是充分运行系统，验证系统各部件是否都能政党工作并完成所赋予的任务。下面简单讨论几类系统测试。

    　　１、恢复测试

    　　恢复测试主要检查系统的容错能力。当系统出错时，能否在指定时间间隔内修正错误并重新启动系统。恢复测试首先要采用各种办法强迫系统失败，然后验证系统是否能尽快恢复。对于自动恢复需验证重新初始化（reinitialization）、检查点(checkpointing mechanisms)、数据恢复(data recovery)和重新启动 (restart)等机制的正确性；对于人工干预的恢复系统，还需估测平均修复时间，确定其是否在可接受的范围内。

    　　２、安全测试

    　　安全测试检查系统对非法侵入的防范能力。安全测试期间，测试人员假扮非法入侵者，采用各种办法试图突破防线。例如，①想方设法截取或破译口令；②专门定做软件破坏系统的保护机制；③故意导致系统失败，企图趁恢复之机非法进入；④试图通过浏览非保密数据，推导所需信息，等等。理论上讲，只要有足够的时间和资源，没有不可进入的系统。因此系统安全设计的准则是，使非法侵入的代价超过被保护信息的价值。此时非法侵入者已无利可图。

    　　３、强度测试

    　　强度测试检查程序对异常情况的抵抗能力。强度测试总是迫使系统在异常的资源配置下运行。例如，①当中断的正常频率为每秒一至两个时，运行每秒产生十个中断的测试用例；②定量地增长数据输入率，检查输入子功能的反映能力；③运行需要最大存储空间（或其他资源）的测试用例；④运行可能导致虚存操作系统崩溃或磁盘数据剧烈抖动的测试用例，等等。

    　　４、 性能测试

    　　对于那些实时和嵌入式系统，软件部分即使满足功能要求，也未必能够满足性能要求，虽然从单元测试起，每一测试步骤都包含性能测试，但只有当系统真正集成之后，在真实环境中才能全面、可靠地测试运行性能系统性能测试是为了完成这一任务。性能测试有时与强度测试相结合，经常需要其他软硬件的配套支持。

     

    阶段         产出

    1. 计划——《系统测试计划》
    2. 设计——《系统方案》（系统测试项和系统测试子项）
    3. 实现——《系统测试用例》
    4. 执行——《测试报告》

    概念：将已经集成好的软件系统，与其他系统元素结合在一起，在实际运行环境下，进行一系列的测试活动。

    目的：验证系统对需求的符合程度；

    对象：软硬件集成一起的系统，并尽可能地在实际运行环境与条件；

    常用类型：

    1、功能测试——（针对软件质量中）“功能性”

    目的：根据产品的需求规格说明书和测试列表，验证产品的功能实现是否符合需求规格；

    关注点：

    • 功能是否遗漏
    • 功能实现是否满足用户需求和系统设计的隐性需求
    • 输入能否正确接受，输出结果是否正确

    测试方法：等价类、边界值、判定表、因果图、正交、状态迁移、流程分析……

    2、性能测试——“效率”

    目的：测试软件集成系统中运行的性能，度量系统相对于目标的差距；

    为什么要进行性能测试呢？

    • 因为它是产品质量的重要组成部分；
    • 用户眼中的良好形象；
    • 节省成本（主要是物理设备成本）的重要手段

    性能指标是怎么定义的？（需求规格中的）

    • 直接提出的性能指标
    • 以某个版本为基准
    • 与竞争对手的同类产品的比较

    性能指标的特征：

    • 需求性（设计出来的）
    • 代表性
    • 可用性
    • 可测性
    • 完整性：从三个方面——能力（请求量，在线用户量等）、质量（响应率，正确率，延时）、软硬件配置（物理设备）

    按目的分类：

    • 产品性能质量测试（有指标定义）
    • 基准性测试（无指标定义）
    • 性能规划测试（有指标定义）

    性能测试的基本步骤：（是一个反复执行，重复优化的过程）

    1. 性能测试需求分析
    2. 业务功能验证
    3. 测试环境准备
    4. 测试脚本与数据准备
    5. 测试场景分析
    6. 测试场景监控
    7. 测试执行
    8. 结果分析

    性能测试结论（明确的）

    • 指标类：明确产品在不同条件下的性能指标；
    • 稳定类：系统是否稳定，每个模块是否稳定；
    • 对比类：通过好坏对比来知道差距；
    • 验证类：通过与否；
    • 优化类：优化方向，优化效果

    3、压力测试（stree Testing）——“效率、可靠性”

    目的：验证系统在其资源超负荷的情况下的表现（自我保护能力、可靠性），发现性能瓶颈、优化系统；

    分类：

    • 稳定性压力测试
    • 破坏性压力测试

    4、容量测试（Volume Testing）——“效率”

    目的：验证系统在不同配置、不同场景下能正确处理的最大业务量；

    对象：面向数据的；

    5、负载测试

    目的：

    6、安全性测试

    7、图形用户界面（GUI）测试

    8、可用性测试

    9、安全性测试

    10、配置测试

    11、兼容性测试

    12、异常测试

    13、备份测试

    14、健壮性测试

    15、文档测试

    16、在线帮助测试

    17、网络测试

    18、稳定性测试

     

    系统测试，是测试生命周期中最为重要的一个环节：
    系统测试
    1、 适用对象
    由开发部门提供给测试部的最终系统。
    2、 进入条件
    (1) 已经完成集成测试。
    (2) 该系统可以运行在真实或仿真的环境下。
    3、 测试内容
    测试该系统是否达到了系统需求和功能规格说明中的要求，一般需要进行以下几方面的测试：
    (1) 功能测试。
    (2) 性能测试。
    (3) 外部接口测试。
    (4) 人机界面测试。
    (5) 强度测试。
    (6) 冗余测试。
    (7) 可靠性测试。
    (1) 安全性测试。
    (9) 恢复测试。
    4、 具体要求
    (1) 由项目负责人决定具体进行那些方面的测试，但至少应该进行功能和性能测试。
    (2) 系统测试采用功能测试的方法。
    (3) 必须编写正式的系统测试计划。
    (4) 系统测试可以在开发环境中进行。
    (5) 系统测试组组长应由高级应用专家担任。
    (6) 系统测试过程中必须对用户手册进行评价，找出用户手册与实际操作结果的差异。
    (7) 系统测试由测试部负责开展，开发小组予以配合。
    5、 实施步骤
    (1) 在需求分析阶段开始准备【系统测试计划】，并且在设计阶段加以细化更新，在实现阶段最终确定下来。
    (2) 建系统测试环境，完成测试设计和开发，准备测试数据。
    (3) 执行系统测试用例，并且详细记录测试结果。
    (4) 判定测试用例是否通过。
    (5) 提交系统测试报告。
    (6) 完成交付测试计划。
    6、 分析评估
    根据【概要设计说明书】、【详细设计说明书】、系统测试结果和发现的错误信息，评价系统的设计与实现。
    7、 通过准则
    (1) 完全执行了系统测试计划中的每个测试用例。
    (2) 在系统测试中发现的错误已经得到修改并且通过了测试。
    (3) 完成软件系统测试报告。
    (4) 交付测试计划已经完成。

    瀑布模型需要完整的需求分析,没有迭代的过程. 而迭代模型可以在设计过程中不断的更新,完善需求分析.我觉得瀑布模型不过是一个元素,每个模型中必不可少的有瀑布模型.迭代模型是n个瀑布模型的叠加罢了.

    瀑布式模型适合的项目要有以下两个特征：  

      1、需求明确；  

      2、需求稳定，基本上没有变化，或者没有关键性变化。  

      其他的没有限制。

    原型：简单说,是当软件需求不明确的时候,先做个样品,给客户看一下,看是否是客户所要得.  

        原型可分为抛弃原型和非抛弃原型.在客户确认了需求之后,抛弃原型就作废了;而非抛弃原形是以后继续开发的基础(非抛弃模型可以理解为螺旋模型的一次周期).  

        开发非抛弃原形要比开发抛弃原形成本高,因为非抛弃原形在设计和实现时必须考虑质量特性,而抛弃原形则不必.  

        我个人认为,在需求完全不明确的情况下,以抛弃原型为宜;但项目太大时,应选用螺旋模型.

    增量

    螺旋型：Barry Boehm正式发表了软件系统开发的"螺旋模型"，它将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。

    螺旋模型沿着螺线进行若干次迭代，图中的四个象限代表了以下活动：

     

    （1） 制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；

     

    （2） 风险分析：分析评估所选方案，考虑如何识别和消除风险；

     

    （3） 实施工程：实施软件开发和验证；

     

    （4） 客户评估：评价开发工作，提出修正建议，制定下一步计划

    一个阶段首先是确定该阶段的目标，完成这些目标的选择方案及其约束条件，然后从风险角度分析方案的开发策略，努力排除各种潜在的风险，有时需要通过建造原型来完成。如果某些风险不能排除，该方案立即终止，否则启动下一个开发步骤。最后，评价该阶段的结果，并设计下一个阶段。

    兼容测试是测试软件在一个特定的硬件/软件/操作系统/网络等环境下的性能如何。向上兼容向下兼容，软件兼容硬件兼容。软件的兼容性有很多需要考虑的地方

    探索测试是指通常用于没有产品说明书的测试，这需要把软件当作产品说明书来看待，分步骤逐项探索软件特性，记录软件执行情况，详细描述功能，综合利用静态和动态技术来进行测试。探索测试人员只靠智能、洞察力和经验来对bug的位置进行判断,所以探索测试又被称为自由形式测试。

    可移植性测试是指测试软件是否可以被成功移植到指定的硬件或软件平台上

    可移植性测试是指测试软件是否可以被成功移植到指定的硬件或软件平台上

    用户界面，英文是User interface。是指软件中的可见外观及其底层与用户交互的部分（菜单、对话框、窗口和其它控件）。

     

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

     

    用户界面测试用户分析软件用户界面的设计是否合乎用户期望或要求。它常常包括菜单，对话框及对话框上所有按钮，文字，出错提示，帮助信息 (Menu 和Help content)等方面的测试。比如，测试Microsoft Excel中插入符号功能所用的对话框的大小，所有按钮是否对齐，字符串字体大小，出错信息内容和字体大小，工具栏位置/图标等等。

    健全测试是指一个初始化的测试工作，以决定一个新的软件版本测试是否足以执行下一步大的测试努力。例如，如果一个新版软件每5分钟与系统冲突，使系统陷于泥潭，说明该软件不够“健全”，目前不具备进一步测试的条件。

    静态测试指测试不运行的部分，例如测试产品说明书，对此进行检查和审阅.。静态方法是指不运行被测程序本身，仅通过分析或检查源程序的文法、结构、过程、接口等来检查程序的正确性。静态方法通过程序静态特性的分析，找出欠缺和可疑之处，例如不匹配的参数、不适当的循环嵌套和分支嵌套、不允许的递归、未使用过的变量、空指针的引用和可疑的计算等。静态测试结果可用于进一步的查错，并为测试用例选取提供指

    集成测试是指一个应用系统的各个部件的联合测试，以决定他们能否在一起共同工作并没有冲突。部件可以是代码块、独立的应用、网络上的客户端或服务器端程序。这种类型的测试尤其与客户服务器和分布式系统有关。一般集成测试以前，单元测试需要完成。

     

    集成测试是单元测试的逻辑扩展。它的最简单的形式是：两个已经测试过的单元组合成一个组件，并且测试它们之间的接口。从这一层意义上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合成程序的更大部分。方法是测试片段的组合，并最终扩展进程，将您的模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试。此外，如果程序由多个进程组成，应该成对测试它们，而不是同时测试所有进程。

     

    集成测试识别组合单元时出现的问题。通过使用要求在组合单元前测试每个单元，并确保每个单元的生存能力的测试计划，可以知道在组合单元时所发现的任何错误很可能与单元之间的接口有关。这种方法将可能发生的情况数量减少到更简单的分析级别。

    可接受性测试是在把测试的版本交付测试部门大范围测试以前进行的对最基本功能的简单测试。因为在把测试的版本交付测试部门大范围测试以前应该先验证该版本对于所测试的功能基本上比较稳定。必须满足一些最低要求。比如不会很容易程序就挂起或崩溃。如果一个新版本没通过可测试性的验证，就应该阻拦测试部门花时间在该测试版本上测试。同时还要找到造成该版本不稳定的主要缺陷并督促尽快加以修正

     

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

  • web 测试技巧

    2008-12-30 16:14:20

    测试人员容易遗漏一些隐藏的缺陷

      

    通常软件测试会暴露软件中的缺陷，经过修正后可以保证软件系统的功能满足需求并正确运行。但是，在系统测试和确认测试中，测试人员容易遗漏一些隐藏的缺陷。众所周知，软件测试不可能发现所有的缺陷，而软件开发周期各个阶段仍然存在注入缺陷的可能，但是，有一些缺陷是测试中容易忽略的，也就是说，通过测试方法和用例可以充分暴露这些缺陷，遗憾的是，它们往往被忽略或者某种原因忘记测试了，这就给软件留下了隐患或者危机。这些容易被忽略的缺陷包括：

     

    1、安装缺陷

     

    通常项目组完成代码后，发布时候安装打包是最后一个环节，而软件测试人员通常在测试的时候，没有仔细的测试这一部分，而把用例集中在其他功能上。安装时候的缺陷通常通过拷贝而不是运行安装程序方式给测试人员安装软件，结果正式安装时候出现问题，引起例如控件没有注册，注册表没有导入等。删除时候没有注意安装文件夹是否存在用户文件，造成数据丢失;使用绝对路径;安装顺序没有说明书。

     

    2、配置文件

     

    有些文件在ini等配置文件中写出了管理员口令密码等信息，而且是明文的!这是一个安全隐患。另外，有些安装文件的 XML 文件，为了方便在数据库和中间层连接文件中写入了Admin 口令和密码。作为一个合格的软件测试人员，必须检查这些可以用记事本打开的文件。因为，一个稍有常识而且喜欢探索的用户，可能从中获取信息而成为不自觉的黑客。所以，配置文件可能成为软件安全方面的一个缺陷。

     

    3、网页安全缺陷

     

    现在网站开发已经注意到：登陆网站进入其内部网页后，直接拷贝网址，然后粘贴到另一IE 窗口输入，可以绕过登陆直接访问。也许商业网站很关注这个问题，但是很多行业软件却很容易忽略。

     

    网页安全缺陷还可能存在于 IE 弹出的子窗口。有些设计不严格的软件，在主页面关闭的时候子页面还可以运行，这是一个明显的漏洞，而且还大大增加了错误发生的几率。

     

    4、判断顺序/逻辑缺陷

     

    对界面进行多个输入判断的时候，非常容易出现这种问题。例如判断年月顺序，判断长度，判断非空等。假如操作员仅仅满足单个条件，保存不能成功;而按界面从上之下顺序一一满足条件之后，保存是没有问题的。但是，改变一下输入的次序，校验失效。例如，一一满足条件之后，不保存，倒过来将上面的输入改成非法输入，然后保存，结果居然也能成功，这是因为原先的判断由于发生过，或者根据语句顺序只检查最后一个判断，所以没有报错。这种错误尤其在 Java scrīpt 脚本的页面中要注意。能够保存不能保证数据正确，有可能引起系统崩溃或者后续数据错误。所以，在测试的时候，不要按照正常的顺序输入，而是要打乱步骤，看看代码是否强健，是否在判断逻辑上没有错误。良好的代码应该经得起折腾，至少保存时会再此全部进行判断，而不只是简简单单走到判断的最后一行。

     

    5、调试语句和冗余信息

     

    维护项目和升级改造的推广系统最容易潜伏这类缺陷。典型表现在没有删除或者屏蔽调试语句。弹出一个界面不友好的提示信息，会使不明真相的用户产生误以为系统发生了严重故障，从而引起对软件的不信任感。页面中某个角落存在当前客户不需要的冗余按钮和功能也是一种缺陷。多余的功能会使用户以为是额外附加部分而去使用，其结果可想而知;而多余的按钮会误导好奇心强的用户操作，产生不必要的错误。

     

    同样值得关注的还有参数设置，由于没有实际数据，开发人员在调试或者单元测试的时候，习惯性的进行自我设定而忘了删除，软件测试人员可能会忽略掉了这部分测试，也可能导致在客户现场发生错误而影响系统发布和验收。

     

    6、不可重现的故障

     

    新参加软件测试的人员或者新来的开发人员总是要问，不可重现的缺陷是否需要记录，有必要吗?回答是肯定的。测试必须如实的记录发生的问题，也许不能重现，或者使非软件系统本身问题，但是，可能这些偶然性背后是有规律的，不记录这些，就不可能发现这些规律。

     

    7、多节点的逆向流转缺陷

     

    当前软件不少喜欢使用工作流来驱动。工作流的问题，就是可能出现多个流向分支。测试容易忽略的部分，就是工作流多节点的逆向流转。例如，通过不通过涉及两个分支，但是流程逆转的时候，有可能不是回到上一节点而是平级的另一个节点去了。软件测试要格外注意这类用例的设计。另外，有些时候默认分支在向前的时候是有默认值的，例如默认通过，那么保存的时候要提示用户是否通过，否则可能由于操作疲劳而走错了节点，引起回退。

     

    8、输入框缺陷

     

    试过往输入框粘贴数据而不是直接输入吗?可能这里会出现问题。按 Ctrl+V 的时候，输入框会根据长度大小自动截断输入长度。但是用鼠标，截断可能会失效。有一次测试人员就是用这种方法把一篇 Word 文档输入进去了，保存的时候，数据库崩溃。有些网站登陆的口令****可以拷贝下来的，只要放在剪贴板里面马上明文显示。

     

    输入框可以说是问题最多的部分，能够引起的麻烦也很多。日期、数字、文本等等，都需要耐心的测试一下。

     

    9、界面布局缺陷

     

    曾经有一次，项目经理回来向测试部反映一个问题，客户对界面不满意。原因很简单，因为界面上删除按钮和保存按钮挨得很近。结果有些操作不熟练的业务人员，很容易误按。这个问题是测试人员没有意料到的，因此注意关闭、删除、退出按钮与保存、下一步等按钮的距离。类似的按钮应按此规则排列分布。

     

    界面布局还可能发生在窗口最大化和最小化上，有可能窗口缩小的时候没有下拉框或不匹配分辨率，对用户来讲，这个错误实在很低级。有些用户由于操作习惯，非常不喜欢腾出手使用鼠标，尤其是大量输入的界面，因此，要注意设置键盘的快捷方式。还有，按 Tab定位到下一焦点时要注意顺序，避免跳转太灵活而让操作人员感到无从适应，在界面进行维护或者修改的时候，不要忘了软件测试开发人员是否无意改变了这些快捷方式和跳转顺序。

     

    10、版本和补丁包的环境问题

     

    理论上讲，这属于兼容性测试应该覆盖的问题。有些客户很喜欢更新最新的软件版本或者微软时不时打些补丁包，问题就出现了。有时候升级不一定是好事。这些问题最好在测试的时候增加几个用例，多用不同软件版本的机器跑一跑。软件测试有个定律是：你没跑过的地方，就一定会出事。经常听到开发人员抱怨，怎么我的机器没问题，你的机器就有事了呢?这不能完全靠配置管理员解决问题，环境配置项是大家最容易忽略的。

     

    11、用户管理缺陷

     

    用户管理的角色和授权需要好好研究一下，作过测试的人员都知道，有时候为了测试的方便，测试用户都是具有超级权限的用户。而且，比较容易忽略用户管理这一部分的测试。往往发往客户的时候，很多测试用户都没有删除。

     

    另外，有些接口的用户和口令，到软件使用寿命结束都没有更改过。在一次测试中，软件测试人员发现，给一个用户授超级用户权限，之后更改这个用户为受限权限。使用中发现，用户居然没有真正回收权限，用户管理界面上没有任何不对。及早准备用户管理用例，不要等到测试快结束时候才想起。

     

    12、常识缺陷

     

    从逻辑或者统计学上讲，计算机是允许如此处理的，但是从常识上来讲，这些情况不可能发生。例如电话号码不可能出现小数点，终止时间不能大于开始时间等等。除此之外，常识还要结合业务特点来进行判断，因此，开发和测试人员要格外注意对自己知识的培养以及增加对需求细节的了解。不能因为一味追求进度而采用最简单的代码来实现，对用户来说，这些错误可能是很荒谬的。

     

    尽管我们不可能完美的测试一个软件，但是我们仍然可以改进我们的软件测试。每次测试结束，及时总结测试中的不足，进一步完善用例。思考一下那些容易忽略的软件缺陷，能提高对软件测试的认识，提高所在组织软件的质量。

     

     

     

     

     

     

     

     

     

     

     

    十大负面测试用例

     

     

     

    2008-07-09 作者：朱少民 来源：网络

     

     

    负面测试(Negative testing)是相对于正面测试(Positive testing)而言的。它们也是测试设计时的两个非常重要的划分。简单点说，正面测试就是测试系统是否完成了它应该完成的工作;而负面测试就是测试系统是否不执行它不应该完成的操作。形象一点，正面测试就象一个毕恭毕敬的小学生，老师叫我做什么，我就做什么;而负面测试就象一个调皮捣蛋的孩子，你叫我这样做，我偏不这样做，而且和你对着干。开发人员也是最讨厌修改此类bug的。

     

    正面测试主要根据需求，功能说明书，设计文档等相关参考文档来执行测试，而负面测试则主要根据错误猜测，逆向思维来测试系统，一定程序上的的依赖测试人员的经验积累。

     

    执行负面测试时，不单单要测试系统是否处理了用户的异常操作，还要检查系统对于这些异常操作是否给予了正确的错误提示。它是系统对用户进行继续正确操作的指引。

     

    简言之负面测试的三部曲就是：

     

    1、检查程序中的屏幕或页面是否给出了清晰且充分的提示或约束;

     

    2、测试系统是否处理了用户的异常操作;

     

    3、检查系统的错误提示是否清晰且充分。

     

    以下是Steve Miller的《Top 10 Negative Test Cases》，概括性的提到了一些做负面测试时经常需要注意的测试。

     

    负面测试用例被设计于用软件未意欲被使用的方式测试软件，它也应该是测试工作的一部分。以下就是在设计测试工作量时你应该考虑的十大负面测试用例。

     

    1、植入的单引号。大多数基于SQL的数据库系统在用户存储包含一个单引号的信息时会出现问题，例如John's car。每一个可以接受文字数字型数据条目的屏幕都要试试输入包含一个或多个单引号的文本。

     

    【补充】其实不只是单引号，基本上测试人员应该测试所有的特殊字符和空/空格(单纯的空格和文本前后的空格)。单引号，逗号，/，<，>(对于web的应用程序)都是很容易引发错误的。在开发早期测试组就可以建议开发组写一个通用的函数来处理这些特殊字符，然后在处理用户的输入时套用这个函数就可以避免此类错误了。

     

    2、必需输入的数据条目。功能说明书上应该清楚的指出屏幕上必须输入数据条目的字段。测试屏幕上每一个被说明为必须输入的字段以保证它强制要求你在字段中输入数据。

     

    【补充】对于强制输入的字段，在屏幕上最好有些标识以说明其为必须输入的字段。一般在字段前或后用红色的*号表示。测试时必须要检查有标识的字段是否和功能说明书或其他参考文档一致，错误信息提示是否正确，强制输入的字段是否真的必须输入。

     

    3、字段类型测试。功能说明书上应该清楚的指出要求特定数据输入要求(日期字段，数字字段，电话号码，邮编等等)的字段。测试屏幕上每一个被指出有特定类型的字段以保证你输入了基于字段类型的符合正确格式的数据(数字型字段应该不允许字符或特殊字符，日期型的字段应该允许输入一个正确的日期等等)

     

    【补充】其实这里还有一个字段格式和字段内容的测试。有些字段对输入的格式有要求，这些字段的格式一般在屏幕上也有相应的提示。所以在测试时需要测试提示的格式是否合理(和功能说明书或其他参考文档相一致)以及系统是否正确识别输入的格式。有些字段对字段的内容有限制，如常见的用户名，不能包含特殊字符，首字不能未数字等要求。所以在测试时需要测试提示的格式是否合理(和功能说明书或其他参考文档相一致)还有不符合内容要求的数据输入时系统是否正确的处理。

     

    4、字段长度测试。功能说明书上应该清楚的指出可以在字段中输入的字符数(例如，first name必须是50个或更少的字符)。写测试用例以保证你只可以输入特定的字符数。防止用户输入比允许范围更多的字符比因用户已输入过多的字符而给出的错误信息更加的文雅些。

     

    【补充】一般对于限制长度的字段，现在开发大多采用限制输入的方法(设置字段的长度)来处理。所以测试时需要测试限制的长度是否合理(和功能说明书或其他参考文档相一致)，对于没有限制长度的字段，要测试无穷输入时是否出错，有问题报bug时建议开发人员根据需要限制长度。

     

    5、数字型的边界测试。对于数字型的字段，测试上下边界是非常重要的。例如，如果你正在计算某个账户的利息时，你永远不会输入一个负的利息数给应该赢取利息的账户。因此，你应该尝试用负数测试。同样，如果功能说明书上要求字段在某一个特定的范围(如从10～50)，你就应该尝试输入9或51，它应该给出一个得体的信息表示失败。

     

    6、数字的约束测试。大多数数据库系统和编程语言允许数字条目被识别为整数或长整数。通常，整数的范围是从-32,767~32,767，长整数的范围从-2,147,483,648~2,147,483,647。对于那些没有特定边界限制的数字数据条目，用这些限制测试以确保不会出现数字的溢出错误。

     

    【补充】小数型的数字字段同样也需要格外的测试。一般对于未指出数字类型的字段，尝试输入负整数，负小数，0，正整数，正小数进行测试。

     

    不管是哪种数据库系统，对于数字一般都有多种数字类型。所以测试人员一定要测试的全面。

     

    7、日期边界测试。对于日期型的字段，测试上下边界是很重要的。例如，如果你正在检查一个出生日期的字段，很大可能出生日期不能早于150年前。同样，出生日期应该不是将来的某一天。

     

    【补充】一般来说，每种数据库系统的日期都有个范围，如SQL Server最小日期是1753年1月1日，所以如果是输入型的日期字段同样也应该测试早于1753的日期。

     

    8、日期的有效性。对于日期字段，确保不允许无效的日期是很重要的(04/31/2007是一个无效的日期)。测试用例也应该检查闰年(每个第4年和第400年是一个闰年)。

     

    9、web会话测试。很多的web应用程序依赖浏览器的会话来追踪已登录的用户，应用程序的设置等等。应用程序的大多数屏幕不被设计为没有首次登录就可以被运行。应用程序应该确保在打开应用程序的某一页面之前会话里有一个有效的登录。

     

    10、性能的改变。当发布产品的最新版本时，应该有一套运行于识别屏幕(列出信息的屏幕，add/update/delete数据的屏幕等等)速度的性能测试。测试包里应该包括比较先前版本和现有版本性能统计值的测试用例。这个可以帮助识别那些可以证明是随着对现有版本的代码变更而引起的潜在的性能问题。

     

    【补充】从第一条到第八条是我们在测试字段时常常需要做的测试，一般的测试人员都不陌生。第九条在测试web应用程序中会作为检查应用程序的安全性而做的一项测试。而第十条估计很多公司都不会将它考虑到测试的范畴中，一般最多也就是在测试用例中添加校验某一个操作是否在系统允许的响应时间里，很少去做这样的比较，除了一些有针对性的性能测试。

     

     

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

211/212>
Open Toolbar