功能测试培训PPT课件
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
• 另外测试用例完成后就会进入一个用例评审的阶段，在用例评审阶段，会有用例评 审人，针对你的用例作出的评审，主要检查你的用例是否有测试点遗漏，场景遗漏， 测试case描述模糊，测试结果输出模糊等问题，针对用例评审人提出的问题，我们也 要及时的更改我们的用例。
.
10
• （5）及时维护通用测试用例
•
什么是通用测试用例呢？我理解的通用测试用例就是：项目中或者跨项目中很多
• （3）细化测试点变成可执行用例
•
根据测试需求分析得到的需求框架，梳理细化测试点，这里的测试点
虽然粗，但是不应该有遗漏，这是进行测试点细化的前提。根据测试点，
细化出具体的测试用例。
•
在细化测试点的时候，我们可以要参考以前写好的公共测试用例，甚
至可以直接引用，这样既可以避免一些不必要的时间浪费，但是参考不等
求很有可能会使得项目整体业务逻辑发生变化，一定要及时提前确认。
.
3
提取测试点举例一：
.
4
.
5
提取测试点举例二：Xmind 思维导图
.
6
提取测试点举例三：Visio 流程图
.
7
• （2）分析得到用例优先级
•
得到了需求的各个测试点后，应该先将这些测试点简单的分配一下优
先级，我认为得到优先级后可以让需求用例的设计更有侧重和着重点。
.
15
• 1、充分利用软件缺陷的二八定律
• （1）定义： 80%的软件缺陷存在于20%的软件代码中（软件缺陷的“群集”现象）
– 一般情况下，在分析、设计、实现阶段的复查和测试工作能够发现和避免80%的缺陷， 而系统测试又能找到剩余缺陷的80%，最后的4%的缺陷可能只有在用户大范围、长时 间使用后才会暴露出来。
用例不断维护的产出，因此我们在测试软件维护的过程中一定要及时的更新通用测试
用例，对后面的测试和用例维护有一个很大的指导作用。
– 比如：登录、界面显示（列表页面、弹窗页面等）
Hale Waihona Puke Baidu
.
11
• 2、如何提升用例设计能力
• （1）熟悉业务，了解系统
•
任何系统都有大的业务背景，只要熟悉了业务知识才能更有效的使用系统。
于照搬，在引用的同时，也一定要思考本次需求自己特有的测试点。
• 用例注意事项：完整性（覆盖全部需求，不能有遗漏的功能 ）、不重 复、不多余
.
8
细化测试点得到可执行用例举例：
.
9
• （4）及时更新测试用例
• 需求分析和用例编写阶段，是主要的细化用例时间，这段时间的目标是梳理出可指 导执行测试的用例，但是需求会有变动，需求会有维护，用例也一样，所以用例是需 要持续维护的， 所以在需求变动的同时，我们也要及时维护测试用例，否则的话，测 试用例很可能成为一个错误的指导。
的公用业务，固化模块，这些功能基本上是趋于稳定不变的，因此可以梳理出通用的
比较全面的测试点，作为指导和规范业务和模块的规范，这些生成的规范即通用的测
试用例。当我们针对某一模块或者业务持续维护时，就发现我们需要持续维护这的用
例，就会发现有些用例业务类似、执行步骤一致、验证项属性一致等等，这个时候通
过梳理业务的通用属性，通用用例梳理梳理成章。所以说，通用的测试用例是一个对
求人员的职责，这个需求做起来复不复杂那是开发人员的事情，作为测试人员需要考
虑的事就是你所设计的正向和反向测试用例是不是用户常用到的场景，以及一些客户
基本不会用到的场景有哪些。
.
12
• （3）多思考，不要拘束于惯性思维
•
我们知道一个人做一个工作时间越久，也就是我们说的经验越丰富，可能这个思维
方式就会越被限定住。比如，测试的统计表多了，当拿到一个新增的统计表的时候，
.
13
• （4）不要闭门造车，利用好网络资源
•
提升测试用例设计能力，多思考是非常重要的，但是不是让你傻思考，当你的进
步遇到瓶颈的时候，不要闭门造车，做井底之蛙，要充分利用网络上的学习资源，学
习一些前辈的经验，并把这些运用到实际的测试用例设计中去。山外青山楼外楼，多
浏览和关注一些关于测试用例设计的网站或者微信公众号，广开言路，相信会对你的
•
任何系统在使用过程中，都有一个熟悉的过程，对系统越熟悉，越容易发现系统问
题和业务问题。
• （2）用客观的思考方式站在用户的角度分析
•
作为测试人员如果想提升测试用例的编写能力，首先应该做到的就是站在客户的角
度分析客户需要什么和客户想要什么，客户不想要什么，也就是所谓的客户的使用场
景，这样有利于我们更好的挖掘和思考隐含的需求。至于这个需求该不该做，那是需
测试用例设计能力的提升会有很大的帮助的。
• （5）善于总结分享
•
基于以上四点我们还要做到善于总结，乐于分享，把经常见到的用例设计的误区和
一些好的用例设计，和用例设计习惯分享给周围的小伙伴，这样可以集众人之所长，
不断提升我们的用例设计能力。
.
14
二、如何快速发现bug
• 什么是bug?
• 需求规定要做的，却没有实现 • 需求规定不要做的，却实现了 • 需求没有提到的，也实现了 • 需求没有提到，但是必须要做而又未实现的 • 客户体验：很难理解、很难使用、响应慢等（有用、易用、好用、友好）
功能测试+LoadRunner 分享
分享内容：
• 用例设计 • 如何发现bug • Appscan使用介绍
.
2
一、用例设计
• 1、如何编写用例
• （1）测试需求分析，得到测试点
•
在测试需求分析阶段，我们只有需求文档，所以编写测试用例的唯一依据就是需
求文档，因此在进行用例编写之前一定要进行需求分析，需求分析的主要工作就是：
首先想到的是公用用例上所列的测试点基本上就是最全的了，我都不用思考，直接用
就行了。
• 其实这是一个误区，公用用例的目的是帮助我们减少一些不必要的内耗，但是我们 的思维不要被它所限定，如果公用用例中某个点是错的，那我们岂不要一错再错了。 所以作为一个测试人员如果想要提升自己的测试用例设计能力，一定要多思考，不要 被这种惯性思维束缚，不要被所谓的经验束缚。
了解需求的整个实现背景；分析需求的合理性；明确需求的范围，挖掘需求文档中隐
藏的需求；在通过需求交底的过程，确定开发的初步实现思路和方法，随着测试需求
分析的深入，列出需求的框架，包括测试范围即各个功能点，测试的场景等；确定一
些测试可以提前介入的工作等；需要说明的是对于需求中的问题一定要记录下来，找
需求确认，需求漏掉的或者存在问题的地方，开发和测试更容易漏掉，而且遗漏的需
.
10
• （5）及时维护通用测试用例
•
什么是通用测试用例呢？我理解的通用测试用例就是：项目中或者跨项目中很多
• （3）细化测试点变成可执行用例
•
根据测试需求分析得到的需求框架，梳理细化测试点，这里的测试点
虽然粗，但是不应该有遗漏，这是进行测试点细化的前提。根据测试点，
细化出具体的测试用例。
•
在细化测试点的时候，我们可以要参考以前写好的公共测试用例，甚
至可以直接引用，这样既可以避免一些不必要的时间浪费，但是参考不等
求很有可能会使得项目整体业务逻辑发生变化，一定要及时提前确认。
.
3
提取测试点举例一：
.
4
.
5
提取测试点举例二：Xmind 思维导图
.
6
提取测试点举例三：Visio 流程图
.
7
• （2）分析得到用例优先级
•
得到了需求的各个测试点后，应该先将这些测试点简单的分配一下优
先级，我认为得到优先级后可以让需求用例的设计更有侧重和着重点。
.
15
• 1、充分利用软件缺陷的二八定律
• （1）定义： 80%的软件缺陷存在于20%的软件代码中（软件缺陷的“群集”现象）
– 一般情况下，在分析、设计、实现阶段的复查和测试工作能够发现和避免80%的缺陷， 而系统测试又能找到剩余缺陷的80%，最后的4%的缺陷可能只有在用户大范围、长时 间使用后才会暴露出来。
用例不断维护的产出，因此我们在测试软件维护的过程中一定要及时的更新通用测试
用例，对后面的测试和用例维护有一个很大的指导作用。
– 比如：登录、界面显示（列表页面、弹窗页面等）
Hale Waihona Puke Baidu
.
11
• 2、如何提升用例设计能力
• （1）熟悉业务，了解系统
•
任何系统都有大的业务背景，只要熟悉了业务知识才能更有效的使用系统。
于照搬，在引用的同时，也一定要思考本次需求自己特有的测试点。
• 用例注意事项：完整性（覆盖全部需求，不能有遗漏的功能 ）、不重 复、不多余
.
8
细化测试点得到可执行用例举例：
.
9
• （4）及时更新测试用例
• 需求分析和用例编写阶段，是主要的细化用例时间，这段时间的目标是梳理出可指 导执行测试的用例，但是需求会有变动，需求会有维护，用例也一样，所以用例是需 要持续维护的， 所以在需求变动的同时，我们也要及时维护测试用例，否则的话，测 试用例很可能成为一个错误的指导。
的公用业务，固化模块，这些功能基本上是趋于稳定不变的，因此可以梳理出通用的
比较全面的测试点，作为指导和规范业务和模块的规范，这些生成的规范即通用的测
试用例。当我们针对某一模块或者业务持续维护时，就发现我们需要持续维护这的用
例，就会发现有些用例业务类似、执行步骤一致、验证项属性一致等等，这个时候通
过梳理业务的通用属性，通用用例梳理梳理成章。所以说，通用的测试用例是一个对
求人员的职责，这个需求做起来复不复杂那是开发人员的事情，作为测试人员需要考
虑的事就是你所设计的正向和反向测试用例是不是用户常用到的场景，以及一些客户
基本不会用到的场景有哪些。
.
12
• （3）多思考，不要拘束于惯性思维
•
我们知道一个人做一个工作时间越久，也就是我们说的经验越丰富，可能这个思维
方式就会越被限定住。比如，测试的统计表多了，当拿到一个新增的统计表的时候，
.
13
• （4）不要闭门造车，利用好网络资源
•
提升测试用例设计能力，多思考是非常重要的，但是不是让你傻思考，当你的进
步遇到瓶颈的时候，不要闭门造车，做井底之蛙，要充分利用网络上的学习资源，学
习一些前辈的经验，并把这些运用到实际的测试用例设计中去。山外青山楼外楼，多
浏览和关注一些关于测试用例设计的网站或者微信公众号，广开言路，相信会对你的
•
任何系统在使用过程中，都有一个熟悉的过程，对系统越熟悉，越容易发现系统问
题和业务问题。
• （2）用客观的思考方式站在用户的角度分析
•
作为测试人员如果想提升测试用例的编写能力，首先应该做到的就是站在客户的角
度分析客户需要什么和客户想要什么，客户不想要什么，也就是所谓的客户的使用场
景，这样有利于我们更好的挖掘和思考隐含的需求。至于这个需求该不该做，那是需
测试用例设计能力的提升会有很大的帮助的。
• （5）善于总结分享
•
基于以上四点我们还要做到善于总结，乐于分享，把经常见到的用例设计的误区和
一些好的用例设计，和用例设计习惯分享给周围的小伙伴，这样可以集众人之所长，
不断提升我们的用例设计能力。
.
14
二、如何快速发现bug
• 什么是bug?
• 需求规定要做的，却没有实现 • 需求规定不要做的，却实现了 • 需求没有提到的，也实现了 • 需求没有提到，但是必须要做而又未实现的 • 客户体验：很难理解、很难使用、响应慢等（有用、易用、好用、友好）
功能测试+LoadRunner 分享
分享内容：
• 用例设计 • 如何发现bug • Appscan使用介绍
.
2
一、用例设计
• 1、如何编写用例
• （1）测试需求分析，得到测试点
•
在测试需求分析阶段，我们只有需求文档，所以编写测试用例的唯一依据就是需
求文档，因此在进行用例编写之前一定要进行需求分析，需求分析的主要工作就是：
首先想到的是公用用例上所列的测试点基本上就是最全的了，我都不用思考，直接用
就行了。
• 其实这是一个误区，公用用例的目的是帮助我们减少一些不必要的内耗，但是我们 的思维不要被它所限定，如果公用用例中某个点是错的，那我们岂不要一错再错了。 所以作为一个测试人员如果想要提升自己的测试用例设计能力，一定要多思考，不要 被这种惯性思维束缚，不要被所谓的经验束缚。
了解需求的整个实现背景；分析需求的合理性；明确需求的范围，挖掘需求文档中隐
藏的需求；在通过需求交底的过程，确定开发的初步实现思路和方法，随着测试需求
分析的深入，列出需求的框架，包括测试范围即各个功能点，测试的场景等；确定一
些测试可以提前介入的工作等；需要说明的是对于需求中的问题一定要记录下来，找
需求确认，需求漏掉的或者存在问题的地方，开发和测试更容易漏掉，而且遗漏的需