基础篇
1.软件测试生命周期(软件测试的流程是什么?)
需求分析→测试计划→ 测试设计→ 测试开发→ 测试执行→ 测试报告
需求分析:分析需求、细化需求、验证需求的的正确性和合理性
测试计划:规划测试人员数量、规划时间、测试范围、测试目的
测试设计、测试开发:分析需求,从细化的需求中提炼功能点设计测试用例,执行测试用例记录多少条BUG
测试报告:测试的范围、有多少测试用例、执行了多少、余留了多少测试用例、发现了多少BUG,修改了多少BUG(后续需要验证)、一流的BUG以及解决方案
2.如何描述一个bug
测试版本号(代码版本号)、测试环境(平台)、测试步骤和测试数据、实际结果、预期结果、附件(错误截图、错误日志,web的api等)
3.BUG的级别
(1)Blocker(崩溃):
阻碍开发或测试工作的问题;造成系统崩溃、死机、死循环,导致数据库数据丢失,与数据库连接错误,主要功能丧失,基本模块缺失等问题。如:代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等(该问题在测试中较少出现,一旦出现应立即中止当前版本测试)。
(2)Critical(严重):
系统主要功能部分丧失、数据库保存调用错误、用户数据丢失,一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符,模块无法启动或调用,程序重启、自动退出,关联程序间调用冲突,安全问题、稳定性等。如:软件中数据保存后数据库中显示错误,用户所要求的功能缺失,程序接口错误,数值计算统计错误等(该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试)。
(3)Major(一般):
功能没有完全实现但是不影响使用,功能菜单存在缺陷但不会影响系统稳定性。如:操作时间长、查询时间长、格式错误、边界条件错误,删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多)
(4)Minor(次要):
界面、性能缺陷,建议类问题,不影响操作功能的执行,可以优化性能的方案等。如:错别字、界面格式不规范,页面显示重叠、不该显示的要隐藏,描述不清楚,提示语丢失,文字排列不整齐,光标位置不正确,用户体验感受不好,可以优化性能的方案等(此类问题在测试初期较多,优先程度较低;在测试后期出现较少,应及时处理)
4.bug的生命周期
New:新发现的Bug,未经评审决定是否指派给开发人员进行修改。
Open:确认是Bug,并且认为需要进行修改,指派给相应的开发人员。
Fixed:开发人员进行修改后标识成修改状态,有待测试人员的回归测试验证。
Rejected:如果认为不是Bug,则拒绝修改。
Delay:如果认为暂时不需要修改或暂时不能修改,则延后修改。
Closed:修改状态的Bug经测试人员的回归测斌验证通过,则关闭Bug。
Reopen:如果经验证Bug仍然存在,则需要重新打开Bug,开发人员重新修改。
5.如果如何一个BUG好开发人员产生冲突怎么办?
- 检查自身,看BUG描述有没有问题
- 站在用户角度考虑,说服开发人员
- BUG 的顶级要有理有据
- 提高自身业务水平和技能
- 和开发,产品经理一起讨论沟通
4.用例篇
1.测试用例的设计方法
- 等价类
- 边界值
- 因果图
- 正交排列
- 场景设计法
- 错误猜测法
(1)等价类
依据需求将输入划分为若干个等价类,从等价类中选出一个测试用例,如果这个测试用例测试通过,则认为所代表的等价类测试通过,这样就可以用较少的测试用例达到尽量多的功能覆盖,解决了不能穷举测试的问题
有效等价类:
对于程序的规格说明书是合理的、有意义的输入数据构成的集合,利用有效等价类验证程序是否实现了规格说明中所规定的功能和性能
无效等价类:
根据需求说明书,不满足需求的集合。
(2)边界值
边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法
6-10个字符就要测试5,6,10,11等情况
(3)因果图
因果图是一种简化了的逻辑图,能直观地表明程序输入条件(原因)和输出动作(结果)之间的相互关系。因果图法是借助图形来设计测试用例的一种系统方法,特别适用于被测试程序具有多种输入条件、程序的输出又依赖于输入条件的各种情况。
常用的关系
恒等,与,或,非
设计步骤
- 分析所有可能的输入和可能的输出。
- 找出输入与输出之间的对应关系。
- 画出因果图。
- 把因果图转换成判定表。
- 把判定表对应到每一个测试用例。
(4)正交法
//待定
(5)场景设计法
把一个个孤立的功能点按照一定策略组合在一起,形成了一个业务场景
(6)错误猜测法
根据测试人员的经验,直觉,知识,来判断系统的功能模块,那一块有问题,来着重设计测试用例
只能作为一种补充的设计测试用例的方法