目录
1.软件测试
2.需求
2.1 用户需求
2.2 软件需求
2.3 测试人员眼里的需求
2.4 需求的重要性
3.测试用例
3.1 什么是测试用例
3.2 为什么有测试用例
4.BUG
4.1 BUG的概念
4.2 如何描述一个BUG
4.3 如何定义BUG的优先级
4.4 BUG的生命周期
5.软件生命周期
6. 软件开发模型
① 瀑布模型 (Waterfall Model)：往往适用于需求非常稳定的项目。
② 螺旋模型(Spiral Model)：大型项目，具有一些风险适用于螺旋模型。
③ 迭代、增量模型
④ 敏捷模型
7.软件测试模型
① 软件测试v模型
② 软件测试W模型
8.软件测试生命周期
1.软件测试
定义：软件测试就是一系列活动，这些活动是为了评估一个程序或者软件系统的特性或能力，并确定是否达到了预期的效果。
软件测试是一个过程，就是进行一个比较，拿着预期的结果和程序的执行结果作比较。
特点：软件测试只是一个样本试验，具有不可穷尽性。
2.需求
满足用户期望或正式规定文档（合同、标准、规范）所具有的条件和权能，包含用户需求和软件需求。
在大多数软件公司，会有两部分需求，一部分是用户需求，一部分是软件需求。
大多数公司在进行软件开发的时候会把用户需求转化为软件需求，开发人员和测试人员工作的直接依据 就是软件需求。
软件需求是测试人员进行测试工作的基本依据。
用户需求比较简答，软件需求越详细越好。
2.1 用户需求
可以简单理解为甲方提出的需求，如果没有甲方，那么就是终端用户使用产品时必须完成的任务。该需求一般比较简略。
2.2 软件需求
或者叫功能需求，该需求会详细描述开发人员必须实现的软件功能。
2.3 测试人员眼里的需求
需求是测试人员开展软件测试工作的依据。
测试人员以“用户登陆”为例，来阐述下整个过程：
业务需求—>软件功能需求点—>测试需求点—>测试用例
2.4 需求的重要性
① 从软件功能需求出发，无遗漏的识别出测试需求是至关重要的，这将直接关系到用例的测试覆盖率。
② 对于识别出的每个测试需求点，需要采用具体的设计测试用例的方法来进行测试用例的设计。
3.测试用例
3.1 什么是测试用例
测试用例（Test Case）是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。
3.2 为什么有测试用例
执行测试用例的时候，绝大部分的测试点都是参考测试用例执行的。
① 测试用例解决测试人员工作重复性的问题。
② 测试用例可以提高测试人员的效率。
③ 测试用例是自动化的基础。
4.BUG
4.1 BUG的概念
准确的来说：当且仅当规格说明是存在的并且正确，程序与规格说明之间的不匹配才是错误。
当需求规格说明书没有提到的功能，判断标准以最终用户为准：当程序没有实现其最终用户合理预期的功能需求时，就是软件错误。
4.2 如何描述一个BUG
① 发现BUG的版本
② 问题出现的环境：PC电脑，手机，浏览器型号、版本
③ 错误重现的步骤：通过什么样的操作可以出现这个问题
④ 预期行为的描述：预期结果的描述
⑤ 错误行为的描述：执行结果的描述
⑥ 其他：bug标题，bug优先级
⑦ 不要把多个bug放到一起
4.3 如何定义BUG的优先级
bug的定义每个公司都不一致，在定义级别之前需要查看公司规范。
① 崩溃(Blocker)：阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错 误，主要功能丧失，基本模块缺失等问题。
② 严重(Critical)：系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他 功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用 冲突，安全问题、稳定性等。
③ 一般(Major)：功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。
④ 次要(Minor)：界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。
4.4 BUG的生命周期
测试人员应该跟踪一个Bug的整个生命周期，从Open到Closed的所有状态。
bug的不同状态：Start 与 End 不是流程里的状态，只是开始，结束标志。
● New:新发现的Bug，未经评审决定是否指派给开发人员进行修改。
● Open：确认是Bug，并且认为需要进行修改，指派给相应的开发人员。
● Fixed:开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。
● Rejected：如果认为不是Bug，则拒绝修改。
● Delay:如果认为暂时不需要修改或暂时不能修改，则延后修改。
● Closed：修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug。
● Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。
无效的bug：open->closed open-rejected-closed
5.软件生命周期
软件的生命周期：软件从诞生到不能使用。
软件的生命周期可以分成6个阶段，即需求分析、计划、、设计、编码、测试、运行维护。
① 需求分析
测试人员产出需求文档(软件规格说明书)
开发人员判断需求是否合理，需求是否完整。
② 计划
软件开发让谁去做，软件什么时候开始开发，什么时候结束开发。
③ 设计
UI设计师：产出一个UI设计稿
开发人员：产出一个技术文档(接口，库表，缓存，mq...)
④ 编码
写代码实现需求
⑤ 测试
执行测试，提出BUG，验收BUG，发送测试报告。
⑥ 运行维护
上线、维护线上软件质量(当发现线上BUG，测试人员需要复现BUG，开发人员需要修复问题)
6. 软件开发模型
① 瀑布模型 (Waterfall Model)：往往适用于需求非常稳定的项目。
瀑布模型在软件工程中占有重要地位，是所有其他模型的基础框架。瀑布模型的每一个阶段都只执行一 次，因此是线性顺序进行的软件开发模式。
特点：每个阶段之间的关系是线性的。
优点：每一个阶段要做的工作非常的清楚。
缺点：产品效果出现的较晚。如果测试人员介入的太晚，以至于如果测试阶段发现问题，需要不断的向前回溯，如果需求出现问题，此时我们之前的工作(开发，测试)付之东流，需求需要重新设计。
② 螺旋模型(Spiral Model)：大型项目，具有一些风险适用于螺旋模型。
特点：每一次实施的时候都要进行风险分析。
优点：风险分析可以避免一些未知的问题。
缺点：风险分析错误，会导致一系列的损失。风险分析需要一定的成本。
③ 迭代、增量模型
例如淘宝：登录、注册、搜索、查看商品信息、支付……
迭代：先开发淘宝-登录大概框架，先开发淘宝-注册大概框架，先开发淘宝-搜索大概框架，查看，支付……
增量：先开发登录直到登录开发结束再去开发注册，注册开发结束在进行下一步……
增量：适用于模块和模块之间没有任何关系。
迭代：项目先看到雏形，然后再仔细开发最终实现项目。
④ 敏捷模型
敏捷宣言：
个体与交互重于过程和工具。
可用的软件重于完备的文档。
客户协作重于合同谈判
响应变化重于遵循计划
在每对比对中，后者并非全无价值，但我们更看重前者。
特点：重沟通，轻流程。重支付，轻文档。重协作，轻谈判。拥抱变化。
Scrume角色：
PO：产品经理，收集用户需求
SM：项目经理，对项目进行计划、对需求进行优先级排序。
Team：研究团队(开发---实现需求、测试---负责项目测试、设计师---产出交互设计稿)
Scrume具体流程：
7.软件测试模型
① 软件测试v模型
特点：线性的；左边是开发，右边是测试。
优点：将测试分为了好多种类型。每个阶段要做的工作非常明确。
缺点：测试介入的太晚，测试和开发是串行的。
② 软件测试W模型
特点：开发一个V，测试一个V。
优点：测试人员尽早介入了需求。开发人员和测试人员并行的。
缺点：测试和开发相应来说也是串行的。不能拥抱变化，不能适用于敏捷。
8.软件测试生命周期
软件测试的生命周期：
需求分析→测试计划→ 测试设计、测试开发→ 测试执行→ 测试评估→维护上线。
每一个阶段测试人员做的工作
需求分析：分析需求正确性、完整性
测试计划：who(由谁测试)，when(何时开始测试、何时结束测试，测试点有哪些)
测试设计：编写测试用例、编写测试工具、测试用例评审
测试执行：执行测试用例，发现BUG，提交BUG，验收BUG...
测试评估：产出一个测试报告
运行维护：上线、维护线上软件质量(当发现线上BUG，测试人员需要复现BUG，开发人员需要修复问题)
