天天在谈测试技术，回过头来发现，技术背后的基础是测试最本质的内容：测试用例。
做了将近5年的产品测试，一直都在研究测试技术，突然有一天（就在最近）产品质量发生雪崩，让我开始思考原因：
为什么：产品出现BUG；因为：测试发布了带BUG的线上产品
为什么：测试发布了带BUG的线上产品； 因为：测试用例不完善
为什么：测试用例不完善； 因为：？？？？？
希望老师回复下，给我指导下！
怎么才能提高团队凝聚力、提高效率呢？
现在的团队待的很窝火。
我们是9个开发 2个测试，做一个网站。开发和测试总是沟通不顺利。
1、开发排任务的时候，总是拖拖拉拉，规定时间测试问大家都完成没，部分开发不回应，等我们发现有大量任务没有排完成时间的时候，他才站出来说自己还没有排完。
2、在做任务的时候，开发只顾自己负责的一亩三分地儿，有的连需求都不搞懂也不问就开发。提测后发现开发出来的功能和原型差别太多。
3、开发不注意自测，提测的功能有很多低级bug。明明可以注意一下就能避免的问题，却还要我们提交bug后才修改，浪费时间。
怎么才能消除上述三个问题呢？为什么开发就不能和测试好好协作呢？
m5433660 发表于 2018-9-19 17:11
王老师你好！
我们公司现在产品业务比较稳定，打算做接口自动化，目前遇到以下几个问题想请教一下：
1、 ...
感谢参与，很抱歉没有及时回复。
从功能测试向接口测试尝试，从方向上是值得肯定的，离代码更近，会测试的更细致，先为我们自己鼓掌。
1、语言只是工具，掌握一门高级语言，切换成其他的是不难的。我之前都是用C/C++的，到16年才换的Java，感觉是平滑过渡，很快就掌握了。
同时，现在很难有一种语言走天下的事情了，掌握一门主要编程语言，其他的脚本语言也是需要会用的。测试Javaweb的程序，JS肯定是要了解的；与linux打交道，shell/awk也是必须的了。所以擅长的语言不一样，不应该成为开展工作的障碍，各种语言互通有无，恰恰是优势。
不好统一的应该是主语言的问题，其实流行的就是：python java c++ C#。每个人单独写的工具，可以不做规定，但团队层面的框架需要统一主语言，统一的方式可以采取一些竞争方式。能够将技术方向说明白的，估计也就是几个人，几个人如果已经统一了，直接开展工作。如果不统一，各自限期拿出方案，之后进行对比分析。
最好的情况是大家争先恐后，最后负责人是幸福的烦恼，最终比较方案的可行性、结合其他成员的实际情况、再考虑一下后期招聘和培训的问题，进行选择。这里面需要参考的一点是，要看一下被测对象的开发框架，最好能够靠一下。有两个好处：1、了解开发框架的机制，能够测试的更细；2、和开发人员多一些共同话题，有助于项目进步。
不好的情况是大家畏首畏尾，没有建设性意见，这时就要依靠个别人的能力了，其实也好办，目前网上
各种框架是很成熟的，花时间尝试一下，没有绝对正确的方案，参考上述方面选择合适产品的。
不好不坏，就是方案层次不齐，选择质量最高的就可以了。
2、在原本工作中增加一项工作，不是所有人都认可的。但话可以反着说，不是所有人都不想在原本工作中增加一项工作的，有些人就是想做有些新东西，学有些新知识，可以依靠这部分人，逐步实行，通过少部分人的努力带动整个团队的整体氛围。同时，在考核文化中，增加一定的鼓励机制，我了解过某互联网公司的
测试团队，很明确的一条就是完成本职的测试工作是基本的考核基线，如果想要优秀就必须有新的工具输出、新的框架推广、新的专利提交等等。
业务测试和接口自动化，最终肯定是相辅相成的，接口自动化要明确远期的目标如何提升了业务测试的效率；业务测试也要逐渐慢慢依托于接口测试，最终成就接口测试。
最开始的期间，会有些矛盾。可以调和的，就参考上面的“带动”方式，进行调和；
不能调和的，以业务测试为主。但在分析的时候一定要实时求实。
3、在这，只对技术上提供一点建议，管理上还需要自己根据团队情况进行规划。
首先，确定远期的目标，一定要想明白、看清楚，接口在可以预见的时间给出成绩，如何提高了效率，也就是分阶段的，确定接口测试在整体测试中的作用。最终的结果肯定是，能够替代一大部分手工测试才可以。
第二，理一下能够完成咱们这个工作的工具、框架，尽量多收集一些方式方法，做一个初步的筛选。
第三，选择其中3-4款，进行实际的试用。要结合本身项目的业务做试用。其中会涉及到网络协议、数据库等方面的知识，要根据被测系统的情况来看，所以这个阶段需要查阅比较多的资料。
第四，确定1款涉及本身项目的技术路线，进行小范围试用，微调方案，如果实在不合适，要尽快改正。
最终，大规模推行。
这个过程一定要坚定信念，小步快跑。一个建议是，如果遇到摇摆不定的选择时，就相信自己的直觉，快速决定，不要考虑太多，实践才是硬道理！
学习路线要根据团队实际的情况，待测系统的实际情况进行分析。
如果团队基础比较好，可以直接就进行上面的方案分析、试用；如果基础比较弱，需要分析一下待测系统接口测试需要的知识，进行系统的学习。比如，系统是否用到数据库，哪种数据库，如何操作；是否用到网络协议（更具体的是ssh telnet hdfs），需要对实际的协议进行学习。
实际的经验是，开始的时候用不到各方面很细的知识，只要有对知识本质的理解，到时候逢山开路，遇水搭桥就可以了。
祝国庆愉快，马到成功！ 乐哈哈yoyo 发表于 2018-9-26 15:11
公司接了个项目然后给了其他团队做，中途换了两个产品经理，之前的团队也解散了，然后我接手了这个项目，项 ...
虽然与主题无关，还是感谢你的参与。
我的答案永远是：坚持，而且是必须坚持。
我甚至没有问你失望的点是什么，是客户需求总变？是开发同事扯皮？还是开发同事能力太差？…………
不管是哪种原因，在一个公司上班，拿一份工资，就要对得起自己的职业道德，只要是对公司、对项目有利的事情，一定要坚持。
无论是哪种问题导致你的失望，你需要想尽一切办法去改善这个事情，因为有个事实要接受，现在公司遇到的事情，很可能在其他公司也会有。
你现在因为解决不了而放弃，结果就是后面再遇到也是无计可施。
祝国庆快乐，柳暗花明！ 悠悠小仙仙 发表于 2018-9-26 15:14
天天在谈测试技术，回过头来发现，技术背后的基础是测试最本质的内容：测试用例。
做了将近5年的产品测试 ...
虽然无主题无关，但这个问题我很感兴趣。问题也比较深入，说明你是一个认真思考的人，我的看法也是一样的，测试用例是测试最本质的内容。
我刚工作的时候，我的指导人说过，测试用例是测试人员的代码，我觉得很中肯。
测试用例不完善的原因有很多，可以根据实际的情况进行分析和整改。
业务不熟悉的，精耕业务；验证点不到的，增加验证点；市场反馈的问题，进行回溯分析等等。
我经历过的项目很多，但测试用例真的很完美的非常少。团队中不是每个人都能写“完善”的测试用例；一个人也不是每个时间都能写“完善”的用例。
原因当然还是多种的，有一点很关键：测试用例的通过太过人性化，不够规范。
可以规定测试用例的格式、评审的粒度，但在我看来，这个过程取决定作用的是写用例的本人。功能太多，各人自顾自己的功能用例设计尚且不暇，对别人的用例评审自然也只能睁只眼闭只眼了。少数责任心强，能力强的老员工，精力也是有限的，无法对所有的用例进行仔细分析。
结果，写出来的用例有的太繁琐，不可测试性太强，比如用例中出现：操作多次，界面友好等不专业的说法；有的想的很美好，实际无法操作，比如用例出现：测试所有非法情况等只有作者本人才明白的说法等等~~
那么怎么才能规范用例的编写的？实际就是在个人设计用例的时候，增加一个第三方的校验流程。
我的方法是把用例写成代码，并能编译通过。
1、能够自动化的，直接写成自动化代码。
2、不能自动化的，写成注释+打印的伪代码。
一方面，在写用例脚本的过程，有编译器的限制，提供了用例编写出错底线；另一方面，写成代码的时候，人就不会用一句一时兴起的话来编写用例了。人，最难忽悠的是自己。
我所在的团队在如此做的时候，大家普遍的反应就是发现之前的用例太粗，当转为用例代码时，用例的可用性上提高了一个档次。
有一点，需要有科学的认识，测试是无法消除所有BUG的，所以不要求全责备，抓住重点，保证别出“雪崩”。
祝雪崩与你永别。 巴黎的灯光下 发表于 2018-9-26 15:24
怎么才能提高团队凝聚力、提高效率呢？
现在的团队待的很窝火。
我们是9个开发 2个测试，做一个网站。开 ...
同情你呀，整体氛围不积极的团队，干活很累，辛苦了。
首先，团队的问题，我感觉不是出在测试上。测试一共就2个人，不是氛围的始作俑者，再者这三个问题测试并没有做错什么。当然，他们可以做的更好，比如更积极的去了解、去与开发沟通。不过问题的根本还是在开发的几位同学上。
开发同学的这种“无私者无畏”的气氛的具体原因分析过吗？
只有了解了问题的原因，才能因地制宜。
是对公司的（或者项目的）方向不认可，感觉没干头？还是待遇上满足不了大家？
有些是可以满足的，有些是可以引导的，希望你能根据具体原因进行解决。
1、开发的任务给出明确的要求，什么时间完成什么样的任务，需要回应的明确的告诉大家要回复。
有不及时回复，马上当面询问，为什么没有回复？并告诉他下次一定要回复。做事情以项目为公，不要在乎自己的面子问题，实事求是。
非常时刻可以引入奖惩机制，不好罚，可以赏，得不到赏的自然就是变相的罚了。
2、每个开发人员追求不一样，有的就像种着一亩三分地，你就随他做个小佃户，但要求要讲清楚，每次分配任务要出具需求分析的文档或者简单设计。
区分一下有没有想做地主的，给他（们）提供资源、激励倾斜，少数会带动多数的。
3、开发的自测是否作为研发过程的必选？加强研发过程的管理，自测的过程不仅仅是一句空话，自测报告提供，内容的完备都细致的规范起来。
开发和测试如果在正向问题上进行争论、冲突，是需要鼓励的。我之前做测试的时候，吵的最凶的两个开发，在我换了两次工作后还保持联系，关系非常好，
关键在于发力的点是以项目利益为根本的。
祝你早日消除问题。 王老师，请问金融行业的系统交互目前是多个系统进行交互，进件-核心-扣款，中间还穿插其他的系统。这种情况想要做自动化的如何下手呢？有没有好的建议，目前对自动话这块还不是特别了解，是否能提供好的思路和建议呢？谢谢 王老师，抱歉我想问下与本次主题不太相关的问题。我是一个测试新人，我们公司是个小公司，测试只有我一个人，然后有一个产品是我们自己用的，在我进来之前已经使用了蛮长时间了，现在我要对这产品进行测试，但我完全不知道要如何开始。要是对客户使用的产品我还有点思路，但这种我就:'(。能否给我提供一点建议，谢谢 慕鱼非鱼 发表于 2018-9-28 16:26
王老师，请问金融行业的系统交互目前是多个系统进行交互，进件-核心-扣款，中间还穿插其他的系统。这种情况 ...
抱歉回复晚了，国庆休息了一下。
整体系统能够分成多个子系统，从测试角度是个进步，可以以此为基础进行细化。
1）是否有一个统一的对外界面，通过界面的操作进行界面的自动化测试。这点模拟的就是我们初级工程师的基本功能测试，主要的工作是点点点。由于多个系统交互，对于能够进行打桩的地方，通过技术手段进行打桩，一方面可以提高界面自动化的成功率，一方面增加验证点，提高测试的针对性。
2）对于已经划分的子系统，分阶段进行子系统接口的自动化，之所以要分阶段，是考虑到精力的问题，指导思路是“伤其十指，不如断其一指”，各个击破。对于子系统的接口自动化，需要考虑可行性，就是该子系统的接口定义是否清晰，开发结构是否允许单独抽离进行测试。如果技术上可行，接口上下行的数据还是需要打桩，通过多种测试数据完成接口的覆盖。
具体的技术路线，需要结合开发的框架，团队的情况进行深入考虑。祝你顺利。 liyl4396 发表于 2018-9-29 16:19
王老师，抱歉我想问下与本次主题不太相关的问题。我是一个测试新人，我们公司是个小公司，测试只有我一个人 ...
我大概理解公司自用的产品，类似于OA之类的系统。自用的系统与对外卖的产品是有区别的，可能对界面的美观、易用性、性能等都有比较大的容忍度，所以在测试中要把握好度。即使是这样说，测试要做的事情还是很多的，也是需要做细的。
首先说基本功能测试。其实说对客户使用的东西会有思路，因为你知道客户大概是怎么用的，之所以对自用系统没思路，大概是因为有些流程你不太了解，这就是所谓的业务了。自用系统有每天都相关的考勤流程、财务流程等等，也有接触不到的比如销售流程、产品维护流程等等。每个系统的业务都是需要花时间去研究的，当自用系统的各个流程都有多了解后，基本功能的测试相信你会有思路的，接着而来的就是测试设计、用例编写这些老生常谈的东西，需要你根据具体的工作要求输出超出预期的结果来。
之后是自动化测试。根据基本功能测试的情况，进而研究如何提高测试效率，提高测试针对性，估计会引入界面自动化、接口自动化这些内容。
之后就是性能测试、安全测试这些可能自用系统不是特别关心的东西，如果有时间和精力，建议还是实战的运用一下。自用系统规模小，很多问题方便分析，反而进步更快。
祝你早日做出成绩。 wanglidong1224 发表于 2018-10-8 10:49
我大概理解公司自用的产品，类似于OA之类的系统。自用的系统与对外卖的产品是有区别的，可能对界面的美观 ...
非常谢谢您的回复，谢谢！ 王老师说得实在太好了，收藏。 王老师，有没有QQ 群 没有qq群。可以加我qq315567708
多多讨论。
页:
1
[2]
