武汉工程大学实习报告

1、武汉工程大学计算机科学与工程学院毕业实习报告专业软件工程班级学号学生姓名指导教师牛志梅（讲师）吕涛（副教授）朱鹏飞（工程师）实习时间20152016 学年第 2 学期2016.02.29至 2016.03.11实习成绩武汉工程大学计算机科学与工程学院制说明：1、 实习指导教师由学院校内教师担任，负责组织实习、学生管理、参加实习答辩、实习成绩评定、给出实习评语等工作。2、 实习报告由武汉工程大学计算机科学与工程学院提供基本格式（适用于学院各专业），各专业教研室和指导教师可根据本专业特点及实习内容做适当的调整，学生须按指导教师下达的实习报告格式认真进行填写。3、 实习成绩由指导教师根据学生的实习情

2、况给出各项分值及总评成绩。4、 指导教师评语一栏由实习指导教师（校内教师）就学生在整个实习期间的表现给出客观、 全面的评价， 包括实习期间的表现、 实习报告的质量、实习答辩的情况等。5、 学生必须参加实习答辩，凡不参加实习答辩者，实习成绩一律按不及格处理。实习答辩小组应由 2 人及以上教师组成，其中校内指导教师必须参加，否则视作无效答辩。6、 实习报告正文字数应不少于5000 字，实习日记字数不少于500 字/天。7、 实习报告正文中实习目的与任务、实习地点、实习内容和要求等项，可由指导教师统一给出（自主实习除外）。学生自主实习的，可根据实习的情况自行填写以上内容。8、 自主实习的学生还应提供

3、由实习单位出具的实习鉴定表（复印件），与实习报告一起装订，作为参加实习答辩和评定成绩的依据。毕业实习答辩记录表学生姓名：学号：班级：答辩地点：答辩内容记录（至少3 个问题。有问有答。问题简洁。答案准确）：记录人签字：各项评分标准实际备注总分值总得分答分值得分在规定时间内能就实习的内容进行全面辩15完整的阐述，言简意明，重点突出，条成30理清晰。绩在规定时间内能准确、完整、流利地回15答教师所提出的问题。答辩小组成员（签字）：年月日毕业实习成绩评定表学生姓名：学号：班级：类别总分各项实际合计值分值评分标准备注得分得分遵守学校和实习单位的考勤、安全生产等纪实习10律，积极参加实习活动，无旷课、迟到

4、、早20退等情况。表现积极完成各项任务，表现良好，服从并配合10指导教师和实习单位的工作安排。实习报告格式规范，文字通顺。按照实习大10纲要求认真完成规定项目内容，能运用所学专业知识对问题加以分析，并对全过程的实习内容进行系统的总结。项目每天记载实习笔记，内容翔实不空泛，无相实践20互抄袭现象。论述充分完整，结构严谨合理。及50体现了实习过程中的学习情况和项目实践情实习况，及所思、所获、所感。报告按照要求完成实习项目，方案合理，设计工作量饱满，能运用专业知识和技能去发现与20解决实际问题。在项目实践过程中展现出了较强的学习能力、动手实践能力、团队协作能力和创新意识。15在规定时间内能就实习的内

5、容进行全面完整实习的阐述，言简意明，重点突出，条理清晰。30答辩在规定时间内能准确、完整、流利地回答教15师所提出的问题。总评成绩指导教师评语指导教师：（签字）日期：年月日一、实习目的与任务实习目的：1 、学习软件测试的相关知识。2 、体验和适应企业中型团队项目开发和测试全过程 3 、了解软件测试过程中出现的问题；4 、具备对前沿信息技术的独立研究和应用能力5 、具备对多种企业平台、软件、框架的集成和整合能力6、培养和提高学生对岗位的适应能力， 使学生更多地了解软件企业的研发流程、 目配置管理和软件开发技术。实习任务：实习的任务是熟悉软件测试的全过程。通过实习，能够熟练掌握测试的方法、测试的基

6、本知识， 能够搭建测试环境， 解决在测试过程中出现的问题； 针对一款软件能够找出比较有用的测试点，能够独立的进行软件测试工作。二、实习地点湖北克兰科技，由专业的测试工程师指导。三、实习内容和要求1、软件测试的相关知识，具体内容如下：（1）软件测试的历史以及重要性；（2）软件测试的分类：白盒测试及黑盒测试；（3）测试用例的编写方法；（4）针对一款具体的软件实施整个测试过程，包括测试环境的搭建、测试用例的编写、测试结果记录，最后形成测试报告；（5）总结实习过程中遇到的问题以及解决思路。四、实习总结及分析本次实习是从公司的讲师介绍软件测试的基本知识开始的， 什么是软件测试？软件测试描述一种用来促进鉴

7、定软件的正确性、 完整性、安全性和质量的过程。换句话说，软件测试是一种实际输出与预期输出间的审核或者比较过程。软件测试的经典定义是 : 在规定的条件下对程序进行操作， 以发现程序错误， 衡量软件质量， 并对其是否能满足设计要求进行评估的过程。 软件测试的背景及目的是什么？软件测试的目的有如下几点： 第一，测试是为了发现程序中的错误而执行程序的过程； 第二，好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案； 第三，成功的测试是发现了至今为止尚未发现的错误的测试。第四，测试并不仅仅是为了找出错误 . 通过分析错误产生的原因和错误的发生趋势，可以帮助项目管理者发现当前软件开发过程中的缺陷，

8、以便及时改进。 第五，这种分析也能帮助测试人员设计出有针对性的测试方法， 改善测试的效率和有效性； 第六，没有发现错误的测试也是有价值的， 完整的测试是评定软件质量的一种方法。 如果在测试某个程序段时发现了可以纠正的缺陷， 或者测试最终确定再没有其他缺陷， 则应将这次合理设计并得到有效执行的测试称作是“成功的”。而所谓“不成功的”测试，仅指未能适当地对程序进行检查， 未能找出程序中潜藏缺陷的测试。因为软件中不可能没有缺陷，没有找出它们，当然测试是“不成功的”。接下来是软件测试的分类软件测试可以分为白盒测试和黑盒测试， 所谓白盒测试， 又称结构测试或者逻辑驱动测试。 白盒测试是把测试对象看作一个

9、打开的盒子。 利用白盒测试法进行动态测试时， 需要测试软件产品的内部结构和处理过程， 不需测试软件产品的功能。白盒测试法的覆盖标准有逻辑覆盖、 循环覆盖和基本路径测试。 其中逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定 / 条件覆盖、条件组合覆盖和路径覆盖。白盒测试是知道产品内部工作过程， 可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序， 检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能， 白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。白盒测试常用工具有 :Jtest、VcSmith、Jcontract、C+Test 、

10、CodeWizard、logiscope 。另一种黑盒测试 ，又称功能测试或者数据驱动测试。 黑盒测试是根据软件的规格对软件进行的测试，这类测试不考虑软件内部的运作原理， 因此软件对用户来说就像一个黑盒子。软件测试人员以用户的角度， 通过各种输入和观察软件的各种输出结果来发现软件存在的缺陷，而不关心程序具体如何实现的一种软件测试方法。黑盒测试常用工具有 :AutoRunner 、winrunner 。除此之外还有 UI 测试即户界面测试， 又称 UI 测试。用户界面，是指软件中的可见外观及其底层与用户交互的部分 ( 菜单、对话框、窗口和其它控件 ) 。用户界面测试是指测试用户界面的风格是否满足

11、客户要求， 文字是否正确， 页面是否美观， 文字，图片组合是否完美，操作是否友好等等。 UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。 用户界面测试用户分析软件用户界面的设计是否合乎用户期望或要求。它常常包括菜单，对话框及对话框上所有按钮，文字，出错提示，帮助信息 (Menu 和 Help content) 等方面的测试。比如，测试 Microsoft Excel 中插入符号功能所用的对话框的大小，所有按钮是否对齐， 字符串字体大小，出错信息内容和字体大小，工具栏位置 / 图标等等。另

12、外一个是冒烟测试， 冒烟测试的名称可以理解为该种测试耗时短， 仅用一袋烟功夫足够了。 也有人认为是形象地类比新电路板基本功能检查。 任何新电路板焊好后，先通电检查，如果存在设计缺陷，电路板可能会短路，板子冒烟了。冒烟测试的对象是新编译的每一个需要正式测试的软件版本， 目的是确认软件基本功能正常， 可以进行后续的正式测试工作。 冒烟测试的执行者是版本编译人员。 也有随机测试， 随机测试没有书面测试用例、记录期望结果、 检查列表、脚本或指令的测试。 主要是根据测试者的经验对软件进行功能和性能抽查。 随机测试是根据测试说明书执行用例测试的重要补充手段， 是保证测试覆盖完整性的有效方式和过程。随机测试

13、主要是对被测软件的一些重要功能进行复测，也包括测试那些当前的测试样例 (TestCase) 没有覆盖到的部分。 另外，对于软件更新和新增加的功能要重点测试。 重点对一些特殊点情况点、 特殊的使用环境、 并发性、进行检查。尤其对以前测试发现的重大Bug，进行再次测试，可以结合回归测试(Regressive testing)一起进行。本地化测试也是测试的一大类， 本地化就是将软件版本语言进行更改，比如将英文的windows 改成中文的 windows 就是本地化。本地化测试的对象是软件的本地化版本。 本地化测试的目的是测试特定目标区域设置的软件本地化质量。 本地化测试的环境是在本地化的操作系统上安

14、装本地化的软件。 从测试方法上可以分为基本功能测试， 安装 / 卸载测试，当地区域的软硬件兼容性测试。 测试的内容主要包括软件本地化后的界面布局和软件翻译的语言质量，包含软件、文档和联机帮助等部分。了解完基础知识之后 , 接下来就是接触自动化测试工具的学习，比较典型的就是QTP和 Loadrounder,QTP 是 quicktest Professional 的简称，是一种自动测试工具。 使用 QTP的目的是想用它来执行重复的手动测试，主要是用于回归测试和测试同一软件的新版本。它的特点有： QTP是一个侧重于功能的回归自动化测试工具；提供了很多插件，如： .NET 的， Java 的， SA

15、P的， Terminal Emulator 的等等，分别用于各自类型的产品测试。 QTP支持的脚本语言是VBScript ，QTP支持录制和回放的功能。 录制产生的脚本， 可以拿来作为自己编写脚本的 template 。录制时，还支持一种 lower level功能，这个对于 QTP不容易识别出来的对象有用，不过它是使用坐标来标识的，对于坐标位置频繁变动的对象，采用这种方式不可行。另外， QTP的编辑器支持两种视图： Keyword 模式和 Expert模式。使用主要步骤是 制定测试计划 > 创建测试脚本 > 增强测试脚本功能 > 运行测试 > 分析测试结果 大致五个步

16、骤。 QuickTest Professional可以自动引入检查点， 以验证应用程序的属性和功能， 例如验证输出或检查链接有效性。对于关键字视图中的每个步骤， 活动屏幕均准确显示测试中应用程序处理此步骤的方式。使用自动化测试工具可以节省很多时间， 省去很多手动的繁琐的工作。 LoadRunner，是一种预测系统行为和性能的负载测试工具。 通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找LoadRunner 能够对整个企业架构进行测试。通过使用LoadRunner，企业能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。LoadRunner 是一种适用于各种体系架构的自

17、动负载测试工具，它能预测系统行为并评估系统性能。这一性能工具出现的背景是企业的网络应用环境都必须支持大量用户，网络体系架构中含各类应用环境且由不同供应商提供软件和硬件产品。难以预知的用户负载和愈来愈复杂的应用环境使公司时时担心会发生用户响应速度过慢，系统崩溃等问题。这些都不可避免地导致公司收益的损失。 Mercury Interactive的 LoadRunner 能让企业保护自己的收入来源，无需购置额外硬件而最大限度地利用现有的IT 资源， 并确保终端用户在应用系统的各个环节中对其测试应用的质量，可靠性和可扩展性都有良好的评价。LoadRunner 的测试对象是整个企业的系统，通过模拟实际用

18、户的操作行为和实行实时性能监测， 来帮助企业客户更快的查找和发现问题。LoadRunner 能支持广范的协议和技术。它在做性能测试的时候使用虚拟用户 (Virtual users) 来模拟实际用户对业务系统施加压力。虚拟用户在一个中央控制器 (controller station) 的监视下工作。 在做一个测试方案时，要做的第一件事就是创建虚拟用户执行脚本。 LoadRunner 提供了 Virtual UserGenerator 来录制或编辑虚拟用户脚本。 它能轻松定位性能问题， LoadRunner 内含集成的实时监测器， 在负载测试过程的任何时候， 都可以观察到应用系统的运行性能。 这些

19、性能监测器实时显示交易性能数据（如响应时间）和其它系统组件包括applicationserver,webserver ，网路设备和数据库等的实时性能。这样，就可以在测试过程中从客户端和服务器的双方面评估这些系统组件的运行性能，从而更快地发现问题。LoadRunner 完全支持 EJB 的负载测试。这些基于 Java 的组件运行在应用服务器上，提供广泛的应用服务。通过测试这些组件，您可以在应用程序开发的早期就确认并解决可能产生的问题。除此之外也讲述了自动化测试的优缺点， 优点是对程序的回归测试更方便。 这可能是自动化测试最主要的任务， 特别是在程序修改比较频繁时， 效果是非常明显的。 由于回归测

20、试的动作和用例是完全设计好的， 测试期望的结果也是完全可以预料的， 将回归测试自动运行，可以极大提高测试效率， 缩短回归测试时间。 可以执行一些手工测试困难或不可能进行的测试。可以执行一些手工测试困难或不可能进行的测试。 增加软件信任度等。 但同时它也有不可否认的缺点：不能取代手工测试 ；手工测试比自动测试发现的缺陷更多； 对测试质量的依赖性极大；测试自动化不能提高有效性；测试自动化可能会制约软件开发。由于自动测试比手动测试更脆弱， 所以维护会受到限制， 从而制约软件的开发； 工具本身并无想像力。有了这些基础知识做铺垫， 接下来则是实践环节， 针对一款订票的 APP进行测试，测试的第一步是对测

21、试环境进行搭建， 这款 APP主要是在手机端进行使用， 那么我们首先需要准备不同的操作系统的手机 - 安卓系统、 ios 系统等，目前主流的系统也就是这两个，确保这两个系统都是最新的系统； 根据软件测试的流程， 接下来设计测试用例， 对于测试用例的设计有许多中方法，在前面已经介绍过了，针对这款 APP是重要是进行黑盒测试，那么测试用例的设计就是根据输入判断输出是否正确， 测试其功能是否能够完成， 是否能够成功订票； 除此之外还要对他的性能进行测试， 如压力测试和负载测试等， 在设计测试用例的过程中遇到了一些问题， 比如，每个程序都是有入口的， 也会有许多个模块共同组成这个程序，那么我们是应该在

22、入口处进行测试还是针对每个模块进行测试呢？提出这个问题后，是我们的导师告诉我， 这两种设计方法各有利弊，为了做到全面测试，最好把能够想到的情况都进行测试； 接下来就是测试的实施， 这一步的难点是对如果出现 bug 怎么办？如果遇到 bug，第一时间是跟项目组长汇报，如果有必要，需要跟开发组成员进行沟通，从源头解决问题，最后是书写测试报告，测试报告主要包括测试概述，测试结果，对软件的评估，改进的建议等内容。五、实习体会从这次实习中我学会了很多，在动手能力和思维方式上有很大的提高，通过这次实训，更多的也发现自己身上的不足， 需要改正的地方， 同时也有自己的优点需要继续努力的地方。在导师精心的讲解下

23、， 对软件测试有了新的认识和理解， 虽然之前上过软件测试的课，但是并没有实际参与到真的测试中去，从理论上升到实践是一个值得学习的过程。软件测试（ Software Testing ），描述一种用来促进鉴定软件的正确性、完整性、安全性和质量的过程。 换句话说，软件测试是一种实际输出与预期输出间的审核或者比较过程。软件测试的经典定义是： 在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。软件测试的步骤可分为如下：第一步：对要执行测试的产品/ 项目进行分析，确定测试策略，制定测试计划。该计划被审核批准后转向第二步。测试工作启动前一定要确定正确的测试策

24、略和指导方针，这些是后期开展工作的基础。 只有将本次的测试目标和要求分析清楚，才能决定测试资源的投入。第二步：设计测试用例。 设计测试用例要根据测试需求和测试策略来进行，进度压力不大时，应该设计的详细，如果进度、成本压力较大， 则应该保证测试用例覆盖到关键性的测试需求。该用例被批准后转向第三步。第三步：如果满足“启动准则”（ EntryCriteria ），那么执行测试。执行测试主要是搭建测试环境，执行测试用例。执行测试时要进行进度控制、 项目协调等工作。 第四步：提交缺陷。 这里要进行缺陷审核和验证等工作。第五步：消除软件缺陷。通常情况下，开发经理需要审核缺陷，并进行缺陷分配。程序员修改自己

25、负责的缺陷。 在程序员修改完成后，进入到回归测试阶段。如果满足“完成准则”（ ExitCriteria ），那么正常结束测试。第六步：撰写测试报告。对测试进行分析，总结本次的经验教训， 在下一次的工作中改。软件测试过程管理，主要包括软件测试是什么样的过程， 如何评价一个软件测试过程， 如何进行配置管理和测试风险分析以及测试成本的管理。程序测试的过程具有破坏性，每当测试一个程序时，人们总希望为程序增加一些价值。利用测试来增加程序的价值， 是指通过测试，找出并修改尽可能多的程序缺陷，从而提高程序的可靠性或质量。 因此，不要只是为了证明程序能够正确运行而去测试程序。 相反，应该一开始就假设程序中隐藏

26、着错误 （这种假设几乎对所有的程序都成立），然后测试程序，发现尽可能多的错误。事实上，如果把测试目标定位于要证明程序中没有缺陷，那么就会在潜意识中倾向于实现这个目标。 也就是说，测试人员会倾向于挑选那些使程序失效的可能性较小的测试数据。 另一方面，如果把测试目标定位于要证明程序中存在缺陷，那么就会选择一些容易发现程序缺陷的测试数据。 而后一种态度会比前者给程序增加更多的价值。事实上，如果在测试某个程序段时发现了可以纠正的缺陷， 或者测试最终确定再没有其他缺陷，则应将这次合理设计并得到有效执行的测试称作是 “成功的” 。而所谓“不成功的”测试，仅指未能适当地对程序进行检查，未能找出程序中潜藏缺陷

27、的测试。“软件测试就是证明软件不存在错误的过程”。对几乎所有的程序而言，甚至是非常小的程序， 这个目标实际上是无法达到的。 因为即使程序完全实现预期要求， 仍可能包含有缺陷。也就是说， 如果程序不按要求工作， 它显然有缺陷， 但如果程序做了不要它做的事，它也有缺陷。 心理学研究告诉我们， 当人们在干一件已经知道是不合适的或不可能做到的事时，往往他们的表现就相当糟糕。把程序测试定义为在程序中找出错误的过程，就使测试成了可以做到的任务， 从而克服了心理上存在的问题。 虽然这看起来像是个微妙的文字游戏，但对成功地进行软件测试有很大的影响。总之，软件测试更适宜被视为试图发现程序中错误 （假设其存在）

28、的破坏性的过程。一个成功的测试， 通过诱发程序发生错误， 可以在这个方向上促进软件质量的改进。 当然最终人们还是要通过软件测试来建立某种程度的信心： 软件做了其应该做的， 而没有做其不应该做的。程序设计组织不应测试自己的程序，在宏观意义上，一个程序设计组织或一个工程项目是个有生命的有机体， 它同样有心理学问题。 在大多数情况下， 人们都以 “在给定日期内，以一定代价完成程序编制任务的能力” 来衡量程序设计组织和项目管理人员的。 这样做的理由是时间和成本指标便于衡量， 而程序的质量很难度量。 要程序设计组织在测试自己的程序时持客观态度是很困难的， 因为如果用正确的定义看待测试， 就不大可能按预定

29、计划完成测试，也不大可能把耗费的代价限制在要求的范围以内。软件生产的三个最重要的因素是：质量、进度和费用。由于费用和进度的限制，要开发一种高质量、 快速交付和低成本的软件产品并不容易。 也就是说要同时达到三个目标是困难的。因此在软件产品的开发中要权衡它们之间的关系， 使软件的特性能满足用户的要求，这意味着软件产品的特性的度量和预计是必要的。软件测试由独立测试机构承担有很多好处。 独立测试是指软件测试工作由在经济上和管理上独立于开发机构的组织进行。独立测试可以避免软件开发者测试自己开发的软件，由于心理学上的问题， 软件开发者难以客观、有效的测试自己的软件，要找出那些因为对问题的误解而产生的错误就

30、更加困难。 独立测试还可以避免软件开发机构测试自己的软件，软件产品的开发过程受到时间、 成本和质量三者的制约，在软件开发的过程中， 当时间、成本和质量三者发生矛盾时， 质量最容易被忽视， 如果测试组织与开发组织来自相同的机构，测试过程就会面临来自于开发组织同一来源的管理方面的压力， 使测试过程受到干扰。客观性对软件测试和软件中的错误抱着客观的态度， 这种客观的态度可以解决测试中的心理学问题， 既能以揭露软件中错误的态度工作， 也能不受发现的错误的影响。经济上的独立性使测试有更充分的条件按测试要求去完成。专业性独立测试作为一种专业工作， 在长期的工作过程中势必能够积累大量实践经验，形成自己的专业

31、知识。 同时软件测试也是技术含量很高的工作， 需要有专业队伍加以研究，并进行工程实践。 专业化分工是提高测试水平、保证测试质量、充分发挥测试效应的必然途径。权威性由于专业优势，独立测试工作形成的测试结果更具信服力，而测试结果常常和对软件的质量评价联系在一起， 专业化的独立测试机构的评价， 更客观、公正和具有权威性。 资源有保证独立测试机构的主要任务是进行独立测试工作， 这使得测试工作在经费、人力和计划方面更有保证，不会因为开发的压力减少对测试的投入，降低测试的有效性可以避免开发单位侧重软件开发而对测试工作产生不利的影响。通过这次实习我更加认识到实践是检验真理的唯一标准，只学不实践，那么所学的就

32、等于零，理论应该与实践相结合。 另一方面，实践可为以后找工作打基础。我感觉实践是大学生活的第二课堂 , 是知识常新和发展的源泉，是检验真理的试金石，也是大学生锻炼成长的有效途径。一个人的知识和能力只有在实践中才能发挥作用 , 才能得到丰富、完善和发展。大学生成长， 就要勤于实践，将所学的理论知识与实践相结合一起， 在实践中继续学习，不断总结，逐步完善，有所创新，并在实践中提高自己的各方面知识、能力、技术等因素融合成的综合素质和能力， 为自己事业的成功打下良好的基础。 在测试工作中很重要的一个方面是写测试用例， 由于实习的公司主要是做外包测试的， 所以我们编写的测试用例没有涉及到代码， 但即使如

33、此， 为了能合理的测试产品，满足用户的要求， 我们同样需要了解客户的需求， 编写合理的测试用例， 并尽量使用少的测试用例覆盖大的测试范围，比如有些打印机支持传真， 而有的不支持， 这就要根据不同的真实场景设计有效的测试用例，黑盒测试的主要方法有边界值分析， 等价类划分，因果图等方法， 在对产品进行测试的时候我用到过边界值分析等方法，把理论运用到实践。在实习中也暴露出自身很多的问题与不足， 在老师的讲解下， 慢慢的我发现其实软件测试都是很有趣的事情， 都是值得我们学习的知识， 在进入公司实习之前很难有这样的项目来增加我们的动手能力，但是经过这几次的实习给我们创造了不少的锻炼自己的机会，我们应好好

34、珍惜，学习知识。 回顾以前所走的路，太多的是无奈和迷茫，这次实习就像是我人生道路上的航标， 为我指明了前进的方向， 使我对自己的前途充满了信心， 同时也知道了自己的前进方向。实习笔记时间： 2016 年 02 月 29 日地点：湖北克兰科技主要内容：今天是进入公司的第一天， 这是在结束大学生活前最后一次到公司实习， 因此对这次实习机会感到格外珍惜。 到公司后，主要是对公司的环境熟悉， 了解公司的历史等基本情况。跟第一次校外实习类似， 前期依然会有针对实习生的培训， 介绍软件测试的背景以及目的等，测试的最终目的是确保最终交给用户的产品的功能符合用户的需求， 把尽可能多的问题在产品交给用户之前发现

35、并改正然后是介绍软件测试的重要性： 在软件业较发达的国家。 软件测试不仅成为软件开发的一个有机组成部分， 而且在软件开发的系统工程中占据着相当大的比重。 以美国的软件开发和生产的平均资金投入为例， 通常是： “需求分析 ”和“规划确定 ”各占百分之三， “设计 ” 占百分之五，设计占百分之五， 编程占百分之七，测试占百分之十五，投产和维护占百分之六七十。测试在。软件开发中的地位不言而喻。 软件测试工程师和软件卡发工程师就像两兄弟，缺一不可，国内开发工程师招聘还是比较容易的， 但在做一些大型项目时需要大量软件测试人员， 因为目前高校里没有单独的专业， 只能招聘后在进行培训， 这就大大增加了企业的

36、成本，所以企业还是希望有一批专业培训的人员能直接上岗。软件测试是一个系列过程活动，贯穿于软件项目的整个生命过程，很多软件项目的开发还停留在 “作坊式 ”阶段，项目的成功往往靠个别程序员决定。时间： 2016 年 03 月 01 日地点：湖北克兰科技主要内容：进入公司的第二天，今天依然是针对实习生的培训，主要讲解的内容是软件测试的整个过程，以及测试方法， 测试的分类方法有很多，可以分为白盒测试和黑盒测试； 白盒测试，又称结构测试、透明盒测试、 逻辑驱动测试或基于代码的测试。白盒测试是一种测试用例设计方法， 盒子指的是被测试的软件， 白盒指的是盒子是可视的， 你清楚盒子内部的东西以及里面是如何运作

37、的。 " 白盒 " 法全面了解程序内部逻辑结构、 对所有逻辑路径进行测试。 " 白盒 " 法是穷举路径测试。 在使用这一方案时， 测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。黑盒测试称功能测试或数据驱动测试， 它是在已知产品所应具有的功能， 通过测试来检测每个功能是否都能正常使用， 在测试时，把程序看作一个不能打开的黑盒子， 在完全不考虑程序内部结构和内部特性的情况下， 测试者在程序接口进行测试， 它只检查程序功能是否按照需求规格说明书的规定正常使用， 程序是否能适当地接收输入数据而产生正确的输出信息，并且保持外部信息 （如数据库或

38、文件）的完整性。黑盒测试方法主要有等价类划分、边值分析、因果图、错误推测等，主要用于软件确认测试。“黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。 “黑盒”法是穷举输入测试， 只有把所有可能的输入都作为测试情况使用， 才能以这种方法查出程序中所有的错误。 实际上测试情况有无穷多个， 人们不仅要测试所有合法的输入， 而且还要对那些不合法但是可能的输入进行测试。时间： 2016 年 03 月 02 日地点：湖北克兰科技主要内容 :今天是进入公司的第三天，今天是讲师给我们讲解软件测试中测试用例的设计方法，依然是依据测试的分类 - 白盒测试，黑盒测试。其中黑盒测试中，

39、 比较常用的有等价类划分，不用考虑程序的内部结构，根据程序的输入接口，把可能的输入划分成不同的段，然后利用每个段的输入， 验证输出段是否是正确的， 同时也验证不合法的输入， 这种设计方法需注意的是选择的数据要有代表性。 另一个黑盒测试用例设计方法， 边界值分析，这种方法主要测试的边界值的问题，根据长期的工作经验来说，大量的错误是发生在输入或输出的边界上。因此针对各种边界情况设计测试用例，可以查出更多的错误。首先应确定边界情况通常输入和输出等价类的边界就是应着重测试的边界情况应当选取正好等于刚刚大于或刚刚小于边界的值作为测试数据而不是选取等价类中的典型值或任意值作为测试数据 . 除了讲解理论知识

40、外， 也给我们讲解了一些实际的例子， 让我们自己动手练习，加深理解，另一种方法是错误推测法， 是基于经验和直觉推测程序中可能存在的各种错误，有针对性的设计测试用例的方法， 但是需要注意的是这种推测方法的基本思想是列举程序中所有可能的错误和容易发生错误的地方， 然后设计测试用例。 根据今天的学习让我对软件测试的测试用例的设计方法有了很大的提高。时间： 2016 年 03 月 03 日地点：湖北克兰科技主要内容 :今天还是继续讲解测试用例的设计方法， 继续昨天讲到的地方， 今天讲解的方法是因果图方法，前面讲到的方法中都是着重考虑输入条件的， 但未考虑到条件之间的联系， 相互结合等，如果考虑这些情况

41、的话可能会出现新的情况， 用之前的方法来测试条件之间的组合可能已经不适合啦， 因为需要考虑的情况很多， 所以引入了一种新的测试方法， 因果图法，找出条件中给出的原因和结果， 并找出他们之间的对应关系， 利用组合条件得到测试用例，最终生成判定表， 这种方法中需要注意的是约束条件和符号的正确使用。 学习了这几种黑盒测试用例的设计方法， 接下来学习的是白盒测试用例的设计方法， 第一种是路径覆盖，这种测试方法主要适用于单元测试， 路径是指函数代码的某个分支， 找出了所有的路径，下面的工作就是给每条路径设定优先级，这样在测试时就可以先测优先级高的，再测优先级低的， 在时间紧迫的情况下甚至可以考虑忽略一些

42、低优先级的路径。 优先级根据两个原则来选取： 一是路径使用的频率， 使用越频繁的优先级越高； 二是路径的重要程度如果失败对系统影响越大的优先级越高。 将根据两个原则所分别得到的优先级相加就得到了整个路径的优先级。根据优先级的排序就可以更有针对性的进行测试时间： 2016 年 03 月 04 日地点：湖北克兰科技主要内容 :通过前面的讲解， 已经学习了许多的测试用例的设计方法， 接下来这两个方法在实际的应用会带来更好的测试效果， 第一个是正交实验设计法， 所谓“正交实验法” 是从大量的实验中挑选适量的、 有代表性的点， 应用依据伽罗瓦理论导出的正交表， 合理安排实验的一种实验设计方法。 利用该方

43、法可以使所有因子和水平在实验中均匀的分布与搭配， 均匀规律的变化。在正交实验设计方法中，通常把判断实验结果优劣的标准叫做实验的指标，把有可能影响实验指标的条件称为因子，而影响实验因子的，叫做因子的水平 (或状态 )。在进行实验优化设计时， 为了完成明确的实验目的， 必须有合理的实验指标， 加上合理的基准来挑选实验因子以及相应的水平。在设计之前我们需要了解的是什么是因素（ Factor）是指在一项试验中，凡欲考察的变量称为因素（变量）；什么是水平（位级） Level 指在试验范围内，因素被考察的值称为水平（变量的取值）；什么是正交试验设计，是研究多因素多水平的一种设计方法，它是根据正交性从全面试

44、验中挑选出部分有代表性的点进行试验， 这些有代表性的点具备了均匀分散，齐整可比的特点，正交试验设计是一种基于正交表的、高效率、快速、经济的试验设计方法。该方法设计的步骤：首先考虑有哪些因素（变量），然后是每个因素有哪几个水平（变量的取值），再者选择一个合适的正交表，并把变量的值映射到表中，最后把每一行的各因素水平的组合做为一个测试用例， 最后加上你认为可疑且没有在表中出现的。这样正交测试用例就设计好了时间： 2016 年 03 月 07 日地点：湖北克兰科技主要内容 :接着昨天的内容， 今天介绍的是场景设计法， 通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果的一种方法。 用例场

45、景来测试需求是指模拟特定场景边界发生的事情， 通过事件来触发某个动作的发生， 观察事件的最终结果， 从而用来发现需求中存在的问题。 我们通常以正常的用例场景分析开始， 然后再着手其他的场景分析。 场景法一般包含基本流和备用流， 从一个流程开始， 通过描述经过的路径来确定的过程， 经过遍历所有的基本流和备用流来完成整个场景。 场景主要包括 4 种主要的类型： 正常的用例场景，备选的用例场景，异常的用例场景，假定推测的场景。通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果。场景法一般包含基本流和备用流， 从一个流程开始， 通过描述经过的路径来确定的过程， 经过遍历所有的基本流和备用流

46、来完成整个场景。为什么场景法能如此清晰的描述整个事件？因为，现在的系统基本上都是由事件来触发控制流程的。 如：我们申请一个项目， 需先提交审批单据，再由部门经理审批，审核通过后由总经理来最终审批，如果部门经理审核不通过，就直接退回。每个事件触发时的情景便形成了场景。 而同一事件不同的触发顺序和处理结果形成事件流。这一系列的过程我们利用场景法可以清晰的描述清楚。时间： 2016 年 03 月 08 日地点：湖北克兰科技主要内容 :针对之前的学习，我们知道，软件测试是有很多模型的，今天学习的是V 模型：测试是开发之后的一个阶段。 测试的对象就是程序本身。 实际应用中容易导致需求阶段的错误一直到最后

47、系统测试阶段才被发现。 整个软件产品的过程质量保证完全依赖于开发人员的能力和对工作的责任心， 而且上一步的结果必须是充分和正确的， 如果任何一个环节出了问题，则必将严重的影响整个工程的质量和 W 模型由 Evolutif 公司公司提出，相对于模型， W 模型增加了软件各开发阶段中应同步进行的验证和确认活动。 W 模型由两个 VV 字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。W 模型强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等同样要测试，也就是说，测试与开发是同步进行的。W 模型有利于尽早地全面的发现问题。例如， 需求分析完成后，测试

48、人员就应该参与到对需求的验证和确认活动中， 以尽早地找出缺陷所在。 同时，对需求的测试也有利于及时了解项目难度和测试风险， 及早制定应对措施，这将显著减少总体测试时间，加快项目进度。 但 W 模型也存在局限性。在 W 模型中，需求、设计、编码等活动被视为串行的，同时，测试和开发活动也保持着一种线性的前后关系， 上一阶段完全结束， 才可正式开始下一个阶段工作。 这样就无法支持迭代的开发模型。对于当前软件开发复杂多变的情况， W 模型并不能解除测试管理面临着困惑时间： 2016 年 03 月 09 日地点：湖北克兰科技主要内容 :学习了 V 模型之后，接下来学习的是X 模型， X 模型 X 模型也

49、是对 V 模型的改进 ,X模型提出针对单独的程序片段进行相互分离的编码和测试 , 此后通过频繁的交接 , 通过集成最终合成为可执行的程序。 X 模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试， 此后将进行频繁的交接， 通过集成最终成为可执行的程序， 然后再对这些可执行程序进行测试。 己通过集成测试的成品可以进行封装并提交给用户， 也可以作为更大规模和范围内集成的一部分。 多根并行的曲线表示变更可以在各个部分发生。 由图中可见，X 模型还定位了探索性测试，这是不进行事先计划的特殊类型的测试，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。 但这样可能对测试造成

50、人力、物力和财力的浪费， 对测试员的熟练程度要求比较高。 软件测试前置模型前置测试模型则体现了开发与测试的结合 , 要求对每一个交付内容进行测试。前置测试模型是一个将测试和开发紧密结合的模型， 此模型将开发和测试的生命周期整合在一起， 随项目开发生命周期从开始到结尾每个关键行为而执行时间： 2016 年 03 月 10 日地点：湖北克兰科技主要内容 :继续学习前置测试模型， 前置测试模型包括 2 项测试计划技术 :其中的第一项技术是开发基于需求的测试用例。这并不仅仅是为以后提交上来的程序的测试做好初始化准备，也是为了验证需求是否是可测试的。 这些测试可以交由用户来进行验收测试， 或者由开发部门

51、做某些技术测试。很多测试团体都认为，需求的可测试性即使不是需求首要的属性，也应是其最基本的属性之一。 因此，在必要的时候可以为每一个需求编写测试用例。 不过，基于需求的测试最多也只是和需求本身一样重要。 一项需求可能本身是错误的， 但它仍是可测试的。而且，你无法为一些被忽略的需求来编写测试用例。第二项技术是定义验收标准。 在接受交付的系统之前， 用户需要用验收标准来进行验证。验收标准并不仅仅是定义需求， 还应在前置测试之前进行定义， 这将帮助揭示某些需求是否正确， 以及某些需求是否被忽略了。 同样的，系统设计在投入编码实现之前也必须经过测试，以确保其正确性和完整性。 很多组织趋向于对设计进行测

52、试， 而不是对需求进行测试。 Goldsmith 曾提供过 15 项以上的测试方法来对设计进行测试，这些组织也只使用了其中很小的一部分。 在对设计进行的测试中有一项非常有用的技术， 即制订计划以确定应如何针对提交的系统进行测试，这在处于设计阶段并即将进入编码阶段时十分有用。时间： 2016 年 03 月 11 日地点：湖北克兰科技主要内容 :设计阶段是做测试计划和测试设计的最好时机。很多组织要么根本不做测试计划和测试设计，要么在即将开始执行测试之间才飞快地完成测试计划和设计。在这种情况下， 测试只是验证了程序的正确性，而不是验证整个系统本该实现的东西。测试有 2 种主要的类型，这2 种类型都需

53、要测试计划。在V 模型中，验收测试最早被定义好，并在最后执行，以验证所交付的系统是否真正符合用户业务的需求。与V 模型不同的是，前置测试模型认识到验收测试中所包含的 3 种成份，其中的 2 种都与业务需求定义相联系：即定义基于需求的测试， 以及定义验收标准。但是， 第三种则需要等到系统设计完成，因为验收测试计划是由针对按设计实现的系统来进行的一些明确操作定义所组成，这些定义包括：如何判断验收标准已经达到，以及基于需求的测试已算成功完成。技术测试主要是针对开发代码的测试，例如 V 模型中所定义的动态的单元测试，集成测试和系统测试。另外，前置测试还提示我们应增加静态审查，以及独立的 QA 测试。QA 测试通常跟随在系统测试之后，从技术部门的意见和用户的预期方面出