发布新日志

  • 常见软件测试面试题<zhuan>

    2012-07-09 16:12:45

    问题一:为什么要在一个团队中开展软件测试工作
    任何软件在开发过程中都会留下缺陷,带有缺陷的软件产品如果提交出去,可能会给公司带来不可估量的损失,我们必须在客户之前发现尽可能多的问题,从而保障客户满意。而发现问题的这个过程称之为测试。

    问题二:简述你在以前的工作中做过哪些事情,比较熟悉什么。
          此问题每个人都不一样。我自己的答案如下。
    我主要的工作是系统测试自动化测试,也曾少量涉及性能测试。在系统测试中,主要是对BOSS系统的业务逻辑功能,以及软交换系统的Class 5特性进行测试。性能测试中,主要是进行的压力测试,在各个不同数量请求的情况下,获取系统响应时间以及系统资源消耗情况。自动化测试主要是通过自己写脚本以及一些第三方工具的结合来测试软交换的特性测试。

    问题三:你所了解的的软件测试类型都有哪些,简单介绍一下。
    1.
    基本功能验证。主要是对发布的版本进行一些最主要功能的测试。英文常见叫法是Smoking Test, Basic Verification Test或者Sanity Check
    2.
    功能测试。主要是依据需求或者需求分析文档,对所发布的版本进行测试,看看是否满足需求,是否出现了不必要的功能。
    3.
    单元测试。是开发人员进行的测试之一,一般是开发人员对很小的模块,比如函数进行测试,一般来说,开发人员还需要开发相应的测试桩来进行此类测试。
    4.
    集成测试。在大型的开发过程中,软件是模块化进行开发的,将不同的模块揉合在一起的话,需要进行的测试就是集成测试。
    5.
    系统测试。当软件提交给测试组后,是对整个系统的所有功能进行测试,一般来说,功能测试是系统测试的一个部分。
    6.
    压力测试。主要是在很大性能的情况下,这个性能已经接近了系统的极限,看看系统运转的情况。
    7.
    负载测试。主要是用各种不同的性能去检测系统,采集各个数据在这些性能情况下的数据。
    8.
    黑盒测试。指系统对你来说是完全不透明的,只给你留下了输入和最终输出,这个是功能测试的方法之一。
    9.
    灰盒测试。指在了解部分系统内部工作机制的情况下,对于系统进行的覆盖性测试。
    10.
    白盒测试。主要是在单元测试和集成测试的情况下,开发人员已知代码,对这一段的代码进行全路径的覆盖测试。
    11.
    界面测试。主要是看用户界面的友好性和易用性,是否有文字或者排版错误,是否有输入限制等等。
    12.
    回归测试。一般是系统发现BUG,开发人员修改后,和BUG直接相关以及可能相关的功能进行的测试。
    13.
    安装和卸载的测试。
    14.
    恢复测试。主要是一个系统在发生了灾难的情况下,从错误中是否容易恢复。
    15.
    兼容性测试。一个系统在不同的语言,操作系统下的系统测试。
    16.
    安全测试。系统在遇到攻击或者类似情况下的表现。
    17.
    Alpha
    测试。系统在给最终用户前,测试人员在实验室中模拟最终用户的测试。
    18.
    Beta
    测试。由部分最终用户通过使用来进行的测试。
    19.
    比较测试。和其他具有相同或者类似功能的系统进行对比的测试。
    20.
    验收测试。一般是最终用户在接受产品前,依据自己所提出的要求进行的测试,很多情况下,验收测试可能委托第三方机构完成。

    问题四:测试计划工作的目的是什么?测试计划文档的内容应该包括什么?其中哪些是最重要的?
    软件测试计划是指导测试过程的纲领性文件。
    包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划,参与测试的项目成员,尤其是测试管理人员,可以明确测试任务和测试方法,保持测试实施过程的顺畅沟通,跟踪和控制测试进度,应对测试过程中的各种变更。
    测试计划和测试详细规格、测试用例之间是战略和战术的关系,测试计划主要从宏观上规划测试活动的范围、方法和资源配置,而测试详细规格、测试用例是完成测试任务的具体战术。所以其中最重要的是测试测试策略和测试方法(最好是能先评审)。

    问题五:你认为做好测试计划工作的关键是什么?
    1.
    明确测试的目标,增强测试计划的实用性
    编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷,因此软件测试计划的价值取决于它对帮助管理测试项目,并且找出软件潜在的缺陷。因此,软件测试计划中的测试范围必须高度覆盖功能需求,测试方法必须切实可行,测试工具并且具有较高的实用性,便于使用,生成的测试结果直观、准确
    2.
    坚持“5W”规则,明确内容与过程
    5W”规则指的是“What(做什么)”、“Why(为什么做)”、“When(何时做)”、“Where(在哪里)”、“How(如何做)”。利用“5W”规则创建软件测试计划,可以帮助测试团队理解测试的目的(Why),明确测试的范围和内容(What),确定测试的开始和结束日期(When),指出测试的方法和工具(How),给出测试文档和软件的存放位置(Where)。
    3.
    采用评审和更新机制,保证测试计划满足实际需求
    测试计划写作完成后,如果没有经过评审,直接发送给测试团队,测试计划内容的可能不准确或遗漏测试内容,或者软件需求变更引起测试范围的增减,而测试计划的内容没有及时更新,误导测试执行人员。
    4.
    分别创建测试计划与测试详细规格、测试用例
    应把详细的测试技术指标包含到独立创建的测试详细规格文档,把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系,测试计划主要从宏观上规划测试活动的范围、方法和资源配置,而测试详细规格、测试用例是完成测试任务的具体战术。

    问题六:常见的测试用例设计方法都有哪些?请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。

    1.         等价类划分

    划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.

    2.         边界值分析法

      边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.

      使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.

    3.         错误推测法

      基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.

      错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.

    4.         因果图方法

    前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图(逻辑模型). 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.

    5.         正交表分析法

    有时候,可能因为大量的参数的组合而引起测试用例数量上的激增,同时,这些测试用例并没有明显的优先级上的差距,而测试人员又无法完成这么多数量的测试,就可以通过正交表来进行缩减一些用例,从而达到尽量少的用例覆盖尽量大的范围的可能性。

    6.         场景分析方法

    指根据用户场景来模拟用户的操作步骤,这个比较类似因果图,但是可能执行的深度和可行性更好。


    问题七:您认为做好测试用例设计工作的关键是什么?

    白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果

    黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试,以最少的用例在合理的时间内发现最多的问题


    问题八:详细的描述一个测试活动完整的过程。

    1.         项目经理通过和客户的交流,完成需求文档,由开发人员和测试人员共同完成需求文档的评审,评审的内容包括:需求描述不清楚的地方和可能有明显冲突或者无法实现的功能的地方。项目经理通过综合开发人员,测试人员以及客户的意见,完成项目计划。然后SQA进入项目,开始进行统计和跟踪

    2.         开发人员根据需求文档完成需求分析文档,测试人员进行评审,评审的主要内容包括是否有遗漏或者双方理解不同的地方。测试人员完成测试计划文档,测试计划包括的内容上面有描述。

    3.         测试人员根据修改好的需求分析文档开始写测试用例,同时开发人员完成概要设计文档,详细设计文档。此两份文档成为测试人员撰写测试用例的补充材料。

    4.         测试用例完成后,测试和开发需要进行评审。

    5.         测试人员搭建环境

    6.         开发人员提交第一个版本,可能存在未完成功能,需要说明。测试人员进行测试,发现BUG后提交给BugZilla。

    7.         开发提交第二个版本,包括Bug Fix以及增加了部分功能,测试人员进行测试。

    8.         重复上面的工作,一般是3-4个版本后BUG数量减少,达到出货的要求。

    9.         如果有客户反馈的问题,需要测试人员协助重现以及回归测试。


    问题九:以往是否曾经从事过性能测试工作?请尽可能的详细描述您以往的性能测试工作的完整过程。

           曾经做过一套网管系统的性能测试,主要测试该软件在同时管理大量终端的情况下,在响应时间,CPU/磁盘/内存等参数是否满足要求。

           也曾经做过软交换系统的呼叫性能测试,主要是测试软交换系统在有大量呼叫的情况下,响应时间,呼叫成功率,CPU/磁盘/内存等参数是否满足设计要求。


    问题十:您在从事性能测试工作时,是否使用过一些测试工具?如果有,请试述该工具的工作原理,并以一个具体的工作中的例子描述该工具是如何在实际工作中应用的。

           测试网管系统中,使用的Mimic来模拟终端,能够大量的节省成本。

           测试软交换系统的时候,使用的Prolab来模拟终端并发送呼叫软交换,他完成了同时数百人才能完成的摘机拨号工作,主要工作原理是产生一些符合要求的IP包并发送给软交换系统,同时对软交换系统的回应进行处理,决定下一步动作。


    问题十一:您认为性能测试工作的目的是什么?做好性能测试工作的关键是什么?

    主要是保障在大量用户的情况下,服务能正常使用。


    问题十二:在您以往的工作中,一条软件缺陷(或者叫Bug)记录都包含了哪些内容?如何提交高质量的软件缺陷(Bug)记录?

    1.         在传统的BugZilla中,BUG描述应该包括以下的信息

    2.         和BUG产生对应的软件版本

    3.         开发的接口人员

    4.         BUG的优先级

    5.         BUG的严重程度

    6.         BUG可能属于的模块,如果不能确认,可以用开发人员来判断

    7.         BUG标题,需要清晰的描述现象

    8.         BUG描述,需要尽量给出重新Bug的步骤

    9.         BUG附件中能给出相关的日志和截图。

           高质量的BUG记录就是指很容易理解的BUG记录,所以,对于描述的要求高,能提供的信息多且准确,很好的帮助开发人员定位。

    问题十二:BUG管理工具的跟踪过程

           用BugZilla为例子      

    测试人员发现了BUG,提交到Bugzilla中,状态为new,BUG的接受者为开发接口人员

    开发接口将BUG分配给相关的模块的开发人员,状态修改为已分配

    开发人员和测试确认BUG,如果是本人的BUG,则设置为接收;如果是别的开发人员的问题,则转发出去,由下一个开发人员来进行此行为;如果认为不是问题,则需要大家讨论并确认后,拒绝这个BUG,然后测试人员关闭此问题。

    如果开发人员接受了BUG,并修改好以后,将BUG状态修改为已修复,并告知测试在哪个版本中可以测试。

    测试人员在新版本中测试,如果发现问题依然存在,则拒绝修改;如果已经修复,则关闭BUG。


    问题十二:您认为在测试人员同开发人员的沟通过程中,如何提高沟通的效率和改善沟通的效果?维持测试人员同开发团队中其他成员良好的人际关系的关键是什么?

           尽量能有面对面的沟通,如果做不到,那么尽量能直接通过电话沟通,如果只能通过Email等非及时沟通工具的话,强调必须对特性的理解深刻以及能表达清楚。

           一是真诚,二是团队精神,三是在专业上有共同语言,当然也可以通过直接指出一些小问题,而不是进入BUG Tracking System来增加对方的好感。


    问题十三:在您以往的测试工作中,最让您感到不满意或者不堪回首的事情是什么?您是如何来对待这些事情的?

           某次性能测试覆盖不足,造成系统崩溃。


    问题十四:你对测试最大的兴趣在哪里?为什么?

    最大的兴趣就是测试有难度,有挑战性!做测试越久越能感觉到做好测试有多难。曾经在无忧测试网上看到一篇文章,是关于如何做好一名测试工程师。一共罗列了11,12点,有部分是和人的性格有关,有部分需要后天的努力。但除了性格有关的1,2点我没有把握,其他点我都很有信心做好它。

    刚开始进入测试行业时,对测试的认识是从无忧测试网上了解到的一些资料,当时是冲着做测试需要很多技能才能做的好,虽然入门容易,但做好很难,比开发更难,虽然当时我很想做开发(学校专业课我基本上不缺席,因为我喜欢我的专业),但看到测试比开发更难更有挑战性,想做好测试的意志就更坚定了。

    我觉得做测试整个过程中有2点让我觉得很有难度(对我来说,有难度的东西我就非常感兴趣),第一是测试用例的设计,因为测试的精华就在测试用例的设计上了,要在版本出来之前,把用例写好,用什么测试方法写?(也就是测试计划或测试策略),如果你刚测试一个新任务时,你得花一定的时间去消化业务需求和技术基础,业务需求很好理解(多和产品经理和开发人员沟通就能达到目的),而技术基础可就没那么简单了,这需要你自觉的学习能力,比如说网站吧,最基本的技术知识你要知道网站内部是怎么运作的的,后台是怎么响应用户请求的?测试环境如何搭建?这些都需要最早的学好。至少在开始测试之前能做好基本的准备,可能会遇到什么难题?需求细节是不是没有确定好?这些问题都能在设计用例的时候发现。

    第二是发现BUG的时候了,这应该是测试人员最基本的任务了,一般按测试用例开始测试就能发现大部分的bug,还有一部分bug需要测试的过程中更了解所测版本的情况获得更多信息,补充测试用例,测试出bug。还有如何发现bug?这就需要在测试用例有效的情况下,通过细心和耐心去发现bug了,每个用例都有可能发现bug,每个地方都有可能出错,所以测试过程中思维要清晰(测试过程数据流及结果都得看仔细了,bug都在里面发现的)。如何描述bug也很有讲究,bug在什么情况下会产生,如果条件变化一点点,就不会有这个bug,以哪些最少的操作步骤就能重现这个bug,这个bug产生的规律是什么?如果你够厉害的话,可以帮开发人员初步定位问题。


    问题十五:你的测试职业发展目标是什么?

    测试经验越多,测试能力越高。所以我的职业发展是需要时间累积的,一步步向着高级测试工程师奔去。而且我也有初步的职业规划,前3年累积测试经验,按如何做好测试工程师的11,12点要求自己,不断的更新自己改正自己,做好测试任务。


    问题十六:你自认为测试的优势在哪里?

    有韧性

    有能力面对挑战

    有信心做好每一件事情

    有比较好的教育背景

    从以前的经理处都得到了很好的评价表明我做的很好


    问题十七:当开发人员说不是BUG时,你如何应付?

    如果确实是自己理解错误,则承认错误,没什么大不了

    如果是需求不明,请项目经理补充清楚

    如果双方理解不一致,且都不能互相说服,则请项目经理判断。


    问题十八:你为什么想离开目前的职务?


    问题十九:你对我们公司了解有多少?


    问题二十:你找工作时,最重要的考虑因素为何?

    工作的性质和内容是否能让我发挥所长,并不断成长。


    问题二十一:为什么我们应该录取你?

    您可以由我过去的工作表现所呈现的客观数据,明显地看出我全力以赴的工作态度。


    问题二十二:请谈谈你个人的最大特色。

    我的坚持度很高,事情没有做到一个令人满意的结果,绝不罢手。


    问题二十三:一个测试工程师应具备那些素质和技能?


    问题二十四:集成测试通常都有那些策略?

           自上而下,自下而上,平面集成


    问题二十五:测试结束的标准是什么?

           从微观上来说,在测试计划中定义,比如系统在一定性能下平稳运行72小时,目前Bug Tracking System中,本版本中没有一般严重的BUG,普通BUG的数量在3以下,BUG修复率90%以上等等参数,然后由开发经理,测试经理,项目经理共同签字认同版本Release。

           如果说宏观的,则是当这个软件彻底的消失以后,测试就结束了。


    问题二十六:软件验收测试除了alpha,beta测试以外,还有哪一种?

    第三方验收测试


    问题二十七:为什么选择测试这行?

    最开始么,公司安排的,然后么,干一行爱一行,发现测试中间还是有很多东西需要学习的,再就是测试中有很多东西值得改进和研究。


    问题二十六:为什么值得他们公司雇用?

          用自己的经验和其他同事一起发现更多的问题,同时不同行业的观点可以互相借鉴。


    问题二十七:如果我雇用你,你能给部门带来什么贡献?

          分享我的测试经验和测试技能,提高测试部门技术水平

  • 常见功能测试点<zhuan>

    2012-07-09 15:54:48

    以前在这里看到一篇文章说,要积累各个常用模块的测试点,然后到需要测试的时候就根据这些测试点设计测试用例,我觉得这是一个好方法,就决定总结一下。我的实际经验不多,根据我在论坛中学到的零散的东西和自己的想象,总结出以下几点,欢迎各位继续补充。
    1.        登陆
    2.        添加
    3.        查询
    4.        删除


    1.        登陆
    ①        用户名和密码都符合要求(格式上的要求)
    ②        用户名和密码都不符合要求(格式上的要求)
    ③        用户名符合要求,密码不符合要求(格式上的要求)
    ④        密码符合要求,用户名不符合要求(格式上的要求)
    ⑤        用户名或密码为空
    ⑥        数据库中不存在的用户名,不存在的密码
    ⑦        数据库中存在的用户名,错误的密码
    ⑧        数据库中不存在的用户名,存在的密码
    ⑨        输入的数据前存在空格
    ⑩        输入正确的用户名密码以后按[enter]是否能登陆

    2.        添加
    ①        要添加的数据项均合理,检查数据库中是否添加了相应的数据
    ②        留出一个必填数据为空
    ③        按照边界值等价类设计测试用例的原则设计其他输入项的测试用例
    ④        不符合要求的地方要有错误提示
    ⑤        是否支持table键
    ⑥        按enter是否能保存
    ⑦        若提示不能保存,也要察看数据库里是否多了一条数据

    3.        删除
    ①        删除一个数据库中存在的数据,然后查看数据库中是否删除
    ②        删除一个数据库中并不存在的数据,看书否有错误提示,并且数据库中没有数据被删除
    ③        输入一个格式错误的数据,看是否有错误提示,并且数据库中没有数据被删除。
    ④        输入的正确数据前加空格,看是否能正确删除数据
    ⑤        什么也不输入
    ⑥        是否指出table键
    ⑦        是否支持enter键

    4.        查询
    精确查询:
    ①        输入的查询条件为数据库中存在的数据,看是否能正确地查出相应得数据
    ②        输入正确的查询条件以前加上空格,看是否能正确地查出相应的数据
    ③        输入格式或范围不符合要求的数据,看是否有错误提示
    ④        输入数据库中不存在的数据
    ⑤        不输入任何数据
    ⑥        是否支持table键
    ⑦        是否支持enter键
    模糊查询:
    在精确查询的基础上加上以下一点
    ①        输入一些字符,看是否能查出数据库中所有的相关信息
    设计功能和界面测试用例

    设计功能和界面测试用例


    1.1 文本框、按钮等控件测试

    1.1.1 文本框的测试

    如何对文本框进行测试

     a,输入正常的字母或数字。
     b,输入已存在的文件的名称;
     c,输入超长字符。例如在“名称”框中输入超过允许边界个数的字符,假设最多255个字符,尝试输入 256个字符,检查程序能否正确处理;
     d,输入默认值,空白,空格;
     e,若只允许输入字母,尝试输入数字;反之;尝试输入字母;
     f,利用复制,粘贴等操作强制输入程序不允许的输入数据;
     g,输入特殊字符集,例如,NUL及\n等;
     h,输入超过文本框长度的字符或文本,检查所输入的内容是否正常显示;
     i,输入不符合格式的数据,检查程序是否正常校验,如,程序要求输入年月日格式为yy/mm/dd,实际输入yyyy/mm/dd,程序应该给出错误提示

    在测试过程中所用到的测试方法:

     1,输入非法数据;
     2,输入默认值;
     3,输入特殊字符集;
     4,输入使缓冲区溢出的数据;
     5,输入相同的文件名;
    命令按钮控件的测试

    测试方法:

     a,点击按钮正确响应操作。如,单击确定,正确执行操作;单击取消,退出窗口;
     b,对非法的输入或操作给出足够的提示说明,如,输入月工作天数为32时,单击”确定“后系统应提示:天数不能大于31;
     c,对可能造成数据无法恢复的操作必须给出确认信息,给用户放弃选择的机会;
    单选按钮控件的测试

    测试方法:

     a,一组单选按钮不能同时选中,只能选中一个。
     b,逐一执行每个单选按钮的功能。分别选择了“男”“女”后,保存到数据库的数据应该相应的分别为“男”“女”;
     c,一组执行同一功能的单选按钮在初始状态时必须有一个被默认选中,不能同时为空;
    up-down控件文本框的测试

    测试方法:

     a,直接输入数字或用上下箭头控制,如,在“数目”中直接输入10,或者单击向上的箭头,使数目变为10;
     b,利用上下箭头控制数字的自动循环,如,当最多数字为253时,单击向上箭头,数目自动变为1;反之亦适用;
     c,直接输入超边界值,系统应该提示重新输入;
     d,输入默认值,空白。如,“插入”数目为默认值,点击“确定”;或,删除默认值,使内容为空,单击“确定”进行测试;
     e,输入字符。此时系统应提示输入有误。
    组合列表框的测试

    测试方法:

     a,条目内容正确,其详细条目内容可以根据需求说明确定;
     b,逐一执行列表框中每个条目的功能;
     c,检查能否向组合列表框输入数据;
    复选框的测试

    测试方法:

     a,多个复选框可以被同时选中;
     b,多个复选框可以被部分选中;
     c,多个复选框可以都不被选中;
     d,逐一执行每个复选框的功能;
    列表框控件的测试

    测试方法:

     a,条目内容正确;同组合列表框类似,根据需求说明书确定列表的各项内容正确,没有丢失或错误;
     b,列表框的内容较多时要使用滚动条;
     c,列表框允许多选时,要分别检查shift选中条目,按ctrl选中条目和直接用鼠标选中多项条目的情况;
    滚动条控件的测试

    要注意一下几点:

     a,滚动条的长度根据显示信息的长度或宽度及时变换,这样有利于用户了解显示信息的位置和百分比,如,word中浏览100页文档,浏览到50页时,滚动条位置应处于中间;
     b,拖动滚动条,检查屏幕刷新情况,并查看是否有乱码;
     c,单击滚动条;
     d,用滚轮控制滚动条;
     e,滚动条的上下按钮。
    各种控件在窗体中混和使用时的测试

     a,控件间的相互作用;
     b,tab键的顺序,一般是从上到下,从左到右;
     c,热键的使用,逐一测试;
     d,enter键和esc键的使用;
    在测试中,应遵循由简入繁的原则,先进行单个控件功能的测试,确保实现无误后,再进行多个控件的的功能组合的测试。

    ps:密码输入框测试时要特别注意进行字母大写输入的测试。

    查找替换操作
     案例演示:打开word中的"替换"对话框
     测试本功能有通过测试和失败测试两种情况
     通过测试:

     1,输入内容直接查找,或查找全部
     2,在组合框中寻找已经查找过的内容,再次查找并确认文档的内容正确,如,已经查找过"测试用例",再次进入不用重新输入查找内容,直接在文档中搜寻就可以.

    失败测试:
     1,输入过长或过短的查询字符串.如,假设查询的字符串长度为1到255,那么输入0,1,2,256,255和254进行测试;
     2,输入特殊字符集,如,在word中.^g代表图片,^代表分栏符,可以输入这类特殊字符测试;

    替换测试大体相同.
     关于编辑操作窗口的功能测试的用例:
     1,关闭查找替换窗口.不执行任何操作,直接退出;
     2,附件和选项测试.假如,设定"精确搜寻","向后"搜索等附件选项等等来测试;
     3,控件间的相互作用.如,搜寻内容为空时,按钮"搜寻全部","搜寻","全部替换","替换"都为灰色.
     4,热键, Tab键.回车键的使用.

    插入操作
     1,插入文件
     测试的情况
     a,插入文件;
     b,插入图像;
     c,在文档中插入文档本身;
     d,移除插入的源文件;
     e,更换插入的源文件的内容;

    2,链接文件
     测试方法:
     a,插入链接文件;
     b,在文档中链接文档本身;
     c,移除插入的源文件;
     d,更换插入的源文件的内容.

    3,插入对象
     要测试的内容
     a,插入程序允许的对象,如,在word中插入excel工作表;
     b,修改所插入对象的内容.插入的对象仍能正确显示;
     c,卸载生成插入对象的程序,如,在word中插入excel工作表后卸载excel,工作表仍正常使用.

    编辑操作
     编辑操作包括剪切,复制,粘贴操作.

    测试剪切操作的方法
     a,对文本,文本框,图文框进行剪切;
     b,剪切图像
     c,文本图像混合剪切
     复制操作方法与剪切类似.

    测试时,主要是对粘贴操作的测试,方法是:
     a,粘贴剪切的文本,文本框及图文框;
     b,粘贴所剪切的图像;
     c,剪切后,在不同的程序中粘贴
     d,多次粘贴同一内容,如,剪切后,在程序中连续粘贴3次;
     e,利用粘贴操作强制输入程序所不允许输入的数据.

    界面测试用例的设计方法
     1,窗体
     测试窗体的方法:
     a,窗体大小,大小要合适,控件布局合理;
     b,移动窗体.快速或慢速移动窗体,背景及窗体本身刷新必须正确;
     c,缩放窗体,窗体上的控件应随窗体的大小变化而变化;
     d,显示分辨率.必须在不同的分辨率的情况下测试程序的显示是否正常;
     进行测试时还要注意状态栏是否显示正确;工具栏的图标执行操作是否有效,是否与菜单懒中图标显示一致;错误信息内容是否正确,无错别字,且明确等等;

    2,控件
     测试方法:
     a,窗体或控件的字体和大小要一致;
     b,注意全角,半角混合
     c,无中英文混合.

    菜单

    进行测试时要注意
     a,选择菜单是否可以正常工作,并与实际执行内容一致;
     b,是否有错别字:
     c,快捷键是否重复;
     d,热键是否重复;
     e,快捷键与热键操作是否有效
     f,是否存在中英文混合
     g,菜单要与语境相关,如,不同权限的用户登陆一个应用程序,不同级别的用户可以看到不同级别的菜单并使用不同级别的功能;
     h,鼠标右键快捷菜单

    特殊属性
     1,安装界面应有公司介绍或产品介绍,有公司的图标
     2,主界面及大多数界面最好有公司图标
     3,选择"帮助"->"关于"命令,应 看见相关版权和产品信息
    实际中经常用到的几个用例

    login
    1、链接地址是否正确。
    2、产生输入/输出错误时,系统是否进行检测并处理.
    3、密码输入框是否按掩码的方式显示。

    menu:
    1、各模块链接地址是否正确。
    2、鼠标无规则点击时是否会产生无法预料的结果。

    browse:
    1、浏览信息是否存在文字书写错误和语法错误。
    2、浏览信息是否和数据库中对应的字段及信息相一致。
    3、浏览页面中的链接按钮是否可以正确链接并显示。
    4、其他功能按钮按下后,数据是否按既定规约处理。

    add,modify:
    1、产生输入/输出错误时,系统是否进行检测并处理。
    2、列表框是否能够进行选择。
    3、单选组内是否有且只有一个单选钮可选。
    4、多选组内是否能够进行多数据项选择。
    5、多项列表框是否能够进行多数据项选择。
    6、控件是否存在默认输入值,若存在,默认值是否得到显示和提交.
    7、Cancel之类的按钮按下后,控件中的数据是否清空复原或按既定规约处理.
    8、Submit之类的按钮按下后,数据是否得到提交或按既定规约处理。
    9、其他页面按钮按下后,数据是否按既定规约处理。
    10、异常信息表述是否正确。

    search:
    1、输入信息中是否存在和代码中的字符产生冲突的字符,系统是否进行检测并处理。
    2、异常信息表述是否正确。
    3、查询的结果是否正确。
    4、列表框是否能够进行选择。
    5、单选组内是否有且只有一个单选钮可选。
    6、多选组内是否能够进行多数据项选择。
    7、多项列表框是否能够进行多数据项选择。
    8、 Submit之类的按钮按下后,数据是否得到提交或按既定规约处理。


    Statistic:
    1、产生的文件和数据表的计算结果是否正确。
    2、图表结果数据显示是否正确。
    3、浏览页面中的链接按钮是否可以正确链接并显示。
    4、其他功能按钮按下后,数据是否按既定规约处理。
    5、产生输入/输出错误时,系统是否进行检测并处理。
    6、列表框是否能够进行选择。
    7、单选组内是否有且只有一个单选钮可选。
    8、多选组内是否能够进行多数据项选择。
    9、多项列表框是否能够进行多数据项选择。


  • Loadrunner常用的分析点<zhuan>

    2012-07-09 15:51:43

    下面是LoadRunner三大组件中的Controller即压力产生器的部分可供分析的结果参数,一般可以在测试过程中可以进行粗略的观察,待测试结束后利用Analyse即分析器进行详细的分析。

    Vusers(虚拟用户数):

    提供了生产负载的虚拟用户运行状态的相关信息,可以帮助我们了解负载生成的结果。

    Rendezvous(负载过程中集合点下的虚拟用户):

    当设置集合点后会生成相关数据,反映了随着时间的推移各个时间点上并发用户的数目,方便我们了解并发用户的变化情况。

    Errors(错误统计):

    通过错误信息可以了解错误产生的时间和错误类型,方便定位产生错误的原因。

    Errors per Second(每秒错误):

    了解在每个时间点上错误产生的数目,数值越小越好。通过统计数据可以了解错误随负载的变化情况,定为何时系统在负载下开始不稳定甚至出错。

    Average Transaction Response Time(平均事务响应时间):

    反映随着时间的变化事务响应时间的变化情况,时间越小说明处理的速度越快。如果和用户负载生成图合并,就可以发现用户负载增加对系统事务响应时间的影响规律。

    Transactions perSecond(每秒事务):

    TPS吞吐量,反映了系统在同一时间内能处理事务的最大能力,这个数据越高,说明系统处理能力越强。

    Transactions Summary(事务概要说明):

    统计事物的Pass数和Fail数,了解负载的事务完成情况。通过的事务数越多,说明系统的处理能力越强;失败的事务数越小说明系统越可靠。

    Transaction performance Summary(事务性能概要):

    事务的平均时间、最大时间、最小时间柱状图,方便分析事务响应时间的情况。柱状图的落差越小说明响应时间的波动小,如果落差很大,说明系统不够稳定。

    Transaction Response Time Under Load(用户负载下事务响应时间):

    负载用户增长的过程中响应时间的变化情况,该图的线条越平稳,说明系统越稳定。

    Transactions Response time(事务响应时间百分比):

    不同百分比下的事务响应时间范围,可以了解有多少比例的事物发生在某个时间内,也可以发现响应时间的分布规律,数据越平稳说明响应时间变化越小。

    Transaction Response Time(各时间段上的事务数):

    每个时间段上的事务个数,响应时间较小的分类下的是事务越多越好。

    Hits per Second(每秒点击):

    当前负载重对系统所产生的点击量记录,每一次点击相当于对服务器发出了一次请求,数据越大越好。

    Throughput(吞吐量):

    系统负载下所使用的带宽,该数据越小说明系统的带宽依赖就越小,通过这个数据可以确定是不是网络出现了瓶颈。

    HTTP Responses per Second(每秒HTTP响应):

    每秒服务器返回各种状态的数目,一般和每秒点击量相同。点击量是客户端发出的请求数,而HTTP响应数是服务器返回的响应数。如果服务器的响应数小于点击量,那么说明服务器无法应答超出负载的连接请求。

    Connections per Second(每秒连接):

    统计终端的连接和新建的连接数,方便了解每秒对服务器产生连接的数量。同时连接数越多,说明服务器的连接池越大,当连接数随着负载上升而停止时,说明系统的连接池已满,通常这时候服务器会返回504错误。需要修改服务器的最大连接来解决该问题。


  • 软件测试工具LoadRunner常见问题《zhuan》

    2012-07-09 15:49:14

    1.LoadRunner录制脚本时为什么不弹出IE浏览器?
      当一台主机上安装多个浏览器时,LoadRunner录制脚本经常遇到不能打开浏览器的情况,可以用下面的方法来解决。

      启动浏览器,打开Internet选项对话框,切换到高级标签,去掉“启用第三方浏览器扩展(需要重启动)”的勾选,然后再次运行VuGen即可解决问题

      提示:通常安装Firefox等浏览器后,都会勾选上面得选项,导致不能正常录制。因此建议运行LoadRunner得主机上保持一个干净的测试环境。

      2.录制Web脚本时,生成的脚本中存在乱码该如何解决?

      录制脚本前,打开录制选项配置对话框Record-Options,进入到Advanced标签,先勾选“Support charset”,然后选择中支持UTF-8。再次录制,就不会出现中文乱码问题了。

      3.HTML-based script与URL-based script的脚本有什么区别?

      使用“HTML-based script”的模式录制脚本,VuGen为用户的每个HTML操作生成单独的步骤,这种脚本看上去比较直观;使用“URL-based script”模式录制脚本时,VuGen可以捕获所有作为用户操作结果而发送到服务器的HTTP请求,然后为用户的每个请求分别生成对应方法。

      通常,基于浏览器的Web应用会使用“HTML-based script”模式来录制脚本;而没有基于浏览器的Web应用、Web应用中包含了与服务器进行交互的Java Applet、基于浏览器的应用中包含了向服务器进行通信的JavaScript/VBScript代码、基于浏览器的应用中使用了HTTPS安全协议,这时使用“URL-based script”模式进行录制。

      4.为什么脚本中添加了检查方法Web-find,但是脚本回放时却没有执行?

      由于检查点功能会耗费一定的资源,因此LoadRunner默认关闭了对文本及图像的检查。要想开启检查功能,必须修改运行时的配置Run-time Setting。

      进入“Run-time Setting”对话框,依次进入“Internet Protocol→Preferences”,勾选Checks下的“Enable Image and text check”选项即可。

      检查执行结果时推荐使用web_reg_find方法。

      5.运行时的Pacing设置主要影响什么?

      Pacing主要用来设置重复迭代脚本的间隔时间。共有三种方法:上次迭代结束后立刻开始、上次迭代结束后等待固定时间、按固定或随机的时间间隔开始执行新的迭代。

      根据实际需要设置迭代即可。通常,没有时间间隔会产生更大的压力。

      6.运行时设置Log标签中,如果没有勾选“Enable logging”,则手工消息可以发送吗?

      Enable logging选项仅影响自动日志记录和通过lr_log_message发送的消息。即使没有勾选,虚拟用户脚本中如果使用lr_message、lr_output_message、lr_error_message,仍然会记录其发出的消息。

      7.LoadRunner 8.0版本的VuGen在录制Web Services协议的脚本时一切正常,而回放时报出错误提示“Error:serverreturned an incorrectly formatted SOAP response”。这时说明原因引起的?

      造成这种情况的主要原因是LoadRunner 8.0的VuGen在录制Web Service协议的脚本时存在一个缺陷:如果服务器的操作系统是中文的,VuGen会自动将WSDL文件的头改为,因此会有上面的错误提示。

      解决方法:把“LR80WebservicesFPI_setup.exe”和“lrunner_web_sevices_path_1.exe”两个补丁打上即可解决。
     8.VuGen支持Netscape的客户证书吗?

      不支持。目前的VuGen 8.0版本中仅支持Internet Explorer的客户端证书。录制脚本时可以先从Netscape中导出所需的证书,然后将其导入到Internet Explorer中,并确保以相同的顺序导出和导入这些证书。而且,在每台将要录制或运行需要证书的Web Vuser脚本的计算机上都要重复执行前面的过程。

      9.VuGen会修改录制浏览器中的代理服务器设置吗?

      会修改。在开始录制基于浏览器的Web Vuser脚本时,VuGen首先会启动指定的浏览器。然后,VuGen会指示浏览器访问VuGen代理服务器。为此,VuGen会修改录制浏览器上的代理服务器设置。默认情况下,VuGen会立即将代理服务器设置更改为Localhost:7777。录制之后,VuGen会将原始代理服务器设置还原到该录制浏览器中。因此,在VuGen进行录制的过程中,不可以更改代理服务器设置,否则将无法正常进行。

      10.在LoadRunner脚本如何输出当前系统时间?

      LoadRunner提供了char *ctime(const time_t *time)函数,调用参数为一个Long型的整数指针,用于存放返回时间的数值表示。

      调用语句与返回值如下示例:

      typedef long time_t;

      Action()

      {

      time_t t;

      lr_message(“Time in seconds since 1/1/70: %ld ”,time(&t));

      lr_message(“System time and date: %s”,ctime(&t));

      }

      输出结果为:

      Time in seconds since 1/1/70: 1185329968

      System time and date:Wed Jul 25 10:19:28 2007

      11.一些Web虚拟用户脚本录制后立刻回放没有任何问题,但是当设置迭代次数大于1时,如果进行回放则只能成功迭代一次。为什么从第二次迭代开始发生错误?

      这种现象多是由于在“Run-time Setting”的“Browse Emulation”的设置中,勾选了“Simulate a new user on each iteration”及其下面的选项“Clear cache on each iteration”这两个选项的含义是每次迭代时模拟一个新的用户及每次迭代时清除缓存。

      由于脚本迭代时,init和end只能执行一次,如果每次迭代都模拟一个新的用户并清除缓存,

    则用户登录信息将一并清除,因此迭代时可能会发生错误。

      12.虚拟客户脚本“Run-time Setting”中的线程和进程运行方式的区别?

      如果选择“Run Vuser as a process”,则场景运行时会为每一个虚拟用户创建一个进程;选择“Run Vuser as a thread”则将每个虚拟用户作为一个线程来运行,在任务管理器中只看到一个mmdrv.exe,这种方式的运行效率更高,能造成更大的压力,时默认选项。

      另外,如果启用了IP欺骗功能,则先在Controller中选中Tools菜单下的“Expert Mode”,然后将Tools菜单下的“Options>General”标签页中的IP地址分配方式也设置为与Vuser运行方式一致,同为线程或进程方式。

      13.在Controller中运行Web相关测试场景时,经常会有很多超时错误提示,如何处理这类问题?

      这主要有脚本的默认超时设置引起。当回放Web脚本时,有时候由于服务器响应时间较长,会产生超时的错误。这时需要修改脚本的运行时配置。

      进入“Run-time Setting”对话框后,依次进入“Internet Protocol→Preference”。然后点击“Options…”按钮,进入高级设置对话框,可以修改各类超时设置的默认值。

      14.为什么Windows系统中的CPU、内存等资源仍然充足,但是模拟的用户数量却上不去?

      在Windows计算机的标准设置下,操作系统的默认限制只能使用几百个Vuser,这个限制与CPU或内存无关,主要是操作系统本身规定了默认的最大线程数所导致。要想突破Windows这个限制,须修改Windows注册表。以Windows XP Professional为例。

      (1)打开注册表后,进入注册表项HKEY_LOCAL_MACHINE中的下列关键字:SystemCurrentControlSetControlSession ManagerSubSystems。

      (2)找到Windows关键字,Windows关键字如下所示:

      %SystemRoot%system32csrss.exe bjectDirectory=Windows

      SharedSection=1024,3072,512 Windows=On SubSystemType=Windows ServerDll=basesrv,1

      ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=winsrv:ConServerDllInitialization,2

      ProfileControl=Off MaxRequestThreads=16

      SharedSection=1024,3072,512关键字的格式为xxxx,yyyy,zzz。其中,xxxx定义了系统范围堆的最大值(以KB为单位),yyyy定义每个桌面堆得大小。

      (3)将yyyy的设置从3072更改为8192(即8MB),增加SharedSection参数值。

      通过对注册表的更改,系统将允许运行更多的线程,

    因而可以在计算机上运行更多的Vuser。这意味着能够模拟的最大并发用户数量将不受Windows操作系统的限制,而只受硬件和内部可伸缩性限制的约束。


  • 功能测试中遇到不可重现软件缺陷的解决策略<转>

    2012-07-09 15:35:27

    测试人员提交软件缺陷报告后,最不希望看到的这些缺陷被开发人员忽略,尽管你坚信这一定是软件缺陷,而罪魁祸首就是这些缺陷不可重现!一旦出现这样的情况,测试人员会很被动,开发人员也会对测试人员有意见。这就使得关系本来就不怎么融洽的测试人员和开发人员之间的关系更加紧张;对于整个时间紧凑的项目来说,无异于是火上浇油。为了减少这种尴尬情况的出现,非常有必要分析一下软件缺陷不能重现的原因。
    1. 测试环境不一致
    从广义上来说,保证或影响软件的任何因素都是环境,例如,系统的构造版本、应用服务器的类型和版本、浏览器的语音和版本等。
    以下就是我们会遇见的错误:某个B/S(Web应用)架构的系统软件运行于IE8上,出现了JS(Java Script)脚本错误导致页面浏览异常的软件缺陷,把IE8降级到IE6或7后,此软件缺陷就自动消失了。
    2. 测试配置不一致
    程序运行都是基于一定的配置条件下进行的,包括被测系统参数设置、基础数据完整性、业务流程完整性等,比如,我们曾经在某数据库产品测试过程中,由于在安装界面中选择了非默认路径进行安装,结果导致该数据库物理备份会恢复功能出错,而对方在核对缺陷时按照默认路径进行了安装,因此缺陷总是无法重现。
    3. 内存泄露
    某些系统长期运行后出现速度慢的原因是开发人员未养成回收内存的习惯。这类错误在短期内不会出现,但当系统长期运行时就会出现,并且由此会引发一系列的问题。
    4. 数据接口不匹配
    一般只有在查看源代码后才能发现。某些类型的数据会被系统自动转换,有些数据被截断或被强制转换成另外一种数据类型时,会出现一些潜在的错误。
    基于以上测试过程中出现的软件缺陷不能重现的原因,我们提出如下一些解决策略,以更好地从源头上减少不可重现软件缺陷的出现
    1. 测试环境配置充分细致
    测试人员在测试前,严格核对系统的运行环境配置要求,并充分考虑系统在线运行后的环境变化,做好测试环境配置的全面规划,注意细节。另外可以使用Ghost对硬件或某个分区进行镜像备份。
    2. 捕获系统日志,分析异常信息
    测试人员应养成记录系统错误日志的习惯,保留系统在出错时的真实状态。比如将IE浏览器高级选项设置为“显示每个脚本错误的通知”。
    3. 监测系统状态,异常及时告警
    在实施系统测试过程中,我们必须充分关注系统运行状态的变化,一旦系统运行状态发生较大的波动,势必会对后期的业务执行带来较大的影响。因此,系统运行监测的一个重要内容是需要及时反馈系统运行异常,并提供异常报告。
    4. 测试数据翔实,易于追溯
    测试数据是软件测试的核心,很多情况下,测试人员为了缩短测试周期,在实际测试前并没有充分编写足够的测试数据,也没有记录这些测试数据的执行顺序和运行轨迹,一旦程序在某个节点出现问题,我们无法判断其产生的过程和引起这个缺陷的具体测试数据,对我们进一步分析软件缺陷产生的原因会造成一些不必要的障碍。
    正是基于此我们强调在软件测试开始前,我们必须制定完整的测试用例,辅以详细的测试数据,并明确测试数据的操作步骤和每一步的预期结果,这样,一旦软件出现问题,我们可以很快进行重现和定位。
  • 文件上传--测试用例《转》

    2012-07-09 15:32:21

    1.功能测试
    (1)选择符合要求的文件,上传--------上传成功;
    (2)上传成功的文件名称显示----------显示正常(根据需求)
    (3)查看,下载上传成功的文件--------上传的文件可查看或下载
    (4)删除上传成功的文件-------------可删除
    (5)替换上传成功的文件-------------可替换
    (6)上传文件是否支持中文名称--------根据需求而定
    (7)文件路径是否可手动输入----------根据需求而定
    (8)手动输入正确的文件路径,上传-----上传成功
    (9)手动输入错误的文件路径,上传-----提示,不能上传
     
    2.文件大小测试
    (1)符合格式,总大小稍小于限制大小的文件------上传成功
    (2)符合文件,总大小等于限制大小的文件--------上传成功
    (3)符合文件总大小稍大于限制大小的文件--------在上传初提示附件过大
    (4)小为0kb的txt文档-----------------------不能上传
     
    3.文件名称测试
    (1)文件名称过长。Win2000标准:255个字符(指在英文的字符下),如果是中文不超过127个汉字-----提示过长
    (2)文件名称达到最大长度(中文,英文或混在一起)上传后名称显示,页面排版-----------页面显示正常
    (3)文件名称中包含特殊字符-------------根据需求而定
    (4)文件名全为中文--------------------根据需求而定
    (5)文件名全为英文--------------------根据需求而定
    (6)文件名为中、英混合-----------------根据需求而定
     
    4.文件格式测试
    (1)上传正确格式-----------------上传成功
    (2)上传不允许的格式--------------提示不能上传
    (3)上传rar,zip等打包文件(多文件压缩)---------根据需求而定
     
     
    5.安全性测试
    (1)上传可执行文件(exe文件)-----------------根据需求而定
    (2)上传常见的木马文件------------------------提示不能上传
    (3)上传时服务器空间已满----------------------有提示
     
     
    6.性能测试
    (1)上传时网速很慢(限速)-----------------当超过一定时间,提示
    (2)上传过程断网--------------------------有提示是否上传成功
    (3)上传过程服务器停止工资------------------有提示是否上传成功
    (4)上传过程服务器的资源利用率---------------在正常范围
     
    7.界面测试
    (1)界面美观性、易用性(键盘和鼠标的操作、tab跳转的顺序是否正确)----------显示正常(根据需求)
    (2)按钮文字是否正确--------------正确
    (3)正确/错误提示的文字是否正确---------------正确
    (4)说明性文字是否正确-----------------------正确
     
     
    8.其他测试
    (1)有多个上传框时,上传相同名称的文件---------------根据需求而定
    (2)上传一个正在打开的文件-------------------------可以上传
    (3)文件路径是手工输入的是否限制长度----------------限制一定的长度
    (4)上传过程中是否有取消正在上传文件的功能-----------有
    (5)保存时有没有已经选择好,但没有上传的文件-----------提示上传
    ()选择好但是未上传的文件是否可以取消选择------------可以取消选择
  • 一个纸水杯的测试用例设计【zhuan】

    2012-07-06 14:41:18

     

     

    需求:一个带有广告图案的花纸杯。查看需求说明书。
    可从功能性、性能性、易用性、稳定性、安全性……方面进行测试

    功能性:

        水杯的特性:
          1、杯子的容量:能装多少升水,少量、半杯、满杯。
          2、杯子的形状eg:圆形、上口大、下口小。
          3、杯子的材料:纸杯。
          4、杯子的耐温度:装冷水、冰水、热水。
          5、杯子是否会漏水。
          6、用杯子装水,看是否能喝到
        广告的图案:
          1、广告图案是否容易剥落。
          2、广告图案是否合法。
          3、广告图案遇水是否是否会掉落。
     
    性能性:
          1、盛冷水和热水时分别盛多少水杯能够承受。 
     
    易用性:
          1、杯子是否方便饮用。
          2、装热水时杯子是否烫手。
          3、杯子是否有防滑措施。
     
    稳定性:
          1、装入液态多久后会漏水。
          2、杯子从不同高度落下的损毁程度。
     
    安全性:
          1、杯子有没有毒或细菌。
          2、杯子装入热水是否会变形或有异味。
          3、装入不同液体,是否发生化学反应。eg:啤酒、可乐、咖啡等饮料。
     
    可移植性:
          1、杯子再不同的地方、温度等环境下是否都可以正常使用。
     
    破坏测试:
          1、检查水杯最大抗挤压和拉扯承受力。
          2、检查水杯被破坏后,是否会造成使用者伤害。

    用户手册:
          1、用户手册是否对杯子的用法、限制、使用条件等做了详细的说明。
  • 学习性能测试需要掌握的知识面<转>

    2012-07-06 14:32:45

     

    摘要:随着Internet的普及与迅速发展,企业业务量的迅速加大,数据大集中成为一种趋势,IT系统承载的负荷越来越重,系统性能的好坏严重的影响了企业对外提供的服务质量。从而对IT系统的性能进行测试和调优引起企业的重视,进而性能测试工程师成为IT市场的”香悖悖”,并且性能测试有着极高的技术挑战。于是吸引了大量的测试爱好者来学这方面的技术,而一谈到性能测试很多人便会想到鼎鼎大名的LoadRunner这款优秀的性能测试工具,然而到这里问题就产生了?

      关建字:LoadRunner 性能测试 网络基础编程语言数据库操作系统

      LoadRuner与性能测试的关系:LoadRunner初学者的误点:把LoadRunner神化了。很多初学LoadRunner的朋友认为掌握了使用LoadRunner这款性能测试工具,就能够做性能测试了。常在网上看到好多人在学习怎么去使用这款优秀的性能测试工具,本来学习怎么去使用LoadRunner这个工具没有错,却把LoadRunner神化了,”天真的”以为它什么都能做,以为学会了LoadRunner的使用就能做性能测试了。尽管用了大量的时间学会了如何使用LoadRunner录制脚本,如何进行关联,如何进行参数化,如何设置集合点等等?可到头来,性能测试还是不会做。为什么?对于产生的性能报告不知道怎么去分析?不知道如何利用得到的分析报告分析出系统存在的瓶颈?不知道如何进行性能调优?像这些事光会使用LoadRunner是做不到的?说白了LoadRunner只是我们做性能测试的一个工具,它并不是万能的,是死的,具体怎么做还得依靠人去操作与分析。会使用LoadRunner的人,并不一定会做性能测试,会做性能测试的人并不一定都会使用 LoadRunner。LoadRunner只是一个性能测试工具而已。我们应该意识到,测试工具只是性能测试中的一部分,仅是为达到性能测试目的而采用的一种手段

      性能测试与系统性能的关系:高性能,高安全的系统,不是测试出来的,而是构架,设计,编写出来的。当然在这里我并不否认性能测试的重要性,甚至可以说没有经过性能测试的系统,一定不会是优秀的系统,软件是人开发出来的,而人总是会出错的,所谓智者千虑,必有一失……要想做好性能测试,在软件系统需求,设计,编写代码的这些阶段就应该进行性能测试,而不仅仅是系统测试这个阶段才去做性能测试,性能测试应该贯穿于整个软件开发周期中。

      对初学LoadRunner朋友的建意:常看到网上一些网友发贴子问,怎么对性能测试产生的结果进行分析?测试系统时怎么去选择合适的协议?对于发这些贴子的人我想请问你?你能够详细的说下HTTP协议吗?TCP建立连接和释放连接的过程是怎样进行的?什么是协议?协议是用来做什么的?在OSI参考模型中各层的作用?数据库中产生并发的冲突的原因?不要太依赖于LoadRunner工具本身的学习,而去忽略计算机其它基础知识的学习,我们更应该去掌握一门编程语言,良好的网络基础知识,计算机原理与操作系统知识,数据库知识。这些是我们去学习怎么去使用LoadRunner前提与基础。。

      1、为什么要掌握一门编程语言

      其一,大家在使用LoadRunner时常会遇到一些不能录制脚本的情况发生,或者需要录制一些复杂的脚本,这时候我们就必须手动的开发脚本。其二 LoadRunner虽然强大,易于使用,可是它却属于商业软件,价格昂贵,并且代码不开源,我们无法了解LoadRunner具体的实现细节,甚至我们会怀疑LoadRunner收集的性能数据准确吗?它有是如何实现的等等,而这些我们通过LoadRunner的帮助文档无法得知。性能测试工具并不只有 LoadRunner,做性能测试还有许多优秀的性能测试工具可以选择,像JMeter,Curl- Loader等等这些非常优秀的开源工具,在全能上虽然并不上LoadRunner,但在某些方面却比LoadRunner还要强大。例如Curl- Loader这个工具,它虽然支持的协议不多,但是对于http协议它最高能产生10万的并发用户,这是LoadRunner远远所不及的。并且这些工具代码是公开的,我们能够从这些代码中去分析具体实现的细节,并且还可以自已编写代码,增强软件的功能,这也是成为性能测试高手的一条途径。LoadRunner好比我们的Windows操作系统,易于使用,功能强大,代码封闭,论全能比Linux要强大。我们的开源性能测试工具好比Linux操作系统代码开源,不易于使用,但很多方面比我们的Windows要强大。也许这个时候有人会问对于初学者学哪门语言最好最有前途C,C++,VB,JAVA,C#?其实每一种语言能够生存下来,自有其生存的道理,每一种语言都有自已优势和缺点,并且编程语言具有相通信,学好了一门,再去学另外的编程语言,非常快就能上手。对于初学者我建意学习C语言,理由有很多,例如很多优秀的开源性能测试工具就是用C语言开发的…。当然不管选择什么编程语言,或者数据库,或者操作系统,我们不要去想学哪门最好,学哪方面最有前途。我们更应该结合自身的情况,选择最合适的,而不是选择最好的。

      2、为什么要掌握计算机原理和操作系统知识

      论坛上常会看到这些问题?LoadRunner中线程与进程的关系?在什么时候用到它们,怎么区别用线程还是进程呢?LoadRunner录制产生了乱码怎么解决?怎么去发现内存泄漏?对那些发贴问这些问题的朋友,我依然想请问你你知道进程和线程的概念吗?知道进程有几种状态吗?知道进程间的通信是怎么进行的吗?死锁,进程与线程的区别这些概念你明白吗?如果你连内存的概念,内存的作用,内存泄露的概念都搞不清楚,你怎么去发现内存泄露?如果这些你都不知道,自然就不知道怎么去做性能测试分析?一些网友录制脚本常常会产生一些莫名奇妙的错误?还震震有词的说这是LoadRunner的原因。其实要说到底要解决这些问题就必需得有良好的计算机原理和操作系统知识。弄清了进程和线程的区别,你自然就明白了使用进程资源使用高,但安全性要强于线程,线程资源利用率少,使用线程能在一个负载生成器上运行更多的Vuser,但可能存在安全问题。LoadRunner录制产生了乱码怎么解决?为什么会产生乱码,你知道什么是字符集吗?什么是编码吗?字符串在我们内存中有是如何存放的?ASCII编码,ANSI编码,UNICODE编码它们的区别是什么?这些都是操作系统的基础基础。掌握好了这些你自然明白LoadRunner中产生乱码的原因。当然计算机原理和操作系统的基础知识还有很多得掌握的知识。像操作系统的体系架构、操作系统的重要基础概念,内存管理、存储/文件系统、驱动/硬件的管理。要做好性能测试计算机原理和操作系统知识必不可少。

    3、为什么要有良好的网络基础

      经常在51testing论坛中看到很多人发贴子。像LoadRuner中为什么要进行关联?LoadRunner测试系统时如何选择协议?LoadRunner中的如何进行IP欺骗?等等。这些问题随便一搜就能发现大量的贴子,其实说到底这些问题和LoadRunner的关系并不是很大,要去解决这些问题并不在于你对LoadRunner这个工具使用是否熟练,而在于我们网络基础知识是否扎实。例如第一个问题LoadRunner中为什么要进行关联?相信很多朋友都知道HTTP协议知道它是超文本传输协议,但是对于一些新手往往不能够详细的说出HTTP具体的内容,像HTTP工作的原理,HTTP协议为什么要使用基于TCP的协议而不使用UDP的协议,HTTP工作在OSI参考模型的哪一层?在HTTP协议上数据是怎么传输的等等。而只有当我们明白了这一切,自然而然就会明白为什么要使用关联,到最后你会发现这些问题其实根LoadRunner关系并不是很大。HTTP协议本质上是无状态的;对页面的每个请求都将被视为新请求,而且默认情况下,来自一个请求的信息对下一个请求不可用。在传统的Web编程中,这通常意味着在每一次往返行程中,与该页及该页上的控件相关联的所有信息都会丢失。例如,如果用户将信息输入到文本框,该信息将在从浏览器或客户端设备到服务器的往返行程中丢失,为了使用浏览网页,页与页是相互联系不去丢失这些信息,于是了就从现了Cookie,Session,查询字符串等等保持状态的技术。什么是Cookie?什么是Session?Cookie 和Session 有是怎么工作的?当我们明白了这些,很多的问题就自然而然的明白了,像这些都是基础的知识和LoadRunner关系大吗?不大。

      Cookie 是一些少量的数据,这些数据存储在客户端文件系统的文本文件中,或者存储在客户端浏览器会话的内存中。Cookie 包含特定于站点的信息(像用户名密码以及我们在网站一些个性化的设置等等),这些信息是随页输出一起由服务器发送到客户端的。如果浏览器使用的是 cookie,那么所有的数据都保存在浏览器端,比如我们登录以后,服务器设置了cookie用户名,那么当你再次请求服务器的时候,浏览器会将用户名一块发送给服务器,这些变量有一定的特殊标记。服务器会解释为cookie变量,所以只要不关闭浏览器,那么cookie变量一直是有效的,所以能够保证长时间不掉线。。如果设置了的有效时间,那么它会将 cookie保存在客户端的硬盘上,下次再访问该网站的时候浏览器先检查有没有 cookie,如果有的话,就读取该 cookie,然后发送给服务器。这些是Cookie的工作过程,常看到论坛上一些朋友发贴子问使用LoadRunner时录制到了一些Cookie的信息,它是用来做什么的,看起来很烦可不可以把它删除掉?明白了这些细节的知识,你自然能明白那个Cookie的信息能不能删除掉。如果web服务器端使用的是session,那么所有的数据都保存在服务器上,客户端每次请求服务器的时候会发送当前会话的SessionId,服务器根据当前 SessionId唯一地标识在服务器上包含会话数据的浏览器,以确定用户是否登录或具有某种权限。不同的用户发送请求Web服务器会随机发送一个唯一的 SessionID。而我们使用LoadRunner录制时它会把我们SessionID写死,所以导致出错。这时候就得使用关联了,这样不仅明白了 LoadRunner怎样使用关联,而且还明白了为什么要使用关联?对于LoadRunner测试系统时如何选择协议?这个问题也是网络论讨的比较多的问题。要解决这个问题同样得依靠我们的扎实的网络基础,而不是对LoadRunner使用的熟练程度,首先我们得了解LoadRunner录制时的工作原理了,LoadRunner的录制和QTP不一样,它不关心你的对象识别什么的,不关心你的什么界面之类的,不关心你使用什么语言编写的,LoadRunner有一个Agent进程,来专门监控客户端和服务器之间的通信,然后用自己的函数进行录制。LoadRunner录制的时候关心的是通信包,是客户端和服务器之间的数据包。说到这里,大家就比较清楚了,为什么有的时候不能录制呢?因为,协议不认识,导致LoadRunner截获的数据包不能解析,所以录制下来是空的。所以我们得熟悉什么是协议, 熟悉OSI参考模型,OSI参考模型中各层的作用,TCP协议栈各层的作用,熟悉TCP,UDP,ICMP等等协议。当我们明白了这些网络的基础知识后我们自然会明白应该如何去选择协议。另外关于LoadRunner中的如何进行IP欺骗?要解决这个问题同样得有良好的网络基础知识。其实当我们理解了IP 地址的格式,IP地址的分类,子网掩码的概念,以及知道怎么去进行非标准子网的划分方法 ,掌握了这些原理的东西,那么具体怎么在LoadRunner中如何进行IP欺骗,就非常简单了。 当然网络基础知识并不只是上面的而已,还包括路由器,交换机,加密技术等等这些基础的网络知识,这些远远比我们去学习怎么去使用LoadRunner更重要。

      4、为什么要掌握数据库知识

      数据库的重要性我想是不言而喻的,性能测试产生的一个非常大的原因是因为数据大集中的趋势,测试从某种意义来讲就是对数据测试,而我们企业的核心数据是放在数据库中的。现在大型的WEB应用程序,都采用多层结构,像典型三层,用户界面层,数据逻辑层,数据层。而数据层,而数据层对我们整个WEB应用程序的性能是非常大的,对数据库的基础知识不懂,我们怎么去进行性能测试分析?怎么知道确定性能产生的瓶颈是否是数据库的原因,如何对系统进行调优?例如数据库模型设计不合理,一条坏的SQL语句就能影响到整个WEB应用程序的性能,所以熟悉SQL语句,建表,索引,存储过程,事务,触发器,并发等这些基础知识是必需得掌握的。

      路漫漫其修远兮,吾将上下而求索:性能测试难点不在于Loadrunner工具本身,难在对整个系统的全局把握,而对全局的把握你就必需得有丰富的知识面。 并不是学好了LoadRunner的使用就能做性能测试 。目前,国内性能测试领域正处于起步阶段,要做好性能测试还需学习更多的知识,技术性和非技术。性能测试这条路充满着挑战,也充满着机遇。但正如鲁迅先生所说这世上本来没有路,走的人多了,也就成了路。最后祝愿喜爱性能测试的爱好这条道路上能够不鸣则已,一鸣惊人,不飞则已,一飞冲天。


  • 测试总结

    2009-04-28 12:07:01

    测试总结

     

    1.摆正心态

    一个好的测试工程师应具有”测试是为了破坏”的观点,捕获用户观点能力,强烈的质量追求,对细节的关注能力.应用的高风险区的判断能力以便将有限的测试针对重点环节

     

    2. 细致负责

    任何BUG其实都是必现的,测试过程中要清楚自己的操作步骤,一旦问题出现,有很清晰的思路找到必现的规律。

    接到测试任务不要马上盲目就开始进行测试工作,首先考虑所分配的模块中哪些做了改动,都关联到哪些模块,还有哪些边界的地方可能没有测试到, 再进行有目的,有预期结果性的测试,一旦发现BUG 能很快定位

    在测试过程当中应将以前曾经遇到过的类似的错误从记忆深处挖掘出来,这一能力在测试过程中的价值是无法衡量的.因为许多新出现的问题和我们已经发现的问题相差无几.

     

    3.  拓展测试思路,尝试各种不同操作

    如找边界值:很多的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此,针对各种边界情况进行测试,可以查出更多的错误.

     

       软件测试需要模拟真实用户对软件进行操作和使用,从中查找出软件的缺陷。只有通过各种方式对软件全面测试,才能尽量避免漏测

     

    查看论坛和TD中的BUG,查看过程中要注意的问题:

    怎样的操作更容易出现问题

    别人的测试思路与风格和自己有什么区别

     

    4. 不厌其烦
    工作要细心认真,具有责任感

    善于学习、思考、发现、总结问题

    具有耐心与恒心 

    及时关注软件的改动情况

    每出新版本首先要注意:该版本修改了哪些bug?增加了什么功能?需要着重验证修改bug模块及相关模块。

     

     

  • 如何对文本框……进行测试

    2009-04-20 18:36:19

     

     

    1.1 文本框、按钮等控件测试

    1.1.1 文本框的测试

    如何对文本框进行测试

     a,输入正常的字母或数字。
     b,输入已存在的文件的名称;
     c,输入超长字符。例如在名称框中输入超过允许边界个数的字符,假设最多255个字符,尝试输入 256个字符,检查程序能否正确处理;
     d,输入默认值,空白,空格;
     e,若只允许输入字母,尝试输入数字;反之;尝试输入字母;
     f,利用复制,粘贴等操作强制输入程序不允许的输入数据;
     g,输入特殊字符集,例如,NUL\n等;
     h,输入超过文本框长度的字符或文本,检查所输入的内容是否正常显示;
     i,输入不符合格式的数据,检查程序是否正常校验,如,程序要求输入年月日格式为yy/mm/dd,实际输入yyyy/mm/dd,程序应该给出错误提示

    在测试过程中所用到的测试方法:

     1,输入非法数据;
     2,输入默认值;
     3,输入特殊字符集;
     4,输入使缓冲区溢出的数据;
     5,输入相同的文件名;

    命令按钮控件的测试

    测试方法:

     a,点击按钮正确响应操作。如,单击确定,正确执行操作;单击取消,退出窗口;
     b,对非法的输入或操作给出足够的提示说明,如,输入月工作天数为32时,单击确定后系统应提示:天数不能大于31
     c,对可能造成数据无法恢复的操作必须给出确认信息,给用户放弃选择的机会;

    单选按钮控件的测试

    测试方法:

     a,一组单选按钮不能同时选中,只能选中一个。
     b,逐一执行每个单选按钮的功能。分别选择了”“后,保存到数据库的数据应该相应的分别为”“
     c,一组执行同一功能的单选按钮在初始状态时必须有一个被默认选中,不能同时为空;

    updown控件文本框的测试

    测试方法:

     a,直接输入数字或用上下箭头控制,如,在数目中直接输入10,或者单击向上的箭头,使数目变为10
     b,利用上下箭头控制数字的自动循环,如,当最多数字为253时,单击向上箭头,数目自动变为1;反之亦适用;
     c,直接输入超边界值,系统应该提示重新输入;
     d,输入默认值,空白。如,插入数目为默认值,点击确定;或,删除默认值,使内容为空,单击确定进行测试;
     e,输入字符。此时系统应提示输入有误。

    组合列表框的测试

    测试方法:

     a,条目内容正确,其详细条目内容可以根据需求说明确定;
     b,逐一执行列表框中每个条目的功能;
     c,检查能否向组合列表框输入数据;

    复选框的测试

    测试方法:

     a,多个复选框可以被同时选中;
     b,多个复选框可以被部分选中;
     c,多个复选框可以都不被选中;
     d,逐一执行每个复选框的功能;

    列表框控件的测试

    测试方法:

     a,条目内容正确;同组合列表框类似,根据需求说明书确定列表的各项内容正确,没有丢失或错误;
     b,列表框的内容较多时要使用滚动条;
     c,列表框允许多选时,要分别检查shift选中条目,按ctrl选中条目和直接用鼠标选中多项条目的情况;

    滚动条控件的测试

    要注意一下几点:

     a,滚动条的长度根据显示信息的长度或宽度及时变换,这样有利于用户了解显示信息的位置和百分比,如,word中浏览100页文档,浏览到50页时,滚动条位置应处于中间;
     b,拖动滚动条,检查屏幕刷新情况,并查看是否有乱码;
     c,单击滚动条;
     d,用滚轮控制滚动条;
     e,滚动条的上下按钮。

    各种控件在窗体中混和使用时的测试

     a,控件间的相互作用;
     b,tab键的顺序,一般是从上到下,从左到右;
     c,热键的使用,逐一测试;
     d,enter键和esc键的使用;

    在测试中,应遵循由简入繁的原则,先进行单个控件功能的测试,确保实现无误后,再进行多个控件的的功能组合的测试。

    ps:密码输入框测试时要特别注意进行字母大写输入的测试。

    查找替换操作
     案例演示:打开word中的"替换"对话框
    查看(633) 评论(3) 收藏 分享 管理

  • 2009年度上半年计算机技术与软件专业技术资格(水平)考试报名

    2009-03-12 17:42:16

    http://www.bjpta.gov.cn/news_z.asp?news_id=705

    一、报名时间
      2009年3月5日至31日
      台湾居民资格审核时间
      2009年3月19日至20日
    二、网上打印准考证时间
      2009年5月19日至21日
    三、考试时间
      2009年5月23日

     

     


     

  • 软件测试面试常用英语

    2009-03-11 13:15:19

    With my qualifications and experience, I feel I am hardworking, responsible and diligent in any project I undertake. Your organization could benefit from my analytical andinterpersonal skills.
    依我的资格和经验,我觉得我对所从事的每一个项目都很努力、负责、勤勉。我的分析能力和与人相处的技巧,对贵单位必有价值。
    Q:Why did you leave your lastjob?你为什么离职呢?
    A:Well, I am hoping to get an offer of a better position. If opportunity knocks, I will take it.
    我希望能获得一份更好的
    工作,如果机会来临,我会抓住。
    With my strong academic background, I am capable and competent.
    凭借我良好的学术背景,我可以胜任自己的工作,而且我认为自己很有竞争力。
    Q:What do you think you are worth to us?你怎么认为你对我们有价值呢?
    A:I feel I can make some positive contributions to your company in the future.
    我觉得我对贵公司能做些积极性的贡献。
    Q:What make you think you would be a success in this position?
    你如何知道你能胜任这份工作?
    A:My graduate school training combined with my internship should qualify me for this particular job. I am sure I will be successful.
    我在研究所的训练,加上实习工作,使我适合这份工作。我相信我能成功。
    Q:What is your strongest trait(s)?你个性上最大的特点是什么?
    A:Helpfulness and caring.乐于助人和关心他人。
    A:Adaptability and sense of humor.适应能力和幽默感。
    A:Cheerfulness and friendliness.乐观和友爱。
    Q:How do you normally handle criticism?你通常如何处理別人的批评?
    A:Silence is golden. Just don't say anything; otherwise the situation could become worse. I do, however, accept constructive criticism.
    沈默是金。不必说什么,否则情况更糟,不过我会接受建设性的批评。
    A:When we cool off, we will discuss it later. 我会等大家冷靜下来再讨论。)
    Q:How do you handle your conflict with your colleagues in your work?
    你如何处理与同事在工作中的意见不和?
    A:I will try to present my ideas in a more clear and civilized manner in order to get my points across. 我要以更清楚文明的方式,提出我的看法,使对方了解我的观点。
    Q:How do you handle your failure?你怎样对待自己的失敗?
    A:None of us was born "perfect". I am sure I will be given a second chance to correct my mistake.我们大家生来都不是十全十美的,我相信我有第二个机会改正我的错误。
    Q:What provide you with a sense of accomplishment.什么会让你有成就感?
    A:Do my best job for your company. 为贵公司竭力效劳。)
    A:Finish a project to the best of my ability. 尽我所能,完成一个项目。
    Q:How long would you like to stay with this company?你会在本公司服务多久呢?
    A:I will stay as long as I can continue to learn and to grow in my field.
    只要我能在我的行业力继续
    学习和长进,我就会留在这里。
    Q:Could you project what you would like to be doing five years from now?
    你能预料五年后你会做什么吗?
    A:As I have some administrative experience in my last job, I may use my organizational and planning skills in the future.
    我在上一个工作中积累了一些行政经验,我将来也许要运用我组织和计划上的经验和技巧。
    A:I hope to demonstrate my ability and talents in my field adequately.
    我希望能充分展示我在这个行业的能力和智慧。
    Don't appear to be pushy or overly anxious to get a job. 不必过分表现急着要工作。
    Be honest but not too modest. 要诚实,但不必太谦虚。
    Don't put yourself down or cut yourself up. 不可妄自菲薄或自贬。

  • 计算机系统基础知识

    2009-03-11 13:05:15

    计算机系统基础知识
       1.1 计算机系统构成及硬件基础知识
        ●计算机系统的构成
        ●处理机
        ●基本输入输出设备
        ●存储系统
       1.2 操作系统基础知识
        ●操作系统的中断控制、进程管理、线程管理
        ●处理机管理、存储管理、设备管理、文件管理、作业管理
        ●网络操作系统和嵌入式操作系统基础知识
        ●操作系统的配置
       1.3 数据库基础知识
        ●数据库基本原理
        ●数据库管理系统的功能和特征
        ●数据库语言与编程
       1.4 中间件基础知识
       1.5 计算机网络基础知识
        ●网络分类、体系结构与网络协议
        ●常用网络设备
        ●Internet基础知识及其应用
        ●网络管理
       1.6 程序设计语言知识
        ●汇编、编译、解释系统的基础知识
        ●程序设计语言的基本成分(数据、运算、控制和传输、过程(函数)调用)
        ●面向对象程序设计
        ●C语言以及C++(或Java)语言程序设计基础知识
      2.标准化基础知识
        ●标准化的概念(标准化的意义、标准化的发展、标准化机构)
        ●标准的层次(国际标准、国家标准、行业标准、企业标准)
        ●标准的类别及生命周期
      3.信息安全知识
        ●信息安全基本概念
        ●计算机病毒及防范
        ●网络入侵手段及防范
        ●加密与解密机制
      4.信息化基础知识
        ●信息化相关概念
        ●与知识产权相关的法律、法规
        ●信息网络系统、信息应用系统、信息资源系统基础知识
      5.软件工程知识
       5.1 软件工程基础
        ●软件工程概念
        ●需求分析
        ●软件系统设计
        ●软件组件设计
        ●软件编码
        ●软件测试
        ●软件维护
       5.2 软件开发方法及过程
        ●结构化开发方法
        ●面向对象开发方法
        ●瀑布模型
        ●快速原型模型
        ●螺旋模型
       5.3 软件质量管理
        ●软件质量及软件质量管理概念
        ●软件质量管理体系
        ●软件质量管理的目标、内容、方法和技术
       5.4 软件过程管理
        ●软件过程管理概念
        ●软件过程改进
        ●软件能力成熟度模型
       5.5 软件配置管理
        ●软件配置管理的意义
        ●软件配置管理的过程、方法和技术
       5.6 软件开发风险基础知识
        ●风险管理
        ●风险防范及应对
       5.7 软件工程有关的标准
        ●软件工程术语
        ●计算机软件开发规范
        ●计算机软件产品开发文件编制指南
        ●计算机软件需求规范说明编制指南
        ●计算机软件测试文件编制规范
        ●计算机软件配置管理计划规范
        ●计算机软件质量保证计划规范
        ●数据流图、程序流程图、系统流程图、程序网络图和系统资源图的文件编制符号及约定

    6.软件测试知识
       6.1 软件测试基本概念
        ●软件质量与软件测试
        ●软件测试定义
        ●软件测试目的
        ●软件测试原则
        ●软件测试对象
       6.2 软件测试过程模型
        ●V模型
        ●W模型
        ●H模型
        ●测试模型的使用
       6.3 软件测试类型
        ●单元测试、集成测试、系统测试
        ●确认测试、验收测试
        ●开发方测试、用户测试、第三方测试
        ●动态测试、静态测试
        ●白盒测试、黑盒测试、灰盒测试
       6.4 软件问题分类
        ●软件错误
        ●软件缺陷
        ●软件故障
        ●软件失效
       6.5 测试标准
        7.5.1 GB/T 16260.1—2003 软件工程 产品质量 第1部分:质量模型
        7.5.2 GB/T 18905.1—2002 软件工程 产品评价 第1部分:概述
        7.5.3 GB/T 18905.5—2002 软件工程 产品评价 第5部分:评价者用的过程
  • 国外著名的测试技术论坛

    2009-03-06 16:36:23

    http://bdonline.sqe.com/ 一个关于网站测试方面的网页,对这方面感兴趣的人可以参考
    http://citeseer.nj.nec.com/ 一个丰富的电子书库,内容很多,而且提供著作的相关文档参考和下载,是作者非常推荐的一个资料参考网站
    http://groups.yahoo.com/group/LoadRunner 性能测试工具LoadRunner的一个论坛
    http://groups.yahoo.com/grorp/testing-paperannou-nce/messages 提供网站上当前发布的软件测试资料列表
    http://satc.gsfc.nasa.gov/homepage.html 软件保证中心是美国国家航天局(NASA)投资设立的一个软件可靠性和安全性研究中心,研究包括了度量、工具、风险等各个方面
    http://seg.iit.nrc.ca/English/index.html 加拿大的一个研究软件工程质量方面的组织,可以提供研究论文的下载
    http://sepo.nosc.mil 内容来自美国SAN DIEGO的软件工程机构(Sofrware Engineering Process Office)主页,包括软件工程知识方面的资料
    http://www.asq.org/ 是世界上最大的一个质量团体组织之一,有着比较丰富的论文资源,不过是收费的
    http://www.automated-testing.com/ 一个自动化软件测试和自然语言处理研究页面,属于个人网页,上面有些资源可供下载
    http://www.benchmarkresources.com/ 提供有关标杆方面的资料,也有一些其它软件测试方面的资料
    http://www.betasoft.com/ 包含一些流行测试工具的介绍、下载和讨论,还提供测试方面的资料
    http://www.brunel.ac.uk/~csstmmh2/vast/home.html VASTT研究组织,主要从事通过切片技术、测试技术和转换技术来验证和分析系统,对这方面技术感兴趣的人是可以在这里参考一些研究的项目及相关的一些主题信息
    http://www.cc.gatech.edu/aristotle/ Aristole研究组织,研究软件系统分析、测试和维护等方面的技术,在测试方面的研究包括了回归测试、测试套最小化、面向对象软件测试等内容,该网站有丰富的论文资源可供下载
    http://www.computer.org/ IEEE是世界上最悠久,也是在最大的计算机社会团体,它的电子图书馆拥有众多计算机方面的论文资料,是研究计算机方面的一个重要资源参考来源
    http://www.cs.colostate.edu/testing/ 可靠性研究网站,有一些可靠性方面的论文资料
    http://www.cs.york.ac.uk/testsig/ 约克大学的测试专业兴趣研究组网页,有比较丰富的资料下载,内容涵盖了测试的多个方面,包括测试自动化、测试数据生成、面向对象软件测试、验证确认过程等
    http://www.csr.ncl.ac.uk/index.html 学校里面的一个软件可靠性研究中心,提供有关软件可靠性研究方面的一些信息和资料,对这方面感兴趣的人可以参考
    http://www.dcs.shef.ac.uk/research/groups/vt/ 学校里的一个验证和测试研究机构,有一些相关项目和论文可供参考
    http://www.esi.es/en/main/ ESI(欧洲软件组织),提供包括CMM评估方面的各种服务
    http://www.europeindia.org/cd02/index.htm 一个可靠性研究网站,有可靠性方面的一些资料提供参考
    http://www.fortest.org.uk/ 一个测试研究网站,研究包括了静态测试技术(如模型检查、理论证明)和动态测试(如测试自动化、特定缺陷的检查、测试有效性分析等)
    http://www.grove.co.uk/ 一个有关软件测试和咨询机构的网站,有一些测试方面的课程和资料供下载
    http://www.hq.nasa.gov/office/codeq/relpract/prcls-23.htm NASA可靠性设计实践资料
    http://www.io.com/~wazmo/ Bret Pettichord的主页,他的一个热点测试页面连接非常有价值,从中可以获得相当大的测试资料,很有价值
    http://www.iso.ch/iso/en/ISOOnline.frontpage 国际标准化组织,提供包括ISO标准系统方面的各类参考资料
    http://www.isse.gmu.edu/faculty/ofut/classes/ 821-ootest/papers.html 提供面向对象和基于构架的测试方面著作下载,对这方面感兴趣的读者可以参考该网站,肯定有价值
    http://www.ivv.nasa.gov/ NASA设立的独立验证和确认机构,该机构提出了软件开发的全面验证和确认,在此可以获得这方面的研究资料
    http://www.kaner.com/ 著名的测试专家Cem Kanner的主页,里面有许多关于测试的专题文章,相信对大家都有用。Cem Kanner关于测试的最著名的书要算Testing Software,这本书已成为一个测试人员的标准参考书
    http://www.library.cmu.edu/Re-search/Engineer- ingAndSciences/CS+ECE/index.html 卡耐基梅陇大学网上图书馆,在这里你可以获得有关计算机方面各类论文资料,内容极其庞大,是研究软件测试不可获取的资料来源之一
    http://www.loadtester.com/ 一个性能测试方面的网站,提供有关性能测试、性能监控等方面的资源,包括论文、论坛以及一些相关链接
    http://www.mareinig.ch/mt/index.html 关于软件工程和应用开发领域的各种免费的实践知识、时事信息和资料文件下载,包括了测试方面的内容
    http://www.mtsu.ceu/-storm/ 软件测试在线资源,包括提供目前有哪些人在研究测试,测试工具列表连接,测试会议,测试新闻和讨论,软件测试文学(包括各种测试杂志,测试报告),各种测试研究组织等内容
    http://www.psqtcomference.com/ 实用软件质量技术和实用软件测试技术国际学术会议宣传网站,每年都会举行两次
    http://www.qacity.com/front.htm 测试工程师资源网站,包含各种测试技术及相关资料下载
    http://www.qaforums.com/ 关于软件质量保证方面的一个论坛,需要注册
    http://www.qaiusa.com/ QAI是一个提供质量保证方面咨询的国际著名机构,提供各种质量和测试方面证书认证
    http://www.qualitytree.com/ 一个测试咨询提供商,有一些测试可供下载,有几篇关于缺陷管理方面的文章值得参考
    http://www.rational.com/ IBM Rational的官方网站,可以在这里寻找测试方面的工具信息。IBM Rational提供测试方面一系列的工具,比较全面
    http://rexblackconsulting.com/Pages/publicat-ions.htm
    Rex Black的个人主页,有一些测试和测试管理方面的资料可供下载
    http://www.riceconsulting.com/ 一个测试咨询提供商,有一些测试资料可供下载,但不多
    http://www.satisfice.com/ 包含James Bach关于软件测试和过程方面的很多论文,尤其在启发式测试策略方面值得参考
    http://www.satisfice.com/seminars.shtml 一个黑盒软件测试方面的研讨会,主要由测试专家Cem Kanar和James Bach组织,有一些值得下载的资料
    http://www.sdmagazine.com/ 软件开发杂志,经常会有一些关于测试方面好的论文资料,同时还包括了项目和过程改进方面的课题,并且定期会有一些关于质量和测试方面的问题讨论
    http://www.sei.cmu.edu/ 著名的软件工程组织,承担美国国防部众多软件工程研究项目,在这里你可以获俄各类关于工程质量和测试方面的资料。该网站提供强有力的搜索功能,可以快速检索到你想要的论文资料,并且可以免费下载
    http://www.soft.com/Institute/HotList/ 提供了网上软件质量热点连接,包括:专业团体组织连接、教育机构连接、商业咨询公司连接、质量相关技术会议连接、各类测试技术专题连接等
    http://www.soft.com/News/QTN-Online/ 质量技术时事,提供有关测试质量方面的一些时事介绍信息,对于关心测试和质量发展的人士来说是很有价值的
    http://www.softwaredioxide.com/ 包括软件工程(CMM,CMMI,项目管理)软件测试等方面的资源
    http://www.softwareqatest.com/ 软件质量/测试资源中心。该中心提供了常见的有关测试方面的FAQ资料,各质量/测试网站介绍,各质量/测试工具介绍,各质量/策划书籍介绍以及与测试相关的工作网站介绍
    http://www.softwaretestinginstitute.com 一个软件测试机构,提供软件质量/测试方面的调查分析,测试计划模板,测试WWW的技术,如何获得测试证书的指导,测试方面书籍介绍,并且提供了一个测试论坛
    http://www.sqatester.com/index.htm 一个包含各种测试和质量保证方面的技术网站,提供咨询和培训服务,并有一些测试人员社团组织,特色内容是缺陷处理方面的技术
    http://www.sqe.com/ 一个软件质量工程服务性网站,组织软件测试自动化、STAR-EASE、STARWEST等方面的测试学术会议,并提供一些相关信息资料和课程服务
    http://www.stickyminds.com/ 提供关于软件测试和质量保证方面的当前发展信息资料,论文等资源
    http://www.stqemagazine.com/ 软件策划和质量工程杂志,经常有一些好的论文供下载,不过数量较少,更多地需要通过订购获得,内容还是很有价值的
    http://www.tantara.ab.ca/ 软件质量方面的一个咨询网站,有过程改进方面的一些资料提供
    http://www.tcse.org/ IEEE的一个软件工程技术委员会,提供技术论文下载,并有一个功能强大的分类下载搜索功能,可以搜索到测试类型、测试管理、 测试分析等各方面资料
    http://www.testing.com/ 测试技术专家Brain Marick的主页,包含了Marick 研究的一些资料和论文,该网页提供了测试模式方面的资料,值得研究。总之,如果对测试实践感兴趣,该网站一定不能错过
    http://www.testingcenter.com/ 有一些测试方面的课程体系,有一些价值
    http://www.testingconferences.com/asiastar/home 著名的AsiaStar测试国际学术会议官方网站,感兴趣的人一定不能错过
    http://www.testingstuff.com/ Kerry Zallar的个人主页,提供一些有关培训、工具、会议、论文方面的参考信息
    http://www-sqi.cit.gu.edu.au/ 软件质量机构,有一些技术资料可以供下载,包括软件产品质量模型、再工程、软件质量改进等
  • 缺乏版本控制测试易陷混乱风险

    2009-03-04 18:13:01

    缺乏版本控制测试易陷混乱风险

    字体:        | 上一篇 下一篇 | 打印  | 我要投稿  | 每周一问,答贴有奖

      前一段时间,公司委派我负责一个软件测试项目,测试工作进行得还算顺利。但结果还是差点儿出了问题,主要是在测试过程中的版本控制上出了问题。在软件测试中版本控制虽然是一门基本的实践性技术,但是许多人并不知道如何使用它,或者未能有效地利用它。这里与大家分享一下,以作为前事不忘,后事之师。

      在这次软件测试项目中,我们首先会把发现的Bug提交给开发人员,开发人员修复后会把修改过的代码提交到正在测试的版本中去。问题就出在这里。因为修改过后的代码,我们不能保证它是否会带来新的隐患,这样就给测试人员的测试工作带来困扰。后来发展到只要开发人员一提交代码到正在测试的版本中,我们就会比没有发现Bug更为紧张,每一次除去验证修复的Bug之外,还都要尽量保证没有遗漏新修正代码所带来的后患。

      软件测试缺乏版本控制的后果

      随着软件的规模及复杂程度日趋大型化、复杂化,软件测试的方式也从早期的单兵作战式或手工作坊式,渐渐转变为流水线式的团队协作测试方式。最常见的是多个测试人员共同负责一个软件的测试,每个人在各自的机器上都有整个软件的拷贝,并对之实施测试,分别完成各自任务。但当没有有效使用版本控制时,这种测试模式会遇到一些非常棘手的问题。

      (1)缺乏版本控制,难以保证测试进度

      大多数的测试人员都是典型的完美主义者,这样的做法无可厚非,但是缺乏版本控制时会出现较低的测试效率。在测试管理上,不可能要求每个版本都是完美无缺,否则就不需要出新版本了。但要求每个版本的状态都必须在掌控之中,最基本的就是哪些功能OK,哪些功能NG。换句话说,一个测试版本应该很容易对应到一个状态。在未来的任何一个时间点,新测试版本应可以拿来和这个测试版本的快照(Snapshot)做比较。

      (2)缺乏版本控制,难以保证测试的一致性

      软件测试往往是多个测试人员共同协作的过程,不同人对同一个软件的不同部分同时做着测试,这种行为有时会出现彼此交叉的情况。因此,软件测试是多人共同协力进行的复杂工作,必须要在效率与纪律间取得一个平衡,而版本控制据实践证明是有效的方式之一。当缺乏版本控制时,测试一致性的失衡风险就会经常发生。

      因此,对测试团队来说,每个测试版本都应该是一个重要的核查点,因为版本控制代表着掌握着测试过程某个时间点的状况。所以,在多个测试人员共同负责的一个软件测试中,没有进行版本控制或者版本控制本身缺乏正确的流程管理,将会引入很多问题,并难以确保测试的一致性。

      (3)测试版本冗余,易出现误用风险

      一般来说,待测软件在各个测试人员的机器上都有拷贝,并且同一个测试人员在不同时期也会在本机保留多个的软件版本。简单的说就是,一台机器上可能不止一个测试版本。这类似于一种信息的冗余,对于不同版本而言其差别有时可能并不很大。但一个很重要的问题是随着时间推移,测试人员可能会对自己机器上的不同版本间的具体差异了解也变得模糊不情,甚至忘记了当时为什么区分这些版本的原因,这就会给测试工作带来麻烦。而且同时维护多个版本,也很难保证这一过程不会出现差错。因此,缺乏版本控制,版本冗余的误用风险就会成倍增多。

      (4)容易导致本地版本和服务器版本不一致

      测试版本混乱造成的危害还体现在资源的浪费上面,很多测试团队经常发生测试组花费时日测试某一项功能,却发现最新修正的开发版本已经把整项功能取消,导致大家重复测试。发生这类错误原因是因为测试组没有拿到最新的开发版本,也可能是测试人员在从服务器那里更新本地版本时,由于缺乏版本控制和管理,从而导致本地版本和服务器版本不一致。因此,加强本地版本和服务器版本的一致性管理,是绝对重要的一项工作。

      (5)缺乏测试文档可追溯性

      版本控制不仅只为各种测试版本提供了文档管理支持,还能提供可追溯性的文件。这样我们就可以随时查阅软件测试过程中生成的各种文档,这是提高、总结和分享测试经验的重要途径之一。

  • Web 测试的经验

    2007-04-15 21:22:34

    Web 测试的经验

     

    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 的系统测试不但需要检查和验证是否按照设计的要求运行,而且还要评价系统在不同用户的浏览器端的显示是否合适。重要的是,还要从最终用户的角度进行安全性和可用性测试。

  • 功能测试用例的书写方式

    2007-04-15 21:19:39

    功能测试用例的书写方式

    功能性测试用例
    1. 测试的来源,即测试的需求
    测试用例的主要来源有:
    1) 需求说明”及相关文档

    2)相关的设计说明(概要设计,详细设计等)

    3)与开发组交流对需求理解的 记录(可以是开发人员的一个解释)

    4)已经基本成型的UI(可以有针对性地补充一些用例)

    简而言之,所有你能得到的项目文档,都尽量拿到。 从所得到的资料中,分解出若干小的“功能点”,理解“功能点”,编写相应的测试用例。

    2. 用例的组织方式

    不同的公司有不同的做法,原则上,只要方便管理和跟踪,怎么组织都可以的。

    用例可以按大的功能块组织,如查询功能模块的用例,可以组织在一起,打印模块的测试用例,可以另外组 织在一起。

    在没有专门的测试用例管理工具的情况下,用例执行后会产生2种状态:“通过”、“失败”——这样加上“未 执行”的用例的状态,共3种状态。

    即从“未执行”用例中执行一个用例后,该用例状态应为“失败”或“通 过”。将同一状态的用例组织在一起。

    至于用例文件格式,可以是.DOC或.XLS(如果有专门的测试用例管理工具另当别论)。

    3. 用例与其他材料的关联方式,即如何解决用例跟踪的问题 测试用例面临的比较大的风险有:

    需求的变更、设计的修改、需求的错误和遗漏等等。

    由于用例的主要来源是需求和设计的说明,所以对用例的跟踪其实就是对需求和设计的跟踪,需求和设计的 变更势必引起测试用例的变更。

    如前所说,将分解的功能点编号,与相应的用例联系起来。例如,你可以列一个表格,列出各个(编号的)功 能点和测试用例间的关联关系。

    这样,当需求和设计发生变化时,你只需要跟踪“功能点”是否变化,是否增 加了新的功能点。

    重要和困难的是,不手头的资料和信息一定要是最新的。

    4. 一个好的用例的表述要点,即用例中应当包含的信息

    一个优秀的测试用例,应该包含以下信息:

    1) 软件或项目的名称

    2) 软件或项目的版本(内部版本号)

    3) 功能模块名

    4) 测试用例的简单描述,即该用例执行的目的或方法

    5) 测试用例的参考信息(便于跟踪和参考)

    6) 本测试用例与其他测试用例间的依赖关系

    7) 本用例的前置条件,即执行本用例必须要满足的条件,如对数据库的访问权限

    8) 用例的编号(ID),如可以是 软件名称简写-功能块简写-NO.。

    9) 步骤号、操作步骤描述、测试数据描述

    10)预期结果(这是最重要的)和实际结果(如果有BUG管理工具,这条可以省略)

    11)开发人员(必须有)和测试人员(可有可无)

    12)测试执行日期

    5. 给出一个测试用例的例子该范例已经包含一个测试用例的模板。

    项目/软件 技术出口合同网络申领系统 (企业端) 程序版本 1.0.25
    功能模块名 Login 编制人   xxx
    用例编号- TC-TEP_Login_1 编制时间   2002.10.12
    相关的用例
    功能特性 用户身份验证
    测试目的 验证是否输入合法的信息,允许合法登陆,阻止非法登陆
    预置条件 特殊规程说明 如数据库访问权限
    参考信息 需求说明中关于“登陆”的说明
    测试数据 用户名=yiyh 密码=1
    操作步骤 操作描述 数 据 期望结果 实际结果 实际结果

    测试状态

    1 输入用户名称,按“登陆”按钮。 用户名=yiyh,密码为空 显示警告信息“请输入用户名和密码!”
    2 输入密码,按“登陆”按钮。 用户名为空,密码=1 显示警告信息“请输入用户名和密码!”
    3
    输入用户名和密码,按“登陆”按钮。
    用户名=yiyh,密码=2
    显示警告信息“请输入用户名和密码!”

    4
    输入用户名和密码,按“登陆”按钮。
    用户名=xxx,密码=1
    显示警告信息“请输入用户名和密码!”
    5
    输入用户名和密码,按“登陆”按钮。
    用户名=xxx,密码=2
    显示警告信息“请输入用户名和密码!”
    6
    输入用户名和密码,按“登陆”按钮。
    用户名=空,密码=空
    显示警告信息“请输入用户名和密码!”
    7
    输入用户名和密码,按“登陆”按钮。
    用户名=yiyh,密码=1
    进入系统页面。
    8
    输入用户名和密码,按“登陆”按钮。
    用户名=Admin,密码=admin
    进入系统维护页面。
    9
    输入用户名和密码,按“登陆”按钮。
    用户名=yiyh',密码=1
    显示警告信息“请输入用户名和密码!”
    10 输入用户名和密码,按“登陆”按钮。
    用户名=yiyh,密码=1'
    显示警告信息“请输入用户名和密码!”
    11 输入用户名和密码,按“重置”按钮。 用户名=yiyh,密码=1 清空输入信息
    测试人员 开发人员 项目负责人


    备注:本用例未考虑“企业代码”的输入情况;测试用例并未涵盖所有的非法输入,如非法输入中可能会有

    “user=*,pw=*”的组合,对回车的默认操作,空格输入,对输入上溢的处理的处理(可能会跳过身份验证) 等等。

    如果你有兴趣,至少可以再补充5-10条左右的输入组合

    (当然,如果步骤超过15步,用例的易操作 性就降低,你可以再创建一个测试用例如TC-TEP_Login_2)。

  • Bug管理的一般流程

    2007-03-15 14:53:09

    Bug管理的一般流程

    文章出处:本地化测试网 作者:崔启亮 发布时间:2006-03-08

     

         软件测试的主要目的在于发现软件存在的错误(Bug),对于如何处理测试中发现的错误,

     

    将直接影响到测试的效果。只有正确、迅速、准确地处理这些错误,才能消除软件错误,保证

     

    要发布的软件符合需求设计的目标。在实际软件测试过程中,对于每个Bug都要经过测试、确

     

    认、修复、验证等的管理过程,这是软件测试的重要环节。

     

    错误跟踪管理系统

     

        为了正确跟踪每个软件错误的处理过程,通常将软件测试发现的每个错误作为一条条记录

     

    输入制定的错误跟踪管理系统。

     

        目前已有的缺陷跟踪管理软件包括Compuware公司的TrackRecord软件(商业软件)、

     

    Mozilla公司的Buzilla软件(免费软件),以及国内的微创公司的BMS软件,这些软件在功能

     

    上各有特点,可以根据实际情况选用。当然,也可以自己开发缺陷跟踪软件,例如基于Notes

     

    或是ClearQuese开发缺陷跟踪管理软件。

     

        作为一个缺陷跟踪管理系统,需要正确设计每个错误的包含信息的字段内容和记录错误的

     

    处理信息的全部内容。字段内容可能包括测试软件名称,测试版本号,测试人名称,测试事

     

    件,测试软件和硬件配置环境,发现软件错误的类型,错误的严重等级,详细步骤,必要的附

     

    图,测试注释。处理信息包括处理者姓名,处理时间,处理步骤,错误记录的当前状态。

     

    正确的数据库权限管理是错误跟踪管理系统的重要考虑要素,一般要保证对于添加的错误

     

    不能从数据库中删除。

     

    软件错误的状态

     

    新信息(New):测试中新报告的软件缺陷;

     

    打开 (Open):被确认并分配给相关开发人员处理;

     

    修正(Fixed):开发人员已完成修正,等待测试人员验证;

     

    拒绝(Declined):拒绝修改缺陷;

     

    延期(Deferred): 不在当前版本修复的错误,下一版修复

     

    关闭(Closed):错误已被修复;

     

    Bug管理的一般流程

     

        测试人员提交新的Bug入库,错误状态为New

     

        高级测试人员验证错误,如果确认是错误,分配给相应的开发人员,设置状态为Open。如果不是错误,则拒绝,设置为Declined状态。

     

        开发人员查询状态为OpenBug,如果不是错误,则置状态为Declined;如果是Bug则修复并置状态为Fixed。不能解决的Bug,要留下文字说明及保持BugOpen状态。

     

        对于不能解决和延期解决的Bug,不能由开发人员自己决定,一般要通过某种会议(评审会)通过才能认可。

     

        测试人员查询状态为FixedBug,然后验证Bug是否已解决,如解决置Bug的状态为

     

    Closed,如没有解决置状态为Reopen

     

    软件错误流程管理要点

     

        为了保证错误的正确性,需要有丰富测试经验的测试人员验证发现的错误是否是真正的错误,书写的测试步骤是否准确,可以重复。

     

        每次对错误的处理都要保留处理信息,包括处理姓名,时间,处理方法,处理意见,Bug状态。

     

        拒绝或延期错误不能由程序员单方面决定,应该由项目经理,测试经理和设计经理共同决定。

     

        错误修复后必须由报告错误的测试人员验证后,确认已经修复,才能关闭错误。

     

        加强测试人员与程序员的交流,对于某些不能重复的错误,可以请测试人员补充详细的测试步骤和方法以及必要的测试用例。 

  • Bugzilla使用指南

    2007-03-15 14:43:54

    Bugzilla使用指南

     

    文章出处:不详 作者:不详 发布时间:2005-10-30

     

     


     绪言

    什么是Bugzilla

    Bugzilla是一个错误跟踪系统,用于对软件产品程序开发过程的错误跟踪。它的强大功能表现在以下几个方面:

    1.         强大的检索功能

    2.         用户可配置的通过Email公布Bug变更

    3.         历史变更记录

    4.         通过跟踪和描述处理Bug

    5.         附件管理

    6.         完备的产品分类方案和细致的安全策略

    7.         安全的审核机制

    8.         强大的后端数据库支持

    9.         WebXmlEmail和控制界面

    10.     友好的网络用户界面

    11.     丰富多样的配置设定

    12.     版本间向下兼容

    为什么使用Bugzilla

    Bugzilla是一个拥有强大功能的错误跟踪系统。它可以使我们更好的在软件开发过程中跟踪软件错误的处理过程,为开发和测试工作以及产品质量的度量提供数据支持,从而有效的保证软件产品的质量。

     

    Bugzilla使用指南

    新建一个Bugzilla账号

    1.       点击“Open a new Bugzilla account”链接,输入你的Email地址(如:XXX@office)然后点击“Create Account”。

    2.       稍候,你会收到一封邮件。邮件中包含你的登录账号(与你的Email相同)和口令,这个口令时Bugzilla系统随机生成的,你可以根据你的需要进行变更。

    3.         在页面的黄色页角中点击“Log In”链接,而后输入你的账号和口令。最后点击“Login

    产品和结构(Product and Component)

    Bug记录按产品分类,每种产品按功能拆分成几类。以Bugzilla产品为例,它由以下几部分构成:

    l          Administration

    l          Bugzilla-General

    l          Creating/Changing Bug

    l          Documentation

    l          Email

    l          Installation

    l          Query/Buglist

    l          Reporting/Charting

    l          User Accounts

    l          Changing Passwords

    l          User Interface

    Bug报告状态分类和Bug处理意见(Status and Resolution):

    1.       Bug报告状态分类(Status)

    l          待确认的(Unconfirmed)

    l          新提交的(New)

    l          已分配的(Assigned)

    l          问题未解决的(Reopened)

    l          待返测的(Resolved)

    l          待归档的(Verified)

    l          已归档的(Closed)

    2.       Bug处理意见(Resolution)

    l          已修改的(Fixed)

    l          不是问题(Nvalid)

    l          无法修改(Wontfix)

    l          以后版本解决(Later)

    l          保留(Remind)

    l          重复(Duplicate)

    l          无法重现(Worksforme)

    指定处理人(Assigned To)

    l          可以指定一个处理人

    l          如不指定处理人,则系统指定管理员为默认处理人

    超链接(URL)

    l          输入超链接地址,引导处理人找到与报告相关联的信息

    概述(Summary)

    l          概述部分“Summary”的描述,应保证处理人在阅读时能够清楚提交者在进行什么操作的时候发现了什么问题。

    l          如果是通用组件部分的测试,则必须将这一通用组件对应的功能名称写入概述中,以便今后查询。

    硬件平台和操作系统(Platform and OS)(0perating System)

    l          测试应用的硬件平台(Platform),通常选择“PC”

    l          测试应用的操作系统平台(OS)

    版本(Version)

    l          产生Bug的软件版本

    Bug报告优先级(Priority)

    l          分五个等级即P1-P5,P1的优先级别最高之后逐级递减

    Bug状态(Severity)

    l          Blocker,阻碍开发和/或测试工作

    l          Critical,死机,丢失数据,内存溢出

    l          Major,较大的功能缺陷

    l          Normal,普通的功能缺陷

    l          Minor,较轻的功能缺陷

    l          Trivial,产品外观上的问题或一些不影响使用的小毛病,如菜单或对话框中的文字拼写或字体问题等等

    l          Enhancement,建议或意见

    报告人(Reporter)

    l          Bug报告提交者的账号

    邮件抄送列表(CC List)

    l          Bug报告抄送对象,该项可以不填

    l          如需要抄送多人,可将邮件地址用“,”分隔

    从属关系(Bug “ID” 查看(406) 评论(0) 收藏 分享 管理

  • 软件错误跟踪处理流程

    2007-03-15 12:36:36

     
      UML软件工程组织

    软件错误跟踪处理流程

     

    作者:不详  来源:网络

     

    大型本地化软件测试需要进行充分的测试准备,需要科学的测试流程管理。为了跟踪和控制测试质量,便于管理测试发现的Bug,需要为每一个测试项目配置一个专用缺陷跟踪数据库,以便报告、查询、分类、跟踪、处理和验证错误。

    为了保证发现和报告的错误质量,需要首先由经验丰富的测试人员,在缺陷跟踪数据库中对新发现的错误进行确认,如果确实属于错误,再由错误修复工程师进行修复处理。

    1、软件错误的状态

    新错误(New):测试中新报告的软件缺陷。 更多新信息(New More Info):错误修复工程师认为报告的错误信息不完整,要求错误报告者添加更准确的错误信息。 打开 (Open):错误被确认并分配给相关错误修复工程师处理。 拒绝(Declined):拒绝修改缺陷。包括两种情况: 拒绝-不是错误(Declined-Not Bug):报告的错误不术语错误。 拒绝-重复(Declined-Duplicated):以前已经报告过这个错误,需要指出已经报告过的错误标识编号。 修正(Fixed):错误修复工程师已完成修正,等待测试人员验证。 重新打开(Reopen):没有正确修复的错误,需要进一步修复。 延期(Deferred):不在当前版本修复的错误,以后的版本修复。包括两种情况: 延期-下个版本(Deferred –Next Build):本项目的下一个新版本修复。 延期-下个主要版本(Deferred –Next Main Release):本项目不修复,本软件下一个项目的版本修复。 关闭(Closed):错误已被修复。  

     2、Bug管理的一般流程

    测试人员提交新的错误入库,错误状态为New。

    高级测试人员验证错误,如果是重复报告的错误,则设置为Declined-Duplicated状态,并指出与哪个已经报个错误重复(注明标识编号ID#)。否则,如果确认是错误,分配给相应的修复工程师,设置状态为Open。如果不是错误,则拒绝,设置为Declined-Not Bug状态。

    错误修复工程师查询状态为Open的错误,如果因为错误的信息不完全,没法重现错误,则设置状态为New More Info;如果不是错误,则设置状态为Declined-Not Bug;如果是错误则修复,设置状态为Fixed。对于当前版本不能解决,准备本项目的下一个新版本处理的错误,要留下处理注释,设置错误为Deferred –Next Build状态。如果只能在软件的下个新项目才能解决,要留下处理注释,设置错误为Deferred –Next Main Release状态。

    对于不能解决和延期解决的错误,不能由软件修复工程师自己决定,一般要通过某种会议(评审会)通过才能认可。

    测试人员查询状态为Fixed的错误,然后验证错误是否已修复,如果已经修复,设置错误的状态为Closed,如没有解决置状态为Reopen。

    下面以一个错误的处理过程为例,给出一般的处理流程图。



     3、软件错误流程管理要点

    为了保证错误的正确性,需要有丰富测试经验的测试人员验证和确认发现的错误是否是真正的错误,测试步骤是否准确、简洁、可以重复。 软件错误的确认并不总是轻而易举的事情。由于对软件设计具体要求的不了解,对测试报告的个别软件错误,可能无法确认是否属于真正的软件错误,本地化服务商需要与软件供应商交流并确认。 每次对错误的处理都要保留处理信息,包括处理者姓名,时间,处理方法,处理步骤,错误状态,处理注释等。 对错误的拒绝不能由程序员单方面决定,应该由项目经理,测试经理和设计经理共同决定。 对错误延期处理不能由本地户服务商决定,应该由软件供应商决定。 错误修复后必须由报告错误的测试人员验证后,确认已经修复,才能关闭错误。

     


    版权所有:UML软件工程组织

     UML
    软件工程组织

    软件错误跟踪处理流程

     

    作者:不详  来源:网络

     

    大型本地化软件测试需要进行充分的测试准备,需要科学的测试流程管理。为了跟踪和控制测试质量,便于管理测试发现的Bug,需要为每一个测试项目配置一个专用缺陷跟踪数据库,以便报告、查询、分类、跟踪、处理和验证错误。

    为了保证发现和报告的错误质量,需要首先由经验丰富的测试人员,在缺陷跟踪数据库中对新发现的错误进行确认,如果确实属于错误,再由错误修复工程师进行修复处理。

    1、软件错误的状态

    新错误(New):测试中新报告的软件缺陷。 更多新信息(New More Info):错误修复工程师认为报告的错误信息不完整,要求错误报告者添加更准确的错误信息。 打开 (Open):错误被确认并分配给相关错误修复工程师处理。 拒绝(Declined):拒绝修改缺陷。包括两种情况: 拒绝-不是错误(Declined-Not Bug):报告的错误不术语错误。 拒绝-重复(Declined-Duplicated):以前已经报告过这个错误,需要指出已经报告过的错误标识编号。 修正(Fixed):错误修复工程师已完成修正,等待测试人员验证。 重新打开(Reopen):没有正确修复的错误,需要进一步修复。 延期(Deferred):不在当前版本修复的错误,以后的版本修复。包括两种情况: 延期-下个版本(Deferred –Next Build):本项目的下一个新版本修复。 延期-下个主要版本(Deferred –Next Main Release):本项目不修复,本软件下一个项目的版本修复。 关闭(Closed):错误已被修复。  

     2、Bug管理的一般流程

    测试人员提交新的错误入库,错误状态为New。

    高级测试人员验证错误,如果是重复报告的错误,则设置为Declined-Duplicated状态,并指出与哪个已经报个错误重复(注明标识编号ID#)。否则,如果确认是错误,分配给相应的修复工程师,设置状态为Open。如果不是错误,则拒绝,设置为Declined-Not Bug状态。

    错误修复工程师查询状态为Open的错误,如果因为错误的信息不完全,没法重现错误,则设置状态为New More Info;如果不是错误,则设置状态为Declined-Not Bug;如果是错误则修复,设置状态为Fixed。对于当前版本不能解决,准备本项目的下一个新版本处理的错误,要留下处理注释,设置错误为Deferred –Next Build状态。如果只能在软件的下个新项目才能解决,要留下处理注释,设置错误为Deferred –Next Main Release状态。

    对于不能解决和延期解决的错误,不能由软件修复工程师自己决定,一般要通过某种会议(评审会)通过才能认可。

    测试人员查询状态为Fixed的错误,然后验证错误是否已修复,如果已经修复,设置错误的状态为Closed,如没有解决置状态为Reopen。

    下面以一个错误的处理过程为例,给出一般的处理流程图。



     3、软件错误流程管理要点

    为了保证错误的正确性,需要有丰富测试经验的测试人员验证和确认发现的错误是否是真正的错误,测试步骤是否准确、简洁、可以重复。 软件错误的确认并不总是轻而易举的事情。由于对软件设计具体要求的不了解,对测试报告的个别软件错误,可能无法确认是否属于真正的软件错误,本地化服务商需要与软件供应商交流并确认。 每次对错误的处理都要保留处理信息,包括处理者姓名,时间,处理方法,处理步骤,错误状态,处理注释等。 对错误的拒绝不能由程序员单方面决定,应该由项目经理,测试经理和设计经理共同决定。 对错误延期处理不能由本地户服务商决定,应该由软件供应商决定。 错误修复后必须由报告错误的测试人员验证后,确认已经修复,才能关闭错误。

     


    版权所有:UML软件工程组织

  • 251/212>