南昌专业的软件测试培训学校一览表

　　优就业软件测试培训学院培养全栈式软件测试人才，课程设置科学，0基础适学，教学内容涵盖广，贯穿大型项目实训，实战性更强。讲师全程面授，严管学习进度，就业服务贯穿始终，推荐就业。师资严选，由北京大学、北京师范大学、北京、东北林业大学等学校硕士，前华为公司、东软集团、中信银行、数码集团、方正国际、创维集团、运载火箭研究院等测试工程师组成。讲师参与众多大型项目的测试工作，如神州一号稳定性测试、华为融合消息中心压力测试、华为云服务自动化测试、高德在线地图接口测试等，涉及金融、医疗、教育、航天等行业。

　　课程研发深思熟虑、不断更新迭代

　　十*大测试工具：学习LoadRunner、JMeter、Selenium、Appium、Postman、Fiddler等测试工具。

　　前沿开发语言：学习前沿开发语言Python，打下自动化测试的基础。

　　五*大测试技术：课程内容涵盖功能、web自动化、移动自动化、接口、性能主流测试技术。

　　五*大测试领域：按照企业工作流程实训演练，毕业后可进入金融、大数据、电商、移动APP、游戏、企业级应用软件等领域

　　缺陷生命周期

　　知识点：

　　1.缺陷生命周期中各角色的职责

　　2.缺陷的严重程度分类

　　3.缺陷级分类

　　4.缺陷的状态

　　什么是缺陷生命周期

　　缺陷从较开始被发现并提交，到缺陷被修复，较后被验证和关闭的过程称为缺陷生命周期。

　　缺陷生命周期中各角色的职责

　　测试人员：负责测试执行及缺陷跟踪，执行测试发现缺陷后提交到缺陷管理工具中，开发人员修改后需验证缺陷，确认缺陷修改是否正确，一般缺陷由谁提交就由谁来验证，因为提交缺陷的人较了解该缺陷被发现的过程，能更全面的验证该缺陷是否被修复。

　　测试组长：除了负责测试执行和缺陷跟踪外，还需要对测试人员提交的缺陷进行初步审查，增加提交的缺陷都是有效缺陷。

　　项目经理：对新建和重新打开的缺陷进行审核和分配，包括判定缺陷是否有效，设定缺陷解决的时效，给出修复方案的建议和意见。

　　开发人员：对分配给自己的缺陷进行判定及修复，同时对提交错误的缺陷具有拒绝修改的权限。

　　缺陷评审委员会：主要由项目经理、测试经理、质量经理、开发经理、经验丰富开发人员和测试人员组成，他们主要对每一轮测试结束后遗留的缺陷进行确认，将其分配给相应开发人员进行修复，对有争议的缺陷进行仲裁.

　　缺陷的严重程度分类

　　缺陷严重程度：用于说明缺陷对软件系统的影响程度(站在用户的角度)，它和缺陷发生的可能性没有直接关系，缺陷影响程度越大，严重程度就越高。

　　缺陷严重程度分类：

　　致命：系统无法为用户提供服务，系统崩溃或意外退出，蓝屏，造成资源严重不足，数据丢失，或者软件失效造成人身伤害；

　　重大：会影响系统提供给用户的服务，比如系统重启或挂起，功能失效且没有其他可替代的方案，其他严重错误；

　　一般：功能已实现，但存在明显的错误；

　　微小：操作不方便，易使用户误操作，描述有歧义，显示格式不规范等；

　　建议：使用过程中可以提升用户体验的问题，或者后续可以新增加的功能；

　　缺陷级分类

　　缺陷级：用来评估缺陷处理的先后顺序，会随着项目的进展发生变化，通常是站在开发和测试人员角度进行考虑，确定级需要考虑技术问题、缺陷修复难度和风险、缺陷发生的频率、对较终用户的影响。

　　一般严重程度越高的缺陷级越高，严重程度越低的缺陷级越低；有时虽然缺陷严重程度高，但它只在某些特殊情况出现，或者修复该缺陷需要修改软件整体架构，从而引发更多缺陷，或者软件须尽快发布，此时该缺陷的级可能不高，甚至不需要处理；有时缺陷严重程度很低，如软件中出现的公司名称拼写错误，但也须立即修复，因为它关系到公司的形象，此时缺陷级就比较高。

　　缺陷级分类：

　　较高：业务流程阻塞，测试无法进行下去，这种缺陷必须立即修复；

　　高：缺陷严重，需要考虑的；

　　正常：缺陷正常等待修复；

　　低：缺陷可以在开发人员有时间时再修复；

　　较低：缺陷不影响软件的发布，但在发布前必须确认解决、推迟或不解决；

　　缺陷的状态

　　open：测试人员发现缺陷，确认该缺陷没有提交过(以免造成重复提单)，新建缺陷，状态为open，并指给项目经理(如果测试人员清楚该模块的开发人员，则可直接指给相应开发人员)；

　　assigned：项目经理将新建状态的缺陷分配给开发人员，状态为assigned；

　　not a bug：开发人员收到缺陷后检查该缺陷是否有效，若无效，则修改该缺陷的状态为not a

bug，在comment中注明原因并返回给测试人员，测试人员确认后选择重新打开或关闭该缺陷；

　　won't fix：若开发人员认为该缺陷不需要修复，则修改状态为won't

fix，注明原因并返给测试人员，测试人员确认后选择重新打开或关闭该缺陷；

　　duplicate：若开发人员认为该缺陷是一个重复缺陷，则修改状态为duplicate，关联重复缺陷返给测试人员，测试人员确认后选择重新打开或关闭该缺陷；

　　can't reproduce：当开发人员无法重现该缺陷时，则修改状态为can't

reproduce，注明原因并返给测试人员，测试人员确认无法重现则关闭，否则需在comment中详述重现的环境、条件及步骤，必要时提供能复现该缺陷的环境给相应的开发人员，并修改状态为reopen；

　　pending：如果开发人员确认是问题，但因为它可能只在极端情况才出现，或需要对系统架构进行改动，或级低而暂时不需要修复，则可将状态改为pending，等待后续版本修复；

　　invalid：后续版本可能因为需求变更导致某些功能或模块不存在，或者之前的缺陷不存在了，则可修改状态为invalid；

　　need more info：如果该bug描述不完整，需要提供更多的信息进行定位，则修改状态为need more

info，在comment中注明返回给测试人员，测试人员提供相应信息后reopen；

　　in progress：当开发人员认为该缺陷有效，需要修复，则修改状态为in progress，并开始分析缺陷，进行修复；

　　fixed：开发人员修复完缺陷后，修改缺陷状态为fixed，在comment中描述缺陷出现的原因，修复方法，影响范围，并指给测试人员或测试负责人；

　　wait for verification：测试负责人将缺陷指给测试人员时修改状态为wait for verification；

　　reopened：测试人员对已修复的缺陷进行验证，验证不通过，则修改状态为reopened，开发人员重新修复，直到缺陷验证通过；

　　closed：测试人员对已修复的缺陷进行验证，验证通过后，修改状态为closed。