测试概论
软件生命周期 研发组织和流程 测试工作包含的内容 常见测测试方法
只有熟悉测试的工作内容以及测试对软件开发的作用才能更好的编写特定的程序提高测试效率
软件生命周期
不同行业的软件生命周期长短不同，软件生命周期越短，一般质量要求越低。无论是什么类型的企业，软件生命周期中包含的需要完成的工作是类似的。
计划
项目经理根据 项目时间，资源投入，预期收益 制定项目计划，项目计划规定了后续各个工作的出发点。 需求分析 在一些业务比较复杂的行业，比如金融行业，需求分析由专人(业务分析员BA)完成，业务比较简单的行业，电商行业，需求分析由开发负责。 比如为登录功能进行需求分析。 功能描述 用户输入账号(会员名，邮箱或手机号),密码，点击登录，实现密码登录功能 输入 输入参数1：会员名/邮箱/手机号
- 会员名要求是字母数字的组合，长度6-10位；
- 邮箱要求符合邮箱地址的格式要求
- 手机号为纯数字，长度为 11位
输入参数2： 密码 密码要求：字母、数字、特殊字符发的组合，长度 6-12 位。 业务规则
- 如果输入的账户名和密码正确，登录成功；
- 如果输入的密码错误，提示账户名或密码错误；
- 如果账户名不存在，提示账户名或密码错误；
- 如果账户名为空，提示账户名不能为空；
- 如果密码为空，提示密码不能为空。
设计
借助建筑工程的例子类比软件的设计是什么
建筑设计师设计图纸来指导建筑工人建造高楼，设计图纸上可以得到高楼有多少个房间，以及每个房间的作用，房子建好后通常需要装修工人来根据室内设计师的图纸进行室内施工
- 系统架构师或资深开发工程师，给出软件的概要设计(HLD)
软件----子系统/模块 ----函数
- 高级开发工程师给出每个函数的详细设计(LLD)
login()
{
........
if 账户名为空
提示账户名不能为空
.........
}
编码:开发写的代码
测试
由专门的测试工程师完成。
尽早发现软件中存在的问题，并协助开发人员完成问题的定位和修复
运行维护
由运维工程师完成。
运维工程师负责环境的维护、软件上线/升级、线上问题收集反馈等
研发组织和流程
研发组织
研发流程
将软件生命周期中工作按照一定的顺序排起来就形成了不同的研发流程
研发流程可以分为
- 串行流程和并行流程
串行流程比较简单，对管理的要求低；并行流程比较复杂，对管理的要求高。 - 迭代开发和非迭代开发
迭代开发能让用户尽早使用到软件，尽早获取用户的反馈，但多次迭代后软件的质量会下降，软件整体会越来越散，需要隔段时间就进行代码重构
常见的研发流程
-
瀑布流程
特点：串行，非迭代。适合周期短，功能简单的项目。测试接入晚，很可能出现测试时间不够的情况
-
螺旋流程
特点： 迭代开发+瀑布模型，适合周期长，业务的相关性弱的项目
- IPD 集成产品开发
将研发、采购、 生产等都放到一起并行开展工作
测试工作的阶段和活动
四个阶段： 软件测试的工作属于软件研发中的一部分，可以进一步细分为四个阶段：
- 系统测试
- 集成测试
- 单元测试
- 验收测试
软件测试工作实际就是要从各个角度对被测软件进行检查，尽早发现软件中存在的问题，并帮助开发人员定位和修复。
测试用例
测试用例是给测试工程师看的，而且主要是给自己看的。有的公司直接用思维导图来写测试用例，主要是写用例标题
缺陷报告
缺陷相关的术语：错误、缺陷、故障、失效 人为的错误导致软件出现缺陷，缺陷在一定的条件下触发产生故障，如果故障不能很好的处理，可能会产生失效（实际过程中没必要区分这些术语） 缺陷的特点
- 群居性，缺陷往往是扎堆的。作为测试工程师，发现缺陷后，需要考虑多做一做相关的测试，看能否发现更多的缺陷。
- 抗药性，如果测试时只选用一种方法或者思路，必然会有些缺陷发现不了。测试时，需要尽量多用不同的方法和思路来进行测试。
一、测试需求分析概要
1. 什么是测试需求分析
在面临一个待测试的产品时通常留给测试人员的时间已经是非常紧张了，不可能对产品的每一个点都做测试 需要在测试前确定要测试的功能点以及对这些功能点做什么样的测试。(毕竟是老板给你钱的需要对老板负责，抬杠的同学可以去电子厂打1个月的螺丝看看什么是资本家)
2. 为什么做测试需求分析
- 客户对需求描述不够清晰，没有考虑到各个角度，测试人员通过测试人员的发散思维能做全面的检查和分析
- 测试人员需要参与需求分析，参与需求的整个跟踪过程，使得大家对需求的理解是一致的
- 通过测试需求分析能够发现测试依据中的一些缺陷，早期解决缺陷，做到预防
- 测试需求分析是对后续一系列测试工作进行指导的
3. 如何做测试需求分析
需求工程
- 需求开发
- 需求获取：和客户交谈，市场调研；问卷调查；观察；原型；焦点小组会议；头脑风暴（个人觉得如果产品靠谱的话可以参考产品的调查资料）
- 需求分析：功能；性能；安全性；界面；技术；进度；质量
- 需求定义： 软件需求规格说明书
- 需求验证：技术 成本 进度可行性
- 需求管理
- 需求分配
- 需求评审： 文档的格式；语言描述的精确度；功能需求；性能需求；本地化；需求优先级；需求属性；需求的编号名称
- 需求基线： 类似于产品的北极星指标 一般有老板确定，不能随意变动
- 需求跟踪-RTM Requirement Track Matrix 开发工作和测试工作完整
- 需求变更控制--CR Chane Reques --CCB Change Control Board--变更控制委员会
- 测试需求分析过程
- 测试需求获取
- 测试需求分析
- 测试需求整理
- 运用测试阶级方法定义测试用例设计
| 测试需求获取渠道 | 解释说明 | 举例 |
|---|---|---|
| 开发需求获取渠道 | 从开发人员的文档或者和开发人员进行沟通交流确定要测试的内容、测试项。DR--XX（Development Requirement | 1.详细设计文档、组件规格说明书； 2.接口设计文档；架构图；概要设计文档 3.软件需求规格说明书 |
| 标准协议需求获取渠道 | 从软件产品发布的国家、所服务的行业的法律、法规处罚确定要测试的内容、测试项。PR--XX（Protocol Requirement) | 电商法；银行法规；保险法规；税法；证券交易 |
| 竞争需求获取渠道 | 从竞争对手的产品分析和市场已有的产品进行分析确定要测试的内容、测试项。CR--XX（Competition Requirement） | 美团 饿了么 |
| 继承需求获取渠道 | 从以往的软件版本中分析有哪些需求在新版本中继续沿用，通过新旧版本的需求的关联强度确定要测试的内容、测试项 SR--XX（Succeed Requirement） | 支付宝春节集五福 |
| 用户关联需求获取渠道 | 分析使用软件系统的用户人群，通过不同人群对软件系统的操作，确定要测试的内容、测试项。UR--XX（User Requirement） | 管理类型的软件： ERP；OA；CRM |
| 案例库需求获取渠道 | 从已有的缺陷库、用例库、用户问题库中确定要测试的内容、测试项 ER--XX（Established Requiement） | 客服对于已上线系统，客户使用时提出的使用问题。 |
- 测试需求分析方法
- 将不同测试渠道获取的需求进行分析整理，通过分析方法对需求进行分类，通过分析将相同的需求进行合并整理
- 通过软件质量模型的各个特性进行分析对测试需求进行分类
- 功能交互分析法
5. 用户关联分析法
了解使用软件系统的用户角色，每个用户角色对软件系统的操作流程，确定操作流程，每一个流程和路径上的功能点要测试内容。
5. 总结：面对一个软件/产品如何做需求分析
测试分析实战： 慕课网 做测试需分析
测试场景： 为登录功能设计测试用例
测试员为什么要会编测试用例
测试员的目标是要保证系统在各种场景下的功能是符合设计要求的。而测试用例就是测试员想到的测试场景。（这也是高级别的测试员即使不会代码也能找到较好工作的原因）
编写测试用例的思路
等价类，边界值，正交 判定表 因果图 状态迁移图 场景分析 错误猜测法，其中等价类和边界值是最基础最重要的 我的思路是80%的用例使用这两种写，剩余的20使用其他方法。（其他测试方法是对等价类和边界值做了抽象） 等价类 将可能的场景分为一个有效等价类和多个无效等价类，后续只要从每个等价类中任意选取一个值进行测试，就可以用少量具有代表性的测试输入取得较好的测试覆盖结果（等价类：一组数据或因素对程序产生的影响是一样的） 边界值：使用等价类筛选后，选取边界上的再次进行验证（正好等于、刚刚大于或刚刚小于边界的值作为测试数据）
为登录功能设计测试用例 输入框：用户名 输入框：密码 按钮： 登录 功能 用户名
- 等价类：
- 有效的等价类：已经注册的用户名；已注册但是不合法的用户名
- 无效等价类未注册但是合法的用户名； 已注册但是不合法的用户名（特殊字符；长度）； 未注册的用户名 ， 空，空格
- 边界值： 空，长度恰好在需求范围外 特殊字符 密码
- 等价类
- 有效等价类：与用户名对应的正确的密码；
- 无效等价类： 与用户名对应的正确的密码；空，不正确的密码，不合法的密码（SQL注入） 结果
- 等价类：
- 有效等价类：登录成功
- 无效等价类：登录失败，提示信息正确；登录失败，提示信息不正确
非功能 非功能测试一般是在功能测试完之后在进行的，否则即使非功能测试的结果再好但是不能满足业务的需求，那就是做无用功。
当测试服务器主机是Windows Server： 判断一下对大小写有没有限制（Windows不区分大小写） 利用Charless等代理工具测试待测软件在弱网和网络切换时的情况 密码框是否加密显示（不可复制，不能猜出位数，浏览器查看源码的情况下也是加密的） 后台系统创建的用户第一次登录成功时，是否提示修改密码；（高校给学生购买了某网课平台的在线课程一般是用学号作为账户名） 验证码的时效性（验证码有效期内，有效期外，恰好在有效期与无效期，同一用户或IP是否有每天获取验证码的次数） 刷新页面是否会刷新验证码 普通用户登录后访问了管理员有权访问的页面是否阻止访问并给出提示信息 页面内容展示后页面的默认焦点是否在用户名的输入框中，且Tab和Enter可以使用 同一用户在同一终端的多种浏览器上登录，验证登录功能的互斥性是否符合设计预期； 同一用户先后在多台终端的浏览器上登录，验证登录是否具有互斥性。
单用户登录的响应时间是否小于 3 秒；单用户登录时，后台请求数量是否过多； 高并发场景下用户登录的响应时间是否小于 5 秒；高并发场景下服务端的监控指标是否符合预期； 高集合点并发场景下，是否存在资源死锁和不合理的资源等待；长时间大量用户连续登录和登出，服务器端是否存在内存泄漏。
不同浏览器下，验证登录页面的显示以及功能正确性； 相同浏览器的不同版本下，验证登录页面的显示以及功能正确性； 不同移动设备终端的不同浏览器下，验证登录页面的显示以及功能正确性；不同分辨率的界面下，验证登录页面的显示以及功能正确性。
测试用例的格式
| 项目 | 版本 | 需求标识 | 需求名称 | 用例标识 | 用例描述 | 预置条件 | 测试步骤 | 期望结果 | 优先级 | 创建人 | 创建时间 | 维护人 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| XXX理财产品 | V1.0 | R0001 | 交易查询 | TC_DL_003 | 交易查询页面_快速查询条件验证_快速查询选择1天，选择交易状态为已委托，查看筛选内容结果，与筛选条件一致 | 1.当前账户中有已购买的理财产品数据，可供查询 | 1.点击交易查询 2.选择交易状态为已委托，快速查询选项1天，点击交易查询3.查看查询结果内容 | 1.进入交易查询页面 2.查询成功 3.筛选查询内容与筛选条件一致 | 中 | 张小剑 | 2020/09/01 | 张小剑 |
测试用例管理与复用
excel--->数据库
总结
一个优秀的测试工程师应该是有非常广阔的知识面： 产品，开发，运维，数据分析， 安全等软件公司各个方面知识都有所涉猎的“八爪鱼” 这样才能看到软件的整体，甚至是看到软件的短时间内的未来 软件测试是一个妥协的过程，需要平衡测试的投入与产出，不可能做到穷尽测试保证软件完全没有BUG 就目前来说，如果开发用的时开源的主流技术一般不会出现明显的BUG，这也是一些公司没有测试员的原因，且行业内对高级测试员的要求是：一个懂业务懂测试的全栈。
