目录

一、需求

1.1用户需求

1.2软件需求

1.3需求的重要性

二、测试用例

三、BUG

3.1什么是BUG

3.2如何描述一个BUG

4.3BUG优先级

四、软件开发模型

4.1软件生命周期

4.2开发模型

定义：软件测试就是一系列活动，这些活动是为了评估一个程序或者软件系统的特性或能力，并确定是否达到了预期的效果。

可以将软件测试理解为一个过程，就是进行一个比较，拿着预期结果和程序执行结果作比较。

软件测试只是一个样本试验，具有不可穷尽性。

一、需求

需求就是满足用户期望或正式规定文档（合同、标准、规范）所具有的条件和权能，包含用户需求和软件需求。

用户需求比较简答，软件需求需要越详细越好。

1.1用户需求

可以简单理解为是甲方提出的需求，如果没有甲方，那么就是终端用户使用产品时必须要完成的任务，该需求一般比较简略。

1.2软件需求

也可以叫做功能需求，该需求会详细描述开发人员必须实现的软件功能。

1.3需求的重要性

从软件功能需求出发，无遗漏的识别出测试需求是至关重要的，这将直接关系到用例的测试覆盖率。

对于识别出的每个测试需求点，需要采用具体的设计测试用例的方法来进行测试用例的设计。

二、测试用例

什么是测试用例：测试用例是为了实施测试而被测试的系统提供的一组集合，这组集合包含：测试环境，操作步骤，测试数据，预期结果等要素。

执行测试的时候绝大部分测试点都是参考测试用例的。

为什么有测试用例：（1）测试用例解决测试人员工作重复性的问题。（2）测试用例可以提高测试人员工作效率。（3）测试用例是自动化的基础。

三、BUG

3.1什么是BUG

当且仅当规格说明是存在的并且正确，程序与规格说明之间的不匹配才是错误。当需求规格说明书没有提到的功能，判断标准以最终用户为准：当程序没有实现其最终用户合理预期的功能和要求时，就是软件错误；

3.2如何描述一个BUG

（1）发现BUG的版本

（2）问题出现的环境：PC电脑，手机，浏览器型号、版本。

（3）错误重现步骤：通过什么样的操作可以出现这个问题。

（4）预期行为的描述：预期结果的描述。

（5）错误行为的描述：执行结果的描述。

（6）其他：bug标题，bug优先级。

4.3BUG优先级

1、BUG为什么要分优先级

例如一共找到了10个BUG，1-3非常严重，今天必须修复完成。4-7这几个问题明天或者后天修复也行。8-10这几个问题影响不大，如果没有时间修复，也可以等下一个版本开发的时候再修复。

2、BUG有哪些优先级

（1）Blocker（崩溃）：

阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错 误，主要功能丧失，基本模块缺失等问题。如：代码错误、死循环、数据库发生死锁、重要的一级菜单 功能不能使用等（该问题在测试中较少出现，一旦出现应立即中止当前版本测试）。 （2）Critical （严重）： 系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他 功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用 冲突，安全问题、稳定性等。如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序 接口错误，数值计算统计错误等（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）。 （3）Major （一般）： 功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。如：操作时间长、查询 时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等( 该问题实际测试中存在最多） （4）Minor （次要）： 界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。如：错别字、界面格 式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）

四、软件开发模型

4.1软件生命周期

软件从诞生到软件不能使用就是软件生命周期。即需求分析，计划，设计，编码，测试，运行维护。

1、需求分析

PM（产品经理）

QA（测试）产出需求文档（软件规格说明书）。

RD（前端和后端开发）判断需求是够合理，需求是否完整。

2、计划

软件开发由谁去做，软件什么时候开发，什么时候结束开发。

3、设计

UI设计师产出一个UI设计稿。

开发人员产出一个技术文档（接口，库表，缓存，mq……）。

4、编码

写代码实现需求。

5、测试

执行测试，提BUG，验收BUG，发送测试报告。

6、运行维护

上线、维护线上软件质量（当发现线上BUG，测试人员需要复现BUG，开发人员需要修复问题）

4.2开发模型

1、瀑布模型

特点：每个阶段时间的关系是线性的。

优点：每一个阶段要做的工作非常的清楚。

缺点：产品效果出现的较晚，如果测试人员介入的太晚，以至于如果测试阶段发现问题，需要不断地向前回溯，如果需求出现问题，那么之前的工作付诸东流，需求需要重新设计。

往往适用于需求非常稳定的项目。

2、螺旋模型

特点：每一次实施的时候都要进行风险分析。

优点：风险分析可以避免一些未知的问题。

缺点：风险分析错误，会导致一系列的损失。风险分析需要一定的成本。

大型项目，具有一些风险一般适用于螺旋模型。

3、迭代、增量

例如淘宝：登录、注册、搜索、查看商品信息、支付……

迭代：先开发淘宝-登录大概框架，先开发淘宝-注册大概框架，先开发淘宝-大概大概框架，查看，支付……

增量：先开发登录直到登录开发结束再去开发注册，注册开发结束在进行下一步……

迭代适用于模块和模块之间没有任何关系。

增量：项目先看到雏形，然后再仔细开发最终实现项目。

4、敏捷开发模型

（1）敏捷宣言：个体与交互重于过程工具。可用的软件重于完备的文档。客户协作重于合同谈判。相应变化重于遵循计划。在每对比对中，后者并非全无价值，但我们更看重前者。

特点：重沟通，轻流程。重交付，轻文档。重交付，轻文档。重协作，轻谈判。拥抱变化。

（2）Scrume角色

PO：产品经理：收集用户需求。

SM：项目经理：对项目进行计划、对需求进行优先级排序。

Team：研发团队（开发、测试、设计师），分别作用是实现需求，负责项目测试，产出交互设计稿。

5、测试模型

（1）V模型

特点：线性的，左边是开发，右边是测试。

优点：将测试分为了好多种类，每个阶段要做的工作非常明确。

缺点：测试接入的太晚，测试和开发是串行的。

（2）W模型

特点：开发一个V，测试一个V

优点：测试人员尽早介入了需求，开发人员和测试人员并行的。

缺点：测试和开发相应来说也是串行的，不能拥抱变化，不能那个适用于敏捷。