[转载]一个成功的软件测试项目经验

上一篇 / 下一篇  2010-06-02 16:32:31 / 个人分类:测试管理

测试如何尽早介入
        基于以前的测试经验,我们也越来越认识到测试人员应该尽早介入项目的重要性。简单地沿用测试V模型往往出现很多问题,特别是在项目进度拖延的情况下更是如此。如果测试人员一味固执地被要求严格案照V模型定义的标准来开展测试工作的话,则结果往往是在项目初期测试人员工作量极度不饱和(很多测试人员无所事事),而到了项目后期,一旦项目经理决定压缩测试时间,测试人员就不得不加班加点工作。
        但是,不少朋友实践“测试人员尽早介入”的效果并不理想,例如:

 1.测试人员参加项目前期的各种会议,会被当作“专职的”会议记录员。
 2. 测试人员参加代码评审,又不甚了解程序开发语言,浪费了时间其丢失了自信。

实际上,在项目开发初期,测试人员可以开展很多有价值的工作,例如:

1.评审需求文档的正确性和可测试性;根据需求文档整理和分析测试需求,清晰明确的测试需求事测试设计的基础。
2.在开发设计过程中,根据需求文档和设计文档进行测试设计,测试设计方案事测试用例的保证。
3.和项目团队中的集成组和开发组协商软件版本的编译方式和编译进度以及测试人员提取版本的方式和进度。
4.开发人员每天下午4:30前提交所有可编译的代码,每天晚上进行日编译;
5.开发经理根据版本稳定情况,每周提交测试申请单。
6.测试人员根据测试进度需要,提取测试版本。
7.提前准备测试环境,包括数据库环境,操作系统和Web一用服务器,以及复杂集群环境。
8.如果项目需要,还可以在此阶段研究一下自动测试工具,包括一些准备外包测试的工作。


根据产品的成熟度调整测试策略
       开发测试一盘棋。测试经理应该有大局观,保持测试策略总与开发的进展相一致,保证最终的软件成果最佳(而不是测试部发现Bug最多)。合理制定不同阶段的测试策略,会收到不错的效果。

产品开发期同情的测试
       要忍!要在这个能够发现大批Bug的黄金时段学会做减法。就现实而言,这个阶段的产品,大多难以满足系统测试的条件。如果进行追杀式的测试,无疑会加重开发人员的焦虑心情,甚至对测试产生逆反心理。
       另一方面,测试工作部应停滞,特别式不少测试人员对产品的了解还流于皮毛,抓紧时间进行“测试练兵”非常有必要。因此,,“产品开发期”的测试切忌生硬。其实,此时程序人员也知道产品还不成熟,所以要测试经理要告诉测试执行人员:

1.这个阶段不要提交界面简单错误和易用性方面的Bug(可以先记录下来到项目末期提交),否则会使开发人员质疑测试人员发现简单的Bug。
2.换位思考,了解此时开发人员最关心的功能是否能正确运行,多对基本功能进行测试。

产品成熟期积极的测试
        随着产品的不断成熟,主要功能的实现已经趋于完善,关键路径的测试已经不成问题。此时的程序员们,压力已经大大减轻,他们的工作重点也从“构建”转移到了 “修复Bug”,这个阶段程序员对于Bug的接受程度是最高的,对Bug的修复和反馈也非常积极。于是,此时的测试工作应对整个产品的细节和所有路径进行覆盖测试,保证测试的全面性,层层深入地测试产品值得测试的各个部分,尽可能多的发现并报告Bug。

产品稳定期多样的测试
       在这个阶段,可以尽情的向开发人员报告产品易用性和界面的Bug;可以充分发挥每个测试人员的想象力,根据以往的测试经验来搭建测试场景,构造测试数据;可以通过不同业务场景的不同操作,通过特殊的测试数据,以及相对复杂的集群测试环境来进行多样化测试。
       为什么?因为测试必须测试得更加深入,才能发现更深层次得Bug,于是多样性的测试、探索式得测试必不可少。

产品发布期谨慎的测试
        在临近产品发布的日子,包括测试在那的很多工作都变得谨慎起来:代码的提交权限受到了控制,只保留开发经理一个入口;测试的重点更加具有防御性,要仔细测试每个变更,还可以组织“结对测试”来增加测试的保障。

知己知彼,合力制胜
1. 获取程序员信任,及时沟通
         不要与被测程序的开发人员形成不必要的敌对关系。如果能与打交道的程序员共享信息,比如他们的计划、设计文档的早期草案合早期原型等,测试工作会更加有效。越早提出你的意见和反馈,了解程序员提交前完成的工作。

2.主动出击,提供服务
 
在测试前期,直接向开发人员提供服务;这不仅可以建立信任,而且还可以证明测试人员使能够与之合作的人。我们在项目过程中提供给开发人员的服务:
对工作流的运算逻辑构件进行了测试,方便了后期开发工作流客户端应用的使用。

对内部版本和原型进行测试。

对需求文档的可测试性进行评审。开发人员和测试人员一样,对模棱两可的要求很头疼,他们非常希望测试人员的介入。

帮助程序员建立测试环境,方便程序员进行测试。

3.耳目作用
在项目过程中,测试人员有机会能够发现很多存在的问题,比如:需求和设计以及开发的不一致性,项目计划中工作任务的缺失等等。测试人员不要仅局限与测试命令链本身,及时验证和发现项目环节中的问题。

测试项目能否成功,与整个项目组的精诚合作是密不可分的。测试人员是一种服务角色,要乐于接受这种角色,只有这样,才能得到被服务的人帮助和支持,以及认可。


TAG:

karen的个人空间 引用 删除 地下森林   /   2010-06-11 11:36:55
原帖由zhaolong4536于2010-06-08 16:57:41发表
看过之后获益匪浅!有一个问题想问:按楼主的意思(也许是我理解有误),将UI和易用性放在稳定期会不会额.

不好意思啊!先说明一点:此篇文章属转载,标题中已注明过,现在不记得转自哪里了。(当时觉得写得太好了,就转过来了,不小心忘了写地址了)

关于你说的这个问题,我在项目中也遇到过,个人感觉 UI和易用性放在稳定期还是一个不错的方法,就像文章中作者所说的,前期过于专注于细节,一方面打击了团队的积极性,另外也可能疏漏了测试点。 在测试的过程中,发现一般 UI 和易用性中的bug所占比例极高(也正是如此,开发会说测试没水平,只会找错别字之类的),这个放在后期做,可以先保证项目的可用性。在测试过程以及同事的讨论中,个人发现黑盒测试分层进行是一个不错的方法:
第一层:业务层,保证数据在系统中能流通并且是正确的。
第二层:功能层,保证系统的一些功能可以使用:如查询、修改等功能
第三层:UI和易用性,优化系统的用户体验
开心就好 引用 删除 zhaolong4536   /   2010-06-08 16:57:41
看过之后获益匪浅!有一个问题想问:按楼主的意思(也许是我理解有误),将UI和易用性放在稳定期会不会额外的增加项目负担?为什么不能放在项目成熟阶段呢
 

评分:0

我来说两句

Open Toolbar