-
测试需求分析方法
2011-07-07 10:36:03
转载http://www.uml.org.cn/requirementproject/201011304.asp软件测试需求的分析方法
2010-11-30 作者: sdstc 来源: 软件测试网采编
软件测试需求是开发测试用例的依据,测试需求分解的越详细精准,表明对所测软件的了解越深,对所要进行的任务内容就越清晰,对测试用例的设计质量的帮助越大。详细的测试需求还是衡量测试覆盖率的重要指标,测试需求是计算测试覆盖的分母,没有详细的测试需求就无法有效的进行测试覆盖计算。
软件测试执行阶段是由一系列不同的测试类型的执行过程组成的,每种测试类型都有其具体的测试目标和支持技术,每种测试类型都只侧重于对测试目标的一个或多个特征或属性进行测试,准确的测试类型可以给软件测试带事半功倍的效果。
现有的软件测试分析技术不太成熟,对测试需求和测试类型的分析,所采用的方法主要是根据经验进行收集、整理,该方法依赖于测试设计人员的测试经验,由此方法得出的测试需求、测试类型往往导致测试用例设计不充分,测试覆盖度低,测试目的性不强,容易遗漏等缺陷。
可见,如何对测试需求进行细致的整理分析,明确测试执行时的测试类型,是一个亟待解决的问题。
有鉴于此,本方法的主要目的在于提供一种软件测试需求的分析方法,可以方便、详尽的获取测试需求,明确测试执行时需要实施的测试类型。
为实现上述目的,本方法提供了一种软件测试需求分析的方法,包括以下步骤:
a)列出软件开发需求中具有可测试性的开发需求;
b)对步骤a)列出的每一条开发需求,形成可测试的分层描述的测试需求;
c)对步骤b)形成的每一条测试需求,从GB/T 16260.1-2006《软件工程 产品质量 第1部分:质量模型》中定义的软件内部/外部质量模型来确定软件产品的质量需求;
d)对步骤c)所确定的质量需求,分析测试执行时需要实施的测试类型;
e)建立测试需求跟踪矩阵,对测试需求进行管理。
具体实施方式:
下面结合附图及实施例对本方法做详细的说明。
建立开发需求列表,参见图2。将每一条软件需求对应的开发文档及章节号作为软件需求标识,使用软件需求的简述作为原始测试需求描述,没有文档来源的开发需求可用隐含需求或遗漏需求进行标识,标明软件需求获取的来源信息,如开发文档、相关标准、与用户或开发人员的交流等。
由于在提取的开发需求中可能存在重复和冗余,需要进行整理,通过以下方法整理开发需求:
1)删除:删除原开发需求列表中重复的、冗余的含有包含关系的开发需求描述;
2)细化:对太简略的开发需求描述进行细化;
3)合并:如果有类似的开发需求,在整理时需要对其进行合并。
在图2表中,对于每一条开发需求,从测试角度来考虑,形成可测试的分层描述的测试需求。具体地,通过分析每条开发需求描述中的输入、输出、处理、限制、约束等,给出对应的验证内容;通过分析各个功能模块之间的业务顺序,和各个功能模块之间传递的信息和数据,对存在功能交互的功能项,给出对应的验证内容。
对每一条测试需求,从GB /T16260.1定义的软件质量子特性角度出发,确定所对应的质量子特性。即,从适合性、准确性、互操作性、保密安全性、成熟性、容错性、易恢复性、易理解性、易学性、易操作性、吸引性、时间特性、资源利用性、易分析性、易改变性、稳定性、易测试性、适应性、易安装性、共存性、易替换性和依从性方面的定义出发,确定每一条测试需求所对应的质量子特性。
软件测试可以划分为以下测试类型:功能测试、安全性测试、接口测试、容量测试、完整性测试、结构测试、用户界面测试、负载测试、压力测试、疲劳强度测试、恢复性测试、配置测试、兼容性测试、安装测试等。
不同的质量子特性可以确定出不同的测试内容,这些测试内容可以通过不同的测试类型来实施。例如,从易安装性方面考虑,测试内容包括测试软件安装的工作量、安装的可定制性、安装设计的完备性、安装操作的简易性、是否容易重新安装,这对应了测试类型中的安装测试,通过安装测试可以验证这些测试内容。
本方法的一个实施例是建立一个质量子特性与测试类型的关系表,参见图3,该对应表给出了质量子特性与测试类型的对应关系。对所确定的质量子特性,可以使用该对应表来确定测试类型。
建立测试需求跟踪矩阵,参见图4。将上述步骤分析、确定的开发需求、测试需求、测试类型填入测试跟踪需求矩阵。
使用测试需求跟踪矩阵对测试需求进行管理。对于测试工作而言,需求变更管理是一个相对被动的过程,软件需求发生了变更,测试需求必须随之变化。软件需求一旦发生变化,就要对需求跟踪表进行维护,启动配置管理过程,将与软件需求变更相关的内容进行同步变更。
实施例:假设一个开发需求是这样描述:
需求名:增加员工信息
需求描述:一条完整的培训信息包括培训的主题、证书、内容、起止时间、费用、地点、机构,其中培训的主题、内容、起止时间、费用、机构为必填项。培训的起始时间不能晚于截止时间,培训费用精确到元角分。每一个输入项的数据规格应遵循数据字典的要求。
一种软测试需求分析方法的分析过程如下:
1、建立开发需求列表,列出具有可测试性的开发需求。
序号
开发需求标识
开发需求描述
信息来源
1
增加员工信息
一条完整的培训信息包括培训的主题、证书、内容、起止时间、费用、地点、机构,其中培训的主题、内容、起止时间、费用、机构为必填项。培训的起始时间不能晚于截止时间,培训费用精确到元角分。每一个输入项的数据规格应遵循数据字典的要求。
《人力资源管理系统业务需求说明书》
2、根据开发需求的描述,从测试角度来考虑,分析每条开发需求描述中的输入、输出、处理、限制、约束等,形成可测试的分层描述的测试需求。
3、从GB /T16260.1定义的软件质量子特性角度出发,确定每条测试需求所对应的质量子特性。
4、参考图3,对于所确定的质量子特性,选择适合的测试类型。
5、建立测试需求矩阵,将上述步骤分析、确定的开发需求、测试需求、测试类型填入测试跟踪需求矩阵。
图1分析方法流程图
序号
开发需求标识
开发需求描述
信息来源
图2开发需求列表
图3质量子特性与测试类型对应表
-
有效编写高质量软件的75条建议
2010-05-25 15:36:27
以下内容摘自www.51testing.com
1. 你们的项目组使用源代码管理工具了么?
应该用。VSS、CVS、PVCS、ClearCase、CCC/Harvest、FireFly都可以。我的选择是VSS。
2. 你们的项目组使用缺陷管理系统了么?
应该用。ClearQuest太复杂,我的推荐是BugZilla。
3. 你们的测试组还在用Word写测试用例么?
不要用Word写测试用例(Test Case)。应该用一个专门的系统,可以是Test Manager,也可以是自己开发一个ASP.NET的小网站。主要目的是Track和Browse。
4. 你们的项目组有没有建立一个门户网站?
要有一个门户网站,用来放Contact Info、Baselined Schedule、News等等。推荐Sharepoint Portal Server 2003来实现,15分钟就搞定。买不起SPS 2003可以用WSS (Windows Sharepoint Service)。
5. 你们的项目组用了你能买到最好的工具么?
应该用尽量好的工具来工作。比如,应该用VS.NET而不是Notepad来写C#。用Notepad写程序多半只是一种炫耀。但也要考虑到经费,所以说是“你能买到最好的”。
6. 你们的程序员工作在安静的环境里么?
需要安静环境。这点极端重要,而且要保证每个人的空间大于一定面积。
7. 你们的员工每个人都有一部电话么?需要每人一部电话。而且电话最好是带留言功能的。当然,上这么一套带留言电话系统开销不小。不过至少每人一部电话要有,千万别搞得经常有人站起来喊:“某某某电话”。《人件》里面就强烈谴责这种做法。
8. 你们每个人都知道出了问题应该找谁么?
应该知道。任何一个Feature至少都应该有一个Owner,当然,Owner可以继续Dispatch给其他人。
9. 你遇到过有人说“我以为…”么?
要消灭“我以为”。Never assume anything。
10. 你们的项目组中所有的人都坐在一起么?
需要。我反对Virtual Team,也反对Dev在美国、Test在中国这种开发方式。能坐在一起就最好坐在一起,好处多得不得了。
11. 你们的进度表是否反映最新开发进展情况?
应该反映。但是,应该用Baseline的方法来管理进度表:维护一份稳定的Schedule,再维护一份最新更改。Baseline的方法也应该用于其它的Spec。Baseline是变更管理里面的一个重要手段。
12. 你们的工作量是先由每个人自己估算的么?
应该让每个人自己估算。要从下而上估算工作量,而不是从上往下分派。除非有其他原因,比如政治任务工期固定等。
13. 你们的开发人员从项目一开始就加班么?
不要这样。不要一开始就搞疲劳战。从项目一开始就加班,只能说明项目进度不合理。当然,一些对日软件外包必须天天加班,那属于剥削的范畴。
14. 你们的项目计划中Buffer Time是加在每个小任务后面的么?
不要。Buffer Time加在每个小任务后面,很容易轻易的就被消耗掉。Buffer Time要整段的加在一个Milestone或者checkpoint前面。
15. 值得再多花一些时间,从95%做到100%好值得,非常值得。
尤其当项目后期人困马乏的时候,要坚持。这会给产品带来质的区别。
16. 登记新缺陷时,是否写清了重现步骤?
要。这属于Dev和Test之间的沟通手段。面对面沟通需要,详细填写Repro Steps也需要。
17. 写新代码前会把已知缺陷解决么?要。每个人的缺陷不能超过10个或15个,否则必须先解决老的bug才能继续写新代码。
18. 你们对缺陷的轻重缓急有事先的约定么?
必须有定义。Severity要分1、2、3,约定好:蓝屏和Data Lost算Sev 1,Function Error算Sev 2,界面上的算Sev 3。但这种约定可以根据产品质量现状适当进行调整。
19. 你们对意见不一的缺陷有三国会议么?必须要有。要有一个明确的决策过程。这类似于CCB (Change Control Board)的概念。
20. 所有的缺陷都是由登记的人最后关闭的么?
Bug应该由Opener关闭。Dev不能私自关闭Bug。
21. 你们的程序员厌恶修改老的代码么?
厌恶是正常的。解决方法是组织Code Review,单独留出时间来。XP也是一个方法。
22. 你们项目组有Team Morale Activity么?
每个月都要搞一次,吃饭、唱歌、Outing、打球、开卡丁车等等,一定要有。不要剩这些钱。
23. 你们项目组有自己的Logo么?
要有自己的Logo。至少应该有自己的Codename。
24. 你们的员工有印有公司Logo的T-Shirt么?
要有。能增强归属感。当然,T-Shirt要做的好看一些,最好用80支的棉来做。别没穿几次就破破烂烂的。
25. 总经理至少每月参加次项目组会议要的。
要让team member觉得高层关注这个项目。
26. 你们是给每个Dev开一个分支么?
反对。Branch的管理以及Merge的工作量太大,而且容易出错。
27. 有人长期不Check-In代码么?
不可以。对大部分项目来说,最多两三天就应该Check-In。
28. 在Check-In代码时都填写注释了么?
要写的,至少一两句话,比如“解决了Bug No.225”。如果往高处拔,这也算做“配置审计”的一部分。
29. 有没有设定每天Check-In的最后期限?
要的,要明确Check-In Deadline。否则会Build Break。
30. 你们能把所有源码一下子编译成安装文件吗?
要的。这是每日编译(Daily Build)的基础。而且必须要能够做成自动的。
31. 你们的项目组做每日编译么?
当然要做。有三样东西是软件项目/产品开发必备的:1. bug management; 2. source control; 3. daily build。
32. 你们公司有没有积累一个项目风险列表?
要。Risk Inventory。否则,下个项目开始的时候,又只能拍脑袋分析Risk了。
33. 设计越简单越好越简单越好。
设计时候多一句话,将来可能就带来无穷无尽的烦恼。应该从一开始就勇敢的砍。这叫scope management。
34. 尽量利用现有的产品、技术、代码千万别什么东西都自己Coding。BizTalk和Sharepoint就是最好的例子,有这两个作为基础,可以把起点提高很多。或者可以尽量多用现成的Control之类的。或者尽量用XML,而不是自己去Parse一个文本文件;尽量用RegExp,而不是自己从头操作字符串,等等等等。这就是“软件复用”的体现。
35. 你们会隔一段时间就停下来夯实代码么?
要。最好一个月左右一次。传言去年年初Windows组在Stevb的命令下停过一个月增强安全。Btw,“夯”这个字念“hang”,第一声。
36. 你们的项目组每个人都写Daily Report么?
要写。五分钟就够了,写10句话左右,告诉自己小组的人今天我干了什么。一则为了沟通,二则鞭策自己(要是游手好闲一天,自己都会不好意思写的)。
37. 你们的项目经理会发出Weekly Report么?
要。也是为了沟通。内容包括目前进度,可能的风险,质量状况,各种工作的进展等。
38. 你们项目组是否至少每周全体开会一次?
要。一定要开会。程序员讨厌开会,但每个礼拜开会时间加起来至少应该有4小时。包括team meeting, spec review meeting, bug triage meeting。千万别大家闷头写code。
39. 你们项目组的会议、讨论都有记录么?
会前发meeting request和agenda,会中有人负责主持和记录,会后有人负责发meeting minutes,这都是effective meeting的要点。而且,每个会议都要形成agreements和action items。
40. 其他部门知道你们项目组在干什么么?
要发一些Newsflash给整个大组织。Show your team’s value。否则,当你坐在电梯里面,其他部门的人问:“你们在干嘛”,你回答“ABC项目”的时候,别人全然不知,那种感觉不太好。
41. 通过Email进行所有正式沟通
Email的好处是免得抵赖。但也要避免矫枉过正,最好的方法是先用电话和当面说,然后Email来确认。
42. 为项目组建立多个Mailing Group
如果在AD+Exchange里面,就建Distribution List。比如,我会建ABC Project Core Team,ABC Project Dev Team,ABC Project All Testers,ABC Project Extended Team等等。这样发起Email来方便,而且能让该收到email的人都收到、不该收到不被骚扰。
43. 每个人都知道哪里可以找到全部的文档么?
应该每个人都知道。这叫做知识管理(Knowledge Management)。最方便的就是把文档放在一个集中的File Share,更好的方法是用Sharepoint。
44. 你做决定、做变化时,告诉大家原因了么?
要告诉大家原因。Empower team member的手段之一是提供足够的information,这是MSF一开篇的几个原则之一。的确如此,tell me why是人之常情,tell me why了才能有understanding。中国人做事喜欢搞限制,限制信息,似乎能够看到某一份文件的人就是有身份的人。大错特错。权威、权力,不在于是不是能access information/data,而在于是不是掌握资源。
45. Stay agile and expect change 要这样。
需求一定会变的,已经写好的代码一定会被要求修改的。做好心理准备,对change不要抗拒,而是expect change。
46. 你们有没有专职的软件测试人员?
要有专职测试。如果人手不够,可以peer test,交换了测试。千万别自己测试自己的。
47. 你们的测试有一份总的计划来规定做什么和怎么做么?这就是Test Plan。要不要做性能测试?要不要做Usability测试?什么时候开始测试性能?测试通过的标准是什么?用什么手段,自动的还是手动的?这些问题需要用Test Plan来回答。
48. 你是先写Test Case然后再测试的么?
应该如此。应该先设计再编程、先test case再测试。当然,事情是灵活的。我有时候在做第一遍测试的同时补上test case。至于先test case再开发,我不喜欢,因为不习惯,太麻烦,至于别人推荐,那试试看也无妨。
49. 你是否会为各种输入组合创建测试用例?
不要,不要搞边界条件组合。当心组合爆炸。有很多test case工具能够自动生成各种边界条件的组合——但要想清楚,你是否有时间去运行那么多test case。
50. 你们的程序员能看到测试用例么?
要。让Dev看到Test Case吧。我们都是为了同一个目的走到一起来的:提高质量。
51. 你们是否随便抓一些人来做易用性测试?
要这么做。自己看自己写的程序界面,怎么看都是顺眼的。这叫做审美疲劳——臭的看久了也就不臭了,不方便的永久了也就习惯了。
52. 你对自动测试的期望正确么?
别期望太高。依我看,除了性能测试以外,还是暂时先忘掉“自动测试”吧,忘掉WinRunner和LoadRunner吧。对于国内的软件测试的现状来说,只能“矫枉必须过正”了。
53. 你们的性能测试是等所有功能都开发完才做的么?
不能这样。性能测试不能被归到所谓的“系统测试”阶段。早测早改正,早死早升天。
54. 你注意到测试中的杀虫剂效应了么?
虫子有抗药性,Bug也有。发现的新Bug越来越少是正常的。这时候,最好大家交换一下测试的area,或者用用看其他工具和手法,就又会发现一些新bug了。
55. 你们项目组中有人能说出产品的当前整体质量情况么?
要有。当老板问起这个产品目前质量如何,Test Lead/Manager应该负责回答。
56. 你们有单元测试么?
单元测试要有的。不过没有单元测试也不是不可以,我做过没有单元测试的项目,也做成功了——可能是侥幸,可能是大家都是熟手的关系。还是那句话,软件工程是非常实践、非常工程、非常灵活的一套方法,某些方法在某些情况下会比另一些方法好,反之亦然。
57. 你们的程序员是写完代码就扔过墙的么?
大忌。写好一块程序以后,即便不做单元测试,也应该自己先跑一跑。虽然有了专门的测试人员,做开发的人也不可以一点测试都不做。微软还有Test Release Document的说法,程序太烂的话,测试有权踢回去。
58. 你们的程序中所有的函数都有输入检查么?
不要。虽然说做输入检查是write secure code的要点,但不要做太多的输入检查,有些内部函数之间的参数传递就不必检查输入了,省点功夫。同样的道理,未必要给所有的函数都写注释。写一部分主要的就够了。
59. 产品有统一的错误处理机制和报错界面么?
要有。最好能有统一的error message,然后每个error message都带一个error number。这样,用户可以自己根据error number到user manual里面去看看错误的具体描述和可能原因,就像SQL Server的错误那样。同样,ASP.NET也要有统一的Exception处理。可以参考有关的Application Block。
60. 你们有统一的代码书写规范么?
要有。Code Convention很多,搞一份来发给大家就可以了。当然,要是有FxCop这种工具来检查代码就更好了。
61. 你们的每个人都了解项目的商业意义么?
要。这是Vision的意思。别把项目只当成工作。有时候要想着自己是在为中国某某行业的信息化作先驱者,或者时不时的告诉team member,这个项目能够为某某某国家部门每年节省多少多少百万的纳税人的钱,这样就有动力了。平凡的事情也是可以有个崇高的目标的。
62. 产品各部分的界面和操作习惯一致么?
要这样。要让用户觉得整个程序好像是一个人写出来的那样。
63. 有可以作为宣传亮点的Cool Feature么?
要。这是增强团队凝聚力、信心的。而且,“一俊遮百丑”,有亮点就可以掩盖一些问题。这样,对于客户来说,会感觉产品从质量角度来说还是acceptable的。或者说,cool feature或者说亮点可以作为质量问题的一个事后弥补措施。
64. 尽可能缩短产品的启动时间要这样。
软件启动时间(Start-Up time)是客户对性能好坏的第一印象。
65. 不要过于注重内在品质而忽视了第一眼的外在印象程序员容易犯这个错误:太看重性能、稳定性、存储效率,但忽视了外在感受。而高层经理、客户正相反。这两方面要兼顾,协调这些是PM的工作。
66. 你们根据详细产品功能说明书做开发么?
要这样。要有设计才能开发,这是必须的。设计文档,应该说清楚这个产品会怎么运行,应该采取一些讲故事的方法。设计的时候千万别钻细节,别钻到数据库、代码等具体实现里面去,那些是后面的事情,一步步来不能着急。
67. 开始开发和测试之前每个人都仔细审阅功能设计么?
要做。Function Spec review是用来统一思想的。而且,review过以后形成了一致意见,将来再也没有人可以说“你看,当初我就是反对这么设计的,现在吃苦头了吧”
68. 所有人都始终想着The Whole Image么?要这样。项目里面每个人虽然都只是在制造一片叶子,但每个人都应该知道自己在制造的那片叶子所在的树是怎么样子的。我反对软件蓝领,反对过分的把软件制造看成流水线、车间。参见第61条。
69. Dev工作的划分是单纯纵向或横向的么?
不能单纯的根据功能模块分,或者单纯根据表现层、中间层、数据库层分。我推荐这么做:首先根据功能模块分,然后每个“层”都有一个Owner来Review所有人的设计和代码,保证consistency。
70. 你们的程序员写程序设计说明文档么?
要。不过我听说微软的程序员1999年以前也不写。所以说,写不写也不是绝对的,偷懒有时候也是可以的。参见第56条。
71. 你在招人面试时让他写一段程序么?
要的。我最喜欢让人做字符串和链表一类的题目。这种题目有很多循环、判断、指针、递归等,既不偏向过于考算法,也不偏向过于考特定的API。
72. 你们有没有技术交流讲座?
要的。每一两个礼拜搞一次内部的Tech Talk或者Chalk Talk吧。让组员之间分享技术心得,这笔花钱送到外面去培训划算。
73. 你们的程序员都能专注于一件事情么?
要让程序员专注一件事。例如说,一个部门有两个项目和10个人,一种方法是让10个人同时参加两个项目,每个项目上每个人都花50%时间;另一种方法是5个人去项目A,5个人去项目B,每个人都100%在某一个项目上。我一定选后面一种。这个道理很多人都懂,但很多领导实践起来就把属下当成可以任意拆分的资源了。
74. 你们的程序员会夸大完成某项工作所需要的时间么?
会的,这是常见的,尤其会在项目后期夸大做某个change所需要的时间,以次来抵制change。解决的方法是坐下来慢慢磨,磨掉程序员的逆反心理,一起分析,并把估算时间的颗粒度变小。
75. 尽量不要用Virtual Heads 最好不要用Virtual Heads。
Virtual heads意味着resource is not secure,shared resource会降低resource的工作效率,容易增加出错的机会,会让一心二用的人没有太多时间去review spec、review design。一个dedicated的人,要强过两个只能投入50%时间和精力的人。我是吃过亏的:7个part time的tester,发现的Bug和干的活,加起来还不如两个full-time的。参见第73条。73条是针对程序员的,75条是针对 Resource Manager的。
-
微软软件测试的可借鉴之处
2009-03-26 17:38:45
1. 测试流程
首先说说测试流程,微软的测试流程也没什么新的东西,和大多数的测试流程一样。
大致是先进行测试准备,然后是Testcase的编写,然后是白盒测试(不一定每个项目都有),然后是功能测试阶段,然后是验收测试,最终release。
如果看流程的话,和一般公司大同小异,没什么新花样。但是我觉得值得借鉴的是两点。
第一, 微软的流程执行的非常认真。
这点非常值得提倡,我们都知道,测试的最终质量决定于测试流程和测试人员素质,要想测试质量有保证,要么是流程很完善,要么你流程不行,但是个人能力超强。如果有一个很好的流程,就算执行的人稍微差点,最终的质量也不会差到哪里去。所以流程是很重要的。
但是,看国内的公司欠缺的就是这个,要么是没有流程,要么流程是个花架子,没认真执行过。我想微软的测试人都是超级牛人,但是人家还是老老实实的忠实按照流程来走,我觉得这点非常好。(在IBM 也是这样,笔者以前在IBM作项目的时候,发现他们的文档写的特认真,流程特认真),所以说忠实的执行一个好的流程是成功的一大半。
第二, 在整个流程中,微软非常强调测试尽早介入。
微软在这方面是一致提倡的,按照我们国内IT业的恶习,一般都是软件主体差不多成型了,拉几个测试人员过来点点,其实这是非常不好的。微软的测试人员在项目一开始就和开发人员同步介入,在需求阶段就开始介入,进行需求评审。在开发人员开始编码的时候,测试人员就开始编写Test case,并开发一些测试工具,或者写一些配套的测试代码(不要奇怪,微软的测试人员都能写很好的代码)。微软的理念就是:预防bug比解决bug好,所以非常提倡测试尽早介入,把一部分bug消灭在需求阶段。
2. 自动化流程
说到自动化,大家可能以为我是说微软的自动化测试工具多牛,其实微软内部用到的自动化测试工具倒是不多,就算有也都是内部开发的,非常实用的,他们不会去用MI的工具。
说微软的自动化程度高,主要是体现在流程方面,譬如说整个自动构建流程,在开发人员代码check in之后,系统自动发邮件,邮件内容就是一个change list,包括代码更新list以及一个编译者添加的comment,其内容是该版本功能的变化或者修改掉的bug ID。整个测试过程中能用自动化的地方都尽可能采用自动化,尽可能减少人为失误,并且可以使人和机器并行工作。个人觉得,这点很值得我们国内的测试公司借鉴,能自动化的流程都自动化,减少一些不必要的沟通。
3. 质量控制机制
说到质量控制是个大问题,需要整个团队和流程提高素质。那么微软的质量控制可以借鉴的是什么呢?是他们的机制。在微软的测试流程当中,在开发的早期,项目中所有的问题都是Dev leader和PM商量说了算(当然也要参考需求方的意见),但是到后期,具体就是功能测试之后,项目的主动权都在测试这边,某个bug的要不要解决,或者项目进度控制都是测试leader说了算。这和国内的大多数软件公司是不一样的,在微软,测试人员要对最终的软件质量负责任,但是也有相应的权利来约束开发人员。当然,他们也肯定有一些bug是产生争议的,这个时候的仲裁机制就是PM,这个不是我们传统的PM(Project manager),而是一种具有微软特色的PM(全称是Program manager)。这样,测试人员在对一些争议bug的处理上有相当的话语权。
4. 测试用例及管理
微软的测试用例倒没什么特别的,不过看过他们用例之后,还是觉得写的详细,认真,但是又不冗长拖沓,这个需要很高深的水平。另外,微软的测试用例管理用的是微软自己开发的用例管理工具。
另外值得说明的是,微软的每个用例都进行了分级,并且功能所在的模块都标的很清楚。
5. 效率
在效率方面,微软的测试效率非常高!高的让人惊叹,我问一个在微软工作的哥们,“你们那边测试的最大特点是什么”,他说“最大特点是快!”,就是效率很高,具体就是在测试后期过程中测试和开发之间的反馈非常快,开发修改一定量的bug,提交一个新的版本。测试人员往往能在很快的时间内把测试结果反馈出来,一般是在1天之内就能把用例快速run一遍,这样就能减少某些后期才发现bug导致的项目delay。在国内很多项目的通病是,开发解决问题带进一个新问题,测试人员整个遍历一遍用例之后才能发现,这样来回反复就消耗了大量的时间。
但微软是如何才能实现快速反馈呢?
第一, 测试人员对程序的了解,微软的测试人员对程序内部结构都非常熟悉,修改某一个地方,可能引起什么问题,哪些用例需要重新测试,测试人员非常清楚,能快速的执行最可能出错的地方。如果某些模块不熟悉,那么他们会和开发人员在一起沟通这次修改可能引起的问题。
第二, 工具!还是工具,在微软的测试中,测试人员用各种工具帮助测试,提高测试效率是占到很大的比重。
第三, 时间意识。微软的测试人员有强烈的时间意识。
6. 测试工具
测试工具能很大程度上提高测试效率,这个作为测试人员都很清楚。当然测试工具在微软的测试中也应用非常广泛,但是请注意,微软并不是像我们国内的公司一样使用的都是LR或QTP这类的录制回放工具,反而这种工具倒是用的不多,就跟微软不屑CMM一样,可能是不想屈尊自己IT老大的身份吧。
但是微软的测试工具最大的特点是实用。他们用的测试工具都是确实能提高效率,确实能办事情的工具,都不是类似WR和QTP的很大很系统的工具,而是比较小的,很灵活,实用的小工具(譬如:Fiddler、Drip、httpwatch、IE DevToolBar、PaintNotNet、procexp etc.)。甚至有一些测试工具是测试人员在开发人员协助下根据项目需要临时开发的,不过大多数工具都是微软内部已经共享出来的,在微软内部各种各样的小工具特别多。
总体给我的感觉是,不是为了用测试工具而用,而是根据实际的需要,确实能提高效率而用到,在用的过程中确实也很大的提高了效率。
7. 测试人员的专业素质
微软测试给我印象最深刻的还有他们测试人员的专业水准,在测试过程中,测试人员在一些技术上并不逊色于开发人员,在一些bug的处理上,能提出很多合理的很有建设性的建议。
8. 微软的白盒测试
微软的白盒测试怎么执行呢?让我略微有点吃惊的是,微软的一半测试人员基本不做白盒测试,除非有些不能做黑盒的模块,另外也不是所有的产品都作白盒测试。
微软的白盒测试一般还是由专门的白盒测试人员来做,但是开发人员要对测试人员的白盒测试代码进行Review,另外微软对开发人员的代码,效率也都有一套详细的考核机制,所以开发人员对自己的代码也是非常负责任的,都进行很认真的进行测试。
9. 意识(时间,质量)
另外微软的测试还有很好的一点就是意识,时间和质量的意识都是非常强。在控制时间成本上,意识非常强,这点非常值得我们国内同仁学习,另外,风险管理的机制和意识都是非常好。在微软,项目组的每个成员都被明确告知,如果这个项目每delay一天,就会损失多少个million的美元,所以整个项目组都有比较好的时间意识。
另外,在微软,项目组人员的质量意识都是比较强的。怎么样更好服务用户,让用户体验更好,怎么样更好的改进,这种意识比较强。
10. 微软的培训
在微软内部,员工外训的机会比较少,大多都是内部互训,各人培训自己的强项,有比较好的互相分享的习惯。另外微软的内部有非常丰富的各种培训文档。以后我会上传上去和大家分享。
11. 测试数据记录
微软的测试数据记录是非常全的,也都是系统自动的,每天都是由系统自动统计当天的bug情况,然后发送一个report到每个项目组成员的邮箱里。最后到测试总结的时候,这些测试数据将变得非常有用。 -
TD不支持IE7.0版本的解决方法
2009-03-24 17:00:45
将虚拟目录下的首页文件如C:\Inetpub\TDBIN\start_a.htm(用记事本打开)这个页面中的
var fMSIE3456 = (ua.lastIndexOf('MSIE 3.0') != -1) || (ua.lastIndexOf('MSIE 4.0') != -1) || (ua.lastIndexOf('MSIE 5.0') != -1) || (ua.lastIndexOf('MSIE 5.5') != -1) || (ua.lastIndexOf('MSIE 6.0') != -1) 后加上|| (ua.lastIndexOf('MSIE 7.0') != -1)即可IE8也如此。|| (ua.lastIndexOf('MSIE 8.0') != -1) -
印度项目质量管理经验
2008-02-22 09:42:59
原文出处 http://www.yesky.com/20030325/1659121.shtml
计算机和通信技术的迅速发展,特别是Internet技术的发展与普及,为企业内部、企业与外部提供了快速、准确、可靠的信息交流渠道。信息化企业运作管理系统已成为企事业单位参与全球市场竞争的必备支持系统。正是由于这样的市场需求与技术发展现状,为我国的IT行业带来了空前发展的机遇,特别是软件行业。软件企业能否抓住这样一个难得的发展机会需要多方面的努力,其中软件质量保障在其发展过程中占有重要的位置。众所周知,印度已成为世界上软件业增长最快的国家,目前每年软件业产值达数十亿美元,并且还在以每年30%~50%的速度增长。比较我国和印度的软件产业,就不难发现:中国拥有巨大的软件市场和世界公认的软件开发资源,在基础研究和对技术前瞻性的把握上,也有自己的优势,就整体社会经济环境而言也优于印度。此外,中国的软件开发人员费用比较低廉,仅是世界市场的1/3左右。虽然中国人并不缺乏软件开发的天赋,但是在越来越强调规模化经营的今天,先天不足的管理痼疾使我们举步维艰,难以摆脱小作坊式的软件开发模式。而印度软件业从一开始就立足于为美国软件企业服务,并遵循其软件开发的管理模式,与国际标准接轨。管理上的问题不能得到彻底的解决,软件的质量保障就无从谈起。笔者最近在与印度一家通过了CMM4级评估的软件公司(以下简称A公司)进行合作的过程中,较为详细地了解了他们有关项目管理的一些详细情况,更深刻地感受到了项目管理的规范化与企业软件质量保障之间的密切关系。下面想着重从软件企业的构架,软件项目计划、项目管理、项目经理的职责等方面对印度软件的项目管理及我国软件质量保障应注意的问题进行一些经验总结,供业内人士参考。软件测试专业网站:51Testing软件测试网*]L?\-yyFOc X
软件测试专业网站:51Testing软件测试网S+U8Zcg3up
1.软件企业的组织结构(1)A公司结构
图1是A公司的组织结构图,同国内公司差异较大的部门有QA、SSG和人力资源部门。
"ZpZI.g$H138366
dh"Bd;S138366图1* A公司中,QA(Quality Assure)部门与研发部门独立,负责监督流程的执行。QA同时负责领导与研发部门组成的联合工作组,制定公司流程。 软件测试专业网站:51Testing软件测试网:xe'ex7Bw*BV]
* SSG(System Support Group)类似我们的IT部门,负责公司所有计算机软件和硬件资源的分配和管理。所有的办公环境和开发/实验室环境由SSG负责安装和维护,计算机资源属于SSG,由各个项目向SSG提出需求,项目结束后,设备需要交还给SSG。个人和项目组没有固定的软件和硬件资源。SSG是与研发平行的部门。 软件测试专业网站:51Testing软件测试网2s ^0D BA2^` ]+{
* 人力资源部门负责公司的人力资源管理,并维护员工的技能数据库。项目开始时,项目组向人力资源申请人力,向SSG申请计算机硬件和软件。项目结束时需要释放计算机资源给SSG,释放人力资源到人力资源池,并同时更新员工的技能数据库。研发部门的人力资源由研发总负责人和其助手分配(类似我国各公司的人力资源部)。(2)项目组结构
1) A公司对项目组进行独立核算,项目具体负责人为PC(Project Coordinator),负责项目计划和执行,对项目具体成员进行分工。在每个阶段的结束会议上(如概要设计结束),PC要接受QC(Quality Coordinator)的审查。除了PC与QC的接口外,所有其他外部接口都由EM(Engineer Manager)完成,EM负责与客户打交道,向SSG、人力资源要求资源,与其他项目组协调进度。软件测试专业网站:51Testing软件测试网+T?Sy!EgQ3qN9M
软件测试专业网站:51Testing软件测试网adk'C f7U)Et H
2) 汇报关系为: 软件测试专业网站:51Testing软件测试网4grsF#d F0Wj#L
Team Member->Team Leader->PC->EM->研发总负责人。3) 印度工程师分为7级,半年一次考评,即半年有一次升级机会。 软件测试专业网站:51Testing软件测试网|l F)Vj2d.uHR
1级:Software Engineer,刚毕业的本科生和研究生。 软件测试专业网站:51Testing软件测试网km4Gc:o@^bc
2级:Senior Software Engineer。
fWif3V&V138366 3级:Project Leader。
C8n8T*nT#zi5h6?138366 4级:Project Manager。
9z4O/L JWJx138366 5级:Senior Project Manager。
tQ_:C-t!h138366 3级可以成为PC,4级可以成为EM。刚开始平均2年升一级,越往后升职越慢。A公司规定,一人最多可以同时兼任两个项目的PC,EM管理的项目没有限制。
A公司通常的项目组为4到5人,最多不超过10人。
以上是A公司(同时也是印度大多数规范化的软件公司)的组织结构和项目组结构。可以看出,A公司的组织结构非常清晰,各个部门分类非常细,任务明确,软件生产的每一个步骤都有专门的部门、专门的人员负责,从最基础的开发人员到负责统领全局的总经理,层层管理,沟通渠道畅通。而在我国,管理的不规范往往首先体现在公司的组织结构上,集中表现为部门的缺失和管理的交叉上。我国的软件公司,大部分规模较小,开发人员超过 100人的公司很少。在印度,软件公司无论大小,都是“麻雀虽小,五脏俱全”,绝不会因为公司的规模大小而改变合理的组织结构。因此笔者认为,国内的软件企业要想有效地保障产品质量,首先就要在构架合理的组织结构上下功夫,这就如同盖高楼首先要打好地基一样,地基不打牢,结构不合理,其他方面再下功夫也是徒劳。有人说,因为国内软件企业规模小,所以造成结构设置的欠缺,但笔者认为恰恰是因为没有建立一个规范化的组织结构,才会使软件产品质量不保,进而严重影响了企业的发展扩大。
2.项目计划
凡事预则立,不预则废。这里的“预”就是指计划。对于软件企业,计划的重要性是不言而喻的。让我们先看看A公司的项目计划是如何制定的:在A公司,项目开始之前必须先估计项目的规模(以代码行数来衡量);然后制定项目计划。通常时间为2~3周,已知的最长有5周。 EM负责制定项目 EWP(Engineer Work Paper),其中定义了项目需要的人力和计算机资源,由相关部门同意,并报研发总负责人批准后才能开始项目。
项目的正式开始时间由项目组的Kickoff Meeting算起,Closeout Meeting结束。
大概很多人都听过这样一句话:“计划赶不上变化”。这种“变化”对某些行业而言也许并不会产生太大的影响,但对于软件企业而言,却会给软件产品的质量保证带来严重的负面影响。为什么会造成这种“计划赶不上变化”的现象?究其原因,笔者认为主要是因为对计划的重视程度不够,计划过于笼统、粗糙导致可执行性太差,再加上一些人为因素的影响,必然会产生这样的后果。
如果我们的软件企业都能像A公司这样,在作计划时能考虑到每一个细节,不是仓促做出决定,而是由所有的相关部门共同对产品计划进行反复研究、制定、讨论、修改,最终形成一套系统、严密、具有很强的可执行性的计划。计划一旦形成,就严格按照计划去执行,而不受某个人、某件事的影响,那么就不仅能够减少大量资源的浪费,产品的质量也得到了保障。
因此,对计划的高度重视、周密制定、严格执行是企业有效保障产品质量的一个重要环节。
3.项目管理
当企业构架了合理的组织结构并制定了缜密的计划后,就进入了产品的开发阶段。在这个阶段中,项目管理起了重要作用,它所涉及的环节相当具体复杂,下面先介绍一下A公司在项目管理上的具体细节:
(1)开发阶段和项目周期
;z\J0FzyN[138366 开发阶段比较明显,注重各阶段应完成的功能,对本阶段应完成的工作不能留到下一阶段。软件测试专业网站:51Testing软件测试网@esK9A*B(o
软件测试专业网站:51Testing软件测试网 J!am \ C
(2)流程* A公司对流程比对项目更重视。
)H$Pvz3o138366 * 软件开发流程非常规范和系统化,其流程的可执行性很高,并且能在实践过程中不断改进。A公司的流程已覆盖到了一个项目研发的所有方面,包括从最开始的意向到最后软件的版本发布(release),都有相应的流程规定,基本上已形成一种工业化的软件开发。
4}?W W%hK9RA I$g!Ve/a138366 * 人和流程是保证项目成功的两个最关键因素。由好的人按好的流程进行项目开发,才能最大限度地保证项目的成功。一个好的流程可以保证差的人做出来的东西不至于太差,但不能确保做出精品。通过流程可以实现一种规范化、流水线化、工业化的软件开发。(3)计划
1) 计划详细、周到。
2) 流程中明确定义开发阶段。
#O_ R&?0`(c138366
V3V(by-G)R3V138366 3) 每个阶段都列出了该阶段的各项活动,并详细描述每项活动的属性:
5W f ^;h*OhL)ez F138366 * 进入条件,输入; 软件测试专业网站:51Testing软件测试网:g"n(w4pjO_
* 验证方法;
Qzc2E9}9g'TB:Y138366 * 结束条件,输出。4)每个阶段结束都要召开阶段结束会议。前一个阶段结束才能进入下一阶段。
5)计划中每个活动都比较具体,每个活动的时间以天(半天)为单位。计划包括了开展质量控制活动的时间。
(4)Review
按印度公司流程,一般把Review和测试作为保证软件质量两个主要手段。测试的重要性就不需说明了,而 Review则是一个非常简单有效并能尽早发现软件中错误的方法,可以说,任何交付物都要经Review后才能进行基线化。目前A公司有很详细全面、可执行性很高的Review流程和各种交付物的Review Checklist。
在印度软件企业,现有这么一句口号:凡事有计划,凡事必review。
(5)QA
QC(质量经理)作为质量保证部门(SQA)的代表,监督和保证项目的进展遵循QMS各项流程和模板,并且收集项目中发现的一些问题和解决方法以优化流程。
(6)度量数据
CMM中比较强调用数据说话,对项目过程中基本上所有的数据都会有记录,最后把收集的数据提交质量保证部门进行分析,以改进流程。A公司的项目经理和质量经理很重视项目中的数据收集,包括各种Review数据、测试数据以及项目组员每天的活动数据等。项目经理也要维护一个项目档案,在这个项目档案中可以说包含了项目开发过程中所有的产出、开发活动、管理活动等的记录。可以这么说,有了这个项目档案,你就可以完全了解这个项目的开发过程。
(7)团队精神
印度公司都比较强调团队精神、合作精神,应该说,其流程本质上就要求员工之间的互相协调和理解。相对而言,印度员工的合作精神和协调精神都比我国员工要好得多。
(8)培训
印度公司都比较强调培训,一般有专门的培训部门进行协调。在新员工进入公司后都会有公司流程和其他一些公司普遍章程的培训,以保证员工对流程的理解和执行。对于具体项目,项目经理在制定项目计划时就会在项目计划中提出所有的培训需求,包括技术上的培训和其他所需的培训。
(9)配置管理
g}.jTw0ZG138366 在项目正式开展前,项目经理就要制定配置管理计划,并且指定配置管理员建立起配置管理库,按配置流程严格进行配置管理。在配置流程中也详细提供了对更改的控制,没有经过批准的更改请求是绝对不能进行的。
~[_{:shV138366 (10)记录记录及时、充分、比较准确。这些记录包括:重要的邮件、会议纪要、审核记录、缺陷报告、测试报告。
0M S'oIQt+?'B138366
fu6L+H@2S8v?oi138366 1)与客户和其他项目组的所有往来必须邮件记录。2)对所有的活动都有一个跟踪落实的过程,比如对所有的Review记录和更改请求都会有一个状态标识,标识其当前状态,通过跟踪其状态来监督其落实。
3)对所有的活动,包括对文档和代码的更改都会有一个历史记录。
4)记录比较准确、比较客观。
5)许多记录都是通过定量的数值记录,强调以数据说话(CMM4级的重点就是量化管理)。
以上是A公司在项目管理中所涉及到的一些主要环节,很值得国内的软件企业在制定项目管理规划时借鉴。除此之外,我国的软件企业在产品开发管理的过程中,还易出现以下几个方面的问题:
1)需求说明差─需求不清楚、不完整、太概括、或者不可测试,都会造成问题。
2)不切实际的时间表─如果在很短的时间里要求做许多事,出现错误是不可避免的。
3)测试不充分─只能根据客户意见或系统崩溃来判断系统的质量。
4)不断增加功能─在开发正在进行过程中要求增加许多新的功能。这是常见的问题。
5)交流问题─如果开发人员对客户的要求不了解,或者客户由不恰当的期望,必然会导致错误。
p:fw2]L138366
Qcf4u1v+h(P6B-B PZR138366 这些问题的出现,将会对软件质量的保证产生不良影响,针对上述问题并结合A公司在项目管理方面的经验,笔者提出一些相应的解决方法,以供参考:1)可靠的需求─应当有一个经各方一致同意的、清楚的、完整的、详细的、整体的、可实现的、可测试的需求。为帮助确定需求,可使用模型 (prototypes)。
2)合理的时间表——为计划、设计、测试、改错、再测试、变更、以及编制文档留出足够的时间。不应使用突击的办法来完成项目。
3)适当测试─尽早开始测试;每次改错或变更后,都应重新测试。项目计划中要为测试和改错留出足够时间。
4)尽可能坚持最初的需求─一旦开发工作开始,要准备防止修改需求和新增功能,要说明这样做的后果。如果必须进行变更,必须在时间表上有相应的反映。如果可能,在设计阶段使用快速的模型,以便使客户了解将会得到的东西。这将会使他们对他们的需求有较高的信心,减少以后的变更。
5)沟通——在适当时机进行预排和检查;充分利用团组通信工具—电子邮件、群件(groupware)、网络故障跟踪工具、变更管理工具、以及因特网的功能。要确保文件是可用的和最新的。优选电子版文档,避免纸介质文档:进行远距离联合作业及协作;尽早使用模型,使客户的预想表达清楚。
4.PC(项目经理)
项目经理是项目成败的关键人物,其对项目的成败负主要责任。因此在这里将项目经理的有关内容单独提出,以A公司为例详细说明PC在整个产品研发过程中所扮演的角色,希望能对国内软件企业的项目经理有所启示。
(1)在A公司,按流程在一个项目正式开展之前,项目经理需要完成:
* 项目计划(Project Plan):在此描述整个项目所应完成的交付物、项目时间表、培训需求、资源需求、质量保证计划以及过程和交付物的定量质量目标等。
* 项目配置管理计划(Project Configuration Plan):在此指定配置管理员,描述项目配置项列表、配置管理库、版本管理计划等等。
*项目过程手册(Process Handbook):在此描述本项目所采取的裁剪后的生命周期模型和流程。
(2)在项目开发过程中,项目经理需非常了解项目进度,进行工作任务细化、具体计划和安排项目成员工作任务等工作。对突发事件项目经理需能及时合理地进行协调。
(3)总的说来,PC安排工作有这么几个特点:
a.PC对软件开发具有丰富的经验,了解软件开发的普遍流程,了解各个阶段所需完成的工作,这是安排好项目组成员工作的前提,在A公司对PC的整体素质要求非常高。
b.在项目正式开展前,PC准备项目计划文档,在项目计划中包含了项目进度时间表,但此时间表比较粗,只能给出各个阶段和各个子阶段的起始结束日期。对各个阶段和各个子阶段的详细工作安排和各项工作责任人只能在项目开展工程中根据项目实际情况进行安排,一般是在每周项目组例会上进行本周详细工作安排。
g `/DR/Q+~.d-O138366 软件测试专业网站:51Testing软件测试网%M-r9vC:Dv
c.PC对工作安排往往精确到天,有时甚至精确到小时,要做到这一点,需要:* PC对本项目进展非常了解。了解渠道通常是每周组员的状态报告和直接与组员接触了解,这也需项目组成员能如实汇报工作。
* 对现阶段或本周所需完成的工作非常了解。知道现在该做什么,并且能把各项工作进行合理细致地划分,因为各个分解的工作比较细致,因此能相对精确地评估出这些工作完成所需的时间。
* PC对项目组员的能力比较了解,安排工作时能做到有的放矢。当安排的员工对工作不熟悉时,会指定相应的组员进行协助。
* PC对组员的工作安排都比较细致饱满。一般不会出现有些员工有事干,有些员工没事干的情况,当出现这种情况或员工提前完成工作时,PC就会进行相应的协调。
d.PC在项目组例会上的工作安排一般只限于本周或甚至是过后的二、三天,一般不会太长,对长时间工作的安排容易失去精确并且不易控制。相对而言,短时间的工作安排就比较精确而且容易控制,并且能不断根据完成的工作进行调整。当然,这就要求PC能根据项目计划中的项目时间表进行整体进度的把握。
e.项目组例会一般一周一次(时间不能太长),但必要时(如组员工作已完成或其他事情),也可在中途召开项目会议进行工作安排,一般时间都比较短(十几分钟左右,一般不超过半小时,以免浪费时间),总之,当PC觉得需要时,就会召开项目会议。
f.当项目组出现意外事件或影响项目团结的事件时,PC能及时合理协调,解决项目组内的不和谐气氛。
q tV$z yt5X138366 软件测试专业网站:51Testing软件测试网*K|,w0q8P5g,I3W)\8_^!{
g.PC善于鼓励手下,发挥员工的潜能,PC往往会赞扬很好地完成了工作的组员。
's#x@`$D?e9^3\Uw138366
5NJ)I!Diop3RT4V138366 从上面可以看出,对PC的能力(包括技术和管理能力)要求是非常高的,我国的软件企业往往只重视PC的技术能力,但事实上,一个只精通技术的人往往不能成为一个合格的领导者,笔者认为对PC而言,首先要求他能够比他的下属看得更远一步,顺利时不盲目乐观,遇到挫折时不茫然失措,使整个团队始终保持高昂的士气。软件测试专业网站:51Testing软件测试网&@"cw2EpxT,X
1c-G'v^8B:r5` u ry;z138366 总结以上结合印度软件项目管理的经验总结了一些我国软件质量保障应注意的问题。曾有人提出:这样一味地学习模仿,民族软件工业没有多大希望。但笔者认为,在这个问题上不妨采取“拿来主义”的办法,对于好的,事实证明是成功的经验,首先是“占有”,然后才是“挑选”和“ 创新”。如果能把印度的管理经验真正领会并付诸实践,相信对我们的民族软件工业一定会起到积极的推动作用。
-
bugfree2.0安装与配置(Windows+Mysql+PHP+IIS)
2007-12-18 00:21:29
已在下面系统安装运行成功:
Win2000_sp4,WinXP_sp2所需软件:
mysql-4.0.8-win32 mysql数据库
mysqlcc-0.9.3-win32 Control Center图形界面
php-4.4.2-installer.exe PHP环境
bugfree2.0 bugs缺陷管理工具http://www.bugfree.org.cn/安装过程:
全部选默认安装路径
1.安装mysql-4.0.8-win32
2.安装mysqlcc-0.9.3-win32
3.安装php-4.4.2-installer.exe
4.运行C:\mysql\bin\winmysqladmin.exe
第一次运行,会弹出填写用户名和密码的窗口,直接关掉.(此时,mysql默认用户名为root,密码为空)
5.运行MySQL Control Center,在Register Server窗口中的Host Name:wind(你的计算机名字),点Add.
在Console Manager窗口中双击root@wind:3306开启连接.
6.控制面板=>管理工具=>Internet信息服务=>默认网站(右键)=>新建虚拟目录=>别名(bugfree)=>浏览目录(指向你的bugfree)
7.新建的虚拟目录bugfree(右键)=>属性=>文档(添加index.php至顶)
8.在mysqlcc里=>Datebases(右键)=>新建数据库(bugfree2)=>bugfree2(右键)connect=>User Administration(右键)=>新建用户(用户名:root密码:空host:计算机ip)=>在右边勾选bugfree2
9.打开本地硬盘上bugfree文件夹下include下config.inc.php文件.
这里是bugfree的系统配置.因前面的设置和里面的参数是对应的,所以不用修改此文件参数.
10.=>点bugfree虚拟目录(在右边框里找到install.php)=>右键(浏览)=>进入安装
安装时,如果你没有stmp服务器,可选flase.跳过stmp检索.
11.访问http://192.168.1.90/bugfree
默认用户名:admin 密码:123456 -
TD7.6中英文对照表
2007-12-17 12:55:48
TD7.6中英文对照表
Defect
英文
中文
备注
Defect
缺陷
Summary
概要
Detected By
被(谁)发现
Detected on Date
被发现的日期
Severity
严重程度
Assigned To
被分配给
Detected in Version
被发现的版本
Modified
修正
修正Defect的日期
Priority
优先级
Project
项目
Reproducible
可重现
Status
状态
Subject
主题
Descrīption
描述
Submit
提交
Attach
缚上
Thesaurus
辞典
R&D Comments
研发人员备注
Actual Fix Time
实际修改时间
Estimated Fix Time
估计修改时间
Planned Closing Version
计划关闭的版本
Select Filter Condition
选择过滤器条件
Available/Visible Column
可用/可见 列
Attachments
附件
Favorite
喜爱的
Requirement
需求
Estimated DevTime
估计设计和生成测试时间
Execution Status
执行状态
Template
模板
Exec Date
执行日期
Expected
期望结果
Duration
持续时间
Analysis
分析
Details
详细资料
Associated
联合
Current
当前的
-
mantis安装与配置(Windows+Mysql+PHP+IIS)
2007-12-16 18:10:41
已在下列系统安装运行成功:
Win2000_sp4,WinXP_sp2所需软件:
mysql-4.0.8-win32 mysql数据库
mysqlcc-0.9.3-win32 Control Center图形界面
php-4.4.2-installer.exe PHP环境
mantis-0.19.4.rar bugs缺陷管理工具安装过程:
全部选默认安装路径
1.安装mysql-4.0.8-win32
2.安装mysqlcc-0.9.3-win32
3.安装php-4.4.2-installer.exe
4.运行C:\mysql\bin\winmysqladmin.exe
5.运行MySQL Control Center,在Register Server窗口中的Host Name:wind(你的计算机名字),
点Add.在Console Manager窗口中双击root@wind:3306开启连接.
6.设置Mantis1) 打开IIS管理器,在默认网站中增加一个虚拟目录Mantis,指向你的Mantis解压缩目录(这里使用C:\Mantis),在“属性”窗口的“文档”页面增加默认文档“index.php”;
2) 将C:\Mantis中的config_inc.php.sample复制一份,改名为config_inc.php,修改其中的设置; Mantis的设置是这样保存的:在config_defaults_inc.php中保存这Mantis的默认设置,用户自己的设置信息保存在config_inc.php中,如果某个选项在config_inc.php中有设置,则系统使用config_inc.php中的设置,否则使用config_defaults_inc.php的系统默认设置;config_inc.php.sample则是Mantis给出的一个用户设置文件例子。 所以我们需要修改config_inc.php文件中的设置,设置很简单,各个参数的意义可以参见config_defaults_inc.php,这里对每个参数都有详细的解释,虽然是E文,不过应该都能看懂;Sample中给出的一些设置是一定需要修改的,比如MySQL数据库的连接参数,管理员的邮箱的;其他的要根据你的实际情况进行修改.下面是我的一些自定义参数,其中一些参数($g_use_jpgraph 和$g_use_phpMailer的设置请参照下面的内容):
$g_use_iis = ON; # 使用IIS
$g_show_version = OFF; # 不在页面下部显示 Mantis的版本号
$g_default_language = 'chinese_simplified'; # 默认语言为简体中文
$g_show_project_menu_bar = ON; # 显示项目选择栏
$g_show_queries_count = OFF; # 在页脚不显示执行的查询次数 $g_default_new_account_access_level = DEVELOPER; # 默认用户级别
$g_use_jpgraph = ON; # 使用图形报表
$g_jpgraph_path = 'C:/PHP/includes/JPGraph/src/'; # JPGraph路径
$g_window_title = 'Mantis Bug 跟踪管理系统'; # 浏览器标题
$g_page_title = 'Mantis Bug 跟踪管理系统'; # 页面标题栏
$g_enable_email_notification = ON; # 开通邮件通知
$g_smtp_host = 'smtp.mail.net'; # SMTP 服务器
$g_smtp_username = 'mailuser'; # 邮箱登录用户名
$g_smtp_password = 'mailpwd'; # 邮箱登录密码
$g_use_phpMailer = ON; # 使用 PHPMailer 发送邮件
$g_phpMailer_path = 'C:/PHP/includes/PHPMailer/'; # PHPMailer 的存放路径
$g_phpMailer_method = 2; # PHPMailer 以 SMTP 方式发送 Email
$g_file_upload_ftp_server = 'ftp.yourftp.com'; # 上传文件 FTP
$g_file_upload_ftp_user = 'ftpuser'; # FTP 登录用户名
$g_file_upload_ftp_pass = 'ftppwd'; # FTP 登录密码
$g_short_date_format = 'Y-m-d'; # 短日期格式,Y 大写表示 4 位年
$g_normal_date_format = 'Y-m-d H:i'; # 普通日期格式
$g_complete_date_format = 'Y-m-d H:i:s'; # 完整日期格式
完成以上设置以后,你就可以使用Mantis了,打开IE,输入http://localhost/mantis,应该就可以
看到Mantis的登录页面了,你可以用默认用户名administrator和密码root登录进去,进行管理设置。 -
bugzilla安装与配置(Windows+Mysql+Perl+IIS)
2007-12-15 22:45:52
已在下列系统安装运行成功:
Win2000_sp4,WinXP_sp2所需软件:
Mysql 4.0.18
Mysqlcc 0.9.3
ActivePerl 5.8.0
Bugzilla-2.17.6安装过程:
1.安装Mysql 4.0.18
安装Mysqlcc 0.9.32.安装ActivePerl 5.8.0
3.在Mysql中创建数据库bugzilla
用户名:bugs(必须是bugs) 密码:任意
运行cmd进入bugzilla目录,运行perl checksetup.pl查看需要更新的perl模块
到http://www.cpan.org/选Perl modules->all modules,下载not found的模块,
perl模块有两种安装方法,一种直接解压下载模块,进入其目录,运行
perl MakeFile.pl
nmake
nmake test (可省略此步)
nmake install
(安装了VC就会有nmake)
另一种是运行ppm <module name>,DBD-mysql-2.9002、DBI-1.38最好用这种方式。
安装完成后可以运行perl checksetup.pl检查是否bugzilla需要的perl模块都安装完毕。运行Modules下的installModule.bat(注意安装的路径)
所有模块安装完成后,运行perl checksetup.pl,如果模块全部安装正确,会在bugzilla目录下
生成localconfig文件。
修改localconfig文件
$index_html = 1 (生成index.html)
$mysqlpath = "c\\mysql\\bin" (你的mysql\bin路径)
$webservergroup = "8"
$db_host = "localhost" (计算机IP)
$db_user = "bugs" (mysql的登陆用户名)
$db_pass = '<bugs_password>'(mysql bugs用户的登陆密码)再次运行perl checksetup.pl,系统提示输入administrator邮箱,名字,密码。
4.默认网站->属性->主目录->配置->添加:
Executable: C:\Perl\bin\perl.exe "%s" %s
Extension: .pl
Limit to: GET,HEAD,POSTExecutable: C:\Perl\bin\perl.exe "%s" %s
Extension: .cgi
Limit to: GET,HEAD,POST5.新建虚拟目录bugzilla
bugzilla目录属性->文档:
添加index.cgi至顶6.重起IIS
-
bugs安装与配置(Windows+Mysql+PHP+IIS)
2007-12-15 22:27:02
已在下列系统安装运行成功:
Win2000_sp4,WinXP_sp2所需软件:
mysql-4.0.8-win32 mysql数据库
mysqlcc-0.9.3-win32 Control Center图形界面
php-4.4.2-installer.exe PHP环境
bugs_1.7.2 bugs缺陷管理工具安装过程:
全部选默认安装路径
1.安装mysql-4.0.8-win32
2.安装mysqlcc-0.9.3-win32
3.安装php-4.4.2-installer.exe
4.运行C:\mysql\bin\winmysqladmin.exe
第一次运行,会弹出填写用户名和密码的窗口,直接关掉.
5.运行MySQL Control Center,在Register Server窗口中的Host Name:wind(你的计算机名字),
点Add.
在Console Manager窗口中双击root@wind:3306开启连接.
6.控制面板=>管理工具=>Internet信息服务=>默认网站(右键)=>新建虚拟目录=>别名(bugs)=>浏览目录
(指向你的bugs_1.7.2)
7.新建的虚拟目录bugs(右键)=>属性=>文档(添加index.php至顶)=>bugs(右键)=>浏览=>点BUGS Installation scrīpt(安装bugs)
=>I Accept=>默认选项=>continue=>默认用户名为Administrator你可以在下面设置密码=>update
8.访问http://192.168.1.90/bugs
软件测试技术交流群60926703 (已满) CDN流媒体测试技术交流群126760166 (未满)
标题搜索
我的存档
数据统计
- 访问量: 107572
- 日志数: 57
- 建立时间: 2007-12-14
- 更新时间: 2011-07-07