[你问我来答第20期]：如何编写好的测试用例？(已结束)

femir

问题：
1、需求范围如何确定？
2、手机助手（91，豌豆荚）测试更注重哪些测试类型，或者说不重视那些测试类型？
3、自动化测试在小公司能不能生存？（QTP），我想往QTP方向走，但是现在公司没有涉及这块？
  请老师指点  谢谢

aspstar

请求专家，面对相对简单、不太规范的业务需求，而且没有详细的开发设计文档，测试人员应该如何做测试。业务需求提出人员在系统开发测试接近尾声后，频繁提出需求变更，测试人员应如何应对？

ranquan

我想问一下 性能测试怎样进进行呢，工具是不是比手工好呢

zbl0531

专家：黑盒测试的真正出路在哪？纠结中

aspstar

专家：黑盒测试的真正出路在哪？纠结中
zbl0531 发表于 2012-3-21 17:31

    专家们不是说了吗？黑盒功能测试的前途在于对业务的熟悉。

aspstar

我想问一下 性能测试怎样进进行呢，工具是不是比手工好呢
ranquan 发表于 2012-3-21 17:21

    性能测试需要综合能力比较强，尤其是系统、数据库，中间件比较了解。

aspstar

问题：
1、需求范围如何确定？
2、手机助手（91，豌豆荚）测试更注重哪些测试类型，或者说不重视那些测试 ...
femir 发表于 2012-3-20 22:59

    目前的测试环境来看，自动化没啥前途。

aspstar

回复  zbl0531


    系统除了增删查改还能有什么其他功能么，
hclovezz1314 发表于 2012-3-20 16:50

    熟悉业务逻辑才是测试中的难点。

sun_0910

怎样去组建和管理一个比较全的通用测试用例库？对于通用的测试用例，如何去进行编写？
http://bbs.51testing.com/thread-500041-1-5.html
帮忙回答一下，谢谢！！

Jane70301

庄姐，看到你，很高兴。我的问题不是关于技术，是职业发展方面。我也是做黑盒，所有黑盒经验愈多，就觉得不知以后怎么发展。就像某个行友说的一样，黑盒还是大部分是功能性，设计技术含量似乎不如白盒和性能之类，我也非常困惑。不知能否与你请教你是怎么规划的呢

ranquan

回复 147# aspstar 我想请问一个问题，帮助文档怎么写

薰衣草の香

新手，求指教，活了23年了第一次自己想学点东西，上大学是父母的要求，学编程技术纯粹是为了跟风，现在真心想学测试，求高手，求速成方法，23岁了，不小了，貌似真的等不起了，跪求

femir

测试用例的字段越多越好你怎么看？
随着测试的回归，bug数越来越少，怎样才能写出发现至今还没有发现的bug用例？

pmlpml6509

回复 9# yjdeihc
如果是代码覆盖测试，基于图覆盖设计测试用例的技术最牛！代码覆盖率可达到90％以上。
如果是验收测试，基于活动图和操作顺序图的操作组合设计测试用例的技术最牛！代码覆盖率基本都可以在70％以上。
哈哈，当然分析设计代价比monkey测试方法大许多许多，不一定适用。

pmlpml6509

回复 155# femir
了解测试用例的“杀虫剂”准则。努力不断设计新测试用例加入回归过程！

pmlpml6509

回复 151# Jane70301
努力学习，成为写自动测试脚本的大佬。分分钟有新岗位等你！

link0313

WEB页面测试有哪些方面？重点在哪里？需要注意的有哪些？测试用例的方向在哪边？请版主指导！

天使V3坠落

庄姐，对于pos机怎么设计测试用例，测试的重点在哪里；需要注意那些地方呢 ？

楠族开心果

你好，我是刚刚从事软件测试职位，对于很多的都不懂，测试用例该怎么样编写？还有如何能做到快速掌握呢？
后悔无救 发表于 2012-3-6 14:05

1、根据需求文档，完全按照需求文档框架/功能描述，根据自己的理解整理为用例。简单来说，就是将需求文档描述的内容，重新按照用例的格式编辑一次，把能想到的各种可能性添加进去

2.    搜索其他测试人员的编写的类型功能用例，先理解，再根据项目实际需求的较小差异，重新新增/删/改，组成满足需求的用例组。

快速掌握用例其实没有什么窍门，只有多看，多想，多写，多评审

楠族开心果

回复 57# pitiy

关于测试用例书写我有如下疑问
怎样的测试用例是好用例?每条用例覆盖一个功能点？
这种用例在实际操作中有很大的缺陷。
首先不能确保测试人员进行集成测试时对功能用例执行到位，可能会出现遗漏。
因此我们在测试用例输出过程中，建议测试人员就测试因子使用工程方法进行流程功能覆盖。
但是这样引入另外一个问题，客户的需求是不断变化的，需求在执行设计和测试用例输出时，很大几率产生变化，这种变化势必对原输出的测试用例照成冲击。调整的工作量有时会很大，有可能对整个功能会推倒重新输出用例。
不知道版主能不能就这个给出你的解决方案。

每个用例覆盖一个功能点，是最佳的理想状态。但条件覆盖有个缺点就是每次执行会存在一个较长的周期，如果部分不可套用自动化，会导致测试和开发并行产生无法按时验证完每个版本的分支。

有两种方式可供参考：

1．在原本的测试用例的上，再次放大用例描述的模糊度，以利于用例可用于相似但细节不同的功能。以登陆界面的字符长度为12双字节的用户名提示框为例：

原始用例步骤：在登陆界面用户名输入框输入11个中文字符

修改后的用例步骤：在登陆界面输入不超过字符长度限制的用户名

点评：原始用例步骤仅适合登陆界面用户名字符长度限制为11以上的编辑框。修改后的用例可用于任何字符长度的用户名编辑框。此方法还可用于对流程描述，如”进入编辑用户名界面”可替换为”编辑用户名”

2.建立较为完善的基础用例库，项目用例作为基础用例库的子集存在。这样的用例库在针对单个功能时，存在多种不同的描述和设计。如1点的模糊程度不同可作为相同用例的不同两只用例存在。而在以后的实际项目中，根据项目实际需求，从基础用例库筛选合适的用例组作为项目用例组。

另外，我们公司的黑盒测试用例会演进为自动化用例。如果单一覆盖点测试用例，会导致自动化脚本代码复用率不高。像这样的问题，应该怎么解决？

首先一般都是安装测试用例去做的，单一运行，假如希望脚本复用高，需要整理业务函数脚本，把常用的业务函数化调用。这个让你们负责设计框架的人去想的。如果觉得业务利用率不高，就写成公共方法调用