嵌入式的测试 case该如何来写?
本人现在从软件测试转向嵌入式测试发觉有很多地方是完全不同的,项目不去说光是testcase就有很大的不同,以前发现bug可以用图片记录,但现在是作机顶盒的测试根本不可能抓图!一个case还可能和很多东西发生关联使得原来的一个case无法独立,真不知道咱们写了。有经验的人可以分享一下吗?:s 个人认为黑盒测试的解决不了嵌入式测试中找出的bug,虽然可以找出很多的bug. 但是bug定位非常困难!难道这里没有有经验的高手来指导一下吗? 是不是现在作嵌入式测试的都很水啊!每个小模块的单元测试更重要,还有模块的整合测试. 这里所谓的黑盒测试只是像用户一样的操作,时间长了谁都可以作的,那我们的实力在哪里呢? 只是一个挑剔的用户,这样做事情是没有效率的!
没有实力就没有地位! 1、嵌入式的系统,需要有很好的错误日志记录,日志可以作为bug报告的重要依据。
2、case如果无法独立运行,需要添加测试代码,包括桩代码和驱动代码。 日志就只是windows自带的日志吗? windows是嵌入式系统吗?:p类似于windows的日志,不过是由开发人员设计的产品运行日志/操作维护日志等。 不太明白啊!嵌入式的测试好难啊!和一般的软件测试完全不同,好要命啊!对嵌入式没一个了解怎么测啊,现在只能象用户那样,好原始一点都不专业啊,怎么样才能改变现状啊!想知道嵌入式开发的过程,但无从下手!好痛苦!!!!! 你们只作系统测试吗? 就功能测试,完成一般功能就可以,实在没前提! 你只要从用户的角度出发,从功能性,性能性的角度思考即可!嵌入式的测试和其他测试,我想框架都是一样的。呵呵,然后多考虑一些异常的情况,边缘情况,多进行一些反常规思维的操作。我想,bug会滚滚而来的。 楼上那位说得不错,我也是做嵌入式软件测试的,没有工具,全是凭手动的,写testcase首先你要了解整个流程,你这个产品做出来要达到什么样的结果,你输进去什么要输出来什么,把预期希望的结果先写下来,然后先用一般的思维思考这个流程的正确走法,再从一些异常操作来考虑,包括输入的异常,操作顺序的异常等,这就和你的思维、想法有关了,看你能不能想得到,观察得到了,呵呵,白盒测试是要把所有的路径都走过,我们黑盒测试也需要把所有能走的路径都走一篇,同一条路径正常的数据要走,不正常的数据也要走 了解产品是最重要的。故你你还需要时间。 由于应用层界面和功能难于统一,因此没有通用的测试平台。也正是因为这样,黑盒测试是各个嵌入式软件开发的主要测试手段。但也有有实力的企业也开发了自动化测试工具。期待有过这方面开发经验的高手多加指点我们 可是嵌入式的驱动程序该如何写test case 那要根据需求来写的,不同的产品不同的需求test case当然也不一样了,不过写这个我觉得应该跟别的软件测试写这个注意的应该差不多的吧,你如果图片不能截下来那就画出来,把预期的结果界面画出来,是比那个麻烦了一点,或者描述出来 谢谢版主 呵呵,个人理解 楼主搞个模板就行