嵌入式产品黑盒测试的方法、技巧

cm

我一直从事嵌入式产品的黑盒测试，但是最近感觉关于测试方法和用例编写的思维已经陷入僵局，尤其是我们公司的产品，每款产品的整个开发阶段要历时1~3年，面对同一款产品的不停修改和测试，我想不陷入僵局也难。
还是说说目前我面临的情况吧，由于是嵌入式产品的黑盒测试，大家都知道，绝大部分功能只能靠手工完成，虽然我们编写了部分小工具来完成个别重复性的工作。因此，当产品修改完bug或者添加新需求后，我们通常是先针对修改部分进行测试，然后再对整个用例进行测试。
由于产品功能繁多，因此设计的用例也较多。我们设计用例的方法都是从产品功能进行分析，基本是按照每项功能进行分类编号，再对每项功能进行正常操作和异常操作的划分，涉及到的数据通常分为正常、边界和非法值。但是并没有写下具体的操作步骤，也就是说，这个用例只能针对部分熟悉产品的人来使用。

问题1：是否有必要每次都对修改后的产品按照所有用例进行完全测试？由于之前出现过仅对修改部分进行测试，后来却发现据说没有修改的部分也出现了问题，因此每次我们都是基本对所有用例进行测试的。但是这样很费时间。

问题2：测试用例的编写，是否有必要写下每步具体的操作步骤？还是只写下每个测试要点就可以了？而且，当每个操作关联性很强的时候，就会有很多重复性的工作。比如说，在测试这个功能的时候，已经作了操作1~n；但是在测试下一个功能的时候，还得把操作1~n再作一次。怎么样才可以避免这些重复性的工作？

问题3：如何才能使测试用例具备更好的延续性和可复用性？

不知道各位在黑盒测试中是怎么做的？先谢谢各位sdlkfj3

cm

怎么没有人回复呢

amama123

sdlkfj1 建议楼主覆盖 所有功能的细节的简单描述用例
不然你会发现维护的痛苦

soteric

一般来说，修改后不会把以前的都再重复测一次，而只是把修改的区域或者说是修
改后的相关所能影响到的区域，对这些区域设计一些用例。一般公司会在这些方面
有一个具体准则。
关于用例的操作步骤，可以把一些步骤基本相同的整理在一起，那样只要把重点描
述出来就可以了，操作步骤只要能让其他执行人员清晰地看懂就可以。

cm

请问，你们是怎么判断修改后影响到的区域呢？是靠测试人员进行新旧程序比较？还是依赖于开发人员的说法？

原帖由 soteric 于 2007-2-28 10:56 发表
一般来说，修改后不会把以前的都再重复测一次，而只是把修改的区域或者说是修
改后的相关所能影响到的区域，对这些区域设计一些用例。一般公司会在这些方面
有一个具体准则。
关于用例的操作步骤，可以把一些 ...

yongjun4

刚转入嵌入式软件测试，有和LZ同样的问题，希望有经验的人能够指点一二，先谢谢了

alice1002376

LZ的困惑我同样存在，这也让我很郁闷，更郁闷的是，对开发声称的同一版本、同一主板，而只有显示屏不一样的东西，认为不需要重复测试的东西，也会出现令人咋舌的不同，真是晕啊～～～

su_suny

看公司的版本控制做的好不好，如果经常出现反复的问题，则只要经过编译的软件都全面测试一遍。黑盒测试分覆盖测试很重要，不能想当然，上次没有问题，这次就无需测试了。这种想法往往会造成返工或投诉。

millerjordan

楼主请加我交流
msn :xordan_gjx@hotmail.com

HappyGirl

估计楼主的问题在所有搞嵌入式软件测试中大家都面临的问题。
用例个人认为应该写的详细一些，把输入点和预期结果都应该描述清楚，这样对于功能不熟悉的人员也能按照你写的用例来执行。
至于重复性的测试，目前我也是感到非常的不爽，有时觉得是在浪费时间和精力，对于开发人员部分修改的程序，我也是先着重测试修改部分的功能，最后再进行总体的测试。如果我们嫌麻烦，不进行综合测试的话，开发人员修改完程序后很可能引发其它功能出现问题，到时问题被客户检测出来，后果是不堪设想的。

关注各位有什么好的方法可以来提高测试效率！

winpower

你所提出的问题在目前的嵌入式软件测试中是存在的

成因有：

1.R&D没有做集成测试或者没有认真做。这里指的集成是指每出一个版本就需要R&D人员自行集成测试.在技术力量不够强的情况下，出一个版本肯定会出现这样或那样的问题
2.在不可避免出现新bug情况下，应该要R&D出风险控制文档（面要稍微宽一点，特别是模块与模块交叉部分），测试人员结合风险控制文档编写更加完善的Test Case
3.Testing 部门本身的Case不够全面

解决办法：
1.在完善Test Case的情况下引进自动化
2.根据公司产品的实际情况跟R&D人员一起制定Base Line（功能，性能等）控制，当版本改动不大时，手动做一些根据风险控制文档编写的Case,其余全部使用自动化工具完成
3.跟你老板沟通，要求R&D在更改bug时尽量考虑周全并测试

Case的一致性跟R&D做产品时的一致性关系非常大，如果公司有一个完整的研发流程控制，每一步都能严格控制，问题就会有很好的改善


不知我所说对你是否有帮助，欢迎交流！！！谢谢

spring279

建议把用例写得清楚一点...因为用例是写给测试人员看的,当然希望一看就懂得如何操作...
至于修改后的软件,我们的做法是重点测试修改过的部分,对没修改的部分简要地过一遍...这样应该可以节省很多时间...

chenhuayang

看老楼上大虾们的心得，收获多多～～～～sdlkfj3

guai00

转入嵌入式行业快3个月了，发现它的功能性测试真的是很烦啊！虽然没有项目进度时间的关卡与复杂的数据处理逻辑等，只是简单的功能测试，可是为什么会那么枯燥！应该怎么样培养兴趣？恢复自信？

anqiers

是啊,觉得真是很烦很枯燥,怎么样才能提高兴趣,有兴趣研究的朋友请加我QQ:38132657

yuq2002

我也刚转入做嵌入软件测试 ,现在我为公司写Test Case.

ok-ok

问题1：没时间或时间紧的就检测改过的部分,但还是建议全做,毕竟有时候一个BUG改好但可能由此引起另一个BUG

问题2：我们是测试方法,测试步骤,预想目标,测试结果这样写用例的,我觉得这样写比较规范,至于重复问题,我觉得测试10次没问题但不保证100次没问题,测试10次没问题但不保证1000次没问题,质量不是靠测试来保证的,真的要避免重复就使用自动化测试工具

问题3：建立测试用例平台,对已经通过的测试用例进行归档,方便测试人员对用例复用和延续

[ 本帖最后由 ok-ok 于 2007-8-8 23:41 编辑 ]

ziyouzizai

问题1：是否有必要每次都对修改后的产品按照所有用例进行完全测试？由于之前出现过仅对修改部分进行测试，后来却发现据说没有修改的部分也出现了问题，因此每次我们都是基本对所有用例进行测试的。但是这样很费时间。

修改之后，是否会影响其他的部分，这个问题可以去请教研发人员，他们熟悉系统的架构和关联，参考他们的意见后，重点测试有关联的部分。

harneyluo

刚进入嵌入式不久，学习了

woshiheng

回归测试非常重要，一定要做的。可以采用自动化的测试方法，节省人工。