软件测试人掌握这8大能力直接晋级高级工程师

面试官也经常会给测试人去出一些逻辑题，逻辑题能够分析出来你这个人思维有没有？活跃不活跃？
还有他的维度，包括他想的问题的全面性，都能够判断得出来。
比如说去买一样商品，它的里边逻辑就会经常会出现很多问题，比如说它的会员的级别，
什么样的级别去买什么样的商品，它的价格不一样，什么情况下会给优惠券，什么样的情况下不给优惠券？
达到多少钱的情况下才能够使用优惠券？如果说这里边的逻辑出现了问题的话，那么整个的业务不用再测了

要去测一个网站的逻辑的时候，一定要先思考这一个业务流程可能会涉及到哪些逻辑，
这些逻辑哪些是可行的，有些是正向逻辑，有些是逆向逻辑，都要考虑全面，
而不是说只是把正向的逻辑测试全面了，逆向逻辑不考虑。
其实往往更容易出错的地方就是逆向逻辑

思维导图工具能够起到什么作用，能够让你更有效的进行测试，能够让你的思路更清晰

去测试的时候，不要仅仅只是站在测试人员的角度上去对整个网站进行测试，
还更多的要站在用户的角度，要替用户考虑

把自己的个人能力提升起来，多跟别人虚心请教，多去自己想办法解决问题

在任何的企业里边去工作，肯定会遇到一些工作当中的一些不愉快的事情，
而不是什么事情都会让你很顺心。
所以要去处理工作上的一些不顺心的事情，不要把它带到你的工作上，
或者是你的生活上，尽可能的去跟别人沟通，去解决这个工作上遇到的麻烦

在工作当中可能会涉及到跟开发人员的沟通，跟产品人员的沟通，跟ui人员的沟通，
跟这三方的人员去沟通的时候，就要用不同的沟通方式

如果你觉得你的领导不好，或者说你觉得对你的领导一些建议，
不要的去跟同事之间去说他坏话或者怎么样的，领导需要的是解决问题的人，而不是制造问题的人

跟开发人员阐述缺陷时要简洁明了、清晰易懂。当发现严重缺陷时，
也不要大惊小怪，要站在开发人员的角度思考如何解决问题。
而不是踩在开发头上，炫耀自己发现问题的能力。

当对产品提出意见时，要站在用户的角度去说明自己的想法，
而不要主观认为不好而要求产品进行修改。

跟领导沟通时要有大局观，不能只考虑自己部门的情况。
并且与领导沟通时，尽量直奔主题，不要拐弯抹角，当与领导意见不一致时，
也不要直接反驳，应该先给予认可，再阐述自己的想法。

在集体会议中不要一味的突出自己的个人能力，不要当话痨，也不要默默无闻。
适当的提出一些自己的见解，有助于让大家更加重视你的存在。
切记不要在多人会议中，去指责别人和推卸问题。各个部门的同事，都要面子~

与下级沟通时不要摆高姿态，不要让下级产生畏惧感，应该更多的为下级解决问题。
服务好部门的同事，才能更好的产生凝聚力。

测试周期的时间控制，应当采取多种方法去衡量，
例如人员能力，人员数量，项目复杂程度，
同类项目的测试经验等多方面去衡量。

测试成本指的是人员成本跟时间成本，
不要浪费每个人的时间跟劳动力，
要让每个人充分发挥最大的价值。

测试计划对于一个项目是核心关键，它的存在为了让测试进行中有依据可查。
所以测试计划，一定要切合实际情况，要经过思考和衡量最后得出计划安排。

组员的情绪可以直接影响测试进度跟测试的质量，当有组员出现思想问题时
，应当及时沟通，采取一些必要的措施去解决问题。
而不能装看不见。

任何项目在进行期间都存在许多潜在的风险，
例如，人员离职，生病请假，业务变更，需求变更，服务器或其他组件故障等。
应当提前做出相应的解决方案，以免到时候手忙脚乱。

测试的方向是指测试的目标和测试的范围，很多项目的测试是有针对性的，
例如性能测试，所以在测试中，一定要随时清楚测试的目标和目的是什么，
以免把时间浪费在无关紧要的业务上。

不了解整个公司的业务，
根本就没办法进行测试

了解整个业务里面所需的数据有哪些？
哪些是需要用户提供的？
哪些是自己提供的？
有哪些可以是假数据？
有哪些必须是真数据？
添加数据的时候可以用哪个库？
明白了整个软件的数据库架构，
才能知道哪一个数据是从哪一个表里头带出来的，
它的逻辑是什么，有没有连带关系。

用什么语言开发的？
用的是什么服务器？
测试它的话需要用什么样的环境进行测试？
整体的测试环境是什么样的？
如果缺少了，需要进行环境搭建，架构搭建。
一般去一家新公司之后，架构是搭建好的，
了解它即可，熟悉之前的这些老员工们使用什么样的架构去做的。

整个软件有哪些模块，
比如说首页面、注册页面、登录页面、会员页面、商品详情页面、优惠券页面等等
明白有多少个模块需要测试，每个模块之间的连带关系，进而怎样进行人员分工

任何项目在进行期间都存在许多潜在的风险，
例如，人员离职，生病请假，业务变更，需求变更，服务器或其他组件故障等。
应当提前做出相应的解决方案，以免到时候手忙脚乱。

测试的方向是指测试的目标和测试的范围，
很多项目的测试是有针对性的，例如性能测试，
所以在测试中，一定要随时清楚测试的目标和目的是什么，
以免把时间浪费在无关紧要的业务上。

至少你要满足一般缺陷的发现能力，这个是最基本的，
如果要连最简单的一般的缺陷都发现不了的话，
别说优秀测试工程师了，你说你是测试我都不信

在软件的测试过程当中有一些缺陷藏的比较深，
有的是性能方面的问题，有的是功能方面的问题，
它需要有一些设定特定的条件的情况下才会出现这样的问题。
比如说买双鞋必须选择的是什么品牌，必须选择是红颜色，必须选择44号，
而且必须选择用特定的支付方式才会出现这样的bug的时候，
那么这种就属于特别隐性的bug，
对于这样的问题的发现能力一定要比别人更强，要找到一些别人可能发现不了的bug

当发现了一个缺陷之后，能够想到通过这个缺陷可能会引发其他哪个地方出现问题，
这就叫做连带的问题。而不是说发现这一个bug之后提了这一个就算完了，
一定要有一个察觉，可能其他地方也存在这样的问题。

有些软件里边可能有一些操作模块，或者是代码写的接口，
表面上没有什么问题，但是它是有隐患的，比如说这个接口写的不稳定，
当他传的数据有一些问题的时候，可能它最后返回的结果就是报错就是报404或者报乱码。

如果你只能停留在界面级别的话，那你根本就没有办法达到尽早发现问题的这个能力
你必须要等到前端人员把每个界面都做好了之后才能进入测试，
而我能比你早一个月进入测试了，然后我比你结束测试时间快一个月，
而你又比我晚一个月，那么咱俩的薪资一下就拉开了

需要知道这个缺陷它到底是由什么原因产生的，是属于什么类型的缺陷，
是ui前端人员做的问题，还是后台接口人员做的问题？
不仅要找到这个bug，还要知道这个bug产生的原因，
这样的测试人员是非常棒的，而且很是受人尊敬，提bug的方式也就不一样了

合理的进行人员分工是提高效率的重要保证

比如说测试在赶进度，或者这个软件项目的质量把控是一个团队来把控的，
协助组员解决问题就显得尤为关键

一个团队里边的人员分工，他们的任务都是不一样的，这就是咱们说的配合。
你的东西做完了，要轮到我了，我的性能测完了之后该轮到你了，
所以整个的一个流程下来之后，大家应该是各司其职，配合得非常紧密的一个过程

我给你提bug，你改我的bug，咱们的目的只有一个，就是让这个软件变得更好，
所以在这样的情况下，咱们就一定要配合开发

既然是一个团队协作的过程，就一定要互相的去督促对方，包括督促开发去改bug，
因为开发人员他们有时候工作很忙，他们不知道要先改哪些问题，要后改哪些问题，
但是往往有一些缺陷，它影响了测试的这个时间，影响了测试的进度，
那么这个时候就需要测试员去督促开发人员，让他尽快的去解决你棘手的问题。
这个东西能够提高咱们的测试效率

愿意背锅的最后都成为了领导，不愿意背锅的最后依然是员工

基础知识就是根基，根基打好了，你才能够更有效地往后期发展，也就是为了以后的学习做一个铺垫。
如果根基都没打好，功能测试不会，就想直接学性能，那性能是做不好的

熟悉工具和熟练使用工具完全是两个概念，熟悉工具基本上等同于不会，
遇到过很多简历上写会使用什么什么工具，都没有实际能力。
比如loadrunner只会一个简单的录制，增强一下脚本，
觉得会用了，那知识会用了1/5，其他4/5 都不会。

它是怎么样给服务器发送请求的，是用什么样的方式去发送请的，是用什么样的方式去监控的，
它的操作原理是什么样的，咱们要把这件事情搞清楚，这样的话能有助于更好的去使用这些东西。
包括一些请求的协议，每个协议代表什么意思，它是用来干什么的。

一定要能够自己完成一个独立的内容，独立的工作，
这件事情领导你交给我好了，放心我能给你搞定，要的是这样的人

找出缺陷的时候，不仅要看它的表面，还要看它的本质

发现问题不是能力，发现问题并提出解决方案才是真的能力

测试报告能够说明你表达的清不清楚？领导能不能看懂？
还有就是能不能够把你整个测试的过程给它梳理得非常详细，人家能够通过你的报告，
能够了解到整个的项目的情况，而不是只了解一个片面的情况

触类旁通