qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

几种常见SQL分页方式效率比较

     摘要: 分页很重要,面试会遇到。不妨再回顾总结一下。  1、创建测试环境,(插入100万条数据大概耗时5分钟)。createdatabaseDBTestuseDBTest--创建测试表createtablepagetest(idintidentity(1,1)notnull,col01intnull,col02nvarchar(50)null,col03datetimenull)--1万记录集declar...  阅读全文

posted @ 2011-11-09 16:42 顺其自然EVO 阅读(251) | 评论 (0)编辑 收藏

《Linux内核修炼之道》——分析内核源码如何入手?(上)

《Linux内核修炼之道》——分析内核源码如何入手?(上)

透过现象看本质,兽兽门无非就是一些人体艺术展示。同样往本质里看过去,学习内核,就是学习内核的源代码,任何内核有关的书籍都是基于内核,而又不高于内核的。

  既然要学习内核源码,就要经常对内核代码进行分析,而内核代码千千万,还前仆后继的不断往里加,这就让大部分人都有种雾里看花花不见的无助感。不过不要怕,孔老夫子早就留给我们了应对之策:敏于事而慎于言,就有道而正焉,可谓好学也已。这就是说,做事要踏实才是好学生好同志,要遵循严谨的态度,去理解每一段代码的实现,多问多想多记。如果抱着走马观花,得过且过的态度,结果极有可能就是一边看一边丢,没有多大的收获。

  假设全国房价上涨1.5%,假设80后局长是农民子弟,??,既然我们的人生充满了假设,那么我在这里假设你现在就迫不及待的希望研究内核中USB子系统的实现,应该没有意见吧?那好,下面就以USB子系统的实现分析为标本看看分析内核源码应该如何入手。

  分析README

  内核中USB子系统的代码位于目录drivers/usb,这个结论并不需要假设。于是我们进入到该目录,执行命令ls,结果显示如下:

  atm  class  core  gadget  host  image  misc  mon  serial  storage Kconfig 
  Makefile  README usb-skeleton.c

  目录drivers/usb共包含有10个子目录和4个文件,usb-skeleton.c是一个简单的USB driver的框架,感兴趣的可以去看看,目前来说,它还吸引不了我们的眼球。那么首先应该关注什么?如果迎面走来一个ppmm,你会首先看脸、脚还是其它?当然答案依据每个人的癖好会有所不同。不过这里的问题应该只有一个答案,那就是Kconfig、Makefile、README。

  README里有关于这个目录下内容的一般性描述,它不是关键,只是帮助你了解。再说了,面对“read我吧read我吧”这么热情奔放的呼唤,善良的我们是不可能无动于衷的,所以先来看看里面都有些什么内容。

  23 Here is a list of what each subdirectory here is, and what is contained in
  24 them.
  25
  26 core/        - This is for the core USB host code, including the
  27             usbfs files and the hub class driver ("khubd").
  28
  29 host/        - This is for USB host controller drivers.  This
  30             includes UHCI, OHCI, EHCI, and others that might
  31             be used with more specialized "embedded" systems.
  32
  33 gadget/        - This is for USB peripheral controller drivers and
  34             the various gadget drivers which talk to them.
  35
  36
  37 Individual USB driver directories.  A new driver should be added to the
  38 first subdirectory in the list below that it fits into.
  39
  40 image/        - This is for still image drivers, like scanners or
  41             digital cameras.
  42 input/        - This is for any driver that uses the input subsystem,
  43             like keyboard, mice, touchscreens, tablets, etc.
  44 media/        - This is for multimedia drivers, like video cameras,
  45             radios, and any other drivers that talk to the v4l
  46             subsystem.
  47 net/        - This is for network drivers.
  48 serial/        - This is for USB to serial drivers.
  49 storage/    - This is for USB mass-storage drivers.
  50 class/        - This is for all USB device drivers that do not fit
  51             into any of the above categories, and work for a range
  52             of USB Class specified devices.
  53 misc/        - This is for all USB device drivers that do not fit
  54             into any of the above categories.

  这个README文件描述了前边使用ls命令列出的那10个文件夹的用途。那么什么是USB Core?Linux内核开发者们,专门写了一些代码,负责实现一些核心的功能,为别的设备驱动程序提供服务,比如申请内存,比如实现一些所有的设备都会需要的公共的函数,并美其名曰USB Core。

  时代总在发展,当年胖杨贵妃照样迷死唐明皇,而如今人们欣赏的则是林志玲这样的魔鬼身材。同样,早期的Linux内核,其结构并不是如今天这般有层次感,远不像今天这般错落有致,那时候drivers/usb/这个目录下边放了很多很多文件,USB Core与其他各种设备的驱动程序的代码都堆砌在这里,后来,怎奈世间万千的变幻,总爱把有情的人分两端。于是在drivers/usb/目录下面出来了一个core目录,就专门放一些核心的代码,比如初始化整个USB系统,初始化Root Hub,初始化主机控制器的代码,再后来甚至把主机控制器相关的代码也单独建了一个目录,叫host目录,这是因为USB主机控制器随着时代的发展,也开始有了好几种,不再像刚开始那样只有一种,所以呢,设计者们把一些主机控制器公共的代码仍然留在core目录下,而一些各主机控制器单独的代码则移到host目录下面让负责各种主机控制器的人去维护。

  那么USB gadget那?gadget白了说就是配件的意思,主要就是一些内部运行Linux的嵌入式设备,比如PDA,设备本身有USB设备控制器(USB Device Controller),可以将PC,也就是我们的主机作为master端,将这样的设备作为slave端和主机通过USB进行通信。从主机的观点来看,主机系统的USB驱动程序控制插入其中的USB设备,而USB gadget的驱动程序控制外围设备如何作为一个USB设备和主机通信。比如,我们的嵌入式板子上支持SD卡,如果我们希望在将板子通过USB连接到PC之后,这个SD卡被模拟成U盘,那么就要通过USB gadget架构的驱动。

  剩下的几个目录分门别类的放了各种USB设备的驱动,比如U盘的驱动在storage目录下,触摸屏和USB键盘鼠标的驱动在input目录下,等等。

  我们响应了README的热情呼唤,它便给予了我们想要的,通过它我们了解了USB目录里的那些文件夹都有着什么样的角色。到现在为止,就只剩下内核的地图——Kconfig与Makefile两个文件了。有地图在手,对于在内核中游荡的我们来说,是件很愉悦的事情,不过,因为我们的目的是研究内核对USB子系统的实现,而不是特定设备或host controller的驱动,所以这里的定位很明显,USB Core就是我们需要关注的对象,那么接下来就是要对core目录中的内容进行定位了。

  分析Kconfig和Makefile

  进入到drivers/usb/core目录,执行命令ls,结果显示如下:

  Kconfig  Makefile  buffer.c  config.c  devices.c  devio.c  driver.c  
  endpoint.c  file.c  generic.c  hcd-pci.c  hcd.c  hcd.h  hub.c  hub.h  
  inode.c  message.c  notify.c  otg_whitelist.h  quirks.c  sysfs.c  urb.c  
  usb.c  usb.h

  然后执行wc命令,如下所示。

  # wc –l ./*
     148 buffer.c
     607 config.c
     706 devices.c
    1677 devio.c
    1569 driver.c
     357 endpoint.c
     248 file.c
     238 generic.c
    1759 hcd.c
     458 hcd.h
     433 hcd-pci.c
    3046 hub.c
     195 hub.h
     758 inode.c
     144 Kconfig
      21 Makefile
    1732 message.c
      68 notify.c
     112 otg_whitelist.h
     161 quirks.c
     710 sysfs.c
     589 urb.c
     984 usb.c
     160 usb.h
   16880 total

 drivers/usb/core目录共包括24个文件,16880行代码。core不愧是core,为大家默默的做这么多事。不过这么多文件里不一定都是我们所需要关注的,先拿咱们的地图来看看接下来该怎么走。先看看Kconfig文件,可以看到下面的选项。

  15 config USB_DEVICEFS
  16         bool "USB device filesystem"
  17         depends on USB
  18         ---help---
  19           If you say Y here (and to "/proc file system support" in the "File
  20           systems" section, above), you will get a file /proc/bus/usb/devices
  21           which lists the devices currently connected to your USB bus or
  22           busses, and for every connected device a file named
  23           "/proc/bus/usb/xxx/yyy", where xxx is the bus number and yyy the
  24           device number; the latter files can be used by user space programs
  25           to talk directly to the device. These files are "virtual", meaning
  26           they are generated on the fly and not stored on the hard drive.
  27
  28           You may need to mount the usbfs file system to see the files, use
  29           mount -t usbfs none /proc/bus/usb
  30
  31           For the format of the various /proc/bus/usb/ files, please read
  32           <file:Documentation/usb/proc_usb_info.txt>.
  33
  34           Usbfs files can't handle Access Control Lists (ACL), which are the
  35           default way to grant access to USB devices for untrusted users of a
  36           desktop system. The usbfs functionality is replaced by real
  37           device-nodes managed by udev. These nodes live in /dev/bus/usb and
  38           are used by libusb.

  选项USB_DEVICEFS与usbfs文件系统有关。usbfs文件系统挂载在/proc/bus/usb目录,显示了当前连接的所有USB设备及总线的各种信息,每个连接的USB设备在其中都会有一个对应的文件进行描述。比如文件/proc/bus/usb/xxx/yyy,xxx表示总线的序号,yyy表示设备所在总线的地址。不过不能够依赖它们来稳定地访问设备,因为同一设备两次连接对应的描述文件可能会不同,比如,第一次连接一个设备时,它可能是002/027,一段时间后再次连接,它可能就已经改变为002/048。

  就好比好不容易你暗恋的mm今天见你的时候对你抛了个媚眼,你心花怒放,赶快去买了100块彩票庆祝,到第二天再见到她的时候,她对你说你是谁啊,你悲痛欲绝的刮开那100块彩票,上面清一色的谢谢你。

  因为usbfs文件系统并不属于USB子系统实现的核心部分,与之相关的代码我们可以不必关注。

  74 config USB_SUSPEND
  75       bool "USB selective suspend/resume and wakeup (EXPERIMENTAL)"
  76       depends on USB && PM && EXPERIMENTAL
  77       help
  78         If you say Y here, you can use driver calls or the sysfs
  79         "power/state" file to suspend or resume individual USB
  80         peripherals.
  81
  82         Also, USB "remote wakeup" signaling is supported, whereby some
  83         USB devices (like keyboards and network adapters) can wake up
  84         their parent hub.  That wakeup cascades up the USB tree, and
  85         could wake the system from states like suspend-to-RAM.
  86
  87         If you are unsure about this, say N here.

这一项是有关USB设备的挂起和恢复。开发USB的人都是节电节能的好孩子,所以协议里就规定了,所有的设备都必须支持挂起状态,就是说为了达到节电的目的,当设备在指定的时间内,如果没有发生总线传输,就要进入挂起状态。当它收到一个non-idle的信号时,就会被唤醒。节约用电从USB做起。不过这个与主题也没太大关系,相关代码也可以不用关注了。

  剩下的还有几项,不过似乎与咱们关系也不大,还是去看看Makefile。

  5 usbcore-objs    := usb.o hub.o hcd.o urb.o message.o driver.o /
  6                         config.o file.o buffer.o sysfs.o endpoint.o /
  7                         devio.o notify.o generic.o quirks.o
  8
  9 ifeq ($(CONFIG_PCI),y)
  10         usbcore-objs    += hcd-pci.o
  11 endif
  12
  13 ifeq ($(CONFIG_USB_DEVICEFS),y)
  14         usbcore-objs    += inode.o devices.o
  15 endif
  16
  17 obj-$(CONFIG_USB)       += usbcore.o
  18
  19 ifeq ($(CONFIG_USB_DEBUG),y)
  20 EXTRA_CFLAGS += -DDEBUG
  21 endif

  Makefile可比Kconfig简略多了,所以看起来也更亲切点,咱们总是拿的money越多越好,看的代码越少越好。这里之所以会出现CONFIG_PCI,是因为通常USB的Root Hub包含在一个PCI设备中。hcd-pci和hcd顾名而思义就知道是说主机控制器的,它们实现了主机控制器公共部分,按协议里的说法它们就是HCDI(HCD的公共接口),host目录下则实现了各种不同的主机控制器。

  CONFIG_USB_DEVICEFS前面的Kconfig文件里也见到了,关于usbfs的,与咱们的主题无关,inode.c和devices.c两个文件也可以不用管了。

  那么我们可以得出结论,为了理解内核对USB子系统的实现,我们需要研究buffer.c、config.c、driver.c、endpoint.c、file.c、generic.c、hcd.c  hcd.h、hub.c、message.c、notify.c、otg_whitelist.h、quirks.c、sysfs.c、urb.c 和usb.c文件。这么看来,好像大都需要关注的样子,没有减轻多少压力,不过这里本身就是USB Core部分,是要做很多的事为咱们分忧的,所以多点也是可以理解的

posted @ 2011-11-09 16:38 顺其自然EVO 阅读(261) | 评论 (0)编辑 收藏

软件探索性测试 笔记三

 *把所有要做的事情按照优先级排序,然后从最重要的事情做起

  进行局部探索式测试的决策的5要素:输入、状态、代码路径、用户数据、执行环境

  输入:

  1、识别哪些输入值和其他输入有关联,在同一个测试用例中使用它们

  2、识别和考虑输入的先后顺序

  3、注意区分非法输入是input filter、还是input check,还是使用exception

  *留意是否可以绕过input filter

  *留意ctrl,alt,shift按键组合的字符,找出特殊字符

  4、注意测试不输入任何值的情况、默认值的情况

  *留意默认值能否修改、删除

  5、根据输出结果来选择输入

  *可以有时候先观察输出结果,然后再选择新的输入

  *注意初始状态对输出地影响,是否要重复运行测试几遍

  *输出结果是否可以保存?尝试改变保存的输出值,看看改动这些值后,是否会重新生成,或者有新的问题

  状态:

  1、确认软件状态是临时的,还是长期保存的

  2、使用状态信息来帮助寻找相关的输入

  3、使用状态信息来辨识重要的输入序列

  *例如状态变化在某种方式上被累加起来,就必须考虑是否会发生溢出

  代码路径:

  弄清输入会导致软件走的那条分支

  用户数据:

  使用用户的真实数据(你可能不清楚所有数据的相互关系和结构,用真实的数据可以弥补这点)

posted @ 2011-11-09 16:30 顺其自然EVO| 编辑 收藏

互联网产品需求管理杂思2——需求收集

需求收集是进行产品需求管理的第一步。需求收集得到的各种用户需求素材是产品需求的唯一来源。可以说需求收集的质量影响着产品最终的质量。

  1、需求收集目的

  需求收集的目的在于:通过以市场为导向的客户需求收集,保持公司产品的核心竞争力,最终实现产品创新。具体说来:

  1)深刻理解市场需求、用户需求,准确把控行业发展趋势,保持高度的市场敏感度。

  2)保证产品研发是围绕客户需求来展开,真正实现产品研发“以市场为导向、以客户为中心”,而不是闭门造车。

  3)实现产品创新。通过有创新性的新卖点、新产品的持续不断推出,保证公司产品核心的竞争优势。

  4)及时获得竞争对手相关产品及市场策略,做到“知己知彼”。

  5)通过需求收集等相关活动,有机串接市场营销部门与产品研发部门,建立跨职能部门、端到端的流程进行需求开发。

  6)加强与用户互动,提升用户忠诚度及粘性。

  2、需求收集指导原则

  互联网并不缺少用户需求,恰恰相反,用户需求泛滥。面对市场上众多的“需求”,那些才是真正的用户需求呢,那些需求符合公司的产品战略要求呢?

  需求采集的指导原则:

  以公司的产品愿景、产品战略为指导

  产品愿景及战略决定了:需求采集应该面向那些细分的目标用户群,而非普遍撒网;对不同的用户需求进行优先级排序出现需求冲突时候取舍的标准;确定能实现或者不能实现的需求。

  以用户欲望为准绳,给用户带来“价值”而非“功能”

  3、需求收集方法

  1)建立需求收集机制:明确每个需求收集活动参与者的岗位职责、建立需求预处理流程、周期性的重复需求收集活动。

  2)使用统一的需求收集系统。

  3)采取一定的需求收集技术和方法。

  关于需求收集的方法,如何做好需求收集 这篇文章讲解得比较详细,可以参考其内容。

  用于需求收集的常见手段包括:

  ● 原型法
  ● 头脑风暴
  ● 用户访谈法
  ● 问卷调查法
  ● 标杆分析法
  ● 观察不期而遇的用户
  ● 各种会议(如用户大会、展览会、学术研讨会等)
  ● 现场支持
  ● 和支持团队(运营团队、技术支持团队)谈话
  ● 客户热线
  ● 客户满意度调查
  ● 用户行为分析
  ● 合作开发

 一些思考:

  1)需求收集应该收集用户真正面临的问题和业务场景,这样才能够捕获用户真正的需求,而不是只盯住用户提出系统需要实现什么样的功能,“需求收集”不是“需求汇总”。

  2)用户要的是产品的“价值”,而非产品的“功能”。只有当一个产品功能真正帮客户解决问题,这个功能才具有价值,也才真正有“功能”。

  3)需求收集流程要真正发挥作用,必须在组织层面通过组织管理制度及绩效考核制度来保证,将需求收集纳入到各相关部门的绩效考核中。不能指望大家三分钟的热情。

  4)需求收集流程的执行情况是一个公司管理是否规范的试金石,也可以衡量一个公司是否真正“以市场为导向、以客户为中心”。

  5)需求收集既要避免“什么都要做”的冲动,又要避免“只关注当下需求”,核心根源还是在于产品战略是否清晰。

  6)常规的需求收集手段并不能够解决产品创新问题,但如果没有持续的需求积累,创新就无从谈起,创意的灵光源于专业。

  7)尊重竞争对手和用户。竞争对手和用户并不像我们想象的那么愚蠢,以自己的标准来度量别人的产品才是真正的愚蠢。很多时候我们从自己的预设立场出发,否定掉了众多创新机会。对竞争对手,我们应当首先成为其产品忠实用户;对用户,我们应当通过用户社区等互动手段来“倾听用户的心声”。

  4、需求收集理论模型

  4.1、$APPEALS:收集市场需求的工具

  APPEALS方法是IBM在IPD总结和分析出来的客户需求分析的一种方法。它从8个方面对产品进行客户需求定义和产品定位。

  ● $-产品价格(Price)
  ● A-可获得性(Availability)
  ● P-包装(Packaging)
  ● P-性能(Performance)
  ● E-易用性(Easy to use)
  ● A-保证程度(Assurances)
  ● L-生命周期成本(Life cycle of cost)
  ● S-社会接受程度(Social acceptance)

  关于$APPEALS可以参考 $APPEALS市场需求和产品定位工具

  4.2 客户满意度模型(Kano模型)

  KANO模型定义了三个层次的顾客需求:基本型需求、期望型需求和兴奋型需求。这三种需求根据绩效指标分类就是基本因素、绩效因素和激励因素。

  基本型需求:顾客认为产品“必须有”的属性或功能。当其特性不充足(不满足顾客需求)时,顾客很不满意;当其特性充足(满足顾客需求)时,无所谓满意不满意,顾客充其量是满意。

  期望型需求:耍求提供的产品或服务比较优秀,但并不是“必须”的产品属性或服务行为有些期望型需求连顾客都不太清楚,但是是他们希望得到的。在市场调查中,顾客谈论的通常是期望型需求,期望型需求在产品中实现的越多,顾客就越满意;当没有满意这些需求时,顾客就不满意。

兴奋型需求:要求提供给顾客一些完全出乎意料的产品属性或服务行为,使顾客产生惊喜。当其特性不充足时,并且是无关紧要的特性,则顾客无所谓,当产品提供了这类需求中的服务时,顾客就会对产品非常满意,从而提高顾客的忠诚度。

  一旦每个需求都得到了明确的分类,就能够在需求收集过程对需求进行优先次序排序。

  关于Kano模型的详情,可以参考kano模型 及 需求入门 - 用Kano模型来确定需求优先级。

  4.3 层次分析法(AHP, Analytic Hierarchy Process)

  在做需求收集时候,最为麻烦是确定用户需求的优先级,利用层次分析法(AHP, Analytic Hierarchy Process)可以从不同的方面(如重要性、风险、成本)等角度去比较每两个用户需求之间的优先顺序。

  层次分析法将决策总是有关的元素分解成目标、准则、方案等层次,在此基础之上进行定性和定量分析的决策方法。这种方法的特点是在对复杂的决策问题的本质、影响因素及其内在关系等进行深入分析的基础上,利用较少的定量信息使决策的思维过程数学化,从而为多目标、多准则或无结构特性的复杂决策问题提供简便的决策方法。尤其适合于对决策结果难于直接准确计量的场合

  在IBM Rational Focal point中提供了层次分析法对需求进行排序。

4.4 四象限定位法

  四象限定位法以需求的急需性作为横轴,需求的重要性作为纵轴,可以建立如下的消费者需求四象限图:

  具体内容可以参考 四象限定位法。

  当然还是其他的一些方法,例如:Delphi方法、亲和图法(Affinity Diagram)等。

  5、创新产品的需求收集:你是否有自己的idea bucket?

  对于众多颠覆性创新的产品,其核心的创意很多时候与现有产品的需求及要求是相互矛盾的,因此这些创意是不可能完全依赖现有产品的需求收集过程得出来。

  当然任何创意也不可能从空而降,这些创新性产品之所以能够脱颖而出,根本原因还是在于这些产品经理们对于所在行业的用户真实需求及痛苦之处有深刻的了解,然后“Think Different”。别的产品经理们在审视收集的各种需求时候把这些创意作为“不靠谱”的需求而过滤掉了,而这些创新产品的产品经理去把这些需求作为一个创新的机会来把握住了。

  因此创新产品的需求仍然可以收集,只不过相对于普通产品的需求收集过程,我们在标准上应当更加开放。在需求收集平台中,我们应当单独留出一个创意桶(idea bucket),专门用于收集、汇总各种产品需求、创意、设想等,并定期在公司层面回顾这些创意,以发掘产品创新的机会。

  前面的Kano模型也经常用于产品创新领域。

  6、常用需求管理软件

  除了使用自行开发的软件来实现统一需求收集外,一些常用的需求管理软件也可以用于类似场合:

  IBM Rational Focal Point

  IBM Rational Requisite Pro

  IBM Rational DOORS

  Jira

  Borland Caliber RM

  其中Focal Point用于需求收集是最为合适的工具。

相关链接:

互联网产品需求管理思考1——统一需求管理

posted @ 2011-11-09 16:23 顺其自然EVO| 编辑 收藏

远程测试的实施方法探讨及实践

  一、现有测试实施方式中可能遇到的问题

  在实际应用系统测试中,我们经常遇到一些系统部署范围较大的案例:比如某行业产品数据管理系统,其数据的采集工作由各地市级的生产单位执行,数据采集完毕后经由地市级分子公司汇总并上传到省局级分公司,在由省局级分公司上传至国家局总部进行最终的汇总和统计,以供领导进行整体规划和决策。由于其结构特点,可以将系统由上至下划分为总中心系统、省局系统、地市级系统和生产单位业务系统四部分(有时地市级系统和生产单位业务系统合并,即为总中心、省局、地市三部分),各部分由对应级别的业务单位使用、管理和维护。对于这类系统测试,常规的实施方式大多在计划阶段将不同级别模块的测试工作划分,并安排在不同时间和地点进行测试,或由不同的测试队伍分别进行测试。

  由于以上特点,测试实施过程中往往需要针对上下级系统间衔接、数据一致及数据传输性能等质量特性增加一部分额外的测试工作,以确保系统工作能力的验证。那么,是否有办法减少这部分的额外工作,以比较快捷的方式实现不同地域、不同级别系统测试工作的协同实施呢?我们在某次测试工作中的经历为这个问题提供了一个参考思路。

  二、一次测试实施的启发

  这次测试是为某通信企业小型机服务器设备选型而进行的性能测试,参与测试厂商多为国内外知名的设备供应商,测试使用预先确定的统一业务框架和数据,由参测厂商提供多款不同档次的小型机服务器搭建工作环境,确保在相同构架、相同业务量的情况下对不同型号设备进行性能比对。当时由于某参测厂商的一款主打产品在国内没有现货,经多方商讨后,决定使用其远在美国总部的实验室设备部署测试环境,测试工作小组在国内通过专用网络远程访问测试环境和执行测试,测试实施过程确保由组织者进行监督和控制。为此,在测试小组工作地点和实验室环境分别向电信部门申请了专用链路,以便双方跨地域的通讯连接。测试过程中,测试小组派专人赴实验室环境协助环境部署和设备管理,其它人员在国内环境实施测试工作,并及时将数据汇总整理后上报组织单位。这样的远程测试环境,为我们进行一些大规模系统的测试实施提供了全新的解决途径。

  三、远程测试实施方式简述

  上述案例中的重点是通过专用电信链路在两地间形成快速有效的通讯环境,将测试环境和实验室环境构建成专用局域网,并通过远程访问管理工具提供了即时操作界面,确保异地测试实施的顺利进行,同时因为不需要测试团队全体奔赴国外,避免了相关组织工作可能造成的延误,并有效地节约了时间和测试实施成本。参考上述模式,我们可以考虑将不同地域子系统纳入统一的测试环境,以集中的方式对分布在各地的不同级别系统进行测试。

  要构建这样的测试环境,搭建两地甚至是多地间的有效连接是关键。目前主要的实现方式有两种:一是向电信部门申请专用链路,确保各地有效连接,这种方式实施成本略高,但连接效果较好,传输速度和数据量均有所保障,还可以通过专用工具如VNC等远程访问管理工具进行管理和控制,系统安全性和独立性方面比较可靠;二是直接通过Internet进行连接,利用一些通讯工具提供的远程访问功能实现异地交互的需求,这种方式实现成本较低,但是通讯效果受两地间链路影响较大,所能承载的传输数据量较为有限,此外系统安全受工具自身安全性影响较大。

 四、远程测试实施的特点分析及展望

  上面对远程测试的实现方法做了初步的探讨,那么远程测试实施自身都有哪些特点呢?我们认为,首先应看到远程测试实施所具备的以下优点:

  1、实施方式贴近系统实际工作情况,实时性较强,测试人员可以按照各个业务系统间正常的工作方式安排测试任务。

  2、测试人员可以直观的了解各级系统衔接、数据传输等业务工作状态,避免了因分时分组实施测试而可能造成的沟通问题,测试人员可以更加专注于业务流程的分析和特定功能的集中验证。

  3、因为测试工作划分上更加趋近于系统业务流程,因此更加有利于测试工作的组织和管理,类似于多级系统交互的复杂案例的执行不在是困难。

  4、便于以集中的形式实施系统测试,测试小组内部交流更加快捷方便,有利于测试人员从宏观角度分析和掌握系统特点。

  5、便于测试组织及实施人员差旅安排,一定程度上可以降低测试实施成本,为更加合理有效的利用测试经费提供了更多的选择空间。

  同时,远程测试实施中需要还注意以下问题:

  1、由于涉及将不同网络进行连接,安全性方面必须谨慎对待。

  2、复杂的链路必然影响操作的响应速度,目前远程测试实施环境不适合传输大规模数据,涉及系统外大规模业务数据传输时建议事前准备或通过其它方式传输。

  3、以第一种实现方式而言,必然存在申请专用链路的成本,选择时需要权衡利弊。

  4、测试前期准备工作比较复杂,需要考虑充分,同时需要多方面协调与沟通。

  5、对网络链路依赖较大,特别是第二种实现方式完全依赖于Internet的传输效果。

  6、人员组织安排有别于传统测试实施方式,权责划分将更加复杂。

  7、需要加强对测试环境的管理和监督。

  8、目前可利用的工具较为有限,远程测试实施的环境部署的复杂度较高。

  虽然存在一些未知因素,但是可以预见的是,随着网络技术的发展和通讯软件的不断更新,方便快捷的构建远程测试环境将不是一个梦想。对于软件测试工作者,尤其是我们第三方软件测试机构而言,测试实施过程也将面临更多的选择。

posted @ 2011-11-09 16:13 顺其自然EVO 阅读(164) | 评论 (0)编辑 收藏

针对B/S客户端进行性能测试的几个关键问题

针对B/S客户端进行性能测试的时候,会遇到很多技术难点,往往成为性能测试的礁石。有些难题,虽然看起来是个小问题,但是如果没有科学的解决办法,往往会影响整个测试项目的进度,带来很大的损失。

  基于以往性能测试项目的经验,本文总结了针对B/S客户端进行性能测试时遇到的多个关键技术问题,愿与业内同行进行深入探讨,共同提升测试能力。

  1、性能测试脚本录制最重要的地方

  性能测试脚本录制最重要的地方,个人认为有以下三个方面:

  第一,在性能测试之前要先做程序的功能验证。这是最开始要做的事情,要确保厂商程序的被测功能点都是正确的。功能验证都不通过,性能测试所做的一切都没有意义了,同时,功能验证的过程也是熟悉业务的过程,对于测试工程师非常重要;

  第二,参数化分析。虽然参数化本身非常重要,但是更重要的是参数化的分析,要分析哪些值需要做参数化,这才是关键;

  第三,做关联。做关联可能是最难了,因为需要分析服务器返回的数据,要对程序的流程有个彻底的了解。做关联的难点还是对程序流程的理解,并不是关联本身。

  2、测试脚本的第一次录制

  对B/S客户端进行第一次脚本录制,测试工程师需要注意以下几个方面:

  1)在测试脚本录制之前,测试工程师应该已经对测试规范进行熟悉了,第一次脚本录制的目的之一就是要按照测试规范实际进行一步步的操作,看看是否会遇到一些报错的问题;

  2)通过第一次脚本录制,测试工程师需要了解被测程序的各个功能是否已经实现以及实现的方式是怎么样的。虽然是性能测试,但是对于功能的理解,流程的把握是相当重要的;

  3)B/S性能测试脚本里面,核心的问题就是要把参数化做好。所以第一次录制脚本,测试工程师要仔细的观察程序变化,要看一看哪些地方是需要做参数化的,以及做参数化的难易程度问题。

  3、在测试脚本里找不到需要参数化的那个值

  问题描述:按照测试规范的要求,需要对一个数值进行参数化,但是在脚本中没有发现这个值,参数化无法进行。

  解决方法:这是属于厂商实现机制的问题,测试工程师需要和厂商进行沟通,让厂商修改程序,使被参数化的值能够在脚本中显露出来,这样,性能测试才可能顺利进行。

  4、参数文件里不能有空行

  问题描述:在实际测试中,我们配置了11个参数文件,跑10个循环没有错误,很正常,但是跑100个就报错了。

  解决方法:把报错的链接从IE中打开,发现有几个值是空的,因此而报错。打开脚本,看参数文件,界面里显示的确实是11个值,没有更多的值了,但是从记事本里把参数文件打开,按Ctrl+A,发现在后面几行里有空行,就是因为这个空行才报的错。所以发现,参数文件里不能有空行,对于空行,系统也是识别的。

  5、极限测试中测试终止条件必须定义明确

  问题描述:起初,性能测试终止条件定义的是CPU的最高值以及事物通过率的最低值,后来发现这些条件其实都是很难达到的。尤其在极限测试的时候,终止条件显得尤其重要,没有终止条件就没有办法达到极限了。

  解决方法:需要定义更细的终止条件,而且在一定的时间内能够达到,要不然无法进行极限测试。

  6、用LoadRunner监控Linux及Unix资源不稳定

  问题描述:用LR监控Linux及Unix资源,有时监控会断掉,就无法监控资源了

  解决方法:有时候确实会出现这个问题,所以在实际测试中首先要用LR对服务器进行监控,同时使用服务器自身的NMON函数来收集数据,把应用服务器和数据库服务器的CPU、内存、硬盘IO等的值都收集下来。

  7、使用NMON函数要注意的事项

  第一,NMON函数是在服务器端本地启动的,所以每次使用都需要登陆到服务器把NMON打开。查看NMON是否打开的命令是:ps –ef|grep nmon。

  第二,NMON函数的原理是把每次收集的数据都放到了一个文件里,所以每次开始新一轮的测试,都需要关闭上一次开启的NMON,然后打开一个新的NMON,以便容易区分数据。

  第三,要把时间校准好。作为控制台的那台测试机的时间、应用服务器的时间、数据库服务器的时间,这三个时间要校准,没有必要去确认哪个时间准确,需要做的是把这三个时间的差别算出来,要以做控制台的测试机的时间为基准。

posted @ 2011-11-09 16:06 顺其自然EVO| 编辑 收藏

致所有致力于测试的新手

 今天并不是什么特殊的日子,只是最近郁闷,至于何来,并没有太多的出处。可能是技术上的不服,也可能是人际关系上的问题。总之,自己也是新手,亦想早日成为高人,在职场上早日立足。至于这些凌乱繁琐的关系,有必要和朋友们分享一下自己的经历和感触。

  为什么选择学测试?你最好搞清楚这个问题,否则会很容易迷失方向。我的朋友圈子中,有很多,才开始自己的测试生涯,却已经被其他的旁支所迷惑,比如最终投身去做开发。我尊重他们的选择,也理解他们无法在短期内整理出自己的思路,不能怪他们。但是我想说,无论你选择什么道路,都必须坚持走下去。毕竟,世界上捡芝麻丢西瓜的事情谁也说不准。 当然,反过来,可能是你的造化。当然,造成你无法确定做测试还是做开发的根本原因无异于一句话:“测试人员跟在开发人员后面,没有前途的,技术上也被开发鄙视。” 对于不了解行情的新手来说,这是一句迷惑,答案只有自己投身之后才知道。却因此而放弃走测试的路,我认为,很不值。我可以说,测试行业正在日趋规范化,前途是光明的。只要有自信和技术,你怕什么呢? ——还有人说,测试不需要动脑子,简单,做不下开发了,来做测试。这的确是一条出路,不过往后你会发现,一旦你这么想了,成功也就越来越远了。很显然,缺乏激情和想象力,促使你放弃了做开发,那么什么保证你将来不放弃作测试呢?测试很简单?如果是,那么你就是被开发鄙视的测试人员,也没有什么目标可言了。结论:既然选择了,就要为了自己的目标走下去。

  测试需要什么技术?很多。相对于开发而言,新手做测试,对于狭义理解的技术要求相对比较低。狭义的技术是指计算机技术,编程技术,数学运算技术等一些硬技术。要求虽然低,但是不是没有要求。不过,这些硬技术绝对是不够的。扎实了这些技术,你能够获得一个饭碗,是你生存的工具。至于你能吃上什么菜,完全需要广义的技术来决定。凡事都是2/8原则的,交流和做人无异于其他行业的职场。这些技术,你自己去体会和累积,没有人能帮你。至于有些人喜欢背后议论,职场上有些表面上喜欢说好话,却不做实事的人而言,你自己的心态显然没有放端正。仅仅只知其一不知其二的臆断会令你丧失判断力和交际能力。有些人就是天生讨人喜欢,我们无法去嫉妒他们。因此,我也希望,我能和论坛上的朋友,一起努力,做一个有技术的人。免得出现电影中的台词:“一点技术含量都没有。”想想就可笑啊……

  怎样建立良性循环的交流圈? 这里,我有时候忍不住想说,我们的论坛还不够活跃。难道这不是一个很好的平台么?说废话也没用,希望大家多多发帖讨论吧。技术上的争论,没有什么可以保留的。虽然,我也知道,身为版主,有时候说话很激进,但是,我同样也希望各位能共同促进技术上的交流和发展。Improve together。测试,是团队项目,相信大家都明白。说这些,仅仅因为发现,新手园地每日的报道新兵很多,发话和提问的很少。我会把责任归在自己办事不利的身上,希望我的公告能起到积极效果。

  最后,说点实际的内容。想学东西,每个人都有过的念头。至于新手如何才能更快更有效率的学习,我有几点方法和大家共享一下:

  1、不要试图自己是牛人,一下子什么都要学,给自己个宽恕和计划,半年能精通一门技术,已经很值得羡慕和崇拜了。

  2、不要去买很多书,尤其是中文书,太误导人了。 英语好的,多看看原版,思路清晰易解。英语不好的,去借鉴朋友的经验,比看书学的快得多。所以,交流比什么都重要。

  3、学测试,入门的,从纯黑盒的理论和测试用例的编写学起。

  4、做测试,数据库非常重要,至少要强迫自己能非常熟练一门数据库平台。

  5、所谓学技术,拿台电脑,摸几下鼠标,点几下键盘,自己操作,别光看别人演示,看会了,立即就会忘的。

  6、学编程,新手自己动脑子,别总是想着改代码,改不出高手的。想看资料的,请在WINDOWS环境下按F1,看懂了,自然成高手了。

  不多说了,大家一起努力。

posted @ 2011-11-09 15:41 顺其自然EVO| 编辑 收藏

sql语法大全 菜鸟版

SQL分类:
DDL—数据定义语言(CREATE,ALTER,DROP,DECLARE)
DML—数据操纵语言(SELECT,DELETE,UPDATE,INSERT)
DCL—数据控制语言(GRANT,REVOKE,COMMIT,ROLLBACK) 首先,简要介绍基础语句:
1、说明:创建数据库
CREATE DATABASE database-name

2、说明:删除数据库
drop database dbname

3、说明:备份sql server
--- 创建 备份数据的 device
USE master
EXEC sp_addumpdevice 'disk', 'testBack', 'c:mssql7backupMyNwind_1.dat'
--- 开始 备份
BACKUP DATABASE pubs TO testBack

4、说明:创建新表
create table tabname(col1 type1 [not null] [primary key],col2 type2 [not null],..)根据已有的表创建新表:
A:create table tab_new like tab_old (使用旧表创建新表)
B:create table tab_new as select col1,col2… from tab_old definition only

5、说明:删除新表drop table tabname

6、说明:增加一个列

Alter table tabname add column col type注:列增加后将不能删除。DB2中列加上后数据类型也不能改变,唯一能改变的是增加varchar类型的长度。

7、说明:添加主键: Alter table tabname add primary key(col) 说明:删除主键: Alter table tabname drop primary key(col)

8、说明:创建索引:create [unique] index idxname on tabname(col….) 删除索引:drop index idxname注:索引是不可更改的,想更改必须删除重新建。

9、说明:创建视图:create view viewname as select statement 删除视图:drop view viewname

10、说明:几个简单的基本的sql语句选择:select * from table1 where 范围插入:insert into table1(field1,field2) s(1,2)删除:delete from table1 where 范围更新:update table1 set field1=1 where 范围查找:select * from table1 where field1 like ’%1%’ ---like的语法很精妙,查资料!排序:select * from table1 order by field1,field2 [desc]总数:select count * as totalcount from table1求和:select sum(field1) as sum from table1平均:select avg(field1) as avg from table1最大:select max(field1) as max from table1最小:select min(field1) as min from table1

11、说明:几个高级查询运算词
A: UNION 运算符
UNION 运算符通过组合其他两个结果表(例如 TABLE1 和 TABLE2)并消去表中任何重复行而派生出一个结果表。当 ALL 随 UNION 一起使用时(即 UNION ALL),不消除重复行。两种情况下,派生表的每一行不是来自 TABLE1 就是来自 TABLE2。
B: EXCEPT 运算符
EXCEPT 运算符通过包括所有在 TABLE1 中但不在 TABLE2 中的行并消除所有重复行而派生出一个结果表。当 ALL 随 EXCEPT 一起使用时 (EXCEPT ALL),不消除重复行。
C: INTERSECT 运算符
INTERSECT 运算符通过只包括 TABLE1 和 TABLE2 中都有的行并消除所有重复行而派生出一个结果表。当 ALL 随 INTERSECT 一起使用时 (INTERSECT ALL),不消除重复行。 注:使用运算词的几个查询结果行必须是一致的。

12、说明:使用外连接
A、left outer join: 左外连接(左连接):结果集几包括连接表的匹配行,也包括左连接表的所有行。
SQL: select a.a, a.b, a.c, b.c, b.d, b.f from a LEFT OUT JOIN b ON a.a = b.c
B:right outer join: 右外连接(右连接):结果集既包括连接表的匹配连接行,也包括右连接表的所有行。
C:full outer join: 全外连接:不仅包括符号连接表的匹配行,还包括两个连接表中的所有记录。

td { font-size: 12px } .commentTextBox { font-family : Verdana; font-size: 13px; } .userData { BEHAVIOR: url(#default#userdata) }

posted @ 2011-11-09 09:38 顺其自然EVO 阅读(173) | 评论 (0)编辑 收藏

软件探索性测试 笔记二

 测试十戒律:

  1、你应该使用大量输入,来反复锤炼被测的应用程序

    *大规模的随机测试(自动化),而且有助于理解输入和输出的关系;

  2、你应当贪图你的邻居的应用程序

  3、你应当亲自寻找睿智的预言家

    *对应的输入是否有对应的输出,也就是测试基准是否清楚的了解特定输入和环境条件组合的情况;

    *尝试让测试基准自动化,也许做不到,但是这样思考你可以选择做更有效率的工作

  4、你不应该崇拜无法重现的失效

    *尽最大努力注意并记住(或记录下)对软件采取的动作次序,同时记住应用程序的响应;

    *考虑使用调试器之类能追踪动作和软件状态的工具;

    *警惕为它白白花去了一整天的时间;

  5、你应该尊重你的模型和自动化测试

    *测试模型是关于应用程序做些什么(即模型)和怎么去做(即自动化测试)的点滴智慧的结晶;

    *即使做不到自动化,也应该尝试;

  6、你应该利用开发人员的过错与他们作对

    *总结开发人员的错误类型,理解他们自己的错误模式,然后将该类型错误的测试运用到该开发人员编写的每个模块;

  7、你应该醉心于应用程序的谋杀(诸如让你的机器蓝屏吧^_^)

    *对于任何一个缺陷应该深入调查,而不是轻易放过;

    *确认自己是否确实了解缺陷的影响程度和破坏力;

  8、你应该保持产品发布时刻的圣洁

    *不要抱怨发布日期,当时间不够以前,应提前警告后果;

 9、你应该贪图开发人员的源代码

    *理解错误处理代码,以及哪些输入能触发他们;

  10、不能假设任何东西

    *在我们验证某个缺陷是真之前,不要相信它是真的;

    *测试时,应该什么都不期待,既不期待他应该发生,也不期待他不应该发生;

  个人总结:

  1、重点关注错误处理代码

    *输入过滤器:用于防止错入得输入进入被测试的软件;

    *输入检查:用于保证软件不会使用错误的输入;

    *异常处理;

    *输入类型,输入长度,和边界值;

  2、应该具备的特点:

    *不断超越自己、质量至上、持续教育;

    *不要为逃脱的缺陷而懊恼,把它们当做是一个学习的机会;

  对自己的训练:

  有趣的观点:

  1、软件测试是门学科,不是技艺,也不是艺术,是需要通过训练的;训练的意思是理解学科的每一个细节!

  2、在事先不了解如何正确编制软件的情况下,不存在建立一种软件开发方法,让质量更好的可能!

  3、评估测试人员,不要用软件缺陷的数量、软件缺陷的严重性、测试用例的多少、自动化测试的代码量、回归测试套件的数目以及任何具体的指标来衡量。测试人员是有责任教育破坏质量的人,哪些行为是错误的,以及如何改进

posted @ 2011-11-08 23:02 顺其自然EVO 阅读(219) | 评论 (0)编辑 收藏

互联网产品需求管理思考1——统一需求管理

 对于互联网公司而言,产品需求管理是产品研发的核心环节,产品需求的正确与否直接影响产品开发周期、产品开发成本、产品运营成本,甚至直接决定了产品市场竞争力。根据统计:产品开发中40%~60%的问题都是在需求阶段埋下的“祸根” ,在测试阶段及运营阶段发现需求阶段植入的问题,解决的代价是需求阶段发现问题的68~200倍。

  关于需求管理的故事很多,列举一些常见问题:

  ● 某天老板问起:我很久以前提过一个需求,提过以后就没下文了。产品经理无辜地说:有提过吗,是给我提的吗?

  ● 某个销售谈起:我很久以前提过一个需求,当时被产品否掉了,觉得不重要,现在竞争对手就靠此功能赢得了众多客户。产品经理无辜地说:当时是被否掉了,但你后面再没有提过,因此在后续产品开发中当然没考虑此需求

  ● 某天老板提起:某个产品的某个功能很不错,于是乎大家加班加点地开发实现了类似功能。等到产品开发出来后才开始找客户、找卖点。

  ● 销售们抱怨:产品人员、开发人员闭门造车,只关注技术,不关注客户需求。产品及技术无辜地说:销售人员根本描述不清楚需求,我们已经按照他们需求开发出来了,他们还是不满意。

  ● 销售人员只管销售目标的完成,客户反映的信息不能传递到产品及技术部门。研发部门主动到销售人员那里了解市场信息时,他们往往说:“我只管销售,你先把产品拿出来再说”

  ● 某个客户在社区里投诉:xx产品的xx功能做得太差了,已经投诉过几次都还没有改善;但产品及技术无辜地说:他这功能相对于其他产品功能优先级很低,因此暂时不考虑

  ● 竞争对手某个杀手级产品的功能其实以前公司很久以前就做了,但后来没有持续完善,导致“起了个大早,赶了个晚集”

  ● 某个产品越做越大、越做越乱,直到有一天无法维护时候整理产品功能才发现,里面有一堆乱七八糟的需求,这些需求怎么来的、现在哪一个客户在使用此功能,谁都不知道

  ● 公司层面产品相关利益者都参加的需求收集会议也开了很多次,但大家对于产品需求的理解还是没有统一

  ● 与竞争对手的产品比较,产品功能比竞争对手全面多了,但还是竞争不过竞争对手的产品

  ● 某个产品离职了,大家才发现,对产品最熟悉的人只有这个产品经理,没有任何文档及功能说明,有的只是网站页面和代码

  对于大部分互联网公司而言,都意识到了产品管理的重要性,因此都有相应的产品管理流程,但为何以上问题仍然屡见不鲜呢?

  以上问题的根源在于:

  1)没有对各种需求有效地分层分级,对不同阶段需求的目标没有明确的定义

  2)没有建立一个横跨市场和产品研发部门的组织机构来统一负责收集市场需求,并将其传递给产品研发团队

  3)缺少完备的需求收集、汇总、分析机制,“公司神经末梢与大脑失去联系”

  4)没有建立一套跨部门的端到端的业务流程来指导市场需求收集与传递工作

  5)没有一个客户需求分析工具来指导系统性地收集客户需求

  1、互联网产品需求来源

  一提到需求管理,产品人员及技术人员都会异口同声地说:软件需求管理,我们有啊。我们的软件开发过程遵循CMMI3、RUP、XP、SCRUM等开发过程,需求管理是我们进行开发的最重要阶段。

  我们这里所指的“需求”不单纯只是技术术语的产品需求、软件需求,还包括:

  ● 客户所想所需:Needs、Wants
  ● 市场需求
  ● 产品包需求:Offering Requirement
  ● 产品需求
  ● 开发需求

  相对于传统软件开发过程,互联网企业的需求管理来源更加多样化,包括:

 1)外部来源

  ● 客户需求:客户在使用产品过程中所提的建议和意见;以及通过客户访谈等手段得到的需求
  ● 竞争对手产品分析:直接作为竞争对手产品的客户试用,获得竞争对手产品相关信息
  ● 社会化媒体:搜索引擎、IM、BBS、Blog、SNS社区、Blog、Twitter、百度知道等社会化新媒体
  ● 传统媒体/竞争对手软文等
  ● 合作伙伴
  ● 行业分析

  一些竞争对手分析的手段可以参考 电子商务企业竞争情报分析工具

  2)内部来源

  ● 公司产品战略
  ● 客服人员:包括呼叫中心(电话、短信、传真、邮件等)、在线客户(IM、BBS、留言板、WebCall等)
  ● 运营人员:所谓互联网产品是运营出来的,任何成功产品不可能一蹴而就。公司内部运营人员在运营中产生的需求是重要的需求来源渠道。
  ● 市场营销人员
  ● 销售人员
  ● 财务人员
  ● 技术支持
  ● 网站用户行为分析:包括网站用户购买行为、点击流等

  2、统一需求管理的意义

  由于需求来源的多样化,就要求在公司层面对需求进行统一的管理,以保证能够:

  1)建立端对端的需求管理流程,实现技术与市场的无缝结合。

  2)深入理解行业,成为行业专家:对于互联网企业而言,必须深刻理解所在行业的特征及行业用户的痛点才能够推出有竞争的产品,因此必须首先成为所在行业专家。产品需求本质代表了行业用户的需求,通过产品需求的持续积累,可以加深对于行业理解,从而成为行业专家,能够推出更符合行业需求的产品

  3)知识的传承:通过对需求持续统一的管理可以保证知识的传承,避免产品需求知识积累在几个人脑袋里。

  4)主动收集需求,准确把握市场机会点

  5)产品创新:通过产品及产品间原有需求的优化、借鉴、组合等手段来达到产品创新的目的。

  我们这里的所说的“统一需求管理”比RUP中的更为宽泛,包括:

  ● 公司层面统一的需求管理组织支撑体系
  ● 公司层面统一的需求管理流程制度
  ● 公司层面统一的需求管理工具 3、怎样实现统一需求管理

  在实现公司层面需求统一管理,华为及IBM所采用的IPD过程很有借鉴意义,核心思想在于:

  1)组织支撑

  通过建立一个横跨市场和产品研发部门的组织机构来统一负责收集市场需求,并将其传递给产品研发团队

  2)端对端的流程

  所谓“端到端流程”是区别于职能式的产品开发模式,建立的产品开发流程是跨部门的、关注业务实现的、客户到客户的业务流程。企业中与产品需求相关的主要有三大流程体系:市场管理流程、产品开发流程、需求开发流程。在市场管理流程的第一阶段(了解市场阶段)、在产品开发流程的第一阶段(概念阶段)都会定义客户需求的收集活动,用需求开发流程来支撑需求收集活动。

  4、统一需求管理一些思考

  1)所谓“工欲善其事,必先利其器”,一个好的需求管理工具对于需求管理有很大帮助。但工具不是万能的,关键还是使用工具的人,因此不用整天寻找完美的工具,而是要问一下自己:对于工具的使用热情我们能够坚持多久?

  2)工具本身并不能解决需求管理混乱的困局。核心问题还是需求管理的方法论、流程制度是否能够持续完善。成功需求管理的秘诀之一就是:持续积累、持续完善。

  3)我们很多时候忙于开拓新的市场需求而忘记了总结的价值。与客户、市场、销售、产品、技术、运营等相关人员定期对积累的各种需求(不单纯只是产品需求)进行“requirement review ”(类似于“cod review”),可以碰撞并挖掘出许多有价值的产品需求及卖点。

  4)对于运营型企业而言,各种行业需求的持续积累是企业最为宝贵的财富之一,也是产品创新之源。因此应当把持续的需求积累提升到公司战略层面。

posted @ 2011-11-08 23:01 顺其自然EVO 阅读(237) | 评论 (0)编辑 收藏

仅列出标题
共394页: First 上一页 369 370 371 372 373 374 375 376 377 下一页 Last 
<2024年11月>
272829303112
3456789
10111213141516
17181920212223
24252627282930
1234567

导航

统计

常用链接

留言簿(55)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜