困因
范文一：功能测试常用方法
功能测试大全
1、在测试过程中所用到的测试方法：
a ，输入非法数据;
b ，输入默认值;
c ，输入特殊字符集;
d ，输入使缓冲区溢出的数据;
e ，输入相同的文件名;
2、登陆
①用户名和密码都符合要求(格式上的要求)
②用户名和密码都不符合要求(格式上的要求)
③用户名符合要求，密码不符合要求(格式上的要求)
④密码符合要求，用户名不符合要求(格式上的要求)
⑤用户名或密码为空
⑥数据库中不存在的用户名，不存在的密码
⑦数据库中存在的用户名，错误的密码
⑧数据库中不存在的用户名，存在的密码
⑨输入的数据前存在空格
⑩输入正确的用户名密码以后按[enter]是否能登陆
⑾输入的密码是否以*显示
⑿输入密码错误次数是否有限制
⒀密码输入框测试时要特别注意进行字母大写输入的测试。
3、添加
①要添加的数据项均合理，检查数据库中是否添加了相应的数据
②留出一个必填数据为空
③按照边界值等价类设计测试用例的原则设计其他输入项的测试用例
④不符合要求的地方要有错误提示
⑤是否支持table 键
⑥按enter 是否能保存
⑦若提示不能保存，也要察看数据库里是否多了一条数据
⑧如果存在两条相同的记录是否也能添加成功
4、删除
①删除一个数据库中存在的数据，然后查看数据库中是否删除
②删除一个数据库中并不存在的数据，看书否有错误提示，并且数据库中没有数据被删除
③输入一个格式错误的数据，看是否有错误提示，并且数据库中没有数据被删除。 ④输入的正确数据前加空格，看是否能正确删除数据
⑤什么也不输入
⑥是否支持table 键
⑦是否支持enter 键
⑧若记录与其它表的数据有关联，是否允许删除
5、查询
1) 精确查询：
①输入的查询条件为数据库中存在的数据，看是否能正确地查出相应得数据
②输入正确的查询条件前加上空格，看是否能正确地查出相应的数据
③输入格式或范围不符合要求的数据，看是否有错误提示
④输入数据库中不存在的数据
⑤不输入任何数据
⑥是否支持table 键
⑦是否支持enter 键
⑧ 要关注组合查询和分页控件
2) 模糊查询：
①输入一些字符，看是否能查出数据库中所有的相关信息
6、设计功能和界面测试用例
6.1文本框、按钮等控件测试
6.1.1文本框的测试
a ，输入正常的字母或数字。
b ，输入已存在的文件的名称;
c ，输入超长字符。例如在“名称”框中输入超过允许边界个数的字符，假设最多255个字符，尝试输入256个字符，检查程序能否正确处理;
d ，输入默认值，空白，空格;
e ，若只允许输入字母，尝试输入数字; 反之; 尝试输入字母;
f ，利用复制，粘贴等操作强制输入程序不允许的输入数据;
g ，输入特殊字符集，例如，NUL 及\n等;
h ，输入超过文本框长度的字符或文本，检查所输入的内容是否正常显示;
i ，输入不符合格式的数据，检查程序是否正常校验，如，程序要求输入年月日格式为yy/mm/dd，实际输入yyyy/mm/dd，程序应该给出错误提示
6.1.2命令按钮控件的测试
a ，点击按钮正确响应操作。如，单击确定，正确执行操作; 单击取消，退出窗口;
b ，对非法的输入或操作给出足够的提示说明，如 ，输入月工作天数为32时，单击”确定“后系统应提示：天数不能大于31;
c ，对可能造成数据无法恢复的操作必须给出确认信息，给用户放弃选择的机会;
6.1.3单选按钮控件的测试
a ，一组单选按钮不能同时选中，只能选中一个。
b ，逐一执行每个单选按钮的功能。分别选择了“男”“女”后，保存到数据库的数据应该相应的分别为“男”“女”;
c ，一组执行同一功能的单选按钮在初始状态时必须有一个被默认选中，不能同时为空;
6.1.4控件文本框的测试
a ，直接输入数字或用上下箭头控制，如，在“数目”中直接输入10，或者单击向上的箭头，使数目变为10;
b ，利用上下箭头控制数字的自动循环，如，当最多数字为253时，单击向上箭头，数目自动变为1; 反之亦适用;
c ，直接输入超边界值，系统应该提示重新输入;
d ，输入默认值，空白。如，“插入”数目为默认值，点击“确定”; 或，删除默认值，使内容为空，单击“确定”进行测试;
e ，输入字符。此时系统应提示输入有误。
6.1.5组合列表框的测试
a ，条目内容正确，其详细条目内容可以根据需求说明确定;
b ，逐一执行列表框中每个条目的功能;
c ，检查能否向组合列表框输入数据;
6.1.6复选框的测试
a ，多个复选框可以被同时选中;
b ，多个复选框可以被部分选中;
c ，多个复选框可以都不被选中;
d ，逐一执行每个复选框的功能;
6.1.7列表框控件的测试
a ，条目内容正确; 同组合列表框类似，根据需求说明书确定列表的各项内容正确，没有丢失或错误;
b ，列表框的内容较多时要使用滚动条;
c ，列表框允许多选时，要分别检查shift 选中条目，按ctrl 选中条目和直接用鼠标选中多项条目的情况;
6.1.8滚动条控件的测试
a ，滚动条的长度根据显示信息的长度或宽度及时变换，这样有利于用户了解显示信息的位置和百分比，如，word 中浏览100页文档，浏览到50页时，滚动条位置应处于中间; b ，拖动滚动条，检查屏幕刷新情况，并查看是否有乱码;
c ，单击滚动条;
d ，用滚轮控制滚动条;
e ，滚动条的上下按钮。
6.1.9各种控件在窗体中混和使用时的测试
a ，控件间的相互作用;
b ，tab 键的顺序，一般是从上到下，从左到右;
c ，热键的使用，逐一测试;
d ，enter 键和esc 键的使用;
ps ：在测试中，应遵循由简入繁的原则，先进行单个控件功能的测试，确保实现无误后，再进行多个控件的的功能组合的测试。
范文二：功能测试常用方法
, 常用的功能测试方法
,
, 首先测试程序的核心功能，然后测试辅助功能。
, 首先测试功能，然后测试性能。
, 首先测试常见情况，然后测试异常情况。
, 首先测试经过变更的部分，然后测试没有变更的部分。
, 首先测试影响大的问题，然后测试影响小的问题。
, 首先测试必须测试的部分，然后测试可选或没有要求测试的部分 功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。常用的测试方法如下:
1. 页面链接检查:每一个链接是否都有对应的页面，并且页面之间切换正确。
2. 相关性检查:删除/增加一项会不会对其他项产生影响，如果产生影响，这些影响是否都正确。
3. 检查按钮的功能是否正确:如update, cancel, delete, save等功能是否正确。
4. 字符串长度检查: 输入超出需求所说明的字符串长度的内容, 看系统是否检查字符串长度,会不会出错.
5. 字符类型检查: 在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型,会否报错.
6. 标点符号检查: 输入内容包括各种标点符号,特别是空格,各种引号,回车键.看系统处理是否正确.
7. 中文字符处理: 在可以输入中文的系统输入中文,看会否出现乱码或出错.
8. 检查带出信息的完整性: 在查看信息和update信息时,查看所填写的信息是不是全部带出.,带出信息和添加的是否一致
9. 信息重复: 在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理.
10. 检查删除功能:在一些可以一次删除多个信息的地方,不选择任何信息,按”delete”,看系统如何处理,会否出错;然后选择一个和多个信息,进行删除,看是否正确处理.
11. 检查添加和修改是否一致: 检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填;添加规定为整型的项,修改也必须为整型.
12. 检查修改重名:修改时把不能重名的项改为已存在的内容,看会否处理,报错.同时,也要注意,会不会报和自己重名的错.
13. 重复提交表单:一条已经成功提交的纪录，back后再提交，看看系统是否做了处理。
14. 检查多次使用back键的情况: 在有back的地方,back,回到原来页面,再back,重复多次,看会否出错.
15. search检查: 在有search功能的地方输入系统存在和不存在的内容,看search结果是否正确.如果可以输入多个search条件,可以同时添加合理和不合理的条件,看系统处理是否正确.
16. 输入信息位置: 注意在光标停留的地方输入信息时,光标和所输入的信息会否跳到别的地方.
17. 上传下载文件检查:上传下载文件的功能是否实现，上传文件是否能打开。对上传文件的格式有何规定，系统是否有解释信息，并检查系统是否能够做到。
18. 必填项检查:应该填写的项没有填写时系统是否都做了处理，对必填项是否有提示信息，如在必填项前加*
19. 快捷键检查:是否支持常用快捷键，如Ctrl+C Ctrl+V Backspace等，对一些不允许输入信息的字段，如选人，选日期对快捷方式是否也做了限制。
20. 回车键检查: 在输入结束后直接按回车键,看系统处理如何,会否报错.
范文三：功能测试常用的策略和方法
功能测试（黑盒测试）常用的策略和方法
黑盒测试（Black-box Testing ，又称为功能测试或数据驱动测试）是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产品的内部结构和处理过程。
采用黑盒技术设计测试用例的方法有：等价类划分、边界值分析、错误推测、因果图和综合策略。
黑盒测试注重于测试软件的功能性需求，也即黑盒测试使软件工程师派生出执行程序所有功能需求的输入条件。黑盒测试并不是白盒测试的替代品，而是用于辅助白盒测试发现其他类型的错误。
黑盒测试试图发现以下类型的错误：
1）功能错误或遗漏；
2）界面错误；
3）数据结构或外部数据库访问错误；
4）性能错误；
5）初始化和终止错误。
一、黑盒测试的测试用例设计方法
·等价类划分方法
·边界值分析方法
·错误推测方法
·因果图方法
·判定表驱动分析方法
·正交实验设计方法
·功能图分析方法
等价类划分:
是把所有可能的输入数据, 即程序的输入域划分成若干部分（子集）, 然后从每一个子集中选取少数具有代表性的数据作为测试用例. 该方法是一种重要的, 常用的黑盒测试用例设计方法.
1) 划分等价类: 等价类是指某个输入域的子集合. 在该子集合中, 各个输入数据对于揭露程序中的错误都是等效的. 并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试. 因此, 可以把全部输入数据合理划分为若干等价类, 在每一个等价类中取一个数据作为测试的输入条件, 就可以用少量代表性的测试数据. 取得较好的测试结果. 等价类划分可有两种不同的情况:有效等价类和无效等价类.
有效等价类:是指对于程序的规格说明来说是合理的, 有意义的输入数据构成的集合. 利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能.
无效等价类:与有效等价类的定义恰巧相反.
设计测试用例时, 要同时考虑这两种等价类. 因为, 软件不仅要能接收合理的数据, 也要能经受意外的考验. 这样的测试才能确保软件具有更高的可靠性.
2）划分等价类的方法:下面给出六条确定等价类的原则.
①在输入条件规定了取值范围或值的个数的情况下, 则可以确立一个有效等价类和两个无效等价类.
②在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下, 可确立一个有效等价类和一个无效等价类.
③在输入条件是一个布尔量的情况下, 可确定一个有效等价类和一个无效等价类.
④在规定了输入数据的一组值（假定n 个）, 并且程序要对每一个输入值分别处理的情况下, 可确立n 个有效等价类和一个无效等价类.
⑤在规定了输入数据必须遵守的规则的情况下, 可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）.
⑥在确知已划分的等价类中各元素在程序处理中的方式不同的情况下, 则应再将该等价类进一步的划分为更小的等价类.
3）设计测试用例:在确立了等价类后, 可建立等价类表, 列出所有划分出的等价类:
输入条件 有效等价类 无效等价类
然后从划分出的等价类中按以下三个原则设计测试用例:
①为每一个等价类规定一个唯一的编号.
②设计一个新的测试用例, 使其尽可能多地覆盖尚未被覆盖地有效等价类, 重复这一步. 直到所有的有效等价类都被覆盖为止.
③设计一个新的测试用例, 使其仅覆盖一个尚未被覆盖的无效等价类, 重复这一步. 直到所有的无效等价类都被覆盖为止.
边界值分析法
边界值分析方法是对等价类划分方法的补充.
（1）边界值分析方法的考虑:
长期的测试工作经验告诉我们, 大量的错误是发生在输入或输出范围的边界上, 而不是发生在输入输出范围的内部. 因此针对各种边界情况设计测试用例, 可以查出更多的错误.
使用边界值分析方法设计测试用例, 首先应确定边界情况. 通常输入和输出等价类的边界, 就是应着重测试的边界情况. 应当选取正好等于, 刚刚大于或刚刚小于边界的值作为测试数据, 而不是选取等价类中的典型值或任意值作为测试数据.
（2）基于边界值分析方法选择测试用例的原则:
1）如果输入条件规定了值的范围, 则应取刚达到这个范围的边界的值, 以及刚刚超越这个范围边界的值作为测试输入数据.
2）如果输入条件规定了值的个数, 则用最大个数, 最小个数, 比最小个数少一, 比最大个数多一的数作为测试数据.
3）根据规格说明的每个输出条件, 使用前面的原则1）.
4）根据规格说明的每个输出条件, 应用前面的原则2）.
5）如果程序的规格说明给出的输入域或输出域是有序集合, 则应选取集合的第一个元素和最后一个元素作为测试用例.
6）如果程序中使用了一个内部数据结构, 则应当选择这个内部数据结构的边界上的值作为测试用例.
7）分析规格说明, 找出其它可能的边界条件.
错误推测法
错误推测法: 基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.
错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况, 根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况.
输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.
因果图方法
前面介绍的等价类划分方法和边界值分析方法, 都是着重考虑输入条件, 但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合, 可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类, 他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合, 相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）.
因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况. 利用因果图生成测试用例的基本步骤:
(1) 分析软件规格说明描述中, 那些是原因(即输入条件或输入条件的等价类), 那些是结果(即输出条件), 并给每个原因和结果赋予一个标识符.
(2) 分析软件规格说明描述中的语义. 找出原因与结果之间, 原因与原因之间对应的关系. 根据这些关系, 画出因果图.
(3) 由于语法或环境限制, 有些原因与原因之间, 原因与结果之间的组合情况不不可能出现. 为表明这些特殊情况, 在因果图上用一些记号表明约束或限制条件.
(4) 把因果图转换为判定表.
(5) 把判定表的每一列拿出来作为依据, 设计测试用例.
从因果图生成的测试用例（局部, 组合关系下的）包括了所有输入数据的取TRUE 与取F ALSE 的情况, 构成的测试用例数目达到最少, 且测试用例数目随输入数据数目的增加而线性地增加.
前面因果图方法中已经用到了判定表. 判定表（DECision Table ）是分析和表达多逻辑条件下执行不同操作的情况下的工具. 在程序设计发展的初期, 判定表就已被当作编写程序的辅助工具了. 由于它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确. 判定表通常由四个部分组成.
条件桩（ConDItion STub ）:列出了问题得所有条件. 通常认为列出得条件的次序无关紧要.
动作桩（Action Stub ）:列出了问题规定可能采取的操作. 这些操作的排列顺序没有约束.
条件项（Condition Entry ）:列出针对它左列条件的取值. 在所有可能情况下的真假值. 动作项（Action Entry ）:列出在条件项的各种取值情况下应该采取的动作.
规则:任何一个条件组合的特定取值及其相应要执行的操作. 在判定表中贯穿条件项和动作项的一列就是一条规则. 显然, 判定表中列出多少组条件取值, 也就有多少条规则, 既条件项和动作项有多少列.
判定表的建立步骤:（根据软件规格说明）
①确定规则的个数. 假如有n 个条件. 每个条件有两个取值（0,1）, 故有 种规则. ②列出所有的条件桩和动作桩.
③填入条件项.
④填入动作项. 等到初始判定表.
⑤简化. 合并相似规则（相同动作）.
B. Beizer 指出了适合使用判定表设计测试用例的条件:
①规格说明以判定表形式给出, 或很容易转换成判定表.
②条件的排列顺序不会也不影响执行哪些操作.
③规则的排列顺序不会也不影响执行哪些操作.
④每当某一规则的条件已经满足, 并确定要执行的操作后, 不必检验别的规则.
⑤如果某一规则得到满足要执行多个操作, 这些操作的执行顺序无关紧要.
黑盒测试的优点
1. 基本上不用人管着，如果程序停止运行了一般就是被测试程序CRASh 了
2. 设计完测试例之后，下来的工作就是爽了，当然更苦闷的是确定crash 原因 黑盒测试的缺点
1. 结果取决于测试例的设计，测试例的设计部分来势来源于经验，OUSPG 的东西很值得借鉴
2. 没有状态转换的概念，目前一些成功的例子基本上都是针对PDU 来做的，还做不到针对被测试程序的状态转换来作
3. 就没有状态概念的测试来说，寻找和确定造成程序crash 的测试例是个麻烦事情，必须把周围可能的测试例单独确认一遍。而就有状态的测试来说，就更麻烦了，尤其不是一个单独的tEStcase 造成的问题。这些在堆的问题中表现的更为突出。
黑盒测试（功能测试）工具的选择
那么，如何高效地完成功能测试？选择一款合适的功能测试工具并培训一支高素质的工具使用队伍无疑是至关重要的。尽管现阶段存在少数不采用任何功能测试工具，从事功能测试外包项目的软件服务企业。短期来看，这类企业盈利状况尚可，但长久来看，它们极有可能被自动化程度较高的软件服务企业取代。
目前，用于功能测试的工具软件有很多，针对不同架构软件的工具也不断推陈出新。这里重点介绍的是其中一个较为典型自动化测试工具，即Mercury 公司的WinRunner 。 WinRunner 是一种用于检验应用程序能否如期运行的企业级软件功能测试工具。通过自动捕获、检测和模拟用户交互操作，WinRunner 能识别出绝大多数软件功能缺陷，从而确保那些跨越了多个功能点和数据库的应用程序在发布时尽量不出现功能性故障。
WinRunner 的特点在于: 与传统的手工测试相比，它能快速、批量地完成功能点测试; 能针对相同测试脚本，执行相同的动作，从而消除人工测试所带来的理解上的误差; 此外，它还能重复执行相同动作，测试工作中最枯燥的部分可交由机器完成; 它支持程序风格的测试脚本，一个高素质的测试工程师能借助它完成流程极为复杂的测试，通过使用通配符、宏、条件语句、循环语句等，还能较好地完成测试脚本的重用; 它针对于大多数编程语言和Wi ndows 技术，提供了较好的集成、支持环境，这对基于Windows 平台的应用程序实施功能测试而言带来了极大的便利。
WinRunner 的工作流程大致可以分为以下六个步骤:
1．识别应用程序的GUI
在WinRunner 中，我们可以使用GUI Spy 来识别各种GUI 对象，识别后，WinRunner 会将其存储到GUI Map File 中。它提供两种GUI Map File 模式: Global GUI Map Fil e 和GUI Map File per Test 。其最大区别是后者对每个测试脚本产生一个GUI 文件，它能自动建立、存储、加载，推荐初学者选用这种模式。但是，这种模式不易于描述对象的改变，其效率比较低，因此对于一个有经验的测试人员来说前者不失为一种更好的选择，它只产生一个共享的GUI 文件，这使得测试脚本更容易维护，且效率更高。
2．建立测试脚本
在建立测试脚本时，一般先进行录制，然后在录制形成的脚本中手工加入需要的TSL （与C 语言类似的测试脚本语言）。录制脚本有两种模式: Context Sensitive 和Analog ，选择依据主要在于是否对鼠标轨迹进行模拟，在需要回放时一般选用Analog 。在录制过程中这两种模式可以通过F2键相互切换。
只要看看现代软件的规模和功能点数就可以明白，功能测试早已跨越了单靠手工敲敲键盘、点点鼠标就可以完成的阶段。而性能测试则是控制系统性能的有效手段，在软件的能力验证、能力规划、性能调优、缺陷修复等方面都发挥着重要作用。
3．对测试脚本除错(debug)
在WinRunner 中有专门一个Debug TOOlbar 用于测试脚本除错。可以使用step 、paus e 、breakpoint 等来控制和跟踪测试脚本和查看各种变量值。
4．在新版应用程序执行测试脚本
当应用程序有新版本发布时，我们会对应用程序的各种功能包括新增功能进行测试，这时当然不可能再来重新录制和编写所有的测试脚本。我们可以使用已有的脚本，批量运行这些测试脚本测试旧的功能点是否正常工作。可以使用一个call 命令来加载各测试脚本。还可在c all 命令中加各种TSL 脚本来增加批量能力。
5．分析测试结果
分析测试结果在整个测试过程中最重要，通过分析可以发现应用程序的各种功能性缺陷。当运行完某个测试脚本后，会产生一个测试报告，从这个测试报告中我们能发现应用程序的功能性缺陷，能看到实际结果和期望结果之间的差异，以及在测试过程中产生的各类对话框等。
6．回报缺陷（defect ）
在分析完测试报告后，按照测试流程要回报应用程序的各种缺陷，然后将这些缺陷发给指定人，以便进行修改和维护。
常用的功能测试方法
功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。常用的测试方法如下：
1. 页面链接检查：每一个链接是否都有对应的页面，并且页面之间切换正确。
2. 相关性检查：删除/增加一项会不会对其他项产生影响，如果产生影响，这些影响是否都正确。
3. 检查按钮的功能是否正确：如update, cancel, delete, SAve 等功能是否正确。
4. 字符串长度检查: 输入超出需求所说明的字符串长度的内容, 看系统是否检查字符串长度, 会不会出错.
5. 字符类型检查: 在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型), 看系统是否检查字符类型, 会否报错.
6. 标点符号检查: 输入内容包括各种标点符号, 特别是空格, 各种引号, 回车键. 看系统处理是否正确.
7. 中文字符处理: 在可以输入中文的系统输入中文, 看会否出现乱码或出错.
8. 检查带出信息的完整性: 在查看信息和update 信息时, 查看所填写的信息是不是全部带出., 带出信息和添加的是否一致
9. 信息重复: 在一些需要命名, 且名字应该唯一的信息输入重复的名字或ID, 看系统有没有处理, 会否报错, 重名包括是否区分大小写, 以及在输入内容的前后输入空格, 系统是否作出正确处理.
10. 检查删除功能:在一些可以一次删除多个信息的地方, 不选择任何信息, 按”delete ”, 看系
统如何处理, 会否出错; 然后选择一个和多个信息, 进行删除, 看是否正确处理.
11. 检查添加和修改是否一致: 检查添加和修改信息的要求是否一致, 例如添加要求必填的项, 修改也应该必填; 添加规定为整型的项, 修改也必须为整型.
12. 检查修改重名:修改时把不能重名的项改为已存在的内容, 看会否处理, 报错. 同时, 也要注意, 会不会报和自己重名的错.
13. 重复提交表单：一条已经成功提交的纪录，back 后再提交，看看系统是否做了处理。
14. 检查多次使用back 键的情况: 在有back 的地方,back, 回到原来页面, 再back, 重复多次, 看会否出错.
15. search 检查: 在有search 功能的地方输入系统存在和不存在的内容, 看search 结果是否正确. 如果可以输入多个search 条件, 可以同时添加合理和不合理的条件, 看系统处理是否正确.
16. 输入信息位置: 注意在光标停留的地方输入信息时, 光标和所输入的信息会否跳到别的地方.
17. 上传下载文件检查：上传下载文件的功能是否实现，上传文件是否能打开。对上传文件的格式有何规定，系统是否有解释信息，并检查系统是否能够做到。
18. 必填项检查：应该填写的项没有填写时系统是否都做了处理，对必填项是否有提示信息，如在必填项前加*
19. 快捷键检查：是否支持常用快捷键，如Ctrl+C Ctrl+V Backspace 等，对一些不允许输入信息的字段，如选人，选日期对快捷方式是否也做了限制。
20. 回车键检查: 在输入结束后直接按回车键, 看系统处理如何, 会否报错.
范文四：功能测试的方法
功能测试常用方法
1.页面链接检查：每一个链接是否都有对应的页面，并且页面之间切换正确。可以使用一些工具，如LinkBotPro、File-AIDCS、HTML Link Validater、Xenu等工具。LinkBotPro不支持中文，中文字符显示为乱码；HTML Link Validater只能测试以Html或者htm结尾的网页链接；Xenu无需安装，支持asp、do、jsp等结尾的网页，xenu测试链接包括内部链接和外部链接，在使用的时候应该注意，同时能够生成html
2.相关性检查： ? 功能相关性：删除/增加一项会不会对其他项产生影响，如果产生影响，这些影响是否都
正确，常见的情况是，增加某个数据记录以后，如果该数据记录某个字段内容较长，可
能会在查询的时候让数据列表变形。
? 数据相关性：下来列表默认值检查，下来列表值检查，如果某个列表的数据项依赖于其
他模块中的数据，同样需要检查，比如，某个数据如果被禁用了，可能在引用该数据项
的列表中不可见。 3.检查按钮的功能是否正确：如新建、编辑、删除、关闭、返回、保存、导入，上一页，下一页，页面跳转，重置等功能是否正确。常见的错误会出现在重置按钮上，表现为功能失效。
4.字符串长度检查:输入超出需求所说明的字符串长度的内容,看系统是否检查字符串长度。还要检查需求规定的字符串长度是否是正确的，有时候会出现，需求规定的字符串长度太短而无法输入业务数据。 5.字符类型检查:在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型。
6.标点符号检查:输入内容包括各种标点符号,特别是空格,各种引号,回车键。看系统处理是否正确。常见的错误是系统对空格的处理，可能添加的时候，将空格当作一个字符，而在查询的时候空格被屏蔽，导致无法查询到添加的内容。
7．特殊字符检查：输入特殊符号，如@、#、$、%、!等，看系统处理是否正确。常见的错误是出现在% ‘ \这几个特殊字符
8.中文字符处理:在可以输入中、英文的系统输入中文,看会否出现乱码或出错。
9.检查信息的完整性:在查看信息和更新信息时,查看所填写的信息是不是全部更新,更新信息和添加信息是否一致。要注意检查的时候每个字段都应该检查，有时候，会出现部分字段更新了而个别字段没有更新的情况。
10.信息重复:在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理。
11.检查删除功能:在一些可以一次删除多个信息的地方,不选择任何信息,按“delete”,看系统如何处理,会否出错;然后选择一个和多个信息,进行删除,看是否正确处理。如果有多页，翻页选，看系统是否都正确删除，并且要注意，删除的时候是否有提示，让用户能够更正错误，不误删除。
12.检查添加和修改是否一致:检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填;添加规定为整型的项,修改也必须为整型.
13.检查修改重名:修改时把不能重名的项改为已存在的内容,看会否处理,报错.同时,也要注意,会不会报和自己重名的错. 14.重复提交表单：一条已经成功提交的纪录，返回后再提交，看看系统是否做了处理。对于Web系统来说，可以通过浏览器返回键或者系统提供的返回功能。
15.检查多次使用返回键的情况:在有返回键的地方,返回到原来页面,重复多次，看会否出错。
16.搜索检查:有搜索功能的地方输入系统存在和不存在的内容,看搜索结果是否正确.如果可以输入多个搜索条件,可以同时添加合理和不合理的条件,看系统处理是否正确，搜索的时候同样要注意特殊字符，某些系统会在输入特殊字符的时候，将系统中所有的信息都搜索到。
17.输入信息位置:注意在光标停留的地方输入信息时,光标和所输入的信息会否跳到别的地方。
18.上传下载文件检查：上传下载文件的功能是否实现，上传文件是否能打开。对上传文件的格式有何规定，系统是否有解释信息，并检查系统是否能够做到。下载文件能否打开或者保存，下载的文件是否有格式要求，如需要特殊工具才可以打开等。上传文件测试同时应该测试，如果将不能上传的文件后缀名修改为可以上传文件的后缀名，看是否能够上传成功，并且，上传文件后，重新修改，看上传的文件是否存在。
19.必填项检查：应该填写的项没有填写时系统是否都做了处理，对必填项是否有提示信息，如在必填项前加“*”；对必填项提示返回后，焦点是否会自动定位到必填项。
20.快捷键检查：是否支持常用快捷键，如Ctrl+C、Ctrl+V、Backspace等，对一些不允许输入信息的字段，如选人，选日期对快捷方式是否也做了限制。
21.回车键检查:在输入结束后直接按回车键,看系统处理如何,会否报错。这个地方很有可能会出现错误。
22．刷新键检查：在Web系统中，使用浏览器的刷新键，看系统处理如何，会否报错。
23．回退键检查：在Web系统中，使用浏览器的回退键，看系统处理如何，会否报错。对于需要用户验证的系统，在退出登录后，使用回退键，看系统处理如何；多次使用回退键，多次使用前进键，看系统如何处理。
24．直接URL链接检查：在Web系统中，直接输入各功能页面的URL地址，看系统如何处理，对于需要用户验证的系统更为重要。如果系统安全性设计的不好，直接输入各功能页面的URL地址，很有可能会正常打开页面。
25．空格检查：在输入信息项中，输入一个或连串空格，查看系统如何处理。如对于要求输入整型、符点型变量的项中，输入空格，既不是空值，又不是标准输入。
26．输入法半角全角检查：在输入信息项中，输入半角或全角的信息，查看系统如何处理。如对于要求输入符点型数据的项中，输入全角的小数点（“。”或“．”，如４．５）；输入全角的空格等。
27．密码检查：一些系统的加密方法采用对字符Ascii码移位的方式，处理密码加密相对较为简单，且安全性较高，对于局域网系统来说，此种方式完全可以起到加密的作用，但同时，会造成一些问题，即大于128的Ascii对应的字符在解密时无法解析，尝试使用“uvwxyz”等一些码值较大的字符作为密码，同时，密码尽可能的长，如17位密码等，造成加密后的密码出现无法解析的字符。
28．用户检查：任何一个系统，都有各类不同的用户，同样具有一个或多个管理员用户，检查各个管理员之间是否可以相互管理，编辑、删除管理员用户。同时，对于一般用户，尝试删除，并重建同名的用户，检查该用户其它信息是否重现。同样，提供注销功能的系统，此用户再次注册时，是否作为一个新的用户。而且还要检查该用户的有效日期，过了有效日期的用户是不能登录系统的。容易出现错误的情况是，可能有用户管理权限的非超级管理员，能够修改超级管理员的权限。 29．系统数据检查：这是功能测试最重要的，如果系统数据计算不正确，那么功能测试肯定是通不过的。数据检查根据不同的系统，方法不同。对于业务管理平台，数据随业务过程、状态的变化保持正确，不能因为某个过程出现垃圾数据，也不能因为某个过程而丢失数据。
30．系统可恢复性检查：以各种方式把系统搞瘫，测试系统是否可正常迅速恢复。
31．确认提示检查：系统中的更新、删除操作，是否提示用户确认更新或删除，操作是否可以回退（即是否可以选择取消操作），提示信息是否准确。事前或事后提示，对于Update或Delete操作，要求进行事前提示。 32．数据注入检查：数据注入主要是对数据库的注入，通过输入一些特殊的字符，如“’”，“/”，“-”等或字符组合，完成对SQL语句的破坏，造成系统查询、插入、删除操作的SQL因为这些字符而改变原来的意图。如select * from table where id = ‘ ’ and name = ‘ ’，通过在id输入框中输入“12’-”，会造成查询语句把name条件注释掉，而只查询id=12的记录。同样，对于update和delete
比如用Jmeter，来完成数据注入检查。 33．刷新检查：web系统中的WebForm控件实时刷新功能，在系统应用中有利有弊，给系统的性能带来较大的影响。测试过程中检测刷新功能对系统或应用造成的影响（白屏），检查控件是否回归默认初始值，检查是否对系统的性能产生较大影响（如每次刷新都连接数据库查询等）。
34．事务检查：对于事务性操作，断开网络或关闭程序来中断操作，事务是否回滚。 35．时间日期检查：时间、日期验证是每个系统都必须的，如2006-2-29、2006-6-31等错误日期，同时，对于管理、财务类系统，每年的1月与前一年的12月（同理，每年的第1季度与前一年的第4季度）。另外，对于日期、时间格式的验证，如2006年2月28日、2006-2-28、20060228等。日期检查还要检查日期范围是否符合实际的业务，对于不符合时间业务的日期，系统是否会有提示或者有限制
36．多浏览器验证：越来越多的各类浏览器的出现，用户访问Web程序不再单单依赖于Microsoft Internet Explorer，而是有了更多的选择：Maxthon、Firefox、Tencent Traveler等，考虑使用多种浏览器访问系统，验证效果。
37．安装测试：对于C/S架构的系统，安装程序的测试是一个重要方面，安装程序自动化程度、安装选项和设置（验证各种方案是否都能正常安装）、安装过程中断测试、安装顺序测试（分布式系统）、修复安装及卸载测试。
38．文档测试：主要是对用户使用手册、产品手册进行测试，校验是否描述正确、完整，是否与当前系统版本对照，是否易理解，是否二义性等。
39．测试数据检查：事实告诉我们，测试数据比代码更有可能是错的，因此，当测试结果显示有错误发生的时候，怀疑代码错误前要先对测试数据检查一遍。
40．请让我的机器来运行：在某些项目中，出现一个病态的问题：系统没有问题呀，它在我的机器上是能够通过的。这就说明了其中存在着和环境相关的BUG。“是否所有的一切都受到了版本控制工具的管理？”、“本机的开发环境和服务器的环境是否一样？”、“这里是否存在一个真正的BUG，只不过是在其他的机器里偶然出现？”。所有的测试必须在所有系统要求的机器上运行通过，否则的话，代码就可能存在问题。 41．Ajax技术的应用：Ajax有很多优点，但也有很多缺点，如果利用优点、避免缺点，是我们对新的Web2.0应用的一个挑战。而Ajax的应用最直接的问题就是用户体验，用户体验的效果直接关系到是否使用Ajax技术。“会做，并不意味着应该做、必须做”，这就是对Ajax技术的很重要的注解。
42．Ajax技术的应用：Ajax采用异步调用的机制实现页面的部分刷新功能，异步调用存在异常中断的可能，尝试各种方法异常中断异步的数据调用，查看是否出现问题。在这里遇到的一个问题就是对日期控件的操作，已经如果页面数据较多的时候的刷新。
43．脚本错误：随着Ajax、IFrame等异步调用技术的发展，Javascrīpt技术也越来越受到开发人员的重视，但Javascrīpt存在调试困难、各浏览器存在可能不兼容等问题，因此在Web系统中，可能会出现脚本错误。同时，脚本错误造成的后果可大、可小，不能忽视。
范文五：功能测试的基本方法
功能测试的基本方法
功能测试主要采用黑盒测试方法，结合测试内容对功能进行测试，同时在测试过程中对用户需求、设计文档和使用手册进行检查。测试方法主要根据测试对象的不同灵活进行选择。
功能测试主要分为功能模块测试和业务流程测试，同时在测试过程中对用户需求、设计文档和使用手册进行检查。
功能模块测试主要可采用黑盒测试策略设计测试用例，进行测试。主要功能模块测试的测试用例设计方法包括：
1)等价类划分法：等价类划分法是把所有可能的输入数据，即程序的输入域划分成若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例。
2)边界值分析法：针对功能说明中的输入输出域，进行边界值和极限值的设计和测试。
3)因果图法：以需求设计说明书为依据设计业务测试流程图和测试案例。
4)错误推测法：采用逆向思维方式，结合以往测试经验和直觉设计软件在功能和流程上可能存在的各种错误，进行容错性测试。
业务流程测试主要是在功能点测试的基础上，测试系统完成某项业务的能力。业务流程重点考查系统不同模块、不同子系统之间的功能衔接、数据流向以及完成业务功能的正确性和便利性。按照以下原则进行流程测试：
1)先测功能后测流程：业务流程测试是建立在功能点测试基础上的。首先要保证流程测试涉及到的功能点实现正确，所以，流程测试安排在功能测试的后面进行。
2)先测主流程后测分支流程：主流程就是指按照正常情况实现的业务流程，分支流程指出现特殊情况后的业务流程。
3)先测子系统内的流程，后测子系统间的流程：子系统内的流程测试随子系统的功能测试进行。
