51Testing软件测试论坛
标题:
《移动APP测试实战》第一天打卡阅读
[打印本页]
作者:
测试猿华夏结
时间:
2019-5-5 21:59
标题:
《移动APP测试实战》第一天打卡阅读
本帖最后由 测试猿华夏结 于 2019-5-5 22:11 编辑
今天阅读1——68页(两天的阅读量,因为昨天就开始计划阅读了)
阅读内容:
序言
测试新人提升建议
1)针对开发语言或脚本语言的深度掌握和熟练使用;
2)锻炼和提升自己的测试分析设计和评估能力,并不断完善自己的测试体系和思想
3)对产品的相关开发技术和设计架构,甚至深入到代码实现角度的深层次掌握和理解;
4)坚实的自动化测试理解以及实践积累;
5)对操作系统、网络等基础知识更深入的掌握和实践;
6)保持对测试行业新技术的不断探索和对齐
试管理者完善建议
1)建立自己清晰完善的测试解决方案体系和思想,配合工作管理,不断实施打磨,梳理完善自我的测试知识体系,培养出自己的一套测试解决方案体系和思想。
2)对质量和效率提升如何更加清晰的平衡和把关能力;
3)完善和建设清晰的测试度量体系;
4)关注和推动自动化测试,同时关注投资回报率(ROI)
第1章 产品功能测试概述
1.1 互联网产品常见的研发流程
互联网产品流程中分工角色
产品经理
负责产品方向和具体需求的规划,需求文档的编写。
项目经理
简称PM,负责项目的立项和时间安排,并跟进项目研发的进展、变更和风险,以及各种跨团队的协调工作。
设计师
负责产品的交互设计、视觉设计等方面。主要的产出是产品的交互原型和设计稿。
开发人员
负责产品的技术架构设计和代码编写,产出是可运行的实际产品。
测试人员
负责产品的质量把关,包括功能、性能和稳定性等多方面的测试内容。
运维人员
负责产品的服务端运行环境的建设和维护,以及日常的配置管理、容量规划、网络和设备故障处理等工作,常常也包含监控平台的建设和管理。
运营人员
负责业务和产品的推广和拓展。
需求评审的价值(测试人员视角)
1.充分理解需求,为后续的测试用例编写打下基础。
2.基于对需求细节的了解,可以更准确地评估测试的要点和工作量。
3.发现需求中模糊不清的地方。从质量管理的角度,这也是一个非常好的缺陷预防的方法。
所谓的互联网的做法也并不是因为它比传统的软件流程先进,而是它更适互联网产品的运作方式而已,本质上还是产品形态和需求驱动的。
1.2 测试用例设计和评审
对各种场景和路径比较系统化的覆盖,是对一个专职或者专业测试人员的基本要求。
是否编写用例的建议
1)用例设计上的投入
根据项目周期来判断测试各阶段时间占比,如测试设计文档,文档评审,用例编写,用例评审
2)用例编写的详细程度(至少包括)
用例的题目,一句话描述。·
测试步骤,逐个写下,详细程度需要有少量经验的人也可以执行。·
前置条件,此用例的执行需要哪些前置条件或者在什么条件下才会有预期的结果。·
测试数据,此用例的执行需要什么样的测试数据,比如无货的商品,特殊的优惠券等,需要提前准备好并附上。
期望的测试结果
3)表现形式
常见形式:思维导图,Excel文档,用例管理平台
常用的测试用例设计方法推荐书籍
《软件测试》(Software Testing:ACraftsman抯Approach,SecondEdition),作者是Paul C.Jorgensen。
《微软的软件测试之道》(How WeTest Software at Microsoft),作者是AlanPage、Ken Johnston和Bj Rollison。
《探索式软件测试》(ExploratorySoftware Testing),作者是James A.Whittaker
参加一些有丰富测试经验的人在场的用例评审,可以很快地打开思路,考虑得更加全面
遇到需求理解不一致时,把这些问题逐个记录下来,然后通过邮件集中发出来给对应的产品经理和开发人员来确认,进而让大家的理解达成一致。
可以实践的方式是用例设计的Workshop。就是让所有测试人员都集中在一起,然后给出一个功能场景请大家来写出自己认为需要的用例。
[attach]124310[/attach]
欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)
Powered by Discuz! X3.2