在软件测试理论中，提到software testing methodology的时候，强调三个步骤，1.creating test strategy; 2.create test plan/design; 3.executing test. 可是在一些实际例子中，好像经常第一和第二部分混在一起的情况，test strategy 和test plan 的概念和关系始终很糊涂，恳请高手能从理论和实际应用的两个角度讲解一下。（俺是新手，一些关键的概念搞不清楚，很痛苦，不要批评俺太拘泥于这些东东）答：test strategy 用来表述如何测试软件系统，如何确定软件系统的测试级别和测试重点。实际项目中，单元测试、集成测试、功能测试、系统测试、验收测试等阶段的测试活动都要有不同的测试策略。拿集成测试阶段来说，可以采用自顶向下和自底向上的混合策略完成测试任务。test plan 要求用系统的方法来保障测试任务的顺利完成。包括测试任务的分配，测试资源的分配，测试策略和测试范围的确定，测试用例的设计方法，通过/失败准则的确定，测试风险的评估，日程安排等方面的内容。

　　问：backend测试主要是确认GUI界面中的显示数据是否与对应后台查询到的数据对应一致？如果是这样，那什么时候才需要进行backend测试？比如说，我注册一个用　户，成功后，那我是否需要进行相应的数据库查询，确认注册是否成功？或者在线购物，我成功下了个订单后，然后是不是需要核对‘我的订单‘中的显示订单情况与数据库查询返回的订单结果是否一致？如果是这样，那是不是所有涉及到表单提交，且引起数据库变化的操作，都要进行backend测试？

　　答：backend测试可以理解为数据库测试。通过GUI键入的数据会被存储在后台数据库中，或者说数据作为记录存储在数据库的数据表中。因此，backend测试不仅要求通过GUI键入的数据被恰当地，正确地存储在后台数据库中，还要求通过GUI调用的这些数据(记录)能够被正确的显示出来。通过上述分析后，楼主的疑虑不难被消除了。

　　问：在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来说，是不是基本都是通用的？

　　答：那些用例可以作为我们平时UI测试时的参考，但是不提倡生搬硬套。平时的UI测试要根据UI的特征来进行CASE的设计。这些特征包括符合通用的标准和规范，正确性，一致性，舒适性，直观性等等。

　　问：在版本基本稳定的情况下，会确认一个基线版本，在此是不是马上就会进行一天一次的（Build verfication test） (Nightly build)，还是逐渐的频率越来越高？如果每天都构建新版本，那是不是每天都要进行回归测试？

　　答：BVT也可以被看作冒烟测试。BVT测试具备下面这些特点：它只是测试人员进行全面测试前的一个测试子集，用来验证软件系统主要的功能是否完好；BVT是一种类型的回归测试，在软件每次有新的build版本时进行；测试时间短，不会超过30分钟；BVT的用例要能覆盖软件基本功能；每天有新的build版本时，都要进行BVT。明白了这些，相信楼主的疑惑也是可以取消的。

　　问：系统测试是不是可以理解为也是一次全面的功能测试，只不过它是在实际运行环境下进行的？那它的测试用例完全用全部的功能测试用例就OK了吗？

　　答：功能测试和系统测试是两码事。功能测试主要是验证软件功能的实现情况，不考虑非功能性问题。而系统测试则是在更广的范围内进行的测试，包括：功能测试、安全测试、容量测试、安装测试、压力测试等等方面。所以即使执行了全部的功能方面的用例，也是无法完成系统测试的。

　　问：类似兼容性测试，压力测试，性能测试，恢复测试，安装测试，它们属于不属于系统测试的范畴？如果不属于，这些测试是在系统测试之前进行还是之后进行？都在运行环境进行吗？

　　答：上述类型的测试均属于系统测试的范畴。是在用户使用软件系统的近真实的环境中进行的。

　　问：关于build和release的概念有点模糊，能否给予解释？是不是build XYZ是指一个具体的基线版本，而build  xyz release  abc，是指这个基线版本下的一个实际的发布的子版本？所谓release是不是就是指一个真正向用户或者公众发布的版本？

　　答：软件发布前的版本都是build版本，这个阶段的版本是不断发现bug，不断解决bug，不断完善软件的过程。真正向用户发布的版本是release版本，也是软件的最终版本。

　　问：Use case相比较用户需求文档或用户设计文档来说，是不是提供了最详细的功能实现细节？它们三者是不是就是个逐步一一细化的关系？

　　答：Use Case只是描述了软件系统的功能而已，并没有提供功能实现的细节。Use Cases是捕获用户需求的非常有效的机制。通过Use Cases 用户可以看到系统提供的功能，知道自己需要什么样的功能，进而生成用户需求文档。用户接口设计文档应该满足用户需求。补充: Use Case只是描述了系统的功能是怎样的，用户需求里面可能还会关注到系统性能。所以三者的关系不能简单理解为逐步细化。