缺陷管理

什么是 Mantis MantisBT is a free popular web-based bugtracking system (feature list). It is written in the PHP scripting language and works with MySQL, MS SQL, and PostgreSQL databases and a webserver. MantisBT has been installed on Windows, Linux, Mac OS, OS/2, and others. Almost any web browser should be able to function as a client. It is released under the terms of the GNU General Public License (GPL). Mantis 是一个 BUG 管理系统。主要特点如下： 1、 用 php 写的系统，安装方便，不用像 bugzilla 那样安装那么多 perl 支持； 2、 系统相对简单轻磅，使用简单； 3、 出色的多语支持，对于对日开发等公司非常合适； 界面图示： 在线演示地址： http://www.futureware.biz/mantisdemo 环境搭建及 Mantis 安装、配置 由于

一、测试过程之需求分析 　　测试介入阶段一般从需求分析开始，需求分析阶段是整个软件生命周期最关键的一环，产品、研发、测试三方对产品需求理解应做到一致，所以需求评审会尤其重要，所以一般会先进行一次需求评审，如果有异议的，不确定的点，产品需要修改，周知大家，或者再次进行一次需求评审。 　 　 需求阶段需要产出： 　需求文档规格书、产品原型图、详细设计说明书等，建议测试人员做到专业，在每个环节都严格把控，保证项目整体的质量。 二、测试过程之测试计划、测试方案 　　测试计划大多为测试组长编写，主要包含测试目标、测试资源、测试策略、测试需求（功能、接口、自动化、性能、安全、兼容性）、测试进度计划，根据项目总体排期表，制定出测试排期与人员安排计划。 　　测试方案为具体实施的方案，主要包含测试需求细化、自动化测试设计、性能场景抽离、测试数据和测试脚本、测试用例设计等。 三、测试用例编写 　　测试需求评审通过、测试计划、方案制定好后，便可进行测试用例编写工作了，可根据详细需求文档、开发设计文档、输出用例脑图或者测试用例，最好测试点细化，在测试用例中，包括测试数据验证点。 四、测试用例执行 根据测试用例，进行执行，在过程中也可以开展探索式测试，随机测试等，扩大测试范围。 五、测试过程之缺陷管理 　　缺陷的管理每个公司都有自己的管理平台，合理的管理缺陷、分析缺陷不仅可以提高产品质量还可以提高工作效率。

转载自：http://www.cnblogs.com/snooper/archive/2009/09/07/1561715.html 搭建 Mantis 缺陷管理系统 By Snooper 错误必有！欢迎指正！ 什么是 Mantis MantisBT is a free popular web-based bugtracking system (feature list). It is written in the PHP scripting language and works with MySQL, MS SQL, and PostgreSQL databases and a webserver. MantisBT has been installed on Windows, Linux, Mac OS, OS/2, and others. Almost any web browser should be able to function as a client. It is released under the terms of the GNU General Public License (GPL). Mantis 是一个 BUG 管理系统。主要特点如下： 1、 用 php 写的系统，安装方便，不用像 bugzilla 那样安装那么多 perl 支持； 2、

判断题 软件测试就是为了验证软件功能实现的是否正确，是否完成既定目标的活动，所以软件测试在软件工程的后期才开始具体的工作。 （初级） （ × ） 发现错误多的模块，残留在模块中的错误也多。( √ ) （初级） 测试人员在测试过程中发现一处问题，如果问题影响不大，而自己又可以修改，应立即将此问题正确修改，以加快、提高开发的进程。（ × ）（初级） 单元测试通常应该先进行“人工走查”，再以白盒法为主，辅以黑盒法进行动态测试。 （ √ ）（中级） 功能测试是系统测试的主要内容，检查系统的功能、性能是否与需求规格说明相同。（ √ ）（中级） 软件质量管理即QM由QA和QC构成，软件测试属于QC的核心工作内容。（√）（高级） 软件测试只能发现错误，但不能保证测试后的软件没有错误。(√) 软件就是程序。(X) 测试只要做到语句覆盖和分支覆盖，就可以发现程序中的所有错误。(X) I18N测试是指对产品做出具有国际性的规划，而L10N测试则是指对软件做出符合本地需求更改工作。（√）【高级】 （ × ）用黑盒发测试时，测试用例是根据程序内部逻辑设计的。 （ √ ）白盒测试是基于对程序控制结构了解的基础上来设计测试用例的。 （ × ）测试是为了验证软件正确的实现了用户需求。 （ √ ）确定测试主要测试软件功能是否满足用户的合理需求，以“需求规格说明书”为测试依据。 （ √ ）软件测试时经常要输入无效的

什么是软件？ 软件是计算机系统中与硬件相互依存的另一部分， 软件包括程序+文档 什么是软件测试？ （1）软件测试是在现有软件（程序+文档）中寻找缺陷的过程； （2）软件测试是指使用人工或者自动化手段来运行或测试某个系统的过程，目的是检验系统是否满足需求规格说明书中的要求 软件测试的目的？ 测试的目的是找出软件产品中的错误，使软件尽可能的符合用户的要求。 黑盒测试： 又叫功能测试，把程序看成一个黑盒子，完全不考虑程序的内部结构和处理过程，根据规格说明书，通过操作软件验证程序的功能是否与规格说明书规定的一致。 白盒测试： 也称结构性测试，是基于代码的测试，按照程序内部的逻辑结构，检测程序是否能按预定要求进行正确的工作。 回归测试： 回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。 冒烟测试： 是指在对一个新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性，冒烟测试又称版本验证测试。冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件的基本功能正常，可以进行后续的正式测试工作。 简单地说，冒烟测试就是用较少的人，在较短的时间内测试程序的主要功能，如果通过再进行正式的测试。 aplha测试和bate测试的区别？ Alpha测试(α测试)： 通常也叫“验证测试”，主要是指在软件开发完成以后

1.什么是软件测试? 答:软件测试是 为了发现错误而执行程序的过程 。或者说，软件测试是 根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例 (即输入数据及其预期的输出结果)，并利用这些测试用例去运行程序，以发现程序错误的过程。（1.验证程序正常运行 2.验证满足用户需求 3.发现缺陷） 2. 软件测试的目的? 答;测试的目的是想 以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷 ，通过修正错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患带来的商业风险。 3.什么是需求文档测试？ （主要测试需求中是否存在逻辑矛盾以及需求在设计上是否可以实现） 1、需求文档是否符合用户需求； 2、需求文档是否符合逻辑； 3、技术上是否能实现； 软件开发过程中，通常会有专门的测试人员，他们首先 会根据需求文档编写测试用例 ，用于指导如何测试，以及那些输入条件预期得到什么结果 4. 什么是设计文档测试? 答:测试设计是否符合全部需求以及设计是否合理 5.什么是 α测试 ? 答:Alpha测试(α测试)是 由一个用户在开发环境下进行的测试 ，也可以是 公司内部的用户在模拟实际操作环境下进行的受控测试 ， Alpha测试不能由程序员或测试员完成 。Alpha测试发现的错误，可以在测试现场立刻反馈给开发人员，由开发人员及时分析和处理。 目的是评价软件产品的功能

接口测试用例和报告模板 当今在测试领域，接口测试已经越来越多的被提及，被重视。 区别于传统意义上的系统级别测试，很多测试人员在接触到接口测试的时候，也许对测试执行还可以比较顺利的上手，但一提到相关的归档，比如测试用例和报告，就有些不知所措了。 今天就用这篇文章来说说接口测试用例和报告。 1.　　接口用例模板 提到测试用例，我们知道，其中最重要的两个要素就是： 测试步骤 预期结果 其实对于接口测试也同样如此；接口测试的步骤中，最重要的是将实现向接口发送预设请求，结果则要关注响应信息及后续处理。 所以接口测试用例编排可以考虑下列两种形式： 要注意的是，实际工作场景中我们可能还会对接口之间的串联和混合场景进行测试。 2.　　测试报告模板 接口测试报告很多时候会和接口性能测试报告一起，如果要单独报告的话，可以考虑以下内容： 2.1　　 系统 接口 概况 简要描述与测试项目相关的一些背景资料，如被测系统简介，项目上线计划等。 对于系统接口的定义和设计做出介绍，比如系统一共有多少个接口？采用哪种协议？都涉及到哪些发送方法？采用怎样的请求格式？使用怎样的返回标准？可用表格说明。 2.2　　 测试目的与范围 描述本次接口测试的目的、范围与目标，内容应与本次接口测试的《接口测试实施方案》中的对应内容保持一致。 2.2.1. 测试目的 本次测试的目的在于确保系统接口功能和逻辑处理已验证，符合

培训内容： 软件质量管理 软件质量 质量成本 不良质量成本 质量管理策略 质量管理措施 建立缺陷预防策略 缺陷预防策略要点 “验证”型缺陷预防策略 “确认”型缺陷预防策略 “产品”型缺陷预防策略 “项目”型缺陷预防策略 “运营”型缺陷预防策略 缺陷预防过程：上层过程 识别业务类型并建立缺陷预防策略 督导缺陷预防策略的实施 评价缺陷预防措施的ROI 持续改进缺陷预防 融合缺陷预防过程和持续改进 缺陷预防过程：下层过程 定制项目缺陷预防目标和策略 预测和规划项目缺陷预防 项目生命周期实施缺陷预防 跟踪缺陷数据 分析缺陷数据 评价项目缺陷预防效果 融合缺陷预防过程和项目过程 缺陷预防技术－质量目标分解 何为质量目标？ 分解质量目标到生命周期过程中 分解质量目标到缺陷类型上 关联质量目标和质量成本 缺陷预防技术－基础规约 缺陷的类型划分 缺陷的粒度划分 BUG的类型和粒度划分 故障的类型和粒度划分 错误的类型和粒度划分 缺陷预防技术－数据指标 缺陷静态指标：分布和比率 缺陷动态指标：趋势和生命周期 缺陷过程指标：注入、漏出和检出 缺陷管理指标：质控ROI 缺陷预防技术－数据分析和过程控制技术 常规分析技术：分布和趋势 控制图技术 Rayleigh分析 ODC分析 Gompertz分析 回归分析 MonteCarlo模拟 实施缺陷预防 缺陷预防是投资，如何管理缺陷预防的ROI？

在 blog 中看到有人写到 web 权限管理的一些文章，这里把我曾经做过的一些权限管理作一下总结，欢迎拍砖。 这里讨论的权限只涉及到信息管理系统里面的权限管理，超出此范围的权限管理暂不涉及。 1 、权限的应用对象 上面我们已经定义了权限的范围，就是信息系统管理里面的表单操作，那么权限的应用对象就是表单，更进一步说，就是表达表单内容的 web 管理页面。 2 、权限的分类 一个页面的权限范围分为以下几种，也可以叫做 基本权限单位 。 l 操作权限 ：操作权限是一种页面级别的权限，也可以叫做页面权限。包括以下几种 n 新增 n 修改 n 删除 n 查询 在此基础上还可以进行更加详细的一些分类，比如查看他人记录的权限，修改他人记录的权限等。这部分也可以使用下面的记录权限来实现。 l 按钮权限 ：针对页面上按钮的权限管理，包括 n 是否可见 n 是否可用 有时候，我们可以把按钮权限看作为字段权限。 l 字段权限 ：字段在页面的不同状态（新增，修改，查询）下面的各种状态管理。包括 n 是否可见 n 是否可修改 l 记录权限 ：记录权限是指用户对某些记录的查看和修改权限。比如客户关系管理系统中，不同界别的系统用户可以看到不同的记录，例如上司可以看他所有下级员工的客户列表等。 3 、权限的实现模型 上面的权限分类大概对涉及到页面元素的权限进行了一个比较全面的概括

2.1软件缺陷管理的目的 　　确保每个被发现的缺陷都能够被有效的解决（注意，这里的解决不一定被修复，也可以是其它的处理方式，如在下一个版本修正或者不修复，但每个Bug 的修复方式必须能在开发组织中达到一致） 2.2软件缺陷的定义 　　一、软件未达到产品说明书中标明的功能 　　二、软件出现了产品说明书中指明的不能出现的功能 　　三、软件功能超出了产品说明书中指明的范围 　　四、软件未达到产品说明书中指明应该达到的目的 　　五、软件测试人员认为软件难以理解和使用，运行速度慢，或最终用户认为不好 2.3软件缺陷严重程度（severity） 描述因缺陷引起的故障对软件产品影响的程度。通常划分为以下几个级别： 2.4软件缺陷优先级 描述缺陷必须被修复的紧急程度 2.5软件缺陷类别 　　1 .界面(UI) ：界面错误，如界面显示不符合需求，提示信息不合规范等； 　　2. 功能(Function) ：系统功能无效、不响应、不符合需求； 　　3. 性能(Rerformance) ：系统响应过慢，无法承受预期负荷等； 　　4. 安全性(Security) :存在安全隐患的缺陷； 　　5. 数据(Data) :数据导入或设置不正确的； 　　6. 其他(Other) ：不在上述类别范围的其它错误。 2.6软件缺陷状态 　　状态用于跟踪缺陷处理过程及当前所处阶段，常用状态有以下情况： 　　1. 提交