在进行一个业务测试的时候，碰到一种情况，在小数据量下测试一个模块功能的时候，完成了测试，提交了版本；
   最后在客户实际使用，当数据量很大的情况下面，结果出现了那个模块页面打不开的情况，实在郁闷；
   所以在对于一个模块里面是调用另外的表的数据来进行操作的时候，完成了功能测试，一定要进行下大数据量的测试，才能保证系统运行良好；

   不知道平常大家是怎么测试报表的，最近在一个项目的测试过程之中，涉及到了很多报表的测试，当然设计数据肯定是需要的，在检查数据准确性的过程中,就采用了自己编写sql来查询数据的准确性，不看开发人员的存储过程，来和程序里面的报表进行数据校对，为什么这么做呢，因为我感觉到测试人员测试报表，首先对报表的数据来源，即业务单据，比较熟悉，了解数据库里面的字段取值以及特殊标志字段的意思，那么在测试报表的时候，就可以写出最实际符合业务的sql语句，从而就可以与程序里面的数据进行比对；

   在往常的测试过程中，要求进行测试用例的编写，用例评审，用例维护，用例执行；那么是不是所有模块都需要进行这些工作呢，比如一个参考系的维护，仅仅新增，修改，查询简单功能，在我看来，这样下来，工作量既大，又无用，而且死板，丧失了软件测试的艺术性.
   于是我就对于这样些的问题，我就自己进行了下思考，我把下面的用例叫做测试要点，不妨大家可以一起来讨论下，比如，对于一个参考系的测试要点设计：
========================
--------
数据库为：该页面所涉及到的表名，因为测试的时候，我们是经常需要查看数据库的；
--------
逻辑业务：
列表出该页面所需要处理的逻辑业务；比如这个表对别的表的影响，特殊的业务要求等等，根据实际情况来进行增加；
--------
数据业务：列表出数据操作组合，和用例设计很象，但是是抽象类型的，在测试的同时可以给予很大发挥空间，仅仅列出一些常用的，可以根据实际需要进行增加；
1.新增正常流程
2.必填字段判断
3.关键字重复判断
4.对于选择框的选择用例：下拉框，弹出窗口，时间选择
5.特殊值的判断，日期，数字，长度;而且日期判断里面要进行前后时间比较下；左右空格的处理！～
6.返回到主页面的数据显示情况；
7.正常修改
8.必填,关键字重复修改的判断
9.正常删除，包括对主表和子表的删除操作；
10.删除的判断：已审核的不能删除判断
11.查询，左右加空格查询的效果！
12.详细查看功能
========================
    这样，对于一些根本就不需要花费大量时间在上面进行测试的模块给予了解放，往往对于那些参考系，单据就可以这样处理，参考系就偏重于数据业务方面，单据就偏重于逻辑业务方面；
    而对于需要重点测试的模块，涉及到复杂数据流的时候，我们就可以进行重点测试了；