对测试群中“不能成为专业测试人员的10大理由”的拙见
有些话 稍显不是很对
深圳-巫师()9:49:50
微言几句 90%以上的中国IT企业很难做到让测试人员在开发早期 甚至需求早期就进入因为有以下不利因素：
1并不是许多公司的产品岗位 是一个专门的岗位或独立的完善的有设计能力的部门 或者即使有也存在许多产品环节问题的产品部门 过早的去介入他们的需求讨论中会拖沓产品的设计时间或者混淆他们的设计思路 因为一个相对优秀的测试人员如果对本系统尤其是服务等各细节或开发实现各细节理解的很到位的话他会很抵触的针对和当前开发实现相违背的地方提出相关“反对”意见这样会遭到产品的不满 所以我不赞成在这个点介入而赞成去有意识的照到相关服务开发和前端开发人员 在对他们的开发设计方案初步确定可以做的时候在介入旁听记住只是旁听 捎带以测试角度的提问
深圳-巫师()9:52:39
2 实际情况90%的中国IT企业 测试资源实际是很紧张的测试人员的水平那也是高低相差很多真正的有经验的有理论的那更少了 所以基本都是在疲于应对各种产品需求测试时间和测试进度基本处于压缩状态并不是不想优先去考虑
深圳-巫师()9:55:30
3实际情况90%de IT企业文档 产品相关文件 开发实现实际说明相关文件基本趋于只有个需求描述就不错了 成长型企业很难有要说百度腾讯阿狸这一级别的我信有但并不一定从测试角度来讲能很好的提取测试需求。大多数 是要靠测试人员主动去提问去了解。
深圳-巫师()10:03:10
这条微言几句：
基于场景设计测试用例是一个好方法甚至可以贯穿所有的测试生命周期 在任何一处测试点使用这个方法去设计 主流程 备选流程 都是十分可靠的。这里我十分赞同。 后一句 我不明白 这一句 是想要我们测试人员了解真实用户行为到什么程度。但是我想如果 对场景设计法 使用还到一定火候的话会有限度的针对用户 何时 何地 何种条件 去使用了什么功能做出测试设计。你提到的工作环境就是客户使用环境 网络环境 运营商环境等因素这些因素 实际要测到一定程度 是相当复杂和耗时的一个面向业务型的成长型企业 永远第一准则（也许很难听，但是很长见）是先优先保上线 先上线再优化保不出大问题。这是测试设计优先级的一种策略，也是无奈之举我们测试人员不得不顶住的一种上线压力。这一问题的解决 还与软件开发设计架构 和服务节点部署 数据库等诸多环节，有时候更好的解决方是架构师和运维人员。
深圳-巫师()10:05:54
其他几条 我基本赞成无微言意见
深圳-巫师()10:17:45
哦 还有这个
深圳-巫师()10:26:38
怎么讲 这并不是一个很好辩论或能正确50%以上的一个论点当然我本人支持有开发能力或读代码能力是好的。但我想说的是，也许有时候陷入到读代码中 并不是我们的主要任务也许会陷入更多的代码陷阱中因为如果本身不是一个写代码出身的话（至少2年以上）会陷入一个很深的误区。就像一个笑话，一个迷路的直升机飞到了微软的大楼，问那里的人：where am i?大楼里的人答：“你在飞机上”那个人回答：“哦 那我知道了 我在微软的大楼” 这个笑话实际是我记忆最深的一个 给我的启发是 我们测试人员到底是要是其中的哪个角色最合适呢？最终我的结论是ALL 十分可怕 但我更偏向于 问问题的那个人就是回答““哦 那我知道了 我在微软的大楼” ”的这位，这位很聪明 是个比较符合测试角色的职业（个人认为） 这一问题想说的是 如果陷入代码过多就会回答 你在飞机上 那是一个绝对正确 但实际和“业务目标”相去甚远的一个答案（但是这个答案按开发人员角度或代码角度来讲是绝对十分一定正确的，是不应该被嘲笑的） 所以那个飞机上问问题而又马上反应过来并判断出来的角色才是一个合格的测试人员。 所以测试人员如果测试理论扎实 设计方法经验方法严密 那她看不看代码实际关系不是很重要 起码不是绝对重要。另外我想说的是 如果你是白盒测试人员 那么写代码读代码很重要。
深圳-巫师()10:29:14
而且 国内开发并不规范都是骑驴看唱本式开发无有许多很精密的前期设计各种设计过早的让测试人员看代码也是很难的。
测试人员的第一要务 还是要作为一个独立的分析体已产品需求为主要出发点 去检查开发实现设计这是主要。
深圳-巫师()10:30:19
就是说 你看的代码 也许根本是程序逻辑正确（回答 你在飞机上）但是业务逻辑需求完全没照顾到的。
深圳-巫师()10:34:46
所以 一个高超的或相对称职的测试人员 要扮演的角色 绝对不是一个开飞机的（那是攻城师的事）或是一个指挥飞机 去哪（那是射鸡师的事）我们要做实际就是发现 协调 沟通 确认解决也就是飞机起飞前 给飞机做检查的
当然会发现 是第一问题不会发现 找不到问题的症结 就谈不上找谁去协调
无论做黑盒 白盒 都不应该拿出来比较 或有相关利益上的差别，唯一的评比差别只在于
如果他写的是完全 你在飞机上 而你在飞机上再往下无上下文衔接业务目标的话那么这个白盒人员就是白干 在牛X的代码逻辑不为业务逻辑服务都是耍流氓
以上纯属个人意见尊重原文作者主题主旨 {:3_73:} dingge 在译文(一)出来之后，发到QQ群里就有同行伙伴提出了一些疑问，在这里我也结合我的工作实际阐述一下。
1.文章中第二点，深圳的一位网友就提出了：在中国90%以上的中国IT企业很难做到让测试人员在开发早期甚至需求早期就介入。
我不太确定他说的90%是否有数据支持，至少我所认识的很多同行都会在需求阶段让测试人员介入,如果还不是这样,我想测试人员是时候做些什么了吧??绝不能坐以待毙.我待过2家互联网公司，说说我的经历。一家是创业型公司，一家是中型公司，当时我们是如何做的呢？创业型公司，或许很多这样的公司，都没有较为成熟的文档化和流程，以快为先，唯快不破。没有专职的项目经理，甚至产品经理都没有，我们的CEO，CTO就是产品经理，甚至我们每个人都可以为产品设计贡献思路。老板们的想法已经成型了，很多时候在脑子里，没有文档化，然后开需求宣讲会议，因为人不多，开发测试都会参加，会议上也会有一些讨论，这是大改，还有小改，可能就发邮件给大家，邮件也算是文档吧。大多数时候大家很难在会议上就发现需求的全部漏洞，但是基于对系统的理解，有时候测试人员的思路也很活跃，"可以...不可以...如果...如果不..."类似使用场景的思路联想到的问题可能起到作用。但是不去参加这个会议，可能就只能到了代码写完提交给测试了，这个时候最大的问题就是，如果开发人员理解的有偏差，测试人员如何保证产品的质量呢？只有保证测试的需求与业务需求是一致的，才能真正的说明我们测试的是一款正确的产品。
其实如果不去参加那个宣讲会议，就是那位网友说的情况了。在我看来，在没有项目流程的公司里，测试人员要更加主动，主动承担一部分项目管理的工作。如果没有文档，可以主动申请加入到需求宣讲中去。其实参与到宣讲中，至少还有一个好处，可以知道为什么这么改，有助于我们更加理解业务的初衷。如果是邮件发出来的，可能就没有这么多来龙去脉。
上面说的是业务需求，其实对于开发设计的会议，我当时也是非常乐意去参加的，你会知道他们的设计思路是什么，大致算法如何设计，有哪些异常处理，是否有异常报警机制等等。没错，我能想到的一些use case也会提出来，让他们开发的时候考虑到。这样子，我能更懂产品，测试思路也更宽阔，而且让开发理解我们测试人的思路，如果他们也懂一些测试思路，很多问题在开发设计阶段就可以规避了，这也是尽早测试的意义所在。
再说第二家公司也就是现在这里，流程稍微正规一些，不过也是一步一步建立起来的，测试人员也参与到流程改进中去。有专职的项目经理和产品经理，需求是产品经理事先设计好的，只不过设计的时候可能会阅读原有的设计文档或咨询一下之前负责的开发或测试原来的业务逻辑，这也是为了取其精华去其糟粕，这是需求设计完成前测试人员唯一介入的；当需求设计完成后会发给项目组成员，组织宣讲，会议上可以提出相关疑问，产品经理会记录下来再进行确认或重新设计。之后需求设计freeze，如果不是特别大的问题,其他需求变更可以考虑延后处理，对于严重需求漏洞就需要及时变更,越往后成本越高.之后开发测试人员会依照新的文档开始工作,但是在测试设计用例或开发代码设计时经过更深入业务理解之后可能又会发现需求的一些问题,会集中反馈出来,产品经理一样会酌情考虑是否延后处理.后面的阶段就是进行用例评审,组织测试等等了.总体来看流程比之前创业型公司顺了很多,至少测试可以较早的介入.当然,测试人员参与到流程改进中也是一大保证.至少我的经历来看,项目延期的几大杀手就是需求变更，无流程和糟糕的项目计划.
2. 对于第三点中的情况,我想作者的意图也只是想要表达场景法设计用例的重要性,而且场景法设计用例的确是贯彻软件测试的始末.如深圳的那位朋友所说,没有一款产品是需要覆盖100%的,我们的策略都是一定要覆盖重要核心的业务,次要的备选流业务可以通过产品,开发及测试三方评审哪些需要覆盖哪些不需要覆盖,以得出测试的范畴,因为即使测试出了bug,也可能不修复,我想不被修复的bug是没有意义的.而且评审过的测试范围即使某天出现遗漏我们也有说法.
3. 对于第一点中谈的代码能力.我个人意见是:这项技能是锦上添花,并不需要每个测试人员都需要具备.但是具备了就可以参与到项目的code review中去,在提测前期就可以发现很多问题，而且具有代码能力的测试人员可能更懂得如何更有效的去测试。
据我对功能逻辑性bug的分析,记住是功能逻辑性的不包括其他类型诸如UIUE上的。主要有3类:
1)大多数bug是很简单的代码错误,如果一经过大家的评审,就能发现出来；
2)一部分是业务理解错误,写的代码不符合业务需求,代码走读时也可以发现部分问题，但是不能发现全部，代码走读也可能只是对核心业务代码或接口部分进行的评审，而系统层面的需要在系统测试阶段才能发现。如果在前期保证产品，开发和测试三方对需求理解的一致性，就可以减少很多这样的bug,不是吗？
3)还有一小部分可能真的是比较难处理的bug，难复现，难调试。这部分东东，测试人员也很难评审出来。
4. 最后我再补充一条：能够将自动化和手工测试很好结合起来开展工作的也是一大挑战。
我相信在很多公司，专业做自动化测试的团队对业务理解不够深刻，他们很多时候都是在研究新的技术完善测试框架，或者按照手工测试用例的优先级编写脚本，然后只是让自动化daily run。而且他们不一定知道测试哪个需求时需要自动化配合做回归测试，或者哪些内容可以提前把关键流程的用例事先实现自动化，等提测之后用来自动化smoke，哪些需求变更了又需要更新自动化。如果通过双方测试人员沟通，这种沟通的成本我觉得也不少。熟练地掌握手工测试技能并且能够自动化实现，在项目测试中很好的配合，以节省回归测试时间，这是一个挑战也是一个趋势。
===========================
zzzmmmkkk,本名赵敏科,6年测试经验,从事过多年功能测试,性能测试及自动化测试,乐于分享。
不定期发布有关测试技术文章,测试经验分享,测试思考和问题探讨
加入“zzzmmmkkk”,可以：
1. 请在微信“添加好友”->“搜索公众账号”里查找“zzzmmmkkk”
2. 或者点击本文右上角按钮后选择“关注公众账号”
=========================== 在译文(一)出来之后，发到QQ群里就有同行伙伴提出了一些疑问，在这里我也结合我的工作实际阐述一下。
1.文章中第二点，深圳的一位网友就提出了：在中国90%以上的中国IT企业很难做到让测试人员在开发早期甚至需求早期就介入。
我不太确定他说的90%是否有数据支持，至少我所认识的很多同行都会在需求阶段让测试人员介入,如果还不是这样,我想测试人员是时候做些什么了吧??绝不能坐以待毙.我待过2家互联网公司，说说我的经历。一家是创业型公司，一家是中型公司，当时我们是如何做的呢？创业型公司，或许很多这样的公司，都没有较为成熟的文档化和流程，以快为先，唯快不破。没有专职的项目经理，甚至产品经理都没有，我们的CEO，CTO就是产品经理，甚至我们每个人都可以为产品设计贡献思路。老板们的想法已经成型了，很多时候在脑子里，没有文档化，然后开需求宣讲会议，因为人不多，开发测试都会参加，会议上也会有一些讨论，这是大改，还有小改，可能就发邮件给大家，邮件也算是文档吧。大多数时候大家很难在会议上就发现需求的全部漏洞，但是基于对系统的理解，有时候测试人员的思路也很活跃，"可以...不可以...如果...如果不..."类似使用场景的思路联想到的问题可能起到作用。但是不去参加这个会议，可能就只能到了代码写完提交给测试了，这个时候最大的问题就是，如果开发人员理解的有偏差，测试人员如何保证产品的质量呢？只有保证测试的需求与业务需求是一致的，才能真正的说明我们测试的是一款正确的产品。
其实如果不去参加那个宣讲会议，就是那位网友说的情况了。在我看来，在没有项目流程的公司里，测试人员要更加主动，主动承担一部分项目管理的工作。如果没有文档，可以主动申请加入到需求宣讲中去。其实参与到宣讲中，至少还有一个好处，可以知道为什么这么改，有助于我们更加理解业务的初衷。如果是邮件发出来的，可能就没有这么多来龙去脉。
上面说的是业务需求，其实对于开发设计的会议，我当时也是非常乐意去参加的，你会知道他们的设计思路是什么，大致算法如何设计，有哪些异常处理，是否有异常报警机制等等。没错，我能想到的一些use case也会提出来，让他们开发的时候考虑到。这样子，我能更懂产品，测试思路也更宽阔，而且让开发理解我们测试人的思路，如果他们也懂一些测试思路，很多问题在开发设计阶段就可以规避了，这也是尽早测试的意义所在。
再说第二家公司也就是现在这里，流程稍微正规一些，不过也是一步一步建立起来的，测试人员也参与到流程改进中去。有专职的项目经理和产品经理，需求是产品经理事先设计好的，只不过设计的时候可能会阅读原有的设计文档或咨询一下之前负责的开发或测试原来的业务逻辑，这也是为了取其精华去其糟粕，这是需求设计完成前测试人员唯一介入的；当需求设计完成后会发给项目组成员，组织宣讲，会议上可以提出相关疑问，产品经理会记录下来再进行确认或重新设计。之后需求设计freeze，如果不是特别大的问题,其他需求变更可以考虑延后处理，对于严重需求漏洞就需要及时变更,越往后成本越高.之后开发测试人员会依照新的文档开始工作,但是在测试设计用例或开发代码设计时经过更深入业务理解之后可能又会发现需求的一些问题,会集中反馈出来,产品经理一样会酌情考虑是否延后处理.后面的阶段就是进行用例评审,组织测试等等了.总体来看流程比之前创业型公司顺了很多,至少测试可以较早的介入.当然,测试人员参与到流程改进中也是一大保证.至少我的经历来看,项目延期的几大杀手就是需求变更，无流程和糟糕的项目计划.
2. 对于第三点中的情况,我想作者的意图也只是想要表达场景法设计用例的重要性,而且场景法设计用例的确是贯彻软件测试的始末.如深圳的那位朋友所说,没有一款产品是需要覆盖100%的,我们的策略都是一定要覆盖重要核心的业务,次要的备选流业务可以通过产品,开发及测试三方评审哪些需要覆盖哪些不需要覆盖,以得出测试的范畴,因为即使测试出了bug,也可能不修复,我想不被修复的bug是没有意义的.而且评审过的测试范围即使某天出现遗漏我们也有说法.
3. 对于第一点中谈的代码能力.我个人意见是:这项技能是锦上添花,并不需要每个测试人员都需要具备.但是具备了就可以参与到项目的code review中去,在提测前期就可以发现很多问题，而且具有代码能力的测试人员可能更懂得如何更有效的去测试。
据我对功能逻辑性bug的分析,记住是功能逻辑性的不包括其他类型诸如UIUE上的。主要有3类:
1)大多数bug是很简单的代码错误,如果一经过大家的评审,就能发现出来；
2)一部分是业务理解错误,写的代码不符合业务需求,代码走读时也可以发现部分问题，但是不能发现全部，代码走读也可能只是对核心业务代码或接口部分进行的评审，而系统层面的需要在系统测试阶段才能发现。如果在前期保证产品，开发和测试三方对需求理解的一致性，就可以减少很多这样的bug,不是吗？
3)还有一小部分可能真的是比较难处理的bug，难复现，难调试。这部分东东，测试人员也很难评审出来。
4. 最后我再补充一条：能够将自动化和手工测试很好结合起来开展工作的也是一大挑战。
我相信在很多公司，专业做自动化测试的团队对业务理解不够深刻，他们很多时候都是在研究新的技术完善测试框架，或者按照手工测试用例的优先级编写脚本，然后只是让自动化daily run。而且他们不一定知道测试哪个需求时需要自动化配合做回归测试，或者哪些内容可以提前把关键流程的用例事先实现自动化，等提测之后用来自动化smoke，哪些需求变更了又需要更新自动化。如果通过双方测试人员沟通，这种沟通的成本我觉得也不少。熟练地掌握手工测试技能并且能够自动化实现，在项目测试中很好的配合，以节省回归测试时间，这是一个挑战也是一个趋势。
===========================
zzzmmmkkk,本名赵敏科,6年测试经验,从事过多年功能测试,性能测试及自动化测试,乐于分享。
不定期发布有关测试技术文章,测试经验分享,测试思考和问题探讨
加入“zzzmmmkkk”,可以：
1. 请在微信“添加好友”->“搜索公众账号”里查找“zzzmmmkkk”
2. 或者点击本文右上角按钮后选择“关注公众账号”
=========================== 排版很重要。
页:
[1]
