1、测试原则
1）重要性，故障后损失程度（测试等级和测试重点）。
2）使用经可能少的测试用例，发现经可能多的程序错误。
确定测试方法时：
1）拿到一个测试任务时，先关注它的主要功能和业务流程，业务逻辑是否正确实现，考虑使用场景法。
2）需要输入数据的地方，采用等价类划分法，包括输入条件和输出条件的等价类划分，将无无限测试变成有限测试；
3）在任何情况下都必须采用编辑值分析法；
4）若程序的功能说明书中含有输入条件的组合情况（有因果关系），则一开始就采用因果图制判定表法。
5）对于参数配置类的软件，要考虑参数之间的组合情况，使用正交排列法选择较少的组合方式。
总结：
|
场景 |
首要考虑 |
测试方法 |
|
拿到测试任务时 |
功能和业务流程 |
场景法 |
|
任何情况/场景 |
|
边界值法 |
|
有数据输入时 |
输入/出条件 |
等价类划分法 |
|
功能说明中，有因果关系组合情况 |
条件桩（因）/动作桩（果） |
因果图制判定表法 |
|
有多个输入控件时 |
参数的组合情况 |
正交排列法 |
2、缺陷定义
程序、数据、文档中存在以下问题：
1）未达到需求文档的功能；
2）出现了需求文档指明不会出现的功能；
3）超出了需求文档指明的范围；
4）需求文档未指明，而产品应实现的目标，可软件没有达到；
5）不易理解、不易使用、运行速度曼、最终用户任务不好的。
3、缺陷表现形式
1）功能、特性、没有实现或部分实现；
2）设计不合理、功能特性不明确、逻辑不清或存在矛盾；
3）实际结果与预期结果不一致；
4）未达到需求文档所规定的性能指标；
5）运行出错、中断、崩溃、界面混乱；
6）数据不正确、精度不准确、不完整或个数不统一；
7）用户不能接受的问题；
8）硬件或系统软件上存在的问题。
4、缺陷状态分类
1）缺陷状态：
2）缺陷管理权限：
5、缺陷严重程度
|
类别 |
描述 |
例如 |
|
A-致命的-（Fatal/Blocker） |
造成系统或应用程序崩溃、死机、系统挂起，或造成数据丢失，主要功能完全丧失，导致本模块以及相关模块异常等问题。 |
代码错误，死循环，数据库发生死锁、与数据库连接错误或数据通讯错误，未考虑异常操作，功能错误… |
|
B-严重错误-（Critical） |
主要功能部分丧失、数据不能保存，系统次要功能完全丧失，问题局限在本模块，导致模块功能失效或异常退出。 |
致命的错误声明，程序接口错误，数据库的表、业务规则、缺省值未加完整性等约束条件… |
|
C-一般错误-（Major） |
次要功能没有完全实现但不影响使用（界面、性能、兼容性） |
提示信息不准确、用户界面查、操作时间长、模块功能部分失效… |
|
D-较小错误-（Minor） |
使操作不便，但不影响功能的操作和执行 |
错别字、界面不规范(字体大小不同呀、文字排列不整齐…) |
|
E-建议问题-（Enhancement） |
测试人员提出的建议、质疑 |
|
6、缺陷优先级
|
序号 |
状态 |
状态说明 |
例如 |
|
1 |
Low |
测试建议（非缺陷），可以在发布后在商量是否改进，或可不用解决。 |
1、测试建议； |
|
2 |
Medium |
不影响功能的正常使用，可以在资源充足的情况下解决。 |
1、辅助性说明描述不清楚； 2、显示格式不规范； 3、长时间操作未给用户进度提示； 4、提示窗口文字采用行业术语； 5、系统处理未优化； …… |
|
3 |
High |
事件是重要的，但由于解决问题需要花费一定的时间，所以可以用较长的时间解决，如果时间紧，可留到下个版本解决。 |
1、界面文字错误等； 2、打印内容、格式错误； 3、简单的输入限制未放在前台进行控制； 4、删除操作未给出提示； …… |
|
4 |
Very high |
重要事件，在发布前解决。 |
1、功能不符； 2、缺少功能，与需求不符； 3、数据流错误； 4、程序接口错误； 5、轻微的数值计算错误； …… |
|
5 |
Urgent |
非常重要事件，需要马上解决。 |
1）由于程序引起的死机，运行中断，程序崩溃等； 2）死循环； 3）数据库死锁； 4）数据通讯错误； 5）严重的数值计算错误； …… |
注：严重程度和优先级不是绝对的正比关系。
7、缺陷类型
|
1 |
系统缺陷 |
由程序引起的错误，不能执行正常的工作和重要功能，使系统崩溃或资源不足 |
|
2 |
数据缺陷 |
计算错误 |
|
约束错误 |
||
|
输入/出错误 |
||
|
3 |
数据库缺陷 |
数据库死锁 |
|
表、缺省值未加约束条件 |
||
|
连接错误 |
||
|
过多空字段 |
||
|
4 |
接口缺陷 |
数据通信错误 |
|
程序接口错误 |
||
|
5 |
功能缺陷 |
功能无法实现 |
|
功能实现错误 |
||
|
6 |
安全性缺陷 |
用户权限 |
|
超时限制 |
||
|
访问控制 |
||
|
加密错误（GET明文、POST密文） |
||
|
7 |
兼容性缺陷 |
操作系统 |
|
浏览器 |
||
|
终端 |
||
|
8 |
性能缺陷 |
未达到预期性能目标 |
|
性能测试中出错 |
||
|
9 |
界面缺陷 |
操作界面错误（与PSD/UI相符？） |
|
打印内容、格式错误 |
||
|
删除后未给出提示 |
||
|
长时间操作未给提示（如ATM） |
||
|
界面不规范 |
||
|
10 |
建议 |
功能建议 |
|
性能建议 |
|
代码错误 |
界面优化 |
设计缺陷 |
配置相关 |
安装部署 |
|
安全相关 |
性能问题 |
标准规范 |
测试脚本 |
其它 |
8、缺陷报告书写规范
1）保证缺陷可以重现；
2）缺陷描述、准确、清晰、完整；
3）一个缺陷一个报告（便于分配和验证）；
4）标题简短、准确、体现问题本质；
5）浮现步骤的描写要完整、准确、简短；
6）实际结果描述：现响、行为。
9、缺陷处理流程/生命周期
10、问题
1）Q:如何测试网络协议？
A:
|
1 |
一致性测试 |
检测协议实现本身与协议规范的符合程 |
|
2 |
互操作性测试 |
基于某一协议检测不同协议实现间互操作互通信的能力 |
|
3 |
性能测试 |
检测协议实现的性能指标，比如数据传输速度，连接时间，执行速度，吞吐量，并发度， |
|
4 |
健壮性测试 |
检测协议是现在各种恶劣环境下运行的能力，比如注入干扰报文，通信故障，信道被切断 |
实践
1、测试流程
搭建什么样的测试环境？适配什么样的版本？
|
了解项目形态 |
如电子商务系统——web系统 |
|
（商业）模式 |
B2C/C2C |
|
WEB架构 |
B/S C/S |
对于B/S：
2、熟悉被测软件
3、测试计划
A、6要素:why、what、where、when、who、how
B、用例要素：
|
用例编号 |
测试标题 |
用例优先级 |
操作步骤 |
预期结果 |
测试结果 |
C、缺陷要素：
|
缺陷状态 |
缺陷类型 |
优先级 |
严重程度 |
4、测试（用例）设计思路
|
点 |
独立的功能点 |
|
线 |
业务场景/流程，如:购物车>>核对订单>>结算订单 |
|
面 |
非功能性、兼容性…… |
|
体 |
|
1）点
测试用例元素：
|
ID |
模块 |
优先级 |
前置条件 |
测试标题 |
步骤描述 |
测试数据 |
预期结果 |
实际结果 |
是否bug |
2）其它
HTTP状态码：
|
100 |
Server对client的请求 |
|
200 |
请求成功 |
|
300 |
重定向 |
|
400 |
客户端异常 |
|
500 |
服务端异常 |
TCP/UDP区别：