51Testing软件测试论坛

标题: 请教大家功能测试的优先是什么？ [打印本页]

作者: 1019 时间: 2009-5-5 15:36
标题: 请教大家功能测试的优先是什么？
从我负责测试部门以来，每次听到上司向我提出的一个问题就是我们的测试方法不对，他说：测试应该先测逻辑流程，整个流程走通了，再测第个功能点，叫我们不要拿到系统就开始测试字符类型、长度、页面显示等等之类的问题。但是我想了想，如果功能点都没有走通，测流程有什么用呢？还是说测功能点时，一些非法的操作先不测，等正常流程走通过，再做一些非正常的测试，请各位大虾给我点意见，也分享下你们的经验。

作者: fy_fuying 时间: 2009-5-5 16:25
优先测试正确的业务，然后再测试其他如边界值一类的。

作者: 51testing-wn 时间: 2009-5-6 22:57
他指的意思应该是先做冒烟测试。应用部署成功后，看看整个业务流程能不能走通。下面是我引用的话“冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。”http://baike.baidu.com/view/120001.htm

作者: test_yyp 时间: 2009-6-6 21:59
3楼说得很有逻辑

作者: lza945 时间: 2009-6-10 21:23
其实你上司意思就是先进行预测试了，在测试进行前，最好先进行预测试，这样是可以有效地保证你下面的工作是有效的

作者: 鹭岛 时间: 2009-6-11 10:27
1.需求评审过
2.提交测试申请（可以与计划和编写用例以及评审同步）
3.计划完整性
4.测试用例评审完成
5.一切OK，开发人员提交打包的程序
6.部署安装，没问题，OK，可以进行测试，按照测试用例执行功能测试
7.提交报告（碰到严重性错误导致系统无法继续执行测试等的也要提交报告说明问题中断测试）

作者: 1019 时间: 2009-6-13 12:19
下而是我看到的一则功能测试思路，我觉得得也比较符合我们公司的情况，贴出来与大家分享。

　　以客户需求（业务需求）为基础，数据为指导。

　　1.需求分析

　　拿到一个成品，首先熟悉需求，要想更细的了解最好参照开发需求（功能说明书）以及测试需求。如果这些文档并不齐全，只能靠自己的嘴巴和脑袋了。首先要用心分析需求文档，每个细节每个业务流程。对于不懂的或者与现有系统矛盾的地方，及时张开自己的金嘴去问熟悉这个系统的相关人员。

　　需求分析后，最好是能画出一个功能流程图。对于每个子功能，尽可能把各种可能的路径都显示在这张图上面。

　　对于如何画好这张图，这个时候最好的方式采用数据驱动的方式。每个模块之所以能关联在一起，追根揭底都是因为它们有数据传递。分析出数据流的流向，一般都能把握住功能与子功能的各个分支，尽量做到无遗漏。

　　2.测试执行

　　1）BVT测试，确保基本功能都跑通。

　　2）接口测试，将整个业务流程从创建数据，到处理数据，然后到处理结束，整个过程走一边，确保流程能走得通。

　　3）各个子功能深度测试。这个过程谁经验丰富谁占优势，但是也是有些技巧的。怎么确保此功能不会出现严重的问题了，首先研究数据。这个功能涉及到那些数据，然后从界面上提交关键数据，确保数据信息成功保存在数据库中。

　　4）关联测试。这个阶段，首先要搞清楚数据的关联。搞清楚这个关联可以采用两种方式结合：一个是从界面上了解数据之间的关联，另外一个更准确的方式是分析数据库。分析数据库中各个表中的数据，把每个外键找出来，然后找出外键相关的表。然后弄清楚这些表中的数据界面上哪里调用上。

作者: 1019 时间: 2009-6-13 12:21

原帖由鹭岛于 2009-6-11 10:27 发表
1.需求评审过
2.提交测试申请（可以与计划和编写用例以及评审同步）
3.计划完整性
4.测试用例评审完成
5.一切OK，开发人员提交打包的程序
6.部署安装，没问题，OK，可以进行测试，按照测试用例执行功能测试
7. ...

哎，你说的流程确实应该这样，但是我很久都没有经历过项目的需求评审，什么用例评审的，基本上需求都没有，拿到手上就在那里先摸一段时间才晓得是怎么个回事，累啊。

作者: ITF_126 时间: 2009-6-15 12:03
中新龙通（WWW.CN-CDI.COM WWW.CN-CDI.CN WWW.CHINADRAGONI.COM）
是中国本土领先的一家企业咨询服务提供商，专长于为初创型、成长型及多元化发展型企业提供政策法规、风险防范、行业指导、市场准入、业务申报、资格许可、财务管理、并购兼并及策略性之整体咨询服务。

● 网络文化经营许可证（含网络游戏）审批
● 全网SP证审批，各省地网SP证快速办理
● ICP证快速办理
● 四网合一号码（短消息接入号码）申请
● 各地分公司注册.全国备案,号码备案
● 呼叫中心（CALLCENTER）审批
● 公司注册，垫资，外资注册

TEL: 010-58677911 QQ: 1160877620 Contact Person: 任先生

作者: zhangxinnow 时间: 2009-6-16 14:18
这是一个可用和好用的问题，所有的正常业务流程都走通了，保证可用的基础上才谈好用（仔细的测试功能点）。如果不可用建议直接打回修改。

作者: name135791 时间: 2009-6-17 23:37
你们老大是对的，应该首先保证关键业务流程正常，不然测试就会有大把用例通不过，这样将会直接导致整个测试失败，浪费了时间。

建议做个冒烟测试套件，然后把它做为测试准入准则，只有冒烟测试用例全部通过才进入测试，否则版本打回。

字符长度之类的算界面测试，对于很多软件而言，它的风险是较低的，所以可以少测或者不测。测试优先级是跟软件风险相关的，对于高风险功能应该早测，

全面测，对于低风险功能可以后测试，甚至不测。

我属于测试风险控，呵呵

作者: 灰盒 时间: 2009-6-18 14:24

原帖由 name135791 于 2009-6-17 23:37 发表
你们老大是对的，应该首先保证关键业务流程正常，不然测试就会有大把用例通不过，这样将会直接导致整个测试失败，浪费了时间。

建议做个冒烟测试套件，然后把它做为测试准入准则，只有冒烟测试用例全部通过才进入 ...

不知道你们测试计划怎么排的,有没有分单元测试和集合测试.这位老大的意思呢,是要做数据的畅通,其实单元测试结束,进入集合测试的前提.

但是提前做这种测试,我不认同.

作者: hellinangel 时间: 2009-6-19 14:41
个人认为应该先进行基本业务流程测试，当基本业务流程测试通过后，进行性能测试（如果有需要），然后开始全面测试

作者: 蓝色水滴 时间: 2009-6-24 12:00
个人认为老板是正确的，基本功能如果都不能实现，测试各个输入框的长度之类的就没有多少意义了，只会增加自己重复测试的机会。

作者: 蓝色水滴 时间: 2009-6-24 12:07
可以将测试用例标上优先级，先来个预测试（当然是测试优先级高的，就是老板所说的基本流程了），不通过的直接打回开发部门，这样既提高了效率，也减少了自己重复测试的机会

作者: 1019 时间: 2009-6-26 12:00

原帖由灰盒于 2009-6-18 14:24 发表

不知道你们测试计划怎么排的,有没有分单元测试和集合测试.这位老大的意思呢,是要做数据的畅通,其实单元测试结束,进入集合测试的前提.

但是提前做这种测试,我不认同.

现在的小公司哪会做到什么单元或集合测试哦，目前的团队是以功能测试为主，我从经验中总结，首先保证每个功能的正常实现，然后再逻辑流程，最后在各个输入框字符的控制、界面显示，提示语言描述。其次，针对不同的项目的需求进行性能测试，或简单的安全测试。
但似乎我们公司的需求变动超级频繁，常常都是做的差不多了发现很多设计上的问题根本就行不通，再就是交互上的问题，老大们看到的是表面的东西，一看就提这个界面怎么不行，这话描述的不专业，太哆嗦等等，正是因为没有规范，所以开发都觉得自己是合理的，然后我们就把表面的一些东西整理出来开会讨论，一讨论就是一天两天，特浪费时间。

作者: 不再迷茫 时间: 2009-7-29 11:42
恩，你们确实有点问题。。。。如果业务功能不能实现其他都没有意义，测试字符长度这都是小问题，业务功能才是最需要处理的

作者: brucehuang 时间: 2009-8-31 11:10
测试字符长度这些都比较粗浅，还是先做做冒烟。测测流程比较好。不知道你对你们公司的产品的功能流程熟悉不。可以多了解下流程。流程真的很重要

作者: ff520mm1314 时间: 2012-2-16 15:23
路过，学习了~

作者: pilottest 时间: 2012-2-21 23:26
路过，也学习，楼主说的跟我们公司业务也有一些相关链呀，需求常常变更。

作者: yintianyouqin 时间: 2012-2-22 09:05
回复 16# 1019

你说的对，很多时候就是因为没有规范，所以测试起来极其费劲。所以在小公司测试的时候，测试人员应该靠自己的努力去赢得大家的信任。这样慢慢地就可以帮助公司制定一些符合公司实情的规范，从而走上一个良性的循环。

作者: yuanliming1982 时间: 2012-2-24 22:18
个人建议：
优先进行功能走读。

作者: xiaogx 时间: 2012-12-14 16:41
我觉得这个还是测试流程的问题（如果LZ公司有测试流程的话）。像LZ说的字符串、输入文本框这些测试点应该在单元测试或者说单个UC测试的时候完成的，接下来就是正确的业务逻辑和业务功能以及异常的流程的测试。功能测试应该还是以正常的业务功能为主，业务功能不能通过这个软件根本没意义。

作者: willyenillye 时间: 2012-12-27 11:24
从这个问题本身来看，很简单，就是个测试优先级和测试阶段的问题。一般来说，冒烟-》主要功能-》细节展开。

缺陷严重性分级后，各个测试阶段对应发现不同级别的问题。BLOCKER级的问题在冒烟时发现，CRITICAL级的在主功能发现，MAJOR级的在走辅助功能时陆续发现，到什么数据检查之类的时候，已经只能发现MINOR以下的问题了。

但是看了楼下的各种回答，我发现，对于测试人员如何进行需求分析这个问题，是可以开一个专题的。在我眼里，一个高级测试工程师应该同时是一个合格的需求分析师。

作者: Emocat 时间: 2013-1-16 20:54
結果很認真地讀了每一層，發現後面不知道誰是老大誰是lz了╮(╯▽╰)╭

作者: 骷髅行走lby 时间: 2013-2-17 20:24
先主流程，再细枝末节的功能
楼主可以先整理出一部分核心的功能、流程用例，给开发，开发内测通过这些用例了再提交给测试部门

作者: xjs19841125 时间: 2013-5-8 01:47
业务流程的BUG属于P1-P2级问题并且修复需要的时间相对多应当优先测试，再者才是P3-P4交互及显示上的问题，太纠结于细节会让测试过程变成钻牛角尖而浪费资源。在功能测试基本完成后可以进行安全及性能测试，通过阶段划分可以有效的降低产品质量风险并且进度可以得到控制。软件产品的质量并不是测试一个岗位能控制得了的，在有条件的情况下建议推广产品设计评审、视觉风格平生、技术方案评审、单元测试、接口测试等将产品质量保障向前推，让产品经理、开发人员共同加入到产品的质量保障上来。同时质量保障向后推建立好用户反馈机制、用户BUG复现机制，从这几个方面入手可以使产品质量得到很大提高。

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)