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

测试回复集(一)

上一篇 / 下一篇  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的资料给他们发过去.
是否他们想用这两个工具,所以干脆让招聘的人做整理.






TAG:

引用 删除 _丢丢   /   2015-11-16 16:48:20
收益了~
 

评分:0

我来说两句

显示全部

:loveliness: :handshake :victory: :funk: :time: :kiss: :call: :hug: :lol :'( :Q :L ;P :$ :P :o :@ :D :( :)

日历

« 2020-04-21  
   1234
567891011
12131415161718
19202122232425
2627282930  

数据统计

  • 访问量: 39023
  • 日志数: 44
  • 图片数: 1
  • 文件数: 2
  • 建立时间: 2006-11-24
  • 更新时间: 2020-04-13

RSS订阅

Open Toolbar