详细的描述一个测试活动完整的过程。
答案：（供参考，本答案主要是瀑布模型的做法）
项目经理通过和客户的交流，完成需求文档，由开发人员和测试人员共同完成需求文档的评
审，评审的内容包括：需求描述不清楚的地方和可能有明显冲突或者无法实现的功能的地方。
项目经理通过综合开发人员，测试人员以及客户的意见，完成项目计划。然后 SQA 进入项目，
开始进行统计和跟踪
开发人员根据需求文档完成需求分析文档，测试人员进行评审，评审的主要内容包括是否有
遗漏或者双方理解不同的地方。测试人员完成测试计划文档，测试计划包括的内容上面有描
述。
测试人员根据修改好的需求分析文档开始写测试用例，同时开发人员完成概要设计文档，详
细设计文档。此两份文档成为测试人员撰写测试用例的补充材料。
测试用例完成后，测试和开发需要进行评审。
测试人员搭建环境
开发人员提交第一个版本，可能存在未完成功能，需要说明。测试人员进行测试，发现 BUG
后提交给 BugZilla。
开发提交第二个版本，包括 Bug Fix 以及增加了部分功能，测试人员进行测试。
重复上面的工作，一般是 3-4 个版本后 BUG 数量减少，达到出货的要求。
如果有客户反馈的问题，需要测试人员协助重现并重新测试。
在您以往的工作中，一条软件缺陷（或者叫 Bug ）记录都包含了哪些内容？如何提交高质量的软件缺陷（ Bug ）记录？
在传统的 BugZilla 中，BUG 描述应该包括以下的信息
和 BUG 产生对应的软件版本和模块
开发的接口人员
BUG 的优先级
BUG 的严重程度
BUG 可能属于的模块，如果不能确认，可以用开发人员来判断
BUG 标题，需要清晰的描述现象
BUG 描述，需要尽量给出重新 Bug 的步骤
BUG 附件中能给出相关的日志和截图。
高质量的 BUG 记录就是指很容易理解的 BUG 记录，所以，对于描述的要求高，能提供的信息
多且准确，很好的帮助开发人员定位，因此提交高质量的软件缺陷记录需要注意对 BUG 记录
的描述质量多且准确。
G BUG 管理工具的跟踪过程
用 BugZilla 为例子
测试人员发现了 BUG，提交到 Bugzilla 中，状态为 new，BUG 的接受者为开发接口人员
开发接口将 BUG 分配给相关的模块的开发人员，状态修改为已分配，开发人员和测试确认
BUG，如果是本人的 BUG，则设置为接收；如果是别的开发人员的问题，则转发出去，由下
一个开发人员来进行此行为；如果认为不是问题，则需要大家讨论并确认后，拒绝这个 BUG，
然后测试人员关闭此问题。
如果开发人员接受了 BUG，并修改好以后，将 BUG 状态修改为已修复，并告知测试在哪个版
本中可以测试。
测试人员在新版本中测试，如果发现问题依然存在，则拒绝验证；如果已经修复，则关闭
BUG。
答:1) 测试人员或开发人员发现bug后，判断属于哪个模块的问题，填写bug报告后，系统会自动通过Email通知项目组长或直接通知开发者。
2) 经验证无误后，修改状态为VERIFIED.待整个产品发布后，修改为CLOSED.
3) 还有问题，REOPENED，状态重新变为“New"，并发邮件通知。
4) 项目组长根据具体情况，重新reassigned分配给bug所属的开发者。
5) 若是，进行处理，resolved并给出解决方法。(可创建补丁附件及补充说明)
6) 开发者收到Email信息后，判断是否为自己的修改范围。
7) 若不是，重新reassigned分配给项目组长或应该分配的开发者。
8) 测试人员查询开发者已修改的bug，进行重新测试。
您认为在测试人员同开发人员的沟通过程中，如何提高沟通的效率和改善沟通的效果？
维持测试人员同开发团队中其他成员 良好的人际关系的关键是什么？
尽量面对面的沟通，其次是能直接通过电话沟通，如果只能通过 Email 等非及时沟通工具的
话，强调必须对特性的理解深刻以及能表达清楚。
运用一些测试管理工具如 TestDirector 进行管理也是较有效的方法，同时要注意在
TestDirector 中对 BUG 有准确的描述。
在团队中建立测试人员与开发人员良好沟通中注意以下几点：
一真诚
二是团队精神
三是在专业上有共同语言
四是要对事不对人，工作至上
当然也可以通过直接指出一些小问题，而不是进入 BUG Tracking System 来增加对方的好感。
