软件测试基本概念(2)
1.什么是软件？
软件的定义：包括两个部分
软件=程序+文档
程序是能够实现某种功能的指令的集合，如JAVA,VB
文档是指软件在开发、使用和维护过程中产生的图文集合，如《系统需求规格说明书》、《用户手册》、Readme,甚至是一些软件市场宣传材料、包括文字和图形等。
2.什么是软件测试？
2.1 软件测试定义：
使用人工或自动的手段，来运行或测试某个系统的过程及其文档。其目的在于检验它是否满足规定的要求或弄清预期结果和实际结果之间的差别。
2.2 软件项目流程;
2.2.1. 需求评审：（此过程必不可少）
（1）需求稿更新或者变更最好让开发or QA修订版本且每个版本用不同的颜色标注，并让策划确认最终版本，方便需求的跟踪记录，以免后期发生不必要的纠纷。
（2）发现需求bug、模糊和遗漏的地方
2.2.2. 交互视觉评审：（可简化）
决定了产品的表现层形式，并让大家在直观展示产品功能的情况下更好的验证需求，明确产品目标。
2.2.3. 开发设计评审：（可简化）
（1）开发设计评审的目的是让项目组各个成员了解开发的设计思路，从而发现开发设计上的缺陷或者与需求不符合的地方，也能让各个开发之间的分工合作更加清晰、明朗。
（2）代码、框架、数据库设计
2.2.4.测试计划及评审（可简化）：
2.2.5.测试用例及评审（必不可少）：
需要补充用例的情形
测试过程中发现用例覆盖不全；
出现线上bug；
测试过程中临时增加需求；
已有测试用例还可能在测试过程中根据具体实现情况进行更新（如验证点，期望结果等）；
非用例发现问题的场景（包括开发自验，联调）
2.2.6.测试过程：
（1）必要测试：冒烟测试---》功能测试+新需求功能功能---》回归测试
（2）性能测试：检查应用的负载能力，简单的性能测试可以由系统测试人员完成，一般是在系统测试阶段的中后期开始进行，这样可以尽量保证无critical级别的bug阻碍性能测试执行。那么什么样的项目需要做性能测试呢？根据我们的经验，如果一个项目是新项目，而且预期上线后马上就会有很大的用户量，那肯定是需要做性能测试的；如果是维护期的项目，框架和用户量变动都不大，那么可以省略性能测试环节；当然，具体情况还是需要具体分析
（3）安全性测试/易用性测试：
2.3 好的测试工作方式：
（1）.bugbash有开发、策划、视觉、产品经理、项目经理一起参与，会发现很多意想不到的bug以及体验上的问题
(2).站会： 一般是开发、测试人员会介绍昨天做了什么，今天要做什么，遇到了什么问题
（3）日报：
l 测试的日报应该包括以下几点内容：
l 测试环境：在哪个机器上测试的；
l 测试资源：人员安排；
l 测试模块及进度：告知项目组每个模块的测试进度；
l Bug统计：bug的增长趋势及各个状态bug的分布图，帮助项目组了解整个项目的质量情况。
l 项目风险及解决情况：测试过程中遇到的问题以及是否解决。
（3）测试质量报告：告知产品测试了哪些内容、目前存在哪些遗留bug和风险，并对测试过程的质量状况进行分析
（4）项目总结：项目优缺点，优点下个项目继续沿用，缺点提出解决方案并在下个项目中跟踪。
3.软件测试流程（在项目中体会会更深刻）
3.1 测试需求分析--》测试计划--》测试设计--》测试执行--》测试记录
测试需求分析：获取测试对象，你要测什么？what?参照需求给出的《需求规格说明书》和开发给出的《详细设计说明书》，自己通过查资料和参加培训学习业务相关知识
A.明确需求的范围及实现效果，具体做成什么样子，是否可测，排出优先级
B.明确每一个功能点业务，前后台处理，对于模糊的需求进行澄清
C.明确业务流程，前后台处理，对于模糊的需求进行澄清
D.状态流转变化图，要在需求中识别以下4种状态：识别各种状态、引起状态转移的操作、相关的状态转移、状态转移导致的动作。
E.挖掘业务背后的隐式需求，非功能性需求（性能、安全、易用、可靠性）
需求分析主要按照完整性、正确性和二义性三方面分析：
完整性检查
- 项目范围：明确项目实现的功能从而确定测试范围
- 验证措施及属性：输入值的验证，如参数的边界值，异常处理等
- 系统与子系统、模块间关系：是否清晰描述系统与其子系统以及模块之间的需要验证系统之间页面的跳转，传递的参数，这个主要是用于项目中涉及到系统之间的调用的情况
- 历史数据 ：如果是对于老系统的改造，那对于历史数据应该如何处理，以及数据如何进行迁移
- 页面展现 ：页面显示内容以及相应的跳转
- 功能交互分析 ：需求是否考虑到异常的情况等
- 规格确认：明确产品性能或其他方面的规格
正确性和二义性检查
目标使得需求文档中不存在模糊、模棱两可的问题，对此可建立起一个二义性检测清单：
表2 二义性检测checklist
| 模糊类型 | 说明 |
|---|---|
| Else模糊 | 例如输入框内数字限制为0～99（那么指定范围之外输入会怎样？） |
| 指代模糊 | 例如可将范围1合并到范围2，这个范围才是有效范围（这个具体指什么？） |
| 逻辑操作模糊 | 与，或，非，与非等复合操作符使用不当 |
| 优先级模糊 | 因果混淆，用例先后次序不严谨 |
| 异常分支是否说明 | 预期之外的事情，如上传图片失败、登录失败、确认失败等等 |
| 隐含需求 | 语法检查 、度量方式 、相关术语的说明、内容冲突 、增删改检查 |
按照业务模块（大模块）下的业务流程（子模块），子模块中的输入项（等价类划分+边界值）、按钮、业务条件/约束、数据输入和输出（场景法）、数据库变化进行比较细致的分析其中场景分析法包括以下几种场景：
- 正常的用例场景
需求中提到的正常的操作流程：包括事件名称，输入数据、输出数据。
- 备选的用例场景
在正常的操作流程中添加某些特定的条件，对于这种类型的场景我们可以列出一份问题检查表。
1）场景中每一步是否都和需求相符
2）对于场景中每一个需求定义和执行动作我们是否都理解并统一认识（与策划和开发）
3）场景中是否存在一些主观上的判断（想当然）
4）我是否已经做了所有的假设
5）这么做是否真正有意义
- 异常的用例场景
发现异常用例场景的方法：
1）什么样的数据条件将会导致这一步不能继续处理
2）什么样的历史数据将会导致这一步不能继续处理
3）什么样的人为行为将会导致这一步不能继续处理
- 假定推测场景
在以正常的用例场景作为起点，对每一个步骤鉴别约束条件，如果约束条件不存在，会怎么样？
3.2测试计划：
3.2.1 针对开发周期比较长，各阶段目标区分比较明显的项目，明确测试范围和测试任务、测试策略和方法、测试环境与辅助工具、人力和时间资源分配、测试风险分析（5点）
关于测试策略和测试方法（后面有详细介绍）：
A.黑盒测试：输入数据，检查输出是否与实际相符合
B.白盒测试
C.静态测试
D.动态测试
3.2.2 针对敏捷性互联网开发， 敏捷性的项目讲究沟通重于文档，在我们看来，测试人员只要把思路都理清了，把可能碰到的问题都考虑到了，项目组其他成员对于测试的工作安排也清楚了，那不写测试计划文档也是没问题的。
3.3测试设计：测试环境设计（包括软硬件环境、数据库环境）、测试用例设计、辅助工具自动化脚本的编写
3.3.1 关于测试用例的设计（另有文章详细介绍）：
前提条件：
A.了解需求
B.了解开发数据库设计和接口设计
测试用例（公用和特有的）包括：
A.冒烟测试用例（可用于开发自测）
B.新功能测试用例
C.回归测试用例
C1我们可以选择系统的核心功能、已经最容易出错的模块或者功能的测试用例组成回归测试用例集，放弃那些非关键的、优先级较低或者已经非常稳定的模块的测试用例，因为这些模块即使测到bug，也可能只是noramal级别以下的bug。
C2当我们发现此次测试的版本的功能全部为新增功能，或者对原来的功能造成的影响非常小的时候，我们可以将回归测试局限到此次新开发的功能以及局部受影响的功能上，在允许的条件下，回归测试用例集尽量覆盖到受影响的部分。
3.3.2 测试策略和方法
3.4 测试执行：测试环境搭建，测试用例执行、自动化脚本执行
测试执行流程？：
单元测试-》集成测试-》系统测试-》验收测试
3.5 测试记录：缺陷跟踪记录、测试总结分析报告
3.什么是bug?(评价测试人员的标准：有效的bug数和编写有效的测试用例数)
缺陷的分类:
不符合用户需求的问题，主要分为3类：
(1)完全没有实现的功能，比如用户需要你在软件中实现A、B、C三个功能，你只实现了A、B功能，而没有实现C这个功能，因此可以视为一个bug.
(2)基本实现了用户需要的功能，但是运行过程中会出现功能或性能上的问题，诸如经常报错或导致系统死机，响应时间未达到用户要求等问提。
(3)实现了用户不需要的功能，多余的功能。比如用户需要你实现A、B、C三个功能，你却实现了A、B、C、D四个功能，则功能D可以看做是一个BUG.
缺陷描述：
(1)确保重现bug
(2)要用最少且必要的步骤描述bug
例子：
测试版本：
updates_2015.06.24_1.5.5.0_35915
描述：
【1.5.5.0】【运维端】转换机插入新三板行情任务，交易市场为1上交所（应该是j股转市场）(详见附件)
步骤：
1)登陆运维端，系统管理-转换机任务维护
2)高级查询，股转交易操作员输入，查询
期望结果：
行情任务 交易市场应该显示为股转市场
实际结果：
行情任务 交易市场显示为上交所A