typedef用法
为typedef int size即可。
使用typedef为现有类型创建别名，定义易于记忆的类型名，typedef 还可以掩饰复合类型，如指针和数组。数据类型包括内部数据类型（int,char等）和自定义的数据类型（struct等）。
在编程中使用typedef目的有两个，一个是给变量一个易记且意义明确的新名字，另一个是简化一些比较复杂的类型声明。符合范围规则，使用typedef定义的变量类型其作用范围限制在所定义的函数或者文件内（取决于此变量定义的位置），而宏定义则没有这种特性。-typedef
扩展资料：
typedef的相关内容：
1、标准调用约定的函数在它们返回到调用者之前，都会从堆栈中移除掉参数，为Pascal的标准约定。
2、在C/C++中，调用约定是调用者负责清理堆栈，而不是被调用函数；为强制函数使用C/C++调用约定，可使用__cdecl。另外，可变参数函数也使用C/C++调用约定。
3、Windows操作系统采用了标准调用约定（Pascal约定），因为其可减小代码的体积。这点对早期的Windows来说非常重要，因为那时它运行在只有640KB内存的电脑上。
参考资料来源：百度百科-typedef
Android是如何使用AndroidManifest.xml的
一、关于AndroidManifest.xml
AndroidManifest.xml 是每个android程序中必须的文件。它位于整个项目的根目录，描述了package中暴露的组件（activities, services, 等等），他们各自的实现类，各种能被处理的数据和启动位置。 除了能声明程序中的Activities, ContentProviders, Services, 和Intent Receivers,还能指定permissions和instrumentation（安全控制和测试）-f
二、AndroidManifest.xml结构
《?xmlversion=“1.0“encoding=“utf-8“?》《manifest》 《application》 《activity》 《intent-filter》 《action/》 《category/》 《/intent-filter》 《/activity》 《activity-alias》 《intent-filter》《/intent-filter》 《meta-data/》 《/activity-alias》 《service》 《intent-filter》《/intent-filter》 《meta-data/》 《/service》 《receiver》 《intent-filter》《/intent-filter》 《meta-data/》 《/receiver》 《provider》 《grant-uri-permission/》 《meta-data/》 《/provider》 《uses-library/》 《/application》 《uses-permission/》 《permission/》 《permission-tree/》 《permission-group/》 《instrumentation/》 《uses-sdk/》 《uses-configuration/》 《uses-feature/》 《supports-screens/》《/manifest》
三、各个节点的详细介绍
上面就是整个am(androidManifest).xml的结构，下面以外向内开始阐述～～
1、第一层(《Manifest》):(属性)
《manifest xmlns:android=“ package=“com.woody.test“ android:sharedUserId=“string“ android:sharedUserLabel=“string resource“ android:versionCode=“integer“ android:versionName=“string“ android:installLocation=[“auto“ | “internalOnly“ | “preferExternal“] 》《/manifest》-typedef
A、xmlns:android
定义android命名空间，一般为
B、package
指定本应用内java主程序包的包名，它也是一个应用进程的默认名称
C、sharedUserId
表明数据权限，因为默认情况下，Android给每个APK分配一个唯一的UserID，所以是默认禁止不同APK访问共享数据的。若要共享数据，第一可以采用Share Preference方法，第二种就可以采用sharedUserId了，将不同APK的sharedUserId都设为一样，则这些APK之间就可以互相共享数据了。详见：E、versionCode-f
是给设备程序识别版本(升级)用的必须是一个interger值代表app更新过多少次，比如第一版一般为1，之后若要更新版本就设置为2，3等等。。。
F、versionName
这个名称是给用户看的，你可以将你的APP版本号设置为1.1版，后续更新版本设置为1.2、2.0版本等等。。。
G、installLocation
安装参数，是Android2.2中的一个新特性，installLocation有三个值可以选择：internalOnly、auto、preferExternal
选择preferExternal,系统会优先考虑将APK安装到SD卡上(当然最终用户可以选择为内部ROM存储上，如果SD存储已满，也会安装到内部存储上)
选择auto，系统将会根据存储空间自己去适应
选择internalOnly是指必须安装到内部才能运行
(注：需要进行后台类监控的APP最好安装在内部，而一些较大的游戏APP最好安装在SD卡上。现默认为安装在内部，如果把APP安装在SD卡上，首先得设置你的level为8，并且要配置android:installLocation这个参数的属性为preferExternal)-typedef
2、第二层(《Application》):属性
一个AndroidManifest.xml中必须含有一个Application标签，这个标签声明了每一个应用程序的组件及其属性(如icon,label,permission等)
《application android:allowClearUserData=[“true“ | “false“] android:allowTaskReparenting=[“true“ | “false“] android:backupAgent=“string“ android:debuggable=[“true“ | “false“] android:description=“string resource“ android:enabled=[“true“ | “false“] android:hasCode=[“true“ | “false“] android:icon=“drawable resource“ android:killAfterRestore=[“true“ | “false“] android:label=“string resource“ android:manageSpaceActivity=“string“ android:name=“string“ android:permission=“string“ android:persistent=[“true“ | “false“] android:process=“string“ android:restoreAnyVersion=[“true“ | “false“] android:taskAffinity=“string“ android:theme=“resource or theme“ 》《/application》-f
A、android:allowClearUserData(’true’ or ’false’)
用户是否能选择自行清除数据，默认为true，程序管理器包含一个选择允许用户清除数据。当为true时，用户可自己清理用户数据，反之亦然
B、android:allowTaskReparenting(’true’ or ’false’)
是否允许activity更换从属的任务，比如从短信息任务切换到浏览器任务
C、android:backupAgent
这也是Android2.2中的一个新特性，设置该APP的备份，属性值应该是一个完整的类名，如com.project.TestCase，此属性并没有默认值，并且类名必须得指定(就是个备份工具，将数据备份到云端的操作)-typedef
D、android:debuggable
这个从字面上就可以看出是什么作用的，当设置为true时，表明该APP在手机上可以被调试。默认为false,在false的情况下调试该APP，就会报以下错误：
Device XXX requires that applications explicitely declare themselves as debuggable in their manifest.-f
Application XXX does not have the attribute ’debuggable’ set to TRUE in its manifest and cannot be debugged.-typedef
E、android:description/android:label
此两个属性都是为许可提供的，均为字符串资源，当用户去看许可列表(android:label)或者某个许可的详细信息(android:description)时，这些字符串资源就可以显示给用户。label应当尽量简短，之需要告知用户该许可是在保护什么功能就行。而description可以用于具体描述获取该许可的程序可以做哪些事情，实际上让用户可以知道如果他们同意程序获取该权限的话，该程序可以做什么。我们通常用两句话来描述许可，第一句描述该许可，第二句警告用户如果批准该权限会可能有什么不好的事情发生-f
F、android:enabled
Android系统是否能够实例化该应用程序的组件，如果为true，每个组件的enabled属性决定那个组件是否可以被 enabled。如果为false，它覆盖组件指定的值；所有组件都是disabled。-typedef
G、android:hasCode(’true’ or ’false’)
表示此APP是否包含任何的代码，默认为true，若为false，则系统在运行组件时，不会去尝试加载任何的APP代码
一个应用程序自身不会含有任何的代码，除非内置组件类，比如Activity类，此类使用了AliasActivity类，当然这是个罕见的现象
(在Android2.3可以用标准C来开发应用程序，可在androidManifest.xml中将此属性设置为false,因为这个APP本身已经不含有任何的JAVA代码了)
H、android:icon
这个很简单，就是声明整个APP的图标，图片一般都放在drawable文件夹下
I、android:killAfterRestore
J、android:manageSpaceActivity
K、android:name
为应用程序所实现的Application子类的全名。当应用程序进程开始时，该类在所有应用程序组件之前被实例化。
若该类(比方androidMain类)是在声明的package下，则可以直接声明android:name=“androidMain“,但此类是在package下面的子包的话，就必须声明为全路径或android:name=“package名称.子包名成.androidMain“-f
L、android:permission
设置许可名，这个属性若在《application》上定义的话，是一个给应用程序的所有组件设置许可的便捷方式，当然它是被各组件设置的许可名所覆盖的
M、android:presistent
该应用程序是否应该在任何时候都保持运行状态,默认为false。因为应用程序通常不应该设置本标识，持续模式仅仅应该设置给某些系统应用程序才是有意义的。
N、android:process
应用程序运行的进程名，它的默认值为《manifest》元素里设置的包名，当然每个组件都可以通过设置该属性来覆盖默认值。如果你想两个应用程序共用一个进程的话，你可以设置他们的android:process相同，但前提条件是他们共享一个用户ID及被赋予了相同证书的时候-typedef
O、android:restoreAnyVersion
同样也是android2.2的一个新特性，用来表明应用是否准备尝试恢复所有的备份，甚至该备份是比当前设备上更要新的版本，默认是false
P、android:taskAffinity
拥有相同的affinity的Activity理论上属于相同的Task，应用程序默认的affinity的名字是《manifest》元素中设定的package名
Q、android:theme
是一个资源的风格，它定义了一个默认的主题风格给所有的activity,当然也可以在自己的theme里面去设置它，有点类似style。
不过现在在android stuido 上面 版本控制已经使用Gradle了。
请问大家： 软件测试中的测试执行结果分为：pass , fail , Block 其中 Block是什么意思啊 谢谢啦，我急
Block，阻塞的意思，一些因素会导致测试不能进行到底。可以理解为用例执行了一部分，然后出错没法继续执行了。
Pass，即通过，指测试运行结束，测试人得到了预料中的测试结果状态和测试行为。
Fail，即失败，在很多情况下，测试人得到预料之外的测试结果，状态或行为，这些结果与测试目标相差甚远，一个或多个测试错误需要记录下来。
扩展资料
测试用例设计一般遵循以下原则：
（1）正确性
输入用户实际数据以验证系统是否满足需求规格说明书的要求;测试用例中的测试点应首先保证要至少覆盖需求规格说明书中的各项功能，并且正常。
（2）全面性
覆盖所有的需求功能项;设计的用例除对测试点本身的测试外，还需考虑用户实际使用的情况、与其他部分关联使用的情况、非正常情况(不合理、非法、越界以及极限输入数据)操作和环境设置等。
（2）连贯性
用例组织有条理、主次分明，尤其体现在业务测试用例上;用例执行粒度尽量保持每个用例都有测点，不能同时覆盖很多功能点，否则执行起来牵连太大，所以每个用例间保持连贯性很重要。
（4）可判定性
测试执行结果的正确性是可判定的，每一个测试用例都有相应的期望结果。
（5）可操作性
测试用例中要写清楚测试的操作步骤，以及与不同的操作步骤相对应的测试结果。
