Bug分类
1功能：
1.1功能未实现（一般为功能没有实现需求功能）
1.2功能异常（一般为测试是功能操作报错，无法正常执行）
2数据
2.1数据校验错误（一般为测试数据校验的规则是否存在且能正常校验，如果开始时
间小于结束时间，手机号码校验、身份证校验、编码规则校验等等）
2.2数据展示错误（一般测试从数据库中查询出来的数据在展现是对应的字段是否正
确、展现的格式或字符类型是否正确）
2.3数据计算错误（主要为查询统计功能中的计算数据是否正确）
2.4数据丢失（一般指数据在流转过程中，数据信息中某些字段或数据本身不能正常
显示或数据库中数据丢失）
2.5数据不一致（一般指同一个字段的数据在不同模块或界面显示的数据不一致）
3一致
3.1与功能需求不符
3.2与界面需求不符
3.3字段名称不一致
3.4需求不明确（需求建议可以归为需求不明确）
4环境
4.1客户端环境（一般为某个客户端出现异常而其他客户端能正常使用）
4.2应用服务器环境（一般为应用服务器环境问题导致系统不能正常执行，如tomcat
版本问题、JDK版本问题等等）
4.3数据库服务器环境（一般为数据库服务器环境问题导致系统不能正常执行，如
Oracle版本问题、Oracle参数问题等等）
5易用性
5.1提示信息不友好
5.2提示信息错误
5.3操作易用性建议
6界面
6.1界面有错别字
6.2界面不美观、风格不一致
6.3界面建议
7其他
7.1系统崩溃
7.2服务僵死
7.3客户端死机
7.4程序不可预期的退出
7.5兼容性。
Bug剖析•所有的Bug报告有以下的基本要求：•标题。
要简略。
•指派。
谁来处理这个问题。
•重现步骤。
问题再次出现的相关步骤。
•优先级别。
问题的紧迫性与重要性。
•严重程度。
问题所产生的后果。
•解决方案。
怎么解决问题。
其他很多方面对修复问题及明白其深层次原因也很有帮助，但以上基本准则简练得多。
下面我们来对每条准则逐一展开讨论，消除这些疑惑。
标题及指派标题应该简明扼要，一句话就详尽说明问题的唯一性，使Bug报告的检索及标识变得简单。
“点击取消按钮，屏幕就清空了”是个差劲的标题。
“关闭编辑框，清空屏幕”就是个很好的标题。
后者简短得多，而且对问题的出处及发生时间提供了具体的信息。
当你要创建一份新的Bug报告时，你必须指定具体人选来解决其中问题。
但是，即使你这个团队的每个人都很了解，你也不应该将一个Bug指定给其中某一位，除非你是开发团队的一员。
相反，你应该将此任务交给这整个团队。
通常的做法是在Bug报告中指定责任方或团队作为默认选择。
默认的选择通常是“主导”或“会诊”团队。
不会再有更好的了。
要相信这些团队，他们会知道问题由谁来解决。
作者注：有些团队希望将所有Bug都指派给团队中的某些个人，这样可保证没有Bug被遗漏。
但是，他们还是必须确认将Bug指派给“主导”或“会诊”团队以确保Bug未被遗漏。
毕竟，团队外部人员并不知道软件还有其他什么功能。
作为惯例，所有Bug必须指派给能对其进行经常性检查的个人或团队。
因为，大多数优先团队会每天开例会，我还是偏好将Bug指定给“主导”或“会诊”团队为默认选择。
重现步骤没什么比一份Bug报告没有清晰的重现步骤更让人郁闷了。
就像你的亲友对你说：“你知道该怎么办！”，没有给你更多解释。
这让我很茫然，不知道怎么办。
悲催了。
Bug重现步骤应是言简意赅——一言中的。
同时要包含软件创建编号（通常是单独列出的），你的工作环境（操作系统版本、所用浏览器及其他相关的细节）以及一些先备条件（像先注册个Xbox com金牌账号等）。
Bug的级别定义、bug的提交流程都是一个公司的相关要求。
一般来讲bug报告中，按照bug类型分、bug级别分、bug重现能力分Bug状态一、bug类型分一般会分为功能性bug、界面bug、兼容性等等的bug1、为什么会这么做呢？因为在做bug汇总和评估的时候会根据这些分类，把bug都汇总起来当然与我们相关的似乎就是绩效考核。
（别的作用我想不到了）二、bug严重级别分分出以下bug级别，并在网上找到了相应的描述。
做参考（1）致命错误致命错误通常有如下情况：1、需求书中的重要功能未实现；2、造成系统崩溃、死机,并且不能通过其它方法实现功能；3、常规操作造成程序非法退出、死循环、通讯中断或异常，数据破坏丢失或数据库异常、且不能通过其它方法实现功能的。
（2）严重错误严重错误通常使系统不稳定、不安全、或破坏数据、或产生错误结果，而且是常规操作中经常发生或非常规操作中不可避免的主要问题，1、重要功能基本能实现，但系统不稳定、一些边界条件下操作会导致run-time error、文件操作异常、通讯异常、数据丢失或破坏等错误；2、重要功能不能按正常操作实现，但可通过其它方法可实现；3、错误的波及面广，影响到其它重要功能正常实现；4、密码明文显示；5、C/S、B/S模式下，利用客户端某些操作可造成服务端不能继续正常工作的。
（3）一般错误程序的功能运行基本正常，但是存在一些需求、设计或实现上的缺陷；次要功能运行不正常，1、次要功能不能正常实现；2、操作界面错误（包括数据窗口内列名定义、含义不一致）；3、打印内容、格式错误；4、查询错误，数据错误显示；5、简单的输入限制未放在前台进行控制；6、删除操作未给出提示；7、数据库表中有过多的空字段；8、因错误操作迫使程序中断；9、找不到规律的时好时坏；10、数据库的表、业务规则、缺省值未加完整性等约束条件；11、经过一段时间运行后，系统性能或响应时间会变慢；12、重要资料，如密码未加密存放（包括配置文件中的密码），或其它存在安全性隐患的；13、硬件或通讯异常发生恢复后，系统不能自动正常继续工作（需要过多的人工干预才行）；14、系统兼容性差，与其它支持系统一起工作时容易出错，而没有充分理由说明是由支持系统引起的；或者由于使用了非常规技术或第三方组件造成不能使用自动化测试工具进行测试的。
敏捷软件开发的三重迭代模型1概述如今随着信息化时代的发展，软件的需求量不断增加，软件开发方法也一直处在不断发展的过程中。
在众多的方法中，敏捷软件开发凭借其以人为核心，快速迭代，及时响应客户需求的特征，成为众多高效团队的胜利之道。
敏捷软件开发有多种，包括SRCRUM，特征驱动软件开发（FDD），自适应软件开发（ADP）以及极限编程（XP）等。
这些方法都有以下主要特征：1.1迭代计划迭代是周期性较小的交付，从而实现用户的一些需求，在每次迭代结束时，会给客户演示迭代生成的系统，以得到他们的反馈。
1.2用户反馈需求的具体细节很可能随时间而改变，尤其在客户看到集成到一起的系统。
有用户的反馈，再把反馈之后的需求集成到产品，这会避免很多无用功以及对需求的曲解。
1.3持续集成和测试驱动开发开发人员每天会迁入他们的代码并集成，频繁的集成帮助项目在早期发现项目的风险和质量问题，还可以在任何时间发布可以部署的软件。
测试驱动开发有助于编写简洁可用和高质量的代码，有利于重构并加速开发过程。
持续集成和测试驱动开发是迭代的基础。
在敏捷团队中，愿景和软件一起演化，每次的迭代，团队需改进系统设计，使设计尽可能适合于当前系统。
这种做法并不是要放弃架构或者设计，而是增量地演化出系统最佳架构和设计方式。
正是敏捷软件开发方法的这些优势，使得越来越多的企业来采用实践。
但随着实践的发展，出现的问题也越来越多。
2问题敏捷软件开发的核心就是以最低的成本、最快速的为客户提供价值。
基于这一优势，越来越多的软件开发企业开始采用敏捷软件开发方法，由于许多企业缺少在软件开发方法研究上的经验，在实施敏捷过程中往往会出现一些问题，从而未能达到预期的目标。
下面总结了一些经典问题。
2.1任务对人依赖问题很多团队在进行任务分派时，由于诸多不合理的任务分解，导致任务分解的粒度较大。
开发过程中，对于大粒度的任务，安排的开发人员需要花费较其他小粒度任务更多的时间，使得其他开发人员已完成手头工作但无法插手到此大粒度任务中，因为这些大粒度的任务具有连续性，从而出现任务对人依赖的现象。
