岁月无痕的个人空间_首页_51Testing软件测试网

我的好友

日历

音乐欣赏

统计信息

访问量: 2189
日志数: 25
图片数: 1
建立时间: 2007-06-10
更新时间: 2008-07-04

我的最新日志

国外常见测试网站

2008-7-04

软件测试相关的63个国外站点网址简介

http://bdonline.sqe.com/
一个关于网站测试方面的网页,对这方面感兴趣的人可以参考

http://citeseer.nj.nec.com/
一个丰富的电子书库,内容很多,而且提供著作的相关文档参考和下载,是作者非常推荐的一个资料参考网站

http://groups.yahoo.com/group/LoadRunner
性能测试工具LoadRunner的一个论坛

http://groups.yahoo.com/grorp/testing-paperannou-nce/messages
提供网站上当前发布的软件测试资料列表

http://satc.gsfc.nasa.gov/homepage.html
软件保证中心是美国国家航天局（NASA)投资设立的一个软件可靠性和安全性研究中心，研究包括了度量、工具、风险等各个方面

http://seg.iit.nrc.ca/English/index.html
加拿大的一个研究软件工程质量方面的组织，可以提供研究论文的下载

http://sepo.nosc.mil
内容来自美国SAN DIEGO的软件工程机构（Sofrware Engineering Process Office)主页，包括软件工程知识方面的资料

http://www.asq.org/
是世界上最大的一个质量团体组织之一，有着比较丰富的论文资源，不过是收费的

http://www.automated-testing.com/
一个自动化软件测试和自然语言处理研究页面，属于个人网页，上面有些资源可供下载

http://www.benchmarkresources.com/
提供有关标杆方面的资料，也有一些其它软件测试方面的资料

http://www.betasoft.com/
包含一些流行测试工具的介绍、下载和讨论，还提供测试方面的资料

http://www.brunel.ac.uk/~csstmmh2/vast/home.html
VASTT研究组织，主要从事通过切片技术、测试技术和转换技术来验证和分析系统，对这方面技术感兴趣的人是可以在这里参考一些研究的项目及相关的一些主题信息

http://www.cc.gatech.edu/aristotle/
Aristole研究组织，研究软件系统分析、测试和维护等方面的技术，在测试方面的研究包括了回归测试、测试套最小化、面向对象软件测试等内容，该网站有丰富的论文资源可供下载

http://www.computer.org/
IEEE是世界上最悠久，也是在最大的计算机社会团体，它的电子图书馆拥有众多计算机方面的论文资料，是研究计算机方面的一个重要资源参考来源

http://www.cs.colostate.edu/testing/
可靠性研究网站，有一些可靠性方面的论文资料

http://www.cs.york.ac.uk/testsig/
约克大学的测试专业兴趣研究组网页，有比较丰富的资料下载，内容涵盖了测试的多个方面，包括测试自动化、测试数据生成、面向对象软件测试、验证确认过程等

http://www.csr.ncl.ac.uk/index.html
学校里面的一个软件可靠性研究中心，提供有关软件可靠性研究方面的一些信息和资料，对这方面感兴趣的人可以参考

http://www.dcs.shef.ac.uk/research/groups/vt/
学校里的一个验证和测试研究机构，有一些相关项目和论文可供参考

http://www.esi.es/en/main/
ESI（欧洲软件组织），提供包括CMM评估方面的各种服务

http://www.europeindia.org/cd02/index.htm
一个可靠性研究网站，有可靠性方面的一些资料提供参考

http://www.fortest.org.uk/
一个测试研究网站，研究包括了静态测试技术（如模型检查、理论证明）和动态测试（如测试自动化、特定缺陷的检查、测试有效性分析等）

http://www.grove.co.uk/
一个有关软件测试和咨询机构的网站，有一些测试方面的课程和资料供下载

http://www.hq.nasa.gov/office/codeq/relpract/prcls-23.htm
NASA可靠性设计实践资料

http://www.io.com/~wazmo/
Bret Pettichord的主页，他的一个热点测试页面连接非常有价值，从中可以获得相当大的测试资料，很有价值

http://www.iso.ch/iso/en/ISOOnline.frontpage
国际标准化组织，提供包括ISO标准系统方面的各类参考资料

http://www.isse.gmu.edu/faculty/ofut/classes/
821-ootest/papers.html 提供面向对象和基于构架的测试方面著作下载，对这方面感兴趣的读者可以参考该网站，肯定有价值

http://www.ivv.nasa.gov/
NASA设立的独立验证和确认机构，该机构提出了软件开发的全面验证和确认，在此可以获得这方面的研究资料

http://www.kaner.com/
著名的测试专家Cem Kanner的主页，里面有许多关于测试的专题文章，相信对大家都有用。Cem Kanner关于测试的最著名的书要算Testing Software,这本书已成为一个测试人员的标准参考书

http://www.library.cmu.edu/Re-search/Engineer
- ingAndSciences/CS+ECE/index.html 卡耐基梅陇大学网上图书馆，在这里你可以获得有关计算机方面各类论文资料，内容极其庞大，是研究软件测试不可获取的资料来源之一

http://www.loadtester.com/
一个性能测试方面的网站，提供有关性能测试、性能监控等方面的资源，包括论文、论坛以及一些相关链接

http://www.mareinig.ch/mt/index.html
关于软件工程和应用开发领域的各种免费的实践知识、时事信息和资料文件下载，包括了测试方面的内容

http://www.mtsu.ceu/-storm/
软件测试在线资源，包括提供目前有哪些人在研究测试，测试工具列表连接，测试会议，测试新闻和讨论，软件测试文学（包括各种测试杂志，测试报告），各种测试研究组织等内容

http://www.psqtcomference.com/
实用软件质量技术和实用软件测试技术国际学术会议宣传网站，每年都会举行两次

http://www.qacity.com/front.htm
测试工程师资源网站，包含各种测试技术及相关资料下载

http://www.qaforums.com/
关于软件质量保证方面的一个论坛，需要注册

http://www.qaiusa.com/
QAI是一个提供质量保证方面咨询的国际著名机构，提供各种质量和测试方面证书认证

http://www.qualitytree.com/
一个测试咨询提供商，有一些测试可供下载，有几篇关于缺陷管理方面的文章值得参考

http://www.rational.com/
IBM Rational的官方网站，可以在这里寻找测试方面的工具信息。IBM Rational提供测试方面一系列的工具，比较全面

http://rexblackconsulting.com/Pages/publicat-ions.htm
Rex Black的个人主页，有一些测试和测试管理方面的资料可供下载

http://www.riceconsulting.com/
一个测试咨询提供商，有一些测试资料可供下载，但不多

http://www.satisfice.com/
包含James Bach关于软件测试和过程方面的很多论文，尤其在启发式测试策略方面值得参考

http://www.satisfice.com/seminars.shtml
一个黑盒软件测试方面的研讨会，主要由测试专家Cem Kanar和James Bach组织，有一些值得下载的资料

http://www.sdmagazine.com/
软件开发杂志，经常会有一些关于测试方面好的论文资料，同时还包括了项目和过程改进方面的课题，并且定期会有一些关于质量和测试方面的问题讨论

http://www.sei.cmu.edu/
著名的软件工程组织，承担美国国防部众多软件工程研究项目，在这里你可以获俄各类关于工程质量和测试方面的资料。该网站提供强有力的搜索功能，可以快速检索到你想要的论文资料，并且可以免费下载

http://www.soft.com/Institute/HotList/
提供了网上软件质量热点连接，包括：专业团体组织连接、教育机构连接、商业咨询公司连接、质量相关技术会议连接、各类测试技术专题连接等

http://www.soft.com/News/QTN-Online/
质量技术时事，提供有关测试质量方面的一些时事介绍信息，对于关心测试和质量发展的人士来说是很有价值的

http://www.softwaredioxide.com/
包括软件工程（CMM,CMMI,项目管理）软件测试等方面的资源

http://www.softwareqatest.com/
软件质量/测试资源中心。该中心提供了常见的有关测试方面的FAQ资料，各质量/测试网站介绍，各质量/测试工具介绍，各质量/策划书籍介绍以及与测试相关的工作网站介绍

http://www.softwaretestinginstitute.com
一个软件测试机构，提供软件质量/测试方面的调查分析，测试计划模板，测试WWW的技术，如何获得测试证书的指导，测试方面书籍介绍，并且提供了一个测试论坛

http://www.sqatester.com/index.htm
一个包含各种测试和质量保证方面的技术网站，提供咨询和培训服务，并有一些测试人员社团组织，特色内容是缺陷处理方面的技术

http://www.sqe.com/
一个软件质量工程服务性网站，组织软件测试自动化、STAR-EASE、STARWEST等方面的测试学术会议，并提供一些相关信息资料和课程服务

http://www.stickyminds.com/
提供关于软件测试和质量保证方面的当前发展信息资料，论文等资源

http://www.stqemagazine.com/
软件策划和质量工程杂志，经常有一些好的论文供下载，不过数量较少，更多地需要通过订购获得，内容还是很有价值的

http://www.tantara.ab.ca/
软件质量方面的一个咨询网站，有过程改进方面的一些资料提供

http://www.tcse.org/
IEEE的一个软件工程技术委员会，提供技术论文下载，并有一个功能强大的分类下载搜索功能，可以搜索到测试类型、测试管理、测试分析等各方面资料

http://www.testing.com/
测试技术专家Brain Marick的主页，包含了Marick 研究的一些资料和论文，该网页提供了测试模式方面的资料，值得研究。总之，如果对测试实践感兴趣，该网站一定不能错过

http://www.testingcenter.com/
有一些测试方面的课程体系，有一些价值

http://www.testingconferences.com/asiastar/home
著名的AsiaStar测试国际学术会议官方网站，感兴趣的人一定不能错过

http://www.testingstuff.com/
Kerry Zallar的个人主页，提供一些有关培训、工具、会议、论文方

查看(38) 评论(0)
测试用例检查点

2008-7-04

一、环境配置测试
　　（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）错误日志的格式是否正确

查看(21) 评论(0)
对于无法再现的bug如何再现的一点思路

2008-7-04

从标题来看大家可能会觉得晕，这里说到的不可复现是指这些Bug有时出现，有时候不出现。相信大家在测试过程中肯定遇到过这种Bug，不少这种不可复现的Bug定位起来非常困难，可能很长时间都不能得到解决。能否复现这些不可复现的Bug成为大家关注的一个话题，最近国外的测试专家James Bach、Jonathan Kohl等对这个话题进行了一些探讨，这里把他们的一些思路理出来和大家分享。
      要想复现不可复现的Bug，需要先提到一个概念就是ET（Exploring Test），也就是探索式测试，这种测试方法是由James Bach首先提出来的，在所掌握的被测对象的信息不是很充分的情况下，这是一种很有效的测试方法.
      在给大家阐述如何复现不可复现的Bug的思路之前，先说说为什么要复现这些不可复现的Bug。对于整个项目或者产品而言，如果这些不可复现的Bug是很严重的Bug，比如导致系统崩溃等，如果不能及时、准确的定位和解决，最终发布出来的软件到达用户手中后，一旦出现势必会影响软件已经公司在用户心中的形象，严重的会“迫使”用户选择竞争对手的产品，这些显然都是公司所不愿看到的。而对于测试人员而言，出现了这些不可复现的Bug，实际上是一次很好的锻炼和提高机会，如果只是提交缺陷报告将这个大皮球踢给开发人员，不仅丧失了一次提高测试水平的机会，还有可能破坏和开发人员之间的关系。
      现在进入正题。当出现不可复现的Bug时，大家可以从以下五个方面来进行考虑：
1、被测对象的版本信息
      我测试的到底是哪个版本，这主要是有两个作用：一是确认我测试的是正式的软件版本，如果不是就先记录下该问题，然后选择正式的版本进行测试（开发人员基于尝试的一次非正规的修改可能会导致不可复现的Bug）；二是可以和其它版本进行对比，如果其它的版本没有类似的问题，就可以去对比这两个版本之间的区别。
2、环境
      这里的环境是指出现不可复现的Bug时所对应的测试环境等，比如测试所用的计算机，如果出现不可复现的Bug，那我换一台机器是不是还会出现类似的问题，也就是说通过环境的改变来进一步搜集不可复现Bug的相关信息。
3、模式
      这里的模式是指我对这个Bug如何出现的一个理解，先给这个Bug设定一个模式，比如是不是数据库通信中断，然后再进行测试，收集更多的信息去修改和完善这个模式，这样不断进行，最终直到Bug能完全复现为止，这个时候只要使用这个模式就可以复现出Bug了。
4、人
      这里提到的人有两个含义：一是测试是由人来进行的，人的操作、人的思维方式会有不同，通过分析这些信息也有可能找到这些不可复现的Bug的蛛丝马迹；二是想复现不可复现的Bug，往往需要多个人之间的相互协作，比如测试人员、开发人员等，通过大家的沟通和协作就能更容易去复现了。
5、测试工具
      通过一些debug工具或者log工具等搜集内存等信息，根据这些信息来进行分析，找出不同信息之间的共同点，比如某一块内存始终都会被改写等，通过这种方式来去复现Bug。
      上面的五个方面都是和ET的思想紧密相关的，通过不断的测试和不断的信息收集和分析，逐步的把模糊的、不确定的测试变成清晰的、确定的测试，这样就能复现那些不能复现的Bug了。考虑信息时可以从以上五个方面来进行考虑。

查看(21) 评论(0)
WEB站点-测试用例

2008-7-04

界面测试 -- 一般包括页面文字,控件使用，少图，CSS，颜色等
1、文字
内容一致性：
公司要求文字的一致性，例如各种宣传文字、注册的协议条款、版权信息等；
各处相同含义文字的一致性，例如标题栏文字、页面主题文字、弹出窗口文字、菜单名称、功能键文字等。
样式一致性：
   （通常分类包括）各类文字字体、字号、样式、颜色、文字间距、对齐方式
            按钮的文字间距，按钮长度一定前提下，2个字的按钮，需要中间空一格（或者其它约定，需要统一）；
            链接文字，同一类，菜单、小标题、页角文字链接，在点击时颜色变化要相同；
            对齐方式，页面上文字的对齐，例如表单、菜单列、下拉列表中文字的对齐方式（左、右、居中等要统一）
语言习惯
   中文：文字简单，含义明确，无歧异，无重复，无别字，正确运用标点符号。
   英文：
   日文：

2、按钮
1）button的样式整体要统一，例如突出、扁平、3D效果等只能选其一；
2）采用的图片表述相同功能，要采用单一图标。
3、文本框
1）录入长度限制，根据数据库的设计，页面直接限定录入长度（特殊处屏蔽复制、粘贴）；
2）文本框自身的长度限制，主要考虑页面样式。
4、单选框
1）默认情况要统一，已选择，还是未选。
5、日期控件
1）图标、控件颜色、样式统一；
2）点击控件、文本框均应弹出日期选择框。
6、下拉选择框
1）默认是第一个选项，还是提示请选择一个。

7、提示信息
1）静态文字与它的提示信息一致性，例如静态文字为‘ID’，出错信息显示‘用户ID’；
2）空值时，出错信息需要统一，例如可以采用“静态文字”+不能为空；
3）出现录入错误时，例如可以统一采用“静态文字”+格式不符合要求；
4）提示信息标点符号是否标识；点击上一步，返回的页面上不应残留出错信息；
5）静态提示信息，在录入框右侧，应有录入信息的相应要求的提示文字，达到方便操作的目的；
6）必输项提示信息，必输项提示信息采用统一的标志。

导航测试 -- 死导航、乱导航、操作复杂等
链接测试 -- 发现404错误
8、死链接
1）避免死链接情况，执行完相应操作应有返回按钮，返回到相应页面；例如：操作成功后，进入成功提示信息页面，但页面没有返回按钮，无法及时进入操作之前的页
面。
9、IE的后退
   退出系统，无论直接关闭浏览器或点击后退键，退出都不应再返回系统；
10、分辨率
1）页面文字显示、样式等要支持常见分辨率，例如CRT显示器的1024*768，LCD的1280*1024。

11、重复提交问题
    功能操作完成后，鼠标右键点击所在页面，选择弹出菜单的刷新功能，容易出现重复提交问题。
    功能操作完成后，通过IE的后退键进行重复操作，容易出现重复提交问题。
    某功能键反应时间延迟时（限制客户端网络带宽等方式来模拟实现），在短时间内重复点击该功能键，容易出现重复提交问题；

安全性测试 -- 别被人黑掉
12、防止SQL注入式攻击
1）不允许任何直接在jsp页面调用SQL语句，这种情况常发生在系统的后期修改中。
13、用户非授权页面访问
1）每个页面都需要安全验证，防止用户通过直接拷贝具体页面地址等方式，访问系统；
2）页面过期的时间设定，用户在设定时间内未进行任何操作，不允许访问系统。

查看(27) 评论(0)
界面测试用例

2008-7-04

一、文本框、按钮等控件测试

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、选择“帮助”->“关于”命令、应看见相关版权和产品信息。

查看(31) 评论(0)
如何写性能测试用例?

2008-7-04

由于性能测试与功能测试有很大的区别，所以讨论出的结果可能与预先的设想有一定的区别。
性能测试的目的：
为了验证系统是否达到用户提出的性能指标，同时发现系统中存在的性能瓶颈，起到优化系统的目的。

性能测试指标的来源：
用户对各项指标提出的明确需求；如果用户没有提出性能指标则根据用户需求、测试设计人员的经验来设计各项测试指标。（需求+经验）

主要的性能指标：
服务器的各项指标（CPU、内存占用率等）、后台数据库的各项指标、网络流量、响应时间。

BUG观点：
1、性能测试就象人在无风情况下跑步（正常情况下的性能指标）；
2、压力测试就象人在微风中跑步（在正常的基础上加大多少百分比压力的性能指标）；
3、负载测试就象人在强风中跑步（不断加压，直到系统崩溃）。

HTTP观点：
1、负载测试是正常情况下持续的加压；
2、压力测试是直接加压达到一个极限值。

大家统一的观点：
性能测试、压力测试、负载测试密不可分，可统称为性能测试。

性能测试要点：
1、性能测试是在功能测试完成之后进行。
2、性能测试计划、方案一般与测试用例统一在一个文档里。
3、测试环境应尽量与用户环境保持一致。
4、性能测试一般使用测试工具和测试人员编制测试脚本来完成，性能测试的环境应单独运行尽量避免与其他软件同时使用。
5、性能测试的重点在于前期数据的设计与后期数据的分析。
6、性能测试的用例主要涉及到整个系统架构的问题，所以测试用例一旦生成，改动一般不大，所以做性能测试的重复使用率一般比较高。（说明：当系统中出现的某个功能点需要修改，它一般只会影响到功能测试的设计用例，而对于性能测试，很少影响到性能测试的设计用例。但是如果某个功能有较大的修改，性能测试也应该进行重新测试。）

查看(24) 评论(0)

界面测试

2008-7-04

界面测试

界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。目前界面的设计引起软件设计人员的重视的程度还远远不够，直到最近网页制作的兴起，才受到专家的青睐。而且设计良好的界面由于需要具有艺术美的天赋而遭拒绝。
　　目前流行的界面风格有三种方式：多窗体、单窗体以及资源管理器风格，无论那种风格，以下规则是应该被重视的。
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):专业性强的软件要使用相关的专业术语，通用性界面则提倡使用通用性词语。
2： 规范性：
通常界面设计都按Windows界面的规范来设计，可以说：界面遵循规范化的程度越高，则易用性相应的就越好。小型软件一般不提供工具厢。
规范性细则：
1):常用菜单要有命令快捷方式。
2):完成相同或相近功能的菜单用横线隔开放在同一位置。
3):菜单前的图标能直观的代表要完成的操作。
4):菜单深度一般要求最多控制在三层以内。
5):工具栏要求可以根据用户的要求自己选择定制。
6):相同或相近功能的工具栏放在一起。
7):工具栏中的每一个按钮要有及时提示信息。
8):一条工具栏的长度最长不能超出屏幕宽度。
9): 工具栏的图标能直观的代表要完成的操作。
10):系统常用的工具栏设置默认放置位置。
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)：与正在进行的操作无关的按钮应该加以屏蔽(Windows中用灰色显示，没法使用该按钮)。
7)：对可能造成数据无法恢复的操作必须提供确认信息,给用户放弃选择的机会。
8)：非法的输入或操作应有足够的提示说明。
9): 对运行过程中出现问题而引起错误的地方要有提示，让用户明白错误出处，避免形成无限期的等待。
10): 提示、警告、或错误说明应该清楚、明了、恰当。
5：美观与协调性：
界面应该大小适合美学观点，感觉协调舒适，能在有效的范围内吸引用户的注意力。
美观与协调性细则：
1): 长宽接近黄金点比例，切忌长宽比例失调、或宽度超过长度。
2): 布局要合理,不宜过于密集，也不能过于空旷，合理的利用空间。
3): 按钮大小基本相近，忌用太长的名称，免得占用过多的界面位置。
4): 按钮的大小要与界面的大小和空间要协调。
5): 避免空旷的界面上放置很大的按钮。
6)：放置完控件后界面不应有很大的空缺位置。
7): 字体的大小要与界面的大小比例协调, 通常使用的字体中宋体9-12较为美观，很少使用超过12号的字体。
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): 主菜单数目不应太多，最好为单排布置。

13):菜单条是否显示在合适的语境中？

14):应用程序的菜单条是否显示系统相关的特性（如时钟显示）？

15):下拉式操作能正确工作吗？

16):菜单、调色板和工具条是否工作正确？

17):是否适当地列出了所有的菜单功能和下拉式子功能？

18):是否可能通过鼠标访问所有的菜单功能？

19):相同功能按钮的图标和文字是否一致？

20):是否能够用其他的文本命令激活每个菜单功能？

21):菜单功能是否随当前的窗口操作加亮或变灰？

22):菜单功能是否正确执行？

23):菜单功能的名字是否具有自解释性？

24):菜单项是否有帮助，是否语境相关？

25):在整个交互式语境中，是否可以识别鼠标操作？

26):如果要求多次点击鼠标，是否能够在语境正确识别？

27):如果鼠标有多个按钮，是否能够在语境中正确识别？

28):光标、处理指示器和识别指针是否随操作恰当地改变？
7:独特性：
如果一味的遵循业界的界面标准，则会丧失自己的个性.在框架符合以上规范的情况下，设计具有自己独特风格的界面尤为重要。尤其在商业软件流通中有着很好的迁移默化的广告效用。
测试细则：
1):　安装界面上应有单位介绍或产品介绍，并有自己的图标。
2):　主界面，最好是大多数界面上要有公司图标。
3):　登录界面上要有本产品的标志，同时包含公司图标。
4):　帮助菜单的“关于”中应有版权和产品信息。
5):　公司的系列产品要保持一直的界面风格，如背景色、字体、菜单排列方式、图标、安装过程、按钮用语等应该大体一致。

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 关闭。
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)：尽量防止对系统的独占使用。

5)：窗口能否基于相关的输入或菜单命令适当地打开？

6)：窗口能否改变大小、移动和滚动？

7)：窗口中的数据内容能否使用鼠标、功能键、方向箭头和键盘访问？

8)：当被覆盖并重调用后，窗口能否正确地再生？

9)：需要时能否使用所有窗口相关的功能？

10)：所有窗口相关的功能是可操作的吗？

11)：是否有相关的下拉式菜单、工具条、滚动条、对话框、按钮、图标和其他控制可为窗口可用，并适当地显示？

12)：显示多个窗口时，窗口的名称是否被适当地表示？

13)：活动窗口是否被适当地加亮？

14)：如果使用多任务，是否所有的窗口被实时更新？

15)：多次或不正确按鼠标是否会导致无法预料的副作用？

16)：窗口的声音和颜色提示和窗口的操作顺序是否符合需求？

17)：窗口是否正确地关闭

查看(18) 评论(0)

需求评审与需求测试

2008-7-04

需求评审与需求测试

在软件开发过程中，需求分析是最开始的工作，需求分析如果做得不够详细或者是偏离用户需求的话，往往会给项目带来灭绝性的灾难。因此如何保证需求分析的正确性，不偏离用户的需求就成了决定软件项目成败的关键。

需求工程师取得用户的显性需求后，要仔细的分析用户到底要求软件实现什么功能，用户的表达和需求工程师的理解有时间并不会一致，这样会导致用户所想的和需求说明书上所描述的有偏差。并且需求工程师取得用户的需求后必须做仔细透彻的分析，有时候用户的需求并不一定正确，可能是用户忽然的想法，并不可行。如果需求工程师不能对用户提出的需求进行判断的话，可能辛辛苦苦的实现了用户需求，结果被用户自己否决掉。用户绝对不会将责任揽到自己身上，他们只会说“你们是专家，怎么能怪我呢？”。

网上有一幅漫画形象地描述了信息在传递过程中产生的误差。

需求分析师是项目中直接与客户接触的人，需求做的好不好决定项目成败，因此对于需求规格说明书的正确性必须进行彻底的验证，将错误在开工前就消灭。

　　通常有两种手段来检查需求的正确性，分别是需求评审和需求测试。
　
　　1、需求评审
        需求评审可以分为正式评审与非正式评审，在需求规格说明书完成后，需求组必须自己对需求做评审。如果需求组递交的需求规格说明书在指导后面的工作的时候出现很明显的错误，我想拿高工资的需求分析人员是无法向老板交差的。为了需求分析人员的名誉，他们自己会对自己提交的内容进行审核，直到他们认为自己的工作成果足够好，才会将需求规格说明书提交给正式评审组。
　
　　正式评审组的成员一般由公司内经验最丰富，技术最牛的人（技术总监）来担任，当然参加评审的人中间还应该有项目经理、QA人员、测试人员、架构师，他们仔细阅读需求规格说明书，并针对自己将要开展的工作内容进行检查，并提出问题。
　
　　正式评审是最后一关，如果正式评审通过了，将进入系统设计阶段，如果在系统设计阶段再跨里程碑来修改需求的话，所花费的代价将大大增加。因此正式评审将是一个“鸡蛋里挑骨头”的过程，只有所有的人都认为需求已经没有什么可挑剔评审才能通过。
　
　　2、需求测试
      可以认为需求评审也属于需求测试范围，但是这里提的需求测试和评审不同，它是测部门来测试需求是否符合用户的要求。显然这是有难度的，传统的测试工作都是从单元测试开始，编码之前全部做得都是计划性工作。测试人员对需求分析进行测试？那么前提条件是测试人员必须熟悉需求分析，这对测试人员的要求提高了。将需求测试人员作为测试人员中的特殊种类来培养，能够对需求是否正确进行检查，这样就能够在需求阶段就引入测试。当然需求测试人员可以是经过培训的需求分析人员，但是他必须脱离需求组，加入测试部门，这样才能保证测试不是自己人测自己，以保证测试的效果。
　
　　需求测试不等同于后面阶段集成测试或者系统测试，后面的测试都是软件已经编写完成的条件下，判断软件是否会出错。而需求测试，只是验证需求是否真的是用户的。对于需求的功能测试，可以用RAD工具建立界面原型，用户通过原型的操作来确定是否需求跟他的期望相同。对于那些用户不合理的需求，测试人员要能够分辨出来，并跟用户进行核对，确定用户的真实需求。可以说需求测试是需求测试人员和用户共同来执行的。
　

     之所以将需求测试和需求评审并行进行，是因为需求评审是项目的各方干系人共同进行的检查工作，评审工作关注的焦点是分散的，很难将偏离用户的需求检查出来，并且涉及的人很多，因此不可能耗费太长时间。而需求测试执行的时间可以比评审时间长，有专门的关注方面，能够检查出不合理的需求分析，在项目前期进行错误纠正，往往比实现后纠正要节约几百甚至几千倍的成本。

查看(26) 评论(0)
LR视频集

2008-6-18

LoadRunner视频集

http://www.sg138.cn发布

注：如转载请注明出处。

在线观看：

小布老师视频 - 测试工具概述，兼LoadRunner介绍1-4讲

http://www.sg138.cn/LR/lr-1.html

http://www.sg138.cn/LR/lr-2.html

http://www.sg138.cn/LR/lr-3.html

http://www.sg138.cn/LR/lr-4.html

小布老师LR系列培训视频  - LoadRunner概述(上下)

http://www.sg138.cn/LR/lr-5.html

http://www.sg138.cn/LR/lr-6.html

小布老师LR系列培训视频  - LoadRunner安装

http://www.sg138.cn/LR/lr-7.html

小布老师LR系列培训视频  - 录制和回放测试脚本(1-3)

http://www.sg138.cn/LR/lr-8.html

http://www.sg138.cn/LR/lr-9.html

http://www.sg138.cn/LR/lr-10.html

小布老师LR系列培训视频 - LoadRunner测试Tuxedo应用系统 1-4

http://www.sg138.cn/LR/lr-11.html

http://www.sg138.cn/LR/lr-12.html

http://www.sg138.cn/LR/lr-13.html

http://www.sg138.cn/LR/lr-14.html

小布老师视频 - 在LoadRunner中使用动态库技术

http://www.sg138.cn/LR/lr-15.html

另：如需下载，请直接查看源文件中swf文件下载即可。

查看(135) 评论(0)
测试用例之性能测试用例

2008-4-14
性能测试、压力测试、负载测试、强度测试、稳定性测试、健壮性测试、功能测试、接口测试……,这么多眼花缭乱的测试类型名称，估计很少有人能准确的区分并说出定义来，至于对应的测试用例如何编写和执行，就更不用说了。

如果问测试工程师测试用例如何编写，就象是问程序员如何编写代码得到的答案一样，每个人都会给出不同的编写方法，但实用的测试用例却象优秀的程序一样难以编写。

目前国内，测试工程师却时常要面对“已经延期几倍计划时间的项目”，测试用例如何发挥更大的作用，是一个迫切需要解决的问题。事实上，完全可以把测试用例看成是测试工程师编写的程序：这个“程序”是为了辅助测试工作的进行而开发的，目的是为了发现软件问题，同时“顺便”证明软件功能是否符合要求。

本文针对上面的问题，以设计性能测试用例为示范，讲解在企业实际工作中，如何有效划分测试种类和编写对应的测试用例，使测试工作更加合理、高效率的开展。

1测试种类和阶段

1.1 测试种类

对于测试种类的说法多种多样，最多的能达到30多种测试类型。而实际工作中很多测试是互相包含的。按照企业中实际工作需要，通常主要进行下面几种类型的测试：功能测试、健壮性测试、接口测试、强度测试、压力测试、性能测试、用户界面测试、可靠性测试、安装/反安装测试、文档测试。

下面介绍几种重要的测试种类及其测试的内容：

功能测试：功能测试主要针对产品需求说明书的测试，是验证功能是否否合需求，包括原定功能的检验、是否有冗余功能、遗漏功能。这类测试应由测试员做，这并不意味着程序员在发布前不必检查他们的代码能否工作，他们也需要进行基本功能的测试。

接口测试：程序员对各个模块进行系统联调的测试，包含程序内接口和程序外接口测试。这个测试，在单元测试阶段进行了一部分工作，而大部分都是在集成测试阶段完成的。由开发人员进行。

性能测试：在交替进行负荷和强迫测试时常用的术语。性能测试关注的是系统的整体。它和通常所说的强度、压力/负载测试测试有密切关系。所以压力和强度测试应该与性能测试一同进行。

用户界面测试：对系统的界面进行测试，测试用户界面是否友好、是否方便易用、设计是否合理、位置是否正确等一系列界面问题

安装/反安装测试：安装测试主要检验软件是否可以正确安装，安装文件的各项设置是否有效，安装后能否影响原系统；反安装是逆过程，测试是否删除干净，是否给影响原系统等。

文档测试：主要测试开发过程中针对用户的文档，以需求、用户手册、安装手册等为主，检验文档是否和实际应用存在差别。文档测试不需要编写测试用例。

测试种类的划分不要拘泥于上面的形式，总体来说应该服从于测试策略，可以根据具体工作的特点进行安排，为了工作更容易开展，完全可以把一些测试合在一起进行。在后面的性能测试用例的编写上，充分体现了这一思想。

1.2 测试阶段

和开发过程相对应，测试过程会依次经历单元测试、集成测试、系统测试、验收测试四个主要阶段。对应关系如图1所示：

需求开发

高层设计

详细设计

编程

单元测试

集成测试

系统测试

验收测试

图1 开发与测试的“V”型关系

单元测试：单元测试是针对软件设计的最小单位––程序模块甚至代码段进行正确性检验的测试工作，通常由开发人员进行。

集成测试：集成测试是将模块按照设计要求组装起来进行测试，主要目的是发现与接口有关的问题。由于在产品提交到测试部门前，产品开发小组都要进行联合调试，因此在大部分企业中集成测试是由开发人员来完成的。。

系统测试：系统测试是在集成测试通过后进行的，目的是充分运行系统，验证各子系统是否都能正常工作并完成设计的要求。它主要由测试部门进行，是测试部门最大最重要的一个测试，对产品的质量有重大的影响。

验收测试：验收测试以需求阶段的《需求规格说明书》为验收标准，测试时要求模拟实际用户的运行环境。对于实际项目可以和客户共同进行，对于产品来说就是最后一次的系统测试。测试内容为对功能模块的全面测试，尤其要进行文档测试。

尽管测试阶段的划分十分明确，但是在具体的项目和产品的测试中，尤其在执行测试时，会根据实际需要来开展。

1.3 测试种类、阶段和用例的关系

为了便于在实际工作中提高效率，同时方便测试用例的编写和执行，可以把上面提到的各个测试类型与对应的测试用例合并。合并后的测试用例主要有以下几种：

1．功能测试用例：包含功能测试、健壮性测试、可靠性测试

2．性能测试用例：包含性能测试、压力测试、强度测试

3．集成测试用例：包含接口测试、健壮性测试、可靠性测试

4．安全测试用例：安全测试用例

5．用户界面测试用例：包含用户界面测试用例、少量功能测试用例

6．安装/反安装测试用例：安装/反安装测试用例

综合上面的分析，测试种类、测试阶段以及执行人员具体的关系如表1所示。

总之，测试的种类应该尽量的少，这样每次都可以执行更多的测试内容。例如在进行功能测试的同时，完全可以进行健壮性的测试。（当然如果产品健壮性方面要求较高，就可以把健壮性测试作为独立的测试。）

2性能用例编写方案

性能测试在软件测试中占有重要的地位，而性能测试又关联很多内容。例如压力和强度测试就与性能测试密切相关：针对一个网站进行测试，模拟10到50个用户就是在进行常规性能测试，用户增加到1000乃至上万就变成了压力/负载测试，如果同时对系统进行大量的数据查询操作，就包含了强度测试。

为了便于性能测试工作的实施，这里的性能测试综合了性能、强度、压力、负载等多方面的测试内容，主要包含的内容有：预期性能指标测试、用户并发性能测试、疲劳强度测试、大数据量测试和速度测试、网络、服务器等方面的内容。

性能测试不同的系统有不同的要求，编写方法要根据实际要求进行编写，本文提出一个常见的参考方案，在实际工作中，可以根据需要加入其它例如内存泄露等和性能相关的测试用例。

下面介绍各个部分性能测试用例包含的内容：

2.1预期性能指标测试用例

通常系统在设计前都会提出一些性能指标，这些指标是性能测试要完成的首要工作之一。针对每个指标都要编写多个测试用例来验证是否达到要求，并根据测试结果来改进系统的性能。

这类通常以单用户为主，如果遇到并发用户的情况，可以归到并发用户测试用例中。这类用例通常都是可以通过手工来执行的用例，例如示例中的上传一份文件，期望的性能为2M/S，完全可以手动上传文件，同时用秒表计时。这些内容通常在需求说明书中可以显而易见的查到。不过当看到如支持并发用户300人，就应该放到后面进行。测试结果也是直接记录是否达到要求，如果系统没有达到要求则进行改善。

2.2用户并发性能测试用例

用户并发测试是性能测试的最主要部分，包含了负载测试和压力测试的过程。主要是逐渐增加用户数量来加重系统负担，直到出现不能接收的性能点或者瓶颈。一般要测试正常数量的用户并发和极限数量下用户并发的情况。

并发用户测试主要是对系统的核心功能和重要业务进行测试，要以真实的业务数据作为输入，选择有代表性和关键的业务操作来设计测试用例。主要编写以下两个方面的用例：

核心模块的测试（可以理解为“单元性能测试”）：对核心功能模块进行并发用户测试，测试系统是否能够稳定运行。例如对于互联网的公用邮件系统，每天早上9点左右可能是收发邮件的高峰，这时候上千的用户都要在上班后进入邮件系统，系统这个时候需要接收和发送大量的邮件。所以邮件系统这一功能模块要进行并发测试。通过测试可以知道数据库服务器、操作系统、网络设备等是否能够承受住考验，同时可以对瓶颈进行分析。

表2列出来一些常见的参数(表格中的数据为示例的测试用例和测试结果)，可以根据实际需要进行增加和删除，其中磁盘I/O、数据库相关测试参数要根据实际情况进行选择，因此没有列出。

在编写这类用例时，要进行综合分析，选出系统中的各个核心模块，分别设计每个模块的测试用例：把模块划分成小的“事务”进行测试，这样在测试分析中便于定位问题究竟出现在哪里。例如邮件系统可以划分成：接收邮件、发送邮件、打开邮件等小的事务进行测试用例的编写，每个操作做为一个用例来执行。

业务组合性能测试（可以理解为“集成性能测试”）：所有的用户不会只使用核心模块，通常每个功能都可能被使用到，所有既要模拟多用户的“相同”操作，又要模拟多用户的不同操作，对多个业务进行组合性能测试。

业务组合测试是更接近用户实际操作系统的测试，因此用例编写要充分考虑实际情况，选择最接近实际的场景进行设计。这里的业务组成单位以不同模块中的“子操作事务”为单位，进行各个模块的不同业务的组合。例如在办公自动化系统中就可以选择“公文模块中的发送公文、电子公告模块中的查看公告信息、网上论坛模块中的上传文件”等事务作为一组组合业务进行测试，用例设计信息如下：

功能：在线用户达到高峰时，用户可以正常使用系统，保证500个以内用户可以同时在线使用系统。

目的：测试系统500个以内的用户同时在线能否使用比较常见的模块：公文系统、电子公告、网上论坛。

方法：采用LoadRunner的录制工具录制三个业务：

业务1––在公文系统内，进行打开、修改等操作；

业务2––在电子公告系统内，查看、发布公告；

业务3––在网上论坛系统内发布帖子，查看文章。每个业务分配一定数目的用户，利用LoadRunner来完成相关参数的测试。

其它部分设计可以参考表2。执行时要分别记录各个事务的执行情况。

多用户并发性能测试是性能测试的核心内容，包含了全部与多用户相关的测试。因此设计时要全面考虑，不要有遗漏。在测试执行时，本部分通常是采用性能测试工具例如LoadRunner来进行测试的，因此更容易执行和提高效率。

2.3疲劳强度与大数据量测试

疲劳强度测试是在系统稳定运行下模拟最大用户数量、并长时间运行系统，通过综合分析执行指标和资源监控来确定系统处理最大业务量时的性能。

疲劳强度测试的目的就是检验系统长时间运行后的性能，因此设计用例时，需要编写不同参数或者负载条件下的多个测试用例，对服务器、软件、网络进行不同条件下的综合测试分析，测试时要记录系统发生故障的信息作为测试结果。疲劳强度测试也是采用测试工具进行的。

大数据量测试分为两种：一个是针对某些系统存储、传输、统计查询等业务进行大数据量的测试；另一个是与前面并发测试相结合的综合数据测试。编写用例时主要编写前一部分，后一部分尽量放在并发测试中。

大数据量测试一般是针对那些对数据库有特殊要求的系统进行测试，例如电信业务系统的手机短信息表，由于有的用户关机或者不在服务区，每秒钟需要有大量的短信息保存，同时在用户联机后还要及时发送，因此对数据库性能有极高的要求，需要专门测试。

本部分用例设计表格可以参考用户并发性能测试部分。

2.4网络性能测试

网络性能测试主要是为了准确展示带宽、延迟、负载和端口的变化是如何影响用户的响应时间的。在实际的软件项目中，主要是测试用户数目与网络带宽的关系。

编写用例的格式如表3(表格中的数据为示例数据)：

本部分可以独立测试，也可以和用户并发性能测试、疲劳强度与大数据量性能测试结合起来，在原有的基础上采用工具来调整网络设置，从而达到监视网络性能的目的。通常网络性能都是采用工具进行性能评估，由系统集成工程师来进行。

2.5服务器性能测试

本部分的测试用例不必独立编写，或者根据实际需要编写少量的测试用例，建议这部分的用例编写和前两部分结合起来，在用户并发性能测试、疲劳强度与大数据量性能测试时完成对服务器性能的监控，完成对服务器性能的评估。

2.6性能分析基本策略

在上面的用例执行完成后，接下来要进行性能分析。性能分析是性能测试的最终目的，否则测试出的指标就不会有实际意义，这里主要介绍一下性能分析的基本思路。性能分析通常要围绕三个方面进行：软件、服务器、网络。

软件主要是分析具体事务执行时间，尤其并发用户部分，根据测试工具测试出的结果分析那些事务执行的慢，然后可以分析执行较慢的代码，针对网页可以分析具体的页面元素执行情况。

服务器的分析要结合软件的运行情况进行分析，着重分析硬件的执行参数，CPU、硬盘、内存、中断、内存等情况，分析尤其要注意对这些参数进行综合分析，往往各个参数之间会互相影响，最后在调查、分析整体系统的基础上，找出影响服务器整体性能的瓶颈，确定相应的升级需求：

1. 服务器硬盘负载较重，需增加硬盘。

2. CPU整体性能偏低，需增加或更新CPU。

3. 网卡性能偏低，需更换光纤网卡。

4. 硬盘I/O负载任务繁重，需使用高转速硬盘或采用RAID卡。

5. 内存资源短缺，需增大内存。

6. 其他方面，需要升级软件系统、合理进行子网划分、加强管理等。

网络性能分析要结合结合服务器和测试目标软件，通常网络传输慢会有软件和服务器方面的原因，甚至有时候会有客户端方面的原因。不过目前网络的环境普遍可以，不管是局域网还是广域网，网络的环境越来越好。

3用例管理

测试用例的管理我们可以借鉴开发过程中对程序的管理方法，我们可以把测试用例看成程序––测试工程师编写的程序，这个程序也要经过“设计”、“开发”、“测试”、“版本管理”、“发布”、“维护”等一系列操作，然后按照管理软件程序的方法来管理测试用例。

用例管理主要包含评审、修改、执行用例、用例版本维护、用例升级方面的内容。

3.1 用例评审

测试用例评审是测试用例不可缺少的一个环节，这是对“测试部门开发出的产品”进行的“测试”。基本思路是对测试准备阶段的成果进行分期评审，依次评审系统/验收测试用例、集成测试用例、单元测试用例。

评审用例在比较正规的公司更容易实施，要求相应的软件开发团队必须在实际工作中对测试给予足够的重视，才可以把这项工作做好，否则只是走走形式。有效的用例评审通常由下面两种形式组成：

测试部门外部评审––主要是由开发部、项目实施部、甚至销售人员参加的评审，目的主要是查找测试工程师编写的用例是否缺少内容。建议采用非正式评审的形式进行，因为我们很难把开发人员组织在一起，一般来说他们的开发进度压力很大，能够抽出时间看文档已经是“很给面子了”。当然不统一进行评审会耽误工程的进度，所以在实际工作中如果时间紧迫，可以提前启动测试实施工作，待评审完成后进行用例的修改工作。通常测试工作进行一段时间评审就会结束，这个时候测试执行人员可以在工作中对测试用例的内容进行动态的调整，再次执行被修改过的部分用例（如果能够采用正式评审，效果肯定会更好。）。

外部评审主要工作方式是用文档直接记录评审结果，测试人员根据评审结果对用例进行升级修改。

测试部门内部评审––部门内部同行对测试策略的评审，评审的核心内容是测试策略和用例编制思路是否正确，以此来保证测试用例的有效性。可以组织正式的评审，由用例的设计人员进行讲解，然后大家共同评审；也可以把文档发给部门的同事进行评审。内部评审有些象开发人员在单元测试中的交叉测试。

内部评审的主要工作方式是项目会议，大家可以进行激烈的讨论，共同探讨用例编写、交流经验，这样用例的编写水平才能提高，同时可以进行一些创新。

评审方式中的外部评审最为重要。因为开发人员很容易发现用例中遗漏了什么内容，同时还可以发现错误的用例––因为存在对需求理解的偏差。用例外部评审可以理解为开发人员在查找测试人员编写的“程序”缺陷。

通常情况下先执行内部评审，然后执行外部评审。很多时候，内部评审会被忽略，建议要进行内部评审。这样至少有两个好处：集思广益和提高测试小组输出文档的质量。

3.2 管理方案

国内大多数IT公司在测试用例的发展经历了以下几个阶段：
- 无用例而执行测试：测试的初级阶段，完全手工测试，测试执行工程中没有测试用例作为执行依据，可能会按照需求进行测试；
- 有用例而不使用用例执行测试：已经编写测试用例，但是受各种环境的影响，例如需求变动频繁、编写的用例过于简单等，测试用例编写后在实际工作中不能使用；
- 按照部分用例执行测试：随着用例编写水平的提高，部分测试用例可以在测试中发挥作用；
- 完全按照用例执行测试：组织建立了规范的项目管理过程，对测试用例进行规范的管理，执行测试用例以用例为准则来执行测试。
完全按照测试用例执行测试是一个公司测试水平的体现，测试用例管理成为这一阶段的主要内容。测试用例管理的核心内容是版本管理。如果测试用例是采用文字编辑软件例如word编写，建议采用工具（例如Visual SourceSafe）对用例进行控制。可以参照图2进行。

编写用例

用例评审

进入版本控制库

用例修改

使用用例&维护&升级

图2 测试用例管理示意图

1、编写用例：测试工程师根据需求分析、概要设计、详细设计等文档编写测试用例。

2、用例评审：3.1小结说明了用例的评审。原则上用例像程序一样，要经过多次的修改才可以通过，而实际工作中只进行一到两次。

3、用例修改：评审结束后，需要根据评审意见进行修改，修改后通常不再进行评审。建议在时间和人力资源比较充裕的情况下，对用例的评审要像测试开发部门的产品一样，经过反复的评审和修改，然后正式投入使用，因为每次评审可能都有新的发现。

4、使用用例：在执行任务时，从版本控制库取出用例，执行时建议直接在用例上记录测试结果。这样做会带来两个好处：首先是下次测试时可以看见上次测试的结果记录，可以起一个提醒的作用；其次可以一次性的把发现的缺陷输入到缺陷跟踪数据库中，在输入时可以进行综合统计，避免输入重复的缺陷。每次使用后送入版本控制库中，进行版本的管理。

5、用例升级/维护：随着软件产品的不断修改、升级，对应的用例也需要升级和维护。针对同一个项目，可以根据需求的变更不断进行维护；如果是产品，用例的维护则更加重要，要达到用例和产品的版本一一对应。

测试用例的管理还可以采用专门的测试软件例如TestDirector等来进行管理，测试工具通常会具备上面的功能。如果有条件，建议采用集成华的测试工具，这样更容易对测试执行全程进行监控，可以把测试需求、测试用例、缺陷管理统一起来，大大提高测试效率。

在测试用例管理规范化并成为测试的执行准则后，管理测试用例带来的巨大好处开始逐渐显现出来，测试用例成为评估测试和改进测试工作的主要依据，可以给工具带来巨大的方便。例如可以通过测试用例的执行情况来统计分析执行结果，编写测试报告，判断软件测试是否完成，通过统计测试覆盖率、测试合格率、重要测试对象的合格率是多少来完成对软件质量的评估；尤其是新员工到岗后，可以更容易介入工作。

总之，不管是性能测试还是其它测试都要本着“一切从实际出发”的原则，根据不同产品的特性进行用例编写，最后按照要求完成测试，达到提高产品质量的目的。在测试用例的编写过程中，尤其要记得“创新”，如果长期依靠某一测试用例编写模式、采用某些固定的模板，测试用例编写工作肯定会停滞在某一层次上不再发展，一定要跟着测试对象的不断变化来调整策略，在具体的工作中改进和提高，才能“开发”出优秀的测试用例！
查看(170) 评论(0)