6、如果版本未更新，
1）建议着重进行业务逻辑方面测试，在电脑上以文档形式画出简单的业务逻辑图片，重点说明：一定 要尽量考虑所有的情 况，因为这样的BUG要么就没有，一旦有就是HIGH
2）建议进行环境测试（当然要根据需求测试相应的环境）
3）严格核对需求文档，防止需求遗漏
7、严格按照缺陷提交说明提交BUG，因为这有可能涉及BUG的统计问题，（一般公司的缺陷描述：系统名称_功能模块，缺陷描述，要具体问题具体对待）
优先级和严重程度不要夸大也不要降低，实事求是，因为这与开发和测试的绩效考评有挂钩，要是夸大缺陷，会影响开发的绩效考评，降低会影响自己的绩效考评，建议：系统级（影响流程）和跳黄页（报服务器错误的，这类缺陷有的是服务器配置错误导致）建议为高，功能实现建议为中，界面易用，或者不影响系统使用的其他问题建议为低，具体级别公司会有规定，如果没有规定，可以参考一下我的建议
8、测试没有空闲。项目在不同阶段，会有些时间很‘空闲’。建议：
1）把测试管理工具中的缺陷全部分类导出，总结一下哪些模块容易产生哪些缺陷，重点看一下自己没发现或没有考虑到的缺陷，有多余时间可以看一下 CLOSED_NBUG的缺陷，这类BUG一般都是需求不明确，需求变更而产生的，看一下这类缺陷，可以总结一下哪些需求容易产生误解，和出现了哪些新需求。
2）把测试管理工具中的用例细细看几遍，学习别人的用例编写方法和思想，空闲时间可以自己试着编写，看自己编写的与别人编写的用例差距在哪，从而不断完善。
3）进入一些测试论坛，比如51testing，把自己的困惑和经验和大家一起分享，共同学习，共同进步！
好了，今天先写这些了，都是自己的一些体会，要是有什么不对的地方，希望大家多多指正，谢谢！主要针对新人写的，大虾看了别见笑，测试经验中有的不适合大虾。
文章来源于领测软件测试网 https://www.ltesting.net/
