软件测试面试题_每天一道软件测试面试题系列 (八)_描述一次测试用例设计的完整的过程 怎样估计测试工作量？进行测试时产生了哪些文档或记录？

1、描述一次测试用例设计的完整的过程

回答技巧:
    这个问题是考验你在工作前半段是否真的针对你业务进行过测试用例设计,所以回答的时候一定要仔细,并且要从开头讲,也就是从立项会开始讲
答案:
    首先作为测试人员,当我们开完立项会后,需要拿到接下来测试项目的需求文档,(以及原型图)进行熟悉的工作,在熟悉完成之后按照需求文档功能点的顺序编写测试用例(业务比较复杂的建议用x-mind把业务流程画下来,方便自己日后理解),如果是电商网站或者其它旅游网站,可以按照场景法的顺序编写测试用例
    如果你的项目是电商,在登录页面用户名,密码框,可以用到边界值测法,等价类划分法,错误推断法,如果涉及到用户支付了,可以使用场景法.说一套具体支付流程,还有就是涉及到账号,密码的状况.一旦登录成功之后,要考虑登录之后的网址复制到其它浏览器或者PC上,是否还是显示登录之后的页面,这块开发人员是否有处理.
    在测试登录页面还要考虑到环境情况,如果是登录瞬间没有网络之后该怎么显示页面,点击登录之后,页面跳转时间也要进行测试，所以总结一点,测试项目要考虑到功能,性能,安全等因素

2、怎么估计测试工作量？

回答技巧:
    面试官问这个问题,可以说在你写测试计划的时候,工作量就会考虑到,工作量直接影响到你的测试周期
答案:
    需求分析: 分析该项目测试所用到的技术(功能,安全,接口)
    效率假设：即测试队伍的工作效率。对于功能测试，这主要依赖于应用的复杂度，窗口的个数，每个窗口中的动作数目。对容量测试，主要依赖于建立测试所需数据的工作量大小。是否需要进行数据库表的数据比对
    测试假设：为了验证一个测试需求所需测试动作数目。
    应用的维数：应用的复杂度指标。例如要加入一个记录，测试需求的维数就是这个记录中域的数目。
    开发人员认知:比如你负责的开发人员的水平问题,开发人员技术好,业务能力强的BUG就少,技术一般的业务差的要适当延长,总之项目开发人员的水平也会影响到你的工作量
     是否需要其它人员配合测试:例如手机注册,有可能会用到公司其它员工的手机号
     所处测试周期的阶段：有些阶段主要工作都在设计，有些阶段主要是测试执行。其实这个工作主要由测试组长来考虑,如果公司公司就你一个测试,那就要自己也懂才行

3、进行测试时产生了哪些文档或记录？

回答技巧:
    也是判断面试人员是否真的工作过,要对每个文档有深入的理解,不能光说有哪些就行了,而是要把这些文档存在的意义讲出来才专业
答案：
    测试的整个过程有系统测试计划(主要表明接下来测试的具体分工,时长,环境,所用到的软硬件,预估测试环境,预发布环境,正式环境的时间安排,测试所用到的技术)、系统测试用例、系统测试报告(分日报,阶段报告,这2个我会着重讲)、缺陷报告、产品发布说明,产品使用手册
     在执行测试的过程中 只有缺陷报告，这个还是用在缺陷管理工具中进行的，最后在工具中导出缺陷报告.

4、你对软件周期了解吗,你是怎样看待软件周期的？常见的软件生命周期模型有哪些？

回答技巧:
     这个问题一般从在于你之前对工作中的软件开发流程有没有深刻的认知,软件从无到有的一系列过程是否说的详细,所以我的建议是要从工作的角度去谈,这样更让人能够信服.尽量可以结合自己的项目去讲(从无到有)
     软件生命周期是指一个计算机软件从功能确定、设计，到开发成功投入使用，并在使用中不断地修改、增补和完善，直到停止该软件的使用的全过程（从酝酿到废弃的过程）
     生命周期从收到应用软件开始算起，到该软件不再使用为止。它有如下各方面的内容：初始构思、需求分析、功能设计、内部设计、文档计划、测试计划、文档准备、集成、测 试、维护、升级、再测试、逐步淘汰 (phase-out)、等等
     瀑布模型，迭代式模型，快速原型模型，螺旋模型

5、项目版本执行过程中，测试人员如何把控测试进度？

技巧:
    这个涉及到测试工作经验的问题.首先在测试之前会写测试计划,那预估的时间段是由测试,开发,产品共同商量得来的,所以测试人员要根据以往测试项目整体时间来判断,在新版本的时候,(测试环境)冒烟测试时间,执行测试用例测试时间,回归测试时间,突发情况预留时间,(正式环境)冒烟测试时间,回归测试时间.那这些时间必须要提前预估出来,并且在每个阶段遇到问题要及时跟开发,产品,项目经理,测试组长积极沟通.
    在项目的系统测试过程中，测试负责人要及时了解测试进度，跟踪BUG提交、修复及验证情况以及系统的拷机情况。
    在开发初期阶段，测试组在构建功能模块时，很多模块、功能点的开发完成进度和原计划会存在一定的偏差，就需要测试负责人动态的刷新计划表，根据实际的开发进度调整测试计划。
    在开发阶段，存在版本编译不出来导致无法测试，开发人员修复代码太随意导致版本稳定性反复，需求变更过大导致后端测试开发变更严重等现象，会导致测试工作无法正常进行。就需要测试负责人及时反馈出来，根据项目本身的特点进行对应的处理。
    当测试进度出现延期时，要及时确认问题原因，如果是问题协查导致，则需及时与研发人员进行沟通协商，看问题是否必须在测试环境进行排查，若为必现问题可与研发协商要求其在自己环境进行排查，若必须占用测试环境，则需及时调整测试计划，若因此可能影响版本的发布，则应及时与SE确认。
    若发现有较多BUG未解决，则应主动联系SE(项目负责人)及研发人员召开BUG会确定问题的解决时间。若发现有较多BUG未验证，则应提醒项目组的测试人员及时进行验证，对于一些拷机或非必现的BUG，建议测试人员在此BUG上现做拷机标记，连续拷机一周未再复现的做关闭处理，若再次复现则继续进行排查。
    疑难问题的跟控：比较难复现的问题，怎么去尝试复现。比较难定位的问题，怎么驱动、反馈给SE，协调开发人员定位问题。比较难处理的问题，怎么跟控反馈进度等。
    每天下班前需确认拷机内容，每天上班第一件事需确认拷机结果，只有这样才能保证拷机的效果，实现拷机的真正意义。