1、过滤问题,出错信息(编辑信息),

2、页面的出错信息是否与当前的页面或界面相适应,出现的提示信息是否明白,

3、权限问题(不该有的信息是否能显示出来,要显示出来的东西是否显示正确;),

4、数据不存在问题(可输入字段的前半部分在编辑界面上,特殊符号的输入%,空格键,令过滤信息检测不正确;)

5参考:只有树;既有树,又有列表;参考界面,

6基础信息是否共用，还是私用；

7单据编号是否唯一，且连号；

8两个用户或者三个用户同时操作同一单据，同一列表，同一单据明细，同一编辑界面，同一按钮，同时保存，同时改单，同时修改，同时删除，

9多页面操作的复杂性，暂不考虑；（数据是否同步）

10仓库库存量是否及时，准确反映出数据；

11原则上不允许报表出现负的数量和金额，并且在月结转或年结转时，数据的处理方式的合理性；

12系统流程设计的合理性，程序员设计系统时应该引导用户进行正确的操作，并且设计的流程是通用，简单，可操作性的；

13客户需求只不过客户想达到怎样的结果，至于表达形式，程序员应该是对系统比较熟悉的，用最简单的方法满足客户需求，

14考虑设计的合理性问题，不能说只能按这样操作，按这样的操作会出错，系统给出的东西，按正确操作，出错的机率比较少，多数出错都是由于用户不按常规操作造成的；

如果设置了受限站点,在IE上又不能删除该站点,只能在注册表找到相关信息删除,

具体设置如下: 在注册表中找到

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet

Settings\ZoneMap\Domains键值删除对应的键就可以了!

  之前用CHM做的测试记录,可能节点太多,数据全部都没有保存得到,使自己几天来做的整理全部都没有了,
心情一下子落下来了,不过工作还要工作,唯有下次做时,小心点..
不过我都编译看过是保存的,但第二天还是不见了数据,
看来数据丢失是毁灭性的...
下次有机会再整理下自己的文档,
不然自己做了这么长时间,
有些东西要记起的,
反而没有记住,
做好自己的工作,就是最有效的提高自己的能力...
   不过还好,有些记录而上传到网站上!

   1仓库人员：最关心库存的准确性，财务人员：报表能否直观反映报表的正确性；

   2结存数,盘点,数据继承接转;盈亏分析,数据的完整性:

   3员工应该区分所属的部门(货管,财务,销售),在选择员工可实现过滤不相关的数据;

   4客户要修改时,单据编号和之前的编码有区别的;(比如以前编码为PC,后来变为PK)

   5用户能跟踪得到单据和报表的关联性;

   6生产单号或者单据是否完成或结束,所带的参考应该是客户所需的正确数据;

   7新做系统时,如果和之前系统的表结构有很大出入,怎样把之前的旧数据继承过来;

   8单据被引用后,是否有作废,删单功能,要保证参考结存数年的正确性;

   9产品有KG数和PCS数,或者两个数量的其一的应对方式;


   10操作速度的慢与快,直接影响用户对系统的依赖性,和可持续性;

   11盘点出来要输入实盘数时动用的人力和物力；

   12系统能引导用户操作;(导航测试,系统误操作,不常规操作,系统是否都能有异常的处理;)

   13设计就要首先要为用户先想到，把自己的想法讲比管理层，让他们觉得ERP系统可以省他们一些烦心事，并数据的稳定性和录单时有些规范；

1、数据过滤，  
2、日期逻辑问题； 
3、产品进出逻辑关系；
4查询和动态查询的合理性;
(是否可查询该字段,查询的条件是否自动清除)  
4过滤不该有的功能(检查工具栏,右键)
5客户操作异常,给出的提示信息,用户是否接受  
6用户点击记录是否为当前记录(审核,选择)
7用户是否跳过系统定出的规则;   
8用户保存的数据是否一致;(没有多余的数据或缺少数据;)
9单据新增,保存,刷新(单据编号都应该是唯一的;) 
10产生对账单,盘点单时,应该要秀出来(系统自动启动到单据明细中) 
11单据明细,序号的连续性和唯一性; 
12哪些数据信息是用户必填和可选择的;  
13用户的破坏性操作  
14升级版本问题
(是在系统开发库原有基础上升级,还是在用户使用环境中增加新增的功能;)  
15界面显示的信息是否通用,用户是否一看就明白;
16系统默认值的测试;(用户看不到的数据系统就不能有该数据)  
16-1 给出的提示重复:新增时提示一次,保存时提示一次,审核时提示一次,新增同一条记录又提示一次;
 
17系统规则为了保存数据正确,在不同的点上多做几个检测,会使用户眼花缭乱,并对速度有所影响;

  纯属个人测试所用，如引用，请根据自己情况而定！写得很乱，只不过为自己资料而留低，没有进行好的编辑！

1、过滤问题,

2、数据不存在问题,

3、加载的信息不正确,

4、出错返回的页面不对,

5、权限问题,

5-1、不按常规操作产生的问题,

6、系统出现错误后,而又找不到重现的有效方法，跟踪产生问题的原因，
最常用的方法：只能继续操作容易出现问题的地主，想办法令问题得以重现；

7、逻辑日期：比如仓库入库是24号，而仓库出库日期应该大于25号；

8、通用的业务流程：如果不同公司的业务流程不一样，再作改动，
花费的人力和物力资源不可估量的，所以好的设计，
就能让软件面对同一行业的客户时都能应付自如；

9、单据编号的唯一性，主要考虑，单据号是否保存到数据表中去，
再新增时是否自动加一，同时考虑，两个用户或多个用户同时操作时的情况；

10、数据的过滤是否合理性和参考的数据不冗余；

11、单据审核后，且该单据被其他单据所引用时，如果再对该单据进行反审核（改单，进行修改数据时），系统对数据正确性和可更改性的把握要有明确的规则；

12、考虑客户最关心的数据：仓库最重要的可以有是仓库的库存量，而财务关心的报表应该是可读性，并一目了然，金额是否正确，数据是否正确，能提高用户的工作效率；

13、搭建用户的使用环境，测试才有利；
（遇到用户的特殊环境：多个用户同时远程连接服务器进行BS系统的操作；）
（不同用户操作同一单据，同一按钮等等）
（在局域网测试没有问题，但连接在外网时，出现乱码的情况，字符不识别;)
 (用户速度慢也会抱怨，有可能机器配置不高，或者系统对优化方面做得不全面；）

14系统升级过程中，应该有固定的时间，并给出提示让用户知道情况，但升级不能太频繁，影响用户操作就会不好，（我们系统是用tomcat,有时出现错误了，查不到原因，迫不得意有时都会重启tomcat,才能进行系统的操作，有时都几无奈的....

15最后，一定学一些业务方面的知识！

GUI 测试 :
   图形用户界面（ GUI ）对软件测试提出了有趣的挑战，因为 GUI 开发环境有可复用的构件，开发用户界面更加省时而且更加精确。同时， GUI 的复杂性也增加了，从而加大了设计和执行测试用例的难度。因为现在 GUI 设计和实现有了越来越多的类似，所以也就产生了一系列的测试标准。下列问题可以作为常见 GUI 测试的指南：

窗口：
· 窗口是否基于相关的输入和菜单命令适当地打开？
· 窗口能否改变大小、移动和滚动？
· 窗口中的数据内容能否用鼠标、功能键、方向键和键盘访问？
· 当被覆盖并重新调用后，窗口能否正确地再生？
· 需要时能否使用所有窗口相关的功能？
· 所有窗口相关的功能是可操作的吗？
· 是否有相关的下拉式菜单、工具条、滚动条、对话框、按钮、图标和其他控制可为窗口使用，并适当地显示？
· 显示多个窗口时，窗口的名称是否被适当地表示？
· 活动窗口是否被适当地加亮？
· 如果使用多任务，是否所有的窗口被实时更新？
· 多次或不正确按鼠标是否会导致无法预料的副作用？
· 窗口的声音和颜色提示和窗口的操作顺序是否符合需求？
· 窗口是否正确地被关闭？

下拉式菜单和鼠标操作：
· 菜单条是否显示在合适的语境中？
· 应用程序的菜单条是否显示系统相关的特性（如时钟显示）？
· 下拉式操作能正确工作吗？
· 菜单、调色板和工具条是否工作正确？
· 是否适当地列出了所有的菜单功能和下拉式子功能？
· 是否可以通过鼠标访问所有的菜单功能？
· 文本字体、大小和格式是否正确？
· 是否能够用其他的文本命令激活每个菜单功能？
· 菜单功能是否随当前的窗口操作加亮或变灰？
· 菜单功能是否正确执行？
· 菜单功能的名字是否具有自解释性？
· 菜单项是否有帮助，是否语境相关？
· 在整个交互式语境中，是否可以识别鼠标操作？
· 如果要求多次点击鼠标，是否能够在语境中正确识别？
· 光标、处理指示器和识别指针是否随操作恰当地改变？

数据项：
· 字母数字数据项是否能够正确回显，并输入到系统中？
· 图形模式的数据项（如滚动条）是否正常工作？
· 是否能够识别非法数据？
· 数据输入消息是否可理解？

边界条件是指软件计划的操作界限所在的边缘条件.
 如果软件测试问题包含确定的边界,那么数据类型可能是:
       数值速度字符地址位置尺寸数量
    同时,考虑这些类型的下述特征:
       第一个/最后一个最小值/最大值
       开始/完成超过/在内
       空/满最短/最长
       最慢/最快最早/最迟
       最大/最小最高/最低
       相邻/最远
越界测试:
  通常是简单加 1 或者很小的数(对于最大值)和减少 1 或者很小的
  数(对于最小值),例如:
      第一个减 1/最后一个加 1
      开始减 1/完成加 1
      空了再减/满了再加
      慢上加慢/快上加快
      最大数加 1/最小数减 1
      最小值减 1/最大值加 1
      刚好超过/刚好在内
      短了再短/长了再长
      早了更早/晚了更晚
      最高加 1/最低减 1

另一些该注意的输入:默认,空白,空值,零值和无;非法,错误,不正
确和垃圾数据.

      1.应用程序速度慢(加载数据太多;网络速度;系统异常,没有返回出错之前的界面;
        用户操作频繁,不断点击节点;)
      2.系统不稳定(测试的时候,没有找到系统出现问题的点,导致没有修改完全!)
      3.数据不正确(用户保存的数据没有保存得到,报表反映的信息不对:)
      4.功能不满足!(系统需求时,没有真正理解用户所需!)

      用户登录网页界面的测试要点:
         1.不能同时在页面上登录两个用户;
         2.两个用户权限不同时,看到的信息应该属于该用户权限的信息;
         3.错误的用户或密码登录时,返回的页面是返回到登录界面的;

     好的测试人员不一定要很强的编程能力,但懂得一些技能知识对测试是有帮助的!
测试只能尽量满足客户需求,涉及原则性的问题(比如会造成系统不稳定,系统不可操作时),
一定懂得和客户SAID:NO!
    并要向客户给出合理解释,有一定的耐性!
因为客户多数情况下是不懂得系统架构的,能满足客户的基本需求,
有时功能上的东西,只不过表达形式不同而已..

      尽量避免重复测试,每次发布新版本,给的时间是有限的,
        要把以前测试到的问题重新按步骤运行一遍,
      但有时解决一个问题,引起另外的一个问题是不可避免的,
        只能尽量找到问题的关键点,
      自己要分析系统,设计一些好的用例,比盲目测试好得多!

   对应用系统的架构要有一定的认识!
公司是怎样开发的?用到什么编程语言?什么数据库等等...
对公司各个环节都有所了解之后,把测试到问题进行合理分析,
问题要描述清楚,并要有重现错误的发生,
开发人员才会找到关键点,才会把问题解决彻底的!

  从事测试工作接近两年了,感触的东西很多,
从开始的C/S架构到现在的B/S架构,发觉一切都原来在积累紧...
  测试一定要有测试用例,没有好的用例,
测试就好随意和随机性,
  测试用例,就是自己有自己的操作步骤,要有一定的预期结果!

   始终自己都有写不完的结束,只有等待那一天的出现,
     但生活由不得你去等待...
   不去做,不去尝试,怎样知道自己想要怎样的生活呢?
     而在生活中,如果自己不喜欢的东西就不去做,这属于生活的一部分?