51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 4441|回复: 5
打印 上一主题 下一主题

[讨论] 怎样编写一份高质量的测试用例?

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2010-11-23 22:08:56 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
简单介绍一下我的情况:做了三年财务后经朋友推荐来到ERP公司做财务软件测试,至今干了一年多。其间主要是黑盒测试,在既定的需求设计文档指导下测试产品功能。也编写过简单的测试用例、测试要点分析和数据推演等。下个月有一个比较重要的答辩,希望能编写出一份含金量高的测试用例(或完整的数据推演),结合用例进行半小时左右的答辩。初步拟题是应付模块的付款业务。希望能得到大家的建议,或者有合适的模板发给我也行。
PS:由于我的专业是财务,没有经过系统的计算机学习,太专业的术语就不用赘言了。且我们单位也比较偏重于结合用户实际应用场景,所以还是希望大家从这方面考虑,谢谢大家!!
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
发表于 2010-11-24 13:41:36 | 只看该作者
首先,ERP系统测试我不熟悉,所以,我只从用例设计思想来简单说说自己的看法。

1.其实,完整的高质量用例本身并不适合用于答辩或交流,一大堆用例和步骤,我不认为评委会有兴趣看到这个。
建议使用树型或框架型结构的用例检查点做为答辩的主体,附加1~2个完整的用例。
——用例检查点结构图是为了让评委了解你设计用例的思维逻辑;
——完整用例是为了让评委了解你对编写实际用例的能力

这是基本考察点,也是最重要的,完成这一点,应该能达到公司对你的基本要求。
——————————————————————————————————
2.明确用例的适用范围。
任何用例组都有局限性的。针对某一测试目标,完整测试的用例组设计不可能在短时间内完成。
比如,完全根据需求文档设计出的黑盒用例,大多都是基本功能用例,对性能测试和兼容测试不具备较好的指导性。

所以,建议你在明确设计用例的适用范围,比如,该用例仅针对于xxx系统在xxx环境中基本的功能测试,适用于版本验收测试和回归测试。
————————————————————————————————————————————
3.通过用例设计,尽可能多的表现出你对测试的理解。

测试用例做为执行测试的主体,通过分析它,其实就能得到整个测试大部分的相关信息,也就是说,从分析用例,就能得到测试计划的基本信息。
比如,
用例的多寡,表示即将投入测试活动资源的多寡;
用例优先级的高低,则表示在测试不同阶段,测试资源的不同分配;
用例分类的不同,则表示在整个测试活动中,测试方法的选取;
……
建议从最简单的入手 ,结合第2点,只做用例分类部分。
比如,你的重点设计的是基本功能用例,而性能用例/兼容用例则作为附加分类,少量写一些检查点,仅表示自己了解这部分的测试是必须要做的。

——————————————————————————————————

最后,不明白所谓的“数据推演”为何物?数据驱动的测试?还是测试数据分析?
回复 支持 反对

使用道具 举报

该用户从未签到

3#
发表于 2010-11-24 15:40:04 | 只看该作者
回复 1# gogo004

首先, 不是很明确,LZ出这份用例到底是为了给客户解说,还是其他用意.
但无论如何, 要面向客户答疑, 个人认为 是要把你们系统的核心 转达给客户.
通过用例方式转达, 最直观的方法是通过 业务流程与特点来描述. 首先 你要自己心里有个 系统流程,每个环节/节点 这个系统有什么特色, 你用例会从哪些方面去考虑. 此时, 正面的用例,是告诉用户 系统有什么功能. 而 扩展的用例 能告诉客户有什么特色. 比如负荷量强, 识别度高, 保密性好等等.
所以,个人觉得, 这个时候,文字描述,思路清晰是关键, 数据强化是辅助,是为了进一步让数据来告诉客户你们系统的特点.
在演示时,可以根据用例及演说流程,准备简单的数据,得出实际的演示结果, 不需要说要非常的全面.
演示解说,只要把精华提到了表达了就好, 过分冗余, 只会画蛇添足...
回复 支持 反对

使用道具 举报

该用户从未签到

4#
 楼主| 发表于 2010-11-24 21:12:29 | 只看该作者
回复 2# Jackc


  很感谢您的详细解答,决定采纳您的意见,缩小一下范围,做一个“短小精悍”型的用例。这次答辩的评委是各位测试经理和领域经理。主要目的还是体现明确的测试思路和技巧,也是一个能力的展示。所以流程图的形式还是很可取的,而且我也把基本的流程图已经做出来的,主要是结合业务实现的各种单据的流转和数据传递。请问其他方面可以拓展测试思路的还有哪些呢?
另外,数据推演是我们现在常用的一种数据分析形式,主要是按照具体的应用场景,结合实际数据的传递,达到预期输出的一个过程。
回复 支持 反对

使用道具 举报

该用户从未签到

5#
 楼主| 发表于 2010-11-24 21:14:39 | 只看该作者
回复  gogo004

首先, 不是很明确,LZ出这份用例到底是为了给客户解说,还是其他用意.
但无论如何, 要面 ...
joycena 发表于 2010-11-24 15:40



    不好意思 是我没表达清楚 答辩的对象是测试经理 不是客户
回复 支持 反对

使用道具 举报

该用户从未签到

6#
发表于 2010-11-24 23:48:53 | 只看该作者
对于测试经理的考核,无非是考察你对业务和测试方法的理解,我想对于付款单来说,2个用例应该能显示你的水平
1、付款单相关的所有接口,以客户应用场景+产品处理方式描述
2、用分类的方法,描述你如何测试应付单如:
功能测试
    参数测试
    数据测试
        计算方法
        币种
           。。。。
        小数位数
        。。。
    UI测试
    。。。
效率测试
并发测试
。。。
描述到很容易测试的简单单元
回复 支持 反对

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-11-7 17:57 , Processed in 0.073800 second(s), 27 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表