关于软件测试一些基本概念的困惑
发布网友
发布时间：2022-04-26 23:17
共1个回答
热心网友
时间：2022-06-19 23:12
1、首先 creating test strategy 这个只是根据前面的分析 之前可能对客户需求分析 或者是功能的分析 有一个测试的策略 这个策略可能和功能相关
具体可以表现为 比如一个功能模块 它既要与外部其他系统交互 还要与内部的其他模块交互 分析出这样一个过称后 那么你就要考虑在测试时 要分别对该功能与外部和内部的交互两部分进行测试 这就是一个简单的策略 策略可能不具体 但是通过前期的分析 要有大致方向 有一些公司会要求编写测试策略文档 但是这个文档要求参差不齐 要看测试人员的水平了
create test plan/design 我经历的测试计划 一是有TPM制定的类似时间点的计划 另外就是比较有经验的测试人员对自己的已经分配的功能的一些测试计划 这就差异很大了 比如可以包含测试功能的先后顺序 也可以包含自己给自己制定的时间点
确实你不要太拘泥于这些东西 怎么说呢 很少有公司会精确的按照某些测试流程来走 因为那样过于僵化 公司会根据自身情况进行调整
2、你理解的backend我感觉是对的 不过没有很绝对的 真正的测试执行时 很少在同时只使用一种测试手段的 所以它只能算一种吧 比如在界面上显示的很可能是转化的数据 比如是一种状态 但是在数据库里却是以数字表示的 那么你怎么知道它们的对应关系是正确的呢 表单提交成功一般都会引起数据库变化吧 失败就不一定了 呵呵 不过看看数据库是对的
3、QC的前身是TD吧，如果用例写的比较好的话 应该是可以的 但不涉及代码的 其实我不太懂 没用过QC 哈哈
4、这个要看情况吧 如果项目很大 一天一次不太现实 是否每次都回归 如果有bug 应该是的 但是频率不能太高 否则开发和测试人员都会崩溃的 而且会有一个评估的 要是一直这样 什么时候是个头呢
5、ST可以说是全面的功能测试吧 但功能测试有时也指黑盒测试 我不知道你这里有没有这个意思 ST也会有白盒测试 但是比重可能不大 看具体项目
用例的话 不一定用全部功能测试用例的 其实用例在整个测试执行过程中 也是有个改进的 随着测试的进行 对某些功能的理解或是涉及变化 用例都要跟着改动 而且在ST时 很可能会补充用例 因为对功能的理解是逐渐加深的
还有一个很实际的问题 有些测试的东西是有目的性 但是执行起来却是随机的
这些很难靠用例表达 有一些是经验 写出来很难看 呵呵
6、像兼容性测试，压力测试，性能测试，恢复测试，安装测试，我个人理解是属于系统测试的 但是一般会根据具体项目进行选择 选择进行哪些测试和具体的执行次序 一般这些测试动态检查一般都在系统测试中后期吧 不过静态的就可以在前期 比如在代码走查时 就可以对SQL语句的性能进行分析 其实我们一般认为测试都要尽早介入 不过这些对测试人员的要求比较高 不是那么容易的
7、可以这么理解吧 其实我也不怎么清楚
8、应该是需求是最粗粒度的 然后设计和Use case 这个不光是细化 还有一个是对功能理解的加深吧 会有一些修正
