常用功能的测试检查表.docx

1、开发人员的意识不足，开发流程不规范，可能是以前做项目一直都是拿到市场可行性分析，然后项目管理人员进行简单模块划分，任务就分配下去了，更不就不写需求文档，或者只是简单书写大体功能点。2

1、开发人员的意识不足，开发流程不规范，可能是以前做项目一直都是拿到市场可行性分析，然后项目管理人员进行简单模块划分，任务就分配下去了，更不就不写需求文档，或者只是简单书写大体功能点。

2、项目进度紧张，后期需求变动可能比较大，来不及书写详细的需求文档

3

3、项目是从原有项目上进行迭代开发，开发人员认为不要再进行需求文档编写。针对上述2点提出个人意见：

对于第一种情况：

1、测试负责人应该坚持开发没出需求文档，就不进行测试，要坚持让开发输出项目需

求文档，哪怕是写的不够详细也好，最少都要输出一份简单的功能列表；

求文档，哪怕是写的不够详细也好，最少都要输出一份简单的功能列表；

2、需求文档要进行评审，评审做会议记录，并有专门人员对需求文档进行修改；

3、最后就是测试人员进行测试需求分析，再根据测试需求点进行测试用例编写了。对于第二种和第三种情况：

1

1、测试人员尽量找到已存在的资料，比如市场调研书，可行性分析报告，收集一切对项目有用的文档。并提出其中的功能点需求；

2、如果是迭代项目开发，则找到前期项目的一些需求文档，概要设计，详细设计，测

试需求，用例等。提起里面的功能点；

3

3、咨询相关人员，获取项目一些大体功能，最好能知道大体项目的框架，然后记录咨询到的功能点；

4、了解项目大体框架后，可以在网上寻找同类产品，把里面的一些亮点功能点进行提

起；

5

5、整合上面的几点，测试人员应该书写一份你认为的测试需求点，然后分发给每个和项目有关人员，如测试人员，开发人员，市场人员。组织进行一个会议评审，在评审中详细记录修改的地方；

6、最后整理出一份评审过的测试需求点，进行设计测试用例。

没有需求文档对于编写测试用例来说，确实很困难，做为测试人员，在没有测试需求文档情况下，我们不能等着开发人员输出，应该主动点，尽可能去多了解项目的一些情况，多知道一点，对测试用例就能多写点。

没有需求文档对于编写测试用例来说，确实很困难，做为测试人员，在没有测试需求文档情况下，我们不能等着开发人员输出，应该主动点，尽可能去多了解项目的一些情况，多知道一点，对测试用例就能多写点。

1.查询输入Form是否正常工作，不输入数据是否查询到全部记录；

当查询的数据非常多的时候，性能有无问题；

当查询的数据非常多的时候，性能有无问题；

查询的下拉菜单列出的数据是否正确；

查询结果是否正确；对于复杂的查询要通过SQL来检查结果；

如输入%*？等通配符是否会导致查询错误；

查询结果列表分页是否正确，在点击下一页上一页时，查询条件是否能带过去，不能点击翻页时又重新查询；

查询结果列表分页是否正确，在点击下一页上一页时，查询条件是否能带过去，不能点击翻页时又重新查询；

对于数据量比较大的表查询时，不容许无条件查询，避免性能问题的出现；

对于查询输入项的值是固定的要用下拉菜单，比如状态、类型等；

分页的统计数字是否正确，共

分页的统计数字是否正确，共X页，第N页，共X条记录等；

对于查询有统计的栏目，比如：总计、合计等要计算数据是否正确；

查询结果有超链接的情况要检查超链接是否正确；

查询权限的检查，比如：user1不能查询到user2的数据等；