51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 3215|回复: 3
打印 上一主题 下一主题

[原创] 有效测试的50条建议-需求阶段(1~5)

[复制链接]
  • TA的每日心情
    奋斗
    2018-8-7 16:39
  • 签到天数: 4 天

    连续签到: 1 天

    [LV.2]测试排长

    跳转到指定楼层
    1#
    发表于 2019-9-30 15:40:28 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
    有效测试的50条建议-需求阶段(1~5)
    一、简述
    测试应当参与到软件的整个生命周期中,远远早于代码的编写阶段。首先需要检验的就是需求文档,为此而衍生的组织活动——需求评审。在项目的早期,消除需求中的缺陷能够大大减小开发和测试返工的代价;

    二、建议
    第1条:测试人员及早介入
    1,缺陷预防是指在各种错误遗留到后续开发阶段之前,运用各种技术和过程,发现和避免这些错误;
    2,可测试的对于一个需求,测试人员可以设计一个过程来执行所测试的功能,如果这个结果是可预期的,并且能够通过编程实现和人工方式加以验证,则该需求具有可测性;

    测试人员需要彻底的了解产品,这不仅是需要了解软件的“输入输出”,还要了解相应的业务背景、现实中的客户应用场景、客户的应用习惯以及产品设计的思想主题等内容,这些都是在对需求说明书的思考学习过程中了解的。除此之外,根据系统的立意主旨,考虑系统的边界,防止本该别的系统的需求放到本系统中来。

    在充分了解产品主题及需求的基础上,进行测试计划、测试设计、测试过程、测试用例等设计时才会更加的出色;

    越早发现需求中的缺陷,我们付出的代价也就越小:


    第2条:验证需求
    1,质量测度标准:我们需要为每条需求建立一个质量测度标准,什么样的标准是满足需求的;
    举个例子:“我们的系统必须够快”
    那么系统怎么算快,不同的人有不同的理解,是响应速度在10秒内,还是说在2秒内,我们需要为够快定义一个可衡量的标准,这就需要需求的描述都精确;

    2,非功能性需求
    非功能性需求,并不赋予系统特殊的功能,但非功能性需求决定了技术方案的选择和存在风险区域,我们可以从以下几个方面来考虑:
    (1)正确性
    根据用户的需要进行检验,是否遵循一定的标准和规则?是否准确的反应了客户的需要,比如一些习惯操作等;
    (2)完整性
    主要是需要保证需求中不遗漏任何必须的元素。如:性能、安全性、可使用性、兼容性和可访问性等;
    (3)一致性
    验证产品需求有没有内部或外部的矛盾;如:需求定义了一个术语“观察者”,但是在上下文当中,可以理解出不同的意思,没有清晰的定义,这就为后来的开发和测试带来了不便;
    (4)可测性或可验证性
    保证测试一条需求的可能性,同时结果是可预期的。如果一个需求是不可测试的,我们必须注明它的风险,同时应尽可能调整需求使其可测;
    (5)可行性
    在给定的预算、时间、技术及其他资源内可实现;
    (6)必要性
    每条需求是否与系统有关,按照系统的既定目标去衡量,考虑系统的边界,这条需求对系统的价值是什么?没有这条需求是否会影响系统实现其目标?
    (7)优先级
    我们可以将需求存在时的正面影响和负面影响各分为5个等级,两方面去评分,总和越高则优先级越高,如此对需求做出取舍;
    (8)可追溯性
    每条需求是否能够找到所有引用它的部分?对于需求的变化,我们能否找到所有受这种变化影响的部分,包含:设计、编码、测试、联机帮助等等;

    第3条:需求就绪后立即涉及测试过程
    需求就绪后,我们应当立即开展测试过程的设计,在测试过程的设计中,发现需求中的错误和遗漏点,明确需求中元素的定义,验证需求的可测性;

    第4条:确保需求变化的传达
    如果需求变化没有及时同步到开发、测试,则可能导致测试过程中测试与开发的冲突,
    常见的原因有
    (1)变更的需求没有形成文档;
    (2)文档过期;
    (3)开发错误理解需求;
    需求变更应当经过组织的重新讨论,并评估变更带来的相关影响;
    同时我们可以借助一些需求管理工具,跟踪需求的变化,同时保证需求的可追溯;

    第5条:注意在现存系统上进行开发和测试
    在现实过程中,可能会遇到以一个软件版本为基线,开发新的软件的情况,但原有的系统没有任何文档,例如:A系统对接某个支付通道,现在公司打算整合所有的支付通道并形成支付服务,需要以A系统某个版本为基线去做新的开发。在这种情况下我们可遵循如下步骤:
    (1)选用确定的基线程序版本;
    我们必须选用某一个稳定的版本作为基线程序,并只把这个版本作为开发工作的起点,这样我们缺陷跟踪则更加直接,不用考虑基线程序的升级版本或修正版本;
    (2)把现有程序文档化;
    我们需要先梳理基线版本的业务逻辑并将其文档化。每个功能写一个段落,包括各种测试场景及预期的输出结果,并反映出系统的内部逻辑,这样我们可以在面对一个问题时确认其是否是缺陷,同时为将来的迭代版本提供参考依据;
    (3)对基线程序的更新也应做好文档的更新
    我们在基线程序的基础上开发新的程序的同时,原基线程序也可能在继续使用并持续迭代,对于基线程序的更新我们也应形成文档,以供后来的参考。
    (4)从此实现有效的开发过程
    对于新系统或原系统,从此应当遵守有效的系统开发过程,避免恶劣的软件工程发展蔓延下去;

    本文章援引《Effective software testing》一书内容,为个人读后笔记,特此声明
    分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
    收藏收藏
    回复

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-11-14 11:58 , Processed in 0.063979 second(s), 22 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表