软件测试

一、白盒测试技术

程序插桩：实现对程序语句的执行（如统计次数），变量的变化等情况进行检查。
逻辑覆盖：包括以下几类：语句覆盖，判定覆盖，条件覆盖，判定/条件覆盖，条件组合覆盖，路径覆盖。覆盖是指至少运行一次。
1.语句覆盖：使得每一可执行语句至少执行一次。
2.判定覆盖：每个判定（流程图里的菱形）的每个取值分支（true or false）至少经历一次。
3.条件覆盖：判定中每个条件的所有可能结果至少出现一次。
4.判定/条件覆盖：同时满足判定覆盖和条件覆盖。
5.条件组合覆盖：使所有判定中各条件判断结果的所有组合至少出现一次。
6.路径覆盖：所有可能的执行路线至少执行一遍，即判定组合。
各种覆盖的关系是语句覆盖<判定覆盖<路径覆盖；条件覆盖<条件组合覆盖；(条件覆盖<>判定覆盖)<判定/条件覆盖；路径覆盖<>条件组合覆盖<>判定/条件覆盖。
基本路径测试：在流程图基础上来设计测试用例保证语句覆盖。

二、黑盒测试技术

等价类划分：有效等价类与无效等价类。
边界值分析方法：同时考虑输入域和输出域边界，输入域边界可以取等价类的每个边界。
非功能测试：强度测试，性能测试等。

压力测试目的：
1. 测试产品/系统在大压力下的稳定性和性能表现，以及压力的极限性能。包括通过产品日志来分析的，如请求处理的压力，错误率、延迟率，平均处理时间等；以及可以使用第三方程序观察产品本身或者通过机器的环境指标来观察的参数，最重要的是：物理内存使用率，cpu idle等，其他指标包括：内存类：swap使用率，cpu类：阻塞进程数，硬盘：空间使用率，网卡：网卡总接收比特数、网卡总发送比特数，网络状态：tcp丢包数、活动的TCP连接数、已建立的TCP连接数、TIME_WAIT的TCP连接数，IO：平均I/O队列长度、平均I/O等待时间、每秒读K字节数、每秒写K字节数。
2. 通过对压力数据的处理，可以使用压力来提高测试的覆盖面，对多种多样的数据进行测试（例如直接采用线上日志来作为压力数据），并且通过空间和时间的置换来达到高压力取代长时间测试的目的。
3. 通过压力测试来支持AB test，以分析和发现产品重构或者优化后出现的问题。

三、测试过程

按过程可以分为单元测试、集成测试、系统测试。测试对象分别为模块、模块间的接口、整个软件。

　

单元测试

接口集成测试

系统测试

Case编写成本

QA介入的话投入成本高

接口可测性强，黑盒测试难度低，投入成本三者间最小

UI逻辑组织、调试耗时长，成本高

Case稳定性

合理解耦，稳定性高

脱离UI，稳定性较系统级测试要高

受浏览器、前端特性影响稳定性不高

Case执行效率

高

接口执行快，较系统测试要高

受前端特性影响，串行执行效率低

测试介入时机

置前

较系统测试易于置前

置前难度大

自动化实施范围

面向细粒度单元，不能覆盖多个单元集成

面向web后端完整业务逻辑

面向web前后端整体逻辑

四、相关概念

CMMI：全称是Capability Maturity Model Integration, 即软件能力成熟度模型集成模型，它不仅仅是对产品质量的认证，更是一种软件过程改善的途径。CMMI 模型的前身是 SW-CMM 和 SE-CMM，前者就是我们指的CMM。CMMI与SW-CMM的主要区别就是覆盖了许多领域；
ISO9000：是指质量管理体系标准，它不是指一个标准，而是一族标准的统称。它的应用范围涵盖了所以相关的产品种类。

五、自动测试工具

功能测试工具：MI公司的WinRunner，Rational公司的Robot，Compuware公司的QARun。他们的基本原理都是通过录制和回放来实现自动化的功能测试，只是在具体形式上有所差别。比如，WinRunner包括两种测试的模式：环境判断模式（基于所选择的GUI对象，与物理位置无关；可以创建GUI map，从而把文件维护从测试脚本中分离）和模拟模式（记录鼠标单击和在二维平面上的精确运动轨迹，记录键盘输入）。
主流负载性能测试工具：QA Load，SilkPerformer，LoadRunner，WebRunner，以及免费的OpenSTA，WAS等。他们通过录制、回放脚本、模拟多用户同时访问被测试系统来制造负载，产生并记录各种性能指标，生成分析结果。比如，LoadRunner可以录制所有支持的协议，然后调用这些脚本向服务器端发出请求并接受服务器的响应。
资源监控工具：在许多测试工具中都有集成，也有更直观的监控产品，如QUEST公司提供一整套监控解决方案。
Xunit：单元测试框架，有诸多实现，如JUnit，CppUnit，CUnit等。

良好的可读性、运行的独立性、可重复执行性，是自动化测试case必须要关注的方面。如果做不到，后期就会带来巨大的维护成本，自动化测试也变成得不偿失。

六、编写测试用例

1. Checklist的内容和模板

对被测对象的分层和结构化
1 UI UE
2 功能 （复杂逻辑，主要业务，数据流，对其他功能影响）
3 性能
4 数据校验
5 安全 （传输中的数据加密）
6 冲突测试（并发）
7 流程测试
8 发布流程 部署方法及验证
9 系统结构
10 第三方依赖的
11 兼容（版本、浏览器、平台、接口变动后的支持）
12 对外部系统影响
13 监控
14 日志

测试分类

测试模块

测试子模块

特殊测试点

UE/UI

　

　

　

功能

　

　

　

性能

　

　

　

数据

　

　

　

安全

　

　

　

冲突测试（多线程并发）

　

　

　

对外部系统影响

　

　

　

兼容

　

　

　

第三方依赖

　

　

　

系统结构

　

　

　

监控

　

　

　

日志

　

　

　

发布流程 

　

　

　

2. 常用的测试用例设计方法

等价类划分
数据测试
   边界条件
   边界值
   非法和异常
流程和状态转移
   流程图
   状态机

3. “好”的测试用例是什么样的？

发现错误的可能性很高
不冗余
最佳组合
独立执行

4. Test Case书写规范四要素

标题：
         需要简明扼要的描述出所要测试的功能，以及所要确认的功能测试点
           规则：【项目名称】测试功能摘要
属性：
case优先级，case类型，执行方法。（如有特殊的操作环境要求，需添加）操作系统版本，浏览器版本
测试步骤：  
           1.操作步骤
           2.测试中需要输入的测试数据
           3.备注—特殊说明     
期望结果：
          1. 输入测试值期望得到的结果
          2.  测试数据产生的测试结果（如果需要）
          3. 附加截图（如果需要，如需求中有做好的产品图片，便于比对结果）

七、Bug与Bug管理

1. 提交有效bug

精准定位+细致撰写+完整提交

2. 如何定位bug

确定是否为本系统BUG：是否排除了数据脚本、配置、环境及第三方依赖的影响

清楚BUG产生的场景、前提

找到BUG重现的最小路径：测试步骤涉及多个测试点时，要反复尝试

3. 如何撰写BUG

BUG标题：
位置 + 功能 + 操作 + 现象
“【交易接口】【担保撤销】支付宝分账网关担保撤销时判断了保险账户金额，导致保险商户余额不足无法退款 ”
“【历史订单手续费计算】批量计算手续费时DBCONFIRMIN的金额没有扣除手续费” 
复现步骤：
（前提）+ 步骤 + 结果 + 期望 + （备注）
备注：
涉及的具体数据信息；SQL脚本；异常日志
附件 ：
截图：直观表现问题所在
测试数据：利于快速复现

4. BUG路径管理

创建分支
按年、季度划分
项目分支名称加上需求编号
按项目涉及模块划分
指定项目负责人（默认为指派人）

5. 输出测试报告

内容：
测试进度情况（完成第几轮或哪几部分测试）
目前遇到的问题及风险
用例执行情况（执行个数、失败个数、新发现BUG数）
BUG验证情况（修复并关闭个数、修复但重现的个数）
分布统计截图、待修复的BUG列表
后续安排

分布统计：
用例：执行结果分布
BUG：按模块分布、按指派者分布