实习日记

上一篇 / 下一篇  2009-06-19 15:08:58

 

   这是自己08年6月写的实习日记,虽然上面有很多也是从网上找的相关东东。

   不过发表上来,以后也看看自己的测试历程吧。在51上面潜水了好一段时间了,以后也要慢慢记录和监督自己的学习了。

  

实习报告

学生:XXX      

学号:120041101107

系别:计算机科学系

专业:计算机科学与技术

实习单位:XXXXXX软件技术有限公司   

实习岗位:软件测试

实习时间:2008-3-10~2008-6-10

 

  我在XXXX软件技术有限公司的实习期间,学到了很多书本上学不到的东西。在经历了公司041905100614版本之后,在经理和老员工的帮助下,我对软件测试这个行业有了全新的认识。

  我们公司的测试项目是中国XXXX的XXX系统,简称XXX。公司的测试组分为性能测试组,业务测试组,自动化测试组,运行维护组。我在业务测试组里,所作的测试类型也可以称为功能测试黑盒测试

  由于测试的是银行的系统,我们在测试之前必须要有大量的银行的知识。所以,刚到公司的两个礼拜就被安排到楼上去学习。通过学习,我对银行的各项业务性质,申报流程等有了初步的认识。

   软件测试的目的:

  1、测试的最终目的是为了避免错误的发生,确保应用程序能够正常高效的运行;

  2、好的测试用例在于发现至今未发现的错误;

  3、成功的测试是发现了至今未发现的错误的测试;

  4、好的测试工程师应该做到不仅发现问题,还能够帮助开发人员分析问题;

  软件测试的原则:

  1、应把“尽早和不断地进行软件测试”作为软件开发者的座右铭,实践证明单元测试能够尽早发现问题,减少后期测试的错误量。可以采用JunitJtest来辅助进行单元测试。

  2、测试用例应由测试输入数据、测试执行步骤和与之对应的预期输出结果三部分组成。

  3、应当避免由程序员检查自己的程序。(指后期系统测试阶段,不包括单元测试)

  4、测试用例的设计要确保能覆盖所有可能路径。在设计测试用例时,应当包括合理的输入条件和不合理的输入条件。不合理的输入条件是指异常的,临界的,可能引起问题的输入条件。

  5、充分注意测试中的群集现象。经验表明,测试后程序残存的错误数目与该程序中已发现的错误数目或检错率成正比。应该对错误群集的程序段进行重点测试。

  6、严格执行测试计划,排除测试的随意性。

  测试计划应包括:所测软件的功能,输入和输出,测试内容,各项测试的进度安排,资源要求,测试资料,测试工具,测试用例的选择,测试的控制方法和过程,系统的配置方式,跟踪规则,调试规则,以及回归测试的规定等等以及评价标准。

  7、应当对每一个测试结果做全面的检查。 

  8、妥善保存测试计划,测试用例,出错统计和最终分析报告,为维护提供方便。

  软件测试的对象:

  软件测试并不单纯等同于程序测试。软件测试应该贯穿整个软件定义与开发整个期间。因此需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档,包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序,都应该是软件测试(评审)的对象。

在对需求理解与表达的正确性、设计与表达的正确性、实现的正确性以及运行的正确性的验证中,任何一个环节发生了问题都可能在软件测试中表现出来

测试的类型有:功能测试,性能测试,界面测试。
  功能测试在测试工作中占的比例最大,功能测试也叫黑盒测试。是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时,需要测试软件产品的功能,不需测试软件产品的内部结构和处理过程。采用黑盒技术设计测试用例的方法有:等价类划分、边界值分析、错误推测、因果图和综合策略。
  性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试,两者可以结合进行。通过负载测试,确定在各种工作负载下系统的性能,目标是测试当负载逐渐增加时,系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点,来获得系统能提供的最大服务级别的测试。

界面测试,界面是软件与用户交互的最直接的层,界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作,起到向导的作用。同时界面如同人的面孔,具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉,相反由于界面设计的失败,让用户有挫败感,再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。

  区别在于,功能测试关注产品的所有功能上,要考虑到每个细节功能,每个可能存在的功能问题。性能测试主要关注于产品整体的多用户并发下的稳定性和健壮性。界面测试更关注于用户体验上,用户使用该产品的时候是否易用,是否易懂,是否规范(快捷键之类的),是否美观(能否吸引用户的注意力),是否安全(尽量在前台避免用户无意输入无效的数据,当然考虑到体验性,不能太粗鲁的弹出警告)?做某个性能测试的时候,首先它可能是个功能点,首先要保证它的功能是没问题的,然后再考虑该功能点的性能测试

软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子,测试人员完全不考虑程序内部的逻辑结构和内部特性,只依据程序的需求规格说明书,检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下几类错误:
  1、是否有不正确或遗漏的功能?
  2、在接口上,输入是否能正确的接受?能否输出正确的结果?
  3、是否有数据结构错误或外部信息(例如数据文件)访问错误?
  4、性能上是否能够满足要求?
  5、是否有初始化或终止性错误?

在做功能测试的时候,我们经常用到这样几个方法,等价类划分,边界值分析法,错误推测法。

 1.等价类划分

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

  2.边界值分析法

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

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

3.错误推测法

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

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

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

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

以上就是我在XX公司里实习的学习和体会了。

 


TAG:

 

评分:0

我来说两句

日历

« 2024-05-28  
   1234
567891011
12131415161718
19202122232425
262728293031 

我的存档

数据统计

  • 访问量: 3872
  • 日志数: 1
  • 图片数: 1
  • 建立时间: 2009-06-19
  • 更新时间: 2009-06-19

RSS订阅

Open Toolbar