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

楠族开心果

如何提高测试用例的需求覆盖率，
xihong2004 发表于 2012-3-27 10:39

请参考http://www.51testing.com/html/14/n-219614.html

楠族开心果

测试用的评审，需要注意一些什么？主要是针对那些人群？
weeny 发表于 2012-3-29 16:54

在国内这个评审这个概念很淡薄，但是却是无处不在的。比如经常做的代码走查、立项会议、需求讨论等等其实都是一种简化的评审，有的公司把这叫做“头脑风暴”（往往是遇到难题的时候集中大家的智慧来冲关 ）

1、可以评审的东东很多，需求、策略、计划、用例、代码.....基本上项目中你能想到的东西，都可以拿出来评审。

2、组织评审需要有清晰的目的（这个是整个环节中重要的部分），很简单，你首先要知道，你需要从这个评审中得到什么？也许是希望被评审东东更加完善，也许是希望增加大家交流的机会，甚至可能是为了应付上面的检查等等。

3、不同目的评审，参与人员自然也随之变化：
比如，希望需求更加完善的评审，理论一切与产品有关的人员，大到项目经理，小到一线销售人员都需要来参加。但是，往往评审的人员越多，时间上就越难安排，所以需要结合实际情况来删减。

当然，也不是说必须要XX人参加的评审才叫评审，比如一个BA与一个客户或开发人员私下的一次交流，只要做了详细的记录，也可以算作是一个评审。

所以，有内容的评审其实是不拘形式的，假如非得搞个内审或外审来规范，我只能说那是走过场而已。

4、在组织评审的细节上，有一点很重要：不要在评审过程中“照本宣书”。
很多公司在评审前不做准备，评审时拉个主持人上去就对着文档、PPT一阵读，半天下来，问大家有没问题，结果只能是只言片语。

所以，在评审前最好先做预审，也就是在评审前，给予评审人员一定的时间，也许是三、两天，也许是一星期，让评审人员熟悉评审目标，并提出自己的意见，由一个统一的程序收集起来，在评审中逐一解决。这样的效果会好很多。

5、最后说说比较规范的评审流程
确定评审目标——确定参与人员（包括主持人、记录员、评审员等）——安排评审时间——预审——整理预审报告——评审——整理评审报告——作者修改评审目标——复审（复审可以走简单流程，由各个提建议的评审人员查看自己的建议是否得到合理的修改）——存档

yuyu2you

我做测试一年了，但是只会输入数据，看数据对不对。感觉没有前途，很迷茫。给些建议吧。

楠族开心果

我做测试一年了，但是只会输入数据，看数据对不对。感觉没有前途，很迷茫。给些建议吧。
yuyu2you 发表于 2012-3-31 13:23

多看些测试的资料；多看些有关的书籍；多练习

holly08

测试用例的粒度怎么个界定.? 碰到功能复杂的测试,书写用例就感觉无从下手

楠族开心果

测试用例的粒度怎么个界定.? 碰到功能复杂的测试,书写用例就感觉无从下手
holly08 发表于 2012-3-31 22:38

根据需求来定。较复杂的，可以先画出流程图，再进行编写测试用例

hw_lizh

呵呵，你好。

lsekfe

看下

下降的雨

回复 153# 薰衣草の香


    看到速成,姐一笑而过

夕阳西下°

初学者，希望能在这里得到帮助！

winsletjoe

顶

a544529651

怎样写好黑盒测试用例，覆盖面广，有不出现冗余；

a939916104

我悄悄地来，悄悄地走

sunmin415

谢谢楼主分享~