软件测试扫盲【教科书级】

按测试技术划分

黑盒测试、白盒测试、灰盒测试


被测试对象是否运行

动态测试、静态测试 (文档检查、代码走查)


按不同的测试手段划分

手工测试(点工) 、自动化测试(工具+代码)

按测试包含的内容划分



功能测试、界面测试、安全测试、兼容性测试、易用性测试

功能测试:测试业务逻辑(手工、自动化)--核心重要

界面测试:UI(user interface)--外观美好、设计合理、友好、---主观性强=需求文档 (原型图 UI切图)--优先级会低

安全测试:高级类型-工具 (扫描--appsan) 代码(脚本-sql注入) --漏洞,薄弱

性能测试: 高级类型-双十一(访问人数多)--并发 (10000) ---资源 内存 --正常处理

易用性测试: --人性化  ,舒适,用户体验==提bug ===站在用户角度考虑,考虑成熟产品

兼容性测试:软件+硬件(windows,Linux,MacOS,Android,Ios); 软件+软件--调用; 软件不同版本之前App(老功能,数据)


按测试阶段划分

单元测试、集成测试、系统测试、验收测试、a测试、b测试


其他测试

回归测试、冒烟测试、探索性测试/自由测试(测试思维)


回归测试:  regression test : 测试-bug ,开发修复bug(修改代码)== 验证bug==其他没被修改的代码模块测试,影响: 上线之前-很多轮 (2-4轮) 的回归冒烟测试(重复) ==自动化测试

冒烟测试:来源--硬件测试 : 电路板-冒烟-短路被烧了=打回开发重做--软件测试:软件提测-核心业务功能

主流程 ,提高测试效率

探索性测试: 发散测试 -能力要求非常的高 ,没有依据,方法  ,只能靠 经验、积累、直觉


需求评审:


什么是需求评审:

项目相关人员就产品需要进行确认和评估的相关活动


为什么要需求评审:

项目组成员理解需求,以便后期高效的进行、开发、设计工作

测试人员参与需求评审的职责

 1.确保主机的理解与产品设计理念一直

明确实现的需求范围

提出主机对产品需求不合理或遗漏

产品需求评审案例 : 只看功能是否正常 ,看控件位置 ,对流程的控制


有需求提需求,让产品更加完美


测试计划,就是一个word文档 

测试用例测试思路

用例设计思路:帮助测试人员构建清晰的测试思维,指导测试思路

软件测试扫盲【教科书级】_第1张图片


个人头像功能测试需求分析

软件测试扫盲【教科书级】_第2张图片



分析显性,和隐性


软件测试扫盲【教科书级】_第3张图片





显性:正常文章描述的东西

隐性: 那边边边角角没有显示出来的细节

 


测试用例的编写 

软件测试扫盲【教科书级】_第4张图片



使用Xmind列出要测试的点,根据测试的需求来定,简单一句,就是找测试点


最后使用Excel 进行功能测试


就是这么玩的

软件测试扫盲【教科书级】_第5张图片


需求

软件测试扫盲【教科书级】_第6张图片



测试用例

软件测试扫盲【教科书级】_第7张图片


弱网测试

软件测试扫盲【教科书级】_第8张图片



使用Fiddler 模拟 3G ,4G 的访问速度,也就是 具体时间

软件测试扫盲【教科书级】_第9张图片


软件测试扫盲【教科书级】_第10张图片


软件测试扫盲【教科书级】_第11张图片


交叉测试

软件测试扫盲【教科书级】_第12张图片




软件测试扫盲【教科书级】_第13张图片


缺陷记录:

软件测试扫盲【教科书级】_第14张图片



软件测试扫盲【教科书级】_第15张图片



有人喜欢创造世界,他们做了开发者;有的人喜欢开发者,他们做了测试员。什么是软件测试?软件测试就是一场本该在用户面前发生的灾难提前在自己面前发生了,这会让他们生出一种救世主的感觉,拯救了用户,也就拯救者这个软件,避免了他们被卸载的命运。

微信搜一搜【程序员一凡】关注这个文绉绉的程序员,关注后回复【面试】有我准备的一线大厂面试资料和简历模板,希望大家都能找到心仪的工作,学习是一条时而郁郁寡欢,时而开怀大笑的路,加油。如果你通过努力成功进入到了心仪的公司,一定不要懈怠放松,职场成长和新技术学习一样,不进则退。如果有幸我们江湖再见!

你可能感兴趣的:(软件测试扫盲【教科书级】)