前段时间有位小伙伴临时抓包的笔试救场，题目如下，感兴趣的小伙伴可以参考一下。能够借鉴的话，固然是极好的。
题目：
现有一个包含10个输入单元（文本框、下拉框等）的新增表单页面，请你设计测试用例，然后补充说明用例分类、各类别用例数以及总用例数。（10分）
答案：
①：该考察题目的需求尚不明确，如输入单元是否包含有必传项与非必传项、输入单元的可控长度、可传输数据类型等。
②：实际工作过程中，面对需求方给予的尚不明确、存在一定问题的需求文档。应与需求方进行有效的沟通，或头脑风暴、或需求评审会，通过思维碰撞与换个角度看待问题的方式，将需求进行有效的梳理规划，在项目周期上可以起到进一步的推动作用。否则会存在一定的风险，在上线前需要做风险评估分析与风险应对预案。
③：有鉴于无法进一步的针对需求进行有效的确认与沟通，我无法提供有效的用例数与总用例数。
④：同时因该需求不适用传统的流程类测试设计。故选择“探索式测试”方案结合“参数类”、“数据类”、“组合类”的测试设计模式进行了测试计划的方案梳理。（参考 “题目1：输入单元用例设计.xmind”）
⑤：探索式测试的优势在于能够根据测试结果及时的调整测试策略与测试点。更有效的发现产品缺陷。例如发现探索路径中的的功能质量非常的好，就可以适当的减少探索度。反之，亦是如此。
题目：
如果上述功能需要紧急上线，你如何设计测试用例，以保证产品的质量？（10分）
答案：
①：面对紧急上线，从测试人员的角度来看，往往是一种“破坏规矩”的感觉。造成这种感觉的根本原因就是“分歧”，所以此时最直接有效的方法是“有效的沟通”，这种沟通“既要对事，也要对人。”“对人”意在强调在沟通时要换位思考，理解沟通的对象，在表达上也需要以能够理解的方式来表达。
②：对于测试人员与测试团队来说，测试用例与产品缺陷是主要的输出。用例会影响测试的执行；执行又会影响到缺陷发现，影响产品的质量。良好的沟通可以让测试人员获得对产品测试非常有用的信息。
③：鉴于考察题目1为一个不完善的需求，这里就以此为例。针对该紧急上线，首先需要做的就是针对该需求的上行或者下行，在不影响业务基线的情况下设计一套合理且趋于完善的测试策略，该策略以业务基线为主，“结果导向错误逆推”、“数据传输过程所产生的的安全问题”为辅进行测试用例颗粒度的控制与质量的把控。（参考 “题目1：输入单元用例设计.xmind”）
④：风险识别：分析测试策略开展所带来的阻碍，进行风险识别。
⑤：风险评估：对识别出来的风险点进行评估，确定风险优先级，优先处理高风险的问题。
⑥：风险应对：结合风险与项目的实际情况，与兄弟部门制定合适的风险应对预案。
题目：
请具体说明你独立完成过的最有挑战性的功能测试/接口测试/性能测试/接口自动化测试/UI自动化测试具体是如何进行的（从测试方法、测试工具或框架、测试流程、主要难点及应对方法等方面阐述）(20分)。
答案：①：在早期的自动化项目中，我所做的自动化项目是一种目盲的追求测试用例覆盖率的项目落地策略。一味的认为针对测试用例进行高度的覆盖就是一个非常不错的自动化项目。随着越来越认识到“自动化实施成本”与“评估自动化的收益”的问题，开始摒弃这种自动化的策略。同时期该策略也越来越在测试领域被众多测试研发人员摒弃。
②：2017年之后开始越来越重视“自动化成本”问题，自动化并不廉价，相反，自动化还很“贵”。自动化的本质是用一段程序去测试验证另外一段程序，这中间需要花费的时间成本其实并不比开发一个新的产品的工作量少多少。时间成本、人力成本和技术成本，都是自动化中需要考虑的成本。
③：在开始思考到自动化成本问题之后，第一个UI自动化落地项目是基于 “RobotFrameWork”（后续简称为‘RF’）来实现的。“RF”的测试案例可以封装为一个一个的“业务关键字”，通过调用这些封装的关键字，来实现测试用例。同时“RF”也可以利用分层思想将自动化测试案例的实现过程分成不同的层。从而实现代码的复用性、可扩展性、维护性。
尽管如此，但“RF”的缺点也很明显。比如“界面反应速度慢，经常卡死”、“导入测试库有时会异常”、“ 关键字驱动 意味着动态对象无法获取，数据、对象跟用例强耦合难于维护”等。
④：同样如此，第一个接口自动化落地的项目是基于“Jmeter”实现的“轻量级接口自动化测试框架”。之所以选择该工具的原因是“Jmeter”的学习成本并不高；而且开源、免费、足够轻量；对HTTP协议的支持非常强大；扩展性也比较好；编程能力强的情况下可以自己写插件；同时支持各种断言等。与“RF”一样，使用“Jmeter”实现的轻量级接口自动化测试框架同样存在问题。如：受制于本身的限制，与直接使用语言进行接口测试相比，灵活性相对不足；JMeter本身的测试报告主要用于性能测试，反映的更多是性能测试层面的结果。而且配置过程比较复杂，在团队成员分享报告等方面比较麻烦；测试脚本和测试结果的管理：脚本和结果基本都是本地管理，无法做到在线管理。
⑤：虽然“RF” 与“Jmeter”这两款开源工具在学习成本上较少，而且落地项目的速度非常的快速便捷，但鉴于二者都是工具类产品，在灵活上都存在着一定的不足之处。最后还是在后续的项目中通过 “编写脚本”的形式来实现自动化方面的项目落地，包括“UI自动化、API自动化与Appium”
题目：
请结合测试工作中的实际内容，说明利用代码实现完成了哪些替代性工作，效果如何？如果涉及框架，请说明如何选型以及选择的框架优势是什么？
答案：
①：自动化测试的作用是什么？把人为的测试行为转化为机器执行的一种过程，目标是为了节省成本，提高测试效率。换而言之，就是通过代码的手段，用一段程序去测试验证另外一段程序，把部分手动劳动转化为机器操作的方式，就是自动化测试。
②：以我最近的 “XXXXXXXXXX”项目为例，全程参与了该项目的头脑风暴、产品立项、需求评审…的从0到1的全过程。前期的测试计划、测试策略、用例基线工作排除掉，在通过冒烟测试之后，根据业务功能的用例基线，之后开始编写基于 Python 实现的 Appium 的自动化测试脚本。初期的思想就是在保证整体的基线流程质量的前提下在进行结果导向的错误逆推反例测试。所以在前期的阶段，Appium 的落地在缺陷修复与测试版本更新上节省了大量的测试时间。
③：“XXXXXXXXXX”的运营后台管理系统在通过功能测试之后，也基于 Python 的Selenium 实现了WEB端的UI自动化。该后台系统为运营人员所使用，只有单系统登录与查询功能。因其需求变更、页面元素变更不频繁，故最终落地了“UI自动化”。同时因其功能单一，“UI自动化”的落地实现了该后台管理系统的测试用例高度自动化覆盖。