服装企业管理软件测试技术

做IT的朋友都知道，软件测试是软件开发过程中的一个重要组成部分，是贯穿整个软件开发生命周期、对软件产品（包括阶段性产品）进行验证和确认的活动过程，其目的是尽快尽早地发现在软件产品中所存在的各种问题——与用户需求、预先定义的不一致性。
软件测试的目的是为了保证软件产品的最终质量，在软件开发的过程中，对软件产品进行质量控制。一般来说软件测试应由独立的产品评测中心负责，严格按照软件测试流程，制定测试计划、测试方案、测试规范，实施测试，对测试记录进行分析，并根据回归测试情况撰写测试报告。测试是为了证明程序有错，而不能保证程序没有错误。那么在日常开发后期有哪些常用的软件测试测术呢？这里我们以服装企业管理软件测试为例。

软件测试技术
自动化测试和手工测试
手工测试和自动化测试也是两种测试方法。自动化测试是对手工测试的一种补充，自动化测试不可能完全替代手工测试，因为很多数据的正确性、界面是否美观、业务逻辑的满足程度等都离不开测试人员的人工判断。而如果仅仅依赖手工测试，测试效率将比较低。尤其是回归测试的重复工作量给测试人员造成了巨大的压力。 因此，得出一个结论：可以认为手工测试与自动化测试是测试互补方法，关键是在合适的地方使用合适的测试手段。

1．自动化测试
自动化测试是软件测试发展的一个必然趋势。随着软件技术的不断发展，测试工具也得到了长足的发展，人们开始利用测试工具来帮助自己做一些重复性的工作。软件测试的一个显著特点是重复性，重复让人产生厌倦的心理，重复使工作量倍增，因此人们想到用工具来解决重复的问题。
很多人一听到自动化测试就联想到基于GUI录制回放的自动化功能测试工具，如QTP、Robot、WinRunner等。实际上自动化测试技术的含义非常广泛，任何帮助流程的自动流转、替换手工的动作、解决重复性问题以及大批量产生内容，从而帮助测试人员进行测试工作的相关技术或工具的使用都称为自动化测试技术。例如，一些测试管理工具能帮助测试人员自动地统计测试结果并产生测试报告，编写一些SQL语句插入大量数据到某个表中，编写脚本让版本编译自动进行，利用多线程技术模拟并发请求，利用工具自动记录和监视程序的行为以及产生的数据，利用工具自动执行界面上的鼠标单击和键盘输入等。
自动化测试的目的是帮助软件系统测试，它可能部分地替代手工测试，但是不可能完全替代手工测试。

2．手工测试
手工测试有其不可替代的地方，因为人具有很强的判断能力，而工具没有。手工测试不可替代的地方至少包括以下几点。
(1)测试用例的设计：测试人员的经验和对错误的判断能力是工具不可替代的。
(2)界面和用户体验测试：人类的审美观和心理体验是工具不可模拟的。
(3)正确性的检查：人们对是非的判断、逻辑推理能力是工具不具备的。
对于一些基本的、逻辑性不强的操作，可以使用自动化测试工具。柱性能测试、压力测试等方面，自动化测试有其优势。它可以用简单的脚本，实现大量的重复的操作。从而通过对测试结果的分析，得出结论，这样不仅节省了大量的人力和物力，而且使测试的结果更准确。
手工测试也存在一些缺陷，手工测试者最常做的就是重复的手工回归测试，不但代价昂贵，而且容易出错。自动化测试可以减少但不能消除这种工作的工作量。测试者可以有更多的时间去从事更有意义的测试，例如，应用程序在复杂的场景下的不同处理等，尽管测试要花费更长的时间找到错误，但并不意味着因此而要付出更高的代价。所以选择正确的测试方法是十分重要的。

探索性测试
探索性测试可以说是一种测试思维技术。它没有很多实际的测试方法、技术和工具，但却是所有测试人员都应该掌握的一种测试思维方式。探索性强调测试人员的主观能动性，抛弃繁杂的测试计划和测试用例设计过程，强调在遇到问题时及时改变测试策略。
探索性测试的定义是：同时设计测试和执行测试。探索性测试有时候会与即兴测试(AdhoeTesting)混淆。即兴测试通常是指临时准备的、即时的Bug搜索测试过程。探索性测试，相比即兴测试更是一种精致的、有思想的过程。
探索性测试是一种不是很严谨的测试方法，缺乏可管理性和度量性。因此，JamesBach提出了基于任务的测试管理(Session—BasedTestManagement)。SessionBased测试管理是用于度量和管理探索性测试的一种方法。
测试人员在采用探索性测试方法的测试过程中，应该及时记录下所谓的“测试故事”，把所有测试中学习到的关于软件系统的知识要点、问题和疑问、测试的主意、进行了怎样的测试等相关信息记录下来，然后周期性地与测试组长或其他测试人员基于记录的“测试故事”展开简短的讨论。
测试组长基于这些记录的结果来判断测试的充分性，测试人员通过讨论可以共享学习到的软件系统相关的信息，交流测试的思想，总结测试的经验，激发测试人员拿出更多的测试主意，从而指导下一次测试任务的执行。
在这种方式的测试管理中，测试组长就像一名教练，但是需要参与到测试的实际任务中，指导测试人员测试的方向和重点，提供更多的关于软件系统相关的信息给测试人员，授予测试人员更多的测试技术。
并非所有的软件测试都需要采用探索性测试的方法，但是可把探索性测试方式作为传统测试方式的补充，在每一项测试后留下一定的时间给测试人员做探索性的测试，以弥补相对刻板的传统测试方式的不足。应该更多地采用探索性测试的思维方式，将其应用在日常测试工作中。

单元测试
单元测试是针对软件设计中的最小单位(程序模块)，进行正确性检验的测试工作，其目的在于发现每个程序模块内部可能存在的差错。由于敏捷开发的兴起，单元测试再度受到重视。没有采用敏捷开发方式的软件企业也在重新审视单元测试的重要性。
对于单元测试的定义，应该分成广义的和狭义的两种。狭义的单元测试是指编写测试代码来验证被测试代码的正确性。广义的单元测试则是指小到一行代码的验证，大到一个功能模块的功能验证，从代码规范性的检查到代码性能和安全性的验证都包括在内，视单元的范围而定义。

1．单元测试由谁来做
关于单元测试应该由谁来做，存在两种截然不同的对立观点：一部分人认为单元测试既然是测试的一种类型，当然应该由测试人员负责；另外一部分人则认为，开发人员应该通过编写单元测试的代码来保证自己写的程序是正常工作的。
支持单元测试应该由开发人员执行的人认为，单元测试是程序员的基本职责，程序员必须对自己所编写的代码持有认真负责的态度。由程序员来对自己的代码进行测试的代价是最小的，却能换来优厚的回报，因为在编码过程中考虑测试问题，得到的是更优质的代码，这个时候程序员对代码应该做什么了解得最清楚。如果不这样做，而是一直等到某个模块崩溃时，程序员则可能已经忘记代码是怎样工作的，需要花费更多的时间重新弄清代码，即使这样也不一定能完全弄清楚，因此修改的代码往往不会那么彻底。
那些支持程序员不应该测试自己代码的人认为，单元测试应该由测试人员来做。程序员通常都有爱护自己程序的潜在心理，不忍心对程序进行破坏性的测试，而且，程序员也缺乏像测试人员一样敏锐的测试思维，很难设计出好的测试代码。
说明：广义的单元测试不仅包括编写测试代码进行单元测试，还包括很多其他的方面，例如代码规范性检查，则完全可以由测试人员借助一些测试工具进行。

2．结对单元测试
测试人员应该与开发人员进行结对的单元测试，测试人员的优势是具有敏锐的测试思维和测试用例设计能力，应该充分利用测试人员的这些优点。一种可行的办法是：把两种观点结合在一起，让测试人员设计测试用例，开发人员编写测试代码实现测试用例，再由测试人员来执行测试用例。也就是说，让测试人员和开发人员结对进行单元测试，如图10．3所示。
开发人员与测试人员在单元测试的过程中必须紧密地合作，一起讨论应该进行哪些测试以及怎样测试，应该添加哪些测试数据。开发人员应该向测试人员提供程序的设计思路、具体实现过程以及函数参数等信息。测试人员根据了解到的需求规格、设计规格来进行测试用例的设计，指导开发人员按照测试用例进行测试代码的设计。测试人员运行开发人员编写的测试代码进行单元测试以及结果的收集与分析。或者利用单元测试工具让单元测试代码自动运行。
结对单元测试要求测试人员对需求的把握能力要强，而且对设计和编码过程有基本的认识。开发人员在结对单元测试中应能更好地按需求进行代码设计，同时也能从测试人员身上学到更多关于测试的知识，以便提高代码编写的质量和防止代码出错的能力。

单元级别性能测试
随着网络的发展，软件也越来越复杂，从独立的单机结构，到c／s结构、B／S结构、多层体系架构，面向服务的(SOA)结构等，集成的软件技术越来越多，支持的软件用户也越来越多，比如我们秘奥软件，就受到了中小服装企业的青睐。一个凸显在人们面前的问题是性能问题。很多软件系统在开发测试时没有任何问题，但是上线不久就崩溃了，原因就在于缺少了性能方面的验证。
软件是否在上线之前进行性能测试就能解决问题呢?不一定，如果性能测试进行得太晚，会带来修改上的风险。很多软件系统在设计的时候并没有很好地考虑性能问题和优化方案，等到整个软件系统开发出来后，测试人员忙着集成测试，开发人员也疲于应付发现的功能上的Bug，当所有功能上的问题都得到解决后，才想到要进行性能测试。性能测试结果表明系统存在严重的问题，如响应时间迟缓、内存占用过多、不能支持大量的数据请求，在大量用户并发访问的情况下会造成系统崩溃。如果此时再去修改程序已经非常困难了，因为要彻底地解决性能问题，需要重新调整系统的架构设计，大量的代码需要重构，这时的程序员已经筋疲力尽，不想再进行代码的调整了，因为调整带来的是大量的编码工作，同时可能引发大量的功能上的不稳定性和再次出现大量的漏洞。
这给测试人员一个启示：性能测试不应该只是一种后期的测试活动，更不应该是软件系统上线前才进行的“演练”，而应该是贯穿软件的生产全过程。
对于性能的考虑应该在架构设计时就开始，对于架构原型要进行充分的评审和验证。由于架构设计是一个软件系统的基础平台，如果基础不好，也就是根基不牢，性能问题就会根深蒂固，后患无穷。性能测试应该在单元测试阶段就开始。从代码的每一行效率，到一个方法的执行效率，再到一个逻辑实现的算法效率；从代码的效率，到存储过程的效率，都应该进行优化。单元阶段的性能测试可以考虑从以下几个方面进行：
①代码效率评估。
②应用单元性能测试工具。
③数据库优化。
应该注意每一行代码的效率，一些看似细小的问题可以经过多次的执行累积成一个大的问题，这是一个量变到质变的过程。
类似的问题有很多，它们的特点是单个问题都很小，但是在一个庞大的系统中，经过多次的调用，问题会逐渐地被放大，甚至引发系统性能等重大问题。这些问题都可以通过代码走查来发现。
如果测试人员不熟悉代码怎么办呢?那么可以借助一些代码标准检查工具，来帮助自动查找类似的问题。测试人员可以使用一些代码效率测试工具来帮助找出哪些代码或方法在执行时需要耗费比较长的时间，例如AQTime是一款可以计算出每行代码执行时间的工具。可以看出每一个方法甚至每一行代码的执行时间是多少。这对开发人员在查找代码层的性能瓶颈时，也会有很大的帮助。除了代码行效率测试工具外，最近还出现了一些开源的单元级别的性能测试框架，可以像使用XUnit这一类的单元测试框架一样，但不是用于测试单元代码的正确性，而是用于测试函数、方法的性能是否满足要求。例如NTime就是这样的一个小土具。

数据库性能测试
目前很多软件系统除了代码层的性能测试之外，都需要应用到数据库，通常数据库也会成为性能瓶颈之一。 那么测试人员应该如何发现数据库相关的性能问题呢?
首先要分析什么会引起数据库的性能问题，一般来说有两个主要原因：数据库的设计和SQL语句。
数据库的设计又分为数据库的参数配置和逻辑结构设计，前一种比较好解决，后一种则是测试人员需要关注的，不良的表结构设计会导致很差的性能表现。
例如，没有合理地设置主键和索引则可能导致查询速度大大降低。没有合理地选择数据类型也可能导致排序性能降低。
低效率的SQL语句是引起数据库性能问题的主要原因之一，其中又包括程序请求的sQL语句和存储过程、函数等SQL语句。对这些语句进行优化能大幅度地提高数据库性能。可以借助一些工具来帮助找出有性能问题的语句，例如SQLBestPracticesAnalyzer、sQLServer数据库自带的事件探查器和查询分析器、LECCOSQLExpert等。目前，广州秘奥软件科技有限公司旗下服装企业管理软件产品采用的数据就是SQL数据库。

压力测试
是否想知道软件系统在某方面的能力可以达到一个怎样的极限呢?软件项目的管理者以及市场人员会尤其关心压力测试的结果，想知道软件系统究竟能达到一个怎样的极限。压力测试(StressTesting)就是一种验证软件系统极限能力的性能测试。
压力测试应该是指模拟巨大的工作负荷以查看应用程序在峰值使用情况下如何执行操作。压力测试与负载测试(LoadTesting)的区别在于，负载测试需要进行多次的测试和记录，例如，随着并发的虚拟用户数的增加，系统的响应时间、内存使用、CPU使用情况等方面的变化如何。压力测试的目的很明确，就是要找到系统的极限点。在系统崩溃或与指定的性能指标不符时的点，就是软件系统的极限点。
经常碰到性能需求不明确的情况。用户通常不会明确地提出性能需求，在进行需求分析和设计时也通常把性能考虑在后面。即使提出了性能上的要求，也是很模糊的，例如：“不能感觉到明显的延迟”。
对于不明确的性能需求，通常需要进行的不是极限测试，而是负载测试，需要逐级验证系统在每一个数据量和并发量的情况下的性能响应，然后综合分析系统的性能表现形式。

软件的安全性测试
软件安全性测试包括程序、系统网络和数据库安全性测试。根据系统安全指标不同测试策略也不同。
1．用户认证安全测试要考虑的问题
(1)明确区分系统中不同用户权限。
(2)系统中会不会出现用户冲突。
(3)系统会不会因用户的权限的改变造成混乱。
(4)用户登录密码是否可见、可复制。
(5)是否可以通过某种非法途径登录系统(如复制用户登录后的链接直接进入系统)。
(6)用户退出系统后是否删除了所有记录，是否可以使用后退键而不通过输入口令进入系统。

2．系统网络安全测试要考虑的问题
(1)测试采取的防护措施是否正确装配好，有关系统的补丁是否打上。
(2)模拟非授权攻击，测试防护系统是否坚固。
(3)采用成熟的网络漏洞检查工具检查系统相关漏洞。
(4)采用各种木马检查工具检查系统木马情况。
(5)采用各种防外挂工具检查系统各组程序是否易存外挂漏洞。

3．数据库安全测试要考虑的问题
(1)系统数据是否机密(如对银行系统，这一点就特别重要)。
(2)系统数据的完整性。
(3)系统数据的可管理性。
(4)系统数据的独立性。
(5)系统数据的可备份和恢复能力(数据备份是否完整，可否恢复，恢复是否完整)。

软件安装／卸载测试
现在的软件系统很多都通过安装包的方式发布。用户通过安装包安装软件系统。安装包在安装的过程中就把很多参数和需要配置的东西设置好，用户安装好后软件就马上可以使用，比如服装企业管理软件。
安装测试需要注意以下几点：
(1)安装过程是否是必要的。有些软件系统根本不需要在安装过程中设置任何参数，不需要收集用户计算机的相关信息，并且软件不存在注册问题，软件系统是为某些用户定制开发的。这些软件系统的安装过程是不必要的。
(2)安装过程。安装过程是否在正确的地方写入了正确的内容?安装之前是否需要什么必备组件，如果缺少了这些组件是否能提示用户先安装哪些组件?能否自动替用户安装?安装过程的提示信息是否清晰，能否指导用户做出正确的选择?安装过程是否能在所有支持的操作系统环境下顺利进行?
(3)卸载。能否进行卸载?卸载是否为用户保存了必要的数据?卸载是否彻底删除了一些不必要的内容?卸载后是否能进行再次安装?
(4)升级安装。如果是升级安装，是否考虑到了用户旧系统的兼容性，尤其是旧数据的兼容性?
(5)安装后的第一次运行。安装后的第一次运行是否成功?第一次运行是否需要用户
设置很多不必要的参数?
(6)利用工具辅助测试。安装测试可以利用一些工具辅助进行，用于跟踪安装过程中产生的所有文件和对注册表进行的修改。

环境测试
环境测试是验证在不同的机器环境下，服装企业管理软件系统是否正常工作。环境测试，也叫做兼容性测试或配置测试等，是指测试软件系统在不同的环境下是否仍然能正常使用。
软件系统往往在开发和测试环境中运行正常。但是到了用户的使用环境中则会出现很多意想不到的问题。由于现在的用户一般不会只使用一个软件系统，可能会同时运行多个软件系统，而且不同的用户有不同的使用习惯和喜好，因此会安装各种各样的软件系统。这些都可能造成软件发布后出现很多兼容性的问题，以及一些与特定环境设置有关的问题。
软件系统的应用环境越来越复杂，现在的软件系统一般涉及以下几个方面的环境：
(1)操作系统环境。
(2)软件环境。
(3)网络环境。
(4)硬件环境。
(5)数据环境。
软件在不同的操作系统环境下的表现有可能不一样。安装包可能需要判断不同的操作系统版本来决定安装什么样的组件。测试时还要注意即使是同一个版本的操作系统，SP的版本不一样也可能会有所区别。
软件在不同的操作系统环境下的表现有可能不一样。安装包可能需要判断不同的操作系统版本来决定安装什么样的组件。测试时还要注意即使是同一个版本的操作系统，SP的版本不一样也可能会有所区别。
软件环境包括被测试软件系统调用的软件，或与其一起出现的常见软件。例如．有些软件需要调用Office的功能；一些特定的输入法软件也可能导致问题的出现，例如，通过DevPartner的覆盖率分析工具的命令行来启动一个．NET程序，再使用TestComplete进行录制，但回放时遇到TextBox控件输入的地方则输入不了中文字符。这种就是典型的两个软件之间的兼容性问题。
对网络环境的测试是指采用的网络协议和结构不一样时，软件系统能否适应。最简单直接的测试方法是拔掉网线，模拟断网的情况，看软件系统是否出现异常，能否正确提示用户。
对硬件环境的测试一般与性能测试结合在一起，包括检查软件系统在不同的内存空间和CPU速度下的表现。或者有些软件需要操作外部硬件，如打印机、扫描仪、指纹仪等，需要测试系统对一些主流产品的支持。
有些软件系统需要导入用户提供的一些真实的基础数据，作为后续系统使用的基础。对这些类型的软件系统应该在发布之前进行至少一次的、加载用户数据后的全面功能测试。环境测试一般使用组合覆盖测试技术进行测试用例的设计。

例如，某个软件系统需要运行在下面的环境中：
操作系统：WindowsXP或Windows2003。
Office版本：0ffice2003或Office2007。
内存配置：128MB或512MB。
如果全覆盖，则需要执行2×2×2—8项测试，如果没有足够的时间做这么多次的测试，则可以利用正交表法或成对组合覆盖等方法减少测试次数。

文章来源：秘奥软件网，中小企业信息化领跑者！全国咨询热线：400-9908-527_www.misall.com