1.击鼠标
　　击鼠标比赛现在开始!参赛者有拉尔夫、威利和保罗。
　　拉尔夫10秒钟能击10下鼠标；威利20秒钟能击20下鼠标；保罗5秒钟能击5下鼠标。以上各人所用的时间是这样计算的；从第一击开始，到最后一击结束。
　　他们是否打平手？如果不是，谁最先击完40下鼠标？
　　2.感觉
　　用第一感觉判断8＋8=91这个等式正确吗？说明理由。
　　3.谎话
　　如果下列每个人说的话都是假话，那么是谁打碎了花瓶？
　　夏克：吉姆打碎了花瓶。
　　汤姆：夏克会告诉你谁打碎了花瓶。
　　埃普尔：汤姆，夏克和我不太可能打碎花瓶。
　　克力斯：我没打碎花瓶。
　　艾力克：夏克打碎了花瓶，所以汤姆和埃普尔不太可能打碎花瓶。
　　吉姆：我打碎了花瓶，汤姆是无辜的。
　　4.大有作为
　　鲁道夫、菲利普、罗伯特三位青年，一个当了歌手，一个考上大学，一个加入美军陆战队，个个未来都大有作为。现已知：
　　A． 罗伯特的年龄比战士的大；
　　B． 大学生的年龄比菲利普小；
　　C． 鲁道夫的年龄和大学生的年龄不一样。
　　请问：三个人中谁是歌手？谁是大学生？谁是士兵？
　　5.麻省理工大学的学生
　　美国麻省理大学的学生来自不同国家。
　　大卫、比利、特德三名学生，一个是法国人，一个是日本人，一个是美国人。现已知：
　　1、 大卫不喜欢面条，特德不喜欢汉堡包；
　　2、 喜欢面条的不是法国人；
　　3、 喜欢汉堡包的是日本人；
　　4、 比利不是美国人。
请推测出这三名留学生分别来自哪些国家？
　　6.宴会桌旁
　　在某宾馆的宴会厅里，有4位朋友正围桌而坐，侃侃而谈。他们用了中、英、法、日4种语言。现已知：
　　A．甲、乙、丙各会两种语言，丁只会一种语言；
　　B．有一种语言4人中有3人都会；
　　C．甲会日语，丁不会日语，乙不会英语；
　　D． 甲与丙、丙与丁不能直接交谈，乙与丙可以直接交谈；
　　E． 没有人既会日语，又会法语。
　　请问：甲乙丙丁各会什么语言？
　　7.借机发财
　　从前有A、B两个相邻的国家，它们的关系很好，不但互相之间贸易交往频繁，货币可以通用，汇率也相同。也就是说A国的100元等于B国的100元。可是两国关系因为一次事件而破裂了，虽然贸易往来仍然继续，但两国国王却互相宣布对方货币的100元只能兑换本国货币的90元。有一个聪明人，他手里只有A国的100元钞票，却借机捞了一大把，发了一笔横财。请你想一想，这个聪明人是怎样从中发财的？
　　8.不合理的安排
　　S先生正在家里休息时，接到了一个陌生人打来的预约电话。对方很想在下下个星期的周五去他家里拜访他。但是S先生并不想见这个陌生人，于是他连忙说：“下下个礼拜五我非常忙。上午要开会，下午1点钟要去参加一个学生的婚礼，接着4点钟要去参加一个朋友的孩子的葬礼，随后是我的叔叔的七十寿辰宴会。所以那天我实在是没有时间来接待您的来访了。”
　　请仔细看题，S先生的话里有一处是不可信的，是哪个地方？
　　9.快马加鞭
　　墨西哥农村现在仍然可以看到人们用马和驴运载货物。一位商人把四匹马从甲村拉到乙村，而从甲村到乙村，A马要花一小时，B马要花两小时，C马要花四小时，D马要花五小时。
　　这位商人一次只能拉两匹马，回来时他还要骑一匹马，其中以走得慢的那匹马作为从甲村拉到乙村所需的时间。听说有人花了12小时就把四匹马全部从甲村拉到乙村，请问：他是如何办到的？

软件测试相关的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的个人主页，提供一些有关培训、工具、会议、论文方

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

从标题来看大家可能会觉得晕，这里说到的不可复现是指这些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了。考虑信息时可以从以上五个方面来进行考虑。

界面测试 -- 一般包括页面文字,控件使用，少图，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）页面过期的时间设定，用户在设定时间内未进行任何操作，不允许访问系统。

 

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

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

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

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

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

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

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

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

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

界面测试

界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。目前界面的设计引起软件设计人员的重视的程度还远远不够，直到最近网页制作的兴起，才受到专家的青睐。而且设计良好的界面由于需要具有艺术美的天赋而遭拒绝。 　　目前流行的界面风格有三种方式：多窗体、单窗体以及资源管理器风格，无论那种风格，以下规则是应该被重视的。 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)：窗口是否正确地关闭

需求评审与需求测试

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

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

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

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

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

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

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

我的同事C，也是我的好朋友，跳槽去了一个正在迅速发展的IT公司，年薪翻了一倍。而他，从准备找工作到工作敲定，仅仅一周。二十万的年薪，在IT行业，对于不到五年工作经验的人来说，是一个很不错的收入了，我的同事自然也很开心很满足。我的其他同事，还有我的朋友，听说后，都非常羡慕，觉得他的运气很好。我也觉得他的运气不错，但除了运气外，我更多地觉得，他具备了这样的实力，所以当机会来了，自然就是他的了。我也会觉得，他的实力，源于他的态度，源于他一点一滴的积累与提升。
　　

　　在与C合作的两年多的时间，我们的合作非常愉快，虽然存在异议，但是所有的争议都是为了把工作做得更好。我们的第一次合作，是一个短信过滤模块，产品出来后，是一个初步的原型，根据我对SMS的理解、业务的需求和维护方便，给他提了很多不错的建议，对于我所提的建议，他没像其他开发那样讨价还价，几天之后又交给我一个比较完美的产品。

　　对产品的测试，我非常挑剔，不满足于简单的需求，在产品满足了功能需求后，继续进行了深入的测试、改进和性能调优；产品试行后，继续跟进产品在实际环境的运行情况，对产品进行二次完善，所有的这个过程，C都非常配合，力求完美，毫无怨言。最终，他开发的这个产品，是我们SMS系统中，功能最完善、故障最少的产品。如果当初，没有他积极的配合，也许，这个产品也像其他的产品一样，只是一个普通的模块，我再努力也是徒劳。
　　

　　在05年春节，我们的P2P系统出现了很大的故障，故障的原因无法定位也无法重现，当时整个团队都承受了很大的压力，我自己也在想方设法定位问题解决问题。那段时间，C给了我非常大的帮助，我们在一起讨论问题可能产生的原因，在交换各自的见解，每有一个新的想法就测试问题是否重现，同时配合代码白盒检查，将问题一个个地解决。我们都很清楚，这些隐藏的问题，仅仅靠一个开发或测试是很难定位的，需要的是一个配合良好的团队的努力。在后来的性能调优中，我提了很多建议，别的开发都没时间去做优化，是C主动接过了别人负责的模块，积极地配合我对P2P进行了长达两个月的性能调优与隐患挖掘，P2P最终成了一个从05年底到现在都无任何来自于软件的故障。现在再翻开我们合作完成的P2P性能调优报告，整整50页，每个改进都密密麻麻地写满了我们各自的原因追踪、改进建议和结果分析，现在再看，我自己还会感动。我想，这样的工作态度，是成就了他年薪翻倍的主要原因。
　　

　　在他刚进入公司的时候，回复bug也跟其他同事那样只是简单地写上“fixed”或“ok”，我对他说：“回复bug的时候，最好能够写上产生bug的原因、解决的方法、升级的步骤以及这个改动引起哪些变动，方便测试进行模块升级和问题跟踪，也方便以后维护管理。”从此以后，他所有的bug回复都非常详细、专业。但，我其他的同事，同样的话我重复了N次，部门经理也发邮件要求大家去遵循，但是没几个同事能够像C那样自觉、认真的地回复，也没几个同事可以坚持两年多来一直都是那样认真地回复每个bug。我想，这就是人与人之间的差距，从这么一件简单的事情上，可以看到不同的人的工作态度。我们在羡慕别人得到了好机会的青睐，以为这只是运气，但事实上，运气的背后，是他的付出。

　　现在，当我们再回头查看两年前C所负责的bug，对于每一个问题，都可以从他的回复中看出当初问题产生的原因以及解决方法，对于公司来说，这无疑是一笔财富。我的这个同事，并不是一个非常聪明的人，也不是一个很能说会道的人，却是一个勤奋、认真的人，也是一个知道自己要的是什么的人。在项目不紧张的时候，他会主动去研究公司的核心产品，尽管那不是他所负责的，但他的主动为他积累了基础，也为他积累了机会；他甚至还会去学习与IT毫不相干的法律，为了维护自己的合法权益。他知道上班时间，也知道下班时间，上班的时候全部投入认真工作，但下班之后就很难得在公司找到他的影子。因为他觉得，下班了，就是自己的时间了，应该回家跟家里人一起分享。我非常欣赏他的这样的一种工作状态，也非常欣赏他的生活态度。公司的人才保留机制做得不好，他来公司两年工资的提高并不是很大，但他还是坚持以学习的态度认真做好他的工作，当他所负责的项目接近了尾声，他觉得自己的努力付出并没有得到相应的回报，所以决定离开。他知道自己的英文口语并不太好，没有像我那样一心坚持进管理完善的外企；因为决定了要离开，他也不像别人那样，边工作边找工作；他看中了一间正在迅速发展的公司，请了10天的年假，开始了他的应聘之路，而他也真的幸运，一周不到，就收到了他想去的公司的offer，当然，最令人兴奋的是他想去的公司满足了他二十万年薪的要求。

　　同事C去新的公司上班将近一个月了，我的其他同事和朋友说起他新的工作，仍然羡慕不已，但我会觉得，这不仅仅是因为他的运气，而是因为在过去的几年中，他努力的付出、认真的学习、塌实的工作，当然，更重要的是他清楚自己需要什么，也努力去争取自己想要的。我的身边，很多人都会在抱怨自己工资不高，也有很多人抱怨自己没有机会，但是，他们很少在自己的身上去找原因，只是将一切归于运气。我很想对他们说，你是否觉得C的运气很好？那你是否也像C那样在好运降临之前主动、认真、塌实地做好每一件事情？

　　其实，机会，并不是天上掉下来的馅饼，而是抓住机会的本事。当你历练出了抓住机会的本事，好运自然降临。

背景：

        我们的软件产品需要在A、B、C三种硬件平台（理论上对我们的软件影响是不大的）上工作，早些时候已经成功在A上工作了，但在B、C上还有些问题，加班的那天是一个deadline，需要保证在B、C上也能够工作。这个产品由X、Y、Z三个部分组成，分别由三个team负责，基本的关系是：X和用户打交道，X调用Y，Y是数据进数据出，Y调用Z，Z和硬件打交道。

        其中，X和Y都是新写的程序，而且早些时候，在X上发现了较多BUG，Y基本上没发现问题。Z的代码在以前的产品中就有，相对已经比较稳定。由于项目的时间压力，这三个部分没有时间做分别的测试，只是程序员简单测一下自己的代码后，就要集成和测试了（这就是我的具体工作）。除了三个team的leader留下外，X的程序员都留下了；Y的leader检查了team members的工作后，认为没什么问题就放他们回家了；Z的leader最“无辜”，目送所有手下下班后，自己不得不留下。

都是指针惹的祸：

        一开始要加班是因为X的工作还没有完成，于是大家就一边等，一边“催”（X的leader声称要到12点才能完成，真是乌鸦嘴），一边各忙各的（我在上网看新闻）。事实上，X到7点多就完成了，但一测试发现有明显的内存访问问题。于是X就调试，由于X在内存访问问题上已经“臭名昭著”了，所以大家（至少我）相信是以前类似的问题，或者是以前的修改没有彻底。

        但很快，X发现问题是：Y传了一个空指针给X；很快，Y也证实了X的说法。大家责问Y，为什么程序员自己测试时没有发现？其实很简单，程序员的单元测试程序会检查是否是空指针，如果空就打印空行。于是，X和Y开始“踢球”，互相要对方加上空指针的错误处理代码；但踢了一会后，新的疑问出现了，Y照理不应该出现空指针，所以要么Y的代码有问题，要么Y要证明自己没错。

找一个BUG好难：
        于是Y的leader也加入了调试队伍，因为Y的代码都有详细的Log，所以很快就定位到了他的一个team member的代码里。不幸的是，Y learder的开发机器在关键时刻down掉了。好在我们初步实施了软件配置管理，Y leader很快在别人的机器上重新搭建好了调试环境。

        Y作了些修改（事实上，他改的这些代码都是无关紧要的），经我测试后，发现还是不行。以我的职业感觉，我觉得X也有问题（后来知道是歪打正着）。但X宁可上sina看“北京某景区有人裸泳”也不肯检查一下自己的代码。Y经过艰苦的调试（其实绝大部分时间我想是在理解这些不属于他的代码），发现是因为某个数据没有取得而导致了空指针的出现，但照理，Z应该总是把这项数据传送给Y的。但Y对Z的“指控”很快被证明是无效的，因为Z leader向大家“展示”了她从硬件取得的数据是好好的。

        于是，Z leader继续吃饼干；Y leader继续调试；X一干人等继续“研究”我国风景区的管理问题。而我也终于无聊到了极点，开始“友情赞助”，检查Y的问题代码。代码很少注释，写得也很随意，甚至缩进的格式都显林乱；但好在代码不长，逻辑也不复杂。我重点检查了内存的操作，但没有发现问题。

        正在我纳闷同样一段代码，为什么其他数据都可以取得，偏偏这项数据取不到的时候，传来了Y learder的叫声。虽然听起来很像绝望后的惨叫，但我敢肯定，这的确是找到真正问题后的欢呼（和惨叫相似也是情理之中，毕竟都是在身心及其疲惫后发出的）。果然，他发现了：这项取不到的数据的名称写错了，应该是Status，但写成了State。（Y向Z要数据时，要传给Z一个数据的名称，然后Z就从硬件取得，并返回给Y。这些数据的名称是Z定义的）那么，怎么会发生这种低级错误的呢？原来，出错的代码Y的那个程序员从另外一处Copy来的，其他数据项的名称都是相同的，偏偏这项数据的名称不同。

有多少Code可以重来：
        Y leader忙着改C文件和H文件，因为这个数据项的名称出现在多处，所以Y leader改得很仔细，也很辛苦；我想他心里一定在臭骂他的这个team member，为什么不定义一个常量或者宏。在Y leader改代码的时候，我也在想，这简直就像Z在故意制造陷阱：这两组数据这么类似，而且其他数据项的名称都相同，为什么偏偏这项数据，一个叫State，另一个叫Status，真是有空，真TMD。

        Y leader终于确认改正了所有该改的State。但用他的team member的单元测试程序一测发现还是有老问题。你可以想象到我们当时的感觉，就像吃了一吨广告上那个很夸张的“凉”得透顶的润喉糖。

        但是！ Y leader大叫：单元测试程序里的State也要改成Status。在无数双眼睛的注视下，Y leader颤抖着replace all，save，F5。终于，当大家看到计算机上的一串字符后，每个人都舒心的笑了。（当然，如果没有刚才的虚惊一场，可能不是每个人都在快工作到午夜的时候还能笑得动的）。我想，此时此刻，此情此景，在Y leader的眼里，一定滚动着些东西，除了眼屎。

        现在，又轮到我上场了。Build时发现X的代码中也需要把一些State改成Status。（如果当初他们也检查一下就好了）。X的程序员也没有定义常量或者宏的习惯，所以我Build了多次，他们才把所有要改的State改掉。

一个QA的精彩：

        后来发生的事可以用一个“峰回路转”来形容，在无数双眼睛的注视下（我的手没有颤抖，因为人已经麻木了，或者说一切都习惯了），我启动了我们的软件，连接到B平台上，检查所有的数据，全部OK；连接到C平台上，检查所有的数据，全部OK。搞定了！

        “回家，回家，回家的感觉是多么多么……”，我想，当时，也许每个人的心里都在回荡着王杰的这首老歌（如果知道这首歌的话），包括陪我们加班到深夜的可怜的老板。

        当其他人已打算转身时，我的思想在激励的斗争着。看着同事们的脸，包括老板沧桑的脸和几张幼稚却不显年轻的程序员的脸，想着家里一天没能见到老爸的孩子，我想回家，但是，我是QA。我默默的连上了A平台，然后发现什么数据都没有。（如果把这个场景定格或者淡出，我怎么想都觉得象好莱坞预示续集的结尾）。

当我喊住大家时，我不知道该如何描述自己的感受。

        无声，无声，又见无声！突然，老板告诉大家：今天的deadline搞定B和C平台就可以了，A平台下个礼拜再说。管他是真是假，老板发话就可以了，还不开溜。3分钟后（其中半分钟是给CVS打上Tag），我坐上了回家的Taxi。

        凌晨一点的上海还是霓虹闪烁，好美。

bug遗漏，我想这个是很多公司很多人头痛的一个问题。众所周知，bug是不可能被完全消灭的，当然也就意味着在发布前不能被全部找出来。于是乎当项目发布后，或多或少都会出现bug遗漏的现象，即使发布初期没有发现，随着时间的流逝，一些隐藏的bug也会慢慢浮现出来。那么对于遗漏的bug，我们该怎么去做？

        古时云：亡羊补牢，为时未晚也。对于遗漏的bug，我们应该去透彻的分析它产生的原因，然后吸取教训，防止再次出现。这样遗漏bug的数量就会越来越少，趋于0。那么怎样的分析才是透彻的呢？我发表一下自己的观点。

        根据我的经验，总结下来有以下几点，首先从根源上说，需求的问题。需求是一切的根本，我们所做的一切都是在需求的基础上进行的，那么需求会不会有问题？当然有啦，否则要需求评审干嘛，每次需求评审，或多或少都能发现一些需求的问题，在还没有开始编码之前就把需求的bug找出来，这个是最理想的状态。显然这个不现实，但是能多发现一个不合理的地方，那就能减少很多风险。因此需求关要把好。当然要求测试人员在需求评审时就要找出需求的bug，这个是要求比较高的，需要对业务的熟悉以及对相似产品的认识。需求关把好了，那么就算踏出了成功的第一步。

        其次，要尽早与开发人员进行测试设计评审，统一对需求的认识（开发测试人员都可能存在对需求的认识不正确）。越早进行，越能够避免出现因为对需求的认识不同而导致出现的问题（最可怕的是因此产生的隐性bug），这样也能减少后期很多不必要的资源浪费。

        接下来，就是用例设计了，这方面体现了一个测试人员的真实地能力。考虑的面要广，包括:使用不同的测试方案，不同的测试数据的类型（要齐全），正常流与异常流等来覆盖所有的需求。

        然后就开始执行测试，要全面地执行测试用例，并且在测试过程中不断的添加遗漏的用例。在时间允许下，尽可能的执行。

        回归阶段，除了要回归前面发现的bug，还要重视回归那些bug相关的模块，这个教训是很多的，所以千万不能忽视。一个小小的小小的参数变动可能引起一个比较远的功能点的大bug，继而引发遗漏。所以这个是需要开发人员与测试人员去识别的。开发人员熟知代码，知道改动的地方会被哪些模块调用或者会引起哪些变化，因此开发人员需要通知测试人员测试关注点以及加强自测。在开发人员与测试人员无间隔的合作下，这种bug的遗漏会减少很多。

        发布前期，应该在保证所有的bug都fixed的前提下，把所有用例都回归一下，以免遗漏。

        最后终于发布了，发布好就可去FB了，^o^。不要在开心的情况下放松神经，所谓行百里，半九十，不能倒在最后的冲刺关头。细心细心再细心。只要一步步走下来，那么就可以把遗漏的bug数量减到最低。

        当然最好做自动化脚本，方便以后的回归。这就是我想说的，大家有意见可以跟着，共同进步。

一、目的

        对 BUG 概念、类型划分、 BUG 状态、 BUG 严重程度等内容进行定义和规范，以便进一步指导我们的测试工作。

二、概念

        BUG ：软件中存在的瑕疵，可能会导致系统失效。简单的说就是软件系统中存在的可能导致系统出错、失效、死机等问题的错误或缺陷。

三、 BUG 的类型划分

•  功能类

A. 重复的功能

B. 多余的功能

C. 功能实现与设计要求不相符

D. 功能使用性、方便性、易用性不够

•  界面类

A. 界面不美观

B. 控件排列、格式不统一

C. 焦点控制不合理或不全面

•  数据处理类

A. 数据有效性检测不合理

B. 数据来源不正确

C. 数据处理过程不正确

D. 数据处理结果不正确

•  流程类

A. 流程控制不符和要求

B. 流程实现不完整

•  提示信息类

A. 提示信息重复或出现时机不合理

B. 提示信息格式不符和要求

C. 提示框返回后焦点停留位置不合理

6 、建议类

A. 功能性建议

B. 操作建议

C. 检校建议

D. 说明建议

7 、性能类

A. 并发量

B. 数据量

C. 压缩率

D. 响应时间

8 、常识类

A. 违背正常习俗习惯的，比如日期 / 节日等

9 、特殊类

A. 不符合 OEM 版本或 DEMO 版本特殊要求的

四、 BUG 状态

        已提交：测试员发现 BUG 后提交到 BUG 管理系统中的状态。（初始状态）

        已修改：程序员在修改了 BUG 后提交到 BUG 管理系统中的状态。

        不修改：程序员或项目经理根据需求分析、概要设计、详细设计说明书等上的要求经过考虑后决定对 BUG 不进行修改。其 BUG 的状态为不修改，需要说明理由。

        延迟：根据目前项目进程或计划等情况，暂时延期的状态

        待讨论：需要进行讨论后才能决定是否需要修改的 BUG 的状态。

        已验证：已经解决的并经过测试员复测的 BUG 的状态。

        关闭：完全解决了，只供以后备查的状态

        重新打开：重新出现在新的版本中，重新打开以前关闭的 bug 状态

        ( 当然在 bug 工具中，可以自己定制适合项目的状态项目，比如废除，拒绝等 )

五、 BUG 的等级划分与优先级

1 、严重：死机，数据丢失，主要功能完全丧失，系统悬挂等错误。修改优先级为最高，该级别需要程序员立即修改。

2 、较高：主要功能丧失，导致严重的问题，或致命的错误声明。修改优先级为高，该级别需要程序员尽快修改。

3 、一般：次要功能丧失， 不太严重，如提示信息不太准确。修改优先级为中，该级别需要程序员修改。

4 、轻微：微小的问题，对功能几乎没有影响，产品及属性仍可使用，如有个错别字。修改优先级为低，该级别需要程序员修改或不修改。

六、 BUG 的优先级 （一般与 BUG 等级挂钩）

参考 1 、紧急、非常高、高、中等、低

　参考 2 、下一个 build 版本 ,a 测试 ,b 测试 , 发布版本，最终发布版本

七、 BUG 记录内容

•  编号

•  标题

•  项目模块

•  测试阶段

•  类型

•  操作环境 ( 操作系统 ,IE 等软硬件环境 )

•  严重程度（等级及优先级）

•  BUG 状态

•  测试员

•  程序员（解决者）

•  解决方案

•  解决日期

•  测试日期

•  详细描述（步骤、结果、期望、备注）

一个家庭主妇在微软当软件测试员，《软件开发的科学与艺术》一书中讲述了这个真实的故事。那位妇女四十多岁了，高中毕业，非常初级的计算机水平还是跟着自己的女儿学到的。让一个大学都没有上过的家庭妇女做测试人员是多么不可思议的事情！不过，她思维独特，怪点子很多，能很快的发现一些问题。微软最终决定聘用她，而她也成为了一名优秀的测试员。

　　在IT圈里做技术的人群里，测试员可能是一个特殊的群体。他们之中计算机专业 “科班出身”的并不多，毕业于其它专业的大有人在，什么建筑、中文、营销专业的都有。另一方面，相对那些做研究开发、项目管理、软件实施甚至是售前售后技术支持的技术人员，测试工作给人的感觉总是技术性低，因此测试员的薪酬水平与其它同等资历的研发人员相比总有一些差距，甚至在重视测试的外资软件公司也是如此。测试不过是每天重复一些操作来发现Bug（错误）。事实的确如此，哪怕是非常热爱这项职业的人也承认它的枯燥。

　　H做专业的测试工程师已经有一年多的时间了，目前仍然在做较为底层的测试。有时候也会写写测试需要的代码，但还没有开始设计整个项目测试案例。目前H正在为微软的某一软件做测试，工作的流程非常严谨而明晰，这自然也意味着枯燥的重复。枯燥并没有淹没H的工作激情，发现一个Bug带来很大的成就感，特别是想到每天将会有几百万人通过使用没有这个Bug的软件准确无误的达到他们的目的。

　　前途在H心目中是非常明朗的，颇有一些“随需”择业的味道。曾经有媒体报道过近来软件测试工程师在职场需求中的风光景况，尽管IT行业的总体需求仍然疲软。在北京和上海等地，测试员的需求量占到了招聘总量的近 1/3。另一方面，H认为从测试员成长为软件项目管理者是更有优势的。例如微软的开发方式本来就是“测试驱动”的，在测试过程中发现了墙角还有没涂到油漆的小块，开发则根据这个思想再补上那一块。测试的经历恰好让人更能从用户的角度来考虑问题，更能深入了解程序开发过程中可能出现的问题，这都是成为一个优秀的项目管理者的必要条件。尽管可能一整天都为了一个小控件“循规蹈矩”地反复测试并撰写测试文档，这样的重复被H当作了重要的积累。H喜欢新东方学校的徐小平新书《骑驴找马》中的一句话：“重复做汉堡，就是麦当劳；重复煮咖啡，就是星巴克；重复教托福，就是俞敏洪；重复做好事，就是活雷锋。”

　　不过，乐观的情况并不具有普遍性。在另一家软件公司做测试的L对工作感到厌倦。这是一家国内著名软件公司的子公司，整个公司测试员就只有两个人。公司不久前才刚刚把测试作为一个单独的部门划分开，尽管建立了测试管理流程，但是没有代码测试，也没有测试工具。测试案例并没有完全规范化，很多测试都是随机的手工操作。这样的测试部门更像是一个辅助性的、服务性的部门，测试员的收入也比开发人员低一个档次。在这样的工作环境下，L觉得是为了生活而忍受枯燥，最痛苦的是这种得不到锻炼和进步的状况。

　　L所在公司对测试的态度在国内具有一定的代表性，将测试部门独立都只是最近的事情。更一些公司仍然停留在开发人员自行测试的阶段。可是如果开发者自己能找到Bug，谁还会在开发时犯下这样的错误呢？在软件业发达的国家，软件测试工程师地位丝毫不亚于程序开发员，一些公司对测试员的要求甚至是曾经做过程序开发的。对测试的重视更体现在人员的配置上，以微软Windows 2000产品团队中最主要的三类人员为例，项目经理约250人，开发人员约1700人，测试人员则是3200人左右。

　　国内软件业的测试员大都与L一样困惑。选择离开并不能解决问题。整个测试环节成熟起来，才将意味着测试员地位的改善。

关于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.页面最大化检查：测试最大化/最小化/还原时页面是否做了对应的处理。

 

Transactions（用户事务分析）
　　用户事务分析是站在用户角度进行的基础性能分析。
1、Transation Sunmmary（事务综述）
　　对事务进行综合分析是性能分析的第一步，通过分析测试时间内用户事务的成功与失败情况，可以直接判断出系统是否运行正常。
2、Average Transaciton Response Time（事务平均响应时间）
　　“事务平均响应时间”显示的是测试场景运行期间的每一秒内事务执行所用的平均时间，通过它可以分析测试场景运行期间应用系统的性能走向。
　　例：随着测试时间的变化，系统处理事务的速度开始逐渐变慢，这说明应用系统随着投产时间的变化，整体性能将会有下降的趋势。
3、Transactions per Second（每秒通过事务数/TPS）
　　“每秒通过事务数/TPS”显示在场景运行的每一秒钟，每个事务通过、失败以及停止的数量，使考查系统性能的一个重要参数。通过它可以确定系统在任何给定时刻的时间事务负载。分析TPS主要是看曲线的性能走向。
　　将它与平均事务响应时间进行对比，可以分析事务数目对执行时间的影响。
　　例：当压力加大时，点击率/TPS曲线如果变化缓慢或者有平坦的趋势，很有可能是服务器开始出现瓶颈。
4、Total Transactions per Second（每秒通过事务总数）
　　“每秒通过事务总数”显示在场景运行时，在每一秒内通过的事务总数、失败的事务总署以及停止的事务总数。
5、Transaction Performance Sunmmary（事务性能摘要）
　　“事务性能摘要”显示方案中所有事务的最小、最大和平均执行时间，可以直接判断响应时间是否符合用户的要求。
　　重点关注事务的平均和最大执行时间，如果其范围不在用户可以接受的时间范围内，需要进行原因分析。
6、Transaction Response Time Under Load（事务响应时间与负载）
　　“事务响应时间与负载”是“正在运行的虚拟用户”图和“平均响应事务时间”图的组合，通过它可以看出在任一时间点事务响应时间与用户数目的关系，从而掌握系统在　　用户并发方面的性能数据，为扩展用户系统提供参考。此图可以查看虚拟用户负载对执行时间的总体影响，对分析具有渐变负载的测试场景比较有用。
7、Transaction Response Time(Percentile)（事务响应时间(百分比)）
　　“事务响应时间(百分比)”是根据测试结果进行分析而得到的综合分析图，也就是工具通过一些统计分析方法间接得到的图表。通过它可以分析在给定事务响应时间范围内能执行的事务百分比。
8、Transaction Response Time(Distribution)（事务响应时间(分布)）
　　“事务响应时间(分布)”显示在场景运行过程中，事务执行所用时间的分布，通过它可以了解测试过程中不同响应时间的事务数量。如果系统预先定义了相关事务可以接受的最小和最大事务响应时间，则可以使用此图确定服务器性能是否在可以接受的范围内。
　　Web Resources（Web资源分析）
　　Web资源分析是从服务器入手对Web服务器的性能分析。
1、Hits per Second（每秒点击次数）
　　“每秒点击次数”，即使运行场景过程中虚拟用户每秒向Web服务器提交的HTTP请求数。
　　通过它可以评估虚拟用户产生的负载量，如将其和“平均事务响应时间”图比较，可以查看点击次数对事务性能产生的影响。通过对查看“每秒点击次数”，可以判断系统是否稳定。系统点击率下降通常表明服务器的响应速度在变慢，需进一步分析，发现系统瓶颈所在。
2、Throughput（吞吐率）
　　“吞吐率”显示的是场景运行过程中服务器的每秒的吞吐量。其度量单位是字节，表示虚拟用在任何给定的每一秒从服务器获得的数据量。
　　可以依据服务器的吞吐量来评估虚拟用户产生的负载量，以及看出服务器在流量方面的处理能力以及是否存在瓶颈。
　　“吞吐率”图和“点击率”图的区别：
　　“吞吐率”图，是每秒服务器处理的HTTP申请数。
　　“点击率”图，是客户端每秒从服务器获得的总数据量。
3、HTTP Status Code Summary（HTTP状态代码概要）
　　“HTTP状态代码概要”显示场景或会话步骤过程中从Web服务器返回的HTTP状态代码数，该图按照代码分组。HTTP状态代码表示HTTP请求的状态。
4、HTTP Responses per Second（每秒HTTP响应数）
　　“每秒HTTP响应数”是显示运行场景过程中每秒从Web服务器返回的不同HTTP状态代码的数量，还能返回其它各类状态码的信息，通过分析状态码，可以判断服务器在压力下的运行情况，也可以通过对图中显示的结果进行分组，进而定位生成错误的代码脚本。
5、Pages Downloader per Second（每秒下载页面数）
　　“每秒下载页面数”显示场景或会话步骤运行的每一秒内从服务器下载的网页数。使用此图可依据下载的页数来计算Vuser生成的负载量。
　　和吞吐量图一样，每秒下载页面数图标是Vuser在给定的任一秒内从服务器接收到的数据量。但是吞吐量考虑的各个资源极其大小（例，每个GIF文件的大小、每个网页的大小）。而每秒下载页面数只考虑页面数。
　　注：要查看每秒下载页数图，必须在R-T-S那里设置“每秒页面数(仅HTML模式)”。
6、Retries per Second（每秒重试次数）
　　“每秒重试次数”显示场景或会话步骤运行的每一秒内服务器尝试的连接次数。
　　在下列情况将重试服务器连接：
　　A、初始连接未经授权
　　B、要求代理服务器身份验证
　　C、服务器关闭了初始连接
　　D、初始连接无法连接到服务器
　　E、服务器最初无法解析负载生成器的IP地址
7、Retries Summary（重试次数概要）
　　“重试次数概要”显示场景或会话步骤运行过程中服务器尝试的连接次数，它按照重试原因分组。将此图与每秒重试次数图一起使用可以确定场景或会话步骤运行过程中服务器在哪个时间点进行了重试。
8、Connections（连接数）
　　“连接数”显示场景或会话步骤运行过程中每个时间点打开的TCP/IP连接数。
　　借助此图，可以知道何时需要添加其他连接。
　　例：当连接数到达稳定状态而事务响应时间迅速增大时，添加连接可以使性能得到极大提高（事务响应时间将降低）。
9、Connections Per Second（每秒连接数）
　　“每秒连接数”显示方案在运行过程中每秒建立的TCP/IP连接数。
　　理想情况下，很多HTTP请求都应该使用同一连接，而不是每个请求都新打开一个连接。通过每秒连接数图可以看出服务器的处理情况，就表明服务器的性能在逐渐下降。
10、SSLs Per Second（每秒SSL连接数）
　　“每秒SSL连接数”显示场景或会话步骤运行的每一秒内打开的新的以及重新使用的SSL连接数。当对安全服务器打开TCP/IP连接后，浏览器将打开SSL连接。
　　Web Page Breakdown（网页元素细分）
　　“网页元素细分”主要用来评估页面内容是否影响事务的响应时间，通过它可以深入地分析网站上那些下载很慢的图形或中断的连接等有问题的
元素。
1、Web Page Breakdown（页面分解总图）
　　“页面分解”显示某一具体事务在测试过程的响应情况，进而分析相关的事务运行是否正常。
　　“页面分解”图可以按下面四种方式进行进一步细分：
1)、Download Time Breaddown（下载时间细分）
　　“下载时间细分”图显示网页中不同元素的下载时间，同时还可按照下载过程把时间进行分解，用不同的颜色来显示DNS解析时间、建立连接时间、第一次缓冲时间等各自所占比例。
2)、Component Breakdown(Over Time)（组件细分(随时间变化)）
　　“组件细分”图显示选定网页的页面组件随时间变化的细分图。通过该图可以很容易的看出哪些元素在测试过程中下载时间不稳定。该图特别适用于需要在客户端下载控件较多的页面，通过分析控件的响应时间，很容易就能发现那些控件不稳定或者比较耗时。

1. What types of documents would you need for QA, QC, and Testing?
2. What did you include in a test plan?
3. Describe any bug you remember.
4. What is the purpose of the testing?
5. What do you like (not like) in this job?
6. What is quality assurance?
7. What is the difference between QA and testing?
8. How do you scope, organize, and execute a test project?
9. What is the role of QA in a development project?
10. What is the role of QA in a company that produces software?
11. Define quality for me as you understand it
12. Describe to me the difference between validation and verification.
13. Describe to me what you see as a process. Not a particular process, just the basics of having a process.
14. Describe to me when you would consider employing a failure mode and effect analysis.
15. Describe to me the Software Development Life Cycle as you would define it.
16. What are the properties of a good requirement?
17. How do you differentiate the roles of Quality Assurance Manager and Project Manager?
18. Tell me about any quality efforts you have overseen or implemented. Describe some of the challenges you faced and how you overcame them.
19. How do you deal with environments that are hostile to quality change efforts?
20. In general, how do you see automation fitting into the overall process of testing?
21. How do you promote the concept of phase containment and defect prevention?
22. If you come onboard, give me a general idea of what your first overall tasks will be as far as starting a quality effort.
23. What kinds of testing have you done?
24. Have you ever created a test plan?
25. Have you ever written test cases or did you just execute those written by others?
26. What did your base your test cases?
27. How do you determine what to test?
28. How do you decide when you have ‘tested enough?’
29. How do you test if you have minimal or no documentation about the product?
30. Describe me to the basic elements you put in a defect report?
31. How do you perform regression testing?
32. At what stage of the life cycle does testing begin in your opinion?
33. How do you analyze your test results? What metrics do you try to provide?
34. Realising you won’t be able to test everything - how do you decide what to test first?
35. Where do you get your expected results?
36. If automating - what is your process for determining what to automate and in what order?
37. In the past, I have been asked to verbally start mapping out a test plan for a common situation, such as an ATM. The interviewer might say, “Just thinking out loud, if you were tasked to test an ATM, what items might you test plan include?” These type questions are not meant to be answered conclusively, but it is a good way for the interviewer to see how you approach the task.
38. If you’re given a program that will average student grades, what kinds of inputs would you use?
39. Tell me about the best bug you ever found.
40. What made you pick testing over another career?
41. What is the exact difference between Integration & System testing, give me examples with your project.
42. How did you go about testing a project?
43. When should testing start in a project? Why?
44. How do you go about testing a web application?
45. Difference between Black & White box testing
46. What is Configuration management? Tools used?
47. What do you plan to become after say 2-5yrs (Ex: QA Manager, Why?)
48. Would you like to work in a team or alone, why?
49. Give me 5 strong & weak points of yours
50. Why do you want to join our company?
51. When should testing be stopped?
52. What sort of things would you put down in a bug report?
53. Who in the company is responsible for Quality?
54. Who defines quality?
55. What is an equivalence class?
56. Is a “A fast database retrieval rate” a testable requirement?
57. Should we test every possible combination/scenario for a program?
58. What criteria do you use when determining when to automate a test or leave it manual?
59. When do you start developing your automation tests?
60. Discuss what test metrics you feel are important to publish an organization?
61. In case anybody cares, here are the questions that I will be asking:
62. Describe the role that QA plays in the software lifecycle.
63. What should Development require of QA?
64. What should QA require of Development?
65. How would you define a “bug?”
66. Give me an example of the best and worst experiences you’ve had with QA.
67. How does unit testing play a role in the development/software lifecycle?
68. Explain some techniques for developing software components with respect to testability.
69. Describe a past experience with implementing a test harness in the development of software.
70. Have you ever worked with QA in developing test tools? Explain the participation Development should have with QA in leveraging such test tools for QA use.
71. Give me some examples of how you have participated in Integration Testing.
72. How would you describe the involvement you have had with the bug-fix cycle between Development and QA?
73. What is unit testing?
74. Describe your personal software development process.
75. How do you know when your code has met specifications?
76. How do you know your code has met specifications when there are no specifications?
77. Describe your experiences with code analyzers.
78. How do you feel about cyclomatic complexity?
79. Who should test your code?
80. How do you survive chaos?
81. What processes/methodologies are you familiar with?
82. What type of documents would you need for QA/QC/Testing?
83. How can you use technology to solve problem?
84. What type of metrics would you use?
85. How to find that tools work well with your existing system?
86. What automated tools are you familiar with?
87. How well you work with a team?
88. How would you ensure 100% coverage of testing?
89. How would you build a test team?
90. What problem you have right now or in the past? How you solved it?
91. What will you do during the first day of job?
92. What would you like to do five years from now?
93. Tell me about the worst boss you’ve ever had.
94. What are your greatest weaknesses?
95. What are your strengths?
96. What is a successful product?
97. What do you like about Windows?
98. What is good code?
99. Who is Kent Beck, Dr Grace Hopper, Dennis Ritchie?
100. What are basic, core, practises for a QA specialist?
101. What do you like about QA?
102. What has not worked well in your previous QA experience and what would you change?
103. How you will begin to improve the QA process?
104. What is the difference between QA and QC?
105. What is UML and how to use it for testing?
106. What is CMM and CMMI? What is the difference?
107. What do you like about computers?
108. Do you have a favourite QA book? More than one? Which ones? And why.
109. What is the responsibility of programmers vs QA?
110. What are the properties of a good requirement?
111. Ho to do test if we have minimal or no documentation about the product?
112. What are all the basic elements in a defect report?

招聘兼职（网上市场调研专员）

职位类型：兼职
招聘人数：不限
公司介绍：本公司是一家专业的市场调研服务公司，协助各大国际市场调研公司在中国招聘网上市场调研专员。本公司已经通过了国内权威第三方支付平台支付宝公司的“信任商家”认证，成为国内免费兼职网站中少数获得此认证的网站之一，信誉极佳！
岗位要求：诚实，有耐心！从事过市场调查方面工作的优先。
工作内容：我们会通过电子邮件，不定期发送调查问卷给调研专员，调研专员自己安排时间填写问卷就可以了。收入按完成问卷的数量计算，每份20分钟的问卷报酬大约为10元。

详情请访问：http://14593647.freesurvey.net.cn

QQ咨询 ：您的QQ
电子邮件：您的Email