软件测试培训心得体会.doc
文档编号：1081523
文档页数：15
上传时间： 2020-06-26
文档级别：普通资源
文档类型：doc
文档大小：41.50KB
软件测试培训心得体会软件测试培训心得体会 在支付宝测试分析的角色和系统分析的角色是对应的 只不过一 个是测试类的另外一个是开发类的 系分下面会有相应开发 测分下 面会有相应的测试用例编写和执行人员 也就是说测试分析文档是对 测试执行人员的一个指导 在我原来的理解方式上 觉得测试分析人 员应该是用例编写人员 而在这里测试分析人员是从业务上去分析 的 用例是用例执行人员来写并且执行的 而通过这次的这次分析觉得自己的测分还存在以下的问题 1 太关注开发的内部实现逻辑 建议 将开发内部实现逻辑看 成一个黑盒子 测试分析要从这个黑盒子的输入和输出上去看开发内 部实现逻辑是不是有问题 而不应该先去了解开发的实现逻辑然后按 照他们的思路去分析 2 分析文档写的过于详细 甚至将用例的步骤都写了出来 建 议 测试分析要从全局上去看问题 细节的东西即便是知道的 也要 留给之后的用例编写人员去了解 就像系分之后的开发需要去写详细 设计的道理一样 这样后面的人才会自己主动去想问题 3 分析文档要考虑维护性问题 不要出现类似比如还款中状态 为 R 这种具体的数据内容 因为我的分析是对后续用例编写人员 的一个指导性的文档 所以如果侧分这么写很有可能导致用例也照着 这么写 其实不管侧分和用例都不应该具体写到 R 这么细节 否则的 话开发稍作变动我们就要相应变动我们的用例 4 没有明确测试目的 review 用例的时候 没有提出每个用例 需要明确一个测试目的 让别人来看这个用例的时候能明白到底是怎 么回事 总结 1 以后写测试分析文档 依据仅仅是 prd 文档 必须抛开开发 实现逻辑部分 即不去看系分文档 待测分出来之后 再去看系分文 档 互相看看彼此考虑的是否存在遗漏的地方 等到在写用例的时候 再让写用例的人和相应的开发去互相明确更细节的东西 2 写用例我们目前都是仅仅做到对流程上的每个节点去单独分 析 细到看输出的时候会关注到数据库表的一个变化 但是除了以上 部分 其实还少了对整体流程的关注 需要增加业务流程的各条路径 的一个覆盖 在针对路径的用例中不需要关注到数据库表级那么细 3 在做流程路径覆盖之前应该画一个路径图 这个图的画法考 虑各个入口的不同分开画流程图 分别进行路径覆盖 软件测试在整个软件周期中的重要性 它存在于整个项目周期 在项目开始之初需求调研的时候就开始了 在形成需求规格说明
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
