这种的话先去了解他这个人的工作中的习惯，他是怎么样的，你就尽量去（了解）。 假如他哪里有短板，假如他测试用例设计的有缺陷，你就在测试用例评审会议上说你可以。你这个点好像你忽略了。你可以用等价类或者边界值，覆盖到中间件的某一点，跟云端边缘端有交界的地方，你可能要去额外的注意。还有UI，你可能是整个页面的边缘上下左右，一个表单，它可能第一页跟最后一页容易出问题，第一个按钮跟最后一个按钮容易出问题。 这是工作上面，生活方面除了工作之外的，假如他吸烟，当然我不吸烟，当然可以去请他们吃饭。因为我们上家公司是这样的，新员工进来第一天会带他们去请他们吃饭，公司报销。当然我直接连续几天请他们吃中午饭。趁开始的时候就先入为主，给他输入一个公司里面有一个很好的，能够帮助你走出困惑，走出懵逼状态，有这么一个人，愿意这么个热心的人，你能够安心稳定的在这里工作，这是指导。除了工作之外的是这样的，如果这两个都不行，都失效了的话。 只能，我遇到一次，之前我们研发组有一个开发，我问他，我跟他争论一个点，让他反正改业务逻辑，他我行我素，我就用我的方法，我不改。这个时候怎么办？他当时态度很差，喊起来了很大声，态度很差，但是我也没有跟他正面冲突，就走开了。让这个事情先冷却下来，之后找个机会隔一两天找他的直系领导说话。 诶，领导，刚才你们组里那个人好像是说话脾气也声音有点大，把我吓惨了。都这样说，相当于点到为止，让他的领导下面去操作。当然至于他是怎么操作，是去训斥他一顿，还也是跟我一样淡化处理，你下次不要这样了。但是我不管了，我只是点到为止。你如何如何？大概是这个情况。
测试效率达不到。可以这样多个多给他派几个任务，假如一天他本身能够 handle 住 3 个需求，假如 3 个测试点，一天给你多派一个，让你可能有点手忙脚乱的，当然是这中间测试用例评审，每一个需求都会跟紧，推进测试用例的评审，还有一些详细评审。 最后，因为我们有一个研发的 jaCoco 测试的覆盖率的一个插件，就是你新增的逻辑点，或者改修改的逻辑点，你有没有覆盖到，最后报告会出来的，会呈现。如果给你了 4 个需求，你只测了 3 个，最后一个没有覆盖到这个时候上线肯定不能上线，全公司等你，他肯定也是不行的，肯定也不行的。 他肯定也会加把劲。如果他真的是有点老油条，一天就给他买奶茶，给他买KFC，端到他位子上让你测，对吧？我都这样了，你还不测，你没法等你绩效 c 了对吧？等你绩效 c 3 个月出去你就完事。
一天上线，必须要上线。我遇到这种情况，一天必须要上线，就是先接下来，一般是产品提需求，他说需求我今天评，明天我要上线，然而我们心里都知道明天可能上不了线，可能我们评估工作量，在心里默估 3 天。这个时候怎么办？我们指先答应他能做这个能做，不是不能做的，能做。我们接先把活接了。 下去把任务拆分一下，涉及的功能点，逻辑点，测试点，要修改的哪些点，去拆分一下，看有没有可能性。如果可行，如果只改一个枚举值，从 0 改到1，从 a 改到b，可以。我可以评估精准测试的思想去评估到改哪个表，把它影响范围圈定了，是明确了可以上线，我们就可以上把相应的研发环节详细评审跟测试用例。评审卡到位就没问题，上线没问题。 但是如果第二种情况就是评估测试点下来，发现改动的范围很大，不像你说的从把一个字符串改成把一个，从 Int 类型改成一个 string 类型，好像没有你说的那么简单。一天就上线，这会涉及到很多的业务点。 就有一次有一个我们产品说把我们主表，我们有个机器，有一个叫栈号的概念，叫 number ID， 原来是 Int 类型。他有一天上来说一个需求，他说我们要改成 string 类型，以适配不同的下位机，要兼容不同的下位机。他说就是一个数据类型的更改，你明天就上线。当时我们也是。接下来我们去分析诶，发现表涉及到每一张表都会涉及，每个业务，每一个页，每一个代码层都会涉及，这个就不行了，直接跟他说要改，你不行，你要上线就绝对崩了。
加班也是当然可以接受，但看情况，这业务你没测完，你肯定是要加班的。还有根据业务紧急程度，业务方的紧急程度，你假如一周后就要上线，假如直播业务一个送礼的过程，送火箭的功能，还是像刚才说的，走研发流程，拆分分任务，走相应的研发测试流程去做上线。这样。
加班严重那就有的说了。好像是我刚进这家公司是去广州那边，因为我们是上海，他这个项目可能还在调研阶段，还没正式起来，我先去。我们先去广州，去了一个月，支援的是一个电商APP，就卖xx的，像 1688 那种电商软件。当时真从起来是第一天的 9 点到第二天的下午 3 点，连续通宵。因为产品方说的第二天早上 8 点就要去做给销售去推广，销售就要去跑客户了。死命令必须要完成，因为研发经理也在场，他全程都在陪同，那就没的说了。对。
我上家的公司也是调休的。
加了一家公司，最希望现在的实话对于我来说能够业务稳定一些。对，不受。因为现在整个行情，整个经济情况波动得很厉害，有些公司它可能就会倒闭或者是裁员啥的。对于公司的业务的运营的状况，还有研发团队，这些东西能有一个稳定的历史和稳定的能看得见的稳定的未来
最近希望能够。当然现在找一份工作，毕竟也 3 月份了，玩了这么久了。因为上家公司主要做自动化，下一个家公司可能也是做大多数做自动化。当然进去先做功能也是必须的，因为上一家公司已经起了框架，框架已经非常熟悉了，下一步就可能一个平台，把前端学一学，因为这个框架说白了还是有一点入门的门槛的。有一些功能人员他不会写代码，望而却步了，阻止他们了。可能有个平台，那就是有人性化的操作，你会基本上就用，你会敲，你会电脑会输入字就可以用平台。是这样。
漏测当然有，我们漏测的百分比不能高于3%，这样子漏测有没有漏，我漏肯定是有。有这种情况。当然可能无非产生这个原因，就是你当时跟开跟产品的沟通，可能有断层，或者产品它可能也有。有一点东西有一些细节他没讲到位，或者他想当然的理解。这个很简单，我就这么说了。你应该能理解我的意思，我就不说很详细了。沟通是方面的这些问题，当然技术方面当然是利用测试方法，这一方面是没有问题的。我是没有问题的。
😍😘❤😝😜😀😁😂😂😂😂😂😄😋😘😄👍🙃🙃😝😜😝🙃🙃🙃🙃🙃🙃🙃
使用的是assertpy第三方库，对于字符串可以用assert_that("test").is_equal_to("test"),判断有is_length\is_true\is_empty\contains\starts_with 对于数字来讲，可用is_equal_to\is_greater_than 对于list、dict来讲，可用is_length\contains\is_length\is_empty\is_type_of 当然对于可迭代对象可用extracting提取索引或者相应的key再做断言 除了这些常规数据结构，还支持自定义对象的断言，比如assert_that(obj).is_instance_of(ibj)\is_type_of
从研发流程解决， 紧急情况，修改用例应对