发布新日志

  • [转] - 减少缺陷漏测的系统方法体系思考

    2015-07-29 14:54:20

    联系我:新浪微博@架构师Jack 或 dongjietest#163.com联系.(#换为@)
           从接触软件测试工作开始,相信所有人都希望减少软件测试后漏测的问题(tester希望,开发经理希望,老板希望),但事实是一直以来都没有很好的真正解决产品漏测的问题以及如何减少功能组合爆炸的问题。过去几年因为工作任务的缘故,我在历经几年自动化测试系统测试和缺陷预防工作后,又回到测试的本源开始思考功能缺陷的测试应该如何做好?从2011年版本到2012年版本直到2013年终于优化完善出了自己的功能测试方法体系,没想到居然在软件测试行业从业近10年时才搞明白了10年前就开始的问题。过去的5年通过实践补充了自己在缺陷预防领域的技能和认知、可测试性设计领域的技能和认知、产品可靠性测试(稳定性测试)领域的技能和认知,直到2年前才开始真正介入功能测试方法改进。最后才意识到原来我们不少漏测的问题,不是性能测试可以发现的,也不是稳定性测试可以发现的,更不是自动化测试能发现的,现有的功能测试用例及方法也发现不了--多功能组合下和不同用户操作序列下才发生的bug。怎么办?以及如何解决组合爆炸的问题--我们一直都在回避。如何让我们投入测试时间最多的功能测试用例该多的地方多,该少的地方少?搞了半天,原来测试领域最基本的工作都没做好,然后就开始疯狂追踪上层建筑,或是简单实行拿来主义拿来一些工具或方法,虽然所拿来的这些工具或方法对局部的确是有优化作用,但你知道自己的全局全貌在哪里吗?知道全部漏测的测试根因在哪里吗(而不是产品技术根因), 如果不知道则容易陷入盲目乐观与更加保守的状态。听说有个工具或方法能发现很多bug--于是开始盲目乐观引入,希望能从此解决完所有测试漏测的问题,结果确实能发现一部分问题但是还是有不少漏测,结果--开始更加保守,对新工具和新方法不再相信和信任,从此对漏测问题放在一边交给其他人去关心。那我就是那位被迫要去关心和解决漏测问题的非主流测试工程师,幸运的是经过过去几年的思考与学习,如今随着个人稳定性测试模型和功能测试模型方法体系的完善,终于让我有信心有知识去应对任何软件的漏测问题, 可以阶段性的结束对漏测问题领域的专注思考,投入更多精力于其他测试技术和方法体系了, 故写此文阶段性纪念下。下面分享一部分如何减少功能缺陷漏测的干货吧,与各位共勉:    

    功能缺陷的测试方法流程
       第一步: 功能测试分析 功能测试阶段
                目的: 提取功能测试对象
                           准备功能测试数据
                减少因为功能测试对象遗漏的漏测

       第二步:功能验证功能测试阶段
                目的:检查功能是否已基本正确实现   
                测试方法 :
    基于生命期: 对象创建 -使用- 销毁 的验证
    数据测试方法: 静态数据测试方法和动态数据测试方法 (边界值和数据等价类、7因子数据类型)
                减少功能的基本逻辑错误漏测和数据处理错误的漏测

       第三步:单功能内测试 功能测试阶段
                目的:发现功能是否存在分支情况、异常情况处理不足的缺陷
                测试方法 :
                功能内子功能的场景插入法
                             重复法设计
                             反叛法设计
                             取消法设计
                            测一送一法设计
                           场景删除法设计
                减少功能内代码的漏测
                 
       第四步:多功能间组合测试 系统测试阶段的用户场景测试
                目的:发现功能间配合工作时存在的缺陷
                测试方法
                    基于用户场景的测试 (Scenario Test)
                减少多功能间组合错误的漏测

    为什么需要用户场景的测试模型?
         补充多个功能组合的测试用例解决传统正交组合测试后3个及以上功能组合缺陷的漏测
         通过常见用户操作序列的场景设计解决数学式穷尽组合爆炸的问题减少组合测试时间和成本,获得最佳投入产出比的组合测试

    用户场景测试的测试步骤 是 不同角色用户最常用的基本操作序列
    用户场景的探索测试    是 不同角色用户非常用的操作序列

    用户场景的探索测试
    在用户场景测试用例执行结束后 , 再用专项时间进行多功能组合的探索测试,补充用户场景测试用例之外的用户操作序列,提高用户操作序列的覆盖面。因为用户最常用的操作序列已在用户场景测试用例中覆盖,但又不能对非常规的操作序列不进行测试,   因此将非常规的操作序列的测试与测试成本进行一个平衡,通过专项的探索测试时间来补充这部分的测试。

    在补充用户操作序列的探索测试中可用的探索测试方法有:
    收藏家法
                同时开启多个功能,同时工作。
    技术根因
               同时多个功能交互容易出现资源竞争处理的错误。

    地标法
            改变一系列规定顺序操作的先后顺序。( A->B->C->D->E)改为 (A->D->C->B->E)
    技术根因
          在实际场景中用户因为对操作不熟悉难免会操作的步骤不是标准的步骤顺序,而程序实现时对于这些改变了操作顺序的操作步骤缺乏容错处理则会出现程序错误。

     混票法
           把最不常用的功能与常用功能进行组合
        技术根因
           在功能测试阶段由于时间及优先级限制,测试人员习惯把常用功能进行组合测试,时间一久就容易忘掉不常用功能与常用功能的组合,而用户的使用习惯中也一定会出现不常用功能与常用功能一起组合的场景

  • 【转】测试者的2大类型特点及发展空间

    2015-05-14 11:36:08

    任何软件产品都由2部分组成:业务逻辑+软件技术。业务逻辑通常由产品经理设计,软件技术由软件开发架构师设计和程序员编程实现。而测试人员呢?则通常对两大部分的质量问题都会进行评测。无论是主动认知还是被动发展,在大部分的组织中都会发现有一部分测试人员更喜欢和擅长进行业务逻辑的测试(后面称:SET)、一部分测试人员更喜欢和擅长对软件技术的测试(SDET)。

     常规业务逻辑的测试类型有:功能验证、功能测试、场景测试、端到端测试、探索测试;

     常规软件技术的测试类型有:性能测试、可靠性测试、单元测试Code Review

     帮助提升研发效率的技术手段有:持续集成、自动化测试

    通常SET会更喜欢和擅长常规业务逻辑的测试类型,SDET会更喜欢和擅长折腾常规软件技术的测试类型和帮助提升研发效率的技术手段。

    两类测试者的知识结构有所不同:

    SET们会更喜欢学习和了解产品的商业知识和分析用户场景及用户行为,从业时间久了会成为产品专家,这类测试者经过长期测试工作训练将拥有更强的以“用户为中心”的思维习惯,无论是转型产品设计或是产品推广都会比较容易,产品路线是其发展的核心。

    SDET们会更喜欢学习和了解产品实现的各类软件技术,如:编程语言、软件设计方法、非功能的测试技术(自动化测试/性能测试/可靠性测试等)、帮助提升测试效率和软件质量的各类软件工具和工程方法。此类角色从业时间久了会成为技术专家,技术路线是其发展的核心。

        作为一家产品公司SETSDET都是必须的,至于SET重要还是SDET更重要将由各公司的基因文化决定。例如:在华为是一家以“客户为中心”的公司,因此在华为ST地位更高也更重要些。在谷歌是一家以“技术创新为中心”的公司,因此SDT地位更高也更重要些,但是后来谷歌也发现了SDET受限于工作时间和兴趣志向的约束导致一些产品问题无法单纯靠SDET来解决,所以又重新组建了谷歌SET资源与SDET形成互补,才真正更好支撑起了谷歌商业产品的需求。(更多可见【转载】How Google Tests Software - The Life of a TEhttp://www.51testing.com/index.php?uid-293557-action-viewspace-itemid-842600

    所以作为一个tester无论走哪条专业路线(产品路线或技术路线)最终依赖的是个人的兴趣和喜好。

    喜好走产品路线的同学也不要觉得职业发展就比走技术路线的同学差,在大多数非技术驱动的产品公司中似乎SDT后来的发展空间比SDET更大。我认识的这类测试人员有的后来还有做到产品总监和市场总监。如果你的创新气质和能力很强,可以往产品经理去发展。如果你的商业思维和影响力很强,可以往产品市场经理去发展。如果你创新力一般又不喜欢商业的压力,也可以做成一个公司中的稀缺的产品测试专家,在公司中也是一个宝,无人可代替。

    喜好走技术路线的同学职业发展路线可以是:成为软件开发者、软件工程专家、软件测试专家,活在自己喜欢的世界中。在重视技术创新和技术品质的公司中也会获得很好的发展。

  • 【转】测试者的2大类型特点及发展空间

    2015-05-14 11:34:29

    新浪微博@架构师Jack 或 dongjietest#163.com联系.(#换为@)

    任何软件产品都由2部分组成:业务逻辑+软件技术。业务逻辑通常由产品经理设计,软件技术由软件开发架构师设计和程序员编程实现。而测试人员呢?则通常对两大部分的质量问题都会进行评测。无论是主动认知还是被动发展,在大部分的组织中都会发现有一部分测试人员更喜欢和擅长进行业务逻辑的测试(后面称:SET)、一部分测试人员更喜欢和擅长对软件技术的测试(SDET)。

     常规业务逻辑的测试类型有:功能验证、功能测试、场景测试、端到端测试、探索测试;

     常规软件技术的测试类型有:性能测试、可靠性测试、单元测试Code Review

     帮助提升研发效率的技术手段有:持续集成、自动化测试

    通常SET会更喜欢和擅长常规业务逻辑的测试类型,SDET会更喜欢和擅长折腾常规软件技术的测试类型和帮助提升研发效率的技术手段。

    两类测试者的知识结构有所不同:

    SET们会更喜欢学习和了解产品的商业知识和分析用户场景及用户行为,从业时间久了会成为产品专家,这类测试者经过长期测试工作训练将拥有更强的以“用户为中心”的思维习惯,无论是转型产品设计或是产品推广都会比较容易,产品路线是其发展的核心。

    SDET们会更喜欢学习和了解产品实现的各类软件技术,如:编程语言、软件设计方法、非功能的测试技术(自动化测试/性能测试/可靠性测试等)、帮助提升测试效率和软件质量的各类软件工具和工程方法。此类角色从业时间久了会成为技术专家,技术路线是其发展的核心。

        作为一家产品公司SETSDET都是必须的,至于SET重要还是SDET更重要将由各公司的基因文化决定。例如:在华为是一家以“客户为中心”的公司,因此在华为ST地位更高也更重要些。在谷歌是一家以“技术创新为中心”的公司,因此SDT地位更高也更重要些,但是后来谷歌也发现了SDET受限于工作时间和兴趣志向的约束导致一些产品问题无法单纯靠SDET来解决,所以又重新组建了谷歌SET资源与SDET形成互补,才真正更好支撑起了谷歌商业产品的需求。(更多可见【转载】How Google Tests Software - The Life of a TEhttp://www.51testing.com/index.php?uid-293557-action-viewspace-itemid-842600

    所以作为一个tester无论走哪条专业路线(产品路线或技术路线)最终依赖的是个人的兴趣和喜好。

    喜好走产品路线的同学也不要觉得职业发展就比走技术路线的同学差,在大多数非技术驱动的产品公司中似乎SDT后来的发展空间比SDET更大。我认识的这类测试人员有的后来还有做到产品总监和市场总监。如果你的创新气质和能力很强,可以往产品经理去发展。如果你的商业思维和影响力很强,可以往产品市场经理去发展。如果你创新力一般又不喜欢商业的压力,也可以做成一个公司中的稀缺的产品测试专家,在公司中也是一个宝,无人可代替。

    喜好走技术路线的同学职业发展路线可以是:成为软件开发者、软件工程专家、软件测试专家,活在自己喜欢的世界中。在重视技术创新和技术品质的公司中也会获得很好的发展。

Open Toolbar