按测试类型分类

• 1.测试执行过程
• 2.测试准入准出–必知标准
• 3.软件缺陷
• • 缺陷报告–注意事项
  • 缺陷报告
  • 缺陷复现步骤.
  • 缺陷报告注意事项
• 关于bug
• • 人员在bug生命周期中的分工
  • 缺陷跟踪管理系统

是看着课程听的，做的课程的随堂笔记
课程的链接如下：
https://coding.imooc.com/class/411.html

1.测试执行过程

3.软件缺陷

缺陷是一种泛称，它可以指功能的错误，也可以指性能低下，易用性差等（比如响应时间长）
并不是所有的测试人员都能提交被开发认可的缺陷，也不是测试员在任何时候都能提交被开发认可的缺陷
什么是软件缺陷
1.软件未达到产品说明书标明的功能（需求遗漏）
2.软件出现了产品说明书指明不会出现的错误
3.软件功能超出产品说明书指明范围
4.软件未达到产品说明书虽未指出但应达到的目标（可能是客户可能是产品经理要求应达到的）
5.软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好
（这个软件爱的呢某个按钮是什么意思， 或者整个软件不好使用，越用越慢）

缺陷产生的原因

缺陷复现步骤.

**复现步骤包含如何使别人能够很容易的复现该缺陷的完整步骤。**为了达到这个要求，复现步骤的信息必须是完整的、准确的、简明的、可复现的
但是实际软件测试过程中，总是存在一些不良的缺陷报告, 主要的问题在于多余步骤、可读性差、难以理解、缺失步骤等

复现步骤的要求
◆提供测试的预备步骤和信息
◆简单地一步一步地引导复现该缺陷
◆每一个步骤尽量只记录一个操作
◆每一个步骤前使用数字对步骤编号
◆尽量使用短语和短句，避免复杂句型和句式
◆复现的操作步骤要完整，准确，简短
◆没有缺漏任何操作步骤
◆每个步骤都是准确无误的
◆没有任何多余的步骤
◆将常见步骤合并为较少步骤
◆只记录各个操作步骤是什么,不需要包括每个步骤的执行结果

缺陷报告注意事项

◆缺陷报告已经向读者包含完整、准确、必要的信息了吗br> ◆一个缺陷报告中是否只报告了一种缺陷（不要在一个缺陷报告中堆太多缺陷，有开发人员去做更深层次的分析）
◆读者是否能容易的搜索该缺陷br> ◆步骤是否可以完全复现而且表达清楚吗br> ◆是否包含了复现该缺陷需要的环境变量或测试所用的数据文件是不是按照从因到果的方式书写）
◆缺陷的标题是按照原因与结果的方式书写的吗br> ◆实际结果和期望结果是否描述不够清楚而容易引起歧义吗/p>

缺陷报告的原则
1.组织Structure:
测试人员应该采用深思熟虑的，小心谨慎的方法执行测试，并且做详尽的记录。这样可以促使他们对待测系统有很好的认识。当错误发生的时候，一个有组织的测试人员能够知道最早出现问题的地方。
2.重现Reproduce:
测试人员在编写缺陷报告之前必须检查问题是否可重现。如果错误不可再重现，仍然应该写下来，但是必须说明问题的偶然性。一个好的处理原则就是在编写缺陷，报告之前反复尝试3次。
3.隔离Isolate:
在尝试编写缺陷报告之前，必须试着隔离错误。可以采用改变一些变量的方法（来看看缺陷是由于数据，程序还是配置等原因导致的），如系统的配置，它可能可以改变错误的症状。这些信息可以为开发人员着手调试提供思路。
4.归纳Generalize:
发现了一个已隔离的，可重现的问题后，应该对问题进行归纳。同一个问题是否出现在其他的模块或其他的地方一个故障是否有更加严重的问题br> 5.对比Compare:
如果测试人员以前曾经验证过现在出错的测试用例，那么他就应该检查以前的测试结果以检查相同的条件以前的测试是否通过。如果是的话，那么这个问题就象是一个回归的错误。注意由于同一测试条件有可能出现在多个测试用例中，这个步骤就不仅仅只是检查一个测试用例在以前的多个结果。
6.总结Summarize:
在缺陷报告的第一行写上错误的总结是非常关键的。测试人员要花些时间思考已发现的错误对客户有何影响。这不仅仅要求测试人员编写的报告要能够吸引读者,使和管理层的沟通清晰，还要能够帮助设置错误修复的优先级别。
7.精简Condense:
在缺陷报告的初稿完成后，测试人员应该反复阅读它，集中剔除那些没有关系的步骤或词语。隐含的或模糊的说明和那些由于对没有任何关系的细节或者那些在重现错误过程中不需要的步骤而消磨报告欢迎程度的无穷唠叨都不是缺陷报告的目标。（不要写的太详细，有些很简单的操作不用展开太细）
8.消除歧义Disambiguate:
测试人员在精简空话的同时或其之后随即应该再仔细检查报告是否有会产生误解的地方。测试人员
应该尽量避免使用模糊的，会产生歧义的和主观的词语。目标是使用能够表述事实，清楚的，不会产生争执的词语。
9.中立Neutralize:
作为坏消息的传递人，和善地提交消息是一个挑战。如同所有的错误总结一样,独立的缺陷报告在措辞方面应该保持公正。攻击开发人员，指责潜在的错误，企图诙谐或使用挖苦将弓|起开发人员的憎恶，并且使注意力从”提高产品质量”这个大的目标上转移开了。
10.检查Review:
一旦测试人员感觉缺陷报告是他能够编写的最好版本，他应该将报告再给一个或多个同行进行检查。在允许的时间里，测试小组应该尽可能提交最好的缺陷报告。

关于bug

人员在bug生命周期中的分工

来源：Bubblegirl123