软件测试
来源:互联网 发布:种子番号搜索软件 编辑:程序博客网 时间:2024/06/05 08:21
软件测试就是利用测试工具按照测试方案和流程对产品进行功能和性能测试,甚至根据需要编写不同的测试工具,设计和维护测试系统,对测试方案可能出现的问题进行分析和评估。执行测试用例后,需要跟踪故障,以确保开发的产品适合需求。
软件测试
编辑本段概念
使用人工或者自动手段来运行或测试某个系统的过程,其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别. 它是帮助识别开发完成(中间或最终的版本)的计算机软件(整体或部分)的正确度(correctness) 、完全度(completeness)和质量(quality)的软件过程;是SQA(software quality assurance)的重要子域。软件测试工程师
编辑本段原则
软件测试的几大原则: 1.软件开发人员即程序员应当避免测试自己的程序测试模型---W模型
软件测试视频
编辑本段心理学
软件测试工程师职业发展前景
软件测试技术
软件测试书籍
编辑本段内容
软件测试主要工作内容是验证(verification)和确认(validation ),下面分别给出其概念: 验证(verification)是保证软件正确地实现了一些特定功能的一系列活动,即保证软件做了你所期望的事情。(Do the right thing) 1.确定软件生存周期中的一个给定阶段的产品是否达到前阶段确立的需求的过程; 2.程序正确性的形式证明,即采用形式理论证明程序符合设计规约规定的过程; 3.评市、审查、测试、检查、审计等各类活动,或对某些项处理、服务或文件等是否和规定的需求相一致进行判断和提出报告。 确认(validation)是一系列的活动和过程,目的是想证实在一个给定的外部环境中软件的逻辑正确性。即保证软件以正确的方式来做了这个事件(Do it right) 1.静态确认,不在计算机上实际执行程序,通过人工或程序分析来证明软件的正确性; 2.动态确认,通过执行程序做分析,测试程序的动态行为,以证实软件是否存在问题。 软件测试的对象不仅仅是程序测试,软件测试应该包括整个软件开发期间各个阶段所产生的文档,如需求规格说明、概要设计文档、详细设计文档,当然软件测试的主要对象还是源程序。编辑本段分类
从是否关心软件内部结构和具体实现的角度划分 A.白盒测试 B.黑盒测试 C.灰盒测试从是否执行程序的角度
A.静态测试 B.动态测试。从软件开发的过程按阶段划分有
A.单元测试 B.集成测试 C.确认测试 D.系统测试 E.验收测试 * 测试过程按4个步骤进行,即单元测试、集成测试、确认测试和系统测试及发版测试。 * 开始是单元测试,集中对用源代码实现的每一个程序单元进行测试,检查各个程序模块是否正确地实现了规定的功能。 * 集成测试把已测试过的模块组装起来,主要对与设计相关的软件体系结构的构造进行测试。 * 确认测试则是要检查已实现的软件是否满足了需求规格说明中确定了的各种需求,以及软件配置是否完全、正确。 * 系统测试把已经经过确认的软件纳入实际运行环境中,与其它系统成份组合在一起进行测试。 单元测试 (Unit Testing) * 单元测试又称模块测试,是针对软件设计的最小单位 ─ 程序模块,进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差错。 * 单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。 1. 单元测试的内容 * 在单元测试时,测试者需要依据详细设计说明书和源程序清单,了解该模块的I/O条件和模块的逻辑结构,主要采用白盒测试的测试用例,辅之以黑盒测试的测试用例,使之对任何合理的输入和不合理的输入,都能鉴别和响应。 (1) 模块接口测试 * 在单元测试的开始,应对通过被测模块的数据流进行测试。测试项目包括: – 调用本模块的输入参数是否正确; – 本模块调用子模块时输入给子模块的参数是否正确; – 全局量的定义在各模块中是否一致; * 在做内外存交换时要考虑: – 文件属性是否正确; – OPEN与CLOSE语句是否正确; – 缓冲区容量与记录长度是否匹配; – 在进行读写操作之前是否打开了文件; – 在结束文件处理时是否关闭了文件; – 正文书写/输入错误, – I/O错误是否检查并做了处理。 (2) 局部数据结构测试 * 不正确或不一致的数据类型说明 * 使用尚未赋值或尚未初始化的变量 * 错误的初始值或错误的缺省值 * 变量名拼写错或书写错 * 不一致的数据类型 * 全局数据对模块的影响 (3) 路径测试 * 选择适当的测试用例,对模块中重要的执行路径进行测试。 * 应当设计测试用例查找由于错误的计算、不正确的比较或不正常的控制流而导致的错误。 * 对基本执行路径和循环进行测试可以发现大量的路径错误。 (4) 错误处理测试 * 出错的描述是否难以理解 * 出错的描述是否能够对错误定位 * 显示的错误与实际的错误是否相符 * 对错误条件的处理正确与否 * 在对错误进行处理之前,错误条件是否已经引起系统的干预等 (5) 边界测试 * 注意数据流、控制流中刚好等于、大于或小于确定的比较值时出错的可能性。对这些地方要仔细地选择测试用例,认真加以测试。 * 如果对模块运行时间有要求的话,还要专门进行关键路径测试,以确定最坏情况下和平均意义下影响模块运行时间的因素。 2. 单元测试的步骤 * 模块并不是一个独立的程序,在考虑测试模块时,同时要考虑它和外界的联系,用一些辅助模块去模拟与被测模块相联系的其它模块。 – 驱动模块 (driver) – 桩模块 (stub) ── 存根模块 * 如果一个模块要完成多种功能,可以将这个模块看成由几个小程序组成。必须对其中的每个小程序先进行单元测试要做的工作,对关键模块还要做性能测试。 * 对支持某些标准规程的程序,更要着手进行互联测试。有人把这种情况特别称为模块测试,以区别单元测试。 集成测试(Integrated Testing) * 集成测试 (集成测试、联合测试) * 通常,在单元测试的基础上,需要将所有模块按照设计要求组装成为系统。这时需要考虑的问题是: – 在把各个模块连接起来的时候,穿越模块接口的数据是否会丢失; – 一个模块的功能是否会对另一个模块的功能产生不利的影响; – 各个子功能组合起来,能否达到预期要求的父功能; – 全局数据结构是否有问题; – 单个模块的误差累积起来,是否会放大,从而达到不能接受的程度。 在单元测试的同时可进行集成测试, 发现并排除在模块连接中可能出现 的问题,最终构成要求的软件系统。 * 子系统的集成测试特别称为部件测试,它所做的工作是要找出集成后的子系统与系统需求规格说明之间的不一致。 * 通常,把模块集成成为系统的方式有两种 – 一次性集成方式 – 增殖式集成方式 1. 一次性集成方式(big bang) * 它是一种非增殖式组装方式。也叫做整体拼装。 * 使用这种方式,首先对每个模块分别进行模块测试,然后再把所有模块组装在一起进行测试,最终得到要求的软件系统。 2. 增殖式集成方式 * 这种集成方式又称渐增式集成 * 首先对一个个模块进行模块测试,然后将这些模块逐步组装成较大的系统 * 在集成的过程中边连接边测试,以发现连接过程中产生的问题 * 通过增殖逐步组装成为要求的软件系统。 (1) 自顶向下的增殖方式 * 这种集成方式将模块按系统程序结构,沿控制层次自顶向下进行组装。 * 自顶向下的增殖方式在测试过程中较早地验证了主要的控制和判断点。 * 选用按深度方向组装的方式,可以首先实现和验证一个完整的软件功能。 (2) 自底向上的增殖方式 * 这种集成的方式是从程序模块结构的最底层的模块开始集成和测试。 * 因为模块是自底向上进行组装,对于一个给定层次的模块,它的子模块(包括子模块的所有下属模块)已经组装并测试完成,所以不再需要桩模块。在模块的测试过程中需要从子模块得到的信息可以直接运行子模块得到。 * 自顶向下增殖的方式和自底向上增殖的方式各有优缺点。 * 一般来讲,一种方式的优点是另一种方式的缺点。 (3) 混合增殖式测试 * 衍变的自顶向下的增殖测试 – 首先对输入/输出模块和引入新算法模块进行测试; – 再自底向上组装成为功能相当完整且相对独立的子系统; – 然后由主模块开始自顶向下进行增殖测试。 * 自底向上-自顶向下的增殖测试 – 首先对含读操作的子系统自底向上直至根结点模块进行组装和测试; – 然后对含写操作的子系统做自顶向下的组装与测试。 * 回归测试 – 这种方式采取自顶向下的方式测试被修改的模块及其子模块; – 然后将这一部分视为子系统,再自底向上测试。 关键模块问题 * 在组装测试时,应当确定关键模块,对这些关键模块及早进行测试。 * 关键模块的特征: ① 满足某些软件需求; ② 在程序的模块结构中位于较高的层次(高层控制模块); ③ 较复杂、较易发生错误; ④ 有明确定义的性能要求。 确认测试(Validation Testing) * 确认测试又称有效性测试。任务是验证软件的功能和性能及其它特性是否与用户的要求一致。 * 对软件的功能和性能要求在软件需求规格说明书中已经明确规定。它包含的信息就是软件确认测试的基础。 1. 进行有效性测试(黑盒测试) * 有效性测试是在模拟的环境 (可能就是开发的环境) 下,运用黑盒测试的方法,验证被测软件是否满足需求规格说明书列出的需求。 * 首先制定测试计划,规定要做测试的种类。还需要制定一组测试步骤,描述具体的测试用例。 * 通过实施预定的测试计划和测试步骤,确定 – 软件的特性是否与需求相符; – 所有的文档都是正确且便于使用; – 同时,对其它软件需求,例如可移植性、兼容性、出错自动恢复、可维护性等,也都要进行测试 * 在全部软件测试的测试用例运行完后,所有的测试结果可以分为两类: – 测试结果与预期的结果相符。这说明软件的这部分功能或性能特征与需求规格说明书相符合,从而这部分程序被接受。 – 测试结果与预期的结果不符。这说明软件的这部分功能或性能特征与需求规格说明不一致,因此要为它提交一份问题报告。 2. 软件配置复查 n 软件配置复查的目的是保证 u 软件配置的所有成分都齐全; u 各方面的质量都符合要求; u 具有维护阶段所必需的细节; u 而且已经编排好分类的目录。 n 应当严格遵守用户手册和操作手册中规定的使用步骤,以便检查这些文档资料的完整性和正确性。 验收测试(Acceptance Testing) * 在通过了系统的有效性测试及软件配置审查之后,就应开始系统的验收测试。 * 验收测试是以用户为主的测试。软件开发人员和QA(质量保证)人员也应参加。 * 由用户参加设计测试用例,使用生产中的实际数据进行测试。 * 在测试过程中,除了考虑软件的功能和性能外,还应对软件的可移植性、兼容性、可维护性、错误的恢复功能等进行确认。 * 确认测试应交付的文档有: – 确认测试分析报告 – 最终的用户手册和操作手册 – 项目开发总结报告。 系统测试(System Testing) * 系统测试,是将通过确认测试的软件,作为整个基于计算机系统的一个元素,与计算机硬件、外设、某些支持软件、数据和人员等其它系统元素结合在一起,在实际运行环境下,对计算机系统进行一系列的组装测试和确认测试。 * 系统测试的目的在于通过与系统的需求定义作比较, 发现软件与系统的定义不符合或与之矛盾的地方。编辑本段软件测试模型
软件测试若使用经典的V模型阶段可以分为
单元测试 集成测试 系统测试V模型是最具有代表意义的测试模型 。
V模型是软件开发瀑布模型的变种,它反映了测试活动与分析和设计的关系 。 从左到右,描述了基本的开发过程和测试行为,非常明确地标明了测试过程中存在的不同级别,并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系 。 左边依次下降的是开发过程各阶段,与此相对应的是右边依次上升的部分,即各测试过程的各个阶段。 用户需求 验收测试 需求分析和系统设计 确认测试和系统测试 概要设计 集成测试 详细设计 单元测试 编码 V模型问题: 1.测试是开发之后的一个阶段。 2.测试的对象就是程序本身。 3.实际应用中容易导致需求阶段的错误一直到最后系统测试阶段才被发现。 4.整个软件产品的过程质量保证完全依赖于开发人员的能力和对工作的责任心,而且上一步的结果必须是充分和正确的,如果任何一个环节出了问题,则必将严重的影响整个工程的质量和预期进度W模型
W模型由Evolutif公司公司提出,相对于V模型,W模型增加了软件各开发阶段中应同步进行的验证和确认活动。W模型由两个V字型模型组成,分别代表测试与开发过程,图中明确表示出了测试与开发的并行关系。 W模型强调:测试伴随着整个软件开发周期,而且测试的对象不仅仅是程序,需求、设计等同样要测试,也就是说,测试与开发是同步进行的。W模型有利于尽早地全面的发现问题。例如,需求分析完成后,测试人员就应该参与到对需求的验证和确认活动中,以尽早地找出缺陷所在。同时,对需求的测试也有利于及时了解项目难度和测试风险,及早制定应对措施,这将显著减少总体测试时间,加快项目进度。 但W模型也存在局限性。在W模型中,需求、设计、编码等活动被视为串行的,同时,测试和开发活动也保持着一种线性的前后关系,上一阶段完全结束,才可正式开始下一个阶段工作。这样就无法支持迭代的开发模型。对于当前软件开发复杂多变的情况,W模型并不能解除测试管理面临着困惑。软件测试
H模型
H模型中, 软件测试过程活动完全独立,贯穿于整个产品的周期,与其他流程并发地进行,某个测试点准备就绪时,就可以从测试准备阶段进行到测试执行阶段。软件测试可以尽早的进行,并且可以根据被测物的不同而分层次进行。软件测试
X模型
X模型也是对V模型的改进,X模型提出针对单独的程序片段进行相互分离的编码和测试,此后通过频繁的交接,通过集成最终合成为可执行的程序。X模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试,此后将进行频繁的交接,通过集成最终成为可执行的程序,然后再对这些可执行程序进行测试。己通过集成测试的成品可以进行封装并提交给用户,也可以作为更大规模和范围内集成的一部分。多根并行的曲线表示变更可以在各个部分发生。由图中可见,X模型还定位了探索性测试,这是不进行事先计划的特殊类型的测试,这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。但这样可能对测试造成人力、物力和财力的浪费,对测试员的熟练程度要求比较高。软件测试
前置模型
软件测试职业发展前景 随着我国软件业的发展,专业的软件测试人员成为了众多知名公司追逐的对象,软件测试有着广阔的发展前景,具体可以分为: • 初级测试工程师:初级职位,开发测试脚本,执行测试 •测试工程师 / 程序分析员:编写自动测试脚本程序 •高级测试工程师 / 程序分析员:确定测试过程并指导初级测试工程师 •测试组负责人:监管 1-3 人工作,负责规模 / 成本估算 •测试 / 编程负责人:监管 4-8 人,安排和领导任务完成,提出技术方法 •测试 / 质量保证 / 项目经理:负责 8 名以上人员的一个或多个项目,负责全生存期 •业务 / 产品经理:负责多个项目的人员管理,负责项目方向和业务盈亏编辑本段技术之路
• 软件测试工程师定义
软件测试工程师简单的说是软件开发过程中的质量检测者和保障者,负责软件质量的把关工作。软件测试工程师(Software Testing Engineer)的主要工作职责是,理解产品的功能要求,并对其进行测试,检查软件有没有错误(Bug),决定软件是否具有稳定性(Robustness),写出相应的测试规范和测试用例。简而言之,软件测试工程师在一家软件企业中担当的是“质量管理”角色,及时纠错及时更正,确保产品的正常运作。[1]工作内容
1、编写软件测试计划,设计软件测试脚本和用例,搭建软件测试环境; 2、执行软件项目测试,包括功能测试、性能测试、易用性测试等; 3、整理、分析、报告并追踪软件缺陷,并确认软件测试问题得以解决; 4、撰写软件测试结果分析报告,预先评估项目的风险,编写其它相关文档; 5、结合研发软件产品项目情况,制定相应的软件、项目版本控制制度。 • 至少是一名软件开发工程师 • 软件测试技术主管 • 软件测试设计师编辑本段管理之路
• 测试主管 • 测试管理者 • 项目主管 • 产品发布主管编辑本段测试工具介绍
AutoRunner 是国内第一款自动化测试工具,可以用来完成功能测试、回归测试、每日构建测试与自动回归测试等工作。是具有脚本语言的、提供针对脚本完善的跟踪和调试功能的、支持IE测试和Windows native测试的自动化测试工具。 TestCenter 是一款功能强大测试管理工具,它可以帮助您:实现测试用例的过程管理,对测试需求过程、测试用例设计过程、业务组件设计实现过程等整个测试过程进行管理。实现测试用例的标准化即每个测试人员都能够理解并使用标准化后的测试用例,降低了测试用例对个人的依赖;提供测试用例复用,用例和脚本能够被复用,以保护测试人员的资产;提供可伸缩的测试执行框架,提供自动测试支持;提供测试数据管理,帮助用户同意管理测试数据,降低测试数据和测试脚本之间的耦合度。 TAR(Terminal AutoRunner)适用于VT100、VT220等标准的应用系统,支持命令行模式和窗口模式(使用Cursors编写的应用程序),支持自动录制脚本、所见即所得的资源和脚本编辑,稳定的自动同步功能。是目前国内最好的银行业务测试工具. LoadRunner 是一种预测系统行为和性能的工业标准级负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题,LoadRunner 能够对整个企业架构进行测试。通过使用LoadRunner , 企业能最大限度地缩短测试时间, 优化性能和加速应用系统的发布周期。目前企业的网络应用环境都必须支持大量用户,网络体系架构中含各类应用环境且由不同供应商提供软件和硬件产品。难以预知的用户负载和愈来愈复杂的应用环境使公司时时担心会发生用户响应速度过慢, 系统崩溃等问题。这些都不可避免地导致公司收益的损失。 TestDirector 是全球最大的软件测试工具提供商Mercury Interactive公司生产的企业级测试管理工具,也是业界第一个基于Web的测试管理系统,它可以在您公司内部或外部进行全球范围内测试的管理。通过在一个整体的应用系统中集成了测试管理的各个部分,包括需求管理,测试计划,测试执行以及错误跟踪等功能,TestDirector极大地加速了测试过程。编辑本段测试用例编写规范
1 目的:统一测试用例编写的规范,以保证使用最有效的测试用例,保证测试质量。 2 范围:适用于公司对产品的业务流程、功能测试测试用例的编写。 3 术语解释 3.1 测试分析:对重要业务、重要流程进行测试前的分析。 3.2 业务流程测试用例:关于产品业务、重要流程的测试用例。 4 业务流程测试用例编写原则 4.1 系统性 4.1.1 对于系统业务流程要能够完整说明整个系统的业务需求、系统由几个子系统组成以及它们之间的关系; 4.1.2 对于模块业务流程要能够说明清楚子系统内部功能、重要功能点以及它们之间的关系; 4.2 连贯性 4.2.1 对于系统业务流程来说,各个子系统之间是如何连接在一起,如果需要接口,各个子系统之间是否有正确的接口;如果是依靠页面链接,页面链接是否正确; 4.2.2 对于模块业务流程来说,同级模块以及上下级模块是如何构成一个子系统,其内部功能接口是否连贯; 5 测试用例设计的方法 5.1 等价类划分法 5.1.1 确定等价类的原则 5.1.1.1 如果输入条件决定了取值范围,或值的个数,则可以确立一个有效等价类和两个无效等价类。 5.1.1.2 如果输入条件规定了输入值的集合,或者规定了“必须如何”的条件,此时可确立一个有效等价类和一个无效等价类; 5.1.1.3 如果输入条件是一个布尔量,则可以确定一个有效等价类和一个无效等价类; 5.1.1.4 如果规定了输入数据的一组值,而且程序对每个输入值分别进行处理,此时可为每一个输入值确立一个有效等价类,此外,针对这组值确立一个无效等价类,它是所有不允许输入值的集合; 5.1.1.5 如果规定了输入数据必须遵守的规则,则可以确立一个有效等价类(符合规则)和若干个无效等价类(从不同的角度违反规则)。 5.1.1.6 如果确知,已划分的等价类中各元素在程序中的处理方式不同,则应将此等价类进一步划分成更小的等价类。 5.1.2 测试用例的选择原则 5.1.2.1 为每一个等价类规定一个唯一的编号; 5.1.2.2 设计一个新的测试用例,使其尽可能多的覆盖尚未被覆盖的有效等价类,重复这一步,直至所有的有效等价类都被覆盖过; 5.1.2.3 设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步,直至所有的无效等价类都被覆盖为止。 5.2 边界值分析法 5.2.1 测试用例的选择原则 5.2.1.1 如果输入了条件规定了值的范围,则应取刚达到这个范围的边界值,以及刚刚超越这个边界范围的值作为测试输入数据; 5.2.1.2 如果输入条件规定了值的个数,则用最大个数、最小个数、比最大多1、比最小小1的数作为测试输入数据; 5.2.1.3 根据规格说明的每个输出条件,使用前面的原则; 5.2.1.4 如果程序的规格说明给出的输入输出域是有序集合,则应选取集合的每一个元素和最后一个元素作为测试用列; 5.2.1.5 如果程序中使用了一个内部数据结构,则应当选择这个内部数据结构的边界上的值作为测试用例; 5.2.1.6 分析规格说明,找出其他可能的边界条件。 6 测试用例设计的原则 6.1 全面性 6.1.1 应尽可能覆盖程序的各种路径 6.1.2 应考虑存在跨年、跨月的数据 6.1.3 大量数据并发测试的准备 6.2 正确性 6.2.1 输入界面后的数据应与测试文档所记录的数据一致 6.2.2 预期结果应与测试数据发生的业务吻合 6.3 符合正常业务惯例 6.3.1 测试数据应符合用户实际工作业务流程 6.3.2 兼顾各种业务变化的可能 6.4 仿真性 人名、地名、电话号码等应具有模拟功能,符合一般的命名惯例;不允许出现与知名人士、小说中人物名等雷同情况。 6.5 可操作性 测试用例中应写清测试的操作步骤,不同的操作步骤相对应的操作结果。 7 测试用例编写格式细则 7.1 测试用例内容 7.1.1 具体实施可以采用EXCEL和图形相结合,可用EXCEL编写测试用例的同时插入图形来加以说明。测试用例设计的内容可由:模块名、功能说明或图形说明、测试用例输入、应输出结果、实际输出结果、结论、BUG编号、BUG级别8部分组成。 7.1.2 在测试用例设计模版中有“业务流程测试用例设计模版”(包含整体业务流程)和“功能测试用例设计模版”两个模板可按需要选择。 7.2 测试用例表格格式 7.2.1 表格内容的字体为宋体; 7.2.2 表格内容的字型为12号; 8 测试用例优先级 测试用例优先级 描述 A 测试计划中重要的模块功能和业务流程 B 测试计划中比较重要的模块功能和业务流程 C 测试计划中次重要的模块功能和业务流程 D 测试计划中不重要的模块功能和业务流程 E 系统小单元、系统容错功能 对于A、B 级应重点考虑 9 BUG级别 参考软件测试停止标准中的错误级别.编辑本段外包软件测试
外包软件测试就是指软件企业将软件项目中的全部或部分测试工作,交给提供软件外包测试服务的公司,由他们为软件进行专门的测试。这样做的好处有两个:一方面软件企业可以更好地专注核心竞争力业务,同时降低软件项目成本;另一方面,由第三方专业的测试公司进行测试,无论在技术上还是管理上,对提高软件测试的有效性都具有重要意义。 外包软件测试行业前景非常看好,发展空间很大。IDG的数据显示,最近几年,中国的软件外包产业年均增长率为36.5%,正处于快速发展的阶段,2008年预计已达到16.9亿美元的市场规模。目前韩日、欧美国家的软件企业纷纷关注中国市场,而作为软件外包强国的印度,在其国内处于前几位的软件外包服务商也准备来“分一杯羹”。从目前市场来看,选择将部分软件测试工作进行外包的公司主要是微软、IBM等国际软件旗舰企业,他们利用第三方专业软件测试公司,在产品发布前对软件进行一系列的集成测试和系统测试,既保证了测试工作的全面性,又节省了人力、物力的开销。最重要的是,测试结果往往好于这些软件企业最初的预期,效果非常令人满意。软件企业和提供软件外包测试服务的公司进行合作,只要达成双赢,两方皆大欢喜,这样的合作就会越来越多,项目也会越做越大。 主要业务类型 ·本地化软件测试 ·国际化软件测试 主要测试的范围 ·本地化语言质量测试 ·国际化软件的功能和性能测试 测试工作主要方式 ·公司内部(In house)执行的测试 ·派驻客户开发中心的现场测试(On site)。编辑本段发展现状与前景
软件开发中出现错误或缺陷的机会越来越多
市场对软件质量重要性的认识逐渐增强。所以,软件测试在软件项目实施过程中的重要性日益突出。但是,现实情况是,与软件编程比较,软件测试的地位和作用,还没有真正受到重视,对于很多人(甚至是软件项目组的技术人员)还存在对软件测试的认识误区,这进一步影响了软件测试活动开展和真正提高软件测试质量。 (1)误区之一:软件开发完成后进行软件测试 人们一般认为,软件项目要经过以下几个阶段:需求分析,概要设计,详细设计,软件编码,软件测试,软件发布。据此,认为软件测试只是软件编码后的一个过程。这是不了解软件测试周期的错误认识。软件测试是一个系列过程活动,包括软件测试需求分析,测试计划设计,测试用例设计,执行测试。因此,软件测试贯穿于软件项目的整个生命过程。在软件项目的每一个阶段都要进行不同目的和内容的测试活动,以保证各个阶段的正确性。软件测试的对象不仅仅是软件代码,还包括软件需求文档和设计文档。软件开发与软件测试应该是交互进行的,例如,单元编码需要单元测试,模块组合阶段需要集成测试。如果等到软件编码结束后才进行测试,那么,测试的时间将会很短,测试的覆盖面将很不全面,测试的效果也将大打折扣。更严重的是如果此时发现了软件需求阶段或概要设计阶段的错误,如果要修复该类错误,将会耗费大量的时间和人力。 (2)误区之二:软件发布后如果发现质量问题,那是软件测试人员的错 这种认识很打击软件测试人员的积极性。软件中的错误可能来自软件项目中的各个过程,软件测试只能确认软件存在错误,不能保证软件没有错误,因为从根本上讲,软件测试不可能发现全部的错误。从软件开发的角度看,软件的高质量不是软件测试人员测出来的,是靠软件生命周期的各个过程中设计出来的。出现软件错误,不能简单地归结为某一个人的责任,有些错误的产生可能不是技术原因,可能来自于混乱的项目管理。应该分析软件项目的各个过程,从过程改进方面寻找产生错误的原因和改进的措施。 (3)误区之三:软件测试要求不高,随便找个人多都行 很多人都认为软件测试就是安装和运行程序,点点鼠标,按按键盘的工作。这是由于不了解软件测试的具体技术和方法造成的。随之软件工程学的发展和软件项目管理经验的提高,软件测试已经形成了一个独立的技术学科,演变成一个具有巨大市场需求的行业。软件测试技术不断更新和完善,新工具,新流程,新测试设计方法都在不断更新,需要掌握和学习很多测试知识。所以,具有编程经验的程序员不一定是一名优秀的测试工程师。软件测试包括测试技术和管理两个方面,完全掌握这两个方面的内容,需要很多测试实践经验和不断学习精神。 (4)误区之四:软件测试是测试人员的事情,与程序员无关开发和测试是相辅相成的过程 需要软件测试人员、程序员和系统分析师等保持密切的联系,需要更多的交流和协调,以便提高测试效率。另外,对于单元测试主要应该由程序员完成,必要时测试人员可以帮助设计测试样例。对于测试中发现的软件错误,很多需要程序员通过修改编码才能修复。程序员可以通过有目的的分析软件错误的类型、数量,找出产生错误的位置和原因,以便在今后的编程中避免同样的错误,积累编程经验,提高编程能力。 (5)误区之五:项目进度吃紧时少做些测试,时间富裕时多做测试 这是不重视软件测试的表现,也是软件项目过程管理混乱的表现,必然会降低软件测试的质量。一个软件项目的顺利实现需要有合理的项目进度计划,其中包括合理的测试计划,对项目实施过程中的任何问题,都要有风险分析和相应的对策,不要因为开发进度的延期而简单的缩短测试时间、人力和资源。因为缩短测试时间带来的测试不完整,对项目质量的下降引起的潜在风险,往往造成更大的浪费。克服这种现象的最好办法是加强软件过程的计划和控制,包括软件测试计划、测试设计、测试执行、测试度量和测试控制。 (6)误区之六:软件测试是没有前途的工作,只有程序员才是软件高手 由于我国软件整体开发能力比较低,软件过程很不规范,很多软件项目的开发都还停留在“作坊式”和“垒鸡窝”阶段。项目的成功往往靠个别全能程序员决定,他们负责总体设计和程序详细设计,认为软件开发就是编写代码,给人的印象往往是程序员是真正的牛人,具有很高的地位和待遇。因此,在这种环境下,软件测试很不受重视,软件测试人员的地位和待遇自然就很低了,甚至软件测试变得可有可无。随着市场对软件质量的不断提高,软件测试将变得越来越重要,相应的软件测试人员的地位和待遇将会逐渐提高。在微软等软件过程比较规范的大公司,软件测试人员的数量和待遇与程序员没有多大差别,优秀测试人员的待遇甚至比程序员还要高。软件测试将会成为一个具有很大发展前景的行业,软件测试大有前途,市场需要更多具有丰富测试技术和管理经验的测试人员,他们同样是软件专家。这两年来国内软件测试人员的需求不断增大,越来越多的IT企业认识到了软件测试的重要性,这种可喜的现状与发展趋势让笔者对我国软件业的发展重新抱有较大的希望。 尽管这是一门崭新的学科,目前在国内的发展仍处于"婴儿"阶段,但看到越来越多的软件公司为软件测试招兵买马,看到越来越多的技术人员投入到软件测试中,我就情不自禁地感叹:机会来了!这机会不仅仅是某一个人的,而是所有人的,它对每个人都是公平的,学的领域需要新的理论新的工具新的方法,由于国内的软件测试还处在一个比较初级的阶段,没有人确切地知道它需要什么样的基础,也没有人确切地知道它应该怎样发展,因此这个领域需要大家来共同革命,以促进它的深入发展。软件测试的前景
随着软件产业的发展,软件产品的质量控制与质量管理正逐渐成为软件企业生存与发展的核心。几乎每个大中型IT企业的软件产品在发布前都需要大量的质量控制、测试和文档工作,而这些工作必须依靠拥有娴熟技术的专业软件人才来完成。软件测试工程师就是这样的一个企业重头角色。业内人士分析,该类职位的需求主要集中在沿海发达城市,其中北京和上海的需求量分别占去33%和29%。民企需求量最大,占19%,外商独资欧美类企业需求排列第二,占15%。然而,目前的现状是:一方面企业对高质量的测试工程师需求量越来越大越大,另一方面国内原来对测试工程师的职业重视程度不够,使许多人不了解测试工程师具体是从事什么工作。这使得许多IT公司只能通过在实际工作中进行淘汰的方式对测试工程师进行筛选,因此国内在短期将出现测试工程师严重短缺的现象。根据对近期网络招聘IT人才情况的了解,许多正在招聘软件测试工程师的企业 很少能够在招聘会上顺利招到合适的人才。在具体工作过程中,测试工程师的工作是利用测试工具按照测试方案和流程对产品进行功能和性能测试,甚至根据需要编写不同的测试用例,设计和维护测试系统,对测试方案可能出现的问题进行分析和评估。对软件测试工程师而言,必须具有高度的工作责任心和自信心。任何严格的测试必须是一种实事求是的测试,因为它关系到一个产品的质量问题,而测试工程师则是产品出货前的把关人,所以,没有专业的技术水准是无法胜任这项工作的。同时,由于测试工作一般由多个测试工程师共同完成,并且测试部门一般要与其他部门的人员进行较多的沟通,所以要求测试工程师不但要有较强的技术能力而且要有较强的沟通能力。- 软件测试
- 软件测试
- 软件测试
- 软件测试
- 软件测试
- 软件测试
- 软件测试
- 软件测试
- 软件测试
- 软件测试
- 软件测试
- 软件测试
- 软件测试
- 软件测试
- 软件测试
- 软件测试
- 软件测试
- 软件测试
- 在VS2010中Ajax的AsyncFileUpload控件出现错误的解决
- ACE:Reactor框架处理事件和多个I/O流
- android中imageButton显示本地图片
- 数据表的设计原则
- RequestDispatcher接口
- 软件测试
- jQuery入门简介
- MFC托盘图标
- OPP,OOP,AOP,IoC,DI的个人理解
- android之检测手机电池
- 51Job自动收藏职位
- 对疲劳最有疗效的食物
- java多线程
- CVSNT (2.5.03 build 2151) 服务器搭建+ Myeclipse CVS(wincvs)