软件质量管理不经理,要达到怎样的能力呢
学10:19:23
我个人认为，要掌握一定的开发知识，然后掌握丰富的软件测试知识，然后对软件工程有一定的了解，当然组织和协调能力那是抽象的不好说
缤雪  10:19:24
我只知道写好的用例是质量经理必须要做的事情.
学习10:19:39
写好的用例是测试工程师必须做到的事情
缤雪  10:20:32
质量经理应该是更要吧!要不怎么控制质量啊?
学习10:20:48
这还用说吗
缤雪 10:26:23
学习者,能指导下吗,我现在的测试工作一直是一个人在摸索中,我正在为怎样在测试前写好测试用例考虑着,也没见过比较规范的好的测试用例,能对一个最简单的主要是对数据库增删改查的管理的系统怎么规划怎么设计TEST CASE给个建议吗?写用例有没有度的问题啊?
学习10:28:31
首先如果你想把增删改这样的测试做好，你必须有去后台数据库中查询数据的能力。增删改的用例很好写的，一些涉及到因增删改之后有异动的业务逻辑流可能将是你必须关注的地方，这就要看需求分析或详细设计中的具体内容了。
学习 10:30:45
一个很简单的例子，比如删除一个部门，用例很简单，就是核对此部门是否删除掉，在前后台都可验证，保险的方式是去后台验证，因为有的JS缓存会有假像，如果JS没处理好或刷新不及时，但部门被删除后涉及主外键关系的部门底下的员工怎么办，前提是此部门底下没有员工了，那这个判断将是你用例中的重点，
 
缤雪 10:32:43
需求提到某角色对某些数据进行修改或者删除或者只可以查看的.
那么就是说删除部门就一个TEST CASE 就可以了
学习10:34:08
这个具体情况具体分析，建用例的划分要合理，一个是好让开发人员看到这条BUG后容易地通过追踪用例过程就可以发现是哪出的问题，太复杂的用例会把开发人员搞晕，另一个是过份简单的用例将导致你的用例条数很多，会把自己搞得很累
缤雪 10:35:31
我感觉不够,似乎要好多个用例
能请问下 ,比如你们对删除部门这样一个操作动作,而部门设计到的主要是用户,用户关系到角色,角色关系到对系统的操作权限,这样大概要设计几个用例.
学习10:37:30
你可以一个CASE 然后底下有多个步聚
学习 10:37:48
还比如，增和改其大部份是相同的，那你可以用例共享
缤雪  10:38:05
这个具体情况具体分析，建用例的划分要合理，一个是好让开发人员看到这条BUG后容易地通过追踪用例过程就可以发现是哪出的问题，太复杂的用例会把开发人员搞晕，另一个是过份简单的用例将导致你的用例条数很多，会把自己搞得很累
我想这就是度的问题,也就是这个度让我迟迟不知道该怎么写好用例
学习:39:20
多混些日子就可以了，这只是接触过与没经历过的差别，没多大技术性，建议你多学开发知识，这对测试非常有用
缤雪 10:39:34
我用BUGFREE2.0可以直接COPY ,修改,写起来倒是方便
学习 10:39:58
你要用TD或别的一些，COPY都不用
缤雪 10:44:37
那么就说对增删改的用例也就是可以多个步骤写在一起,就比如我对一个文本框的输入用例,可以简单写成一个用例,分步骤为:1.正常值输入2.边界值输入3.特殊字符输入 4......这样的?
学习10:45:03
就是这样的，你太有才了
学习10:46:04
当然，仁者见仁，每个人的习惯和公司对用例的要求不一样
缤雪 10:46:12
终于让我明白了!谢谢!是你耐心指导啊!
缤雪 10:46:54
怎么说,我想知道,一些规范的公司,比如经过CMMI认证的公司他们用例写的是一样呢,还是有区别?
缤雪10:47:08
应该说是用例设计
学习10:47:26
和这个没有关系的，大多会和公司系统的性质有关系，产品化和项目化的要求会有不太一样的地方
学习10:48:24
还有包括产品版本升级的频率，变更的频率，和产品所涉及的技术强度等都会决定你什么模块的用例要到什么程度
缤雪10:50:48
那么如果按刚才说的这样写,我要写的这个项目"基础数据管理系统"(就AMDR)的用例那不是很少,就只有两方向了:把权限问题搞定和保证AMD数据正常就可以了
缤雪10:51:46
我也要写产品的用例,那么产品的用例该怎么写呢
学习 10:51:51
这样我替你分析不了的，要从整个项目出发来把握
学习 10:52:24
理论上产品的用例要求会对项目化的用例高点。
缤雪 10:53:54
是否写得要不能偷懒些,写得详细些
学习 10:54:15
产品化的项目，用例的延续性和复用性更高。
学习 10:54:42
这个要根据你公司具体情况来定的
缤雪10:54:55
哦,也就是你说要考虑到升级的问题
缤雪 10:56:13
先考虑到了,测试用例复用性高也就能省事,但是延续性和复用性有区别吗?是指可以对某个用例进行补充?
学习10:56:40
 
缤雪10:57:02
延续性=?接口
学习10:57:03
改天我们面谈一下，这样会累死的

1.

use case是对一项系统功能使用情况的普遍适应的描述，而不是对个别actor或者在个别条件下使用这项功能才适应，它也不是通过举例的方式来描述的”，所以不能叫作“用例”。此种说法不尽全面,而且有些牵强（先不管它正确与否），其实use case到底是个别的，还是群体的（普遍适应），取决于我们的视点。虽然对于单个的scenario来说，use case是多个情节的叠加，是一个整体的复合概念，但是我们知道，一个系统的功能必定是可数的、有限的，而每一个功能都可以表示为一个use case，所以在观察系统提供的所有功能需求的集合这个层面上，use case又是一个一个可数的个体（“椭圆”），每一个都代表了不同的用户目标，适用于个别的actor和个别特定的前置条件。

2.

中文的“测试用例”到底是指test case（带定语的名词词组）呢，还是指对用例进行测试（testing the use cases，动宾词组）呢？显然这两者不易分辨，而且若“用例”和“测试用例”两个词同时出现在一啰个句子或一段话中，常常会让人感觉嗦和便扭。为了消除歧义，干脆以后把test case都叫做“测例”，这样不但比以前的叫法更加简洁明了，而且无论字面上还是语义上都很贴切。当然，用例和测例是不同层面的“例”。

3.

现在市面上Actor也有多种译法，常见的包括“参与者、执行者、主角”等等。，一个用例的真正参与者决不是只有外部的Actor，它们必然还包括系统本身及其内部的各种元素。“执行者”的问题与此类似：一个用例的真正执行者应该是系统本身！因此严格地讲这样译是错误的，兴许叫作“外部参与者”、“外部执行者”才更为恰当.把Actor意译成“使用者”是比较妥当的。在大多数情况下Actor的的确确就是用户（确切地说是系统用户所扮演的一种角色），所以我们可以用“使用者”这个词从字面上与“用户”（user）进行区分，但同时又保持两者语义上的联系。

 

在"我的电脑'-_"属性"里设置完远程连接后,用户远程连接时候,提示"无权限无法登陆",可以检查

1. "我的电脑--"属性'里的用户权限

2. 远程访问的用户是否设置有密码

问题:虚拟机可以PING通主机;而主机不可以PING同虚拟机

待解决:

 

当用户对系统的使用权限有限的时候,可以不采用用户登陆系统,在首页提示的方式(如移动基站管理系统)

可以借鉴"BUGFREE"左下方的提醒方式:

指派给我   我的创建   我的查询

1.

2.

3.

....

 

 

有两个项目的角色权限管理采用的是瀑布式设计,优点是能一目了然,但是页面太长!

角色权限的控制页面可以采取模块标签式,缺点是不能一目了然,如:

角色名称:

角色说明:

角色权限:

模块一     模块二    模块三     模块四......

子模块一   子模块一  子模块一    子模块一.....

子模块二   子模块二  子模块二    子模块二.....

 

 

测试:在Windows XP下安装"税务直通车3.0"

环境:按照"安装说明"完成ORACLE 9I CLIENT 安装和配置,完成IIS安装和配置,完成安装"税务直通车 3.0"STUP安装,完成WEB.CONFIG配置

问题:点击桌面的"税务直通车 3.0"图标,提升"网页无法显示"

解决:给ORA92赋予NETWORK SERVERVICE权限.