测试执行过程注意事项
搭建测试环境事项 *
注意前提条件和特殊说明
测试用例要全部执行
偶然性问题的处理 *
加强测试过程记录
提交缺陷时与开发的关系处理 *
提交一份优秀的问题报告单
及时更新测试用例
面试题：•问：测试环境怎么搭建的？
•参考答案：搭建环境前，开发都会给到我们一份系统发布手册，我们会根据这个手册来搭建。比如，我这个xx系统，是搭建在Unix系统下的，web服务器用的是Tomcat8，MySQL版本是5.7，程序是JAVA编写的，首先我们向开发拿到编译好的安装包，然后用xshell(或CRT)远程连接上Unix系统，把tomcat服务器停掉，把程序包放到webapps目录下，然后再启动tomcat服务器就可以了。
偶然性问题的处理 *
1、在测试执行过程中，一旦系统出现异常信息，我们第一时间要做的是截图，保存证据；
2、确定是偶然性的bug之后，收集相关的日志，连同截图一起提单给开发定位；
3、如果没有日志记录，缺陷在当前版本无法复现，且缺陷的影响程度比较低，可以提交问题单进行跟踪，跟踪三个版本，如果后三个版本都无法复现，就可以关闭该缺陷；
4、如果这些不可复现的Bug是很严重的Bug，比如导致系统崩溃等，并且，实在没有再次出现，除了要及时反馈给上级之外，最后还要写到测试报告中，说明出现了什么现象，但无法再现！
当我们认为某个地方是bug，但开发认为不是bug，怎么处理？
①先跟开发沟通，确认系统的实际结果是不是和需求有不一致的地方；有些地方可能需求没提及，但是用户体检不好，我们也可以认为是bug。
②如果开发以不影响用户使用为理由，拒绝修改，我们可以和产品经理，测试经理等人员进行讨论，确定是否要修改，如果大家都一致认为不用改，就不改。
缺陷的定义
•软件实现的功能和需求不一致的功能
•软件未实现需求和规格未明确提及但应该实现的内容
•软件难以理解，不易使用，运行缓慢，或者最终用户(估计会)认为不好。
缺陷又名为BUG（臭虫）
产品在上线后用户发现bug，这时测试人员应做哪些工作？
1、测试人员复现问题后，提交问题单进行跟踪；
2、评估该问题的严重程度，以及修复问题时的影响范围，回归测试需要测试哪些功能；
3、问题修复后，先在测试环境上回归，通过后再在生产环境上打补丁，然后再进行回归测试；
4、总结经验，分析问题发生的原因，避免下次出现同样问题。
集结（二八定理）
缺陷往往喜欢扎堆，一个模块已经发现的缺陷比别的模块多，通常不是代表这个模块已经把缺陷暴露完了，而是意味着这个模块还存在有同样多的缺陷尚未被发现。这就是著名的二八定理：80%的缺陷出现在 20%的模块。
如何跟踪缺陷
当发现缺陷后，我们要在禅道上提交问题单给开发，并每隔一段时间(间隔一个小时，或两个小时都可以)去检查缺陷是否被处理，如果没及时处理，就要提示开发，让开发及时修复问题，问题修复后，要及时进行回归测试。
缺陷的状态
提交给开发的缺陷，在不同处理阶段，会有不同的状态，以下以缺陷管理工具“禅道”中缺陷的状态来举例。
缺陷的等级
并非所有的缺陷都需要修复
级别是一般，或轻微的缺陷，没有足够的时间解决
不算真正的软件缺陷(非问题)
修复的风险太大，不值得修复
软件缺陷单的编写
•除了书写良好的重现步骤，缺陷单应该包含这些要素：缺陷标题，严重级别，问题所属模块，复现步骤，预期结果，实际结果，有关的日志和截图。
