涅槃Ls的博客

有点颓废了，最近都没有输出总结了。困在了功能测试中。

最近以xmind形式写的测试用例，写的太简洁了， 一味的追求简洁，追求要一屏放下也不好，开发会看不懂，自己过段时间回顾时 也会先懵一会。 ~改！

读《软件测试之困》 day09 & 测试工作评价表（详见图） & 评估时的参考对象就是之前测试过的同类型项目。 & 选取其中20%的重要模块功能，做为重点测试对象。 & 测试用例级别定义（使用风险方面，操作频繁方面） & 复盘 & 问题复盘是提升团队能力的重要契机 & 学会跳出测试范畴，挖掘问题真正原因，找到合适的解决方案，必要时，我们要协助开发或其他人员 认识问题根源。 & 测试用例命中的bug数，非测试用例命中的bug数，用户反馈的bug数，“潜伏”的bug数。 & 绝大部分bug是可以通过测试用例发现的。 & 需求覆盖率，指用户需求实现的比例，一般要求全部实现。 & 代码覆盖率， & 测试自动化、自动化测试（详见图）

读《软件测试之困》 day08 『创新的本质是解决问题并带来收益 『是测试，不为测试 『是软件测试工作，但不能为了测试而测试 『心中有客户 『只要你能够发现问题并描述清楚，转化为一个需求，进而转化为一个任务，争取到支持，发动起一批人，将这个任务完成，并持续不断以主人翁的心态去追踪、维护这个产物，那么，你就是产品经理 『质量就是用户的满意度，质量终归由用户说了算 『软件=程序+数据+文档 『软件升级兼容性测试是必不可少的一步 『白盒测试是从 开发设计、代码内部逻辑、编码规范出发，结合软件需求，设计测试用例，编写测试代码。 『不同产品方向的聊天，进行思维“碰撞”，帮助大家打破自己固有的惯性思维

读《软件测试之困》 day07 〖测试平台：为所有测试人员 提供 测试服务的公共技术、组件、工具、体系文件的集合。 〖包括 测试工作过程中共用的工具、数据、流程、规范、模版。 〖测试平台 的主要价值：在于提升软件测试效率，规范测试过程的输出质量。 〖测试技术平台：自动化测试框架、公共函数库、专项测试工具、业务测试模版、技术评审checklist等。 〖测试业务平台：测试方案、测试用例。 〖测试系统维护平台： 〖测试工作中常见的软件类基础规范 流程 模版 指南（如图） 〖获取者多，贡献者寡 〖负责项目测试，同时负责团队平台建设。 〖小公司靠创意，大公司靠平台。 〖测试用例的全面性 充分性直接影响发现潜藏bug的效率。 〖找到合适的表达方式 提取 共同的部分，做为平台测试用例 〖能够解决问题的东西就是一个工具。 〖测试开发平台集合 五大类（如图） 〖测试工具，常见的文本处理工具、网络通信工具、网络数据抓包工具、自动化测试工具、测试环境构造工具。 〖根因分析：5W1H结构化（六何分析法） who when where what why how 〖操作系统：Windows，Linux，UNIX，macOS，iOS，Android 〖应用软件 就是运行在操作系统上的程序

读《软件测试之困》 day06 & 测试用例简语，宏，变量 & 测试用例是测试人员的核心输出 & 测试用例：为某个特定目标而开发的输入 执行条件 预期结果的集合。 & 测试用例：为了达到某个测试目标，在满足一定条件下，是一系列明确的输入和输出数据组成的元素。 & 测试用例的元素包括但不限于测试用例标题，输入数据，预设条件，操作步骤，预期结果。 & 测试用例是测试人员的中心世界。 & 不断确认软件实现的正确性和可靠性。 & 测试用例就是为了代码而生的。 & 在编写测试用例前，我们需要先进行测试的分析和设计，包括为什么编写这条测试用例，采用什么测试方法，测试思路是什么，测试过程是如何，如何判断正确与否。 & 测试用例的可读性，二义性，可执行性，可维护性，可复用性问题。 & 软件测试的验证记录是产品的设计实现是否符合用户需求的重要凭证。 & 没有数据记录就相当于没有验证。 & 正常测试用例，异常测试用例，相关影响测试用例。 & 非功能特性，从需求角度来看 是产品经理需要解决的。从守护用户质量的角度 是软件测试必须要关注的重要测试内容。 & 非功能特性和软件工程特点统称为专项测试。 & 测试用例集：公共测试用例集，版本发布测试用例集，冒烟测试用例集，演示版本测试用例集。 & 测试用例除需要在被测系统中执行来寻找bug外，还需要用来评估软件质量，工作效率。 & 测试用例核心三要素：预设条件，操作步骤，预期结果。也纪为IPO（input process output） & UI（user interface） & 必要定义统一的引用关键词规则。 & 标题：关键条件+检查点 & 内容不出现 如果 那么的表达 & 内容不出现 模棱两可的词汇 & 内容不出现 不明确的程度副词 & 内容不出现 带有主观色彩的形容词

读《软件测试之困》 day05 #Scrum敏捷开发模式 #可工作的软件高于详尽的文档 #团队研发能力的积累 #需求到用例的正向追溯 #用例到需求的反向追溯 #建立全链路的产品需求追溯体系 #用户可分为内部用户 外部用户 #追溯测试用例设计依据的内容（软件需求） #需求与测试用例的追溯 #需求与代码的追溯 #软件测试用例执行，背后就是在覆盖代码路径 #技术方案是测试人员理解软件设计实现原理的重要输入 #流程，为我们解决共性问题提供了一套系统的标准方法，而工具就是流程执行的助推器 #测试过程输出物的归档 #建模（设计流程图） ## 对于测试相关的工作，如果涉及反复 有规律的操作，那么我们都可以将他们实现自动化或半自动化。 #自动化测试，并非单纯的测试用例的自动化。

读《软件测试之困》 day04_003 【bug处理流程就像一根将bug的相关专业方向人员串联起来的纽带】 【需要经历“提交”，“解决”，“关闭”3种状态】 【填写bug提交前的检查单】 【测试工程师需具备主动沟通，信息搜索，描述规范等能力】 【风险bug修复后 增加系统工程师的审核流程。系统工程师对bug解决方案的有效性，完备性的审核，降低测试工程师回归bug时重新打开的概率】

读《软件测试之困》 day04_002 <再小的团队，只要有信息，就存在流程> <通过“交叉测试”相互补充测试思路，提升软件系统质量> <在模块间使用的轮转式交叉测试是最佳实践> <避免思维定势的手段> <开发和测试，相辅相成，最终目标一致，确保按时交付高质量的产品> <代码“冻结”后的每个bug的变更，进行代码评审> <测试流程规范：一般包括测试方案设计，测试方案评审，测试用例设计，测试用例评审，测试用例执行，回归测试> <大部分历史遗留bug可以在交叉测试中被“消灭”> <调整工作内容：提前启动不依赖版本的测试任务> <测试人员根据不同的项目置顶不同的测试流程> <巩固测试> <测试过程中进行“自我回顾”和查漏补缺> <开发端冒烟测试>，开发自测 <版本发布是一件严谨的事情，一个版本就是一个产品> <了解需要测试的安装包，以及安装后的文件和目录，测试人员要清楚它们的来龙去脉> <规范软件安装包（压缩包）的开发过程> <回归测试前，对软件版本进行确认>

读《软件测试之困》 day04 ｛所有研发活动本质上是一种商业活动，软件测试也不例外｝ ｛控费降本（控制费用，降低成本）｝ ｛测试工作的自动化｝ ｛测试工作的规范化，流程化，以统一测试工作的输入输出｝ ｛提高效率，减少无谓的沟通｝ ｛针对不同测试人员 切分 测试流程的工作模式｝ ｛发挥团队成员各自的优势，使团队形成合力｝ ｛测试环境的配置是一个重要且棘手的问题｝ ｛切不可因为缺少真实的测试环境而放弃相关测试｝

读软件测试之困》 day03 『自己承认自己的价值，充满自信』 『需求只测试人员进行测试分析 测试设计的重要依据』 『开发前期发现的问题，使项目及时止损』 『整个软件生命周期都要关注bug问题』 『用户对核心场景的bug是零容忍的』 『漏测bug给测试人员带来的挫败感』 『复盘』 『只有产品在商业上成功，才有测试成功』 『只有商业的成功，才有测试的成功』 『从工程师到工程商人』 『测试开发工程师：主要进行测试工具开发和功能测试用例脚本化工作』 『带来的收益』 『只有在产品研发中解决问题，创造价值，才是重要的』 『bug是测试人员的重要输出』 『推动bug的解决，并追踪bug的解决情况』 『高频操作路径』 『并不是所有bug都需要解决，值得解决』 『“偏僻路径”上的bug』 『客户想要的产品质量』 『质量与进度尽可能平衡的背后是商业利益最大化』 『利益最大化的平衡点往往对产品在市场上未来表现起决定性作用』 『市场是产品的试金石』 『增加日志追踪，编译带故障注入的版本，以及由专门的开发人员和测试工程师处理，在多种方法和工具的作用下，提高bug出现的命中概率是完全有希望的』 『软件易用性方面的设计解决了客户使用上的痛点问题』 『解决了客户使用上的痛点 就是软件质量高的一种体现』 『需要站在客户的角度发现产品存在的问题，并主动思考解决方案，推动解决』

读《软件测试之困》 day02 $ 工程化软件不可能没有bug，有软件存在的地方便有了软件测试的需求。 $ 每个人的测试思维是不一样的，影响到采取何种策略开展测试工作。 $ 有感悟时，记录下来。 $ 测试工程化。 $ 投资回报率（return on investment）ROI。 $ 函数，功能模块，模块集成。 $ 只有具备良好工程特性的产品 才是满足客户需求的好产品。 $ 软件测试始终需要围绕全链路的工程特性开展工作，这样才全面，系统的守护软件质量。 $ 测试用例的准确性和充分性，决定着对问题的揭露能力。 $ 测试用例是设计出来的，不是填出来的。 $ 梳理测试用例设计规范，设计模版与方法。 $ 测试用例是测试工作的重中之重。 $ 模版是一种常见的解决问题的标准化方法，是工程化的一种体现。 $ 公共测试用例库。

还是自己的用例自己看的快又清晰。 看同事xmind形式的用例，一个头两个大。

读《软件测试之困》 day01 摘写思考序二中的一段话： 【测试工程商人】// 现在还没读到后面，还不知道具体该怎么理解。 【投入产出比ROI】 思考如何基于风险开展测试活动？ 是否能确保所有已完成的测试都比那些还没开展的测试的优先级更高？ 是否已经优先测试了那些风险和优先级更高的部分？ 让严重bug尽可能多的尽早暴露？