现在主要在知乎,地址:https://www.zhihu.com/people/qqrrm 老的文章在:http://blog.csdn.net/pyp

发布新日志

  • 做软件测试需要强势吗?

    2020-04-13 12:54:30


    作者:鹿鸣
    链接:https://www.zhihu.com/question/303675694/answer/1143576945
    来源:知乎
    著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

    测试仅仅是一个工作,和性格关系不大,更关键的是所在公司的流程。

    需求评审,测试本来就应该提出自己的看法和意见,你无法提出意见更多应该是你的水平不到,无法看到文档里面更深入的问题,这个更需要的是多多学习和思考,和性格无关。

    迭代排期也一样,关注进度,主要还是项目经理和质量保证方面的责任,当然了,很多公司的测试会兼顾一些QA的职责,但是看你的描述无法确认是否测试有QA的职责权限。

    公司的流程如果正常,本来就应该有周例会或周报之类的,各个角色说明当前的项目进度,并不需要测试人员去督促进度,测试人员本身的职责和范围,通常也并没有进度监控这项内容。

    而且你们没有项目计划和测试计划的吗?为什么需要测试人员去询问什么时间测试,测试人员只需要按照测试计划,在需要测试的时候,去配置库提取测试版本。

    感觉你们没有项目经理去管理项目,或者开发人员认为并不需要测试就可以发布。

    至少从你描述,我看不出来工作和性格有什么关系,只是表明你的公司的流程有问题,所以需要员工自己去调整工作,应该是没有项目经理,只有开发人员和测试人员,所以需要大家商量着来,结果开发人员更强势,控制了话语权,测试人员被逼随着开发人员的节奏步调进行工作。

    所以你需要做的,建议公司设立开发标准流程,建立项目经理负责制,找真正可以做主的人员,不要有事没事和开发人员说进度之类的事情,这个本来就不是开发人员管的。测试工作上,坚持专业技能,只做应该自己做的,时刻提醒自己,我仅仅是测试人员,测试才是我的工作范围,测试以外的事情,我只有建议权,没有决策权,所以该是哪里的问题,找相应的负责人解决。

    坚信自己是技术人员,一切以技术说话,尽量避免性格因素对于工作的影响。

    大概就是这样。

  • 测试工程师的核心竞争力是什么?

    2020-04-13 12:51:19


    这几天在知乎总能看到一个问题给我推送:

    假如我是一名能100%修复所有bug的程序员,我能在编程领域混成什么地位?

    其实测试人员也可以提出类似的问题:假设我是一名能100%发现所有缺陷的测试工程师,我能在测试领域混成什么地位?

    企业为什么需要测试,本质上是为了保证产品的质量,所以如果企业对产品质量没有任何的要求,那么完全没有必要设置质量相关岗位。当然了,实际因为现实的种种原因,即使企业真的不重视质量,除非是小作坊,企业规模到了一定的程度,只要存在需要提供产品,那么一定需要有质量人员存在,这个人员也许是质检,也许是品质,也许是QA,也许是测试,也有可能是其他角色人员。

    企业的根本目的是生存发展,这些离不开金钱,所以需要计算投入产出,只有一个角色企业认为产出超出了投入,才可能有相关的角色人员存在。

    测试在产品生产甚至是质量链条上,并不一定是必要的存在,所以需要考虑的是自身存在的价值和意义。

    测试总体来说,是质量的度量,实际是提供一个阈值,衡量产品是否低限满足客户需求。

    那么就很容易得出结论,其实测试的能力和企业的要求并无太多的关联性,企业招募人员一定希望最低的成本完成最有价值的事情,测试的价值就是提供质量情况,谁能越多的满足此种企业需要,谁和企业的匹配度越高。

    其实吧,可以认为我上面的内容都是废话,企业很多时候面试的时候考的造火箭,进去大部分时候还是在敲钉子。

  • 如何看到软件测试技术带来的价值?

    2020-03-28 10:59:34

    知乎问题回答

    测试不是创造价值,而是提升价值。

    创造价值的一定是开发人员,但是开发人员做出来的产品质量未知。

    谁能判断一个产品的质量是否优异,除了客户,就是质量人员。

    质量人员的范围很大,比如技术专家、比如QA、比如开发、比如测试等等质量相关或者项目干系人都可以说是狭义或者广义上的质量人员。

    测试的目的是发现产品中存在的问题,以此定义产品的质量。

    质量的好坏和产品的价格非正相关,以客户的判断为最终标准。

    所以如果客户觉得一个产品的质量不优异也可以接受,那么质量相关的投入可以减少。

    测试过程仅仅是质量环节的一个部分,身为测试人员,保持自己的立场即可。

  • 去哪里找系统来进行测试

    2020-03-28 10:56:06


    有一个误区,虽然说软件测试的工作产品之一是通过测试过程发现的缺陷,但是此工作产品的产出并不是单单直接测试获得的。

    一个产品需要测试,拿过来直接测试通常并不能获得一个好的结果,通常需要了解很多的内容才能更好的完成此测试过程。

    比如此产品的需求是什么,需要进行哪些方面的测试,哪些内容是要重点测试的,测试的工作时间是多久,需要安排多少的工作量。

    在软件开发中,也并不是拿过来一个点子就开始写代码吧,需要进行需求调研,整理客户需求,写需求规格说明书,评审,项目计划,概要设计说明书,界面设计,数据库设计,详细设计等等等等,这些都做好了,才开始正式的写代码。即使是敏捷过程,同样有story,站立会议等等,也并不是拿过来都直接做的。

    测试过程类似,参与需求评审,写测试计划,参与项目例会,写测试方案,写测试用例 ,根据计划做接口测试、功能测试、性能测试、安全测试、回归测试等等等等。

    所以说,测试不仅仅是发现缺陷,而是通过软件测试的过程,让项目相关人员了解当前软件的质量情况,最终给发布的软件以信心支持。

    回到问题,你想通过一个具体的软件了解测试,那么建议通过以下的途径进行:

    1.软件确认。随便找一个软件,比如你常去的论坛,比如知乎,比如豆瓣等等等等,软件是什么不重要,重要的是测试的思路。

    2.测试内容。通常功能比较多,可以拆分一些简单的功能模块进行测试,比如登录,比如发帖,比如查询等等。

    3.测试范围。这个其实如果有需求应该是对于需求的分析,但是既然没有需求,那么就参考具体的程序,把上面的功能拆分出来,比如登录就可以列出功能分解:创建新账号,老用户的登录,使用QQ、手机、微信第三方登录等等。这里需要对测试的范围进行确定,具体测试哪些功能。

    4.测试类型。接口测试,功能测试,性能测试等等。

    5.测试计划。简要写一个就可以,主要说明测试的范围,测试的类型,测试用例的编写等等,具体看测试计划相关内容,确认需要做的工作。

    6.测试用例。具体内容应该都学习过的吧,等价类、边界值、场景法等等,能用上的都用上,多分析多写,尽量考虑更多种类的正常和异常的情况,这个才是测试人员最基本最基本的基本功。真正工作中,即使不写测试用例,但是头脑中一定也要有一个测试用例列表,我现在应该做什么,接着做什么,实际按照此列表进行。软件测试绝对不是随便点点的胡乱测试,是有理论和实践支持的科学工作方法。

    7.执行测试。按照测试用例去测试。在测试的过程中,可能需要随时补充调整测试用例,这个是正常现象,发现缺陷就记录下来。

    8.缺陷分析。发现的缺陷进行整理分析,比如是否可以重复出现,测试步骤是否可以简化,是否其他地方存在类似的问题等等。测试缺陷通常有群集的现象,一个地方发现的问题多,那么说明这个地方一定会有更多的问题等待发现。

    按照上面的流程,至少你可以对别人有信心的说,这个软件我成功的进行了测试,即使没有发现任何的缺陷,至少在测试用例的范围之内,我已经尽力了。

    --------------------------

    补充内容:

    测试人员的基本技能是发现缺陷,这个是正确的,但是这个并不是全部。

    任何的工程,都需要考虑成本、进度、质量,测试过程同样不例外。

    确实很多人可以发现别人无法发现的问题,而且测试人员作为专业人士,发现的缺陷本来就应该比开发或者客户等外行多且正规,这个是测试人员的工作。

    但是发现缺陷,同样需要考虑很多的时间和成本问题,而最好的控制手段就是进行规划,也就是计划和用例,保证测试的投入产出比。

    当然了,作为学习阶段,并不需要考虑这些,就像是开发面试,一定会考一大堆的堆栈算法等问题,但是实际真正工作用到的,大部分人还是CRUD居多。

    书上和培训的知识内容,更多是理论的框架,实际工作要复杂很多,在一个不断进化的行业,人员也是需要不停学习的,理论的扎实是很重要的部分,还是一切的基础。

    努力学习和工作吧。

  • 未来方向软件测试,有什么可以指点提醒的?

    2020-03-28 10:53:51

    不清楚你大专学习的什么专业,是否IT相关。个人更建议学习编程,当程序员比测试人员要好很多,而且现在对于测试人员的要求也逐步在提升,没有开发背景的测试人员,上限未必会太高。

    工作用的电脑不是应该工作单位给配置的么。总体来说,测试人员的电脑没有太高的配置要求,因为顶多用个loadrunner,基本对于电脑没有要求。测试人员不比开发人员,开发人员需要使用Visual Studio或者IDEA、Eclipse这样的开发工具,同时搭配类似Oracle数据库才需要高配置的电脑,测试人员也许更需要Android模拟器或者VMware这样的虚拟机。当然还是电脑配置越高越好用。其实测试人员更需要的是多样的测试环境,比如各种分辨率显示器,各种操作系统的机器,各类常用的Android手机等等,但是没有也可以虚拟代替使用。具体还是在工作过程中看你测试的软件,还有公司对于测试方面的资源倾向。

    测试工作总体来说是大杂烩,什么都要求会一点,但是很多没有必要精通。个人觉得比较根本的有两点,第一是测试方法测试思路,落实到测试用例的编写上,测试人员是否水平足够,看测试用例编写即可。第二就是业务的熟悉。测试人员的工作目的还是为了发现缺陷,要发现缺陷就要对业务和软件熟悉,才能更广泛更深层次的发现问题。业务需要在具体工作中了解,所以如果想成为一个优秀的测试人员,努力练好基本功,多分析软件,多写写使用各种测试方法的测试用例。

    从我个人的角度,分析一下你手打的内容,觉得有些违和的地方,意见仅供参考,不需要完全相信。

    1.原文:全面的深入进行数据库、代码、接口非功能等方面的测试。

    这句过于的杂揉。测试人员分很多种,常见的功能测试人员,接口测试人员,自动化测试人员,性能测试人员,测试开发等等。我这里默认角色是人数最多的黑盒功能测试人员。数据库不需要测试,数据库通常不在测试人员的测试范围内。代码不需要测试,代码基本都是单元测试、TDD、接口测试等等,这个是开发人员的责任,基本代码是不需要测试人员管的,测试人员通常只需要测试编译打包后的可执行程序。接口和非功能是两个东西。非功能指的的是性能、安全、界面等内容,接口应该归于功能测试。

    2.原文:可以协助需求、设计以及开发人员做很多补充和完善的测试。

    需要记住一点,你是测试人员,测试方面你才是专业的,你才是专家。所以测试相关的内容,不是协助其他人做测试,而是其他角色人员协助测试人员做专业测试。测试人员需要做的工作是对需求文档、设计文档、开发文档等做测试方向的评审,比如需求文档中是否存在矛盾冲突、无法测试的地方,设计文档是否和需求文档功能一致,或者指导开发人员,除了正常的路径,还需要考虑各种异常情况,这才是测试人员的工作。测试人员在整个项目开发过程中处于辅助地位,但是在测试方面,一定是测试人员做主导。

    3.原文:数据库,增删改查,迁移存储优化(mysql)

    还是身份定位的问题,你是测试人员,不是DBA,迁移存储有DBA、运维,优化有DBA、程序员,哪家公司会叫测试人员做这些工作。测试人员的独立得益于社会化大生产分工,其实没有测试人员,程序员也可以当全栈从头干到尾,为什么还需要需求人员、设计人员、项目经理、DBA、运维等等等等,因为每个专业既然分出来,一定是有其专业化和时间成本分配原则。测试人员只需要做好自己份内的工作。当然了,如果想转行做别的,当然是学的越多越好,但是实际上,任何一个可以独立分工的职业,想学习明白都是要花费很多时间精力的,看你个人的选择如何。

    别的就没有什么了,证书个人觉得ISTQB是坑,看你的公司是否需要,否则看看教程即可,测试人员的理论知识并不算太多。最好的证书一定是信息系统项目管理师,建议优先考这个证。



  • 33岁学软件测试来得及吗?

    2018-06-09 11:12:34

    内容为:之前一直在工厂上班,看不到希望。已经33岁了,想转学软件测试来得及吗?

    我给出了下面的回复,大家可以去给出不同的回复。

    ------回复正文-------

    我看题主的个人资料,你在12个月前关注了测试话题,但是在知乎一直没有进行过操作,今天提出这样的问题,因为对你的信息没有太多的了解,所以只说些自己能分析判断出来的,可能和题主的实际情况不一致,如果看到能补充更多信息更好。


    看题主问题有几点:

    1.工厂上班

    2.没有希望

    3.33岁

    4.希望学软件测试。

    不清楚12个月前为什么你关注了测试的话题,是否你周围的人有在从事相关的工作,可能和你沟通的时候,表达了测试入门门槛低,待遇不错的信息。而你在工厂的工作不是很顺利,33岁不清楚是否有家庭的压力,所以想换一个更有前途的工作。

    因为工厂的职业有很多,所以不清楚你现在的工作是什么,也不清楚你的学历以及是否做过学过做过IT相关的工作,只是从一个测试人员的角度给你一些看法和建议。

    1.测试的入门门槛

    其实不是测试的入门门槛,而是很多公司本来就对员工有入门要求。比如学历,比如相关工作经验。除非你是应届毕业生,公司认为你有培养的价值,所以会降低相关的要求,否则进入公司的那一关就很难。

    2.测试的发展前途

    测试现在的发展趋势都是程序员化,就是一是质量方面要求程序员负担起更大的责任,同时测试人员的技能要求在向程序员发展。所以对于想入测试的人,通常建议先去做程序员,实在对测试感兴趣再从程序员转成测试人员。

    3.年龄限制

    现在的IT行业,整体还是在拼人力。996了解一下,虽然不是全部公司都这样,但是大部分的IT公司加班出差等都是常态。33岁在IT行业真的很大了,很多公司初级人员都是要年轻的,最好吃住都在公司,30岁以后基本都是资深开发或领导一个小组了。33岁真的大部分公司不会需要的。

    4.测试技能。

    软件测试还是需要基础的,测试即使相对开发简单,想入门也需要花费一定量时间和大量的金钱,建议你去咨询一下相关的培训公司。


    所以从你的情况,个人建议不要转职测试,除非你有对口的单位可能会需要测试人员,职位给你保留。

  • 开发对于测试的误解问题回复

    2018-05-27 15:25:01

    原文在https://zhuanlan.zhihu.com/p/37288095,格式更清晰些,紫色部分为原文引用。

    今天看到一篇文章《关于质量保障部(测试)人员的测试管理及KPI工作的思考与讨论》,感觉里面对于测试方面的看法基本都是错误的,但是其中的一些观点很有代表性,就详细回复解答了一下,在这里重新做一下整理和记录。


    因为研发管理不可避免的和测试打交道,会深入到测试管理的种种利弊中,所以今天因为一个问题和测试争论很久。

    故事是这样的:今天团队的一名新人截图告诉我说,测试提的bug,他标记外部原因后给测试,测试又打回来,并回复“请修改状态为已解决”。

    新人就表示了不理解,因为bug的本身是因为研发中需求变更导致产生的历史错误数据干扰,上线后不会有这个情况,严格的说也确实不应该是研发的开发bug。

    但是测试缺认为,虽然你是历史数据,但是我确实发现了问题,你标注外部原因,是对我工作的否定。

    经过沟通,确认了问题的核心是,测试对BUG数量,BUG等级,BUG有效率进行了绩效管理和考核,而《外部原因》这个状态的bug不会算在有效BUG统计中。

    也就是说,开发和测试对这个BUG的状态共识并不一致。

    测试角度释疑:

    个人一直不建议测试人员和开发人员对于缺陷是否需要修改直接进行交流,因为太容易产生文中的矛盾。个人觉得比较理想的状态是缺陷提交后有一个确认过程,比如通常每天测试完成,个人习惯找项目经理确认当天发现的缺陷,确认哪些是缺陷哪些不是缺陷,或者确认是缺陷但是项目经理认为可以暂时不修改,因为不涉及具体的修改缺陷的开发人员,所以即使开发人员有意见认为不需要修改,请先去找项目经理沟通,项目经理确认后再和测试负责人重新对缺陷进行确认。这样通过中间人不易产生矛盾。

    开发人员可以说测试人员提交的缺陷不是bug,这是很正常的行为。但是对于一个问题是否是缺陷测试人员有自己的标准,此标准不会以开发人员的看法改变。当缺陷出现争议的时候应以测试人员为准,因为缺陷为测试人员提交,需要测试人员确认验证后才能关闭,开发人员责任仅限于缺陷修改。

    对于文中的历史遗留问题,开发方既然知道是问题,那么在测试的角度就是缺陷。测试通常没有必要理会缺陷发生的原因,缺陷存在就是存在,开发人员的职责是把缺陷处理掉,至于开发人员说上线等非技术手段就能处理的问题,在测试这边是不存在的。因为太多情况下开发人员都是在应付,即使到线上环境,此问题也未必会解决。测试人员遇到过太多类似的事情,所以很多时候不会信任开发人员的解答,只有修改并经过测试人员验证过的缺陷才能关闭。


    定义
    探讨这个问题,我觉得首先要定义清楚两个个事情:
    1、BUG其实是要分两种类型的。
    即 生产BUG 和 测试BUG。
    这两个问题应该单独管理并分开讨论。很多公司对于这两种问题从工具到认知都是分开处理的。
    2、定义一个名词《真实bug》,也就是开发完成交付后,测试拿到的研发成功他客观真实存在的真实bug数目。
    这个不等于测试提交的bug数目。
    生产bug越少,测试bug越接近真实bug。
    测试bug完全等于真实bug时,生产无bug。

    测试角度释疑:

    测试人员的工作是发现缺陷,无论什么样的缺陷,和缺陷数量无关,和缺陷质量无关,缺陷就是缺陷。

    对于测试人员来说,并没有区分什么生产BUG、测试BUG、真实BUG的必要性。测试人员都了解缺陷具有无尽性,只要有时间,总能发现新的缺陷。

    项目需要考虑进度、成本、质量,测试过程同样需要考虑这些内容,需要在有限的时间内发现尽可能多的缺陷和影响比较大的缺陷,这才是一个测试人员体现价值的地方,所以才会有需求评审、测试计划、测试用例等等。

    总之,生产BUG、测试BUG、真实BUG在测试人员这里没有必要区分,因为定义本身就是有问题的。


    什么是质量保障工程师
    我们再来明确下一名质量保障工程师的定义,测试人员都喜欢叫自己质量保障工程师,部门叫质量保障部,那么顾名思义,测试 就是进行质量保障的。而保障的质量,当然是上线的质量,而不是开发后,那是开发的事,测试能决定吗?
    所以一名合格的测试,首先要保障上线后的bug数目小于预期。上线后能够尽可能的没有bug。
    也就是说,测试工作的究极目标,就是要上线后没有bug,至于需求分析、用例编写、测试、回归,沟通,管理,这些过程,都是为了实现最终目标的手段和方法,那么这个过程中产生的bug数目,即测试bug,还有意义吗?什么才是有意义的呢?

    测试角度释疑:

    没有质量保障这个叫法,通常说的是质量保证。质量保证是QA(Quality Assurance),QA主要工作是检查流程是否符合预定目标,比如项目计划说要有需求,那么QA人员会在计划时间检查是否需求人员完成了需求文档,需求文档是否进行了评审。测试主要工作针对产品,发现产品中的缺陷。

    虽然很多非测试人员都认为质量保证和测试两者是一样的工作,但实际是不同种类的工作。一个测试人员通常不会叫自己质量保证工程师的,我们只会叫自己测试工程师。

    现在在很多公司,确实不区分QA和Test,工作内容也同时包含两者,但是两者实质确实不同的工作内容。

    质量是产品的内附属性,可以认为无论是QA还是Test主要是为产品的质量目标服务。产品开发出来,质量上限实际就已经决定了,Test可以通过工作使产品努力达到质量上限目标;但是开发和QA可以提升这个质量上限,比如QA可以要求开发做单元测试和集成测试,而测试通常是没有这样的权利的。

    测试的工作内容是尽可能的发现产品的缺陷,对产品上线后的问题通常并不关心。这里有一个测试清除率的概念,就是测试的缺陷没有在当前期间发现,遗留到了下一个阶段,这个可以对测试做一个考核目标,但是并不是测试人员关心的问题。测试人员只会关心当前阶段如何尽可能多的发现缺陷。

    测试可以认为是对质量属性的一种度量,通过测试发现的缺陷,可以了解当前产品的质量情况。比如测试发现的缺陷较多,可以认为产品的质量较差,并不是缺陷全部处理了,就认为产品质量好了。因为发现的缺陷越多,可以认为没有发现的问题更多,产品本身质量就有问题。还是那句话,提升质量更多靠的是开发人员和QA,到测试这里,一切都已经太晚了。


    传统kpi的参数分析
    1、bug的数量和bug的级别
    我认为,测试过程中的bug数目,bug等级,统统没有任何意义。因为各个需求复杂度不同,各个需求开发人员不同,开发周期不同,开发质量不同,这些会决定真是存在的BUG总数就不同。
    比如需求A ,到交付时,真实BUG数目是100个,测试测了60个,其他40个上线了,这算成功吗?
    比如需求B,到交付时,真实BUG数目是10个,测试测了10个,其他0个上线,这算失败吗?
    结论:比较两个分别负责需求A和B的人员 产生的bug数量和bug级别,没有任何意义。因为你也不清楚真实bug数目,并且无法预估。

    测试角度释疑:

    只要在测试用例的覆盖范围内,测试发现了多少缺陷就是多少缺陷,即使测试阶段测试人员发现了10个问题,到客户那边发现了1000个问题,也无法说测试人员是失败的,因为测试人员可能已经在他的工作范围内尽力了,测试人员都清楚并不能用缺陷数来度量测试成功或失败。

    在通常情况下是可以对缺陷进行预估的,比如CMMI到4级后,度量数据都应该限定在一个比较确定的区间范围内,缺陷数据也不例外。无论是测试缺陷还是现场用户缺陷,都是可以在计划阶段就预估的,只是需要很**的开发流程和一定量的成本。


    2、bug的有效率
    有效率的定义应该是 bug是否是有效的,所谓有效,那其实就是 bug是否是bug,这个当然是有意义的。但是其实对于中高级以上的测试,既然提出了bug,很少是使用方式,或者执行流程造成的不是bug的无效bug,所以这儿数值,能力达到一定程度,变化并不会特别大。
    另外这个值其实从统计学上,仍然具有缺陷,即数据量样本越大,也就是越大的需求,越复杂的需求,出现无效bug的概率越高,有效率月低,所以并不能完全说明什么。
    结论:bug有效率,有一定程度的意义,kpi占比可以较低。

    测试角度释疑:

    这段我从头到尾都没有看懂什么意思。缺陷就是缺陷,没有是否有效的区别,每一条缺陷都是有意义的。

    感觉答主对中高级测试有误解,中高级测试是可以用更好的手段发现更多的缺陷。举个例子大概说明一下,比如初级测试人员的工作可能只是执行测试用例,中级测试人员负责编写测试用例,高级测试人员可以通过开发测试工具、优化测试流程、通过对业务的熟悉编写较少的测试用例发现更多的问题等等。无论初中高级测试,绝对没有什么高级测试发现的缺陷就一定比中级的好。还是那句话,高级测试可能发现初级测试发现不了的缺陷,但是就缺陷本身没有高低贵贱之分,缺陷本身没有有效无效之分。

    对于缺陷,测试人员通常使用严重性来区分,比如一个缺陷,可能对于产品质量影响比较大,不修改此功能就无法继续使用,那么可能就是一个严重缺陷;比如仅仅是一个文字问题,开发人员连续使用5个叹号做强调,我可能就会提一个轻微缺陷,告诉开发人员最好一个叹号都不要用,也不要用红色之类的提示,所有的提示要统一风格,避免引起客户的不适感。

    开发人员对缺陷的区分主要是优先级,就是修改的顺序。比如一个缺陷,对于测试人员来说可能严重性很高,但是开发人员认为其他缺陷更紧急,测试人员发现的缺陷虽然引发的后果很严重,但是客户很难触发这个缺陷,那么可能就放在最后修改,开发人员会优先修改客户容易发现的缺陷。


    应该怎么做?
    大家发现,所以一个质量保障工程师(测试),最重大的产出都不具备考核价值,那么我们应该如何考核测试的KPI呢?
    根据上文的例子,我们很容易发现,其实关键的问题是需求A开发完成后,他的真实BUG数目是不可预估的,高质量的开发和设计过后,充裕 的时间过后,他的真实存在的bug可能很少,甚至不存在。
    相反,低级工程师、不了解业务的人员开发,时间过渡紧迫加班赶工,等诸多因素可能让真实bug较多。
    在这种情况下,我们要保障的是 尽可能的发现真实bug,尽可能的让自己发现的bug数目接近或者等于 真实bug数目。
    所以,我们为此付出的努力,工作方式,流程,才是我们考核的更重要的部分。

    测试角度释疑:

    缺陷度量数据是可以预估的。

    每个公司进行大量的项目后,只要有一定的测试数据收集和分析,新的项目根据规模、类型等至少可以在数量级范围内对相关数据进行预估。测试工作也都是在一定时间和成本下进行的,所以测试一定也会考虑投入产出比。


    1生产bug预期达成比
    回到最初关于 “质量保障的定义”,很简单,我们首先要衡量的是一名合格的工程师有没有达到保障质量的目标,即如果上文提到的《生产bug》超出预期,那么工作其实是不合格的。
    但是bug预期是一个较为抽象难以量化的东西,只能根据用例复杂度和需求复杂度等具体的需求表述,根据以往经验和团队能力配比,以及时间投入相关,由产品、研发、测试共同制定一个尽可能客观的预期bug数目标准。
    比如一个10人/日的需求 ,bug预期是3 ,计算预期达成比。
    所以在KPI考核中,生产bug的数目可以占到绩效占比的很大程度.

    测试角度释疑:

    生产BUG超出预期,可能是因为需求没有做好,产品和客户要的不一样;生产BUG低,可能是因为客户忍耐性高或者水平不足或者你们的产品客户买来根本就没有用。所以生产BUG不建议作为度量目标,因为你无法预期客户的行为。

    度量目标通常是在可控的范围内制定,无法受控的度量目标就是在给自己挖坑,有过实际经验的兄弟姐妹都应该懂。


    2、用例编写
    详细的用例会覆盖客户的各种实用场景,保证在测试过程中尽可能的发现所有的真实bug,而优秀的用例编写又能让测试用最少的时间,完成测试。所以符合规范的、考虑全面的,有逻辑条例的用例编写,是kpi考核的关键参数。
    这条其实会和很多人认为的bug级别有关联,有些管理者认为能够发现高级、严重bug的工程师是优秀的,实际上,如果程序真实bug没有严重bug,你又何谈发现呢?但是不管有没有,你的用例应该覆盖的到严重bug,也能考虑到各种复杂场景,这个才是更重要的。

    测试角度释疑:

    测试过程也是有时间和成本制约的。

    测试人员写用例,也需要考虑花费的时间。而且前期的需求、设计文档是否真的和实际产品一致,在测试用例上的投入是否值得。这个话题太大,我也很难细说。

    从我的实际经验来看,开发人员写的文档很多都是用处不大的。根据开发文档写测试用例很多时候很难做到,而照着软件写用例,同样的实际我可以发现更多的缺陷。所以测试用例的编写在实际工作中很多还是在测试人员的揣度思考下进行,既要符合KPI的要求,又不要太费时间,还要对得起自己的职业道德,总之不是实际遇到此情况的人员,很难具体的评论说明。


    3、bug描述与定义
    发现了BUG如何第一时间周知相应开发,如何清晰的表达清楚bug内容,如果简介的描述出bug复现的场景。
    如何总结出导致bug的真实操作原因和背景。这些是一个测试人员能力高低的重要标准。
    优秀的工程师对于非必现问题的定位高效,排除无效操作,去除掉障眼法,找出真正必现的使用流程,问题的本质,大大提高了bug的解决周期。
    举个例子 初级工程师“点击下单报错”高级工程师“在选择多规格产品,有优惠的情况下,选择下单报错”

    测试角度释疑:

    测试人员发现缺陷通常会第一时间提交到缺陷库中,具体的分析处理是事后的事情。测试很多时候一天发现几十个的缺陷,不可能每一个都和开发人员沟通确认,通常只有在缺陷过于严重,无法继续测试的情况下,才会联系开发人员。

    我通常不会去理会缺陷发生的原因和背景。因为我主要做的黑盒手工测试,产品对于我来说就是一个无法探知内部细节的黑匣子,我只能通过一些操作,感知发生的回馈,此回馈如果和测试用例的预期不符,那么就是缺陷。至于为什么发生,那应该是开发人员关心的事情。

    测试人员更关心的是发生了这个缺陷,是否其他模块同样会发生,是否进行不同的操作会发生同样的缺陷,是否此缺陷会引发其他的缺陷发生等等。测试人员更关心如何通过发生的缺陷找到更多的问题,而不是去关心缺陷为什么发生和如何修复。

    初级测试和高级测试,对于同一个问题的提交应该是一致的,这个是测试人员的基本能力。不要认为一个问题不同的测试工程师会有不同的提交,缺陷本质都应该一样,缺陷发生的模块,操作过程,严重性,截图等等。

    我个人不建议测试人员对缺陷提出处理意见,比如打印有问题,测试人员应该提出的是无法打印,可以说打印控件无法加载。如果更进一步的提出使用A打印控件更好个人就认为有些过了,因为测试人员的关注点一定是缺陷本身,说多错多,只能给开发人员留下测试人员开发能力不行的借口。


    4、BUG生命周期跟踪与推进
    对每一个BUG的产生、经过、结果都有良好的沟通,并了解问题的真正原因,记录归纳并协助其他团队总结分析。

    测试角度释疑:

    测试有操作不明白的地方可以询问开发人员,开发人员对于发现的缺陷有不明白的地方可以问测试人员。了解问题的真正原因个人认为应该是开发人员而不是测试人员的责任,因为通常测试人员并不会负责处理缺陷,所以真实原因只有开发人员知道。通常一次系统测试过程,会发现百级甚至千级数量的缺陷,分析过程实际是一个很大的工作量。


    5、需求审核
    作为整个研发中心的一员,在需求评审阶段给出合理性建议,提出需求遗漏的问题或者逻辑错误或者质量风险,都是一名高级工程师必备的能力。也是有效降低后期真实bug数目。
    6、测试报告
    定期整理需求测试报告,分类、总结,风险预估。有效的保障整个需求能够持续,安全顺利的进行是高级工程师重要的考核方向,给开发团队和产品团队做kpi数据支撑以及需求总结。
    7、工作效率管理
    如何有设立自己工作的时间计划、优先级安排,以及排期后准时达成,时间预期排期的准确性等情况。

    测试角度释疑:

    至少在我的经验里面,需求大部分并不能提供太有效的信息,顶多知道有什么功能,大概内容是什么。我主要做系统测试,系统测试的参考就是需求规格说明书,但实际对我来说,绝大部分项目需求并不能给测试人员一个很好的参考,需求评审只能发现一些比如性能指标不合理啊,功能说明在各个地方不一致,数据库设计有问题等等,对于最后的测试过程并不能起到决定性的作用。当然了,可能其他的公司会有需求写的很好的,可以对测试人员的测试过程起到很大的指导作用。


    总结:
    上文有些东西是不好量化的,但是不能因为不好量化,就去量化没有意义的量化,用bug数目考核。
    上文只是从有没有好处的角度分析bug数目。并没有说统计坏处,这个大家可能都有经验。不提也罢。
    反是保障测试中发现的bug尽可能接近 真实bug的有效手段和方式 ,是值得考核和提升的。
    最后:
    经过这个事,详细的思考总结了下测试工作内容及绩效管理,对自己是一个记录和成长,也希望对大家有帮助,引起讨论,更希望大家给些意见。

    测试角度释疑:

    测试的KPI是很多测试人一直的考虑的问题。测试出数据的地方通常只有测试用例和缺陷,所以从度量角度只能从这两者考虑,里面还划分很多的属性,比如严重性等,不是测试人员通常没有必要了解这些内容。

    在测试的角度,从来不存在真实bug。我想也不会有哪个公司用真实BUG去考核测试人员。


    其他的就不多说什么了。

    其实写这么多,主要是太多的开发人员对于测试人员的工作不理解,此文就是,所以希望看到此文的无论开发人员还是测试人员还是其他过客,能了解测试人员多一些就多一些吧。

    另外,很多的回复内容仅以自己的工作经验为准,个人并不保证全部正确,每个人对于同一个事件有自己的角度和看法是很正常的,工作不同,具体工作内容不同,对事物的看法不同也很应当,本人只是说明了自己的工作实践和自己对于测试工作的一些思考。

    就是这样。

    over。

  • 别人对我的测试评价

    2018-05-27 15:23:36

    很久没有更新了,现在主要在知乎,链接 https://www.zhihu.com/people/qqrrm ,欢迎大家去访问。

    正文:

    大前年的时候,公司离职的同事,给我推荐了他所在的公司,说要招测试管理,问我是否有兴趣,我就去面试了。当时还是比较急的,当天下午给他们发了我的电子简历,接着我打车就去面试了,没有怎么准备,而且当天有点感冒,状态算不上太好。
    那是一家小公司,开发不到10个人吧,做什么忘记了,但是待遇相当不错,我的同事去那里工资翻了一倍,就是会很辛苦。
    到那里有两个人面试我,一个应该是老总之类的,一个应该是开发主管。当时聊了两个小时左右吧,反正最后我出来的时候渴的不行,在他们的写字楼下买了一瓶水。

    大概的过程有些忘记了,我应该说了一些自己的测试理念,他们两个人感觉对于测试都不是很懂,总要往自动化测试上说,认为自动化测试才是测试,可以解决大部分问题,而我的观念是应该给开发更多灌输测试观念,测试只能保证保底的质量,开发或QA才能真正的提高质量。测试过程要一步一步来,不要一开始就想着做自动化测试,从黑盒测试开始,慢慢提升,一下子到自动化测试效果未必好。当时的自我感觉作为十年加的测试人员,当时聊的都是干货和自身体悟,没有什么忽悠的成分。

    第二天的时候,老同事告诉我面试没有过,我询问原因,给出了下面的答复。


    ------------
    XX说你这10多年没有属于自己真正的知识体系,没有系统的研究过测试方面的技术,还停留在对工作的应付上,不积极主动。
    ------------


    当然了,也许我是实话说多了,比如我承认在当前公司测试工作不多,测试处于辅助位置质量的主力是开发,出现问题应该职责分摊,这些内容也许在开发那边的看法都是减分项吧。自认体系之类的个人还算不错,2007年软件评测师刚出来就考了,市面上的测试书籍也是看到基本就买了,软件项目管理师也考下来,公司本身CMMI3、ISO9000之类的也都熟悉,javaeye,51testing,infoQ也是基本每天都看,但是在别人那里还是评价这么差,这就是自我感知和他人看法的区别吧。

    最后仍然给了他们公司一些建议,不知道是否他们找到了合适的测试人员。


    ------------
    不积极主动的锅我可以背一半。但是测试体系和技术,自认还是够测试人员的行业标准的。

    昨天感觉X老师他们更多的关注于自动化测试等方面,但是在没有体系和公司积累的情况下,自动化测试是不可能开展的。外人觉得自动化测试等很高大上,但是昨天就和他们说了很多了,小公司还是从头来,建立研发体系,加强质量控制,最后才是开展更高级的内容,测试是需要成本的。有时间可以和X老师他们建议一下,首先建立开发规程,先找几个测试人员,把现有程序稳定后,再涉及更多方面的测试内容。

    了解测试的开发人员不多,昨天的X老师他们也未必知道测试是应该如何进行的,等以后有你们公司有开展相关测试工作了,慢慢我想他们会了解测试方面的内容的。测试和开发还是有很多不同的地方的。
    ----------


    算是一个记录吧,本文结束。

  • 签到1000天了

    2017-07-15 22:33:28

  • 太原小吃

    2016-09-27 20:35:44

        去年接了一个项目来过太原,但是当时的客户太精明,天天早上7:30接,晚上18:00放回来,一直没有时间出去逛逛。
        今年有个项目没人,第二次来太原了。这次我的事情不多,每天有大量的时间,可以到处看看了。
        在大众点评看了很多的太原美食帖子,花了两天把自己感兴趣的小吃吃了一遍,做一下记录吧。

        太原的小吃基本在柳巷、帽儿巷食品街附近,很方便就能在一起吃到,就是住的地方离的有点远,每次只能吃几样。自己的肚子还是太小啊。
       



    未完待续。
       
  • 发红包怎么测试?

    2016-09-20 10:17:40

    在论坛看到有人问“发红包怎么测试”,就随便写了写,仅供参考。

    下面是原文回复:

    很麻烦的啊。
    参考微信红包随便说说,只能是一个大概的思路,而且我基本不怎么用微信,所以更具体的,还是应该参照开发人员的需求设计文档。

    一、向单人发红包
    发的人:
    1.单红包。就是等价类了,比如限定数字,0,随机数值,最大值,小数点后几位等。
    2.留言。不录入,最大录入,超长录入,特殊字符等等。
    3.出钱相关。比如超过零钱怎么办,领取后是否扣钱等等。
    4.发送的信息的保留,接收后的显示处理
    5.一些异常处理,比如网络断了
    6.安全
    收的人:
    1.是否及时能看到。看到的内容是否和发的信息一致
    2.放置不动,最后超时处理
    3.接收后的效果等等
    4.收的钱是否进入了钱包等等。

    二、群红包
    更多的内容,比如最多多少人,平均分配还是随机分配,随机分配是否是真随机,随机后是否确实把全部的钱都正确的分割了。等等等等。

    我说的比较简略,但是慢慢写,写个千级的测试用例应该不算太难。

    其实没有需求文档照产品测试总会遗漏的,我想红包这样的需求,不会在需求文档中只有一条“需要有红包功能”就完事了吧。

    PS:真的有这样的需求。我在测试一个移动版软件,标书里面真的就一句“软件应该有离线采集功能”,但是离线采集应该采集哪些东西,采集的数据如何整合到产品里面去,都木有了。现在开发在做离线采集功能,我这边写测试用例和测试一下移动框架,顺便来这里灌点水。答案仅供参考。
  • 记一次性能测试过程

    2016-01-30 20:59:55

        去年的时候,一个项目经理生小孩,公司待遇不好新人都跑光了,老人手里都一堆的项目忙不开,实在没有人了,最后找我接手了此项目.
        去年下半年,就和一个开发一样,写代码,见客户,现场实施维护,做需求.测试的工作几乎都放下了.
        当然了,公司测试方面有事情,还是需要找我们测试处理的.
        上周五下午,突然说要测试一个项目,还说老总很重视,周一就要结果.
        这个事情本来和我无关,是我们集团的另外一个G子公司负责的,他们主要开发硬件,对软件不了解,所以最后这个活儿还是需要我来做.
        东西不很麻烦,就是测试一个webservice接口的性能,开发人员是我们的部门副经理L,他主管研发中心技术方面的工作,我开发方面有问题,也经常询问他.我原先测试过类似的接口,所以觉得这个应该不算麻烦.
        接口说明文件给我了,客户的要求很简单,50并发3秒内就可以,那就测试吧.
        但是实际做的不算很顺利,本来想在G公司的的机器上安装一个lr,用他们的机器测试,但是lr怎么都安装不上,换了win7/win8/虚拟机都不行.最后没有办法,用我的笔记本测试.因为我们子公司公司要求网络物理隔离,所以网管不给我开通网络,最后没有办法使用他们的wifi走无线进行测试.
        开始测试的时候,文档写的是https接口,但是我访问网址没有wsdl内容,去问L,L说https的不行,我给你http的吧,http访问就没有问题了.这个时候已经下午4点了,我还以为周六周日要加班,问他们的经理说加班能打车不,她既然说不是有公交吗.我当时就想骂人了,外面零下20多度,我个人义务给你们帮忙,打个车都不行(公司很偏,公交半小时一趟,有两次都是等车太冷,最后我都打车走的).好在后来他们的研发副总说,接口测试需要调第三方的接口,那个需要花钱的,所以尽量少测试.
        那就好办了,原先按照测试的要求,需要慢慢持续压的,但是要求少测试,那就50并发一次完事.这样加了会班,晚上7点弄完了,大概只用了200多次接口调用吧,基本符合客户要求.写测试报告,给一圈领导检查,没问题了,回家,耶~~.
        事情这么简单结束,我就不用写这么多了.这件事情我们老总还是很重视的,一直督促着,客户那边也有测试,突然告诉我说,客户那边的测试结果很糟糕,根本不满足需要.
        既然事情是我做的,所以最后还得是我来处理.
        客户给我们的邮件有错误说明,但是我既然看不懂,最后和客户建了一个QQ**流了一下,发现他们用的是java vuser.我知道lr可以使用java和vb,但是第一次看到真的有人用java写lr脚本.有交流就好办了,两方把lr测试脚本交换,大家都用对方的测试,果然我这边测试也出现了同样的问题.
        其实出现问题的原因很简单,他们使用的https的网址,我使用http的.我问了我们的部门经理,到底使用http还是https的,结果他告诉我必须使用https的,因为客户就是这么要求的,那么当时测试的时候怎么不告诉我啊.
        lr的c风格的vuser测试https还是比较简单的,感觉lr直接调用了系统的证书;客户那边的java vuser就很麻烦,必须进行证书转换,好在有baidu,还是能搞定的.
        测试过程也总出问题,lr不能使用线程压,一用线程就组件错误,只能用进程压,但是进程方式vuser就经常会崩掉,在网上找了很多的内容,改了一堆的参数都没有解决.其实这样也是很正常的,进程方式,比如我用50并发,就是50个mmdv.exe,一个大概3~5%cpu,5~15M内存,我的笔记本烂的很,还是酷睿2,一跑cpu就瞬间100%,应该使用多台机器做负载,但是我嫌麻烦懒得弄,就这么坚持测了.最后的解决方法就是出错就手动继续run进程,反正就是保持50在线并发,磕磕绊绊的过来了.
        L还总在质疑测试方法是否对,lr是否有问题,说他用程序写测试没有问题.我最后告诉L,所有的测试人员都是这么测试的,即使我说测试通过了,客户那边使用同样的方法测试,结果还是不会通过的.
        反正最后测试的结果,我们调用的第三方接口速度就很慢,结果给了客户,那边也没有说什么,继续怎么样就不清楚了.
        其实从测试过程说,一个很简单的接口,lr的代码不超过20行,但是周围一大堆的问题很难处理,比如网络总坏,客户那边还总在催,开发人员还不信任测试结果.一个很简单的东西,弄的麻烦死了.
        年前应该没什么事情了,年后总觉得这件事情还会继续.
       
  • 缺陷就是缺陷,不是其他

    2015-11-13 23:08:30

    http://bbs.51testing.com/thread-1047880-1-1.html

    看到过很多的观点,认为缺陷有分类,比如从严重性分类,比如从优先级分类,比如从阶段分类,比如从属性分类等等.
    但是,实际在我看来,缺陷就是缺陷,缺陷的属性很单一,就是到客户那里,认为这里有问题,就是缺陷,其他都是开发/测试等附加上去的含义,从客户角度并没有太多的意义.
    比如很多人问过,无法重新的问题怎么处理,其实在我看来,并无太多的处理意义,还是看是否可能对客户有重大影响,测试人员可以发现这样的问题,客户也可以 发现,但是很好解释,让客户重现一次,无法重新就应付过去;等客户再次发现的时候,再处理也不迟,如果客户发现了不再提出,说明他不重视,所以从成本角度 看,可以不处理;如果用户反复提出,那么说明客户重视,自然要花时间和精力去处理.其实本身来说,,无法重现的问题,很多时候即使测试人员发现了,开发说 修改了,也无法确认是吧.想想微软的蓝屏,大家心里就应该清楚应该怎么办了.
    还有人说发现了别人没有发现的问题,所以这个测试人员的水平很高.其实呢,这个是两说的问题,第一就是测试人员经验到了,可能发现一些新手没有发现的问 题;或者就是测试人员灵机一动,或者就是随机测试发现了而已,这样的问题,测试人员都很难发现,除非有大量的用户在用,否则我想客户发现的几率比专业的测 试人员会更小.当然了,这样的问题会让测试人员自己心里很爽的,<测试之美>第一篇就说的这个问题,真的很符合啊.
    当然了,我说这么多,并不是否定大家对缺陷管理的意义,产品的质量还是需要测试人员尽可能的保证的.只是给大家提供另外一个客户考虑的视角,缺陷的严重性/优先级等等都是承建单位确定的,甲方真的未必会在乎这些东西.

    一个缺陷,对于测试和客户的意义不同 .比如发现一个严重的问题,但是也许步骤很复杂,发生几率很小,客户几乎不会触发缺陷,那么对客户的意义也许不大;测试人员一个建议,到客户那里也许就是 需求;一个文字上的轻微缺陷,客户可能就认为是你对他的极其不尊重,软件都直接给你废掉.
    优先级也一样,开发人员的优先级和客户的优先级是两个东西.
    缺陷其他的附属也有同样的问题存在.
    测试、开发视角不同,所以会有严重性、优先级的区别,但是客户的视角没有一个统一的定义.客户提交的缺陷,也许经过测试/开发一分析就没有掉了.
    当然了,大部分的情况下,测试发现的问题未必会到用户那里,而且现在beta版横行,也解决了很多的类似问题.
    这个仅仅给大家一个思考,每个角色,对自己的工作都是有观点、有阶级的,一些事情未必较真.

    近期公司刚完成CMMI,其实有很多想写的,也写了一个框架,但是没有心情整理,有时间再说吧.


  • 测试回复集(一)

    2015-11-13 23:06:51

    其实一直发现自己挺阴暗的,喜欢吐槽,回黑暗向帖子,收集一下自己的回复吧.


    <如何让别人看懂自己的测试用例>
    让看的人先写一个他自己看得懂的,你再按照他写的模式扩展.


    <怎么给公司搭建缺陷管理平台>
    随便找一个搭上就可以了,麻烦的是让开发人员用。

    <项目多大才适合做自动化测试>
    主要看成本和收益,比如你的软件只需要测试一次,那么就没有必要测试自动化;如果软件变更不多,需要进行多次测试,从成本收益比看,自动化测试可能就更合适.
    自动化测试个人感觉主要不是为了发现问题,而是保证在软件变更后,不会影响原有功能.

    <软件测试与售后>
    售后很麻烦的,就是客户的出气筒,而且要经常出差,发展前景也不好,其实觉得售前比售后好,但是也要出差.

    <独立去客户测试需要测试哪些内容>
    谁让你干活的,向谁要需求,没有需要至少要操作手册,再没有去问开发人员业务流程.
    了解需求后,根据需求写测试用例.实际测试过程中对用例进行补充.
    测试那些方面的内容,请去和项目经理确认,比如功能/安全/性能等.
    具体的测试用例内容,论坛里面很多,多找找多看看就可以.
    业务方面除非开发过或测试过的人,否则没有人可以帮你的.

    <验收用例怎么写>
    我自己写验收用例的时候,不考虑异常,只考虑常用场景和正常的操作,分支也根据需要不用全部走到,但是需求规格和合同要求要全部覆盖到.
    用例粒度可以粗一些,最好详细说明操作步骤和录入数据,因为操作的人可能不是乙方而是甲方人员.
    总之,一切以安全简单高效为主,只要客户通过验收即可.
    验收用例这种东西吧,还是看客户的,有的要求的多些就多写,少的就随便写点对付过去.
    其实,验收用例本来就应该是甲方或第三方提供的吧.

    <测试用例执行结果和编写不一致怎么办>
    简单的就是提交缺陷,复杂的参考下面的内容,仅仅作为参考.
    1.判断是否预期结果是错误的
    2.再次进行验证,包括各种环境,条件,试出各种错误出现的方式,并了解引发错误最简洁方式.
    3.如果原先的用例没有问题,提交缺陷.
    4.再次进行思考,是否可能会有其他的地方出现问题,探索性测试,需要的时候补充用例.
    5.打开编译器,把bug改了
    6.缺陷自己验证关闭
    7.告诉程序员,you can't,i do.

    <如何确保测试用例已覆盖全面>
    用例评审,找各个方面的人去审核用例,大家都说没有问题了,签字盖章打基线.
    谁敢说不全,没有覆盖到,喏,你的签名在上面呢.
    是否覆盖到,很多时候不是一个技术问题,需求全/设计全/单元测试什么都全,到自己这里,想不全都很难的吧.

    <缺陷单是否需要给质量部门>
    你不给质量部数据,质量怎么能改进啊.
    对一个程序来说,QA对质量的把握更宏观全面些.

    <面试题:A+B写测试用例>
    需要确定a和b是什么,那个+符号代表什么,接着就是不同的玩法了.
    比如a,b有nil或等价的东西.a,b超长,a,b非对应类型,不同的客户端同时发a,b,a,b发送后断掉,发a后隔很久发b等等等等.
    主要从几个方面
    1.正常
    2.数据异常
    3.客户端异常
    4.服务器异常
    5.网络相关
    6.多用户相关
    等等等等,慢慢想,能想出很多东西的.

    <面试题:进行资料收集整理>
    应该是让你google或百度出来xenu和loadrunner的资料给他们发过去.
    是否他们想用这两个工具,所以干脆让招聘的人做整理.





  • 测试转开发一样不爽的吧

    2015-11-13 23:05:35

    http://bbs.51testing.com/thread-1073876-1-1.html

    看到很多人说开发转测试不适应,其实测试转开发也一样的.
    当年单位大裁人,20个测试只留下2个,我只做了一年测试,当然在18人之列.
    当时找了面试通过了两份工作,一个Linux下c开发,一份继续做测试.我贪图熟悉就继续做测试了.
    说真的,现在看,开发的前途应该更好些,测试一直有些不死不活的样子,反正10多年也一直混下来了,而且还有继续下去的样子.
    近期有一个项目,项目经理生小孩,公司待遇太差,人走的太多,其他开发人员都忙,没有办法,项目交给我了.
    测试的好处一是压力小,二是不出差.在公司10多年,就出差过1次,结果为了这个项目,两个月出差了两次,每次去的时候说3天5天,结果都半个月.
    程序到处都是问题,客户到不错,每天请客,但是我不喝酒啊,而且也基本不会和人打交道,还要和人到处赔笑脸累死人了.
    好容易客户应付过去了,回单位还要修改一大堆的问题.客户提交的新需求,自己搞不定,还要求别人帮忙做几个模块.
    原先每天工作个半天,看看小说就打发过去了,现在每天忙的和狗似的,总有问题要处理,一天客户打10多个电话,还要随时和领导汇报进度情况.
    想来混日子,还是测试好.开发更合适有进取心的人.
    现在每天都在学一大堆的东西,感觉再过几个月,等项目经理回来,自己大概就能当一个合格新手程序员了.
  • 这几天的程序员生活

    2015-08-06 23:20:33

    一直做测试,开发的活儿也干过,比如写个嵌入式OCX,做个演示程序之类的。
    这几天修改一个程序,弄的我彻底混乱了。

    需求是车间提出的,XX部需要定期传我们公司的产品信息到他们那里,简单说,就是他们分给我们公司一些认证码,我们公司的产品有产品码,还有一个sam码,程序需要把这三个码(产品码、认证码、Sam码)关联,公司记录产品生产记录(消耗三码)以及销售记录,定期把记录生成标准xml文件上传。

    原先公司有人写过程序,但是生成的xml不符合标准,所以上面就给了我们一个程序,但是程序本身有问题,比如销售过的记录,仍然可以重复销售,车间反映程序不好用,每个月生产大量的产品(几百到几万),一个一个录入太费事。希望能用条码枪扫描的方式快速录入。

    正好这段时间我没有什么事情做,领导就安排我做了。

    程序是用python的,使用的pylons框架。原先我只是大概的了解python,并没有具体的写过程序,这次刚好熟悉一下。

    程序有setup的安装包,安装是好用的,里面使用了nginx。领导不知道从哪里弄来的src,行,就分析改吧。

    第一步就坑了我,src文件根本无法运行,查找了很多的资料,最后都无法从源码执行。好在setup的是好用的,我就只能在src中修改,再发布到安装程序中。后来他们说,src的版本是比较旧的,但是也没有办法,因为安装文件中是pyo的,看不到源码什么样,我后来也去网上找了反编译插件,但是都是linux下的,算了,不费事了,版本旧就旧吧,干活要紧。

    接着就是大概的分析程序,了解pylons的都知道,这个就是一个胶水MVC框架,基本只负责model、controller、routing等内容,我用的程序View部分采用的Extjs。

    一通下资料学习,好在程序逻辑不是很复杂,就是几个mysql数据库的表,对应几个js页面功能。使用fiddler很容易就能知道哪个部分对应什么页面。剩下的就是动手修改了。

    里面的坑就不说了,反正有源码,主要就是照葫芦画瓢,弄出来再说。很快第一版发布了。

    安装到车间,第二天就来找了,IE6下不好使。我都用Firefox的,大家都知道,用firebug调试很方便,没有出问题啊。结果我在IE下一用,真的有问题,可能是我原先复制的ext控件,firefox支持,IE6不支持,重新把控件写了一遍,这次可以了。

    接着发布,人家又来了。说用扫描枪不好使,每次扫描后,没有保存扫描的记录,而是保存的下拉框中第一条记录。

    我开发的时候,没有用扫码枪,因为我知道扫码枪的最后有一个Enter事件,所以我都是用键盘Enter替换扫码枪,在我这里是没有问题的。赶紧借了一个扫描枪测试,确实有问题。

    接着就是调试,弄了一天都没有弄好,Combo控件本身就应该是存在问题的,Ext对combo的控制本来就很乱来,每次扫码枪扫完后,焦点我都挪走了,但实际combo上还是有焦点,而且焦点是最后的鼠标位置,后来我实在搞不定,就听了别人的意见,把combo换成了text,这样就不会有问题了。

    接着继续发布,结果人家检查的时候立刻就打脸了,比如原先1234的产品码,用扫码枪扫描,自动关联获取sam码和认证码,我测试的时候,都是随便输入比如aa之类的没问题,但是人家检查的时候,用12录入就获取到了,靠,我马上想到了,当时对ext不熟悉,使用了data.store.find,这个是带正则匹配的,换成findExtra就没问题了。

    现在车间还在用,其实如果没问题,应该还是比较好用的。

    只是在这个过程中,发现自己还是遗漏了太多的内容。如果从测试人员的角度,这样一个程序,写测试用例,一点点的测试,根本不会出现这样的问题。但是自己当了程序员,就第一时间想着把功能完成,最后并没有按照系统的方式去测试,都是随便大概的跑跑就那么样的,结果就不停的有小问题存在。

    看来开发和测试的差异还是蛮大的。一个很小的程序的修改,我觉得5天应该可以搞定,但实际10天了,还是可能会有新需求、新问题存在。

    纪念自己的程序员之旅。

    PS.
    现在一周过去了,没有人来找我,应该大概不会有什么新问题了.

  • 关于《××社保系统》测试的一些想法和建议(2003年1月)

    2014-12-23 17:53:58

    2003年初,到了现在的公司,那个时候公司还没有测试人员,所以就下到了项目组中做测试,不到2周后,根据项目组的项目,写了这份总结文档。
    现在看来,那个时候我的一些想法和现在几乎一样,10多年过去了,其实感觉测试并没有太多的发展,至少在我的角度,看不到测试有进一步的可能,也许测试人员终将消亡,全栈工程师取代一切。

    直接copy会出错,感兴趣下载看吧。

    测试总结.doc(80.5 KB)社保系统。
  • 测试别被敏捷忽悠

    2014-06-20 18:54:44

    这篇帖子原先发表我在博客园的blog里,还有一些讨论,想想还是在这里也发一份吧。这个应该是几个月前的事情了。

           个人对敏捷一直很关注,其实很正常的啦,作为一个资料的深度收集爱好者,在满眼都是敏捷的今天,想不关注都不可能啊。

            腾讯无线研发部副总监张鼎(dylan)写了一篇《反思:别被敏捷忽悠》,里面的观点我个人很喜欢。这个应该是对dylan的访谈整理,也许会和dylan的意思有偏差,但假设不是记者太无良,dylan的思想应该是反敏捷的,至少对敏捷思想有很多的质疑。

          提炼一下dylan的观点:

    1. 敏捷方法会拉低质量标准。
    2. 传统瀑布和敏捷方法没有本质差别。
    3. 互联网软件和传统应用型软件开发没有本质差别
    4. 在一些情况下,文档优于沟通。

          上面的观点是我总结的,具体内容大家可以看原文,有误读的地方请原文作者谅解。

          其实对于敏捷,我的观点一直很矛盾,对开发人员这应该是好的,但是对于测试则未必。

          敏捷从根本讲应该是开发方法,不是方法论,所以很多人可以把敏捷嵌入到CMMI、RUP等开发流程框架内。换句话说,敏捷说了开发人员应该怎么做,但是没有说比如测试人员做什么,也就是说,无论XP还是Scrum等,基本都没有考虑测试人员在其中应该做什么。当然了,有些开发人员会说,还要测试人员做什么,有TDD、BDD等,测试人员滚一边去玩吧。但是测试人员真的可以缺席吗?

          测试人员其实一直努力的在希望嵌入到敏捷开发过程中,比如段念的《什么是敏捷软件测试》,朱少民的《究竟什么是敏捷测试》等,甚至有专门的书籍说敏捷过程中的测试,但都像是CMM的效颦TMM一样,没有太多的信服力。感觉就是在敏捷过程中,强加了一个测试角色,做和传统测试差不多的活儿,看上去很美,但是总觉得相当的不协调。

          测试是什么,测试是质量的控制和度量。就和帖子最开始的dylan说的一样,敏捷实际在降低质量基线。敏捷的说法是从根源上,通过TDD、BDD、用户现场确认等方法,解决质量确认问题。认为通过用户认证了,就是好的。但是用户不是专业的测试人员,对质量等的认知,其实是有一定偏差的,敏捷方法貌似总在有意无意的忽视这种质量偏差。

          在软件工程中,有一个基本的观点,不要让开发人员测试自己的程序,但是在敏捷过程中,测试角色是大部分由开发人员直接兼任,当然带包装的--测试驱动开发,但实质还是开发自己负责自己部分的质量问题。产品的生产者是开发,质量的提供者是开发,难道质量的确认者仍然是开发?或者再加上用户?这样做是否会出问题?

          从根本说,敏捷方法的研发者都是开发出身,对测试我想未必有深入的了解,敏捷方法其实规定的都是开发人员的行为,但是问题就在于没有留出测试验证的位置, 测试人员即使挤进去,也有很多的力气无法使用上。比如敏捷测试过快,是否有必要重复的做开发人员做过的测试;敏捷变更太多,测试人员能否跟上变更的节奏等等。

          我这里仅仅是提出问题,并没有解决问题。敏捷开发我还是仅从大家的资料中了解分析,测试也更多从理论和别人的文章中获取敏捷测试相关内容,也许我的整篇文章观点都是错误的,但是至少希望能给测试人员以思考,至少能提出一个让我认为合理的、可以容易确认执行的敏捷中的测试过程,也就不枉我打这么多的字了。


  • 宋词分析改编版(ruby)

    2014-02-02 23:50:10

    很久之前写的了,在别的地方,blog多就总忘,还是在这里留一个备份吧。现在是ruby2.0版了,有时间还是应该重构一下。还有,我专门买了一个移动硬盘安装ubuntu,笔记本也用wubi安装了一个,所以现在主要在ubuntu下学习ruby,坑就少多了,大家也可以学习一下ruby。



    上一次我写的宋词分析,是在Windows环境下的,缺省编码是GBK(936),所以在处理UTF-8的时候,需要转换为GBK,再进行处理分析。 
        不过现在已经是ruby1.9版了,那么就改一下,在uft-8下处理程序,主要就是把原宋词文件内容从gbk编码为utf-8,再进行相应的处理,dos下需要chcp 65001转换为utf-8编码,再执行才可以看到正确结果,否则就是乱码。 
        我用的SciTE,在Options->Open Global Options File中,code.page=65001,output.code.page=65001去除前面的#,就可以正确处理utf-8文字了。 
        嗯,Windows就是麻烦,Linux和mac一直想玩玩,但是单位无法上网,需要联网的东西太费事了。 
        还有就是改写为utf-8版后,计数和gbk版的不同了,gbk版的,和原文的计数一致,utf-8版的,一是计数多了,二是很多后面的也提到了前面,不知道为什么,也许是gbk->utf-8转换的时候,一些文字出现问题了吧。 



    #coding: utf-8
    require "iconv"

    NUM1 = 2 #分词长度
    NUM2 =500  #显示大于多少的记录

    def splitword(s,l)    #分词,s是字符串,l是字符分词长度
      lt  = s.length
      k = Array.new
      0.upto(lt-l) do |i| 
        k<<s[i..i+l-1]
      end
      return k
    end

    t = Time.now

    x = Array.new     #记录分词结果的数组
    File.open("ci.txt", "r")  do |file|
      file.each do |line|    
        line = Iconv.conv("UTF-8//IGNORE","GBK", line)    
        line.chomp!
        column = line.split(/,|。|!|?|、/)          #使用标点分割
        column.delete_if {|i| i.length >10 }    #去除大于10个字的语句
        column.each do |col| 
          splitword(col,NUM1).each{|i| x<<i} if col.length>NUM1 # 分词
        end 
      end
    end

    h = Hash.new
    h = x.inject(Hash.new(0)){|hash,x| hash[x] += 1; hash} #把数组内容进行计数为hash
    h.delete_if {|key, value| value <NUM2}               #去除hash中小于指定数值的部分

    y = Array.new
    y  = h.sort {|a,b| b[1]<=>a[1]}                      # 从大到小排序
    y.each_index {|i| puts "#{i+1} #{y[i][0]} = #{y[i][1]}" }

    puts "运行时间是:"<<(Time.now-t).to_s<<"秒"
  • 近期我所遇到的一些测试情况

    2014-01-29 10:26:40

    我在的公司,可以说是一个作坊,10年前,我来的时候,还没有专职测试人员,那个时候公司就过了cmm2,我现在都不清楚没有测试人员怎么过的。
    我来公司后,测试部就组建了,有的时候人多,有的时候人少,多的时候7、8个人,少的时候快2年时间,就我一个测试人员。
    当然了,从上面情况也能看出,公司也不重视测试,我个人懒的换地方,我所在的城市,专职测试可以去的地方也不多,也就这么对付着过来了。
    公司还是有一定规模的,大概70多开发人员,cmmi3、iso9000等等也都有,看上去比较正规,当然了,在我内部人的看法就是作坊。
    去年11月的时候,我最后一个手下离职了,又变成了光杆司令,当然了,我个人都习惯了,就和主管领导说,给我人啊,虽然没有活儿,但是真的要测试,总不能我一个人做吧。
    嗯,测试工作一直是不饱和的,去年我的实际工作量时间,不超过6、7个月吧,全年很多时候都空闲着,我个人平时喜欢看小说,这也是我不舍得走的原因之一吧,很清闲,可以做自己喜欢的事情。
    其实我去年一年,做的最多的事情不是测试,是给各个项目写测试文档,平时的时候,各个项目组,都不喜欢做测试,只有在项目验收的时候,我测试需要出具测试用例和测试报告,才会找我。或者做测试,但是测试到一半,1、2轮的时候,开发人员就以种种理由闪人了,比如其他项目组要用人,或者去现场开发等等,所以我去年只测试了一个完整的项目,大概1个月的时间,其他都是扔了一大堆的缺陷在哪里,没有理会了。
    当然了,这和公司的情况也有关系,第一,我们主要做行业软件,大部分的时候,开发人员都是在现场开发,边开发边上线,那边就直接用了,很多时候可能不希望测试人员插手,至少测试提出的一大堆问题需要改不是;第二就是很恶心的任务单制度。我们公司在建立项目的时候,就给出了项目的费用和人力计划,要报销等,必须在额度内,但是有一个问题,大家也都知道,开发人员几乎不可能在进度的设定内完成,所以进度一定是不够的,这种情况下,谁还会考虑测试人员?我一直和项目管理部的人说,测试要独立出来,不要走项目内经费,要不测试根本不可能有活儿干,那边一直在推搪。我去年干的活,还有一些费用没有报销,因为超过额度了,研发经理说等下次再做2期的时候,给我转过去,但是2期什么时候,天知道。
    上面的介绍一下背景,下面就是近期遇到的一些情况。

    公司有一个大项目,实际这两年,公司都指望这个项目,所以人力什么的很充足,还是老规矩,现场开发,去年要结项,去写测试用例,需求文档之类的是不用指望了,就是按照软件写吧,反正他们的说法,有就行,看都不看。当然了,写文档的过程中,测试人员一定会发现一些问题,实际软件已经在使用快1年了,个人觉得还是比较稳定的,问题算不上太多。写好后给他们了,至于改不改,和我无关了。

    2014年,这个软件在其他的地方销售成功,根据客户的要求,要做些改动,所以相当于原版本的一个升级。在2014年项目管理部出台了一个决议,说全部项目的计划、需求都需要评审,既然按规矩来,那就做吧,评审计划。既然有计划评审,当然在评审过程中,我作为测试要争取自己的利益和资源,其实当时开了一个下午,项目经理、我、项目管理部、QA,内容不多,大部分时间都在抢资源。虽然测试现在只有我1个人,但是还是说要3个人、1个半月(计划是2个人,1个月)。中间的细节就不说了,其实这个软件是一个很大的项目,160多个模块,业务流程也很复杂,他们开发了快2年,我对原有的版本比较熟悉,新的版本也就是写测试用例的1个月,勉强算了解。

    计划定下来了,人没有啊,找人。在我最后一个手下离开的时候,我就和主管领导说要招人,他的意思是,你测试现在也没有工作,即使招到人,也许过两天就跑了,所以等有工作的时候再说,你看开发组谁没有工作,到时候就支援你。嗯,这次有工作了,就从项目组暂时找了一个人,计划充当测试人员。还少人员啊,就和做软件的项目组说,测试没有人,到时候能否支援,项目经理也答应了。一切看起来挺好的吧。

    正好,有一个其他部门的人,强烈要求做研发,我们的研发副总看,不好推脱(小老板招的人),就扔给我了。嗯,现在有两个测试小白等着我浇灌了。

    既然这样,写ppt,做培训资料,后来看到有项目经理对我的工作比较感兴趣,那更好啊,开大培训,就介绍我们系统测试的工作。

    其实我写的ppt很少内容,只有13、4也,我的ppt原则是简略版的,只要说的内容,就不写,ppt只是一个引导。我第一次讲培训,效果不知道怎么样,反正很多人,20多吧,各个部门都来捧场了,我还以为讲2、30分钟就可以了呢,结果讲了1个半小时,我自己都怀疑自己怎么那么能说的。
    ppt主要内容就是:质量是用户的要求;测试是质量控制和度量,终极目的是验证需求和确认质量;,测试的工作是发现问题;一个软件开发出来后,有一个质量上限,测试的工作是接近上限,但是无法到达,提供质量的方法是开发和质量保证,测试做的工作主要是验证和修补,对质量的提高没有决定性作用;质量成本是有数量级的差别的,越到后期,处理成本越高;任何问题,等到系统测试发现和处理,全部都晚了。

    反正说了很多,效果如何不清楚,培训后,我问了很多人,都说挺好,我想可能还是客气话居多。

    当然了,这个是科普性质的培训,后来我还专门花了一天的时候,给两个新人,做具体测试内容应该如果做的培训,效果如何现在还没有开始测试,不清楚。

    原先说了,我和软件的项目组说要借调一个人,现在人齐了,本来我想测试人员越多越好,就去和研发经理L确认人员,你知道他怎么说吗?一周时间够不够,我当时就思密达了(他们在外面开发,没有听我的培训)。我说,你们的软件开发了两年,不说别的,你培训客户需要多久。L说,客户都知道业务啊,培训怎么用就行了。我说,老大,除了我,另外两个都是新人,业务都不熟悉,1周时间恐怕你的软件做什么他们都未必清楚。反正最后说了很多,他的人我也就不指望了。还有,本来我的计划是在年前,让他们去现场熟悉一下原版软件,这样年后测试其他地方的升级版,大概业务也能熟悉,但是万恶的任务单,他们就是不下,我也无法派工。

    未完待续。回家喽....................
441/3123>
Open Toolbar