心动不如行动,行动才会梦想成真!

发布新日志

  • 评审用例的重要性

    2007-12-18 13:08:03

              现在测试的一个patch,目前已经build005了,一个小patch就要重新打包5次,可想若是一个大的项目得打多少包,测试人员又得测试多少遍啊。
              什么都是有原因的,从中得出的教训是该patch包没有严格按照测试流程走。由于是个patch,项目管理提交的需求文档不全面,部分测试用例是根据项目管理及开发负责人的口头阐述编写的,而测试用例评审时开发负责人及项目经理没有参加,只是测试人员和开发人员的参与,现在才知道测试的用例和客户的需求是相违背的,还有多余的用例,种种原因造成了一次又一次的重新打包。我觉得流程问题很值得注意,再就是即使是patch包,项目管理、开发部、测试部都要严格按照测试流程走,不要因为是patch包就不重视。希望同行软测人员加强重视测试流程,避免造成人力、物力资源的浪费,更重要的是影响产品的质量。
  • 三级未过的必然性!

    2007-12-18 09:47:58

               三级没有考试过,不是偶然的。
               原因:一是毕业一年半,然而在这一年半里,自己把英语给抛弃了,之前学的英语知识也还给老师了;二是考试前没有准备,如买本英语资料多做题;三是态度不端正,没重视此次考试!
               没考过不可怕,但只要善于总结经验教训,是很宝贵的!从现在就开始学英语,积累工作中生活中遇到的每个单词,我不信这个邪,下次会不及格才怪!

  • 读《实用软件测试过程》有感

    2007-12-12 16:17:03

    阅读完本书,让我对整个测试过程有所了解,虽然介绍测试的每一部分比较粗略,但知识点覆盖的很多,介绍的方面也比较全,很多是平时自己测试时碰到的但没有系统化的东西,看过后才恍然醒悟。如:肯定、否定测试,等价类划分,边界值分析,错误猜测,线索测试等等。

     

    软件测试是保证软件质量的重要活动,是软件项目实施不可缺少的环节,软件测试直接目的是发现软件中存在的缺陷。对一个给定系统进行充分的测试以确定其没有bug是不可能实现的,是可望而不可及的一个目标,但测试有其最高境界:在于运用最简单的有效的测试技术,最大限度地发现软件中的bug

     

    结合本书及自己对测试流程的理解,现总结一个项目的整个测试流程概述如下:

    1.根据软件详细设计文档,测试组长制定测试计划

    2.审核制定的测试计划

    3.根据测试计划设计,设计测试用例,编写测试用例

    4.相关开发人员和测试人员审核测试用例(此阶段可减少很多测试中遇到需求不明白的去询问开发人员)

    5.开发人员提供测试版本,以及相应版本所作修改的文档描述

    6.测试人员根据测试用例和测试工具执行测试

    7.记录测试结果,提交BUG给开发人员

    8.开发人员修改后,提供新的测试版本,测试人员重新测试

    9.测试人员验证后的bug,有测试组长审核后,BUG关闭

    10.提交测试报告

     

    原则上,测试人员对需求了解的越深入,对测试工作越有利,所以最好一开始就应该参加需求分析工作。在编写功能测试用例时也应有验证手段,“预期输出”不仅仅描述为程序的可见行为。其实,“预期结果”的含义并不只是程序的可见行为。例如:模拟boss操作,输入用户手机号,点击go,系统提示“操作成功”,boss开户是否成功还需要查看相应的数据记录是否更新,因此,在这样的一个用例中,还应该包含对测试结果的显示验证手段:在数据库中执行查询语句进行查询,看查询结果是否与预期的结果一致。

     

    测试的四个测试阶段:单元测试,集成测试,系统测试,验收测试。集成测试及其后的测试阶段,一般采用黑盒方法。

     

    其策略包括:1.等价类划分法及边界值分析法提出基本的测试用例;2.用猜测法补充新的测试用例;3.如果在程序的功能说明中含有输入条件的组合,宜在一开始就用因果图法。结合自己的理解下面说一下黑盒测试的测试用例设计方法:等价类划分、边界值分析、错误猜测。

    1.等价类划分法:等价类划分方法是把所有可能的输入数据,即程序的输入域划分成若干子集,然后从每一个子集中选取少数具有代表性的数据作为测试用例。该方法是一种重要的、常用的黑盒测试用例设计方法。等价类:等价类是指某个输入域的子集合。在该子集合中,各个输入数据对于揭露程序中的错误都是等效的。并合理地假定,测试某等价类的代表值就等于对这一类其它值的测试。因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据。取得较好的测试结果。等价类划分可有两种不同的情况:有效等价类和无效等价类。有效等价类:是指对于程序的规格说明来说是合理的,有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。无效等价类:与有效等价类的定义恰巧相反。 设计测试用例时,要同时考虑这两种等价类。因为,软件不仅要能接收合理的数据,也要能经受意外的考验。这样的测试才能确保软件具有更高的可靠性。

    2.边界值分析法:从测试工作经验,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例,可以查出更多的错误。使用边界值分析方法设计测试用例,首先应确定边界情况。通常输入和输出等价类的边界,就是应着重测试的边界情况。应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据。

    3.错误推测法:基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性的设计测试用例的方法。错误推测方法的基本思想:列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例。

     

    以上的测试技术,在编写测试用例,或者是在一些意外的情况下,如需求的变更、设计的修改、需求的错误和遗漏等要及时变更完善测试用例,都可以涉及到。通过最近的界面功能测试,总结出以下几点常用模块的测试点:

    一、文本框的测试:

    1.       输入正常的汉字、字母、数字

    2.       输入超长信息(汉字、字母、数字、特殊字符)

    3.       输入默认值,空格、空白

    4.       若只允许输入字母,尝试输入汉字、数字,反之亦然

    5.       利用复制、粘贴等操作强制输入程序不允许的输入数据

    6.       输入已存在的文件名称,不存在的文件名称,错误的文件名称,文件大小为零

    7.       输入特殊字符集如:NUL\n_%(后两个查询时特别注意)

    8.       输入不符合格式的数据,如:年月日的格式

    9.       页面返回是否正常,显示页面信息是否正确,(各字段及值与数据库中的值比较)

    10.   验证密码是否区分大小写,是否隐藏显示

    11.   在一些界面中多次出现的字段名称,查看字段名是否一致

    12.   在一些需要命名且名字要求唯一时,输入重复的名字,看系统是否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理

    13.   检查添加和修改是否一致:检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填;添加规定为整型的项,修改也必须为整型。

    14.   检查修改重名:修改时把不能重名的项改为已存在的内容,看是否报错

    15.   重复提交表单:一条已经成功提交的纪录,back后再提交,看系统是否做了处理

    16.   必填项在后面用*表示:查看同一个页面中的必填项是否都加了*,其中某些为空是否报错

    二、下拉列表框测试:

    1.       条目内容是否正确,其详细条目可以根据需求说明确定

    2.       每个条目功能的记录和等于查询全部时的记录数(在需求允许的情况下)

    3.       每个条目字段不得重复

    4.       一组条目不能同时选中,只能选择一个,且不能为空

    5.       逐一执行每个条目的功能,分别选择后查询出的数据与数据库中的字段值是否一致

    6.       下拉列表框不选值的时候是否提供默认值

    三、添加测试:
    1.要添加的数据项均合理,检查数据库中是否添加了相应的数据
    2.留出一个必填数据为空
    3.按照边界值等价类设计测试用例的原则设计其他输入项的测试用例
    4.不符合要求的地方要有错误提示
    5.enter是否能保存
    6.若提示不能保存,查看数据库里是否多了一条数据

    7.提交后再点击取消,也要查看数据库里是否多了一条数据

    四、删除测试:

    1.选择记录后点击删除按钮要有提示:“确定要删除吗?”

    2删除一个数据库中存在的数据,然后查看数据库中是否删除

    3.点击删除后再点击取消,然后查看数据库中的数据是否删除

    4.需要考虑删除的关联性,即删除某一个内容的同时删除其关联的某些内容
    五、查询测试:
    精确查询:
    1.输入的查询条件为数据库中存在的数据,看是否能正确地查出相应的数据
    2.输入正确的查询条件之前加上空格,看是否能正确地查出相应的数据
    3.输入格式或范围不符合要求的数据,看是否有错误提示
    4.输入数据库中不存在的数据,看系统是否做了处理
    5.不输入任何数据,(查询出全部数据还是零条记录)

    6.在一些多个字段进行查询,进行综合查询是否能查询出相应的信息
    模糊查询:
    在精确查询的基础上加上一点
    1.输入字段值的部分字符,看是否能查询出包含该字符的所有相关信息

    2.输入特殊字符,如:%_ ,看系统是否能查询出相应的信息

    3.在一些多个字段进行查询,进行综合查询是否能查询出相应的信息

     

    阅读完本书的最大感受是越来越感觉自己对软件测试理解得越肤浅,而需要掌握的测试知识还很多很多。

  • 培训策略技巧---经验分享

    2007-12-07 13:37:11

    如果一次培训结束之后,没有热烈的掌声,那这次培训就很失败!

    最近我不得不开始怀疑自己、反省自己:

    “这到底是怎么啦?”

    “我到底是哪里做错了?”
    ……………………

    于是我将问题转向并集中在了下列方面:

    我培训的内容是不是听众所迫切需要的?

    我培训的方式、方法是否被听众喜欢?

    我培训时的语气、语速等等是否被听众所接受?
    ……………………

    我终于恍然大悟,像我一样来自底层充满希望进行培训的不在少数,要把一件事情做的完美,不是那么简单、容易的事情!

    因此要做好一次培训,总结如下:

    一、培训资料的搜集与整理
      原则:复杂的东西简单化,简单的东西实用化
      1、 资料搜集(各种媒介、网上摘要、工作经验、请教类似的专业人士)
      3、 培训时间的长短把握(最好在培训教材上注明)
      4、 优化培训教材(多站在听众的角度来考虑,培训之前先简单阐述一下该次培训的主要原因、内容、目的)
      5、 换位思考,多站在听众的角度上考虑问题
      6、 说话不要过于主观,特别是不要武断,要保持中立
      7、 初步了解学员的组构,有针对性的准备一些相关的资料

      二、如何提高与达到讲课的实效
      原则:版书数据化、用词专业化、书写简易化、讲课通俗化(用标准的普通话,忌用别字,讲课时说话要比平时略大声一点)
      1、 培训前的气氛调整(如借用课堂的布置、当天的天气、也可利用自己的名字、借用赞美听众们坐姿规范或精神来调整课堂氛围)
      2、 把当次要讲的主要内容版书出来(最好用通俗易懂,一目了然的方式体现出来)
      3、 学会用讲故事的方法来解释及描述
      4、 相互学习及归零的培训法
      5、 不挑剔听众,不另眼看待听众,听众在你眼里都是最优秀的
      6、 语速、语调的规范(每分钟约40个字,切忌不宜太快了,否则培训结束后听众还一头雾水,那你此次培训肯定完了)
      7、 利用自己的特长,结合听众的实际临场发挥
      8、 经验分享(自己成长的过程及历史)
      9、 引用一些名人及名事来引起听众的认同
      10、 在说话与发表自己的观点时,保持中立及多角度的来分析看待
      11、 说话不要过于主观,更不能武断的下定义
      12、 换位思考,多站在听众的角度上考虑他们的承受力

      三、如何规避一些不良习惯
      1、讲师常犯的口误例:
      你我他
      你们/我们
      据我所知
      “知足”与“满足”
      2、讲师常犯的举措
      手指指点点
      站立不端正
      3、讲师一些不良习惯
      例:尾音/噢之类
      这个吗
      一句重复的说
      不乱模仿他人的种种习惯

      四、如何与听众现场互动
      原则:先要求自己用心讲课,发自内心的来参与,目的是让听众主动参与
      1、 培训过程中善于穿插幽默、笑话
      2、 用一些名人、名事作案例来引起听众的共鸣

      五、完善培训教材,为下一次培训补充新的血液
      原则:在于及时与坚持
      1、 在讲课时有些不完善的地方要及时加以补充(当时和课后补充)
      2、 采用填表的方式对听众做一个培训内容及讲师讲课技巧的跟进调查
      3、 培训之后与一些听众进行交流 (有则改之、无则加勉)
      4、 培训之后要回忆自己讲课时的情景,从中找出优缺点,再进一步的完善培训教材及培训方式

    从哪儿跌倒,再从哪儿爬起

    不能被同一个石头绊倒两次

    期盼下次培训不会很糟糕


     

数据统计

  • 访问量: 7325
  • 日志数: 13
  • 图片数: 1
  • 建立时间: 2007-11-06
  • 更新时间: 2008-03-03

RSS订阅

Open Toolbar