前言

记录下自己的测试知识，后面如果有改进再回来优化

测试用例的目标与价值

首先要知道一件事情，质量的追求是无上限的但是公司的钱不是无穷的，我们不可能发现所有的Bug，但是要保证本次需求战略目标能够达成，高成本低价值的检查点可以视情况放弃。
测试用例存在的价值：

如何保证团队统一理解需求，统一质量要求，统一验收标准？需要将这些东西记录下来，大家一起确认统一看法，最后上线的时候才不会出现问题：所以测试用例需要详细目标，详细预期结果验收要求。
理清楚思路，避免遗漏。团队内基本都是普通人，需要一种工具整理清楚检查点，检查一个记一个这样才不会遗漏：所以测试用例结构需要清晰，避免结构混乱影响到覆盖面。
多人一起测试分工的时候非核心成员不知道业务细节难上手怎么办？一段时间后需要重复测试如何避免时间长忘记需求？那么就需要一种工具记录清楚检查点作用，具体操作手册：所以测试用例需要写清楚检查原因，详细操作步骤，预期结果。减少重复学习时间，优点业务基础就能够快速上手测试。
产品这么大，功能点那么多，测试资源就这些，我们该如何有效分配，优先保证重要功能质量，这样就算出Bug影响也少：所以测试用例要表明测试用例优先级，优先完成重要的测试。
Bug紧急修复，如何快速回归，那些是需要着重点测试，那些不影响？那么就需要一种工具记录清楚Bug发现方式，Bug可能关联的功能点：所以测试用例需要按照业务流、功能模块等方式进行划分管理，这样才能快速找到关联功能进行覆盖。还需要添加测试用例优先级，重要的点先覆盖，不重要的也不影响。
开发参考文档，一个好的测试用例能够给到开发很好的参考，提前完成代码优化。
新人上手培训手册，测试用例是最好的培训手册基本上照着执行一边该知道的都知道了（前提是测试用例步骤清晰）。

质量目标分析

个人看法

我个人是推崇完成质量目标最低要求就行了，更多的精力放在产品发展上。

可能会有人问，一直按照最低目标做事，整个团队都按照最低目标做事叠加在一起整体质量还会好吗？
那就可能理解错了，我推崇的是达成目标不做过多的事情，而不是想办法偷懒达成目标。

但是这样的宣导可能会导致一种风气：已经能够达成目标不需要再优化 ->东西够用就行 -> 什么地方我可以偷懒？。所以有些公司不考虑实际情况喜欢把目标定的很高，心理想的是目标定高了做出来的东西再差也不会太差，最后的时候做不到再去折中、去调整浪费时间去沟通，这样大家就很累，徒增很多工作量。可是有些东西其实做的再好对整体产品影响也不大，白白浪费资源。

针对这点我的看法是最低目标实现去考核，团队宣导则是好刚要用在刀刃上，精力要留给重要工作。所以要多以公司战略层面出发沟通去工作，为什么要这样做？是为了达成什么目标而且去做？而不是直接分配安排组员的工作内容。当然这里的沟通成本就会提高不少，就需要统一工作会议先说清楚战略目标，任务分配时基于战略目标说清楚任务目标。

这里举个极端例子：当前产品预估拥有1w级别用户流量，但是还没有登录注册功能，后续需要根据不同用户支持个性化配置。那么目标就是用户登录功能能够实现，性能达到1w用户在线就可以了。不用纠结10w、100w用户如何扩展测试（后续系统如何快速支持扩展100w用户级别是架构师考虑的事情），保证当前用户体验不变快速推出用户需要的功能才是产品发展壮大的重点。

这样才能够减少团队压力同时释放更多的精力完善产品核心优势。

分析流程

常见的项目测试流程：痛点分析 -> 需求调研 ->需求设计 -> 质量目标分析与评审 -> 测试设计与沟通 -> 测试用例编写与评审 -> 功能测试 -> 性能、稳定性、易用性等其他测试 -> 上线前主干测试(UAT测试) -> 生成测试
以战略目标为基础，逐步拆分需求目标，再拆分质量目标，根据质量目标拆分测试用例

参考例子：
- 痛点收集：目前系统是没有登录功能的，不同用户进来我们是不知道的，后面要针对不同用户进行定制化服务、推动都是做不到的。
- 需求调研：
  * 场景分析：网站后续会存在一些定制化功能，需要根据不同的用户进行定制化展现，例如：积分系统、VIP、个性化设置等，当前需要一种方式区分用户保证以上功能能够针对不同用户进行特定展示。
  * 竞品分析：xxxx使用登录功能xxxx。
- 需求设计：我们根据以上面的需求进行设计出来了一个用户管理系统，用户可以自主进行注册、登录、注销。需求的目标就是能够保证用户能够自主注册、登录、注销，用户注册通过后存在唯一标识，能够支持到后续定制化功能的开发。
- 质量目标分析：
  * 基础业务：用户可以自主进行注册、登录、注销。具体细节参考需求详细设计说明。
  * 性能：每秒10个用户同时注册、每秒10个用户同时登录、每秒10个用户同时注销、同时10000用户在线。
  * 稳定性：系统服务异常重启，已注册用户数据不丢失，已登录用户需要重新登录。
  * 安全性：无
  * UI要求：UED保证
  * 升级发布：支持平滑升级
- 测试用例：xxxxx

以上例子简单举例了下质量目标拆分，当然具体工作肯定是需要大量沟通，质量目标提供依据说明这个是能够满足我们产品要求的。

测试设计

测试设计通常可以理解为草稿，思路大纲，测试点罗列等事情，主要的作用就是在测试人员理解需求、测试目标后梳理的测试点，测试方法。拿出来与产品、开发快速沟通确认，要尽可能罗列测试点，可以不用明细测试步骤细节，后续的测试用例编写就要以此为基础进行编写。

场景分析法（业务流分析）

着重从“谁”“什么状态”“做什么”考虑，将三者根据不同的流程进行组合分析再去细化覆盖。

谁，也就是角色，比如：游客、管理员、普通用户等。
什么状态，也就是角色状态，比如：被禁用、已注销、无权限等。
做什么，也可以理解为业务流，比如：登录后注销、登录后查询xxx数据等。

比如：

普通用户、被禁用状态、登录 -> 查询数据 -> 注销
游客、未登录状态、登录 -> 查询数据 -> 注销
普通用户、已登录系统、重复登录 -> 查询数据 -> 注销

以上的业务流写的很粗糙，实际的业务流会很细节，根据不同的业务流细化出不同的分支能做啥

这里简单细化一个业务流：游客用户注册 -> 登录 -> 查询数据 -> 注销

游客注册：
- 注册成功：
  - 直接登录
    - 登录成功
      - 查询xxx数据
        
        注销登录
    - 登录失败
      - 输入错误用户名密码
  - 隔一段时间登录
  - 多地登录
- 注册失败：
  - 失败后重新注册成功
    - 直接登录
  - 注册失败后放弃
    - 输入格式错误
    - 用户已存在

接口测试

着重关注业务逻辑、异常参数、边界值，具体就不细说后面再补充。

控件测试

输入控件主要关注：边界值、特殊字符等情况
交互控件，比如按钮主要关注展示效果
这些东西正常来每个控件都会有检查表，如果没有可以自己列一下，然后照着检查就行了。

关联测试

通常漏测都会出现在这一点上，个人经验通常是维护一套模块关联表，说明不同模块直接的业务、数据、技术架构影响，每次需求同步更新。
检查点：

上下游数据关联：
不同平台数据关联：手机app、PCweb、平板等
服务状态关联：新增了个禁用状态，删除了个什么状态
服务调用关联：比如A调用B服务，如果B挂了怎么办，如果B的调用接口改了怎么办
外部服务管理：前端JS、CSS调用公共OpenApi，手机APP支付功能调用支付宝等。

性能测试

性能测试的主要是回答几个问题：

我现在能做什么：系统是否能够满足当前用户级别需求？
我有什么问题：系统是否存在需要优化的点或者性能Bug？
未来有成长空间：系统如果后续要进行性能扩展需要做什么事情？成本是多少？能够优化到什么程度？

举例：

性能测试要求：压力要求支持1w用户同时在线，每秒10个用户同时注册，每秒10个用户同时登录，每秒10个用户同时注销。并发要求支持1分钟内每秒40用户同时注册。
- 压力测试：
  - 单场景
    - 同时在线
      - 1k用户同时在线24小时
      - 5k用户同时在线24小时
      - 1w用户同时在线24小时
    - 注册测试
      - 每秒5个用户同时注册，持续1小时
      - 每秒10个用户同时注册，持续1小时
      - 。。。。。
  - 组合场景
    - 1w用户同时在线，每秒10个用户同时注册，每秒10个用户同时登录，每秒10个用户同时注销，持续24小时。
- 并发测试：
  - 单场景
    - 注册测试
      - 每秒20个用户同时注册，持续1分钟。
      - 每秒40个用户同时注册，持续1分钟。

异常场景测试

弱网、手机APP资源不够、重启等，后面扩展

其他（再说吧）

测试用例编写格式

模板主要包括：用例编号、用例标题、前置条件、测试步骤、预期结果、实际结果，其他的字段可以看团队情况调整方便管理。

所属迭代：迭代01
所属项目：xxx
所属模块：xxx
用例类型：业务测试

模板1：标题会很长，也不宜阅读，增加一列简单描述用例

用例编号	用例标题	用例描述	前置条件	测试步骤	预期结果	实际结果
xxx_1	游客_未注册情况_注册新用户_登录查询数据_注销	游客注册后查询数据	无	1. 打开登录页面: www.123.com 2. 点击注册新用户 3. 输入用户名: xxx, 密码: xxx 4. 注册提交 5. 返回页面，输入用户名: xxx, 密码: xxx ，提交登录 6. 登录成功后打开xxx页面 7. 查询数据xxxx 8. 注销登录	1. 成功打开页面 2. 跳转到注册页面 4. 提示注册成功 5. 登录成功 6. 成功展示xxx页面 7. 查询成功，正确展示数据xxxx 8. 注销成功，返回登录页面

模板2: 标题更加着重说明测试内容，目录层级会很多，如果用例管理系统没有很好的管理方式不建议

用例编号	目录	用例标题	前置条件	测试步骤	预期结果	实际结果
xxx_1	游客/未注册情况/注册新用户/登录查询数据	游客注册后查询数据	无	1. 打开登录页面: www.123.com 2. 点击注册新用户 3. 输入用户名: xxx, 密码: xxx 4. 注册提交 5. 返回页面，输入用户名: xxx, 密码: xxx ，提交登录 6. 登录成功后打开xxx页面 7. 查询数据xxxx 8. 注销登录	1. 成功打开页面 2. 跳转到注册页面 4. 提示注册成功 5. 登录成功 6. 成功展示xxx页面 7. 查询成功，正确展示数据xxxx 8. 注销成功，返回登录页面

测试用例管理

管理结构

基线
- 鉴权
  - 用户注册
- 查询报表
开发中
- 迭代一
  - 登录需求
    - 鉴权
      - 用户注册

结构说明
基线：所有开发完成且以上线的需求用例统一合并管理，按照模块进行划分
开发中：所有开发中的需求，按照迭代 -> 需求说明 -> 模块 进行层级划分