一、应结合自己参与的信息系统项目，说明在其中所承担的工作。
二、软件缺陷定义：
（1）软件未达到需求规格说明书的功能；
（2）软件出现了需求规格说明书指明不会出现的错误；
（3）软件功能超出需求规格说明书的范围；
（4）软件未达到需求规格说明书未指出但应达到的目标；
（5）测试工程师认为软件难以理解、不易使用、运行速度慢，或者最终用户认为不好。
缺陷类型：
（1）设计缺陷：由于软件设计或代码实现所产生的功能或流程的问题。
（2）界面问题：系统页面的展示的问题。
（3）数据问题：系统数据的来源，处理及处理结果的问题。
（4）需求问题：软件需求测试发现的问题，也包括之后需求变更的问题。
（5）安装部署：软件安装部署过程的错误。
（6）性能问题：软件性能相关的缺陷。
（7）文档问题：用户使用手册，软件帮助文档等出现的问题。
（8）常识问题：系统用户的正常使用习惯相关问题。
（9）安全问题：系统漏洞安全问题。
（10）优化建议：针对操作过程逻辑或界面显示的优化性建议。
（11）其他：除前面分类的其他问题。
严重程度定义
注：严重等级由创建者在创建缺陷时根据此定义来选择，之后都不能随意更改。
优先级的定义
注：立刻、紧急、尽快的问题都要求在系统上线前解决。
正常处理过程：
（1）创建问题
在测试管理系统中，所有用户都可以创建新问题，包括需求问题和软件缺陷等。创建问题时，需要描述清楚，并选择正确的选项。
（2）指派问题
创建问题时，创建者通常要指派给该项目开发负责人，再由其指派任务，或直接指派给相应模块的开发工程师。
如果指派人是错误的，或者需要他人确认或帮助，则可以重新指派给合适的工程师，写上相关备注。
（3）确认问题
通常开发工程师收到新问题后，需要分析和确认此问题是否为Bug。如果是Bug，则选择“确认状态”；如果认为非Bug，则注明原因并指派回创建者。
当创建者收到确认指派时，需要进行及时确认。如果同意为非bug，则及时关闭它；如果不同意，则需要注明理由并指派回相关工程师。
如果问题确认指派次数大于6次时，需要进入“争议处理”流程。
（4）解决问题
此为开发工程师的主要职责，包括Bug的复现、修改和修改验证。
开发工程师需要及时对确认状态Bug进行分析和解决，并自己验证通过，则操作为解决状态，在缺陷管理系统中解决方案选择相应的选项，解决后系统将自动指派回给创建者。
如果Bug无法解决或修改影响比较大，可申请进入“延期解决”流程。
（5）验证问题
创建者需要及时对解决状态的Bug在对应版本上面进行验证。如果验证通过，则可关闭Bug；如果验证不通过，则激活此Bug，系统将自动指派回给解决者。
验证通过准则：相同的操作步骤，进行一定次数的验证测试都没有发生。
验证不通过准则：相同的操作步骤，全部或部分实际结果还会发生，验证不通过则激活Bug。
（6）关闭问题
通过验证的Bug，验证者需要注明验证结果并进行关闭操作，系统将指派给Closed。
如果关闭状态的Bug在之后版本又会发生，则激活此Bug，系统将自动指派回给解决者。
特别处理过程：
（1）客户问题
客户反馈的问题可以由客户直接反馈或项目经理、市场部等了解到客户问题后，将确认后的Bug提交到测试管理系统，按照以上处理流程进行处理，由创建者或测试组进行跟踪验证关闭。
创建客户问题时，创建者需要在Bug标题开头标记为[客户问题]，测试组负责检查和更正。
（2）争议处理
当开发和测试工程师对某问题有争议并且多次沟通无果时（暂定为6次），可以注明双方的理由，并指派给项目经理进行处理。
项目经理可以召开评审会议，或者直接与双方沟通了解，并根据项目情况给出专业意见和最终决定。开发和测试工程师根据项目经理的最终决定执行。
（3）延期解决
当开发工程师对确认Bug进行解决时，发现或评估其解决时间紧或风险比较大等，可以说明原因或理由并指派给项目经理来确认。
项目经理可以召开评审会议，或者直接沟通了解，并根据项目情况给出最终决定。如果不同意，项目经理将此Bug指派回开发工程师，开发工程师继续分析和解决。如果同意，项目经理需要在Bug标题开头标记为[延期解决]和在处理状态选择“延期解决”，然后注明解决时间计划并指派回开发工程师，开发工程师根据解决时间计划来规划和解决此Bug。
三、第三个问题要根据项目的实际情况来写自己是怎么做的，遇到什么样的问题，如何解决的。同时文章收尾要对效果进行评价。
