关于软件测试一些基本概念的困惑

来源：百度知道 编辑：UC知道 时间：2024/06/03 09:20:36
1、 在软件测试理论中，提到software testing methodology的时候，强调三个步骤，1.creating test strategy; 2.create test plan/design; 3.executing test. 可是在一些实际例子中，好像经常第一和第二部分混在一起的情况，test strategy 和test plan 的概念和关系始终很糊涂，恳请高手能从理论和实际应用的两个角度讲解一下。（俺是新手，一些关键的概念搞不清楚，很痛苦，不要批评俺太拘泥于这些东东）
2、 backend测试主要是确认GUI界面中的显示数据是否与对应后台查询到的数据对应一致？如果是这样，那什么时候才需要进行backend测试？比如说，我注册一个用户，成功后，那我是否需要进行相应的数据库查询，确认注册是否成功？或者在线购物，我成功下了个订单后，然后是不是需要核对‘我的订单‘中的显示订单情况与数据库查询返回的订单结果是否一致？如果是这样，那是不是所有涉及到表单提交，且引起数据库变化的操作，都要进行backend测试？
3、 在qc的mercury tours实例中，在测试计划的Mercury Tours Site—Html Pages目录下里有很多关于web page UI方面的测试，像Html page layout, html page source, html tag,spelling &grammar, tab order等等，我的问题，是针对web页面的UI测试的这些用例，对于web-based application来说，是不是基本都是通用的？
4、 在版本基本稳定的情况下，会确认一个基线版本，在此是不是马上就会进行一天一次的（Build verfication test） (Nightly build)，还是逐渐的频率越来越高？如果每天都构建新版本，那是不是每天都要进行回归测试？
5、 系统测试是不是可以理解为也是一次全面的功能测试，只不过它是在实际运行环境下进行的？那它的测试用例完全用全部的功能测试用例就OK了吗？
6、 类似兼容性测试，压力测试，性能测试，恢复测试，安装测试，它们属于不属于系统测试的范畴？如果不属于，这些测试是在系统测试之前进行还是之后进行？都在运行环境进行吗？
7

1、首先 creating test strategy 这个只是根据前面的分析 之前可能对客户需求分析 或者是功能的分析 有一个测试的策略 这个策略可能和功能相关

具体可以表现为 比如一个功能模块 它既要与外部其他系统交互 还要与内部的其他模块交互 分析出这样一个过称后 那么你就要考虑在测试时 要分别对该功能与外部和内部的交互两部分进行测试 这就是一个简单的策略 策略可能不具体 但是通过前期的分析 要有大致方向 有一些公司会要求编写测试策略文档 但是这个文档要求参差不齐 要看测试人员的水平了

create test plan/design 我经历的测试计划 一是有TPM制定的类似时间点的计划 另外就是比较有经验的测试人员对自己的已经分配的功能的一些测试计划 这就差异很大了 比如可以包含测试功能的先后顺序 也可以包含自己给自己制定的时间点

确实你不要太拘泥于这些东西 怎么说呢 很少有公司会精确的按照某些测试流程来走 因为那样过于僵化 公司会根据自身情况进行调整

2、你理解的backend我感觉是对的 不过没有很绝对的 真正的测试执行时 很少在同时只使用一种测试手段的 所以它只能算一种吧 比如在界面上显示的很可能是转化的数据 比如是一种状态 但是在数据库里却是以数字表示的 那么你怎么知道它们的对应关系是正确的呢 表单提交成功一般都会引起数据库变化吧 失败就不一定了 呵呵 不过看看数据库是对的

3、QC的前身是TD吧，如果用例写的比较好的话 应该是可以的 但不涉及代码的 其实我不太懂 没用过QC 哈哈

4、这个要看情况吧 如果项目很大 一天一次不太现实 是否每次都回归 如果有bug 应该是的 但是频率不能太高 否则开发和测试人员都会崩溃的 而且会有一个评估的 要是一直这样 什么时候是个头呢

5、ST可以说是全面的功能测试吧 但功能测试有时也指黑盒测试 我不知道你这里有没有这个意思 ST也会有白盒测试 但是比重可能不大 看具体项目

用例的话 不一定用全部功能测试用例的 其实用例在整个测试执行过程中 也是有个改进的 随着测试的进行 对某些功能的理解或是涉及变化 用例都要跟着改动 而且在ST时