接口测试考虑事项

在集成测试中首先是确定需要测试模块,集成是将多个模块集合在一起工作,模块与模块之间肯定有工作的接口,你就需要研究一个模块输入输出,研究多个模块的输入输出,构造你如何测试这多个模块输入输出的关系。——-查找各模块的输入输出及关系,编写用例

接口测试主要考虑的问题:

1.各个模块连接集成起来的时候,穿越模块接口的数据会不会丢失; —–确定数据完整

2.各个子功能组合起来,能否达到预期要求的父功能; ——集合后,达到需求目标

3.一个模块的功能是否对另一个模块的功能产生不利影响; ——集成后,不影响相关模块功能

4.全局数据结构是否有问题; ——集成后,保证系统数据的正确性

5.单个模块的误差积累起来,是否会放大,从而达到不可接受的程度。 ——-集成后,确保误差不影响系统功能及性能

Service层接口测试,大致有三种测试类型:接口逻辑测试、出错测试、路径测试

接口逻辑测试,对开发人员输写的JavaDoc进行测试,后根据JavaDoc来编写测试用例(一般情况下JavaDoc需要包含前提条件,业务逻辑,输入参数,输出值的描述),在接口逻辑测试中主要是根据所描述的业务逻辑,进行用例的设计,主要目标是测试在正常输入的情况下能得出正确的结果,测试用例的设计方法跟黑盒测试差不多,主要运用等价类,边界值两种方法。

出错测试,做了接口逻辑测试后,可以正常使用了。为了保证数据的安全,及程序在异常情况的逻辑正确性,因此需要测试出错测试。出错测试主要考虑:空值输入(如当传入一个对象参数时,需进行NULL值的参数)、参数属性的测试(如输入一个未赋值参数)、异常的测试(制造一些异常的测试场景,测试的异常描述是否清晰)

路径测试,经过了上述处理后,单个的接口服务已经得到了保证,但是在业务流中是否满足了业务需求其实还是没有得到保证,路径测试的目的就是设计尽可能少的用例,来保证各种业务场景下数据是安全可操作的。

《有赞.测试团队介绍》读后感

读完《有赞测试团队介绍》有了一点小感想,之前一直做黑盒测试,公司需要的时候会做一些性能和自动化,还未曾接触过白盒测试。现在测试开发职位也越来越多了,之前也一直苦于没有这样的机会,如今部门日益壮大,测试开发还是很有必要的。希望以后我们的日常工作也能像有赞一样。白盒测试能力、CodeReview能力或许现在我们还不具备,但是我们可以跟部门一块成长,总有一天会越来越成熟。

虽然暂时不能达到有赞的水平,但是我们可以一点点实现,首先做好第一步也就是有赞的2.1,然后在效仿后面的,相信会有很大的改善,让我们一起努力吧!

具体项目测试:

有赞的项目分为标准需求项目、技术重构项目、优化项目、缺陷修复项目。有限的测试资源通过不同策略支持着绝大部分业务产品的测试工作。
第一、对于标准需求项目或者跨多个业务的项目,一定会有测试投入,并且会有一位PTM来协调测试工作。PTM需要确保所有需求点都拆分到各个业务测试同学手里,跟踪相关测试同学按时提交标准测试方案。当测试方案汇总后,PTM需要评估后续测试过程中,测试人员如何投入。即哪些业务的功能测试PTM可顺带执行掉,哪些确实需要对应业务线测试同学来完成,以避免一个项目投入过多测试同学。
第二、技术重构改造项目,这种一般是单应用或者极少应用改造,但不改变业务使用规则。这类项目测试同学只要设计测试方案并完成测试用例落地即可,用例的执行由开发自行完成。测试同学要做的就是对新系统进行自动化覆盖。如有需要,测试会在上线前做质量check。
第三、对于小型项目,如果开发的自测场景与测试同学的测试场景基本一致,那开发自行搞定即可;或者测试同学把需要特别关注的或者风险点给开发同学简单介绍。对于有差异的,测试同学把差异点向开发同学描述清楚即可。
有赞测试同学拿到具体需求后,按照有赞测试对需求分析和测试方案统一要求,完成相关工作。

                                                   有赞.项目协作图

 

 

通过-Rational-AppScan 如何应对网站攻击

IBM-Rational-AppScan 正是应对这一挑战的利器。

如下图所示,Rational AppScan 工作方式比较简单,就像一个黑盒测试工具一样,测试人员不需要了解 Web 应用本身的结构。AppScan 拥有庞大完整的攻击特征库,通过在 http request 中插入测试用例的方法实现几百中应用攻击,再通过分析 http response 判断该应用是否存在相应的漏洞。整个过程简单易懂高效,测试人员可以快速的定位漏洞所在的位置,同时 AppScan 可以详细指出该漏洞的原理以及解决该漏洞的方法,帮助开发人员迅速修复程序安全隐患。对于攻击的特征以及测试用例用户不需要花费大量的精力,WatchFire 团队定期的对特征库进行更新,随着保证与业界的同步,最大化的提高用户的工作效率。

图 4.-Rational-AppScan 工作示意图

111

下面我们通过简单的实例介绍一下-Rational-AppScan 的使用:

定义扫描

首先确定扫描站点的 URL,根据默认的模板配置向导,确定扫描的整个站点模型以及你想扫描的漏洞种类。例如,我想扫描企业应用 www.xxx.com,想根据默认值扫描是否有安全隐患,启动 AppScan,创建一个扫描,敲入 www.xxx.com; 根据配置向导直至完成。

图 5. 默认的模板配置向导

222

图 6. 创建一个扫描

33

扫描启动,进行测试

只需要点击执行。

扫描结果查看

如图所示,AppScan 以各种维度展现了扫描后的结果,不仅仅定位了问题发生的位置,也提出了问题的解决方案。

图 7. 扫描后的结果

44

web安全测试的checklist

1. 不登录系统,直接输入登录后的页面的url是否可以访问
2. 不登录系统,直接输入下载文件的url是否可以下载,如输入http://url/download?name=file是否可以下载文件file
3. 退出登录后按后退按钮能否访问之前的页面
4. ID/密码验证方式中能否使用简单密码。如密码标准为6位以上,字母和数字混合,不能包含ID,连续的字母或数字不能超过n位
5. 重要信息(如密码,身份证号码,信用卡号等)在输入或查询时是否用明文显示;在浏览器地址栏里输入命令javascrīpt:alert(doucument.cookie)时是否有重要信息;在html源码中能否看到重要信息
6. 手动更改URL中的参数值能否访问没有权限访问的页面。如普通用户对应的url中的参数为l=e,高级用户对应的url中的参数为l=s,以普通用户的身份登录系统后将url中的参数e改为s来访问本没有权限访问的页面
7. url里不可修改的参数是否可以被修改, 浏览器缓存:认证和会话数据不应该作为GET的一部分来发送,应该使用POST
8. 上传与服务器端语言(jsp、asp、php)一样扩展名的文件或exe等可执行文件后,确认在服务器端是否可直接运行
9. 注册用户时是否可以以’–,’ or 1=1 –等做为用户名
10. 传送给服务器的参数(如查询关键字、url中的参数等)中包含特殊字符(’,’and 1=1 –,’ and 1=0 –,’or 1=0 –)时是否可以正常处理

11. 执行新增操作时,在所有的输入框中输入脚本标签(<scrīpt>alert(“”)</scrīpt>)后能否保存

12. 在url中输入下面的地址是否可以下载:
http://url/download.jspfile=C:\windows\system32\drivers\etc\hosts,http://url/download.jsp?file=/etc/passwd
13. 是否对session的有效期进行处理
14. 错误信息中是否含有sql语句、sql错误信息以及web服务器的绝对路径等

15. ID/密码验证方式中,同一个账号在不同的机器上不能同时登录

16. ID/密码验证方式中,连续数次输入错误密码后该账户是否被锁定
17. 新增或修改重要信息(密码、身份证号码、信用卡号等)时是否有自动完成功能(在form标签中使用autocomplete=off来关闭自动完成功能
18.Email Header Injection(邮件标头注入)
Email Header Injection:如果表单用于发送email,表单中可能包括“subject”输入项(邮件标题),我们要验证subject中应能escape掉“\n”标识。
<!–[if !supportLists]–> <!–[endif]–>因为“\n”是新行,如果在subject中输入
“hello\ncc:spamvictim@example.com”,可能会形成以下
Subject: hello
cc: spamvictim@example.com
<!–[if !supportLists]–> <!–[endif]–>如果允许用户使用这样的subject,那他可能会给利用这个缺陷通过我们的平台给其它用户发送垃圾邮件。

19. Directory Traversal(目录遍历)

(1)如何进行目录遍历测试?
目录遍历产生的原因是:程序中没有过滤用户输入的“../”和“./”之类的目录跳转符,导致恶意用户可以通过提交目录跳转来遍历服务器上的任意文件。
测试方法:在URL中输入一定数量的“../”和“./”,验证系统是否ESCAPE掉了这些目录跳转符。
(2)如何预防目录遍历?
限制Web应用在服务器上的运行  进行严格的输入验证,控制用户输入非法路径
20. exposed error messages(错误信息)

(1)如何进行测试?

 

首先找到一些错误页面,比如404,或500页面。
验证在调试未开通过的情况下,是否给出了友好的错误提示信息比如“你访问的页面不存在”等,而并非曝露一些程序代码。
(2)如何预防?
测试人员在进行需求检查时,应该对出错信息进行详细查,比如是否给出了出错信息,是否给出了正确的出错信息。

Web安全测试

1、用户权限测试

(1) 用户权限控制

1) 用户权限控制主要是对一些有权限控制的功能进行验证

2) 用户A才能进行的操作,B是否能够进行操作(可通过窜session,将在下面绍)

3)只能有A条件的用户才能查看的页面,是否B能够查看(可直接敲URL访问)

(2) 页面权限控制

1) 必须有登陆权限的页面,是否能够在不登陆情况下进行访问

2)必须经过A——B——C的页面,是否能够直接由A——C?

  2、URL安全测试

(1)适用范围: URL中含有参数,也就是通过GET方式传递的HTTP请求

(2)什么叫GET方式?

HTTP 定义了与服务器交互的不同方法,最基本的方法是 GET 和 POST。

GET方式在客户端通过URL提交数据,数据在URL中可以看到,例如在日常中订购服务:

http://pay.daily.taobao.net/mysub/subdeal/order_sub_deal.htm?servId=2

POST方式,数据放置在HTML HEADER内提交,数据在URL中看不到

GET只能传输比较少的数据,安全性较低,POST传输数据较多,安全性也比GET高

(3)测试关注点:

1) URL 参数检查:

A:  对URL中参数信息检查是否正确

如:URL中的订单号、金额允许显示出来的话,需要验证其是否正确

B:  对于一些重要的参数信息,不应该在URL中显示出来

如:用户登陆时登录名、密码是否被显示出来了 ,

2) URL参数值篡改

修改URL中的数据,看程序是否能识别:

如:对于以下URL,修改其中planId,看是程序是否可以识别:

http://pay.daily.taobao.net/mysub/plan/subplan/confirmSubPlanInfo.htm?planId=878

又如:对于URL中包含金额参数的,修改金额看是否能够提交成功(可能导致用户把2元金额改成1元金额能提交),还有修改订单号等重要信息看是否会报错

3) URL中参数修改进行XSS注入:

什么是XSS?

XSS的全称是Cross Site Script(跨站点脚本)

XSS的原理很简单,即进行脚本注入,URL执行时即把此脚本进行了执行,一般都是JavaScript脚本。

如“http://demo.aa.org/index_Article_Class.asp?fID_ArticleClass=2&ArticleClassName=abc”

改成“http://demo.aa.org/index_Article_Class.asp?fID_ArticleClass=2&ArticleClassName=abc<script>alert(“hello”);</script>”

看看有没弹出对话框显示hello,有的话就有跨站漏洞。

在URL中进行XSS注入,也就是把URL中的参数改成JS脚本。

4) URL参数中进行SQL 注入

什么是SQL注入?

SQL注入全称是SQL Injection ,当应用程序使用输入内容来构造动态sql语句以访问数据库时,会发生sql注入攻击,如查询、插入数据时。

测试方法: URL中写入SQL注入语句,看是否被执行,

   如:http://demo.testfire.net这个网站中,选择sign in

设置用户名为 admin ‘ or ‘1’=’1   密码为任意数字  ,点击登录就可以登陆。

  一般情况下要进行SQL注入攻击,需要对数据库类型、表名、判断逻辑、查询语句等比较清楚才能够写出有效的SQL注入语句。

  3、表单提交安全测试

适用范围:有表单提交的地方、有HTTP请求的地方(包括GET、POST请求)

测试关注点:

1) 表单中注入XSS脚本

URL中需要检测XSS注入,表单中更需要验证

测试方法:即在表单填写框中直接注入JS脚本

如在表单中输入XSS脚本,程序是不应该让脚本执行的

2) 表单中注入SQL 脚本

与URL中参数进行SQL注入类似,就是在表单中写入SQL注入脚本提交看是否会有问题

  4、Session测试

(1)Session是客户端与服务器端建立的会话,总是放在服务器上的,服务器会为每次会话建立一个sessionId,每个客户会跟一个sessionID对应。

并不是关闭浏览器就结束了本次会话,通常是用户执行“退出”操作或者会话超时时才会结束。

(2)测试关注点:

1)Session互窜

Session互窜即是用户A的操作被用户B执行了。

验证Session互窜,其原理还是基于权限控制,如某笔订单只能是A进行操作,或者只能是A才能看到的页面,但是B的session窜进来却能够获得A的订单详情等。

Session互窜方法:

多TAB浏览器,在两个TAB页中都保留的是用户A的session记录,然后在其中一个TAB页执行退出操作,登陆用户B,此时两个TAB页都是B的session,然后在另一个A的页面执行操作,查看是否能成功。预期结果:有权限控制的操作,B不能执行A页面的操作,应该报错,没有权限控制的操作,B执行了A页面操作后,数据记录是B的而不是A的。

2)Session超时

基于Session原理,需要验证系统session是否有超时机制,还需要验证session超时后功能是否还能继续走下去。

测试方法:

1、打开一个页面,等着10分钟session超时时间到了,然后对页面进行操作,查看效果。

2、多TAB浏览器,在两个TAB页中都保留的是用户A的session记录,然后在其中一个TAB页执行退出操作,马上在另外一个页面进行要验证的操作,查看是能继续到下一步还是到登录页面。

白盒、灰盒、黑盒测试区别

什么是黑盒测试和白盒测试?

黑盒测试也称功能测试或数据驱动测试,它是在已知产品所应具有的功能,通过测试来检测每个功能是否都能正常使用,在测试时,把程序看作一个不能打开的黑盆子,在完全不考虑程序内部结构和内部特性的情况下,测试者在程序接口进行测试,它只检查程序功能是否按照需求规格说明书的规定正常使用,程序是否能适当地接收输入数锯而产生正确的输出信息,并且保持外部信息(如数据库或文件)的完整性。

黑盒测试方法主要有等价类划分、边值分析、因—果图、错误推测等,主要用于软件确认测试。

“黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。

“黑盒”法是穷举输入测试,只有把所有可能的输入都作为测试情况使用,才能以这种方法查出程序中所有的错误。

实际上测试情况有无穷多个,人们不仅要测试所有合法的输入,而且还要对那些不合法但是可能的输入进行测试。

黑盒测试主要是为了发现以下几类错误:

1、是否有不正确或遗漏的功能?

2、在接口上,输入是否能正确的接受?能否输出正确的结果?

3、是否有数据结构错误或外部信息(例如数据文件)访问错误?

4、性能上是否能够满足要求?

5、是否有初始化或终止性错误?

白盒测试也称结构测试或逻辑驱动测试,它是知道产品内部工作过程,可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行,按照程序内部的结构测试程序,检验程序中的每条通路是否都有能按预定要求正确工作,而不顾它的功能,白盒测试的主要方法有逻辑驱动、基路测试等,主要用于软件验证。

“白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。

“白盒”法是穷举路径测试。在使用这一方案时,测试者必须检查程序的内部结构,从检

查程序的逻辑着手,得出测试数据。贯穿程序的独立路径数是天文数字。但即使每条路径都测试了仍然可能有错误。

第一,穷举路径测试决不能查出程序违反了设计规范,即程序本身是个错误的程序。

第二,穷举路径测试不可能查出程序中因遗漏路径而出错。第三,穷举路径测试可能发现不了一些与数据相关的错误。

灰盒测试,确实是介于二者之间的,可以这样理解,灰盒测试关注输出对于输入的正确性,同时也关注内部表现,但这种关注不象白盒那样详细、完整,只是通过一些表征性的现象、事件、标志来判断内部的运行状态,有时候输出是正确的,但内部其实已经错误了,这种情况非常多,如果每次都通过白盒测试来操作,效率会很低,因此需要采取这样的一种灰盒的方法。

白盒测试主要是想对程序模块进行如下检查:

1、对程序模块的所有独立的执行路径至少测试一遍。

3、在循环的边界和运行的界限内执行循环体。

4、测试内部数据结构的有效性,等等。

灰盒测试,确实是介于二者之间的,可以这样理解,灰盒测试关注输出对于输入的正确性,同时也关注内部表现,但这种关注不象白盒那样详细、完整,只是通过一些表征性的现象、事件、标志来判断内部的运行状态,有时候输出是正确的,但内部其实已经错误了,这种情况非常多,如果每次都通过白盒测试来操作,效率会很低,因此需要采取这样的一种灰盒的方法。

灰盒测试结合了白盒测试盒黑盒测试的要素。它考虑了用户端、特定的系统知识和操作环境。它在系统组件的协同性环境中评价应用软件的设计。

灰盒测试由方法和工具组成,这些方法和工具取材于应用程序的内部知识盒与之交互的环境,能够用于黑盒测试以增强测试效率、错误发现和错误分析的效率。

灰盒测试涉及输入和输出,但使用关于代码和程序操作等通常在测试人员视野之外的信息设计测试。

●黑盒测试有可能是动态测试(运行程序,只看输入和输出),也有可能是静态测(不运行程序,只是查看界面)

●白盒测试有可能是动态测试(运行程序,并分析代码结构),也有可能是静态测(不运行程序,只是静态查看代码)

●动态测试有可能是黑盒测试(运行程序,只看输入和输出),也有可能是白盒测(运行程序,并分析代码结构)

●静态测试有可能是黑盒测试(不运行程序,只是查看界面),也有可能是白盒测(不运行程序,只是静态查看代码)

以上事实说明,软件测试有一个致命的缺陷,即测试的不完全、不彻底性。由于任何程序只能进行少量(相对于穷举的巨大数量而言)的有限的测试,在未发现错误时,不能说明程序中没有错误。

浅谈软件开发项目的质量控制

一、引言

  J.M.Juran认为质量控制是一个常规的过程,通过它度量实际的质量性能并与标准比较,当出现差异时采取行动。由此,DonaldReifer 给出软件质量控制的定义:软件质量控制是一系列验证活动,在软件开发过程的任何一点进行评估开发的产品是否在技术上符合该阶段制定的规约。

  二、软件缺陷分析

  在IEEE 1983 of IEEES tandard729 中对软件缺陷下了一个标准的定义:从产品内部看,软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题;从外部看,软件缺陷是系统所需要实现的某种功能的失效或违背。

  软件缺陷是一个更广的概念,而软件错误(error)属于缺陷的一种———内部缺陷,往往是软件本身的问题,如程序的算法错误、语法错误或数据计算不正确、数据溢出等。软件错误往往导致系统某项功能的失效,或成为系统使用的故障。软件的故障、失效是指软件所提供给用户的功能或服务,不能达到用户的要求或没有达到事先设计的指标,在功能使用时中断,最后的结果或得到的结果是不正确的。

  软件缺陷的产生主要是由软件产品的特点和开发过程决定的,如软件的需求经常不够明确,而且需求变化频繁,开发人员不太了解软件需求,不清楚应该 “做什么”和“不做什么”,常常做不合需求的事情,产生的问题最多。同时,软件竞争非常激烈,技术日新月异,使用新的技术也容易产生问题。

  从软件自身特点、团队工作和项目管理等多个方面进一步分析,就比较容易确定造成软件缺陷的一些原因细节,归纳如下:

  (一)软件自身特点造成的问题。

  需求不清晰,导致设计目标偏离客户的需求,从而引起功能或产品特性上的缺陷。系统结构非常复杂,而又无法设计成一个很好的层次结构或组件结构, 结果导致意想不到的问题或系统维护、扩充上的困难;即使设计成良好的面向对象的系统,由于对象、类太多,很难完成对各种对象、类相互作用的组合测试,而隐藏着一些参数传递、方法调用、对象状态变化等方面问题。

  新技术的采用,可能涉及技术或系统兼容的问题,事先没有考虑到。

  对程序逻辑路径或数据范围的边界考虑不够周全,容易在边界条件出错或超过系统运行环境的复杂度。

  系统运行环境的复杂,不仅用户使用的计算机环境千变万化,包括用户的各种操作方式或各种不同的输入数据,容易引起一些特定用户环境下的问题;在系统实际应用中,数据量很大,可能会引起强度或负载问题。

  对一些实时应用系统,要进行精心设计和技术处理,保证精确的时间同步,否则容易引起时间上不协调,或不一致性所带来的问题。

  没有考虑系统崩溃后系统的自我恢复或数据的异地备份等问题,从而存在系统安全性、可靠性的隐患。

  由于通信端口多、存取和加密手段的矛盾性等,会造成系统的安全性或适用型等问题。

  (二)软件项目管理的问题。

  缺乏质量文化,不重视质量计划,对质量、资源、任务、成本等的平衡性把握不好,容易挤掉需求分析、评审、测试等时间,遗留的缺陷会比较多。系统分析时对客户的需求不是十分清楚,或者和用户的沟通存在一些困难。开发周期短,需求分析、设计、编程、测试等各项工作不能完全按照定义好的流程来。开发流程不够完善,存在太多的随机性和缺乏严谨的内审或评审机制,容易产生问题。文档不完善、风险估计不足等。

  (三)团队工作的问题。

  不同阶段的开发人员相互理解不一致,软件设计人员对需求分析结果的理解偏差,编程人员对系统设计规格说明书中某些内容重视不够,或存在着误解。设计或编程上的一些假定或依赖性,没有得到充分的沟通。项目组成员技术水平参差不齐,新员工较多,或培训不够等原因也容易引起问题。

  软件缺陷是由很多原因造成的,但如果把这些缺陷按整个软件开发周期的结果———软件产品(市场需求文档、规格说明书、系统设计文档、程序代码、测试用例等) 归类起来,统计结果发现,规格说明书是软件缺陷出现最多的地方。       

软件产品规格说明书是软件缺陷存在最多的地方,主要原因如下:

  用户一般是非计算机专业人员,软件开发人员和用户的沟通存在较大困难,对要开发的产品功能理解不一致。

  由于软件产品还没有设计、开发,完全靠想象去描述系统的实现结果,所以有些特性还不够清晰。

  用户的需求总是在不断变化的,容易引起前后文、上下文的矛盾和需求描述的不一致。

  需求分析没有得到足够重视。在规格说明书设计和写作上投人的人力、时间不足。排在产品规格说明书之后的是设计,编程排在第三位。而许多人印象中,软件测试主要是找程序代码中的错误,从分析看,这是一个误区。

  如果从软件开发各个阶段所能发现的软件缺陷分布来看,也主要集中在需求分析、系统设计阶段,代码阶段的错误要比前两个阶段少。

  三、分析及应对措施

  (一)定义合适的项目过程。

  软件过程是指开发和维护软件产品的活动、技术和实践的集合。在以计算机网络为基础的现代社会信息化背景下,过程管理作为现代企业管理的先进思想和有效工具,随着外部环境与组织模式的变化而变化。因此,作为一个好的软件项目过程,必须针对企业和项目的实际情况,确定软件项目运作流程,定义软件功能及相关性能,明确各阶段的进入条件和退出条件,进行有效的过程控制与管理,在提高软件开发的效率和项目的成功率的基础上进一步保证所开发软件的质量。

  (二)明确项目需求。

  对于任何软件项目过程而言,需求不仅是一个不可避免的环节,也是软件开发的基础。往往用户需求明确、变更少的项目的成功率就高,而那些用户需求混乱、变更频繁的项目几乎从一开始就注定了失败的命运。但是,在现实生活中,用户需求总是在开发进入中后期时,因为各种不同的原因而发生变化。这就给软件项目过程实施带来不确定因素。在涂装项目中,由于前期需求不明确以及随意变更需求,导致项目组在开发阶段不停的返工,进而造成代码质量低下,测试拖期等一系列问题。因此,在项目实施过程中,为了保证软件开发的顺利进行和最后交付的产品质量,应该对项目需求变更进行管理

  1、需求说明书要描述明确、详尽。由于与用户沟通的需求人员并不是最后的开发人员,所以有可能导致开发人员对需求说明书的理解与用户真正的意图会产生一定的偏差。另外,当项目在进行到开发(编码)阶段时,由于记忆的缺失,对当初所作的需求说明书的理解也会产生偏差。

  2、要对需求变更进行管理。通常需求分析完成后项目就进入开发阶段,用户可能会因为市场或策略的变化而提出需求变更的要求。此时,若是合理变更则有利于项目实施,但有时所作的变更可能会影响项目整体的设计和开发,造成项目进度的延期。对于这一情况,项目组应该积极与用户沟通,制订需求变更说明书,在双方都认可的情况下方可实施。

  3、在项目开发过程中要尽早明确用户需求,有些内容一时无法确定则应该暂缓该部分的开发,尽量降低因需求变更而带来的风险。

  (三)代码走查。

  软件质量在很大程度上依赖于代码质量。在实际环境中对于同一项目而言,由于项目组成员的编程能力、习惯、风格、对需求的理解和个性的不同,所开发的代码质量也不尽相同。再加上一些难以预测的人为因素,由此带来的隐患将严重影响代码质量,最终造成软件质量低下,使得用户无法正常使用并为以后的维护带来更大的工作量和难度。

  在软件开发过程中可以根据需要引进代码走查。每周在规定的时间内,轮流让程序员讲解其所开发代码的主要部分。这项措施一方面可以从侧面促使程序员本人注意所开发代码的质量,另一方面在走查过程中可以获得他人的意见进一步改善代码效率,使开发成员共享项目实施过程中问题解决的思路和方法,使得软件质量更有保障。

  (四)进行正式的测试,并形成制度测试就是对软件产品的检验。

  项目测试分集成测试和系统测试,主要进行功能测试、健壮性测试、性能-效率测试、用户界面测试、安全性测试、压力测试、可靠性测试、安装/反安装测试等活动。测试过程通常在模拟环境中进行。要尽可能覆盖整改项目过程,从最初的需求到部署阶段,都应该制订详细的计划并编制相应的文档,如测试计划、测试用例文档、测试报告等。通过测试活动,尽可能早得发现每个阶段中软件存在的缺陷,以方便后续阶段的实施。总之,一切测试应该符合用户需求。