W模型中要求对设计文档进行测试,如何对其进行有效的测试?（获奖名单已经公布）
本周的问题为“本周的问题为：W模型中要求对设计文档进行测试,如何对其进行有效的测试?”此话题由会员piaohuar2008提供，如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！
获奖名单
奖项获奖名单奖励答案链接
一等奖土土的豆豆 50元京东礼品卡#8
二等奖 300论坛积分
三等奖 100论坛积分
设计文档，是否符合用户需求，软件功能说明详细，文档内容易于理解，专业术语是否易于理解等等方面吧 终于有一个人回答了~~看起来这期的题目要难产了。冷门啊！ 设计文档测试，我认为是对文档的评审过程。
首先需要各部门相关人员进行评审，是否满足了需求； 然后在评审过程中，针对用户群体，讨论设计是否合理， 关于业务流程方面的实现，是否有不足之处；最后经过不断的修订，形成完善的设计文档；
当然，在评审过程中，要对一些术语进行定义、规范和统一；
这前期对文档的评审，是为后期的项目减少风险， 相当关键。 这题目是冷门啊，能运用W模型或规范执行的太少了，我这抛个砖吧。
W模型的设计文档包括：需求设计文档、概要设计文档、详细设计文档三类。W模型要求在完成设计文档后对设计文档进行测试，这比传统V模型更好地体现的“尽早测试”的概念。
我只做过国内项目，就从我的经验说说，存在偏颇希望大家多多讨论。
1、文档本身，对于设计文档本身的一些评测规范，我觉得应根据公司规模、人员素质等情况量身定做。比如 文档格式，需求表述方式，功能是否全面，变量、参数表示形式等。只要能清晰、尽量全面的表达出需求、设计意图即可。过分追求文档形式，会过犹不及的。
2、文档内容，需求是万恶之源啊。需求错误必然导致设计偏颇、然后便一错千里。后期的需求、设计变更更是梦魇。理想的做法，测试人员需求调研期间介入项目，由需求、设计、测试个方面共同完成需求调研。由于立场、经验不同所以需求分析报告会比较全面。
现实工作中，没多少公司会让测试人员前期介入，尤其是短期项目。这时，在进行设计阶段、测试负责人就要多与开发负责人沟通，阶段性的获取设计文档，别等最后设计完成后再获取，那时候就能检查是不是有错别字了。个人觉得在这种前期需求不介入的情况下，“工作经验”、“头脑风暴”往往会更好用。如果是陌生业务，很难在设计评审阶段指出“业务”上的问题。
对于长期项目，测试人员在设计文档的测试过程中还是有很意义的。长期厮混在某个项目，对于业务、系统架构都熟悉了。当项目有需求变更或后续需求时测试人员就可以快速介入，可以在文档测试中指出实质性的问题。
3、测试形式： “评审”是最常见的。在正式评审前，设计、测试人员可以内部举行讨论会，目的是消除“歧义”，包括设计思路、业务理解等方面的。必要时可以请需求人员参与。我觉得这种做法可以有效提高评审的效率。
为了确保业务、设计思路的准确。也可以预先做一个系统原型，给客户演示。客户可以很直观的感受产品，提出切实的意见。
4、参与人员： 在进行“需求设计”文档的评审时，最好有客户参与。概要和设计文档阶段基本都是项目组内人员参与，可以根据实际情况调配。
如果有“外围系统”参与开发，在相应阶段应邀请第三方参与评审。
对于重要项目，我们基本能做到就是这些，小项目基本就看个人实力了，呵呵，毕竟成本是个主要因素。 楼上说的很好啊，目前我们公司就是这样的思路，可惜执行起来大家都不是很配合，特别是对原型、设计的评审，效率极低。。。 楼上说的很好啊，目前我们公司就是这样的思路，可惜执行起来大家都不是很配合，特别是对原型、设计的评审， ...
caonianvicky 发表于 2013-12-18 10:00 http://bbs.51testing.com/images/common/back.gif
我觉得，对于常年都是一套业务，一系列产品的公司，开发和测试人员对系统都很熟悉了，这种“评审”可有可无，不如内部的讨论会实在。
对于新项目，这种评审还是很必要的，说句不好听的话，评审也是划清责任的会议，到时候项目出问题要找人算账，得有点依据啊。磨刀不误砍柴工，推行不动就找QA，让QA从体系角度控制呗。 其实不论是否W模型还是V模型，任何阶段我们都应该对所有输出产物——文档进行评审。
这里针对设计文档，一般可以划分为需求设计、概要设计和详细设计，其实参与的涉众包括需求人员、设计人员、开发人员、测试人员、评审专家等。
开发、测试人员参与的设计文档评审，我们称之为“走读”，在技术领域也可以称为“技术评审”。所谓“走读”，其主要是对文档进行检查，通过走读发现文档中存在的缺陷（可能包括逻辑矛盾、描述模糊和文法错误等），同时参与人员也可以进行技术交流，初级人员也可以学习一些技术方面的知识，了解设计者的思路。而“技术评审”是一个相对正式的评审过程，其在规格、标准等方面进行评审，并在评审后给出相应得修改意见。
理论上，一些模块构架级别的东西，应该在概要设计阶段就已经的得到了解决。我们在评审时，不需要在框架问题上多花功夫。但是在实际操作中，一些构架方面的东西往往到编码的后期还在不停的修改。因此，在进行概要设计评审时，设计者应该做好改变甚至推翻模块原有框架的心理准备。
详细设计的评审，应该提前制定相应得计划，并做好充分的准备，制定评审的入口准则和相关规程，确定评审时间，安排相关组织者和与会人员，准备所需材料等。
同行评审由专门的组织者主持，并有作者和相关同行出席。其规模不宜过大，大致可以控制在七人以下。在会议过程中，可以先由作者对其详细设计进行讲解，引导大家进行走读。然后参与者们共同对详细设计进行评审，确认问题，并对其进行分类。
一般情况下，同行评审可以被控制在两个小时之内。一些简单的模块，可以把同行评审压缩到一个小时之内。在评审过程中，如果遇到问题需要延时，可以由作者决定是否召开“第三小时会议”。
评审结束后，有必要对评审问题进行跟踪，以便确认确陷的到了修改，并且没有引入新的缺陷。
所以可以用缺陷密度来度量和评价。
-缺陷：根据紧急程度/严重性、缺陷类型（内容缺陷、规范缺陷）进行分类统计评审人员的水平
-规模：设计文档的有效页数评审效率：单位时间的缺陷个数（个/人时）
-缺陷密度：单位规模的缺陷个数（个/页）
个人推荐使用软件工程的度量方法进行规范化操作。
大家可以参考《GB/T 16260 软件工程 产品质量》3个部分中 内部/外部度量标准进行评审工作。以下引用部分内容标准条款仅供参考。
文档的清晰性
-是否所设计的架构，包括数据流、控制流和接口，被清楚地表达了
-是否所有的假设、约束、策略及依赖都被记录在本文档了
-是否定义了总体设计目标
文档的完整性
-是否所有以前的TBD（待确定条目）都已经被解决了
-是否设计已经可以支持本文档中遗留的TBD有可能带来的变更
-是否所有的TBD的影响都已经被评估了
-是否仍存在可能不可行的设计部分
-是否已记录设计时的权衡考虑，该文件是否包括了权衡选择的标准和不选择其他方案的原因
文档的依从性
-是否遵守了该项目的文档编写标准
文档的一致性
-数据元素、流程和对象的命名和使用在整套系统和外部接口之间是否一致
-是否反映了实际操作环境（硬件、软件和支持软件）
文档的可行性
-从进度、预算和技术角度上看该设计是否可行
-是否存在错误的、缺少的或不完整的逻辑
文档的数据使用
-所有复合数据元素、参数以及对象的概念是否都已文档化
-是否还有任何需要的，但还没有定义的数据结构，反之亦然
-是否已描述最低级别数据元素，是否已详细说明取值范围
文档的功能性
-是否对每一下级模块进行了概要算法说明
-所选择的设计和算法能否满足所有的需求
文档的接口
-操作界面的设计是否有为用户考虑（例如：词汇、使用信息和进入的简易）
-是否已描述界面的功能特性
-界面将有利于问题解决吗？
-是否所有界面都互相一致，与其他模块一致，以及和更高级别文档中的需求一致
-是否所有的界面都提供了所要求的信息
-是否已说明内部各界面之间的关系
-界面的数量和复杂程度是否已减少到最小
文档的可维护性
-该设计是否是模块化的
-这些模块具有高内聚度和低耦合度吗？
-是否已经对继承设计、代码或先前选择工具的使用进行了详细说明性能
-主要性能参数是否已被详细说明（例如：实时、速度要求、吞吐量等）
文档的可靠性
-该设计能够提供错误检测和恢复吗？（例如：输入输出检查）
-是否已考虑非正常情况
-是否所有的错误情况都被完整并准确地说明
-是否满足该系统进行集成时所遵守的约定
文档的易测性
-是否能够对该系统进行测试、演示、分析或检查来说明它是满足需求的
-该系统是否能用增量型的方式来集成和测试
文档的可追溯性
-是否各部分的设计都能追溯到需求说明书的需求
-是否所有的设计决策都能追溯到原来确定的权衡因素
-所继承设计的已知风险是否已确定和分析
以上大都通过国标GB/T 16260、文档同行评审等中进行引用和转载，大家随便瞅瞅吧~ 带翅膀的不一定是天使，我妈说，那是鸟人。 好帖，确实好帖！
static/image/common/sigline.gif
https://img.alicdn.com/imgextra/i4/871851027/TB2XlRhfdFopuFjSZFHXXbSlXXa_!!2-martrix_bbs.png
页:
[1]
