我们将从检查功能测试开始，关注安全性，互操作性，兼容性，准确性和适用性。我们将讨论用于创建功能性移动测试的各种传统和非传统技术。接下来，我们继续讨论非功能性测试，特别是性能，可用性，可靠性和可移植性。

简介

让我们首先澄清功能测试和非功能测试。考虑一下ATM。 ATM可以让您做什么？它可以让您提取现金，存款，查询余额和转账。在语法上，这些都是动词短语，即动词和名词。

ATM需要很快、可靠的处理。这些是副词。系统能做什么一般是功能。而如何做到的副词和形容词就是非功能性的。

没有适用于所有应用程序的质量特性术列表，或者对所有应用程序同等重要。正如我前面提到的，对于银行应用而言，安全性是大问题，而对单机纸牌游戏，则远没有那么重要。

参考资料

• 全文 https://www.jianshu.com/p/b0eb98724f98
• [书籍:ASTQB-BCS移动测试基础指南 Mobile Testing An ASTQB-BCS Foundation Guide - 2018.pdf](https://www.jianshu.com/p/a252732f8f1c
• 本文涉及的python测试开发库 谢谢点赞！
• 本文相关海量书籍下载
• 2018最佳人工智能机器学习工具书及下载(持续更新)

功能测试

图片.png

功能测试是关于应用程序的功能。它主要关注四个主要特征：

• 准确性;
• 适用性;
• 安全;
• 互操作性。

准确性测试检查应用程序是否真正为您提供了正确的答案。例如，对电子商务应用程序进行的一项精度测试将检查运费的错误计算。

适用性测试检​​查应用程序是否提供了它应该提供的功能。应用程序可以准确地工作但不适合，因为它没有执行您需要执行的操作的功能。例如，航空公司应用程序的一项适用性测试会检查它是否不仅可以搜索航班，还可以在您找到航班后完成预订。

安全测试检查应用程序是否可以拒绝未经授权访问数据和功能，同时允许授权访问数据和功能。例如，药房应用程序的一项安全测试将确保每个客户都可以访问他们自己的处方数据，但不能访问任何其他客户的处方数据。

互操作性测试检查应用程序是否与其使用或使用它的其他应用程序正常工作。例如，餐馆定位应用程序的一个互操作性测试，确保您可以点击餐馆的电话号码，这个动作将正确地导致电话应用程序拨打该餐厅的电话号码。

大多数测试人员在考虑进行功能测试时会想到准确性和适用性的测试。

安全漏洞往往是被动的而不是主动的。我所说的安全漏洞是被动的，是指某人 - 无论是黑客，犯罪分子，心怀不满的工作人员还是安全测试人员 - 都必须尝试利用漏洞来让安全故障发生。对比一个简单的准确性错误，它会给任何人错误的答案，无论是否有意导致失败。因此，重要的是要考虑安全风险可能存在的方式，以便您可以测试它们。让我们来看看其中的一些风险。

首先，移动应用通常是通过网络访问信息，这可能涉及通过公共Wi-Fi网络发送和接收信息。这样的公共网络具有内在的风险，因为犯罪分子很容易监控它们的流量。因此，发送到应用程序或从应用程序发送的任何敏感数据都需要加密。

移动设备本身受到攻击，因为人们会下载并安装应用程序而不会提出明显的问题：“谁创建了这个应用程序？”现在，大多数人，在使用他们的PC时，要知道他们不应该打开他们不认识的人发送的附件，但同样的人会下载并安装由他们不认识的人创建的应用程序。任何这样的应用程序都可以想象成为特洛伊木马。

此外，人们并不总是在他们的移动设备或其PC上建立良好的安全性。移动设备更容易丢失。

当人们用手机换另一部手机时，他们可能会对新手机过于兴奋而不记得擦拭旧手机，因此可能会留下私人和机密信息。即使它被擦除，你也要问，“擦除的安全级别是多少？”只是删除一些内容是不够的，只是覆盖一次内存位置通常不足清理数据。

移动应用程序也带来了特殊挑战，因为它们有时会使用许多不同的通信渠道。其中一些本质上是不安全的，或者以不安全的方式易于使用。对于大多数PC和笔记本电脑而言，唯一固有的不安全通道是Wi-Fi。

但是，移动应用程序除了可能不安全的Wi-Fi之外还使用其他渠道。例如，假设您通过短信与某人发短信。这是不安全的，因为您的网络运营商可以访问这些消息。现在，一个有安全意识的人会说，“不，我从来没有这样做过。我使用Telegram应用程序。“好的，但你正确使用它吗？默认情况下，如果您与Telegram中的某人开始聊天，则表示不安全。您必须启动加密聊天，并且当您开始聊天时，告诉应用程序在您结束聊天时让线程自毁，以使消息真正安全。特别指出，微信的功能过多，已经爆出多起诈骗与安全事件。

所以，仅仅因为某人使用具有安全性的软件并不意味着他们以一种安全的方式使用它。例如，很多人使用的密码非常简短或明显。几乎所有应用程序的用户都不会拥有相同的安全思维。不仅仅是用户可能不安全。开发人员有时也这样。因此，在测试应用时，请查看敏感信息存储在设备上或存储在应用中的情况。

最后，您可能想要考虑一下您的应用程序在越狱后的iPhone行为，或root后的Android手机，或等效修改后的其他型号的手机。这可能会改变您应用的安全行为。现在，你的经理们可能会说，“嘿，人们不应该这样做，设备供应商也不支持，所以我们为什么要担心会发生什么？”我想这个问题的答案取决于风险与您的应用有关的安全漏洞。

让我们看一下安全测试的开源思想库：OWASP。
OWASP是开放式Web应用程序安全项目，他们的网站是安全意识的宝库, OWASP专注于创建与安全相关的资源，而不是工具，而是信息。 在OWASP网站上，可用的资源是主要移动应用程序安全风险列表。比如：

• 弱服务器端控制：当服务器端通过本机应用程序或混合应用程序信任身份验证时，就会出现这种情况。例如，如果本机应用程序与服务器建立连接，则服务器端软件可能会认为该用户是应用程序声称的用户。这可以很容易地在设备端被击败，或者通过直接与服务器呈现给更多接口交互来绕过。

• 设备或服务器端的不安全数据存储：这是另一个主要风险。比如设备丢失了，服务器被黑了。

• 不安全的数据传输：此处的问题示例包括私有识别信息的不正确或弱加密，或者在您应该或以弱的方式使用这些渠道时不使用HTTPS或FTPS等安全协议。

• 意外数据泄漏：例如，必须解密加密数据才能使用它 - 假设我们在设备上存储有关用户病历的私人信息，我们允许用户添加，修改和删除信息。必须解密该信息以便向用户显示。如果该信息存储在临时位置，并且可以访问临时位置，则可能再次在服务器端或客户端导致数据泄漏。

• 弱的身份验证和授权：身份验证问题可能导致使用移动应用程序的人不是我们认为正在使用移动应用程序的人。事实上，其他一些人设法掌握了这个人的证书。授权问题可能导致某人能够访问他们实际上无法访问的功能和数据，或者在访问被撤销或过期后保留访问权限。

• 加密失败：这里的一个示例问题是，使用较弱的加密算法（可能出于向后兼容性或速度的目的）会使应用程序容易受到攻击。即使是强大的算法也可能因使用不良密码而变弱。

• 客户端注入：这是攻击者强制或欺骗应用程序使用专门用于劫持应用程序本身的数据。这可以用于例如将个人识别信息从设备上载到因特网上的某个目标数据存储库，使用该应用程序作为不知情的利用工具。

• 通过不受信任的输入做出无效的安全决策：当您的应用具有其他应用可访问的界面时，可能会出现这些问题。如果攻击者可以弄清楚如何利用这些界面，他们可以强制您的应用程序执行操作或泄露敏感信息，而无需用户知道这种情况。例如，使用特洛伊木马类型下载的应用程序可能会发生此类攻击。

• 不正确的会话处理：大部分互联网都运行在所谓的无状态协议（如SOAP和HTTP）上。然而，人们通过认证和接受授权的过程来执行敏感活动，这需要一个状态的概念。例如，可以通过cookie或其他令牌处理状态信息，但是如果不能安全处理，这些cookie和其他令牌可以泄露给攻击者，从而允许攻击者像执行身份验证一样执行操作。

• 缺乏二进制保护：当有人获得您的应用程序的二进制文件并设法对其进行反向工程时，可能会发生这种情况。这可能是为了窃取算法，产生应用程序的淘汰，或者弄清楚如何访问应用程序使用的敏感信息。

首先，在对应用程序进行安全性测试时，请确保合适的人员和正确的应用程序可以访问他们有权访问的功能和数据。
相反，请确保不应访问某些功能和数据的人员和应用程序不能这样做。这是声明的后半部分，它更加复杂，需要更多的思考和更多的工作。通过对基于角色的安全性的分析，可以列出对于正确的人和正确的应用程序来说，它们对他们应该访问的内容的访问权限，并且该列表可以用作一组测试条件。但是，要识别与检查错误的人或应用程序相关的所有有趣的测试条件，以及访问他们不应该访问的内容要困难得多。

在存储数据时，至少应对敏感数据进行加密，并以强大，安全的方式加密。当数据在传输过程中时，无论再次使用哪种协议，至少应该对敏感数据进行安全加密。虽然这里显而易见的是蜂窝网络或Wi-Fi网络，但不要忘记移动设备和连接到它的设备之间的数据流动，比如蓝牙键盘。在任何情况下，您的应用都不应以明文形式发送敏感数据，即未加密的数据。

最后，如果您参与测试内部应用程序，请确保测试所有移动设备是否正确遵循安全策略，包括人们自己的设备（如果他们带来工作）。有很多公司的恐怖故事都是从人们丢失设备没有得到妥善保护并获得公司信息开始的。

现在，您使用此安全测试的程度取决于安全性对您的应用程序的重要程度。如果你正在进行纸牌游戏，那里没有太多的安全风险。如果你正在编写一个访问银行账户的应用程序，那就完全不同了。

互操作性在移动设备上是一个大问题，因为许多应用程序使用其他应用程序来执行某些操作，因此无需在应用程序本身中构建该功能。比如分享微博。还有与服务器组件的互操作性，当移动应用程序通过网络与服务器端的接口进行通信时，就会发生这种情况。本地和远程互操作性也可能发生。假设我使用Yelp找到餐馆，然后点击餐馆的地址。 Yelp调用设备上的地图应用程序，并将地址传递给该应用程序。除非已经下载了当前位置的地图，否则地图应用程序可以使用该网络来联系其指定的在线地图库。从测试的角度来看，请注意这是用户的单个用例，但是在此过程中的任何一点都可能发生故障。

如果您的控件之外的应用程序是新的或更改的，那么这也会带来一些测试挑战。例如，如果Google更改了手机上的默认Android相机应用，则此类更改可能会破坏Facebook功能，允许我将图片直接插入到帖子中。

这些东西在更新期间确实会被破坏。我的Android手机一度自动更新了它的操作系统，尽管事实上我曾两次要求它不这样做。无论如何，它继续并更新了手机。这导致了大量的东西无法运作。例如，首次更新手机时，大部分联系信息都丢失了。然而 - 这真的很奇怪 - 第二天神奇地回来了联系信息。它去了哪里？为什么会回来？我不知道。然而，大多数无法操作的东西，如Facebook，Twitter和许多其他应用程序必须卸载并重新安装。

虽然互操作性有时被称为兼容性，但实际上存在差异。互操作性涉及在应用程序或组件之间进行的活动对话，在哪里使用另一个来完成特定的事情。谈话可以看作是横向的。兼容性更加垂直。或者，可以将兼容性视为一种特殊形式的互操作性，它可以查看您的应用程序如何与设备提供的组件，操作系统以及托管应用程序的移动设备的类似固有功能进行互操作。

例如，如果您的应用在浏览器中运行或以其他方式使用浏览器，则兼容性测试从识别您的应用支持的不同浏览器开始。对于某些基于浏览器的应用程序，尤其是本机应用程序，您必须识别不同的支持设备以及这些设备的不同配置方式。无论您的应用程序是否更改，您还必须准备好测试发生的更改。

记住动态设置中存在互操作性和兼容性也很重要。测试条件与相互依赖性有关，比如使用设备为设备充电，与设备和应用程序进行数据通信数据没有出错。条件组合是移动应用测试的关键部分。 了解应用程序中的相互依赖关系。

我建议测试人员与开发人员密切合作，以了解这些相互依赖关系何时何地发挥作用。然后，思维测试人员可以弄清楚如何更好地创建适合其用户群的特定测试。

为了兼容性和互操作性，您应该使用基于风险的测试来确定关注的位置。您可以使用等价类来识别所涉及的每个因素的不同相关选项。如果风险足够高，您可以考虑进行组合测试，至少对于那些您担心会相互干扰的因素。

如果您的应用程序已在运行，您应该有一些日志。您可以应用一些分析来帮助您弄清楚您的用户群是什么样的，使用了哪些不同的配置，等等。

如果您刚开始测试移动应用程序，那么移动设备与典型PC可能不同的方式会有所不同。通常PC的主要区别在于内存大小，磁盘空间和CPU功率。移动设备还要考虑，如屏幕尺寸，屏幕分辨率，电池续航时间等。快速设备充电器会严重破坏应用程序的数据或功能。

有不同的网络提供商及其数据计划和数据限制，这可能会影响您的应用的工作方式或可以使用的方式。此外，移动设备自然而然地移动。这会影响连接的质量，速度和类型，因此从测试的角度来看，您必须考虑其他因素。

移动设备通常支持外部设备，您的应用可能会使用外部设备或影响应用的工作方式。例如，对于我的手机，我有一个USB转HDMI转换器。

外围设备可能包括蓝牙键盘，耳机，扬声器，HDMI视频适配器，信用卡读卡器等。不同型号手机是不同的。即使在单一型号的手机中，也可能存在连接性，安全性，与类似设备的互操作性，传感器数据如何为应用程序提供等等。比如使用不同的存储卡。

了解您的应用程序在特定设备上的限制。了解阈值，限制以及应用程序如何处理这些限制是测试人员可以与项目团队共享的重要信息。

测试设计：使用经典技术在审查了功能之后，让我们看看它与测试设计的关系。在测试设计期间，您必须考虑应用程序的功能，支持的设备功能以及这两者的交叉方式。还要记住，应用程序使用的设备功能以及应用程序不使用的设备功能，可能会以某种方式与您的应用程序进行交互。假设您有一个播放音乐的应用程序，例如在您玩游戏时播放背景音乐的单用户游戏。它可能适用于蓝牙耳机或其他音频设备，但蜂窝网络呢？起初你可能会说，“不，那里确实不应该有任何互动”，但是当你正在玩背景音乐游戏的过程中发生电话时会发生什么？如果您接听电话，则需要暂停游戏，包括暂停音乐。我在手机上发现了一些情况并不总能正常使用。如果我使用的是使用音频功能的应用程序并接听电话，则音频会继续播放。很明显，有些东西没有经过适当的测试。

如果您的应用程序下载和上传数据，您还应该考虑连接，数据要求和数据计划，特别是如果它可以通过蜂窝网络这样做。电池是一种化学物质，通过一系列持续的化学反应来储存和发电。如果你经常使用它，它会开始变热。如果你经常使用它，那就会改变它的行为。因此，您必须在测试设计期间考虑功耗和电池行为。使用您的应用程序并为您的设备充电也会产生巨大的热量，甚至可能会烧坏电池调制解调器。但是，应用程序可以控制情况，根据阈值关闭应用程序，并根据已知的安全温度值再次启动应用程序。例如，如果温度过高，iPhone将在屏幕上显示错误消息，
关闭所有应用程序。但是，如果在操作系统的帮助下将阈值内置到应用程序中，应用程序可以避免这种情况。危险温度大于80摄氏度，而更安全的温度范围是55摄氏度至60摄氏度[阈值]。同样，提前获得这些知识可以帮助减轻灾难。
如果你在整天插在墙上的设备上测试你的应用程序，这是不现实的;它不仅在功率方面不切实际，而且在设备位置方面也是如此。真正的设备会被移动。这意味着设备 - 因此您的应用程序 - 必须处理信号强度变化。更改位置也会影响设备的温度，这会影响您的应用。例如，如果您的应用程序在很多地方之外使用，设备可能会变热，这会影响设备性能，甚至可能导致设备关闭。如果您的应用消耗大量电力，这将加剧，因为这会使设备变热。

有关操作系统和应用程序架构的技术细节也会影响您设计测试的方式。
测试人员需要与应用程序的开发人员密切合作，并询问有关系统集成的相互依赖性的问题。如果测试人员可以阅读代码并了解他们的应用程序正在执行的操作，那么这也非常有用。 阅读日志文件有助于了解应用程序实际执行的操作。
测试人员应该观看应用程序并查看日志文件并进行比较。

在您的研究中，请特别注意受影响的应用或应用使用的受支持设备的各个方面。这包括屏幕尺寸，屏幕分率，GPS，磁力计，电话子系统，陀螺仪，加速度计和支持设备可能包含的任何其他传感器等功能。尽可能多地收集有关设备功能的信息，以支持不同的受支持设备。

不要认为相同的设备功能在两个不同的设备上以相同的方式工作。例如，如果您的应用使用GPS，则GPS功能在Android手机和Apple手机上的工作方式可能不同。

安装，重新安装，升级和卸载通常序号彻底测试，这些安装过程的稳健性甚至比标准PC应用程序更为关键，因为在此过程中可能会出现各种中断，通知，连接状态更改以及后台甚至前台活动。

此外，请考虑支付相关行为与这些安装状态流程的交集，包括从赞助模式到付费模式的更改，反之亦然（如果允许）。如果订阅付款模型的到期或取消需要触发安装状态更改，则这尤其危险。

最后，让我提一下非功能性测试。在服务器端组件负载很重的情况下测试应用程序的功能行为是一件明智的事情，因为连接超时和数据更新延迟会影响功能行为。

将测试技术应用于测试设计在测试设计期间，请记住使用基础测试技术，甚至可能使用高级测试技术。目前，我们可以专注于基础技术：

• 等价划分是一项重要的技术，几乎适用于所有测试环境，也适用于其他技术的构建块，如决策表和成对测试。使用等价划分的一个示例是识别不同的支持设备。

• 边界值分析是等价分区的扩展。

• 有序等价分区是这样一种分区，当分区的两个成员不相同时，一个成员大于另一个成员。

• 边界值可以影响功能和非功能行为，例如测试在线扑克游戏中的最小和最大玩家数量。

• 在测试影响应用程序应该和不应该执行的操作的条件组合时，决策表非常有用，尤其是对于快速发生的事务。例如，如果您要支付申请费用，可能有不同的付款方式，例如信用卡，借记卡，Paypal，支付宝等。这些条件以及诸如邮政编码和PIN信息之类的相关条件可以相互作用以确定支付行为的工作方式。

• 当系统的行为取决于过去发生的事情以及相关条件在过程中可能发生变化时，基于状态的测试非常有用。例如，应用程序行为通常会根据连接的类型，速度和状态而更改，并且对连接的更改可能会更改系统在进程中的行为方式。

• 用例是描述正常，异常和错误处理方案的有用方法。例如，考虑视频服务。我们可以做一些事情，比如查看我们的视频队列，添加到队列，从队列中删除，重新排序队列，等等。

• 探索性测试是将创造力和灵活性应用于测试任务的好方法。当事件序列和条件组合难以预测或受到许多变化时，它尤其有用。例如，您可以使用探索性测试来查看在使用应用程序时可能发生的外部中断等事情，以及应用程序是否以合理的方式处理这些内容。

• 错误猜测：最初由Glenford Myers描述的错误猜测的概念后来被James Whittaker详细描述为软件攻击的概念。 8攻击的一个例子是尝试根据路由器安全性可能较弱的假设来拦截来自路由器的Wi-Fi信息。

• 基于缺陷的测试类似于错误猜测，但它基于过去存在的缺陷而不是您怀疑可能存在的缺陷。例如，如果您保留了在应用程序或类似应用程序中看到的缺陷列表，或者您在类似应用程序中听到或读过的缺陷列表，则可以设计可能会暴露此类缺陷的测试。

• 最后，在考虑条件，配置选项等时，考虑组合测试和分类树等组合技术，这些条件，配置选项等应该是独立的，但可能会以意想不到的方式进行交互。例如，如果风险足够高，您可能决定使用成对测试来查找连接类型，连接设置和通信功能之间的交互。

用户观点和场景与用例类似，但它们涉及额外的细节，例如用户技能，用户位置，照明，天气，连接类型和强度，附件和外围设备以及设备运动。

当您掌握用户技能时，如果愿意，可以将其提升到另一个级别，并使用所谓的用户角色测试。用户角色涉及尝试将自己置于用户的脑海中。由于移动应用程序用户群可能非常庞大且多样化，因此能够以不同用户的方式查看应用程序非常重要。记得，每个用户在某些方面都是独一无二的，但角色测试包括关注用户与您的应用互动的方式，您可以对其进行分区以识别应用和移动设备互动的相关风格，接近应用的方式，情感状态和意图使用应用程序，等等。

例如，考虑对您的应用一无所知的首次使用者如何使用它。考虑一个偶然的用户，偶尔使用你的应用程序的人，不时会使用它。频繁用户如何使用您的应用？专家？一个人对您的应用程序或移动设备使用情况感到困惑，这与受到威胁的用户类似，但有点不同？一个生气或同样不耐烦的用户怎么样？如果恶意用户试图渗透您的应用并最终侵入您的服务器呢？那些正在评估您的应用程序以进行审核或考虑使用它的人呢？拥有强大技术技能的用户怎么样？年轻用户怎么样？老用户？

同样，如果您正在创建一个您期望的应用程序 - 或者已经拥有 - 一个非常多样化的用户群，那么角色测试对您来说非常有用。如果您有良好的可用性要求，那么确定相关的用户角色以及受欢迎和不受欢迎的用户将更容易，但这是一种罕见的奢侈品。我们稍后会回到这个主题。

最后，为您的应用程序开发和使用重要测试条件的清单是一种经过验证的最佳实践，可以帮助您避免忘记每个版本中的重要测试条件。检查清单应包括主要功能，不同连接类型和速度的效果，以及任何不同的设置或配置选项。您最初可以使用等价分区和边界值分析等技术创建这些清单。随着时间的推移，随着您的应用程序的发展，检查表应随之发展。

头脑风暴是一种用于识别测试条件，设计测试和改进测试条件的协作技术。

1.第一步是确定您计划如何捕获在TestStorming会话期间收集的信息。这可以是思维导图的形式，白板，活动挂图或电子表格。

2.第二步是确定会议的范围。这涉及设置一些时间限制和一组合理的功能来考虑。毕竟，您和您的同事可能无法在一次会话中进行所有测试分析和设计。

3.这是第三步，它侧重于较大测试问题的某些子集，特别是您认为最重要的质量特征。

第四步是指派一名协调人，一位会议负责人。理想情况下，此人具有测试经验和促进经验，以及对移动应用程序的预期行为的深入了解。

这使我们进入第五步，邀请不同的参与者。正如头脑风暴会议中的典型情况一样，您需要一个跨职能的团队，就像参与前面描述的风险分析过程的利益相关者团队一样（第38页）。在此背景下，这意味着开发人员，测试人员和业务利益相关者。现在，理想情况下，我们希望团队中的每个人都具有创造力，注重细节，礼貌和知识渊博。所需知识包括预期的应用程序使用，组织目标和测试，以及应用程序的使用方式。这问了很多参与者。更现实的是，瞄准一个团队，每个人都有创造力，参与，愿意参与，并能够提供一些有用的意见。

6.第六步是会话本身。首先回顾风险，要求，以前发现的缺陷以及其他相关背景信息。完成此审核后，您要求每位参与者确定他们的前五个测试条件。这些可能与审查中涉及的项目有关，也可能是全新的想法。毕竟，这是头脑风暴。

7.第七步是优化测试条件列表。这涉及识别和解决重叠。它涉及组合条件，这些条件基本上是彼此重新陈述，保持措辞最佳或抛光措辞以结合两者的优点。它还涉及将有用的副产品（如项目风险和需求缺陷）重定向到适当的人员。分类测试条件可以帮助这个过程
。
8.第八步是审查。这涉及到参与者决定测试的测试条件，并且暂时有效地包装了该过程的头脑风暴部分。

9.第九步是测试人员采用这组测试条件并创建测试用例。您可能无法为所有条件创建实际测试用例。如果您打算使用探索性测试，您可能只是围绕某些条件包装测试章程。无论哪种方式，对于每种情况，您必须确定相关的测试神谕。请记住，测试神谕是您咨询的内容，用于评估测试结果是正确还是不正确。对于每种情况，您还必须确定适当的覆盖深度。

10.步骤10是运行测试并记录结果，结果像往常一样进行测试执行。

11.最后，步骤11涉及确定是否存在特别有用的某些测试。如果是这样，您可以捕获它们以便重复使用。

TestStorming的价值就像您合作的任何其他流程一样;团队，总的来说，有相关的知识和经验，可以帮助您避免遗漏任何东西。如果您能让利益相关者审查您作为测试人员创建的测试条件，您是否可以在没有实际头脑风暴会议的情况下获得许多相同的好处？是的，可能是这样，但头脑风暴在避免差距和建立共识方面更为强大。

比如以下是我认为机票订购的前五个测试条件。账户安全；快速获取准确的航班状态信息；旅行管理功能比如是否提供饭；流媒体视频娱乐。；付款信息，我的护照信息和其他个人识别信息安全存储。

非功能测试

关注

• 性能;
• 可用性;
• 移植性;
• 可靠性。

软件的可维护性方面最好通过静态测试技术来解决，例如评论和静态代码分析，所以不列在这里。

性能测试性能测试涉及响应时间，资源利用率和吞吐量。资源利用涉及在特定负载水平下查看资源消耗。您检查的特定资源将取决于您预计会发生瓶颈的位置。通常，它们包括CPU利用率，内存利用率，磁盘利用率，磁盘带宽利用率，网络带宽利用率等。

另外还有负载测试、压力测试、可伸缩性测试等。

在移动设备上，由于内存耗尽导致的应用程序崩溃很容易且经常发生。
瓶颈也可以在连接上。例如，如果系统的设计假设客户端和服务器端之间始终存在大而宽的数据管道，就像通常在办公室或工厂中运行的PC客户端 - 服务器应用程序一样，那就是对于依赖移动连接的系统而言，这不是一个特别明智的设计决策。
当您从客户端查看应用程序本身时，有许多问题需要询问其性能。如果应用程序尚未运行，它需要多长时间才能启动？当人们做其他事情时，有延迟吗？应用程序有时会很快，有时会很慢吗？

如果应用程序正在执行某些操作且用户必须等待，是否会让用户发布其状态？我个人更喜欢进度条，前提是进度更新频繁且准确。然而，像小旋转轮一样令人沮丧，至少你知道发生了什么事。如果你点击某些东西并且应用程序就在那里，那总是让我想知道，“嗯，我是否点击了那个图标？应用程序是否意识到我点击了图标？“这通常会让我开始一遍又一遍地点击。
您还应该考虑资源使用情况，例如CPU，内存，网络带宽等，正如我所提到的那样。请记住，您的应用程序正在移动设备上运行，并与许多其他应用程序共享内存和带宽，电池电量和CPU利用率以及所有其他资源。要测试这一点，您需要找出其他应用程序的典型组合，以及它们通常会做什么。背景加载的这一方面在客户端是关键的，因为资源是如此有限。

要考虑的另一个问题是完成各种工作需要多长时间才能完成某些用例 - 以及这对人们是否会令人沮丧。性能对可用性有影响。
不要忘记考虑客户端代码效率，即看待性能的白盒方式。理想情况下，您的技术足以参与代码审查并查看这些问题。

尝试查看竞争应用。你很可能有一些竞争对手，所以下载它们并对它们进行基准测试。您还可以对不竞争但正在执行类似操作的应用程序的性能进行基准测试。对目标用户使用的其他应用程序的性能进行基准测试。如果您要升级现有的应用程序，显然您不希望它变慢。所有这些都是绩效目标的良好来源。

不要将性能测试留到项目结束或发布。系统构建时的性能测试。我们常常看到的是，组织要等到发布之前才进行性能测试，然后性能结果不是很好。在最糟糕的情况下 - 这是令人惊讶的频繁 - 这些人发现调整是不够的。他们实际上必须对系统进行重大的重新设计，这非常昂贵并且对发布计划非常具有破坏性。

记得在测试实验室中安装便宜的旧设备;不要只用最快和最新的东西来测试。

保持高水平并概述性能测试方法。不要试图编写完整的性能测试计划。

可用性、简单性、学习曲线等都需要考虑。

必须尽可能多地了解其支持的平台（包括硬件）的另一个原因，固件，操作系统功能和限制。

恢复是指所有应用程序再次启动和运行所需的时间，以及能够在崩溃之前执行的操作。

与性能测试类似，可靠性测试具有客户端元素和服务器端元素。对于服务器端元素，例如故障频率，故障恢复速度以及能力容忍不利的外部事件。 对于客户端元素，您需要考虑应用程序的可靠性以响应潜在的破坏性事件。例如，当您的应用通过Wi-Fi或蓝牙连接时，当连接断开，重新连接或以其他方式更改时，您的应用如何响应？同样，检查电池和充电状态变化会发生什么变化，例如让电池变得非常，非常低，还是经常连接和断开充电器？如果设备过热怎么办？如果硬件传感器或外围设备出现故例如，如果我在应用程序中输入内容时关闭蓝牙键盘，它不会导致应用程序崩溃，应用程序也不应无限期挂起，直到键盘返回。相反，应用程序应无缝恢复到软键盘，如果蓝牙键盘重新连接，它应无缝切换回外部键盘。

共享资源的稀缺性是可靠性挑战的另一个来源。您的存储，内存和CPU资源有限。此外，您可能遇到内存泄漏意味着可用内存比应有的更少的情况。使您的应用程序更加困难的是，您通常拥有许多同居应用程序，其中一些应用程序在后台无形运行。当内存耗尽或网络带宽占用背景应用消耗大量且可能不同数量的这些资源时，您的应用会发生什么？
尽管有一个奇怪的名字，“monkey”是可靠性测试的有用工具。可用性不仅包括测量失败之间的平均时间，还包括平均修复时间。

另外还有在不支持的设备等情况的错误消息。

习题

某在线购物的应用程序支付接口支持支付宝、云闪付、苏宁支付。需要同时测试有效和无效的等价分区，那么理论上测试的最少数量是多少？

A.3
B.6
C.7
D.10

测试应用程序正确性的要检查以下哪两个属性？

Ａ 响应时间。
B 适用性。
C 安全性。
D 互操作性。
E 准确性。