软件测试基础培训(1)

正确理解软件测试的定义正确理解软件测试的目的和原则知道软件测试的各种分类方法了解软件测试职业和素质的要求软件测试软件测试分类软件测试的周期性软件测试停止准则软件测试职业为什么需要测试什么是测试测试的基本原则基本的测试过程测试的心理学软件还有什么缺陷？软件应该没什么问题了吧！软件系统在我们生活中快速发展，从商用系统到日常消费都能看到。许多人都有这样的经历：一些软件运行结果不完全符合我们的预期。这会引起很多后果，比如经济、时间和商业信誉上的损失，更严重的可能导致人员伤亡。——中心思想：软件系统总是存在着质量问题。软件行业竞争加剧，产品交付周期缩短，客户质量诉求提高。在诸多矛盾影响下，软件产品可能隐藏大量的缺陷。由于质量保证手段的缺失或介入过晚，缺陷往往在开发后期集中爆发，严重影响项目进度，直接导致发布周期的延迟。但是，为了赢得客户占领市场，决策者往往迫不得已发布一个低质量的版本，更糟糕的是“问题未能浮出水面”，而直接被项目团队“内部消化”客户投诉越来越多，项目交付越来越困难。为解决客户反馈的问题，研发团队只能加班加点发布更多的补丁，然而补丁本身隐藏的缺陷，导致问题加剧。这样一来公司需要承担高昂的维护成本，研发团队士气低落，客户出现信任危机……。作为质量保证的有效手段，规范的软件测试可以有效缓解上述问题：•通过引入各种测试技术，尽早开展测试活动，及时发现缺陷，缩短项目周期；•通过编写高效测试用例，缩短测试执行时间，提升测试覆盖度，从而减少将缺陷遗漏给客户带来的损失；•通过规范的测试管理，以及搭建自动化测试平台，为决策者提供量化数据，随时对产品质量进行评估，使问题“浮出水面”任何人都可能犯错（eror），在代码、软件系统或文档中产生缺陷（defect,fault,bug）。假如这个缺陷被执行到了，系统就没法完成应该做的是或者做不应该做的事，导致失败（failure）。有些软件，系统或文档中的缺陷能导致失败，但并不都会。错误可能转化为缺陷，也可能不会。缺陷可能导致系统失败或失效，也可能不会。缺陷的产生是因为软件的制造者人类本身就是会犯错误的，另外还有一些客观因素比如时间紧，代码复杂，基础件复杂，技术更替或者系统原因。说了一大堆，最终还是人本身的局限性，有谁能保证不犯错呢~举个例子有一行代码：ifa0thendo…,程序员犯了错误，写成了ifa=0thendo…,但是由于某些外部限制，a=0的情况不可能出现，所以这个错误也就不具备变成缺陷的条件。另有一行代码：ifa=0.83975,thendo…,程序员犯了错误，写成了ifa=0.93975,thendo…,并且输入值完全有可能是0.83975或者0.93975，所以就具备了条件成了缺陷，但是由于出现该输入值的几率非常之小，以至于一直都未发生过，也就不能成为失效或失败。——摘自《软件评测师》有一个问题经常摆在软件工程师或项目经理面前：你们做的软件到底质量如何。定性的评价比较困难，就需要有具体的数字来衡量。什么度量数值可以客观的反应软件的质量？缺陷数量虽然不是唯一的指标，但却是最容易的。很容易理解，一个很容易找到Bug的软件质量肯定有问题。当软件测试只能找到很少或根本没有缺陷的时候，我们就能对软件有足够的信心，设计合适的测试通过大大降低了该系统的风险。即便有缺陷发现，修复这些缺陷也能提高软件的质量。挖空心思却找不到缺陷的软件当然让人放心。这是产品经理梦寐以求的目标。要从以往项目中吸取教训。对以往缺陷的分析可以帮助我们不断改进开发过程，再未来的版本或产品中避免类似的问题出现，从而提高质量。这是质量保证的一个重要内容。总结以上，软件测试有三点主要作用：提供质量度量（MeasureQuality），提供软件产品信心（ProvideConfidence），提供过程改进的依据（ImproveProcess）。测试不能表明软件中不存在错误，它只能说明软件中存在错误。谈谈你对软件测试的理解软件测试•定义1：软件测试是在规定的条件下对程序进行操作，以发现错误，对软件质量进行评估。–即软件测试是为了发现错误而执行程序的过程。•定义2：软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计的一批测试用例，并利用这些测试用例运行程序以及发现错误的过程，即执行测试步骤。背景：对于测试（testing）的一般理解是运行测试（tests），比如执行一个软件。这只是测试的一部分。测试活动存在于测试执行前与执行后：比如测试计划和控制，选择测试条件，设计测试用例，检查测试结果，评估出口准则，测试报告和结束活动。测试也包含了文档（包括代码）评审和静态分析。不同角度的测试目标也不同。比如开发阶段测试目标是尽可能找到缺陷，以便尽快修复。而验收测试则是证明开发的系统符合预期，对系统符合需求增添信心。有时候测试的目的仅在评估软件质量，并无意于修复缺陷，作用仅在于为相关方提供评估发布时间的信息。谈谈你知道的测试原则原则一：测试只是展示缺陷测试只能表明缺陷存在，却不能证明没有缺陷。测试能降低未发现缺陷留存的概率，却不能证明软件是绝对正确的。原则二：穷尽测试是不可能的测试所有的输入和条件组合是不可能的，除非是极其简单的操作。可以取而代之的是基于风险和优先级的测试。原则三：早期测试要较早发现缺陷，就要在软件周期尽可能早的时候开始测试，而且要专注于已定义的测试目标。——越早发现问题，解决的代价越小。原则四：缺陷簇生要对缺陷发现率高的模块投入更多的测试。少量模块往往隐藏了大部分缺陷。原则五：杀虫剂悖论相同的测试重复多次后就无法再找到缺陷了。要克服“杀虫剂悖论”，测试用例要不断评审修改，追加新的和不同的测试，就有可能找到新的缺陷。原则六：测试是上下文相关的测试在不同上下文环境中的执行是不同的。不能用相同的态度和手段测试不同类型的系统。原则七：无错谬论假如建立的系统不稳定或不满足客户的需要和期望，那么发现和修复缺陷就毫无帮助了。缺陷数量往往用于评估软件质量，但要是系统本身背离了用户要求，那就算缺陷再少也没有用，因为没有人会去用它。需求规格说明只是需求的不完全载体，文字说明必然有遗漏和偏差，而各人的理解更有可能出错。要不断通过各种途径保证所生产的的确是客户需要的。常用的方式就是邀请领域专家或用户尽可能的参与到开发活动中来，特别是需求评审和演示（Demo）。测试过程有哪些呢？背景：对测试来说最显而易见的部分是测试执行，但是为了让测试工作更有效和高效，测试也应该包括用于测试计划（planningtest）、用例设计、测试准备和评估结果。基本测试过程由以下过程构成：计划与控制分析与设计实施与执行分析出口准则和报告测试结束活动基本测试过程中包含了9项测试活动图示中画出了相互的顺序和关系请大家结合自己做过的项目，根据经验判断具体的活动应该归到哪一类。测试计划是定义测试目标及测试活动规格说明以满足特定目标和使命的过程。其实计划就是计划，它是一个过程，而不是完成一份计划文档。需要所有相关人员的参与，否则计划文档没有任何价值。有人把计划总结为：什么人、在什么时间内、根据什么、做什么、怎么做。测试控制是持续比较实际进展和计划的动并报告状态，如实际和计划的偏离。测试控制就是持续追踪测试活动的进度，及时发现与计划的偏差，并采取措施消除偏差或修改计划。测试计划也应该纳入测试监控的反馈。测试分析和设计是将抽象测试目标转化为具体有形测试条件和测试用例的过程。测试分析和设计有以下主要任务：评审测试依据（例如需求文档、界面规格说明书、分析报告、架构设计、设计、风险分析报告等）评审测试依据和可测试性基于测试项，规格说明，行为和软件结构进行分析并确定测试条件设计测试用例并确定优先级确定必要的测试数据来支持测试条件和测试用例设计测试环境并确定所需的基础设施和工具建立测试依据和测试用例间的双向可追溯性测试实施是搭环境，选用例；而测试执行自然就是“跑测试”了。测试实施和执行有以下主要任务：确定，实施测试用例（包括确定测试数据），以及制定优先级开发测试规程以及制定优先级，创建测试数据，和准备测试用具及自动化脚本验证测试环境搭建正确验证和更新测试依据和测试用例间的双向可追溯性根据预定的执行次序使用手工方式或工具执行测试规程记录测试执行的输出，被测试软件的版本或标示、测试工具等比较真实结果和预期结果将（真实结果和预期结果）比较的差异作为事件来报告，并且分析其原因（比如代码缺陷，测试数据，测试文档或错误的执行方法等）重测试上次失败的测试是否被修复了（确认测试），执行修改后的或原有的测试以确定修复缺陷的代码没有引入新的缺陷（回归测试）·维护测试追溯性往往会被忽视掉，在测试最后阶段来做这个事情往往是事倍功半。·很多项目之所以测试管理混乱就源于此。评估出口准则是测试执行与先前定义的测试目标做比较评估的活动。分析出口准则有以下主要任务：将测试日志和测试计划中规定的出口准则做比较确定是否需要更多的测试或者修改规定的出口准则为相关方提供测试总结报告测试出口准则也可以理解为测试退出条件，即满足条件就算测试结束。出口准则不是一成不变的。※例如原来规定所有的缺陷都要进行修复，但在项目过程中发现项目时间不够，可以通过某些正式的流程将出口准则修改为修复B类以上的缺陷。测试结束活动指的是从已完成的测试活动中整理经验，事实数据等。测试结束活动发生于某些项目里程碑，比如软件系统发布，项目完成（或取消），一个里程碑版本完成，或一个维护版本发布。测试结束活动有以下主要任务：检查计划交付物都已经交付关闭时间报告或提交更改记录编写系统验收文档完成和打包测试件，测试环境和测试基础设施，以便未来重用将测试件交付给维护组分析经验教训以确定将来项目所需要的改进用收集的信息来增进测试成熟度心理学是啥学？是否有开发人员问你为什么总是挑他的错？背景：测试评审过程中与开发过程中人的心态肯定是不同的。尽管拥有正确心态的开发人员也可以测试自己写的代码，但是独立的测试人员来完成测试不但可以更加专注，还可以获得额外的好处，比如受过训练的专业测试人员有独立的视角。但是独立性也不能取代对系统的熟悉，开发人员可以更有效地在自己的代码中找到缺陷。这里从低到高定义了独立性级别：被测试软件开发者来设计测试（最低独立性）其他人（比如其他开发人员）来设计测试同组织内其他组的人员（比如独立测试组）或测试专业人员来设计测试不同组织或公司的人员（外包或外部授权体）来设计测试在测试中寻找系统失效有可能被理解为对产品和其作者的批评，因而尽管测试对风险管理具有建设性意义，却经常被看做是非建设性活动。寻找系统失效需要的是：好奇心职业悲观主义精神挑剔的眼睛对细节的关注与开发同伴之间的良好沟通错误推测经验假如错误，缺陷和失效能得到良好的沟通，那么测试人员和分析、设计、开发人员之间的不良感觉是完全可以避免的。无论在开发过程中还是测试过程中。测试人员需要有良好的人际能力，以围绕缺陷，进度和风险事实信息为依据进行建设性的沟通。测试过程中的缺陷发现和修复可以节约后面的时间和金钱，并降低风险。有一些方法可以改进测试人员和其他角色之间的沟通和相互关系：进行合作而不是争斗——提醒所有人质量更好的系统才是共同目标围绕事实基础进行中立客观的沟通，和实际事件报告测试发现的问题而不是批评相关人，比方说我们可以写下目标和实际事件报告测试发现的问题。尽力理解其他人的感受和反应确认他们理解你所说的，你也理解他们所说的测试也有道德规范，你知道嚒？有不少公司为图方便把真实用户信息用于测试，这会损害用户利益。测试人员有责任通过一定的途径提出劝告。本章了解即可。参与测试的个人会接触到保密和需要权限才能了解的信息。一套职业道德规范可以保证这些敏感信息不会被滥用：公共——认证软件测试员的行为应当与公共利益一致客户和雇主——一致认证软件