51Testing软件测试论坛

标题: 如何制定一份有效的，可行性高的测试规范？（08-09-22）（获奖名单已公布） [打印本页]

---

作者: 默默巫    时间: 2008-9-22 15:31
标题: 如何制定一份有效的，可行性高的测试规范？（08-09-22）（获奖名单已公布）
提高测试团队工作的规范性也是保证软件质量的必要手段，所以每个公司都应该制定自己的测试规范，这份规范应该是贯穿整个软件开发周期的，也是所有开发和测试都应该遵循的，如何制定这样一份规范让大家都愿意遵其行事呢？这样的规范具体应该包含哪些内容呢？



感谢会员xazaj提供此精彩问题！如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	zhuzx	当当购物卡50元	33#
二等奖	archonwang	300论坛积分	2#
	huguxiang		7#
三等奖	baiyuxuan	100论坛积分	18#
	fire83617		32#
	prettyyang		54#

---

作者: archonwang    时间: 2008-9-22 15:49
标题: 答：如何制定一份有效的，可行性高的测试规范？
占个位置，改天答

=====================================================

【2008-09-25】抽空就该问题做一个简单的说明。


如何制定一份有效的，可行性高的测试规范？

书写一份有效，可行性高的规范，我觉得需要注意以下几个方面：
1. 规范在内容上要系统全面。
关于测试的方式、方法、种类、流程等等我想自然不必再赘述了。但是如何把这些方式、方法、种类、流程串接起来形成一个体系却是值得我们每一个深入思考的问题。一份规范的影响面及其适应的情况毕竟来说还是很局限的。所以，我认为，从体系框架上构建是产生有效且高可行度规范的充分条件，皮之不存毛将焉附？第二，在规范的内容上必须要相对比较全面，至少能涵盖到目前所从事的主要的测试工作。第三，系统性的表述是规范的基本要求--一般我们都是要求使用结构化的语言，框架式进行编写，务必使构成该规范的每个部分都清晰明了。

2. 内容的细分项目要求具备一定的可操作性。
所谓规范的可操作性，即是要求可量化的量化，不能量化的具体化。很多同仁定规范时，对规范所要求的工作内容不够明确，不是雾里看花，就是“空对空”。评审的人一头雾水，执行的人无所适从，当然其可操作性必然不佳。尽量要求规范中的操作步骤明确，实现目标量化或具体化（建议参考SMART原则制定）。

3. 内容中所引用的术语、行业名词必须规范且统一。
很有必要的注意事项，团队内的成员来自不同的地方，每个人对相同的测试事务所持的观点未必相同，规范的作用之一就是尽量减少差异化，以期不同人做相同事能得到一个尽可能一样的结果。所以在制定规范时使用统一的口径是很必要的，以免产生歧义和误差。

4. 制定规范一定要注意适应当前企业的实际和现状。
也许这一点才是对可行性要求的最基本的要素。之前，包括我自己在内，对规范的理解也仅限于从网络上获得一些已成形的内容，到最后发现却根本不合适。比如说，一个只有三两个人的测试团队，就要求做自动化框架体系的构建--往往不切实际是一切规范失效的最根本原因。较好的规范应该是具备可实现性的，能在一定时期内努力后，可达到的目标。

接下来，补充几点说明：
1. 做规范的基本思想就是建立标准，以教育、培训、参照、考评和持续优化，使一切事可控并习惯化，以实现生产力提升，获得企业资源配置最优化与企业利润最大化。所以，将对规范的执行纳入绩效考核体系是必然的。有效无效，可行性高还是不高，我想不是靠几个大脑想就能实现的，最后还是要由实践来检验。
2. 既然是规范，必然有其缺失错漏，所以规范的有效及可行性判断必然是需要经过循序渐进、持续优化的过程，没有一步到位。不同的团队组织，对于规范的态度是积极执行，及时响应与否将决定规范的价值。所以，我想请大家记得这句话：好的规范是整个团队、组织一步一个脚印，不断整理、总结、归纳做出来的，不是拍拍脑袋想出来的。其所谓的有效、可行性也是基于此而言--大家万勿舍本求末。

[ 本帖最后由 archonwang 于 2008-9-25 15:58 编辑 ]

---

作者: free_xiaoyu    时间: 2008-9-22 18:03
占个沙发

---

作者: 一马平川    时间: 2008-9-22 18:20
标题: 需要测试专家和测试精英回答的问题
版主你这个题目很好，但是感觉离我们很遥远，毕竟我们不是测试经理，唉。。。。。

---

作者: bzfyhfyh    时间: 2008-9-23 10:20
呵呵，赞成  一马平川  的说法。
期待着精彩的对答。

---

作者: 开心网    时间: 2008-9-23 11:58
标题: 版主请读,个人觉的这个题目存在二异性
到底是回答“如何制定一份有效的，可行性高的测试规范？”；还是回答“测试规范具体应该包含哪些内容呢？”。请版主确认，呵呵！！！

---

作者: huguxiang    时间: 2008-9-23 12:52
我觉得测试规范应该包括两部分的规范，第一是测试内容的规范，第二是测试流程的规范。
1.        测试内容的规范
测试内容依我的理解包括文档、程序、数据。
文档规范主要指的是需求说明书的规范和设计说明书的规范，至于这两个文档规范在《软件评测师教程》里面有详细介绍，我把它粘贴出来吧，当然每个公司还可以根据具体的情况特殊考虑。
G:\QQ截图未命名.bmp
上面已经说到了，公司可以根据具体情况特殊考虑，可以删除或增加相关的规范，应该由公司高层、设计师、开发部、测试部分别派代表来开会讨论并制定规范，规范一旦通过评测制定，就由行政部发布执行。有了文档规范之后，测试部根据文档规范评测相关文档。
程序规范，即软件编码规范。这个规范在《软件评测师教程》中也有写到，而且总结得比较好。
A．        源程序文档化 包括以下几方面的规范：符号名的命名、程序的注释、标准的书写格式等
B．        数据说明 包括以下几方面的规范：数据说明的次序、说明语句中变量安排有序化、使用注释说明复杂数据结构等
C．        语句结构 比如:在一行内写一条语句、程序清晰等
D．        输入/输出
等等。。。。。。
   数据规范，一般是基础数据有相当严格的规范，下面举一个我们公司数据规范的例子，如下表所示：
代码        名称
HG001        合格
HG002        不合格
TY001        检验特征项值不符合标准
TY002        检验特征项值超出规定范围
ZM001        褶皱
ZM002        裂纹
ZM003        杂物
ZM004        破损
ZM005        色泽不一致
（注意看代码，是通过设计部统一给名称编码的，现在不能变，以后也不能变，录入数据的时候必须按照这个规范来录）
2.        测试流程规范 测试流程一旦制定了规范就不能经常变动，测试流程的规范也应该由公司高层、设计师、开发部、测试部派出代表开会议定，得到大家认同的规范才能有效的执行。各个行业、每一个公司都有自己独特的流程规范，但是总的应该包括一下几个方面的规范：
A．        测试用例的规范、bug的规范等等------规范测试人员的行为
B．        提交功能界面测试文档规范（一般测试部会发格式文档给开发部填写，开发部发邮件提交功能界面给测试部）、修改bug规范、配置文件规范等等------规范开发人员的行为
。。。。。。
这些一起形成了软件开发周期的规范，如果是刚试用这些规范，可以规定一个月的试用期，看这些规范在实际开发周期中是否适用，什么都要经过一个试验的过程，慢慢就会形成一种风气，大家都会按照这个规范行事。
呵呵 经验之谈 请高手指点

[ 本帖最后由 huguxiang 于 2008-9-24 10:22 编辑 ]

---

作者: 天才精英    时间: 2008-9-23 13:52
标题: 最近几次的冠军，怎么都不见踪影了呢？
我们很期待高手的精彩回答。

---

作者: 测试能手    时间: 2008-9-23 17:54
标题: 6楼朋友讲述属实，下面是我的揣测，请版主定夺

原帖由 开心网 于 2008-9-23 11:58 发表
到底是回答“如何制定一份有效的，可行性高的测试规范？”；还是回答“测试规范具体应该包含哪些内容呢？”。请版主确认，呵呵！！！

这个问题确实讲述不是很清楚，建议清晰一下。估计出题人是想知道：测试规范具体应该包含哪些内容？而如何制定揣测不是重点。

---

作者: 翱翔太空    时间: 2008-9-23 18:11
标题: 同意楼上的观点
难怪答题的高手较少，呵呵！！！请版主尽快确认，谢谢啦！！！

---

作者: 默默巫    时间: 2008-9-24 09:17

原帖由 开心网 于 2008-9-23 11:58 发表
到底是回答“如何制定一份有效的，可行性高的测试规范？”；还是回答“测试规范具体应该包含哪些内容呢？”。请版主确认，呵呵！！！

我觉得虽然是两个疑问？但两者之间是紧密结合的，可以并作一起回答．

---

作者: xazaj    时间: 2008-9-24 10:18

原帖由 开心网 于 2008-9-23 11:58 发表
到底是回答“如何制定一份有效的，可行性高的测试规范？”；还是回答“测试规范具体应该包含哪些内容呢？”。请版主确认，呵呵！！！

确认“开心网”这位朋友的疑问：
直接回答：“测试规范具体应该包含哪些内容呢？”即可， 其实这两个问题回答的重点是一样。
因为测试规范是测试部门提出，但是执行者可能会包括开发等其他部门，所以可行性也是内容的重点。

---

作者: 锅仔    时间: 2008-9-24 10:50
占个位子，一会回答

---

作者: sixsigmay    时间: 2008-9-24 10:54
占个位置看答案

---

作者: inksong    时间: 2008-9-24 11:05
标题: 除了有测试规范，应该还有开发规范
除了有测试规范，应该还有开发规范，因为不仅仅有测试，还有开发，所以这些都是贯穿整个软件工程的。当然作为我门测试的人来说，可能关注的点在测试上面，但是开发我门也不能遗忘。

---

作者: inksong    时间: 2008-9-24 11:17
标题: 每个公司都有自己的规范，虽然有细微差别，但本质都是使测试更加标准化
按照规范来说，应该还包括开发规范，下面是开发，和测试的规范。

1．项目开发计划的规范
2．概要设计说明书的规范
3．软件需求说明书的规范
4．详细设计说明书的规范
5．可行性研究报告的规范
6．模块开发卷宗的规范
7．数据库设计说明书的规范
8．数据要求说明书的规范
9．文件给制实施规定的实例的规范
10．开发进度月报的规范
11．项目开发总结报告的规范
12．用户手册
13．操作手册的规范
14．测试计划的规范
15．测试分析报告的规范

（一）项目开发计划的规范
。1引言
1.1编写目的
说明：编写这份软件项目开发计划的目的，并指出预期的读者。
1.2 背景
        说明：
a.        待开发的软件系统的名称；
b.        本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络；
c.        该软件系统同其他系统或其他机构的基本的相互来往关系。
1.3定义
        列出本文件中用到的专门术语的定义和外文的首字母组词的原词组。
1.4参考资料
        列出用得着的参考资料，如：
a.        本项目的经核准的计划任务书和合同、上级机关的批文；
b.        属于本项目的其他已发表的文件；
c.        本文件中各处引用的文件、资料，包括所要用到的软件开发标准。列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
2项目概述
2.1工作内容
        简要地说明在本项目的开发中须进行的各项主要工作。
2.2主要参加人员
        扼要说明参加本项目开发的主要人员的情况，包括他们的技术水平。
2.3产品
2.3.1程序
        列出须移交给用户的程序的名称、所用地编程语言及存储程序的媒体形式，并通过引用相关文件，逐项说明其功能和能力。
2.3.2文件
        列出须移交用户的每种文件的名称及内容要点。
2.3.3服务
        列出需向用户提供的各项服务，如培训安装、维护和运行支持等，应逐项规定开始日期、所提供支持的级别和服务的期限。
2.3.4非移交的产品
        说明开发集体应向本单位交出但不必向用户移交的产品（文件甚至某些程序）。
2.4验收标准
        对于上述这些应交出的产品和服务，逐项说明或引用资料说明验收标准。
2.5完成项目的最迟期限
2.6本计划的批准者和批准日期
3实施计划
3.1工作任务的分解与人员分工
        对于项目开发中需要完成的各项工作，从需求分析、设计、实现、测试直到维护，包括文件的编制、审批、打印、分发工作，用户培训工作，软件安装工作等，按层次进行分解，指明每项任务的负责人和参加人员。
3.2接口人员
        说明负责接口工作的人员及他们的职责，包括：
a.        负责本项目同用户的接口人员；
b.        负责本项目同本单位各管理机构，如合同计划管理部门、财务部门、质量管理部门等的接口人员；
c.        负责本项目同个份合同负责单位的接口人员等。
3.3进度
        对于需求分析、设计、编码实现、测试、移交、培训和安装等工作，给出每项工作任务的预定开始日期、完成日期及所需资源，规定各项工作任务完成的先后顺序以及表征每项工作任务完成的标志性事件（即所谓“里程碑）。
3.4预算
        逐项列出本开发项目所需要的劳务（包括人员的数量和时间）以及经费的预算（包括办公费、差旅费、机时费、资料费、通讯设备和专用设备的租金等）和来源。
3.5关键问题
        逐项列出能够影响整个项目成败的关键问题、技术难点和风险，指出这些问题对项目的影响。
4支持条件
        说明为支持本项目的开发所需要的各种条件和设施。
4.1计算机系统支持
        逐项列出开发中和运行时所需的计算机系统支持，包括计算机、外围设备、通讯设备、模拟器、编译（或汇编）程序、操作系统、数据管理程序包、数据存储能力和测试支持能力等，逐项给出有关到货日期、使用时间的要求。
4.2需由用户承担的工作
        逐项列出需要用户承担的工作和完成期限。包括需由用户提供的条件及提供时间。
4.3由外单位提供的条件
        逐项列出需要外单位分合同承包者承担的工作和完成的时间，包括需要由外单位提供的条件和提供的时间。
5专题计划要点
        说明本项目开发中需制定的各个专题计划（如分合同计划、开发人员培训计划、测试计划、安全保密计划、质量保证计划、配置管理计划、用户培训计划、系统安装计划等）的要点。

---

作者: inksong    时间: 2008-9-24 11:18
标题: 概要设计说明书的规范
概要设计说明书的规范
1引言
1.1编写目的
说明编写这份概要设计说明书的目的，指出预期的读者。
1.2背景
说明：
a.        待开发软件系统的名称；
b.        列出此项目的任务提出者、开发者、用户以及将运行该软件的计算站（中心）。
1.3定义
列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
1.4参考资料
列出有关的参考文件，如：
a.        本项目的经核准的计划任务书或合同，上级机关的批文；
b.        属于本项目的其他已发表文件；
c.        本文件中各处引用的文件、资料，包括所要用到的软件开发标准。列出这些文件的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
2总体设计
2.1需求规定
说明对本系统的主要的输入输出项目、处理的功能性能要求，详细的说明可参见附录C。
2.2运行环境
简要地说明对本系统的运行环境（包括硬件环境和支持环境）的规定，详细说明参见附录C。
2.3基本设计概念和处理流程
说明本系统的基本设计概念和处理流程，尽量使用图表的形式。
2.4结构
用一览表及框图的形式说明本系统的系统元素（各层模块、子程序、公用程序等）的划分，扼要说明每个系统元素的标识符和功能，分层次地给出各元素之间的控制与被控制关系.
2.5功能器求与程序的关系
本条用一张如下的矩阵图说明各项功能需求的实现同各块程序的分配关系：
        程序1        程序2        ……        程序n
功能需求1        √                       
功能需求2                √               
……                               
功能需求n                √                √
2.6人工处理过程
说明在本软件系统的工作过程中不得不包含的人工处理过程（如果有的话）。
2.7尚未问决的问题
说明在概要设计过程中尚未解决而设计者认为在系统完成之前必须解决的各个问题。
3接口设计
3.1用户接口
说明将向用户提供的命令和它们的语法结构，以及软件的回答信息。
3.2外部接口
说明本系统同外界的所有接口的安排包括软件与硬件之间的接口、本系统与各支持软件之间的接口关系。
3.3内部接口
说明本系统之内的各个系统元素之间的接口的安排。
4运行设计
4.1运行模块组合
说明对系统施加不同的外界运行控制时所引起的各种不同的运行模块组合，说明每种运行所历经的内部模块和支持软件。
4.2运行控制
说明每一种外界的运行控制的方式方法和操作步骤。
4.3运行时间
说明每种运行模块组合将占用各种资源的时间。
5系统数据结构设计
5.1逻辑结构设计要点
给出本系统内所使用的每个数据结构的名称、标识符以及它们之中每个数据项、记录、文卷和系的标识、定义、长度及它们之间的层次的或表格的相互关系。
5.2物理结构设计要点
给出本系统内所使用的每个数据结构中的每个数据项的存储要求，访问方法、存取单位、存取的物理关系（索引、设备、存储区域）、设计考虑和保密条件。
5.3数据结构与程序的关系
说明各个数据结构与访问这些数据结构的形式:
6系统出错处理设计
6.1出错信息
用一览表的方式说朗每种可能的出错或故障情况出现时，系统输出信息的形式、含意及处理方法。
6.2补救措施
说明故障出现后可能采取的变通措施，包括：
a.        后备技术说明准备采用的后备技术，当原始系统数据万一丢失时启用的副本的建立和启动的技术，例如周期性地把磁盘信息记录到磁带上去就是对于磁盘媒体的一种后备技术；
b.        降效技术说明准备采用的后备技术，使用另一个效率稍低的系统或方法来求得所需结果的某些部分，例如一个自动系统的降效技术可以是手工操作和数据的人工记录；
c.        恢复及再启动技术说明将使用的恢复再启动技术，使软件从故障点恢复执行或使软件从头开始重新运行的方法。
6.3系统维护设计
说明为了系统维护的方便而在程序内部设计中作出的安排，包括在程序中专门安排用于系统的检查与维护的检测点和专用模块。 各个程序之间的对应关系，可采用如下的矩阵图的形式；

---

作者: baiyuxuan    时间: 2008-9-24 11:18
原题：
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
如何制定一份有效的，可行性高的测试规范？

提高测试团队工作的规范性也是保证软件质量的必要手段，所以每个公司都应该制定自己的测试规范，这份规范应该是贯穿整个软件开发周期的，也是所有开发和测试都应该遵循的，如何制定这样一份规范让大家都愿意遵其行事呢？这样的规范具体应该包含哪些内容呢？
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

说实话，这题本身就没有什么太大的价值。

1、所有开发和测试都应该遵循的话规范，是很难制定出来的。开发要遵循的，是研发规范；测试要遵循的，自然是测试规范；前期的需求、规格人员，则是相应的需求、规格分析设计规范；后期的客服，又有客服规范。各个部门的具体职责，情况都是完全不同的，因此想一份规范笼统概述，要么就是大而空，没有实际价值；要么就是过于繁琐细致，以致于失去其“规”的价值。

2、如何制定测试规范？？
简单而言，结合你所在公司的实际情况，未来的发展规划，业务重点，潜在客户的客观需求，行业的可能发展方向，业界的已有通行规范来制定。
这事说起来当然很简单，但实际实行的时候，就会遇到几个问题：
1）公司的高层的重视、支持程度
如果你所在公司的领导层根本不重视测试，或者对测试没有什么想法，那么你测试规范制定得再好，再完美，也等于废纸，甚或在现在的电子化办公时代，连废纸都不如。而很不幸，在国内而言，测试的受重视程度，在绝大多数公司，都是嘴上喊得响亮，行动上拖拖拉拉，毫无效率与目标，也就是说，你没有高层的真正的实际支持，你之后所作一切，都将是白费。那么具体应该有什么样的支持？我个人从业经验而言，觉得需要以下几点：
（1）权
足够的执行权力，领导权力，约束权力，推行权力，奖惩权力，是测试规范在制定后能真正贯彻、有效切实实施的保证
（2）人
合理的，有用的，实际的人力资源，是制定、贯彻、实施、监控、监督、改进测试规范的实际保障
（3）物
包括各类软件、硬件的支持，这里包括下载、购买相应的参考标准、参考资料、注册参加某些特定的会员、对内部人员的培训等等，都属于物力上支持
当然，我说从权、人、物上获得支持，并不是制定测试规范，包括后续的贯彻、实施、监控、改进等，是无限制的支持，本身的监管和限制，也都是矛盾对立统一的，是相辅相成的。
2）情况的不明确
很多公司，在制定这样那样的规范（不局限于测试规范）时，总是想着一下子覆盖所有的情况，满足所有的条件，解决所有的问题，结果造成了大而空，细而乱的规范，最后无法执行、实施、监控、改进而形同废弃。进而导致高层领导从此对此类规范失去信心，只相信人本位管理。在制定规范之前，需要先明确当前的自身状况，问题，为什么要制定这规范，制定这规范是为了解决什么问题，预期能够解决到什么程度，可能需要投入哪些资源、成本，预期如何实施等。说实话，制定规范并不是一蹴而就的事情。
3）制定者本身的能力问题
规范的制定者本身的能力、经验、甚至资历的不足，会限制、约束、甚至直接摧毁整个规范的制定。通常而言，应该是建立一个规范制定小组，由至少一个高层领导参与（不管是直接参与，还是作为名誉参与，作用在于起到对规范制定小组或委员会的权威性的认可），所有相关部门最低限度，至少派出 1 名代表，直接相关主要部门不少于 3 名代表。代表的应选择从业经验丰富，技术全面，思维敏捷，细致的人。如情况允许，可以邀请、聘请相关的咨询、管理专家，甚至你的主要大客户的代表参与到这个规范制定小组中。

当然，仅就规范的制定而言，会遇到的问题还很多很多，以上列举的也只是常见的。顺便说一句，在规范制定时的争吵现象是不可避免的，此时通常的做法有几类，表决式，少数服从多数式，领导一票决定式，外来和尚念经式，这个一般取决于具体企业的企业文化。

3、这样的规范具体应该包含哪些内容呢？
这个，我只能先 -_-!!! 真正要说具体的内容，请 Google 或 Baidu “测试规范”关键字，然后你会获得大量的范例
具体包含的内容，简单而言，就是指导、规定、约束、限制。
指导：就是指导相应的人员如何操作，完成相应的工作，任务。
规定：就是要求相应的人员必须履行的职责。
约束：就是对相应的人员的工作中可能出现的问题的提前预防针。
限制：就是对相应的人员的禁止性措施。
其实，具体规范应该的包含内容，还是与具体公司的实际情况相挂钩的。A 公司可能完全限制人员连接 Internet， B 公司就变成有条件的限制， C 公司则完全不限制。

规范制定完成之后，具体的实施、监督、监控、监管、对实施过程中出现的问题和收集到的建议/意见的改进，才是真正的难点和麻烦之处。

[ 本帖最后由 baiyuxuan 于 2008-9-24 11:20 编辑 ]

---

作者: inksong    时间: 2008-9-24 11:19
标题: 软件需求说明书的规范
软件需求说明书的规范
1引言
1.1编写目的
说明编写这份软件需求说明书的目的，指出预期的读者。
1.2背景
说明：
a．        待开发的软件系统的名称；
b．        本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络；
c．        该软件系统同其他系统或其他机构的基本的相互来往关系。
1.3定义
列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
1.4参考资料
列出用得着的参考资料，如：
a．        本项目的经核准的计划任务书或合同、上级机关的批文；
b．        属于本项目的其他已发表的文件；
c．        本文件中各处引用的文件、资料、包括所要用到的软件开发标准。 列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
2任务概述
2.1目标
叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。|
2.2用户的特点
列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件的预期使甩频度。这些是软件设计工作的重要约束
2.3假定和约束
列出进行本软件开发工作的假定和约束，例如经费限制、开发期限等。
3需求规定
3.1对功能的规定
用列表的方式（例如IPO表即输入、处理、输出表的形式），逐项定量和定性地叙述对软件所提出的功能要求，说明输入什么量、经怎样的处理、得到什么输出，说明软件应支持的终端数和应支持的并行操作的用户数。
3.2对性能的规定
3.2.1精度
说明对该软件的输入、输出数据精度的要求，可能包括传输过程中的精度。
3.2.2时间特性要求
说明对于该软件的时间特性要求，如对：
a．        响应时间；
b．        更新处理时间；
c．        数据的转换和传送时间；
d．        解题时间；等的要求。
3.2.3灵活性
说明对该软件的灵活性的要求，即当需求发生某些变化时，该软件对这些变化的适应能力，如：
a．        操作方式上的变化；
b．        运行环境的变化；
c．        同其他软件的接口的变化；
d．        精度和有效时限的变化；
e．        计划的变化或改进。
对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。
3.3输人输出要求
解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精度等。对软件的数据输出及必须标明的控制输出量进行解释并举例，包括对硬拷贝报告（正常结果输出、状态输出及异常输出）以及图形或显示报告的描述。
3.4数据管理能力要求
说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的增长对数据及其分量的存储要求作出估算。
3.5故障处理要求
列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。
3.6其他专门要求
如用户单位对安全保密的要求，对使用方便的要求，对可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求等。
4运行环境规定
4.1设备
列出运行该软件所需要的硬设备。说明其中的新型设备及其专门功能，包括：
a．        处理器型号及内存容量；
b．        外存容量、联机或脱机、媒体及其存储格式，设备的型号及数量；
c．        输入及输出设备的型号和数量，联机或脱机；
d．        数据通信设备的型号和数量；
e．        功能键及其他专用硬件
4.2支持软件
列出支持软件,包括要用到的操作系统、编译（或汇编）程序、测试支持软件等。
4.3接口
说明该软件同其他软件之间的接口、数据通信协议等。
4.4控制
说明控制该软件的运行的方法和控制信号，并说明这些控制信号的来源。

---

作者: inksong    时间: 2008-9-24 11:19
标题: 详细设计说明书的规范
详细设计说明书的规范
1引言
1.1编写目的
说明编写这份详细设计说明书的目的，指出预期的读者。
1.2背景
说明：
a．        待开发软件系统的名称；
b．        本项目的任务提出者、开发者、用户和运行该程序系统的计算中心。
1.3定义
列出本文件中用到专门术语的定义和外文首字母组词的原词组。
1.4参考资料
列出有关的参考资料，如：
a．        本项目的经核准的计划任务书或合同、上级机关的批文；
b．        属于本项目的其他已发表的文件；
c．        本文件中各处引用到的文件资料，包括所要用到的软件开发标准。列出这些文件的标题、文件编号、发表日期和出版单位，说明能够取得这些文件的来源。
2程序系统的结构
用一系列图表列出本程序系统内的每个程序（包括每个模块和子程序）的名称、标识符和它们之间 的层次结构关系。
3程序1（标识符）设计说明
从本章开始，逐个地给出各个层次中的每个程序的设计考虑。以下给出的提纲是针对一般情况的。对于一个具体的模块，尤其是层次比较低的模块或子程序，其很多条目的内容往往与它所隶属的上一层 模块的对应条目的内容相同，在这种情况下，只要简单地说明这一点即可。
3.1程序描述
给出对该程序的简要描述，主要说明安排设计本程序的目的意义，并且，还要说明本程序的特点（如 是常驻内存还是非常驻？是否子程序？是可重人的还是不可重人的？有无覆盖要求？是顺序处理还是并发处理等）。
3.2功能
说明该程序应具有的功能，可采用IPO图（即输入一处理一输出图）的形式。
3.3性能
说明对该程序的全部性能要求，包括对精度、灵活性和时间特性的要求。
3.4输人项
给出对每一个输入项的特性，包括名称、标识、数据的类型和格式、数据值的有效范围、输入的方式。数量和频度、输入媒体、输入数据的来源和安全保密条件等等。
3.5输出项
给出对每一个输出项的特性，包括名称、标识、数据的类型和格式，数据值的有效范围，输出的形式、数量和频度，输出媒体、对输出图形及符号的说明、安全保密条件等等。
3.6算法
详细说明本程序所选用的算法，具体的计算公式和计算步骤。
3.7流程逻辑
用图表（例如流程图、判定表等）辅以必要的说明来表示本程序的逻辑流程。
3.8接口
用图的形式说明本程序所隶属的上一层模块及隶属于本程序的下一层模块、子程序，说明参数赋值和调用方式，说明与本程序相直接关联的数据结构（数据库、数据文卷）。
3.9存储分配
根据需要，说明本程序的存储分配。
3.10注释设计
说明准备在本程序中安排的注释，如：
a．        加在模块首部的注释；
b．        加在各分枝点处的注释；
c．        对各变量的功能、范围、缺省条件等所加的注释；
d．        对使用的逻辑所加的注释等等。
3.11限制条件
说明本程序运行中所受到的限制条件。
3.12测试计划
说明对本程序进行单体测试的计划，包括对测试的技术要求、输入数据、预期结果、进度安排、人员职责、设备条件驱动程序及桩模块等的规定。
3.13尚未解决的问题
说明在本程序的设计中尚未解决而设计者认为在软件完成之前应解决的问题。
4程序2（标识符）设计说明
用类似F．3的方式，说明第2个程序乃至第N个程序的设计考虑。
......

---

作者: inksong    时间: 2008-9-24 11:20
标题: 可行性研究报告的规范
可行性研究报告的规范
1引言
1.1编写目的
说明编写本可行性研究报告的目的，指出预期的读者。
1.2背景
说明：
A.        所建议开发的软件系统的名称；
B.        本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络；
C.        该软件系统同其他系统或其他机构的基本的相互来往关系。
1.3定义
列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
1.4参考资料
列出用得着的参考资料，如：
1.        本项目的经核准的计划任务书或合同、上级机关的批文；
2.        属于本项目的其他已发表的文件；
3.        本文件中各处引用的文件、资料，包括所需用到的软件开发标准。
列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
2可行性研究的前提
说明对所建议的开发项目进行可行性研究的前提，如要求、目标、假定、限制等。
2.1要求
说明对所建议开发的软件的基本要求，如：
A.        功能；
B.        性能；
C.        输出如报告、文件或数据，对每项输出要说明其特征，如用途、产生频度、接口以及分发对象；
D.        输入说明系统的输入，包括数据的来源、类型、数量、数据的组织以及提供的频度；
E.        处理流程和数据流程用图表的方式表示出最基本的数据流程和处理流程，并辅之以叙述；
F.        在安全与保密方面的要求；
G.        同本系统相连接的其他系统；
H.        完成期限。
2.2目标
说明所建议系统的主要开发目标，如：
A.        人力与设备费用的减少；
B.        处理速度的提高；
C.        控制精度或生产能力的提高；
D.        管理信息服务的改进；
E.        自动决策系统的改进；
F.        人员利用率的改进。
2.3条件、假定和限制
说明对这项开发中给出的条件、假定和所受到的限制，如：
a．        所建议系统的运行寿命的最小值；
b．        进行系统方案选择比较的时间；
c．        经费、投资方面的来源和限制；
d．        法律和政策方面的限制；
e．        硬件、软件、运行环境和开发环境方面的条件和限制；
f．        可利用的信息和资源；
g．        系统投入使用的最晚时间。
2.4进行可行性研究的方法
说明这项可行性研究将是如何进行的，所建议的系统将是如何评价的。摘要说明所使用的基本方法 和策略，如调查、加权、确定模型、建立基准点或仿真等。
2.5评价尺度
说明对系统进行评价时所使用的主要尺度，如费用的多少、各项功能的优先次序、开发时间的长短 及使用中的难易程度。
3对现有系统的分析
这里的现有系统是指当前实际使用的系统，这个系统可能是计算机系统，也可能是一个机械系统甚 至是一个人工系统。
分析现有系统的目的是为了进一步阐明建议中的开发新系统或修改现有系统的必要性。
3.1处理流程和数据流程
说明现有系统的基本的处理流程和数据流程。此流程可用图表即流程图的形式表示，并加以叙述。
3.2工作负荷
列出现有系统所承担的工作及工作量。
3.3费用开支
列出由于运行现有系统所引起的费用开支，如人力、设备、空间、支持性服务、材料等项开支以及开 支总额。
3.4人员
列出为了现有系统的运行和维护所需要的人员的专业技术类别和数量。
3.5设备
列出现有系统所使用的各种设备。
3.6局限性
列出本系统的主要的局限性，例如处理时间赶不上需要，响应不及时，数据存储能力不足，处理功能 不够等。并且要说明，为什么对现有系统的改进性维护已经不能解决问题。
4所建议的系统
本章将用来说明所建议系统的目标和要求将如何被满足。
4.1对所建议系统的说明
概括地说明所建议系统，并说明在第2章中列出的那些要求将如何得到满足，说明所使用的基本方法及理论根据。
4.2处理流程和数据流程
给出所建议系统的处理流程和数据流程。
4.3改进之处
按2.2条中列出的目标，逐项说明所建议系统相对于现存系统具有的改进。
4.4影响
说明在建立所建议系统时，预期将带来的影响，包括：
4.4.1对设备的影响
说明新提出的设备要求及对现存系统中尚可使用的设备须作出的修改。
4.4.2对软件的影响
说明为了使现存的应用软件和支持软件能够同所建议系统相适应。而需要对这些软件所进行的修改和补充。
4.4.3对用户单位机构的影响
说明为了建立和运行所建议系统，对用户单位机构、人员的数量和技术水平等方面的全部要求。
4.4.4对系统运行过程的影响
说明所建议系统对运行过程的影响，如：
a．        用户的操作规程；
b．        运行中心的操作规程；
c．        运行中心与用户之间的关系；
d．        源数据的处理；
e．        数据进入系统的过程；
f．        对数据保存的要求，对数据存储、恢复的处理；
g．        输出报告的处理过程、存储媒体和调度方法；
h．        系统失效的后果及恢复的处理办法。
4.4.5对开发的影响
说明对开发的影响，如：
a.        为了支持所建议系统的开发，用户需进行的工作；
b.        为了建立一个数据库所要求的数据资源；
c.        为了开发和测验所建议系统而需要的计算机资源；
d.        所涉及的保密与安全问题。
4.4.6对地点和设施的影响
说明对建筑物改造的要求及对环境设施的要求。
4.4.7对经费开支的影响
扼要说明为了所建议系统的开发，设计和维持运行而需要的各项经费开支。
4.5局限性
说明所建议系统尚存在的局限性以及这些问题未能消除的原因。
4.6技术条件方面的可行性
本节应说明技术条件方面的可行性，如：
a．        在当前的限制条件下，该系统的功能目标能否达到；
b．        利用现有的技术，该系统的功能能否实现；
c．        对开发人员的数量和质量的要求并说明这些要求能否满足；
d．        在规定的期限内，本系统的开发能否完成。
5可选择的其他系统方案
扼要说明曾考虑过的每一种可选择的系统方案，包括需开发的和可从国内国外直接购买的，如果没有供选择的系统方案可考虑，则说明这一点。
5.1可选择的系统方案1
参照第4章的提纲，说明可选择的系统方案1，并说明它未被选中的理由。
5.2可选择的系统方案2
按类似5.1条的方式说明第2个乃至第n个可选择的系统方案。
......
6投资及效益分析
6.1支出
对于所选择的方案，说明所需的费用。如果已有一个现存系统，则包括该系统继续运行期间所需的费用。
6.1.1基本建设投资
包括采购、开发和安装下列各项所需的费用，如：
a.        房屋和设施；
b.        ADP设备；
c.        数据通讯设备；
d.        环境保护设备；
e.        安全与保密设备；
f.        ADP操作系统的和应用的软件；
g.        数据库管理软件。
6.1.2其他一次性支出
包括下列各项所需的费用，如：
a．        研究（需求的研究和设计的研究）；
b．        开发计划与测量基准的研究；
c．        数据库的建立；
d．        ADP软件的转换；
e．        检查费用和技术管理性费用；
f．        培训费、旅差费以及开发安装人员所需要的一次性支出；
g．        人员的退休及调动费用等。
6.1.3非一次性支出
列出在该系统生命期内按月或按季或按年支出的用于运行和维护的费用，包括：
a．        设备的租金和维护费用；
b．        软件的租金和维护费用；
c．        数据通讯方面的租金和维护费用；
d．        人员的工资、奖金；
e．        房屋、空间的使用开支；
f．        公用设施方面的开支；
g．        保密安全方面的开支；
h．        其他经常性的支出等。
6.2收益
对于所选择的方案，说明能够带来的收益，这里所说的收益，表现为开支费用的减少或避免、差错的减少、灵活性的增加、动作速度的提高和管理计划方面的改进等，包括；
6.2.1一次性收益
说明能够用人民币数目表示的一次性收益，可按数据处理、用户、管理和支持等项分类叙述，如：
a．        开支的缩减包括改进了的系统的运行所引起的开支缩减，如资源要求的减少，运行效率的改进，数据进入、存贮和恢复技术的改进，系统性能的可监控，软件的转换和优化，数据压缩技术的采用，处理的集中化／分布化等；
b．        价值的增升包括由于一个应用系统的使用价值的增升所引起的收益，如资源利用的改进，管理和运行效率的改进以及出错率的减少等；
c．        其他如从多余设备出售回收的收入等。
6.2.2非一次性收益
说明在整个系统生命期内由于运行所建议系统而导致的按月的、按年的能用人民币数目表示的收益，包括开支的减少和避免。
6.2.3不可定量的收益
逐项列出无法直接用人民币表示的收益，如服务的改进，由操作失误引起的风险的减少，信息掌握情况的改进，组织机构给外界形象的改善等。有些不可捉摸的收益只能大概估计或进行极值估计（按最好和最差情况估计）。
6.3收益／投资比
求出整个系统生命期的收益／投资比值。
6.4投资回收周期
求出收益的累计数开始超过支出的累计数的时间。
6.5敏感性分析
所谓敏感性分析是指一些关键性因素如系统生命期长度、系统的工作负荷量、工作负荷的类型与这些不同类型之间的合理搭配、处理速度要求、设备和软件的配置等变化时，对开支和收益的影响最灵敏的范围的估计。在敏感性分析的基础上做出的选择当然会比单一选择的结果要好一些。
7社会因素方面的可行性
本章用来说明对社会因素方面的可行性分析的结果，包括：
7.1法律方面的可行性
法律方面的可行性问题很多，如合同责任、侵犯专利权、侵犯版权等方面的陷井，软件人员通常是不熟悉的，有可能陷入，务必要注意研究。
7.2使用方面的可行性
例如从用户单位的行政管理、工作制度等方面来看，是否能够使用该软件系统；从用户单位的工作人员的素质来看，是否能满足使用该软件系统的要求等等，都是要考虑的。
8结论
在进行可行性研究报告的编制时，必须有一个研究的结论。结论可以是：
a．        可以立即开始进行；
b．        需要推迟到某些条件（例如资金、人力、设备等）落实之后才能开始进行；
c．        需要对开发目标进行某些修改之后才能开始进行；
d．        不能进行或不必进行（例如因技术不成熟、经济上不合算等）。

---

作者: inksong    时间: 2008-9-24 11:23
标题: 模块开发卷宗的规范
模块开发卷宗的规范
1标题
软件系统名称和标识符
模块名称和标识符（如果本卷宗包含多于一个的模块，则用这组模块的功能标识代替模块名）
程序编制员签名
卷宗的修改文本序号
修改完成日期
卷宗序号（说明本卷宗在整个卷宗中的序号）
编排日期（说明整个卷宗最近的一次编排日期）
2模块开发情况表
3功能说明
扼要说明本模块（或本组模块）的功能，主要是输入、要求的处理、输出。可以从系统设计说明书中摘录。同时列出在软件需求说明书中对这些功能的说明的章、条、款。
4设计说明
说明本模块（或本组模块）的设计考虑，包括：
a．        在系统设计说明书中有关对本模块（或本组模块）设计考虑的叙述，包括本模块在软件系统中所处的层次，它同其他模块的接口；
b．        在程序设计说明书中有关对本模块（或本组模块）的设计考虑，包括本模块的算法、处理流程、牵涉到的数据文卷设计限制、驱动方式和出错信息等；
c．        在编制目前已通过全部测试的源代码时实际使用的设计考虑。
5原代码清单
要给出所产生的本模块（或本组模块）的第一份无语法错的源代码清单以及已通过全部测试的当前有效的源代码清单。
6测试说明
说明直接要经过本模块（或本组模块）的每一项测试，包括这些测试各自的标识符和编号、进行这些测试的目的、所用的配置和输入、预期的输出及实际的输出。
7复审的结论
把实际测试的结果，同软件需求说明书、系统设计说明书、程序设计说明书中规定的要求进行比较和给出结论。


数据库设计说明书的规范
1引言
1.1编写目的
说明编写这份数据库设计说明书的目的，指出预期的读者。
1.2背景
说明：
a．        说明待开发的数据库的名称和使用此数据库的软件系统的名称；
b．        列出该软件系统开发项目的任务提出者、用户以及将安装该软件和这个数据库的计算站（中心）。
1.3定义
列出本文件中用到的专门术语的定义、外文首字母组词的原词组。
1.4参考资料
列出有关的参考资料：
a．        本项目的经核准的计划任务书或合同、上级机关批文；
b．        属于本项目的其他已发表的文件；
c．        本文件中各处引用到的文件资料，包括所要用到的软件开发标准。
列出这些文件的标题、文件编号、发表日期和出版单位，说明能够取得这些文件的来源。
2外部设计
2.1标识符和状态
联系用途，详细说明用于唯一地标识该数据库的代码、名称或标识符，附加的描述性信息亦要给出。如果该数据库属于尚在实验中、尚在测试中或是暂时使用的，则要说明这一特点及其有效时间范围。
2.2使用它的程序
列出将要使用或访问此数据库的所有应用程序，对于这些应用程序的每一个，给出它的名称和版本号。
2.3约定
陈述一个程序员或一个系统分析员为了能使用此数据库而需要了解的建立标号、标识的约定，例如用于标识数据库的不同版本的约定和用于标识库内各个文卷、、记录、数据项的命名约定等。
2.4专门指导
向准备从事此数据库的生成、从事此数据库的测试、维护人员提供专门的指导，例如将被送入数据库的数据的格式和标准、送入数据库的操作规程和步骤，用于产生、修改、更新或使用这些数据文卷的操作指导。如果这些指导的内容篇幅很长，列出可参阅的文件资料的名称和章条。
2.5支持软件
简单介绍同此数据库直接有关的支持软件，如数据库管理系统、存储定位程序和用于装入、生成、修 改、更新数据库的程序等。说明这些软件的名称、版本号和主要功能特性，如所用数据模型的类型、允许 的数据容量等。列出这些支持软件的技术文件的标题、编号及来源。
3结构设计
3.1概念结构设计
说明本数据库将反映的现实世界中的实体、属性和它们之间的关系等的原始数据形式，包括各数据项、记录、系、文卷的标识符、定义、类型、度量单位和值域，建立本数据库的每一幅用户视图。
3.2逻辑结构设计
说明把上述原始数据进行分解、合并后重新组织起来的数据库全局逻辑结构，包括所确定的关键字和属性、重新确定的记录结构和文卷结构、所建立的各个文卷之间的相互关系，形成本数据库的数据库管理员视图。
3.3物理结构设计
建立系统程序员视图，包括：
a．        数据在内存中的安排，包括对索引区、缓冲区的设计；
b．        所使用的外存设备及外存空间的组织，包括索引区、数据块的组织与划分；
c．        访问数据的方式方法。
4运用设计
4.1数据字典设计
对数据库设计中涉及到的各种项目，如数据项、记录、系、文卷、模式、子模式等一般要建立起数据字典，以说明它们的标识符、同义名及有关信息。在本节中要说明对此数据字典设计的基本考虑。
4.2安全保密设计
说明在数据库的设计中，将如何通过区分不同的访问者、不同的访问类型和不同的数据对象，进行分别对待而获得的数据库安全保密的设计考虑。

数据要求说明书的规范
1引言
1.1编写目的
说明编写这份数据要求说明书的目的，指出预期的读者。
1.2背景
说明：
a.        待开发软件系统的名称；
b.        b.列出本项目的任务提出者、开发者、用户以及将运行该项软件的计算站（中心）或计算机网络系统。
1.3定义
列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
1.4参考资料
列出有关的参考资料，如：
a.        本项目的经核准的计划任务书或合同，上级机关的批文；
b.        属于本项目的其他已发表文件；
c.        本文件中各处引用的文件、资料，包括所要用到的软件开发标准。列出这些文件的标题、文件编号、发表日期和出版单位。说明能够得到这些文件资料的来源。
2数据的逻辑描述
对数据进行逻辑描述时可把数据分为动态数据和静态数据。所谓静态数据，指在运行过程中主要作为参考的数据，它们在很长的一段时间内不会变化，一般不随运行而改变。所谓动态数据，包括所有在运行中要发生变化的数据以及在运行中要输入、输出的数据。进行描述时应把各数据元素逻辑地分成若干组，列如函数、源数据或对于其应用更为恰当的逻辑分组。给出每一数据元的名称（包括缩写和代码）、定义（或物理意义）度量单位、值域、格式和类型等有关信息。
2.1静态数据
列出所有作为控制或参考用的静态数据元素。
2.2动态输人数据
列出动态输入数据元素（包括在常规运行中或联机操作中要改变的数据）。
2.3动态输出数据
列出动态输出数据元素（包括在常规运行中或联机操作中要改变的数据）。
2.4内部生成数据
列出向用户或开发单位中的维护调试人员提供的内部生成数据。
2.5数据约定
说明对数据要求的制约。逐条列出对进一步扩充或使用方面的考虑而提出的对数据要求的限制（容 量、文卷、记录和数据元的个数的最大值）。对于在设计和开发中确定是临界性的限制更要明确指出。
3数据的采集
3.1要求和范围
按数据元的逻辑分组来说明数据采集的要求和范围，指明数据的采集方法，说明数据采集工作的承担者是用户还是开发者。具体的内容包括：
a.        输入数据的来源，例如是单个操作员、数据输入站，专业的数据输入公司或它们的一个分组；
b.        数据输入（指把数据输入处理系统内部）所用的媒体和硬设备。如果只有指定的输入点的输入才是合法的，则必须对此加以说明；
c.        接受者说明输出数据的接受者；
d.        输出数据的形式和设备列出输出数据的形式和硬设备。无论接受者将接收到的数据是打印输出，还是CRT上的一组字符、一帧图形，或一声警铃，或向开关线圈提供的一个电脉冲，或常用介质如磁盘、磁带、穿孔卡片等，均应具体说明；
e.        数据值的范围给出每一个数据元的合法值的范围；
f.        量纲给出数字的度量单位、增量的步长、零点的定标等。在数据是非数字量的情况下，要给出每一种合法值的形式和含意；
g.        更新和处理的频度给出预定的对输入数据的更新和处理的频度。如果数据的输入是随机的，应给出更新处理的频度的平均值，或变化情况的某种其他度量。
3.2输人的承担者
说明预定的对数据输入工作的承担者。如果输入数据同某一接口软件有关，还应说明该接口软件的来源。
3.3预处理
对数据的采集和预处理过程提出专门的规定，包括适合应用的数据格式、预定的数据通信媒体和对输入的时间要求等。对于需经模拟转换或数字转换处理的数据量，要给出转换方法和转换因子等有关信息，以便软件系统使用这些数据。
3.4影响
说明这些数据要求对于设备、软件、用户、开发单位所可能产生的影响，例如要求用户单位增设某个机构等。

---

作者: inksong    时间: 2008-9-24 11:24
标题: 文件给制实施规定的实例的规范
尽管在文件编制中存在着很多灵活性，然而，文件的编制确实是非常必要的，其意义如前所述。为了控制这种灵活性，保证文件编制能达到应该达到的目的，对于具体的软件开发任务，应编制的文件的种类、详细程度应取决于承担开发单位的管理能力、任务的规模、复杂性和成败风险等因素。一个软件开发单位应该根据本单位经营承包的应用软件的专业特点和本单位的管理能力，制定一个文件编制实施规定，说明在什么情况下应该编制哪些文件。由于国内目前在这方面还缺乏成熟的经验，这里提供参考国外经验制定的两个例子，用以向国内软件开发单位说明如何建立这种实施规定，使项目负责人能确定本项目开发过程中应编制的文件的种类。当然，例子毕竟只是例子，这两个例子各自都不免有其片面性，它们两者之间也不免有不一致之处，之所以列出来无非是供国内软件开发单位参考。
例1：
此例规定用求和法来确定应编制的文件。该方法的要点是提出十二个考虑因素来衡量一个应用软，件，每个因素可能取值的范围是互至5。任务负责人可用这十二个因素对所要开发的程序进行衡量，确定每个因素的具体值。把这十二个因素的值相加，得到一个总和。然后由这个总和的值来确定应该编制的文件的种类。使用这个方法的具体过程如下：
a.        按表OI中的十二个因素衡量所要开发的程序，得到每个因素的值；
b.        把衡量所得的各个因素的值相加，得总和之值；
c.        根据总和之值，从表OZ查出应编制的文件的种类。
表1文件编制的十二项衡量因素
序号        因素        因素取值准则
                1        2        3        4        5
1        创造性要求        没有——在不同的设备上重编程序        很少——具有严格的要求        有限——具有新的接口        相当多——应用现有的技巧        重大的——应用先进的技巧
2        通用程度        很强的限制——单一目标        有限制——功能的范围是参量化的        有限的灵活性允许格式上有某些变化        多用途，灵活的格式有一个主题领域        很灵活——能在不同的设备上处理范围广泛的主题
3        工作范围        局部单位        分指挥部        单个指挥部        多个指挥部        国防部，世界范围
4        目标范围的变化        没有        极少        偶尔有        经常        不断
5        设备复杂性        单机，常规处理        单机，常规处理，扩充的外设系统        多机，标准外设系统        多机，复杂的外设系统        主机控制系统，多机，自动I/O和显示
6        人员        1～2人        3～5人        5～10人        10～18人        18人以上
7        开发投资        6人月以下        6人月至3人年        3人年至10人年        10人年至30人年        30人年以上
8        重要程度        数据处理        常规过程控制        人身安全        单位成败        国家安全
9        对程序改变的完成时间要求        2周以上        1～2周        3～7天        1～3天        24小时以内
10        对数据输入的响应时间要求        2周以上        1～2周        1～7天        1～24小时        60分钟内
11        程序语言        高级语言        高级语言带一些汇编        高级语言带相当多的汇编        汇编语言        机器语言
12        并行的软件开发        没有        有限        中等程度        很多        完全的并行开发
表1文件编制的十二项衡量因素
因素总和        可行性研究报告        项目开发计划        软件需求说明书        数据要求说明书        概要设计说明书        详细设计说明书        数据库设计说明书        用户手册（使用说明）        操作手册        模块开发卷宗        测试设计        测试分析报告        项目开发总结报告        开发制度月报
12～18*
14～24
24～38
38～50
48～60       

√
√
√        √
√
√
√
√       
√
√
√
√       
***
***
***
***       


√
√       



√       
***
***
***
***        √
√
√
√
√       

√
√
√       
√
√
√
√       
√
√
√
√       
**
**
√
√        √
√
√
√
√       
√
√
√
√
*在因素总和较低的情况下,项目开发总结报告的内容应包括：程序的主要功能、基本流程、测试结果和使用说明。
**测试分析报告应该写，但不必很正规。
***数据要求说明和数据库设计说明是否需要编写应根据所开发软件的实际需要来决定。
例2：
为了避免在软件开发中文件编制的不足或过分，一个简便的办法是把对软件文件的编制要求同软件的规模大小联系起来，这就是本例的出发点。软件的规模不妨分为四级：
1.        小规模软件源程序行数小于5000的软件；
2.        中规模软件源程序行数为10000～50000的软件；
3.        大规模软件源程序行数为100000—500000的软件；
4.        特大规模软件源程序行数大于500000的软件。
对上述的四级软件的文件编制要求分别列于表3。
至于源程序行数为5000～10000，50000～100000的软件，其文件编制要求介于两级之间，可根据一个软件产品的具体情况，由项目负责人参照表3的规定，确定需要编制的文件种类。
对于源程序行数大于500000的特大规模软件，可进一步把本指南规定的十四种文件按实际需要扩展成更多种类，这一点在本指南5.3.3已经提到。
表3产品文件体系
(这里有个图，我不会传)

---

作者: inksong    时间: 2008-9-24 11:25
标题: 开发进度月报的规范
l标题
开发中的软件系统的名称和标识符
分项目名称和标识符
分项目负责人签名
本期月报编写人签名
本期月报的编号及所报告的年月
2工程进度与状态
2.1进度
列出本月内进行的各项主要活动，并且说明本月内遇到的重要事件，这里所说的重要事件是指一个开发阶段（即软件生存周期内各个阶段中的某一个，例如需求分析阶段）的开始或结束，要说明阶段名称及开始（或结束）的日期。
2.2状态
说明本月的实际工作进度与计划相比，是提前了、按期完成了、或是推迟了？如果与计划不一致，说 明原因及准备采取的措施。
3资额耗用与状态
3.1资额耗用
主要说明本月份内耗用的工时与机时。
3.1.1工时
分为三类：
a．        管理用工时包括在项目管理（制订计划、布置工作、收集数据、检查汇报工作等）方面耗用的工时；
b．        服务工时包括为支持项目开发所必须的服务工作及非直接的开发工作所耗用的工时；
c．        开发用工时要分各个开发阶段填写。
3.1.2机时
说明本月内耗用的机时，以小时为单位，说明计算机系统的型号。
3.2状态
说明本月内实际耗用的资源与计划相比，是超出了、相一致、还是不到计划数？如果与计划不一致，说明原因及准备采取的措施。
4经费支出与状态
4.1经费支出
4.1.1支持性费用
列出本月内支出的支持性费用，一般可按如下七类列出，并给出本月支持费用的总和：
a.        房租或房屋折旧费；
b.        社工资、奖金、补贴；
c.        培训费包括给教师的酬金及教室租金；
d.        资料费包括复印及购买参考资料的费用；
e.        会议费召集有关业务会议的费用；
f.        旅差费；
g.        其他费用。
4.1.2设备购置费
列出本月内支出的设备购置费，一般可分如下三类：
a．        购买软件的名称与金额；
b．        购买硬设备的名称、型号、数量及金额；
c．        已有硬设备的折旧费。
4.2状态
说明本月内实际支出的经费与计划相比较，是超过了。相符合、还是不到计划数？如果与计划不一致，说明原因及准备采取的措施。
5下个月的工作计划
6建议
本月遇到的重要问题和应引起重视的问题以及因此产生的建议。

---

作者: inksong    时间: 2008-9-24 11:25
标题: 项目开发总结报告的规范
1引言
1.1编写目的
说明编写这份项目开发总结报告的目的，指出预期的阅读范围。
1.2背景
说明：
a．        本项目的名称和所开发出来的软件系统的名称；
b．        此软件的任务提出者、开发者、用户及安装此软件的计算中心。
1.3定义
列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
1.4参考资料
列出要用到的参考资料，如：
a．        本项目的已核准的计划任务书或合同、上级机关的批文；
b．        属于本项目的其他已发表的文件；
c．        本文件中各处所引用的文件、资料，包括所要用到的软件开发标准。列出这些文件的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
2实际开发结果
2.1产品
说明最终制成的产品，包括：
a．        程序系统中各个程序的名字，它们之间的层次关系，以千字节为单位的各个程序的程序量、存储媒体的形式和数量；
b．        程序系统共有哪几个版本，各自的版本号及它们之间的区别；
c．        每个文件的名称；
d．        所建立的每个数据库。 如果开发中制订过配置管理计划，要同这个计划相比较。
2.2主要功能和性能
逐项列出本软件产品所实际具有的主要功能和性能，对照可行性研究报告、项目开发计划、功能需求说明书的有关内容，说明原定的开发目标是达到了、未完全达到、或超过了。
2.3基本流程
用图给出本程序系统的实际的基本的处理流程。
2.4进度
列出原定计划进度与实际进度的对比，明确说明，实际进度是提前了、还是延迟了，分析主要原因。
2.5费用
列出原定计划费用与实际支出费用的对比，包括：
a.        工时，以人月为单位，并按不同级别统计；
b.        计算机的使用时间，区别CPU时间及其他设备时间；
c.        物料消耗、出差费等其他支出。
明确说明，经费是超出了、还是节余了，分析其主要原因。
3开发工作评价
3.1对生产效率的评价
给出实际生产效率，包括：
a．        程序的平均生产效率，即每人月生产的行数；
b．        文件的平均生产效率，即每人月生产的千字数；
并列出原订计划数作为对比。
3.2对产品质量的评价
说明在测试中检查出来的程序编制中的错误发生率，即每干条指令（或语句）中的错误指令数（或语句数）。如果开发中制订过质量保证计划或配置管理计划，要同这些计划相比较。
3.3对技术方法的评价
给出对在开发中所使用的技术、方法、工具、手段的评价。
3.4出错原因的分析
给出对于开发中出现的错误的原因分析。
4经验与教训
列出从这项开发工作中所得到的最主要的经验与教训及对今后的项目开发工作的建议。

---

作者: inksong    时间: 2008-9-24 11:26
标题: 用户手册的规范
1引言
1.1编写目的
说明编写这份用户手册的目的，指出预期的读者。
1.2背景
说明：
a.        这份用户手册所描述的软件系统的名称；
b.        该软件项目的任务提出者、开发者、用户（或首批用户）及安装此软件的计算中心。
1.3定义
列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
1.4参考资料
列出有用的参考资料，如：
a.        项目的经核准的计划任务书或合同、上级机关的批文；
b.        属于本项目的其他已发表文件；
c.        本文件中各处引用的文件、资料，包括所要用到的软件开发标准。列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够取得这些文件资料的来源。
2用途
2.1功能
结合本软件的开发目的逐项地说明本软件所具有各项功能以及它们的极限范围。
2.2性能
2.2.1精度
逐项说明对各项输入数据的精度要求和本软件输出数据达到的精度，包括传输中的精度要求。
2.2.2时间特性
定量地说明本软件的时间特性，如响应时间，更新处理时间，数据传输、转换时间，计算时间等。
2.2.3灵活性
说明本软件所具有的灵活性，即当用户需求（如对操作方式、运行环境、结果精度、时间特性等的要求）有某些变化时，本软件的适应能力。
2.3安全保密
说明本软件在安全、保密方面的设计考虑和实际达到的能力。
3运行环境
3.1硬设备
列出为运行本软件所要求的硬设备的最小配置，如：
a.        处理机的型号、内存容量；
b.        所要求的外存储器、媒体、记录格式、设备的型号和台数、联机／脱机；
c.        I／O设备（联机／脱机？）；
d.        数据传输设备和转换设备的型号、台数。
3.2支持软件
说明为运行本软件所需要的支持软件，如：
a．        操作系统的名称、版本号；
b．        程序语言的编译／汇编系统的名称和版本号；
c．        数据库管理系统的名称和版本号；
d．        其他支持软件。
3.3数据结构
列出为支持本软件的运行所需要的数据库或数据文卷。
4使用过程
在本章，首先用图表的形式说明软件的功能同系统的输入源机构、输出接收机构之间的关系。
4.1安装与初始化
一步一步地说明为使用本软件而需进行的安装与初始化过程，包括程序的存储形式、安装与初始化过程中的全部操作命令、系统对这些命令的反应与答复。表征安装工作完成的测试实例等。如果有的话，还应说明安装过程中所需用到的专用软件。
4.2输入
规定输入数据和参量的准备要求。
4.2.1输入数据的现实背景
说明输入数据的现实背景，主要是
a.        情况——例如人员变动、库存缺货；
b.        情况出现的频度——例如是周期性的、随机的、一项操作状态的函数；
c.        情况来源—一例如人事部门、仓库管理部门；
d.        输入媒体———例如键盘、穿孔卡片、磁带；
e.        限制——出于安全、保密考虑而对访问这些输入数据所加的限制；
f.        质量管理——例如对输入数据合理性的检验以及当输入数据有错误时应采取的措施，如建立出错情况的记录等；
g.        支配——例如如何确定输入数据是保留还是废弃，是否要分配给其他的接受者等。
4.2.2输入格式
说明对初始输入数据和参量的格式要求，包括语法规则和有关约定，如：
a.        长度—一例如字符数／行，字符数／项；
b.        格式基准——例如以左面的边沿为基准；
c.        标号——例如标记或标识符；
d.        顺序——例如各个数据项的次序及位置；
e.        标点——例如用来表示行、数据组等的开始或结束而使用的空格、斜线、星号、字符组等。
f.        词汇表——给出允许使用的字符组合的列表，禁止使用＊的字符组合的列表等；
g.        省略和重复——给出用来表示输人元素可省略或重复的表示方式；
h.        控制——给出用来表示输入开始或结束的控制信息。
4.2.3输入举例
为每个完整的输入形式提供样本，包括：
a．        控制或首部——例如用来表示输入的种类和类型的信息，标识符输入日期，正文起点和对所用编码的规定；
b．        主体——输入数据的主体，包括数据文卷的输入表述部分；
c．        尾部——用来表示输入结束的控制信息，累计字符总数等；
d．        省略——指出哪些输入数据是可省略的；
e．        重复——指出哪些输入数据是重复的。
4.3输出对每项输出作出说明
4.3.1输出数据的现实背景
说明输出数据的现实背景，主要是：
a．        使用——这些输出数据是给谁的，用来干什么；
b．        使用频度——例如每周的、定期的或备查阅的；
c．        媒体——打印、CRI显示、磁带、卡片、磁盘，
d．        质量管理—一例如关于合理性检验、出错纠正的规定；
e．        支配——例如如何确定输出数据是保留还是废弃，是否要分配给其他接受者等。
4.3.2输出格式
给出对每一类输出信息的解释，主要是：
a．        首部——如输出数据的标识符，输出日期和输出编号；
b．        主体——输出信息的主体，包括分栏标题；
c．        尾部——包括累计总数，结束标记。
4.3.3输出举例
为每种输出类型提供例子。对例子中的每一项，说明：
a．        定义——每项输出信息的意义和用途；
b．        来源——是从特定的输入中抽出、从数据库文卷中取出、或从软件的计算过程中得到；
c．        特性——输出的值域、计量单位、在什么情况下可缺省等。
4.4文卷查询
这一条的编写针对具有查询能力的软件，内容包括：同数据库查询有关的初始化、准备、及处理所需 要的详细规定，说明查询的能力、方式，所使用的命令和所要求的控制规定。
4.5出错处理和恢复
列出由软件产生的出错编码或条件以及应由用户承担的修改纠正工作。指出为了确保再启动和恢复的能力，用户必须遵循的处理过程。
4.6终端操作
当软件是在多终端系统上工作时，应编写本条，以说明终端的配置安排、连接步释、数据和参数输入步骤以及控制规定．说明通过终端操作进行查询、检索、修改数据文卷的能力、语言、过程以及辅助性程序等。

---

作者: inksong    时间: 2008-9-24 11:26
标题: 操作手册的规范
1引言
1.1编写目的
说明编写这份操作手册的目的，指出预期的读者。
1.2前景
说明：
a．        这份操作手册所描述的软件系统的名称；
b．        该软件项目的任务提出者、开发者、用户（或首批用户）及安装该软件的计算中心。
1.3定义
列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
1.4参考资料
列出有用的参考资料，如：
a．        本项目的经核准的计划任务书或合同、上级机关的批文；
b．        属于本项目的其他已发表的文件；
c．        本文件中各处引用的文件、资料，包括所列出的这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
2软件征述
2.1软件的结构
结合软件系统所具有的功能包括输入、处理和输出提供该软件的总体结构图表。
2.2程序表
列出本系统内每个程序的标识符、编号和助记名。
2.3文卷表
列出将由本系统引用、建立或更新的每个永久性文卷，说明它们各自的标识符、编号、助记名、存储媒体和存储要求。
3安装与初始化
一步一步地说明为使用本软件而需要进行的安装与初始化过程，包括程序的存载形式，安装与初始化过程中的全部操作命令，系统对这些命令的反应与答复，表征安装工作完成的测试实例等。如果有的话，还应说明安装过程中所需用到的专用软件。
4运行说明
所谓一个运行是指提供一个启动控制信息后，直到计算机系统等待另一个启动控制信息时为止的计算机系统执行的全部过程。
4.1运行表
列出每种可能的运行，摘要说明每个运行的目的，指出每个运行各自所执行的程序。
4.2运行步骤
说明从一个运行转向另一个运行以完成整个系统运行的步骤。
4.3运行1（标识符）说明
把运行1的有关信息，以对操作人员为最方便最有用的形式加以说明。
4.3.1运行控制
列出为本运行所需要”的运行流向控制的说明。
4.3.2操作信息
给出为操作中心的操作人员和管理人员所需要的信息，如：
a.        运行目的；
b.        操作要求；
c.        启动方法 如应请启动（由所遇到的请求信息启动）、预定时间启动、…，••等；
d.        预计的运行时间和解题时间；
e.        操作命令；
f.        与运行有联系的其他事项。
4.3.3输入一输出文卷
提供被本运行建立、更新或访问的数据文卷的有关信息，如：
a.        文卷的标识符或标号；
b.        记录媒体；
c.        存留的目录表；
d.        文卷的支配如确定保留或废弃的准则、是否要分配给其他接受者、占用硬设备的优先级以及保密控制等有关规定。
4.3.4输出文段
提供本软件输出的每一一个用于提示、说明、或应答的文段（包括“菜单”）的有关信息，如：
a.        文段的标识符；
b.        输出媒体（屏幕显示、打印、……）；
c.        文字容量；
d.        分发对象；
e.        保密要求。
4.3.5输出文段的复制
对由计算机产生，而后需用其他方法复制的那些文段提供有关信息，如：
a.        文段的标识符；
b.        复制的技术手段；
c.        纸张或其他媒体的规格；
d.        装订要求；
e.        分发对象；
f.        复制份数。
4.3.6恢复过程
说明本运行故障后的恢复过程。
4.4运行2（标识符）说明
用与本手册4.3条相类似的方式介绍另一个运行的有关信息。
5非常规过程
提供有关应急操作或非常规操作的必要信息，如出错处理操作、向后备系统的切换操作以及其他必须向程序维护人员交待的事项和步骤。
6远程操作
如果本软件能够通过远程终端控制运行，则在本章说明通过远程终端运行本软件的操作过程。

---

作者: inksong    时间: 2008-9-24 11:27
标题: 测试计划的规范
1引言
1.1编写目的
本测试计划的具体编写目的，指出预期的读者范围。
1.2背景
说明：
a．        测试计划所从属的软件系统的名称；
b．        该开发项目的历史，列出用户和执行此项目测试的计算中心，说明在开始执行本测试计划之前必须完成的各项工作。
1.3定义
列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
1.4参考资料
列出要用到的参考资料，如：
a．        本项目的经核准的计划任务书或合同、上级机关的批文；
b．        属于本项目的其他已发表的文件；
c．        本文件中各处引用的文件、资料，包括所要用到的软件开发标准。列出这些文件的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
2计划
2.1软件说明
提供一份图表，并逐项说明被测软件的功能、输入和输出等质量指标，作为叙述测试计划的提纲。
2.2测试内容
列出组装测试和确认测试中的每一项测试内容的名称标识符、这些测试的进度安排以及这些测试的内容和目的，例如模块功能测试、接口正确性测试、数据文卷存取的测试、运行时间的测试、设计约束和极限的测试等。
2.3测试1（标识符）
给出这项测试内容的参与单位及被测试的部位。
2.3.1进度安排
给出对这项测试的进度安排，包括进行测试的日期和工作内容（如熟悉环境。培训、准备输入数据等）。
2.3.2条件
陈述本项测试工作对资源的要求，包括：
a．        设备所用到的设备类型、数量和预定使用时间；
b．        软件列出将被用来支持本项测试过程而本身又并不是被测软件的组成部分的软件，如测试驱动程序、测试监控程序、仿真程序、桩模块等等；
c．        人员列出在测试工作期间预期可由用户和开发任务组提供的工作人员的人数。技术水平及有关的预备知识，包括一些特殊要求，如倒班操作和数据键入人员。
2.3.3测试资料
列出本项测试所需的资料，如：
a．        有关本项任务的文件；
b．        被测试程序及其所在的媒体；
c．        测试的输入和输出举例；
d．        有关控制此项测试的方法、过程的图表。
2.3.4测试培训
说明或引用资料说明为被测软件的使用提供培训的计划。规定培训的内容、受训的人员及从事培训的工作人员。
2.4测试2（标识符）
用与本测试计划2.3条相类似的方式说明用于另一项及其后各项测试内容的测试工作计划。
3测试设计说明
3.1测试1（标识符）
说明对第一项测试内容的测试设计考虑。
3.1.1控制
说明本测试的控制方式，如输入是人工、半自动或自动引入、控制操作的顺序以及结果的记录方法。
3.1.2输入
说明本项测试中所使用的输入数据及选择这些输入数据的策略。
3.1.3输出
说明预期的输出数据，如测试结果及可能产生的中间结果或运行信息。
3.1.4过程
说明完成此项测试的一个个步骤和控制命令，包括测试的准备、初始化、中间步聚和运行结束方式。
3.2测试2（标识符）
用与本测试计划3.l条相类似的方式说明第2项及其后各项测试工作的设计考虑。
4评价准则
4.1范围
说明所选择的测试用例能够接查的范围及其局限性。
4.2数据整理
陈述为了把测试数据加工成便于评价的适当形式，使得测试结果可以同，已知结果进行比较而要用到的转换处理技术，如手工方式或自动方式；如果是用自动方式整理数据，还要说明为进行处理而要用到的硬件、软件资源。
4.3尺度
说明用来判断测试工作是否能通过的评价尺度，如合理的输出结果的类型、测试输出结果与预期输出之间的容许偏离范围、允许中断或停机的最大次数。

---

作者: inksong    时间: 2008-9-24 11:27
标题: 测试分析报告的规范
1引言
1.1编写目的
说明这份测试分析报告的具体编写目的，指出预期的阅读范围。
1.2背景
说明：
a.        被测试软件系统的名称；
b.        该软件的任务提出者、开发者、用户及安装此软件的计算中心，指出测试环境与实际运行环境 之间可能存在的差异以及这些差异对测试结果的影响。
1.3定义
列出本文件中用到的专问术语的定义和外文首字母组词的原词组。
1.4参考资料
列出要用到的参考资料，如：
a．        本项目的经核准的计划任务书或合同、上级机关的批文；
b．        属于本项目的其他已发表的文件；
c．        本文件中各处引用的文件、资料，包括所要用到的软件开发标准。列出这些文件的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
2测试概要
用表格的形式列出每一项测试的标识符及其测试内容，并指明实际进行的测试工作内容与测试计划中预先设计的内容之间的差别，说明作出这种改变的原因。
3测试结果及发现
3.1测试1（标识符）
把本项测试中实际得到的动态输出（包括内部生成数据输出）结果同对于动态输出的要求进行比较，陈述其中的各项发现。
3.2测试2（标识符）
用类似本报告3.1条的方式给出第 2项及其后各项测试内容的测试结果和发现。
4对软件功能的结论
4.1功能1（标识符）
4.1.1能力
简述该项功能，说明为满足此项功能而设计的软件能力以及经过一项或多项测试已证实的能力。
4.1.2限制
说明测试数据值的范围（包括动态数据和静态数据），列出就这项功能而言，测试期间在该软件中查出的缺陷、局限性。
4.2功能2（标识符）
用类似本报告4.l的方式给出第2项及其后各项功能的测试结论。
．．．．．．
5分析摘要
5.1能力
陈述经测试证实了的本软件的能力。如果所进行的测试是为了验证一项或几项特定性能要求的实现，应提供这方面的测试结果与要求之间的比较，并确定测试环境与实际运行环境之间可能存在的差异 对能力的测试所带来的影响。
5.2缺陷和限制
陈述经测试证实的软件缺陷和限制，说明每项缺陷和限制对软件性能的影响，并说明全部测得的性能缺陷的累积影响和总影响。
5.3建议
对每项缺陷提出改进建议，如：
a．        各项修改可采用的修改方法；
b．        各项修改的紧迫程度；
c．        各项修改预计的工作量；
d．        各项修改的负责人。
5.4评价
说明该项软件的开发是否已达到预定目标，能否交付使用。
6测试资源消耗
总结测试工作的资源消耗数据，如工作人员的水平级别数量、机时消耗等。

---

作者: inksong    时间: 2008-9-24 11:30
标题: 测试过程的规范
1.1        目的
此文档是根据TPUP中定义的Test Workflow形成的软件测试过程 ，明确在TPUP的各阶段的测试工作内容。
1.2        背景
为了按照TPUP进行软件开发和测试活动，特制作该文档。
1.3        范围
此文档可运用于采用TPUP开发的任一软件项目。
1.4        定义
1.4.1        测试的软件错误级别：
按照对工作功能的影响程度，将错误分为以下5级：
一级：不能完全满足系统要求，基本功能未完全实现；或者危及人身安全。
二级：严重地影响系统要求或基本功能的实现，且没有更正办法（重新安装或重新启动该软件不属于更正办法）。
三级：严重地影响系统要求或基本功能的实现，但存在合理的更正办法（重新安装或重新启动该软件不属于更正办法）。
四级：使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。
五级：其他错误。
1.4.2        单元测试（Unit Testing）：
单元测试是对最小的可测试软件元素（单元）实施的测试。它所测试的内容包括内部结构（如逻辑和数据流）以及单元的功能和可观测的行为。
1.4.3        集成测试（Integration Testing）：
集成测试是确保各单元组合在一起后能够按既定意图协作运行，并确保增量的行为正确。它所测试的内容包括单元间的接口以及集成后的功能。
1.4.4        系统测试（System Testing）：
系统测试是通过与系统的需求定义作比较，发现软件与系统定义不相符合或与之矛盾的地方。它将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合起来，在实际运行（使用）环境下，对计算机系统所进行的一系列集成测试和确认测试。
1.4.5        验收测试（Acceptance Testing）：
1.5        验收测试是系统测试的延续，这种测试是确定系统是否符合它的验收标准，并使客户、用户或经授权的实体能够确定接受该系统。缩略词
TPUP                   托普统一开发过程
RUP                     Rational统一开发过程
SEPG                       软件工程过程组
SQA                       软件质量保证
SCM                    软件配置管理
SDP                     软件开发计划
2.        过程描述
2.1        软件测试过程总观
软件测试包括下列七个阶段：
a.        计划测试阶段– 开展下列计划活动：
1.        测试总体计划。
2.        计划系统测试。
3.        计划集成测试。
4.        计划单元测试。
b.        设计测试阶段—开展下列设计活动
1.        设计系统测试用例。
2.        设计集成测试用例。
3.        设计单元测试用例。
4.        设计测试过程。
5.        设计单元测试和集成测试所需要的驱动程序和桩模块。
c.        实施测试阶段—开展下列活动
1.        制作测试脚本。
d.        单元测试阶段—开展下列活动
1.        根据单元测试计划以及单元测试用例、测试过程（脚本）执行单元测试。
2.        记录单元测试结果。
3.        评估单元测试活动。
e.        集成测试阶段—开展下列活动
1.        根据集成测试计划以及集成测试用例、测试过程（脚本）执行集成测试。
2.        记录集成测试结果。
3.        评估集成测试活动。
f.        系统测试阶段—开展下列活动
1.        根据系统测试计划以及系统测试用例、测试过程（脚本）执行系统测试。
2.        记录系统测试结果。
3.        评估系统测试活动。
g.        验收测试阶段—开展下列活动
1.        根据委托方制定的验收标准，选取系统测试用例的一个子集执行验收测试。
2.        记录验收测试结果，根据验收标准得出验收测试结论。
2.2        角色和职责
下面定义的各角色在项目开展前需要经过相关培训，掌握开展角色活动所需要的技能。
2.2.1        软件测试组
2.2.1.1 测试设计员
测试设计员负责下列活动：
a.        制定系统、集成、单元测试计划。
b.        设计系统、集成、单元测试用例、测试过程、测试脚本。
c.        评估系统、集成、单元测试活动。
2.2.1.2 测试员
测试员负责下列活动：
a.        在集成测试阶段按照集成测试用例执行集成测试
b.        记录集成测试结果
c.        在系统测试阶段按照系统测试用例执行系统测试
d.        记录系统测试结果
2.2.2        设计员
设计员负责下列活动：
a.        设计单元测试、集成测试所需要的驱动程序、桩模块
2.2.3          集成员
集成员负责下列活动：
a.        制定软件集成计划。
b.        集成软件工作版本。
2.2.4        实施员
实施员负责下列活动：
a.        编写驱动程序和桩模块
b.        在单元测试阶段按照单元测试用例执行单元测试
c.        记录单元测试结果
2.2.5        SQA
SQA 审计软件测试过程。向项目经理报告其结果。
2.2.6        SEPG
SEPG 维护此文档并对其进行更新以满足TPUP的需要。SEPG为项目提供支持并可提供软件测试过程培训。
2.2.7          SCM
配置管理员负责对所有测试工件进行配置管理。
2.2.8        客户、用户或经授权的实体
执行验收测试。
2.3        过程详述
2.3.1        计划测试阶段
2.3.1.1 主要活动
主要活动        输入工件        输出工件
测试总体计划        Software Development Plan (Draft)
        主测试计划 (Baseline)
计划系统测试        Use Case Model（Baseline）
Supplementary Specification (Baseline)
Software Development Plan (Draft)
Iteration Plan        软件系统测试计划 (Baseline)
Software Development Plan (Baseline)
计划集成测试        Design Model (Baseline)
Software Development Plan
Software Integration Plan (Baseline)
Iteration Plan        软件集成测试计划 (Baseline)
计划单元测试        Design Model
Implement Model
Software Development Plan
Iteration Plan        软件单元测试计划 (Baseline)
a.        测试总体计划：
时机：Inception Phase第一个迭代后期进行。
输入：Software Development Plan（Draft）
活动：明确测试的范围、需要的资源。定义角色等。
输出：Main Test Plan

b.        计划系统测试
进入准则：
a)        SRS（Use Case Model & Supplementary Specification）形成文档，纳入基线。
时机：Elaboration Phase第一个迭代前期进行。
输入：SRS、SDP(Draft)
活动：制定System Test Plan。
输出：System Test Plan
退出准则：
a)        所有SRS中的需求在测试计划中指定了相应的测试用例包对其进行跟踪。
b)        测试计划被批准并且置于配置管理之下。

c.        计划集成测试
进入准则：
a)        Design Model 形成文档、纳入基线。
时机：在Elaboration的中、后期进行。在以后的迭代中增加。
输入：Design Model、Software Integration Plan、Iteration Plan
活动：制定集成测试计划
输出：Integration Test Plan
退出准则：
a)        所有的集成版本都进行了描述、并且每一集成版本内Class 之间的接口都建立了跟踪。
b)        测试计划被批准并且置于配置管理之下。

d.        计划单元测试
进入准则：
a)        Design Model 形成文档、纳入基线。
时机：在Elaboration的中、后期进行，在以后的迭代中增加。
输入：Design Model、Software Integration Plan、Iteration Plan
活动：制定单元测试计划
输出：Unit Test Plan
退出准则：
a)        测试计划被批准并且置于配置管理之下。
2.3.2        设计测试阶段
2.3.2.1 主要活动
主要活动        输入工件        输出工件
设计系统测试        Use Case Model
Supplementary Specification
System Test Plan        软件系统测试用例
软件系统测试过程
工作量分析文档（仅供性能测试用）
设计集成测试        Design Model
Implementation Model
Integration Test Plan        软件集成测试用例
软件集成测试过程
驱动程序或桩模块
设计单元测试        Design Model
Implementation Model
Unit Test Plan        软件单元测试用例
驱动程序或桩模块
a.        设计系统测试
进入准则：System Test Plan被基线化。
时机：在Elaboration第一个迭代前期。
输入：SRS（Use Case Specification、Supplementary Specification）、System Test Plan
活动：制定系统测试用例。
制定系统测试过程。
输出：System Test Cases、System Test Procedure、Workload  Analysis Document
退出准则：
a)        所有的软件需求能够被测试用例跟踪。
b)        测试用例和测试过程被批准且基线化。

b.        设计集成测试
进入准则：Integration Test Plan被基线化。
时机：在Elaboration第一个迭代后期，以后的迭代新增。
输入：Integration Test Plan、Software Integration Plan、Design Model
活动：
a)        制定集成测试用例（可以部分重用系统测试用例）。
b)        制定集成测试过程（可以部分重用系统测试过程）。
c)        开发集成测试所需要的驱动程序和桩模块。       

输出：Integration Test Cases、Integration Test Procedures、Drives、Stubs
退出准则：测试用例和测试过程被批准，并且被基线化。

c.        设计单元测试
进入准则：Unit Test  Plan被基线化。
时机：在Elaboration第一个迭代后期进行，以后的迭代增加。
输入：Design Model、Implement Model、Unit Test Plan
活动：
a)        制定单元测试用例
b)        开发单元测试驱动程序或桩模块。
输出：Unit Test Cases、Unit Test Drivers、Unit Test Stubs
退出准则：Unit Test Cases被批准并基线化。
2.3.3        实施测试阶段
2.3.3.1         进入准则
测试用例和测试过程被批准并基线化
2.3.3.2         输入
系统测试用例、系统测试过程、集成测试用例、集成测试过程
2.3.3.3         活动
编制测试脚本
2.3.3.4 输出
测试脚本（Test Scripts）
2.3.3.5         退出准则
测试脚本通过编译、顺利运行。
2.3.4        单元测试阶段
2.3.4.1 进入准则：
a.   完成单元（Class）的编码
b.        代码无错误地通过编译
2.3.4.2 输入：
a.        Implement model
b.        Class
c.        Unit Test Plan
d.        Unit Test Cases
b.             单元测试所需要的驱动程序和桩模块。
2.3.4.3 活动：
a、        执行单元测试
b、       评估单元测试
2.3.4.4 输出：
a、        单元测试日志
b、       单元测试评估报告
2.3.4.5 退出准则：
a、        软件单元功能与设计一致。
b、        软件单元接口与设计一致。
c、        能够正确处理输入和运行中的错误。
d、        在单元测试中发现的错误已经得到修改并且通过了测试。
e、        达到了相关的覆盖率的要求。
1、        语句覆盖率达到100%。
2.3.5          集成测试阶段
2.3.5.1 进入准则
a.   软件集成策略已被制定。
b.   被集成的模块通过了单元测试
c.        需要的驱动程序或桩模块已经开发。
2.3.5.2 输入：
a、        Design Model
b、        Implementation Model
c、        按照集成策略集成的版本。
d、        软件集成计划。
e、        集成测试用例、测试过程、测试脚本。
f、        集成测试计划。
c.        驱动程序或桩模块。
2.3.5.3 活动
a、        执行集成测试
b、        回归测试以前的集成
c、        记录测试结果
d、          集成增量模块，重复a-c，直到增量集成结束。
e、        评估集成测试
2.3.5.4 输出
a、        集成测试日志
b、        集成测试评估报告
2.3.5.5 退出准则
a、软件单元无错误地连接。
b、满足各项功能、性能要求。
c、按照增量集成策略完成了整个系统的集成以及测试。
d、 在集成测试中发现的错误已经得到修改并且通过了测试。
2.3.6        系统测试阶段
2.3.6.1 进入准则
a.        所有的模块按照集成策略全部集成且通过了集成测试
2.3.6.2 输入：
a、        软件需求规格说明书（Use Case Model & Supplementary Specification）。
b、        软件系统。
c、        软件系统测试计划。
d、        软件系统测试用例、测试过程、测试脚本
2.3.6.3 活动
a、执行系统测试
根据测试计划、测试用例、系统测试指南作下列类型的测试：
功能确认测试
性能测试
安全性测试
故障转移及恢复测试
强度（压力）测试

---

作者: inksong    时间: 2008-9-24 11:31
2.3        过程详述
2.3.1        计划测试阶段
2.3.1.1 主要活动
主要活动        输入工件        输出工件
测试总体计划        Software Development Plan (Draft)
        主测试计划 (Baseline)
计划系统测试        Use Case Model（Baseline）
Supplementary Specification (Baseline)
Software Development Plan (Draft)
Iteration Plan        软件系统测试计划 (Baseline)
Software Development Plan (Baseline)
计划集成测试        Design Model (Baseline)
Software Development Plan
Software Integration Plan (Baseline)
Iteration Plan        软件集成测试计划 (Baseline)
计划单元测试        Design Model
Implement Model
Software Development Plan
Iteration Plan        软件单元测试计划 (Baseline)
a.        测试总体计划：
时机：Inception Phase第一个迭代后期进行。
输入：Software Development Plan（Draft）
活动：明确测试的范围、需要的资源。定义角色等。
输出：Main Test Plan

b.        计划系统测试
进入准则：
a)        SRS（Use Case Model & Supplementary Specification）形成文档，纳入基线。
时机：Elaboration Phase第一个迭代前期进行。
输入：SRS、SDP(Draft)
活动：制定System Test Plan。
输出：System Test Plan
退出准则：
a)        所有SRS中的需求在测试计划中指定了相应的测试用例包对其进行跟踪。
b)        测试计划被批准并且置于配置管理之下。

c.        计划集成测试
进入准则：
a)        Design Model 形成文档、纳入基线。
时机：在Elaboration的中、后期进行。在以后的迭代中增加。
输入：Design Model、Software Integration Plan、Iteration Plan
活动：制定集成测试计划
输出：Integration Test Plan
退出准则：
a)        所有的集成版本都进行了描述、并且每一集成版本内Class 之间的接口都建立了跟踪。
b)        测试计划被批准并且置于配置管理之下。

d.        计划单元测试
进入准则：
a)        Design Model 形成文档、纳入基线。
时机：在Elaboration的中、后期进行，在以后的迭代中增加。
输入：Design Model、Software Integration Plan、Iteration Plan
活动：制定单元测试计划
输出：Unit Test Plan
退出准则：
a)        测试计划被批准并且置于配置管理之下。
2.3.2        设计测试阶段
2.3.2.1 主要活动
主要活动        输入工件        输出工件
设计系统测试        Use Case Model
Supplementary Specification
System Test Plan        软件系统测试用例
软件系统测试过程
工作量分析文档（仅供性能测试用）
设计集成测试        Design Model
Implementation Model
Integration Test Plan        软件集成测试用例
软件集成测试过程
驱动程序或桩模块
设计单元测试        Design Model
Implementation Model
Unit Test Plan        软件单元测试用例
驱动程序或桩模块
a.        设计系统测试
进入准则：System Test Plan被基线化。
时机：在Elaboration第一个迭代前期。
输入：SRS（Use Case Specification、Supplementary Specification）、System Test Plan
活动：制定系统测试用例。
制定系统测试过程。
输出：System Test Cases、System Test Procedure、Workload  Analysis Document
退出准则：
a)        所有的软件需求能够被测试用例跟踪。
b)        测试用例和测试过程被批准且基线化。

b.        设计集成测试
进入准则：Integration Test Plan被基线化。
时机：在Elaboration第一个迭代后期，以后的迭代新增。
输入：Integration Test Plan、Software Integration Plan、Design Model
活动：
a)        制定集成测试用例（可以部分重用系统测试用例）。
b)        制定集成测试过程（可以部分重用系统测试过程）。
c)        开发集成测试所需要的驱动程序和桩模块。       

输出：Integration Test Cases、Integration Test Procedures、Drives、Stubs
退出准则：测试用例和测试过程被批准，并且被基线化。

c.        设计单元测试
进入准则：Unit Test  Plan被基线化。
时机：在Elaboration第一个迭代后期进行，以后的迭代增加。
输入：Design Model、Implement Model、Unit Test Plan
活动：
a)        制定单元测试用例
b)        开发单元测试驱动程序或桩模块。
输出：Unit Test Cases、Unit Test Drivers、Unit Test Stubs
退出准则：Unit Test Cases被批准并基线化。
2.3.3        实施测试阶段
2.3.3.1         进入准则
测试用例和测试过程被批准并基线化
2.3.3.2         输入
系统测试用例、系统测试过程、集成测试用例、集成测试过程
2.3.3.3         活动
编制测试脚本
2.3.3.4 输出
测试脚本（Test Scripts）
2.3.3.5         退出准则
测试脚本通过编译、顺利运行。
2.3.4        单元测试阶段
2.3.4.1 进入准则：
a.   完成单元（Class）的编码
b.        代码无错误地通过编译
2.3.4.2 输入：
a.        Implement model
b.        Class
c.        Unit Test Plan
d.        Unit Test Cases
b.             单元测试所需要的驱动程序和桩模块。
2.3.4.3 活动：
a、        执行单元测试
b、       评估单元测试
2.3.4.4 输出：
a、        单元测试日志
b、       单元测试评估报告
2.3.4.5 退出准则：
a、        软件单元功能与设计一致。
b、        软件单元接口与设计一致。
c、        能够正确处理输入和运行中的错误。
d、        在单元测试中发现的错误已经得到修改并且通过了测试。
e、        达到了相关的覆盖率的要求。
1、        语句覆盖率达到100%。
2.3.5          集成测试阶段
2.3.5.1 进入准则
a.   软件集成策略已被制定。
b.   被集成的模块通过了单元测试
c.        需要的驱动程序或桩模块已经开发。
2.3.5.2 输入：
a、        Design Model
b、        Implementation Model
c、        按照集成策略集成的版本。
d、        软件集成计划。
e、        集成测试用例、测试过程、测试脚本。
f、        集成测试计划。
c.        驱动程序或桩模块。
2.3.5.3 活动
a、        执行集成测试
b、        回归测试以前的集成
c、        记录测试结果
d、          集成增量模块，重复a-c，直到增量集成结束。
e、        评估集成测试
2.3.5.4 输出
a、        集成测试日志
b、        集成测试评估报告
2.3.5.5 退出准则
a、软件单元无错误地连接。
b、满足各项功能、性能要求。
c、按照增量集成策略完成了整个系统的集成以及测试。
d、 在集成测试中发现的错误已经得到修改并且通过了测试。
2.3.6        系统测试阶段
2.3.6.1 进入准则
a.        所有的模块按照集成策略全部集成且通过了集成测试
2.3.6.2 输入：
a、        软件需求规格说明书（Use Case Model & Supplementary Specification）。
b、        软件系统。
c、        软件系统测试计划。
d、        软件系统测试用例、测试过程、测试脚本
2.3.6.3 活动
a、执行系统测试
根据测试计划、测试用例、系统测试指南作下列类型的测试：
功能确认测试
性能测试
安全性测试
故障转移及恢复测试
强度（压力）测试
负载测试
配置测试
安装测试
以上类型的测试可以根据项目情况进行裁剪。
b、记录测试结果
c、评估测试活动
d、编写系统测试评估报告
2.3.6.4 输出
a、        系统测试日志
b、        系统测试评估报告
2.3.6.5 退出准则
a、系统满足需求规格说明书的要求 。
b、完全执行了系统测试计划中的每个测试用例。
C、在系统测试中发现的错误已经得到修改并且通过了测试。
2.3.7        验收测试阶段
验收测试阶段是客户、用户证明软件满足需求而执行的测试活动，一般是执行系统测试用例的一个子集来证明其满足验收标准。用户也可以授权某一实体来执行验收测试，但需要在委托合同中注明。
2.3.7.1 进入准则：
软件已经通过了系统测试。
2.3.7.2 输入
b.        a、项目立项审批表。软件需求规格说明书（SRS）
c.        软件系统。
d.        选择用于验收测试的系统测试用例、测试过程、测试脚本。
2.3.7.3 活动
执行验收测试。
2.3.7.4 输出
验收测试报告。
2.3.7.5 退出准则
完全执行所选择的系统测试用例。
根据测试结果，对被测试软件给出验收测试结论。
2.4        过程测量
•        各阶段的缺陷修复率。
•        各阶段计划测试的完成率。

---

作者: fire83617    时间: 2008-9-24 12:52
有效的，可行性高的测试规范要依公司实际情况而确定，可以借鉴和学习，最忌生搬硬套。
一套测试规范其主要目的在于提高工作效率，提高大家的工作热情，让工作在有条不紊且愉快的环境中展开。
我觉得要做到有效且可行性高，需做到以下几点：
1.集思广益，先在测试部门拿出一套出来，大家经过讨论后确定，然后广证意见。前期制定的时候我们必须做到所有人都参与了，这样，规范出来后大家按照规范来做的积极性就很高了，我想很少有人会自己打自己的脸吧？
2.规范必须因公司和产品不同而有所不同。就像有些公司并不适合走cmmi流程一样。大路通天，找到适合自己的路走是最快的，用高射炮打蚊子，岂非大材小用？反之，亦然。举一例，起抛砖引玉：
   我第一家公司的产品比较多元化也开发周边产品，其实说白了就一种产品，只不过对于平台的不同和客户不同经常冠不同的名字，我第二家公司只有一种产品，也就是一款软件，同类市场有很强、很成熟的国外产品，他们两家公司在需求分析阶段有着截然的不同：第一家公司，需求分析由开发做，然后开发测试一起评审；第二家公司,由测试提第一手需求，开发提第二手需求，然后开发测试一起评审得到最终的需求。而且我觉得他们这样做很合理，第一家就不说了，只分析第二家，为什么会有两手需求？为什么会由测试提第一手需求呢？原因在于公司的产品单一，加上为了保密和人员的流动性，很多开发人员只了解自己写的功能，对其他开发人员写的并不熟悉，而最熟悉公司产品的，反而是测试人员，而且市场上有其他同类产品，对比分析这块，测试人员比较有时间。而第二手需求只是更进一步的细化，让开发明确该如何实现功能，和实现什么样的功能。
3.规范不止是测试的流程、开发的流程、文档的管理和代码的标准，其实最重要的就是规范出属于自己公司的术语和专业词汇。也就是说你在描述bug或者交流的时候，你说出一个什么样的名词，别人通过了解规范知道你这个名词是什么意思。这样可以提高bug的可读性和严谨性，又可以提高交流的速度和质量，做到千人一词，那么就不会出现你自己“创造”新的名词，开发或者测试还来问你是什么意思的尴尬，既节省时间又提高效率。
    总之一句话：因人而异，各有千秋，集百家之长来完善自己，属于自己的才是最有效、最可行的测试规范。

---

作者: zhuzx    时间: 2008-9-24 14:53
标题: 一份有效的，可行性高的测试规范至少包括哪些内容？
由于内容太多，请想看的朋友通过下面的链接到我的博客看看，谢谢！！！
http://www.51testing.com/?33505/ ... e_itemid_93575.html
                    

                                           zhuzx
                                                              2008-09-24

---

作者: tian910    时间: 2008-9-24 15:08
标题: zhuzx测试专家，我到您的博客看了，怎么只回答了一个问题？
还有一个“如何制定一份有效的，可行性高的测试规范？”我们更是期待您的精彩回答呀？

偶，先送点鲜花表示谢意！！！哈哈！！！

---

作者: 爱巢    时间: 2008-9-24 15:55
标题: 刚看完zhuzx前辈回答了每周一问，确实比较精彩，每个题目都切中了要害
好贴呀，和tian910同行一样，迫切希望您再继续回答后面的问题，分享您的测试经验。

---

作者: zhuzx    时间: 2008-9-24 16:08
标题: 朋友，请不要给我短消息了，我今天比较忙！！！
爱巢和tian910朋友，不用急，我今天比较忙，后面一定回答，谢谢各位对我的关注！！！

                                         zhuzx

---

作者: 世博宝宝    时间: 2008-9-25 10:01
标题: 测试前辈，您还真帅！！！
zhuzx，今天通过您的链接去看了答题的答案，顺便浏览了您的博客，终于在您的博客相册里看到您的真面目了。真的很帅呢！！

---

作者: chuming    时间: 2008-9-25 15:25
标题: inksong朋友，建议以后答题，最好把模板的内容放到附件里，太多了
不过还是很感谢你的无私分享精神！！！

---

作者: archonwang    时间: 2008-9-25 16:04
【如何制定一份有效的，可行性高的测试规范？】是一项管理性质的问题，我想一些模板、流程、方法、工具等等固然有用，却是不全面的。希望可以看到更多有深度的思考和解答。

附图是对测试管理中各项内容的简单分析。

[ 本帖最后由 archonwang 于 2008-9-25 16:28 编辑 ]

---

作者: zhuzx    时间: 2008-9-25 16:17
标题: 如何制定一份有效的，可行性高的测试规范？
我今天下午抽空，在我的博客里回答了这个问题，请想看的朋友到我博客转转，呵呵！！！

http://www.51testing.com/?33505/ ... e_itemid_93689.html

---

作者: 若竹    时间: 2008-9-25 16:40
标题: 看了各位朋友的回答，受益匪浅！！！
我们公司天生都没有一个测试规范，太不正规了，没办法，老板想赚更多的钱呀？

---

作者: 天才精英    时间: 2008-9-25 17:22
标题: 看了您的回答，我很受启发，应该规范一下才行

原帖由 zhuzx 于 2008-9-24 14:53 发表
由于内容太多，请想看的朋友通过下面的链接到我的博客看看，谢谢！！！
http://www.51testing.com/?33505/ ... e_itemid_93575.html
                    

                                         ...

说实话，我们公司根本就没有测试规范，弄得大家写的测试用例，递交的缺陷都不规范，两个人两种风格，也没有测试经理，自己测试自己的项目。再说公司就两个测试人员，编写测试规范简直就是小题大做了，呵呵.

---

作者: yangj823    时间: 2008-9-25 17:52
我看各位在前面发言很多了.尤其大家对要不要制定测试规范都存在不同的意见.

既然这里提出的是如何制定,那么我就说一下我对这个问题的看法.

一般都是公司觉得制定一份有效的,可行性高的测试规范已经很迫切了,大家才坐在一起开始讨论这个问题.这说明公司一个或者多个项目已经发现了很多问题.那么如何制定呢?首先开始制定的时候不要期望一下子能够把这个测试规范很好的建立起来,建立测试规范是需要不断完善的.

我认为最简单的办法就是先把目前公司内部已经出现的问题罗列出来:比如: 有很多错报,漏报的bug;测试的覆盖不够全面;对需求了解存在问题;测试用例覆盖不全等等.
然后我们可以先把目前存在的问题进行归类.然后先制定如何克服这些问题的办法或者说规范.然后把制定的这些办法在接下来的项目中尝试应用.这样就可以在实践当中不断的完善这些制定的规范.通过多个项目的不断实践以及制定针对出现的每个问题的解决办法,可以把这些测试规范一点一点的充实起来.经过一段时间的实践,应用,总结和制定规范.最后就可以形成公司内部的一个比较有效的,可行性高的测试规范.

这是我目前想到的一些看法.期待大家精彩的发言.

---

作者: xazaj    时间: 2008-9-26 00:01
谢谢 回答以上问题的朋友们，大家一起来讨论以后，觉得豁然开朗，先前在网上找了几分测试规范的范例，参照着写出来总觉得自己都推行不起来，还是有很多细节问题需要解决的，持续关注中！~    再次对回帖的朋友表示感谢

---

作者: qiyan    时间: 2008-9-26 09:50
标题: 朋友能否把你写的测试规范文档给我们分享一下

原帖由 xazaj 于 2008-9-26 00:01 发表
谢谢 回答以上问题的朋友们，大家一起来讨论以后，觉得豁然开朗，先前在网上找了几分测试规范的范例，参照着写出来总觉得自己都推行不起来，还是有很多细节问题需要解决的，持续关注中！~    再次对回帖的朋友表示感 ...

您看，大家都在帮您吧！！您太幸运了。个人建议：最好把你写的测试规范共享出来，说不定我们还会给你提出更好的建议呢？嘿嘿！！

---

作者: 天府之国    时间: 2008-9-26 11:08
标题: xazaj真想看看您的测试规范
同意45楼朋友的说法，xazaj能否把你的测试规范给我们看看？？让我们也长长见识！！

---

作者: 朝九晚五    时间: 2008-9-26 15:00
标题: zhuzx，刚通过链接看了您写的测试规范，收益匪浅！！
很好的贴！！

---

作者: lihang617    时间: 2008-9-26 23:18
标题: 《软件测试规范》(草案)
一、目的与适用范围

1、目的

软件测试是软件工程的重要组成部分，测试工作的质量直接影响软件产品的生命力。测试工作的标准化是软件质量保证(Quality Assurance)重要而且必须的环节。制定本标准的目的在于使测试流程更标准，测试过程更规范。从而使整个软件生产纳入更系统化、更专业化的轨道。

2、适用范围

本标准适用于软件测试流程的管理和测试的具体操作过程。本标准的使用者可以是企业内部的测试人员和开发人员。

二、测试方法

软件测试的方法和技术是多种多样的。以下将介绍比较常用的一些测试方法：

1、静态测试

静态方法是指不运行被测程序本身，仅通过分析或检查源程序的文法、结构、过程、接口等来检查程序的正确性。静态方法通过程序静态特性的分析，找出欠缺和可疑之处，例如不匹配的参数、不适当的循环嵌套和分支嵌套、不允许的递归、未使用过的变量、空指针的引用和可疑的计算等。静态测试结果可用于进一步的查错，并为测试用例选取提供指导。

2、动态测试
　动态方法是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率和健壮性等性能，这种方法由三部分组成：构造测试实例、执行程序、分析程序的输出结果。

3、黑盒测试

黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。黑盒测试方法主要有等价类划分、边值分析、因—果图、错误推测等，主要用于软件确认测试。

“黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。

4、白盒测试

白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。

“白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。“白盒”法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的独立路径数是天文数字。但即使每条路径都测试了仍然可能有错误。第一，穷举路径测试决不能查出程序违反了设计规范，即程序本身是个错误的程序。第二，穷举路径测试不可能查出程序中因遗漏路径而出错。第三，穷举路径测试可能发现不了一些与数据相关的错误。

5、ALAC(Act-like-a-customer)测试

ALAC测试是一种基于客户使用产品的知识开发出来的测试方法。ALAC测试是基于复杂的软件产品有许多错误的原则。最大的受益者是用户，缺陷查找和改正将针对哪些客户最容易遇到的错误。

6、单元测试方法

6.1单元测试任务

单元测试任务包括：

u 模块接口测试；

u 模块局部数据结构测试；

u 模块边界条件测试；

u 模块中所有独立执行通路测试；

u 模块的各条错误处理通路测试。

模块接口测试是单元测试的基础。只有在数据能正确流入、流出模块的前提下，其他测试才有意义。

6.2接口测试

测试接口正确与否应该考虑下列因素：

u 输入的实际参数与形式参数的个数是否相同；

u 输入的实际参数与形式参数的属性是否匹配；

u 输入的实际参数与形式参数的量纲是否一致；

u 调用其他模块时所给实际参数的个数是否与被调模块的形参个数相同；

u 调用其他模块时所给实际参数的属性是否与被调模块的形参属性匹配；

u 调用其他模块时所给实际参数的量纲是否与被调模块的形参量纲一致；

u 调用预定义函数时所用参数的个数、属性和次序是否正确；

u 是否存在与当前入口点无关的参数引用；

u 是否修改了只读型参数；

u 对全程变量的定义各模块是否一致；

u 是否把某些约束作为参数传递。

如果模块内包括外部输入输出，还应该考虑下列因素：

u 文件属性是否正确；

u OPEN/CLOSE语句是否正确；

u 格式说明与输入输出语句是否匹配；

u 缓冲区大小与记录长度是否匹配；

u 文件使用前是否已经打开；

u 是否处理了文件尾；

u 是否处理了输入/输出错误；

u 输出信息中是否有文字性错误；

6.3数据测试

检查局部数据结构是为了保证临时存储在模块内的数据在程序执行过程中完整、正确。局部数据结构往往是错误的根源，应仔细设计测试用例，力求发现下面几类错误：

u 不合适或不相容的类型说明；

u 变量无初值；

u 变量初始化或省缺值有错；

u 不正确的变量名（拼错或不正确地截断）；

u 出现上溢、下溢和地址异常。

除了局部数据结构外，如果可能，单元测试时还应该查清全局数据（例如FORTRAN的公用区）对模块的影响。

6.4控制流测试

在模块中应对每一条独立执行路径进行测试，单元测试的基本任务是保证模块中每条语句至少执行一次。此时设计测试用例是为了发现因错误计算、不正确的比较和不适当的控制流造成的错误。此时基本路径测试和循环测试是最常用且最有效的测试技术。计算中常见的错误包括：

u 误解或用错了算符优先级；

u 混合类型运算；

u 变量初值错；

u 精度不够；

u 表达式符号错。

比较判断与控制流常常紧密相关，测试用例还应致力于发现下列错误：

u 不同数据类型的对象之间进行比较；

u 错误地使用逻辑运算符或优先级；

u 因计算机表示的局限性，期望理论上相等而实际上不相等的两个量相等；

u 比较运算或变量出错；

u 循环终止条件或不可能出现；

u 迭代发散时不能退出；

u 错误地修改了循环变量。

6.5出错处理测试

一个好的设计应能预见各种出错条件，并预设各种出错处理通路，出错处理通路同样需要认真测试，测试应着重检查下列问题：

u 输出的出错信息难以理解；

u 记录的错误与实际遇到的错误不相符；

u 在程序自定义的出错处理段运行之前，系统已介入；

u 异常处理不当；

u 错误陈述中未能提供足够的定位出错信息。

6.6边界条件测试

边界条件测试是单元测试中最后，也是最重要的一项任务。众的周知，软件经常在边界上失效，采用边界值分析技术，针对边界值及其左、右设计测试用例，很有可能发现新的错误。

---

作者: lihang617    时间: 2008-9-26 23:19
7、集成测试的基本方法

某设计人员习惯于把所有模块按设计要求一次全部组装起来，然后进行整体测试，这称为非增量式集成。这种方法容易出现混乱。因为测试时可能发现一大堆错误，为每个错误定位和纠正非常困难，并且在改正一个错误的同时又可能引入新的错误，新旧错误混杂，更难断定出错的原因和位置。与之相反的是增量式集成方法，程序一段一段地扩展，测试的范围一步一步地增大，错误易于定位和纠正，界面的测试亦可做到完全彻底。下面讨论两种增量式集成方法。

7.1 自顶向下集成

自顶向下集成是构造程序结构的一种增量式方式，它从主控模块开始，按照软件的控制层次结构，以深度优先或广度优先的策略，逐步把各个模块集成在一起。深度优先策略首先是把主控制路径上的模块集成在一起，至于选择哪一条路径作为主控制路径，这多少带有随意性，一般根据问题的特性确定。

自顶向下集成测试的具体步骤为：

u 以主控模块作为测试驱动模块，把对主控模块进行单元测试时引入的所有桩模块用实际模块替代；

u 依据所选的集成策略（深度优先或广度优先），每次只替代一个桩模块；

u 每集成一个模块立即测试一遍；

u 只有每组测试完成后，才着手替换下一个桩模块；

u 为避免引入新错误，须不断地进行回归测试（即全部或部分地重复已做过的测试）；

u 从第二步开始，循环执行上述步骤，直至整个程序结构构造完毕。

自顶向下集成的优点在于能尽早地对程序的主要控制和决策机制进行检验，因此较早地发现错误。缺点是在测试较高层模块时，低层处理采用桩模块替代，不能反映真实情况，重要数据不能及时回送到上层模块，因此测试并不充分。解决这个问题有几种办法，第一种是把某些测试推迟到用真实模块替代桩模块之后进行，第二种是开发能模拟真实模块的桩模块；第三种是自底向上集成模块。第一种方法又回退为非增量式的集成方法，使错误难于定位和纠正，并且失去了在组装模块时进行一些特定测试的可能性；第二种方法无疑要大大增加开销；第三种方法比较切实可行。

7.2自底向上集成

自底向上测试是从“原子”模块（即软件结构最低层的模块）开始组装测试，因测试到较高层模块时，所需的下层模块功能均已具备，所以不再需要桩模块。

自底向上综合测试的步骤分为：

u 把低层模块组织成实现某个子功能的模块群（cluster）;

u 开发一个测试驱动模块，控制测试数据的输入和测试结果的输出；

u 对每个模块群进行测试；

u 删除测试使用的驱动模块，用较高层模块把模块群组织成为完成更大功能的新模块群；

u 从第一步开始循环执行上述各步骤，直至整个程序构造完毕。

自底向上集成方法不用桩模块，测试用例的设计亦相对简单，但缺点是程序最后一个模块加入时才具有整体形象。它与自顶向综合测试方法优缺点正好相反。因此，在测试软件系统时，应根据软件的特点和工程的进度，选用适当的测试策略，有时混和使用两种策略更为有效，上层模块用自顶向下的方法，下层模块用自底向上的方法。

此外，在集成测试中尤其要注意关键模块，所谓关键模块一般都具有下述一或多个特征：①对应几条需求；②具有高层控制功能；③复杂、易出错；④有特殊的性能要求。关键模块应尽早测试，并反复进行回归测试。

8、确认测试的基本方法

8.1确认测试标准

实现软件确认要通过一系列黑盒测试。确认测试同样需要制订测试计划和过程，测试计划应规定测试的种类和测试进度，测试过程则定义一些特殊的测试用例，旨在说明软件与需求是否一致。无论是计划还是过程，都应该着重考虑软件是否满足合同规定的所有功能和性能，文档资料是否完整、准确，人机界面和其他方面（例如，可移植性、兼容性、错误恢复能力和可维护性等）是否令用户满意。

确认测试的结果有两种可能，一种是功能和性能指标满足软件需求说明的要求，用户可以接受；另一种是软件不满足软件需求说明的要求，用户无法接受。项目进行到这个阶段才发现严重错误和偏差一般很难在预定的工期内改正，因此必须与用户协商，寻求一个妥善解决问题的方法。

8.2 配置复审

确认测试的另一个重要环节是配置复审。复审的目的在于保证软件配置齐全、分类有序，并且包括软件维护所必须的细节。

8.3α、β测试

事实上，软件开发人员不可能完全预见用户实际使用程序的情况。例如，用户可能错误的理解命令，或提供一些奇怪的数据组合，亦可能对设计者自认明了的输出信息迷惑不解，等等。因此，软件是否真正满足最终用户的要求，应由用户进行一系列“验收测试”。验收测试既可以是非正式的测试，也可以有计划、有系统的测试。有时，验收测试长达数周甚至数月，不断暴露错误，导致开发延期。一个软件产品，可能拥有众多用户，不可能由每个用户验收，此时多采用称为α、β测试的过程，以期发现那些似乎只有最终用户才能发现的问题。

α测试是指软件开发公司组织内部人员模拟各类用户行对即将面市软件产品（称为α版本）进行测试，试图发现错误并修正。α测试的关键在于尽可能逼真地模拟实际运行环境和用户对软件产品的操作并尽最大努力涵盖所有可能的 用户操作方式。经过α测试调整的软件产品称为β版本。紧随其后的β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，并要求用户报告异常情况、提出批评意见。然后软件开发公司再对β版本进行改错和完善。

9、系统测试的基本方法 　

9.1恢复测试

恢复测试主要检查系统的容错能力。当系统出错时，能否在指定时间间隔内修正错误并重新启动系统。恢复测试首先要采用各种办法强迫系统失败，然后验证系统是否能尽快恢复。对于自动恢复需验证重新初始化（reinitialization）、检查点(checkpointing mechanisms)、数据恢复(data recovery)和重新启动 (restart)等机制的正确性；对于人工干预的恢复系统，还需估测平均修复时间，确定其是否在可接受的范围内。

9.2安全测试

安全测试检查系统对非法侵入的防范能力。安全测试期间，测试人员假扮非法入侵者，采用各种办法试图突破防线。例如，①想方设法截取或破译口令；②专门定做软件破坏系统的保护机制；③故意导致系统失败，企图趁恢复之机非法进入；④试图通过浏览非保密数据，推导所需信息，等等。理论上讲，只要有足够的时间和资源，没有不可进入的系统。因此系统安全设计的准则是，使非法侵入的代价超过被保护信息的价值。此时非法侵入者已无利可图。

9.3强度测试

强度测试检查程序对异常情况的抵抗能力。强度测试总是迫使系统在异常的资源配置下运行。例如，①当中断的正常频率为每秒一至两个时，运行每秒产生十个中断的测试用例；②定量地增长数据输入率，检查输入子功能的反映能力；③运行需要最大存储空间（或其他资源）的测试用例；④运行可能导致虚存操作系统崩溃或磁盘数据剧烈抖动的测试用例，等等。

9.4性能测试

对于那些实时和嵌入式系统，软件部分即使满足功能要求，也未必能够满足性能要求，虽然从单元测试起，每一测试步骤都包含性能测试，但只有当系统真正集成之后，在真实环境中才能全面、可靠地测试运行性能系统性能测试是为了完成这一任务。性能测试有时与强度测试相结合，经常需要其他软硬件的配套支持。

10、回归测试方法

回归测试的价值在于它是一个能够检测到回归错误的受控实验。当测试组选择缩减的回归测试时，有可能删除了将揭示回归错误的测试用例，消除了发现回归错误的机会。然而，如果采用了代码相依性分析等安全的缩减技术，就可以决定哪些测试用例可以被删除而不会让回归测试的意图遭到破坏。

选择回归测试策略应该兼顾效率和有效性两个方面。常用的选择回归测试的方式包括：

10.1再测试全部用例：

选择基线测试用例库中的全部测试用例组成回归测试包，这是一种比较安全的方法，再测试全部用例具有最低的遗漏回归错误的风险，但测试成本最高。全部再测试几乎可以应用到任何情况下，基本上不需要进行分析和重新开发，但是，随着开发工作的进展，测试用例不断增多，重复原先所有的测试将带来很大的工作量，往往超出了我们的预算和进度。

10.2基于风险选择测试 ：

可以基于一定的风险标准来从基线测试用例库中选择回归测试包。首先运行最重要的、关键的和可疑的测试，而跳过那些非关键的、优先级别低的或者高稳定的测试用例，这些用例即便可能测试到缺陷，这些缺陷的严重性也仅有三级或四级。一般而言，测试从主要特征到次要特征

10.3基于操作剖面选择测试 ：

如果基线测试用例库的测试用例是基于软件操作剖面开发的，测试用例的分布情况反映了系统的实际使用情况。回归测试所使用的测试用例个数可以由测试预算确定，回归测试可以优先选择那些针对最重要或最频繁使用功能的测试用例，释放和缓解最高级别的风险，有助于尽早发现那些对可靠性有最大影响的故障。这种方法可以在一个给定的预算下最有效的提高系统可靠性，但实施起来有一定的难度。

10.4再测试修改的部分：

当测试者对修改的局部化有足够的信心时，可以通过相依性分析识别软件的修改情况并分析修改的影响，将回归测试局限于被改变的模块和它的接口上。通常，一个回归错误一定涉及一个新的、修改的或删除的代码段。在允许的条件下，回归测试尽可能覆盖受到影响的部分。

再测试全部用例的策略是最安全的策略，但已经运行过许多次的回归测试不太可能揭示新的错误，而且很多时候，由于时间、人员、设备和经费的原因，不允许选择再测试全部用例的回归测试策略，此时，可以选择适当的策略进行缩减的回归测试。

---

作者: lihang617    时间: 2008-9-26 23:19
标题: 草案（续）
三、测试阶段的划分

根据开发过程和实际需求将测试阶段划分为：设计阶段、代码检测单元测试阶段、集成测试阶段、系统测试阶段、验收测试阶段、回归测试（复测）阶段。各阶段中使用的测试方法详见本规范的测试方法。

1、设计阶段

核心工作是对软件产品功能说明书进行检查，软件产品功能说明书是对软件产品最终需要实现的功能的描述。编写软件测试计划。

2、单元测试阶段

单元测试完成对软件最小的结构的测试，一般用来验证模块的功能属性，它利用设计文档作为指导，主要使用白盒测试技术；但也可以测试其它项目，如性能、可用性等等，可使用“黑盒”或“白盒”方法进行。在单元测试中，检查出模块内部的错误是单元测试的主要工作。该阶段的测试工作，由编程组内部人员进行交叉测试（避免编程人员测试自己的程序）。

单元测试过程：　一般认为单元测试应紧接在编码之后，当源程序编制完成并通过复审和编译检查，便可开始单元测试。测试用例的设计应与复审工作相结合，根据设计信息选取测试数据，将增大发现上述各类错误的可能性。在确定测试用例的同时，应给出期望结果。

提高模块的内聚度可简化单元测试，如果每个模块只能完成一个，所需测试用例数目将显著减少，模块中的错误也更容易发现。

3、集成测试阶段

时常有这样的情况发生，每个模块都能单独工作，但这些模块集成在一起之后却不能正常工作。主要原因是，模块相互调用时接口会引入许多新问题。例如，数据经过接口可能丢失；一个模块对另一模块可能造成不应有的影响；几个子功能组合起来不能实现主功能；误差不断积累达到不可接受的程度；全局数据结构出现错误，等等。集成测试是组装软件的系统测试技术，按设计要求把通过单元测试的各个模块组装在一起之后，进行集成测试以便发现与接口有关的各种错误。

4、确认测试阶段

确认测试的目的是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是确认测试的任务，即软件的功能和性能如同用户所合理期待的那样。

5、系统测试阶段

计算机软件是基于计算机系统的一个重要组成部分，软件开发完毕后应与系统中其它成分集成在一起，此时需要进行一系列系统测试。包括恢复测试、安全测试、强度测试和性能测试等。在系统测试之前，软件工程师应完成下列工作：

（1） 为测试软件系统的输入信息设计出错处理通路；

（2） 设计测试用例，模拟错误数据和软件界面可能发生的错误，记录测试结果，为系统测试提供经验和帮助；

（3） 参与系统测试的规划和设计，保证软件测试的合理性。

系统测试应该由若干个不同测试组成，目的是充分运行系统，验证系统各部件是否都能工作并完成所赋予的任务。

6、回归测试（复测）阶段

回归测试就是漏洞修复完成后再对软件进行测试，以确保软件没有产生“回归”或因修复而变得更糟，这种测试一般要重新运行最初发现问题的原始测试程序。有关回归测试有两个焦点：有没有产生新的漏洞，修复是否确实使缺陷消除。

回归测试的过程：

有了测试用例库的维护方法和回归测试包的选择策略，回归测试可遵循下述过程进行：

u 识别出软件中被修改的部分

u 从原基线测试用例库中排除所有不再适用的测试用例，确定那些对新的软件版本依然有效的测试用例

u 如果必要，生成新的测试用例集，用于测试原来测试用例集无法充分测试的部分

u 依据一定的策略选择测试用例测试被修改的软件。

u 进行测试，并记录测试结果到测试报告

u 分析测试报告

u 修正和测试工作

u 完成测试产品提交配置

四、测试类型的划分

1、功能测试：对软件功能进行的测试，主要检查软件功能是否实现了软件功能说明书（软件需求）上的功能要求。

2、界面测试：对软件的用户界面进行的测试，主要检查用户界面的美观度、统一性、易用性等方面的内容。

3、数据处理测试：对软件数据接口进行的测试，主要检查软件数据处理中输入、处理、输出数据过程。

4、流程测试：按操作流程进行的测试，主要有业务流程、数据流程、逻辑流程、正反流程，检查软件在按流程操作时是否能够正确处理。

5、极限测试：在软件的极限条件下进行的测试，主要有对数据的极限值、边界值操作，对软件进行致命操作等。

6、并发测试：在网络环境、并发环境、多用户条件下对软件进行的测试。

7、安全测试：对软件安全性方面的测试，主要检测软件中加密、解密、数据备份、恢复、病毒检测等问题。

8、性能测试：对软件整体性能的测试，测试内容有适应性、健壮性、可恢复性、灾难恢复能力等

9、安装测试：在不同PC条件、操作系统、模拟客户机等条件下进行软件的安装测试，主要检查软件打包或发布之后存在的问题。

五、测试模式

V型模型，实现测试与软件开发的同步进行。

六、测试—开发工作流程

七、测试工作流程

测试操作流程图

说明：

设计测试用例、执行测试用例详见《测试用例》。

描述软件错误即填写bug记录表，详见《BUG标准》

八、附录

附录一、测试文档

I 测试计划

1．引言

1.1编写目的

【阐明编写测试计划的目的，指明读者对象。】

1.2项目背景

【说明项目的来源、委托单位及主管部门。】

1.3定义

【列出测试计划中所用到的专门术语的定义和缩写词的原意。】

1.4参考资料

【列出有关资料的作者、标题、编号、发表日期、出版单位或资料来源，可包括：

a. 项目的计划任务书、合同或批文；

b. 项目开发计划；

c. 需求规格说明书；

d. 概要设计说明书；

e. 详细设计说明书；

f. 用户操作手册；

g. 本测试计划中引用的其他资料、采用的软件开发标准或规范。】

2．任务概述

2.1目标

2.2运行环境

2.3需求概述

2.4条件与限制

3．计划

3.1测试方案

【说明确定测试方法和选取测试用例的原则。】

3.2测试项目

【列出组装测试和确认测试中每一项测试的内容、名称、目的和进度。】

3.3测试准备

3.4测试机构及人员

【测试机构名称、负责人和职责。】

4．测试项目说明

【按顺序逐个对测试项目做出说明：】

4.1测试项目名称及测试内容

4.2测试用例

4.2.1输入

【输入的数据和输入命令。】

4.2.2输出

【预期的输出数据。】

4.2.3步骤及操作

4.2.4允许偏差

【给出实测结果与预期结果之间允许偏差的范围。】

4.3进度

4.4条件

【给出测试对资源的特殊要求，如设备、软件、人员等。】

4.5测试资料

【说明测试所需的资料。】

5．评价

5.1范围

【说明所完成的各项测试说明问题的范围及其局限性。】

5.2准则

【说明评价测试结果的准则。】

II 测试用例

详见《测试用例》

III 测试记录报告

填写测试用例执行报告，详见《测试用例》

IV 测试问题报告

即BUG记录表，详见《BUG标准》

V 测试分析报告

1．引言

1.1编写目的

【阐明编写测试分析报告的目的，指明读者对象。】

1.2项目背景

【说明项目的来源、委托单位及主管部门。】

1.3定义

【列出测试分析报告中所用到的专门术语的定义和缩写词的原文。】

1.4参考资料

【列出有关资料的作者、标题、编号、发表日期、出版单位或资料来源，可包括：

a. 项目的计划任务书、合同或批文；

b. 项目开发计划；

c. 需求规格说明书；

d. 概要设计说明书；

e. 详细设计说明书；

f. 用户操作手册；

g. 测试计划；

h. 测试分析报告所引用的其他资料、采用的软件工程标准或软件工作规范。】

2．测试计划执行情况

2.1测试项目

【列出每一测试项目的名称、内容和目的。】

2.2测试机构和人员

【给出测试机构名称、负责人和参与测试人员名单。】

2.3测试结果

【按顺序给出每一测试项目的：

a. 实测结果数据；

b. 与预期结果数据的偏差；

c. 该项测试表明的事实；

d. 该项测试发现的问题。】

3．软件需求测试结论

【按顺序给出每一项需求测试的结论。包括：

a. 证实的软件能力；

b. 局限性（即项需求未得到充分测试的情况及原因）。】

4．评价

4.1软件能力

【经过测试所表明的软件能力。】

4.2缺陷和限制

【说明测试所揭露的软件缺陷和不足，以及可能给软件运行带来的影响。】

4.3建议

【提出为弥补上述缺陷的建议。】

4.4测试结论

---

作者: 九角树    时间: 2008-9-27 09:53
标题: 答题友情提醒
朋友们，个人觉得答题最好用自己的话总结一下，不要大片原文转载，最好使用附件，方便大家查阅，谢谢各位！！！

---

作者: hsbc    时间: 2008-9-28 09:33
标题: 版主，能否早点讨论其它好的题目
今天完了都快国庆了，能否讨论一下别的题目，我国庆期间还想参加答题呢？我看题目都快变成2周一问了，呵呵！！！！

---

作者: hrsc    时间: 2008-9-28 09:55
标题: zhuzx老兄，从论坛得知你是个热心人
从论坛得知你不仅是个热心人，还是个测试行业的佼佼者！！！以后多多关注，提前谢谢谢，嘿嘿！！

我已经给你短消息，要您的MSN, 请查收，谢谢！！！

---

作者: prettyyang    时间: 2008-9-28 10:10
标题: 测试组工作流程和规范
我也正在制定测试部门的规范，刚制定好，领导还没审批，欢迎大家指出改进意见，谢谢！详见附件

[ 本帖最后由 prettyyang 于 2008-9-28 11:31 编辑 ]

---

作者: 豆腐佬    时间: 2008-9-28 10:35
标题: prettyyang是个聪明人
prettyyang是个聪明人，把你的测试规范拿来大家探讨，相信大家给你提建议以后，你的测试规范一定是最棒的！！！

---

作者: 天府之国    时间: 2008-9-28 10:47
标题: 偶，刚才发现51Testing网站的一个Bug！！
就是“发表于 2008-9-28 10:45  ”这个时间总是比实际的北京时间“2008-9-28 10:34 ”大约快10秒钟左右。

发现这个Bug，版主是不是该给颁个鼓励奖呀，哈哈！！！开玩笑的了。

---

作者: uestc    时间: 2008-9-28 10:57
标题: 看来xazaj朋友，还不愿意把测试规范拿来分享呢，遗憾！！
xazaj朋友，还不愿意把测试规范拿来分享呢？大家呼吁他这么久了，也不情愿贴出来，遗憾！！还是“prettyyang”爽快！！！您是好人一个呀！！

---

作者: uestc    时间: 2008-9-28 11:04
标题: 版主我刚才发帖的时候，确实验证了这个Bug，快了11分钟

原帖由 天府之国 于 2008-9-28 10:47 发表
就是“发表于 2008-9-28 10:45  ”这个时间总是比实际的北京时间“2008-9-28 10:34 ”大约快10秒钟左右。

发现这个Bug，版主是不是该给颁个鼓励奖呀，哈哈！！！开玩笑的了。

朋友您太细心了，我试过了快了11分钟。我们天天上51Testing都没有发现这个问题，好伤心。

版主是该奖励一下“天府之国”朋友。

---

作者: prettyyang    时间: 2008-9-28 11:18

原帖由 archonwang 于 2008-9-28 11:02 发表
看了其中一份，请作者结合贵公司实际，参考使用。如有错漏出入，见谅。

谢谢，我已下载附件，麻烦删除附件吧，因为文档里有公司相关的资料，我上传时忘记删除了，谢谢

---

作者: archonwang    时间: 2008-9-28 11:26
标题: 回复 59# 的帖子
OK。已处理。

---

作者: 郭玉娇    时间: 2008-9-28 16:16
占个角落，看各位专家精彩的回答。

---

作者: 测试人才    时间: 2008-9-30 11:23
标题: 版主国庆就不每周一问啦？？
平时太忙了，都没时间上51Testing上答题，准备在国庆答答题目，谁知版主至今都还不更改新题目，太遗憾啦！！！这个国庆太失败啦！！！呵呵！！！

---

作者: testingleader    时间: 2008-9-30 16:22
标题: 国庆放假，难道每周一问也放国庆？
晕哟！！！每周一问也放国庆节啦！！！

---

作者: 915SW    时间: 2008-10-2 11:32
标题: zhuzx有了您，我们这些菜鸟就高枕无忧了

原帖由 zhuzx 于 2008-9-24 14:53 发表
由于内容太多，请想看的朋友通过下面的链接到我的博客看看，谢谢！！！
http://www.51testing.com/?33505/ ... e_itemid_93575.html
                    

                                         ...

zhuzx朋友，看了您近期的回答，我们收获颇多，进步比较明显，呵呵！！相信有了您的支持，我们这些菜鸟就高枕无忧了！！！

---

作者: 海洋世界    时间: 2008-10-2 11:53
标题: 朋友，看了您的帖很受启发

原帖由 zhuzx 于 2008-9-25 16:17 发表
我今天下午抽空，在我的博客里回答了这个问题，请想看的朋友到我博客转转，呵呵！！！

http://www.51testing.com/?33505/ ... e_itemid_93689.html

朋友，您的帖写得很是在，看了受启发！！希望以后能够得到高手您的帮助！！！

---

作者: 怪好    时间: 2008-10-2 12:14
标题: 版主，搞了半天，还是那个老题目放到哪儿，太没意思啦！！！
现在都超过一周啦，怎么还没有换题目呢？我看就是放假了，没人管啦。

---

作者: 默默巫    时间: 2008-10-2 16:41

原帖由 怪好 于 2008-10-2 12:14 发表
现在都超过一周啦，怎么还没有换题目呢？我看就是放假了，没人管啦。

国庆期间每周一问已延期到工作日更新.

---

作者: lucy-lucy    时间: 2008-10-6 09:36
标题: 国庆后，都还没有更换题目呀？
我看是两周一问啦！！！

---

作者: 奇怪的测试人    时间: 2008-10-6 12:09
标题: 看了zhuzx朋友几次答题，你太认真啦
前辈，你这种认真负责、一丝不苟的精神，值得我们新手学习学习。

下面是我的MSN：请加我，谢谢！！

ZLW-938@MSN.COM

---

作者: 猫腻    时间: 2008-10-6 12:55
标题: 每周一问是51Testing的一个亮点
有了每周一问，感觉个人受益匪浅！！

特别感谢上面多次获奖的各位朋友的无私经验分享！！！

---

作者: 默默巫    时间: 2008-10-6 13:19

原帖由 uestc 于 2008-9-28 11:04 发表



朋友您太细心了，我试过了快了11分钟。我们天天上51Testing都没有发现这个问题，好伤心。

版主是该奖励一下“天府之国”朋友。

不是ＢＵＧ，呵呵．
是服务器的时间和北京时间未同步．

---

作者: 天府之国    时间: 2008-10-6 13:38
标题: 版主英明，这次答题很多高手，都回答得不错哟
其实版主早就该多奖励几个人了，您太英明啦，这样可以提高高手答题的积极性，呵呵！！！

---

作者: zxbcug    时间: 2008-10-14 15:32
标题: 回复 2# 的帖子
我很赞同二楼高人见解里的：
规范要具有可操作性；
规范要适应企业现状；
规范要经过循序渐进、持续优化的过程。

我借用一句马克思主义政治经济学的话来表达我的感受：“生产关系适应生产力的发展时促进生产力的发展，不适合生产力的发展时阻碍生产力的发展”。这里生产关系相对于规范。

---

作者: zishuijing    时间: 2009-6-18 16:42
标题: 回复 65# 的帖子
原帖由 zhuzx 于 2008-9-25 16:17 发表
我今天下午抽空，在我的博客里回答了这个问题，请想看的朋友到我博客转转，呵呵！！！

http://www.51testing.com/?33505/ ... e_itemid_93689.html

这个贴的链接看不到了；希望有转贴的朋友给看看；谢谢！！

---

作者: xinwuhanqqm    时间: 2009-8-24 15:54
标题: 请热心的朋友转贴，谢谢！
系统每次提示：出错了，您请求的页面没有找到
非常希望能看到这个贴子，请热心的朋友转贴，谢谢！

---

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)

Powered by Discuz! X3.2