1 v模型
用户需求,需求分析,概要设计,详细设计,软件编码,单元测试,集成测试,系统测试,验收测试、
W模型
2测试流程
编写测试计划 — 评审测试计划 – 编写测试用例 – 评审测试用例 – 执行测试阶段(冒烟测试,系统测
试) – 分析和总结测试结果 – 完成测试
产品提出需求后,开立项会进行讨论需求制定需求文档,开发根据需求文档进行编
码,测试人员需要根据需求文档进行编写测试计划,以及对应的测试用例编写,用
例编写结束后,进行用例评审,开发提交代码后执行冒烟测试,冒烟测试通过后执
行过程中出现bug进行提交bug,并对bug进行追踪。bug关闭后我们做测试总
结,提交对应的测试报告
3测试原则
尽早原则,边界和极端原则,28原则,确认原则,回归原则
4bug生命周期
新建,确认,解决,重新验证,关闭,重新打开
一个Bug由测试人员发现并提交,我们将状态标注为新建;开发人员接收了该Bug,将Bug的状态修改为已分配(Assigned),表示已经认可;开发人员解决了该Bug后,就将Bug的状态修改为解决,并发给测试人员回归测试;测试人员对Bug进行同归测试,如果确实已经解决,就将Bug的状态修改为关闭,否则的话则发给开发人员重新修改。还要说明的是,Bug是可以“死而复生”的,以前版本已经关闭的Bug,如果新版本中重新出现,我们就需要将其状态修改为重新打开。
5cookie和session的区别
cookie是存放在浏览器上而session是存放在服务器上的。
cookie不是很安全,涉及到用户隐私方面尽量存放在session中。
当访问量增多时,session会更加占用服务器资源。
6软件测试分为呢几个阶段
单元测试、集成测试、系统测试、验收测试
7系统测试的范围
功能测试、用户体验测试、性能测试、UI测试、兼容性测试、安装测试、文档测试、稳定性测试等
8白盒,黑盒,灰盒测试的区别
白盒测试:对程序的内部结构与算法进行的测试
黑盒测试:不考虑程序的内部结果,只检查程序是否实现了需求的功能
灰盒测试:关注系统接口所实现的功能,是否和需求一致。
9回归测试怎么做
首先,把bug单对应的用例执行一遍,还要检查有数据交互的模块会不会受影响,有没有引入新的问题;项目上线前,还要把当前版本的重要功能以及冒烟测试的用例都回归一遍,确保重要功能上线后不出问题。
10.产品在上线后用户发现bug,这时测试人员应做哪些工作?
- 测试人员复现问题后,提交问题单进行跟踪;
- 评估该问题的严重程度,以及修复问题时的影响范围,回归测试需要测试哪些功能;
- 问题修复后,先在测试环境上回归,通过后再在生产环境上打补丁,然后再进行回归测试;
- 总结经验,分析问题发生的原因,避免下次出现同样问题。
11如何减少非单位单的提交
- 熟悉项目需求,充分了解各个各个功能模块的功能、参数、约束条件,弄清存在数据交互的模块之间的数据来源、数据流向;
- 跟产品确认该问题是否属于非问题单。
12你们发现bug会怎么处理
发现bug后,我们会先自己定位一下,比如,抓个包,看看是前端的问题,还是后端的问题,检查下数据库的数据是不是正确的,尽量把问题发生的原因或者产生的日志找出来,方便开发定位问题,然后就提单给开发,然后开发做出相应的处理,开发修复完后就进行回归测试,回归测试通过后就关闭这个bug,没有通过就继续给回开发修复。如果遇到开发认为这个不是bug的话,那么我们就要和开发沟通,然后我们要坚持自己的立场,通过讨论后一致认为是bug就给开发修复,不是就关闭这个bug。如果开发和我们意见一直不一致,那么就要将问题升级,召集开发经理和测试经理一起讨论,再做决定。
13怎样保证覆盖用户需求?
项目开始前,我们会先熟悉需求,画好流程图,保证整个流程都覆盖全面,小组之间每个人都要根据各自的流程图,各个功能点有哪些限制条件,来讲解一下自己对测试点的理解,防止之后编写测试用例时出现遗漏;用例编写完之后,再进行用例的评审,看看测试点有没有用遗漏,对需求理解有没有错误,测试场景是否覆盖完全。
14如何尽快找到软件中的bug?
- 尽快熟悉公司的产品业务,只有熟悉了产品的业务流程、你才能迅速找出软件中存在的一些重要的缺陷;
- 把自己当成用户,把自己当成是用户去使用该系统
- 善于怀疑,不要过于相信开发人员的能力;
15在需求文档不太详细的情况下,如何开展测试?
- 首先,把需求文档中有异议的部分标识出来,再找产品和开发一起讨论,把需求明确下来;
- 提取测试点,然后再叫上产品和开发一起对测试点进行讨论,看有没有遗漏,是不是合理的,
然后再编写测试用例,再评审,评审通过后,再进行后续的测试。