1、回顾
上个星期的课程,主要了解“Linux及持续集成”,其中包括:Linux的基础命令,jenkins的设置、环境配置、新建Job等,其中还触及到了Git和Maven。之前对此了解较少,因此课堂听讲呈一脸懵态,课下咨询组群以及查找资料,慢慢有了方向和了解,对该模块的思考和收获正在整理编辑中,暂定“测试思路”为百人计划课堂4的分享主题。
2、收获
06.21,主题“测试思路”,感谢主讲人阿辉,讲解的很细致,还举例说明,反复听了3遍,写了以下总结。
欠佳部分(/可借鉴措施):
测试流程:需求分析--需求评审--需求转化为功能点--设计用例--用例评审--执行用例--完成项目测试--测试总结(可能不是很全面,但目前学习中理解到测试流程的几个步骤)
1)需求分析:此前需求文档只是阅读+熟悉模块功能点,欠缺分析和统计。
(在熟悉基本功能的基础上,分析需求,标注需求不合理及不明确的地方,并输出分析文档)
2)需求评审:此前还未参与需求评审。
(在权限范围内,争取参与需求评审,或与产品沟通需求文档,提出分析文档中的需求不合理或不明确处,完善产品需求)
3)需求转化为功能点:此前功能点的提炼已需求文档为主,提炼时的思路不是太清晰,主要需求文档上的点覆盖为止。
(理清转化的思路,可借鉴阿辉团队给出的思路:UI与数据分离、功能点划分优先级、黑盒法拆解、自顶向下拆解等,其中:
a.提到的数据,根据我们的测试产品,可能还触及不到,目前考虑基本功能的实现情况、该功能实现的显示情况以及该功能与其他功能的交互情况等;
b.继续使用Xmind思维导图记录测试功能点,但是注意细分功能点,从点到面,从全局到局部;)
4)设计用例:此前用例设计已功能点为主,已测试经验为辅,用例设计数量较多,但是有重复和多余的现象存在(一个模块用例可能几个人补充,比较混乱)。
(应分通用用例和个性化用例,及时的更新和维护用例,尽量单人负责模块用例,做到用例覆盖全面而不冗余,复用率高)
5)回归测试:测试范围模糊,通常模块全部用例执行一遍,效率不高。
(对模块功能理解后明确回归范围,优先回归已存在已修复bug后回归模块的主流程,可按照优先级回归,而后留有时间进行探索性测试)
6)总结:此前总结基本描述版本、测试内容、测试结果、发现问题等,对于问题的分析,原因的总结较为缺乏。
(除了日常的测试版本总结外,应阶段性的对模块的问题进行总结和原因分析,为避免问题回退,可将总结文档与开发能分享)
网友评论