1、数据输入测试：
　　向系统输入数据或输入数据库操作命令时，一般是测试系统对数据库中数据操作的过程。
　　数据类型测试：由于不同的数据库系统对数据类型要求的不同，在定义数据库表时，也规定了数据字段的数据类型。测试步骤和方法：在系统的数据维护功能界面上，录入或修改数据时，特意输入非系统设计的数据类型，检查系统是否可以接受，若不能接受则检查是否满足了系统在这方面的设计要求，如即刻清除非法内容、输入焦点不能到下一输入位置、出现系统自定义的提示信息、不允许出现开发工具的报错信息等。若系统可以接受并保存，则要看数据库表的字段类型设计是否与用户或习惯上不一致，并且要注意其他模块在调取该数据时，是否有特定要求。
　　边界值测试：根据数据取值范围的要求，输入符合取值范围的数据、取值范围的上、下限和超过取值范围的数据。注意，除要测试数据库系统本身数据类型取值范围外，还要根据软件系统设计中的一些特定要求，设计测试用例来测试。
　　数据合法性测试：测试人员除了要测试输入数据是否满足所使用数据库系统本身的数据类型和取值范围的要求外，还应该根据经验和软件系统和需求的特定要求检查输入数据的合法性。比如：日期合法性（出生年月、参保日期、发生时间、根据习惯和业务逻辑顺序对日期合理性的要求等）。工资、比例、率等，都要注意输入的合理、合法性。
　　单引号和双引号：不要忽略输入单引号和双引号可能引起的错误和数据问题。在功能录入界面上，在某字段的输入框输入了包括单引号和双引号的数据，以后在通过Select 语句查询时可能会出问题。特别在基于WEB方式的系统，输入了单引号，在查询数据记录时，肯定会出现页面链接错误（页面无法链接或找不到或链接对象错误）。
　　空值测试：在测试数据录入或修改的功能界面时，若不输入任何东西，系统又没有设计成NOT NULL，则这时，要非常注意其影响。因为数据可以正常保存，但数据表该字段是空值，那么所有与该字段有关的操作，如：查询(AND)、计算（累加、连乘）等，则可能出现数据问题（计算结果为0，无记录返回）。对于测试人员首先要检查系统到底是作为空值，还是作为空串或空字符处理。另外对于允许不输入任何值的字段，在测试过程中，要检查是否在界面显示或打印报表时，这些字段作为了关键要素或标题等情况。
　　空格：在数据维护的功能界面上，输入数据时，要注意是否在输入位置有空格，首先看系统设计时，是怎么考虑的，若系统允许输入空格，则检查条件查询或作为调用参数时的数据返回情况；另外检查程序是否使用了去掉空格的函数。
　　数据校验的不一致：测试时，对于一些编号、编码、代码等主键或作为查询或调用条件的字段，要注意系统对他们的输入合法性检查与查询或调用条件的要求是否是一致的。特别是对于数据结构设计中没有特定约束，而由程序进行校验控制的情况。
　　分析：数据输入测试的主要目的是保证输入到系统中数据的合法、合理性。我觉得，数据输入过程的检查是非常重要的，若在编程过程中，不注重数据的校验功能，虽然看起来加快了开发进度，但给以后会带来一些不可预计的编程或维护工作量。
　　2、目录路径测试：
　　测试系统中规定的路径要求，更改路径，检查系统的是否可以正确运行及系统的排错功能。测试时，根据系统设计说明书（详细设计）或通过对程序源代码的熟悉，找出系统运行过程中指定的路径或在运行过程中，需要使用者选择路径的地方。特意更改路径（选择正确的路径、选择另外的路径、输入不存在的路径）。检查系统是否具有路径上的容错性和灵活性。比如，原则上在程序中，好不要写路径，另外可以提供配置路径的对话框，若输入了非法路径，系统有无提示等。
　　3、 数据操作测试：
　　包括数据操作测试和用户界面操作的测试。
　　修改、新增数据：对于新增和修改数据，要注重以下几个方面的测试。界面上，新增数据成功后，数据列表是否立即刷新，输入有错误时，是否清空错误的数据，输入焦点是否得以控制。在提示信息上，是否有保存成功的提示，输入有错误时，提示的错误信息是否准确，可读。数据方面，要通过SQL检查数据提交是否正确。
　　删除数据：测试删除记录时，系统是否有确认提示，能否批量删除，根据系统详细设计，检查删除主表记录时，在业务上，其他相关表是否相应更改。
　　事物的提交与回滚:熟悉C/S模式开发或数据库应用系统开发的人都知道，数据库事物的概念。对于一个比较复杂的业务逻辑或业务上有数据一致和完整性要求时，尽量使用事物对数据进行提交，这样一旦由于意外原因引起系统或硬件故障时，可以回滚。根据系统的设计要求在测试时，可人为模拟意外故障，来测试系统的数据完整性和容错能力。
　　4、工具条和快捷键测试：
　　在功能界面测试时，对系统菜单中定义的快捷键和菜单工具条中的工具按钮要测试。主要是有效性和一致性测试。有效性：检查是否有效，界面有无反应。一致性：定义或提示的信息是否与实际完成的功能一致。
　　5、 操作顺序测试：
　　按钮顺序测试：在功能界面上，不按照设计上或习惯上的操作顺序点击功能按钮，看系统有什么反应；多次、反复点击某一按钮，看系统有什么反应。主要是测试系统的控制、校验和容错能力；
　　业务逻辑顺序：不按照系统的正常业务逻辑、流程操作，来测试系统是否控制了业务流程的顺序。
　　6、按钮有效性控制测试：
　　主要是测试当不具备条件或无实际意义的情况下，按钮的“Enabled”属性。比如：某一业务未处理，下一环节的功能按钮则应变灰（不可用）。逐条显示数据记录，当游标已经指到了后一条时，“下一条”和“末记录”按钮则应变灰等。
　　7、同时刻操作测试：
　　对于删除、修改、增加数据和一些业务功能，进行多客户端同时刻操作测试，看系统有什么反应。
　　8、附件压力测试：
　　对于有发送、上传、下载、邮件等功能的系统，选取大的文件，进行测试，来检查系统的界面效果和稳定性，看是否会死机或长时间无任何反应等。
　　9、 数据输出测试：
　　数据处理输出测试：主要测试对数据的排序、条件查询是否按照输入的条件或要求输出了正确的数据。
　　打印输出：
　　测试打印功能是否能够正常打印出报表，打印设置后，是否能按照设置的要求打印。
　　10、WEB测试：
　　基于WEB方式的应用，对于一些提交表单的页面，通过多次点击“back”键，来测试系统的处理情况。对于有保存数据功能的页面，多次点击“保存”，来测试系统的处理情况。
　　其他测试注意事项：
　　1. 测试的策略有哪些？
　　答：黑盒/白盒，静态/动态，手工/自动，冒烟测试，回归测试，公测（Beta测试的策略)
　　2. 你认为做好测试用例工作的关键是什么
　　需求和设计文档的理解程度，对系统的熟悉程度
　　3. 你以前工作时的测试流程是什么
　　需求评审（有开发人员，产品经理，测试人员，项目经理）－>
　　需求确定(出一份确定的需求文档)－>
　　开发设计文档（开发人员在开始写代码前能输 出设计文档）－>
　　想好测试策略，写出测试用例－>
　　发给开发人员和测试经理看看（非正式的评审用例）－>
　　接到测试版本－>执行测试 用例（中间可能会补充用例）－>
　　提交bug（有些bug需要开发人员的确定（严重级别的，或突然发现的在测试用例范围之外的，难以重现的），有些可 以直接录制进TD）－>
　　开发人员修改（可以在测试过程中快速的修改）－>
　　回归测试（可能又会发现新问题，再按流程开始跑）