-
用户注册和密码修改测试点
2008-06-10 14:33:24
用户注册和密码修改测试点
一．用户注册
只从用户名和密码角度写了几个要考虑的测试点，如果需求中明确规定了安全问题，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.新密码与旧密码一样能否修改成功．
有个朋友问我,注册的时候测试了密码长度,修改的时候为什么还要测试.
我在这里举个我亲身经历的例子,以前我玩一个游戏,叫恋爱盒子,在游戏里我把密码改成了xuewufengtian,后来怎么也上不去了.因为资料填写不全无法找回密码.后来我在一次注册过程中发现,注册的时候密码长度最长是10位,这时我灵机一动,用了原来的用户名和xuewufengt的密码就进去了. 这表明,修改密码时候的最大长度和注册及登陆的时候密码最大长度有可能是不一致的. -
测试要点总结
2008-04-03 10:40:16
测试要点总结
环境配置测试
（1） 网络连接是否正常
（2） 网络流量负担是否过重
（3） 软件测试平台是否可选
（4） 如果（3），是否在不同的软件测试平台进行软件测试
（5） 所选软件测试平台的版本（包括Service Pack）是否正确
（6） 所选软件测试平台的参数设置是否正确
（7） 所选软件测试平台上正在运行的其它程序是否会影响测试结果
（8） 画面的分辨率和色彩设定是否正确
二、 代码测试
A． 静态测试
（1） 同一程序内的代码书写是否为同一风格
（2） 代码布局是否合理、美观
（3） 程序中函数、子程序块分界是否明显
（4） 注释是否符合既定格式
（5） 注释是否正确反映代码的功能
（6） 变量定义是否正确（长度、类型、存储类型）
（7） 是否引用了未初始化变量
（8） 数组和字符串的下标是否为整数
（9） 的数组和字符串的下标是否在范围内（不“越界”）
（10） 进行数组的检索及其它操作中，是否会出现“漏掉一个这种情况”
（11） 是否在应该使用常量的地方使用了变量（例：数组范围检查）
（12） 是否为变量赋予不同类型的值
（13） （12）的情况下，赋值是否符合数据类型的转换规则
（14） 变量的命名是否相似
（15） 是否存在声明过，但从未引用或者只引用过一次的变量
（16） 在特定模块中所有的变量是否都显式声明过
（17） 非（16）的情况下，是否可以理解为该变量具有更高的共享级别
（18） 是否为引用的指针分配内存
（19） 数据结构在函数和子程序中的引用是否明确定义了其结构
（20） 计算中是否使用了不同数据类型的变量
（21） 计算中是否使用了不同的数据类型相同但长度不同的变量
（22） 赋值的目的变量是否小于赋值表达式的值
（23） 数值计算是否会出现溢出（向上）的情况
（24） 数值计算是否会出现溢出（向下）的情况
（25） 除数是否可能为零
（26） 某些计算是否会丢失计算精度
（27） 变量的值是否超过有意义的值
（28） 计算式的求值的顺序是否容易让人感到混乱
（29） 比较是否正确
（30） 是否存在分数和浮点数的比较
（31） 如果（30），精度问题是否会影响比较
（32） 每一个逻辑表达式是否都得到了正确表达
（33） 逻辑表达式的操作数是否均为逻辑值
（34） 程序中的Begin…End和Do…While等语句中，End是否对应
（35） 程序、模块、子程序和循环是否能够终止
（36） 是否存在永不执行的循环
（37） 是否存在多循环一次或少循环一次的情况
（38） 循环变量是否在循环内被错误地修改
（39） 多分支选择中，索引变量是否能超过可能的分支数
（40） 如果（39）,该情况是否能够得到正确处理
（41） 子程序接受的参数类型、大小、次序是否和调用模块相匹配
（42） 全局变量定义和用法在各个模块中是否一致
（43） 是否修改了只作为输入用的参数
（44） 常量是否被做为形式参数进行传递
B 动态测试
（1） 测试数据是否具有一定的代表性
（2） 测试数据是否包含测试所用的各个等价类（边界条件、次边界条件、空白、 无效）
（3） 是否可能从客户那边得到测试数据
（4） 非（3）的情况下，所用的测试数据是否具有实际的意义
（5） 是否每一组测试数据都得到了执行
（6） 每一组测试数据的测试结果是否与预期结果一致
（7） 文件的属性是否正确
（8） 打开文件语句是否正确
（9） 输入/输出语句是否与格式说明书所记述的一致
（10） 缓冲区大小与记录长度是否匹配
（11） 使用文件前是否已打开了文件
（12） 文件结束条件是否存在
（13） 产生输入/输出错误时，系统是否进行检测并处理
（14） 输出信息中是否存在文字书写错误和语法错误
（15） 控件尺寸是否大小适宜
（16） 控件颜色是否符合规约
（17） 控件布局是否合理、美观
（18） 控件TAB顺序是否从左到右，从上到下
（19） 数字输入框是否接受数字输入
（20） （19）的情况下、数字是否按既定格式显示
（21） 数字输入框是否拒绝字符串和“非法”数字的输入
（22） 组合框是否的能够进行下拉选择
（23） 组合框是否能够进行下拉多项选择
（24） 对于可添加数据组合框，添加数据后数据是否能够得到正确显示和进行选择
（25） 列表框是否能够进行选择
（26） 多项列表框是否能够进行多数据项选择
（27） 日期输入框是否接受正确的日期输入
（28） 日期输入框是否拒绝错误的日期输入
（29） 日期输入框在日期输入后是否按既定的日期格式显示日期
（30） 单选组内是否有且只有一个单选钮可选
（31） 如果单选组内无单选钮可选，这种情况是否允许存在
（32） 复选框组内是否允许多个复选框（包括全部可选）可选
（33） 如果复选框组内无复选框可选，这种情况是否允许存在
（34） 文本框及某些控件拒绝输入和选择时显示区域是否变灰或按既定规约处理
（35） 密码输入框是否按掩码的方式显示
（36） Cancel之类的按钮按下后，控件中的数据是否清空复原或按既定规约处理
（37） Submit之类的按钮按下后，数据是否得到提交或按既定规约处理
（38） 异常信息表述是否正确
（39） 软件是否按预期方式处理错误
（40） 文件或外设不存在的情况下是否存在相应的错误处理
（41） 软件是否严格的遵循外设的读写格式
（42） 画面文字（全、半角、格式、拼写）是否正确
（43） 产生的文件和数据表的格式是否正确
（44） 产生的文件和数据表的计算结果是否正确
（45） 打印的报表是否符合既定的格式
（46） 错误日志的表述是否正确
（47） 错误日志的格式是否正确 -
测试工具大全
2008-03-16 21:00:23
测试工具大全
工具类别 工具名称 生产厂商 相关网站 通用功能自动化测试工具 Winrunner Mercury Quicktest pro Mercury Xrunner Mercury QARun Compuware TestPartner Compuware WebKing Parasoft http://www.parasoft.com Robot IBM Rational http://www.ibm.com/cn Visual Test IBM Rational http://www.ibm.com/cn Functional Tester IBM Rational http://www.ibm.com/cn SilkTest Segue SilkTest International Segue e-Tester Empirix WebFT Radview TestComplete AutomatedQA QA Wizard Seapine Software EggPlant RedStone Test Edition Microsoft Visual Studio PureTest Minq Autotester Autotester Testbench400 Original Software TestExpert VEReCOMM TestRunner Qronus TTCN suite Telelogic http://www.telelogic.com.cn QC/Replay Centerline Web AutoTester eValid Software Research WebART OCLC MaxQ 开源 WebInject 开源 Marathon 开源 性能测试/监控工具 LoadRunner Mercury SiteScope Mercury Topaz Mercury QaLoad Compuware PerformaSure/benchmark Quest Silkperformer Segue Silkperformer Lite Segue SilkCentralTM Performance Manager Segue e-Load Empirix Robot IBM Rational http://www.ibm.com/cn Performance Tester IBM Rational http://www.ibm.com/cn WebLoad RadView Web applicaton stress tool Microsoft Application center test Microsoft PureLoad Minq Athene APR Metron ForeCast Facilita Impact/Impact for CBT Cyrano Berkeley Laboratory sniffer Lawrence Jmeter 开源 openSTA 开源 Siege 开源 StressMark 开源 DBMonster 开源 白盒测试/代码分析工具 VcTester ezTester http://www.eztester.com Jtest Parasoft http://www.parasoft.com C++test Parasoft http://www.parasoft.com SOA test Parasoft http://www.parasoft.com .test Parasoft http://www.parasoft.com Codewizard Parasoft http://www.parasoft.com Insure++ Parasoft http://www.parasoft.com DataRecon Parasoft http://www.parasoft.com Numega devpartner studio Compuware DevPartnerJavaEdition Compuware BoundsChecker Compuware SmartCheck Compuware DBPartner Compuware Bean-test Empirix Aqtime AutomatedQA QESatJava AutomatedQA Visual Unit Unitware PC-lint Gimpel Software Macabe Macabe Optimizeit Suite Borland JProbe Suite Quest Software Application assurance suite Quest Software Sql optimizer Quest Software Jprofiler ej-technologies workbench Cyrano Logiscope TeleLogic http://www.telelogic.com.cn rulecheck TeleLogic http://www.telelogic.com.cn SilkPerformer Component Test Edition Segue Purifyplus IBM rational http://www.ibm.com/cn Rational Test Realtime IBM rational http://www.ibm.com/cn junit 开源 cactus 开源 Hansel 开源 TestNG 开源 StrutsTestCase 开源 JFCUnit 开源 Httpunit 开源 Dunit 开源 cppunit 开源 http://sourceforge.net/projects/cppunit Nunit 开源 Xunit 开源 JTR 开源 MallocDebug Linux平台工具 Valgrind Linux平台工具 Kcachegrind Linux平台工具 dmalloc Linux平台工具 ElectricFence Linux平台工具 LeakTracer Linux平台工具 memprof Linux平台工具 ccmalloc Linux平台工具 mprof Linux平台工具 yamd Linux平台工具 njamd Linux平台工具 mpatrol Linux平台工具 嵌入式测试工具 VcTester ezTester http://www.eztester.com codetest Metrowerks Cantata/cantana++ IPL IceMaster Reflex Technology System test Reflex Technology scorecast DDC-I Testquest Testquest UniText ATTOL vectorcast Vector software testrunner Qronus Logiscope Telelogic http://www.telelogic.com.cn 测试管理工具 TestDirector(QualityCenter) Mercury QADirector Compuware certify Worksoft Product manager Aimware SilkCentral Test Manager Segue Doors Telelogic http://www.telelogic.com.cn e-manager Empirix testmanager IBM Rational http://www.ibm.com/cn TestView Manager RadView Professional T-Plan 缺陷管理工具 TestDirector(QualityCenter) Mercury ClearQuest IBM Rational http://www.ibm.com/cn TrackRecord Compuware TestTrack pro Seapine TrueTrack McCabe Devtrack Techexcel Notes IBM Lotus SilkCentral Issue Manager Segue PVCS Tracker Merant AR System Remedy URTrack LealSoft Butterfly Hansky Bugzilla 开源 Mantis 开源 JIRA 开源 BugFree 开源 配置管理工具 ClearCase IBM Rational http://www.ibm.com/cn PVCS Version Manager Merant VCS Diamond StarTeam Borland Perforce Perforce TRUEchange McCabe SYNERGY CM Telelogic http://www.telelogic.com.cn VSS Microsoft Firefly Hansky CVS Subversion SCCS RCS CCC/Harvest Computer Associates 欢迎转载此文，转载时请注明文章来源：文斯测试技术研究中心 http://blog.csdn.net/vincetest
-
web测试的几个重点
2008-03-16 20:44:28
很多时候，基于需求的测试和针对web特有的浏览器兼容性测试、cookie失效的验证，对于测试人员并不陌生。但实际上，与浏览器相关的测试内容远不止这些。举一个例子来说，很多时候我们都非常明确页面上的所有入口，并对这些入口设计了大量的用例，而浏览器的地址栏却常常会被我们忽略。实际上，url的输入意义远比我们意识中的重要，忽略了url的测试，很容易造成安全上的隐患。
再进一步的说，浏览器的前进、后退、刷新按钮同样是测试人员需要关注的点。前进、后退在用户登录、注销信息的测试中应用最为频繁。而刷新，往往容易被忽视，但其同样是bug的“温床”。在最近的一次测试中，我就遇到过在我删除某条记录系统提示删除成功后，点击“刷新”按钮，页面提示出错的情况。出现该现象的原因就在于页面试图去取已删除的内容，导致出现异常。其实这个问题应该隐藏了比较久的时间，但是却一直未被发现，足可见我们都忽视了“刷新”的测试。
除了上述的内容外，我相信一定还存在很多我们在测试中忽视的内容，而这些点的补充，是我们每一个人的责任！
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.2和1.3的测试中
1.6 应用程序特定的功能需求
最重要的是，测试人员需要对应用程序特定的功能需求进行验证。尝试用户可能进行的所有操作：下订单、更改订单、取消订单、核对订单状态、在货物发送之前更改送货信息、在线支付等等。这是用户之所以使用网站的原因，一定要确认网站能像广告宣传的那样神奇。
采取措施：深刻理解需求说明文档
1.7 设计语言测试
Web设计语言版本的差异可以引起客户端或服务器端严重的问题，例如使用哪种版本的HTML等。当在分布式环境中开发时，开发人员都不在一起，这个问题就显得尤为重要。除了HTML的版本问题外，不同的脚本语言，例如Java、Javascrīpt、 ActiveX、VBscrīpt或Perl等也要进行验证。
-
界面测试用例
2008-03-16 20:43:33
界面测试用例
一、文本框、按钮等控件测试
1、文本框的测试
如何对文本框进行测试：
a、输入正常的字母或数字；
b、输入已存在的文件的名称；
c、输入超长字符。例如在“名称”框中输入超过允许边界个数的字符，假设最多255个字符，尝试输入256个字符，检查程序能否正确处理；
d、输入默认值，空白，空格；
e、若只允许输入字母，尝试输入数字；反之，尝试输入字母；
f、利用复制，粘贴等操作强制输入程序不允许的输入数据；
g、输入特殊字符集，例如，NUL及\n等；
h、输入超过文本框长度的字符或文本，检查所输入的内容是否正常显示；
i、输入不符合格式的数据，检查程序是否正常校验，如程序要求输入年月日格式为yy/mm/dd，实际输入yyyy/mm/dd，程序应该给出错误提示。在测试过程中所用到的测试方法：
1、输入非法数据；
2、输入默认值；
3、输入特殊字符集；
4、输入使缓冲区溢出的数据；
5、输入相同的文件名；2、命令按钮控件的测试
测试方法：
a、点击按钮正确响应操作。如单击确定，正确执行操作；单击取消，退出窗口；
b、对非法的输入或操作给出足够的提示说明，如输入月工作天数为32时，单击“确定”后系统应提示：天数不能大于31；
c、对可能造成数据无法恢复的操作必须给出确认信息，给用户放弃选择的机会；3、单选按钮控件的测试
测试方法：
a、一组单选按钮不能同时选中，只能选中一个；
b、逐一执行每个单选按钮的功能。分别选择了“男”、“女”后，保存到数据库的数据应该相应的分别为“男”、“女”；
c、一组执行同一功能的单选按钮在初始状态时必须有一个被默认选中，不能同时为空。
4、up－down控件文本框的测试测试方法：
a、直接输入数字或用上下箭头控制，如在“数目”中直接输入10，或者单击向上的箭头，使数目变为10；
b、利用上下箭头控制数字的自动循环，如当最多数字为253时，单击向上箭头，数目自动变为1；反之亦适用；
c、直接输入超边界值，系统应该提示重新输入；
d、输入默认值，空白。如“插入”数目为默认值，点击“确定”；或删除默认值，使内容为空，单击“确定”进行测试；
e、输入字符。此时系统应提示输入有误。5、组合列表框的测试
测试方法：
a、条目内容正确，其详细条目内容可以根据需求说明确定；
b、逐一执行列表框中每个条目的功能；
c、检查能否向组合列表框输入数据。6、复选框的测试
测试方法：
a、多个复选框可以被同时选中；
b、多个复选框可以被部分选中；
c、多个复选框可以都不被选中；
d、逐一执行每个复选框的功能。7、列表框控件的测试
测试方法：
a、条目内容正确：同组合列表框类似，根据需求说明书确定列表的各项内容正确，没有丢失或错误；
b、列表框的内容较多时要使用滚动条；
c、列表框允许多选时，要分别检查shift选中条目，按ctrl选中条目和直接用鼠标选中多项条目的情况；8、滚动条控件的测试
要注意一下几点：
a、滚动条的长度根据显示信息的长度或宽度及时变换，这样有利于用户了解显示信息的位置和百分比，如word中浏览100页文档，浏览到50页时，滚动条位置应处于中间；
b、拖动滚动条，检查屏幕刷新情况，并查看是否有乱码；
c、单击滚动条；
d、用滚轮控制滚动条；
e、滚动条的上下按钮。9、各种控件在窗体中混和使用时的测试
a、控件间的相互作用；
b、tab键的顺序，一般是从上到下，从左到右；
c、热键的使用，逐一测试；
d、enter键和esc键的使用。在测试中，应遵循由简入繁的原则，先进行单个控件功能的测试，确保实现无误后，再进行多个控件的的功能组合的测试。
ps：密码输入框测试时要特别注意进行字母大写输入的测试。二、查找替换操作
案例演示：打开word中的“替换”对话框。
测试本功能有通过测试和失败测试两种情况：
通过测试：
1、输入内容直接查找、或查找全部；
2、在组合框中寻找已经查找过的内容、再次查找并确认文档的内容正确，如已经查找过“测试用例”、再次进入不用重新输入查找内容、直接在文档中搜寻就可以。失败测试：
1、输入过长或过短的查询字符串。如假设查询的字符串长度为1到255，那么，输入0、1、2、256、255和254进行测试；
2、输入特殊字符集。如在word中^g代表图片、^代表分栏符、可以输入这类特殊字符测试；替换测试大体相同。
关于编辑操作窗口的功能测试的用例：
1、关闭查找替换窗口。不执行任何操作、直接退出；
2、附件和选项测试。假如设定“精确搜寻”、“向后”搜索等附件选项等等来测试；
3、控件间的相互作用。如搜寻内容为空时、按钮“搜寻全部”、“搜寻”、“全部替换”、“替换”都为灰色。
4、热键、Tab键。回车键的使用。插入操作
1、插入文件
测试的情况：
a、插入文件；
b、插入图像；
c、在文档中插入文档本身；
d、移除插入的源文件；
e、更换插入的源文件的内容。2、链接文件
测试方法：
a、插入链接文件；
b、在文档中链接文档本身；
c、移除插入的源文件：
d、更换插入的源文件的内容。3、插入对象
要测试的内容：
a、插入程序允许的对象、如在word中插入excel工作表；
b、修改所插入对象的内容。插入的对象仍能正确显示；
c、卸载生成插入对象的程序、如在word中插入excel工作表后卸载excel、工作表仍正常使用。编辑操作
编辑操作包括剪切、复制、粘贴操作。
测试剪切操作的方法
a、对文本、文本框、图文框进行剪切；
b、剪切图像；
c、文本图像混合剪切。复制操作方法与剪切类似。
测试时，主要是对粘贴操作的测试方法是：
a、粘贴剪切的文本、文本框及图文框；
b、粘贴所剪切的图像；
c、剪切后，在不同的程序中粘贴；
d、多次粘贴同一内容，如剪切后，在程序中连续粘贴3次；
e、利用粘贴操作强制输入程序所不允许输入的数据。三、界面测试用例的设计方法
1、窗体
测试窗体的方法：
a、窗体大小，大小要合适，控件布局合理；
b、移动窗体。快速或慢速移动窗体，背景及窗体本身刷新必须正确；
c、缩放窗体，窗体上的控件应随窗体的大小变化而变化；
d、显示分辨率。必须在不同的分辨率的情况下测试程序的显示是否正常。进行测试时还要注意状态栏是否显示正确，工具栏的图标执行操作是否有效，是否与菜单懒中图标显示一致；错误信息内容是否正确、无错别字且明确等等。
2、控件
测试方法：
a、窗体或控件的字体和大小要一致；
b、注意全角、半角混合；
c、无中英文混合。四、菜单
进行测试时要注意：
a、选择菜单是否可以正常工作、并与实际执行内容一致；
b、是否有错别字；
c、快捷键是否重复；
d、热键是否重复；
e、快捷键与热键操作是否有效；
f、是否存在中英文混合；
g、菜单要与语境相关、如、不同权限的用户登陆一个应用程序、不同级别的用户可以看到不同级别的菜单并使用不同级别的功能；
h、鼠标右键快捷菜单。特殊属性
1、安装界面应有公司介绍或产品介绍、有公司的图标；
2、主界面及大多数界面最好有公司图标；
3、选择“帮助”->“关于”命令、应看见相关版权和产品信息。 -
性能测试
2008-03-16 20:42:55
性能测试
2.1 连接速度测试用户连接到Web应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长（例如超过5秒钟），用户就会因没有耐心等待而离开。
另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。
2.2 负载测试
负载测试是为了测量Web系统在某一负载级别上男阅埽员Ｖeb系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问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应用系统开发没有联系或联系很少的人员）的参与，最好是最终用户的参与。
采取措施：手动测试，参与人员最好有外部人员
-
兼容性测试
2008-03-16 20:41:43
4 兼容性测试
4.1 平台测试
市场上有很多不同的操作系统类型，最常见的有Windows、Unix、Macintosh、Linux等。Web应用系统的最终用户究竟使用哪一种操作系统，取决于用户系统的配置。这样，就可能会发生兼容性问题，同一个应用可能在某些操作系统下能正常运行，但在另外的操作系统下可能会运行失败。
因此，在Web系统发布之前，需要在各种操作系统下对Web系统进行兼容性测试。
4.2 浏览器测试
浏览器是Web客户端最核心的构件，来自不同厂商的浏览器对Java，、Javascrīpt、 ActiveX、 plug-ins或不同的HTML规格有不同的支持。例如，ActiveX是Microsoft的产品，俏狪nternet 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。在该目录下有很多资料，其中引起我注意的是已过期页面。该公司每个月都要更改产品价格，并且保存过期页面。我翻看了一下这些记录，就可以估计他们的边际利润以及他们为了争取一个合同还有多大的降价空间。如果某个客户在谈判之前查看了这些信息，他们在谈判桌上肯定处于上风。
5.2 SSL
很多站点使用 SSL 进行安全传送。你知道你进入一个 SSL 站点是因为浏览器出现了警告消息，而且在地址栏中的 HTTP 变成 HTTPS。如果开发部门使用了SSL，测试人员需要确定是否有相应的替代页面(适用于3.0 以下版本的浏览器，这些浏览器不支持SSL。当用户进入或离开安全站点的时候，请确认有相应的提示信息。是否有连接时间限制？超过限制时间后出现什么情况？
5.3 登录
有些站点需要用户进行登录，以验证他们的身份。这样对用户是方便的，他们不需要每次都输入个人资料。你需要验证系统阻止非法的用户名/口令登录，而能够通过有效登录。用户登录是否有次数限制? 是否限制从某些 IP 地址登录? 如果允许登录失败的次数为3，你在第三次登录的时候输入正确的用户名和口令，能通过验证吗? 口令选择有规则限制吗? 是否可以不登陆而直接浏览某个页面？
Web应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内（例如15分钟）没有点击任何页面，是否需要重新登陆才能正常使用。
5.4 日志文件
在后台，要注意验证服务器日志工作正常。日志是否记所有的事务处理? 是否记录失败的注册企图? 是否记录被盗信用卡的使用? 是否在每次事务完成的时候都进行保存? 记录IP 地址吗? 记录用户名吗?
5.5 脚本语言
脚本语言是常见的安全隐患。每种语言的细节有所不同。有些脚本允许访问根目录。其他只允许访问邮件服务器，但是经验丰富的黑客可以将服务器用户名和口令发送给他们自己。找出站点使用了哪些脚本语言，并研究该语言的缺陷。还要需要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。最好的办法是订阅一个讨论站点使用的脚本语言安全性的新闻组。
6 接口测试在很多情况下，web 站点不是孤立。Web 站点可能会与外部服务器通讯，请求数据、验证数据或提交订单。
6.1服务器接口
第一个需要测试的接口是浏览器与服务器的接口。测试人员提交事务，然后查看服务器记录，并验证在浏览器上看到的正好是服务器上发生的。测试人员还可以查询数据库，确认事务数据已正确保存。
这种测试可以归到功能测试中的表单测试和数据校验测试中
6.2 外部接口
有些 web 系统有外部接口。例如，网上商店可能要实时验证信用卡数据以减少欺诈行为的发生。测试的时候，要使用 web 接口发送一些事务数据，分别对有效信用卡、无效信用卡和被盗信用卡进行验证。如果商店只使用 Visa 卡和 Mastercard 卡， 可以尝试使用 Discover 卡的数据。(简单的客户端脚本能够在提交事务之前对代码进行识别，例如 3 表示 American Express，4 表示 Visa，5 表示 Mastercard，6 代表Discover。)通常，测试人员需要确认软件能够处理外部服务器返回的所有可能的消息。
这种情况在远程抄表中可能会体现到
6.3 错误处理
最容易被测试人员忽略的地方是接口错误处理。通常我们试图确认系统能够处理所有错误，但却无法预期系统所有可能的错误。尝试在处理过程中中断事务，看看会发生什么情况？订单是否完成？尝试中断用户到服务器的网络连接。尝试中断 web 服务器到信用卡验证服务器的连接。在这些情况下，系统能否正确处理这些错误？是否已对信用卡进行收费？如果用户自己中断事务处理，在订单已保存而用户没有返回网站确认的时候，需要由客户代表致电用户进行订单确认。
采取措施：在理解需求的基础上，充分发挥想象力，尽量比较全面的列出各种异常情况。
7 结论
无论你在测试 internet、intranet 或者是 extranet 应用程序，web 测试相对于非 web 测试来说都是更具挑战性的工作。用户对 web 页面质量有很高的期望。在很多情况下，就像业务功能一样，页面用于维护和发展公共关系，所以第一印象非常重要。
-
WEB测试资料
2008-03-16 20:40:30
WEB测试资料
关于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.页面最大化检查：测试最大化/最小化/还原时页面是否做了对应的处理。 -
web测试技术经典案例
2008-03-16 20:30:56
web测试技术经典案例
2008-03-13 19:53:28 / 个人分类：Web测试
1. 概述
随着web应用的增多，新的模式解决方案中以web为核心的应用也越来越多，很多公司各种应用的架构都以B/S及web应用为主，但是有关WEB测试方面的内容并没有相应的总结，所以我在这里对web的测试方法和采用的测试技术进行总结，便于内部交流。
测试方法尽量涵盖web程序的各个方面，测试技术方面在继承传统测试技术的技术上结合web应用的特点。
相关的测试和实现技术也有着很大的关系，由于本公司使用J2EE体系，也许例子中只有JAVA平台可以使用，.NET平台测试技术暂时不涉及，如果你有请与我联系。
2. 测试方法
说明：测试方法的选择取决你的测试策略。
一般的web测试和以往的应用程序的测试的侧重点不完全相同，基本包括以下几个方面。
当然圆满的完成测试还要有好的团体和流程等的方方面面的支持，你同样应该对这些方面进行注意。
有些测试方法设计到了流程，哪些应该在你的测试团队建设中建立。2.1 界面测试
现在一般人都有使用浏览器浏览网页的经历，用户虽然不是专业人员但是对界面效果的印象是很重要的。如果你注重这方面的测试，那么验证应用程序是否易于使用就非常重要了。很多人认为这是测试中最不重要的部分，但是恰恰相反界面对不懂技术的客户来说那相当关键，慢慢体会你会明白的。
方法上可以根据设计文档，如果够专业的话可以专业美工人员，来确定整体风格页面风格，然后根据这个可以页面人员可以生成静态的HTML，CSS等甚至生成几套不用的方案来讨论，或者交给客户评审，最后形成统一的风格的页面/框架。注意不要靠程序员的美术素养形成你的web风格，那样可能会很糟糕。
主要包括以下几个方面的内容：
站点地图和导航条位置、是否合理、是否可以导航等内容布局布局是否合理，滚动条等简介说明说明文字是否合理，位置，是否正确
背景/色调是否正确、美观，是否符合用户需求；
页面在窗口中的显示是否正确、美观（在调整浏览器窗口大小时，屏幕刷新是否正确）表单样式大小，格式，是否对提交数据进行验证（如果在页面部分进行验证的话）等
连接连接的形式，位置，是否易于理解等web测试的主要页面元素
页面元素的容错性列表（如输入框、时间列表或日历）
页面元素清单（为实现功能，是否将所需要的元素全部都列出来了，如按钮、单选框、复选框、列表框、超连接、输入框等等）
页面元素的容错性是否存在
页面元素的容错性是否正确
页面元素基本功能是否实现（如文字特效、动画特效、按钮、超连接）
页面元素的外形、摆放位置（如按钮、列表框、核选框、输入框、超连接等）
页面元素是否显示正确（主要针对文字、图形、签章）
元素是否显示（元素是否存在）
页面元素清单（为实现功能，是否将所需要的元素全部都列出来了，如按钮、单选框、复选框、列表框、超连接、输入框等等）测试技术
通过页面走查，浏览确定使用的页面是否符合需求。可以结合兼容性测试对不用分辨率下页面显示效果，如果有影响应该交给设计人员提出解决方案。
可以结合数据定义文档查看表单项的内容，长度等信息。
对于动态生成的页面最好也能进行浏览查看。如Servelet部分可以结合编码规范，进行代码走查。是否支持中文，如果数据用XML封装要做的工作会多一点等等。界面测试要素:
符合标准和规范,灵活性,正确性,直观性,舒适性,实用性,一致性1.直观性:
用户界面是否洁净,不唐突,不拥挤.界面不应该为用户制造障碍.所需功能或者期待的响应应该明显,并在预期出现的地方.
界面组织和布局合理吗?是否允许用户轻松地从一个功能转到另一个功能?下一步做什么明显吗?任何时刻都可以决定放弃或者退回,退出吗?输入得到承认了吗?菜单或者窗口是否深藏不露?
有多余功能吗?软件整体抑或局部是否做得太多?是否有太多特性把工作复杂化了?是否感到信息太庞杂?
如果其他所有努力失败,帮助系统真能帮忙吗?
2.一致性快速键和菜单选项.在Windows 中按F1键总是得到帮助信息
术语和命令.整个软件使用同样的术语吗?特性命名一致吗?例如,Find是否一直叫Find,而不是有时叫Search?
软件是否一直面向同一级别用户?带有花哨用户界面的趣味贺卡程序不应该显示泄露技术机密的错误提示信息.
按钮位置和等价的按键.大家是否注意到对话框有OK按钮和Cancle按钮时,OK按钮总是在上方或者左方,而Cancle按钮总是在下方或右方?同样原因,Cancle按钮的等价按键通常是Esc,而选中按钮的等价按钮通常是Enter.保持一致.
3.灵活性状态跳转.灵活的软件实现同一任务有多种选择方式.
状态终止和跳过,具有容错处理能力.
数据输入和输出.用户希望有多种方法输入数据和查看结果.例如,在写字板插入文字可用键盘输入,粘贴,从6种文件格式读入,作为对象插入,或者用鼠标从其他程序拖动.4.舒适性
恰当.软件外观和感觉应该与所做的工作和使用者相符.
错误处理.程序应该在用户执行严重错误的操作之前提出警告,并允许用户恢复由于错误操作导致丢失的数据.如大家认为undo /redo是当然的.
性能.快不见得是好事.要让用户看得清程序在做什么,它是有反应的.2.2 功能测试
对功能测试是测试中的重点
主要包括一下几个方面的内容
连接这个连接和界面测试中的连接不同那里注重的是连接方式和位置，如是图像还是文字放置的位置等，还是其他的方式。这里的连接注重功能。如是否有连接，连接的是否是说明的位置等。表单提交应当模拟用户提交，验证是否完成功能，如注册信息，要测试这些程序，需要验证服务器能正确保存这些数据，而且后台运行的程序能正确解释和使用这些信息。还有数据正确性验证，异常处理等，最好结合易用性要求等。B/S结构实现的功能可能主要的就在这里，提交数据，处理数据等如果有固定的操作流程可以考虑自动化测试工具的录制功能，编写可重复使用的脚本代码，可以在测试、回归测试时运行以便减轻测试人员工作量。
Cookies 验证如果系统使用了cookie，测试人员需要对它们进行检测。如果在 cookies 中保存了注册信息，请确认该 cookie能够正常工作而且已对这些信息已经加密。如果使用 cookie 来统计次数，需要验证次数累计正确。关于cookie的使用可以参考浏览器的帮助信息。如果使用B/S结构cookies中存放的信息更多。功能易用性测试完成了功能测试可以对应用性进行了解，最好听听客户的反映，在可以的情况下对程序进行改进是很有必要的，和客户保持互动对系统满意度也是很有帮助的。
测试技术功能测试的测试技术可是很多的，我们可以结合实际环境选择使用
白盒测试技术(White Box Testing) 深入到代码一级的测试，使用这种技术发现问题最早，效果也是最好的。该技术主要的特征是测试对象进入了代码内部,根据开发人员对代码和对程序的熟悉程度,对有需要的部分进行在软件编码阶段，开发人员根据自己对代码的理解和接触所进行的软件测试叫做白盒测试。这一阶段测试以软件开发人员为主，在JAVA平台使用Xunit系列工具进行测试，Xunit测试工具是类一级的测试工具对每一个类和该类的方法进行测试。
黑盒测试技术（Black Box Testing）黑盒测试的内容主要有以下几个方面，但是主要还是功能部分。主要是覆盖全部的功能，可以结合兼容，性能测试等方面进行，根据软件需求，设计文档，模拟客户场景随系统进行实际的测试，这种测试技术是使用最多的测试技术涵盖了测试的方方面面，可以考虑以下方面
正确性 (Correctness)：计算结果，命名等方面?
可用性 (Usability)：是否可以满足软件的需求说明。
边界条件 (Boundary Condition)输入部分的边界值,就是使用一般书中说的等价类划分,试试最大最小和非法数据等等.
性能 (Performance) 正常使用的时间内系统完成一个任务需要的时间,多人同时使用的时候响应时间,在可以接受范围内.J2EE技术实现的系统在性能方面更是需要照顾的,一般原则是3秒以下接受,3-5秒可以接受,5秒以上就影响易用性了. 如果在测试过程中发现性能问题，修复起来是非常艰难的，因为这常常意味着程序的算法不好，结构不好，或者设计有问题。因此在产品开发的开始阶段，就要考虑到软件的性能问题。
压力测试 (Stress) 多用户情况可以考虑使用压力测试工具,建议将压力和性能测试结合起来进行.如果有负载平衡的话还要在服务器端打开监测工具,查看服务器CPU使用率,内存占用情况,如果有必要可以模拟大量数据输入,对硬盘的影响等等信息.如果有必要的话必须进行性能优化(软硬件都可以).这里的压力测试针对的是某几项功能.
错误恢复 (Error Recovery) 错误处理，页面数据验证,包括突然间断电,输入脏数据等.
安全性测试(Security)这个领域正在研究中,不过防火墙,补丁包.杀毒软件等的就不必说了,不过可以考虑破坏性测试时任意.看了一些资料后得知,这里面设计到的知识\内容可以写本书了,不是一两句可以说清的,特别是一些商务网站,或者跟钱有关,或者和公司秘密有关的web更是,需要这方面的测试,在外国有一种专门干这一行的人叫安全顾问,可以审核代码,提出安全建议,出现紧急事件是的处理办法等,在国内没有听说哪里有专门搞安全技术测试的内容.兼容性 (Compatibility) 不同浏览器，不同应用程序版本在实现功能时的表现,不同的上网方式,如果你测试的是一个公共网站的话.
兼容性测试内容详述
硬件平台
浏览器软件和版本:浏览器插件,浏览器选项,视频分辨率和色深.文字大小,调制解调器速率.
软件配置 (Configuration) 如IE浏览器的不用选项-安全设定最高,禁用脚本程序,等等,你们的程序在各种不用的设置下表现如何.单元测试技术(Unit Test):
2.2.1 下面是对白盒测试和单元测试的区别的论述:单元测试和白盒测试是不同的,虽然单元测试和白盒测试都是关注功能虽然他们都需要代码支持,但是级别不同,白盒测试关注的是类中一个方法的功能是更小的单位,但是完成一个单元测试可能需要N多类,所以说作单元测试需要什么写驱动和稳定桩,比如查询单元是一个查询包包N多的测试类,测试数据,运行他需要提供数据的部分,输入参数和发出命令的驱动等等.是比类大的一个整体进行的.
另一个明显的区别是白盒测试不会关注类接口,但是单元测试主要的内容就是类接口测试.
不过很多时候是很少区分的,因为这两种技术实现起来有很多相互关联的部分.不过要看你对质量的关注程度来决定.
2.2.2 功能测试边界测试\越界测试技术详述
边界条件
边界条件是指软件计划的操作界限所在的边缘条件.
如果软件测试问题包含确定的边界,那么数据类型可能是:
数值速度字符地址位置尺寸数量
同时,考虑这些类型的下述特征:
第一个/最后一个最小值/最大值
开始/完成超过/在内
空/满最短/最长
最慢/最快最早/最迟
最大/最小最高/最低
相邻/最远
越界测试
通常是简单加1或者很小的数(对于最大值)和减少1或者很小的数(对于最小值),例如:
第一个减1/最后一个加1
开始减1/完成加1
空了再减/满了再加
慢上加慢/快上加快
最大数加1/最小数减1
最小值减1/最大值加1
刚好超过/刚好在内
短了再短/长了再长
早了更早/晚了更晚
最高加1/最低减1另一些该注意的输入:默认,空白,空值,零值和无;非法,错误,不正确和垃圾数据.
2.2.3 状态测试技术
软件可能进入的每一种独立状态;
从一种状态转入另一种状态所需的输入和条件;
进入或退出某种状态时的设置条件及输入结果.
具体测试方法可以参考如下:
每种状态至少访问一次;
测试看起来最常见最普遍的状态转换;
测试状态之间最不常用的分支
测试所有错误状态及其返回值
测试随机状态转换2.2.4 竞争条件测试技术
竞争条件典型情形参考如下:
两个不同的程序同时保存或打开同一个文档
共享同一台打印机,通信端口或者其他外围设备
当软件处于读取或者修改状态时按键或者单击鼠标
同时关闭或者启动软件的多个实例
同时使用不同的程序访问一个共同数据库2.3 负载\压力测试(StressTest)
在这里的负载\压力和功能测试中的不同,他是系统测试的内容,是基本功能已经通过后进行的.可以在集成测试阶段,亦可以在系统测试阶段进行.
使用负载测试工具进行,虚拟一定数量的用户看一看系统的表现,是否满足定义中的指标.
负载测试一般使用工具完成，loadrunner，webload，was，ewl，e-test等，主要的内容都是编写出测试脚本，脚本中一般包括用户一般常用的功能，然后运行，得出报告。所以负载测试包括的主要内容就不介绍了。
负载测试技术在各种极限情况下对产品进行测试 (如很多人同时使用该软件，或者反复运行该软件)，以检查产品的长期稳定性。例如，使用压力测试工具对web服务器进行压力测试. 本项测试可以帮助找到一些大型的问题，如死机、崩损、内存泄漏等，因为有些存在内存泄漏问题的程序，在运行一两次时可能不会出现问题，但是如果运行了成千上万次，内存泄漏得越来越多，就会导致系统崩滑。用J2EE实现的系统很少但是并不是没有内存问题.
无论什么工具基本的技术都是利用线程技术模仿和虚拟用户，在这里主要的难点在与测试脚本的编写，每种工具使用的脚本都不一样，但是大多数工具都提供录制功能就算是不会编码的测试人员同样可以测试。
对负载工具的延伸使用可以进行系统稳定性测试，系统极限测试，如使用100的Load Size连续使用24小时，微软定义的通过准则是通过72小时测试的程序一般不会出现稳定性的问题。
2.4 回归测试 (Regression Test)
过一段时间以后，再回过头来对以前修复过的Bug重新进行测试，看该Bug 是否会重新出现。
回归测试技术可以在测试的各个阶段出现，无论是单元测试还是集成测试还是系统测试。是对以前问题进行验证的过程。
回归测试的目的就是保证以前已经修复的Bug不会再出现。实际上，许多Bug都是在回归测试时发现的，在此阶段，我们首先要检查以前找到的Bug 是否已经更正了。值得注意的是，已经更正的Bug 也可能又回来了，有的Bug 经过修改之后可能又产生了新的Bug。所以，回归测试可保证已更正的Bug不再重现，不产生新的Bug。
2.5 Alpha 和Beta 测试 (Alpha and Beta Test):
在正式发布产品之前往往要先发布一些测试版，让用户能够反馈出相关信息，或者找到存在的Bug，以便在正式版中得到解决。
特别是在有客户参加的情况下，对系统进行测试可能会出现一些我们没有考虑的情况，还可以解决一些客户实际关心的问题
3 不同的测试技术区分
3.1 覆盖测试技术
说明:测试覆盖率可以看出测试的完成度,在测试分析报告中可以作为量化指标的依据，测试覆盖率越高效果越好。
覆盖测试可以是程序代码的执行路径覆盖，亦可以是功能实现的步骤覆盖（可以理解成流程图的路径覆盖）。
该技术可以用在任何测试阶段，包括单元测坏死、集成测试、系统测试。
使用该技术时可以使用以上的任何测试方法和测试技术。
3.2 白盒测试和黑盒测试技术
白盒测试技术 (White Box Testing)该技术主要的特征是测试对象进入了代码内部,根据开发人员对代码和对程序的熟悉程度,对有需要的部分进行在软件编码阶段，开发人员根据自己对代码的理解和接触所进行的软件测试叫做白盒测试。这一阶段测试以软件开发人员为主，使用Xunit系列工具进行测试，可以包括很多方面如功能性能等。
黑盒测试 (Black Box Testing)测试的主体部分黑盒测试的内容主要有以下几个方面，但是主要还是功能部分。主要是覆盖全部的功能，可以结合兼容，性能测试等方面进行,包括的不同测试类型请参考以上内容。
3.3 手工测试和自动化测试
手工测试（Manual Testing）：即依靠人力来查找Bug。方法可以参考上边的测试，也可以根据对实现技术及经验等进行不同的测试。
自动测试（Automation Testing）使用有针对工具实行。可以作出自动化测试的计划,对可以进行自动化测试的部分编写或者录制相应的脚本,可以加入功能,容错,表单提交等,可以参考MI,Rational或者其他类测试工具说明.
根据权威的软件测试经验，手工测试还是主要的测试方法，自动测试不够灵活，在这里不再详述。微软的测试过程80％还是手工完成。
自动测试永远也代替不了手工测试，但是手工测试的工作量很大是不争的事实。
3.4 根据RUP标准按阶段区分测试
单元测试在上边有详细的叙述，还有针对单元测试和集成测试的论述，请参考。
集成测试分为功能集成测试和系统集成测试，相互有调用的功能集成，在系统环境下功能相互调用的影响等，使用方法可以任意选用上面的内容。注重功能方面。
系统测试在功能实现的基础上，可以加入兼容性，易用性，性能等等
验收测试可以包括Alpha和Beta测试，在这里就不再详述。
4. 存在风险及解决方法
说明：测试不能找出所有的问题，只是尽量将问题在开发阶段解决大多数的问题而已。
测试风险如下：软硬件的测试环境提供上也对测试结果有很大的影响。
测试团队的水平，经验，合作效果等
整个开发流程对测试的重视程度，测试的进入时间等
由于测试环境操作系统，网络环境，带宽等情况可能产生的测试结果可能不同这是就需要经验以及对测试环境的保护等方面下一些功夫。5. 软件缺陷的原则
软件缺陷区别于软件bug,它是在测试过程中出现的对系统有影响的,但是在设计中没有的或者对修改后的bug测试和开发人员有不同意见等
软件未达到产品说明书标明的功能。
软件出现了产品说明书指明不会出现的错误。
软件功能超出产品说明书指明范围。
软件未达到产品说明书虽未指出但应达到的目标。
软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。6. 文档测试
产品说明书属性检查清单
完整.是否有遗漏和丢失?完全吗?单独使用是否包含全部内容?
准确.既定解决方案正确吗?目标明确吗?有没有错误?
精确,不含糊,清晰.描述是否一清二楚?还是自说自话?容易看懂和理解吗?
一致.产品功能能描述是否自相矛盾,与其他功能有没有冲突?
贴切.描述功能的陈述是否必要?有没有多余信息?功能是否原来的客户要求?
合理.在特定的预算和进度下,以现有人力,物力和资源能否实现?
代码无关.是否坚持定义产品,而不是定义其所信赖的软件设计,架构和代码?
可测试性.特性能否测试?测试员建立验证操作的测试程序是否提供足够的信息?
产品说明书用语检查清单说明对问题的描述通常表现为粉饰没有仔细考虑的功能----可归结于前文所述的属性.从产品说明书上找出这样的用语,仔细审视它们在文中是怎样使用的.产品说明书可能会为其掩饰和开脱,也可能含糊其词----无论是哪一种情况都可视为软件缺陷.
总是,每一种,所有,没有,从不.如果看到此类绝对或肯定的,切实认定的叙述,软件测试员就可以着手设计针锋相对的案例.
当然,因此,明显,显然,必然.这些话意图诱使接受假定情况.不要中了圈套.
某些,有时,常常,通常,惯常,经常,大多,几乎.这些话太过模糊."有时"发生作用的功能无法测试.
等等,诸如此类,依此类推.以这样的词结束的功能清单无法测试.功能清单要绝对或者解释明确,以免让人迷惑,不知如何推论.
良好,迅速,廉价,高效,小,稳定.这些是不确定的说法,不可测试.如果在产品说明书中出现,就必须进一步指明含义.
已处理,已拒绝,已忽略,已消除.这些廉洁可能会隐藏大量需要说明的功能.
如果...那么...(没有否则).找出有"如果...那么..."而缺少配套的"否则"结构的陈述.想一想"如果"没有发生会怎样.
-
开始测试吧
2008-03-16 20:06:09
自己开始学习测试
