功能测试培训.pptxVIP

功能测试+LoadRunner 分享;分享内容：;一、用例设计;提取测试点举例一：;提取测试点举例二：Xmind 思维导图;提取测试点举例三：Visio 流程图;（2）分析得到用例优先级 得到了需求的各个测试点后，应该先将这些测试点简单的分配一下优先级，我认为得到优先级后可以让需求用例的设计更有侧重和着重点。 （3）细化测试点变成可执行用例 根据测试需求分析得到的需求框架，梳理细化测试点，这里的测试点虽然粗，但是不应该有遗漏，这是进行测试点细化的前提。根据测试点，细化出具体的测试用例。 在细化测试点的时候，我们可以要参考以前写好的公共测试用例，甚至可以直接引用，这样既可以避免一些不必要的时间浪费，但是参考不等于照搬，在引用的同时，也一定要思考本次需求自己特有的测试点。 用例注意事项：完整性（覆盖全部需求，不能有遗漏的功能 ）、不重复、不多余 ;细化测试点得到可执行用例举例：;（4）及时更新测试用例 需求分析和用例编写阶段，是主要的细化用例时间，这段时间的目标是梳理出可指导执行测试的用例，但是需求会有变动，需求会有维护，用例也一样，所以用例是需要持续维护的， 所以在需求变动的同时，我们也要及时维护测试用例，否则的话，测试用例很可能成为一个错误的指导。 另外测试用例完成后就会进入一个用例评审的阶段，在用例评审阶段，会有用例评审人，针对你的用例作出的评审，主要检查你的用例是否有测试点遗漏，场景遗漏，测试case描述模糊，测试结果输出模糊等问题，针对用例评审人提出的问题，我们也要及时的更改我们的用例。 ;（5）及时维护通用测试用例 什么是通用测试用例呢？我理解的通用测试用例就是：项目中或者跨项目中很多的公用业务，固化模块，这些功能基本上是趋于稳定不变的，因此可以梳理出通用的比较全面的测试点，作为指导和规范业务和模块的规范，这些生成的规范即通用的测试用例。当我们针对某一模块或者业务持续维护时，就发现我们需要持续维护这的用例，就会发现有些用例业务类似、执行步骤一致、验证项属性一致???等，这个时候通过梳理业务的通用属性，通用用例梳理梳理成章。所以说，通用的测试用例是一个对用例不断维护的产出，因此我们在测试软件维护的过程中一定要及时的更新通用测试用例，对后面的测试和用例维护有一个很大的指导作用。 比如：登录、界面显示（列表页面、弹窗页面等） ;2、如何提升用例设计能力 （1）熟悉业务，了解系统 任何系统都有大的业务背景，只要熟悉了业务知识才能更有效的使用系统。 任何系统在使用过程中，都有一个熟悉的过程，对系统越熟悉，越容易发现系统问题和业务问题。 （2）用客观的思考方式站在用户的角度分析 作为测试人员如果想提升测试用例的编写能力，首先应该做到的就是站在客户的角度分析客户需要什么和客户想要什么，客户不想要什么，也就是所谓的客户的使用场景，这样有利于我们更好的挖掘和思考隐含的需求。至于这个需求该不该做，那是需求人员的职责，这个需求做起来复不复杂那是开发人员的事情，作为测试人员需要考虑的事就是你所设计的正向和反向测试用例是不是用户常用到的场景，以及一些客户基本不会用到的场景有哪些。 ;（3）多思考，不要拘束于惯性思维 我们知道一个人做一个工作时间越久，也就是我们说的经验越丰富，可能这个思维方式就会越被限定住。比如，测试的统计表多了，当拿到一个新增的统计表的时候，首先想到的是公用用例上所列的测试点基本上就是最全的了，我都不用思考，直接用就行了。 其实这是一个误区，公用用例的目的是帮助我们减少一些不必要的内耗，但是我们的思维不要被它所限定，如果公用用例中某个点是错的，那我们岂不要一错再错了。所以作为一个测试人员如果想要提升自己的测试用例设计能力，一定要多思考，不要被这种惯性思维束缚，不要被所谓的经验束缚。 ;（4）不要闭门造车，利用好网络资源 提升测试用例设计能力，多思考是非常重要的，但是不是让你傻思考，当你的进步遇到瓶颈的时候，不要闭门造车，做井底之蛙，要充分利用网络上的学习资源，学习一些前辈的经验，并把这些运用到实际的测试用例设计中去。山外青山楼外楼，多浏览和关注一些关于测试用例设计的网站或者微信公众号，广开言路，相信会对你的测试用例设计能力的提升会有很大的帮助的。 （5）善于总结分享 基于以上四点我们还要做到善于总结，乐于分享，把经常见到的用例设计的误区和一些好的用例设计，和用例设计习惯分享给周围的小伙伴，这样可以集众人之所长，不断提升我们的用例设计能力。 ;二、如何快速发现bug;1、充分利用软件缺陷的二八定律 （1）定义： 80%的软件缺陷存在于20%的软件代码中（软