移动应用的测试策略与测试架构

今天我们来谈谈移动测试的测试策略与测试架构。

首先我们将移动应用的范围限定在智能移动操作系统(比如Android、iOS、WinPhone等)上,包括手机应用,智能设备应用等。

智能手机和智能设备的普及需要大量的应用来支撑。随着应用数量的增多,业务复杂度的提高,移动应用也越来越需要各种测试来保证应用以及设备本身的正确和稳定运行。因此移动应用测试的需求也越来越大,大量关于移动应用测试的书籍应运而生,比如《Android移动性能实战》《腾讯iOS测试实践》《移动APP性能评测与优化》《深入理解Android自动化测试》《精通移动App测试实战:技术、工具和案例》等。

这些书都介绍了大量的移动应用测试实践,但是无论看多少本书,学习多少种测试方法、测试技术或者测试工具和框架,首先还是需要学习并使用测试策略与测试架构。如果没有在一开始制定好的测试策略和测试架构,而是盲目进行各种测试,很有可能事倍功半。

对于移动应用,首先它本质上也是软件系统,所以通用的软件测试方法技术都可以使用。其次它又拥有嵌入式的特征,比如开发需要交叉编译、需要远程调试、硬件资源相对不足等。所以移动应用的测试也有其特殊之处,比如也需要交叉编译、远程测试以及各种硬件相关测试等。对应的移动应用的测试策略和测试架构也有其特殊性之处。

制定测试策略

我将移动测试分为三种类型,分别是基础测试、进阶测试和产品测试,其中基础测试是产品能正确并快速交付的基本保障,扩展测试主要是为了增强软件系统的健壮性,而产品测试主要是通过产品角度以及用户角度去思考而进行的测试。下面分别列举了常见的三种类型测试。

基础测试

  • 功能测试 (Function Test)[1] 。
  • 集成测试(Integration Test )
  • 单元测试(Unit Test)
  • 契约测试(Contract Test)[2]

进阶测试

  • 兼容测试(Compatibility Test)
  • UI视觉测试(UI Visual Test)
  • 性能轮廓(Profiling)
  • 安全测试(Security Test)
  • 异常测试(Exception Test)[3]
  • 猴子测试(Monkey Test)
  • 安装、升级和卸载测试(Install、Upgrade and Uninstall Test)
  • 耐久测试(Endurance Test)
  • 耗电测试(Power Consumption Test)
  • 流量测试(Network Traffic Test)
  • 其他硬件功能专项测试[4]

产品测试

  • 易用性测试(Usability Test)
  • A/B测试(A/B Test)
  • 产品在线测试(Product Verification Test or Product Online Test)
  • 用户测试(Customer Test)[5]

对于一个中小型项目来讲,很多时候资源都是十分有限的,很难做到全面类型的测试,大型项目更是如此,更难有足够多的资源做所有类型的测试。而且可能还由于团队人员的技术能力不足,或者所拥有的测试相关的技术栈的局限,以及开发测试环境和软件系统架构的限制,有些类型的测试是无法进行的。

所以,制定测试策略的关键点在于根据质量需求的优先级,并参考团队的各种限制来指定。

首先通过和PO、PM等进行讨论得到产品质量需求的优先级,然后根据优先级指定相应类型的测试。再根据团队的资源、项目周期、技术能力以及各种限制来制定相应的测试方法和测试技术,其中包括使用自动化测试还是手动测试、使用什么测试工具和测试框架、测试的范围和程度等。

下表是一个典型手机应用的测试策略表的样例(这个只是一个模拟项目的样表,真实项目中的各类信息应该更多,并且可以根据具体情况添加新列。并且注意,这些测试并不一定由测试人员或者QA来做,应该由整个团队一起协作完成):

表中的质量需求优先级的获取是一个比较繁琐的过程,需要和各个利益相关者一起讨论并且协商获得。

根据这个测试优先级表,就知道应该把资源优先投入到高优先级的测试中。等高优先级的测试做到团队可以接受的程度后,再按照优先级做下一个类型的测试。这个表中的优先级在开发过程中不是绝对不变的。如果PO、PM等利益相关者对于产品质量需求的优先级发生了改变,在得到团队同意后,还需要改变这个表中的测试优先级。所以需要经常与团队更新测试进度,并及时获得团队各个角色对于测试和产品质量需求的反馈与更新。

其次可以根据测试金字塔等模型来思考不同类型测试之间的关系和工作量,但是很多情况下也可以不用参考这些测试模型,因为移动应用的复杂度一般不会特别高,并且当前大多数情况下,移动应用中复杂的业务逻辑都会尽量在服务器端进行处理,所以移动应用很多时候只是一个用户交互系统,所以应该尽可能的完成会影响用户使用的E2E流程测试,然后再继续做其他类型的测试。

但是对于在移动应用中实现复杂业务的项目,测试策略还是应该尽量思考测试类型之间测试用例重复的问题,尽量避免重复的用例,降低测试成本。

制定测试架构

通过测试优先级表,我们获得了简易版的测试策略,然后就应该制定测试架构了。由于嵌入式软件的特殊性,其测试架构也与常规的桌面系统和服务器系统有一定的区别。下图为针对上面样列测试策略相对应的功能测试架构:

图中只针对功能测试进行了进一步的详细架构设计,并没有对其他测试比如集成测试、兼容性测试和稳定测试等进行详细架构设计,感兴趣的读者可以根据自己项目的实际情况自己尝试一下。

通过这个架构图,可以比较系统以及直观的了解各种类型测试的分布、关系和测试系统的架构等。

然后配合测试优先级表就可以较好的指导团队进行有效的测试,比如制定更好的测试计划,制定更适合的自动化测试系统等。并且还可以更有效的评估产品质量,比如什么类型的测试没有做,那么那些特定方面就存在较高的风险。

不过任何软件系统都是存在缺陷和风险的,关键是看这些缺陷对于开发商和用户产生的影响有多大,风险是不是在可控范围内的。永远不要尝试去找到所有缺陷并消除,而是要从风险大小、影响程度等各方面综合考虑,增加团队对于产品质量的信心,并且不要对客户产生严重的大范围的影响。

注:

[1]. 后台常住应用测试也属于功能测试。

[2]. 单机应用可以不用考虑做契约测试。

[3]. 异常测试包括弱网测试,比如低速网络信号、网络时断时续,网络切换以及无网络等,突然断电等。

[4]. 其他硬件功能专项测试包括硬件功能关闭,硬件功能异常等。

[5]. 用户测试包括收集用户使用信息,并生成用户真实使用的测试用例来对系统进行测试。


更多精彩洞见,请关注微信公众号:思特沃克

Share

从测试策略到测试架构

文/刘冉

今年是我做软件测试的第7个年头了,当年我从软件开发转做软件测试的时候,没有想过我能在这个领域做这么久。

在这7年里面,我在软件测试领域摸爬滚打,从自动测试起步,逐步接触到软件测试的各个领域:各种测试方法(等价类,全配对等)、测试技术(单元测试,功能测试,性能测试,探索性测试等)、自动化测试工具(JUnit,Selenium,Gatling,ZAP等)、测试流程(传统测试流程,敏捷测试流程等)以及测试策略(测试象限和测试金字塔等)。

其中“测试策略”在测试业界是讨论的比较少的,因为大多数人的工作重点是设计测试用例,执行测试或者开发和维护自动化测试,而只有少部分人才会涉及到测试策略的工作,从而导致很多测试人员其实并没有系统的了解测试策略。

所以我准备将我这几年对于测试策略的经验、总结以及思考以系列文章的形式写出来,希望能稍微帮助一下大家去理解测试策略,从而做到更好的测试,减少缺陷,提高质量。

测试策略

首先来看一下Wikipedia上对于测试策略的定义:

A test strategy is an outline that describes the testing approach of the software development cycle. It is created to inform project managers, testers, and developers about some key issues of the testing process. This includes the testing objective, methods of testing new functions, total time and resources required for the project, and the testing environment.

Test strategies describe how the product risks of the stakeholders are mitigated at the test-level, which types of testing are to be performed, and which entry and exit criteria apply. They are created based on development design documents. System design documents are primarily used and occasionally, conceptual design documents may be referred to. Design documents describe the functionality of the software to be enabled in the upcoming release. For every stage of development design, a corresponding test strategy should be created to test the new feature sets.

更多内容详见:https://en.wikipedia.org/wiki/Test_strategy

所以测试策略(Test Strategy)的第一目标就是“减少缺陷的出现和发布”。其中“减少缺陷的出现”可以通过测试前移等方法来解决,在进行软件需求分析和架构设计的时候发现缺陷;而“减少缺陷发布”可以使用各种测试方法、技术来验证和测试编码完成的功能(这两点在今后的文章里面会通过不同的例子进行更详细的阐述)。

由此可见,“测试策略”并不是只由测试人员定制的,它是由一个团队的各个角色一起来制定和建立的,目的是保证软件的质量,减少缺陷。

而“测试计划”是用于实施测试策略的。只有充分理解测试策略目的和实施方式,才能充分理解测试策略,为什么要做测试策略,什么样的测试策略才更有意义、更好,怎样实施才能更有效等问题。

测试计划

测试计划在Wikipedia中是这样定义的:

A test plan documents the strategy that will be used to verify and ensure that a product or system meets its design specifications and other requirements. A test plan is usually prepared by or with significant input from test engineers.

更多内容详见:https://en.wikipedia.org/wiki/Test_plan

制定测试计划是保证测试策略能被有效执行的一种方式。它告诉了团队在什么阶段,什么样的角色应该执行测试策略中什么样测试技术和测试方法。它主要由测试人员编写,但是应该由整个团队进行评审,因为开发人员、产品经理、业务分析人员甚至用户都可能参与到测试计划的执行中。

测试计划是可以根据项目的实际进展情况进行调整的,所以它并不是一成不变的。

测试架构

在上个世纪六七十年代软件系统还处于小规模的时候,软件开发并没有谈什么架构,软件测试也不存在什么策略可言。但是随着软件规模的极速增大,复杂性也成指数级增加,专业的软件架构应运而生。

为了有效的在规定时间内完成复杂软件系统的测试,必须有一个指导性的策略来帮助团队理解、选择和组织大量的测试,因此软件测试策略就出现了。而测试策略往往是高层次的指导,对于一些中小型项目也许已经足够了,但是却不足以应付现代越来越复杂的软件系统。

因为随着微服务、移动互联网、物联网、大数据分析系统、AI系统等的出现,要测试一个包含各种技术,外部依赖,或者独立子系统的复杂系统,并不是简单的根据测试策略在不同层面上做不同的测试就可以了,而是要理清各种测试之间的相互联系和制约,然后思考怎么有效的将各个维度上的测试联系起来,以软件系统架构的思维去思考整个测试体系。

请注意这里不是说要去设计一套全自动化的测试系统来完成整个系统的所有测试,而是通个各种有效的方式(无论手动还是自动)把各种测试合理且有效的联系起来,形成一个拥有完整架构的测试体系,这样才能使整个系统的各种测试更加可视化和更易于理解,使整个系统的各种测试更加有效,避免重复测试,节约成本。

举例来说,一个前后端分离的Web业务系统不仅有前端UI和大量的JavaScirpt代码,还有后端的API和第三方依赖系统以及数据库系统,如何将各层测试有效的联系起来就是测试架构需要解决的问题。

首先,前端、后端API、第三方依赖系统和数据库系统有各自的单元测试、集成测试等,然后可以使用契约测试来测试统一前端和后端API,再使用Stub加入对于第三方依赖系统的契约测试或者监控测试,还需要使用测试数据生成系统参数,将各种测试数据存入数据库系统用于支持契约测试等。

对于不同软件系统,其架构一般都是根据业务需求、技术能力等各种条件来设计的。与软件架构一样,测试策略和测试架构在不同的项目里面,需要根据其软件系统的架构、技术栈、业务需求、人员的技能等因素来定制和设计。

再谈测试策略

现在业界流行的测试金字塔和测试象限只是两种高度抽象和简化的测试策略模型,不具备实际可操作性,只具备高层次的指导性和参考性。直接根据这两个模型来工作是低效的,甚至可能带来负面效果。所以对于测试金字塔和测试象限不能盲目的使用,而是需要根据项目的实际情况来生成适合自己项目的测试策略和测试架构,并在此基础上执行真实的测试工作。

扩展阅读:

http://www.infoq.com/cn/articles/an-effective-test-strategy

http://www.testingexcellence.com/test-strategy-and-test-plan/

更多精彩洞见,请关注微信公众号:思特沃克

Share