如何针对设计进行有效性测试？（09-3-30）（获奖名单已公布）

默默巫

如何针对设计进行有效性测试？

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

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	kukumaru	当当购物卡50元	17#
二等奖	贝贝酷	300论坛积分	22#

相关文章：

黑盒测试设计

软件设计中的可用性

MVC设计模式

更多内容请点击＞＞＞

贝贝酷

以下几方面对设计进行有效性测试：
1.产品设计的任何阶段都可以进行测试，只要条件允许也都应该进行测试品设计,什么时候进行测试，取决于你对于产品有什么样的问题，只要你有问题都应该去做。
  具体说一个例子：你现在要设计一个IM软件，和QQ基本相似；
那么，哪怕是在你的产品设计之初，只有简单想法还没有任何具体界面设计的时候，如果你有拿不准的问题一样可以通过测试解决。
  你可能会问“我什么都没有，拿什么去测？”。“拿QQ呗”；
  再往后，“纸原型”、“可简单演示的低保真原型”、“可互动的高保真原型”、“beta版本”都可以去做。
  补充一下：我说到的“测试”不局限于“找用户来作”，一样包括“访谈”和自己的“评估”。
2.测试最关键的点有5点：测试的准备、测试的方法、被测的人、测试的人、测试的环境
  所谓“测试的准备”主要指“明确测试的目的性”和“准备测试的问题”。往往我们很容易搞清楚自己“为什么测试”，目的性都不是什么大问题；
  但，“测试之前没有充分准备‘问题’测试中随机应变，导致测试结果大多没有什么价值”，这是大多数“经验丰富”之人常犯的错误，所以我建议：“在整个测试项目中，用50%的时间去做准备工作”；
  然后，如何准备问题也是非常重要的。比如，一个关于语音搜索的产品测试，可以 “从以往用户的录音中提炼问题来测试”而不要用“给话务员培训的对答脚本”来测试；
  还有，某领导往往喜欢用自己遇到的问题去测试，当我提到“这不一定是用户的问题”时，领导反倒理直气壮的告诉我“我就是用户呀”，我只能回答他：“在咱们自己的产品面前您只能是领导，不是用户”…
  关于“测试的方法”这个其实很简单，相信大多数科班出身的人都能很好的掌握。我只想不中听的提醒纯“心理学”专业的同学：站在“产品设计”的角度测试，而非纯粹的“心里测试”角度测试。
  这么说只是因为我遇到不少“心理学”专业的朋友，他们给了我这种感觉，导致一些测试结果对于“产品”本身的直接意义很小。（并非说完全没有作用）
“被测的人”指“如何明确自己产品的针对性用户群，如何找到准确的典型用户”。这些都是我们成天提到的东西，无需我来讲；
  往往“如何让被测者很好的与系统和测试者进行交互”其实是最大的课题，当你遇到一个“死活不说话、测试过程紧张无比”怎么都无法从他那里得到有效信息的被测者时，“暂时把话题扯开谈谈轻松的事情、聊聊家长、说说他喜欢的话题、甚至讲讲小笑话”都会是不错的做法。。。
  “测试的人”我就不说了，只有一个建议：测试的人和总结测试报告的人要是同一人。
  “测试的环境”是我最想强调的，这也是我个人一直不支持“在实验室”里测试的主要原因之一；我见过很多实验室设计的太“不自然”了（设计合理的实验室倒还好），用户在测试中根本没有平时使用的感觉；
我个人一般比较支持“低成本”的更加自然的测试环境，尽量不要改变用户平时用户的环境，只作为一个让他没有感觉到的“旁观者”或者“偷窥者”更合适。
  还比如，测试一个语音搜索产品的话务员操作系统，“把话务员“关”到严肃的实验室用个大摄像头对着他，自己龟缩在单面玻璃后面”的“科学”方式，还不如“去话务员工作的地方，把话务员的显示器切为双屏显示，通过另外的耳机旁听话务员正常工作”效果更好。
3.在应用用户测试的结果上一些建议
  1)首先，再强调一下“测试和评估之前的准备工作十分重要”，往往我们的测试可能有两种情况──
  第一种：你设计了两个杯子，你认为第一个设计比第二个设计好，你需要通过测试来验证你的观点；
  第二种：你设计了两个杯子，你不知道那一个更好，你需要通过测试来得到答案；
如果你明确了你的目的，然后又做了充分的准备，我想“提炼结果”应该不是大问题。
  2)不是所有用户说的都是对的，以用户为中心不等于“用户怎么说就怎么作”。
我见过一个人，测试中用户说“我觉得这个地方全部展开不好，太占空间了，应该收缩到下拉菜单里”，用户一走他马上就心花怒放的去改了。问他为什么？他告诉我：“这是用户说的”！
  第二天又测试了一个用户，这个用户说“这个地方其实很重要，收缩起来可能找不到，你应该给展开”。他晕了，问我“怎么办？”，我回答他：“我不是用户，”。
  3)其实我想说：“把用户的测试当作意见来源，而非指示来源。
  既然是意见就需要‘筛选’”，“提炼用户研究的结果最关键还是你自己的思考和辨别能力”，这种能力只能靠“你比任何人都更深入理解产品和用户”。同我回答“如何做好搜索引擎的用户研究？”一样：最基础的还是“至少每天搜索200个字以上”。
4.专家评估往往是站在专家的角度“用用户的模式思考”。
  “专家评估”之前一定要熟悉“产品架构和业务流程”，因为你提出的不应该只是“用户的问题”，还得包含“产品的因素”，这样才能很好的直接应用。
   我个人一直比较主张：“专家评估”之前一定要熟悉“产品架构和业务流程”，因为你提出的不应该只是“用户的问题”，还得包含“产品的因素”，这样才能很好的直接应用。
   专家评估的问题总结需要有技巧性，尽量要让问题的表现更加明了而且要出来修正的办法。我自己往往会用PPT的方式，先把问题分类然后再展示问题表现、问题分析、危险程度、修正办法等

最后，总结一下：
1、产品的任何阶段都可以进行测试，无需等待完整的设计完成之后；
2、测试和评估是随时随地的；
3、不一定在实验室的测试和评估就更好，我个人比较排斥那种“不自然”的方式；
4、把“数据”和“用户”相结合很重要；
5、作专门测试项目时，拿出50%的时间作准备工作；
6、测试的目的：验证观点或者得到观点；
7、读懂数据和提炼用户测试结果的基础是：深入理解自己的产品和用户。

black_tulip

17楼第一。

搂搂兔

有效性测试，我觉得比如以前邮箱空间不是很大时，有些网站号称能达到多少多少个M的邮箱空间，实际上仅仅是个噱头，并没有实现多么高的空间提供

志大才疏

我把题目划分为两个关键点：
1）设计：软件研发过程中的设计阶段 即概要设计和详细设计
2）有效性测试又称确认测试 即验证软件是否达到预期需求     这里的软件泛指软件生命周期中所有的软件工作产品

从而得知一般设计的有效性测试就是设计文档的评审。
如果想使其测试更全面、更细致、更有效，那就要相应的做一些扩充；一般来说从方法、过程、工具三个方面来扩充。

这里说得比较宏观，要详细说的话要写好多 ，所以就这样简而概之。

萧洛鸳

如何针对设计进行有效性的测试：设计的范围比较广，有前期需求分析的设计，测试计划的设计，测试用例的设计等多方面。针对需求分析方面的设计，在进行设计的时候通常主要有三方的代表，客户代表，开发代表和测试代表，当然中间肯定有技术总监进行评审，如果进行有效性的设计宗旨就是满足客户的需求另外一方面就是便于公司自己以后改进该版本的预留功能，只要满足了客户的需求这是设计是要重点考虑的，如何保证满足就是后期测试用例设计要全面考虑到的，按照测试用例设计的方法来进行全面详细的设计，比如等价类划分法，边界值法，因果图法，场景法等等。其实在设计测试用例的时候，要有个好习惯，就是根据需求画出流程图，所谓流程图就是实现功能的路径，根据流程图计算有多少条路径，然后针对每个路径设计测试用例，每个路径设计的测试用例至少应该包括2个方面，合法和非法。这样在进行用例设计的时候就会很方面，相对来说也会比较全面。

kukumaru

假设有个类别widget;我们希望能够针对该类别做有效性测试，通常我们可能会为widget定义一个is_valid()成员函数
widget w;
if (w.is_valid()) {...}

然而有时候我们可能更希望接口更直接点，比如：
error e;
if (e) {...}

这时候可以采取的一个方法是提供一个转型：
比如转至一个int

class error {
public:
    error (int code) : m_error_code(code) {}
    operator int() const {return m_error_code; }
private:
    int m_error_code;
};

通常我们并不鼓励这么做，自动转型暴露了内部数据，总是存在难以发现的隐患（我们应该尽可能遵循伟大的c_str()传统)；

另外一种转型operator bool也不被鼓励

class error {
...
   operator bool() const { return m_error_code != 0; }
};

原因是你有可能写出：

error e(1), e2(2);
if (e == e2) { ... }

在没有定义operator==的情况下，if (e == e2) 居然也可以通过，而且返回真。原因是e和e2都转型为bool后再做比较。

当然你可以定义operator==以消除这种状况的发生。

class error {
...
   operator bool() const { return m_error_code != 0; }
   bool operator==(const error& e) { return m_error_code == e.m_error_code; }
};

这时if (e == e2) { ... } 可以返回正确的结果，同时你也达到进行有效性测试的目的。

对于像smart_ptr这样的模板类别，情况会有点微妙的变化。你仍然可以进行有效性测试：

smart_ptr<int> s;
if (s) { ... }

但operator==却行为异常。因为你可能对着两个不同类型的smart_ptr进行比较，而对于不同类型的smart_ptr，并未有operator==被实作出来(你只会针对同型的smart_ptr实作operator==)：

smart_ptr<A> s1;
smart_ptr<B> s2;

if (s1 == s2) {... }
结果是显而易见的，s1,s2分别实施转型至bool，if比较返回true

正确的做法是基于不同的smart_ptr类型产生不同的可测试有效性的类型：下面是一个方法(MordenC++p178)

template <class T>
class smart_ptr {
    class nested_unspecified_type {
            void opeartor delete(void*);
    };
public:
    opeartor nested_unspecified_type*() const {
              if (!m_pointee) return 0;
   static nested_unspecified_type n;
   return &n;           
    }
};

nested_unspecified_type会声明而未定义void opeartor delete(void*); 的原因是阻止写出如下的delete代码:
delete smart_ptr<int>(new int);

另一个更加精妙的方法来自boost\system\error_code.cpp，即转型至一个函数指针
template <class T>
class smart_ptr {
    typedef void (nested_unspecified_type)();
    static void nested_unspecified_type_(){}
public:
    opeartor nested_unspecified_type() const {
              if (!m_pointee) return 0;
              return nested_unspecified_type_;
    }
};

延伸讨论：
上述除了opeartor==的行为需要考虑以外，其他的比较操作符也需要考虑，比如opeator!=, operator<等。如果没有定义这些操作符，那么smart_ptr或者error都会转型以完成比较，所以行为也就会未定义。

结论是：要定义有效性测试符，请采用转型为内部函数指针的转型符，同时也必须定义各种比较操作符

纽约的西瓜

额，这个问题可问住我这个菜鸟了。向各位学习了先

纽约的西瓜

额，这个问题可问住我这个菜鸟了。向各位学习了先

单尾鱼

这个问题，我不太了解，来向前辈们学习下

qingna0238

很多时候需求上的功能点可以很容易地测出：具体功能项有没有实现，难点在于实际用户的对软件的错误理解而造成的非法操作，引起的系统异常，使之不能正常工作，我往往是我们按照正常测试流程走很难测到的。所以用户在实际需求中，都隐含着对软件的健壮性的强列需求。而我们一般的测试流程中往往最容易忽略这一点。站在用户的角度来测，模似实际情况，才会更有效。

chengxq

需求--->功能点---->评审------>测试观点------>评审--------->测试用例-------->评审------->执行

firstflag

1 需求评审
2 设计方案评审
3 详细设计评审
4 测试用例设计（用合理的用例最大可能覆盖设计的方方面面）
5 版本测试（制定出合理的测试时间、计划、人力模块划分）
6 故障分析总结
7 测试复盘总结
8 文档修订（规程修订、方案修订）
如果每一步都能得到严格有效的执行，可以保证测试的有效性

rolei

严格的设计评审，应该是最有效的设计测试方法。

当然，这样的设计评审应当是多方参与的（干系人），包括客户、市场、需求、专家、开发、测试、维护.....
针对不同的干系人，进行必要的宣讲和阐述。
不同的人对评审的内容有所侧重，得出的结果也较全面。

默默巫

大家还是按标题＂如何针对设计进行有效性测试＂来进行回答吧．

yolander

原帖由 black_tulip 于 2009-3-31 13:30 发表


问题描述中说的“这种设计”是“用户提供或者自行整理的需求文档”。

在这个时候好像还不大会有接口，接口的实现代码，代码结构。

是，所以我说这个问题看的我很糊涂，到底是针对的用户需求，还是针对设计，能否请发问人来解释一下呢？

yolander

原帖由 lanbiers 于 2009-3-31 13:15 发表
有效性测试（又称功能测试）一般都先于编码过程，即通过对设计文档的理解，使用单元测试实现功能。
验证设计文档中的代码结构是可以满足预期功能的。
功能测试时，应针对接口迚行测试。
接口的实现代码可以在单元 ...

之前看标题的时候以为是说如何针对设计进行有效性测试
可后来看到内容时又说是针对“用户提供或者自行整理的需求文档”进行有效性测试，就把我弄糊涂了
如果是针对设计进行测试，主要是在设计和编码阶段，进行单元和集成测试
其中单元测试，主要是验证单元模块（或者类和对象）的输入输出以及数据流，查看其是否代码满足了详细设计文档中的要求
集成测试是在单元测试基础上进行，主要是验证模块间的接口问题，查看其是否满足该要设计文档中的要求
参考V模型，在测试时，是要假设下一层设计文档能够满足上一层文档的设计要求，这样反向推断
而下一层设计文档是否能满足上一层文档的设计要求，是需要按自顶向下的顺序，通过评审和审计的手段来控制和保证的

black_tulip

原帖由 lanbiers 于 2009-3-31 13:15 发表
有效性测试（又称功能测试）一般都先于编码过程，即通过对设计文档的理解，使用单元测试实现功能。
验证设计文档中的代码结构是可以满足预期功能的。
功能测试时，应针对接口迚行测试。
接口的实现代码可以在单元 ...

问题描述中说的“这种设计”是“用户提供或者自行整理的需求文档”。

在这个时候好像还不大会有接口，接口的实现代码，代码结构。

lanbiers

有效性测试（又称功能测试）一般都先于编码过程，即通过对设计文档的理解，使用单元测试实现功能。
验证设计文档中的代码结构是可以满足预期功能的。
功能测试时，应针对接口迚行测试。
接口的实现代码可以在单元测试中先行实现后，在单元测试通过后移入相应的源码包中。
功能测试时无需设计复杂的测试用例，只需要按照设计文档的预期输入设计测试用例，断言相关的接口输出为预期设计，如果单元测试通过，则可以推论设计是满足预期功能不设计的。

black_tulip

这个问题需要真正有经验的老同志来回答。