浅谈持续集成构建在互联网软件测试项目中应用与分析
浅谈持续集成构建在互联网软件测试项目中应用与分析the Application of Continuous & build Integration in Internet Software Testing Project and Analyzing
阿里巴巴（中国）网络技术有限公司王亮
Alibaba（Chinia）Technology Co.,Ltd. Jonas.Wong
【摘要】：本文将介绍持续集成在互联网软件项目中的应用及案例分析，主要针对互联网行业软件项目过程中的软件测试效率和质量的研究与实践；在当前Web2.0时代，笔者抓住互联网行业的软件测试特性，在软件项目的开发过程中运用持续集成构建的思想来统一规范、流程和管理，不仅提升项目在提测之前的软件版本质量，也有利于软件项目过程的效率和质量风险控制。在浅谈持续集成及工具在项目中的应用同时，也结合笔者从事互联网软件测试的工作经验，进一步阐述与总结在软件测试过程的持续集成带来的益处与不足。
笔者会先介绍当前互联网的软件测试与传统的软件测试区别与联系，然后针对互联网软件测试的特性再结合持续集成工具思想的运用，最后将比较详细的介绍Hudson持续集成构建平台在项目中的实践与分析，从而解决了在多个项目并行开发的软件项目中应该如何应用持续集成以保持项目整理开发过程的高质量和高效率问题。
【关键词】：软件测试持续集成互联网软件项目构建自动化统一代码Web2.0
ABSTARCT: A perception on constant integration application of network software testing project and analyzing, The content is mainly about constant integration application of IT software project and focus on software project testing with quality research in network line. Presently it is the time for Web 2.0, the writer grasps network feature , adopts constant integration methods unify criterion、procedure and management. Which not only enhances software version quality, but also to the benifit for software project efficiency and quality risk control. While application of constant integration and project tools, combined with writer years experience in network testing, this content will summarize advantage and shortage occuring in the constant integration procedure.
Writer will show us the difference between tradition and modern methods in software testing, and software testing feature combined with the applicating on constant integration methods. Finally it is detailed introduction for Hudson constant integration adopted in projects practicing and analyzing，It solves the problems of many items application in concurrent development software testing involved how to apply constant integration to keep item procedure high quality and efficienc.
KEYWORDS：software testing Constant Integration Internet software project Build Automation Uniform Code Web2.0
一、引言
在互联网信息时代，随着Internet的快速增长及Web应用的不断发展，使其快速渗透到商业、电子商务、军事、工业、教育等领域和个人生活的各个方面，对我们的生活及工作产生了深远的影响。在当今市场需求和Internet技术进步的不断推动下，Web应用日益增加，互联网的软件规模不断扩大，复杂性增加，操作易用性降低，面对互联网的用户也越来越多，因此软件的质量越来越成为人们共同关注的问题，作为保证软件质量和可靠性的重要手段，软件测试已成为互联网软件项目开发过程的重要环节。
在整个软件生命周期中每个环节都存在软件测试的活动，软件测试伴随着软件开发，以检验每一个阶段性的成果是否符合质量要求和达到预先定义的目标，尽可能早的发现问题并
修复问题已成为当前互联网时代软件开发与测试过程的目的，也就孕育了要提高上游软件质量，发挥测试工程师在软件项目需求、设计阶段参与的重要性。互联网的信息和产品更新速度较传统软件产品是非常之快的，保证好软件系统的质量和稳定性，运用敏捷的测试思维、测试工具来改变传统的测试方法和测试观念，正是在互联网软件实施过程中必须面对的。针对互联网软件开发的特点，笔者结合多年的软件测试经验与测试策略、工具，总结一些比较适用的方法、流程和工具综合运用到互联网软件开发与测试过程中，综合运用持续集成构建的思想进一步保证软件质量和提升开发效率。
二、现状分析
目前在互联网软件开发测试过程中，存在效率低下、质量不高的情况，具体可以总结成以下几个方面：
第一、RD编写的代码质量不高
开发工程师在编码阶段，经常犯一些比较低级的错误，致使提测版本的代码质量较低，如空指针异常、重复犯错及违背编码规范等，常常会被在冒烟测试阶段退回而重新开发，增加提测版本质量和效率的风险，也影响到项目整体开发进度。
第二、单元测试流程不规范，质量和覆盖率较低
为了提高上游代码质量，在开发过程增加了单元测试流程和规范，各部门产品线统一推广与执行，实施一段时间后发现流程在各产品线执行执行的比较混乱，存在一些流程和规范细节问题，执行出现脱节，导致单元测试的代码质量与代码覆盖率下降，在某些项目过程中暴露的非常明显，较严重地影响了项目进度和质量。
第三、测试方法单一，测试策略陈旧，测试过程的效率和质量低下项目过程，测试工程师从立项前的需求讨论到立项后的需求、DEMO、设计评审和TC
编写几乎全程参与，一定程度提升测试工程师在项目研发过程的地方和影响力，另外也带来了测试方法单一和测试策略陈旧的问题，全靠手工测试已成为项目测试过程的瓶颈，往往就导致项目、需求排队现象，进一步分析说明了我们的测试产出比低下，效率不高。
必须改变整个项目过程的测试方法，引入新的测试工具和测试策略，必须发挥自动化的力量缓解手工测试的瓶颈和解决效率低下的问题。
第四、上线后出现故障频繁，bugfix需求增多
项目和小需求在互联网行业中更新非常快，如果过程没有更好的控制软件风险的话，上线后的需求就会出现很多故障，导致用户大量投诉，后续修复的工作量将投入很多资源去支持，一定程度上浪费了精力和物力，降低了生成率。
尤其是在大项目和新增需求发布上线后，故障的频繁让开发、测试心惊胆战，不仅要处理手中新的需求，还要跟进线上故障的bugfix需求，使工程师的精力分散，增加了质量的风险。如何把故障减少下来，如何提升测试阶段和开发前期的质量，已摆在工程师及主管们面前。
第五、无数据支撑来度量和评估开发和测试人员的质量和效率
软件过程度量目前实施的还不规范，无基本度量的数据来支撑说明存在的问题，只能通过某阶段某现象说明有问题存在，但无法给一个标准去度量和评估，这样给软件开发和测试过程的质量和效率评估带来很多不便，如何收集过程数据，如何制定度量标准，还需要进一步在软件开发过程进行分析与梳理。软件过程度量也是为保证软件质量的纽带，其实这个专题研究的内容也是比较广的，从软件工程上来讲，测试过程改进有很多模型参考，这里不展开说明。
三、互联网软件测试特性
在基于互联网软件系统开发过程中，通常就是以Web系统为基础，按照B/S的访问方式为主，包含客户端浏览器、Web应用服务器、数据库服务器的软件系统，首先从技术实现上来说，一般的Web系统结构，不论是.NET还是J2EE框架，都是多层框架设计，有用户操作界面层、业务逻辑层、数据驱动层；其次从结构上来讲，都是有客户端部分、传输网络部分和服务端部分。
1、系统架构
一个比较典型的互联网软件系统的结构示意图如图-1，前端的用户浏览器，通过网络访问应用服务器及数据库服务器传回的数据。
图-1
2、互联网软件测试特点
1）不断创新，改变易用性，留住用户
在互联网软件开发过程中，我们往往关注点会集中在用户体验、软件的创新及能为用户带来的价值，所以必须建立在用户体验基础上进行创新，留住用户，改变易用性，是互联网软件开发与测试的首要特点。
2）采用敏捷的开发测试思维，快速实现新功能，快速修复线上bug
基于创新的思维决定了我们在互联网行业的软件开发过程中，必须采取小步快走、版本微创新和快速获取用户反馈，只有这样才能体验客户第一，改变软件服务的对象观念。第二个互联网软件开发测试的特点就是快，行业觉得要快速实现新功能并快速发布，快速修复线上存在的问题。
在很多互联网公司，开发和测试团队往往是技术团队的主力军，信息更新快捷和项目需求发布的频繁，很多程度上与传统软件开发和测试过程分离开来，组成比较小的团队进行软件开发与测试，这样有利于处理需求的响应速度的提升，也有利软件开发过程的风险和资源管理。
3）采用的工具协助敏捷开发测试过程，提出了自动化测试
大家知道，如果缩短软件开发和测试过程的时间，在保证需求质量的前提下，我们必须提供我们的过程效率，那么如何提高呢？这里就引起在互联网软件项目中的自动化测试，尤其在软件测试过程，自动化测试不仅仅是测试技能的提升，更是能给测试工程师乃至整个研发团队带来质的价值和创新，是真正提高了整个研发过程的效率。自提出自动化测试以后，工程师不断研究与实践，发现自动化脚本与更新维护成本非常大，久而久之维护的工作量已
超出预期评估时间，这样导致要花大量的资源投入自动化维护，增加成本，经过大量项目实践与分析，在互联网行业的自动化不能是单纯的基于页面UI功能自动化，必须基于架构进行分层设计自动化，深化自动化技术和平台化的服务，做到持续集成才更有效。
3、敏捷测试思维
通过了解互联网系统架构和软件开发测试过程，我们必须改变以往的测试思维和测试策略，抓住Web软件测试的特点综合选取更适合的方法去运用，直到提出持续集成构建，才在项目中慢慢推广应用起来，其实就是采用敏捷的开发过程和测试思维相结合，把软件开发整个过程质量控制提到上游。
四、持续集成介绍
1、持续集成是什么
大师Martin Fowler对持续集成是这样定义的: 持续集成是一种软件开发实践，即团队开发成员经常集成它们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。
在敏捷开发与测试中，持续集成是极限编程十二实践之一（1999年Kent Beck编写的《解析极限编程》），最初被使用极限编程方法的开发人员所推捧，并在过去的几年中得到广泛应用，成为业界广为人知的软件开发实践。该实践用于解决软件开发过程中一个具体且重要的问题，即“确保当某个开发人员完成新的功能或修改代码后，整个软件仍旧能正常工作。”
简单来说，持续集成是频繁、持续的在多个团队成员的日常工作中进行集成、验证并反馈。一个典型的持续集成周期基本包含如下几个步骤：
1）持续集成服务器不断从版本代码库的服务器上检查代码状态，看代码是否有更新；
2）若发现代码有最新的提交，集成服务器就会从版本代码库服务器下载最新的代码；
3）等代码完成更新结束后，持续集成服务器调用自动化编译脚本进行代码编译；
4）运行所有的自动化测试；
5）进行代码分析
6）输出可执行的软件，提高给测试人员进行最后的测试与验证
7）通过测试工程师的测试与验证，最后发布集成到发布
通过上面的持续集成构建步骤我们不难知道，其实持续集成就是一个循环、多次运用、统一检查的过程，如图-2所示描述
图-2
2、持续集成模式
根据持续集成在项目中的运用与分析，从基础搭建模式到企业级的解决方案模式，基本可以分成下面三种模式，它们分别是递增的关系，在软件开发中随着系统的复杂度和测试件的可测性不断改进的过程，最理想的持续集成达到是统一化、流程化和服务化的过程。
1）基础模式
目前，有很多种持续集成工具，其中不乏开源产品，如Maven、Hudson平台。项目伊始，我们可以建立自己的持续集成服务器，整个项目的持续集成基础结构如图-3所示：
图-3
并发多个工程师进行代码开发，每个工程师有独立的开发环境和开发分支，然后统一提交到中央代码库，最后进行统一集成编译。
2）阶段式模式
在基础模式的框架基础上，我们增加软件开发过程单元测试、静态代码检查、UI 功能自动化检查，如图-4
阶段模式的持续集成较集成提升了很多，在集成server中增加了很多构建套件，综合利用持续集成的特点进行统一管理。
图-4
3）管道模式
阶段式持续集成重复任务多，而过程化集成的管理复杂性太高了，任何过程化上的变化都要修改已经写好的脚本，而这些脚本维护比较困难。既然以上两种模式都不灵了，所以就引出了高级模式就是管道式的持续集成模式。
管道式持续集成形式上与过程化持续集成相类似，但却在概念上有显著不同。在管道式持续集成中，所有的过程单元都运行在同一管道的上下文中，即各单元所使用的原材料都是完成相同的，即代码基线相同。当持续集成服务器发现有新的代码时，会创建新的一个管道，所有的过程单元都在这一个管道中运行，包含编译打包、单元测试、功能测试、性能测试和自动化测试。而每个单元产生的产物也在该管道中有效。如图-5所示：
图-5
不难看出管道模式的持续集成综合了基础模式和阶段模式的优点，在管道式中，每次构建都会试图从管道的一端走到另一端。因此，你不会遗漏任何一个版本的成功产品代码，基本上可以使项目研发过程全部自动化了。
3、持续集成流程
一般在互联网软件开发和测试过程中，增加了持续集成构建，在开发和测试环节会进行多次集成与构建，做的比较好的公司，如google，微软等，可以集单元测试、功能自动化测试等集成在一起构建，做到分支代码变更脚本通知一条龙智能流程化和服务化，可见下图-6流程所示。
图-6
4、持续集成优点
通过上述概念和模式的阐述，让读者很容易发现持续集成最大的优点就是降低风险，提高项目研发过程的效率和质量，迎合在互联网时代信息快速更新的现象。持续集成本身并不能帮助开发工程师找到bug，它是通过不断的测试和反馈来尽早的发现缺陷，问题发现的越
早处理问题的成本就越小越容易解决，由于无法证明通过了测试的代码是无bug存在的，所以持续集成中的测试非常重要，好的测试能够更多更快的发现当前版本中的错误。
往往在开发和测试过程中，软件的缺陷是累积性的，当缺陷很多时，就很难发现它们，利用持续集成构建的思想，在项目过程中可以尽早的发现缺陷，最大限度的降低了我们在项目后期发现缺陷的可能性和偶然性。
每成功构建运行一次就意味着之前做的代码提交可以成功集成，没有与他人提交的分支代码发生冲突，没有带来新的缺陷，有利于开发人员对项目保持自信心和提高工程师的工作激情。
持续集成在项目中的频繁部署将会使最终部署的难度降到最小，用户能够看到频繁上线的软件，并做及时的沟通反馈，有助于增强互联网模式下用户的信心和动力，也有助于Web 产品化和服务化朝着正确的方向快速发展。
5、持续集成构建分析及工具
在敏捷的软件开发和测试团队中，我们所要做的只不过是：不断的回顾、找出问题与瓶颈、不断地重构。通过不断重构持续集成基础结构以及自动化构建脚本，使其达到我们对“反馈时间”和“判断质量准确性”的要求。另外，我们已将“持续集成”扩展到整个软件开发周期，涵盖了持续部署及发布。在上面的配置文件中，不难看出在管道模式中的两个Stage分别名为“UAT”测试和交付的“Production”，它们一个用于部署新版本到我们自己的持续集成服务器，另一个用于部署新版本到一个公用的持续集成服务器。部署‘UAT’的频率为两天到一周之间，‘Production’的频率基本都是一周。这样，我们可以得到快速反馈，改进自己的产品，同时其它团队可以尽早地使用我们开发的新功能。
目前业界主流的持续集成工具主要有：Apache Continuum，CruiseControl，Hudson，Maven，LuntBuild等等，开源工具使用的比较多是Hudson框架。
五、Hudson介绍
1、Hudson简介
是一个功能强大的持续集成框架，可以持续构建和测试软件项目，并监控持续集成中生成的报告，属于开源框架，可以进行多元化插件开发与集成。
框架的优点是基于WAR包，安装部署非常简单，提供了功能完善的Web管理界面和强大的报告输出功能，另外就是有丰富的插件支持，并支持自动化安装，便于维护。
2、核心应用
由于是开源框架，在项目实践中可以不断完善我们持续集成过程存在的问题，可以集成更多的插件解决我们想要自助的集成模式。
目前在笔者参与的项目中的核心应用主要有几个部分：
1）静态代码检查（Findbugs工具）
2）单元测试（Junit）
3）代码覆盖率检查（Cov）
3、安装与配置
开源框架，有便利的安装指南，安装起来非常快捷，主要步骤有：
下载Hudson WAR包
部署到Jboss服务中
安装Html Report Plugin插件
安装Cobertura Plugin插件
安装Findbugs Plugin插件
创建分组视图和用户权限
配置也比较简单，主要配置插件和SVN代码及环境相关的条件，我们先看下配置插件，见下图所示：
Cobertura配置（图-7）
图-7
Findbugs的配置（图-8）
图-8
在Hudson持续集成平台中创建一个Job（图-9）
图-9
下面是配置代码库，以Svn代码库代码管理为例（图-10）
图-10
后续进行配置定制执行任务和执行shell脚本，然后完成生成单元测试报告和生成代码覆盖率报告的配置，最后完成生产bug扫描报告和自动发生邮件提醒的配置，当然也开源插件集成到自动发到手机提醒。都配置完成后就可以进行build 运行查看配置信息的报告，如果都通过自己在项目中需求的话，基本配置就完成了，后续在项目中就能发挥Hudson平台进行持续集成带给我们价值。
六、Hudson在项目中的应用
可以看出，持续集成的关键在于完成的自动化、完成的流程化，需要借助相关工具和平台才能完成，所以持续集成环境的搭建需要花费比较大的精力，但是环境一旦搞定后，只需要花费很短的时间去维护，而且可以给我们项目开发和测试的效率带来很大的回报。根据持续集成的重要实践，下面以笔者工作中的实例，主要是在Hudson平台进行持续集成进行应用和分析，在项目中的持续集成流程，详见下图-11说明
图-11
下面以当前正在开发的一个项目（项目名称为Campaign）为例说明Hudson在项目中的应用及分析，如图-12所示：
图-12
从Hudson持续平台上截图中可以看到，目前这个项目并行有5条分支（应用）在开发，平台上很清晰的记录了每个应用开发过程构建集成的记录信息，如成功、失败和持续的Time，图中s列颜色分别代表了：蓝色-集成构建通过，黄色-集成构建（冒烟失败）不通过，还有
一种红色-集成构建过程编译失败或发生错误。
下面分别拿不通过和通过的两个应用分支来看（Campaign-Bss和Campaign-Settle）（一）先看Campaign-Bss（图-13）分支集成情况：
图-13
图-13中标红圈起来的我们一一说明和分析下：
●左侧表示：持续集成的历史记录，可以看出有红色编译失败或错误阶段到黄色冒烟
失败的build history记录
●右侧表示：插件集成后检查，如Findbugs（静态代码）检查、静态代码检查，单元
测试和UI自动化覆盖率检查。图-13中覆盖率的图很明显随着Build次数覆盖率是
提高的，也就是说最后的Build覆盖率肯定比前一次要好，质量要高，直到达到约
定的提测条件时且主干无failed的情况下才通过（主干无failed是只单元测试脚本
在研发过程中可能有变更，如添加、修改和删除，有运行失败的风险，所以要求研
发工程师要保证单元测试脚本每次Build后必须是100%Pass）
图-14
●进一步查看Coverage Report 我们不难发现更详细的信息展现在我们眼前，如图
-14所示，比较详细的输出了工程包摘要，如Lines（代码行覆盖）这里统计代
码行共计525行，完成覆盖245行，所以结果统计是Lines为47%
●分析下下面圈起的信息是显示代码框架中（接口）实现类、方法的名称（如dao
层和bo业务的接口实现类等信息），其中com.ali.bp.bss.activity.dao.impl 在
Conditionals为N/A（说明开发还未提交代码集成），可以通过下面名称详细查
看代码覆盖率覆盖的情况
（二）再看Campaign-Settle（图-15）分支集成情况：
图-15
图-16
Campaign-Settle分支集成通过后，总体无Findbugs增加，Lines覆盖率为63%，从图-15和图-16中不难看出比Campaign-Bss分支集成后的质量要好。
通过这个项目的案例我们来做个小结与分析，从上面（一）和（二）持续集成分析报告
来看，（二）的结果最终是集成成功且冒烟通过，而（一）被测试退回重新修复问题再等待集成验证。我们通过Hudson这样的一个持续集成平台，规范了研发过程的集成测试流程，让测试协助开发一起提升整个研发过程的质量和效率，提高软件系统的上游质量。
很明显目前我们在项目中运用的持续集成还没有到达管道模式的一体化平台，像UI功能自动化当前是在另外一个系统上运行，如果没有通过在Hudson平台配置的话，在持续集成平台中是看不到运行结果报告的，另外还有一些插件有待后续进一步研究与实践，像在C++框架模式如何实现Hudson持续集成目前还是调试实践中，当然业绩也有很多好的关于持续集成的平台与案例学习与借鉴，还是希望能通过项目实践证明持续集成能真正解决当前互联网行业软件开发模式存在的一些问题。
七、结束语
结合笔者在互联网行业工作经验，浅谈了在前端基于java应用的软件测试过程中，我们运用敏捷的开发和测试思想，采用Hudson持续集成构建平台，整体打破了传统测试思维，经过多个项目的实践证明，采用持续集成提升了软件开发和测试过程的质量和效率，提高了互联网软件生产效能。
我们说持续集成并不是一蹴而就的工作，要想真正做到管道的持续集成构建模式，需要在项目过程中不断积累经验来提升与改进，当然实施持续集成也是需要根据团队的实际情况来实施，但这并不能成会“偷赖”的另一个说法。俗语道“没有做不到，只有想不到”，只要不断反思、重构与实践总结，在互联网软件测试过程中创新每天都会出现。
[笔者介绍] 笔者北理工软件工程硕士，软件评测师，高级工程师，一直从事软件开发测试工作，关注软件项目管理、测试团队管理、软件流程控制和软件性能测试及自动化测试技术。互联网时代，技术推动进步，欢迎有相同爱好的同仁探讨，联系email：jonas.wangl@https://www.360docs.net/doc/613154992.html,
参考文献：
[1] https://www.360docs.net/doc/613154992.html,/p-38337810233.html
[2] https://www.360docs.net/doc/613154992.html,/channel_content/jw-ostools-index.html--- java开源工具介绍
[3] https://www.360docs.net/doc/613154992.html,/p-11450464.html-------使用Hudson进行持续集成
[4] Rick Craig and Stefan P.Jaski —Systematic Software Testing
[5] Bill Hetzel —The Complete Guide to Software Testing
[6] Glenford J.Myers —The Art of Software Testing,1979
[7] 朱少民，2010. 软件测试方法和技术第2版
[8] [美]阿希著，李昂等译2004 机械工业出版社Web测试指南
[9] 51Testing软件测试网组编，陈卫俊等编著互联网单元测试及实践
[10] （美）达斯汀，（美）加瑞特，（美）高夫著，余昭辉等译2010 机械工业出版社自动化软件测试实施指南
[11] https://www.360docs.net/doc/613154992.html,/cn/ 知名的软件开发社区
[12] Paul M.Duvall 2008.Continuous Integration Improving Software Quality and Reducing Risk
[13] 许晓斌著2011 机械工业出版社Maven实战
[14] Sonatype Company Maven：The Definitive Guide
[15] （苏）科斯科拉著，李贝译2010.测试驱动开发的艺术
[16] 罗时飞编著电子工业出版社2008. 敏捷持续集成：高效研发之道
[17] （美）Weinberg Gerald M. Quality Software Management:Systems Thinking
[18] Ivar Jacobson,Grady Booch,James Rumbaugh The Unified Software Development Process
[19] Robert C. Martin 2002. Agile Software Development: Principles, Patterns, and Practices
[20] https://www.360docs.net/doc/613154992.html,/view/fabf6c7d27284b73f2425093.html 使用Hudson搭建日构建系统
[21] https://www.360docs.net/doc/613154992.html,/p/hudson 持续集成引擎Hudson介绍
一个成功软件测试项目的经验
本文以一个工作流测试项目为例，总结了在测试过程中积累的经验，探讨了目前国内软件开发企业在软件测试过程中遇到的问题以及解决的方法。测试项目背景和实施情况工作流在某公司软件产品线中占有重要地位。 Workflow项目是5系列中的一个小版本，主要增加了任务代办、任务代理、以及任务交接等功能，同时还修复了一些易用性和功能性的Bug。下面，我们大概介绍一下这个项目的实施情况： ●项目规模与测试人员配置： ○项目代码行数：5万行 ○开发人员配置：开发人员5名、实习生1名 ○测试人员配置：测试设计人员1名、测试执行人员2名、实习生1名 ●项目测试时的系统部署情况: ●测试预期与测试执行情况整个测试项目是比较成功的，项目的时间执行情况和预期的测试指标度量都比较接近。发现Bug总数和缺陷密度都达到了要求的标准。当然，测试周期的实际值比计划值晚了两周，原?因是在系统测试后期，为了满足PSO部门提出的定时器需求造成了一定的延期。回顾整个项目的测试过程，我有几点小小的感悟，愿在此和大家一起分享。 测试如何尽早介入 基于以前的测试经验，我们也越来越认识到测试人员应该尽早介入项目的重要性。简单地沿用测试V模型往往出现很多问题，特别是在项目进度拖延的情况下更是如此。如果测试人员一味固执地被要求严格按照V模型定义的标准来开展测试工作的话，则结果往往是在项目初期测试人员工作量极度不饱和（很多测试人员无所事事），而到了项目后期，一旦项目经理决定压缩测试时间，测试人员就不得不加班加点地工作。但是，不少朋友实践“测试人员尽早介入”的效果并不理想，例如： ●测试人员参加项目前期的各种会议，会被当作“专职的”会议记录员。 ●测试人员参加代码评审，又不甚了解程序开发语言，浪费了时间其丢失了自信。那么，在这个XXX5.2 Workflow项目中我们是怎么做的呢？实际上，在项目开发初期，测试人员可以开展很多有价值的工作，例如： ●评审需求文档的正确性和可测试性；根据需求文档整理和分析测试需求，清晰明确的测试需求是测试设计的基础。 项目管理者联盟，项目管理问题。 ●在开发设计过程中，根据需求文档和设计文档进行测试设计，测试设计方案是测试用例的保证。 ●和项目团队中的集成组和开发组协?商软件版本的编译方式和编译进度以及测试人员提取版本的方式和进度。
软件测试面精彩试题及问题详解
软件开发——软件测试 1、测试的关键问题是() A．如何组织对软件的评审 B．如何验证程序的正确性 C．如何采用综合策略 D．如何选择测试用例 2、下面不属于软件测试步骤的是 A．集成测试 B．回归测试 C．确认测试 D．单元测试 3、自底向上集成需要测试员编写驱动程序。请判断这句话的正确与否。 A．T B．F 4、测试人员要坚持原则，缺陷未修复完坚决不予通过。请判断这句话的正确与否。 A．T B．F 5、软件测试类型按开发阶段划分是？ A．需求测试、单元测试、集成测试、验证测试 B．单元测试、集成测试、确认测试、系统测试、验收测试 C．单元测试、集成测试、验证测试、确认测试、验收测试 D．调试、单元测试、集成测试、用户测试 6、如果我们可以通过覆盖率检测来判断我们是否对所有的路径都进行了测试，但是仍然可能存在未被检测出来的缺陷，原因是（） A．全部选项 B．程序可能因为缺某些路径而存在问题 C．穷举路径的测试可能不好暴露数据敏感的错误 D．就算穷举路径测试也不能保证程序符合需求 7、下面哪些属于网游的测试内容？ A．客户端性能 B．服务器端性能 C．从运行完 game.exe 打开游戏界面后可进行的各种操作、玩法 D．界面 8、下述有关负载测试，容量测试和强度测试的描述正确的有？ A．负载测试：在一定的工作负荷下，系统的负荷及响应时间。 B．强度测试：在一定的负荷条件下，在较长时间跨度内的系统连续运行给系统性能所造成的影响。 C．容量测试：容量测试目的是通过测试预先分析出反映软件系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数等），系统在其极限值状态下没有出现任何软件故障或还能保持主要功能正常运行。 D．容量测试是面向数据的，并且它的目的是显示系统可以处理目标内确定的数据容量。
一套比较完整的软件测试人员面试题
人力资源问题 你为什么选择软件测试行业 因为之前有了解软件测试这个行业，觉得他的发展前景很好。也对 根据你以前的工作经验描述一下软件开发、测试过程，由那些角色负责，你做什么 要有架构师、开发经理、测试经理、程序员、测试员 我在里面主要是负责所分到的模块执行测试用例。 结合你以前的学习和工作经验，你认为如何做好测试。 根据我以前的工作经验，我认为做好工作首先要有一个好的沟通，只有沟通无障碍了，才会有好的协作，才会有跟好的效率，再一个就是技术一定要过关，做测试要有足够的耐心，和一个良好的工作习惯，不懂的就问，实时与同事沟通这样的话才能做好测试工作。 你觉得测试最重要的是什么 尽可能的找出软件的错误 怎样看待加班问题 加班的话我没有太多的意见，但是我还是觉得如果能够合理的安排时间的话，不会有太多时候会加班的。如果一个很有个性的程序员认为自己的BUG不是BUG，怎么解决？ 首先我要确定我所提的在我认为是不是bug，如果我认为是的话我会在他面前重现这个bug和他讲这是个bug，和他沟通，或者我会找到我的直系领导让他解决。 为什么在团队中要有测试 因为软件有错误，如果没有专业的测试人员很难发现软件的一些错误。 在测试时代学习自己最大的收获是什么? 在测试时代我除了学习了测试的知识外，还看到了老师们对待测试的一种态度，明白了做任何工作都要有沟通，做测试的也要有很好的沟通才可以做好。知道自己在项目组中的位置，和开发的关系。 你对未来的规划 我想在工作中慢慢的积累经验，使自己强大起来，能够担任更重要的职务。 自己优势及缺点 我的优点是有足够的耐心对待每一件事情，善于观察事物，承受压力的能力很强。缺点可能就是我不是很爱说话，习惯做不习惯说，但是和人沟通还是没有问题的。 你为什么选择测试时代不选择51testing 因为相对比来看测试时代价钱相对公道，师资也不错，还有一个原因就是在网上查了一下测试时代的口碑不错，也是网放心过来的原因。 13.请谈谈您对测试工作的理解 我认为测试工作是找出软件产品的错误， 14.你认为测试人员需要具备哪些素质？ 我认为做测试的应该要有一定的协调能力，因为测试人员要经常与开发接触处理一些问题，如果处理不好的话会引起一些冲突这样的话工作上就会做不好。还有测试人员要有一定的耐心，有的时候做的测试很枯燥乏味的。除了要有耐心之外还要细心，不放过每一个可能的错误。 15.你为什么能够做测试这一行。 虽然说我的测试技术还不是很纯熟，但是我觉得我还是可以胜任软件测试这个工作的，因为做软件测试不仅是要求技术好，还要有一定的沟通能力，耐心、细心等外在的因素。综合起来看我认为我是胜任这个工作的。 1测试的目的是什么？ 测试的目的是找出软件产品中的错误，是软件尽可能的符合用户的要求。
一位软件测试工程师六年的工作经验总结
一位软件测试工程师六年的工作经验总结 楼主：admin分享于2011-08-24 11:20标签：无 1、分享第一条经验：“学历代表过去、能力代表现在、学习力代表未来。”其实这是一个来自国外教育领域的一个研究结果。相信工作过几年、十几年的朋友对这个道理有些体会吧。但我相信这一点也很重要：“重要的道理明白太晚将抱憾终生！”所以放在每一条，让刚刚毕业的朋友们早点看到哈！ 2、一定要确定自己的发展方向，并为此目的制定可行的计划。不要说什么，“我刚毕业，还不知道将来可能做什么？”，“跟着感觉走，先做做看”。因为，这样的观点会通过你的潜意识去暗示你的行为无所事事、碌碌无为。一直做技术，将来成为专家级人物？向管理方向走，成为职业经理人？先熟悉行业和领域，将来自立门户？还是先在行业里面混混，过几年转行做点别的？这很重要，它将决定你近几年、十年内“做什么事情才是在做正确的事情！”。 3、软件开发团队中，技术不是万能的，但没有技术是万万不能的！在技术型团队中，技术与人品同等重要，当然长相也比较重要哈，尤其在MM比较多的团队中。在软件项目团队中，技术水平是受人重视和尊重的重要砝码。无论你是做管理、系统分析、设计、编码，还是产品管理、测试、文档、实施、维护，多少你都要有技术基础。算我孤陋寡闻，我还真没有亲眼看到过一个外行带领一个软件开发团队成功地完成过软件开发项目，哪怕就一个，也没有看到。倒是曾经看到过一个“高学历的牛人”(非技术型)带一堆人做完过一个项目，项目交付的第二天，项目组成员扔下一句“再也受不了啦！”四分五裂、各奔东西。那个项目的“成功度”大家可想而知了。 4、详细制定自己软件开发专业知识学习计划，并注意及时修正和调整(软件开发技术变化实在太快)。请牢记：“如果一个软件开发人员在1、2年内都没有更新过自己的知识，那么，其实他已经不再属于这个行业了。”不要告诉自己没有时间。来自时间管理领域的著名的“三八原则”告诫我们：另外的那8小时如何使用将决定你的人生成败！本人自毕业以来，平均每天实际学习时间超过2小时。 5、书籍是人类进步的阶梯，对软件开发人员尤其如此。书籍是学习知识的最有效途径，不要过多地指望在工作中能遇到“世外高人”，并不厌其烦地教你。对于花钱买书，我个人经验是：千万别买国内那帮人出的书！我买的那些家伙出的书，!00%全部后悔了，无一本例外。更气愤的是，这些书在二手市场的地摊上都很难卖掉。“拥有书籍并不表示拥有知识；拥有知识并不表示拥有技能；拥有技能并不表示拥有文化；拥有文化并不表示拥有智慧。”只有将书本变成的自己智慧，才算是真正拥有了它。
软件工作室创业计划
软件工作室创业计划 一、背景简介 随着普通高校的扩大招生，大学毕业生也随之剧增，同时导致的结果就是大学生就业形式也更加严峻，国务院提倡并大力支持大学生创业，然而在计算机专业的大学生在创业中往往成功率低下，这是个很普遍的社会问题。而随着社会信息化的发展，计算机行业日益的增多，已经与人们的生活息息相关，计算机行业发展的步伐越来越快，计算机专业的大学生也面对着一个重大的选择：是自主创业还是进入公司奋斗。 我国大学生创业起步比较晚，一直到20世纪80年代才随改革开放逐渐发展起来，一直以来，大学生创业都是校园内外关注的亮点，而经过多年的累积，中国大学生的创业成功率也相对提高，创业思维也在实践中不断成熟。 但是计算机专业学生在创业中存在着以下几个问题和误区：首先过于形式而忽略实质，一味的追求和强调大学生的自主创业观点、过于的依赖负责人，导致这种结果的原因是对自己不够自信；出于一时的心热而忽略了自己的能力，从而在受挫之后创业热情被浇灭，还有就是专业能力问题。专业能力的低下是直接导致整个团队能力低下的主要原因；其次是大学生缺乏市场意识、盈利能力，这是许多普通高校大学生共同存在的问题，市场意识淡薄，缺乏市场定位使得整个团队发展受限、让团队的产品局限于一些商家阶段型需求而非恒久需求。 根据现在越来越多的公司，还有网络这个人流量众多的平台，软件开发工作室应运而生，越来越多的人选择了软件开发工作室。 二、任务阐述 通过接受公司或个人委托，开发设计出让客户满意的软件，帮助客户能够完成手中项目，达到致富的目的，加速社会进入网络时代。 三、创业构想 随着社会网络化的进一步发展，网络软件可以令人们的工作生活提高效率，而软件开发工作室正是公司或个人的不二选择，可以通过有实力的工作室开发出令人满意的软件，提高工作效率，加速项目推进，而工作室的发展，依靠着自身的实力还有宣传，提高知名度，慢慢发展，通过帮助企业或个人开发软件盈利，为社会的网络化提供自己的一份力。 四、形象
软件测试题目-附答案
1 一、选择题 1．软件测试的目的是（ B ）。 A ）试验性运行软件 B ）发现软件错误 C ）证明软件正确 D ）找出软件中全部错误 2．软件测试中白盒法是通过分析程序的（ B ）来设计测试用例的。 A ）应用范围 B ）内部逻辑 C ）功能 D ）输入数据 3．黑盒法是根据程序的（ C ）来设计测试用例的。 A ）应用范围 B ）内部逻辑 C ）功能 D ）输入数据 4．为了提高软件测试的效率，应该（ D ）。 A ）随机地选取测试数据 B ）取一切可能的输入数据作为测试数据 C ）在完成编码以后制定软件的测试计划 D ）选择发现错误可能性最大的数据作为测试用例 5．与设计测试用例无关的文档是（ A ）。 A ）项目开发计划 B ）需求规格说明书 C ）设计说明书 D ）源程序 6．测试的关键问题是（ B ）。 A ）如何组织软件评审 B ）如何选择测试用例 C ）如何验证程序的正确性 D ）如何采用综合策略 7．软件测试用例主要由输入数据和（ C ）两部分组成。 A ）测试计划 B ）测试规则 C ）预期输出结果 D ）以往测试记录分析 8．成功的测试是指运行测试用例后（ B ）。 A ）未发现程序错误 B ）发现了程序错误 C ）证明程序正确性 D ）改正了程序错误 9．下列几种逻辑覆盖标准中，查错能力最强的是（ D ）。 A ）语句覆盖 B ）判定覆盖 C ）条件覆盖 D ）条件组合覆盖 10．在黑盒测试中，着重检查输入条件组合的方法是（ D ）。 A ）等价类划分法 B ）边界值分析法 C ）错误推测法 D ）因果图法 11．单元测试主要针对模块的几个基本特征进行测试，该阶段不能完成的测试是（ A ）。 A ）系统功能 B ）局部数据结构 C ）重要的执行路径 D ）错误处理 12．软件测试过程中的集成测试主要是为了发现（ B ）阶段的错误。 A ）需求分析 B ）概要设计 C ）详细设计 D ）编码 13．不属于白盒测试的技术是（ D ）。 A ）路径覆盖 B ）判定覆盖 C ）循环覆盖 D ）边界值分析 14．集成测试时，能较早发现高层模块接口错误的测试方法为（ A ）。 A ）自顶向下渐增式测试 B ）自底向上渐增式测试 C ）非渐增式测试 D ）系统测试 15．确认测试以（ A ）文档作为测试的基础。 A ）需求规格说明书 B ）设计说明书 C ）源程序 D ）开发计划 16．使用白盒测试方法时，确定测试数据应根据（ A ）和指定的覆盖标准。 A ）程序内部逻辑 B ）程序的复杂度 C ）使用说明书 D ）程序的功能 17．程序的三种基本结构是（ B ）。 A ）过程子、程序、分程序 B ）顺序、选择、循环 C ）递归、堆栈、队列 D ）调用、返回、转移 18．结构化程序设计的一种基本方法是（ D ） A ）筛选法 B ）递归法 C ）归纳法 D ）逐步求精法 19．软件调试的目的是（ A ） A ）找出错误所在并改正之 B ）排除存在错误的可能性 C ）对错误性质进行分类 D ）统计出错的次数 20．程序三种基本结构的共同特点是（ D ）
软件测试人才发展现状
软件测试人才发展展望 软件测试属新兴职业，但目前国内软件产业规模越来越大，国内软件行业突破了传统的作坊式生产，从单打独斗的开发模式升级为工业化、流水线式的生产模式，导致专业的软件测试人才需求缺口巨大。据悉，中国IT人才缺口超过100万名，其中30万名以上为软件测试人才。作为工业化产品质量的“把门”者，软件测试工程师也就成为软件开发企业必不可少的技术人才。据悉，目前国内软件测试和开发人员比例大约在1：4—1：5，而国外测试和开发人员比例为1：1，可见，国内软件测试人才需求和职业发展潜力巨大。据分析，中国软件测试职业具有以下特征： 就业竞争小。据前程无忧数据显示，目前国内120万软件从业人员中，真正能担当软件测试职位的不超过5万人，人才缺口达到20万并有逐年扩大的趋势。人才的极度匮乏令许多IT企业不得不延缓甚至停止项目，为企业发展带来消极影响，但对人才就业却有积极意义。人才供不应求让软件测试人员的就业竞争压力明显小于同类其它职业，有利于从业者的身心健康。另外，由于软件测试在我国起步较晚，独立设置测试部门、对测试人员有强烈需求的多为独具慧眼的大中型IT企业。软件测试人才不需要在小企业积累经验就能获得知名企业的入门通行证，工作起点高于同类其它职业。 高薪没商量。为了吸引更多的人才，企业纷纷采取高薪策略，刚入行的软件测试人员，起步月薪就在3000-6000元左右，远高于同龄人1000-2000元的薪资水平，工作2-3年后的薪资更是翻番。 多元化发展。与其他IT职位相比，软件测试人员最大的优势就是发展方向的多元化。由于工作的特殊性，测试人员不但需要对软件的质量进行检测，而且对于软件项目的立项、管理、售前、售后的等领域都要涉及。在这过程中，测试人员不仅提升了专业的软件测试技能，还能接触到各行各业，项目管理、沟通协调、市场需求分析等能力都能得到很好的锻炼，从而为自己的多元化发展奠定了基础。经过软件测试岗位洗礼的人才往往是行业中的多面手，比其它IT人才具有更强的可塑性，在技术、管理、市场甚至其它非IT领域都能得到良好的发展。 无性别歧视。如果把软件开发领域比作男子单打，那么软件测试领域就是混合双打。由于工作的特殊，软件测试人员往往更偏好认真、耐心、细致、敏感、等个性元素，而这在一定程度上与女性的个性气质相吻合。据了解，目前很多IT企业中软件测试人员的比例更趋向平衡，甚至出现女性员工成主流的情况。 测试职业的这些特征吸引了很多软件人才的注目，山东省软件评测中心根据多年人才培养的经验，展望2011年，软件测试人才将呈现以下发展趋势： 1、中高级软件测试人才需求量进一步加大
项目经理-项目经理软件测试管理经验
项目经理软件测试管理经验 将软件测试作为项目进行管理，通常经历有四个阶段：启动阶段、计划阶段、实施阶段和收尾阶段，这些阶段相互衔接，分别完成不同任务。各阶段都围绕保证测试效率和测试有效性展开，从而保证测试质量和软件开发进度。 一、启动阶段 首先项目经理发起测试项目会议，参会人员有开发人员、需求人员、技服人员、产品推广人员和测试人员等，共同定义测试范围、测试需求、测试预算和测试进度，对所提供的测试计划进行分析，并对模糊问题进行确认。 利用PROJECT项目管理平台，项目经理评估软件开发工作量、估计开发工时、测试工作量、估计测试工时等，分配项目任务，制定项目进度计划。 （1）项目经理通过项目管理平台分配项目任务、调整项目进度、增删项目需求等，系统会自动发送邮件给任务的相关负责人，同时项目经理还可查看项目完成情况（可远程登陆）。 （2）项目组所有成员（包括开发人员、测试人员等）登陆项目管理平台，更新所承担的项目任务后，系统会自动发送邮件给项目经理及关联任务负责人。
二、计划阶段 内容包括配置测试环境、组建测试团队。分析和确定项目测试的里程碑，对可能导致项目测试失败的各种要素进行风险分析（人力风险、物力风险、未知风险等），项目经理对测试任务进行明确分工和评估，约定测试项目进度的报告机制（通过BUGFREE和PROJECT）。 布署软件缺陷管理平台BUGZILLA或MANTIS；版本控制及源代码管理平台推荐使用SVN+FishEye或VSS工具；测试用例管理工具Testopia （Bugzilla+Testopia）；项目管理平台通常使用PROJECT SERVER。 三、实施阶段 测试人员严格依照软件需求文档仔细地、探索性地执行测试用例，同时借助测试经验和程序的特征执行相应的随机测试，以便发现测试用例没有覆盖到的潜在的重大缺陷。 使用软件缺陷管理平台，实时向程序开发人员提交测试发现的缺陷、存在的问题，使软件测试与程序开发进程无缝集成。 （1）提交BUG：测试人员发现BUG，提交至缺陷管理平台后，系统会自动发送邮件给项目经理、开发人员及任务承担人员，通知新增修改任务。（2）BUG描述：在BUG提交操作时，需测试人员对如何发现BUG的测试步骤进行详细描述，通过被标注的截屏文档查看BUG故障，省去因沟通不及时而导致项目进度延缓，可以大大提高工作效率。 （3）BUG管理：通过系统的权限管理功能，项目经理登陆缺陷管理平台（可远程登陆）了解所有的BUG状态，并可变更BUG优先级、BUG修改
(完整版)软件测试基础习题及答案
1、软件测试的定义？ 软件测试是一个过程或者一系列过程，用来确认计算和代码完成了其应该完成的功能，并且不执行其不应该有的操作。 2、软件测试的目标是什么？ 是想以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，通过修正各种错误和缺陷提高软件质量，降低软件发布后由于潜在的软件错误和缺陷造成的隐患所带来的商业风险。 3、简单描述一下软件测试的原则？ 所有的软件测试都应追溯到用户需求 应当把“尽早地和不断地进行软件测试”作为测试者的座右铭 Good Enough原则 质量第一 充分注意测试中的群集现象 程序员应避免检查自己的程序 有据可依 尽量避免软件测试的随意性，要有预期结果 重视回归测试 妥善保存一切测试过程文档 4、软件测试中验证和确认的区别？ Verfication 验证： 是保证软件正确实现特定功能的一系列活动和过程。 目的是保证软件生命周期中的每一个阶段的成果满足上一个阶段设定的目标。 Validation 确认： 是保证软件满足用户需求的一系列的活动和过程。 目的是在软件开发后保证与用户需求符合 5、软件测试按照测试的基本策略可分为哪两种并加以详细说明？ 白盒测试： 白盒测试也称结构测试或逻辑驱动测试，是指基于一个应用代码的内部逻辑知识，即基于覆盖全部代码、分支、路径、条件的测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。
黑盒测试： 黑盒测试是指不基于内部设计和代码的任何知识，而基于需求和功能性的测试，黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。黑盒测试方法主要有等价类划分、边值分析、因—果图、错误推测等，主要用于软件确认测试。 6、整个软件生命周期中，需要进行哪几项测试？ 单元测试、集成测试、系统测试、验收测试 单元测试 单元测试是对软件中的基本组成单位进行的测试，如一个模块、一个过程等等。它是软件动态测试的最基本的部分，也是最重要的部分之一，其目的是检验软件基本组成单位的正确性。因为单元测试需要知道内部程序设计和编码的细节知识，一般应由程序员而非测试员来完成，往往需要开发测试驱动模块和桩模块来辅助完成单元测试。因此应用系统有一个设计很好的体系结构就显得尤为重要。 一个软件单元的正确性是相对于该单元的规约而言的。因此，单元测试以被测试单位的规约为基准。单元测试的主要方法有控制流测试、数据流测试、排错测试、分域测试等等。 集成测试 集成测试是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确。它根据集成测试计划，一边将模块或其他软件单位组合成越来越大的系统，一边运行该系统，以分析所组成的系统是否正确，各组成部分是否合拍。集成测试的策略主要有自顶向下和自底向上两种。 系统测试 系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确并非一项简单的任务，它被称为测试的“先知者问题”。因此，系统测试应该按照测试计划进行，其输入、输出和其他动态运行行为应该与软件规约进行对比。软件系统测试方法很多，主要有功能测试、性能测试、随机测试等等。 验收测试 验收测试旨在向软件的购买者展示该软件系统满足其用户的需求。它的测试数据通常是系统测试的测试数据的子集。所不同的是，验收测试常常有软件系统的购买者代表在现场，甚至是在软件安装使用的现场。这是软件在投入使用之前的最后测试。
软件测试人员应具备的能力
按照本章所说的的软件测试人员应具备的能力，分析一下自己的优势和劣势，提交一份不少于1000字的报告。 在本门的《搭建Windows 测试环境》课程中，提到了两个关键的额名称：软件测试和环境测试。通过本章的讲解：能够让我们了解到了软件测试和测试环境的知识,搭建测试环境的应该具备的知识，了解到软件的层次、分类、授权等的基本内容，了解到对软件操作的常用术语和一些简单的硬件知识。 在学习本章的软件测试环境中，测试环境就是运行软件必须具备的各种软件和硬件的集合，软件测试主要目的就是发现软件中的错误和缺陷。然而软件测试只能发现存在的错误，并不能保证软件的质量，并不是发现的错误越多，软件的质量越好；实际上正好相反，软件测试人员在软件当中的错误越多，往往证明软件的质量越差，隐藏的错误越多。 而作为一个测试人员，在搭建测试环境中，所需要做的工作： ◆搭建测试平台。 ◆学习软件使用，了解用户的需求。 ◆测试软件，发现问题。 ◆提交问题报告。 对于上面所列出的事项，就应该知道我们做为一个测试人员，最起码应该具备的技术知识，具体的可分成3大类：1、软件知识，2、硬件知识，3、网络知识。 软件知识，就是在软件知识当中，测试人员需要能够快速的学习软件的使用，了解常用的软件术语。最重要的是能够安装和使用常用软件和操作系统：作为初级测试人员，可以不具备软件开发的能力，但是如果想做好测试工作，软件开发的知识也是必须具备的，而且不仅是软件开发的知识，在测试相应软件时，还需要相应的软件方面的知识。 软件在计算机当中是一系列的指令，他不能够脱离硬件的存在，他也需要一定的载体才能够进行传播。 对软件的使用，很多用户发现在使用计算机的时候非常困难，往往找不到自己需要的功能，最后得出结论这个软件不支持这个功能。从这里让我知道软件的设计本身不符合用户的习惯；了解到该软件的功能没有很好的分类。 所以我们作为一个软件测试人员，必须先了解用户的需求，了解用户的习惯方式，最后总结出Windows 的资源管理的界面的5个名词： 1、标题栏 2、菜单栏 3、工具栏 4、状态栏 5、对话框 在学习软件的使用，帮助分类主要看清楚每个帮助的用途，同时还要有一个学习步骤让自己能够快速使用软件的主要功能。至此分有8类： 1.README 2.使用向导(Tutorials) 3.用户指南(User’s Guide) 4.参考手册(Reference Manual) 5.联机帮助 6.索引(Index) 7.收索（Search） 8.新闻组 对于硬件知识，测试人员必须能够对常见的硬件设备有一个了解和认识，所以常见的硬件有如下几点： CPU，内存，硬盘，网卡，显卡，主板，光驱，鼠标和键盘，显示器等。 硬件被安装到计算机中时比不能立刻使用，还需要安装软件进行驱动，才能够发挥硬件的最大特性。所以配置不同的驱动程序，硬件的效率也是不相同的
软件测试详细标准
软件测试标准 前言 前一版的《软件测试标准》，在测试工作中发挥了很好的指导作用。本次修改在原标准基础上，提出了新的测试理念、工作方法、组织方式，使之更贴近实际工作，真正起到纲领的作用。 一、软件测试 1、软件测试的目的 软件测试是指为了度量和提高被测试对象的质量、对测试对象进行工程设计、使用和维护的与软件开发过程并发的生命周期过程。软件测试的目的为：验证软件产品的实现状态以及实现质量。 2、软件测试相关概念 2.1白盒测试 指基于程序结构的测试，测试目标是检查程序内部逻辑结构和逻辑路径，是代码级的测试。 2．2黑盒测试 基于程序功能的测试，根据输入输出的关系推断程序功能的正确性。 2．3测试用例 测试方案，包括数据输入和相应的期望输出。依据测试用例来执行具体操作。 2．4预防性测试 其原理为：只要测试在生命周期中进行得足够早，就能够提高待测软件的质量。 2．5测试风险分析 其目的为：确定测试对象、测试的优先级、测试的深度。 2.6软件测试模型 公司目前采用V模型，实现测试与软件开发的同步进行。
2.7等价类划分 将测试对象按某种约定划分为有限个组成部分，提高测试的有效性。 2.8边界值分析 分析测试对象的所有边界值及边界附近的临界值。 二、测试工作流程 需求分析审核需求分析，编写验收测试部分用例 实地调研重点收集客户实际业务资料、操作习惯，并与需求分析作出对比 概要设计审核概要设计，从用户角度提出问题 编写集成测试用例 详细设计 审核详细设计报告，与需求分析、概要设计进行比对编写单元测试用例编写用户手册总体框架单元测试阶段提出测试计划 审核测试用例 执行测试 测试总结 集成测试阶段验收测试阶段 补充测试用例资料归档 修改测试 审核修改计划程序员提供修改清单编写测试用例执行测试 测试总结 复测测试报告复测测试用例复测 三、开发—测试流程
最新软件集成测试报告模板
技术文件 技术文件名称：XX软件集成测试报告技术文件编号： 版本： 共页 (包括封面) 拟制 审核 会签 标准化 批准 特灵达新时技术有限公司
目录 1编写目的 (2) 2术语、定义和缩略语 (2) 2.1术语、定义 (2) 2.2缩略语 (2) 3测试任务描述 (2) 4测试环境 (2) 4.1测试环境描述 (2) 4.1.1硬件环境描述 (2) 4.1.2软件环境描述 (2) 4.2测试环境比较 (2) 5故障描述 (2) 5.1××××测试模块 (2) 5.2××××测试模块 (4) 6测试结果分析 (4) 6.1××××模块测试结果分析 (4) 6.2总体测试结果分析 (4) 6.3测试结论 (4) 7测试总结 (4) 8参考资料 (5) 9附录：测试现场记录 (5)
1编写目的 < 提示：编写者可以照抄下列语句，说明《软件测试报告》的编写目的，也可以适当修改。> “编写本《软件测试报告》的目的在于以书面的形式对测试结果进行总结，给软件的评价提供依据。” 2术语、定义和缩略语 2.1术语、定义 <要求：逐项列出本文中用到的难以理解或可能引起混淆的术语及其定义。> 2.2缩略语 本文件应用了以下缩略语： <要求：逐项列出本文中用到的缩略语及其原文和汉语含义。> 3测试任务描述 <要求：简要描述本次测试的测试模块，各测试模块包含的测试任务，包括测试任务的名称、测试任务的目的和内容。> 4测试环境 4.1测试环境描述 4.1.1硬件环境描述 < 要求：描述实际测试中采用的硬件环境，主要指硬件设备的配置关系。如，采用了哪些硬件设备，各硬件之间是怎么搭配的。> 4.1.2软件环境描述 <要求：描述实际测试中采用的软件环境，如操作系统、嵌入式软件的版本、维护台版本和软件工具，以及各软件版本之间的配置关系。> 4.2测试环境比较 <要求：指出测试环境与实际运行环境（如局方的运行环境）的差异，分析这些差异将给测试结果带来的影响。> 5故障描述 5.1××××测试模块 <要求：根据《软件测试方案》中划分的模块，针对每个模块以表格的方式描述测试中出现的故障。以下的表格仅作为参考，其中第一个表指的是该模块中采用的功能测试方法的测试故障描述，第二个表采用走读等代码级测试方法的软件错误描述。> 表x：故障一览表(对于功能性测试，若无功能性测试则此表不用)：
软件测试人员面试题
你为什么选择软件测试行业 因为之前有了解软件测试这个行业，觉得他的发展前景很好。也对 责，你做什么 我在里面主要是负责所分到的模块执行测试用例。 结合你以前的学习和工作经验，你认为如何做好测试。 根据我以前的工作经验，我认为做好工作首先要有一个好的沟通，只有沟通无障碍了，才会有好的协作，才会有跟好的效率，再一个就是技术一定要过关，做测试要有足够的耐心，和一个良好的工作习惯，不懂的就问，实时与同事沟通这样的话才能做好测试工作。 你觉得测试最重要的是什么 尽可能的找出软件的错误 怎样看待加班问题 加班的话我没有太多的意见，但是我还是觉得如果能够合理的安排时间的话，不会有太多时候会加班的。 如果一个很有个性的程序员认为自己的BUG不是BUG，怎么解决？首先我要确定我所提的在我认为是不是bug，如果我认为是的话我会在他面前重现这个bug和他讲这是个bug，和他沟通，或者我会找到我的直系领导让他解决。
为什么在团队中要有测试 因为软件有错误，如果没有专业的测试人员很难发现软件的一些错误。在测试时代学习自己最大的收获是什么? 在测试时代我除了学习了测试的知识外，还看到了老师们对待测试的一种态度，明白了做任何工作都要有沟通，做测试的也要有很好的沟通才可以做好。知道自己在项目组中的位置，和开发的关系。 我想在工作中慢慢的积累经验，使自己强大起来，能够担任更重要的职务。 自己优势及缺点 的能力很强。缺点可能就是我不是很爱说话，习惯做不习惯说，但是和人沟通还是没有问题的。 你为什么选择测试时代不选择51testing 因为相对比来看测试时代价钱相对公道，师资也不错，还有一个原因就是在网上查了一下测试时代的口碑不错，也是网放心过来的原因。 13.请谈谈您对测试工作的理解 我认为测试工作是找出软件产品的错误， 14.你认为测试人员需要具备哪些素质？ 我认为做测试的应该要有一定的协调能力，因为测试人员要经常与开发接触处理一些问题，如果处理不好的话会引起一些冲突这样的话工
软件测试人员逻辑推断能力测试
软件测试人员逻辑推断能力测试题 1. 鲁道夫、菲利普、罗伯特三位青年，一个当了歌手，一个考上大学，一个加入美军陆战队，个个未来都大有作为。现已知： (1) 罗伯特的年龄比战士的大； (2) 大学生的年龄比菲利普小； (3) 鲁道夫的年龄和大学生的年龄不一样。 请问：三个人中谁是歌手？谁是大学生？谁是士兵？ 2. 美国麻省理大学的学生来自不同国家。大卫、比利、特德三名学生，一个是法国人，一个是日本人，一个是美国人。现已知： (1) 大卫不喜欢面条，特德不喜欢汉堡包； (2) 喜欢面条的不是法国人； (3) 喜欢汉堡包的是日本人； (4) 比利不是美国人。 请推测出这三名留学生分别来自哪些国家？ 3. 前提： (1) 有五栋五种颜色的房子； (2) 每一位房子的主人国籍都不同； (3) 这五个人每人只喝一种饮料，只抽一种牌子的香烟，只养一种宠物； (4) 没有人有相同的宠物，抽相同牌子的香烟，喝相同的饮料。 提示： (1) 英国人住在红房子里； (2) 瑞典人养了一条狗； (3) 丹麦人喝茶； (4) 绿房子在白房子左边； (5) 绿房子主人喝咖啡； (6) 抽Pall Mall烟的人养了一只鸟； (7) 黄房子主人抽Dunhill烟； (8) 住在中间那间房子的人喝牛奶； (9) 挪威人住第一间房子； (10) 抽混合烟的人住在养猫人的旁边； (11) 养马人住在抽Dunhill烟的人旁边； (12) 抽Blue Master烟的人喝啤酒； (13) 德国人抽Prince烟； (14) 挪威人住在蓝房子旁边； (15) 抽混合烟的人的邻居喝矿泉水。 问题：谁养鱼？ 4. 五个人来自不同地方，住不同房子，养不同动物，抽不同牌子香烟，喝不同饮料，喜欢不同食物。根据以下线索确定谁是养猫的人。 (1) 红房子在蓝房子的右边，白房子的左边（不一定紧邻）；
软件测试人员6年工作经验总结
1、分享第一条经验：“学历代表过去、能力代表现在、学习力代表未来。”其实这是一个来自国外教育领域的一个研究结果。相信工作过几年、十几年的朋友对这个道理有些体会吧。但我相信这一点也很重要：“重要的道理明白太晚将抱憾终生！”所以放在每一条，让刚刚毕业的朋友们早点看到哈！ 2、一定要确定自己的发展方向，并为此目的制定可行的计划。不要说什么，“我刚毕业，还不知道将来可能做什么？”，“跟着感觉走，先做做看”。因为，这样的观点会通过你的潜意识去暗示你的行为无所事事、碌碌无为。一直做技术，将来成为专家级人物？向管理方向走，成为职业经理人？先熟悉行业和领域，将来自立门户？还是先在行业里面混混，过几年转行做点别的？这很重要，它将决定你近几年、十年内“做什么事情才是在做正确的事情！”。 3、软件开发团队中，技术不是万能的，但没有技术是万万不能的！在技术型团队中，技术与人品同等重要，当然长相也比较重要哈，尤其在MM比较多的团队中。在软件项目团队中，技术水平是受人重视和尊重的重要砝码。无论你是做管理、系统分析、设计、编码，还是产品管理、测试、文档、实施、维护，多少你都要有技术基础。算我孤陋寡闻，我还真没有亲眼看到过一个外行带领一个软件开发团队成功地完成过软件开发项目，哪怕就一个，也没有看到。倒是曾经看到过一个“高学历的牛人”(非技术型)带一堆人做完过一个项目，项目交付的第二天，项目组成员扔下一句“再也受不了啦！”四分五裂、各奔东西。那个项目的“成功度”大家可想而知了。 4、详细制定自己软件开发专业知识学习计划，并注意及时修正和调整(软件开发技术变化实在太快)。请牢记：“如果一个软件开发人员在1、2年内都没有更新过自己的知识，那么，其实他已经不再属于这个行业了。”不要告诉自己没有时间。来自时间管理领域的著名的“三八原则”告诫我们：另外的那8小时如何使用将决定你的人生成败！本人自毕业以来，平均每天实际学习时间超过2小时。 5、书籍是人类进步的阶梯，对软件开发人员尤其如此。书籍是学习知识的最有效途径，不要过多地指望在工作中能遇到“世外高人”，并不厌其烦地教你。对于花钱买书，我个人经验是：千万别买国内那帮人出的书！我买的那些家伙出的书，100%全部后悔了，无一本例外。更气愤的是，这些书在二手市场的地摊上都很难卖掉。“拥有书籍并不表示拥有知识；拥有知识并不表示拥有技能；拥有技能并不表示拥有文化；拥有文化并不表示拥有智慧。”只有将书本变成的自己智慧，才算是真正拥有了它。 6、不要仅局限于对某项技术的表面使用上，哪怕你只是偶尔用一、二次。“对任何事物不究就里”是任何行业的工程师所不应该具备的素质。开发Windows应用程序，看看Windows程序的设计、加载、执行原理，分析一下PE文件格式，试试用SDK开发从头开发一个Windows应用程序；用VC＋＋、Delphi、Java、.Net开发应用程序，花时间去研究一下MFC、VCL、J2EE、.Net它们框架设计或者源码；除了会用J2EE、JBoss、Spring、Hibernate等等优秀的开源产品或者框架，抽空看看大师们是如何抽象、分析、设计和实现那些类似问题的通用解决方案的。试着这样做做，你以后的工作将会少遇到一些让你不明就里、一头雾水的问题，因为，很多东西你“知其然且知其所以然”！ 7、在一种语言上编程，但别为其束缚了思想。“代码大全”中说：“深入一门语言编程，不要浮于表面”。深入一门语言开发还远远不足，任何编程语言的存在都有其自身的理由，所以也没有哪门语言是“包治百病”的“灵丹妙药”。编程语言对开发人员解决具体问题的思路和方式的影响与束缚的例子俯拾皆是。我的经验是：用面对对象工具开发某些关键模块时，为什么不可以借鉴C、C51、汇编的模块化封装方式？用传统的桌面开发工具(目前主要有VC++、Delphi)进行系统体统结构设计时，为什么不可以参考来自
动画工作室的方案
一个动画工作室不同的部门负责不同的工作流程， 从剧本确定到期原画设定、分镜头脚本，这一过程需要利用的软件是2D的绘图软件结合手写板，或者干脆就用纸笔替代，这一阶段目前已知的对性能有要求的是CPU主频更敏感，2d绘图软件对多核支持度暂时利用率较低，即便以后的软件会提高，但是做画设计师并不太希望软件频繁的更新造成操作上的不适应，因为有笔有手的设计师已经足够创造他们本部分流程所需要的内容。不过高频率对于2d绘图软件仍然起提高软件和其他设备的响应速度的作用。 脚本设定完是2D的话就会进入绘制和上色阶段，目前需求尚且不明，但是如果是3D的动画角色就需要开始角色建模以及场景建模了。正是因为建模环节需要大量实时显示和选择顶点、线框，甚至一组或上万组模型，当中设计动作和K 帧需要显卡快速预览以便修改，所以为了方便设计人员流畅的拖曳和摆放众多的模型，图形卡根据模型的规模和数量逐步向高端专业卡靠拢，模型规模不大的情况下，入门级专业卡和主流中高游戏卡区别不大，模型到了中等规模入门级专业卡在MAYA和3DsMax软件中操作的帧率可以明显感觉到和游戏卡的差距。就以长沙某动画基地的3维设计部门举例在这个部门建模部分所需的专业卡规格要求不高，入门级专业卡足以应付。 建模还有另外的方向则是建立毛发或粒子的运动模型，目前大部分3维软件处理粒子模型的时候都选择使用CPU模拟物体在真实世界中的物理运动方式，而这样的模拟任务在大多数环境下都是通用运算资源消耗极大，通常需要设计员缩减规模完成模拟以后进行复制再生成，此时不论是提高频率还是增加处理器核心，甚至包括多路核心只要导演认为这个环节进度跟不上拖了整个项目后腿，无论多高的代价都回想办法提供更好的硬件提高流程的完成速度。而增强处理器性能已经是有许多已有的现成测试结果大家可以看Realflow官方网站上放出的结论。 目前已经看到的粒子模拟应用包括在3DsMax中的FumeFX插件以及可以与Maya互相导入导出的RealFlow。 上图是一个Realflow官方发布的Benchmark模型用来测试主机运行粒子模拟运算速度用的，测试很简单，将模型拷贝到指定路径，运行批处理调用无界面的Realflow命令测试，这样可以排除一些其他的影响，侧重点明显在运算子系统。从官方的测试结果来看处理器的频率与核心数量对模拟速度影响最大， 尽管在粒子、毛发等物理运算的新趋势是利用GPU与CPU协同加速，但是目前GPU更迭速度远快于开发人员对GPU性能开发的掌握程度，在用户[视觉效果设计师]没有完全掌握成熟稳定的GPU加速方案之前，花钱砸在更高频率更多内核的CPU上无疑是更明显更直接的提高工作效率的做法。 视觉设计行业最终输出成片或者动画的过程需要通过计算机渲染，因为单台计算机在渲染这个流程中应用极有限，
软件测试-填空题
1、软件质量工程包括软件质量保证、软件质量规划和软件质量控制三大方面。 2、McCall模型产品修改纬度的质量因素有可维护性、可测试性、灵活性。 3、面向对象模型不同于其他模型的主要特征是组件的密集重用。 4、有两种同行评审方法学：审查和走查。 5、RMA可以划分成三组类别内部风险管理措施，分包风险管理措施，顾客风险管理措施 6、支持性质量手段有模板和检查表。 7、依据软件系统的生命周期和其他阶段，软件质量度量划分为软件过程度量和软件产品度量。 8、软件配置发布的版本有基线版本、中间版本、修订版本。 9、SQA标准被划分成软件质量管理标准和软件项目过程标准两类。 10、软件缺陷的固有特征有软件缺陷的固有性、软件缺陷的敏感性、软件缺陷的感染性。 11、McCall模型划分了软件运行、软件转移、软件修改三个纬度的11个软件质量因素。 12、螺旋模型任何一次迭代都可划分为制定计划、风险分析和化解、工程和顾客评估四个项限。 13、依据合同评审的目标对合同评审主题进行分类为建议草案评审主题和合同草案评审主题两种类型。 14、典型的版本方针包括严格-单一活动版本方针、多版本方
针。 15、软件对属于各种质量因素的需求的符合性是由软件质量度量来测量的。 16、CAPA过程的成功运行包含如下活动：信息收集、信息分析、解决方案和改进方法的建立、改进方法的执行、跟踪。 17、常见的软件配置演化模型有线性演化模型和树演化模型。 18、软件更改的质量保证工作需要每个更改的SCI的质量保证和整个新软件系统版本的质量保证两个级别的活动。 19、从内容和重点上我们可以把质量管理标准划分成认证标准和评估标准两种类型。 20、测试人员、SQA单位是SQA专职人员。 21、CMM内容包含初始级、可重复级、已定义级、已管理级和可优化级五个等级。 22、软件质量保证的目标包括面向产品的软件开发和面向过程的软件维护两大方面。 23、开发生命周期阶段SQA部件可以划分成三类：评审、专家观点、软件测试、软件维护SQA部件和由第三方/分包商使用的SQA部件。 24、版本方针和更改方针是维护方针的主要组成。 25、外部参与方可被分类为分包商、COTS软件和重用软件模块的供货商和顾客自身三组。