W模型中要求对设计文档进行测试,如何对其进行有效的测试?（获奖名单已经公布）

lsekfe

本周的问题为“本周的问题为：W模型中要求对设计文档进行测试,如何对其进行有效的测试?”
此话题由会员piaohuar2008提供，如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	土土的豆豆	50元京东礼品卡	#8
二等奖		300论坛积分
三等奖		100论坛积分

Miss_love

设计文档，是否符合用户需求，软件功能说明详细，文档内容易于理解，专业术语是否易于理解等等方面吧

lsekfe

终于有一个人回答了~~看起来这期的题目要难产了。冷门啊！

Charles_H

设计文档测试，我认为是对文档的评审过程。
首先需要各部门相关人员进行评审，是否满足了需求； 然后在评审过程中，针对用户群体，讨论设计是否合理， 关于业务流程方面的实现，是否有不足之处；  最后经过不断的修订，形成完善的设计文档；
当然，在评审过程中，要对一些术语进行定义、规范和统一；
这前期对文档的评审，是为后期的项目减少风险， 相当关键。

hotivy

这题目是冷门啊，能运用W模型或规范执行的太少了，我这抛个砖吧。

W模型的设计文档包括：需求设计文档、概要设计文档、详细设计文档三类。W模型要求在完成设计文档后对设计文档进行测试，这比传统V模型更好地体现的“尽早测试”的概念。

我只做过国内项目，就从我的经验说说，存在偏颇希望大家多多讨论。

1、文档本身，对于设计文档本身的一些评测规范，我觉得应根据公司规模、人员素质等情况量身定做。比如 文档格式，需求表述方式，功能是否全面，变量、参数表示形式等。只要能清晰、尽量全面的表达出需求、设计意图即可。过分追求文档形式，会过犹不及的。

2、文档内容，需求是万恶之源啊。需求错误必然导致设计偏颇、然后便一错千里。后期的需求、设计变更更是梦魇。理想的做法，测试人员需求调研期间介入项目，由需求、设计、测试个方面共同完成需求调研。由于立场、经验不同所以需求分析报告会比较全面。
   现实工作中，没多少公司会让测试人员前期介入，尤其是短期项目。这时，在进行设计阶段、测试负责人就要多与开发负责人沟通，阶段性的获取设计文档，别等最后设计完成后再获取，那时候就能检查是不是有错别字了。个人觉得在这种前期需求不介入的情况下，“工作经验”、“头脑风暴”往往会更好用。如果是陌生业务，很难在设计评审阶段指出“业务”上的问题。
   对于长期项目，测试人员在设计文档的测试过程中还是有很意义的。长期厮混在某个项目，对于业务、系统架构都熟悉了。当项目有需求变更或后续需求时测试人员就可以快速介入，可以在文档测试中指出实质性的问题。

3、测试形式： “评审”是最常见的。在正式评审前，设计、测试人员可以内部举行讨论会，目的是消除“歧义”，包括设计思路、业务理解等方面的。必要时可以请需求人员参与。我觉得这种做法可以有效提高评审的效率。
为了确保业务、设计思路的准确。也可以预先做一个系统原型，给客户演示。客户可以很直观的感受产品，提出切实的意见。

4、参与人员： 在进行“需求设计”文档的评审时，最好有客户参与。概要和设计文档阶段基本都是项目组内人员参与，可以根据实际情况调配。
如果有“外围系统”参与开发，在相应阶段应邀请第三方参与评审。

对于重要项目，我们基本能做到就是这些，小项目基本就看个人实力了，呵呵，毕竟成本是个主要因素。

caonianvicky

楼上说的很好啊，目前我们公司就是这样的思路，可惜执行起来大家都不是很配合，特别是对原型、设计的评审，效率极低。。。

hotivy

楼上说的很好啊，目前我们公司就是这样的思路，可惜执行起来大家都不是很配合，特别是对原型、设计的评审， ...
caonianvicky 发表于 2013-12-18 10:00

    我觉得，对于常年都是一套业务，一系列产品的公司，开发和测试人员对系统都很熟悉了，这种“评审”可有可无，不如内部的讨论会实在。
   对于新项目，这种评审还是很必要的，说句不好听的话，评审也是划清责任的会议，到时候项目出问题要找人算账，得有点依据啊。磨刀不误砍柴工，推行不动就找QA，让QA从体系角度控制呗。

土土的豆豆

其实不论是否W模型还是V模型，任何阶段我们都应该对所有输出产物——文档进行评审。
这里针对设计文档，一般可以划分为需求设计、概要设计和详细设计，其实参与的涉众包括需求人员、设计人员、开发人员、测试人员、评审专家等。
开发、测试人员参与的设计文档评审，我们称之为“走读”，在技术领域也可以称为“技术评审”。所谓“走读”，其主要是对文档进行检查，通过走读发现文档中存在的缺陷（可能包括逻辑矛盾、描述模糊和文法错误等），同时参与人员也可以进行技术交流，初级人员也可以学习一些技术方面的知识，了解设计者的思路。而“技术评审”是一个相对正式的评审过程，其在规格、标准等方面进行评审，并在评审后给出相应得修改意见。
理论上，一些模块构架级别的东西，应该在概要设计阶段就已经的得到了解决。我们在评审时，不需要在框架问题上多花功夫。但是在实际操作中，一些构架方面的东西往往到编码的后期还在不停的修改。因此，在进行概要设计评审时，设计者应该做好改变甚至推翻模块原有框架的心理准备。
详细设计的评审，应该提前制定相应得计划，并做好充分的准备，制定评审的入口准则和相关规程，确定评审时间，安排相关组织者和与会人员，准备所需材料等。
同行评审由专门的组织者主持，并有作者和相关同行出席。其规模不宜过大，大致可以控制在七人以下。在会议过程中，可以先由作者对其详细设计进行讲解，引导大家进行走读。然后参与者们共同对详细设计进行评审，确认问题，并对其进行分类。
一般情况下，同行评审可以被控制在两个小时之内。一些简单的模块，可以把同行评审压缩到一个小时之内。在评审过程中，如果遇到问题需要延时，可以由作者决定是否召开“第三小时会议”。
评审结束后，有必要对评审问题进行跟踪，以便确认确陷的到了修改，并且没有引入新的缺陷。

所以可以用缺陷密度来度量和评价。
-缺陷：根据紧急程度/严重性、缺陷类型（内容缺陷、规范缺陷）进行分类统计评审人员的水平
-规模：设计文档的有效页数评审效率：单位时间的缺陷个数（个/人时）
-缺陷密度：单位规模的缺陷个数（个/页）

个人推荐使用软件工程的度量方法进行规范化操作。
大家可以参考《GB/T 16260 软件工程 产品质量》3个部分中 内部/外部度量标准进行评审工作。以下引用部分内容标准条款仅供参考。
文档的清晰性      
-是否所设计的架构，包括数据流、控制流和接口，被清楚地表达了      
-是否所有的假设、约束、策略及依赖都被记录在本文档了      
-是否定义了总体设计目标      

文档的完整性      
-是否所有以前的TBD（待确定条目）都已经被解决了      
-是否设计已经可以支持本文档中遗留的TBD有可能带来的变更      
-是否所有的TBD的影响都已经被评估了      
-是否仍存在可能不可行的设计部分      
-是否已记录设计时的权衡考虑，该文件是否包括了权衡选择的标准和不选择其他方案的原因      

文档的依从性      
-是否遵守了该项目的文档编写标准      

文档的一致性      
-数据元素、流程和对象的命名和使用在整套系统和外部接口之间是否一致      
-是否反映了实际操作环境（硬件、软件和支持软件）      

文档的可行性      
-从进度、预算和技术角度上看该设计是否可行      
-是否存在错误的、缺少的或不完整的逻辑      

文档的数据使用      
-所有复合数据元素、参数以及对象的概念是否都已文档化      
-是否还有任何需要的，但还没有定义的数据结构，反之亦然      
-是否已描述最低级别数据元素，是否已详细说明取值范围      

文档的功能性      
-是否对每一下级模块进行了概要算法说明      
-所选择的设计和算法能否满足所有的需求      
        
文档的接口      
-操作界面的设计是否有为用户考虑（例如：词汇、使用信息和进入的简易）      
-是否已描述界面的功能特性      
-界面将有利于问题解决吗？      
-是否所有界面都互相一致，与其他模块一致，以及和更高级别文档中的需求一致      
-是否所有的界面都提供了所要求的信息      
-是否已说明内部各界面之间的关系      
-界面的数量和复杂程度是否已减少到最小      
        
文档的可维护性      
-该设计是否是模块化的      
-这些模块具有高内聚度和低耦合度吗？      
-是否已经对继承设计、代码或先前选择工具的使用进行了详细说明性能      
-主要性能参数是否已被详细说明（例如：实时、速度要求、吞吐量等）      

文档的可靠性      
-该设计能够提供错误检测和恢复吗？（例如：输入输出检查）      
-是否已考虑非正常情况      
-是否所有的错误情况都被完整并准确地说明      
-是否满足该系统进行集成时所遵守的约定      
        
文档的易测性      
-是否能够对该系统进行测试、演示、分析或检查来说明它是满足需求的      
-该系统是否能用增量型的方式来集成和测试      
        
文档的可追溯性      
-是否各部分的设计都能追溯到需求说明书的需求      
-是否所有的设计决策都能追溯到原来确定的权衡因素      
-所继承设计的已知风险是否已确定和分析

以上大都通过国标GB/T 16260、文档同行评审等中进行引用和转载，大家随便瞅瞅吧~

海里的幸福

带翅膀的不一定是天使，我妈说，那是鸟人。

qlvgm

好帖，确实好帖！