软测项目辅导综合教程
介绍项目通常包括以下几个方面内容，顺序不限。项目介绍内容要精简，不要使用广告词语、销售话术。注意这里说的是面试时口述的项目介绍，而不是简历中写的项目简介。
- 项目名称、项目由来
- 项目开始时间、结束时间，或者现在的状况(测试完成、还未上线)，
- 项目团队人数，多少开发、多少测试
- 项目产品包括哪几个，我负责哪个或者哪些
- 我负责测试的模块有哪些，每个模块的主要功能
- 我除了做功能测试之外，我还使用哪些测试工具用来做什么其他类型的测试
- 一共写多少用例、发现多少缺陷
举例ecshop类似电商项目：
- 我最近做的项目是娃哈哈电商项目(项目名称)，这个项目是我们公司为娃哈哈食品有限公司开发的他们公司的电商门户平台(项目由来)。
- 整个项目包括了1个web版的后台管理系统、1个web前端购物网站，和安卓版、iOS版的2个app产品(项目产品)
- 项目是从2021年10月开始，计划到今年5月上线，目前已经完成内部的系统测试，等待交互用户，测试组已经停止了工作(项目时间)
- 这个项目一共20多个人，开发有10多个，测试7个人。组长和2个同事负责后端web管理系统，2个人负责web网站，我和另外一个同事负责2个app的测试(项目成员职责)
- app的主要功能模块有5个，分别是首页、分类、聊天、购物车和我的，我负责其中首页、分类和购物车这3个模块的业务分析、案例设计，但我们2个人都要执行app的所有用例。(本段及以下5段都是我负责模块的介绍)
- 首页主要是搜索框、轮播广告、分类导航栏、促销商品和分类商品推荐，分类导航栏就是将热卖的商品分类做成导航便于用户直接访问该分类下的商品，比如饮料、矿泉水、牛奶等分类导航，分类推荐就是将各分类中各热销的商品进行推荐
- 分类就是分类搜索，可以选择分类进行搜索
- 聊天就是和客服进行线上交流，分为聊天记录列表显示和进行聊天2个功能
- 购物车可以查看购物车商品，修改删除商品，修改选择的活动、优惠，进行结算
- 我的中的功能很多，包括了系统设置，账户管理，我的订单，我的优惠，我的金币，我的收藏，我的收货地址等
- 这个项目我一共写了800多条用例，发现了接近60个的缺陷(用例和缺陷数量)
- 我除了做功能测试之外，还独立负责了app的所有接口测试，是使用postman做接口测试，用jmeter做接口的性能测试，用solopi做app前端的性能测试，运行monkey做app可靠性测试，以及sql注入的安全性测试，使用mysql做数据库的数据检查，用fiddler抓包定位缺陷。还参与了appium自动化测试，负责了商品搜索、购物车和结算模块的PO(PageObject页面对象)对象封装和测试方法的编写，我们的appium运行的是python版本，使用unittest做测试框架，ddt组织测试数据参数化，数据来源是通过excel读取(其他测试)。
其他类型的举例，没有提及的内容就参考娃哈哈电商项目：
- 我最近做的项目是上海烟草集团后勤与员工福利管理系统。这是我们公司为上海烟草开发的用于他们后勤管理部的办公用品申请、后勤物资管理和员工福利货币化管理的系统。这个项目包含1个web版的后勤管理系统和2个前端app。项目组8个开发、3个测试，我负责2个app的测试。app有首页、办公申请、员工福利、清单和我的。首页是后勤管理部公告和我的进行中订单列表显示；办公申请是员工按部门人数限额申请办公物资，按申请金额和物资分类特性，有的需要部门经理从首页进行审批，有的直接到后勤部直接分发；员工福利是一个电商模块，员工使用基于工龄和岗位级别计算的定期分发积分抵扣部分货币化员工福利；清单就是购物车。
- 我最近做的项目是永辉超市线上系统。这个项目包含1个web版的后勤管理系统、2个前端app和1个微信。
举例seafile类似云盘项目：
这个项目是我们公司给中国移动上海研究院开发的内部文件加密管理系统。项目从2022年5月开始，到2022年12月交付用户。整个项目包括1个基于加密webapi的web前端和1组服务器端系统组成。服务器端系统一共由20多个模块组成，有加密RPC协议模块、数据库管理模块、NoSQL键值管理模块、消息管理模块、块存储管理模块、文件管理模块、版本管理模块、仓库管理模块、权限管理模块等，web前端包括人脸识别登录、仓库管理、文件管理、工作组管理等模块。项目组有10多个人，测试5人，4人负责服务器端的测试，我负责web前端的测试，重点是大量和服务器端的联调测试。指定终端的人脸识别登录后，创建动态令牌；仓库管理中可以增删改仓库、资料库和目录，设置密码，查看仓库和目录中文件列表；文件管理中可以上传、修改、删除文件，分享文件，审批文件，提交版本，设置密码；工作组管理中可以创建、修改、删除工作组，设置工作组成员架构权限，设置密码等。
举例aeaicrm类似crm项目：
奥康CRM项目是我们公司给奥康集团开发的客户关系管理系统，这是温州的一家制作皮鞋、皮包的公司。项目从2022年5月开始，到2022年12月交付用户。项目采用B/S架构，使用php语言的zend框架开发，后台数据库是mysql数据库。项目组有9个开发、4个测试。系统包括销售管理、客服管理、财务管理和系统管理4个部分，我负责其中的销售管理模块的业务分析、案例设计和执行。销售管理主要是一个销售漏斗，由他们的市场部使用，实现对经销商、加盟商等客户的销售管理，功能包括了潜在客户管理、客户信息管理、线索管理、商机管理、拜访管理、订单管理等。
举例龙戈小额贷类似小额贷项目：
东山小额贷管理系统项目是我们公司给东莞康华投资集团开发的贷款管理系统，项目从2022年1月开始，到2022年11月交付用户。项目采用B/S架构，使用java语言开发，后台数据库是mysql数据库。项目组有20多个开发、7个测试。系统包括产品管理、流程管理、客户管理、贷款管理、担保管理、财务管理、报表管理和系统管理等10多个大模块，我负责其中的客户管理模块和贷款管理中的贷前贷中模块。客户管理包括了创建客户、客户调查、客户修改、客户分类、客户查询、客户征信查询、客户关联人查询、客户经营活动查询、客户金融业务查询等；贷款管理包括了贷款申请、贷款受理、项目调查、贷款审批、合同管理、放款审核、资料归档，贷后的收款、逾期、展期、结清、资产管理等功能是其他同事负责的。
举例棉花糖餐饮管理软件类似餐饮项目：
海底捞餐饮管理系统项目是我们公司给北京海鸿达餐饮管理集团开发的企业内部管理系统，项目从2022年1月开始，到2022年9月交付用户。系统分为B/S架构的集团管理系统、门店收银台系统、营业员pad点餐宝app和微信小程序4个部分组成，后台使用php语言和mysql数据库开发。项目组有10多个开发、4个测试。我在项目中负责收银台和点餐宝app的测试(如果会微信小程序的测试，则改为负责点餐宝app和微信小程序的测试)。(负责哪些就只介绍哪些)收银台系统包括堂食、预约、查询、会员、后厨、仓库、报表和系统设置等模块，根据权限设置供门店不同部门使用。app包括了开台、点单、餐单和结账4个模块。微信小程序包括了首页、活动、会员和我的4个模块。基本工作流是餐桌开台、点单、下单、餐单调整和结账，测试的重点是各种餐品类型的点单和调整，以及结账中各种费用的计算核对。
举例GreaterWMS类似仓储管理项目：
TAWMS系统是我们公司为山东金塔机械集团开发的智能仓储管理系统，用于公司和关联供应商、销售商的化工机械原材料和成品的仓储物流管理。整个系统包括了一个web主系统、关联企业接口程序以及一个掌上机app组成。主系统包括了系统设置、入库管理、出库管理、库存管理、物流管理、报表共6个模块。掌上机有司机、装卸、分拣、仓管4个模块，根据登录员工的角色只显示专用模块。后台接口程序主要是接收关联企业推送的货品和出入库单数据。项目组有7个开发、3个测试，我在项目中负责入库管理、库存管理这2个模块，以及app的仓管模块。这个项目我一共编写了1100多条用例，发现50多个缺陷。
- 瀑布模式的答复
- 需求分析：评审需求文档、设计文档，邀请开发给我们做需求和设计的培训；
- 测试设计：采用质量模型分析、功能交互分析和用户场景分析的分析方法，用思维导图编写测试点，同时小组配合编写测试计划和方案。我在这个项目中负责xx、xx等n个模块的设计。
- 案例设计：对每个测试点采用恰当的案例设计方法来设计测试案例，然后评审案例的准确性、无歧义和覆盖完整性。xx模块中xx功能我采用了xxx案例设计方法(针对该设计方法展开阐述一下设计过程)。我一共设计了nnn条案例。
- 搭建测试环境，准备测试数据：CMO搭建环境，开发提供基础数据的脚本；
- 执行冒烟测试：我们自己编写的selenium、appium冒烟测试脚本，运行主流程，测试通过就进行系统测试。
- 执行测试并提交缺陷：使用禅道管理测试案例、测试结果和缺陷；测试一轮发现所有缺陷后，统计提交给开发修复，等开发修复后再进行下一轮的全面回归测试。我们一共进行了近10轮的回归测试。测试中我们会隔一段时间更换一些案例。
- 除了功能测试之外，我还负责了这个项目的xx测试(如弱网测试、兼容性测试等)，使用xxx工具进行的测试。
- 写测试报告：达到测试通过标准后，结束测试，编写测试报告，总结测试过程和产品质量。
- 迭代模式的答复
我们这个项目采用迭代式开发，每1个月迭代1个版本，每个迭代周期内开发完成1部分模块的开发和上个版本的缺陷修复，我们测试完成上个版本的测试。在每个迭代周期内，我们需要针对这个版本的新增模块设计测试用例，对上个版本无影响模块做自动化回归测试，有影响模块做手工回归测试。这个项目经过7轮迭代完成全部都开发和接口测试、功能测试工作。然后我们还进行了性能测试、弱网测试、兼容性测试和可靠性测试。
- 升级维护项目的测试过程答复
我们这个CRM项目是一个日常迭代的升级维护项目，一个月为一个迭代周期，每个周期内完成业务部门提出的新需求和修复缺陷。在每个迭代周期内，我们需要进行需求分析，分析修改可能影响到的模块，然后设计测试案例，并对上个版本无影响模块做自动化回归测试，有影响模块做手工回归测试。最新的一次升级主要是上线了客户分组功能。以前客户管理只能分行业和区域，现在新增一个分组功能，实现组内批量管理，和组内公用限额。除了客户管理模块需要重新测试之外，产品管理中的配额管理，以及订单管理中的新增订单、订单审核等都需要回归测试。我们除了要日常测试之外，上线当晚还要做上线验证。
- 回答的是测试分析，分析测试点基本采用的都是质量模型分析方法中的功能点分解分析，分析后还可以再加上功能交互分析和场景分析。
- 你需要在介绍这个模块如何测试时先介绍一个提纲，提纲内容是介绍该模块分解为哪几个主要功能的测试，和哪些其他的测试，其中主要功能中又分为哪些不同情况多测试，提纲的介绍有助于面试官的理解。等提纲介绍完毕后，再说明每个测试点中分别测试了哪些内容。介绍一个模块怎么测试，实际上是介绍该模块中的功能，和运行的不同情况，把它说成为我要测试xxx、我要测试xxx。
- 1. 你负责的电商系统首页模块是怎么测试的？
回答：首页模块有搜索框、轮播广告、分类导航栏、促销商品和分类商品推荐功能，我就是分别对这些功能进行测试。
搜索框即使关键字搜索，关键字可以来源于商品名称、商品设置中的商品关键字，商品属性中的可关键字搜索属性，对它的测试分为单关键字的搜索和多关键字组合的搜索，多关键字搜索需要考虑不同关键字来源的组合，所以使用了正交实验的测试方法。搜索中还需要测试到商品状态、无库存对搜索结果的影响。
轮播广告的测试就是和后台的联调，配置有广告，配置无广告，查看分别的显示情况，广告有链接无链接分别点击，以及轮博广告的左滑右滑，这些功能都需要分别测试。
分类导航栏也是和后台的联调测试，每个商品分类和功能模块在首页导航栏中配置或不配置，都需要检查首页显示并点击查看跳转。
促销商品的推荐以及各分类精品商品的推荐也是如此，配置有和配置无都要查看前台，并点击查看商品详情。还要测试商品状态对推荐的影响。
另外还要测试推荐商品的算法，以及排序
按照开发提供的算法，到数据库中查询用户搜索记录表、活动表、商品表的数据，再和前台界面推荐的商品比对
首页就是这些测试点。
- 2. 你负责的电商系统购物车模块是怎么测试的？
回答：购物车模块的测试，包括了各种情况的添加商品进购物车、购物车中商品的显示、购物车中修改和删除商品，以及选择商品做结算这4个部分的测试。
添加商品进购物车，需要考虑属性和数量是否选择、商品的不同状态、所选商品数量是否有效，以及是否已经达到购物车记录上限这些不同情况的测试。属性和数量是否选择这部分的测试，包括了需要测试不区分属性的商品可以不选属性和数量直接添加购物车，区分属性的商品必须选择属性和数量，以及先选数量后选属性后需要判断新属性商品数量是否有效。商品状态包括了需要测试添加购物车时所选商品是否上架、是否普通商品，是否配送用户默认收货地址。商品数量是否有效，包括了需要测试不能超库存，不能小于最少购买数量、大于最大购买数量，而且需要测试和购物车中已有该商品记录的数量累计是否有效。
购物车中商品的显示，需要测试各种添加来源的商品是否都能显示、商品状态的显示和排序是否正确、商品各信息显示是否正确。
商品的修改和删除，包括了修改属性、数量、优惠，以及删除单个商品、多选商品进行删除，还有一键清空下架商品等功能。
选择商品做结算，包括了选择几条购物车商品记录去结算、所选商品的状态和数量等功能的测试，后面就是结算模块的测试了。
- 3. 你负责的网盘项目文件管理模块是怎么测试的？
回答：文件管理模块的测试，包括了各类资料库和目录中所有文件显示、新增文件文件夹、分享文件文件夹、修改文件内容、删除文件文件夹、设置文件夹权限这6个部分的测试，重点一是不同权限下这些操作能否完成需要检查是否满足要求，以及多人同时操作一个文件文件夹时的结果是否满足设计要求。我们系统中对文件和文件夹的权限包括了在线浏览、在线修改、下载、上传、复制、分享和删除，文件属性包括提交、审核和发布，不同部门和级别的员工可以进行的提交、审核和发布权限不同。比如没有上传权限的文件夹中不允许新建文件文件夹，没有在线修改、下载和上传权限、但有在线浏览权限的文件，作为提交部门的员工，可以在线阅读，但不能修改和下载、以及下载后的提交新版本。还有多人下载同一版本并修改提交后需要测试自动生成多版本分支并给相关提交人、审核人提示版本合并通知。
- 4. 你负责的餐饮系统堂食模块是怎么测试的？
回答：堂食模块的基本流程是：1.对空闲的餐台进行开台；2.对已开台的餐台进行点单；3.对餐台中未下单菜品进行下单；4.对餐单进行管理；5.对餐台中已下单菜品进行上菜；6.对餐台的餐单做结账。这里需要对餐台的状态流转进行测试，状态有空闲、未下单、已下单、已上菜、已结账。
另外点菜中需要针对不同菜品类型分别进行点菜测试，菜品类型包括餐台预点菜、普通菜、时价菜、称重菜、多规格菜、多口味菜、套餐菜。我需要测试餐台预点菜是否开台后按照菜品设置中是否餐台固定数量预点或按就餐人数预点；时价菜是否能每份输入价格，称重菜是否不能点多份，而是每点一次经过称重后自动修改重量；多规格、多口味菜能否选择规格和口味；套餐菜能否按照菜品设置中套餐的必选组、单选组和多选组的要求选择菜品。
堂食模块中最重要的测试内容是账单计算，测试点包括了各种菜品类型的菜品原价、会员折扣价、菜品特价，以及餐单面单、退菜、优惠券抵扣等。
- 5. 你负责的WMS系统仓库管理模块是怎么测试的？
回答：仓库管理模块分为仓库仪表板、货品查询、空库查询和盘点4个子模块。仓库仪表板和空库查询以图形化方式显示整个库的库存监控，以实现由库找货，需要测试库、区和货架的不同类型和状态的图形与文字显示是否正确；货品查询提供了货品仓储类型、货品规格分类、货号、货品名称等条件的综合查询，查询到货品后实现由货找库，主要是配合数据库检查搜索结果是否正确，这里采用了正交实验的用例设计方法。还要测试货品的分拣、下架、移库、维修、报废功能是否正确，测试空货架的上架、设置功能是否正确。
盘点模块是选择库或区进行动态盘点，打印盘点清单，进行盘点核对并生成盘点报告。需要测试盘点清单中货品内容和数量是否正确，需要测试盘点的不同结果所生成的盘点报告是否正确。
- 将项目实践课程上整理的缺陷中挑选几个比较复杂的缺陷，详细的描述出来。描述的内容包括：哪个模块、哪个功能、操作过程、缺陷现象、和期望结果的差别，说明如何用Fiddler抓包、检查数据库、adb logcat定位缺陷。每个项目至少准备2个。
- 举例1：未配置属性加价的促销商品选择属性时闪退的bug
区分属性的促销商品，如果商品管理中未配置属性加价的价格，那么前段app在商品详情中进入属性和数量选择，选择属性并提交后数秒内闪退。当时一开始以为是偶发的缺陷，因为不区分属性以及区分属性但都配置有属性加价的促销商品做相同操作时都没有问题，后来反复验证，并比对数据库后才发现是区分属性的商品未配置属性加价才会导致该问题。我们用Fiddler抓包定位，发现提交请求完全没发出来，同时还检查了上游请求确认商品详情接口的返回数据无误，需求中也明确说明属性可以不配置加价。再结合查看adb logcat日志，我们断定这是一个前端错误，代码中没有针对属性加价节点为空时做额外处理。
- 举例2：对订单使用红包和积分抵扣可以抵扣到负数金额的bug。抓包定位该缺陷发现后台返回数据中订单结算金额就是显示负值，所以我们断定是后端错误，后台开发在针对红包和积分抵扣的代码中漏做了如果抵扣到负则抵扣为0的判断。
- 举例3：web端删除默认收货地址后app端订购添加收货地址死循环的bug。先查看adb logcat日志没有发现前端错误，抓包后查看发现后端返回数据中收货地址编号为空，于是前端按照设计中要求无收货地址则发起添加收货地址的请求，但查看数据库发现，后端看用户表中默认收货地址字段非空，于是只添加一条用户收货地址表记录，而不更新用户表的默认收货地址字段，这样就导致后台添加完收货地址表后重新返回用户收货地址时依然返回空。后来web端开发增加了默认收货地址禁止删除、添加收货地址接口也增加了当默认收货地址空和无效时都更新默认收货地址才解决了这个问题。
- 举例4：CRM项目中cookie的缺陷。CRM系统是B/S架构，有1个名叫ofname的cookie用于保存退出时所处模块，以便于下次登录后直接跳转到指定模块。测试中发现10多个模块中有1个线索管理模块进入时，该cookie写值的过期时间为session级，其他模块进入时写的过期时间都是1个月，结果就导致从线索管理模块退出后再次登录无法立即跳转到本模块。
- 举例5：网盘项目中共享到群组只读目录权限控制错误的bug。网盘项目中可以对资料库和目录进行共享，可以共享给用户，也可以共享给群组，共享时可以设置只读、读写、下载、上传、复制、删除、分享等权限。测试中发现到共享给群组的只读目录权限控制错误，只能控制该目录不能新增和删除文件，但不能控制修改文件。通过抓包查看到共享目录的接口传参和响应内容都正确，但内部逻辑中没有将该目录下的所有文件也设置为只读，导致了对该只读目录中的文件依然可以修改。
- 举例6：点餐系统中菜品多次免单后实际只免最后一次菜品的bug。多次免单时界面显示已免了多次累计的多道菜，但结账时餐单菜品数量和金额却不正确。反复验证后发现实际只能免最后一次免单时的菜品数量。通过抓包发现，免单接口的传参都正确，服务器端返回免单成功，但数据库中实际更新的免单菜品数量并不做累计，而是直接更新成新提交的数量，导致最后结账时菜品数量不正确。这是通过查询数据库发现到的问题。
测试过程：
- 分析设计文档，并和开发人员沟通，分析每个页面所有潜在sql注入点，包括了登录输入、搜索条件输入、URL传参等位置。
- 开启数据库日志，对页面上所有潜在sql注入点进行操作，分析日志中的sql语句，有针对性的编写注入语句，包括了单引号、双引号、反引号、无引号，以及带有若干小括号的各种爆破注入方式，以及针对可能存在应对的字符转码和宽字节注入，针对无回显的盲注等注入方式，都要进行多次尝试。
- 反复尝试中发现注入成功，则给开发开安全性缺陷，告之此处存在sql注入点。
本次电商项目中，我们进行了全面的sql注入的测试。一共针对从开发那里获取的商品分类列表显示页面、商品详情显示、登录、商品搜索、优惠券搜索、订单搜索等20多个页面的文本框、URL网址进行测试，采用各种爆破注入方式、宽字节注入、盲注之后，测试通过，整个系统不存在注入点。但是上次CRM项目中，我们就在订单管理模块中的订单查询中发现了sql注入点，因为整个项目中针对sql语句没有采用预处理方案，而是采用特殊字符和关键字转义的方式，结果采用字符转码char函数和宽字节注入ooorrr表示or的方式实现了注入。
测试过程：
- 从设计文档和开发人员获取关于cookie的设计内容，分析系统哪些模块写cookie、写哪些cookie、哪些功能会增删改cookie。
- (国内项目一般不提该内容，国外有些项目有该功能，这一条面试中可以不提)根据需求中要求首页提示使用cookie，对浏览器启用cookie和禁用cookie时打开首页的提示功能进行测试。
- 检查所有功能操作时的cookie是否符合设计，检查内容包括写cookie的name，value，path，expire。本电商项目的后台管理系统要写token、userid、lastvisit、osd等7个cookie，其中有个osd的cookie用于保存退出时所处模块，以便于下次登录后直接跳转到指定模块。测试中就发现20多个模块中有1个直播管理模块进入时，该cookie写值的过期时间为session级，结果就导致从直播管理退出后再次登录就无法跳转到本模块，其他模块却没有这个问题。
- 修改cookie的值，在相应功能页面刷新，检查功能是否发生指定变化。该修改包括了修改为其他正确的值和修改为错误的值
- 删除cookie，在相应功能页面刷新，检查功能是否发生指定变化
- 查看cookie值是否加密，是否不包含隐私
测试过程：
- 从需求和设计获取性能指标要求，包括广义并发量、具有性能要求的功能点、响应速度要求、服务器端硬件监控要求、软件session数要求等。
- 根据网站环境部署特点，以及用户使用习惯计算测试并发量。电商web系统的需求广义并发量上限是日uv量60万、吞吐量上限是日订单量8万，结合项目上线后采用DNS+LVS4层+Nginx7层的3级负载均衡，设计人员定下的单台服务器做1万并发量的测试，根据用户要求测试主业务流程的所有功能响应时间是否小于800ms，订单吞吐率能否满足大于100个/s。
- 使用Jmeter开发接口服务器的性能测试脚本，使用线程组、循环控制器、事务控制器、吞吐率常量定时器、同步定时器、http请求，使用json提取器、json断言、以及信息头管理器、csv配置文件、用户定义变量等配置元件来管理取样器、构造所需参数、提取响应值、以及断言对响应做检查。根据调试结果确定线程数250、燃起时间125秒、循环700次；设置了首页事务控制器和结算事务控制器，因为这2个页面都涉及了多个接口的同时调用；吞吐率常量定时器限定了结算接口吞吐率180；同步定时器配置在商品搜索上，25个搜索同时提交；json提取登录请求的token值和userid，商品搜索请求中的goods_id，提交订单请求中的order_id；json断言对登录、添加购物车、结算和查看订单进行了断言，断言业务状态码和其他指定键值；用户定义变量配置了主机、支付企业代码等环境参数。
- 同时，网管在服务器端内网搭建测试环境，采用分布式执行，40台执行机每台运行250并发，网管配合把服务器端的监控程序开启。我们编写存储过程插入铺底数据和测试数据，循环插入1万个新用户和20万铺底订单数据，每个用户涉及到用户表、用户收货地址表、用户支付方式表，每个订单涉及到订单表、订单明细表、订单操作记录表、发货单表、发货单明细表。还准备了测试结束后数据清除脚本来删除测试结束后生成的垃圾数据。
- 采用分布式执行方式执行了2轮测试，每轮大约4个小时。合并测试数据后，用命令行导出html测试报告。
- 测试结束后分析测试结果，发现电商web系统中的商品查询速度不达标，实际测试90%接近1200ms。查看后台程序日志发现主要集中在商品价格查询功能消耗时间长。后来通过优化多条商品查询相关的sql语句，将复杂查询分解为多条简单查询、使用索引、调整where条件中的语法和顺序后，才回归测试通过的。
注意：python编程基本不会的同学不要在面试中尝试说自动化。python编程基础学会、框架代码无法理解的同学，可以说冒烟自动化测试脚本的开发。能看懂框架设计的逻辑、理解驱动层工作原理的同学可以说参与了自动化测试框架的开发。
问：你们冒烟测试自动化脚本如何编写的？有什么作用？
答：我们使用python语言、selenium(用于web项目)或appium(用于app项目)开发了本项目的冒烟测试脚本，主要内容就是创建webdriver对象，然后运行了产品的主流程，这个电商项目我们脚本编写了打开首页、登录、搜索商品、选择查看商品、选择属性和数量后加入购物车、结算、查看我的订单、查看最新订单详情、判断订单金额是否正确。我们编写的冒烟测试脚本，用于产品每次回归测试前先执行，确认主流程能否正常运行，主流程正常运行才进行回归测试。
问：有哪些元素定位的方法？遇到过哪些定位失败的情况，怎么解决？
答：selenium有8大元素定位方法，象id, name, class_name, tag_name, link_text, partial_link_text, css_selector和xpath，这些都用过。appium中还有一些appium专用的定位方法，知道有，但是项目中还没有需要用的情况。元素定位失败的情况有很多，主要有这几类：1.属性值动态变化导致之前定位的内容下次定位就失败，解决方法有如果能用别的属性就用其他属性来定位，如果必须用这个则看能否使用css_selector或xpath的模糊定位，样式表中*=,^=和$=，xpath中contains函数、starts-with函数、ends-with函数都能实现模糊定位。2.等待时间不够导致，解决办法就是多加等待时间；3.定位到多个导致后续执行其他方法报错，解决办法有使用样式表或xpath来进一步精确定位，还可以用find_elements定位到多个后再用序号来确定唯一的一个；4.元素不在当前屏幕导致定位不到，则需要使用ActionChains类或js代码scrollTo来移动页面使元素移动到当前屏幕；5.没有先切换framework或window或context就定位其他页面的元素导致失败，解决办法就是先切换。
问：显式等待在项目中用过吗？举个例子。
答：用过，web或app中促销模块有个抢红包按钮有随机时间倒计时，倒计时完成后才能点击，就使用了显式等待，使用webdriverwait对象的until方法，传参是expected_conditions模块中的element_to_be_clickable函数，表示一直等到该按钮元素可被点击。
问：你们框架怎么设计的？你会搭建吗？
答：我们这个项目的框架使基于unittest开发的一个框架，采用三层架构分离的设计思想，整个框架分为底层的po层(页面对象层)、中间的用例层和上层的驱动层，po层实现所有页面元素操作的封装，用例层编写的是基于unittest和ddt的所有测试用例，一个方法是一个用例，ddt实现参数化，驱动层读取excel的用例列表，根据用例中标记是否需要执行的字段来判断加入到测试套件中，每个用例都有关键字对应测试方法，每个用例都有本用例专用的参数行或参数表单，框架能实现将需要执行的用例的参数加载到ddt.data中让测试方法参数化执行。这个框架我会搭，但是当时写不是我写的，是我们组长写的，我在项目中主要负责首页模块、购物车模块的所有po元素封装和用例的编写，我把我写的脚本交给我们组长合并到框架中，这个项目我一共写了200多个测试方法。
- 整体测试过程：
- 从开发人员获取接口文档，文档描述了接口的请求URL、方法、传参、头部等信息
- 配合Fiddler抓包工具熟悉接口，分析接口业务
- 设计接口测试的用例，包括单接口和多接口组合的测试。
- 搭建接口测试环境，准备测试数据，准备测试工具
- postman中单接口测试用手工测试，将每个接口分别调用，配置请求方法、URL、传参、头部等，运行查看结果是否符合用例预期响应。多接口测试采用自动化测试，针对每个用例创建集合，在集合中添加用例的步骤中描述的接口请求，适用变量来配置每个请求的URL、请求方法、传递参数和头部信息，编写数据提取和断言的代码。最后导出集合和变量的脚本文件，使用newman批量运行。
- 发现缺陷提交缺陷报告，等开发修复后回归测试。直到测试通过。
- 多接口测试自动化怎么做的？
答：使用postman做的接口的自动化测试。同样是先进行多接口的测试用例的设计，设计完成后再用postman来实现。在postman中创建集合，集合中创建文件夹，每个文件夹对应一个测试用例，配置好全局变量、环境变量、集合变量和参数文件变量，在文件夹中添加本用例所需要的所有请求，使用变量来配置请求的方法、URL、信息头和参数，设置好传参方式，根据api文档，提取或者json、或者xml、或者字符串、或者头部中所需要的值，保存为集合变量，或者对提取到的值做检查，基本做的都是等值断言，有时也需要进行或大于小于、或包含、或存在即非空的断言。
脚本调试通过后，导出集合脚本和环境变量脚本，使用node.js中的newman来批量运行。
- postman中都有哪些不同的提取情况？
1.如果响应是json数据，则需要从json中获取节点值
jsondata = pm.response.json();
pm.collectionVariables.set("token", jsondata.data.token);
2.如果响应是xml数据，则需要将xml数据转json后再处理
jsondata = xml2Json(responseBody);
pm.collectionVariables.set("token", jsondata[“soap:Envelope”][“soap:Body”][“ns1:loginResponse”][“token”]);
3.如果响应是纯文字，需要从纯文字中提取到特定值，需要使用正则表达式
status=responseBody.match('<font size="12">(.+?)</font>');
pm.collectionVariables.set("status", status[1]);
4.如果响应内容只有1个字符串，则可以将整个响应做保存
pm.collectionVariables.set("status", pm.response.text);
5.如果要保存响应的头部信息
token=postman.getResponseHeader("Anthorization");
pm.collectionVariables.set("token", token);
除了可以写入到collectionVariables集合变量外，还可以写入globals全局变量、environment环境变量中。
- 你在项目的接口测试中使用过postman的哪些断言？
pm.test("断言名称", function(){
pm.expect(提取的实际结果).to.eql(期望值);
});
除了判断是否eql之外，还可以判断gt、ge、lt、le、contains、match等。还可以对响应状态码、响应时间做断言。
- 具体接口如商品收藏接口、添加购物车接口、结算接口等如何测试？
- 需要分析2个内容：1.这个接口需要传递哪些参数，返回什么内容的结果。2.这个接口需要测试哪些情况。
- 问题1的分析方法：看这个接口执行前需要的条件和执行过程中需要输入的内容，结合起来基本就是该接口需要传递的参数。比如收藏商品的接口，需要先登录，说明这些接口需要传递用户数据以表示哪个用户收藏商品，收藏时可以收藏商品，也可以收藏商品+属性。这样就分析出来收藏接口需要传递userid用户编号、goods_id商品编号和attr_id属性编号3个参数，前2个必填，属性编号可选。
- 问题2的分析方法：和分析该接口对应的界面功能需要测试哪些情况，分析方式和结论都完全相同。所以照着分析界面功能需要测试哪些情况去描述。比如收藏商品的接口，首先测试必填项和选填项的填写和不填写，然后测试用户登录前后的不同情况，测试商品类型是否上架、是否普通商品、是否未删除，以及属性是否该商品的单选属性等不同情况。
- ecmobile有43个接口：
- 系统设置获取接口
- 首页通知接口
- 首页广告接口
- 首页促销接口
- 首页分类精品推荐接口
- 首页搜索接口
- 文章获取接口
- 文章详情接口
- 商品高级搜索接口
- 商品分类列表显示接口
- 品牌查询接口
- 价格区间显示接口
- 商品详情接口
- 商品基本参数接口
- 商品描述接口
- 商品评论显示接口
- 商品添加收藏接口
- 商品收藏显示接口
- 商品收藏删除接口
- 订购红包校验接口
- 订购积分校验接口
- 商品添加购物车接口
- 购物车显示接口
- 购物车修改商品接口
- 购物车删除商品接口
- 商品结算核对接口
- 商品结算接口
- 地区查询接口
- 登录接口
- 退出接口
- 用户信息显示接口
- 注册字段获取接口
- 注册接口
- 我的订单显示接口
- 确认收货接口
- 取消订单接口
- 订单支付接口
- 查看订单物流接口
- 我的收货地址获取接口
- 我的收货地址添加接口
- 我的收货地址修改接口
- 我的收货地址删除接口
- 修改默认收货地址接口
- 接口测试中发现的缺陷
例1：添加收货地址接口中，如果是该用户的第一次添加，需要同时写用户表的默认收货地址，但没有写，导致用户没有默认收货地址。
其他：商品结算接口中，不返回进口商品的关税金额；商品详情接口中，商品服务属性的加价为0时，应该返回0，但实际返回空值。
- 测试需求：性能指标从设计人员获取，要求是在测试机型红米K40手机(骁龙870，8G内存)进行测试，运行环境要求cpu已经有30%、内存有4G已经被使用，电量100%充满。测试指标要求：进程平均cpu占用率<10%，内存平均占用<400M，响应速度<1500ms。
- 测试计划：在手机中持续运行4小时，使用solopi监控cpu,内存，响应速度，运行appium编写的操作主流程：用户登录、搜索商品、查看详情、添加购物车、结算、查看订单。
- 准备测试数据：准备用户数据，账户余额1亿，准备商品数据，1个商品，单价100，库存100万。
- 执行过程：在手机中打开solopi，勾选上监控数据，启动测试，运行appium脚本4个小时。执行完成后停止solopi。导出solopi的监控数据，分析cpu,内存和响应速度，以及手机adb logcat日志，发现响应速度不达标，其他都满足要求。配合开发一起分析原因，发现大部分响应超时都是商品搜索功能。Fiddler抓包查看数据后发现主要是后端响应速度慢导致，不是前端问题。
- 制定测试计划：分2个阶段进行，阶段1测试4小时monkey随机操作是否有异常，如果有异常则修复回归测试直到阶段1测试通过。然后进行阶段2测试，阶段2测试48小时monkey随机操作是否有异常，如果有异常则修复后重新进行阶段1测试再进行阶段2测试，一直到阶段2测试通过。
- 准备测试数据：准备用户数据，账户余额1亿，准备商品数据，100个商品，有上架、下架，有普通、配件，有删除、未删除，有促销，有数量优惠，有会员等级折扣价格，也有会员等级指定价格，有商品用户已收藏，有点商品已在购物车。
- 准备测试环境：准备了骁龙系列、麒麟系列、天玑系列不同cpu的手机，内存从4G到12G的手机，有使用流量，有使用wifi。多部手机都先打开app，让用户已经登录，并adb连接上电脑。
- 执行过程：电脑端运行adb shell monkey -p com.insthub.ecmobile -s 5 --ignore-crashes --pct-touch 75 --pct-motion 20 --pct-syskeys 5 --throttle 350 -v -v -v 40000 1> /sdcard/Download/ecrun.log 2> /sdcard/Download/ecerr.log。--throttle 350的间隔时间在预先测试中发现这样间隔时间运行大体会执行1万次需要1小时，所以运行4小时设置为执行4万次，运行48小时就执行48万次。且monkey命令执行时导出日志。执行完毕后导出adb logcat日志。
- 分析结果：查看monkey日志和adb logcat 日志，检查是否存在严重错误。检查结果发现，运行4小时没有错误，运行48小时过程中出现app闪退现象，定位后发现是商品图片多、图片尺寸大时反复切换图片导致。后来将日志提交给开发，开发进一步缩小图片数量和尺寸后重新执行阶段1和阶段2的回归测试，测试通过。
安装测试包括了安装，升级和卸载。分为安装前、安装中和安装后。还要考虑安装的兼容性。
- 安装前：对安装包进行检查，比对安装包中的文件和配置是否和开发提供的手册内容一致，通过aapt命令来比对。对安装包文件进行杀毒。
aapt list xxx.apk
aapt dump badging xxx.apk
aapt dump permissions xxx.apk
- 安装中：
安装：分为离线安装和在线安装。检查安装过程的功能、权限选择等是否正确。
升级：顺序升级、跳序升级、降级
卸载：检查卸载过程的功能。
- 安装后：安装和升级都要检查软件启动和运行功能。涉及启动时的性能要求、权限选择，运行功能是否正常，以及安装后的环境兼容性。卸载则要检查卸载内容是否干净。/data/app和/data/data这2个目录中的该包内容是否全部清除。
- 制定测试计划：分2个阶段进行，阶段1测试50多k/s网速时的产品运行可靠性；阶段2测试8k/s网速时的产品运行可靠性，每阶段运行时间4小时。
- 工具选择：使用fiddler模拟弱网，使用appium编写自动运行脚本。
- 测试功能：在弱网下测试订购主流程是否存在问题，步骤包括：
- 用户登录
- 搜索商品
- 查看商品详情
- 添加购物车
- 结算
- 查看订单
需要对每个步骤能否成功执行做判断，只有本步骤执行成功才会执行下个步骤，要求对结算过程中当订购成功时断言支付是否成功，如果支付失败则断言报错。
- 准备测试数据：准备用户数据，账户余额1亿，准备商品数据，1个商品，单价100，库存100万。
- 执行过程：使用fiddler，开启模拟调制解调器网速的开关，手机使用代理连接到fiddler，运行appium脚本，循环执行4小时后停止。查看appium脚本运行的结果，查看是否有报错，同时还检查adb logcat -d *:F致命错误级的日志。发现第一阶段测试没有问题。第二阶段测试时调整fiddler中上传和下载的网络延迟数据，上传延迟从300调整到3000，下载延迟从150调整到1500。再次执行appium脚本4小时。检查appium脚本执行结果，同样发现没有错误。所以测试通过。
1847
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
