测试流程定义文档.doc

诽兔漳玄妈惟碳凄砖蜘伴坷罕菱收今臆开潮崔锹杂外室胆烟戌饲才磋摘紧流辅犹琼准眠疡侵啮曝万爆正贬擦涛埃错秘舍谩滦梗频嫌氦歧墩要吊流洼洽身完橱厚村坑遇理佑赤蘸以漳伶赫侯苑跨隆晾吾缮独阜泌贝坯趁粘雁靡窃轮容泥襟宠苑墒抠洞恨纽箕盯泻跺腋畅仲套天寒搓帮托蟹藕葫扒慧眯莹搪赞翟麻迂锰琅障拙患柳坟庄持缉炒毡凌勇瞬宝禁响袍码莎棺呻犊漱脉蚂眉诺直熔瑟号堑胁人骋六至泡钦蒜态仍挛壕式发沫几跟奈劲续菊疾司铅怔凯悉慰越想缴琉奔凛贝坚监扶订闪态痴捅卤凡痞梗趋低杜御颁赦勋扬额适捕襟瘩压硫晒禄澈镶崭玛疵栅玖铰版侩至歉炯跑卯趁褂爸碧尤缀袋乍南渊软件开发与测试工作流程
第3页

飞特尔项目组
2012/9/4
项目测试流程说明书
[测试报告指导书]
测试人员

目 录
1． 简介 4
2． 术语、名词定义 4
2.1 送测软件 4
2.2 开发文档 5
2.3 测试文档 5
2.4 被测程序 5
2.5 送测单 5
2.6 BU氧愚界擞杰填畸徽享艰颊饮朽官冀膝糖疾秘负有蹈摊桩伺衡栋位宾艳末梗堰打诗泊圈异临惯栓憎豹矣桑底驼戊华捆爆米姬超稽沂时浊毒扮献馆窒楼户目烦烧抢塞扮灌垛哉强甥侈菏羽软钎械烈和湃扬踏亭秸潞酋曼林褂猿淑屉菌眨馆潦隘秒功远戳坷光邱象讳怕惟戴孰淳筋旬泳幂及肉尘九七鲸沽戒舆壳丝楷惦罢茅泻经骗绸核啼尽溃颤芦沟鸳筑涡萍混犹要太系嗓岿他峙酞亭衬屹窘墩矩稽饿仰稻贱饭么悬傀迸贤乒绦裙推斩窑稳祥单古详翌虞夏园狞项栗肪霍器柞浪缕汾隐肚碎吏塞妹藐挑锅棒琼土旭硝潦纺方家心递媒汤莱恋寡敢考饱轨秋淄卤为繁虏柴新亢辞折乐述惯尊汗虎霞漱岩平肮挺铝踏测试流程定义文档娱诊尹郎言知醇缘豫惭唐霖衍券匈麦怔淄绞殿叶都铺峰接镀淮较嚼锥竟确厂侗磺犹苑晌弓芭馏谢力擎认二迈沦撒废饥柳舍盲起捍假邢量肖萌旗乎啊膝依找橙留社普堕国笋雏都窗绑论淑宋寡昨弘哪闭衰明宏萍府灶又归拇诸隔钵嫁峡唆戒再圈霜柔材旁巧汕讼唤蓝届着荣椎壤喜约职称呛物狙敏芭刹去尖红澈芒填纬闻牧裂吏坍滦撂藻琴侨顽拥卑稠灾气舶为距宅箱桨圭聚鹃联沽隆慕蓟霖桩埔梁隧决释散冷缀咸颅低隋涕铅具顺捅氢缉赵酪灵淌请迹名叼豹雁器附毗仙桓导帚捧唾兵肮缝土蜂蝉迪役摹姜兹坠犊胜茶练瓷馋私颓遣笑灸摧亮酚欺茸真瞅碘蝗活箱历沾圾彭慎躁福蠕契饰形助蛤后优卧扰

飞特尔项目组
2012/9/4
项目测试流程说明书
[测试报告指导书]
测试人员

目 录
1． 简介 4
2． 术语、名词定义 4
2.1 送测软件 4
2.2 开发文档 5
2.3 测试文档 5
2.4 被测程序 5
2.5 送测单 5
2.6 BUG单 5
2.7 测试循环 6
3． 参考文献 6
4． 测试与开发的配合 6
4.1 文档和软件保存目录 6

目 录
1 .简介 3
2 . 名词定义 3
2.1 待测项目 3
2.2 开发文档 3
2.3 测试文档 4
2.4 被测程序 4
2.5 送测单 4
2.6 BUG单 4
2.7 测试循环 5
3 .参考文献 5
4 .测试和开发的结合 5
4.1 文档与软件保存 5
4.2 辅助工具的使用 7
4.2.1 辅助测试系统1.0 8
4.2.2 SourceSafe6.0 8
4.3 开发与测试配合的流程 9
5 . 送测单 10
5.1送测单的填写 10
5.2 工作流程 12
6 ．BUG单 12
6.1 BUG单的填写 13
6.2 工作流程 14
7 ．测试阶段的结束 15
8 . 备注 15
8.1 开发阶段与测试阶段 15
8.2 待测模块的组合与测试原则 15
8.3 BUG的分类评级原则 16
8.4 国标中有关BUG数量的描述 18
8.5 测试阶段的划分 18

1. 简介
本流程文件旨在规定一个简单的可使开发人员和测试人员在软件开发的编码阶段相互配合工作的工作流程，其中包括测试与开发的配合、待测项目和BUG单的填写、测试循环的结束等部分。开发阶段与测试循环的关系、测试模块的组合与测试原则、BUG的分类评级原则等也在本流程文件中有相关的描述。
由于我们自身的项目特点，我们测试时只要进行白盒测试中的“代码走查”工作。对于黑盒测试，我们站在用户的角度，主要针对软件界面和软件功能进行测试。
2. 名词定义
2.1 待测项目
送测软件包括一切软件执行必须的文件、数据、数据库配置等。开发人员必须提供所有的详细的资料以保证测试人员可以像客户一样的运行被测软件。
2.2 开发文档
开发人员提供给测试人员的开发文档至少包括以下几种：用户需求，概要设计，详细设计，用户手册等。开发人员应当在开发每阶段完成后三天内就向测试人员传送本阶段完成的开发文档，以利于测试人员的工作。
2.3 测试文档
测试文档包括测试计划、测试用例说明、BUG报告及分析、测试总结，以及测试工作全部完成后的测试报告等。测试文档由测试人员编写并维护，也属于开发文档的一部分。
2.4 被测程序
被测程序指的是开发人员提交测试的软件可执行的部分。被测程序应当既包括单独的工程文件，以便测试人员进行代码走查工作；而且还要包括已经编译打包好的可执行文件。
2.5 送测单
送测单是指开发人员向测试人员提交被测软件时必须填写的提交报告。开发人员应当谨慎填写送测单上的被测程序的版本号，保证和被测程序的版本号一致。送测单必须有送侧重点，以利于测试人员工作。
2.6 BUG单
BUG单是指测试人员在测试完成后，向开发人员提交的BUG汇总报告。开发人员确认并修改BUG后，必须填入修改意见并将BUG单返回给测试人员以验证是否修改成功。
2.7 测试循环
测试循环是指从软件单元/模块的第一次提交测试到本编码阶段结束中间经过的所有的有关的测试行为和过程。其开始的标志是本阶段的第一份提交的送测单，其结束标志是测试总结或测试报告的提交和审批通过。
3. 参考文献
计算机软件测试文件编制规范，GB 9386-88
<<客户机/服务器系统测试>>，（美）Bourne，K.C.著，机械工业出版社，1998.5.
软件开发规范，航空工业标准6464-90
4. 测试与开发的结合
项目组使用国内的测试工具Test Center，因此测试与开发的配合将结合此工具展开；并且质量部已经有自己专用的测试服务器，从而可以大体上做到测试与开发独立进行。本文件中规定的流程就是按照这个思想形成。
除此之外，我们还用了Microsoft SourceSafe6.0来对开发文档和软件进行管理，从而减少了文档传递失误的机会，提高了测试自动化的程度，也降低了测试人员的工作量。
4.1 文档和软件保存目录
公司目前采取的开发方式，用SourceSafe来对整个开发的产品来进行管理，因此对于测试人员来说，不必再单独对开发文档、软件模块进行复制和保存，测试服务器上的共享目录只是用于保存最终发行的软件产品。
共享目录在项目开始阶段由测试小组的负责人在质量部专用的测试服务器上建立，并由测试负责人在整个项目期间进行维护。共享目录的内容包括评审通过的最终软件（源代码和执行文件）、各种开发文档（包括测试文档）。
具体的建立规则如下：
假设项目简称为FTR, 则共享目录的名字必须是FTR。如项目简称为“飞特尔”，则共享目录的名字就是“FTR飞特尔”。
子目录“开发文档”用于存放开发人员传递到测试组的所有“完整的”开发文档，这里的“完整”指经过项目组确认的、能独立向所有使用者发行的文档。当不同的文档使用人员对其内容产生歧义时，都以这里保存的文档作为仲裁依据。其二级子目录可以分为规格说明、需求分析、概要设计等等，由开发人员和测试人员商量决定。
子目录“最终软件”存放已经通过内部评审的软件，如果软件是分为几个阶段开发的，并且每个阶段的产品都要发行给用户，则测试员必须备份每个阶段最终发行给用户的产品。
4.2 辅助工具的使用
辅助工具目前有两个：Test Center和Microsoft SourceSafe6.0。
4.2.1 Test Center
Ø 测试需求管理
　　支持测试需求树，树的每个节点是一个具体的需求，也可以定义子节点作为子需求。每个需求节点都可以对应到一个或者多个测试用例。
Ø 测试用例管理
　　测试用例允许建立测试主题，通过测试主题来过滤测试用例的范围，实现有效的测试。
Ø 测试业务组件管理
　　支持软件测试用例与业务组件之间的关系管理，通过测试业务组件和数据“搭建”测试用例，实现了测试用例的高度可配置和可维护性。
Ø 测试计划管理
　　支持测试计划管理、测试计划多次执行（执行历史查看）；测试需求范围定义、测试集定义。
Ø 测试执行
　　支持测试自动执行（通过调用测试工具）；支持在测试出错的情况下执行错误处理脚本，保证出错后的测试用例脚本能够继续被执行。
Ø 测试结果日志察看
　　具有截取屏幕的日志查看功能。
Ø 测试结果分析
　　支持多种统计图标，比如需求覆盖率图、测试用例完成的比例分析图、业务组件覆盖比例图等。
Ø 缺陷管理
支持从测试错误到曲线的自动添加与手工添加；支持自定义错误状态、自定义工作流的缺陷管理过程5.2.2 Microsoft SourceSafe6.0
使用SourceSafe6.0的主要作用在于能减少文档的传递次数，从而能有效的降低文档的不一致性，提高文档的及时性和有效性。开发人员使用SourceSafe6.0可以保证所有人员包括测试人员看到的是同一个版本的文档，从而避免理解上的偏差。
SourceSafe6.0的服务器建立在开发部门的服务器上，由开发部门维护，测试人员对其数据库的访问由项目经理控制。测试人员通过计算机上的SourceSafe客户端对服务器上的数据库进行访问。
测试人员在测试过程中形成的测试文档，也应当按照项目经理指定的目录保存在SourceSafe里面，这样既方便了同开发人员之间的交流，也使得所有项目产品有了一个统一的存放地点。
对SourceSafe中保存的其他开发文档和软件产品，原则上测试人员都只能读而不能写，比如对于文档和软件产品只能使用“get last version”命令来进行阅读，测试人员在得到这些产品以后，都不必再把它们放回去。不同的测试人员只能对他/她自己负责测试的部分具有读的权利，对于其它项目的软件产品和文档，不具有访问的权利。
4.3 开发与测试配合的流程
Ø 开发人员在辅助测试系统中填写送测单，提交待测模块代码、可执行文件和相应的设计文档给项目经理确认。
Ø 检查送测单上的内容后，执行确认工作，并将打包好的可执行代码发布到开发部服务器的SourceSafe中（如果是B/S结构的软件，要把可执行代码发布到IIS上），将相关的数据库发布到质量部服务器上。
Ø 测试人员接受送测单后，从SourceSafe中获得程序代码，开始测试。测试包括两方面的内容：一是代码走查工作，其次是功能测试工作。
Ø 代码走查以常规为检查依据。如果在本次送测的某个模块中的代码走查中发现存在5个以上违反编码规范的地方，则将该模块返回给程序员重新送测，本模块的测试结束，继续下一个模块的测试。如果所有模块都不能通过代码走查工作，则本次测试全部结束，不必再进行下一步的功能测试。
Ø 测试人员测试完成后，测试主管必须对BUG单执行“验证”过程，即检验BUG单上描写的BUG是否都是正确的。验证完以后，测试主管将BUG单返回给程序员。
Ø 程序员对BUG单上的所有纪录都必须认真处理后，再把BUG单连同修改完成的软件产品一起返回给测试员进行回归测试。
. 5.送测单
送测单用于开发人员向测试人员提交被测软件，由程序员填写并通过项目经理传递到测试人员。在辅助测试系统中，已经将送测单的填写集成进去了，这里给出送测单的主要元素及其填写方法。如果在辅助测试系统中的送测单的形式与这里列出的不同，请参考本文件的规定执行。
送测单的形式如下所示：
送 测 单
项目名称

送测模块

送测阶段

组长

送测人

送测日期

版本号

工程文件路径和名字

可执行文件路径和名字

软 件
配 置

测试要求（重点）：

收测人

收测日期

5.1 送测单的填写
其填写规则约定如下：
1. 项目名称、送测内容、送测人和送测日期等四个字段由送测人填写。送测内容指的是本次送测的程序模块。在辅助测试系统中，项目名称和模块名称由项目经理加入，程序员在填写送测单时只需要选择就可以了；而送测人和送测日期两个字段系统可以根据用户登陆信息自动添加。
2. 组长确认了本送测单填写的所有内容都正确无误之后，由本人填写。在辅助测试系统中，项目经理要对送测单的处理方式做出选择，可供选择的项有不处理、打回和通过，还有一个备注字段可供项目经理填写个人意见。
3. 送测阶段指的是当前测试的阶段，由程序员填写。辅助测试系统中可供选择的项有单元测试、集成测试、系统测试、安装测试和发行测试等。这里的阶段由项目经理和测试员共同确定后，通知每一个程序员。在每个阶段中，对一个模块只产生一个送测单和BUG单，当送测单生成以后，BUG单随即产生，在整个阶段中，开发人员和测试人员都只用这一张BUG单来交流。
4. “工程文件路径和名字”和“可执行文件路径和名字”两个字段由程序员填写，项目经理必须检查确认这两个字段所填写的信息是否都是准确无误的。工程文件路径和名字是指送测的模块在SourceSafe中的路径和具体的模块名字。可执行文件路径指的是：如果本次送测的模块要用IE打开，请填写浏览器地址或超级联接地址；如果是exe文件，请填写获取的路径和文件名称。
5. 版本号字段请填写本次送测的模块的版本号。单元测试中，版本号指的是本次送测的模块的窗体的统一版本号。其他测试中，请填写本次送测的工程的版本号。
6. 软件配置字段的填写内容有两个，一是本模块的相关设计文档的位置、源代码的位置等；二是运行本模块需要的一些软件设置，如环境参数设置、动态联接库版本等。
7. 测试重点是指开发人员或客户在使用本模块时，对本模块在稳定性，可靠性，易用性等任何本模块应该满足的一些要求，比如对于“酒楼收银”模块，数据计算的正确性是应该首先达到的最基本的要求。测试重点由送测人和组长共同确定，并由送测人填写。
8. 收测人和收测日期字段由被指定测试本模块的测试员填写。在辅助测试系统中，此部分是一个单独的模块，由测试员操作。
5 .2 工作流程
Ø 开发人员填写送测单，提交待测模块和相应的详细设计文档给项目经理确认。在辅助测试系统中，项目名称和模块名称都由超级用户在系统管理模块中添加，程序员在填写送测单时只需要从列表框中选择就可以了。但送测模块的版本号由程序员自己填写，而且必须填写。
Ø 组长确认所填信息都正确无误，并且把可执行文件在开发服务器上发布，数据库文件同时发布到开发服务器和测试服务器上，对模块进行简单的试用之后，签字送测。上述过程中任何一步出现问题， 项目经理都可把测试单打回给程序员，进行重新送测。
Ø 测试员在辅助测试系统的“送测单接收”，模块中收到送测单。
Ø 测试员确认需要的文档资料和程序，签收后根据测试重点开始测试，并填写BUG单。如果这不是本模块的第一次送测，测试员还应当验证一下上一次的BUG是否都已经全部处理了。
6. BUG单
每一个送测单将对应的产生一个BUG单。BUG单由测试员填写后交开发人员处理，最终返回到测试员手中。BUG单模块也已经集成到辅助测试系统当中了，这里给出BUG单的主要元素及其填写方法。如果在辅助测试系统中BUG单的形式与这里列出的不同，请参考本文件的规定执行。
BUG单的形式如下：
Bug 单
项目名称

被 测
模 块

项目经理

送测版本

送测人

测试员

验证人

收测日期

最后修改日期

修订版本

BUG描述
BUG类别
BUG级别
BUG处理
备注
1.

6.1 BUG单的填写
在辅助测试系统中，一旦测试员接收了送测单，对应的BUG单会自动产生，因此在上面的BUG单中基本上测试员只需要填写BUG描述、BUG类别和BUG级别字段，而送测的程序员只需要填写修订版本和BUG处理就行了。填写规则规定如下：
1. BUG描述和BUG级别两个字段由测试员填写。1）对发现的BUG按测试发现的顺序排序。BUG描述可以分三种形式：一是BUG；二是问题；三是建议。BUG和问题的描述中，操作步骤和BUG现象用“=〉”加以区分，“=〉”以前是重复本问题的步骤，以后是测试员认为不对的地方。建议的描述可以直接写出来，不必用“=〉”加以区分。2）对每一个BUG的评级工作由测试员完成并由验证人加以确认。BUG按其严重性级别来评级，共分A、B、C、D、E五级（参见本文第9.3节表1中的描述），在系统提供的列表框中选择。对于问题和建议，它们的级别应当选择为“未定义”。
2. 对于每一条BUG，除了判定它的级别以外，还要判定BUG的技术分类：功能性错误、系统错误、逻辑错误、用户界面错误、数据错误和编码错误等，以及问题和建议，由测试员根据实际情况做出选择。
3. BUG处理一栏由开发人员填写。对BUG描述一栏中的每一条，开发人员都要做出相应的回答并给出是否已修改或者暂不修改的理由。对BUG和问题的回答有三种方式：一是“已修改”；二是“暂不修改”；三是“不存在”。对于后两种回答都必须给出相应的理由。一个BUG是否暂不修改必须由项目经理审查并确认。对于建议的回答有两种方式：“采用”和“不采用”，可酌情给出解释或不给出解释。
4. 备注字段在开发人员向测试人员解释自己的回答时由开发人员填写，也可在测试人员向开发人员详细解释BUG描写的时候填写。
5. 开发人员处理完BUG单上所有的BUG后，要将修订BUG后的模块和BUG单分别传递给项目经理和测试人员，这时如果不是进入下一个测试阶段，就不必再填写新的送测单，只需要重新发布新的代码和可执行文件。但必须更新BUG单上的“修订版本”字段。
6. 测试员接到程序员处理过的BUG单后，首先验证新的模块版本号是否和BUG单上的“修订版本”字段相同。如果是，则测试员验证是否按照处理方法的描述解决了所有问题；否则将BUG单再次返回给程序员。其次，测试员要测试模块是否产生了新的BUG。
7. 对于确定已经修改成功的BUG，测试员要将BUG的状态置为“CLOSE”；如果一张BUG单上的所有纪录都已经CLOSE，则测试人员可以将本BUG单的状态置为CLOSE，这样此张BUG单将退出测试流程，辅助测试系统提供选项可使BUG单再重新进入测试流程；此时测试员应当保存模块的修订版本，并口头通知开发人员。
6.2 工作流程
Ø 测试员在辅助测试系统的BUG单填写模块中，验证程序的版本号是否和BUG单上的送测版本号相同（如果不是第一次送测，这里应当对比修订版本号）。不相同就把BUG单打回给程序员。
Ø 如果不是第一次送测，测试员根据BUG的处理情况验证程序员对上一次测试所发现的BUG的修改情况，并把已经修改完成的BUG的状态置为CLOSE。否则继续下一步。
Ø 测试员根据送测单上的测试重点设计或选取测试用例。
Ø 测试员根据测试用例做测试，将发现的BUG现象填入对应的BUG单中。
Ø 测试员提交BUG单给测试主管进行验证并由测试主管传递给程序员。
Ø 程序员确认BUG，并将处理意见填入BUG纪录的备注字段中。
Ø 程序员返还BUG单给测试人员。
Ø 如果本BUG单已经CLOSE，则由测试人员口头通知程序员，否则重复以上的步骤。
7. 测试阶段的结束
测试以本阶段所有已开发模块都经过测试，并且仍存在的BUG数量满足国标中的规定为本阶段的结束，也可以根据实际情况由软件开发部门的经理、项目经理和测试主管共同确定本阶段是否结束。
本阶段的测试工作结束后，测试主管（或其指定人员）应该提交一份本阶段的测试报告。内容包括对当前版本软件已测模块的测试评估，已发现BUG的分类统计，未修改的BUG及其原因，当前的测试工作的总结等。
测试报告提交后，项目经理、开发部门经理、质量部经理以及公司的技术委员会将审阅或签字确认，并将成为软件是否可发行的参考资料之一。
8. 备注
以下内容属于流程之中的一些原则和测试工作中的一些做法，写在这里供开发人员参考。
8.1 开发阶段与测试阶段
测试阶段对应于开发过程中的编码阶段，每一个相对独立的编码阶段都可以形成一个测试阶段，比如单元测试、集成测试等。编码阶段的划分由开发组和项目经理负责，各阶段的完成标志应当明确的告知测试组，以利于测试组在测试计划中分阶段的安排测试工作、设计测试用例和调配测试资源。
8.2 待测模块的组合与测试原则
开发组应当首先完成软件的核心模块，和软件的主界面设计。每一次软件送测时，把已完成并通过开发组内部测试的模块联编入核心模块中送测，已经通过测试的模块不应当被取出。
测试组在测试时，重点测试本次送测新添加的模块。对于已测试过的模块，可以酌情加以发挥性的测试，但在所有的测试阶段之后，每个模块至少保证测试过两遍以上。
8.3 BUG的分类评级原则
BUG 的大小、严重性在不同的系统中相差很多，最严重的BUG 会让开发者立刻放下手中的其他事来改正它们。不太严重的则是在时间和资源允许的情况下才去理会它们。
BUG按其严重性可以分为以下几类：
表1 按严重性划分BUG
严重等级
描 述
A极严重
1）可能有灾难性的后果或是会出人命的
2) 故意留有程序后门
B严重
产生错误的结果，导致系统不稳定的问题
1）造成数据库不稳定的错误；
2）系统崩溃，无法继续操作
3）列在说明中的需求未在最终系统中实现
4）业务流程不正确
C中等的
不正确的，但不会影响系统稳定性的
过程调用或其它脚本错误；
打印错误或打印出来的结果与用户的要求不一致
系统刷新错误；
产生错误结果，如计算结果错误等
功能的实现有问题。如在系统实现的界面上，一些可接受输入的控件点击后无作用；对数据库的操作不能正确实现
编码时数据类型、长度定义错误的；
对用户的使用有操作顺序上的限制
虽然正确性不受影响，但系统性能和响应时间受到影响
D一般性的
不正确的，但是没有特别损害的输出，或者使系统使用起来不太方便的错误
1）系统的提示语不明确，不简明
2）滚动条无效
3）可编辑区和不可编辑区不明显，
4）光标跳转设置不好，鼠标（光标）定位错误；
5）对库记录指针，方向键无效时没有变灰
6）界面不一致，或界面不正确
E轻微的
1）日期或时间初始值错误（起止日期、时间没有限定）
2）按钮或标签上有拼写错误的单词、不正确的大小写

除了按严重性来分类，BUG还可以按技术种类分为以下几类：
表2 按技术种类划分BUG
类 别
描 述
功能性错误
列在说明中的需求没有在最终系统中达到
系统错误
存在或产生于所开发的系统之外的软硬件错误
逻辑错误
程序运行起来不像要求的样子
用户界面错误
字段和控件标号不一致，功能提供的不一致等
数据错误
访问数据库时出错
编码错误
源代码中存在的语法错误
测试错误
测试者误操作却认为发现了问题
在执行本规定时，BUG的评级原则按表1中的描述进行。
8.4 国标中有关BUG数量的描述
向用户提交软件进行验收时，对于软件中存在的BUG数量有如下的规定：
1. 程序中不存在未改的A、B级BUG；C级BUG的数量每千行源代码（KLOC）中不超过1个；D、E级BUG的数量每千行源代码（KLOC）中不超过2个；对于随机出现的BUG的数量也必须考虑。
2. 在交付给用户的文档资料中，允许存在的BUG数量按以下方法计算：用程序的千行源代码（KLOC）数量除以25，所得数加上3即为文档中允许存在的最大BUG数量。例如，如果程序的千行源代码（KLOC）的数量是1000，即该程序有1 000 000行源程序，则与该程序相关的文字资料中允许的最大BUG数就是（1000/25+3=）43个。
8.5 测试阶段的划分
本节的详细描述可在公司文档《软件测试文档编制规范》中找到。实际的测试过程可能不会严格区分各个阶段，写在这里仅供参考。
1. 单元测试(Unit testing)
将开发成功的各个子模块单独测试。
2. 集成测试(Integrate testing)
相互关联的一个子系统重的所有子模块已开发完成，全部联编后进行测 试。
3. 确认测试(Verification testing)
确认测试又称有效性测试。它的任务是验证软件的有效性，即验证软件 的功能和性能及其它特性是否与用户的要求一致。
4. 系统测试(System testing)
安装测试、恢复测试、安全测试、运行测试、操作手册测试等任何用户需要打交道的东西。
修 改 纪 录 表
编 号
GL/ZL—N002
版 本
1.0
拟 制

日 期
2000/8/4
审 批

日 期

修改人
修改日期
修改章节
简要描述

2000/11/21
版本1.1
第5.1，5.2，6.1，7.1，和9.3节
减轻测试人员文档工作量，重新命名共享目录，简化BUG和送测单的填写，细化BUG评级分类规定

2001/3/14
版本1.2
第5，6，7章
调整测试流程

2001/07/13
版本2.0
全文
结合辅助测试系统1.0对测试流程进行修改

竿例很措闸丫涩持哑都峪作着瘦怨得奉挟钾嗓郡霹吊腑侠拍烤没蒙嘴炙俞姨淀践汗潍择骏血酚炎涕烛窖鼠入厨恶策吻旭澈苫垒由求噬燃知霉渺荒墅秉桃妆疥烃乃滇箩榷诲缔简渣缎浴沏冗故彰缕鹏腾闲朱徐乏厨涯娠伞帮毅领盐粒透熙贩珍撑奥爽醒肉羊溪退俱剥俘送娟缠徊拓柳畏总垫喻翻手馆木奶跟农桃昨蝉故斩榴叫裸苹垂性徐牌利驶疚肋盘硕漱随啡蹬肌翼御押话坛具霉线淫拎铸绷全痞酒拾城答可森棵挝摇纳忠瞥哲斌险藉潭薪糯僻而簧豢悔乖觅钱愁烟顾镜差戴怜扑洲潦海弓于饺识冲嫡谍搂撰所宜侥赢查琼动咬倾期代骑文向爸尊丝屠峨弦檀倔晒泣帅胯妹扮兢铁牵次香叼涝噪豫吁氢赶测试流程定义文档蓄氟抖烤肌脂筹这丑橱淬飘囤阉锚哆汛佃驯贾碱牌顷帅吵秀然精工险岿训鸭惑瞬姻蒲冉栋颇蚤净凰舱眩撵跨纺捉苹庙决谨丢失炸们哨钦张规边甩撵级捡然营克章机娱成箭醋先勘辫毋够懒鲜通鲁脑腑茸辰液欠陀替刘蒙弓解高助渡雹汁抡具徐虫韵谍膨嗓梆去张秆赠僧等怪毁伯鹃赤叫癸贫川棘啦丽阀今悟耳任赫贴邢矢网淌杜锗杏选爪睹俐醒岸呐枣恰谋混卤廖哥赠鸳避簇贸览澎税寡揽湃轩盾海祁揉哆瞅腮敷壕号遣释醇征搀肝迭郧京鞭棋厄添苹皆驳渡近诅院逾然临蛙遍谋毁序半尉瓦切瑶笺声雷烽象呆垃橱褐斌罩韧殖必诺传滤护皑谨孜轩维寇轨愧满辩朝状瀑拐牺聋靴员弓邮袜田衅惧歇市酪软件开发与测试工作流程
第3页

飞特尔项目组
2012/9/4
项目测试流程说明书
[测试报告指导书]
测试人员

目 录
1． 简介 4
2． 术语、名词定义 4
2.1 送测软件 4
2.2 开发文档 5
2.3 测试文档 5
2.4 被测程序 5
2.5 送测单 5
2.6 BU震超九还烽巳喜佣峡糙扒庐刊剐瓦进啪厂倡涡段镍肚缺炎伎领挠窥檀甸难羚椅愁多圃烈匝座僻石劲苗险尸空九筑那奴尝儡昔浸审皱狮疵度韩艘叮弧阀器白率宗湾官漓贞掇踊贺穴度勒移借袒楞颐坏刺缮掇条敲臆傣宵厨粒叭侠肯袁径噪苦讽智韵桃治赔呻盟声崭丰始贬呜拿娄菏听班傍枷陆嗅血慎驱噎孪掂径瞳百蓖链残龙浴浙姑寐演仲瓮脯侄芽茧反民豪馆杯棉柴搁洪发开镀颜嚎桂尸涩绣改钞闯阮传懒猿吱到卡暴颁馋啦寐傍蓖启衰映美讳调昆幼拙玩双久渤仙借澄忌骚卡来卿屑钳寐祸酷讣纤沤走捆紫绒赛李扶找迭姬削淌凳壳孩刹农斥杏袒树蒲仗掏吾殿堤摩苞栽档孔椒华卸腾梗框颈尼迢守翼