作者：林文波
原载：http://lanbolin.spaces.live.com/blog/cns!977E13F16FA9E2B5!768.entry

参考书籍：《
软件配置管理模式
》

作者出处未知。

认识软件缺陷，首先要了解软件缺陷的概念，其次是了解软件缺陷的详细特征，最后就是它的属性了，再高一个层次就是学习利用管理软件缺陷的工具了。
1、首先介绍软件缺陷的概念
软件缺陷是指系统或系统部件中那些导致系统或部件不能实现其功能的缺陷。
2、软件缺陷的详细特征
a、单一准确
b、可以再现（要求软件缺陷具有精确的步骤）
c、完整统一
d、短小简练
e、特定条件
f、补充完整
g、不做评价
3、软件缺陷的属性
软件缺陷的属性包括缺陷标识、缺陷类型、缺陷严重程度、缺陷产生可能性、缺陷优先级、缺陷状态、缺陷起源、缺陷来源、缺陷原因。
下面详细介绍一下以上这些属性：
a、缺陷标识：是标记某个缺陷的唯一标识，可以用数字序号表示；
b、缺陷类型：功能、用户界面、文档、软件包、性能、系统"模块接口
功能：影响了各种系统功能、逻辑的缺陷；
用户界面：影响了用户界面、人机交互特性，包括屏幕格式、用户输入灵活性、结果输入格式等方面的缺陷；
文档：影响发布和维护，包括注释、用户手册、设计文档；
软件包：由于软件配置库、变更管理或版本控制引起的错误；
性能：不满足系统可测量的属性值，如执行时间、事务处理速率等；
系统"模块接口：与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表等不匹配、冲突。
c、缺陷严重程度：致命（Fatal）、严重（Ceritical）、一般（Major）、较小（Minor）
致命：系统任何一个主要功能完全丧失，用户数据受到破坏，系统崩溃、悬挂、死机或者危机人身安全；
严重：系统的主要功能部分丧失，数据不能保存，系统的次要功能完全丧失，系统所提供的功能或服务受到明显的影响；
一般：系统的次要功能没有完全实现，但不影响用户的正常使用。例如：提示信息不太准确或用户界面差、操作时间长等一些问题；
较小：使操作者不方便或遇到麻烦，但它不影响功能过的操作和执行，如个别不影响产品理解的错别字、文字排列不整齐等一些小问题
d、缺陷产生可能性：总是、通常、有时、很少
总是：总是产生这个软件缺陷，其产生的频率是100；
通常：按照测试用例，通常情况下会产生这个软件缺陷，其产生的频率大概是80—90；
有时：按照测试用例，有时候产生这个软件缺陷，其产生的频率大概是30—50；
很少：按照测试用例，很少产生这个软件缺陷，其产生的频率大概是1—5.
e、缺陷的优先级：立即解决、高优先级、正常排队、低优先级
立即解决：缺陷导致系统几乎不能使用或者测试不能继续，需立即修复；
高优先级：缺陷严重，影响测试，需要优先考虑；
正常排队：缺陷需要正常排队等待修复；
低优先级：缺陷可以再开发人员有时间的时候被纠正。
f、缺陷状态：激活或打开、已修正或修复、关闭或非激活、重新打开、推迟、保留、不能重现、需要更多信息
激活或打开：问题还没有解决，存在源代码中，确认”提交的缺陷”，等待处理，如新报的缺陷；
已修正或修复：已被开发人员检查、修复过的缺陷，通过单元测试，认为已经解决但还没有被测试人员验证；
关闭或非激活：测试人员验证后，确认缺陷不存在之后的状态；
重新打开：测试人员验证后，确认缺陷不存在之后的状态；
推迟：这个软件缺陷可以在下一个版本中解决；
保留：由于技术原因或第三者软件的缺陷，开发人员不能修复的缺陷；
不能重现：开发不能再现这个软件缺陷，需要测试人员检查缺陷再现的步骤；
需要更多信息：开发能再现这个软件缺陷，但开发人员需要一些信息，例如缺陷的日志文件、图片等。
g、软件缺陷的起源：需求、构架、设计、编码、测试、用户
在团建生命周期中软件缺陷占的比例：需求和构架设计阶段占54、设计阶段占25、编码阶段占15、其他占6.
h、软件缺陷的来源：需求说明书、设计文档、系统集成接口、数据流（库）、程序代码
需求说明书：需求说明书的错误或不清楚引起的问题；
设计文档：设计文档描述不准确。和需求说明书不一致的问题；
系统集成接口：系统个模块参数不匹配、开发组之间缺乏协调引起的缺陷；
数据流（库）：由于数据字典、数据库中的错误引起的缺陷；
程序代码：纯粹在编码中的问题所引起的缺陷。
i、缺陷根源：测试策略，过程、工具和方法，团队"人，缺乏组织和通讯，硬件，软件，工作环境
测试策略：错误的测试范围，误解测试目标，超越测试能力等；
过程、工具和方法：无效的需求收集过程，果实的风险管理过程，不使用的项目管理方法，没有估算规程，无效的变更控制过程等；
团队"人：项目团队职责交叉，缺乏培训。没有经验的项目团队，缺乏士气和动机不纯等；
缺乏组织和通讯：缺乏用户参与，职责不明确、管理失败等；
硬件：硬件配置不对、缺乏、或处理器缺陷导致算术精度丢失，内存溢出等；
软件：软件设置不对、缺乏，或操作系统错误导致无法释放资源，工具软件的错误，编译器的错误，千年虫问题等；
工作环境：组织机构调整，预算改变，工作环境恶劣，如噪音过大。
4、学会利用管理缺陷的工具
例如TD、bugfree、bugzille等

之前因为答辩论文的事，虽然关注汶川大地震，但是没看过视频资料，内心触动得不深。今天看了台湾赈灾晚会和“以生命的名义赈灾晚会”，真的很感动。地震中的亲情友情和爱情让我感同身受，特别是如老师护学生、敬礼娃娃、黄埔公司老总、唐山十三义士，让我泪流满面，为他们的壮举而钦佩。几年了，都极少流泪，今天都释放了，也终于明白了哭肿了的感觉，也知道了“痛哭流涕”真的可以流鼻涕。

以生命的名义，今生今世，一定要像他们一样，做一件真正有意义的事情！

之前的应用程序基于Asp.Net 2.0 + SQL Server 2005开发，运行在Windows Server 2003 32bit上，没有问题。
但现在将应用程序升级到Asp.Net 3.0 +SQL Server 2005，开发结束后，将应用程序配置到Windows Server 2008上运行，出现了不少问题，主要是读取dbf数据库文件和发送email出错。读取dbf数据库文件需要安装额外的oledb驱动，发送email使用了jmail com组件，而这两个组件都是设计运行在32位系统上的。程序运行时一直报告找不到组件。
参照http://technet.microsoft.com/zh-cn/library/aa996091(EXCHG.80).aspx，在控制台下执行命令：

cscript c:
\
inetpub
\
adminscripts
\
adsutil.vbs
SET

/
w3svc
/
AppPools
/
Enable32BitAppOnWin64
True

将IIS 7切换到32位下运行，这些组件就可以找到了，程序运行正常。

其他的没什么好说的，直接看代码即可，唯一一个需要说明的是，C++中常用的三种字符编码：
MBCS
，Unicode，UTF8，新手一般会在这个问题上犯糊涂。
MBCS是变长字节编码，具体的编码由操作系统确定，实际上是操作系统的内码。如在简体中文操作系统中，其编码是GB18030（GB2312的超集）；在繁体中文操作系统中，其编码是BIG5。对于GB18030，其英文字符编码与ASCII码值相同，用单字节编码，中文字符则用双字节编码，其值为字符对应的区位码值。
Unicode是双字节编码。其英文字符编码也与ASCII码值相同。不同之处在于，即使英文字符也用双字节表示，其第一个字节值为0，第二个字节为对应的ASCII码值。对于汉字，与GB18030的不同之处在于，相同汉字的编码值不同，不是汉字的区位码值，而是Unicode编码值。
UTF8也是变长字节编码。其英文字符编码也与ASCII码值相同，但只用一个字节编码；对于汉字等字符，则用三个字节编码。
UTF-8编码的最大长度是4个字节。
从以上的说明可以看出，存储一个相同的中英文混合的文本文件，MBCS和UTF8编码的文件要比Unicode编码的文件小，这是因为前两者对英文字符都使用单字节编码，更节省空间的缘故。实验中还发现，MBCS比UTF8文件的大小要稍小，这是因为UTF8保存汉字需要更多字节的缘故。

在计算机对这三种文字编码的处理效率上，Unicode编码要比MBCS和UTF8编码的效率高。这是因为Unicode是定长编码，在处理过程中不需要判断下一个字符的开始位置，因而处理效率高。在C++中，如果开启Unicode编码，则程序中的所有字符就是Unicode编码。如果需要保存为UTF8编码，必须手工处理。
附件是C++中读写UTF8文件的工具类。想当初我在互联网上到处寻找读写UTF8的C++方法，遍寻不得，希望能够给后来人给予帮助。附件中的CDirectory类是我在项目中使用的文件夹操作函数。

代码下载