|
测试时代 第十次（北京）测试交流会圆满结束，欢迎大家继续讨论......
主题：网站怎么测试
nature_swe 2002-3-5 12:46:44
在网站测试中，测试的重点是交互性测试和性能测试
交互性测试中测试的是网页的操作性和界面的友好程度
性能测试中主要是测试反映时间
这两方面在风站测试中有着比较突出的地位
seanhe 2002-3-5 13:23:24
网站的测试应该分成交互性的和非交互性的。对于非交互性的比如：链接等有工具可以直接查，而交
互性的就需要写测试代码了，其实在开发的过程中，将交互的代码分类保存起来，在测试的时候统一
执行是比较好的方法。
hitech 2002-3-14 11:13:30
网站的测试应该包括流量测试和安全测试。
http 2002-3-14 15:41:43
网站测试主要有以下几个方面：
1.安全性测 -- 别被人黑掉。
2.压力测试 -- 得到服务器的负载。
3.链接测试 -- 发现404错误。
4.导航测试 -- 死导航、乱导航、操作复杂等。
5.界面测试 -- 多在于少图，CSS，颜色等
以上是我测试网站的经验及观点。
主题：怎样组织软件测试？
GERALDLI 2002-3-13
我接触到两种观点：
其一，软件测试是由独立软件测试部门完成的，认为这样可以保证测试的客观性和合理性，避免开发
人员按自己的编程思路进行测试而造成的负面效应，但测试人员对业务不熟悉就成了问题，他们必须
从头熟悉整个软件的业务流程。
其二，软件测试是由项目组中的相关人员完成的，认为项目组成员对业务非常熟悉，不在需要花费更
多的时间进行业务知识的培训就可以开始测试，但这样做的负面效应也是显而易见的。
那么到底该怎样来组织测试呢？
seanhe 2002-2-24 16:28:0
我感觉，测试必须独立运作，不然工作过程中会遇到很多问题，因为测试同开发的目标是不一样的。
不熟悉软件可以通过培训，提前介入等方法解决。我听到的一种比喻就是让猴子看桃，你说这得是什
么样的猴子才看的住啊：）
nature_swe 2002-2-25 12:37:23
如果一个软件公司不是打算只做一个项目就散伙的话还是有必要建立一个独立的软件测试部门为好。
其实软件测试是一门非常复杂的学科，把它作为软件开发过程中一个独立的流程来处理的话是非常有
利于软件质量的提高。
ggw 2002-2-26 11:35:2
测试是一个综合人员、综合技术的工作。开发人员进行单元测试、测试人员进行系统测试、QA、项目
经理、设计人员进行审核测试设计和测试用例等。
seanhe 2002-2-26 11:55:15
如果规模小，公司的主要目标并不是高质量，而是迅速占领市场，有效的方式当然是自己测试了。但
是公司到了一定的规模，质量就是公司进一步发展的基础了，成立测试部门就势在必行了。
SAjiang 2002-3-1 9:49:41
同意seanhe的说法。是否设置独立的软件测试部门，要经过质量，人力，成本，收益，公司发展目标
的综合考虑和权衡。
我工作的公司是这样做的：
1、开发人员负责自己开发模块的单元测试；
2、开发人员成小组，相互之间进行代码检视；
3、开发部内部集成测试（初步检测软件，保证基本能RUN）；
4、独立的测试部门先进行系统集成测试，因为我们的系统包括一些硬件，所以开发的软件要与之进行
集成，保证系统互连及接下去的系统测试能进行；
5、系统测试，较全面的对最终目标系统进行功能验证，做尽可能多地覆盖；
3-5步都有相应的按用户需求说明设计的测试用例方案，各自负责不同的内容的验证。
主题：测试何苦要自己来设计用例，我们要做的是设计测试用例
HUAJING_WU 2002-4-2
测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径
或核实是否满足某个特定需求。可以从分析设计阶段的用例和补充规约中生成测时用例
lpp56 2002-4-2 10:33:48
我觉的你的做法也有可取之处，但是主要的功能界定的范围国大，而且很多的主要功能，都依附于其
他非主要功能之上，而非主要功能如果不稳定很可能会导致主体的功能出现问题，而且，从
rational的rup中所举的测试用例的例子看他也是尽量的覆盖所有的测试点，所以我觉个人认为针对
不同的系统，不同的时间，不同的功能，可以给各个功能（需求）制定一个测试的优先级，在测试过
程中尽量先测试优先级高的需求并编写相应的测试用例。而你的情况也就是这种方法的一种，也就是
你将主要的功能界定为最高的优先级，而起它的测试你界定为低优先级，这样在12天内你完成了所有
高优先级的测试，并撰写了相应的测试用例，而其他的优先级你却没有撰写用例，而且你所说的情况
还存在一种测试通过标准的问题，你的标准就是前面说的
但如果换一个系统，那么jakim兄所说的也可能会必定位优先级，也可能需要写测试用例，而且测试
用例写的越细，就越可能发现系统设计上的一些缺陷，而且有些数据是属于纤一发而动全身的数局，
对于这种数据有效性的严正也就变成了高优先级的需求了！！！！！
HARRY_YOU 2002-4-14
背景：同事在做CIM系统测试用例时发现，系统中功能的层级太深（5、6层），所以做测试对具体的
功能点非常难描述，有谁有好的解决办法非常感谢：）
例（简化的）：客户管理（如添加客户类型等功能点）——基金公司（很多功能点）——华安基金
（新增分部等功能点）--某个分部（添加等功能点）--相关资料查询（几个类别查询）。
蔓雪 2002-4-11 18:3:53
我认为测试用例可以按照功能点编写，你所说的“对具体的功能点非常难描述”具体指的是什么？
每一个用例可以写出每个功能点的简要说明、基本流、分支流以及测试数据、预期结果、实际结果。
功能点例如：
A.添加客户类型、删除客户类型、修改客户类型。
B.添加公司、删除公司、修改公司。
C.添加分部、删除分部、修改分部。
D.按客户类别查询、按公司分类查询、按公司名称查询等等。
不论功能点有多少，都是一层层的进行的，有了客户类型划分，才能按客户类型添加公司，有了公司
才能添加公司的部门，然后才能按照各种条件进行资料查询。
以上是我的个人意见，不足之处请大家共同探讨。
seanhe 2002-4-11 21:33:17
有时候如果语言难以描述，可以截图下来，再付以文字描述，这样可能比较有效。其实无所谓难描
述，测试的工作就是要遍历系统的功能点，主要看你的组织和分类了。估计你好没有将条例想清楚。
seanhe 2002-4-14 17:3:21
测试计划理论上是按照行需求来设计的，如果需求设计的很规范，测试计划只需要与其对应就成了。
如果不规范，需要将系统分成耦合性不强的几个部分，然后逐层的细化。有时候是不容易想清楚，不
容易的事情干好了才有成就感吗：）
主题：web测试
lanyueliang 2002-3-1 16:58:31
给你提供一点东东，希望有所帮助
1.功能测试:检验系统是否满足功能需求说明书中的功能需求，检验程序是否满足程序设计书中定义
的功能。
2.负载测试：通过模拟大批量用户的并发请求，给系统施加较大的负载，这时检测整个系统处理交易
的能力。
3.压力测试：在反常数量或资源（使用的容量达到规定的极限）的情况下执行应用程序，检测中间件
系统在长时间、高负载情况下的运行处理能力，从而检验系统的稳定性。
4.操作系统+浏览器兼容性测试：在不同操作系统(win,mac,unix)和不同版本的浏览器（IE4.0,
IE5.0,IE5.5,NN6,NN4.5)组合情况下web应用能否正确执行。
5.安全性测试：安全性测试是要检验在系统中已经存在的系统安全性、保密性措施是否发挥作用，有
无漏洞。
6.可用性测试：主要从使用的合理性和方便性等角度对软件进行检查，是专为“对用户友好”的特性
进行测试。这是一种主观的感觉，取决于最终用户或顾客。
7.超链接检查：检查是否页面上所有的连接都正确链接，是否存在broken links.
8.图形显示检查：检查是否所有的图片都被正确装载，在不同的浏览器、分辨率下图片能否正确显示
（包括位置、大小）。
9.分辨率检查：在不同分辨率设置情况下，窗口的滚动条能够正确滚动，屏幕刷新是否正确。
10.调整窗口检查：在调整浏览器窗口大小时，屏幕刷新是否正确。
11.外部网络访问检查：从外部网络拨号访问web应用以验证连接、功能和性能。
主题：下载有关界面标准的文档
yinpengh 2002-4-28 19:23:23
用户界面设计的技巧与要求
界面设计的重要性有这么几个原因:首先,用户界面越直观,就越易用,越易用就越便宜。因为界面越
好，培训用户就越容易，降低了培训成本：界面越出色，用户就越少求助，降低了客户支持成本。其
次，界面越出色，用户就喜欢使用，增强了开发者工作的满意程度。
用户界面设计的技巧与技术
这里介绍的用户界面设计技巧将有助于提高面向对象的界面设计。
1. 一致。你能做到的最重要的事情就时保证用户界面运作的一致性。对于表框来说，如果双击其中
的项，使得某些事件发生，那么双击任何其它列表框中的项，都应该有同样的事情发生。所有窗口按
钮的位置要一致，标签和讯息的错词要一致。用户界面的一致性使得在用户对于界面运作建立起精确
的心理模型，从而降低培训的支持和成本。
2. 建立标准并遵循之。在应用软件中保持一致的唯一途径就是建立设计标准并加以遵循。最好的办
法时采取一套行业标准，对自身的特殊的需要加以补充。已有的行业标准，如IBM标准（1993）与
Microsoft标准（1995），通常可满足95％到99％的需要。采用行业标准，只需利用已有的成果，也
使你的应用软件看起来或感觉上更向用户已购买或建立的其他应用软件。应当在定义基础构造界面就
建立用户界面设计标准（Ambler,1998）
3. 阐述规则。用户要知道怎么使用你为他们开发的软件。软件运作的一致性表明，规则你只须解释
一遍。这比一步步详细讲解如何使用应用软件每个特性要容易得多。
4. 同时支持生手和熟手。图书馆目录符号对图书馆系统的一般用户来说，也许时够用了，但对熟手
用户，如图书管理员，很可能就没有那么有效了。图书管理员是受过专门训练，能够用复杂的查询系
统找到信息，因此，应当考虑建立一套查询界面已满足他们的特殊要求。
5. 界面件切换很重要。如果从一个屏幕转换到另一屏幕很困难，用户会很快灰心并放弃。当屏幕流
程与用户想完成的工作流程相符，此软件对用户才有意义。由于不同用户工作方式不同，应用软件需
要有足够的灵活以支持他们不同的方式。在建模阶段，界面用户流程图可用来模拟屏幕之间的流程。
6. 界面上的布局很重要。在西方，人们是自左而右，从上而下阅读，基于人们的习惯，屏幕的组织
也应当是自左而右，从上而下。屏幕小部件的布局也应当以用户熟悉的方式进行。
7. 讯息和标签措词要适当。屏幕上显示的文本是用户主要的信息源。如果文本措词很糟，用户的理
解就会很糟。要使用完整的措词和句子，而不要用缩写和代码，使文本易于理解。讯息措词要积极，
显示用户处于控制之中，并提示如何正确使用软件。如，下面那一条讯息更吸引人：“已输入了错误
信息”还是“帐号应为8位数”？此外，讯息错词要一致，在屏幕上显示的位置要一致。尽管这样的
讯息“需输入名字”和“应输入帐号”分别来说措词上没有分别，放在一起就不一致了。根据第一条
讯息的措词，第二条信息更好的措词应当是“须输入帐号”，这就使得两条讯息措辞一致了。值得注
意的是如果是中文软件要尽量避免用英文提示和一些让人看不懂的信息。
8. 了解小部件。为恰当的任务使用恰当的小部件，首先可以帮助增强应用软件的一致性，可能使得
应用软件很容易构造。学会如何正确使用小部件的唯一途径是阅读和理解你们所采用的用户界面标准
及准则。
9. 对其他软件不盲从。除非你知道一个应用软件是遵循了你们的用户界面标准和准则，否则你绝对
不能认定他做的都是对的。尽管看看人家怎么做，从中获得些主意是很不错的想法，但在懂得怎样区
分用户界面设计的好坏之前，你得留神。太多的开发者的错误地模仿其他应用软件的用户界面，而那
些界面却设计得很糟。
10. 颜色使用要适当。使用颜色要谨慎。如果使用了，也要使用指示符。问题就在于有些用户可能是
色盲，如果在屏幕上使用了颜色来突出显示某些东西，家若想让色盲的用户注意到，那么需要做些
另外的工作来突出它，如果在其旁边显示一个符号。颜色的使用也得一致，已使得整个应用软件有同
样的观感。此外，在不同平台上，色彩的表现不尽人意――在一个系统上看上去很好，在另一个系统
上常常看上去很糟。展示会上我们常听到展示者这样说：“在我家的机器上看上你过去可是很好的呀。
11. 遵循对比原则。打算在应用软件中使用颜色，要确保屏幕的可读性。最好的方法是遵循对比原
则：在浅色背景上使用深色文字，在深色背景上使用浅色文字。蓝色文字以白色为背景很容易读，但
一红色为背景很难辨认。
问题出在蓝色与红色之间没有足够的反差，而蓝色与白色之间则反差很大。
12. 字体使用要适当。老式英语字体可能在莎士比亚的剧本封面上看上去很合适，但在屏幕上却很难
辨认。要用那些可读性好的字体，如serif或Times Roman。此外，字体的使用要一致。节俭、有效的
使用两三种字体的屏幕看上去远胜于使用五六中字体的屏幕。要记住每次改变了字体的大小、风格
（粗体、斜体、下划线…..）、样式或颜色，都是在使用不同的字体。
13. 灰掉而不是移走。在某些时刻，用户经常只能访问应用软件的某些功能。在删除一个对象之前，
要先选中它。由此加深用户的心理模型，软件应当用删除按钮及（或）菜单项去做一些事。按钮应当
移去还是灰掉？灰掉它，决不能移走！当用户不该使用时侯就灰掉它，可是用户对如何使用应用软件
建立精确的心理模型。如果仅仅移走一个小部件或菜单项，而不是灰掉它，用户很难建立精确的心理
模型，因为用户只知道当前可用的，而不知道为什么是不可用的。
14. 使用非破坏性的却省按钮。通常每个屏幕定义一个却省按钮，如果用户按了回车键调用此按钮。
问题是有时用户会意外敲回车键，结果激活了缺省按钮／缺省按钮绝不能有潜在的破坏性，如删除或
保存（也许用户根本不想保存）
15. 区域排列。当屏幕有多个编辑区域，要以视觉效果和效率来组织这些区域。如图1所示，编辑区
域左对齐是最好的方法。换句话说，要使编辑区域左边界在一条直线上且上下排列。与之相应的标签
则应右对齐，置于编辑区域旁。这是屏幕上组织区域的一个整洁有效的方式。
16. 数据对其要适当。对一列列的数据通常的作法是整数，浮点数右对齐，字符串左对齐。
17. 屏幕不能拥挤。拥挤的份额屏幕让人难以理解，因而难以使用。试验结果（Mayhew,1992年）显
示屏幕总体盖度不应超过40％，而分组屏幕盖度不应超过62％。
18. 有效组合。逻辑上关联的项目在屏幕上应当加以组合，以显示其关联性。反之，任何相互之间毫
不相关的项目应当分开隔开。在项目集合间用间隔对其进行分组／或用方框也同样可做到这一点。
19. 在操作焦点处打开窗口。当用户双击一个对象显示其编辑框／详情屏幕，用户的注意力也集中于
此。因而在此处而不是其他地方打开窗口才有意义。
20. 探出菜单不应是为宜的功能来源。如果主要功能被隐藏起来，用户就不能学会怎样使用软件。开
发人员最让人灰心的作法是滥用弹出菜单，也称作上下文相关菜单，提供针对当前工作的屏幕区域特
定功能的访问。
上述的这些标准我们力争严格按照该标准进行测试，更好的为研发人员服务。向他们提供更加严格更
加有价值的测试报告。但是，现阶段由于种种原因我们现在的测试标准据该标准还有很多差距。现在
的很多标准都还不构完善。
所有的这些我们都将逐步完善最后制定出一套适合我们自己的测试标准。
主题：测试用例到底是怎样的？
foolstone 2002-4-5 8:56:44
目录
概述
测试资源和环境
测试数据
测试策略
测试通过标准
测试需求表
测试用例表
测试用例
{测试用例的标题1}
测试名称
既测试用例名和测试用例标识号。
测试目的及描述
给出测试用例的详细描述。
特殊设备（可 选）
描述本测试用例要用到的特殊设备和要求。
前提条件
描述完成本测试用例的必要前提条件。
输入数据
描述执行本测试用例的应输入的数据。
测试过程
第{N}步：
描述一个单独的测试步骤。
预期结果：
描述本步测试的预期结果。
{测试用例的标题2}
同上...........
附测试用例结果记录表
czking 2002-4-15 11:18:14
我觉得用例的测试就是画出该用例的状态图或逻辑图，其实就像流程图似的，定义好场景。然后用矩
阵的方式将流程的各分支都罗列出来，预置条件和预料输出结果，正确处理出错信息（如连库失败
等）。
－－－－－－－－－－－－－－－－－－－－－－
我告诉组员如此这般测试，他们都觉的太浪费时间了，唉，测试就是这样……
lt_bobby 2002-4-25 12:9:21
用例编号：1011
模块名称 工程 编号/版本 2.0
用例编制人员 ee 编制时间 ee
测试用例功能
利用生成器新建工程，可正常新建工程。
参考信息
参见《**项目详细设计说明书--***模块》
输入说明
1. 新建工程，工程名称为：erp，子目录名为：jdyw
2. 新建工程，工程名称为：JDYW，子目录名为：yw
3. 新建工程，工程名称为：bb，子目录名为：
输出说明
1. 工程 erp 正常建立
2. 工程 JDYW 正常建立
3. 工程 bb 正常建立
特殊规程要求
新建工程前，确认无任何工程。
环境要求
win98/NT/ME/2000/XP系统在win98下需安装pws,其他系统下需安装IIS4.0以上IE4.0以上，
office2000下的access2000及excel2000
主题：怎样测试才有效率？
wenwenlong 2002-2-23 11:39:32
测试一定要有测试规程，测试用例！按照测试规程去做吧。
但测试的一个重要标准是100%覆盖需求中的功能点，
效率吗？我觉得，使用关键路径是个不错的办法（至少不至于测个没完呢？！呵呵）
nature_swe 2002-2-25 17:17:29
我所理解的软件测试的效率是指测试用例揭示软件中的错误的效率
对一个模块进行测试用例的设计时，能设计出的测试用例的组合大多不是唯一的，效率高的组合是指
用少的时间和精力（少运行几个测试用例）发现多的错误。
要提高测试的效率，我觉得还是应多在测试设计和测试开发阶段多下功夫
seanhe 2002-2-26 12:0:1
测试也是分层次逐步细化的，比如测试经理组织写测试方案，由测试工程师执行，测试工程师只用管
对不对就成了。测试是否有效，要看你们不同阶段定义的质量目标了，如果是试用版本，当然就是基
本运行稳定了。
aux0 2002-2-26 16:1:20
seanhe,依不同的测试策略，可生成数不清的测试方案哦,测试经理只是仅仅写个太概吗?如果如您所
说,那么测试工程师只是按已知的方案按步骤执行即可,不是很死版吗,测试工程师就不可以根据自已
对项目的理解和认识,设计一些方案,找出其中的bugs吗?
seanhe 2002-2-26 21:32:58
我说地是测试经理组织写测试方案。是组织，具体如何组织就看测试经理地了。方案定下来了，当然
按照测试方案进行。但是不是只局限于测试方案，我觉得没有什么冲突，但是测试方案的要点必须充
分，没有二义性。作方案地时候要充分考虑到测试工程师地素质不同，就低不就高。这样也方便于测
试实施的外包或者雇佣低成本的人员，对于产品类，也可以作为以后测试的参考。其实测试方案是十
分清晰还是留给测试工程师发挥一直是争论的焦点，我觉得还是依据实际的情况灵活掌握好。
lpp56 2002-2-27 9:52:40
我觉得首先要，通过开发人员获得系统需求的级别，这里的级别，包括时间，技术风险，资源消耗量
等，在获得了需其的优先级后，在制定测试的优先级，在制定测试的优先级的时候不光是要参考需求
优先级，还要参考测试风险，测试策略等测试等因素同时还有一点要注意的是，在时间无法满足测试
要求的情况下要首先测试系统的基本功能，千万不敢从一开始就求全求大，那样会在测试时间过仅的
情况下吃大亏的，同时有效率的测试还需要自己开发一些工具，如数据生成，数据到入，缺陷统计，
等相应的工具。
seanhe 2002-2-27 10:54:2
理论上，系统测试的参考文档是需求规格说明书，上面详细的列出了程序需要实现的功能，但是很少
有项目做到了这点。这就需要测试人员合理的定义测试策略用来规避风险了，一般的做法是在程序提
交的前一阶段对程序进行评估，有的书上叫确认测试，看看程序的质量到达了什么水平，大的问题首
先暴露出来，如果不适合测试，可以退回给开发组。
seanhe 2002-2-28 9:16:59
那就要看测试经理的能力了，多沟通，包括时时的掌握测试人员的问题，程序的质量，及时同开发人
员，用户沟通，知道什么是对的，什么是重要的。有一定的预见性，合理的分配进度等。总之，这样
的项目风险很大，需要依靠能力。我们最好还是依靠软件工程的方法来，这样对公司，对个人都是有
好处的。
lpp56 2002-2-28 13:23:46
我觉得aux0兄所说的情况最好首先保证测试组在项目开发的初期就进入系统，并且参加每一次的开发
部门的讨论会，同时还可要求开发人员每开发出一个模块，或一个功能点，都要提交给测试，同时还
可以要求开发人员在提交测试模块前，列出自己人为地应该被测试的地方，或者是该被测对象所完成
的基本功能是那些（（我曾经试验过，效果一般但对于你提到的那种情况只能四码当活马码医了同时
向你提到的那种情况，我建议可以采用xp中的子对编程法，这样可以尽量减少无文档带来的风险）。
illesy 2002-3-4 14:45:36
应该由系统设计人员确定测试的主要关键点，代码的编写人员确定模块的测试用例，测试人员根据确
定系统说明确定测试用例。
seanhe 2002-3-4 16:11:41
一般来说，牵扯到具体代码的测试会交给工具和开发人员，这样效果比较好。当然还要有一套流程保
证。测试人员的介入最好在集成测试以后，这样效率比较高，当然关键路径是个好方法，但是操作起
来比较困难，也不易推广。
lpp56 2002-3-5 9:8:25
我不是特别同意seanhe兄的观点，如果测试人员在集成测试后进入系统，按么它对于系统的熟悉程度
要低于从单元测试作其的测试人员，（同时由于时间相对较少对于系统文档的要求回非常高，但一般
企业的文档都无法达到该要求。）这样将导致一些，需要在精通系统流程基础上发现的缺陷无法发
现，而且还有对于测试人员由于测试人员在开发过程的中部介入过程，可能会导致作单元测试的开发
人员的测试用文档与现载测试人员的交接问题，这样对文档的内容，风格等因素都由较高的要求从目
前我们国家情况看可能无法达到。所以我觉得，测试的介入点应该是在每一个单元模块被开发完，即
开始测试，而且单开发人员做过测试后应将相应的用例交给测试人员，作为参考。这样缺陷被发现的
时间比较早，所以修改缺陷所花费的成本也就相对较低。
seanhe 2002-3-5 13:18:45
我设计的测试流程，测试经理是从需求开始介入的，在需求完成后测试经理会出系统测试方案。单元
测试开发人员进行会比较节省人力成本，但是测试人员应该按照开发人员编写的单元测试方案对测试
结果进行抽查。测试人员也是分级别的，就像不可能要求所有的开发人员都象开发经理一样了解系统
一样，所以，测试过程中，测试经理是全程参与，进行方案的编写和指导，根据不同的阶段申请不同
的资源。当然首先是文档要到位。总体来说，单元测试还是开发人员进行成本要低，也更有效。
lpp56 2002-3-7 11:28:44
seanhe兄的流程有一个问题，测试经理主要职责是什么，是不是同时启动多个项目的时候每一个测试
组的测试主要负责人都叫作该项目的测试经理，同时入股有一个人来分析需求的话，一方面工作量回
很大，同时对于需求的分析也会不彻底，，而且开发人员编写的测试方案与测试结果进行抽查，但此
时会产生测试人员对于开发人员单元测试方案的依赖，对于发现缺陷非常不利。而且缺陷可能被隐藏
到系统的后期而此时修改缺陷所付出的成本会相当于前面的几倍！而在模块编写过成中有测试人员同
时分析需求的话，会产生部分xp中子对编程带来的好处（两人对于需求的分析会闭一个人更全面一
些。）而且在向seanhe兄所说的同时还要求开发人员对于所采用的用例记录的非常详细，这一点在目
前大多数软件项目开发时间过仅的情况下可能会无法推行。
ajingjing 2002-4-11 15:51:2
如果在资源条件允许的情况下，我也认为在单元测试介入比较好。有利于测试人员对系统的了解，也
有利于bugs的及早发现。但单元测试还是应以开发人员为主。
joliana 2002-4-12 9:53:24
我比较同意LPP56的，我觉的就现在的现状来看，从开发的每个模块开始测试比较好，开发人员提交
的模块应该是通过代码测试的。
同时开发人员应该有模块全局变量及一些边界值的说明。
|
