分类 TestDoc 下的文章

之所以写这篇文章,主要是大部分测试还是处于弱势地位,线上一旦出问题,大部分人想到的是:你这个没测?基于这点,这篇文章也许可以给你一个明确的答案,这到底是谁的责任。

一、先解决问题

线上爆发重大bug,这时候不是追究责任的时候,而是动员所有可调用的资源,尽快解决这一问题,将损失降到最低。而一般公司在这之前就应该制定好出现重大问题的补救流程和方案以及对应的人员分配。

二、定义bug的性质

解决问题后,定义线上发生的问题的性质,是第三方引起的,不可抗拒的问题,还是自身疏忽导致的错误?且爆发的问题的严重程度,关于bug严重程度的区分,可以参看我的另一篇文章。(传送门:http://blog.jianjiexuan.com/testdocument/42.html

三、分析产生bug的根源

1、需求未涉及,或需求当初定义的不够详细造成。

 这个一般由需求、设计、测试都承担责任,需求的责任最重。之所以说设计和测试也有连带责任,是因为需求评审的时候也参与进去了,而需求都是通过大家一致确认可行通过才执行的。当然,有些公司对于需求评审也不是很重视,也没有专门写需求文档的人,甚至一些小公司直接都是口头表达,这样的需求连记录都没有,实在没办法追责。不过,一般这样的公司也不会追责,如果追责的话,建议设计(产品)、测试一句:你可以刷新简历了。

2、设计过程、开发过程未实现造成。

 这种问题是需求检查到了有未完成的需求,但是设计和开发并没有进行弥补。则为设计与开发的责任,而设计的责任最大。

3、测试过程中的疏漏造成。

 测试过程中的疏漏有2种情况,一种是测试用例没有覆盖,一种是测试用例覆盖了没有执行。第一种参与过测试用例评审的都有责任,但是设计测试用例的人承担最大责任。第二种则完全是测试责任。当然,很多公司根本就不具备评审测试用例或者有专门写测试用例的人,本来管理流程就乱,一人做多种职位的事情,这时候如果硬要追责,建议测试一句:你可以刷新简历了。

4、交付部署中出现问题造成。

 比如版本错误、发布错误、部署错误,一般在设计(产品)、配置、测试经理共同承担责任。

5、私自改动代码造成。

 只能开发哥哥完全承担了。

四、分析总结

 对于这次的事件进行分析与总结,确定是谁的问题后,应该吸取教训,并给出措施,给下次的版本一个参考。

 

其实这套方案肯定是基于自身的流程和管理都非常明确的公司执行。并不适合小团队去执行,小团队建议还是大家一起承担,否则,只会让员工提前离开。如果你不是领导者,愿你不需要看到这篇文章。

 

enlightened每个测试在工作一段时间后,都会迷茫,其实不仅仅是测试,很多工种都会这样,不知道下一步往哪个方向发展,觉得自己在虚度岁月,没有任何进步,开始慢慢的适应了现在的一成不变,这是很危险的,你能看到这篇文章,说明你想改变,恭喜你,你会有收获的。 测试或其他技术工种的发展方向大致是相同的:1、继续专研技术,成为中级测试、高级测试、测试专家等;2、管理方向,这就不仅仅是测试技术了,你得懂得很多团队的东西,最好能有几个证书;3、转相关行业,比如产品、开发什么的。大部分人会选择第一点,而第一点又能细分很多种,白盒的、性能的、数据库的,而我主要讲的是综合的,慢慢的提升以下能力,不管你去互联网哪家公司,你都能如鱼得水。

一、品德心态好

  为什么把这个放在第一位呢?很多人不在乎,认为有技术就行,其实这个不管在测试还是其他方面都很重要,你平易近人,凡事有理有据,不歇斯底里,大家就都愿意和你共事,这样的你也会在这样的工作氛围内更加得心应手,而且测试是需要吵架的,如何把握这个吵架的分寸就很重要,不影响彼此的关系还能把工作做好。

1、首先,我们自己要语气平缓,有些人真的是天生语气就很冲(我身边有这样的人,基本没朋友),如果你是,一定要尽力去更改。虽然也许你本意只是阐述一个bug,但是别人听起来就是责怪,所以这是很头疼的。我之前也有,我明明是在讲bug,开发说你别这么激动,感觉我要吵架,其实真没有(宝宝好委屈(┬_┬)),因为不仅仅一个人这样说,我知道这肯定是我的问题,我肯定是要改的,所以就经常听些舒缓的音乐,看些心理或者周易之类的书,说话的时候每次注意点,形成习惯后,就会彻底改变。

2、讲问题要有理有据,对事不对人,测试很多时候对需求的理解和开发或者产需求的人有偏差,还有描述问题的时候和开发理解的有偏差,这时候难免会起争执。首先,有争执是好事,证明你有自己的想法,你去思考了,你在乎这个需求了,而争执的目的我们要清楚,就是希望产品更好,千万不要带着个人色彩,这样以后的工作大家都会尴尬。但是有争执不能歇斯底里,我们要讲事实摆道理,最重要的一点,一定要倾听别人的想法,坚持己见固然不错,前提是你真的是对的。如果别人说的有道理,你也可以称赞认同,记住,我们争执的目的。

3、对于同是测试的同事,要互相帮助,不要吝啬自己所会的,因为你一直在前进就不怕别人赶超,你帮助别人的同时,也能巩固自己的知识。我经常遇到这样的测试,自己偷偷的学习些技术,为什么说偷偷的呢,因为别的测试走过去的时候,她会迅速关掉正在看的东西(技术类的),首先你学习是好事,但是被看到又怎么了,别人有心也去学,这不是激励你么,再说别人真有心去学,肯定也能搜到,如果无心,看到就看到呗,反正不思进取。还有很多时候新手问问题,很多人会说,就这样啊,点一下写几个东西就好了,很简单的。拜托,你不想说就直说,想说就说清楚。如果你有这些问题,你一定要更改,你的突出不是阻止别人前进,而是加快自己前进的步伐,而且,好的心态,对你整个人生都是有帮助的。相信我。

二、业务熟悉

  作为一个合格的测试,不管你要测什么,你都要了解清楚你所要涉及的业务的所有需求,不能说了解,应该叫掌握、熟记于心。这是一个很庞大的事情,但是你必须这样,因为只有这样,任何一个改动你都能了如指掌,及时进行跟踪,别其他人问起,你却不知道,这样真的很尴尬。

1、熟悉你所测试的系统

  必须非常熟悉你所测试的系统,知道哪些需求是重要的,哪些的次要的,这样才能更好的合理分配你的测试资源。对于需求文档不全的公司,你可以自己编写需求文档,作为自己的参考红本书,有任何改动实时更新,并及时记到脑子里,这样的你,就像上战场打仗的将军,已经清楚敌人的排兵布阵,你怎么能不赢呢?

2、熟悉跟本系统有关的上下游系统业务

  有些系统会涉及到其他系统,虽然我们不需要测试,但是一些需求以及其他系统业务也是要掌握的,这样也可以给自己提供更广的测试思路。也用打仗来比喻的话,这就是需要知道整个国家之间的状态、彼此错综复杂的关系,才能纵横捭阖,在战场上给与一些意想不到的战术。

3、熟悉数据的交互

  熟悉后台与前台的数据交互,这样可以在你提问题的时候,更加有技术性,不仅仅是描述表面的。

三、掌控Deadline

  如果一个版本需求过多,那么开发的任务就多,测试人员要测试的点也就非常的多。这个时候,如果版本封板的时间都是由项目经理或者PM来定,那测试人员就会很被动。而通过测试自己评估需求需要测试的时间及优先级,就能给出一个合理的时间给项目经理或PM,而这个时间最终点就是Deadline。测试要在这个时间点前各种督促开发,根据优先级安排测试,这样可以掌控整个测试的节奏,不需要拼命的加班,也能高效率的完成工作。

四、测试技术

这一点估计才是大家真正想看的,也是对自己镀金很重要的部分,这决定你将处于什么位置。

1、懂得用jmeter、LoadRunner进行性能测试;

2、懂得搭建性能测试需要的环境,例如服务器、redis、memcache等等;

3、懂得一些抓包工具的使用,fidder、charles、Wireshark等等;

4、懂得一些基本命令(数据库、linux)的使用;

5、懂得一些自动化测试,会写一些基础脚本(java、python)进行接口自动化;

6、懂得如何编写性能测试报告并能够进行分析; 

7、懂得一些安全性能测试。

如果你能慢慢掌握以上四大点,基本你走到哪里都不愁高薪了。看看自己缺少哪点,再根据自己的实际情况去学习,祝愿大家都能学有所成!yes

1、【页面/客户端的响应时间】

    响应时间直接影响最终用户的使用体验,从而在很大程度上影响用户忠诚度。是客户发出请求到得到响应的整个过程的时间。

2、【服务器的吞吐量】
    常用的是系统每小时能处理的业务量。例如,最高每小时能接受的网站浏览次数,或者一个电子商务网站每小时能下多少个订单。

3、【最大并发用户数】
    这里的“最大”其实并不是真正的最大,而是在响应时间合理的情况下,能承受的并发用户数。也就是系统最多能承受多少用户同时访问且用户感觉不到页面响应变慢。

4、【能否能稳定的长期运行】
    任何客户都不希望自己的系统动不动就宕机,这会对最终用户造成非常不好的印象,从而给客户的业务带来大的损失。应用服务系统是否能长期稳定运行除了跟服务器的硬件有关系之外,与软件本身也有很大的关系。可利用7*24方式去进行测试。

5、【最大数据规模】
    能保证正常访问的最大容忍数据规模。

6、【服务器后台操作是否会影响前台性能】

7、【什么情况下会导致系统崩溃】

测试用例评审检查单
序号 主要检查项 是否通过
1 《需求规格说明书》是否评审?  
2 是否按照测试计划时间完成用例编写?  
3 需求新增和变更是否进行了对应的调整?  
4 用例是否按照公司定义的模板进行编写?  
5 测试用例是否覆盖了《需求规格说明书》?  
6 用例编号是否和需求进行对应?  
7 非功能测试需求或不可测试需求是否在用例中列出并说明?  
8 用例设计是否包含了正面、反面的用例?  
9 每个测试用例是否清楚的填写了测试目的、步骤、预期结果?  
10 步骤/输入数据部分是否清晰,是否具备可操作性?  
11 测试用例是否包含测试数据及数据的生成办法或者输入的相关描述?  
12 测试用例是否包含边界值、等价类分析、因果图、错误推测、等测试用例设计方法?是否针对需求不同部分设计使用不同设计方法?  
13 重点需求用例设计至少要有三种设计方法?  
14 每个测试用例是否都阐述预期结果和评估该结果的方法?  
15 需要进行打印、表格、导入、导出、接口是否存在打印位置、表格名称、指定数据库表名或文件位置;表格和数据格式是否有说明或附件?  
16 用例覆盖率是否达到相应质量指标?  
17 用例预期缺陷率是否达到相应质量指标?  

那么如何进行测试用例的评审呢?

测试用例评审标准

1、首先要清楚内部评审的定义,是测试组内部的评审,还是项目组内部的评审。评审的定义不同,内容也不会相同。

 如果是测试组内部的评审,应该着重于:

  • 测试用例本身的描述是否清晰,是否存在二义性;
  • 是否考虑到测试用例的执行效率。测试设计的冗余性,造成了效率的低下;
  • 是否覆盖了所有的软件需求;
  • 是否完全遵守了软件需求的规定。这并不一定的,因为即使再严格的评审,也会出现错误,应具体情况具体对待。

 如果是项目组内部的评审,也就需要评审委员会来做了,角度不同,评审的标准也不同。比如:

  • 收集客户需求的人员注重你的业务逻辑是否正确;
  • 分析软件需求规格的人注重你的用例是否跟规格要求一致;
  • 开发负责人会注重你的用例中对程序的要求是否合理。

测试用例评审步骤

 测试用例的评审能够使用例的结构更清晰,覆盖的用户场景更全面;对于测试工程师来说也是一个快速提高用例设计能力的过程。

  1、需要评审的原因

  测试用例是软件测试的准则,但它并不是一经编制完成就成为准则。由于用例开发人员的设计经验和对需求理解的深度各不相同,所以用例的质量难免会有不同程度的差异。

  2、进行评审的时机

  一般会有两个时间点。第一,是在用例的初步设计完成之后进行评审;第二是在整个详细用例全部完成之后进行二次评审。如果项目时间比较紧张,尽可能保证对用例设计进行评审,提前发现其中的不足之处。

  3、参与评审人员

  这里会分为多个级别进行评审。

  • 部门评审,测试部门全体成员参与的评审。
  • 公司评审,这里包括了项目经理、需求分析人员、架构设计人员、开发人员和测试人员。
  • 客户评审,包括了客户方的开发人员和测试人员。这种情况在外包公司比较常见。

  4、评审内容

  评审的内容有以下几个方面(可使用检查单):

  • 用例设计的结构安排是否清晰、合理,是否利于高效对需求进行覆盖。
  • 优先极安排是否合理。
  • 是否覆盖测试需求上的所有功能点。
  • 用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确;期待结果是否有明显的验证方法
  • 是否已经删除了冗余的用例。
  • 是否包含充分的负面测试用例。充分的定义,如果在这里使用2&8法则,那就是4倍于正面用例的数量,毕竟一个健壮的软件,其中80%的代码都是在“保护”20%的功能实现。
  • 是否从用户层面来设计用户使用场景和使用流程的测试用例。
  • 是否简洁,复用性强。例如,可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。

  5、评审的方式

  • 召开评审会议。与会者在设计人员讲解之后给出意见和建议,同时进行详细的评审记录。
  • 通用邮件与相关人员沟通
  • 通用即时通信工具直接与相关人员交流

  方式只是手段,得到其它人员对于用例的反馈信息才是目的。

  无论采用那种方式,都应该在沟通之前把用例设计的相关文档发送给对方进行前期的学习和了解,以节省沟通成本。

  6、评审结束标准

  在评审活动中会收集到用例的反馈信息,在此基础上进行用例更新,直到通过评审。

设计测试用例一般有8个方法,分别是等价类划分、边界值、场景法、因果图、判定表、正交排列表、状态转换图、测试大纲法等

一、等价类划分及边界值

首先这两个设计测试用例的方法一般是一起的,等价类划分即将所有合理的、有意义的或不合理的、无意义的数据分为有效等价类和无效等价类,运用有限的测试用例去覆盖无穷的数据输入,而边界值则是对等价类划分的补充。

设计测试用例的步骤:

  • 划分等价类
  • 细化等价类划分
  • 建立等价类表
  • 根据等价类表划分编写测试用例

其中,当我们熟练了之后,2、3步骤可以忽略

我们以实际例子说明。

需求:

年龄输入框:1-99整数,可以为空

分析步骤:

1、划分等价类

1)有效等价类

①1-99整数;

②为空;

2)无效等价类

①<1的整数;

②>99的整数;

③小数;

④特殊字符;

2、细分等价类(加入边界值)(可省略)

1)有效等价类

①1-99整数,如1(边界),2(边界),55,98(边界)、99(边界)

②为空,空格

2)无效等价类

①<1的整数,如0(边界),-1,-100

②>99的整数,如100(边界),999,无穷大

③小数,如0.1,10.55,小数点后多位

④特殊字符,如!、@、*、%或组合)……&等

3、建立等价类表(可省略)

将输入的数据和预期结果以表格展示出来,下图示例

年龄
编号 输入数据 预期结果
1 1 通过
2 2 通过

4、根据等价类表划分编写测试用例

二、场景法

现在的软件几乎都是用事件触发来控制流程的,事件触发时的情景便形成了场景,而同一事件不同的触发顺序和处理结果就形成事件流。

设计测试用例的步骤:

  • 根据说明(流程图),描述出程序的基本流及各项备选流
  • 根据基本流和各项备选流生成不同的场景
  • 对每一个场景生成相应的测试用例

举例,下面是一个简单登录的流程图

liuchengtu1、根据说明(流程图),描述出程序的基本流及各项备选流

基本流:

基本流1:输入正确的用户名

基本流2:输入正确的密码

基本流3:点击“登录”按钮,程序能正常登录

备选流:

备选流1:不输入用户名和密码

备选流2:输入正确的用户名,错误的密码

备选流3:密码为空

备选流4:用户名为空

备选流5:输入错误的用户名,正确的密码

备选流6:输入错误的用户名,错误的密码

2、根据基本流和各项备选流生成不同的场景(部分举例)

场景描述 基本流 备选流
场景1:输入正确的用户名及密码点击登录,成功登录 基本流  
场景2:用户名、密码为空点击登录程序给与提示 基本流 备选流1

 V表示Valid,有效的,I表示Invalid,无效的。

编号 场景 用户名 密码 预期结果
1 场景1:成功登录 V V 提示登录成功
2 场景2:用户名、密码为空,登录失败 I I 给与错误提示

3、对每一个场景生成相应的测试用例

  用例描述中详细写出测试数据。

三、因果图、判定表

因果图是一种利用图解法分析输入与输出的各种组合情况,从而设计测试用例的方法,它适合于检查程序输入条件的各种组合情况。因果图和判定表一般是同时使用的。

设计测试用例的步骤:

  • 找出所有输入条件并编号,即“原因”
  • 找出所有输出条件并编号,即“结果”
  • 明确输入与输出之间的关系(制约关系和组合关系)
  • 根据因果图,写出判定表
  • 根据判定表写出测试用例

举例:

需求:›有一个饮料自动售货机(处理单价为5角钱硬币)的控制处理软件,它的软件规格说明如下:

  • 若投入5角钱的硬币,按下“橙汁”或“啤酒”的按钮,则相应的饮料就送出来。若投入1元钱的硬币,同样也是按“橙汁”或“啤酒”的按钮,则自动售货机在送出相应饮料的同时退回5角钱的硬币。
  • 不能同时投两个硬币,不能一次同时购买2瓶及以上饮品。

1、找出所有输入条件并编号

  • 投入1元硬币(1)
  • 投入5角硬币(2)
  • 按下“橙汁”按钮(3)
  • 按下“啤酒”按钮(4)

2、找出所有输出条件并编号 

  • 退还5角(a)
  • 送出“橙汁”饮料(b)
  • 送出“啤酒”饮料(c)
  • 错误提示(d)
  • 退还1元(e)

3、明确输入与输出之间的关系(图省略)

如1、2为互斥,3、4为互斥;ab、ac、ad、de可以组合,bcd可以单独出现;ae、bc、bd、cd、be、ce互斥

图示例:13组合输出ab

yinguotu

›4、根据因果图,写出判定表

 1表示选择输入条件及造成的输出结果,以列来看

  1 2 3 4 5 6 7 8
输入 1 投币1元 1 1     1      
2 投币5角     1 1   1    
3 按下橙汁 1   1       1  
4 按下啤酒   1   1       1
 
输出 a 退回5角 1 1       1    
b 送出橙汁 1   1          
c 送出啤酒   1   1        
d 错误提示         1 1 1 1
e 退还1元         1      

5、根据判定表写出测试用例

退还1元硬币,提示错误

用例编号 用例操作 预期结果
1 投入1元硬币,按下“橙汁”按钮 送出橙汁,退还5角硬币
2 投入1元硬币,按下“啤酒”按钮 送出啤酒,退还5角硬币
3 投入5角硬币,按下“橙汁”按钮 送出橙汁
4 投入5角硬币,按下“啤酒”按钮 送出啤酒
5 投入1元硬币 退还1元硬币,提示错误
6 投入5角硬币 退还5角硬币,提示错误
7 按下“橙汁”按钮 提示未投币
8 按下“啤酒”按钮 提示未投币

四、正交排列表

常用正交表下载:http://pan.baidu.com/s/1bpMCjBT

通过已有的正交排列参考表将要测试的因素代入进去,可以已最少的用例覆盖最多的可能

举例:测试一个字符属性设置功能(选项),测试过程中需要考虑4个方面问题。

  • 字符类型:中文、英文、特殊符号
  • 字符属性:字型字号、普通效果、特殊效果
  • 字符位置:单元格、排版框、区域
  • 操作系统:Windows98、 Windows2000、Linux

因为是4个因素,每个因素里还有3个可能,所以我们可以参考L9(34)正交排列这个排列

序号  A  B  C  D
1 1 1 1 1
2 1 2 2 2
3 1 3 3 3
4 2 1 2 3
5 2 2 3 1
6 2 3 1 2
7 3 1 3 2
8 3 2 1 3
9 3 3 2 1

其中ABCD对应的是四个因素,而123分别对应每个因素中的三个选项,变更后为测试用例组合:

测试用例编号  字符类型  字符属性  字符位置  操作系统
1 中文 字型字号 单元格 Windows98
2 中文 普通效果 排版框 Windows2K
3 中文 特殊效果 区域 Linux
4 英语 字型字号 排版框 Linux
5 英语 普通效果 区域 Windows98
6 英语 特殊效果 单元格 Windows2K
7 特殊符号 字型字号 区域 Windows2K
8 特殊符号 普通效果 单元格 Linux
9 特殊符号 特殊效果 排版框 Windows98

五、状态转换图

设计测试用例的方法:

  • 找出程序的所有输入动作,并进行编号
  • 找出程序的所有状态
  • 找出什么动作会导致什么状态发生,画出状态转换图
  • 把相关联的动作和状态联系起来,设计测试用例

举例:某程序登录框,需输入账户和密码,提供关闭和登录按钮

1、找出程序的所有输入动作,并进行编号:

  • ip1→输入账号;
  • ip2→输入密码;
  • ip3→点击“登录”按钮;
  • ip4→点击“关闭”按钮。

2、找出程序的所有状态:

  • 启动状态
  • 账号已输入
  • 密码已输入
  • 账号已输入、密码已输入
  • 错误提示状态
  • 登录成功
  • 退出

3、找出什么动作会导致什么状态发生,画出状态转换图

如图所示:

zhuangtai4、把相关联的动作和状态联系起来,设计测试用例

把相关联的动作和状态联系起来,设计测试用例,为了减少测试用例数量,一条测试用例最好沿着状态转换图的一条路径编写完,如上图,大概有11条路径。

六、测试大纲法

测试大纲法适用于跳转页面较多的界面用例设计,如安装。

设计测试用例的方法:

  • 找出所有的窗口以及每个窗口的输入动作(注意先后顺序)
  • 找到各个窗口之间的联系,并据此编写测试用例

1、大纲是一种着眼于需求的方法,为了列出各种测试条件,就将需求转换为大纲的形式。

2、在根和每个叶节点之间存在唯一的路径,每条路径定义了一个特定的输入条件集合,用于定义测试用例。

如图示例,下图为各个界面所展示的可点击的操作(只是模拟,没有实际数据,哈哈),而一条路径就可以为我们定义一条测试用例。

cesdagang