软件测试小白学习笔记 四

软件测试管理

测试项管理工具

1. Redmine
   · 需求、任务、用例、bug的集成管理
   · 核心思想基于scrum
   · 完善计划、发布、文档、待办等功能
   · 支持多项目
   · 灵活的基于角色的访问控制
   · 问题跟踪系统
   · 甘特图和日历
   · 新闻文档和文件管理
   · feeds和邮件通知
   · 项目wiki
   · 项目论坛
2. JIRA
   · JIRA也可以定义为Professional Issue Tracker，即它是一个专业的问题跟踪管理软件，相似的有：Bugzilla、Trac、Mantis、Clear Quest、Streber等。
3. Topo
   · Topo集成任务、缺陷、文档、代码，集成企业树形组织架构，企业域账号，提供高效易用的本地部署企业级项目管理解决方案，Topo提供了研发型团队的基本常用功能。
   · 轻量项目管理，关注任务、缺陷、文档、代码
   · 层级项目管理，契合企业组织架构
   · 多项目数据汇总对比，量化项目管理
   · 完整任务、缺陷流程，高效看板
   · subversion集成，随时进行代码浏览和检视
   · 海量文档管理，桌面FTP集成轻松访问文档
   · 项目讨论、项目实时沟通更便捷
4. 禅道
   基于scrum，有开源版、专业版、企业版，集产品管理、项目管理、测试管理、人员管理为一体的多版本管理软件。核心的三种角色：产品经理、研发团队和测试团队。通过需求进行合作，产品经理整理需求，研发团队实现任务，测试团队保障质量。
   敏捷开发（Agile），scrum是敏捷开发多种方式中比较流行的一种。
   测试是独立的、迭代的测试，即只要测试条件成熟，测试准备活动完成，测试的执行活动就可以展开。

软件测试需求分析的方法

1. 根据软件开发需求说明书逐条列出软件开发需求，并判断其可测试性。
2. 形成可测试的描述并界定出测试范围。
3. 根据质量标注，逐条制定质量需求，即测试通过的标准。
4. 分析测试执行时需要实施的测试类型。
5. 建立需求跟踪矩阵，并输入测试需求管理系统，对测试需求实施严格有效的管理。

软件测试需求分析结果的评审

• 评审内容：包括完整性检查和准确性检查。
• 评审方法：相互评审；交叉评审；轮查（分配审查）；走查；小组评审。

软件测试需求管理内容

（1）变更管理
变更的主要任务：
· 分析变更的必要性和合理性，确定是否实施变更。
· 记录变更信息，提交变更申请。
· 做出更改。
· 修改相应的软件测试工作，如更新测试用例等。
· 评审后，正式发布新版本的软件测试需求说明书。
（2）状态管理
状态有以下几种：
Open、Analyzed、Reviewed、Resolved、Passed、Unresolved、Closed、Cancel、Failed。
（3）文档版本管理
记录下每次编辑的增量，必要时可以进行回滚。
（4）跟踪管理
跟踪一个软件测试需求使用期限的全过程，包括正向跟踪和逆向跟踪。

测试计划管理

1. 测试计划Testing Plan 描述了要进行的测试活动的范围、方法、资源和进度的文档。
2. 对整个信息系统应用软件组装测试和应用测试。
3. 确定测试项、被测特性、测试任务、谁执行任务以及各种可能的风险。

缺陷基本属性

（1）缺陷标识（ID），追踪缺陷。
（2）缺陷状态（Status），缺陷修复过程进展情况。
（3）缺陷标题/概要（Summary），记录缺陷位置、缺陷结果，最好少于50字。
（4）缺陷详细描述（Description），简洁、准确、完整、可重现，揭示错误实质，菜单、错误信息用双引号“”，按钮用【】；
（5）缺陷严重程度（Severity），缺陷对产品使用的影响程度；
（6）缺陷优先级（Priority），被修复的紧急程度；
（7）缺陷所属项目/模块（Subject），精准定位；
（8）缺陷提交人（Detected By）
（9）缺陷提交时间（Detected Date）
（10）缺陷处理人（Assigned To）
（11）测试版本（Detected in Version）

缺陷再现步骤

（1）用什么账号、权限，登录程序；
（2）功能菜单导航，打开一级菜单->打开二级菜单->····；
（3）缺陷详细描述，建议，附图，预期结果。

缺陷类型

（1）功能问题：软件功能未实现或实现不完整、不正确等情况下的缺陷；
（2）界面问题：用户操作界面中存在的不合理、不正确、不美观等方面的缺陷；
（3）验证问题：提示的错误信息，不适当的数据验证等缺陷；
（4）算法问题：由算法问题引起的缺陷；
（5）易用性问题：用户操作使用过程中存在的不符合使用习惯或操作复杂等方面的缺陷；
（6）兼容性问题：系统在不同的测试环境中产生的缺陷；
（7）性能问题：系统性能未达到性能需求所要求的各项指标；
（8）安全性问题：系统存在安全方面的隐患一类的缺陷；

缺陷严重程度

缺陷严重程度	描述
A-致命	1.造成系统或程序崩溃、死机、系统挂起、非法退出； 2.严重数值计算错误，造成数据丢失，主要功能完全丧失 3.存在安全性与保密性问题：如代码错误、死循环、发生死锁、与数据库连接错误或数据通讯错误，未考虑异常操作、功能错误等。
B-严重	1.主要功能部分丧失，数据不能保存，次要功能完全丧失； 2.导致模块功能失效或异常退出：如致命的错误声明，程序接口错误，数据库的表、业务规则、缺省值未加完整性等约束条件。
C-一般	1.次要功能没有完全实现但不影响使用； 2.界面严重错误与需求不一致； 3.输入未做限制：如提示信息不太准确，或用户界面差，操作时间长，模块功能部分失效等，打印内容、格式错误，删除操作未给出提示，数据库表中有过多的空字段等。
D-建议	1.使用户操作不方便或遇到麻烦，但它不影响功能的操作和执行； 2.对测试对象的改进意见或测试人员提出的建议、质疑：如错别字、界面不规范（字体大小不统一，文字排列不整齐，可输入区域和只读区域没有明显的区分标志），辅助说明描述不清楚，长时间操作未给用户提示，提示窗口文字未采用行业专业术语等。

缺陷优先级

缺陷优先级	描述
A-最高	软件的主要功能错误或造成软件崩溃，数据丢失的缺陷，或用户重点关注的问题，缺陷导致系统几乎不能使用或者测试不能继续，需立即修复。
B-中等	影响软件功能和性能的一般缺陷，严重影响测试，需要优先考虑。
C-一般	界面设计与需求不一致，提示信息错误等。
D-最低	属于优化，可以不做修改的问题或暂时无法修复但影响不大的问题。

缺陷状态

缺陷状态	描述
New（新的）	bug提交到缺陷库中会自动的被设置成New状态。
Open（已打开）	当一个bug被认为New之后，测试负责人或开发负责人将确认这是否是一个bug，如果是，就将这个bug指定给某位开发人员处理，并将bug的状态设定为“Open”，开发人员开始处理bug，“Open”表示开发人员正在处理这个bug。
Fixed（已修复）	当开发人员进行处理（并认为已经解决）之后，就可以将这个bug的状态设置为“Fixed”。
Reopen（再次打开）	如经过再次测试发现bug仍然存在，测试人员将bug再次转给开发组，将bug的状态设置为“Reopen”。
Closed	测试人员经过再次测试后确认bug已经被解决，将bug的状态设置为“Closed”。
Rejected（被拒绝）	测试负责人或开发负责人查看状态为“Open”的bug，如果发现这是产品说明书中定义的正常行为或者经过与开发人员的讨论之后认为这并不能算作bug的时候，测试负责人或开发负责人就将这个bug的状态设置为“Rejected”。

禅道使用教程

禅道