软件测试学习之测试用例

测试用例

测试用例价值体系

测试用例概念

测试用例（Test Case）包含测试输入、执行条件和预期结果的文档6。

通过大量的测试用例来检验软件的运行效果。

是指导测试工作进行的依据。

把所有的情况都提到（穷举测试）无法实现。

测试用例价值

指导测试的实施

规划测试数据的准备

编写测试脚本的“设计规格说明书”

评估测试结果的度量基准

分析缺陷的标准

测试用例基础概念

测试用例示例

 

测试用例的组成

用例编号

模块

测试点（测试标题）

优先级

前提条件

测试步骤

期望结果（预期结果）

实际结果

测试用例的优先级

测试用例根据重要性分成一定等级

P0.最核心的测试用例（比如冒烟测试，如果不通过的话，其他的都不用测）

p1.高优先级的测试用例

p2.中优先级的测试用例（更全面，比如边线测试，网络测试）

p3低优先级的测试用例（不用常常被执行，比如性能，压力测试）

划分优先级是在有限的测试时间和条件下先执行最高优先级的测试用例

测试用例设计工具

思维导图(只用写测试用例的一部分，比如测试点，测试步骤)

Excel

测试用例设计

设计方法的选择

任何情况下，都需要采用等价类划分法，将无限测试变成有限测试

在规定了数据范围的情况下，必须采用边界值分析法

如果需要关注它的主要功能和业务流程、业务逻辑是否正确实现，考虑使用场景法

如果含有输入条件的组合情况，考虑选用因果图和判定表法

采用错误推断法再追加测试用例

测试用例编写步骤

1.划分功能模块

2.正向功能验证（冒烟测试）

3.单个功能项验证

4.功能之间交互验证

5.隐形需求

测试用例的粒度（遵守公司对测试粒度的要求）

测试用例可以写的简单，也可以写的很复杂

最简单的测试用例是测试的纲要，仅仅指出要测试的内容

测试用例写的过于简单，则可能失去了测试用例的意义

测试用例写得过于复杂或详细，会带来两个问题：

·维护成本问题

·效率问题

测试用例的评审

·测试用例本身的描述是否清晰，是否存在二义性

·测试用例内容是否正确，是否与需求目标相一致

·测试用例的期望结果是否确定、唯一

·测试用例是否覆盖了所有的需求

·测试用例是否具有可执行性

·是否从用户层面来设计用户使用场景和业务流程的测试用例

·场景测试用例是否覆盖最复杂的业务流程

·用例设计是否包含了正面、反面的用例

面试测试测试用例设计

面试形式

·自有产品功测试用例设计

·常用应用测试用例设计

思路

·需求分析（明确需求——和面试官交流需求细节）

·界面（页面布局设计和产品原型图一致——页面文案正确）

·功能（正向功能验证——冒烟测试、单个功能项验证、功能之间的交互验证——模块跳转、模块数据传递、接口验证——请求和响应是否正确）

·易用性（功能操作是否简便、页面布局是否美观合理、提示语相关信息是否易于理解）

·兼容性（app——平台、厂商、系统版本、屏幕大小与分辨率   web——浏览器、操作系统、分辨率）

·性能（服务器性能测试——访问时间、支持多少人响应   app客户端新能测试——耗电量、内存、cpu）

·安全性(注入攻击——注入js语句,注入java语句。加密——密文传输。权限)

App测试要点——网络（断网、弱网、wifi）。中断测试（打电话、切换等）。系统权限（相机、定位、相册）

Web测试要点——连接测试（直接访问链接是否能访问）。多个浏览器同时访问是否能访问成功。

常用测试策略和测试手段

测试策略概念

在特定环境约束之下，描述软件开发周期中关于测试原则、方法、方式的纲要，并阐述了他们之间如何配合，以高效地减少缺陷、提升质量。

测试策略的关注重点

测试的目标是什么？

测试可能存在的风险是什么？

测试的对象和范围是什么？

如何安排各种测试活动？

如何评价测试的效果？