我混迹在51，51却没有我的传说....

发布新日志

  • 测试管理工具比较

    2011-07-28 15:36:52

    测试管理工具很多，对比下其中的几个工具的优劣，有熟悉的可以留言发表意见：

    QC:

        目前我认为已经相当不错的测试管理工具了，从测试需求--测试计划--测试用例--软件缺陷，实现了前后管理的生命周期管理，统计分析功能非常强大，配合office使用，非常方便易用，商业价格太贵，普遍用破解。

    JIRA：

    缺陷管理方面的思路与QC相反，QC是流程驱动，JIRA是人为驱动，你要指定这个缺陷给谁来修改，前提是你知道应该谁来改，不知道的情况下，一般指给开发经理，如此驱动带来多次指派的重复劳动缺陷，用的不多，不过多评价。

    Bugzilla：

    开源工具，对缺陷的管理不错，属于开源主流，与bugfree差不多，用的不多，相对QC体系性稍差

    禅道：

    严格意义上讲，禅道不是一个专业的测试管理工具，而是一个项目管理工具，只是其中集成了项目中的测试环节的功能，总体使用效果不佳，需要深度的二次开发，测试用例与需求和缺陷无法形成体系，执行用例时不能直接提缺陷，每次要单独在缺陷里描述相应的复现步骤，导出和导入功能需要二次开发，统计功能一般。

    个人比较喜欢QC，现在已经是全生命周期管理软件了，有时间要好好研究一下。

    查看(787) 评论(0) 收藏 分享 管理

  • 测试职业发展方向

    2011-07-28 11:15:08

    测试职业发展方向：

    相信很多测试人员进入测试行业之初的一段时间内，都会有这样的迷茫，我将来能做什么？我的未来什么样子？整天被开发人员鄙视，我该如何提升自己？我这一辈子就整天做这样的事情吗？将来的路该怎么走？带着这些疑问，我给大家一些基本的意见，对软件测试的职业发展方向进行以下简单的介绍，希望对大家有用：

    1、测试业务专家：测试工作中，不同的公司针对不同的行业，不同的行业中有不同的业务需求，长时间的对一个行业的测试积累，必然会总结和学习到该行业的很多业务规则和知识，如此的长期积累下去，便可以成为一个行业专家，比如财务行业，测试做时间长了，可以做需求，更高级的可以做咨询；

    2、测试技术专家：软件测试中除了手工的功能测试，还有自动化和性能，这两方面都需要技术积累，自动化测试有工具，有框架，有相应的模式；性能测试有经验积累，有技术积累，有测试经验积累，适合做技术的同学可以向此方向发展，成为一个资深的测试技术专家；

    3、测试管理方向：测试不仅仅是一个重复的工作，同时其中也存在管理和体系的问题，学习和总结出适合公司的测试体系和管理方式，同样是需要时间的积累，总结和学习的，日常工作过程中不仅仅是关注于具体的测试工作，时常的学习和总结所处环境中的管理模式和测试体系，有何优劣，总结，提炼，再总结再提炼，形成一套自己的管理思路和体系将来可以成为一个测试方面的管理者；

    大概的方向如此，希望能够对一些迷茫的童鞋有所帮助，希望你关注我，有交流需要的加我的qq群52533417，非诚勿扰

    查看(418) 评论(3) 收藏 分享 管理

  • 关于敏捷开发模式下的测试如何开展

    2011-07-28 11:00:15

    1、敏捷开发模型：

    Scrum模型的一个显著特点就是响应变化，它能够尽快地响应变化。

    2、如何开展测试：

    敏捷模式下的测试要与开发工作开展模式结合，让开发反过来也配合测试，开发的工作可以合力完成一部分后交给测试，

    此时，测试既有任务可以开展，开发又能继续接下来的新任务，而不是开发集中开发，测试集中测试，这种模式下已经

    脱离了敏捷的概念，开发要敏捷，测试也要敏捷；

    查看(549) 评论(4) 收藏 分享 管理

  • 需求文档规范的重要性

    2009-06-16 19:54:37

     

    在一个软件项目的生产过程中，最关键的阶段就是需求的确定。

    概要设计的依据是需求文档，详细设计的依据也将是需求文档，

    测试大纲的结构级次也是依据需求文档框架结构而提炼产生的，

    测试案例编写依据测试大纲的结构和功能点列表而设计出来的，

    因此需求文档成了整个项目从始至终的重要的依据性文档标准，

    因此其重要性自然不言而喻。下面说说需求文档的在项目中的重要性！

    1、高质量的需求文档切断bug的来源

    在需求文档编写过程中如果质量控制不到位，自然会产生最原始的bug

    设计人员依据不明确的需求文档设计出了不准确的概要设计和物理模型

    开发人员依据已经存在bug的概要设计产生程序代码，系统提交测试的

    时候这些隐含的bug已经从需求一直流转到了测试人员的面前成为测试

    人员的劳动成果但是这虽然给测试人员带来了工作成果和成就感但是这

    对一个项目来讲却是巨大的损失，本应该在需求文档产生是就能避免的

    东西尽量控制在其最原始的状态而不是放任自流下去，因此由此看来文

    档测试的重要性就体现出来了，很多企业并不重视对文档的测试和检查

    从而使这些问题逐渐逐步的被放大，同时放大了修复问题的代价，给项

    目带来损失，因此，测试要在需求文档编写产生时介入，同步测试需求

    文档中存在的遗漏和不准确的描述直接将一些输入控制，界面标准等问

    题扼杀在摇篮之中，付出了最小的代价产生了最好的效果，避免了需求

    变更，就避免了损失的放大，为项目和公司节约了成本，同时也能提高

    产品的质量，一举多得！

    2、需求文档编写的要求

    为了节约成本必须加强控制，控制好需求文档编规范的高标准、高要求

    编写的质量和规范性以及可读性，这对需求人员的要求就相对提高了，不

    仅仅是懂业务和会用word这么简单了，要能将需求文档编写成为设计人

    员和开发人员的思维角度读懂的文档，不仅仅是简单的规则描述是问题了

    当需求文档编写符合规范，概要设计上就更加清晰流畅，代码编写上就能

    控制的更加规范和标准，提高了代码生产效率，降低了低级bug的存活率

    从而提高了系统的质量。一旦需求文档编写的不好导致了连锁反应最终到

    需求变更，需求变更是一个项目最难承受的代价，当整个系统在多人合作

    的情况下生产出来，此时需求文档的一点小小变化都可能会导致整个系统

    发生巨大的改变和调整，由此需要付出的代价是不可估量的，损失是惨重

    的，也是开发、测试、维护所最不愿意接受和面对的，控制好需求的编写

    可以达到事半功倍的效果，高水平的测试团队可以从标准的需求文档中预

    估出系统的缺陷率，预估出要编写的测试案例数，从而为后期的测试工作

    带来了巨大的前置信息，提高了测试工作的工作效率，高质量的需求文档

    编写有百利而无一害，需要得到重视！

    总结：需求文档编写的高质量和测试人员介入文档测试对于一个项目来说

    都是非常重要的环节，需要加强控制和规范，为公司带来效益，货真价实！

    -------------------------------------------------------------

    NBA总决赛结束了，我所钟爱的LAKERS夺冠了，我的偶像KOBE获得了MVP奖杯~~

    23--24

    幸福

     

     

    查看(1580) 评论(1) 收藏 分享 管理

  • 项目测试工作经验总结

    2009-06-12 19:57:57

    好久没有来更新我的空间了，面对51感到十分的愧疚，

    甚至没有太多的时间浏览，希望今后能有多点的时间来学习吧！

    近期一直在做一个项目的测试工作，时间紧任务重是这个项目的特点，

    经过一段时间的测试计划和组织，总结了一些经验，记录之：

    1、在测试计划的制定过程中一定要充分考虑到测试环境的因素：

    测试计划的编写是根据项目经验和实际的项目操作过程，

    通过对项目的大小，功能点的多少，菜单的数目和页面的复杂情况，

    最终估计出总体的工作量，在具体分配和计划的时候，

    不能完全只考虑到工作量的100%分配和完成，

    因为按开发计划出来的东西，在工期十分紧张的情况下是有偏差的

    如果按照客户的最后期限为标准开展开发和测试工作的计划

    那么在这个过程中就一定要考虑到测试环境的稳定性和提交代码的可测性

    实际工作过程中，按开发计划出来的代码从一定程度上来讲

    是存在很多bug，甚至无法在测试环境下运行，

    更甚至就在代码build过程中就出现问题

    因此在制定测试计划和开展工作过程中一定要充分考虑到测试环境的影响程度！

    2、测试工程师的个人情况和工作稳定程度

    在编制测试计划的过程中，不能不考虑测试工程师的个人情况

    从业务能力，操作能力，沟通能力，工作责任心，等各个方面

    对项目组测试成员进行一下整体的评估和分类

    同时要针对个人的不同情况考虑到工作过程中出现的出勤问题

    比如员工中存在婚假对象，产假对象等等，在编制计划时要增加预估百分比

    以弥补测试周期中出现的人员异动，从而控制好风险的程度。

    3、测试计划的制定要有开发计划的按期完成作为前提：

    测试计划制定的再好，如果没有开发计划的按期完成做为保证

    一切都将变为空谈，没有任何的实际意义，估计出来的工作量没有任何价值

    就像不同环境下测试来的性能指标一样，几乎完全没有参考价值

    开发计划的保障成为测试工作开展的前提，否则将导致测试工作的延期

    最终导致风险的扩大化，对整个项目产生不可预计的影响。

    4、测试过程中要预留出修改bug的时间：

    在测试过程中，由于项目的性质和客户的要求不同

    最终提供测试的程序可能由于工期的保障最终出现大量bug

    严重的情况就是bug直接导致系统无法继续测试下去

    为了继续测试只能等待bug的修复，而此时开发人员甚至没有时间关注bug

    大部分时间都在赶时间编写代码

    一旦出现此类情况，必须及时提出对策解决

    避免开发忙的不可开交，测试闲的无所事事

    5、测试案例的编写到位和后期维护工作的重要性

    测试初期，从测试计划开始，到测试任务具体执行

    主要时间不是在测试系统，而是在花费大量时间编写高质量的用例

    如果初期没有对测试用例的编写规则进行详细的规划和约束

    最终不同测试人员编写出来的案例千奇百怪，千差万别

    在测试执行过程中影响了测试质量的控制

    初期一定要对案例质量进行控制，花费大量的人力物力去评审和返工

    否则前面准备不好，后期必然出现测试工作忙，案例编写质量差

    执行人员执行起来发现不了问题，但是又没有更多的资源去补充和修改

    好的猎手一定要有好的打猎工具，正如我的同学在打算考研之后

    第一件事就是准备好一切考研期间需要的东西，包括很高级的钢笔和墨水！

    暂时先总结到这吧，有时间继续~~

    这几天NBA的总决赛打的如火如荼，还是和大家分享一下我喜爱的湖人队吧~~

     

    查看(487) 评论(0) 收藏 分享 管理

  • 测试案例评审

    2009-05-06 23:41:52

    在日常的测试案例评审过程中应该注意的事项简单总结

    软件质量检查措施：

    （1）事先把检查的主要内容制成一张表，使检查活动集中在主要问题上。

    （2）只评审工作，不评审开发者。评审的气氛应该是融洽的。存在的错误应该被有礼貌地指出来，任何人的意见都不应被阻挠或小看。

    （3）建立一个议事日程并遵循它。检查过程不能放任自由，必须排照既定的方向和日程进行。

    （4）不要化太多的时间争论和辩驳。

    （5）说清楚问题所在，但不要企图当场解决所有问题。

    （6）对检查人员进行适当的培训。

    查看(455) 评论(0) 收藏 分享 管理

  • 性能测试分析

    2009-01-15 14:43:03

     


    分析原则：
        <1> 具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点）
        <2> 查找瓶颈时按以下顺序，由易到难。
        服务器硬件瓶颈-〉网络瓶颈（对局域网，可以不考虑）-〉服务器操作系统瓶颈（参数配置）-〉中间件瓶颈(参数配置，数据库，web服务器等）-〉应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）
        注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。

         <3>分段排除法 很有效。
         <4>分析的信息来源：
            1 根据场景运行过程中的错误提示信息
            2 根据测试结果收集到的监控指标数据

    一．错误提示分析

    分析实例：
    1 •Error: Failed to connect to server "10.10.10.30:8080": [10060] Connection
       •Error: timed out Error: Server "10.10.10.30" has shut down the connection prematurely

      分析：
    •A、应用服务死掉。
       （小用户时：程序上的问题。程序上处理数据库的问题）
    •B、应用服务没有死
       （应用服务参数设置问题）
        例：在许多客户端连接Weblogic应用服务器被拒绝，而在服务器端没有错误显示，则有可能是Weblogic中的server元素的AcceptBacklog属性值设得过低。如果连接时收到connection refused消息，说明应提高该值，每次增加25％
    •C、数据库的连接
       (1、在应用服务的性能参数可能太小了 2、数据库启动的最大连接数（跟硬件的内存有关）)

    2  Error: Page download timeout (120 seconds) has expired

    分析：
    可能是以下原因造成
    •A、应用服务参数设置太大导致服务器的瓶颈
    •B、页面中图片太多
    •C、在程序处理表的时候检查字段太大多

    二．监控指标数据分析

    1．最大并发用户数：
    应用系统在当前环境（硬件环境、网络环境、软件环境（参数配置））下能承受的最大并发用户数。
    在方案运行中，如果出现了大于3个用户的业务操作失败，或出现了服务器shutdown的情况，则说明在当前环境下，系统承受不了当前并发用户的负载压力，那么最大并发用户数就是前一个没有出现这种现象的并发用户数。
    如果测得的最大并发用户数到达了性能要求，且各服务器资源情况良好，业务操作响应时间也达到了用户要求，那么OK。否则，再根据各服务器的资源情况和业务操作响应时间进一步分析原因所在。

    2．业务操作响应时间：
    • 分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始。使用“事务性能摘要”图，可以确定在方案执行期间响应时间过长的事务。
    • 细分事务并分析每个页面组件的性能。查看过长的事务响应时间是由哪些页面组件引起的？问题是否与网络或服务器有关？
    • 如果服务器耗时过长，请使用相应的服务器图确定有问题的服务器度量并查明服务器性能下降的原因。如果网络耗时过长，请使用“网络监视器”图确定导致性能瓶颈的网络问题
    3．服务器资源监控指标：
    内存：
        1 UNIX资源监控中指标内存页交换速率（Paging rate），如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。

        2 Windows资源监控中，如果Process\Private Bytes计数器和Process\Working Set计数器的值在长时间内持续升高，同时Memory\Available bytes计数器的值持续降低，则很可能存在内存泄漏。

    内存资源成为系统性能的瓶颈的征兆:
        很高的换页率(high pageout rate);
        进程进入不活动状态;
        交换区所有磁盘的活动次数可高;
        可高的全局系统CPU利用率;
        内存不够出错(out of memory errors)

    处理器：
        1 UNIX资源监控（Windows操作系统同理）中指标CPU占用率（CPU utilization），如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。如果服务器专用于SQL Server,可接受的最大上限是80-85%
        合理使用的范围在60%至70%。
        2 Windows资源监控中，如果System\Processor Queue Length大于2，而处理器利用率（Processor Time）一直很低，则存在着处理器阻塞。

    CPU资源成为系统性能的瓶颈的征兆:   
         很慢的响应时间(slow response time)
         CPU空闲时间为零(zero percent idle CPU)
         过高的用户占用CPU时间(high percent user CPU)
         过高的系统占用CPU时间(high percent system CPU)
        长时间的有很长的运行进程队列(large run queue size sustained over time)

    磁盘I/O：
        1 UNIX资源监控（Windows操作系统同理）中指标磁盘交换率（Disk rate），如果该参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统。
        2 Windows资源监控中，如果 Disk Time和Avg.Disk Queue Length的值很高，而Page Reads/sec页面读取操作速率很低，则可能存在磁盘瓶径。

    I/O资源成为系统性能的瓶颈的征兆 :
         过高的磁盘利用率(high disk utilization)
        太长的磁盘等待队列(large disk queue length)
        等待磁盘I/O的时间所占的百分率太高(large percentage of time waiting for disk I/O)
        太高的物理I/O速率:large physical I/O rate(not sufficient in itself)
        过低的缓存命中率(low buffer cache hit ratio(not sufficient in itself))
        太长的运行进程队列，但CPU却空闲(large run queue with idle CPU)

    4．数据库服务器：
    SQL Server数据库：
        1 SQLServer资源监控中指标缓存点击率（Cache Hit Ratio），该值越高越好。如果持续低于80%，应考虑增加内存。
        2 如果Full Scans/sec（全表扫描/秒）计数器显示的值比1或2高，则应分析你的查询以确定是否确实需要全表扫描，以及SQL查询是否可以被优化。
        3 Number of Deadlocks/sec(死锁的数量/秒)：死锁对应用程序的可伸缩性非常有害，并且会导致恶劣的用户体验。该计数器的值必须为0。
       4 Lock Requests/sec(锁请求/秒)，通过优化查询来减少读取次数，可以减少该计数器的值。

    Oracle数据库：
      1 如果自由内存接近于0而且库快存或数据字典快存的命中率小于0.90，那么需要增加SHARED_POOL_SIZE的大小。
        快存（共享SQL区）和数据字典快存的命中率：
       select(sum(pins-reloads))/sum(pins) from v$librarycache;
        select(sum(gets-getmisses))/sum(gets) from v$rowcache;
        自由内存：    select * from v$sgastat where name=’free memory’;
    2 如果数据的缓存命中率小于0.90，那么需要加大DB_BLOCK_BUFFERS参数的值（单位：块）。
      缓冲区高速缓存命中率：
        select name,value from v$sysstat where name in ('db block gets’,
        'consistent gets','physical reads') ;
       
        Hit Ratio = 1-(physical reads / ( db block gets + consistent gets))
    3 如果日志缓冲区申请的值较大，则应加大LOG_BUFFER参数的值。
        日志缓冲区的申请情况 ：
         select name,value from v$sysstat where name = 'redo log space requests' ;
    4 如果内存排序命中率小于0.95，则应加大SORT_AREA_SIZE以避免磁盘排序 。
       内存排序命中率 ：
         select round((100*b.value)/decode((a.value+b.value), 0, 1, (a.value+b.value)), 2)from v$sysstat a, v$sysstat b where a.name='sorts (disk)' and b.name='sorts (memory)' 

    查看(735) 评论(0) 收藏 分享 管理

  • Subversion快速入门教程

    2008-12-30 22:24:04Digest 1

     

    如何快速建立Subversion服务器，并且在项目中使用起来，这是大家最关心的问题，与CVS相比，Subversion有更多的选择，也更加的容易，几个命令就可以建立一套服务器环境，可以使用起来，这里配套有教程。


        本文是使用Subversion最快速的教程，在最短的时间里帮助您建立起一套可用的服务器环境，只需略加调整就可以应用到实际项目当中。


        本教程分为以下几个部门，不仅仅是快速入门，最后我们还有一些高级功能的说明，为了说明简单，教程是在windows下使用的方式，以方便资源有限的项目使用，对于UNIX环境下，区别并不大。

     

    1. 软件下载
    2. 服务器和客户端安装
    3. 建立版本库（Repository）
    4. 配置用户和权限
    5. 运行独立服务器
    6. 初始化导入
    7. 基本客户端操作

    1，软件下载

    • 下载Subversion服务器程序。

        到官方网站 的下载二进制安装文件，来到二进制包下载部分 ，找到 Windows NT, 2000, XP and 2003部分，然后选择"the same directory"，这样我们可以看到许多下载的内容，目前可以下载svn-1.3.0-setup.exe。

    • 下载Subversion的Windows客户端TortoiseSVN。

        TortoiseSVN是扩展Windows Shell的一套工具，可以看作Windows资源管理器的插件，安装之后Windows就可以识别Subversion的工作目录。


        官方网站是TortoiseSVN，下载方式和前面的svn服务器类似，在Download页面的我们选择Official version for Win2k/XP or higher的版本，然后在sourceforge的下载页面选择目前的最高稳定版本的安装文件TortoiseSVN-1.3.2.5840-svn-1.3.0.msi，还可以sourceforge的语言下载页面中，下载简体中文语言包。


    2    ，服务器和客户端安装

     

    • 服务器安装，直接运行svn-1.3.0-setup.exe，根据提示安装即可，这样我们就有了一套服务器可以运行的环境。
    • 安装TortoiseSVN，同样直接运行TortoiseSVN-1.3.2.5840-svn-1.3.0.msi按照提示安装即可，不过最后完成后会提示是否重启，其实重启只是使svn工作拷贝在windows中的特殊样式生效，与所有的实际功能无关，这里为了立刻看到好的效果，还是重新启动机器。

    3，建立版本库（Repository）


        运行Subversion服务器需要首先要建立一个版本库（Repository），可以看作服务器上存放数据的数据库，在安装了Subversion服务器之后，可以直接运行，如：

    svnadmin create E:\svndemo\repository
    就会在目录E:\svndemo\repository下创建一个版本库。
    我们也可以使用TortoiseSVN图形化的完成这一步：
    在目录E:\svndemo\repository下"右键->TortoiseSVN->Create Repository here...“， 然后可以选择版本库模式， 这里使用默认即可， 然后就创建了一系列目录和文件。

     

    4，配置用户和权限


    来到E:\svndemo\repository\conf目录，修改svnserve.conf：

    # [general]
    # password-db = passwd

    改为：

    [general]
    password-db = passwd

    然后修改同目录的passwd文件，去掉下面三行的注释：

    # [users]
    # harry = harryssecret
    # sally = sallyssecret

    最后变成：

    [users]
    harry = harryssecret
    sally = sallyssecret

    疑问：　用户是直接在这里建成吗？

    疑问2：为什么我机上并没有passwd文件？


    5    ，运行独立服务器

    在任意目录下运行：

    svnserve -d -r E:\svndemo\repository

    我们的服务器程序就已经启动了。

    疑问：独立的服务器名称是什么，我都没有使用，直接在客户端创建一个库，直接操作，都行得通，默认的用户是操作系统用户。


    6    ，初始化导入

    来到我们想要导入的项目根目录，在这个例子里是E:\svndemo\initproject，目录下有一个readme.txt文件：

    1. 右键->TortoiseSVN->Import...
    2. URL of repository输入“svn://localhost/trunk”
    3. ok

    完成之后目录没有任何变化，如果没有报错，数据就已经全部导入到了我们刚才定义的版本库中。


    7    ，基本客户端操作

    取出版本库到一个工作拷贝：

    来到任意空目录下，在本例中是E:\svndemo\wc1，运行右键->Checkout，在URL of repository中输入svn://localhost/trunk，这样我们就得到了一份工作拷贝。

    在工作拷贝中作出修改并提交：

    打开readme.txt，作出修改，然后右键->Commit...，这样我们就把修改提交到了版本库，我们可以运行。

    察看所作的修改：

    readme.txt上右键->TortoiseSVN->Show Log，这样我们就可以看到我们对这个文件所有的提交。在版本1上右键->Compare with working copy，我们可以比较工作拷贝的文件和版本1的区别。

     

     

    PS：2008年就要过去了，我很怀念，迎接美好的2009~~~加油！！！

     

     

     

     

     

    查看(626) 评论(0) 收藏 分享 管理

  • 测试管理技巧

    2008-12-23 21:27:40

     

    软件测试的主要工作过程是通过项目小组来分工的，在带领一个工作小组开展

    工作的过程中对组员的管理是有一定的技巧和哲学的，因为对于项目经理或者

    产品经理来讲，测试经理是管理整个测试过程的控制者和协调者，对于测试工

    程师来讲，测试经理是任务的分配者和资源的提供和协调者，在这个过程中就

    有很多的矛盾存在，任务重，时间紧，压力大，加班多，测试工作的进度控制

    困难，资源的协调，测试环境的保障等等因素都会给测试工作带来不小的困难

    和阻力，在这个过程中就要求我们测试经理做好这个协调者的工作，在我个人

    的工作过程中总结了一部分经验和大家分享：

     

    确保测试环境等资源的保障，协调好各个部门的配合，技术支持，数

    据库，环境维护等等各个相关部门的全力合作，保证测试工程师的工

    作环境稳定运行。

     

    任务计划明确，分工明确，确保各个测试工程师的工作量，使各个工

    程师的工作保持在一个同等的水平上，不产生分歧和不满

     

    定时组织开会总结各个测试工程师的工作所得，分享大家在不同的工

    作过程中的体会和经验，有助于拓宽思路，对今后的测试工作有很大

    的帮助

     

    定期带领测试工程师出去组织一些问题活动，使测试工程师在枯燥频

    繁的工作之余得到身心的放松，这样有助于增加上下级感情，提高测

    试工作效率

     

    为下属谋取更多的福利，作为一个中层领导者，必须维护下属的利益

    让下属意识到在你的带领下干活是有安全感的，至少是能得到一些福

    利的，避免怨声载道，抱怨声此起彼伏，不仅不利于组织工作的开展

    也影响了测试工作的效率和质量，测试工作经常出现赶进度加班的轻

    卡情况，在这种情况下要尽量能争取到一些福利，比如加班食品，带

    领团队共同进餐，下班后打车等等一系列的福利措施都是有助于测试

    工作的开展。

     

    以上是我的个人的一些工作经验总结，希望对大家有所帮助，总结的

    不全面，仅供参考。

     

     

     

     

    查看(653) 评论(0) 收藏 分享 管理

  • Excel表格中的Bug问题单导入TD方法介绍

    2008-12-14 11:41:24

        如果将bug问题单放在excel中进行管理，有时需要将问题单导入TD中，TD有插件支持此功能的实现，详细方法见下面的介绍：

    一、           操作步骤：

    1、首先访问td主页

     

    2、点击左上角的Add-Ins Page，跳转到该界面。

    3、在该界面点击More TestDirector Add-ins 跳转到新界面

    4、点击红色标示中的Microsoft Excel Add-in，跳转到新界面

     

    5、点击红色表示的Download Add-ins ，下载该插件并双击安装

     

    6、安装后打开Excel，点击【工具】--【宏】--【安全性】

     

    7、设置两个选项卡：安全性设置为中，勾选信任所有安装的加载项和模板，点击确定

     

    8、将excel中的各个列标题命名为TD中选中bug单上的标准字段，选中Excel表中的所要导入的问题单所在的行

     

    9、点击excel上的【工具】中的Export To TestDirector

     

    10、弹出窗口输入：TD地址/后点击Next。

     

    11、选择域和管理库后点击Next

     

    12、输入用户名和密码点击Next

     

    13、因为要导入的是问题单，因此选择DEFECTS后点击Next。

     

    14、选择一个匹配模板后点击Next

     

    15、弹出窗口左边栏中显示的是td中问题单上的各种属性，右边栏显示的是即将要与excel表格中的列对应的属性列表，选择【状态】点击右选按钮。

     

    16、Excel表中于TD中的【状态】相匹配的列是【A】，因此填写A后点击ok。

     

    17、依次将红色标注的选项和Td中的必输项对应完毕点击Next

     

    18、弹出导入成功提示界面后点击Finish。

     

    19、进入TD中查看导入的问题单

     

    注：

    1、附件只能单独添加，不能导入。

     

     

    查看(719) 评论(1) 收藏 分享 管理

  • [论坛] 用WORD导入TD requirement的方法

    2008-12-12 22:42:32

    用WORD导入TD requirement的方法

    第一步
    新建一个word文件，点击Open Requirement，这个是新建一个根节点的名称
    第二步
     
    设置审核状态标志
    一般是Not Reviewed


    第三步骤，就是添加对这个需求的描述了
    点击Descrīption，后面输入要描述的信息


    第四步骤：点击author

    这个是创建人字段

    第5步骤，
    点击录入个结束标志


     
    这个时候一个可以导入TD的Requirement就完成了

    效果图：


    进阶研究：嵌套设置
    以下是一个open和一个close
     （open requirement）
    ****
     （close requirement）


    ****是其中的内容，可以再设置一个open和close，形成嵌套
     
     （open requirement）
    ****
     （close requirement）

    效果图：

     

    以上过程就是将word中的需求导入到TD中的过程，前提是要安装插件Download Add-ins ，插件下载可以到TD的主页上下载。
     

    查看(1154) 评论(1) 收藏 分享 管理

Open Toolbar