第一篇:第07章、正确理解软件测试(理论课)参考教案
注意事项:
关于软件测试和软件质量的关系,软件测试和软件工程的关系,以及软件工程和软件质量的关系,学员可能会觉得较难理解,要用通俗的语言和实际的案例进行讲解。 本次课程的内容以介绍测试实践经验为主,需要采用提问、举例和总结的方式进行授课。
PPT第1~5页:
回顾上一章内容,可以采用提问的方式;并简要介绍本章的学习目标。
PPT第6页:
内容进度页,向学员介绍本次课程的进度安排。
PPT第7~8页:
阐述尽早进行软件测试并把测试贯穿整个软件生命周期的原则。 首先提问学员,软件缺陷是在软件生命周期的什么阶段被引入到程序中的?并将学员的回答在白板上记录。然后进行总结,并引申阐述在各阶段都会引入什么样的错误。接下来承上启下地提出,不同阶段引入的缺陷对于软件的整个影响有什么不同?对测试的影响有什么不同?通过幻灯片8中的表格总结出软件测试应该尽早进行的结论。
通过幻灯片9中的图表,分析软件生命周期的不同阶段引入错误的多少是不同的,但是这些错误需要在后续的测试过程中逐渐发现,所以说软件测试在任何阶段都不能松懈,软件测试应该贯穿于整个软件生命周期。
PPT第9页:
说明软件测试应该追溯到需求的原则。首先通过装修房子的案例说明什么是需求,需求是用来约束产品的最终标准,然后阐述如下几个观点: 软件需求过程和需求说明书也是要测试的。
最终交付的产品必须满足需求说明书中的每一项,如果不能满足,必须以文档的形式列出来请客户方确认并同意。
如果软件测试过程中发生争议,将需求说明书作为标准来评判。 阐述测试应该由第三方构造的原则。可以从以下几个方面来说明程序设计者不应该测试自己的程序:
程序设计者一般只熟悉程序结构,不熟悉需求。
程序设计者不容易发现自己程序中存在的很多隐性问题。
有些程序设计者淡化自己程序缺陷的严重程度,影响了程序修复。
最后需要强调的是,以上观点只是对测试工作而言,强调测试团队组织的独立性。在实际的工作中,有时也是需要程序员进行测试的,比如单元测试工作,很多公司都是由程序员或系统设计员完成的。而其它测试的话,多数是由测试人员完成的,如果一个项目中实在没有单独的测试队伍的话,也应该让程序员相互进行测试,这样也比不进行测试要好得多,但是在测试之前,首先要进行相关知识的培训(如需求、测试方法和策略等)。
PPT第10页:
阐述测试是无法穷举的,测试者需要遵循Good-Enough的原则。首先通过第一堂课中的加法计算器的案例或者教材中电话号码系统的案例,说明对一个非常小的程序,想要进行穷举测试是非常麻烦的,当程序稍微复杂一些,比如Windows计算器中的加法运算,穷举测试几乎是不可能的。接下来讲述测试的“Good-Enough”原则。最后通过测试工作量和发现缺陷数量之间关系的图表说明,找到测试费用和测试量之间的平衡点,是最佳选择。
PPT第11页:
阐述测试前必须确定预期的输出结果的原则。通过教材中的四舍五入的例子说明,在测试之前如果不知道输出什么样的结果是正确的,就无法进行测试。提示学员在编写测试用例时,必须给出预期结果。
阐述测试完成后必须认真检查每个测试结果的原则。主要强调仔细检查缺陷报告的必要性,不能遗漏缺陷,遗漏缺陷会带来很大的危害。重复缺陷或相似缺陷很容易被遗漏,前面已经强调过,测试不是一个人完成的工作,需要测试组共同协作,最终完成产品的检测。但是多人测试就会带来一个问题,那就是重复缺陷报告和相似缺陷报告,测试时需要注意以下问题:
重复的缺陷描述可能属于不同的模块,要分别处理。 相似的缺陷报告很容易被作为重复的缺陷报告被剔除。
一个缺陷被两个人提交后,可能都认为是对方跟踪,结果谁都没有跟踪。 讲解必须充分关注测试过程中的群集现象,举例说明测试后发现缺陷最多的模块,其残留的错误也可能是最多(可以举一篮苹果中的坏苹果数目的例子说明群集现象)。
PPT第12页:
顺序介绍其他值得注意的规律和经验,时间允许的情况下,可以让学员进行讨论:在测试中,还有哪些规律需要注意?
PPT第13页:
根据实际授课情况,对“软件测试的原则”进行小结,回顾前面所讲的内容。
PPT第14页:
内容过渡页,做好知识点之间的过渡。
PPT第15页:
提问学员什么是软件,以及软件的特点是什么?从问答中引导学员回顾软件和软件程序的区别,接下来提问学员软件测试的对象是什么?根据学生的回答,引出软件测试不仅要测试软件程序是否运行正常,还需要测试软件的文档是否符合要求。然后引出评审的概念。
简要说明在“关于评审”中要介绍的知识点。
PPT第16~18页:
讲解评审的概念,评审主要是针对文档进行评审,但也包含对代码本身的评审。评审的方式是多种多样的,评审的次数和内容也可以根据项目具体制定,但是对开发各关键阶段涉及的一些文档的评审是必不可少的,那么,软件在开发各个阶段都会涉及到哪些文档呢? 提问学员回答后,切换到幻灯片17进行补充介绍:
对用户来说用户文档包括:用户手册、安装说明等等(如源代码也作为产品的一部分则还包括源代码)
对企业来说开发文档包括:源代码、需求分析、概要设计、详细设计、其他设计文档、业务建模、技术经验总结等等 对企业来说管理文档包括:开发过程的时间和人员安排计划、便于企业改进开发过程等等
文档对于软件产品的重要性是不言而喻的,它不仅仅是脑力劳动的输出,更重要的是经验重用和项目管理的手段,是走上工程之路的基础。这里强调文档的重要性是因为文档在测试和开发过程中经常被忽视或推迟完成。 最后通过幻灯片18说明评审工作的意义。
PPT第19页:
内容过渡页,做好知识点之间的过渡。
PPT第20~24页:
介绍软件测试和软件质量之间的关系。这部分内容从整体上包括层层深入的三个部分:
软件质量和软件过程:过程决定质量,软件过程决定软件质量。
软件质量的建立:软件质量是在软件开发过程中逐渐建立起来的。 过程与质量的关系:过程的质量直接影响软件的质量。 决定软件质量的关键因素:人员、技术和过程是决定软件质量的关键因素。 好的产品是怎样生产出来的:高质量的人员和好的过程应该得到好的产品。
软件测试和软件过程:软件测试是软件过程的一部分。
强调软件测试过程在整个软件生命周期中占有重要的位置。 软件测试和软件质量:软件测试是有效提高软件质量的技术手段。
提出问题:那么软件测试是不是软件质量保证的安全网呢?这里可以列举牛奶的生产过程进行说明:
如果把牛奶的生产过程比作软件生产过程的话,那么软件质量就相当于牛奶质量,软件测试相当于牛奶质量检测。牛奶质量检测只能测试当前的牛奶好坏,要提高牛奶质量必须改善生产牛奶的过程,从精选奶牛开始,每个步骤都要改进。
最后总结:只有坚持不懈的改进过程中的问题才是提高软件产品质量的根本出路,但是注意过程并不意味着忽视技术。软件质量不是依靠软件测试来保证的,软件质量需要靠不断的提高技术水平和改进软件开发过程来保证,正如牛奶的生产,如果把所有对质量的期望都压在对最后一道工序的质检上,那将是一个什么样的结果。
PPT第25页:
内容过渡页,做好知识点之间的过渡。
PPT第26页:
阐述“软件质量不是靠测出来的”这一观点。这部分内容在介绍软件测试和软件质量之间的关系时已经进行了详尽的阐述,这里作为正确理解软件测试的一个观点,可以提示学员如下的内容:
在实际的工作中不要把自己看作质量卫士,要能够明确自己的职责,以较好的心态对待软件测试。
测试人员作为软件的质量保证人员之一,要积极参与推行软件开发过程改进和软件测试过程改进,从根本上提高软件的质量。
阐述“软件测试人员需具备很多开发人员不具备的素质”这一观点。
可以从人们对“测试”这一行业的人员素质的错误认识谈起,比如:某些简单硬件(比如电话)生产厂家的测试人员,在流水线上对组装好的产品进行着简单的检测工作。这使人们心目中形成了一个印象,那就是,测试就是按照固定的流程进行简单操作。这些人相对于产品的设计者,是不需要很高深的知识的。他们只负责检测产品的某些功能是否正常,而不需要告诉设计人员是什么原因造成的。这是无所谓的,因为设计人员基本上可以从现象很快判断出问题出在哪里。
随着软件行业的发展,软件作为一个产品,也需要进行测试。但是一提起“软件测试”,有些人马上想到了那些流水线上的工人。实际上软件产品和硬件产品完全不同,需要的测试人员也不同。而那些流水线上的工人,连复杂一些的硬件产品(比如程控交换机)测试也是无法完成的。 现代软件的复杂程度的不断增加,对软件测试工作者的要求也越来越高,不是谁都可以做测试,在很多公司,对测试人员的水平要求已经超过了开发人员。 接下来提问学员,关于第一章中“软件测试人员需要具备的素质”的内容,然后对幻灯片中的内容进行详细的阐述,阐述时侧重与测试人员和开发人员所需技能的对比。
阐述“软件测试需要开发人员和测试人员共同努力”这一观点。我们提倡第三方来测试,提倡测试部门从项目组中独立出来,目的是保证进行客观公正的测试,但是这是否说明,开发和测试是完全独立,互不依赖的呢?可以从以下几个方面进行阐述:
测试和开发一个是破坏性的,一个是建设性的,正是不断的破坏和建设才能使软件更加稳定更加强大,要更快更好的完成这一过程,需要双方的配合和努力。 测试可以帮助开发人员更快的定位缺陷的位置和产生原因。 开发人员可以帮助测试人员优化缺陷。开发人员通过单步跟踪等方式对程序的检测可以节省很多测试工作量。
有些测试工作可能需要开发人员完成,如单元测试。
PPT第27页:
详细讲解软件测试的V模型,侧重于不同阶段的测试工作的对应,说明软件测试不是软件开发过程中的一个阶段,而是贯穿于整个软件生命周期。
PPT第28页:
根据实际授课情况,对“争取理解软件测试”进行小结,回顾前面所讲的内容。
PPT第29页:
内容过渡页,做好知识点之间的过渡。
PPT第30页: 讲解处理缺陷时需要注意的几个问题,包括如下几个观点:
注意缺陷报告的处理成本
对于大多数项目来说处理全部缺陷是不可能的。 对缺陷的处理本身也需要成本。 不可重现的缺陷如何处理。 修改缺陷要量力而行。
修改缺陷是有风险的。 修改缺陷也需要成本。 关注被推迟修改的缺陷
在一个版本中被推迟的缺陷,到了下一个版本可能优先级会有所变动。 使用缺陷跟踪工具,可能会帮助我们轻松完成这一工作。 如果决定据理力争就一定要赢
如果自己提交的报告存在争议,应该进行重新测试,如果确认自己的报告是正确的,可以收集更有说服力的资料,必要时采用会议的方式讨论。
PPT第31页:
对本次课程进行回顾总结,并利用剩下的时间回答学员的问题
课堂练习答案
一.填空题:
1.尽早地进行软件测试,并把软件测试贯穿于整个软件生命周期
软件测试应追溯需求、测试应由第三方来构造 穷举测试是不可能的,要遵循Good-enough原则 必须确定预期输出结果
必须彻底检查每个测试结果 充分注意测试中的群集现象 其他规律和经验:
二八定理
要严格执行测试计划,排除测试的随意性
测试的时候,既要注意合法合理的输入,也要注意非法的非预期的输入 检查程序是否做了应该做的同时,也要检查是否做了不该做的 测试应从“小规模”开始,逐步转向“大规模” 关注缺陷的修复
2.分析
设计
实现
80% 系统测试
发现错误
发现所有的错误 3.早期阶段
中间成果
最终成果 二.选择题:
1.ABC 2.ABCD
第二篇:第05章、软件测试流程和分类(理论课)参考教案
注意事项:
需要结合软件产品的整体研发流程来使学员熟悉软件测试流程,明确一个软件项目的不同阶段需要做的工作、输出哪些文档,特别是不同的阶段需要做哪些测试工作,重点要使学员掌握软件项目工作流程图。 关于软件测试的分类,内容比较多而且知识点比较细,这部分内容重在概念的理解,讲解时需要自己组织一些简单的案例,目的是让学员明白各种测试方法的概念和应用的场合,具体的实现不是本章的重点。
PPT第1~3页:
回顾上一章内容,可以采用提问的方式;并简要介绍本章的学习目标。
PPT第4页:
内容进度页,向学员介绍本次课程的进度安排。
PPT第5页:
介绍软件项目在需求阶段的工作流程。
首先介绍什么是需求分析,然后阐述需求调研和需求分析对一个软件项目的重要性,强调需求分析并不是与测试无关的工作,如果有条件,测试人员也应该参与需求调研和分析,这样有助于发现系统中很多隐含的缺陷。 接下来介绍软件需求阶段的工作流程,测试组在需求阶段需要完成的任务和提交的文档。让学员明白一个观点,需求分析过程不只是在项目开始完成以后就不再进行了,需求分析会贯穿整个项目周期,可能还包括系统维护阶段,这时需要引导学员回顾软件生命周期的螺旋模型。
PPT第6~12页:
让学员了解在需求阶段测试组都应该做哪些工作。
首先通过幻灯片6概要介绍需求阶段测试组制定测试计划和系统测试方案时重点考虑的问题,然后通过后面的幻灯片详细介绍。 在讲解各个条目的时候,最好和前面课程中的测试计划案例或模板对应,提示学员哪些项目需要以文字的形式体现在测试计划和系统测试方案中,哪些条目可以帮助我们理解产品和产品的实现过程,间接帮助实现测试文档。
PPT第13页:
介绍软件设计编码阶段需要完成哪些工作。流程图中涉及到“详细设计”和“概要设计”的概念,需要在此进行知识扩展,侧重于介绍详细设计和概要设计所涵盖的内容。需要提醒大家的是,而现在国内很多公司没有做详细设计,有些公司迫于项目进度的压力将详细设计和编码同步进行,或者在编码之后补充文档。这样就要求概要设计文档细致一些。 概要设计
在需求明确,有详细的《需求规格说明书》之后、就进入设计和编码阶段,这一阶段首先要做概要设计,目的是使整个软件开发工作可以协调有序地进行。
概要设计是编码阶段将软件系统需求转换为未来系统的设计的第一份文档,是项目小组今后共同作战的基础,概要设计的重点是考虑开发规范、系统构架、实施环境、系统性能和模块的分解和接口规范等。概要设计的成果是指导软件设计编码的《概要说明书》。
详细设计
详细设计是在概要设计的基础上实现的,详细设计着重描述每一模块是怎样实现的,包括实现算法、逻辑流程等。详细设计结束后会完成《详细设计说明书》,又可称为《程序设计说明书》。编制详细设计说明书的目的是向编码人员说明一个软件系统各个层次中的每一个程序(每个模块或子程序)的设计考虑,如果一个软件系统比较简单,层次很少,本文件可以不单独编写,有关内容合并入概要设计说明书。
接下来根据流程图介绍软件设计编码阶段的一般流程。这一阶段测试组的主要工作是完成产品的单元测试。
PPT第14页:
介绍在设计编码阶段测试组需要完成的测试工作。在概要设计完成以后,测试组就应该参照软件需求规格说明书和概要设计文件着手编写系统集成测试方案了,这里需要简要介绍集成测试的概念。在详细设计阶段完成以后,测试组需要以此为依据编写单元测试方案和单元测试用例。这里简要介绍单元测试的基本概念和作用。
PPT第15页:
介绍在系统集成和验收阶段测试组需要完成的测试工作。这一阶段80%的工作是测试活动,根据幻灯片中的流程图进行讲解。强调软件测试过程贯穿了整个软件的生命周期。
PPT第16页:
回顾整个软件生命周期中的测试活动。这里将测试活动从软件生命周期中摘出来,形成软件测试各阶段示意图,需要讲解每个测试阶段的具体工作和作用,以及每个阶段前后之间的顺序关系。
PPT第17~21页:
主要以概念为主,介绍不同测试阶段的特点和作用。依据幻灯片的顺序,参照教材阐述每个测试阶段的特点、需要进行的工作和所起的作用,注意区分集成测试、系统测试和验收测试的不同之处,让学员明白什么时候需要进行什么阶段的测试。这里涉及到确认测试、有效性测试和验收测试等学员首次接触的概念,需要重点讲解。
PPT第22页:
对软件测试流程的知识进行小结,提出接下来要讲解的内容。回顾前面所讲的软件项目总体过程和软件测试流程的知识,在回顾软件产品生产流程时可以讲解案例8-1,需要达到如下目标:
让学员了解一个大型项目的工作进度是如何组织与制定的。
让学员对将来工作的任务分配有一个感性的认识,明确工作任务流程的概念,作为项目组的一员,在实际的工作中是如何接受任务并执行的。 明确测试工作在整个项目过程中占据重要地位,测试是连接开发和用户之间的桥梁纽带。
接下来承上启下地提出,为了很好地完成前面各个阶段的测试工作,软件测试工程师和专家们总结了很多有用的经验、方法和技巧,接下来我们就介绍软件测试的分类和策略。
PPT第23页:
介绍软件测试分类的概述,说明对软件测试的分类从不同的角度有不同的分类方法,这里介绍其中的三种分类:按测试策略分类、按测试阶段分类、按测试方法分类,具体的内容在后面进行详细的介绍。
PPT第24页:
介绍静态测试和动态测试的概念。静态测试和动态测试具有明显的区别,就是是否运行程序。静态测试一般在编码结束后由程序员完成,可以发现程序中多数的缺陷。前面讲过的白盒测试和黑盒测试都属于动态测试的内容。介绍时侧重于两者的区别。
PPT第25页:
介绍黑盒测试和白盒测试概念,采用举例的方式说明,例如:
要测试汽车的车灯是否正常,如果用黑盒测试的方法,则打开开关看看对应的车灯是否打开,亮度是否正常;如果用白盒测试的方法,则检查线路是否连通,布线是否合理等。
要测试一个按考试分数划分学员等级的程序,假定考试分数为0~60、61~80、81~100时,分别代表不及格、及格和优秀三个级别,如果采用黑盒测试法,则选择有代表意义的分数(如0、60、50、61、72、80、81、93、100、101等)输入到程序中,看程序的输出结果是否正确就可以了;如果采用白盒测试法,则需要首先查看程序的代码或设计文档,了解程序的结构,然后选择具有代表意义的输入数据(如-3、43、74、94、150),运行程序,争取让程序的每个判断和分支语句都被覆盖一遍,以便发现程序的缺陷。
总结黑盒测试和白盒测试的概念,及其各自的优缺点,强调虽然黑盒和白盒两种测试策略可以相互补充,但是即使两种方法都采用了也不可能测试出程序中全部的缺陷。
PPT第26页:
介绍手工测试和自动测试的概念。手工测试不是一种测试方法,而是相对于自动测试而产生的一个概念,所谓手工测试就是不借助自动测试工具完成的测试,手动执行测试用例判断结果的过程。如果在测试过程中借助了被测程序之外的其他的系统来帮助检查或运行程序,就称之为自动测试。需要注意的是,自动测试工具可以是自行开发的,也可以是使用第三方的。在介绍自动测试的时候,侧重于以下几个方面:
为什么要使用工具。
例如我们需要在测试数据库的过程中逐条向数据库中输入一万条记录,如果没有自动测试工具,这种工作对于软件测试人员来讲简直就是一场噩梦。因此自动测试工具可以为我们省去许多繁杂的工作
自动测试相对手工测试具有一定的优势,人会因为疲劳出错,机器不会出现类似问题
自动测试还不具有普遍性 测试工具本身还不能满足所有的测试要求。 测试工具的复杂性制约了人们的使用。 有些测试工具是非常昂贵的。 不能唯工具论
PPT第27页:
介绍冒烟测试和回归测试的概念。
关于冒烟测试的概念,在第三章实践课时曾简单介绍过,在这里做正事的介绍。侧重于什么是冒烟测试和为什么要进行冒烟测试。冒烟测试的概念源于硬件测试,电路板插装完成后第一道测试工序是插电,插电后如果电路板出现冒烟现象,测试人员就拒绝进行下一步的测试。软件的冒烟测试是指,测试组拿到开发组提交的测试版本后,会首先对这一版本进行部分功能的测试,这种测试不用需要全部的测试人员参与,测试一般从两个方面入手: 验证此版本关键功能可以正常工作。 此版本修改的严重问题已经基本正常,同时在返测中没有发现修改缺陷可能引发的新缺陷。
然后根据测试的结果决定是否让其他的测试人员转到新版本进行测试。冒烟测试的目的是为了节省有限的测试时间和测试资源。如果新的版本不经过冒烟测试而直接发放到所有测试人员手中,那么一旦测试版本根本无法正常运行,那么会耽误所有测试人员的宝贵工作时间。例如:安装新系统可能需要卸掉旧系统,也可能需要重新搭建测试环境。冒烟测试可以通过自动测试工具辅助进行。 讲解回归测试的概念,然后分别举例阐述下面两个观点:
回归测试可以借助工具完成。列举Mercury公司的Winrunner或IBM公司Rational Robot等自动测试工具实现测试的过程,说明借助工具完成回归测试已经非常普遍。
回归测试是非常必要的,可以参考案例8-2,列举阿里亚娜5型火箭发射失败的例子来说明。
PPT第28页:
对按策略分类的测试类型进行小结,回顾前面的软件分类的知识点,每个测试类型用一两句话进行概括。
PPT第29页:
介绍按阶段进行的软件测试分类。单元测试、集成测试、系统测试的概念及每个阶段所作的工作在介绍软件测试流程的时候已经进行了讲解,这里侧重介绍每个阶段测试的对象、目的、测试依据和测试方法。
PPT第30页:
根据实际授课情况,有侧重地分别介绍每个测试方法。注意介绍测试方法之间的区别,如压力测试和负载测试的区别,界面测试和功能测试的区别等。由于学员没有进行过相应的操作,介绍时需要采用实际生活中的案例来做类比,尽可能通俗易懂。比如:讲解压力测试和负载测试时可以用载重汽车的案例来解释;讲恢复测试时,可以用SQL Server通过日志进行回滚的功能作为例子。
PPT第31页:
对本次课程进行回顾总结,并利用剩下的时间回答学员的问题。
课堂练习答案
一.填空题:
1.模块测试
最小
集成测试
单元测试
单元模块 2.集成测试
确认测试
有效性测试
软件配置审查
3.模拟的黑盒测试
需求规格说明书
测试计划
测试种类
测试用例
测试步骤
4.软件配置审查
人工审查
用户手册 5.确认测试
功能覆盖
6.用户
质量保证
设计测试用例
用户界面
实际数据
功能 兼容性
可维护性
二.填空题:
1.ABD 2.ABC
可移植性
第三篇:软件测试 心得体会
兰州直方科技有限公司
心得体会
如果要进步,那么就要尝试新的技术,新的思维,大胆的使用,在用的过程中肯定会学到新的东西。
加强团队内部的沟通,是解决团队内部分散的最好办法,如果一个团队没有很好沟通,那么这个团队就像是没有肥力的沙漠就没有竞争力,它的存在价值值得怀疑。但是加强团队建设是一件很不容易做到的事情,加入团队中有某一个成员技术很牛,就是搞独立,不按照游戏的规则,那么,作为项目小组的负责人,该如何去解决这个问题。我想在肯定他技术很牛的同时也应该让他明白如果只是将自己所做的模块做好,整个项目却是一般般,那么自己做好的那个模块就起不到任何的作用了。沟通,再沟通,直到他能很好的配合团队的工作,这样我相信我们的团队是一个有凝聚力、竞争力的团队,我们才能按时高质量的完成项目。
在这次的项目中,我们学到了很多。尤为深刻的体会是一个团队如果不能团结在一起,那么它就没有竞争。项目组之间要多交流一边更好的理解别人的思维、项目的进程来及时解决存在的问题以及计划的改进。要对自己准确定位知道自己能胜任什庅样的工作以及在那一方面最擅长可以做得很好。
很荣幸,在本次项目开发中,我个人承担项目小组长的角色,在项目进展过程中,非常感谢项目小组成员对我工作的支持,项目经理对我的信任。感谢在项目开发中,各位领导对项目进度的关注!谢谢!
兰州直方科技有限公司
第四篇:软件测试心得体会
心得体会
六天的培训结束了,感觉过得好快啊。虽然是因为参加“模拟招聘”获得这次机会的,不像其他同学一样是交钱的,但是我也是抱着要学东西的心态参加的。
第一天老师就给了个下马威——教材全是全是英文版的。对于虽然大三的我来说,英语四级刚过,六级成绩还没出来的情况下,想看懂全文是不太现实的。在老师讲解过程中利用在线翻译才勉强能看懂句子。不过培训过程中最难忘的不是来自教材,而是来自老师的那双犀利的眼神。无论何时,只要你打开了与课堂无关的网页,她总会第一时间或叫号码,或叫名字,或站到你旁边。说实话,大学上课已经很久没有这种高中被管的感觉了。虽然不爽,但是却有种回到高中的快感(说的是实话)。
头几天还蛮不错的,食堂开门的,超市没关。可后几天,当校门口已无人烟,就剩我们这几个的时候就真觉得寝室楼好静啊,还不如在机房呆着。对于老师我想说的是,前几天笑容总是挂在脸上,可两天后明显笑的少了,不知道是不是因为和大家熟了,没有刚见面的客气了(我喜欢看人笑,本身也喜欢笑,老师的这种变化,我很敏锐的察觉了)。
这次培训虽然感觉学到的没有很多,但是我了解了一个企业,起码是软件测试这一行业大致的运作模式,让我对我将来要不要从事这个行业有了认识。貌似软件测试女生为主,男生比较适合从开发做起,这是我这几天得到的最大体会。还有对于课堂结束的演讲,是个锻炼
自己的好机会,我并不否认这点,不过貌似每个人都只有一次机会,我是个表现欲很强的人,让我讲了一次有点不过瘾。
开始我是因为不想浪费免费来上课的就会,来到后我觉得确实很多时候是需要多接触下这些社会上的公司、企业等,毕竟还有一年就毕业了,到底何去何从自己是真的要好好做个打算了。期待下一期的网新的培训„„
第五篇:软件测试心得
《软件测试心得体会》
软件测试在整个软件周期中的重要性。它存在于整个项目周期,在项目开始
下面简单谈谈我的几点体会:
体会一:
体会一:软件测试在整个软件周期中的重要性。
它存在于整个项目周期,在项目开始之初需求调研的时候就开始了,在形成需求规格说明书的时候就需要针对文档进行测试。这个环节在后续整个项目中占了很大的比重,能主导整个项目的走向,成败与否全在于开始阶段的决策。
体会二:软件测试的真正意义在于发现错误,而不在于验证软件是正确的。
再严密的测试也不能完全发现软件当中所有的错误,但是测试还是能发现大部分的错误,能确保软件基本是可用的,所以在后续使用的过程中还需要加强快速响应的环节。结合软件测试的理论,故障暴露在最终客户端之前及时主动的去发现并解决。这一点就需要加强研发队伍的建设。
体会三:在系统性能测试方面需要重视。
经过这次培训中多个案例的讲解,让我了解到系统在上线之后会有很多不能预知的性能问题,需要在上线之前实现进行模拟,以规避风险,包括大数据量访问,高并发数等等。当然也有很多应对手段,没有哪种手段可称为最完美,只有最合适的,需要灵活掌握,综合运用以达到最优程度,这是个很值得研究的领域。
下面是我的几点想法:
想法一:加强系统上线前的性能测试。
目前我们在项目建设过程中对性能压力测试的重视程度还不太高,厂家也很少有雇佣第三方的测试机构。而是在现网进行试用,遇到问题再解决,可能会产生滞后问题,影响客户使用。希望以后能在性能测试方面提高重视程度,加大人力投入,以保证系统上线后能够稳定运行。
想法二:适当介入相关项目研发
对于快速响应这块,我们不能一味依赖厂家,而希望自己就能快速响应,及时将问题解决。这也是一个比较长远的问题,需要加强研发力量的投入。
我个人是做开发出身,有此类经验,当时是在客户现场,因为了解系统内部结构,能够在第一时间排查解决客户所反馈问题。
现在系统完全由厂家开发,很难了解内部结构,或许会造成后期维护困难。所以,是否应该针对某些项目介入厂家研发工作,比如请厂家提供源代码等相关要素,以增进维护人员对系统的了解。
最后再次感谢公司提供的平台,感谢领导的信任,让我有机会得到更深层次的学习以及展示自己能力的机会,我也会尽我所能来完善工作的系统,提高整体工作效率,为南方电网的发展建设提供更坚实,优秀的支撑服务平台。