功能测试培训.pptx

功能测试 LoadRunner分享 分享内容 用例设计如何发现bugAppscan使用介绍 一 用例设计 1 如何编写用例 1 测试需求分析 得到测试点在测试需求分析阶段 我们只有需求文档 所以编写测试用例的唯一依据就是需求文档 因此在进行用例编写之前一定要进行需求分析 需求分析的主要工作就是 了解需求的整个实现背景 分析需求的合理性 明确需求的范围 挖掘需求文档中隐藏的需求 在通过需求交底的过程 确定开发的初步实现思路和方法 随着测试需求分析的深入 列出需求的框架 包括测试范围即各个功能点 测试的场景等 确定一些测试可以提前介入的工作等 需要说明的是对于需求中的问题一定要记录下来 找需求确认 需求漏掉的或者存在问题的地方 开发和测试更容易漏掉 而且遗漏的需求很有可能会使得项目整体业务逻辑发生变化 一定要及时提前确认 提取测试点举例一 提取测试点举例二 Xmind思维导图 提取测试点举例三 Visio流程图 2 分析得到用例优先级得到了需求的各个测试点后 应该先将这些测试点简单的分配一下优先级 我认为得到优先级后可以让需求用例的设计更有侧重和着重点 3 细化测试点变成可执行用例根据测试需求分析得到的需求框架 梳理细化测试点 这里的测试点虽然粗 但是不应该有遗漏 这是进行测试点细化的前提 根据测试点 细化出具体的测试用例 在细化测试点的时候 我们可以要参考以前写好的公共测试用例 甚至可以直接引用 这样既可以避免一些不必要的时间浪费 但是参考不等于照搬 在引用的同时 也一定要思考本次需求自己特有的测试点 用例注意事项 完整性 覆盖全部需求 不能有遗漏的功能 不重复 不多余 细化测试点得到可执行用例举例 4 及时更新测试用例需求分析和用例编写阶段 是主要的细化用例时间 这段时间的目标是梳理出可指导执行测试的用例 但是需求会有变动 需求会有维护 用例也一样 所以用例是需要持续维护的 所以在需求变动的同时 我们也要及时维护测试用例 否则的话 测试用例很可能成为一个错误的指导 另外测试用例完成后就会进入一个用例评审的阶段 在用例评审阶段 会有用例评审人 针对你的用例作出的评审 主要检查你的用例是否有测试点遗漏 场景遗漏 测试case描述模糊 测试结果输出模糊等问题 针对用例评审人提出的问题 我们也要及时的更改我们的用例 5 及时维护通用测试用例什么是通用测试用例呢 我理解的通用测试用例就是 项目中或者跨项目中很多的公用业务 固化模块 这些功能基本上是趋于稳定不变的 因此可以梳理出通用的比较全面的测试点 作为指导和规范业务和模块的规范 这些生成的规范即通用的测试用例 当我们针对某一模块或者业务持续维护时 就发现我们需要持续维护这的用例 就会发现有些用例业务类似 执行步骤一致 验证项属性一致等等 这个时候通过梳理业务的通用属性 通用用例梳理梳理成章 所以说 通用的测试用例是一个对用例不断维护的产出 因此我们在测试软件维护的过程中一定要及时的更新通用测试用例 对后面的测试和用例维护有一个很大的指导作用 比如 登录 界面显示 列表页面 弹窗页面等 2 如何提升用例设计能力 1 熟悉业务 了解系统任何系统都有大的业务背景 只要熟悉了业务知识才能更有效的使用系统 任何系统在使用过程中 都有一个熟悉的过程 对系统越熟悉 越容易发现系统问题和业务问题 2 用客观的思考方式站在用户的角度分析作为测试人员如果想提升测试用例的编写能力 首先应该做到的就是站在客户的角度分析客户需要什么和客户想要什么 客户不想要什么 也就是所谓的客户的使用场景 这样有利于我们更好的挖掘和思考隐含的需求 至于这个需求该不该做 那是需求人员的职责 这个需求做起来复不复杂那是开发人员的事情 作为测试人员需要考虑的事就是你所设计的正向和反向测试用例是不是用户常用到的场景 以及一些客户基本不会用到的场景有哪些 3 多思考 不要拘束于惯性思维我们知道一个人做一个工作时间越久 也就是我们说的经验越丰富 可能这个思维方式就会越被限定住 比如 测试的统计表多了 当拿到一个新增的统计表的时候 首先想到的是公用用例上所列的测试点基本上就是最全的了 我都不用思考 直接用就行了 其实这是一个误区 公用用例的目的是帮助我们减少一些不必要的内耗 但是我们的思维不要被它所限定 如果公用用例中某个点是错的 那我们岂不要一错再错了 所以作为一个测试人员如果想要提升自己的测试用例设计能力 一定要多思考 不要被这种惯性思维束缚 不要被所谓的经验束缚 4 不要闭门造车 利用好网络资源提升测试用例设计能力 多思考是非常重要的 但是不是让你傻思考 当你的进步遇到瓶颈的时候 不要闭门造车 做井底之蛙 要充分利用网络上的学习资源 学习一些前辈的经验 并把这些运用到实际的测试用例设计中去 山外青山楼外楼 多浏览和关注一些关于测试用例设计的网站或者微信公众号 广开言路 相信会对你的测试用例设计能力的提升会有很大的帮助的 5 善于总结分享基于以上四点我们还要做到善于总结 乐于分享 把经常见到的用例设计的误区和一些好的用例设计 和用例设计习惯分享给周围的小伙伴 这样可以集众人之所长 不断提升我们的用例设计能力 二 如何快速发现bug 什么是bug 需求规定要做的 却没有实现需求规定不要做的 却实现了需求没有提到的 也实现了需求没有提到 但是必须要做而又未实现的客户体验 很难理解 很难使用 响应慢等 有用 易用 好用 友好 1 充分利用软件缺陷的二八定律 1 定义 80 的软件缺陷存在于20 的软件代码中 软件缺陷的 群集 现象 一般情况下 在分析 设计 实现阶段的复查和测试工作能够发现和避免80 的缺陷 而系统测试又能找到剩余缺陷的80 最后的4 的缺陷可能只有在用户大范围 长时间使用后才会暴露出来 2 应用 80 20法则的应用 至少应分为两个阶段 阶段的划分取决于目标时间的长短 目标时间相对长的 可以划分为两个以上的阶段 单个阶段的时间可以适当的长一些 否则 阶段应少一些 单个阶段的时间短一些 第一个阶段是快速的进行一轮软件测试 获得软件缺陷在各模块的分布情况 第二个阶段 根据上一阶段软件缺陷在各模块的分布情况 重点测试软件缺陷分布较多的模块 如果有第三甚至更多的阶段 把上一阶段作为第一阶段 根据上一阶段软件缺陷在各模块的分布情况 重点测试软件缺陷分布较多的模块 以此类推 这样的话 我们就可以花费较少的时间 发现较多的软件缺陷 2 从不同角度进行测试从不同角度进行测试 我们可以在短时间内发现较多的软件缺陷 从开发人员的角度考虑 获知开发人员认为软件产品中那些模块开发难度大 缺乏信心 从而快速定位我们的测试重点 从最终客户的角度考虑 尽可能从他们的既有的使用习惯和可能的问题出发 也就是用户体验出发 找出尽可能多的软件缺陷 3 善于怀疑世界上没有绝对正确的 总有错误的地方 具有叛逆心理 别人认为不可能发生的事 我却认为可能发生 别人认为是对的 我却认为是错的 假如一个水平很高的程序员编写的程序 不要有 他写的这个程序应该没有问题吧 这种想法 这样很容以遗漏软件中的Bug 4 参照其他测试人员报告的软件缺陷每个人的思维都是有局限性的 我们可以参照其他测试人员报告的软件缺陷 获取新的测试思路 从而发现以前未曾发现的软件缺陷 5 不要让程序员 用户不会这样操作 的观点说服自己遇到这样的情况 你要坚持自己的正确的观点 把这种现象作为一个Bug 6 随机测试 即使经过大量的充分测试 也不能发现软件中的所有缺陷 所以在测试的时候可以做一些随机测试 比如胡乱在界面上乱点 有时也会发现一些意想不到的软件缺陷 1 态度 耐心仔细 2 根据用例执行 但不限于用例 需要随时保持发散思维 3 兼容