开始我的测试项目

日志说明：

    今天开始了EDS系统的测试，这个项目的黑盒测试都都是由自己负责进行的，而且测试主管正在尝试建立完善的测试流程，因为这个是自己第一次独立进行的测试任务，一定要努力的去做好他，每天都写总结，为自己积累测试经验。

开始我的测试项目

    今天的测试，总天来说是比较凌乱的，测试程序是开发人员匆忙中完成的，版本的质量不高，出现了很多本不应该出现的问题，而且，对于需求说明中的一些功能，无论是编写人员还是开发人员，还是我自己都没有详细的去考虑，导致今天在测试的时候发现的问题需要修改需求说明。自己在前段时间所做的需求评审，其实并没有关注具体的细节问题，只是大致的把每个功能模块需要进行测试的内容进行了考虑，其实把时间都用在了测试用例的设计上面去了，而在今天的测试，发现测试用例并没有起到什么作用，测试的时候还是依照需求说明和自己的经验进行的，一个方面是自己设计的测试用例确实存在问题，另一个方面是，根据需求说明，其实在测试的时候就可以设计测试用例，不用参考已经设计好的测试用例了。

    公司的项目都是一个人负责一个项目，其实没有必要把测试用来设计的十分详细和正规，在测试用例中体现出测试项和测试思想就可以了，重点是测试思想的体现，其实测试用例就是你测试思想的体现，只不过详细的测试用例把你测试思想细化了，从输入数据方面进行了细化，因为公司的项目基本上一致的，测试数据的细化并没有太多的复杂性，在以后的测试用例设计中，应该重点体现自己的测试思想，而不是为了完成测试用例那个文档而去做一些本来没有必要却花费时间的事情。

     由于开始的时候没有考虑到会被要求今天就开始在linux下进行测试，自己给自己的测试时间是今天完成windows下的测试，没有想到，测试主管会要求自己在linux下也要进行测试，于是，整个测试都比较马虎，这是不应该出现的，不能为了时间而忽视质量，何况测试主管要求的，不一定非要去完成，就算是完不成，也没有什么关系，但是，如果自己测试的东西在以后正式交付以后出现了问题，那就不是测试主管的问题，而是自己的问题，测试主管不会去管你十分做完了他交代的任务，而是管你做的工作质量如何。

     晚上的时候，也总结了一些今天测试中的问题和想法，顺便写在这里，作为记录。

     1.测试界面友好性问题如果在编码之前就能够确定，那么就不会出现今天提示信息不一致的bug了，因为没有统一的格式，每个开发人员在自己负责开发的模块用自己熟悉的提示信息，这样导致了整个程序的提示信息格式不一致和凌乱，虽然这个问题没有什么大的影响，但是，至少体现了一个开发团队的成熟度。

     2.自己执行测试用例，所以测试用例可以不用详细，但是在测试中需要和其他人员进行交流，需要其他人员的支持，所以测试计划一定要详细，对需要其他人员支持的部分一定要详细描述，同时，在完成测试计划以后，应该把测试计划提交给相关的每个人，如果可能，应该组织评审，由自己说明测试自己对这个项目的测试思想，测试策略，需要哪些资源支持，提早让相关的人员知晓。

     3.需求文档中没有规定的或者开发人员没有实现的程序和需求文档中规定的内容不一致，但是，事实上开发人员是对的，而需求文档是错误的，那么在这种情况下需求肯定要变更，而测试用例和测试都要相应的进行变更，此时就需要变更控制了，还有极端的情况是，需求说明书中的错误比较多，会导致测试错误，此情况应该如何处理呢？