目前我的工作所包含的应该是以下测试：UI界面测试、功能测试、性能测试、功能测试报告输出
一：UI界面测试
1、打开一个页面，首先感觉到的应该是这个页面的打开速度，这属于性能方面的表现
若打开速度缓慢，需要等待不正常的时间，那么就要分析原因了。此时提交BUG
2、界面的设计：色彩和布局
3、界面是否有脚本错误
在IE高级设置中，勾选“显示每个脚本错误的通知”，同时取消“显示友好http错误信息”。这样在打开有脚本错误的页面时，IE会自动弹出错误提示框。如果有脚本错误，则可提交相应的BUG
注：脚本错误可能不会影响我们正常的业务操作，但可能导致我们无法完成正常的业务流程。所以，测试过程中，这个是检查的关键点
4、检查被测页面的文字信息：页面标题、正文文字、图片文字、按钮文字
5、不同分辨率的显示效果
如果被测系统没有做出明确的系统分辨率说明，就需要在不同分辨率下查看被测系统的页面表现。如果显示错误的话，就要提交界面UI设计方面的BUG
6、窗口最大化、最小化、关闭功能是否正常
二、功能测试。又称“数据驱动测试”，从“容错处理、数据转换、业务处理”这三方面找BUG
1、容错处理：在用户犯错的时候，给出适当的信息提示，这就是容错
2、数据转换：再复杂的软件也可以拆分成“增、删、改、查”这四部分
3、业务处理：从业务流程角度出发。在测试过程中一定要跟踪一条完整的数据流程。
三、性能测试
有些问题在做黑盒测试的时候，稍微注意就能发现。
比如：1、明明2s就能打开的页面，却需要花10s
2、一打开系统，机器的CPU就超过75%
四、功能测试报告输出
测试工作完成后，就要对当前测试工作做一个总结，对项目的BUG进行分析，给出合理的分析报告，反应被测软件的质量，以便项目组织决定项目是否上线或发布。
比如：从最终的测试数据看，本版本测试是不通过的，未能达到《……项目系统测试计划》中定义的停测标准，不建议上线，从遗留的BUG来看，仍需要一个版本进行测试，以期测试完全，并且BUG的处理周期应该缩短。
注释：
从软件测试的角度来讲，用户行为是最难模拟的，就像极限，我们只能无限趋向于那个点。只要认为可能给系统带来严重后果的，问题都应该被揭露。
提交BUG时，要注意描述的专业性、准确性、简洁性。BUG描述主要包含：测试数据、测试步骤、 测试结果
