软件测试的流程

软件测试的流程:软件测试流程与文档写作软件测试的各个阶段测试过程PDCA戴明循环检查需求确定测试需求测试需求的依据与收集测试需求的分析形成测试需求分析测试需求的优先级测试需求的覆盖率和覆盖程度软件测试流程（需求阶段）l需求分析阶段测试人员需要做哪些工作？参与需求调研测试计划定义l定义ü《ANSI/IEEE软件测试文档标准829-1983》将测试计划定义为：¡°一个叙述了预定的测试活动的范围、途径、资源及进度安排的文档。它确认了测试项、被测特征、测试任务、人员安排，以及任何偶发事件的风险。¡±l注意：ü重要的ü在工作过程中，如果无法按照自己预定的进度像一把尺子，而不是鞭子。你在工作中不断的用这把尺子来衡量ü测试计划由谁来写？是计划过程，而不是产生的文档。完成，也不要害怕或者沮丧，进度的作用就自己，那些地方需要调整。ü测试计划根据什么写？撰写测试计划l重要的l你在工作中不断来衡量中的哪些地方需要调整。l测试计划的内部作用ü作为测试计划的结果，ü存储计划执行的细节，让测试人员来进行同行评审ü存储计划进度表、测试环境等更多的信息。l测试计划的外部作用ü为客户提供一种信心是计划过程，而不是产生的文档。测试工作让相关人员人员来评审ü向客户提供有关测试过程、人员的技能、资源、使用工具等信息。经典面试问题

l测试计划的内容？答：一个计划包括：1）需要做什么2）怎么去做3）需要花费多长时间4）需要的资源（人力、测试环境和工具）5）成本6）如果不能完成计划会造成的影响7）测试的优先级8）每一部分的测试由谁来负责经典面试问题9)计划中每一部分相互之间联系的风险10）关键的检查点数据11）测试的入口和退出的标准12）对测试过程的主要执行者和贡献者13）如果项目能提前完成将有的潜在利益测试计划要尽早开始。可以在需求定义过程开始时就开始测试计划。测试计划的目的l测试计划的目的是处理以下重要的问题：ü测试策略ü资源利用ü风险ü优先级风险评估l一个测试计划成功的关键的一点就是去识别和评估项目风险。l风险就是那些会出影响项目造价和进程的概率。在测试中，风险既包括那些项目的失败的可能性也包括由失败造成的影响。它具有不确定性和代价巨大的特征。l风险评估就是的可能性和潜在影响。在一个风险分析活动中，对于一个管理者来说，就是通过输入或是输出提高风险鉴别能力。错从而估计项目障碍发生项目风险评估l风险有很多种形式，ü应用软件程序不能满足最终用户的期望（说明的或是未说明的）ü应用软件程序不能按时（可以是合同约定的时间也可以是市场上投资后得不到预期回报）交给客户。以下是两种主要的分类：；不能管理的风险能导致很多问题，包括：ü增加测试成本ü测试周期延长ü服务停止ü矫正维护费用过多测试策略l当需求和项目的风险被充分理解后，测试计划的下一步是确定测试策略。

测试策略回答了以下问题：ü我们为什么测试？ü我们计划做什么以及不做什么？ü我们将如何做测试？测试计划注意事项l增强测试计划的实用性ü计划是作为动词而不是名词使用的，或者应该叫做¡°计划测试¡±更恰当一些，重点在于对整个测试项目工作的计划ü而《测试计划》只是用来记录最终结果的那份文档而已。再说得明确一点，是¡°计划测试工作¡±，而不是¡°编制测试计划¡±。ü一切从实际出发，千万不要流于形式！l坚持“5W1H”规则，明确内容与过程üWHAT、WHY、WHEN、WHERE、WHO、HOW测试计划注意事项测试计划注意事项l分别创建测试计划与测试策略ü编写软件测试计划要避免一种不良倾向是测试计划的¡°大而全¡±，长大篇论，重点不突出。测试计划案例l案例：中国证券业2000年问题第二次测试计划ü上海证券交易所.深圳证券交易所l参加单位ü沪深证券交易所与证券结算公司ü沪深证券卫星通信公司ü所有会员公司至少两家营业部参测，其中至少一家是不发达地区（深、沪、省会城市和计划单列市以外），各会员公司按表（一）填写，务必于11月26日前将参测营业部名单（即填写后续表一）用电子邮件报至两证券交易所测试计划的内容l1.简介ü1.1目的ü1.2背景ü1.3范围l2.测试参考文档和提交文档ü2.1测试参考文档ü2.2测试提交文档l3.术语和定义l4.测试策略ü4.1测试策略ü4.2测试工具简介—目的（Why）l1.1目的ü做事:确认目标¡ª做什么¡ª怎么做方法

l可包含：ü撰写软件测试计划的目的？ü通过测试希望达到的目标？--功能，性能，界面—背景和范围（What）--明确目标和方法，便于团队交流简介l1.2背景ü测什么产品（参考需求说明书）•产品规格n产品名称、制造商和产品版本号的说明•产品信息n产品的用户、开发该产品的背景•技术结构n介绍产品的主要功能，可以借助图表的格式表述l1.3范围ü测试流程的各个阶段要测什么ü分别简要列出要测试和不进行测试的性能指标和功能点测试计划的内容l1.简介ü1.1目的ü1.2背景ü1.3范围l2.测试参考ü2.1测试参考文档ü2.2测试提交文档l3.术语和定义l4.测试策略文档和提交文档ü4.1测试策略ü4.2测试工具2测试参考文档l2.1测试参考文档测试计划中引用的文档或书籍2测试参考文档l2.2测试提交文档测试计划的内容l1.简介ü1.1目的ü1.2背景ü1.3范围l2.测试参考ü2.1测试参考文档ü2.2测试提交文档l3.术语和定义l4.测试策略文档和提交文档ü4.1测试策略

ü4.2测试工具测试计划的内容l3术语定义（可选）ü定义了开发产品或测试过程中常用术语的含义，开发和测试人员常常因为对一个术语的理解不同产生争议l4.1测试策略（How）ü测试策略描述测试小组用于测试整体和每个阶段的方法。ü确定测试策略要从模块、功能、整体、系统、版本、压力、性能、配置和安装等各个方面来考虑4测试策略—测试工具l4.2测试工具ü此项目将使用以下工具：测试计划的内容l1.简介ü1.1目的ü1.2背景ü1.3范围l2.测试参考文档和提交文档ü2.1测试参考文档ü2.2测试提交文档l3.术语和定义l4.测试策略ü4.1测试策略ü4.2测试工具测试计划的内容l5确定测试内容(What)ü功能的测试•理论上测试要覆盖所有的功能项ü整体考虑•要考虑到数据流从软件中的一个模块流到另一个模块的过程中的正确性确定测试内容资源l人力资源ü这里的人力资源包括测试人员，开发人员，项目负责人，客户代表所有与项目有关的人员，即项目接口人资源l系统资源(Where)ü需要使用的软件在哪里可以下载，测试工具放在哪里？ü需要的硬件怎么解决？ü文档在哪里？测试计划的内容l7.测试进度（When）ü各测试阶段资源要求及时间安排

ü项目里程碑l可以参考一下项目经理的项目开发进度ü可以使用相对日期：比如XXX工作开始于XXX部门XXXX工作的结束并提交XXXXü也可以加注总的测试工作量预期，用¡°人/月¡±、¡°人/日¡±等描述。7.测试进度测试计划的内容l8.测试人员的任务分配l9.风险和问题设计阶段的测试测试设计分析测试要素对设计进行评审l选择评审组成员l对评审组进行培训l通报项目组l分配足够的时间l只对文档化的事实进行评审l和项目组一起进行评审l对评审形成建议l和项目组对建议一起进行评审l准备正式的报告测试的执行测试执行中的主要工作测试用例的合理选择BVT测试与冒烟测试测试的记录与跟踪bug的定义lbug：在软件使用过程中所出的现问题，或者导致软件不能符合设计要求或满足消费者需求的问题ü未实现产品说明书要求能更改的功能ü软件出现了产品说明书指明不应该出现错误的ü软件实现了产品说明书未提到的功能ü软件未实现产品说明书虽未明确提及但应该实现的目标ü软件难以理解、不易使用、运行缓慢或者最终用户认为不好用l简单地说，bug就是软件做了没有期望它去做的事（或者相反，软件没有做到所期望它去做的事）bug的识别l有些问题看似错误但不是缺陷

l有些问题看似正确但却是缺陷l同一现象的既可能是bug，也可能不是看似错误但不是错误看似正确但却是错误l安装某个软件成功，但它破坏了操作系统的功能或其他软件。l软件卸载过程中没有完全卸掉它的组件，有些会降低系统运行的效率，有些会导致升级版本无法安装。l软件需要支持大多数的硬件配置，例如迪斯尼狮子王游戏的教训，虽然软件本身没有错误，但是却影响了多数用户的使用。同一现象的2种可能l同一种现象在不同的环境和系统中，可能是缺陷也可能不是l在性能和精度等方面的要求上，民用产品与军用产品有很大的区别l在系统易用性方面，普通用户与专业用户对产品的要求存在很大的差异bug与“软件缺陷”的关系l“软件缺陷”是一个软件系统中的需求、体系结构、设计和应用上的错误。而“bug”是软件缺陷的实际证明。l软件缺陷有可能成为bug，但并非所有的软件缺陷都产生bug。判断bug的方法*bug的分类Bug的严重程度和优先级Bug的严重程度和优先级l严重程度高优先级不一定高：ü如果某个严重的软件缺陷只在非常极端的条件下产生，则没有必要马上解决。ü如果修正一个软件缺陷，需要重新修改软件的整体架构，可能会产生更多潜在的缺陷，而且软件由于市场的压力必须尽快发布，此时即使缺陷的严重性很高，是否需要修正，需要全盘考虑。l严重程度低优先级不一定低：ü如果是软件名称或公司名称的拼写错误，则必须尽快修正，因为这关系到软件和公司的市场形象。bug的识别再现bug怎样有效记录buglBUG报告—项目组就正在测试中的软件质量问题的一种书面沟通方式l读者：ü开发人员（关ü项目管理者（关注概述和严重程度）、ü后续版本的测试人员（关注问题集中的模块和测试方法）注重现步骤）、ü运行维护人员（关注用户使用中系统是否出现遗留问题、系统薄弱模块等）怎样有效记录bugl保证重现bug(Reproduce)l分析故障——使用最少步骤复现故障

l包含所有重现bug的必要步骤l方便阅读l尽量简单——一个bug一个报告l注意自己的语气l值得注意的经验怎样有效记录bugl保证重现bug(Reproduce)ü对于严重程度较高的bug，一般要重复测试2次以上ü对于随机产生的bug，要在其他机器上测试一下ü不可重现的bug也要报告ü详细记录出现bug的测试点的测试步骤及相关截图、日志、开发人员定位信息等，尤其对于暂时不能复现的问题。缺陷报告几个关键点l一位IBM前辈总结的lCanpigrideüCondense－精简，üAccurate－准确，缺陷报告几个关键点：猪能骑清晰而简短是一个bug？还是用户操作错误，或是者理解错了，等等？带偏见，不用幽默或者情绪化的语言。这到底是不üNeutralize－用中性的语言描述事实，不üPrecise－精确，这到底是什么问题？üIsolate－定位，这到底是个什么样的问题？尽量缩小这个问题的范围。几个关键点üGeneralize－还有没有其他的üRe-Create－如何引发和重现这个bug？（环境üImpact－影响，这个缺陷对客户有什么影响？üDebug－怎么做才可以让开发更容易来修改这个bug？（跟踪缺陷报告某些地方存在这样的问题？，步骤，前提条件）何影响？对测试有，截图，日志，直接访问等等）üEvidence－证据，如何证明确实存在这个bug？问题单模板举例怎样有效记录缺陷l包含所有重现缺陷的必要步骤怎样有效记录缺陷l方便阅读站在开发人员的角度考虑问题ü1.概述（完整，揭示错误实质ü2.步骤（Steps）：完整，准确，简•“完整”即没有缺漏，“准确”即•步骤正确，“简短”即没有多余的步骤。ü3.尽量使用业界惯用的表达术语和表达方法（term）Summary）：简洁、准确，短，保证快速准确的重复错误，ü4.检查拼写和语法错误怎样有效记录缺陷

l尽量简单——一个缺陷一个报告ü便于分配问题ü便于回归测试，关闭bug怎样有效记录缺陷l注意自己的语气l换位思考,保持中立（Neutralize）ü要站在客观中立的立场上，不能参杂主观感情ü例如：ü¡°这个问题在上一个版本中已经修复了，怎么这次又出现了呢？¡±ü¡°这个错误太低级了！¡±ü¡°我觉得这样不行！¡±怎样有效记录缺陷l值得注意的经验1）报告不能重现的缺陷2）不能夸大缺陷3）小缺陷（甚至建议）也要报告4)引用别人的报告时，不能修改，可以添加批注之类的补充评论5）概述最好用陈述句，不超过15个字缺陷报告案例分析缺陷报告案例分析缺陷报告案例分析bug的生命周期lNew:新发现的bug，未经过评审决定是否派给开发人员进行修改lOpen：确认是bug，并且认为需要进行修改，指派给相应的开发人员修改lFixed：开发人员进行修改后标识成修改状态，待测试人员验证确认bug的生命周期lRejected：如lDelay：如果认为暂时不需要修改或暂时不能修改，lClosed：修改状态的bug经过测试人员的测试验证通过果认为不是bug，则拒绝修改则延后修改。lReopen：经过验证bug仍然存在，则需要重新打开bug，开发人员重新修改跟踪一个bug的生命周期跟踪一个bug的生命周期lNew:新发现的bug，未经过评审决定是否派给开发人员进行修改lOpen：确认是bug，并且认为需要进行修改，指派给相应的开发人员修改lFixed：开发人员进行修改后标识成修改状态，待测试人员验证确认lRejected：如lDelay：如果认为暂时不需要修改或暂时不能修改，lClosed：修改状态的bug经过测试人员的测试验证通过果认为不是bug，则拒绝修改则延后修改。

lReopen：经过验证bug仍然存在，则需要重新打开bug，开发人员重新修改Bug评审应该注意的问题回归测试回归测试的过程回归测试的策略测试报告测试报告的编写测试报告的编写测试报告的编写测试报告的编写软件质量评估l覆盖---专注于过程ü需求覆盖ü代码覆盖l质量---专注于结果ü缺陷报告ü性能评测软件测试评估l软件测试评估，也就是测试总结，是软件测试生命周期的最后一个环节。l测试评估主要分为两种：对覆盖（过程）的评估和对缺陷（结果）的评测。l两种覆盖：对源代码的覆盖和对需求的覆盖。l对源代码的覆盖：ü指的是在单元测试过程中所测试到的源代码占代码总数的百分比，一般有语句覆盖、分支覆盖、条件覆盖、路径覆盖等。ü一个通用的标准是：关键模块的语句覆盖率为100%，