软件测试面试题_每天一道软件测试面试题系列 (六)_如何提交高质量的软件缺陷（Bug）记录，Web项目中的安全测试怎么测？

一：在您以往的工作中，一条软件缺陷（或者叫Bug）记录都包含了哪些容？如何提交高质量的软件缺陷（Bug）记录？

一条Bug记录最基本应包含：

（1）bug编号	
（2）bug严重级别，优先级
（3）bug产生的模块
（4）首先要有bug摘要，阐述bug大体的内容
（5 bug对应的版本
（6）bug详细现象描述，包括一些截图、像....等等
（7）bug出现时的测试环境，产生的条件即对应操作步骤；

高质量的Bug记录：

1. 通用UI要统一、准确缺陷报告的UI要与测试的软件UI保持一致，便于查找定位。
2. 尽量使用业界惯用的表达术语和表达方法使用业界惯用的表达术语和表达方法，保证表达准确，体现专业化。
3. 每条缺陷报告只包括一个缺陷每条缺陷报告只包括一个缺陷，可以使缺陷修正者迅速定位一个缺陷，集中精力每次只修正一个缺陷。校验者每次只校验一个缺陷是否已经正确修正。
4. 不可重现的缺陷也要报告首先缺陷报告必须展示重现缺陷的能力。不可重现的缺陷要尽力重现，若尽力之后仍不能重现，仍然要报告此缺陷，但在报告中要注明无法再现，缺陷出现的频率。
5. 明确指明缺陷类型根据缺陷的现象，总结判断缺陷的类型。例如，即功能缺陷、界面缺陷、数据缺陷，合理化建议这是最常见的缺陷或缺陷类型，其他形式的缺陷或缺陷也从属于其中某种形式。
6. 明确指明缺陷严重等级和优先等级时刻明确严重等级和优先等级之间的差别。高严重问题可能不值得解决，小装饰性问题可能被当作高优先级。
7. 描述 (Description) ，简洁、准确，完整，揭示缺陷实质，记录缺陷或缺陷出现的位置描述要准确反映缺陷的本质内容，简短明了。为了便于在软件缺陷管理数据库中寻找制定的测试缺陷，包含缺陷发生时的用户界面（UI）是个良好的习惯。例如记录对话框的标题、菜单、按钮等控件的名称。
8. 短行之间使用自动数字序号，使用相同的字体、字号、行间距短行之间使用自动数字序号，使用相同的字体、字号、行间距，可以保证各条记录格式一致，做到规范专业。
9. 每一个步骤尽量只记录一个操作保证简洁、条理井然，容易重复操作步骤。
10. 确认步骤完整，准确，简短保证快速准确的重复缺陷，“完整”即没有缺漏，“准确”即步骤正确，“简短”即没有多余的步骤。
11. 根据缺陷，可选择是否进行图象捕捉为了直观的观察缺陷或缺陷现象，通常需要附加缺陷或缺陷出现的界面，以图片的形式作为附件附着在记录的“附件”部分。为了节省空间，又能真实反映缺陷或缺陷本质，可以捕捉缺陷或缺陷产生时的全屏幕，活动窗口和局部区域。为了迅速定位、修正缺陷或缺陷位置，通常要求附加中文对照图。 附加必要的特殊文档和个人建议和注解如果打开某个特殊的文档而产生的缺陷或缺陷，则必须附加该文档，从而可以迅速再现缺陷或缺陷。有时，为了使缺陷或缺陷修正者进一步明确缺陷或缺陷的表现，可以附加个人的修改建议或注解。
12. 检查拼写和语法缺陷在提交每条缺陷或缺陷之前，检查拼写和语法，确保内容正确，正确的描述缺陷。
13. 尽量使用短语和短句，避免复杂句型句式软件缺陷管理数据库的目的是便于定位缺陷，因此，要求客观的描述操作步骤，不需要修饰性的词汇和复杂的句型，增强可读性。以上概括了报告测试缺陷的规范要求，随着软件的测试要求不同，测试者经过长期测试，积累了相应的测试经验，将会逐渐养成良好的专业习惯，不断补充新的规范书写要求。此外，经常阅读、学习其他测试工程师的测试缺陷报告，结合自己以前的测试缺陷报告进行对比和思考，可以不断提高技巧。
14. 缺陷描述内容缺陷描述的内容可以包含缺陷操作步骤，实际结果和期望结果。操作步骤可以方便开发人员再现缺陷进行修正，有些开发的再现缺陷能力很差，虽然他明白你所指的缺陷，但就是无法再现特别是对系统不熟悉的新加入开发人员，介绍步骤可以方便他们再现。实际结果可以让开发明白错误是什么，期望结果可以让开发了解正确的结果应该是如何。

二：需求文档会不会写，使用手册会不会写？

需求文档：

1. 项目背景与需求分析？
   —谁提的需求？什么场景？遇到什么问题？
   —简要描述分析过程：决策过程和依据是什么？解决方案是什么？
   —有没有相关的背景数据资料？
   —明确本次需求：用户、场景、需求、解决方案是什么？
2. 本次需求的目的及功能列表？
   —这个需求整体是什么样子的？是否要分阶段？
   —本次需求做哪些？前后关系是什么？
   —本次需求的功能清单有什么？
   —涉及的功能或页面有什么？
3. 流程与所处的产品模块关系
   —业务逻辑图
   —业务流程图
   —页面流程图
4. 功能详细描述
   —交互设计图
   —原型图
5. 简要的测试用例（可选）
   —关键的用例是什么？
   —重点关注点
   —错误提示表
6. 考核指标
   —本次需求要统计哪些指标？
   —怎么计算的？
   —怎么埋点的？

使用手册

三. 测试用例设计要遵循的原则

代表性：

能够代表并覆盖各种合理的和不合理、合法的和非法的、边界的和越界的、以极限的输入数据、操作和环境设置等.

可判定性：

即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果.

可再现性：

即对同样的测试用例，系统的执行结果应当是相同的。

四. Web项目中的安全测试怎么测？

五 错误推断法设计用例？

基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例的方法。

列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据这些情况选择测试用例
例子：

六. 产品测到什么时候就算足够（结束标准）？

（1）从微观上来说，在测试计划中定义，比如系统在一定性能下平稳运行72小时，目前Bug Tracking System中，本版本中没有一般严重的BUG，普通BUG的数量在3以下，BUG修复率90%以上等等参数，然后由开发经理，测试经理，项目经理共同签字认同版本Release。
（2）如果说宏观的，则是当这个软件彻底的消失以后，测试就结束了。