发布新日志

  • 【转】如何质量和进度都双赢

    2015-10-12 14:57:25

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

    如何质量和进度都双赢

    上一篇 / 下一篇  2009-11-19 22:45:08 / 个人分类:正确的测试思想

    质量与进度只有矛盾这一属性吗?我的看法是“Not only”,质量与进度也有统一的时候。先说说为什么大家会感受:要么选择质量,放弃进度;要么选择进度,放弃质量;那是我们基于这样一个假设的前提:从事质量活动的技术水平没有改变的情况下,在资源没有改变的情况下,肯定只有降低质量要求才能满足进度要求。

    可是,我们换一种角度思考:如果我们改进了质量活动的技术水平,让其更有效率,更科学,更有生产率,那么我们是可以在不影响进度的情况下,达到更高的质量目标。甚至,还有可能在提高质量目标的情况下,缩短项目的进度。

    上面的道理,或许有的朋友明白了,或许有的朋友觉得是空白理论。那我再举2个例子,说明质量工作的生产率提高了,对进度的影响不但不会反面,反而会是积极的。

    案例1、我们在一个项目中使用了valgrind进行自动的内存错误检测,2天时间发现了40多个内存处理错误的缺陷。而按以往的测试方法,很可能有近一半的内存错误都发现不了。而要发现另20多个内存处理错误,按以往的生产率可能需要近1个月。我们仅仅是因为采用了更科学的测试技术,结果就获得了质量和进度的双赢。

    案例2、投入2人日进行设计需求的评审,发现了40个需求描述潜在的缺陷。这些缺陷一定会导致后续开发引入40个以上的bug。而我们通过静态测试,发现缺陷,开发修改缺陷只需要几人日的工作量就达到了缺陷消除的效果。要是采用传统的测试方法,要发现这些缺陷引入的bug可能需要数十人日甚至上百人日的工作量,甚至还可能不能全部发现这些bug

    以上2个案例,就是成功的案例——如何质量和进度都双赢,通过改进质量活动的生产率,既提高质量,又能缩短研发进度。

    此篇博文的目标和价值,就是希望告诉大家,我们不是要了质量,就要牺牲进度。我们质量工作者,需要自己开动脑筋持续寻找科学的质量工作方法,才能无愧自己的工作职责和价值。同时要告诉老板,在测试技术方面的投入不只是人力,更要有科学。

    在测试领域既提高质量,又帮助进度缩短的技术和方法还有很多,希望大家开拓视野,多从互联网上探索,寻找吧。

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

    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)
    技术根因
          在实际场景中用户因为对操作不熟悉难免会操作的步骤不是标准的步骤顺序,而程序实现时对于这些改变了操作顺序的操作步骤缺乏容错处理则会出现程序错误。

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

  • 下拉框测试用例示范

    2015-07-29 14:39:53

    大家总结的,比较全面,但是还是要看你自己的具体需求,还可以搜索一下看看有没有缺失
    1、从中选择一两个是否正确;
    2、列表内容,是可变还是固定的,可变的最好要用SQL或其他方式验证正确性,不允许出现重复值;
    3、可选内容是否符合需求说明书中的要求,没有丢失或错误;
    4、高度宽度显示是否正确,超出下拉框范围后是否有滚动条显示;
    5、是否有默认值,默认值显示是否正确;
    6、是否有空选项,如果有空,会对系统有何影响;
    7、如果系统要求非空,这里不选择,是否有提示信息。
    8、列表中的排序方式,特别是选项过多时尤为重要;
    9、选择一个选项后是否可编辑,有的下拉菜单允许编辑选择,这还需要验证其合法性;
    10、列表中文本的对齐方式,一般都是左对齐;
    11、选择框的长度是否合适,是否会出现选择项后不能全部显示其内容;
    12、下拉菜单获取焦点后,是否可以通过键盘操作,主要包括↑,↓,Home ,End ,PageUP ,PageDown等
  • 【转】测试者的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更大。我认识的这类测试人员有的后来还有做到产品总监和市场总监。如果你的创新气质和能力很强,可以往产品经理去发展。如果你的商业思维和影响力很强,可以往产品市场经理去发展。如果你创新力一般又不喜欢商业的压力,也可以做成一个公司中的稀缺的产品测试专家,在公司中也是一个宝,无人可代替。

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

  • 微软的结对测试

    2009-04-23 18:30:30

    Exploratory Testing at Microsoft

    Microsoft's recent emphasis on test automation has caused some to think that Microsoft has devalued

    the importance of exploratory testing. Exploratory testing is a (generally) manual approach to testing

    where every step of testing influences the subsequent step. During exploratory testing, testers use their

    previous knowledge of the application under test as well as their knowledge of test methodologies to

    find bugs quickly. The Windows Application Compatibility test team, for example, is highly dependent

    on exploratory testing to verify the functionality of hundreds of applications during the development of

    a new version of the operating system.

    On teams where there is an increased emphasis on automated tests, exploratory techniques are

    beneficial early in the test design phase to influence the structure and goals of the automated tests.

    Teams often schedule "bug bashes" throughout the product cycle, where testers take part of a day to test

    their product using an exploratory approach. This approach simulates the customer experience and is

    typically successful at finding bugs that other tactics might have missed. Many teams analyze the bugs

    found during the bug bash and use the findings to influence the design of future automated tests.

    In teams where a higher level of automated tests is necessary, testers often use exploratory techniques

    in conjunction with specifications and other relevant information to influence test case design. In

    testing, it is essential to find the important bugs as early as possible while also striving to design tests

    that will find bugs and verify functionality and correctness for the entire life of the application.

    One novel and successful approach to exploratory testing used at Microsoft is the practice of pair

    testing. Inspired by pair programming, this practice groups two testers together for an exploratory

    testing session. One tester sits at the keyboard and exercises the feature or application while the other

    tester stands behind or sits next to the first tester and helps to guide the testing. Both testers are

    performing exploratory testing, but while one concentrates on driving the functionality, one is thinking

    about the application from a high level. The testers switch roles at regular intervals. In a single 8-hour

    session, 15 pairs of testers found 166 bugs, including 40 classified as severity 1 (bugs that must be

    fixed as soon as possible). In feedback collected from a survey sent to the 30 participants, only 3

    thought that pair testing was less fun than an individual approach is, and 4 four thought it was less

    effective.

  • 解放全人类(游戏公测)

    2009-03-04 11:41:25

  • CubicTest 录制测试

    2009-02-17 11:07:44

    【转载】

    http://boss.bekk.no/display/BOSS/CubicTest+-+Tutorial

    Recording tests

    Alternatively to creating a test manually (as described above), tests can be recorded by interacting with an existing web application.

    The recorder requires that Firefox or Opera is installed. 

    To record a test,

    1. Right click in the background of a Test and choose "Record" (or right click on an arbitrary Page/State and choose "Record from this Page/State")
      Firefox/Opera will open and load the start point URL.
    2. To record page element assertions, right click on the page in Firefox on "page elements" (e.g. a link) and choose e.g. "Assert link present".
      To record text-present-assertions, first highlight/select the text and then right click and choose "assert text present".
    3. To record user interactions, interact with the page as normal. The interactions will be recorded, and "click" events will trigger the transition to a new state. Text input will not automatically trigger a transition to a new state. Observe that user interactions are added to the Cubic test model in the background.

    To stop recording,

    1. Right click in the graphical test editor -> toggle "Record" off.
  • Selenium RC的安装,配置和交互

    2009-02-13 18:10:55

    【转载】

    Hi All,
     
    In this article I will tell you how you can install and use Selenium RC(the best open source web testing tool and multi browser testing). I have been using Selenium RC for a while now and found it very useful to test web based applications. I have found that there is no installation and user guide for Selenium RC.
     
    First download selenium-remote-control-1.0-SNAPSHOT i.e. the nightly build from the http://seleniumrc.openqa.org/download.html. There is some issue with Version 1.0 beta 1 (run time error when running on IE browser).
     
    This is a zip file so, unzip the file and save it in ur c drive (Folder selenium-remote-control-1.0-SNAPSHOT).  Create a folder called Seleniumin your c drive and a sub folder called tests in c:\Selenium. Save all you selenium scrīpts in C:\Selenium\Tests\. 
     
    Before runing first thing is close all Firefox browser windows and follow the instructions given below.
     
    Open the Windows "Start" menu, select "Run" (on Windows Vista, use "Start Search" or enable the Run box, as described here) then type and enter one of the following:

        * firefox.exe -profilemanager
        * firefox.exe -P
     
    For more details go to http://kb.mozillazine.org/Profile_Manager
     
    When creating the profile manager you will have to create it under  a new folder C:\Firefoxselenium.
     
    Once the profile manager is created you will have to create two batch file (.bat); one for IE and the other for Firefox.
     
    This is an example of the SeleniumFirefox.bat file.
     
    cd
    \ cd C:\selenium-remote-control-1.0-SNAPSHOT\selenium-server-1.0-SNAPSHOT
    java -jar selenium-server.jar -port 4545 -firefoxProfileTemplate C:\Firefoxselenium -htmlSuite chrome http://www.yourtestwebsite.com// C:\selenium\G_alltestff.html* C:\selenium\*Results.html*
    pause 
     
    This is an example of the SeleniumIE.bat file.
     
    cd
    \ cd C:\selenium-remote-control-1.0-SNAPSHOT\selenium-server-1.0-SNAPSHOT
    java -jar selenium-server.jar -port 4545  -htmlSuite iehta http://www.yourtestwebsite.com// C:\selenium\G_alltestie.html* C:\selenium\*Results.html*
    pause 
     
    Next step is to create G_alltestff.html (For Firefox)
     
    <html>
    <head>
    <meta content="text/html; charset=ISO-8859-1"
    http-equiv="content-type">
    <title>Test Suite</title>
    </head>
    <table id="suiteTable"    cellpadding="1"
               cellspacing="1"
               border="1"
               class="selenium">
            <tbody>
                            <tr><td><b>Test Suite</b></td></tr>
                                <tr><td><a href=".\Tests\Name of you selenium scrīpt.html">Name of the scrīpt</a></td></tr>
        </tbody>
      </table>
    </body>
    </html>
     
    Next step is to create G_alltestie.html (For Firefox)
     
    <html>
    <head>
    <meta content="text/html; charset=ISO-8859-1"
    http-equiv="content-type">
    <title>Test Suite</title>
    </head>
    <table id="suiteTable"    cellpadding="1"
               cellspacing="1"
               border="1"
               class="selenium">
            <tbody>
                            <tr><td><b>Test Suite</b></td></tr>
                                <tr><td><a href="C:\Selenium\Tests\Name of you selenium scrīpt.html">Name of the scrīpt</a></td></tr>
        </tbody>
      </table>
    </body>
    </html>
     
    Once you have done this you are all set to rock and roll. To run Selenium RC on Firefox double click on  SeleniumFirefox.bat file and to run Selenium RC on IE double click on  SeleniumIE.bat. Selenium RC is a very useful tool and I feel it’s very stable that Selenium IDE.
     
    I would also like to thank my colleague Wedi Wun for helping me write the Selenium RC installation and user guide.To know more about Selenium RC/IDE Data driven testing see my article Data Driven Selenium using Excel Macros.
     
    Cheers
    Pavan Puddupakkam

Open Toolbar