最开始收到大家想了解《搭建测试环境》这个topic的时候我有点困惑, 我们有关于《搭建测试环境》的培训, 网上的资料也很多, 现成的文档也很多, 大家还想了解什么呢? 后来想了想, 还是决定给大家说说测试环境对咱们测试结果的影响, 所起到的作用, 平时咱们可能更多的是搭环境或者是考原理, 可能大家不是很了解为什么要这么弄, 今天就给大家串一串线.
搭建测试环境是软件测试实施的一个重要阶段，测试环境适合与否会严重影响测试结果的真实性和正确性。
测试环境包括什么?
简单的说测试环境就是软件运行的平台, 即软件、硬件、网络、测试数据四种元素的合集, 也就是说: 测试环境=软件+硬件+网络+测试数据
硬件包括: 服务器、PC机、笔记本、各种终端等. 例如做性能测试, CPU的数量、内存的数量、硬盘等因素都是非常重要的指标, 只有选择适合的硬件测试环境并进行适当的设置, 才能有效的进行软件的功能与性能测试. SharePoint 2013就有他必须的hardware requirements, 在准备测试环境的时候, 一定要按照硬件标准来进行环境的准备工作.通常一个较完善的测试环境会根据项目的需求和条件的限制所占比例的不同，分为标准配置，最佳配置和最低配置的硬件设备。如压力测试，性能测试，容量测试必须保证在标准配置及最佳配置的设备上运行，而功能测试，用户界面测试等完全可以在低配置上的机器上运行。
软件环境指被测软件运行时的操作系统、数据库及其他应用软件构成的环境. 软件环境相对比较复杂, 需要考虑的因素也很多, 有操作系统的语言、版本、浏览器的版本和位数. 比如DocAve需要结合SharePoint和SQL, 那就还需要考虑SharePoint的配置、版本, SQL的配置和版本等因素. 对于一些涉及到域的功能, 还需要结合功能的特点考虑域环境的设置和各种用户认证等. DocAve Manager的web site是建立在IIS上的, 同时DocAve Manager是通过浏览器进行访问的, 前台使用Silverlight , 所以对应的IIS版本, 配置, 浏览器版本、配置, Silverlight 都是在准备测试环境的时候需要考虑的因素。
测试中所需要使用的网络环境也是在搭建测试环境和准备测试用例的时候需要考虑的因素。例如，如果测试结果同接入Internet的线路的稳定性有关，那么应该考虑为测试环境租用单独的线路；如果测试结果与局域网内的网络速度有关，那么应该保证计算机的网卡、网线以及用到的集线器、交换机都不会成为瓶颈；很多功能是针对网络条件不好的情况设计的, 那么测试的重点就在于模拟低网速网络条件下feature的性能和产生结果. 比如Replicator的real time, byte level 等
在软件测试中测试的数据源非常重要，应尽可能的取得大量真实数据。无法取得真实数据时尽可能的模拟出大量的数据。数据准备包括数据量和真实性两个方面。现实中越来越多的产品需要处理大量的信息，不可避免的使用到了数据库系统。少量数据情况下，软件产品表现出色，一旦交付使用，数据急速增长，往往一个简单的数据查询操作就有可能耗费掉大量的系统资源，使产品性能下降，失去可用性，这样的案例已经很多, 很早以前遇到一个case, 就是CA有一个search web part的功能, 最早在进行简单数据校验的时候, 功能运行的非常好, 但是当web part超过120个之后, job就会hang住, 所以大家在准备测试数据的时候同样要把数据量考虑进来, 这样才能算测试完成。数据的真实性通常表现为正确数据和错误数据，在容错性测试中对错误数据的处理和系统恢复是测试的关键, 举我最近碰到的一个case,我们在还原apps的时候, 如果apps中有坏数据, 咱们的job就会hang住。还有一个例子, 在D6 GA release的时候曾经出现过这样一个bug, 含有8000个site collection, 很多功能无法save plan. 这个问题到非常往后了才发现. 主要是QA的环境一般不会有这么多site collection, 其实QA Team的环境尽量和客户保持一致, 但是允许job的数据并不需要那么大. 这样很多在客户那里经常遇到的问题才能更早更快的被QA team捕捉到. 还有一部分人有这种想法, 我测试的功能与service啊, 或者一些特殊的configuration没有关系, 所以我的环境不需要准备这样的数据, 其实这样的想法是不对的. 虽然你所测试的功能只针对部分SharePoint数据, 但是并不能保证现有的功能与其他SharePoint数据的兼容性. 比如之前有的功能不支持workflow, QA的测试环境中就不包含workflow, 但是结果所有含有workflow的site在运行job的时候都会exception. 这种情况在客户那里就是完全没有办法接受的, 所以模拟相对真实的测试环境是非常重要的!
另外, 每个环境都有其特殊性, 做测试数据也需要有针对性的准备, 否则即便准备了测试环境, 依然得不到正确、真实的测试结果. 举个例子来说,对于SQL 2012的测试, 首先要知道SQL 2012有哪些大的改进. 这些改进对现有功能有哪些影响. AlwaysOn Availability Groups, 这项新功能将数据库镜像故障转移提升到全新的高度，利用AlwyasOn, 用户可以将多个组进行故障转移, 而不是以往的只针对单独的数据库. 对于测试2012, 肯定要考虑的case就是搭建AlwaysOn Availability Group, 把产品的数据安装在这样的环境上, 当进行故障转移之后, 我们的产品是否可以正常工作. 再比如SharePoint 2010 的某个CU 版本提升了User Profile Service, 那么对于QA而言只准备team site来进行测试很显然是不够的, 应该多准备一些和User Profile service结合的数据, 进行相关性的测试.
测试环境搭建的标准是什么?
- 选择比较普及的操作系统和软件平台作为最常规的测试环境. 每个产品都会支持很多操作系统版本、浏览器版本、SQL版本、SharePoint版本等等. 但并不代表说每个环境我们都需要投入等比例的测试, 应该选择大多数客户最常用的环境作为主要测试环境, 其他版本主要测试的是兼容性. 比如测试SharePoint, 我们一般会选择最新的SP补丁, 因为DocAve最大的客户群还是在美国, 美国一般对SharePoint更新比较，快所以最新的SP补丁就是常规环境. 但是CU每个月都会出, 客户一般都不会更新, 所以一定不是常规测试环境. 再比如测试对应的德文、法文环境, 咱们就需要了解德文客户一般常见的操作系统版本是什么? SQL版本是什么? 是fresh install 还是打语言包? SQL和操作系统是德文还是英文? 等等 , 总之测试环境的准备一定要结合release的目标以及市场需求来制定.
- 营造相对简单、独立的测试环境: 除了操作系统, 测试机器上只安装软件允许和测试必备的软件, 以免不相关的软件影响测试实施. 比如VS, Office等
针对环境, 编写正确的测试用例?
准备好了测试环境就需要针对测试环境进行测试, 编写正确有效的测试用例. 在咱们公司, 测试环境大概分为两大类, 常规测试环境和特殊测试环境. 常规测试环境是指大多数客户经常使用的, 我们推荐客户使用的一类测试环境. QA会在这类环境上执行大多数的测试用例. 这类环境往往不需要编写特殊的测试用例, 而是要尽可能的按照上面提到的标准来准备, 尽可能的模拟客户真实环境和数据进行测试
针对于特殊环境, 是指客户使用群体相对不多, 有一些special 的东西我们需要进行特殊处理, 那么测试用例的编写就一定要根据环境的特殊之处进行编写. 举一个ADFS的例子, 客户可以通过ADFS联合认证来实现其他域的用户直接访问当前域的SharePoint. 因此对于测试来说, check/find user, copy user等相关的option就会变得尤为重要. 所以我们经常说的针对特殊环境进行基础功能校验, 并不是指所有的特殊环境都要验证所有的case, 而是要验证有针对性的case.
而特殊环境的选择, 也要根据release实际的objective和代码改动来进行选择, Case也要进行有计划的删减. 一般情况下, 每个release 的test environment是根据两个原则进行选取的, 一方面是客户的使用情况, 通过选择客户使用多的环境版本、配置方式来作为regular test environment, 通过客户的特殊需求、release objective来确定特殊环境的scope, 通过开发改动量的影响也能区分出一些特殊环境是否有必要进行验证.
环境测试相关的经验分享
对于现有的环境测试, 我也总结了一些经验, 给大家分享一下:
- 语言环境的测试: 需要考虑的主要因素有语言中的特殊字符, 输入法等, 举个例子, 记得D6中第一次支持日文, 在全角输入法下保存各种profile就会弹错.
- 对于DR solution的测试, 一定要考虑failover之后, 产品允许的正确性, 包括运行老plan, create 新plan, restore 老backup数据等等
- 如果产品中有涉及到Enterprise SP版本特有feature的改动, 不要忘记检查下foundation server, 看看开发是不是忘记判断版本
- 对于SQLSP等新版本的测试, 一定要根据release note, 优先测试新功能
- 对应所测试的产品, 要考虑所相关软件的版本和不同配置情况下产品的运行(比如SP, SQL, IIS, Browser….) 举例子来说, 微软在SharePoint 2010版本中增强了SharePoint Service Application Cross-Farm支持能力, 不同的功能就需要有针对性的进行不同的验证. 比如RC, 需要确保可以读取跨域Remote Farm Web Analytics Service相应DB信息，与此相关联Report Center功能需要着重测试如:Referrers, Search Usage, Configuration Report
说了这么多, 对于一个好的QA而言, 一定要不断的拓展自己的知识面,熟悉相关软件的原理与设置, 才能把测试环境应用好, 得出最真实准确的report, 学会及时利用网络资源进行research, 不断的总结在测试中积累的经验.