按测试类型分类
1.测试执行过程
测试执行阶段的主要任务
1.确定测试用例的优先级
2.开发测试规程并确定优先级，创建测试数据，同时也可以准备测试用具和设计自动化测试脚本
3.根据测试规程创建测试套件，以提高测试执行的效率
（按照测试计划去设计创建测试场景，把相应的测试用例塞到我的测试套件里）
4.确认已经正确搭建了测试环境
5.根据计划的执行顺序，通过手工或使用测试工具来执行测试规程（都是依据计划里的执行顺序）
6.记录测试执行的结果，以及被测软件、测试工具和测试件的标识和版本.
（提取一些bug，记录当前被测软件的版本号）
7.将实际结果和预期结果进行比较，对实际结果和预期结果之间的差异，作为事件上报，并且进行分析以确定引起差异的原因
8.缺陷修正后，重新进行测试活动
2.测试准入准出–必知标准
测试准入标准（什么情况下可以开始测试）
◆开发编码结束，并在开发环境已完成单元测试。（开发自己对代码有一个初步的测试）
◆需求上规定的功能均已实现;如没有完全实现，请提供测试范围
◆已完成集成测试，被测系统的基本流程可以走通，界面上的功能均实现，经过代码评审并符合软件编码规范（相当于开发之间的联调）
◆开发提交最新版本代码，以此为基线,提交并通知测试组进行测试
◆兼容性测试要求明确
◆安全测试和性能测试范围和要求
（开发自测，基本流程跑通，测试范围比较明确）
测试暂停、停止
1.测试人员先进行冒烟测试，若发现重大缺陷或bug过多时、或者流程卡壳导致基本流程无法走通，测试无法正常进行，可以暂停测试并返回开发
2.被测项目需调整而暂停的，测试也相应暂停
3.存在其他优先级更高的任务时，可以向领导申请暂停测试
4.被测系统经过系统测试，达到系统准出标准，可以停止测试
测试准出标准（什么情况下测试结束）
3.软件缺陷
缺陷是一种泛称，它可以指功能的错误，也可以指性能低下，易用性差等（比如响应时间长）
并不是所有的测试人员都能提交被开发认可的缺陷，也不是测试员在任何时候都能提交被开发认可的缺陷
什么是软件缺陷
1.软件未达到产品说明书标明的功能（需求遗漏）
2.软件出现了产品说明书指明不会出现的错误
3.软件功能超出产品说明书指明范围
4.软件未达到产品说明书虽未指出但应达到的目标（可能是客户可能是产品经理要求应达到的）
5.软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好
（这个软件爱的呢某个按钮是什么意思， 或者整个软件不好使用，越用越慢）
缺陷产生的原因
所以测试人员要尽早的加入讨论组中。
由于热点的变化，项目需求也会不断变化，或者刚开始没有剖析好需求
由于软件复杂，随便改一个小的地方都可能影响到全部
流程中没有完善的需求文档，设计文档等都可能会使缺陷产生。
好的测试能够思考到缺陷产生的原因
如何发现缺陷
1.用户体验不够好
2.界面上有明显的错误信息
3.功能不完备，没有按照需求说明编写代码，致使某些功能缺失
4.**功能不完善，**不能正常运行或者运行的过程中出现程序崩溃、停止运行的情况
5.逻辑不正确，与需求说明书、测试用例不符
6.模块之间的交互性不好，与其他的模块做集成测试时遇到问题（系统不是一个人开发的，多人共同协作交互的时候可能由于沟通的比较少会出现问题）
7.程序的性能不够好，不能承载压力考验
缺陷报告–注意事项
对于缺陷报告很重要的一点是上报的缺陷一定要是可以重现的缺陷
BUG重现
1.不要我认为我觉得，要做好bug记录，记录流程
2.查找时间以来和竞争条件的问题（比如余额宝的基金分红是和时间有关的），发现这个问题是有什么条件的
3.边界条件软件缺陷、内存泄露和数据溢出等白盒问题可能会慢慢自己显露出来（比如一个项目吗开始测试的时候都没问题，但是一个月后测试突然变得非常慢，就可以考虑是内存泄漏等问题）
4.状态缺陷仅在特定软件状态中显露出来
5.考虑资源依赖性和内存、网络、硬件共享的相互作用
无法重现的BUG
（突然出现，突然不见，抓不到规律无法复现）
1.首先，应当对这样的缺陷进行详细的记录，并尽快提交给开发人员
2.其次，对于寻找难以再现的缺陷要合理地安排时间，要考虑到测试项目的整体进度,对一-时难以再现的缺陷可以暂时搁置，以保证项目的正常进度
3.最后在测试过程中对于未出现的bug予以关注，自己再研究研究
缺陷报告
1.缺陷报告是对缺陷进行记录、分类和跟踪的文档
2.软件测试人员的任务之一就是书写良好的软件缺陷报告
3.提供准确、完整、简洁、一致的缺陷报告是体现软件测试的专业性、高质量的主要评价指标
4.通常，缺陷报告的直接读者是软件开发人员和质量管理人员,除此之外，来自市场和技术支持等部门的人也可能需要查看缺陷情况
缺陷报告包含信息
◆易于搜索软件测试报告的缺陷。（软件缺陷要有自己的关键词）
◆报告的软件缺陷进行了必要的隔离，报告的缺陷信息具体、准确。（找到错误真正发生的点，不要概括地说这整个流程都有错）
◆软件开发人员希望获得缺陷的本质特征和复现步骤。（从开发人员的角度来看，给出缺陷本质是从哪里来的）
◆市场和技术支持等部门]希望获得缺陷类型分布以及对市场和用户的影响程度。（比如是应用型或流程型，从而判断你这个缺陷对于市场对于用户的影响有多大）
缺陷报告的写作准则(5C)
◆Correct (准确) : 每个组成部分的描述准确，不会引起误解
◆Clear (清晰) : 每个组成部分的描述清晰，易于理解
◆Concise (简洁) : 只包含必不可少的信息，不包括任何多余的内容（不光包含步骤，还要包含用了什么数据彩印发这个缺陷）
◆Complete (完整) :包含复现该缺陷的完整步骤和其他本质信息
◆Consistent (一致) : 按照一致的格式书写全部缺陷报告
缺陷报告的组织架构
1.缺陷的标题（比如容易被搜索到）
2.缺陷的基本信息（环境信息版本信息，在哪个项目里呀）
3.测试的软件和硬件环境
4.测试的软件版本
5.缺陷的类型
6.缺陷的严重程度
7.缺陷的处理优先级（优先处理的需要开发人员立即给予技术支持）
8.复现缺陷的操作步骤
9.缺陷的实际结果描述
10.期望的正确结果描述
11.注释文字和截取的缺陷图像
缺陷标题
1.尽量按缺陷发生的原因与结果的方式书写( "执行完A后， 发生B，”或者"发生B，当A执行完后”)
2.避免使用模糊不清的词语，例如“功能中断”“功能不正确”
行为不起作用”等。应该使用具体文字说明功能如何中断，如何
不正确，或如何不起作用
3.使用关键字使得方便搜索
4.避免使用术语，俚语或过分具体的测试细节等
缺陷复现步骤.
**复现步骤包含如何使别人能够很容易的复现该缺陷的完整步骤。**为了达到这个要求，复现步骤的信息必须是完整的、准确的、简明的、可复现的
但是实际软件测试过程中，总是存在一些不良的缺陷报告, 主要的问题在于多余步骤、可读性差、难以理解、缺失步骤等
复现步骤的要求
◆提供测试的预备步骤和信息
◆简单地一步一步地引导复现该缺陷
◆每一个步骤尽量只记录一个操作
◆每一个步骤前使用数字对步骤编号
◆尽量使用短语和短句，避免复杂句型和句式
◆复现的操作步骤要完整，准确，简短
◆没有缺漏任何操作步骤
◆每个步骤都是准确无误的
◆没有任何多余的步骤
◆将常见步骤合并为较少步骤
◆只记录各个操作步骤是什么,不需要包括每个步骤的执行结果
缺陷报告注意事项
◆缺陷报告已经向读者包含完整、准确、必要的信息了吗?
◆一个缺陷报告中是否只报告了一种缺陷? （不要在一个缺陷报告中堆太多缺陷，有开发人员去做更深层次的分析）
◆读者是否能容易的搜索该缺陷?
◆步骤是否可以完全复现而且表达清楚吗?
◆是否包含了复现该缺陷需要的环境变量或测试所用的数据文件?（是不是按照从因到果的方式书写）
◆缺陷的标题是按照原因与结果的方式书写的吗?
◆实际结果和期望结果是否描述不够清楚而容易引起歧义吗?
缺陷报告的原则
1.组织Structure:
测试人员应该采用深思熟虑的，小心谨慎的方法执行测试，并且做详尽的记录。这样可以促使他们对待测系统有很好的认识。当错误发生的时候，一个有组织的测试人员能够知道最早出现问题的地方。
2.重现Reproduce:
测试人员在编写缺陷报告之前必须检查问题是否可重现。如果错误不可再重现，仍然应该写下来，但是必须说明问题的偶然性。一个好的处理原则就是在编写缺陷，报告之前反复尝试3次。
3.隔离Isolate:
在尝试编写缺陷报告之前，必须试着隔离错误。可以采用改变一些变量的方法（来看看缺陷是由于数据，程序还是配置等原因导致的），如系统的配置，它可能可以改变错误的症状。这些信息可以为开发人员着手调试提供思路。
4.归纳Generalize:
发现了一个已隔离的，可重现的问题后，应该对问题进行归纳。同一个问题是否出现在其他的模块或其他的地方?同一个故障是否有更加严重的问题?
5.对比Compare:
如果测试人员以前曾经验证过现在出错的测试用例，那么他就应该检查以前的测试结果以检查相同的条件以前的测试是否通过。如果是的话，那么这个问题就象是一个回归的错误。注意由于同一测试条件有可能出现在多个测试用例中，这个步骤就不仅仅只是检查一个测试用例在以前的多个结果。
6.总结Summarize:
在缺陷报告的第一行写上错误的总结是非常关键的。测试人员要花些时间思考已发现的错误对客户有何影响。这不仅仅要求测试人员编写的报告要能够吸引读者,使和管理层的沟通清晰，还要能够帮助设置错误修复的优先级别。
7.精简Condense:
在缺陷报告的初稿完成后，测试人员应该反复阅读它，集中剔除那些没有关系的步骤或词语。隐含的或模糊的说明和那些由于对没有任何关系的细节或者那些在重现错误过程中不需要的步骤而消磨报告欢迎程度的无穷唠叨都不是缺陷报告的目标。（不要写的太详细，有些很简单的操作不用展开太细）
8.消除歧义Disambiguate:
测试人员在精简空话的同时或其之后随即应该再仔细检查报告是否有会产生误解的地方。测试人员
应该尽量避免使用模糊的，会产生歧义的和主观的词语。目标是使用能够表述事实，清楚的，不会产生争执的词语。
9.中立Neutralize:
作为坏消息的传递人，和善地提交消息是一个挑战。如同所有的错误总结一样,独立的缺陷报告在措辞方面应该保持公正。攻击开发人员，指责潜在的错误，企图诙谐或使用挖苦将弓|起开发人员的憎恶，并且使注意力从"提高产品质量”这个大的目标上转移开了。
10.检查Review:
一旦测试人员感觉缺陷报告是他能够编写的最好版本，他应该将报告再给一个或多个同行进行检查。在允许的时间里，测试小组应该尽可能提交最好的缺陷报告。
关于bug
bug的生存周期：
从bug被发现的那一刻到bug已经被开发解决（开发和测试沟通的过程）
下面可以很好的体现bug的一生
人员在bug生命周期中的分工
缺陷跟踪管理系统
早期的缺陷跟踪大都是以缺陷记录单的形式完成，现在还有很多项目还用此方法，但是随着用户对软件功能需求的不断增加，软件算法和复杂度都发生了很多变化，随之而来的是软件缺陷的增长，后来用Excel也不够用，所以出现了缺陷跟踪管理系统。
在软件行业发展历程中，曾经或者正在被大量使用的缺陷管理系统包括JIRA、BUGZILLA、 QC、禅道等。
而目前，除了部分大型IT公司拥有自研的缺陷跟踪管理系统外,很多公司应用禅道来进行缺陷跟踪甚至是项目管理。
这几个平台主要就是页面不一样，实质相差不多 都是bug管理
