需求分析阶段：
1,增加的新功能,以及需求变动, 要考虑到测试范围的变化,务必确保没有因为变动引起测试遗漏.2,拿到需求以后,及时跟开发沟通各个功能点什么时候能够开发完成;尤其在第一个初步的版本出来以后,要跟他们确认下缺失的功能点.因为有个时候开发会遗漏功能点, 尽量想办法把问题提前发现.测试阶段：
采取冒烟测试－〉回归测试－〉系统测试，这样的测试流程。
3, 冒烟测试的时候,所有的模块都要冒烟,即便有些模块最近都没有改动过。因为模块集成后，可能因为某些模块的变动引起其他模块的功能失效
Bug相关：
４, 不同浏览器的问题, 要在标题里加注
非IE浏览器的问题,发现以后在IE里验证.
５, UI的问题，一定要截图，除了方便开发定位，另外还起到纪录的作用。
6, Bug标题: 要描述清楚是什么错误.看一眼标题就可以知道标题描述的是期待结果还是实际结果。
7, Bug描述: 某某功能错误,或记录错误的, 一定要在描述里写明复现步骤，是什么错误,怎么错了.
8, 激活Bug：Re-active Bug的时候,要写明是什么地方测试未通过,存在什么问题.
9, 一个Bug只记录跟踪一个问题：验证Bug的时候，如果发现该Bug引发了新问题，不要再激活原Bug, 应新建一个Bug,但要在原Bug上链接到新Bug.确保一个Bug只记录跟踪一个问题。
10, 出现的Bug都有记录：Bug与开发直接沟通的,确认是一个Bug的,一定要在TFS里提交Bug，确保每个出现的Bug都有记录,方便以后跟踪.
11, 每次给客户部署的版本,要记录下此版本上存在的Bug.
测试阶段：
1、遇到时间紧，人手不够不能充分进行测试时，着重对新模块和修改过的模块进行测试，其他模块进行简单冒烟
2、必要的随机测试很重要，往往能发现一些按照用例跑所发现不了的bug，最好是让测试人员随机跑其他人员的模块（简单的交叉测试）
用例设计阶段：
正常流程的用例要有，最关键的是对于异常情况考虑要全面，用例覆盖面很重要，必要的时候要多次评审测试用例
需求分析阶段
尽量听取第一手需求，尽量避免从开发人员那里获得需求然后按照他们的思路来测试，这样测试人员的思路会被开发人员带着走，不便于发现隐藏问题（吃过亏的都知道
解Bug：
1、如果部署了正式环境上发现有页面问题，联系开发人员尽快解决，通过替换文件的方式而不用重新发版本，因此这种bug越早发现越好
2、项目时间紧张时候，如果遇到非常严重的bug，除了在工具里提交bug之外还要马上联系开发人员告知bug，因为有时候开发人员没时间及时的去查看bug列表
3、每个人对自己分配的测试模块要去盯开发人员，不能拖着，不然开发人员很容易遗忘）
