测试之道、

发布新日志

  • 测试人员应具备的七种思维方式

    2008-12-24 23:50:23

      作为软件测试人员,应具备以下七种思维方式:逆向思维方式,组合思维方式,全局思维方式,两极思维方式,简单思维方式,比较思维方式,动起来,更精彩!

      1、逆向思维方式

      ☆逆向思维在测试中用的很多,比如将根据结果逆推条件,从而得出输入条件的等价类划分

      ☆其实逆向思维在调试当中用到的也比较多,当发现缺陷时,进一步定位问题的所在,往往就是逆流而上,进行分析

      ☆逆向思维是相对的,就是按照与常规思路相反的方向进行思考,测试人员往往能够运用它发现开发人员思维的漏洞

      2、组合思维方式

      ☆很多东西单一的思考都没有问题,当将相关的事物组合在一起却能发现很多问题;如多进程并发,让程序的复杂度上了一个台阶,也让程序的缺陷率随之而增长

      ☆按照是否排序组合可以分为:排列(有序)和组合(无序);针对不同的应用,可以酌情考虑使用“排列”或者“组合”

      ☆为了充分利用组合思维而不致于让自己的思维混乱,要注意“分维”,将相关的因素划分到不同的维度上,然后再考虑其相关性

      3、全局思维方式

      ☆事物往往存在多面性,当我们掌握了越多的层面,我们对它的认识就越清楚,越有利于我们掌握其本质,全局思维方式就是让我们从多角度分析待测的系统;试着以不同角色去看系统,分析其是否能够满足需求

      ☆其实平常我们在软件开发过程中,进行的各种评审,就是借助全局思维的方式,让更多的人参与思考,脑力激荡,尽可能的实现全方位审查某个解决方案的正确性以及其他特性

      4、两极思维方式

      ☆边界值分析是两极思维方式的典范

      ☆为了看系统的稳定性,我们采用了压力测试

      ☆两极思维方式,是在极端的情况下,看是否存在缺陷?

      ☆注意是两极,不是一极

      ☆测试人员做久了,往往容易走极端——职业病,不利于与人沟通

      5、简单思维方式

      ☆剥离一些非关键特征,追逐事物的本质,让事物简单的只剩下“根本”

      ☆针对事物本质(解决问题的本质)的测试,让我们不至于偏离方向

      6、比较思维方式

      ☆认识事物时,人们往往都是通过和头脑中的某些概念进行比较,找出相同、相异之处,或者归类,从而将其加入大脑中的知识体系,可能的话,再建立好的搜索方式,以便以后使用

      ☆应用模式是“比较思维”很常见的例子,现在模式很火,有设计模式、体系结构模式、测试模式、等等,一些专家针对一些相关问题的共性找出来的解决方法,取完名字后,可以让大家方便的复用

      ☆让经验在这里发挥作用,测试中经验很重要,比较思维是使用经验的方式

      7、动起来,更精彩

      ☆关注程序的运行时状态

      ☆传统的基于结构的程序可以更多的在代码中反映将来程序的运行方式;而面向对象将代码和运行时显著分离

      ☆让我们在关注代码静态结构(如类结构)的同时,也要谨慎关注其动态(对象交互网)表现

      其实这些思维方式,大家都在有意识或者无意识的使用着,它们各自都有自己的妙处,将我们的思维发散,有意识的将他们用在问题的思考上,有时可以给我们一种“柳暗花明又一村”的感觉。

      最后想说,只是知道这些原则意义不是很大,如果真能让它们成为思考的血液,才能发挥它的真正价值。那真的需要很多的历练,其实成为一名出色的测试人员,远没有那么简单,需要简单,需要(不断的学习+不断的经历+不断的思考)。

  • Web 测试的经验

    2008-09-21 13:29:02

    1. 功能测试
    1.1.链接测试
       链接是 Web 应用系统的一个主要特征,它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先,测试所有链接是否按指示的那样确实链接到了该链接的页面;其次,测试所链接的页面是否存在;最后,保证 Web 应用系统上没有孤立的页面,所谓孤立页面是指没有链接指向该页面,只有知道正确的 URL 地址才能访问。
       链接测试可以自动进行,现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成,也就是说,在整个 Web 应用系统的所有页面开发完成之后进行链接测试。
    1.2. 表单测试
       当用户给 Web 应用系统管理员提交信息时,就需要使用表单操作,例如用户注册、登陆、信息提交等。在这种情况下,我们必须测试提交操作的完整性,以校验提交给服务器的信息的正确性。例如:用户填写的出生日期与职业是否恰当,填写的所属省份与所在城市是否匹配等。如果使用了默认值,还要检验默认值的正确性。如果表单只能接受指定的某些值,则也要进行测试。例如:只能接受某些字符,测试时可以跳过这些字符,看系统是否会报错。
    1.3.Cookies测试
    Cookies 通常用来存储用户信息和用户在某应用系统的操作,当一个用户使用 Cookies 访问了某一个应用系统时, Web 服务器将发送关于用户的信息,把该信息以 Cookies 的形式存储在客户端计算机上,这可用来创建动态和自定义页面或者存储登陆等信息。
       如果 Web 应用系统使用了 Cookies ,就必须检查 Cookies 是否能正常工作。测试的内容可包括 Cookies 是否起作用,是否按预定的时间进行保存,刷新对 Cookies 有什么影响等。
    1.4.设计语言测试
    Web 设计语言版本的差异可以引起客户端或服务器端严重的问题,例如使用哪种版本的 HTML 等。当在分布式环境中开发时,开发人员都不在一起,这个问题就显得尤为重要。除了 HTML 的版本问题外,不同的脚本语言,例如 Java 、 Javascrīpt 、 ActiveX 、 VBscrīpt 或 Perl 等也要进行验证。
    1.5.数据库测试
       在 Web 应用技术中,数据库起着重要的作用,数据库为 Web 应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在 Web 应用中,最常用的数据库类型是关系型数据库,可以使用 SQL 对信息进行处理。

    在使用了数据库的 Web 应用系统中,一般情况下,可能发生两种错误,分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的,而输出错误主要是由于网络速度或程序设计问题等引起的,针对这两种情况,可分别进行测试。
    2. 性能测试
    2.1.连接速度测试
       用户连接到 Web 应用系统的速度根据上网方式的变化而变化,他们或许是电话拨号,或是宽带上网。当下载一个程序时,用户可以等较长的时间,但如果仅仅访问一个页面就不会这样。如果 Web 系统响应时间太长(例如超过 5 秒钟),用户就会因没有耐心等待而离开。
       另外,有些页面有超时的限制,如果响应速度太慢,用户可能还没来得及浏览内容,就需要重新登陆了。而且,连接速度太慢,还可能引起数据丢失,使用户得不到真实的页面。
    2.2.负载测试
       负载测试是为了测量 Web 系统在某一负载级别上的性能,以保证 Web 系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问 Web 系统的用户数量,也可以是在线数据处理的数量。例如: Web 应用系统能允许多少个用户同时在线?如果超过了这个数量,会出现什么现象? Web 应用系统能否处理大量用户对同一个页面的请求?
    2.3.压力测试
      负载测试应该安排在 Web 系统发布以后,在实际的网络环境中进行测试。因为一个企业内部员工,特别是项目组人员总是有限的,而一个 Web 系统能同时处理的请求数量将远远超出这个限度,所以,只有放在 Internet 上,接受负载测试,其结果才是正确可信的。
       进行压力测试是指实际破坏一个 Web 应用系统,测试系统的反映。压力测试是测试系统的限制和故障恢复能力,也就是测试 Web 应用系统会不会崩溃,在什么情况下会崩溃。黑客常常提供错误的数据负载,直到 Web 应用系统崩溃,接着当系统重新启动时获得存取权。
       压力测试的区域包括表单、登陆和其他信息传输页面等。
    3. 可用性测试
    3.1.导航测试
       导航描述了用户在一个页面内操作的方式,在不同的用户接口控制之间,例如按钮、对话框、列表和窗口等;或在不同的连接页面之间。通过考虑下列问题,可以决定一个 Web 应用系统是否易于导航:导航是否直观? Web 系统的主要部分是否可通过主页存取? Web 系统是否需要站点地图、搜索引擎或其他的导航帮助?
       在一个页面上放太多的信息往往起到与预期相反的效果。 Web 应用系统的用户趋向于目的驱动,很快地扫描一个 Web 应用系统,看是否有满足自己需要的信息,如果没有,就会很快地离开。很少有用户愿意花时间去熟悉 Web 应用系统的结构,因此, Web 应用系统导航帮助要尽可能地准确。
       导航的另一个重要方面是 Web 应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道 Web 应用系统里面是否还有内容,内容在什么地方。
    Web 应用系统的层次一旦决定,就要着手测试用户导航功能,让最终用户参与这种测试,效果将更加明显。
    3.2.图形测试
       在 Web 应用系统中,适当的图片和动画既能起到广告宣传的作用,又能起到美化页面的功能。一个 Web 应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有:
       ( 1 )要确保图形有明确的用途,图片或动画不要胡乱地堆在一起,以免浪费传输时间。 Web 应用系统的图片尺寸要尽量地小,并且要能清楚地说明某件事情,一般都链接到某个具体的页面。
       ( 2 )验证所有页面字体的风格是否一致。
       ( 3 )背景颜色应该与字体颜色和前景颜色相搭配。
       ( 4 )图片的大小和质量也是一个很重要的因素,一般采用 JPG 或 GIF 压缩。
    3.3.内容测试
       内容测试用来检验 Web 应用系统提供信息的正确性、准确性和相关性。
       信息的正确性是指信息是可靠的还是误传的。例如,在商品价格列表中,错误的价格可能引起财政问题甚至导致法律纠纷;信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行,例如使用 Microsoft Word 的 " 拼音与语法检查 " 功能;信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口,也就是一般 Web 站点中的所谓 " 相关文章列表 " 。
    3.4.整体界面测试
       整体界面是指整个 Web 应用系统的页面结构设计,是给用户的一个整体感。例如:当用户浏览 Web 应用系统时是否感到舒适,是否凭直觉就知道要找的信息在什么地方?整个 Web 应用系统的设计风格是否一致?
    对整体界面的测试过程,其实是一个对最终用户进行调查的过程。一般 Web 应用系统采取在主页上做一个调查问卷的形式,来得到最终用户的反馈信息。
       对所有的可用性测试来说,都需要有外部人员(与 Web 应用系统开发没有联系或联系很少的人员)的参与,最好是最终用户的参与。
    4. 客户端兼容性测试
    4.1.平台测试
       市场上有很多不同的操作系统类型,最常见的有 Windows 、 Unix 、 Macintosh 、 Linux 等。 Web 应用系统的最终用户究竟使用哪一种操作系统,取决于用户系统的配置。这样,就可能会发生兼容性问题,同一个应用可能在某些操作系统下能正常运行,但在另外的操作系统下可能会运行失败。
       因此,在 Web 系统发布之前,需要在各种操作系统下对 Web 系统进行兼容性测试。
    4.2.浏览器测试
       浏览器是 Web 客户端最核心的构件,来自不同厂商的浏览器对 Java ,、 Javascrīpt 、 ActiveX 、 plug-ins 或不同的 HTML 规格有不同的支持。例如, ActiveX 是 Microsoft 的产品,是为 Internet Explorer 而设计的, Javascrīpt 是 Netscape 的产品, Java 是 Sun 的产品等等。另外,框架和层次结构风格在不同的浏览器中也有不同的显示,甚至根本不显示。不同的浏览器对安全性和 Java 的设置也不一样。
       测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中,测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。
    5. 安全性测试
    Web 应用系统的安全性测试区域主要有:
       ( 1 )现在的 Web 应用系统基本采用先注册,后登陆的方式。因此,必须测试有效和无效的用户名和密码,要注意到是否大小写敏感,可以试多少次的限制,是否可以不登陆而直接浏览某个页面等。
       ( 2 ) Web 应用系统是否有超时的限制,也就是说,用户登陆后在一定时间内(例如 15 分钟)没有点击任何页面,是否需要重新登陆才能正常使用。
       ( 3 )为了保证 Web 应用系统的安全性,日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。
       ( 4 )当使用了安全套接字时,还要测试加密是否正确,检查信息的完整性。
       ( 5 )服务器端的脚本常常构成安全漏洞,这些漏洞又常常被黑客利用。所以,还要测试没有经过授权,就不能在服务器端放置和编辑脚本的问题。
    6. 总结
       本文从功能、性能、可用性、客户端兼容性、安全性等方面讨论了基于 Web 的系统测试方法。
    基于 Web 的系统测试与传统的软件测试既有相同之处,也有不同的地方,对软件测试提出了新的挑战。基于 Web 的系统测试不但需要检查和验证是否按照设计的要求运行,而且还要评价系统在不同用户的浏览器端的显示是否合适。重要的是,还要从最终用户的角度进行安全性和可用性测试。

Open Toolbar