测试

软件测试的方法一共有几种 1、按是否查看程序内部结构分为：（1）黑盒测试（black-box testing）：只关心输入和输出的结果（2）白盒测试（white-box testing）：去研究里面的源代码和程序结构2、按是否运行程序分为：（1）静态测试（static testing）：是指不实际运行被测软件，而只是静态地检查程序代码、界面或文档可能存在的错误的过程。静态测试包括：对于代码测试，主要是测试代码是否符合相应的标准和规范。对于界面测试，主要测试软件的实际界面与需求中的说明是否相符。对于文档测试，主要测试用户手册和需求说明是否真正符合用户的实际需求。（5）动态测试（dynamic testing），是指实际运行被测程序，输入相应的测试数据，检查输出结果和预期结果是否相符的过程3、按阶段划分：（1）单元测试（unit testing），是指对软件中的最小可测试单元进行检查和验证。桩模块（stud）是指模拟被测模块所调用的模块，驱动模块（driver）是指模拟被测模块的上级模块，驱动模块用来接收测试数据，启动被测模块并输出结果。（2）集成测试（integration testing），是单元测试的下一阶段，是指将通过测试的单元模块组装成系统或子系统，再进行测试，重点测试不同模块的接口部门。集成测试就是用来检查各个单元模块结合到一起能否协同配合，正常运行。（3）系统测试（system testing），指的是将整个软件系统看做一个整体进行测试，包括对功能、性能，以及软件所运行的软硬件环境进行测试。系统测试的主要依据是《系统需求规格说明书》文档。（4）验收测试（acceptance testing），指的是在系统测试的后期，以用户测试为主，或有测试人员等质量保障人员共同参与的测试，它也是软件正式交给用户使用的最后一道工序。验收测试又分为a测试和beta测试，其中a测试指的是由用户、 测试人员、开发人员等共同参与的内部测试，而beta测试指的是内测后的公测，即完全交给最终用户测试。4、黑盒测试分为功能测试和性能测试：1)功能测试（function testing），是黑盒测试的一方面，它检查实际软件的功能是否符合用户的需求。包括逻辑功能测试（logic function testing）界面测试（UI testing）UI=User Interface易用性测试（usability testing）：是指从软件使用的合理性和方便性等角度对软件系统进行检查，来发现软件中不方便用户使用的地方。兼容性测试（compatibility testing）：包括硬件兼容性测试和软件兼容性测试2)性能测试（performance testing）软件的性能主要有时间性能和空间性能两种时间性能：主要指软件的一个具体事务的响应时间（respond time）。空间性能：主要指软件运行时所消耗的系统资源。软件性能测试分为：一般性能测试：指的是让被测系统在正常的软硬件环境下运行，不向其施加任何压力的性能测试。稳定性测试也叫可靠性测试（reliability testing）：是指连续运行被测系统检查系统运行时的稳定程度。负载测试（load testing）：是指让被测系统在其能忍受的压力的极限范围之内连续运行，来测试系统的稳定性。压力测试（stress testing）：是指持续不断的给被测系统增加压力，直到将被测系统压垮为止，用来测试系统所能承受的最大压力。(Validate the system or software can allowed the biggest stress.)5、其他测试类型：回归测试（regression testing）是指对软件的新的版本测试时，重复执行上一个版本测试时的用例。(When a new build or release is deployed, repeat all the test cases which has executed in the last build or release.)冒烟测试（smoke testing），是指在对一个新版本进行大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。(validate the major function is deployed or not in software of system when a new build or release is implement.)随机测试（random testing），是指测试中所有的输入数据都是随机生成的，其目的是模拟用户的真实操作，并发现一些边缘性的错误。(means or all the test data is random, to validate the some edge bugs.)

beta测试版是什么意思

beta测试版是什么意思ta，这个希腊字母的英文写法，怎么会变成了“测试”的含义。据我所知的，广义上对测试有三个传统的称呼，alpha、beta、gamma，用来标识测试的阶段和范围。alpha 是指内测，即现在说的 CB，指开发团队内部测试的版本或者有限用户体验测试版本。beta 是指公测，即针对所有用户公开的测试版本。然后做过一些修改，成为正式发布的候选版本时（现在叫做 RC - Release Candidate），叫做 gamma。 可是，这个 beta，无论如何它是“测试”的定语，什么时候喧宾夺主变成了“测试”的中心词了？ 在此我大胆臆测一下： 由于大部分人看到的版本已经是公众测试版本，所以通常都带有 beta 字样。某人不知其含义，于是误以为 beta 的就是测试的。凡是你要表示这是个测试版本，就要带上一个 beta。但是，实际情况，总有封测/内测和公测之分啊，好，那加个定语，于是有了 Closed Beta、Open Beta。 真是越想越别扭…… 也许那人要说了，天，alpha、beta、gamma 这些软件开发工程的术语，我怎么知道？相信广大的用户也很难知道吧？嗯，确实这样，不过，你写 CB、OB 就易懂？我这个搞软件开发的反倒不懂了…… 不知道天底下那么多莫名其妙的缩写所谓何事！清清楚楚的把原意写出来不好吗？打内测、公测两个字和打 CB、OB 相比费很多事吗？在某些中文输入法下还要按 Shift 切换模式，只有更麻烦的。是不是非要写一大堆人家不懂的缩写名词才能显示自己才识渊博？当然，有可能我想的太多了，以小人之心度君子之腹了。世上之事，存在即合理。 唉，如果大家都觉得合理，我也只有认了。不过，真的很不方便而且很别扭。尤其像这种莫名其妙的缩写。 类似的还有那个什么 PK。 我所知道的，PK 最先应该出现在 UO，这个基于文字的网络游戏的始祖里头。记得高中看杂志，里面解释为 Player Killer，即在游戏里面攻击其它玩家角色（PC - Player Character）的玩家。 这个缩写我觉得还算合理，因为要去表达一个会攻击其它玩家的玩家，说起来很拗口，也没有一个固有的名词来很好的表达，PK 很好的表达了这个意思，因此这个缩写很成功。 慢慢的，有人开始说，“我昨天又被 PK 了……”云云，好像这个原意已经发生了转化。不过细想，也无不可，可以理解为 Player-Kill 这样一个动词。不过，现在为大家所熟悉的，超女里面所谓 PK 的叫法，我就不理解了。 “你们两个 PK……” “什么是 PK？” “……” 很难解释清楚了。 不得不承认，现在的世界，越来越考人的知识和信息补全能力了……

如何进行测试管理

想必每位测试管理者都有这个疑惑，我也不例外。 经过了2个公司的测试管理经历，其实总的来说不外乎测试计划、测试用例、测试执行、测试跟踪和测试总结。 今天说一下测试计划。 测试计划，首先顾名思义，应该是为测试的所有工作进行全局的计划安排，测试计划中包括了所有的测试工作，比如说测试背景、测试目的、测试范围、测试策略、测试方法、测试阶段、测试完成标准、测试工作量、测试资源、测试环境、测试进度等等。测试进度是上至管理者、下至项目经理都会关心的一件事情，并且是仅此一件事情，由此可见测试之外的人员的肤浅，当然，不能称之为肤浅，因为你得理解，他们也只能关心到这一层面了。有几个方面稍作记录，供大家参考。1、 测试工作量的估算 测试工作如同项目工作一样，都需要进行估算，且不说成本的估算，那是第三方测试关心的事情，一般公司内都是作集成测试和系统测试，而任何人都知道测试不是无休止的。所以我们需要对测试进度进行估算，但是首先我们需要估算测试的工作量。通常来说，测试人员在项目开始便介入项目，开展相应的测试工作，而并不是到了项目测试阶段才参与项目。测试的工作量是根据测试范围和测试阶段、测试方式来确定的，主要因素是测试范围，所以我们需要确定测试范围。测试范围又是通过项目需求或者产品需求规格说明而来，因此这就是我们提取测试范围和测试需求的一个好方式。通常来说，建议对测试工作进行细化，对每项工作都进行工作分解，分解的粒度可以自己定义，以可以把分解后的工作量准确的估算出为准。WBS之后，那么可以粗略的将所有工作的工作量求和，得出最终的测试工作量，当然，一般来说回归测试的遍数可以认为是3次，那么最后制定出调整因子，可以选择20%用以浮动的工作量。 如果项目能力成熟度比较高，需求文档写得比较完整和详细，那么也可以采取另外一种方法，就是根据需求文档进行推导测试工作量，这个方法是从网上找来的，在实际中试用过2次，呵呵，试用结果证明，某些参数需要根据以往的经验值调整。 以系统测试为例： 1． 由需求文档的页数计算出系统测试用例的页数（推荐比例为1.5）2． 由系统测试用例页数计算编写系统测试用例时间（推荐比例为1）3． 由系统用例计算执行系统测试时间（推荐比例为2）4． 用执行系统测试计算回归测试时间（推荐比例为0.5）2、 测试进度的制定 测试工作量制定出之后，根据测试的资源对测试进度进行估计，当然，估计的最终结果要跟项目的测试进度相对比，我本人认为可以参考COCOMO方法，进行测试工期的估算，当然，也可以根据每个公司的以往经验值进行类推估算。3、 测试进度的更新 一般情况下，测试计划不会被严格的执行，通常伴随着都是项目的延期、测试阶段的压缩，如此一来，测试进度的更新是经常发生的事情。所以需要注意的一点是，测试进度估算完毕后，排定时最好不要以具体的时间点到时间点的方式，而是采用工作量和工期天数来表示，这样在开发阶段影响了测试计划后，不需要频繁的调整。另外，在测试时间被压缩后，如果测试计划制定的详细，包括了各项测试需求和他们的优先级，那么此时可以利用测试需求的优先级，跟项目经理协商，调整测试范围和测试需求，在短的时间内优先测试重要的功能点，而一些不常用的和级别低的测试需求可以转移到用户现场或者后期进行。 对于项目中计划的更改或者需求、设计的更改，项目组一定要注意及时通知测试人员，其实就是项目的干系人，所有的干系人都需要及时通知到，这也是项目中配置管理的重要职责。需求或设计发生变动时，测试人员需要及时调整测试计划和测试用例，其中尤属测试用例的调整工作量较大，这种情况的频繁发生要求我们制定测试用例时，需要保证测试用例的条理性和通用性，避免具体数据的及早设入。另外，关于测试的更新管理应在测试计划中规定好，明确更新周期和暂停测试的原则。例如，小版本的产品更新不能大于每天三次，一个相对大的版本不能每周大于1次，规定紧急发布产品仅限于何种类型的修改或变更，由谁负责统一维护和同步更新测试环境。测试暂停可以表现在产品错误发布或者服务器数据更新等情况，是比较有必要的一个方面，有利于测试管理者有效安排测试资源的合理运用。

软件测试是做什么的？

软件测试就是利用测试工具按照测试方案和流程对产品进行功能和性能测试，甚至根据需要编写不同的测试工具，设计和维护测试系统，对测试方案可能出现的问题进行分析和评估。执行测试用例后，需要跟踪故障，以确保开发的产品适合需求。 使用人工或者自动手段来运行或测试某个系统的过程,其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别. 它是帮助识别开发完成（中间或最终的版本）的计算机软件（整体或部分）的正确度(correctness) 、完全度(completeness)和质量(quality)的软件过程；是SQA(software quality assurance)的重要子域。 Grenford J.Myers曾对软件测试的目的提出过以下观点: (1)测试是为了发现程序中的错误而执行程序的过程； (2)好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案； (3)成功的测试是发现了至今为止尚未发现的错误的测试。 然而,这种观点指出测试是以查找错误为中心,而不是为了演示软件的正确功能.但是只从字面意思理解,可能会产生误导,认为发现错误是软件测试的唯一目的,查找不出错误的测试就是没有价值的测试,实际上并非如此! (1)测试并不仅仅是为了找出错误.通过分析错误产生的原因和错误的发生趋势,可以帮助项目管理者 发现当前软件开发过程中的缺陷,以便及时改进； (2)这种分析也能帮助测试人员设计出有针对性的测试方法,改善测试的效率和有效性； (3)没有发现错误的测试也是有价值的,完整的测试是评定软件质量的一种方法 软件测试完整分类，参见：软件测试的完整分类以上的都是官话！其实说白了，软件测试就是在开发人员做出软件投放市场前，尽可能早的找出软件当中所存在的BUG！因为任何软件在理论上来说都是存在问题的，都不是完美的！尽早的找出漏洞，公司的损失也就越低！这也就是软件测试人员越来越受重视的原因！其实软件测试是一种相当乏味枯燥的工作，一般面公司都比较偏向稍微内向的人，另外测试人员还要具备相当的口才，方便与开发人员还有客户交流！

冒烟测试和回归测试的区别

冒烟测试和回归测试的区别：冒烟测试是自由测试的一种。冒烟测试(smoketest)在测试中发现问题，找到了一个Bug，然后开发人员会来修复这个Bug。这时想知道这次修复是否真的解决了程序的Bug，或者是否会对其它模块造成影响，就需要针对此问题进行专门测试，这个过程就被称为SmokeTest。在很多情况下，做SmokeTest是开发人员在试图解决一个问题的时候，造成了其它功能模块一系列的连锁反应，原因可能是只集中考虑了一开始的那个问题，而忽略其它的问题，这就可能引起了新的Bug。SmokeTest优点是节省测试时间，防止build失败。缺点是覆盖率还是比较低。回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中，新版本的连续发布使回归测试进行的更加频繁，而在极端编程方法中，更是要求每天都进行若干次回归测试。因此，通过选择正确的回归测试策略来改进回归测试的效率和有效性是非常有意义的。