测试旅程
shwonder
这个作者很懒,什么都没留下…
展开
-
通过测试过程驱动开发过程
测试工作做的久了,有时候会感觉测试工作比较被动。尤其是公司提出希望通过测试过程来推动研发过程的改进的想法之后,少量程序员的工作开始变得被动起来,有时会变成测试人员推着开发人员走。这种低效率在一段时间曾使测试人员相当沮丧。 先来分析目前整个研发过程中存在的问题: (1)对于小项目来说,需求常常不明确,并且测试人员往往是在拿到测试程序之后才真正接触到需求。此时,部分测试人员缺少对需原创 2010-04-25 16:49:00 · 790 阅读 · 0 评论 -
对偶尔出现的缺陷的处理
说这个话题之前,先假设有对缺陷评审的相对完善的机制,缺陷能够被准确的评估。再来说缺陷对处理问题。决定一个缺陷被如何处理,我想主要有两个方面的考虑,一是这个缺陷带来的系统风险的大小,另一个是对这个缺陷的修复成本的高低。在同一坐标轴上,这二者构成了四个象限区,如下图: 在第四象限,带来的风险越大并且修复成本越低的缺陷最能够引起重视,通常会被最及时处理;相反,在第二象限,带来的风原创 2010-04-24 22:49:00 · 1944 阅读 · 1 评论 -
维护好公共用例库
1.公共用例的定义: 所谓公共用例,简单理解是指能够被执行的多个不同的测试模块或测试功能点引用到的测试用例。2.编写公共用例的目的: 编制或维护公共用例的主要目的是为了提高测试用例的复用性,既提高测试用例的编写效率,降低用例库中用例的冗余度,便于对用例库对维护,又锻炼用例编写人员对需求对整体把握及抽取公共用例的能力。3.怎样编写功能公共用例: 对于B/S架构的WEB应用程序,包含原创 2010-04-24 22:03:00 · 3761 阅读 · 1 评论 -
妥善处理遗留缺陷
近几年来,在我们各时期的项目或产品中(包括生命周期超过五年的产品),在每个测试阶段都会多或少遗留有部分未被处理的缺陷,尤其是前几年尤为突出,近一年多来随着缺陷管理过程的加强,这种现象逐渐减少,但仍然时有出现。分析下来,产生这个问题大致有以下几个方面: (1)在项目收尾阶段,工作重点转移到了新版本的发布准备工作上,对于后期发现的风险很小的bug未引起项目经理或产品经理原创 2010-05-02 16:56:00 · 2481 阅读 · 0 评论 -
关于大数据量测试
既然提到这个话题,就一定有构建大量测试数据的需求——我们团队常把这一类测试叫做“大数据量测试”。从过去的项目情况来看,我们仅有大概20%项目需要这做方面的测试,且侧重于产品。扯远了。 构造海量数据来验证系统是否能正确执行,怎样才算正确的执行呢?定义一个清晰的、可测量的标准很重要。在进行大数据量测试之前,首先对测试需求做清晰的分析。我们一般很少从功能评价的角度进行这项测试,更多的原创 2010-05-02 00:00:00 · 10320 阅读 · 0 评论 -
没有需求,我们仍然要测试
早期,我们确实遇到了“烂”项目…… 我们的项目有时候是在非常态下进行的,这个非常态是指项目在没有文档化需求或需求以格式文档的形式描述,项目经理以口头的形式描述系统需求,并要求开发人员在短期内完成代码开发。接下来,开发人员在模棱两可的状态下别扭的编写代码,测试人员前期也无从介入,更可怕的是,积极性欠缺或责任心不够的项目经理不但前期没能与客户细致的沟通需求,在系统开发过程中,也没有进行有原创 2010-05-09 17:53:00 · 1100 阅读 · 0 评论