For investors
股价:
5.36 美元 %For investors
股价:
5.36 美元 %认真做教育 专心促就业
测试用例通常可以分为两大类,即验收测试用例和探索测试用例。验收测试用例的核心就是验收条件,对于明确清晰并且细化到足够程度的验收条件,可以直接转换为或者作为测试用例来使用。但是往往很多情况下测试用例没有细化,甚至不够明确和清晰,存在歧义,从而导致很难设计出足够的用例来映射到所有验收条件,称之为 AC Mapping。其次对于整个软件系统来讲,由于很多验收条件都是一些分散的点,而如何通过分析业务需求和验收条件等来设计测试用例,保证测试用例对于系统功能或者端对端场景的全覆盖,即 Function/E2E Coverage,这个是第二个难点。最后一个难点是功能和系统限制,即 Function/System Limitation。它的核心是如何通过分析验收条件,业务流程,技术架构等信息,发现某个功能或者系统级别的限制,只要突破这个它们即开始在做探索性测试,它们也可以叫探索性测试用例。无论验收测试用例还是探索性测试用例,都可以使用各种基础的测试用例方法来分析和设计测试用例,比如等价类,因果图,错误推测法或者场景法等等。
对于测试用例本身,需要使用代码化的思维来进行编写,维护和管理,其目标就是易读,易维护,易执行和易管理。为了达到这个目标,还需要克服以下测试用例的难点:自然语言的多样性,数量大,且自动和手动难统一。大部分情况下的测试用例都会使用自然语言进行描述。而自然语言的多样性和歧义,可能会让用例设计和编写者以外的手动测试执行人员或者自动化测试开发人员产生误解,从而理解错测试用例,并得到错误的测试过程和结果。其次当测试用例的数量增大以后,比如几千上万的时候,维护和管理的问题也随之困难起来,其中还包括如何统一管理自动化测试和手动测试用例,从而减少对于重叠测试用例的维护和管理。为了解决这些问题,需要用多一些方法,其中包括使用代码式思维来编写测试用例,比如用 DSL 语言,测试步骤和测试数据分离等,其次还需要强大的测试用例管理系统等等。
【免责声明】本文系本网编辑部分转载,转载目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题,请在30日内与管理员联系,我们会予以更改或删除相关文章,以保证您的权益!更多内容请添加danei0707学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。