最新评论
我的收藏
统计信息
- 访问量: 2298
- 日志数: 16
- 图片数: 1
- 书签数: 1
- 建立时间: 2006-12-22
- 更新时间: 2008-07-17
RSS订阅
我的最新日志
-
姊妹篇：软件可测试性需求设计
2008-7-17
软件可测试性需求设计Author: Vince 来源:http://blog.csdn.net/vincetest一、引言
1.目的
提高软件的可测试性，加快测试进度，提高测试效率。
2.范围
本文描述的范围主要是可测性设计的特征，考虑方向及设计方法。
3.读者对象
系统分析员、设计人员、开发人员。【文章来源：文斯测试技术研究中心 http://blog.csdn.net/vincetest】
二、测试所需文档
1、需求规格说明书
2、概要设计说明书
3、详细设计说明书
4、系统功能清单
5、系统运行环境搭建指导书
6、系统操作指导书
三、可测试性设计需求
可测试性主要是指被测实体具有如下特征：可控制性、可分解性、稳定性、易理解性、可观察性，该特征的主要要表现是设立观察点、控制点、观察装置。需要注意的是可测性设计时必须要保证不能对软件系统的任何功能有影响，不能产生附加的活动或者附加的测试。【文章来源：文斯测试技术研究中心 http://blog.csdn.net/vincetest】
1.可控制性设计需求
1)全局变量的可控制性设计需求
在外界使用适当的手段能够直接或间接控制该变量,包括获取、修改变量值等.可以将全局类型的变量进行分类并封装到一个个接口中操作。
2)接口的可控制性设计需求
各接口在外界使用适当的手段能够直接调用对该接口进行操作,这里所谓的适当的手段主要包括使用测试工具和增加额外代码. 对于向外提供的接口的接洽处能够人为的对接，比如构造测试环境模拟接口对接，这里所指的开放接口主要是指相对于被测系统，即为被测系统外提供的接口。接口接洽处人为对接时各接口所要求的条件和所需的参数人为的能够轻易达到和提供。
3)模块的可控制性设计需求
对于每个相对独立的模块设计好所需要的驱动和桩都能单独设计用例进行测试对应的功能，在测试运行期间模块异常时能够将其隔离而不影响测试。
4)业务流程的可控制性设计需求
在测试环境满足的情况下能够控制任一单独业务流程，各业务流程具有流通性。
5)场景的可测性设计需求
将一场景所涉及到的业务和接口整合到一个统一的接口使其能够单独操作该场景。
2.可分解性设计需求
1)业务流程的可分解性设计需求
对于复杂的业务流程需合理设定分解点，在测试时能够对其进行分解。
2)场景的可测性设计需求
对于复杂的场景需合理设定分解点，在测试时能够对其进行分解。
3.稳定性设计需求
测试模块发布合理，不能在后期追加的模块为前期所测模块引入新的不必要的测试活动。
4.易理解性设计需求
1)设计文档的易理解性
设计参考标准
内容描述主次要分清
依赖关系描述明确
2)接口的易理解性
接口功能明确
参数有意义
3)业务的易理解性
4)场景的易理解性【文章来源：文斯测试技术研究中心 http://blog.csdn.net/vincetest】
5.可观察性设计需求
1)业务执行状态和过程可观察性设计需求
2)异常情况可观察性设计需求
6.测试驱动和桩的设置
为单个测试接口、测试业务、测试场景预留测试驱动和桩的接入点。
7.适合增量式开发的可测性设计
在增量式开发过程中必须优先考虑测试桩和测试驱动实现的难易程度和真实性。
8.可查询设计
对系统级别的全局变量或者状态设置查询接口；
某一业务或场景调用接口设置接口路径查询.
9.自愈合功能
在某一场景中局部出现故障时设置多路选择或者其他干涉进行跳转执行使其具有正常逻辑功能。
10.输出结果
对于任何一项操作都要能产生预期的输出,不管是正确的还是错误的甚至是异常的.测试结果的表现形式可以是数据、现象等，不管是以什么方式表现，都要有依可寻，在设计文档中要有说明。对于测试结果易于判断,具有可分析性、可获得性.在设置的各个控制点或观察点的结果易于查询、修改等。
11.提供统一的操作执行面板
操作面板元素主要由输入和输出元素组成，如所执行的操作和对应的输出，但由于被测系统可能是一个比较复杂的系统，由多个可以独立的模块组成，涉及到的操作和输出比较多，各操作之间的关联也比较复杂。在设计时统一的做一个操作面板，该操作面板成为一个可以执行整个被测系统操作的独立模块，一种是以命令的形式执行操作，直接以printf语句的形式输出查看，另一种是以GUI的形式，输入（执行的操作）输出均在界面上执行和体现，这样比较直观。如下图所示：
【文章来源：文斯测试技术研究中心 http://blog.csdn.net/vincetest】
特别对于执行某一场景时要跟踪该场景的关键过程和执行后的输出参数，给出一系列可以分析的数据，该场景可以以执行过程分阶段监控，将监控范围内的数据输出以供测试人员分析 -
软件的可测试性
2008-7-17
一次跟客户做测试交流，被问到一个关于软件可测试性的问题，一时间竟无语，以前了解过，却没有真正的关注过，项目马上要做客户需求书和产品需求书了，这个阶段需要做一些把握了，网上搜罗到了好东东，收藏在坛子了，也与各位同仁共享
软件可测试性设计
Author: Vince1 概述
随着软件行业的迅猛发展，软件测试也逐渐受到越来越多的软件公司所重视，然而开发出来的软件直接就可以拿出来做测试吗？根据近几年来的实践证明，在设计软件时事先没有对软件的可测试性进行周密设计和部署的软件在测试时总是很难于进行，直到测试无法进行下去为止。被测软件在编码时需要考虑给测试和后期的产品维护提供必要的手段和接口支持，即要求软件具有可测试性。基于可测试性的目标考虑，良好的架构设计，完备的接口，使得软件测试更加高效和可行，同时产品维护也更加便利。 【文章来源：文斯测试技术研究中心 http://blog.csdn.net/vincetest】本文描述的范围：可测试性定义、可测试性特征、可测试性设计。
读者对象：系统分析和设计人员、开发人员、测试人员。
参考文献：
1.《软件可测试性需求设计》 Vince
2.《高质量C++/C编程指南》 林锐
3.《软件工程思想》 林锐【文章来源：文斯测试技术研究中心 http://blog.csdn.net/vincetest】
2 软件可测试性定义
2.1 可测试性定义
软件的可测试性是指在一定的时间和成本前提下，进行测试设计、测试执行以此来发现软件的问题，以及发现故障并隔离、定位其故障的能力特性。简单的说，软件的可测试性就是一个计算机程序能够被测试的容易程度。
一般来说可测试性很好的软件必然是一个强内聚、弱耦合、接口明确、意图明晰的软件，而不具可测试性的软件往往具有过强的耦合和混乱的逻辑。【文章来源：文斯测试技术研究中心 http://blog.csdn.net/vincetest】
2.2 可测试性特征
1.可操作性：“运行得越好，被测试的效率越高。”
1)系统的错误很少；
2)没有阻碍测试执行的错误；
3)产品在功能阶段的演化(允许同时的开发和测试)。
2.可观察性：“你所看见的就是你所测试的。”
1)每个输入有唯一的输出；
2)系统状态和变量可见，或在运行中可查询；
3)过去的系统状态和变量可见，或在运行中可查询(例如：事务日志)；
4)所有影响输出的因素都可见；
5)容易识别错误输出；
6)通过自测机制自动侦测内部错误；
7)自动报告内部错误；
8)可获取源代码。3.可控制性：“对软件的控制越好，测试越能够被自动执行与优化。”
1)所有可能的输出都产生于某种输入组合；
2)通过某种输入组合，所有的代码都可能被执行；
3)测试工程师可直接控制软件和硬件的状态及变量；
4)输入和输出格式保持一致且有结构；
5)能够便利地对测试进行说明、自动化和再生；
6)接口和模块易控制；
7)业务流程和场景易控制。4.可分解性：“通过控制测试范围，能够更快地分解问题，执行更灵巧的再测试。”
1)软件系统由独立模块构成；
2)能够独立测试各软件模块；
3)业务流程和场景易分解。5.简单性：“需要测试的内容越少，测试的速度越快。”
1)功能简单性(例如：特性集是满足需求所需的最小集合)；
2)结构简单性(例如：将体系结构模块化以限制错误的繁殖)；
3)代码简单性(例如：采用代码标准为检查和维护提供方便)。6.稳定性：“改变越少，对测试的破坏越小。”
1)软件的变化是不经常的；
2)软件的变化是可控制的；
3)软件的变化不影响已有的测试；
4)软件失效后能得到良好恢复和隔离。7.易理解性：“得到的信息越多，进行的测试越灵巧。”
1)设计能够被很好地理解并遵循行业规范；
2)内部、外部和共享构件之间的依赖性能够被很好地理解；
3)设计的改变被通知；
4)可随时获取技术文档；
5)技术文档组织合理；
6)技术文档明确详细；
7)技术文档精确性稳定；
8)相关环境配置说明与操作指导。【文章来源：文斯测试技术研究中心 http://blog.csdn.net/vincetest】
3软件可测试性设计
3.1可测试性设计
软件的可测试性特征主要表现是设立观察点、控制点、观察装置、驱动装置、隔离装置。需要注意的是可测试性设计时必须要保证不能对软件系统的任何功能有影响，不能产生附加的活动或者附加的测试，采取合适的设计模式对软件进行设计。
1.坚持测试驱动设计（测试先行）的方法。
优先编写测试代码，这是标准的XP方法。不是说应该一次性编写全部测试代码后，再一次性全部实现。先写验收测试，再写单元测试，编写一些测试代码，实现它们，再编写一些测试代码，再实现它们等等是个更好的办法。设计以这种方式得以进展；在实现阶段捕捉错误并在下一组测试中改正它，以这种方式编写测试也更少会使人畏缩。【文章来源：文斯测试技术研究中心 http://blog.csdn.net/vincetest】2.尽量做到每个操作对应一个函数，使函数小型化。
使用小型函数说明和重载带缺省参数的函数将使在测试中调用这些函数变的愉快的多。否则，在测试这些函数时将不得不构造额外参数，如果参数很大，那么将很快导致代码膨胀。更糟的是，它会诱使你编写比在其它情况下更少的测试。3. 数据的显示与控制分离
把代码移到 GUI 视图的外面。然后各种 GUI 动作就能成了模型上的简单方法调用。这样，对GUI测试者来说，通过方法调用测试功能比间接地测试功能容易的多。另一个好处是它使修改程序功能而不影响视图变的更容易。4.可控制性设计【文章来源：文斯测试技术研究中心 http://blog.csdn.net/vincetest】
1)全局变量的可控制性设计
I.在外界使用适当的手段能够直接或间接控制该变量,包括获取、修改变量值等；
II. 可以将全局类型的变量进行分类并封装到一个个接口中操作。
2)接口的可控制性设计
各接口在外界使用适当的手段能够直接调用对该接口进行操作,这里所谓的适当的手段主要包括使用测试工具和增加额外代码. 对于向外提供的接口的接洽处能够人为的对接，比如构造测试环境模拟接口对接，这里所指的开放接口主要是指相对于整个被测系统，即为被测系统以外提供的接口。接口接洽处人为对接时各接口所要求的条件和所需的参数人为的能够轻易达到和提供。
3)模块的可控制性设计
对于每个相对独立的模块设计好所需要的驱动和桩都能单独设计用例进行测试对应的功能，在测试运行期间模块异常时能够将其隔离而不影响测试。
4)业务流程的可控制性设计
在测试环境满足的情况下能够控制任一单独业务流程，各业务流程具有流通性。
5)场景的可测试性设计
将一场景所涉及到的业务和接口整合到一个统一的接口使其能够单独操作该场景。5.可分解性设计
1)业务流程的可分解性设计
对于复杂的业务流程需合理设定分解点，在测试时能够对其进行分解。
2)场景的可分解性设计
对于复杂的场景需合理设定分解点，在测试时能够对其进行分解。6.稳定性设计
测试模块发布合理，不能在后期追加的模块为前期所测模块引入新的不必要的测试活动。【文章来源：文斯测试技术研究中心 http://blog.csdn.net/vincetest】7.易理解性设计
1)设计文档的易理解性
I.设计参考标准
II.内容描述主次要分清
III.依赖关系描述明确
2)接口的易理解性
I.接口功能明确
II.参数有意义
3)业务的易理解性
4)场景的易理解性8.可观察性设计
1)业务执行状态和过程可观察性设计
2)异常情况可观察性设计9.测试驱动和桩的设置
为单个测试接口、测试业务、测试场景预留测试驱动和桩的接入点。10.适合增量式开发的可测试性设计
在增量式开发过程中必须优先考虑测试桩和测试驱动实现的难易程度和真实性。11.可查询设计【文章来源：文斯测试技术研究中心 http://blog.csdn.net/vincetest】
1)对系统级别的全局变量或者状态设置查询接口；
2)某一业务或场景调用接口设置接口路径查询12.自愈合功能
在某一场景中的局部出现故障时设置多路选择或者其他干涉进行跳转执行气候的具有正常逻辑的功能。13. 输出结果
对于任何一项操作都要能产生预期的输出,不管是正确的还是错误的甚至是异常的.测试结果的表现形式可以是数据、现象等，不管是以什么方式表现，都要有依可寻，在设计文档中要有说明。对于测试结果易于判断,具有可分析性、可获得性.在设置的各个控制点或观察点的结果易于查询、修改等。14.提供统一的操作执行面板
操作面板元素主要由输入和输出元素组成，如所执行的操作和对应的输出，但可能被测系统是一个比较复杂的系统，由多个可以独立的模块组成，涉及到的操作和输出比较多，各操作之间的关联也比较复杂。在设计时统一的做一个操作面板，该操作面板成为一个可以操作整个被测系统的独立模块，一种是以命令的形式执行操作，直接以printf语句的形式输出查看，另一种是以GUI的形式，输入（执行的操作）输出均在界面上执行和体现，这样比较直观。如下图所示：
特别对于执行某一场景时要跟踪该场景的关键过程和执行后的输出参数，给出一系列可以分析的数据，该场景可以以执行过程分阶段监控，将监控范围内的数据输出以供测试人员分析。【文章来源：文斯测试技术研究中心 http://blog.csdn.net/vincetest】
3.2 可测试性编码
1.注释需要详尽。特别对于接口，要描述清楚功能、实现及参数；
2.使用模块化方法，编码低耦合、高内聚；
3.为集成测试与系统联调准备调测开关及相应打印函数，并且要有详细的说明；
4.为单元测试选择恰当的测试点，并仔细构造测试代码、测试用例，同时给出明确的注释说明。测试代码部分应作为（模块中的）一个子模块，以方便测试代码在模块中的安装与拆卸（通过调测开关）；
5.使用断言来发现软件问题，提高代码可测试性；
6.用断言来检查程序正常运行时不应发生但在调测时有可能发生的非法情况；
7.为测试自动化工具提供所需要的特定“钩子（hook）”；
8.对于每个功能，提供访问、修改“状态”变量的接口，包括提供查询、修改上层软件、软硬件接口、底层硬件状态的接口及打印；
9.提供查询系统状态的接口。比如内存使用、程序使用进程数等；
10.对于测试因为环境等因素而可能无法测试的功能，提供接口模拟软件实现该功能的过程；
11.对于修改功能，提供修改功能参数单位的接口，以便于进行如软件性能等的测试；
12.出错及异常处理保存记录，记录具有详细的属性，并且格式统一、意义明确；
13.在程序异常时，除了保留日志，还需要提供观察、恢复的外部方法；
14.对全局变量、特殊结构，提供查询的方法。【文章来源：文斯测试技术研究中心 http://blog.csdn.net/vincetest】
3.3 可测试性调试与定位
1.对于程序中所涉及到的变量尽可能的在调试过程中可以查询及修改；
2.在整个软件系统执行过程中为每个关键业务或相对独立的业务设定一个调试点，便于系统集成和问题范围的定位；
3.在设定好的调试点处对处理的业务输出数据和全局数据进行可视化输出，便于测试结果的分析。【文章来源：文斯测试技术研究中心 http://blog.csdn.net/vincetest】
3.4 测试所需文档
1.需求规格说明书
2.概要设计说明书
3.详细设计说明书
4.系统功能清单
5.系统运行环境搭建指导书
6.系统操作指导书来源:http://blog.csdn.net/vincetest【文章来源：文斯测试技术研究中心 http://blog.csdn.net/vincetest
-
如何评估测试工作量
2008-7-16
-
测试工作量统计新方法
2008-7-16
最近老大让我做测试计划，改了N次，心里还没底，晕死！
发现一篇好东东，相当有用，特别是对于测试组长和测试经理。
偶看不懂CMMI里的度量呀
测试工作量统计新方法
■ 沈雪芳
软件测试作为软件生命周期中不可或缺的重要环节，正在受到越来越多的重视。然而，在实际项目测试工作中却存在一个突出的问题，就是测试工作量的统计问题。如何统计更科学、更准确，本文作者在实际工作中进行了摸索和尝试。
虽然，目前测试工作越来越受到企业的重视，已形成规模，参与测试工作的人越来越多，投入也越来越大。但与之不协调的是没有一个配套的、较为合理的工作量统计方法。原有的测试工作量计算方法，一般是把测试人员进入项目的时间与进入项目的人员数量相乘，得到项目测试的工作量。该计算方法由于计算方便，容易操作，深受众多项目的推崇。
但是，随着测试在项目的重要性的加深，测试工作分工日益细化，测试资源强调有效重用，测试团队协作越来越强，使用这种方法已经不能满足测试工作量计算的需要了：上级领导不了解整个测试团队资源的使用情况；测试团队负责人难于对项目测试任务实际执行过程产生的工作量、成本进行跟踪;项目组在考核绩效时，遗漏了部分测试人员的工作量。
所以，在项目测试领域急需一种新的工作量统计方法。笔者将这方面的一些实践进行了总结，供读者朋友参考。
其基本思路如下：首先就任务类型的设置要达成一致；其次从每日的工作量收集开始，将测试任务按照一定的类别进行分类；然后将工作量数据按照不同的需求进行统计，得出不同的统计表;最后对这些统计表的数据进行分析，得出相应的结论。
设置任务类型
设置任务类型，是每日工作量数据录入的前提。任务类型需要在整个测试团队内达成一致，这样大家有了相同的标准，得出的数据才具有统计的意义。本文以某公司的项目测试为例进行介绍，其任务类型如表1所示。
这里提到的测试任务类型，在实践中会根据项目实际需要进行调整。例如，新增“测试工具学习”任务类型等。
另外，在表1所示的任务类型中，有一项比较灵活的任务类型——沟通。有的团队认为沟通都是有目的、有目标的，是一个为完成具体测试任务所进行的中间活动，所以他们把沟通作为具体测试任务的一部分。也就是说，对于这样的团队，他们没有“沟通”这个任务类型。有的团队则认为将沟通的内容很难划清界限，为避免测试人员填写工作量时发生混淆，所以，将“沟通”作为独立的任务类型。笔者认为这属于任务类型定义问题，测试团队可以根据已经存在的约定俗成进行设置，只要在整个团队内达成一致就可以的。
表1 测试任务类型分类记录工作量基础数据
这项工作由团队成员根据当天的工作任务完成情况进行记录。它是后续工作量统计的基础，所以要保证这项基础数据收集的准确性，切不可应付了事，最好能在当天下班前填写好当天工作量分配情况。
坚持记录时间需要很强的自我约束能力，所以每天填写工作量记录需要一定的坚持力。在填写工作量记录时，需要为每个任务选择相应的任务类型，填写工作任务持续时间。工作任务持续时间最好不超过4个小时，这是为了避免填写的任务过粗，不利于发现工作过程中的问题。
及时记录、数据准确，是这个环节工作的原则。本例中某公司使用的工作量记录表格如表2所示。
统计人力占用情况
这项工作主要统计测试团队所有成员在各个项目中的投入情况，或者说是项目对测试人员的人力占用情况，每周统计一次。通过对人力占用情况进行统计，测试团队负责人可以得到一份人力占用表。这份人力占用表的主要用途的有三个：
● 供测试团队负责人和上级领导使用，方便他们了解测试团队对项目的支持情况及项目占用测试资源的情况。
● 让上级领导间接了解测试团队的人员饱和度。如果测试团队负责人要申请新增测试资源时，将整个团队的历史人力占用表作为数据证据提供给上级领导，可以增强申请的说服力。
● 提供给项目经理参考。避免项目经理在进行项目人员绩效考核时，遗漏了部分测试人员的工作量。
这项人力占用情况统计工作，笔者建议使用者在每周末进行。统计结束后，测试团队负责人将统计结果作为测试团队工作汇报的一部分提交上级领导。本例中，某公司在某一周测试团队人力占用情况如表2所示。
表2 工作量记录表格在本文的例子里，测试团队在项目1一共投入了B、C、D三个人，B、C成员是100%资源投入。因为项目后续工作安排未知，而B、C成员又属于项目1核心测试人员，因此这两名成员的退出时间未知。另外一个测试成员D因为不属于项目1的核心测试成员，所以他参与2个项目。同时因为项目2规模较小，所以成员D在项目2中投入20%的资源，在项目1中投入80%的资源。考虑到公司在2005年3月将要启动一个新项目，所以，经过和项目1的项目经理协商后达成一致，计划成员D在2005年2月退出该项目，这样他在2005年3月将投入新启动的项目。
通过及时更新、跟踪这张表的数据，可以对团队内测试人员的工作情况心中有数，并可根据公司业务发展、部门建设、人员发展需要，合理安排团队成员的工作。
表3 测试团队人力占用表统计项目测试工作量投入情况
这项统计工作是在每日工作量统计的基础上整理得到的。每周测试团队成员提交工作汇报时，会将本周的工作量数据整理后一起提交。测试团队负责人定期（每周或半个月）对团队成员提交的数据进行汇总，并整理到项目工作量投入表中。这就解决了在实际测试执行过程中，测试人员无法对测试工作量进行跟踪的问题。
笔者曾经碰到一个项目，该项目的测试计划只安排了1.5人日的工作量，但是实际上该项目在测试计划上总共投入了9人日的工作量。经过分析，笔者发现是两个原因导致这个问题的发生：一是测试人员在填写每日工作量记录时，部分任务的“任务类型”选错了；二是该项目测试组长在估算测试工作量时，没有考虑到实际测试执行过程中也需要进行测试计划工作，如每次测试执行的计划、实际工作过程中的计划更新工作等。通过这次分析后，该项目的测试工作量没有再发生这么大的偏差了（偏差率＝（计划值－实际值）/计划值×100%）。所以说，测试工作量的统计、分析可以帮助使用者发现一些问题，并改进使用者的工作。某公司某一项目的测试团队工作量投入情况如表4所示。
表4 某项目测试工作量统计表通过这张统计表格，可以很清楚地了解某个人的工作量投入情况，及具体测试任务使用的工作量情况。
汇总项目测试数据
在项目关闭时，测试团队负责人把整个项目测试过程中产生的数据以及项目基础数据进行汇总。测试过程中产生的数据包括：测试工作量、测试投入成本，它的数据来源于表四；项目基础数据包括：项目规模、项目总成本、项目总工作量，这些数据是向项目经理获取的。这里提到的测试成本，是把每个测试人员的人力成本系数和工作量数据相乘得到的。所有相关人可以通过这张统计表了解项目组中测试占开发总工作量的比例，以及项目组用在测试上的开销情况。这项工作是测试团队资产沉淀的很重要的一项工作。主要用途是：从项目角度对项目测试整体情况进行分析；把测试团队所承接测试的项目进行纵向对比，总结共性，发现问题。
例如，可以对这些项目的测试数据进行分析，得出测试工作量估算公式。再如，笔者曾经通过数据的对比，发现测试文档编写工作量占整个测试工作量的比例较大。通过进一步分析，发现测试用例的维护占用了测试设计很大一部分的工作量，从而应考虑在团队内改进测试用例管理方法。某公司两个项目的测试数据如表5所示。
表5 某测试团队测试项目资产库——测试数据参考项目背景，笔者对几个项目的测试数据进行分析后，得到了项目测试总人力成本的估算公式：测试总人力成本＝20%×项目总人力成本。
另外，通过把几个项目的各项测试类型所花费的工作量进行对比分析后，笔者得出各项测试任务的工作量相对于测试总工作量的分配比例。对于后续的项目，项目测试组长可以参考这个分配比例进行测试工作量的估算。
当然，上面介绍的估算公式和工作量比例，只是适用于笔者所在的测试团队。不同测试团队、项目组、公司组织情况都不一样，这里介绍这个例子，目的只是说明测试工作量统计的一个用途。
表6 某测试团队各项测试任务的工作量比例 总结
测试工作量的统计，是整个测试团队管理的基础。测试团队的管理、决策、策划等需要数据的支持，即用数据说话，所以，数据的收集、统计是很重要的。有了这些数据之后，我们就可以将它应用到绩效考核和项目成本核算上。
在本文中,笔者主要介绍的是测试团队的工作量统计，但实际上这些方法不仅适用于测试团队，也适用于个人、项目团队或者整个公司组织。实施时只需要调整“任务类型”等与测试有关的属性，并做一定的扩展即可。
本文使用的表格，都是在Excel中建立和维护的。在团队规模不是很大时，或者处于试用初期时，使用很方便、实施成本也低。但是如果团队规模较大，团队成员比较多，数据量较大的话，这种手工方式就显得有些力不从心了。读者可以自行开发一个工作量管理系统，使用数据库的方式来记录、分析这些数据。在使用初期可先实现每日工作量数据的录入，以及针对个人、项目、任务类型等属性的统计分析功能即可。
-
转贴：LR录制方式的区别（URL和HTML）
2007-8-24
-
性能测试，想说爱你不容易
2007-8-20
-
测试用例的设计(转贴)
2007-8-14
-
新的生活就要开始了
2007-6-29
-
JAVA?JAVA!
2007-6-22
记得04年学了一段时间JAVA,当时就没搞明白.
当现在不得不再学的时候,那个地方依然是个死角,JAVA的运行环境,JAVA虚拟机.....晕
致于数据类型\类等那些东西,都可以继续学习,可是这个运行环境
-
琪琪落泪了
2007-6-20
