请教大家功能测试的优先是什么？
从我负责测试部门以来，每次听到上司向我提出的一个问题就是我们的测试方法不对，他说：测试应该先测逻辑流程，整个流程走通了，再测第个功能点，叫我们不要拿到系统就开始测试字符类型、长度、页面显示等等之类的问题。但是我想了想，如果功能点都没有走通，测流程有什么用呢？还是说测功能点时，一些非法的操作先不测，等正常流程走通过，再做一些非正常的测试，请各位大虾给我点意见，也分享下你们的经验。 优先测试正确的业务，然后再测试其他如边界值一类的。 他指的意思应该是先做冒烟测试。应用部署成功后，看看整个业务流程能不能走通。下面是我引用的话“冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。”http://baike.baidu.com/view/120001.htm 3楼说得很有逻辑 其实你上司意思就是先进行预测试了，在测试进行前，最好先进行预测试，这样是可以有效地保证你下面的工作是有效的:) 1.需求评审过2.提交测试申请（可以与计划和编写用例以及评审同步）
3.计划完整性
4.测试用例评审完成
5.一切OK，开发人员提交打包的程序
6.部署安装，没问题，OK，可以进行测试，按照测试用例执行功能测试
7.提交报告（碰到严重性错误导致系统无法继续执行测试等的也要提交报告说明问题中断测试） 下而是我看到的一则功能测试思路，我觉得得也比较符合我们公司的情况 ，贴出来与大家分享。
以客户需求（业务需求）为基础，数据为指导。
1.需求分析
拿到一个成品，首先熟悉需求，要想更细的了解最好参照开发需求（功能说明书）以及测试需求。如果这些文档并不齐全，只能靠自己的嘴巴和脑袋了。首先要用心分析需求文档，每个细节每个业务流程。对于不懂的或者与现有系统矛盾的地方，及时张开自己的金嘴去问熟悉这个系统的相关人员。
需求分析后，最好是能画出一个功能流程图。对于每个子功能，尽可能把各种可能的路径都显示在这张图上面。
对于如何画好这张图，这个时候最好的方式采用数据驱动的方式。每个模块之所以能关联在一起，追根揭底都是因为它们有数据传递。分析出数据流的流向，一般都能把握住功能与子功能的各个分支，尽量做到无遗漏。
2.测试执行
1）BVT测试，确保基本功能都跑通。
2）接口测试，将整个业务流程从创建数据，到处理数据，然后到处理结束，整个过程走一边，确保流程能走得通。
3）各个子功能深度测试。这个过程谁经验丰富谁占优势，但是也是有些技巧的。怎么确保此功能不会出现严重的问题了，首先研究数据。这个功能涉及到那些数据，然后从界面上提交关键数据，确保数据信息成功保存在数据库中。
4）关联测试。这个阶段，首先要搞清楚数据的关联。搞清楚这个关联可以采用两种方式结合：一个是从界面上了解数据之间的关联，另外一个更准确的方式是分析数据库。分析数据库中各个表中的数据，把每个外键找出来，然后找出外键相关的表。然后弄清楚这些表中的数据界面上哪里调用上。 原帖由 鹭岛 于 2009-6-11 10:27 发表 http://bbs.51testing.com/images/common/back.gif
1.需求评审过
2.提交测试申请（可以与计划和编写用例以及评审同步）
3.计划完整性
4.测试用例评审完成
5.一切OK，开发人员提交打包的程序
6.部署安装，没问题，OK，可以进行测试，按照测试用例执行功能测试
7. ...
哎，你说的流程确实应该这样，但是我很久都没有经历过项目的需求评审，什么用例评审的，基本上需求都没有，拿到手上就在那里先摸一段时间才晓得是怎么个回事，累啊。 中新龙通（WWW.CN-CDI.COM WWW.CN-CDI.CNWWW.CHINADRAGONI.COM）
是中国本土领先的一家企业咨询服务提供商，专长于为初创型、成长型及多元化发展型企业提供政策法规、风险防范、行业指导、市场准入、业务申报、资格许可、财务管理、并购兼并及策略性之整体咨询服务。
● 网络文化经营许可证（含网络游戏）审批
● 全网SP证审批，各省地网SP证快速办理
● ICP证快速办理
● 四网合一号码（短消息接入号码）申请
● 各地分公司注册.全国备案,号码备案
● 呼叫中心（CALLCENTER）审批
● 公司注册，垫资，外资注册
TEL: 010-58677911QQ: 1160877620Contact Person: 任先生 这是一个可用和好用的问题，所有的正常业务流程都走通了，保证可用的基础上才谈好用（仔细的测试功能点）。如果不可用建议直接打回修改。 你们老大是对的，应该首先保证关键业务流程正常，不然测试就会有大把用例通不过，这样将会直接导致整个测试失败，浪费了时间。
建议做个冒烟测试套件，然后把它做为测试准入准则，只有冒烟测试用例全部通过才进入测试，否则版本打回。
字符长度之类的算界面测试，对于很多软件而言，它的风险是较低的，所以可以少测或者不测。测试优先级是跟软件风险相关的，对于高风险功能应该早测，
全面测，对于低风险功能可以后测试，甚至不测。
我属于测试风险控，呵呵 原帖由 name135791 于 2009-6-17 23:37 发表 http://bbs.51testing.com/images/common/back.gif
你们老大是对的，应该首先保证关键业务流程正常，不然测试就会有大把用例通不过，这样将会直接导致整个测试失败，浪费了时间。
建议做个冒烟测试套件，然后把它做为测试准入准则，只有冒烟测试用例全部通过才进入 ...
不知道你们测试计划怎么排的,有没有分单元测试和集合测试.这位老大的意思呢,是要做数据的畅通,其实单元测试结束,进入集合测试的前提.
但是提前做这种测试,我不认同. 个人认为应该先进行基本业务流程测试，当基本业务流程测试通过后，进行性能测试（如果有需要），然后开始全面测试 个人认为老板是正确的，基本功能如果都不能实现，测试各个输入框的长度之类的就没有多少意义了，只会增加自己重复测试的机会。 可以将测试用例标上优先级，先来个预测试（当然是测试优先级高的，就是老板所说的基本流程了），不通过的直接打回开发部门，这样既提高了效率，也减少了自己重复测试的机会 原帖由 灰盒 于 2009-6-18 14:24 发表 http://bbs.51testing.com/images/common/back.gif
不知道你们测试计划怎么排的,有没有分单元测试和集合测试.这位老大的意思呢,是要做数据的畅通,其实单元测试结束,进入集合测试的前提.
但是提前做这种测试,我不认同.
现在的小公司哪会做到什么单元或集合测试哦，目前的团队是以功能测试为主，我从经验中总结，首先保证每个功能的正常实现，然后再逻辑流程，最后在各个输入框字符的控制、界面显示，提示语言描述。其次，针对不同的项目的需求进行性能测试，或简单的安全测试。
但似乎我们公司的需求变动超级频繁，常常都是做的差不多了发现很多设计上的问题根本就行不通，再就是交互上的问题，老大们看到的是表面的东西，一看就提这个界面怎么不行，这话描述的不专业，太哆嗦等等，正是因为没有规范，所以开发都觉得自己是合理的，然后我们就把表面的一些东西整理出来开会讨论，一讨论就是一天两天，特浪费时间。 恩，你们确实有点问题。。。。如果业务功能不能实现其他都没有意义，测试字符长度这都是小问题，业务功能才是最需要处理的 测试字符长度这些都比较粗浅，还是先做做冒烟。测测流程比较好。不知道你对你们公司的产品的功能流程熟悉不。可以多了解下流程。流程真的很重要 路过，学习了~:lol 路过，也学习，楼主说的跟我们公司业务也有一些相关链呀，需求常常变更。
页:
[1]
2
