黑盒测试注重于测试软件的功能性需求，也即黑盒测试使软件工程师派生出执行程序所有功能需求的输入条件。黑盒测试并不是白盒测试的替代品，而是用于辅助白盒测试发现其他类型的错误。

黑盒测试试图发现以下类型的错误：

1）功能错误或遗漏；

2）界面错误；

3）数据结构或外部数据库访问错误；

4）性能错误；

5）初始化和终止错误。

采用黑盒技术设计测试用例的方法有：等价类划分、边界值分析、错误推测、因果图和综合策略。

黑盒测试的测试用例设计方法

·等价类划分方法

·边界值分析方法

·错误推测方法

·因果图方法

·判定表驱动分析方法

·正交实验设计方法

·功能图分析方法

等价类划分

是把所有可能的输入数据,即程序的输入域划分成若干部分（子集）,然后从每一个子集中选取少数具有代表性的数据作为测试用例.该方法是一种重要的,常用的黑盒测试用例设计方法.

1) 划分等价类:

等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.

有效等价类:是指对于程序的规格说明来说是合理的,有意义的输入数据构成的集合.利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能.

无效等价类:与有效等价类的定义恰巧相反.

设计测试用例时,要同时考虑这两种等价类.因为,软件不仅要能接收合理的数据,也要能经受意外的考验.这样的测试才能确保软件具有更高的可靠性.

2）划分等价类的方法:下面给出六条确定等价类的原则.

①在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类.

②在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下,可确立一个有效等价类和一个无效等价类.

③在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类.

④在规定了输入数据的一组值（假定n个）,并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类.

⑤在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）.

⑥在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类.

3）设计测试用例:在确立了等价类后,可建立等价类表,列出所有划分出的等价类:

输入条件 有效等价类 无效等价类

... ... ...

... ... ...

然后从划分出的等价类中按以下三个原则设计测试用例:

①为每一个等价类规定一个唯一的编号.

②设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步.直到所有的有效等价类都被覆盖为止.

③设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步.直到所有的无效等价类都被覆盖为止.

边界值分析法

边界值分析方法是对等价类划分方法的补充.

1）边界值分析方法的考虑:

长期的测试工作经验告诉我们,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.

使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.

2）基于边界值分析方法选择测试用例的原则:

① 如果输入条件规定了值的范围,则应取刚达到这个范围的边界的值,以及刚刚超越这个范围边界的值作为测试输入数据.

② 如果输入条件规定了值的个数,则用最大个数,最小个数,比最小个数少一,比最大个数多一的数作为测试数据.

③ 根据规格说明的每个输出条件,使用前面的原则1）.

④ 根据规格说明的每个输出条件,应用前面的原则2）.

⑤ 如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个元素作为测试用例.

⑥ 如果程序中使用了一个内部数据结构,则应当选择这个内部数据结构的边界上的值作为测试用例.

7）分析规格说明,找出其它可能的边界条件.

错误推测法

错误推测法: 基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.

错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.

因果图方法

前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入

条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）.

因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.

利用因果图生成测试用例的基本步骤:

① 分析软件规格说明描述中, 那些是原因(即输入条件或输入条件的等价类),那些是结果(即输出条件), 并给每个原因和结果赋予一个标识符.

② 分析软件规格说明描述中的语义.找出原因与结果之间, 原因与原因之间对应的关系. 根据这些关系,画出因果图.

③ 由于语法或环境限制, 有些原因与原因之间,原因与结果之间的组合情况不不可能出现. 为表明这些特殊情况, 在因果图上用一些记号表明约束或限制条件.

④ 把因果图转换为判定表.

⑤ 把判定表的每一列拿出来作为依据,设计测试用例.

从因果图生成的测试用例（局部,组合关系下的）包括了所有输入数据的取TRUE与取FALSE的情况,构成的测试用例数目达到最少,且测试用例数目随输入数据数目的增加而线性地增加.

前面因果图方法中已经用到了判定表.判定表（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造成的问题。这些在堆的问题中表现的更为突出。

常用的功能测试方法

功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。常用的测试方法如下：

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. 页面链接检查：每一个链接是否都有对应的页面，并且页面之间切换是否正确。可以使用QTP的页面检查点检查链接。

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.确认提示检查：系统中的更新、删除操作，是否提示用户确认更新或删除，操作是否可以回退（即是否可以选择取消操作），提示信息是否准确。提示顺序是否正确，事前事后提示。

32.事务检查：对于事务性操作，断开网络或关闭程序来中断操作，事务是否回滚。

33.时间日期检查：时间、日期验证是每个系统都必须的，如20xx-2-29、20xx-6-31等错误日期，同时，对于管理、财务类系统，每年的1月与前一年的12月（同理，每年的第1季度与前一年的第4季度）。另外，对于日期、时间格式的验证，如20xx年x月x日、20xx-2-28、20xx0228等。日期检查还要检查日期范围是否符合实际的业务，对于不符合时间业务的日期，系统是否会有提示或者有限制

34.多浏览器验证：越来越多的各类浏览器的出现，用户访问Web程序不再单单依赖于Microsoft Internet Explorer，而是有了更多的选择：Maxthon、Firefox、Tencent Traveler等，考虑使用多种浏览器访问系统，验证效果。

35.安装测试：对于C/S架构的系统，安装程序的测试是一个重要方面，安装程序自动化程度、安装选项和设置（验证各种方案是否都能正常安装）、安装过程中断测试、安装顺序测试（分布式系统）、修复安装及卸载测试。

36.文档测试：主要是对用户使用手册、产品手册进行测试，校验是否描述正确、完整，是否与当前系统版本对照，是否易理解，是否二义性等。

37.测试数据检查：事实告诉我们，测试数据比代码更有可能是错的，因此，当测试结果显示有错误发生的时候，怀疑代码错误前要先对测试数据检查一遍。

38.请让我的机器来运行：在某些项目中，出现一个病态的问题：系统没有问题呀，它在我的机器上是能够通过的。这就说明了其中存在着和环境相关的BUG.“是否所有的一切都受到了版本控制工具的管理 ”、“本机的开发环境和服务器的环境是否一样 ”、“这里是否存在一个真正的BUG，只不过是在其他的机器里偶然出现 ”。所有的测试必须在所有系统要求的机器上运行通过，否则的话，代码就可能存在问题。

39.脚本错误：随着Ajax、IFrame等异步调用技术的发展，Javascrīpt技术也越来越受到开发人员的重视，但Javascrīpt存在调试困难、各浏览器存在可能不兼容等问题，因此在Web系统中，可能会出现脚本错误。同时，脚本错误造成的后果可大、可小，不能忽视

 

第三篇：体质健康测试总结

体质健康测试工作总结

我校为了认真贯彻落实关于实施《国家学生体质健康标准》有关事项的通知，认真做好了《国家学生体质健康标准》项目测试及测试数据的上报、管理工作，做好了我校全体学生体质健康测试工作，我校实施了《国家学生体质健康标准》工作领导小组并制订了测试工作具体方案，体育组、教导处通力协作，测试工作已圆满完成，下面就我校进行体质健康测试工作做一个简略的小结。

一、组织培训教师，取得家长配合

面对高要求的测试工作，学校认真落实上级有关文件及指示，召开了全体教师裁判员培训，强调了具体项目地点及人员安排。各班主任还与家长积极配合，要求家长在家做好孩子体质健康的锻炼工作，每天晚上孩子在家的跳绳、仰卧起坐、立定跳远由家长进行监督，正是由于全体人员的通力合作，才能使测试工作顺利完成。

二、达标测试、建立建康档案

经过两天时间的努力，我校完成了全体学生达标测试，圆满完成各项达标测试。我校严格按照《国家体育锻炼标准》规定，取消了单项得分的限制，以测试项目得分之和为评定等级的依据。60－75为及格，76－85为良，86分上为优。新标准取消单项得分限制，充分允许学生存在差异，这客观地尊重学生的体质差异，也尊重学生的个性差异，充分体现了新标准的人本观。

三、认真做好总结工作

面对现在学生普遍体质下降的情况，我们将认真对待，把学生的身心健康放在工作的重要地位，为培养全面发展的人才而努力，切实抓好我校体育工作，认真贯彻教育部《关于落实保证中小学生每天体育活动时间的意见》和《新课程标准》的要求，开齐开足了《体育与健康》课时，加大对学校体育教学工作的关注和管理力度，确保学生每天1小时的体育活动。为了进一步弘扬体育锻炼的精神，强健体魄，增强学生身体健康，展示我校学生的风采， 我校坚持了每年开一次运动会和进行跳绳、拔河、打兵乓球、投篮等各类有趣的体育竞赛，这与学校对学生体质健康的重视是分不开的。

为了确保体育活动的正常开展，学校也购置了必要的体育器材，通过近一个月的努力工作，体育组完成了全校学生的体质健康测试工作。并由信息老师进行了数据的采集和整理工作。并按时准确地向区教育局发送数据，完成了数据上报工作。

这次体质健康测试，从分布任务到测试完成，时间紧，任务重。我们觉得没有全体的力量是不可能在短期内对如此多的同学进行测试的。同时积极发动，精心组织，合理安排，是做好这项重要工作的保证。只要各方面积极努力我们学校完全能够做好体质测试工作，对学生的健康负责，为培养全面发展的学生做出贡献。

目前体育组在校领导的安排下，已经在制订新的方案，力争把学生体质健康测试工作规范化，制度化，将体质健康测试工作做得更好