104.基于WEB信息管理系统测试时应考虑的因素有哪些？
　　一、功能测试
　　1、链接测试
　　2、表单测试
　　3、Cookies测试
　　4、设计语言测试
　　5、数据库测试
　　二、性能测试
　　1、连接速度测试
　　2、负载测试 
　　3、压力测试 
　　三、可用性测试
　　1、导航测试 
　　2、图形测试
　　3、内容测试
　　4、整体界面测试
　　四、客户端兼容性测试
　　1、平台测试  
　　2、浏览器测试 
　　五、安全性测试
 
　　105.软件本地化测试比功能测试都有哪些方面需要注意？
　　软件本地化测试的目的：
　　软件本地化测试的测试策略：1.本地化软件要在各种本地化操作系统上安装并测试。2.源语言软件安装在另一台相同源语言操作系统上，作为对比测试。3.重点测试因本地化引起的软件的功能和软件界面的错误。4.测试本地化软件的翻译质量。5.手工测试和自动测试相结合。
 
　　106.软件测试项目从什么时候开始，？为什么？
软件测试应该在需求分析阶段介入，因为测试的对象不仅仅是程序编码，应该对软件开发过程中产生的所有产品都测试，并且软件缺陷存在放大趋势.缺陷发现的越晚，修复它所花费的成本越大.
 
　　107.需求测试注意事项有哪些？
　　一个良好的需求应当具有一下特点：
　　完整性：每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。
　　正确性：每一项需求都必须准确地陈述其要开发的功能。
　　一致性：一致性是指与其它软件需求或高层（系统，业务）需求不相矛盾。
　　可行性：每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。
　　无二义性：对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语言表达出来。
　　健壮性：需求的说明中是否对可能出现的异常进行了分析，并且对这些异常进行了容错处理。
　　必要性：“必要性”可以理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求都能回溯至某项客户的输入，如Use Case或别的来源。
　　可测试性：每项需求都能通过设计测试用例或其它的验证方法来进行测试。
　　可修改性：每项需求只应在S R S 中出现一次。这样更改时易于保持一致性。另外，使用目录表、索引和相互参照列表方法将使软件需求规格说明书更容易修改。
　　可跟踪性：应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟踪性要求每项需求以一种结构化的，粒度好（f i n e - g r a i n e d ）的方式编写并单独标明，而不是大段大段的叙述。
 
　　108.简述一下缺陷的生命周期
　　•软件缺陷的生命周期指的是一个软件缺陷被发现、报告到这个缺陷被修复、验证直至后关闭的完整过程。
　　简单的软件缺陷生命周期：
　　1、发现——打开：测试人员找到软件缺陷并将软件缺陷提交给开发人员；
　　2、打开——修复：开发人员再现、修复缺陷，然后提交测试人员去验证；
　　3、修复——关闭：测试人员验证修复过的软件，关闭已不存在的缺陷。
但是这是一种理想的状态，在实际的工作中是很难有这样的顺利的，需要考虑的各种情况都还是非常多的。
　　复杂的软件缺陷生命周期：
　　1、新建一个软件缺陷，这个软件缺陷是（open）状态，进行bug审查，不是代码问题，是设计需要修改；
　　2、新建一个软件缺陷，这个软件缺陷是（open）状态，进行bug审查，以后修改的，可以延期；
　　3、新建一个软件缺陷，这个软件缺陷是（open）状态，进行bug审查，实际没有这个bug，可以将其关闭；
　　4、新建一个软件缺陷，这个软件缺陷是（open）状态，看是否清楚可重现，如果不能重现，是缺少信息，需要返回到（open）状态；如果能够重现，进行修正，修正后关闭，进行回归测试。
 
　　108.测试分析测试用例注意（事项）？
　　1.为什么要写用例：
　　我们编写测试用例，有如下的好处：
　　便于团队交流：假如说一个测试团队有10个成员，大家测试的时候都各自为政，没有统一的标准，测试的效率无疑会大打折扣；如果大家都遵循统一的用例规范去写，会解决这一问题。
　　便于重复测试 ：大家知道，软件在实际开发过程中是会有不同版本的，比如会从1.0升级到10.0，那么如果不写测试用例的话，在测试10.0版本的时候，你能完全记得1.0版本时你做过哪些测试吗？测试用例像一个备忘录一样，便于重复测试。
　　便于跟踪统计：这一点是针对测试经理或是项目经理来说的，项目负责人通过看测试用例的执行情况，能了解到项目目前的概况，比如已经执行了哪些测试，还有哪些测试没有执行，测试没有通过的地方主要集中在哪些模块等。
　　便于用户自测：尤其是项目软件，有的时候用户希望自己测试一下软件产品，但是用户大都是非专业人士，他需要根据你写好的用例来更好的检验　　产品的质量
　　说了这么多编写测试用例的优点，那它有没有缺点呢？有一个明显的缺点是需要花费大量的时间，通常编写测试用例的时间比实际执行测试的时间还要长，这一点大家会在实际工作中有深刻的体会
 　　2.什么时候写用例：
　　什么时候写用例？这个问题没有统一的标准答案，但有一点可以肯定，是测试用例要尽早编写。 大家认为在哪个阶段开始写用例比较好呢？
　　通常，我们都会在测试设计阶段来写用例，即《需求规格说明书》和《测试计划》都已完成之后
 　　3.由谁来写测试用例
　　有的读者会说，当然是测试人员来写用例了！
　　可是测试人员又会有不同的角色，一般分为测试经理，测试设计人员，测试执行人员和测试工具开发人员等，一般测试用例是由测试设计人员来编写，由测试执行人员来执行，这要求测试设计人员有一定的用例设计经验，并对被测试的系统有深入的了解。
　　但是在很多小公司里面，区分的不是这么明显，一个测试人员往往会身兼数职，既是测试组长，又是测试设计人员，又是测试执行人员。项目组里你一个测试工程师，你不写用例谁写啊！
 　　4.根据什么写测试用例
　　我们编写测试用例的标准是用户需求，具体的参考资料是《系统需求规格说明书》和软件原型，其中软件原型指的是没有嵌入全部源代码的软件界面，比如我做一个电子商务网站，为了尽快能给用户演示，我只是用html语言作一些静态页面，并没有编写动态的程序，这是一个软件原型，它也看作是需求的一部分。