本系列旨在帮助大家面试测开/自动化职位时拿到更高打分。
问题均由学员/粉丝提供的真实面试记录，帮大家解答，我义不容辞，但有些问题如果回答的不够仔细和正确，也希望大家能客观的指出改正，轻点黑我。
已征得记录者放到公众号的同意，问题和答案我会脱敏，不会泄露当事人信息。
开始正文...
case越来越多，如何解决代码冗余及业务封装的问题？例如页面有9999个元素，不同的元素会组织成不同的case，互相组织，你会发现case会非常多，case覆盖的元素也是互相重叠的，这样你们有考虑过解决代码冗余的问题吗？
解决代码冗余的直接手段就是提高复用性：这样代码量和维护成本都会降低，逻辑性提高。
对于此问题，我们要从5种不同层面解决：
首先是元素层面上，对元素进行封装，同一个元素出现在不同用例中的时候，只需要调用一个实体即可，
然后是页面维度，同一个页面涉及到多个用例的断言中时，可以给页面提取出来单独封装，以后用例只要进入这个页面，对这个页面的各种断言都直接调用同一个封装函数即可。
然后是事件维度，给有完整且耦合度高的一系列动作封装成一个事件，比如登录，比如注册，比如退出等。在用例中直接调用即可。
最后是用例间重排和封装策略，即根据实际使用的大数据对所有用例进行重新整合。把常黏在一起的俩个或多个用例合并。减少用例之间的初始化和收尾等操作代码。
扩展：为了解决代码冗余和代码量及重复造轮子的成本。可开发测试组技术/业务微型中台，来一次性端之间的自动化用例中重复率最高的成为中台微服务。
如果去到新公司，你能否接受三分二的时间做业务测试，可能只有三分之一的时间做自动化的时间？
当面试官问出这问题的时候，多半是因为担心你不接受业务手工测试。所以你不应该回答是否接受! 你无论回答接受还是不接受，都带着不情愿的心态。
所以知道了面试官的担忧后，你应该做的是彻底打消他这个担忧。
回答：我认为做自动化/测开，应该是以业务为中心，以实际落地为目的。所以即便我可以不用负责业务测试，我也会主动要求去功能业务测试中锻炼，只有这样，我才能最快的熟悉公司的业务，以免自动化/测开跑偏。只有这样，我才能切身的体会到业务测试中的痛点，找出最接地气的自动化解决方案。只有这样，我才能快速融入到同事中，了解大家最真实的需求。
金融相关业务的测试，你觉得最重要的测试点是哪些？
如果你学过iso9126的话，一定知道，对于金钱业务相关的侧重点。
主要是功能性的准确性：件提供给用户功能的精确度是否符合目标。
保密安全性：软件保护信息和数据的安全能力。（抗灾，防盗）
功能性的依从性：遵循相关标准（国际标准、国内标准、行业标准、企业内部规范）
易理解性：软件交互给用户的信息时，要清晰，准确，且要易懂，使用户能够快速理解软件。(很多金融软件的复杂门槛让劝退了很多新用户)
时间特性：软件处理特定的业务请求所需要的响应时间。金融业务功能一旦发生卡顿，除了会让用户产生恐慌外，也极大可能给不法分子提供机会。
易测试性：更加方便和快速的定位和解决bug的能力。（金融产品如果bug修复的不及时，后果不堪设想，造成的损失会极大，也会被坏人恶意利用扩大损失。）
如果说现在要抢购一个商品，一个人只能抢购1件商品。站在测试的角度，你觉得一个用户去并发购买只能买一件的产品，可能会出现什么问题？
问题1：用户成功购买商品多次，造成活动预期效果下降，被黄牛薅了羊毛。主要在于数据库/缓存更新不及时，服务器没有设置高幂等性措施等。
问题2：用户触发风控，全部购买失败，被封号。
问题3：用户只有第一次购买成功，其他次失败，但因为是并发，所以暴露了意料之外的敏感错误信息(如数据库信息)，有可能被不法分子利用。
问题4：用户使用的ip被局域风控拉黑，导致用户周围的邻居，朋友等人都无法成功购买，造成损失和法律风险。
问题5：用户显示购买多次成功，也扣除了多份的钱。但商品数据库最终只算用户购买成功一次，所以会涉及315法律风险。
问题6：接口未预料到此情况，引起商品服务崩溃，活动取消，然后大规模赔偿风险。
问题7：用户成功一人购买多件，然后宣传出去，其他用户不平衡，导致信任危机。
本次就暂时写这么多。欢迎持续关注下一章哦~
