测试基础知识及面试参考文档.doc

1 自我介绍 个人总结：自我介绍不要太短，也不能太长，两分钟为宜，IT行业的面试一般开头，面试官都会说让你自我介绍下 的，不规定时间的，个人的基本信息一概而过，太多了对你的面试也不会有什么好处，重点放在做过的项目，及学 到的东西和经验总结之类的，个人性格中的优点，缺点（与工作无关的，不影响工作的缺点）大概说下，这样一个从 内到外很清晰的你就展现在面试官面前了。 2 Bug管理 2.1 一个bug包括哪些属性？ 答：以QC为例： 摘要，状态，关闭日期，检测者，检测于版本，计划关闭版本，项目，分配给，主题，实际修复时间，关闭于版本， 检测日期，估计修复实际，优先级，可重新，严重程度，Bug的描述及相关的图片。 ****** 红色为必填字段，经常在项目中使用的属性有，摘要，状态，关闭日期，检测者，检测于版本，项目，分配给，主题， 检测日期，优先级，可重现，严重程度，Bug的描述及相关的图片等属性，其它属性几乎不用。 2.2 bug级别划分？ 答：以QC为例： 紧急，非常高，高，中，低。 紧急严重花屏，内存泄露，用户数据丢失或破坏，系统崩溃/死机/冻结，模块无法启动或异常退出， 非常高严重的数值计算错误，功能设计与需求严重不符，导致其他功能无法测试的错误 高主要功能存在缺陷，但不会影响到系统稳定性。 功能未实现，功能错误，系统刷新错误，语言或数据通讯错误，轻微的数值计算错误， 系统所提供的功能或服务受到明显的影响 中操作界面错误，边界条件显示错误，提示信息错误，长时间操作无进度提示，系统未优化， 光标跳转设置不会，光标定位错误 低界面格式等不规范，辅助说明描述不清楚，操作时未给用户提示，可输入区和只读区没有明显的区分标志， 个别不影响产品理解的错别字，文字排列不整齐等一些小问题，建议 2.3 Bug有哪些状态及Bug生命周期？ 答：以QC为例： Bug的状态有：新建（New），打开（Open），固定（Fixed），重新打开（Reopen），已否决（Rejected），已关闭（Closed）。 下面就对这几种状态进行以下解释： New：（新的） 当某个“bug”被发现的时候（第一次），测试人员记录下此Bug，此时Bug的状态为新建（New）。 Open：（打开的） 一旦开发人员开始处理bug的时候，他（她）就将这个bug的状态设置为“Open”，这表示开发人员正在处理这个“bug” Fixed（已修复的） 当开发人员进行处理（并认为已经解决）之后，他（她）就可以将这个bug的状态设置为“Fixed” Closed（已关闭的） 测试人员重新测试状态为Fixed（已修复）的Bug，经过再次测试之后确认bug已经被解决之后，就将bug的状态设置为“Closed” Reopen（再次打开的） 如果经过再次测试发现bug（指bug本身而不是包括因修复而引发的新bug）仍然存在的话，测试人员将bug再次传递给开发组， 并将bug的状态设置为“Reopen” Reject（拒绝的） 如果测试人员传递到开发组的bug被开发人员认为是正常行为而不是bug时，这种情况下开发人员可以拒绝，并将bug的状态 设置为“Reject”。 ******以上内容为本人在工作中实际应用，不同的管理工具，Bug的状态可能有很多种，但工作中实际中用到的就这么多。 2.4如何提交高质量的bug记录？ 答： 我们一班用缺陷管理工具QC或JIRA提交。 2.5 在测试时，开发人员会说：“我们不需要懂那么多，我们不需要了解那么细，只需要从用户角度来测量就可以了” 如何面对这种情况？ 答:从目前情况来看，开发普遍存在着对测试的误解，误认为测试是对项目工时 的一个附加，做测试不仅仅要测试自己看到的，也要测试自己看不到的冰山之下， 比如判断是否有内存泄露，是否有死锁，是否有不良SQl，是否满足性能需求，是否满足安全 需求等，这些纯用户角度无法度量。 2.6 bug有哪些类型？ 类型 描述 功能类 1，功能未实现 2，功能错误 3 功能设计与需求规格说明书不一致， 4 出现多余功能 5 正常操作，但存储内容不正确 6 功能未完全但不影响系统正常运行 数据类 1，数据丢失 2 数据来源不符合要求但操作成功 3 边界值超出正常范围导致出现1级bug现象 4 数据处理结果不正确 性能类 1 软件运行过程中死机 2 内存泄露 3 系统崩溃，导致系统变慢 4 长时间事务处理，无提示 界面类 1 UI与原型不一致 2 文字，颜色，图片错误等 3 界面设计不规范，没有考虑易用性问题 信息类 1 系统报非友好错误信息 2 必填项无提示 3 提示信息问题 安全类 1 安全性漏洞 2 系统漏洞 建议类 偶然类 3. 测试计划 3.1测试计划工作的