公司面试测试人员一般考什么.doc 详细�0�3

如题所述

01. 为什么要在一个团队中开展软件测试工作? 答:软件测试在整个一个团队中占有非常重要的地位,具体来说就是测试是一个发现软件错误的过程,执行软件测试会以最少的人力和时间,系统的找到软件存在的缺陷和错误,建立起开发人员和使用者对软件的信心。 02. 您是否了解以往所工作的企业的软件测试过程?如果了解,请试述在这个过程中都有哪些工作要做?分别由哪些不同的角色来完成这些工作? 答:软件测试部门配合系统分析人员软件需求分析讨论,并根据需求说明书制定《项目测试计划》,编写测试用例,建立测试环境。 软件测试人员负责软件开发部门的新产品测试及原有产品的升级测试,负责软件问题解决过程跟踪,负责软件开发文档开发工作的规范化及管理开发部门的产品文档,制作用户手册及操作手册,负责产品的上线测试,监督软件开发过程的执行,提高产品质量。 03. 您是否了解以往所工作的企业的软件开发过程?如果了解,请试述一个完整的开发过程需要完成哪些工作?分别由哪些不同的角色来完成这些工作?(对于软件测试部分,可以简述) 答:需求人员连同系统分析人员&测试人员开会讨论需求。系统分析人员写出需求分析说明,并连同系统分析人员&测试人员&需求人员开会讨论可行性。系统分析人员写出详细设计说明书,程式人员编码,给出系统流程图。交与测试人员,测试人员给出Bug 统计表。 04. 您在以往的测试工作中都曾经具体从事过哪些工作?其中最擅长哪部分工作? 答:从事过write test plan,creation of test case,进行功能测试,性能测试,编写测试工具,文档的管理等,比较擅长与写测试用例和进行功能测试。 05. 您所熟悉的软件测试类型都有哪些?请试着分别比较这些不同的测试类型的区别与联系(如功能测试、性能测试�6�7�6�7) 答:有功能测试,性能测试,可靠性测试,安全性测试,负载测试,压力测试,安装/卸载测试,启动/停止测试,兼容性测试,互连测试,文档测试,恢复测试,回归测试,可使用性测试,容量测试。 功能测试只对软件的功能是否满足用户需求来做测试。性能测试需要和压力和负载测试联合起来。 06. 请试着比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系。 黑盒测试:把测试对象当成一个黑盒子,测试人员完全不考虑逻辑结构和内部特性,只依据程式的需求说明书来检查程式的功能是否满足它的功能说明。 白盒测试:把测试对象当成一个透明的盒子,允许测试人员利用程序内部逻辑结构及相关信息,设计或选择测试用例,对程式所有逻辑路径进行测试。 单元测试:白盒测试的一种,对软件设计中的单元模块进行测试。 集成测试:在单元测试的基础上,对单元模块之间的连接和组装进行测试。 系统测试:在所有都考虑的情况下,对系统进行测试。 验收测试:第三方进行的确认软件满足需求的测试。 07. 测试计划工作的目的是什么?测试计划工作的内容都包括什么?其中哪些是最重要的? 答:测试计划工作是对测试工作内容的一个有效的组织和规划,能保证测试工作有效的展开。测试计划工作包括测试目标,测试范围的定义,测试方法的选择,测试进度里程碑,测试资源的有效配置和管理。 测试计划工作也称为测试策略,主要描述测试工程的总体方法和目标,描述目前在进行那一阶段的测试(单元测试,集成测试,系统测试)以及每一阶段内进行的测试种类(功能测试,性能测试等)确定测试范围,生成测试数据等。 其中软件计划中的测试目标最重要,他的软件测试的所需要达成的最终结果。 08. 您认为做好测试计划工作的关键是什么? 答:1. 明确测试的目标,增强测试计划的实用性 2. 坚持“5W”规则,明确内容与过程,'what''why''when''where''how' 3. 采用评审和更新机制,保证测试计划满足实际需求 4. 分别创建测试计划与测试详细规格、测试用例 09. 您所熟悉的测试用例设计方法都有哪些?请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。 答:有黑盒和白盒两种测试种类,黑盒有等价类划分法,边界分析法,因果图法和错误猜测法。白盒有逻辑覆盖法,循环测试路径选择,基本路径测试。 例子:在一次输入多个条件的完整性查询中。利用等价类划分法则和边界分析法则,首先利用等价类划分法,可以一个或多个结果是OK 的测试用例,然后确认多个NG 的测试用例,然后利用边界值分析法,可以对结果分别是OK 和NG 的测试用例进行扩展和补充。 10. 您认为做好测试用例设计工作的关键是什么? 答:测试用例设计工作的关键是对可行的和不可行的都要考虑。 1,输入 2,详细的操作步骤 3,预期输出 4,实际输出。 14. 您在从事性能测试工作时,是否使用过一些测试工具?如果有,请试述该工具的工作原理,并以一个具体的工作中的例子描述该工具是如何在实际工作中应用的。 答:有使用过LoadRunner,该工具能够录制测试人员的操作步骤,然后对这个操作步骤模拟出多个用户来播放出来。 1。Visural User Genertor 创建脚本,选择协议,录制操作,编辑操作。 2。中央控制器(Controller)调度虚拟用户。创建场景,选择脚本,建立虚拟用户,设计shedual,设置ip spoofer。 3。运行脚本。分析shedual。 4。分析测试结果。 15. 您认为性能测试工作的目的是什么?做好性能测试工作的关键是什么? 答:性能测试工作的目的是检查系统是否满足在需求说明书中规定的性能,性能测试常常需要和强度测试结合起来,并常常要求同时进行软件和硬件的检测。 性能测试主要的关注对象是响应时间,吞吐量,占用内存大小(辅助存储区),处理精度等。 16. 在您以往的工作中,一条软件缺陷(或者叫Bug)记录都包含了哪些内容?如何提交高质量的软件缺陷(Bug)记录? 答:检测时间,系统环境,硬体环境,严重程度,程式版本,确认人,功能模块,问题描述,详细操作步骤,是否会重现。 问题描述和详细操作步骤要尽可能的详细。Bug 应该尽量用书面语,对与严重程度比较高的缺陷要在相同环境下在测试一遍。 在C/S 模式下,如果条件满足可以使用替换法来确认是client 端的问题还是 server 端的问题。 03. 您所熟悉的软件测试类型都有哪些?请试着分别比较这些不同的测试类型的区别与联系(如功能测试、性能测试……) 易用性测试-界面的友好性,操作方便性等。 功能测试-系统中功能性需求的满足 安全性测试-系统是否存在安全隐患和漏洞 性能测试-系统在大并发下的响应速度和健壮性 04.请试着比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系。 黑盒/白盒:主要区别在是否了解系统或程序的内部结构和代码 单元测试:关注某一个单元,函数,模块的正确性,一般需要编写相关测试代码。 集成测试:模块或模块直接的集成接口测试,单个模块测试 系统测试:一个完整功能的完全测试。 05.测试计划工作的目的是什么?测试计划工作的内容都包括什么?其中哪些是最重要的? 提前安排出测试工具选择,测试类型选择,人员需求,保证和项目开发协调一致,保证测试工作顺利进行。 .您认为做好测试计划工作的关键是什么? 了解项目或系统的业务需求 和项目经理协调好,了解项目的进度计划安排情况 .您所熟悉的测试用例设计方法都有哪些?请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。 边界值/等价类/业务流程图分析和状态转换分析/业务逻辑分析 .您认为做好测试用例设计工作的关键是什么? 对业务和软件需求非常清楚,可以根据需求不同选择不同的测试用例设计 您以往的工作中是否曾开展过测试用例的评审工作?如果有,请描述测试用例评审的过程和评审的内容。 评审计划->预审->评审; 评审内容主要是测试用例对软件需求的覆盖程度,对于相关边界是否考虑,是否针对复杂流程准备多套测试数据,是否有专门针对非功能性需求的测试。 您以往是否曾经从事过性能测试工作?如果有,请尽可能的详细描述您以往的性能测试工作的完整过程。 制订计划->选择测试功能->选择测试工具->录制脚本->运行测试->分析结果 您在从事性能测试工作时,是否使用过一些测试工具?如果有,请试述该工具的工作原理,并以一个具体的工作中的例子描述该工具是如何在实际工作中应用的。 微软WAS,LoadRunner 您认为性能测试工作的目的是什么?做好性能测试工作的关键是什么? 关键是测试脚本的录制,测试时候测试环境的干净。 在您以往的工作中,一条软件缺陷(或者叫Bug)记录都包含了哪些内容?如何提交高质量的软件缺陷(Bug)记录? 缺陷名词/描述/缺陷等级/严重程度/发现模块/发现步骤和过程/是否可以重现 14.您以往所从事的软件测试工作中,是否使用了一些工具来进行软件缺陷(Bug)的管理?如果有,请结合该工具描述软件缺陷(Bug)跟踪管理的流程。 CQ,也可以使用BugFree 等免费工具。 15.您如何看待软件过程改进?在您曾经工作过的企业中,是否有一些需要改进的东西呢?您期望的理想的测试人员的工作环境是怎样的? 将先进的经验或思想固化到过程中,通过过程改进和能力提高来改进软件质量。 01. 为什么要在一个团队中开展软件测试工作? 因为没有经过测试的软件很难在发布之前知道该软件的质量,就好比 ISO 质量认证一样,测试同样也需要质量的保证,这个时候就需要在团队中开展软件测试 的工作。在测试的过程发现软件中存在的问题,及时让开发人员得知并修改问题,在即将发布时,从测试报告中得出软件的质量情况。 02. 您在以往的测试工作中都曾经具体从事过哪些工作?其中最擅长哪部分工作? 我曾经做过web 测试,后台测试,客户端软件,其中包括功能测试,性能测试,用户体验测试。最擅长的是功能测试 03. 您所熟悉的软件测试类型都有哪些?请试着分别比较这些不同的测试类型的区别与联系(如功能测试、性能测试�6�7�6�7) 测试类型有:功能测试,性能测试,界面测试。 功能测试在测试工作中占的比例最大,功能测试也叫黑盒测试。是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时,需要测试软件产品的功能,不 需测试软件产品的内部结构和处理过程。采用黑盒技术设计测试用例的方法有:等价类划分、边界值分析、错误推测、因果图和综合策略。 性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试,两者可以结 合进行。通过负载测试,确定在各种工作负载下系统的性能,目标是测试当负载逐渐增加时,系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或 者不能接收的性能点,来获得系统能提供的最大服务级别的测试。 界面测试,界面是软件与用户交互的最直接的层,界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作,起到向导的 作用。同时界面如同人的面孔,具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉,相反由于界面设计的失败,让用户有挫败 感,再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。 区别在于,功能测试关注产品的所有功能上,要考虑到每个细节功能,每个可能存在的功能问题。性能测试主要关注于产品整体的多用户并发下的稳定性和健壮 性。界面测试更关注于用户体验上,用户使用该产品的时候是否易用,是否易懂,是否规范(快捷键之类的),是否美观(能否吸引用户的注意力),是否安全(尽 量在前台避免用户无意输入无效的数据,当然考虑到体验性,不能太粗鲁的弹出警告)?做某个性能测试的时候,首先它可能是个功能点,首先要保证它的功能是没 问题的,然后再考虑该功能点的性能测试 04.您认为做好测试用例设计工作的关键是什么? 白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果 黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试,以最少的用例在合理的时间内发现最多的问题 05. 请试着比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系。 黑盒测试:已知产品的功能设计规格,可以进行测试证明每个实现了的功能是否符合要求。 白盒测试:已知产品的内部工作过程,可以通过测试证明每种内部操作是否符合设计规格要求,所有内部成分是否以经过检查。 软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子,测试人员完全不考虑程序内部的逻辑结构和内部特性,只依据程序 的需求规格说明书,检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下几类错误: 1、是否有不正确或遗漏的功能? 2、在接口上,输入是否能正确的接受?能否输出正确的结果? 3、是否有数据结构错误或外部信息(例如数据文件)访问错误? 4、性能上是否能够满足要求? 5、是否有初始化或终止性错误? 软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子,它允许测试人员利用程序内部的逻辑结构及有关信息,设计 或选择测试用例,对程序所有逻辑路径进行测试。通过在不同点检查程序状态,确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测 试。白盒测试主要是想对程序模块进行如下检查: 1、对程序模块的所有独立的执行路径至少测试一遍。 2、对所有的逻辑判定,取“真”与取“假”的两种情况都能至少测一遍。 3、在循环的边界和运行的界限内执行循环体。 4、测试内部数据结构的有效性,等等。 单元测试(模块测试)是开发者编写的一小段代码,用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言,一个单元测试是用于判断某个特定条件(或者场景)下某个特定函数的行为。 单元测试是由程序员自己来完成,最终受益的也是程序员自己。可以这么说,程序员有责任编写功能代码,同时也就有责任为自己的代码编写单元测试。执行单元测试,就是为了证明这段代码的行为和我们期望的一致。 集成测试(也叫组装测试,联合测试)是单元测试的逻辑扩展。它的最简单的形式是:两个已经测试过的单元组合成一个组件,并且测试它们之间的接口。从这 一层意义上讲,组件是指多个单元的集成聚合。在现实方案中,许多单元组合成组件,而这些组件又聚合成程序的更大部分。方法是测试片段的组合,并最终扩展进 程,将您的模块与其他组的模块一起测试。最后,将构成进程的所有模块一起测试。 系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。(常见的联调测试) 系统测试的目的是对最终软件系统进行全面的测试,确保最终软件系统满足产品需求并且遵循系统设计。 验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪,并且可以让最终用户将其用于执行软件的既定功能和任务。 验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后,已经按照设计把所有的模块组装成一个完整的软件系统,接口错误也已经基本排除了,接着就应该进一步验证软件的有效性,这就是验收测试的任务,即软件的功能和性能如同用户所合理期待的那样。 06. 测试计划工作的目的是什么?测试计划工作的内容都包括什么?其中哪些是最重要的? 软件测试计划是指导测试过程的纲领性文件,包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内 容。借助软件测试计划,参与测试的项目成员,尤其是测试管理人员,可以明确测试任务和测试方法,保持测试实施过程的顺畅沟通,跟踪和控制测试进度,应对测 试过程中的各种变更。 测试计划和测试详细规格、测试用例之间是战略和战术的关系,测试计划主要从宏观上规划测试活动的范围、方法和资源配置,而测试详细规格、测试用例是完成测试任务的具体战术。所以其中最重要的是测试测试策略和测试方法(最好是能先评审) 07. 您认为做好测试计划工作的关键是什么? 1. 明确测试的目标,增强测试计划的实用性 编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷,因此软件测试计划的价值取决于它对帮助管理测试项目,并且找出软件潜在的缺陷。因此,软件测试计划中的测试范围必须高度覆盖功能需求,测试方法必须切实可行,测试工具并且具有较高的实用性,便于使用,生成的测试结果直观、准确 2.坚持“5W”规则,明确内容与过程 “5W”规则指的是“What(做什么)”、“Why(为什么做)”、“When(何时做)”、“Where(在哪里)”、“How(如何做)”。利用“5W”规则创建软件测试计划,可以帮助测试团队理解测试的目的(Why),明确测试的范围和内容(What),确定测试的开始和结束日期 (When),指出测试的方法和工具(How),给出测试文档和软件的存放位置(Where)。 3.采用评审和更新机制,保证测试计划满足实际需求 测试计划写作完成后,如果没有经过评审,直接发送给测试团队,测试计划内容的可能不准确或遗漏测试内容,或者软件需求变更引起测试范围的增减,而测试计划的内容没有及时更新,误导测试执行人员。 4. 分别创建测试计划与测试详细规格、测试用例 应把详细的测试技术指标包含到独立创建的测试详细规格文档,把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据 库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系,测试计划主要从宏观上规划测试活动的范围、方法和资源配置,而测试详细规格、测试用例是 完成测试任务的具体战术。 08. 您所熟悉的测试用例设计方法都有哪些?请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。 1.等价类划分 划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的 测试.因此,可以把全部输入数据合理划分为若干等价类, 在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结 果.等价类划分可有两种不同的情况:有效等价类和无效等价类. 2.边界值分析法 边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误. 使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据. 3.错误推测法 基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法. 错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为 0 的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例. 4.因果图方法 前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图(逻辑模型). 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况. 09. 请以您以往的实际工作为例,详细的描述一次测试用例设计的完整的过程。 就说最近的这次网站功能的测试吧 首先:得到相关文档(需求文档和设计文档),理解需求和设计设计思想后,想好测试策略(测试计划简单点就OK 了),考虑到测试环境,测试用例,测试时间等问题。 第二步:设计测试用例,测试策略是:把网站部分的功能点测试完,然后在进行系统测试(另外个模块呢有另一个测试人员负责,可以进行联调测试),网站模 块的测试基本是功能测试和界面测试(用户并发的可能性很小,所以不考虑):这次的网站的输入数据呢是使用数据库中的某张表记录,如果表中某一数据记录中新 加进来的(还没有被处理的,有个标志位),网站启动后会立刻去刷那张表,得到多条数据,然后在进行处理。处理过程中,会经历3 个步骤,网站才算完成了它的 任务。有3 个步骤呢,就可以分别对 这3 个步骤进行测试用例的设计,尽量覆盖到各种输入情况(包括数据库中的数据,用户的输入等),得出了差不多50 个 用例。界面测试,也就是用户看的到的地方,包括发送的邮件和用户填写资料的页面展示。 第三步:搭建测试环境(为什么这个时候考虑测试环境呢?因为我对网站环境已经很熟了,只有有机器能空于下来做该功能测试就可以做了),因为网站本身的 环境搭建和其他的系统有点不同,它需要的测试环境比较麻烦,需要 web 服务器(Apache,tomcat),不过这次需求呢,网站部分只用到了 tomcat,所以只要有tomcat 即可 第四步:执行测试 11. 您以往是否曾经从事过性能测试工作?如果有,请尽可能的详细描述您以往的性能测试工作的完整过程。 是的,曾经做过网站方面的性能测试,虽然做的时间并不久(2 个月吧),当时呢,是有位网站性能测试经验非常丰富的前辈带着我一起做。 性能测试类型包括负载测试,强度测试,容量测试等 负载测试:负载测试是一种性能测试指数据在超负荷环境中运行,程序是否能够承担。 强度测试: 强度测试是一种性能测试,他在系统资源特别低的情况下软件系统运行情况 容量测试:确定系统可处理同时在线的最大用户数 在网站流量逐渐加大的情况下,开始考虑做性能测试了,首先要写好性能测试计划,根据运营数据得出流量最大的页面(如果是第一次的话,一般是首页,下载页,个人帐户页流量最大,而且以某种百分比), Web 服务器指标指标: * Avg Rps: 平均每秒钟响应次数=总请求时间 / 秒数; * Successful Rounds:成功的请求; * Failed Rounds :失败的请求; * Successful Hits :成功的点击次数; * Failed Hits :失败的点击次数; * Hits Per Second :每秒点击次数; * Successful Hits Per Second :每秒成功的点击次数; * Failed Hits Per Second :每秒失败的点击次数; * Attempted Connections :尝试链接数; 13. 您在从事性能测试工作时,是否使用过一些测试工具?如果有,请试述该工具的工作原理,并以一个具体的工作中的例子描述该工具是如何在实际工作中应用的。 17. 您认为性能测试工作的目的是什么?做好性能测试工作的关键是什么? 18. 在您以往的工作中,一条软件缺陷(或者叫Bug)记录都包含了哪些内容?如何提交高质量的软件缺陷(Bug)记录? 20. 您以往所从事的软件测试工作中,是否使用了一些工具来进行软件缺陷(Bug)的管理?如果有,请结合该工具描述软件缺陷(Bug)跟踪管理的流程。 23. 您认为在测试人员同开发人员的沟通过程中,如何提高沟通的效率和改善沟通的效果?维持测试人员同开发团队中其他成员良好的人际关系的关键是什么? 27. 在您以往的测试工作中,最让您感到不满意或者不堪回首的事情是什么?您是如何来对待这些事情的? 31. 在即将完成这次笔试前,您是否愿意谈一些自己在以往的学习和工作中获得的工作经验和心得体会?(可以包括软件测试、过程改进、软件开发或者与此无关的其他方面) 33. 你对测试最大的兴趣在哪里?为什么? 最大的兴趣就是测试有难度,有挑战性!做测试越久越能感觉到做好测试有多难。曾经在无忧测试网上看到一篇文章,是关于如何做好一名测试工程师。一共罗 列了11,12 点,有部分是和人的性格有关,有部分需要后天的努力。但除了性格有关的1,2 点我没有把握,其他点我都很有信心做好它。 刚开始进入测试行业时,对测试的认识是从无忧测试网上了解到的一些资料,当时是冲着做测试需要很多技能才能做的好,虽然入门容易,但做好很难,比开发 更难,虽然当时我很想做开发(学校专业课我基本上不缺席,因为我喜欢我的专业),但看到测试比开发更难更有挑战性,想做好测试的意志就更坚定了。 不到一年半的测试工作中,当时的感动和热情没有减退一点(即使环境问题以及自身经验,技术的不足,做测试的你一定也能理解)。 我觉得做测试整个过程中有2 点让我觉得很有难度(对我来说,有难度的东西我就非常感兴趣),第一是测试用例的设计,因为测试的精华就在测试用例的设计 上了,要在版本出来之前,把用例写好,用什么测试方法写?(也就是测试计划或测试策略),如果你刚测试一个新任务时,你得花一定的时间去消化业务需求和技 术基础,业务需求很好理解(多和产品经理和开发人员沟通就能达到目的),而技术基础可就没那么简单了,这需要你自觉的学习能力,比如说网站吧,最基本的技 术知识你要知道网站
温馨提示:内容为网友见解,仅供参考
无其他回答
相似回答