Guide to Symbian Signed Testing zh-hans
文章信息
本文是对Symbian Signed才的是的深入介绍。我们并不期望使用Symbian Signed的每个人都应阅读本文，但如果你对自己的应用如何受某个特定测试的影响有疑问，它确实是一种有益参考。
我们也鼓励开发伙伴、测试员和其他对Symbian Signed测试过程有兴趣的人士向本指南积极贡献。请根据自己对测试标准v4.0.14的体验对本文作更新。我们Symbian将把来自测试机构的意见及国际反馈整理到本文档中。
Contents |
Symbian Signed测试指南总则
测试标准针对谁？
提交Symbian Signed的所有应用，不管是通过特快签名还是认证签名，都必须符合Symbian Signed测试标准。
提交应用之前要做什么？
如果这时你第一次使用Symbian Signed，那么你就可以查阅我们的文章，它向你提供Symbian Signed测试十大诀窍，使您不致通不过测试。
在提交应用做特快签名或认证签名之前，你应该先根据测试标准进行检查。如果你发现任何问题，请联络Symbian的Symbian Signed团队对其进行探讨后才提交。某些应用会要求免测项，其他应用则会要求Symbian提供一些帮助，以便通过测试，而且，在你提交前向你提供帮助比起当你的应用不能通过测试后才提供这种帮助对我们来说更为方便。
提交检查
T提交检查在对你的应用进行测试前开展。如你不能通过这些检查项中的任何一项，你的应用就不会被测试机构测试，应用将被退回，状态标为"failed"，也不会被签名。
检查 1
每项提交都必须通过这项测试。
门户网站会检查你的提交是否被一个Publisher ID所签名。
测试期间测试机构会验证所使用的Publisher ID是提交者所有。
本项检查不接受免测；如果你没有用你所拥有的Publisher ID对你的提交进行签名，你将无法通过本项检查。
如果Express Signed（特快签名）审查无法通过这项测试用例，那么就会自动发起针对你的帐户的动作。
检查 2
你一定要给自己的应用赋予一个保护域中的UID，它被分派到你正用于提交的帐户中。
如果你做不到这一点，那么你就应该联系Symbian的Symbian Signed团队(symbiansigned@symbian.org) 探讨如何做。
一般情况下，本项检查不接受免测。
检查 3
本项检查只是要确保提交者已经提交了所有的信息。运行这项检查时，测试机构将确信你已经完成了针对那些受限Capabilities的陈述性声明，而且你也提供了一个readme.txt文件，其中含有所有与自己的提交相关的信息。
测试1 –安装
测试指引
大多数应用都容易通过这项测试。大部分应用使用通用的系统安装程序进行安装，安装后会在应用菜单中出现一个图标。某些应用将其图标放到应用菜单下的文件夹中，因此，如果在通常位置没有找到图标，请检查一些新文件夹。某个应用的图标如果出现在某个子文件夹中并不会影响其通过本项测试，尽管这种作法会使手机显得有些杂乱，因此并不建议大家这么做。
如果应用在安装后并不以通常方式出现一个图标，那么开发者就应该随提交的应用提供额外信息，解释测试机构应如何检查应用已被安装。如果开发者没有提供这类信息，这时测试者会联络开发者，向其讯问相关信息。如果开发者不能提供这类信息，那么本测试将不获通过。
一旦开发者向测试机构提供了所需信息，测试继续
如果找不到针对该应用的图标，而开发者也没有提供如何验证安装成功的任何信息，那么本测试将不获通过。
比较版本号时，应该使用某些通用的意识。8.0.1(514)被认为非常接近8.0.1 或8,0,1 或 8.0.1，因而能通过本测试。这一步不获通过的唯一原因就是版本号在意义上存在明显差异。
对开发者的建议
如上所述，大部分应用都以通常方式安装。事实上，作为一位开发者，你有时需要针对自己的应用有意识地改变这种方式。
如果你改变了自己应用的安装方式，那么，你就需要随你的提交明白无误地指出这点，让测试机构无需联络你以获取更进一步信息。
如果你的应用图标不在正常位置，那么应该在你的readme.txt文件中指出何处可以找到这个图标。如果你的应用并不出现任何图标，那么你需要详细说明如何确认应用被成功安装了。
免测
针对本测试的唯一可接受免测是：如果某个应用被设计成对某款终端的预装，这点应该在提交免测申请使明确指明。
并无其他针对本测试的免测项目。
测试2 – 应用启动/终止行为
本测试项确保用户可以控制应用在终端的是否运行。关闭应用有两种方法：在应用内部使用“退出”或类似操作，或从系统的任务管理器。本测试同时检查关闭应用的这两种方法。
测试指引
你应该已经从测试1中注意到在哪里找到图标以启动正在测试的应用。此后的测试将非常直观。
某些应用不会出现在任务管理器中，因而测试机构必须作一些判断，以便确定这种行为是否为应用必需。如果应用并未出现在任务管理器中，那么开发者必须在提交过程中对此作出解释，任何应用如果未出现在任务管理器中又无解释，将不会通过本项测试。
测试机构会阅读开发者的辩解理由。如果有正当理由可以解释应用不出现在任务管理器中，那么就可以接受。某些装饰性理由不足以形成辩解。
但是，应用还是应该提供某种方法，当应用不出现在任务管理器中时还是能让用户退出。可以将退出功能提供为应用用户界面的一部分，或出现在终端的其它地方，但并非人人都认识到，开发者此后应该在提交期间对这一点作出解释。
任何应用如果不能由用户关闭就应要求一个免测，如下所述。
对开发者的建议
一般说来，并无理由让自己的应用不被任务管理器终止，也无理由不让其出现在任务管理器中。
如果有正当的理由不让自己的应用出现在任务管理器中，那么你要随提交解释这种理由。
如果你的应用出现在了任务管理器中，用户就必须能在那里终止该它。如果你的应用出现在了任务管理器中但却不能被终止，你就需要申请一个免测向，然后再提交。
免测
没有“退出”选项的那些应用，或完全不能由用户终止的那些应用将申请一个免测项。这个免测请求应解释这种作法的理由，并需提供技术上的辩解意见。
测试3 - 应用认证
这一步骤的测试验证开发者是否随其提交提供了正确的信息。
测试指引
本测试具有一个主观性元素。针对此测试存在两个元素。
首先，两个测试项中简单的那项将检查终端上的应用名是否符合开发者在提交时所提供的名字。两个名字必须紧密相配。例如，如果应用以名字"Ph Mgr"提交，而在终端上则被称为"Phone Manager"，这可接受。如果在提交时它被称为"Weather Report"而在手机上被称为"Phone Manager"，这就不能被接受。
本测试的第二部分确定开发者已经在提交时精确说明了应用的功能。我们并不期望开发者在提交时对其应用编写冗长的说明，但是我们希望他们能用一到两句话来对应用做一个概括。
当检查该说明是否正确无误时，测试机构将采用一种使用的方法。例如，如果开发者提交时说“本应用显示你所在地区的最新天气预报”，那么你就要检查该应用是否真的显示天气预报，该应用也许有其它功能，但是只要开发者精确地说明了其主要功能，那么这项测试就通过了。
本项测试的意义在于发现开发者所说明的东西有误导成分。
无说明或误导性说明将导致测试不获通过。
对开发者的建议
本项测试对开发者应该不存在问题。当你提交时，你只要准确地给出你的应用得名字和说明。
说明应该简短，描述你的应用的主要功能。你无需提供对所有功能的描述，只要一两句话，简要描述你的应用做些什么。你所提供的描述只针对Symbian和测试机构，因而无理由不提供这些信息。
免测
本项测试不接受免测。
测试4 – 不会破坏语音通话s
电话通话是每一台移动电话的重要功能，本测试验证应哟功能不会让用户无法打出或接听电话。
测试指引
语音通话的测试必须与应用的“安装及运行”一起执行。有必要考虑这里所指的“运行”的意义。
对于那些使用了MultimediaDD capability的应用，重要的是检查应用所拥有的任何音频流功能并不干扰语音通话的音频信号。因此，当运行此项测试时，你应该确保：如果应用具有音频流功能，那么当你执行本测试时它在实际上却是流起来了。
对于其它的应用，你需要确保最可能干扰语音通话的功能当下正在应用中执行。例如，如果应用播放视频，那么你应该在进行本测试时使用该项功能。
VoIP应用在进行本项测试时须加特别注意，但这在Symbian Signed针对VoIP应用的测试章节中讲述。
对“来电必须提示”作何解释？
测试紧急电话
我们不能期望开发者为通过此项测试而去拨打紧急电话，因而可以接受不经此项测试就提交你的应用，只要你已测试过：你的应用不会阻止非紧急电话的拨出。
然而，作为特快签名审查或认证签名测试中的一部分，测试机构会测试这项功能，因此你的应用不应阻止紧急电话的拨出。
对开发者的建议
本项测试的重要一点是事先掌握你的应用是否需要免测。如果你的应用被设计成会干扰语音通话，例如，放置家长锁规定拨叫号码的应用，那么你就需要申请免测才能通过本测试。
你的应用不会在任何方面对语音通话形成干扰，这一点也很重要。例如，你应检查：你是否做过什么从而阻止了语音形式或视觉形式的来电提示。
免测
所有会干扰语音通话的应用都需要申请免除本测试。如今，通过特快签名提交的应用可被接受免测，但是需要你事先提出免测请求。为争取免测申请得到批准，你需要解释应用以何种方式形成对语音通话的干扰，并以你的应用功能场景作为佐证。
例如，如果你的应用是针对终端的家长锁定应用，那么你需要在免测申请中对此加以说明。
免测将给予那些被认为是可以这么做的给定应用。但是，举例来说，使一个游戏阻止用户打出电话的免测申请将不会被接受。
测试5 – 不会破坏消息功能
文本消息已成为手机中的重要功能。因此，本测试要确保应用不会不必要地限制用户收发文本消息的能力。
测试指引
本测试在许多方面都类似于测试4，都测试对语音通话的干扰（或不能进行语音呼叫）。
应用的执行应该有意识地让该功能运行于可能干扰文本消息的应用内部。
对开发者的建议
如果你的应用完全不会与消息收发功能交互，那么你的应用将很容易通过本测试。
I如果你的应用确实改变了用户收发文本消息的方式，那么你必须在提交时提及这一点。如果你不预先提示任何会影响文本消息或未告知用户而影响文本消息收发的行为，你将不会通过本测试。
免测
同样，本测试许多方面类同于测试4。如果你的应用在设计上会对文本消息产生干扰，那么你必须作出声明，为这种行为请求免测。
自启动行为
某些应用被设计成随手机启动而自动启动。本测试将检查：这么做的那些应用是否经过了足够的检查以确保其自启动行为不会威胁到用户，也不会威胁到手机。
测试指引
本测试部分内容涉及到了解应用是否随终端启动而自启。如果应用并不随终端启动而自启，那么本测试不适用。因此首先要做的事情就是检查应用是否被设计成随终端启动而自启。
你还需确定用户能关闭自启选项，而且当关闭时，应用就不会在系统启动时随之自启。
你可以参考测试2中对应用运行情况的检查，了解其在启动后是否正常运行。
不要忘记，系统启动后需要一小段时间应用才会启动。
任何不向用户提供关闭自启动选项的应用都不能通过本测试。
对开发者的建议
如果你并未使用自启动功能，那么你的应用无需通过此项测试。绝大多数的应用都不应该随手机启动而自启。仅当你的应用要向用户提供其希望总是存在的某项服务时你才应该去实现这种自启功能。
如果你正在编写一个游戏或一个通用工具，那么你就不应该去实现自启功能，你也无需担心本项测试。
如果你确实需要事先自启功能，那么你就必须向用户提供能关闭该项功能的方法。你可以在你的应用的设置对话框中提供这种方法。
免测
任何随手机起动而自启及不向用户提供方法以关闭该功能的应用需要申请本项免测。免测只授予例外情形，因为一般情况下没有理由不让用户有机会禁止该应用的自动运行。
测试7 – 不会破坏一些重要的终端应用
用户数据很重要，因此终端上的任何应用都不能在用户不知晓的情况下改变用户数据。本测试试图确定对终端上用户数据的唯一改变就是那些用户知晓的。
测试指引
本项测试的第一步是给终端提供一些数据。你可以手工进行，但保持一个数据集并将其通过蓝牙传送给终端可能更容易（或用其它一些方法将数据送到终端），然后才开始测试。
我们并不规定终端需要的确切数据集，因为我们并不希望将本测试限制为，如仅仅一定数量的联系人记录。
你一旦开始这些测试用例，请不要删除数据，因为在以后的测试中还用得着。
本测试用例中有一个主观性元素，因为某些应用确实将改变用户数据作为其关键功能的一部分。在这种情况下，测试机构需要确保只有应用所制定的数据被改变了。关键是，对用户数据的任何改变必须是用户能控制的，同时也是其所知晓的。
对开发者的建议
通过本测试的关键是：确保在对用户数据作任何改变前提示用户。如果你的应用的关键功能是要修改用户数据，那么就请确定你在改变数据前提示了用户，以给予他们取消这种改变的机会。
如果你的应用设计并不试图改变用户数据，那么你就不必这么做。例如，一个游戏不应该去改变任何名片夹信息，而一个Twitter客户端也不应该去删除日历项。
免测
只在非常特殊的情况下才会接受免测申请。你应联络Symbian后才提出本测试的免除请求，因为极少免测申请会被接受。
测试8 – 卸载
用户能删除应用中其不希望继续存在的任何应用，这一点很重要。本测试要确定用户能够完全删除应用。
测试指引s
本测试共有三个步骤，其中第一个步骤无需说明，测试中不应有问题。
这最后一项测试中具有某些目标性。一般说来，应用卸载后不应留下超过10k的数据。测试中唯一允许的例外是应用户请求下载内容的应用。例如，我们不必指望某个从音乐店铺下载mp3文件的应用去删除所有已下载的音乐。
关键的是，用户必须知晓留下了什么东西。本测试说明用户生成的内容和下载的内容，因此卸载后留下的超过10k的任何东西要么必须是用户创建的，要么是用户下有意载的，且必须在readme.txt中说明过。如果数据对用户为未知，也未在readme.txt中说明，那么本测试不获通过。
对开发者的建议
正如其它某些测试，通过本测试的关键是告知用户。当应用被卸载时，你可以考虑向用户提供一个提示，解释什么会被删除，而什么不会，让他们可以选择删除所有内容，如果他们希望的话。
你也需要保证你提供了有关卸载后留下些什么的信息。在readme.txt文件中，你应该就应用卸载后留下的全部数据作一简明介绍。
有时候，你也许希望对自己应用的卸载进行保护，因而用户不能移除该应用。如果你这么做，那么你不但需要就为何限制卸载提供理据，而且必须向测试机构解释如何卸载。你可以通过使用PIN码来解除，如此这般。
免测
一般情况下，不会接受免测请求。
测试9 – 终端适配
基于同样的底层Symbian平台能开发出不同的终端，重要的是：为该平台设计的任何应用都在一定范围的终端上进行检测。本测试被设计为确保已对该应用面向一系列的终端进行了基本的检测。
测试指引
如测试机构，你首先要做的就是参考终端列表，看看你需要在哪些终端上进行测试。终端列表位于 Symbian Signed Device Table (for v4 of test criteria)。
提交时开发者应已选择了一款主终端，你无需在那款主终端上运行测试9的所有内容，因为大部分测试都已在其它用例中涉及。如果主终端支持多屏幕模式（例如，竖向显示模式和横向显示模式），那么你就应该在那台主终端上运行测试9中的第4步。
做完之后，你应该查阅终端列表，看看还有哪些代表性终端需要你继续测试。
测试时的关键一点是：请记住，我们的目的不是去裁定应用的图形显示品质。只要一些关键功能（退出、帮助等）能够使用及读取，那么该应用就不会因一个细微的图形问题而通不过本项测试。
当应用用户界面旋转时让其保持一个方向是可接受的，且能通过本测试。
对开发者的建议
通过本测试的第一步是为你自己获取正确的平台UIDs。这似乎是一项麻烦工作，但你却仅需为自己的应用一次性地这些事情，因此值得花些时间以确保它们的正确无误。你应该在打包文件中包括你的应用将运行其上的那些平台的UIDs。如果你的应用被设计成只运行于一款特定手机，那么指定那款手机的产品UID就可以了。
代表性终端表已被简化请于 Symbian Signed Device Table (for v4 of test criteria) 查阅。
许多厂商提供远程测试解决方案，让你能在他们的终端上测试自己的应用，即使你没有在物理上访问该手机。
当终端旋转时，如果你的应用必须保持一个显示方向，那么你可以自由地如此实现之，仍然能通过本测试。
免测
VoIP应用测试
什么是VoIP应用？
根据本测试的目的，我们将VoIP应用定义为允许用户使用3G, GPRS 或WiFi连接并使用了MultimediaDD 或NetworkCotrol capability（或两者）从应用内部与另一用户进行通话的任何应用。
测试10
本测试将确定：当VoIP应用正使用中时还是能拨打紧急电话。必须测试的场景有多种，因为VoIP应用会以多种方式对紧急电话形成潜在干扰。与测试4中的紧急电话不同，在那里，如果测试机构因设备原因无法对此进行测试就可以跳过这项测试，本测试对VoIP应用为必测，而测试机构则必须拥有装备以成功运行此项测试。
Note that this content was originally hosted on the Symbian Foundation developer wiki.
(no comments yet)