软件测试基础(新员工培训)

软件测试技术系列SoftwareTestingTechnologySeries软件测试基础整编.王家明2018.9.26本文根据资料整理及个人工作经验总结进行整编，适合测试工程师培训学习使用。1测试培训2•业界对测试部门的培训的统计情况，参考51testing这个胶片讲的是什么•思考：软件测试到底是什么？•测试培训现状•测试并不完美•千年虫•缺陷的故事•缺陷引发的后果•软件测试与程序测试区别•软件的概念•缺陷的概念•测试的目的•软件生命周期中的软件测试活动•我司软件开发过程管理规范•新人的晋级之路，测试技能学习提升方向•澄清概念，QA与软件测试•一个小故事，反思•我司在测试过程中的要求•测试的开展与退出原则•软件测试概念分类•测试计划•为什么要做测试需求分析•测试需求分析图示•测试需求分析方法•测试需求分析方法介绍-测试类型分析法•测试用例设计•系统测试•性能测试•随机测试•探索性测试•回归测试•缺陷管理•我司的缺陷流程-禅道•缺陷定义划分•缺陷填写方法与样例•我司版本管理规范•测试部门管理规范完美软件？用户购买功能的同时也在忍受缺陷--史考特.沃兹沃思（ScottWadsworth)软件从来就没有完美过!人们迫切需要软件来实现未来的梦想…在计算机应用上，2038年问题可能会导致某些软件在2038年无法正常工作。所有使用POSIX时间表示时间的程序都将受其影响，因为它们的时间起点是格林尼治时间1970年1月1日0时0分0秒（这个时间名叫theUnixEpoch）尽管2000年已经过去,我们却还没有走出森林。不是所有计算机都用同样的方式处理日期,许多使用多用户多任务操作系统(UNIX)的计算机处理日期的方式是:从1970年1月1日起计算经过了多少秒。这个数作为“有标记的32位整数”存储在这些计算机中,其最大值为2147483647。这就是说它仅能处理1970年1月1日之后最多2147483647秒的日期——只能计算到2038年1月19日,这个日期之后我们就会遇到问题。千年虫与2038java类代码Datedate=newDate(0);System.out.println(date);打印出来的结果:ThuJan0108:00:00CST1970缺陷的由来为什么存在逃过所有监测手段而存在于发布产品中的缺陷?软件缺陷是怎样产生的?关于缺陷的故事格蕾丝·赫柏（GraceHopper）博士，计算机软件的第一夫人,美国海军准将，世界第三位程序员，发现了计算机程序中的第一个Bug，编译语言创始人和现代高级程序设计语言的奠基人。创造了世界上第一种商业编程语言COBOL并为之后的高级程序设计语言定义了模型我们的目标？降低缺陷逃逸率减少发布产品中的严重BUG使用不同于程序员视角的“第二双眼睛”探索、发现、调查、学习发现能力、定位分析能力、解决问题能力单元测试手工测试缺陷引发的灾难阿丽亚娜5型火箭的杯具处女秀1996年6月4日，阿丽亚娜5型运载火箭的首航，原计划将运送4颗太阳风观察卫星到预定轨道，但因软件引发的问题导致火箭在发射39秒后偏轨，从而激活了火箭的自我摧毁装置，阿丽亚娜5型火箭和其他卫星在瞬间灰飞烟灭。事故原因：代码重用。阿5型的发射系统代码直接重用了阿4型的相应代码，而阿4型的飞行条件和阿5型的截然不同，此次事故损失3.7亿美元。消失在太空在制造火星气候轨道探测器时，一个NSA的工程小组使用的是英制单位，而不是预定的公制单位，这会导致探测器的推进器无法正常运作。正是因为这个Bug，1999年探测器从距离火星表面130英尺的高度垂直坠毁。此项工程耗费3.27亿美元，这还不包括损失的时间（该探测器从发射到抵达火星将近一年的时间）致命的辐射治疗1985年1987年，Therac-25辐射治疗设备卷入多宗因辐射剂量严重超标引发的医疗事故，其罪魁祸首是医疗设备电力软件的Bug。据统计，大量患者接受高达100倍的预定剂量治疗，其中至少3人直接死于辐射剂量超标。另一宗辐射剂量超标的事故发生在2000年的巴拿马城，从美国Multidata公司引入的治疗规划软件，其辐射剂量预设值有误，至少有5人死亡。后续几年中，又有21人死亡，但很难确定这21人中到底有多少人死于本身的癌症，还是辐射治疗剂量超标引发的不良后果。软件测试与程序测试/调试(BUGvsDebug)软件测试程序测试什么是软件？测试软件测试硬件测试程序测试文档测试•软件=程序+文档•缺陷的定义符合下边5个规则之一的才能叫做软件缺陷软件未达到产品说明书标明的功能软件出现了产品说明书指明不应该出现的错误软件功能超出产品说明书指明范围软件未实现产品说明书虽未明确指出但应该实现的目标软件测试员或最终用户认为软件难以理解、不易使用、运行速度缓慢什么是缺陷？•发现程序中的错误并进行修正，将软件不工作的风险程度降低到一个可以接受的程度。测试的目的想以最少的时间和人力，系统地找出软件中潜在的各种错误和缺陷它能够证明软件的功能和性能与需求说明相符合。实施测试收集的测试结果数据为软件可靠性分析提供依据。软件生命周期中的测试活动问题定义可行性研究需求分析总体(概要)设计详细设计编码单元测试综合测试持续满足用户需求•软件从形成开发软件概念起，所开发的软件使用以后，直到失去使用价值消亡为止的整个过程；一般来说，整个生存周期包括计划（定义）、开发、运行（维护）三个时期。①建立总体结构和各子系统之间、各模块之间的关系；②定义各子系统接口界面和各功能模块的接口；③设计全局数据库或数据结构；④规定设计约束，制定组装测试计划，给出每个功能模块的功能描述、全局数据定义和外部文件定义；①细化功能模块，形成可编程的程序模块；②设计程序模块的内部细节包括算法、数据结构以及各程序模块间的接口信息；③设计模块的单元测试计划；软件定义软件开发运行维护要解决什么问题？做还是不做确定做什么，不做什么，不考虑怎样做？软件开发过程管理软件测试工程师的练级之路阶梯一执行、发现记录、描述阶梯二初步设计、定位阶梯三需求的理解、用例的有效性发现隐性需求、测试缺陷分析测试预防、测试方法标准化、固化测试流程阶梯四阶梯五阶梯六改进测试过程、推动测试技术进步•不同阶段（阶梯）的测试能力定义概念QA=软件测试？QA与软件测试的区别QualityAssurance：工作：通过预防，检查与改进来保证软件质量；关注点：整个软件开发的过程,步骤和产物QA软件测试SoftwareTesting：工作：采用设计、执行用例等方法去发现错误；关注点：过程产物和最终产物曾经的故事，有时还在持续……流程化！规范化！17怎么开展软件测试•测试原则：站在用户的角度，对产品进行全面测试，尽早、尽可能多地发现Bug，并负责跟踪和分析产品中的问题，对不足之处提出质疑和改进意见。•软件零缺陷(Zero-Bug)是一种理念，足够好（Good-Enough）是测试的基本原则。•这个“足够好”怎么评判？？？•所有的软件测试都应追溯到用户需求；•完全测试是不可能的，测试需要终止；•测试团队应该独立；•保持精简的团队建设，不能任意降低测试人员的技术要求；•真正关心用户；•应当把“尽早地和不断地进行软件测试”作为软件测试者的座右铭；•其他……你听过的那些测试原则？基于原则开展测试活动（常说的十大原则）•所有测试的标准都是建立在用户需求之上。【用户至上】•必须基于“质量第一”的思想去开展各项软件测试工作。【质量至上】•事先定义好产品的质量标准。【标准化】•软件项目一启动，软件测试也就是开始，而不是等程序写完，才开始进行测试。【尽早参与】•穷举测试是不可能的。【Good-enough原则：权衡投入/产出比的原则，测试既不要不充分，也不要过分，零缺陷是一种理想。】更好•第三方进行测试会更客观，更有效。【他测性，程序员应避免测试自己程序】•软件测试计划是做好软件测试工作的前提。【计划可执行性】•测试用例是设计出来的，不是写出来的。【应该/不应该做的，合法/非法的，科学法，提高效率】•不可将测试用例置之度外，排除随意性。【执行用例更利于查漏补缺】•对发现错误较多的程序段，应进行更深入的测试。【Pareto原则（ParetoPrinciple即80/20原则）】帕累托法则，又称80/20法则、马特莱法则、二八定律、帕累托定律、最省力法则、不平衡原则、犹太法则。意大利经济学家帕累托提出的。法则认为原因和结果、投入和产出、努力和报酬之间本来存在着无法解释的不平衡。测试活动退出的原则•完成所有测试阶段的测试；•功能性测试用例通过100%，非功能性用例通过95%；•缺陷收敛到预定的水平；•缺陷修复率，高等缺陷全部修复，一般缺陷修复90%以上；•通过用户验收测试；•测试用例达到预定的覆盖率；•达到项目计划规定的各项指标；•缺陷度量；•质量成本；•测试行业经验；什么是架构？架构是做什么的，不同的人不同的视角软件架构是指在一定的设计原则基础上，从不同角度对组成系统的各部分进行搭配和安排，形成系统的多个结构而组成架构，它包括该系统的各个组件，组件的外部可见属性及组件之间的相互关系。软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。软件测试概念分类黑盒测试灰盒测试白盒测试单元测试系统测试需求评审功能性需求功能测试负载测试压力测试容量测试非功能性需求设计测试编码测试CodeReview安全性测试可靠性测试兼容性测试需求测试设计评审设计策略静态测试动态测试手工测试随机测试自动化测试探索测试冒烟测试回归测试...软件测试阶段集成测试验收测试质量测试计划---6W1H•1)why——为什么要进行这些测试；（Purpose-目的）•2)what—测试哪些方面，不同阶段的工作内容；（Scope-范围）•3)when—测试不同阶段的起止时间；（Schedule-时间表）•4)where—相应文档，缺陷的存放位置，测试环境等；（Resourse-资源）•5)who—项目有关人员组成，安排哪些测试人员进行测试；（Ownership-权限）•6)how—如何去做，使用哪些测试工具以及测试方法进行测试；（Strategy-策略）•7)worry—考虑有什风险存在，准备些解决方案；（Risk-风险）•参考模板•《JZ-QC-001A[项目名称]-测试计划.docx》测试需求分析测试需求分析---现状•目前，测试过程中存在的问题：•产品质量维度关注不全面，测试类型不完整；•没有测试规格，测试分解分配比较随意；•没有系统的工程方法或指导；•测试过程中，经常会出现需求遗漏、测试设计遗漏等问题；•需求不明确，需求定义随意性等；•为提高客户满意度，需提供产品质量，减少生产环境问题，作为质量保证的重要一环，测试需要站在客户的立场做测试，需要首先明确应该测试什么的问题。测试需求分析---图解•软件需求是基础，功能点是软件需求的分解产物，测试需求是对功能点进行剖析后形成的测试基础，测试案例是对测试需求的操作细化。测试需求分析---方法思路•为了有效的获取测试对象，需要从测试需求分析开始，可分三部分：•明确需求的测试范围，即确定需求中包括了多少功能点；•明确功能的业务处理过程，对每一个功能点的输入、处理逻辑和输出进行提取；•根据用户需求，明确其在特定场景下实际使用时的流程及操作步骤，以明确测试场景。•测试需求分析过程是对功能点列表中列出的每一条功能需求细化和分解的过程，以形成可测试的分层描述的测试要点的过程。•通过分析每条功能需求描述中的输入、输出、处理、限制与约束等，给出对应的验证内容；•通过分析各个功能模块之间的业务顺序，以及各个功能模块之间对传递的信息和数据存在的功能交互，给出对应的验证内容；•经过分解获得的测试需求必须能够充分覆盖软件需求的各种特征，且每个需求都可以进行单独测试，以保证测试需求的完整性；•每个测试需求能够使用数量相当的测试用例来实现，即尽量保证测试案例的粒度是均匀的。测试需求分析---常用分析法