51Testing软件测试论坛

标题: 求安慰~~领导在现场发现了一个bug，大发脾气，心里好难过~~ [打印本页]

作者: 爱加菲 时间: 2011-1-6 09:54
标题: 求安慰~~领导在现场发现了一个bug，大发脾气，心里好难过~~
本帖最后由爱加菲于 2011-1-6 10:24 编辑

我是做了6年多的开发之后转测试的，测试也做了一年多了，前段时间还在坛子里发了一个总结帖。因为自己测试的经验有限，而且现在整个部门只有我一个人在做测试，所以很多东西都要摸索着进行，挺难的，但是我自己也觉得蛮有收获的，还信心满满的坚持着。

可是最近遇到了一个很bt的项目，让我郁闷死。。。。

领导要骂我我也没话说，确实是我的疏忽，没发现这个bug。

我现在很迷茫的是这个，请大家给我指点迷津：
如果一个项目时间特别紧，留给你测试的时间只有短短2.3天，但是那么多内容，正常2,3天肯定细细的测是做不完的，这种情况下，我是选择保证质量，还是保证进度？

作者: gztester 时间: 2011-1-6 10:00
深表同情！

作者: 爱加菲 时间: 2011-1-6 10:01
本帖最后由爱加菲于 2011-1-6 10:53 编辑

但是时间非常紧，虽然有些基础的东西可以借用，但从开发到测试，只给了不到10天的时间。虽然项目规模内容都不多，但是毕竟是一个系统，业务逻辑、增删改、记账、统计、查询、打印，一个也不少。
开发人员忙得人仰马翻，到我这儿测试的时候，时间更是所剩无几了，于是各种加班。。。各种累。。。

实施人员到了现场之后，突然提要求，要增加一个新的页面，但这个页面做完立马就要发到现场去，于是又是一顿赶工，忙中出错啊，问题就出在这里了。
第一轮测试发现了不少bug，改了，到第二轮测的时候，开发人员疏忽了，把两个赋值的数字显示弄反了，我也疏忽了，确实是我的失误，我做了n个用例，看到统计的数字都是对的，但是没发现在ie上的显示位置放反了，这个bug就没被发现出来。这确实是我的疏忽。。。

作者: 爱加菲 时间: 2011-1-6 10:03
接着大家可想而知了，到了现场之后，这个bug被领导发现了，昨天打电话来，当时我没在，于是把开发人员一顿尅！说的很重。。。现在还不知道回来得怎么骂我呢。。。。

作者: 楠族开心果 时间: 2011-1-6 10:03
总结下，吸取教训就可以了。。测试员也不是万能的

作者: 爱加菲 时间: 2011-1-6 10:06
首先我非常诚恳的承认是自己的疏忽和失误。

作者: gztester 时间: 2011-1-6 10:07
睿智的领导会先骂自己
聪明的领导会先骂开发人员

作者: 爱加菲 时间: 2011-1-6 10:11
本帖最后由爱加菲于 2011-1-6 10:55 编辑

但是，我心里也觉得委屈。

测试本来就是个细致的工作。

在没有任何设计文档的情况下，我参加他们的需求讨论会，然后自己整理设计思路、然后猜着需求写测试用例、然后测试执行的时候被进度催着赶时间，真的我没办法保证做到一个bug都不放过。。。我是人，我不是机器，我也有疏忽的时候。。。。

作者: 爱加菲 时间: 2011-1-6 10:13

总结下，吸取教训就可以了。。测试员也不是万能的
楠族开心果发表于 2011-1-6 10:03

领导好像觉得，我就应该发现所有的bug，只要有一个没发现，就是我的错。
可是，怎么可能呢。

我尽量想做的细一点，但是时间有非常紧张，还得赶进度。我到底应该怎么做才对呢？
请大家帮我出出主意吧！

作者: 爱加菲 时间: 2011-1-6 10:13

深表同情！
gztester 发表于 2011-1-6 10:00

谢谢安慰！

作者: 爱加菲 时间: 2011-1-6 10:17

睿智的领导会先骂自己
聪明的领导会先骂开发人员
gztester 发表于 2011-1-6 10:07

昨天正好赶上我没在，要不我领导肯定连我和开发人员一起尅~~~
尅我我也没话说，确实是我疏忽了~~

作者: 楠族开心果 时间: 2011-1-6 10:19
回复 9# 爱加菲

总结错误时对的。但项目中没有bug是不现实的。

作者: sakuna 时间: 2011-1-6 10:23
回复 9# 爱加菲

首先，要镇定，天塌不下来
其次，要做漏测分析，总结还是有必要的
最后，要和领导充分沟通，改变他这种错误的思想

，说不定是你前面的表现太牛叉，让他产生了错觉，你要让他明白你不是万能的

，不过这是一个长期性的工作，需要潜移默化

作者: 楠族开心果 时间: 2011-1-6 10:25
回复 7# gztester

也不能这么说。主要还是看领导对测试的了解程度了

作者: 爱加菲 时间: 2011-1-6 10:25

回复爱加菲

总结错误时对的。但项目中没有bug是不现实的。
楠族开心果发表于 2011-1-6 10:19

好像领导不这么想，他认为测试没发现的bug就是我的bug。

作者: 爱加菲 时间: 2011-1-6 10:27

回复爱加菲

首先，要镇定，天塌不下来
其次，要做漏测分析，总结还是有必要的
最后，要和领导 ...
sakuna 发表于 2011-1-6 10:23

我从来就不牛X，这回我让他明白我不是万能的了。。。
但是不知道回来该怎么跟他沟通。。。。估计得一顿尅我。。。

作者: gztester 时间: 2011-1-6 10:36
大家被动接受领导的骂，领导对质量、对测试的观念没有转变的话，你们这种情况还是会重演

作者: 爱加菲 时间: 2011-1-6 10:40

回复 gztester
也不能这么说。主要还是看领导对测试的了解程度了
楠族开心果发表于 2011-1-6 10:25

我们7/8个开发的，我一个人测试，我之前跟他提过好几次，既然说重视测试，那起码再加一个测试人员。而且开发之前的需求和设计一定要做，否则测试的输入都没有，没有标准，真没法保证测试的质量。

作者: 楠族开心果 时间: 2011-1-6 10:42
回复 18# 爱加菲

我也是，最多的时候一个人面度几个项目。不过还好我们领导如果发现我没有看到的bug，最多只是说再多测测不会多说什么的

作者: 爱加菲 时间: 2011-1-6 10:49

大家被动接受领导的骂，领导对质量、对测试的观念没有转变的话，你们这种情况还是会重演
gztester 发表于 2011-1-6 10:36

我也觉得会这样。。。恶性循环。
其实这样的项目，本来开发和测试都非常辛苦，结果换来一顿骂，大家心里都很难受。
不是不能做好，更不是不想做好。
我应该怎么做？

作者: 爱加菲 时间: 2011-1-6 10:49

回复爱加菲

我也是，最多的时候一个人面度几个项目。不过还好我们领导如果发现我没有看到的bu ...
楠族开心果发表于 2011-1-6 10:42

起码你们领导还理解你一个人测试的辛苦

作者: sakuna 时间: 2011-1-6 10:50

我从来就不牛X，这回我让他明白我不是万能的了。。。
但是不知道回来该怎么跟他沟通。。。。估计得一顿 ...
爱加菲发表于 2011-1-6 10:27

领导之所以这样，我觉得可能有两方面，一方面是客户的因素，总要给客户一点交代，这可以理解为一种踢猫行为，如果他是了解你们的，即便是要K你，也会有所保留的。
另一方面是领导确实不了解测试，这个时候，你的任务除了要做好日常的测试工作，还要让你们领导了解你们是怎么工作的，K一次也就算了，老是被K，谁受得了，是不

再说了，领导不是还没K你嘛，所以没有什么好委屈的，要是不K你了，那你岂不是白委屈了，对不

作者: 爱加菲 时间: 2011-1-6 11:02
本帖最后由爱加菲于 2011-1-6 11:08 编辑

领导之所以这样，我觉得可能有两方面，一方面是客户的因素，总要给客户一点交代，这可以理解为一种踢 ...
sakuna 发表于 2011-1-6 10:50

昨天头找我呢，因为我没在躲过一顿尅。。。
其实不怕尅，确实是我疏忽了，尅我我也心服口服。

关键是我觉得如果再这么做下去，没法保证测试的质量，如果连续被尅，我肯定受不了。

觉得委屈是，即使是经过细致的测试的设计、评审和执行过程，可能也会有些隐藏的bug不被发现。更何况我们现在的这种测试过程，有漏测点、bug被疏忽、太容易发生了。如果领导不意识到现在的设计、开发、测试过程之中存在的很多问题，不能根本上去解决问题，以后类似的情况还是会频繁的发生。

作者: sakuna 时间: 2011-1-6 11:24
回复 23# 爱加菲

觉得委屈是，即使是经过细致的测试的设计、评审和执行过程，可能也会有些隐藏的bug不被发现
感觉这种观点有点问题啊，你一定要淡然，不然你压力会很大的哦

作者: chengning 时间: 2011-1-6 11:30

淡定啊，习惯就好了，比起你来我更惨

作者: 爱加菲 时间: 2011-1-6 11:33

回复爱加菲

觉得委屈是，即使是经过细致的测试的设计、评审和执行过程，可能也会有些隐藏的bug不被 ...
sakuna 发表于 2011-1-6 11:24

说的对，我应该淡定点。。。。
可能是太较真了，对自己要求太高，不现实。

作者: 爱加菲 时间: 2011-1-6 11:33

淡定啊，习惯就好了，比起你来我更惨
chengning 发表于 2011-1-6 11:30

淡定淡定。。。谢谢安慰。。。

作者: samraul 时间: 2011-1-6 11:51
本帖最后由 samraul 于 2011-1-6 11:55 编辑

深表同情。你比我情况还好。我这里也只有1个测试人员，而且我是刚入职。对系统对业务还不太了解。测试没有需求，没有设计文档。前期的设计讨论会议也没有叫上我去，相关邮件也没有抄送给我。之前已经像经理反映过了。到系统开发快结束了，才叫我测试，那个被动啊，相当的不规范，很多业务和后台的东西都不了解。自己只有多问、多了解，把发现的BUG提交给开发人员，并修复了。凭我测试的工作经验，后期系统基本没有什么BUG了，但郁闷的是，一个业务需求的功能没有实现（学校是商户，学校里面每个饭堂再分作下一级商户，因为每个饭堂可能承包给不同的商家，涉及权限问题），我在没有需求和设计文档，并且刚入职没多久，项目前期又没有让我提前介入的情况下，这个真没想到，我觉得可以理解，也不是我想的，你做好，我测试权限就行了。开发人员也没有考虑到，所以没做。但开发人员责怪我测试没有站在用户角度测试，思维不够发散。我解释我的情况，他就说“你好像还不服哦”。我觉得他对测试的认识有误，他觉得测试人员要想到面面俱到，不能有一个BUG漏掉。我发现那么多BUG，发散思维提了那么多建议他没看到，这个问题就放大来看。后来我忍了，没理论，以后自己更用心做好就行了。

作者: 愚人 时间: 2011-1-6 11:59
看到风险，根据之前的情况，对某些模块做重点测试……

作者: Jackc 时间: 2011-1-6 12:21
开始看时，想笑（莫拍砖..真实感受）

看到后面，有些莫名的抓狂...

估摸着下午你们领导就该找你“聊天”了（当然，也许他很忙，忘记了也说不定，呵呵）
——————————————————————
说正事，其实这次事件，可以看作是用户体验这方面，领导好比用户（当然，会比普通用户挑剔了）。让用户打法雷霆的bug，优先级也不低了，仅仅次于主要功能未实现的bug了。

建议你稍微调整一下测试策略，除从功能实现着手设计用例外，增加“用户可见”和“用户感受”两个用例设计因素（这两个概念都比较虚，我尽量描述一些）。
--------------------------------------------------
用户可见：在用户角度，能察觉到的就是bug，不能察觉的即不算bug。故设计用例时，增加用户常用区域用例，减少用户不常用区域的用例，这样的测试活动比较符合产品价值分布规律。
如，在某个边远小功能，存在一大堆bug，但用户基本不使用那一块，那么有必要花费宝贵的资源来发现，并修改它们么？（按照bug价值率来布置测试资源，经常会用到资源不足的测试中）
当然，不是说那遥远的小功能连基本功能测试都能省略哈......

用户体验：这个就比较虚了。对于产品的感受，不同人都不一样。而这部分的bug主要不是通过实际测试完成。大多是通过设计用例，发现疑点，然后评审/协商确认需求，最终达到大家可认可的平衡点。也就是说，可以在测试实际执行未投入的开发阶段，可将部分重心放置于此，减少后期因为纠结于“测试/开发分歧”而浪费宝贵的测试资源。
————————————————————————

作者: Jackc 时间: 2011-1-6 12:21
看了LZ兄弟的描述，领导若因此事找你，多半你只能闷声了....
其实若是强一些的领导，谈谈自己的测试策略以及关注点，多半就过了...

话说回来，居然还有认为测试能发现一切的领导....（如果不是管理策略知而固为之，那我只能祈求兄弟多福了）

作者: 爱加菲 时间: 2011-1-6 12:35

深表同情。你比我情况还好。我这里也只有1个测试人员，而且我是刚入职。对系统对业务还不太了解。测试没有需 ...
samraul 发表于 2011-1-6 11:51

这位同学，我觉得你能在这种情况下把测试起来简直就是奇迹。。。。
深表同情。。。。

作者: 爱加菲 时间: 2011-1-6 12:36

看到风险，根据之前的情况，对某些模块做重点测试……
愚人发表于 2011-1-6 11:59

谢谢指点。
我今天就在找重点地方重新测。

作者: linyucc 时间: 2011-1-6 14:16
这种情况有个优先级的方法，什么功能最重要最先测重点测，比如说流程逻辑算法这是我们最为关心的，站在客户角度来他看重的界面显示查询结果统计结果是否正确，这些东西你可以仔细点测。
还有就是遇到这种情况首先你要先向领导反应工作量大，时间紧，会导致测试中会有遗漏，为可能出现的失误做好退路。

作者: zhaoshucong 时间: 2011-1-6 15:35
建议你们领导再招个人，这样两个人可以互测，减少bug数，除非你们那不重视测试

作者: crystal50112 时间: 2011-1-6 17:17
当然以保证质量为前提

作者: wangsc_testing 时间: 2011-1-7 10:24
我觉得这里边与测试经验有关系。保证质量这是必须的，但质量不仅仅那些主要业务功能的质量，那些附带的功能模块同样也要保证它不会出现很明显的BUG。挨骂了，说明这个BUG是很明显的，应该是很容易测出来的，但被你忽视了。对于你说的测试时间紧迫，功能又多，把所有功能模块测试过来有点难度，那么主要的业务功能模块你肯定要全部测试一遍，对以附带功能，需要你的经验来判断，哪些地方容易出现BUG，哪些地方可能存在BUG，其实也就是对附带功能采用探索性测试方法，虽然发现不了深层次的问题，但至少可以发现很明显的问题。

作者: 张志英 时间: 2011-1-7 11:06
回复 25# chengning

你怎么个惨法了？？？

作者: bj_liuqiang 时间: 2011-1-7 11:12
这样的公司趁早走！

作者: tianshi861 时间: 2011-1-7 14:05
你们领导太不尊重测试了吧，其实出现了问题，你心里比谁都不好受，总结就可以了！

作者: caoase 时间: 2011-1-7 22:33
保证主要功能的正确，记得最后一个版本做好工作流程测试，还有，就算三天，假如你不是mgr一定要写测试报告，告诉他们，你测了哪些。
哪些没测。

3天，感觉好不正规。

作者: 月上百合 时间: 2011-1-7 23:39
菲姐也挨骂了

哈哈
这样子，如果是一个全新的项目，哪么你不要等开发丢过来时再开始，不是分模块吗，好了一个你测一个，到丢过来时，你再系统测一下整体。时间还是来得及的。
如果是改版，哪么时间太急时你可以先保证增量部分是没问题的，然后再把与增量部分相关的模块测一下。这样也是来得及的。在紧急时间中，我们人力也有限，哪么只能先保证优先级高的。像哪些不受影响的部分可以暂时把优先级调低。当然，如果自己不能判断哪些会受影响可以问下开发。嘻嘻你自己做开发好多年，应该由自己经验也可以判断下。希望姐想开点，错了就错了，下次不在同一地方错就地了呗。这种问题出现一次也是好事儿，至少下次你会往这方面注意一下。

作者: 51testing_tracy 时间: 2011-1-8 11:20
还没碰到过这么凶的领导，还能骂人，现场有问题了就赶紧想补救的办法，骂人有什么作用啊，再说测试也不是万能的啊。。。。。

作者: 卟給力吖 时间: 2011-1-9 18:06
1、缺陷产生的原因，其中包括工期短，任务重；
2、软件测试的原则，穷举测试是不可能的，要遵循Good-enough原则；
如果这个BUG比较严重，影响主要功能，那就没什么可说的了，如果只是小问题，那你们领导应该理解你。个人建议，对于测试计划中的项目进度，如果觉得有风险，就要及时提出，通过沟通来确认是否要进行相关的调整（比如说测试人员不足，是否要增加人手？），你不说，领导会认为你接受了，并且很有把握完成任务。

作者: zhangting85 时间: 2011-1-9 21:52
按lz的帖子说，你的领导确实发现了一个很明显的严重BUG，所以没办法，肯定会怪你没测好，你的测试用例执行结果上写了pass的项目确实不应该有BUG，更不应该有严重BUG。

从职业特点上来说，测试人员在传统测试中就是最后的守门员，所以就会产生你说的这种情况。这是传统软件测试的弊端。至于什么流程啊评审啊之类的，只在理想条件下才会有，并且即使有也不一定能起作用。最后只能怪测试。

对于你说的工期紧，工作量大的测试任务，一般方法是划分测试用例优先级。确保高优先级的测试用例必须PASS，系统中不应该有严重BUG（比如你说的两个数字显示反了）和明显BUG（比如重要标题里面的错别字之类的）。

但是说到底，做测试还是会给开发人员背黑锅，绝大部分BUG都是开发引入的，但是最后由测试来背黑锅。黑锅是一定会有的，你看IPHONE4今年新年的时候那个闹钟BUG，IPHONE4也会有BUG，何况你们公司的产品。避免背黑锅的办法有两个，
一个是你自己做测试manager，避免自己直接执行测试用例，这样黑锅由你手下背。为了避免手下对你不满，你可以招几个外包人员，然后黑锅让外包人员背。哪个外包人员黑锅背多了，可以换掉他，这样你们自己公司内部团队还能很和谐，不和谐的外包人员为了不被换掉一定不敢多嘴的。
另外一个办法是你们做敏捷测试，让开发人员自己写白盒测试，测试人员写自动化验收测试Automated Acceptance Test，然后再测试人员做手工探索式测试。万一出了BUG首先可以指责开发人员白盒测试没做好。其次可以指责业务设计人员需求文档没做好导致自动化验收测试有盲点。（这个方法基本不现实，推荐第一个方法）

作者: liangliang06 时间: 2011-1-10 10:55
我也是一个人测试，所遇情况跟你一模一样，只得在以后改正心态了。

作者: littletudou 时间: 2011-1-10 11:18
45楼的思想有问题啊，外包人员也是人，怎么能随便让别人背黑锅？？你这根本就不是解决问题，而是把一个人的痛苦转移给另一个人啊！！

作者: 微笑流淌 时间: 2011-1-10 13:46
回复 31# Jackc

我们领导也认为测试人员应该可以发现所有的BUG,连开发人员写出来的测试工具，也要我先测试一遍，符合测试需求了再用！

作者: 微笑流淌 时间: 2011-1-10 13:51
表示同情，安慰一下吧！

作者: liubin7852 时间: 2011-1-10 21:15
刚入行，还没遇到这种情况，不过表示理解。。。

作者: MGM 时间: 2011-1-11 13:00
测试有测试的苦啊、

作者: superls 时间: 2011-1-11 15:45
领导不给力。
管理混乱无章法。
要质量要进度，不是你说了算，是领导说了算。
要质量就多给些时间，要进度就有损放行。
注意沟通。

作者: ermine 时间: 2011-1-11 23:08
质量，就是满足需求。
尽量将测试的范围定下来，将主要功能弄成表，一定不能出错，而对于不在表里的错误，如果出现没有查到的情况，试严重程度，一起担责任，然后再填到表里。
可以和领导商量一下，不是讨价还价，而是确实时间精力有限，不能因小失大，这样把主次也分一下。

作者: Raynard 时间: 2011-1-12 12:13
这么多牛人额～
受教了

作者: poppy_test 时间: 2011-1-12 14:09
学习了。

作者: freshlin 时间: 2011-1-12 16:42
我同意楼上的观点，如果领导对于测试的观念没改变，导致测试非常被动，效率是很低的。
再有，
“实施人员到了现场之后，突然提要求，要增加一个新的页面”
这种要求应该由项目经理来卡的，
为什么前期没有提这个需求？是项目经理的疏忽还是客户那边忘记了？
如果是客户临时提的，要压下来。否则这样的突发状况会影响原有的流程和进度。

作者: lujunda 时间: 2011-1-12 17:37
承认错误，下次别犯了。老板要训就让他训一顿。
我以前还被训哭过呢。想想就委屈，但自己犯的错，只能承受，不要抱怨。

作者: 爱加菲 时间: 2011-1-13 09:34
这几天忙晕了~~
今天上来一看，这么多高手支招，我都认真仔细的看了，受益匪浅。。。感动ing，谢谢大家！

作者: 没翅膀的飞鱼 时间: 2011-1-14 20:52
领导骂人，嗨，也太过分了

作者: liuyuling2496 时间: 2011-1-19 17:19
看来测试情况都是类似。测试时间被严重压缩，我遇到这种情况的时候，通常会找领导沟通，告诉他这么短的时间你能把系统测试成什么样。我想领导听后一定会有个考量。

作者: 苏高跃 时间: 2011-1-19 17:38
回复 1# 爱加菲

LZ以后要注意，这种情况经常遇到，开发经常把测试的时间占用了。但你测试时也就没几天了，这时你就和你上司说，本来测试需要10天的时间；但现在只有2、3天时间，你们也要赶着上线。我不能保证项目的质量，但我只能保证主要功能的质量，细节上不能保证了。免得出问题K的大，也不能怪你。

作者: 苏高跃 时间: 2011-1-19 17:40
测试是证明软件有错误，不能保证软件没有任何问题的。我们只是把质量问题确保到能接受的范围。

作者: saharis 时间: 2011-1-21 11:32
页面检查类的案例和功能点的案例应该是分开的，执行的时候也是不同类型的测试。

所以计划、执行都应该有一个规范的流程，越严格，风险越小

作者: yirong00511 时间: 2011-1-21 17:02
有几个领导能意识到 “测试不是万能的”！！

作者: websoul 时间: 2011-1-21 17:31
我觉得一个人做测试已经很不容易了，领导可能不知道你工作量大小，或者顾及客户，有的领导也可能是不会做领导，小题大做。
做为你，就吸取教训吧。你开始做的时候要自己评估工作量，时间+人力+项目大小。如果时间和人力有风险，都要提前跟领导说好。让他看到你的工作。测试计划和报告弄个模版，把自己的工作量量化，让领导看到你都作了什么。在量化的工作面前如果领导还说什么的话，就是人品有问题了。

作者: websoul 时间: 2011-1-21 17:41
对了，开发人员的进度你也应该督促，这也是测试人员的工作之一。别直接面对开发人员，面对开发leader。想到的就这么多。不过貌似前面好多前辈都给了很好的意见，多多学习！

作者: hueslife 时间: 2011-1-25 14:42
一看这样的领导就是很无能的那种，自己手上多少人能做多少事，自己都不清楚？

作者: 千里 时间: 2011-1-25 20:41
回复 4# 爱加菲

仅关于这个事情，把开发和测试一顿骂，我觉得作为挨骂者是服气的。但是作为领导，需要在一定程度上面保护员工，感觉没有，这一点有些儿不服气。不过有一点好的，开发和测试一起骂，至少责任都担了而不是有问题只找测试。

作者: 千里 时间: 2011-1-25 20:44

但是，我心里也觉得委屈。

测试本来就是个细致的工作。

在没有任何设计文档的情况下，我参加他们的需 ...
爱加菲发表于 2011-1-6 10:11

有需求会，却没有需求文档。还需要测试员去想像需求，我觉得这首先是项目经理的失职其次是没有需求人员的责任，最后是测试在背黑锅。

作者: 千里 时间: 2011-1-25 20:48

我从来就不牛X，这回我让他明白我不是万能的了。。。
但是不知道回来该怎么跟他沟通。。。。估计得一顿 ...
爱加菲发表于 2011-1-6 10:27

这有资源不够的情况，还有风险少了一个评估吧。不过资源不够，也不敢向领导申请，因为申请了也没用。最后留下了三天时间做测试，结果时间过去了，风险还存在，我们也极少跟领导反馈该程序有风险不能上线，领导也不太征求测试的意见执意上线。

作者: 千里 时间: 2011-1-25 20:50

我们7/8个开发的，我一个人测试，我之前跟他提过好几次，既然说重视测试，那起码再加一个测试人员。而且 ...
爱加菲发表于 2011-1-6 10:40

要厚着脸皮不停的要求加人，要黑着心肠不断的出错，最后领导看不下去了，就给你加人了。

作者: 千里 时间: 2011-1-25 20:52

昨天头找我呢，因为我没在躲过一顿尅。。。
其实不怕尅，确实是我疏忽了，尅我我也心服口服。

关键 ...
爱加菲发表于 2011-1-6 11:02

还有一点是我们害怕的：害怕讲出自己对质量的担忧，害怕讲出测试过程的资源紧张，害怕讲出测试后的风险，害怕讲出目前测试管理&项目管理存在的问题。当然最重要的一点：讲了也没用！

作者: zwb131442 时间: 2011-1-28 14:11
1.走流程-------------时间紧，那么起码先要保证系统的流程没有问题吧？
2.重要功能----------如：新增、保存、统计等
3.校验---------------在保证1、2点的情况下开展
4.界面易用性--------向1、2、3、看齐
其实可以实行内外有别，先上线适用，公司内部继续测试。

作者: archonwang 时间: 2011-1-28 16:01
同情你。对你漠视风险感到有点。。。

明知不可为而为之的事情，是不能打包票，此其一；第二，面对风险时第一要素是让上级明确风险存在，丑话说在前头；第三，面对风险没有第二、第三甚至第四、第五套方案，失策。

别太难过，知道了下次如何做总比被骂了一无所知，无所是从更好。

作者: chaoxiaotian 时间: 2011-1-28 16:16
测试本来就是个挨累不讨好的工作，不要郁闷了，在测试方法方面提点小思路吧
1、先把被测系统的大体情况搞清楚，在纸上画出个框框来，然后再测试，不能无头苍蝇的看到啥就测啥
2、测试的东西多的时候，分清主次，主体的流程什么的一定要测到，不能马虎，其他的视情况而定
3、把测试分类，比如说界面测试、流程测试、bug多发点测试等，按不同的侧重点去测试
4、为每种测试都建立一个标准，比如界面测试标准中包括控件的边缘测试等，按照规范去测，省很多时间。而对于流程，你可以先把流程都写下来，然后按照写好的流程测试，省非常多的时间，而且还能保证质量。

作者: chaoxiaotian 时间: 2011-1-28 16:18
还有，改变领导的看法最好的方法就是用成绩说话，加油

作者: zhangting85 时间: 2011-2-9 00:27
回复 47# littletudou

你这话就说错了，这是把内部矛盾向外转移的管理方法。再说了，即使你是外包人员，你也可以不犯错啊，就不用背黑锅了。并不是说复杂的模块，容易导致你犯错的模块你就一定会犯错的。你是否胜任你的岗位呢。从另一角度来看这个是对自己公司的员工较为宽松，对别公司派过来的外包人员较为严格的一种处事方式罢了。这又算什么呢。自己单位的是自己人，外来的是外人。终究亲疏有别。而且这是中国的传统，任何单位都是这样。同工不同酬，古已有之。现在更是如此，机关单位里有事业编制的二等公民，事业单位里有企业编制的，企业里有劳务派遣的。你还就真别控诉什么。社会本来就是如此。

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)