即时通讯客户端版是OA附带的企业内部聊天工具，有点类似于QQ，简称IM。它的好友就是OA系统所有账号。此工具功能比较简单，基本就是发信息，发文件。但是我忽略了重要的一点，那就是客户端在登录时会加载好友列表，而当oa系统的账号比较多时，就导致了客户端加载不过来好友而登录不了的情况。

   一开始是测试即时通讯网页版的性能，环境部署在虚拟机上，cpu的性能不太好，导致测试结果中cpu占用率基本都在95%以上，后来换了一台服务器，是物理机。同样的场景，性能方面提升了很多。首先是cpu占用率明显下降,基本都在40%-55%;其实是响应时间，曲线图波动比较平缓了，不像之前的在用户数逐渐达到最高时，响应时间几乎直线上升。目前我只能从这两个方面分析出程序没有问题，能支持虚拟用户1000，同时运行数最高达120，并发数最高达80的场景运行13~14分钟。

待续。。。。。

         关于新增功能的测试点，主要是考虑是否可增加一个已存在的名称，按照我之前的理解，其测试用例无非就是输入一个已存在的字段名称，看程序是否给出提示。但是我确忽略了一个重要的问题，那就是如果在已存在的字段名称之前或之后加空格的话，程序是否会在对空格作出处理之后，仍给出提示信息。

         针对每一个测试点，不仅要纵向的（发散性思维）考虑，还要横向的考虑。

        2009年的7月即将过完了，而我在新公司也呆了4个月了。在这四个月里我学到了什么呢？

       1， 业务：

        对于公司业务的了解似乎也只达到50%

       原因：

       这四个月中后两个月，我之前熟悉的大部分需求都改变了。开发商讨修改需求，然后简单的写完需求分析文档，制定好开发计划，而我只是被告知什么时候可以开始进行测试了，在开发期间我也因为别的项目比较紧急，而没时间去了解需求，而向开发了解时，却发现他们也不是很清楚。不知道他们在这种状况下能开发出怎样的系统。而我又怎样去测试呢？

       2，测试能力：

       待续。。。。

        不要去抱怨外界环境阻碍了自己的成长进步，殊不知在外界环境的阻碍下自己可能成长的更快。

       最近公司在验收一个外包软件，测试工作由我担任，在验收标准中有个需求是这样的：下载的视频，图片必须缓存到手机本地。针对这一需求点，验收标准中没有提到可能带来的问题，而我在测试过程中也没有想过这一功能点会引发什么问题。就在验收前的会议上，在说到这个需求点时，技术总监随口就说了一个很明显的问题：随着用户对软件的使用，手机里的视频图片会越来越多，到时候就占满了手机内存，影响用户对其他功能的使用，所以软件应该增加自动清除缓存的机制。

       真是惭愧，我一个专业的测试人员既然没有意识到这么明显的问题，看来很是欠缺发散性思维啊。。。。

 需求不足或很少时的测试    

项目没有明确定义的（或任何）需求规格说明书就开始实施，这很常见，特别是在小公司里面。即使是在大型企业，在他们认为不需要规范领域，也可能存在项目缺少需求规格说明书的情况。在这种情况下如何进行测试是一个常见的问题。
在项目缺少需求规格说明书的情况，并不存在一个做好测试简单快捷的方法，因为需求规格说明书对功能性测试的效力有很大的推动作用。其中关键的一点是要注意保持对需求来源进行追踪，和从这些需求源头上可衍生出哪些需求。这将大大简化对需求合法性的验证。以下是在以往测试成功过的几种策略：
把用户手册当作需求规格说明书使用，这种方法是有效的和符合要求的。如果用户手册提供了足够的细节信息并且被信息组织编排得很有条理，使用它和使用需求规格说明书的效果几乎是一样的。关键是学会在用户手册上系统化地查找需求，确认和追踪这些需求。另外，经常需要从其它的来源获取需求信息来对用户手册进行补充，因为用户手册很少会包含压力和响应时间方面等精确数目信息。
    把设计文档当作需求规格说明书使用，大部分的开发人员至少会在某处的文件上记录或保存系统的一些相关信息。查找出这些设计文档后，它可作为需求的一个源头，特别是对于那些在用户手册上无法找到的硬性指标需求。关键是要小心选择可用作需求的信息，要注意避免把设计信息当作需求。销售文档同样也可以这样用。
    与人交谈。小项目的一个常见问题是“两只腿的需求”，这是指长驻客户公司的应用软件技术支持人员，他们围绕描述软件的用途与客户反复沟通。通常这些技术支持人员都会写下一些信息，这些信息可用作需求，但多半时候这些信息用处不大，这需要和他们坐下来谈论一下这个系统要实现哪些功能。另外，走出去和开发人员，系统的实际用户，甚至购买产品的客户等交谈。在每次会谈中，及时作笔记，然后把这些笔记作为进行测试的基础资料。使用常识。使用常识这个方法应该是所有其它方法都失败后的最后选择。虽然使用常识可能会发现问题，但使用这种方法会引发所发现故障的重要性和关联性的争论，甚至这个缺陷实际上是不是缺陷也可能需要论证。

测试准备不足情况下的测试

一个关键的考虑因素可能是根本上这个软件是否可测，如果没有
足够的时间去为一个全新的产品作测试做准备，唯一可行的办法是向项目管理人
员报告这个软件达不到测试的条件，让其决定如何处理这个问题。如何项目管理
人员做出的决定是宣布这个产品达不到测试的条件，测试人员需提供详细的信息
以解释为什么这个软件达不到测试的条件和需要作哪些改进使它达到测试的条
件。

时间不足的测试

     进行故障分析的第一步相对比较简单，只是简单地往BUG 追踪过程添加一些信息，以允许分析问题的根源。这些信息应包括那部分代码出现了失效和这些代码存在什么问题等信息。还需包括出错代码的编写者名字，和其它一些关于故障如何发生和为何发生的信息。当经过几个软件版本的数据积累后，搜索其中有着共同主题或故障发生原因的数据。通常，软件的那些经过多次修改的代码会被检索出来，重新设计这些代码可以显著提升软件的质量，同时可加快项目开发进度。可能有些界面接口缺少相关的说明文档，或是难以理解的，从而引发不少问题，这时需要重写这些接口，使它们得以简化以利于将来的使用。错误的出现也可能和代码没有直接的关系，例如，可能因为软件运行环境存在过多的干扰，或对于特殊代码，开发人员缺乏相关的培训。当这些错误被逐渐消除后，继续收集数据和评估这些错误移除后产生的作用，以及确认更多错误的来源。这种处理软件故障和故障的源头错误的方法被称为故障避免。这种方法的基本原理是，在故障首次出现之前消除它比等它成为麻烦后再发现和修改它所花费的成本会少很多。随着越来越多的错误被确认和阻止出现，更多的错误将会出现，并且可得到修正。这种方法的净作用是将会极大地节省项目时间和成本。

         在完成公司计划安排的工作的同时，完成以下任务

         一，提升设计测试用例的技术

         1,了解测试系统基本的测试点【web系统测试方法】

         2，结合公司具体的业务情况

         3，根据自己的经验结合其他方面的知识  

         4，每想到新的测试点，或是学到新的设计用例的方法 都做总结  

        二，为找工作做准备

        1，完善简历【加入进两月对功能测试、性能测试的理解】 

        2，发简历

        3，熟悉软件测试面试题目

     注：在目前的公司只能在测试技能方面有提升，软件生命周期的深入理解，与其他部门的沟通协调能力等都得不到锻炼  

        今天是执行Web后台管理系统的第一轮测试的第一天，基本功能的测试都没问题，但是在删除多条数据时，竟然出现了进度条，过了近一分钟，操作仍未结束，程序估计出问题了，赶紧取消了操作。

        一开始我以为是因为删除的数据中有主外键关系，导致动作执行缓慢，我取消了操作，数据中的相关操作也就回滚了。事情没这么简单，接下来的测试中，我只要执行跟数据库有关的操作，都迟迟不见结果。

       赶紧跟开发反映，经过他的查证，数据库出现死锁了。。

       具体原因我不清楚，不过确实是因为我删除的多条数据跟其他模块的数据有主外键关系，。。。。。。最终导致了数据库死锁。。