发布网友 发布时间:2022-04-25 22:23
共3个回答
热心网友 时间:2023-10-16 01:27
字面上的意思就是“使用的例子”,这也还算贴切,说的更通俗点,就是在讲什么人要做什么事,这就是用例。这里的“人”就是本篇要讲的“参与者”,需要说明的是,参与者并不一定是人,也可能是另外的一个系统等。Rup中的需求分析就是描述什么人做什么事,你描述清楚了一个人所要做的事情,那么你就完成了一个用例,你描述清楚了所有的人要做的事,你就完成了需求;这在实际获取需求的过程中当然是一个与客户方代表反复沟通、修正的过程,直至双方对需求的理解趋于准确、无误,然后让客户签上大名,我们就可以后续的设计开发了。
谁是参与者?在一个涉众甚多的庞杂业务中,有时候这个基本问题也的确会让人犯糊涂;比如在做一个银行记帐系统的需求分析中,把银行中的保安也当作参与者就是犯糊涂的一个例子;银行涉众甚多,但不是每一个人都能被称作参与者,只有那些操作计算机的、与将要开发的系统进行交互的人或系统才是参与者;保安在记帐业务中也要操作计算机吗?不需要,那么他就不是参与者。又比如在医院挂号系统中,要挂号的病人和为病人挂号的医生谁是参与者?衡量标准仍然是:谁操作计算机谁就是参与者;如果病人告诉医生自己的信息,然后医生把这些信息录入计算机,那么参与者是医生;如果病人自己通过触摸屏等外设录入或查找自己的信息,那么病人就是参与者。前面的保安不是参与者,所以要开发的系统不需要为保安的安保工作提供什么功能支持,这很自然的就确定了该系统的服务对象、确定了系统的边界。确定了边界就知道了系统要做什么、能做什么、不做什么、不能做什么。系统不需要为不操作计算机的人(不与计算机交互的人或系统)设计任何功能。
以上确定系统的参与者与厘清系统边界的过程有什么困难吗?一切顺理成章啊。无非就是看谁操作计算机(与系统交互)。
在极端认真可爱的需求人员进行需求的用例描述时,生怕客户方不清楚,把跟系统不搭界的活动步骤也写进用例中,以表明写的详细,比如一个银行系统
1, 用户进营业大厅;
2, 用户询问保安如何取排队号;
3, 用户按取号机,取出一个排队号;
4, 用户排队
实际上,用户进大厅、问保安、取排队号都不属于银行的存款系统的职责,这些东西要统统略去,它们跟系统边界不搭边,它们都不是有效的用例。
热心网友 时间:2023-10-16 01:27
功能测试,是测试软件的功能是否正确。
界面测试,是测试界面中是否有不合理的设计,比如是否有文字覆盖现象……
热心网友 时间:2023-10-16 01:28
功能测试。即测试软件系统的功能是否正确
而你说的图形用户界面测试应该属于功能测试追问要测试的是以个网页。分了这两项,我不知道该这么写。
追答那分开的话就图形界面测试 应该是指网页上的‘颜色’,‘字体’,‘控件位置’,‘弹出项’这些与你需求说明文档里面的规格是否一致