测试总结三

用例篇

1、测试用例的基本要素

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

好的测试用例是一个不熟悉业务的人也能依据用例来很快的进行测试。

评价测试用例的标准：对比好坏用例的标准
1.用例表达清楚，无二义性
2.用例可操作性强
3.用例的输入与输出明确，一条用例只有一个预期结果。
4.用例的可维护性好。
5.用例对需求的覆盖率高

2、测试用例的给我们带来的好处（为什么在测试前要写测试用例？）

①测试用例是测试执行的依据
②可以复用（回归测试的时候）
③自动化测试的基础/依据
④衡量需求覆盖率
⑤积累测试的方法思路以供后续借鉴

*使用中带来困扰：
测试用例的设计是费时费力的工作，往往设计测试用例所花费的时间比执行所花费的时间还多
*解决如下问题：
不知道是否较全面的测试了所有功能 测试的覆盖率无法衡量 对新版本的重复测试很难实施 存在大量冗余测试影响测试效率

3、测试用例的设计方法

基于需求进行测试用例的设计
基于需求设计测试用例是测试设计和开发测试用例的基础，第一步就要分析测试需求，验证需求是否正确、完整、无二义性，并且逻辑自洽。在需求正确的基础上细化测试需求，从测试需求提炼出一个个测试点或者测试项，然后根据每一个测试点进行测试用例的设计。
在分析测试需求时，一般分为功能测试需求和非功能测试需求

3.1 功能测试需求

对于功能测试中，可以借助功能框图来帮助我们进行测试的需求分析。概括起来，功能测试需求通常包括以下几个方面。
（1）系统各个功能界面的验证
（2）借助业务把功能串起来进行测试
（3）功能的一致性，交互性（多功能互操作）的测试
（4）系统的不同输入，结果输出的业务数据测试。
（5）功能的错误操作，异常操作的测试（属于负面测试）
（6）功能实现用到的算法验证，有时需要用运代码评审
（7）用户操作的易用性，用户体验，往往结合功能测试同时验证。
针对具体的需求，可以根据业务分类，用户角色或者用户操作区域等将系统的功能分解成若干个功能模块，然后按照功能模块分别进行测试需求分析。按照功能模块划分，业务模块划分是最常见的做法。
下面对一个简单的日历系统的需求进行分析：

对日历根据web界面的功能布局分析出的功能框图如下：