没有最好,只有更好!!!!!!

发布新日志

  • 测试的核心技术是啥?

    架构师Jack 发布于 2010-07-25 15:21:53

      测试这行的客观规律总的来说是:入门容易,提升难。 有些人干测试8-9年了,其针对同一个产品的测试思路和方法,与干测试只有2-3年的人看不出有什么区别。于是行业中有了一种误区,认为测试技术的提升主要集中在对性能测试工具的使用及脚本开发,自动化测试开发,测试工具开发领域。仅个人愚见:测试工具开发和自动化测试开发 主要还是开发技术而不是测试技术,从没有做过测试分析,测试设计的开发人员也能胜任。如果仅狭义地认为测试技术的发展只在自动化测试框架开发或测试工具开发上,那么从逻辑上来说,任何一个开发人员都可以成为测试技术大拿。当然我想:没有人会真正这么认为。
      就其我的感受而言,开发工作有时反而会简单一些。为什么呢?开发工作的目标从一开始是非常明确的,要实现什么要做什么做到什么程度大多数情况下都是清晰的,最大的困难则是如何实现如何做到,总的来说是一个不断聚焦的过程。而测试工作的目标呢?其实很多时候,并不如开发那么明确,例如:同样一个性能指标,开发很清楚要通过实现XX算法来达到目标;而测试则需要对该性能指标先进行测试分析,再进行测试设计,可是测试分析做到什么程度却是一个发散的过程, 2小时也可以,2天也不够,这就导致了测试质量的浮动范围是非常大的,由于开发和项目经理通常对测试设计并不了解,也无法了解(测试其实是一个专业度非常高的领域),因此会导致测试部的工作质量很难在过程中真正去度量和监督。
       从哲学上来说:确定性的规律往往难度不大;不确定性的规律往往说明它是一个复杂系统。因此,我个人认为:测试技术领域最难的技术应该是测试分析和设计。从另一个角度来看,测试价值的体现最主要还是保障自己组织开发的软件在关键应用时不要出故障,给组织造成商业损失。所以,有效的测试覆盖率是最重要的测试工作目标(而不是自动化测试率),需要说明的是测试覆盖率不等于代码覆盖率。通过单元测试达到代码覆盖率100%了就能保障产品无bug其实是一个误区,因为很多组织会为了达到单元覆盖率而去开发单元测试代码,单元测试代码或单元测试设计的质量只能保障消除产品编码的问题,发现产品设计的问题则往往会很困难。而发现产品设计问题的最主要方法还得需要基于黑盒的测试分析和设计。
      如何做好测试分析和测试设计,根据我的经验和体会,建议测试分析和测试设计主要通过3个维度来做,则可以大致达到一个比较高的有效测试覆盖率:
      维度一:从用户实际使用的场景和习惯入手,开发一批测试用例;
      优点:  可以覆盖到主要基本场景;
      不足:  从事场景分析的人无法做到了解用户所有的场景,必定受参与测试分析资源限制会有场景遗漏;
      维度二:通过测试对象内部实现流程的路径及依赖关系分析入手,开发一批测试用例;
      优点:可填补维度一的部分遗漏场景,特别是异常处理和分支交互处理的场景;
      不足:分析阶段主要精力会被局限在内部流程的熟悉和分析中,从而也会遗漏真实环境中的一些偶然小概率事件;
      维度三:依赖基于经验的测试分析和设计,例如:错误猜测法或探索性测试法;
      优点: 给维度二再做一次补充测试分析和设计;
      不足: 维度三效果的质量高低取决于组织内部经验的积累量及测试人员思维的发散能力和创造性;
    总得来说:无论是功能测试还是各种专项测试,依次使用以上3个维度的测试分析和设计,基本上能覆盖到被测对象的绝大部分应用场景,充分保障产品质量,减少问题遗漏。
        因此:测试的核心技术是测试分析和测试设计的能力,它决定了后续所有测试活动的质量及效果。同时,要做好一个测试任务,掌握广泛的测试类型也是必要的核心技术,如:如何给每个测试对象做细做深压力测试,长时间测试,健壮性测试也是决定项目测试质量的关键所在。我本人不相信随便做做的压力测试设计和健壮性测试设计能够保障产品实际应用表现良好。
       测试活动的质量或者一个测试工程师技术水平如何将主要取决于:测试分析和设计的深度及系统化,以及掌握广泛的专项测试类型。
      一家之言,仅供参考,欢迎大家继续讨论。

  • 用户名密码的测试方法(别小看哦)

    movestar 发布于 2010-08-20 10:27:18

    别小看了这个用户名密码这么简单的输入框。可测试的内容还是很多的,并且引发的问题也有很多种类。下面就说一说他的测试方法。

    一、用户注册

    只从用户名和密码角度写了几个要考虑的测试点,如果需求中明确规定了安全问题,Email,出生日期,地址,性别等等一系列的格式和字符要求,那就都要写用例测了~

    以等价类划分和边界值法来分析

    1.填写符合要求的数据注册: 用户名字和密码都为最大长度(边界值分析,取上点)

    2.填写符合要求的数据注册 :用户名字和密码都为最小长度(边界值分析,取上点)

    3.填写符合要求的数据注册:用户名字和密码都是非最大和最小长度的数据(边界值分析,取内点)

    4.必填项分别为空注册

    5.用户名长度大于要求注册1位(边界值分析,取离点)

    6.用户名长度小于要求注册1位(边界值分析,取离点)

    7.密码长度大于要求注册1位(边界值分析,取离点)

    8.密码长度小于要求注册1位(边界值分析,取离点)

    9.用户名是不符合要求的字符注册(这个可以划分几个无效的等价类,一般写一两个就行了,如含有空格,#等,看需求是否允许吧~)

    10.密码是不符合要求的字符注册(这个可以划分几个无效的等价类,一般写一两个就行了)

    11.两次输入密码不一致(如果注册时候要输入两次密码,那么这个是必须的)

    12.重新注册存在的用户

    13.改变存在的用户的用户名和密码的大小写,来注册。(有的需求是区分大小写,有的不区分)

    14.看是否支持tap和enter键等;密码是否可以复制粘贴;密码是否以* 之类的加秘符号显示

    备注:边界值的上点、内点和离点大家应该都知道吧,呵呵,这里我就不细说了~~

    二、修改密码

    当然具体情况具体分析哈~不能一概而论~

    实际测试中可能只用到其中几条而已,比如银行卡密码的修改,就不用考虑英文和非法字符,更不用考虑那些TAP之类的快捷键。而有的需要根据需求具体分析了,比如连续出错多少次出现的提示,和一些软件修改密码要求一定时间内有一定的修改次数限制等等。

    1.不输入旧密码,直接改密码

    2.输入错误旧密码

    3.不输入确认新密码

    4.不输入新密码

    5.新密码和确认新密码不一致

    6.新密码中有空格

    7.新密码为空

    8.新密码为符合要求的最多字符

    9.新密码为符合要求的最少字符

    10.新密码为符合要求的非最多和最少字符

    11.新密码为最多字符-1

    12.新密码为最少字符+1

    13.新密码为最多字符+1

    14.新密码为最少字符-1

    15.新密码为非允许字符(如有的密码要求必须是英文和数字组成,那么要试汉字和符号等)

    16.看是否支持tap和enter键等;密码是否可以复制粘贴;密码是否以* 之类的加秘符号

    17.看密码是否区分大小写,新密码中英文小写,确认密码中英文大写

    18.新密码与旧密码一样能否修改成功

    另外一些其他的想法如下:

    1 要测试所有规约中约定可以输入的特殊字符,字母,和数字,要求都可以正常输入、显示正常和添加成功

    2 关注规约中的各种限制,比如长度,大否支持大小写。

    3 考虑各种特殊情况,比如添加同名用户,系统是否正确校验给出提示信息,管理员帐户是否可以删除,因为有些系统管理员拥有最大权限,一旦删除管理员帐户,就不能在前台添加,这给最终用户会带来很多麻烦。比较特殊的是,当用户名中包括了特殊字符,那么对这类用户名的添加同名,修改,删除,系统是否能够正确实现,我就遇到了一个系统,添加同名用户时,如果以前的用户名没有特殊字符,系统可以给出提示信息,如果以前的用户名包含特殊字符,就不校验在插入数据库的时候报错。后来查到原因了,原来是在java中拼SQL语句的时候,因为有"_",所以就调用了一个方法在“_”,前面加了一个转义字符,后来发现不该调用这个方法。所以去掉就好了。所以对待输入框中的特殊字符要多关注。


    4 数值上的长度 之类的,包括出错信息是否合理
    5 特殊字符:比如。 / ' " \ </html> 这些是否会造成系统崩溃

    6 注入式bug:比如密码输入个or 1=1

    7 登录后是否会用明文传递参数

    8 访问控制(不知道这个算不算):登录后保存里面的链接,关了浏览器直接复制链接看能不能访问。

  • 用VC写一个TCL的解释器(图)

    songfun 发布于 2007-05-29 23:53:26

    今天上完了19期的集成测试自动化TCL(Tool Command Language)课,给他们介绍了TCL的扩展机制以及用VC搭建一个TCL集成测试环境。后来有同学问我是否可以用VC写一个Tclsh那样的解释器,我想了想,难的都教了(扩展指令都会了),简单的还不会么,于是打开VC,歘歘歘……

    自从给大家讲了Console版的tcl集成环境搭建指南后,我发现开始喜欢写“傻瓜式教程”了——呵呵,希望能够给更多的初学者带来有效的帮助。

    以下就直奔主题,带大家用VC写一个最简单的Tcl解释器。

    首先,打开VC(注:本人用的是VC 6.0英文版),点菜单File-->New,出现如下这张图,选择Projects-->Win32 Console Application,在Project Name那里填入MyTcl,然后点OK按钮。

    在接下来的向导窗口中选择“A Simple Application”,点Finish按钮。

    再接下来弹出一个New Project Information,点OK按钮。

    接着,双击VC项目工程的FileView(文件视图)里的MyTcl.cpp文件,输入代码如下:
    [CODE]

    // MyTcl.cpp : Defines the entry point for the console application.
    // code by 51Testing.songfun

    #include "stdafx.h"
    #include <tcl.h>

    int Tcl_AppInit(Tcl_Interp *interp)

     if (Tcl_Init(interp) == TCL_ERROR)
     {
      return TCL_ERROR;
     }
     return TCL_OK;
    }

    int main(int argc, char *argv[])
    {
     Tcl_Main(argc, argv, Tcl_AppInit);
     return 0;
    }

    [/CODE]

    然后,点VC的菜单Project-->Add to Project-->Files,把tcl.h和tcl83.lib分别加进来。如图。
    再在VC的菜单Tools-->Options的Directories里设置tcl83包的头文件路径和库文件路径。如图。

    最后,点VC的“感叹号”Execute(执行按钮),看到什么了?
    呵呵,是不是这个窗口和大家之前看到的那个tclsh应用程序很像啊?
    它就是我们自己写的tcl解释器,怎么样,很有成就感吧,嘻嘻,其实代码也没有多复杂对吧。

    实际上,这个地方只是演示一个例子,我们放着tclsh和scrīpt.Net这样的tcl解释工具不用,却自己用VC写一个tcl解释器的目的是什么?正是为了使用它的扩展机制来扩展我们自己定义的命令。所以上述的例子本身的意义还不是很大,必须结合有效的扩展函数的实现才会显得更有意义(这也是我上课给大家讲的内容)。

    OK,本篇文章到此结束,大家有任何疑问可以随时和我交流,请各位不吝赐教啊,呵呵……

  • 爱一个人

    zz3536 发布于 2006-12-15 16:45:51

    今天在水区看到篇帖子,是关于一个女生在“爱情”与事业之间犹豫的。看后我不尽哑然,这样的感情能称得上爱情么?

    原本打算如下文回复楼主的,念及楼主并不是爱着对方,所以和我思考的方向不一样,我也就不该去引导她做出我希望看到的选择了。

    人们追求爱情最后要的并不是爱情本身,而是与爱人一起生活。一个人也许能和很多人发生爱情,但每个人带给你的感受和生活都是不一样的,你所需要选择的是一个适合你的人及他和你在一起的生活方式(这两者是同时产生的)。所以当你面临抉择的时候,你选择的不是爱情,而是人!因为这个人你才能有这份爱情,而失去了他,你将来照样会有其他的爱情。如果你深爱着对方,你怎么能狠下心来因为自己的原因而离开他,通常分开的原因都是一再的包容对方直到自己实在受不了才放手,爱的伟大之处正是能心甘情愿为你所爱的人“牺牲”自己。

    爱一个人
    很多事情从一开始就知道结果
    很多问题从一产生就知道答案

    轰轰烈烈
    无怨无悔

    平平淡淡
    相守相随

    That's what I want.

Open Toolbar