一，软件缺陷

软件缺陷的定义

IEEE 1983 of IEEE Standard 729中对软件缺陷作了一个标准的定义：从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题；从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。因此软件缺陷就是软件产品中所存在的问题，最终表现为用户所需要的功能没有完全实现，没有满足用户的需求。

软件缺陷是指存在于软件（程序、数据、文档）中的那些不符合用户需求的问题

软件未达到需求规格说明书表明的功能

软件出现了需求规格说明书指明不会出现的错误

软件的功能超出了需求规格说明书指明的范围

软件未达到需求规格说明书虽未指明而应该达到的目标

软件测试人员认为软件难以理解、不易使用、运行速度慢、或者最终用户认为不好

补充: 软件缺陷(Defect)，常常又被叫做Bug

软件缺陷示例

计算器说明书一般声称该计算器将准确无误地进行加、减、乘、除运算。如果测试人员或用户选定了两个数值后，随意按下了“+”号键，结果没有任何反应。——>软件未达到软件需求规格说明书表明的功能

若在进行测试时，发现除了规定的加、减、乘、除功能之外，还能够进行求平方根的运算，而这一功能并没有在说明书的功能中规定。——>软件的功能超出了软件需求规格说明书指明的范围

若在测试过程中发现，因为电池没电而导致了计算不正确，但软件需求规格说明书未能指出在此情况下应如何进行处理。——>软件未达到软件需求规格说明书未指明而应该达到的目标

假如计算器说明书指明计算器不会出现崩溃、死锁或者停止反应，而在用户随意按、敲键盘后，计算器停止接受输入或没有了反应。——>软件出现了软件需求规格说明书指明不会出现的错误

测试人员或最终用户发现计算器某些地方不好用，比如，按键太小、显示屏在亮光下无法看清等。——>软件测试人员认为软件难以理解、不易使用、运行速度慢，或者最终用户认为不好

软件缺陷的表现形式

功能、特性没有实现或部分实现。

设计不合理，功能特性不明确，逻辑不清楚或存在矛盾。

产品实际结果和所期望的结果不一致。

没有达到需求规格说明书所规定的性能指标等。

运行出错，包括运行中断、系统崩溃、界面混乱等。

数据不正确、精度不够、不完整或格式不统一。

用户不能接受的其他问题，如存取时间过长、界面不美观。

硬件或系统软件上存在的其他问题

软件缺陷的产生原因

软件缺陷产生是不可避免的，造成软件缺陷产生的原因主要归纳如下:

需求解释或者记录错误

用户需求定义错误

设计说明存在错误

编码说明、程序代码有误

硬件或者软件系统上存在错误

其他，如文档错误、内容不正确或拼写错误

软件缺陷的根源

- 交流不充分

    - 客户与开发人员、开发人员与测试人员等

- 软件的复杂性

    - 功能复杂、开发复杂、测试复杂

- 开发人员的错误

    - 对需求的理解、开发压力、能力与经验

- 需求的变化

    - 需求说明书、设计文档、程序的变更

- 进度压力

    - 项目周期比较紧

软件缺陷修复的

软件缺陷修复的费用

软件缺陷的信息

为了便于缺陷的定位、跟踪和修改，要对所发现的缺陷，按照缺陷的严重程度、优先级、发现阶段、修复阶段、缺陷的性质、所属功能模块、系统环境等方面进行分类和统计。

软件缺陷分类——缺陷状态

软件缺陷的信息

软件缺陷分类——缺陷所属模块

软件缺陷分类——严重程度

软件缺陷分类——优先级

开发人员拒绝修改的缺陷

程序员无法重现或者现象难以捕捉

没有明确的报告以说明重现缺陷的步骤

程序员无法读懂的缺陷报告

用户很少使用或者不符合用户使用习惯的操作出错

由不受信任的测试人员提出

缺陷修改说明

陷修改说明

不是所有缺陷都会修改

市场的压力使得产品最终发行有时间限制

测试人员错误理解或者不正确操作引出的缺陷(FAQ)

错误的修改影响的模块较多，带来的风险较大(遗留)

修改性价比太低

缺陷报告中提出的问题很难重现

报告缺陷的重要性

软件缺陷的描述是软件缺陷报告的基础部分，需要使用简单、准确、专业的术语来描述缺陷。否则，它就会含糊不清，可能会误导开发人员，影响开发人员的效率，也会影响测试人员自身的声誉，准确报告缺陷是非常重要的。

- 清晰准确的软件缺陷描述可以减少开发人员退回来的缺陷数量，可以节省开发人员和测试人员的时间。

- 提高软件缺陷修复的速度，使项目组能够有效地工作。

- 提高测试人员的可信任程度，可以得到开发人员对有效缺陷的及时响应。

- 加强开发人员、测试人员和管理人员的协同工作，让他们更好的工作。

缺陷的书写规范    

-标题：应保持简短、准确，提供缺陷的本质信息

    - 尽量按缺陷发生的原因与结果的方式书写；

    - 避免使用模糊不清的词语，例如：“功能中断，功能不正确，行为不起作用”等。应该使用具体文字说明缺陷的症状；

    - 为了便于他人理解，避免使用俚语或过分具体的测试细节。

- 复现步骤：应包含如何使别人能够很容易的复现该缺陷的完整步骤。

    - 为了达到这个要求，复现步骤的信息必须是完整的、准确的、简明的、可复现的。常见问题：

        - 包含了过多的多余步骤，且句子结构混乱，可读性差，难以理解；

        - 包含的信息过少，丢失了操作的必要步骤；

- 复现步骤的正确书写方式：

    - 提供测试的环境信息；

    - 简单地一步步引导复现该缺陷，一个步骤包含的操作不要多；

    - 每个步骤前使用数字对步骤编号；

    - 尽量使用短语或短句，避免复杂句型句式；

    - 复现的步骤要完整、准确、简短；

    - 将常见步骤合并为较少步骤；

    - 按实际需要决定是否包含步骤执行后的结果。

- 实际结果：是执行复现步骤后软件的现象和产生的行为。

    - 实际结果的描述应向标题信息那样，要列出具体的缺陷症状，而不是简单地指出“不正确”或“不起作用”。

- 避免常见的错误：

    - 避免使用我、你等人称代词，可以直接使用动词或必要时使用“用户”代替

    - 避免使用情绪化的语言和强调符号；

    - 避免使用诸如“似乎”、“看上去可能”等含义模糊的词汇，而需要报告确定的缺陷结果；

    - 避免使用自认为比较幽默的语句，只需客观地描述缺陷的信息；

    - 避免提交不确定的测试问题，自己至少需要重现一次再提交。

- 反面的示例：

    - 上海人：哪能查询到的结果和查询条件不搭噶的。

    - 北京人：哥们好不容易输入一堆个人详细信息后，点击保存后全瞎了。

缺陷报告

缺陷处理流程

缺陷跟踪

-新提交的缺陷为新建状态，确认有效后为打开状态，经开发人员修改后，缺陷变为已修复（待验证）状态。此时就需要测试人员对缺陷进行回归测试，验证问题是否修复。

    - 如果问题仍然存在，则测试人员将该缺陷的状态修改为重新打开；

    - 如果问题已经修复，则测试人员将该缺陷的状态置为关闭状态（验证通过），同时添加回测说明如“该缺陷已解决”。

- 还有一种情况：开发人员认为缺陷在当前版本可以暂不修改，而考虑在后续版本中再做修正，缺陷的对应状态为延期。

    - 对于这种情况，项目负责人应召集开发人员、测试人员和其他项目相关人员进行讨论，如果讨论结果为同意则延期，如果不同意，则重新打开缺陷。

缺陷统计

- 对软件问题的功能域分布进行分析，找出系统的薄弱环节。

    - 要详细采集每个功能模块或系统构件的缺陷数据，并按功能、错误类型、严重程度等分类。

    - 二八定理：80%的软件问题总是发生在大约20%的功能模块中。

- 对缺陷的注入阶段的分布进行分析，并与历史数据相比较。应按不同的开发阶段详细采集缺陷的数据。

- 应对软件缺陷类型进行分析，以便针对各自的特点，先修复严重缺陷。

- 应动态采集每个测试周期中发现的缺陷数，并有效地控制缺陷的修复率。

- 应密切观察缺陷的状态，并及时跟踪其状态的变化，以检查测试和开发人员的工作情况。

bug统计

缺陷密度

- 基本的缺陷测量是以每千行代码的缺陷数(个/KLOC)来测量的。称为缺陷密度，其测量单位是defects／KLOC。可按照以下步骤来计算一个程序的缺陷密度：

    - 累计开发过程中每个阶段发现的缺陷总数。

    - 统计程序中新开发的和修改的代码行数。

    - 计算每千行的缺陷数=1000*缺陷总数/代码行数。

- 例如

    - 一个29.6万行的源程序总共有145个缺陷，则缺陷密度为：

        - 缺陷密度＝1000*145/296000=0.49  个／KLOC。

缺陷分析

- 1）缺陷数据分析关注的问题

- 2）缺陷数据分析的重要性

- 3）缺陷数据分析的数据指标

缺陷数据分析关注的问题

- 正在测试的软件哪个模块的问题最多

- 测试人员中谁报告的软件缺陷最多

- 各类缺陷所占的数量百分比分别是多少

- 开发人员能及时修复软件缺陷吗

- 开发人员一次正确修复缺陷的百分比是多少

- 正在开发的软件能否在计划的时间内正常发布

缺陷数据分析的重要性

    - 统计未修复的缺陷数目（特别是严重性高的缺陷），预计软件是否可以如期发布。

    - 分析缺陷的类型分布，发现存在较多缺陷的程序模块，找出原因，进行软件开发过程改进。

    - 根据测试人员报告缺陷的数量和准确性，评估测试有效性和测试技能。

    - 根据报告的缺陷修复是否及时，改进软件开发与测试的关系，使测试与开发更有机的配合。

缺陷数据分析的数据指标

- 每天/周报告的新缺陷数目；

- 每天/周修复的缺陷数；

- 累计报告的缺陷数目；

- 累计修复的缺陷数；

- 不同严重性类型的缺陷数；

- 程序模块与发现的缺陷的对应关系

- 色彩

    - 色彩的搭配无序、混乱是软件图形界面设计的大忌，图形界面应尽量设计得温和些。这类缺陷主观类强，个人美感占据主动，所提交的缺陷一般严重程度不可定得太高。

- 例如:

    - 整体页面色彩单调，无变化，仅使用一种色彩，且篇幅较大，可提交建议性的缺陷，即使是简单的界面，宁可采用无色，也不可使用鲜艳的单色，如红色，黄色、绿色等。

    - 背景色与界面字体色彩相近，不能清晰区分，色彩搭配混乱、复杂，且不符合软件标准。

功能结构布局

- 功能结构布局主要从界面的功能区域划分来考虑。相同的、类似的功能应该放在邻近的区域。

- 例如:

    - 记录添加功能界面，添加按钮未放在醒目的位置；

    - 导航功能位于界面的右则；

    - 整体功能区域分布混乱；

图片

- 图片选用不合理，与当前软件类型不符，无法正确体现当前界面功能性含义。图片不规范、不清晰。

- 例如:

    - 图片色彩过于艳丽或黯淡，模糊不清；

    - 图片变形；

    - 图片不符合当前界面的主题，图片与描述性文字不符；

页面大小

- 在B/S结构的软件系统中，当一个页面元素太多，未作精简时，在打开该页面时可能需要较长的加载时间，这对于软件性能是一个不小的影响，既增加了服务器的压力，又容易引起用户的反感。

- 例如:

    - 图片未经压缩、格式不正确。比如采用BMP；

    - 代码冗余，存在太多无用代码；

    - 页面元素太多，太过复杂；

字体

- 字体在软件界面中尤其重要，字体的使用要符合软件开发规范。

- 例如:

    - 字体过大，与其他页面信息脱节，无法形成主体；

    - 字体过小，无法看清楚；

    - 字体不符合当前界面风格；

窗体大小

- 窗体的设计要有层次感，父窗口、子窗口应该有所区别。窗口不应该有太多空白处，功能区域充实。

- 例如:

    - 窗口太大，功能按钮分散，间隔太大；

    - 窗口太小，功能按钮过于集中，间隔太小，或控件显示不全；

    - 弹出窗口未能定于屏幕居中位置；

界面文字

- 页面信息描述不清楚，有语病，错别字。简单语言复杂化，描述不正确，不符合当前页面。错误的帮助信息，乱码等。

容错处理(功能缺陷)

- 容错处理在软件系统中占据十分重要的地位。所谓容错，就是容忍错误的能力。当用户在使用软件过程中发生错误后，软件应该能给出引导信息，指应用户进行正确的操作。

- 例如:

    - 用户输入错误，系统无提示，无响应，用户不能清晰知道系统不处理的原因；

    - 给出信息提示，用户接受后无法继续操作，不给用户“改过自新”的机会；

    - 用户输入不合法的信息后，系统给出提示，用户确定后，系统仍能处理错误的信息。

    - 取消功能不能取消，比如删除，系统给出提示，是否确定删除，用户否认后仍执行了删除。

数据转换

- 软件中的功能主体一般由等组成。

- 例如:增加、修改、删除、查询

    - 无法增加记录，比如点击新增，页面自动关闭。

    - 增加记录后无显示，但提示增加成功；

    - 增加记录后显示不正确，显示为乱码，信息显示不全。

    - 增加记录后多出记录；

    - 无法修改记录；

    - 修改后不能自动更新，需手工更新；

    - 无法删除记录，无法全部删除；

    - 删除不成功，但相应的记录已被删除；

    - 无法查询、查询结果错误；

性能缺陷

- 这里所说的性能问题不需专业的工具就能发现的问题，这类问题在平常做黑盒测试的时候就能发现。

- 例如:

    - 打开文档，10秒应该可以完成的，却花了3分钟；

    - 启动软件，CPU长时间100%，内存消耗过多；

    - 5个用户可以正常使用，20个用户使用时系统崩溃；

    - 打开一个登录页面花了1分钟；

    - 完成一个查询功能，花了2分钟；

不同软件组织的缺陷管理过程

个体行为

- 处于CMM第一级（或称为初始级）的软件组织，对软件缺陷的管理无章可循。工程师们只是在发现缺陷后，修改相应的软件。通常，没有人会去记录自己发现的缺陷。也没有人知道在新的软件版本里，究竟纠正了哪些缺陷，还有哪些缺陷未被纠正。而且，只有在下一轮测试中才有可能知道那些所谓已被纠正了的缺陷是否真的被纠正了，更重要的是纠正过程是否引入了新的缺陷。

- 所以这样的软件组织的项目交货期（Release Date）表现出强烈的不可预测性。并且， 为了获得一个高质量的软件产品（如果能够的话），通常要在测试上花费大量的人力。

项目行为

- 在CMM第二级（或称为可重复级）的软件组织中，软件项目会从自身的需要出发，制定本项目的缺陷管理过程。一个完备软件缺陷管理过程通常会包括如下几个方面：

    - （1）提交缺陷

    - （2）分析和定位缺陷

    - （3）提请修改相应的软件

    - （4）修改相应的软件

    - （5）验证修改

- 项目组会完整地记录开发过程中的缺陷，监控缺陷的修改过程，并验证修改缺陷的结果。

组织行为

- CMM第三级（或称为已定义级）的软件组织会汇集组织内部以前项目的经验教训，制定组织级的缺陷管理过程。并且，要求项目根据组织级的缺陷管理过程定制本项目的缺陷管理过程。

- 从而，整个软件组织中的项目都遵循类似的过程来管理缺陷。好的缺陷管理实践成为所有项目的实践，而教训也为所有项目所了解。更重要的是，随着组织的不断发展完善，组织的过程会得到持续性的改进，所有项目的过程也都会相应的改进。

持续优化

- 与CMM第四级相比，CMM第五级（或称为持续优化级）更强调对组织的过程进行持续性改进，从而使过程能力得到不断的提升。

- 就缺陷管理而言，软件组织应当在量化理解其过程能力的基础上，持续地改进组织级的开发过程、缺陷发现过程，引入新方法、新工具，加强经验交流，从而实现缺陷预防（Defect Prevention）。

- 缺陷预防的着眼点在于缺陷的共性原因（Common Cause）。通过找寻、分析和处理缺陷的共性原因，实现缺陷预防。

- http://www.jira.cn/secure/Dashboard.jspa

三、SVN使用指南

问题与案例

[if !supportLists]l [endif]电脑发生故障，文件没有备份而丢失了

[if !supportLists]l [endif]由于人员离职，导致某些资料丢失了

[if !supportLists]l [endif]我怎么知道手头的公共资料是不是最新版呢？

[if !supportLists]l [endif]想要追溯几个月前的某个状态，却发现那个版本的文件已经被当作垃圾删除了

[if !supportLists]l [endif]每天要花费很多时间来向别人提供需要共享的资料

[if !supportLists]l [endif]相似的应用系统，每次都重复开发，难以复用

[if !supportLists]l [endif]一个软件被用于多个项目，发现其中存在一个BUG，所有这些项目都要进行修复

[if !supportLists]l [endif]人员分布在两地开发，版本如何同步

[if !supportLists]l [endif]甲乙两人为不同目的修改了同一份文件，乙的提交在甲提交之后，导致甲修改的内容丢失了

SVN简介

[if !supportLists]l [endif]一个开源的版本管理软件

[if !supportLists]l [endif]可架设在Apache上，最常用的客户端为TortoiseSVN（简称TSVN）

应用环境

[if !supportLists]l [endif]服务器端：CollabNet的SVN服务器端安装包（内含Apache2.2）

[if !supportLists]l [endif]推荐使用TortoiseSVN（以下简称TSVN）

[if !supportLists]l [endif]可通过TSVN进行读、写操作

[if !supportLists]l [endif]可通过IE浏览器进行读操作

[if !supportLists]l [endif]可通过各种插件与开发工具集成

客户端安装

客户端安装(一)

[if !supportLists]l [endif]安装文件

    - SVN客户端：TortoiseSVN-1.6.8.19260-win32-svn-1.6.11.msi

    - TSVN中文语言包：LanguagePack_1.6.8.19260-win32-zh_CN.msi

[if !supportLists]l [endif]全部选择默认安装，安装完成后重启电脑

[if !supportLists]l [endif]TSVN通过右键菜单与Windows资源管理器集成，没有自己的窗口界面

客户端安装图解

- 安装TortoiseSVN

- 安装LanguagePack中文包

- 重启电脑

- 设置中文

TSVN右键菜单

TSVN图标

创建版本库

- 在SVN服务器端操作

    - 在相应文件夹内新建一个文件夹，用于存储数据

    - 在新建文件夹上点右键，选择“TortoiseSVN－在此创建版本库”，TSVN会在此文件夹内建立若干控制文件

检出

[if !supportLists]l [endif]“检出”用于客户端第一次从SVN服务器上下载版本库数据

[if !supportLists]n [endif]在客户端新建一个文件夹用于存放下载的数据

[if !supportLists]n [endif]在新建文件夹上点右键，选择“SVN检出…”

[if !supportLists]n [endif]在弹出窗口的“版本库URL”处填入版本库的访问地址

[if !supportLists]n [endif]点“确定”开始从SVN服务器下载数据

提交

[if !supportLists]l [endif]“提交”用于将客户端的改动上传到SVN服务器

[if !supportLists]- [endif]在受SVN控制的某层文件夹上（或文件夹内空白处，或某文件上）点右键，选择“SVN提交…”

[if !supportLists]l [endif]TSVN自动检查该文件夹客户端的改动，并将其列在弹出窗口的“变更列表”栏

[if !supportLists]l [endif]在弹出窗口的“信息”栏写上对此次提交的注释，以便将来追溯

[if !supportLists]l [endif]点击“确定”将客户端的改动上传到服务器

假设这个时候程序员B检出内容，就会发现有程序员A提交的内容

程序员C一样可以检出内容

更新

[if !supportLists]l [endif]“更新”用于客户端从SVN服务器下载最新版本

[if !supportLists]n [endif]在受SVN控制的某层文件夹上（或文件夹内空白处）点右键，选择“SVN更新”，TSVN自动比较该文件夹客户端与服务器的版本差异，并下载最新版本到客户端

增加

[if !supportLists]n [endif]n直接在受svn控制的文件夹中添加想要上传的文件，然后右键选择“提交”即可；

删除

[if !supportLists]n [endif] “删除”仅是对客户端的文件进行操作，并不改变服务器上的内容，需要执行“提交”操作才会将删除操作上传到服务器

[if !supportLists]n [endif]将“删除”操作“提交”到服务器后，仅是从服务器的最新版本中删除了此文件或文件夹，在历史版本中仍可找回此文件或文件夹

改名

[if !supportLists]l [endif]“改名”用于在受SVN控制的状态下，对文件或文件夹改名

    - 在受SVN控制的某层文件夹或文件上点右键，选择“TortoiseSVN－改名”

[if !supportLists]l [endif]“改名”仅是对客户端的文件进行操作，并不改变服务器上的内容，需要执行“提交”操作才会将改名操作上传到服务器

[if !supportLists]l [endif]不要用Windows“重命名”来实现改名，因为这个操作不受SVN控制，SVN会将其理解为删除原文件、增加一个新文件，从而导致文件改名后不能跟踪到改名前的状态

移动

[if !supportLists]l [endif]“移动”用于在受SVN控制的状态下，移动文件或文件夹的位置

[if !supportLists]n [endif]在受SVN控制的某层文件夹或文件上点右键，选择“TortoiseSVN－版本库浏览器”

[if !supportLists]n [endif]在弹出窗口拖动文件夹或文件到需要的位置

[if !supportLists]n [endif]由于是对服务器版本库直接操作，移动后将自动执行一次“提交”操作

[if !supportLists]n [endif]移动完成后需要在客户端执行一次“更新”，以下载最新状态

- 不要用Windows的拖动操作或“剪切”、“粘贴”来实现移动，因为这些操作不受SVN控制，SVN会将其理解为在原位置删除文件、在新位置增加文件，从而导致文件移动后不能跟踪到移动前的状态

更新至版本

- “更新至版本”用于取出文件的某历史版本

    - 在受SVN控制的某层文件夹或文件上点右键，选择“TortoiseSVN－更新至版本…”

    - 在弹出窗口中填写要取的版本号，点“确定”取回该版本