软件测试理论总结

1、为什么要测试？软件测试的目的？软件测试的重要性？A、发现缺陷BUG/DefectB、评估软件、项目、产品上线风险？C、满足客户要求、改善软件质量D、帮助开发发现问题、定位问题、修改问题E、软件验收、也包括第三方的验收（验收测试、UAT）F、通过缺陷分析，从而预防同类缺陷的发生。G、错的：软件测试能缩短开发周期。也不能直接降低开发成本。H、改善软件的用户体验（易用性、性能、稳定性）12306订票角度：系统性思维（1、2、3、4、5、6、7+=100:1+2+34+56+7=100）门萨测试角色：用户：发现缺陷、改善用户体验：开发：证明软件GoodEnough，定位缺陷，从而减少开发修改问题的时间历史：证明程序是正确？--》发现功能缺陷、错误--》发现不足（易用性、性能、稳定性）--》缺陷预防现实：验收、评估质量风险、第三方评测、为了盈利而测试（商业成功）（测试成本《《软件缺陷导致成本）2、什么是软件测试？IEEE（国际电器电子工程协会）：目的：验证系统是否满足需求、验证实际结果跟期望结果的差异？xll：在一定的软件、硬件、网络环境下（搭建测试环境LAMP），遵循相对规范的测试流程，使用合适的测试工具，合理的测试方法，测试或运行软件，其目的是为了验证系统是否满足需求、验证实际结果跟期望结果的差异。3、软件测试的工作内容？BAT：Baidu、Alibaba、Tecent4、测试与调试的区别：对象：代码、文档；代码人：测试工程师；开发流程：有规范的流程（除了随机测试和探索性测试外）；无流程目的：发现问题；定位和解决问题5、测试的七大原则：A、测试只能证明软件存在缺陷，不能证明软件没有缺陷（证伪不证真）B、测试是无法穷举？（输入数据是无法穷举、处理逻辑路径是无法穷举），学习测试用例的设计方法。C、测试应该尽早测试？（发现缺陷和修改的成本越早越低。需求-设计-代码-测试-运行）测试应该在需求之后？设计之后？编码之后？测试应该尽早介入，测试应该贯穿整个软件生命周期。D、缺陷的80/20原则（群集效应）。如果测试发现某个模块有问题？继续深入测试。刨根问底？破案？E、杀虫剂悖论（软件对用例会免疫力）不断更新测试用例、更新的测试思维F、测试依赖于商业背景（与行业知识相关）结合专业和工作经历和准备相关的项目。优点SWOT优势、劣势、机会、威慑（竞争对手）准备行业软件G、不存在缺陷的软件并不代表是有用的系统。一个合格、优秀、卓越、伟大的测试工程师的能力与素质的要求？素质、性格、能力、管理、英语、行业六大维度回答答6、测试与开发的关系（独立性）未来趋势：3大趋势：1、测试与开发的结合越来越紧密；2、测试与行业背景结合越来越紧密3、专项测试（测试分工会越来越精细），大数据测试（数据库，用户工程）IT，DT。比较分析不同网站的购物流程：亚马逊、当当网、京东、淘宝（CDC）联众游戏、QQ游戏1、测试人员也开发，开发也做测试（Google：吃狗粮的文化）2、测试人员独立与项目（在项目中有专职的测试人员：客观）3、测试人员独立部门（有专门的测试部门：权威）4、测试人员独立技术（测试工具部、测试技术部）5、测试人员独立于公司（测试服务机构或者公司）缺点：沟通越困难，对产品或者项目的熟悉越少。感情色彩：这是个非常严重的bug！！！！！测试人员发现了BUG，开发人员不愿意修改，该怎么办？加班？敏感问题？三方思考：对方、客观中立、自己地铁自动售货机PM1、计划阶段：可行性分析：A、经济可行性分析；B、技术可行性分析（外包）计划项目里程碑：计划、需求SRS、概要设计HLD、详细设计LLD、编码、测试、运行与维护输出软件项目计划SPP（SoftwareProjectPlan）PM输出软件确认与验证计划SVVP(SoftwareverficationValidationPlan)软件测试计划TPM2、需求阶段：产品（金蝶）：调研与项目（用户）SE系统工程师whattodevelop？黑盒TSE分析测试需求挖掘用户的隐性需求需求规格SRS：功能需求：1、接受货币2、选择商品3、计算功能4、输出商品和找零、5、商品管理性能需求：30S之内输出商品和找零可靠性需求：7X24小时易用性需求：良好易用性，不需要培训。最好用的软件baidu需求分析的技术：UML建模（需求工程）3、设计阶段：概要设计HLD（HighLevelDesign高层设计）：模块分解与接口的定义。1、接受货币（识别真伪、识别面额、识别类别）分解原则？高内聚低耦合？（百度）（无直接耦合、数据耦合、印记耦合、控制耦合、公共耦合、内容耦合）回归测试2、接口：函数接口、消息接口、文件接口（QQ修改头像）、数据库接口详细设计LLD（LowLevelDesign底层设计）：算法的描述（程序=数据结构+算法/思路（各种排序））流程图、伪码。白盒4、编码阶段：熟悉一门编程语言的语法C、Java、PHP和一个开发工具或者平台VC、Eclipse等熟悉一门脚本语言：python、ruby、perl、tcl、shellBAT5、测试阶段：测试工具、方法、流程6、运行与维护：技术支持测试应该贯穿整个软件生命周期。1、测试应该在SRS之后？HLDLLDCODE瀑布模型：缺点：不适应需求变更频繁的项目。适合产品开发的项目。测试滞后于开发。V模型：用户需求URS-----------------------------------------验收测试UAT（UserAcceptanceTesting）需求规格SRS---------------------------------系统测试ST（SystemTesting）概要设计HLD-------------------------集成测试IT（IntegrationTesting）详细设计LLD-----------------单元测试UT（UnitTesting）编码CODE------------代码评审CODEReviewH模型、X模型。1、方法的背景？2、方法的操作步骤、3、优缺点、4、适用范围、5与其他方法怎么样配合、6重点、要点、难点等价类：1、背景：why？输入无法穷举，我们不能测试所有情况，必选选择有代表数据来验证2、操作步骤：1、分析被测试对象输入条件以及子条件（关键点：考虑隐性子条件，条件正交完备）2、根据等价类划分原则划分有效等价类和无效等价类原则：1、规定范围或者格式，譬如长度6~18位，可以划分1个有效、2个无效等价类2、规定的集合或者满足某个条件，譬如一些下拉列表的选择，可以划分1有效、1个无效3、规定了必须如何，譬如组成、开头，可以划分1个有效和若干个无效。4、规定是布尔量，譬如是否已经注册，可以划分1个有效和1个无效5、规定是多种选择（还有不同的处理方式），譬如163邮箱注册的后缀，可以划分成若干个有效，和1个无效。3、根据等价类设计用例原则：（1、用一个用例覆盖尽可能多的有效等价类；2、为每一个无效等价类单独设计用例：为了更好定位问题）设计数据原则：同样效果情况下用例数尽可能少，精确定位问题。3、优缺点：适用范围广、能以有限用例达到比较好覆盖无法穷举的输入。缺点：方法没有刻意考虑边界，只能针对单个输入条件，没有考虑输入之间组合以及输入与输出的关系。4、适用范围：只要有业务规则的情况下，最好是有清晰的业务规则5、与其他方法怎么样配合：一般情况下会跟边界值方法结合使用。6、要点：等价类划分的原则：尤其是要注意隐性条件（完整性，不要遗漏）思考：微信发送图片、上传QQ头像、导入文件这类如何使用等价类边界值：1、背景：why？：很多错误通常都发生在边界上。2、操作步骤：1、分析被测试对象输入条件以及子条件2、分析上点、离点和内点3、根据边界值设计用例的原则设计数据去覆盖可能上点、离点和内点3、优缺点：优点：能够比较高效发现问题缺点：不能考虑输入与输出之间的关系4、适用范围：规定了大小、长度、值的范围、分辨率（广义）5、与其他方法怎么样配合：与等价类配合6、要点：找到边界（隐含的边界）航空行李托运：重量不能超过30公斤，如果超过就要收费，正常人4元每公斤，外国人收6块，头等舱是其他舱的2倍残疾人是正常人的1/2.判定表/决策表：1、背景：why？：输入条件很多情况（要么满足、要么不满足），不同条件组合下输出结果也很多，希望条件跟结果的一一对应的关系它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确2、操作步骤：1、分析被测试对象的输入条件，同时分析各种可能的输出结果（）2、列出所有的条件和动作（）3、填写条件项和动作项4、合并相似规则3、优缺点：优点：能解决复杂条件之间逻辑组合，比较清晰列出所有的组合缺点：一旦条件数过多，组合数会很庞大，合并存在漏测的风险（很难精确定位问题）。对于条件，只能是有两种取值（为真、为假）4、适用范围：条件只有两种取值的多条件组合的例子5、与其他方法怎么样配合：与因果图6、要点：找出业务条件规则，列出各种可能输出结果。（测试象棋马走日这个规则）当条件比较多5要考虑是否有中间结果（简化）正交试验法1、背景：弥补判定表方法可能导致用例规模非常庞大，多条件组合的数量非常巨大。根据伽罗瓦理论，条件之间的两两组合如果不出问题，三三组合以上出问题的概率小，这样一来，可以用非常少的用例来达到比较好的测试效果。2、操作步骤：1、分析输入条件以及条件的取值范围。（筛选出来的条件之间没有约束关系）2、选择合适的正交表（计算需要最小正交表的试验数，然后分两种：1、单一水平：去挑选比需要大但是是最接近的正交表，直接套用；合并去匹配正交表--分解2、混合水平：）保证试验数最少3、根据正交表（拆分之后）设计测试数据（每一列行是一个测试项），如果是空的地方，可以根据实际需要加权处理。3、优缺点：优点：在保证一定均匀覆盖率的前提下可以大大降低试验次数（测试项），缺点：可能有一定的遗漏4、适应范围：配置类需求的分析，多条件多取值的业务测试。5、与其他方法配合：等价类和边界值（输入框）6、要点：选择合适正交表以及如何去合并和分拆！UseCase法/场景法/流程分析法1、背景：在实际工作中，我们很业务功能是通过工作流来实现，需要站在流程角度（用户角度），譬如购物流程安装测试、转账流程、游戏场景2、操作步骤：1、分析业务的基本事件流和备选事件流（正常备选事件流和异常事件流（退出））担心备选流有遗漏2、画出事件流图（UseCase图用例图）3、根据图设计场景4、根据场景来设计测试数据3、优缺点：优点：站在用户的角度来测试（），可以很好地与开发配合，直接通过用例图转化，效率比较高4、适应范围：验收测试用例的设计，只要流程5、与其他方法配合：等价类、边界值（选多少个备选流）6、要点：事件流分析，尤其是备选流的分析是最关键的地方。思路比较清晰，比较广网银转账：写出基本流和备选，并且画出事件流图。影响软件质量的因素：技术：1.现有的技术：人2.技术沉淀：技术文档，专利技术，指导书，问题库，经验库流程：流程可以提高软件透明度，控制项目的进度，帮助项目组预防风险。组织：组织体现的是管理1.让合适的人去做合适的事情2.流程的推动需要组织强有力的保障软件质量管理体系1.ISO9000八项质量管理原则：以顾客为中心：以用户的角度去思考问题（UAT）下游环节为上游环节的客户领导的作用：有激情，有谋略，演讲才能，身先士卒全员参与：团队合作信任基于事实的决策方法：个人能力基线（PCB）（量化管理）持续改进（持续改善）：最初是日本的一个管理理念，从初级员工到高级管理者都需要参与互利的供方关系：共赢，共同创造利润过程方法：过程：输入转化为输出的活动过程方法：过程的识别，相互作用以及管理管理的系统方法：全局化的管理策略2.CMM--初始级：手工作坊式，个人英雄主义，没有相关过程，不可预测并且缺乏控制。--可重复级：特点-可以重复以往的项目经验证券项目（招商证券）国信证券：SRSHLDLLDCodetestcase模板关键过程域（KPA）（keyprocessarea）：需求管