测试汇总

 

名言：

1.错误潜伏在角落里，聚集在边界上。

2.The best tester is not the one who finds the most bugs or who embarrasses the most developers. The best tester is the one who gets the most bugs fixed

测试：

1. 单元测试：单元测试是对软件中的基本组成单位进行的测试，如一个模块、一个过程等等。

          它是软件动态测试的最基本的部分，也是最重要的部分之一，其目的是检验软件

          基本组成单位的正确性。一个软件单元的正确性是相对于该单元的规约而言的。

          因此，单元测试以被测试单位的规约为基准。 单元测试的主要方法有控制流测试、

          数据流测试、排错测试、分域测试等等。

2. 集成测试：集成测试是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确。它根据集成测试计划，一边将模块或其他软件单位组合成越来越大的系统，一边运行该系统，以分析所组成的系统是否正确，各组成部分是否合拍。 集成测试的策略主要有自顶向下和自底向上两种。

3. 系统测试：系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确并非一项简单的任务，它被称为测试的 “ 先知者问题 ” 。因此，系统测试应该按照测试计划进行，其输入、输出和其他动态运行行为应该与软件规约进行对比。软件系统测试方法很多， 主要有功能测试、性能测试、随机测试等等。

4. 验收测试：验收测试旨在向软件的购买者展示该软件系统满足其用户的需求。它的测试数据通常是系统测试的测试数据的子集。所不同的是，验收测试常常有软件系统的购买者代表在现场，甚至是在软件安装使用的现场。这是软件在投入使用之前的最后测试。

5. 回归测试：回归测试是在软件维护阶段，对软件进行修改之后进行的测试。其目的是检验对软件进行的修改是否正确。这里，修改的正确性有两重含义：一是所作的修改达到了预定目的，如错误得到改正，能够适应新的运行环境等等；二是不影响软件的其他功能的正确性。

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

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

1 ）功能错误或遗漏；

2 ）界面错误；

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

4 ）性能错误；

5 ）初始化和终止错误。

白盒测试在测试的早期采用，而黑盒测试主要用于测试的后期。黑盒测试故意不考虑控制结构，而是注意信息域。

7. 白盒测试 ： 白盒测试，也称为结构化测试、基于代码的测试，是一种测试用例设计方法，它从程序的控制结构导出测试用例。用白盒测试产生的测试用例能够：

1 ）保证一个模块中的所有独立路径至少被使用一次；

2 ）对所有逻辑值均需测试 true 和 false ；

3 ）在上下边界及可操作范围内运行所有循环；

4 ）检查内部数据结构以确保其有效性。

8. 灰盒测试：灰盒测试是基于白盒测试和黑盒测试之间的测试。

9.α 测试（ Alpha ）：α 测试是由一个用户在开发环境下进行的测试，也可以是开发机构枘部的用户在模拟实际操作环境下进行的测试。软件在一个自然设置状态下使用。开发者坐在用户旁边，随时记下错误情况和使用中的问题。这是在受控制的环境下进行的测试， α 测试的目的是评价软件产品的 FLURPS( 即功能、局域化、可使用性、可靠性、性能和支持 ) 。尤其注重产品的界面和特色。 α 测试人员是除开产品开发人员之外首先见到产品的人，他们提出的功能和修改意见是特别有价值的。 α 测试可以从软件产品编码结束之时开始，或在模块（子系统）测试完成之后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程序之后再开始。有关的手册（草稿）等应事先准备好。

10. β 测试（ beta ）：β 测试是由软件的多个用户在一个或多个用户的实际使用环境下进行的测试。这些用户是与公司签定了支持产品预发行合同的外部客户，他们要求使用该产品，并愿意返回有关错位错误信息给开发者。与 α 测试不同的是，开发者通常不在测试现场。因而， β 测试是在开发者无法控制的环境下进行的软件现场应用。在 β 测试中，由用户记下遇到的所有问题，包括真实的以及主观认定的，定期向开发者报告，开发者在综合用户的报告之后，做出修改，最将软件产品交付给全体用户使用。 β 测试主要衡量产品的 FLURPS 。着重于产品的支持性，包括文档、客户培训和支持产品生产能力。只有当 α 测试达到一定的可靠程度时，才能开始 β 测试。由于它处在整个测试的最后阶段，不能指望这时发现主要问题。同时，产品的所有手册文本也应该在此阶段完全定稿。由于 β 测试的主要目标是测试可支持性，所以 β 测试应尽可能由主持产品发行的人员来管理。

注：软件验收测试包括：正式验收测试，alpha测试，beta测试

 

测试对象		测试项目
登录框		用户名、密码都为空，一项为空
		用户名、密码正确，一项正确
		任意一项、两项输入时清空、都为空时清空
		输入正确的用户名和正确的密码，但未区分大小写
		一些特殊字符的测试（根据实际情况测试）
界面		界面标题的问题： 界面中英文混合的问题、无错字，颜色、字体、位置、长度、大小等一致
		页面标题与页面对应；列显示顺序（具体参照查询统计的测试）、宽度、位置合适；数据网格的显示，是否完整，是否有异常换行；界面整体风格需一致
		能否记忆用户的设置或操作习惯，避免用户每次进入都需要重新操作一次初始环境 。（参照综合信息平台）
		注意有些选项、菜单项在该灰时是否还不灰，并且还能状态显示
提示信息		（ 1 ）是否需要提示信息
		（ 2 ）提示信息种类（错误、警告、信息等）合适
		（ 3 ）提示信息是否合理、可理解、无错字、标点符号正确
录入		Tab 顺序
		要求必须输入不输入时，系统是否有相应的判断提示
		空格
		如果文本输入域允许输入 1 － 255 个字符： 合法区间：输入 1 个字符和 255 个字符，也可以加入 254 个字符作为合法测试。 非法区间：输入 0 个字符和 256 个字符作为。
		特殊字符的测试，如：查询时如果开发人员是用脚本语言写的话，测试时要考虑英文状态下的单引号、双引号等特殊的字符
整数		必须输入，不输入，清空字段
		有效值
		非数字、 + 、 -
		上下限值（± 1 ），远高 / 低于上下限值
		上下限位数的数字（± 1 ）
		负数，小数， 输入指定类型的内容的地方输入其他类型的内容（错误的数据类型）
		在数据前加 0 、 + ，数据前后中加空格
小数		必须输入，不输入，清空字段
		有效值
		非数字、 + 、 -
		上下限值（± 1 ），远高 / 低于上下限值
		上下限位数的数字（± 1 ）
		负数，错误的数据类型
		在数据前加 0 、 + ，数据前后中加空格
		小数位数（± 1 ）
		只录入“。”和小数 / 整数
日期		必须输入的不输入
		有效日期（注意下每年的 2 月 29 号）
		输入的各种日期格式（ 2008-01-01 、 2008/1/1 、 2008.1.1 、 2008 1 1 等）
		无效日期（ 2008-3-29 2008-2-30 ）
按钮功能的检查		各种按钮对应的功能是否正确（如：添加、删除、编辑、取消、保存）
页面 链接		每一个链接是否都有对应的页面，并且页面之间切换正确
相关性检查		删除 / 增加一项会不会对其他项产生影响，如果产生影响，这些影响是否都正确
删除的检查		在一些可以一次删除多个信息的地方，不选择任何信息，按 ”delete” ，看系统如何处理，会否出错；然后选择一个和多个信息，进行删除，看是否正确处理
		删除记录后，单击“后退”按钮，再单击这条记录，看程序是否作出合理的判断
信息重复	命名重复	在一些需要命名，且名字应该唯一的信息输入重复的名字或 ID ，看系统有没有处理，会否报错，重名包括是否区分大小写，以及在输入内容的前后输入空格，系统是否作出正确处理
	修改时重名（ * ）	修改时把不能重名的项改为已存在的内容，看会否处理并报错。同时，也要注意，会不会报和自己重名的错。
		选择分类，为分类添加记录，假如分类下不允许添加记录名称重复的记录，在分类 a 下添加一条记录，在另一分类 b 下添加与这一分类有相同名称的记录，编辑时，再将该记录的分类改成分类 a ，看系统能否作出判断。
检查添加和编辑要求是否一致		检查添加和编辑信息的要求是否一致，例如添加要求必填的项，修改也应该必填 ; 添加规定为整型的项，修改也必须为整型。
表单测试		重复提交表单：一条已经成功提交的纪录，按 back 后再提交，看看系统是否做了处理
		当用户给 Web 应用系统管理员提交信息时，就需要使用表单操作，例如用户注册、登陆、信息提交等。在这种情况下，我们必须测试提交操作的完整性，以校验提交给 服务器 的信息的正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。如果使用了默认值，还要检验默认值的正确性。如果表单只能接受指定的某些值，则也要进行测试。例如：只能接受某些字符，测试时可以跳过这些字符，看系统是否会报错。
检查多次使用 back 键的情况		在有 back 的地方， back 回到原来页面，再 back ，重复多次，看会否出错
上传下载文件检查		上传下载文件的功能是否实现；
		上传文件的大小、对上传文件的格式有何规定，系统是否有合理的提示信息；
		上传文件是否能保存、打开。
分页		如果记录出现分页，看分页功能是否正确实现，分页显示的记录数是否正确；全部显示记录时，网格是否显示正常，分类统计是否正确。 （有这样一种情况：如只需选择分类，就自动查询出该分类下的记录，假如某一分类下的记录有 2 页，而其他分类下的记录有 1 页，要注意在这个分类的第二页，再选择其他分类时，看是否报错） ；
对话框嵌套层次		应该不要嵌套太多
查询功能的检查		查询内容不录入，单击查询按钮
		录入过长的查询内容，看系统的反应
		在有 search 功能的地方输入系统存在和不存在的内容，看 search 结果是否正确。如果可以输入多个 search 条件，可以同时添加合理和不合理的条件，看系统处理是否正确。
快捷键检查		是否支持常用快捷键，如 Ctrl+C Ctrl+V Backspace 等，对一些不允许输入信息的字段，如选人，选日期对快捷方式是否也做了限制。
回车键检查		在输入结束后直接按回车键，看系统处理如何，会否报错
逻辑测试		选择了一个选择项，与之相关的其他项的变化
超时测试
查询统计的测试		在业务数据的查询和统计结果显示中，通常列表是按照一个规则显示数据的。 如按照单据的录入时间倒序显示数据， 按照营业机构的顺序进行显示， 按照某项业务指标的高低顺序等等。
		分页显示的记录数是否正确
		全部显示记录时，网格是否显示正常，分类统计正确
工作流的测试		当一个功能模块完成一项业务操作后，在制定的管理功能模块是否正确的显示和提示
数据存储的测试		数据进行操作后，是否在指定的数据库表中，记录了数据

 

 

 

测试分三次

 第一次测试，软件某个功能模块开发完成，测试错误，提交修改

 

第二次测试，软件的错误修正完成后，进行再次测试，直到错误改正

 

第三次测试，软件整体开发完成后，将全部功能串接，进行联合测试

 

测试需要三份文档

 

测试手册

 

测试错误报告 

 测试错误统计