可移植性测试.docx

1.1.1 可移植性测试
1.1.1.1 可移植性测试
可移植性指的是未经修改或修改部分源代码后，软部件从一种环境移植到另一种环境中
还能正常工作的难易程度。
注：1、可移植性是一种程度量，代表移植的难易程度；
2、这里的“软部件”一般指应用程序或系统；
3、这里的环境包括软件环境、硬件环境和组织环境。
1.1.1.2 可移植性测试目标
测试软件是否可以被成功移植到指定的硬件或软件平台上。
1.1.1.3 可移植性测试过程

1.1.1.4 可移植性可行性分析
l 软件移植的可行性分析可以为以后确定测试目标与范围做好准备，该阶段的主要目标是：
l 1)了解移植系统或软件的体系结构，便于在目标环境中重构；
l 2)了解移植系统或软件的运行环境，便于以后创建相应的测试环境；
l 3)确定目标环境与原环境的差异性；
l 4)明确度量该系统或软件可移植性的具体指标。
1.1.1.5 分析测试需求
分析测试需求的任务就是明确系统或软件的测试点，以及为这些测试点分配的软件资
源、硬件资源、人力和时间资源等。可以通过以下几个方面来确定测试需求：
l 被测系统或软件是否对可移植性的要求很高；
l 被测系统或软件是否有对其他质量特性有特别的要求，例如安全性、可靠性等；
l 用户希望的被测系统或软件功能点的覆盖范围；
l 为测试分配的全部资源。
1.1.1.6 设计测试用例
根据可移植性的指标体系，移植测试的用例应该包括四类：
l 代码变更测试用例；
l 用户界面测试用例；
l 数据迁移数量测试用例；
1.1.1.7 代码变更测试
部分系统或软件在进行移植前必须要修改部分代码来适应目标环境，代码变更测试的目
标是得到代码的变更行数，这里的变更包括增加、删除和修改。
如果是可执行文件的移植，要求二方必须提供数据真实可靠的代码变更说明，给出总的
源代码变更行数。
如果是源代码的移植，则按下述步骤执行代码变更测试：
1） 获取移植前后两个不同的源代码版本；
2） 以Subversion为例，将两组源代码添加到SVN仓库中；
3） 从仓库中 CheckOut 要统计的源代码的路径，如果在工作拷贝目录下进行，先进行
更新，保证取出是最新的版本，以保证统计的结果准确性；
4） 结合Subversion的同步比对可以得到修改的代码行数；
5） 生成工作拷贝的XML Log文件供StatSVN解析使用；
6） 调用StatSVN的统计分析工作。
7） 查看StatSVN分析的结果
new 代表新增的文件，del 代表删除文件，+int代表该文件新增代码行数，-int 代
表该文件删除代码行数；
8） 综合上述结果可以得出代码比对统计报告，如表2所示；
代码对比统计报告
项目名称：
移植前版本： 移植后版本：
移植前版本的代码总行数SOC（Sum Of Code）：
对比工具：
对比时间：
新增文件数：

新增文件总代码行数：

删除文件数：

删除文件总代码行数：

原有文件新增总代码行数：

原有文件删除总代码行数：

原有文件修改总代码行数：

对比结果：

合计:
代码变更的总行数LOR（Lines Of Rewrite）=

1.1.1.8 用户界面测试
用户界面测试通常与系统或软件在原环境下同时运行并比较，从而更容易分辨目标环境 下系统或软件的用户界面与预期（或原环境下）系统或软件的用户界面不统一的地方。
主要测试的内容包括：各个界面（包括界面、窗口、提示信息）风格、文字、描述是否准确，是否符合需求说明书、数据字典要求；内容、顺序相互是否一致；功能键，包括“确定”、“取消”、“最大化”、“最小化”、“关闭”、“上一页”、“下一页”、“返回首页”、“退出”等是否有效、准确。

检查内容
优
中
差
1
界面显示内容是否完整：
报表的数据显示宽度是否能够自适应或自动换行；
所有数据展现的界面（如统计、查询、编辑录入、打印预览、打印等），必须使测试数据的记录数超过一屏/一页，以验证满屏/页时其窗体是否有横向、纵向滚动条或换页打印，界面显示是否正常；

2
界面显示内容是否一致：
如有多个系统展现同一数据源时，应保证其一致性；

3
界面显示内容是否准确：
对于报表中的所有字段值都应该有明确的定义，对于无意义的字段值，不应该显示空，应显示“--”或“/”，表示该字段值无意义。

4
界面显示内容是否有好：
对统计的数据应按用户习惯进行分类、排序； 某些重要信息在输入、修改、删除时应有“确认”提示信息；界面内容更新后系统应提供刷新功能；
用户在退出系统后重新登陆时应考虑是否需要自动返回到上次退出系统时的界面；

5
界面提示信息是否具有指导性：
在多个业务功能组成的一个业务流程中，如果各个功能之间的执行顺序有一定的制约条件，应通过界面提示用户；
用户提示信息应具有一定的指导性，在应用程序正在进行关键业务的处理时，应考虑在前台界面提示用户应用程序正在进行的处理，以及相应的处理过程，在处理结束后再提示用户处理完毕；
在某些数据输入界面，如果要求输入的数据符合某项规则，应在输入界面提供相应的规则描述；当输入数据不符合规则时应提示用户是否继续；
在对任何配置信息修改后，都应该在用户退出该界面时提示用户保存（如果用户没有主动保存的情况下）；

6
界面显示内容的合理性：
在对某些查询功能进行测试时，应考虑查询条件的设置的合理性以及查询结果的互补性。如某些后台处理时间不应该作为查询条件。
l界面测试时，应考虑某一界面上按钮先后使用的顺序问题，以免用户对此产生迷惑。例如只能在查询成功后显示执行按钮。
界面测试时，应验证窗口与窗口之间、字段与字段之间的浏览顺序是否正确；

7
用户使用的方便性：
在某些对数据进行处理的操作界面，应考虑用户可能对数据进行处理的频繁程度和工作量，考虑是否可以进行批量操作；

8
界面显示及处理的正确性：
界面测试时应验证所有窗体中的对象状态是否正常，是否符合相关的业务规则需要。
应验证各种对象访问方法（Tab 健、鼠标移动和快捷键是否可正常使用，并且在一个激活界面中快捷键无重复；
界面测试不光要考虑合理的键盘输入，还应考虑是否可以通过鼠标拷贝粘贴输入。
对于统计查询功能的查询结果应验证其是否只能通过界面上的查询或刷新按键人工触发，应避免其他形式的触发。
对界面上的任何对象进行拖拉，然后进行查询、打印，应保证查询打印结果不变；

9
数据显示的规范性：
确保数据精度显示的统一：如单价 0 元，应显示为 0.00 元；
确保时间及日期显示格式的统一；
确保相同含义属性/字段名的统一；
对所有可能产生的提示信息界面内容和位置进行验证，确保所有的提示信息界面应居中

1.1.1.9 数据迁移数量测试
完成平台不少于100万数据从传统存储环境向云存储环境的迁移。