注意对一些元数据增删改后的测试，尤其注意如有其他地方引用了这些属性，则禁止相关操作，这是系统的关联性注意与数据库的关联查询在测试初期，要分清主次，轻重缓急，先对主流功能进行测试。

　　不要在已经验证为错误的功能上延伸测试，错误的错误还是错误注意界面中一些默认值的设置，增添系统的人性化设计如果需要进行下一个版本的测试，需要群发邮件。

　　测试执行分以下几个阶段：冒烟测试、功能测试、容错性测试、性能测试、UI测试。冒烟测试是主要功能测试，是线的测试。功能测试是细分的功能点的测试，是点的测试。容错性测试、性能测试的测试点不一样，要看不同的项目涉及的业务，以用户的关注点来定。

　　UI测试主要针对三点：正确、规范、美观协调。

　　经验：程序中所有可能有的错误和容易发生错误的特殊情况。

　　测试人员最好能在开发开始之前，总结出一个列表，列表中列出需要开发人员统一处理的一些细节，比如表单中表头和表内容用什么字体字号；是左对齐还是居中；翻页控件是放在表单左下角还是右下角还是居中；标点符号是用中文半角还是全角；选择框和下拉菜单中的内容按什么排序；搜索结果是否需要排序；错误提示是弹出窗口还是显示在原界面；错误提示语也应尽量统一风格；查询后是否要保存查询条件；浏览器的前进后退是否需要限制等等。项目经理最好统一给开发人员讲一下这些规矩，这样会在测试时省很多事。

　　尽可能考虑到测试过程中的风险，比如测试环境的问题、部署失败的问题、开发延期的问题、人员变动的问题等。

　　1、测试用例要因人而异，如果自己已经很熟练了，测试用例可以只是简单的提示，不需写出详细的执行步骤和测试数据，以免因为无谓的文档浪费太多时间。如果很可能别人还要复用你的测试用例而且有充足的时间，这时就可以把测试用例写详细点。

　　1）如果时间允许，测试一个页面时，要把这个页面的所有功能点的正常异常情况都测完之后再去测下一个页面，这样不容易遗漏。大多时候时间都不很充足，这时要先测主要流程和主要的功能点，这些完成之后再去测细节和异常情况，因为并不是有bug就不能上线的。

　　2）至于测试数据需不需要在设计测试用例时就写出需要根据实际项目情况来定，我一般认为最好把测试用例都写完之后，再准备测试数据，一条数据可以覆盖多个测试用例，这样很可能四五条数据就可以覆盖十几个测试用例，这样可以提高效率。教科书通常认为一条测试数据最好对应一个测试用例，这样测试执行失败时就容易定位问题出在哪里。但实际情况是只有极少数的测试会执行失败并因此发现bug，但如果因为这极少数的失败的情况来降低整个测试执行的效率就显得缺乏实践性了，况且并不是说一条测试数据覆盖了多个用例时就不容易定位错误的根源。所以测试要根据实际情况灵活进行。

　　3）如果要写详细的测试用例，就一定要写的非常的清楚明了，最好让一个不懂项目情况的人也能根据用例执行测试。而且测试用例和测试数据中的关键值一定要用颜色标出。最好还能写出每条用例的测试目的，这样方便日后别人补充你的测试用例。

　　2、如果发现了很多界面性的小问题，不要连续提出，最好先提一两个功能性的问题，再提一两个界面性的问题，这样间隔着提bug有利于开发人员接收，免得他把你提的连续的四五个界面性的bug都拒绝了。另外，一个bug 里最好不要既包括功能性问题又包括界面性问题，这样有可能开发人员只解决了功能性问题就把bug 关了。