1、刚刚从事软件测试职业，如何快速掌握编写测试⽤例的⽅法？该怎样编写测试⽤例呢？
专家分析：
1、根据需求⽂档，完全按照需求⽂档框架/功能描述，根据⾃⼰的理解整理为⽤例。简单来说，就是将需求⽂档描述的内容，重新按照⽤例的格式编辑⼀次，把能想到的各种可能性添加进去。
2、搜索其他测试⼈员编写的同类型功能⽤例，先理解，再根据项⽬实际需求的较⼩差异，重新新增/删/改，组成满⾜需求的⽤例组。
快速掌握⽤例其实没有什么窍门，只有多看，多想，多写，多评审。 2、怎样的测试⽤例是好⽤例?如果⽤⼀条⽤例覆盖⼀个功能点在实际操作中有很⼤的缺陷。⾸先不能确保测试⼈员进⾏集成测试时对功能⽤例执⾏到位，可能会出现遗漏。因此我们在测试⽤例输出过程中，建议测试⼈员就测试因⼦使⽤⼯程⽅法进⾏流程功能覆盖。但是这样引⼊另外⼀个问题，客户的需求是不断变化的，需求在执⾏设计和测试⽤例输出时，很⼤⼏率产⽣变化，这种变化势必对原输出的测试⽤例造成冲击。调整的⼯作量有时会很⼤，有可能对整个功能推倒重新输出⽤例。⾯对这样的情况该如何解决？
专家分析：每个⽤例覆盖⼀个功能点，是最佳的理想状态。但条件覆盖有个缺点就是每次执⾏会存在⼀个较长的周期，如果部分不可套⽤⾃动化，会导致测试和开发并⾏产⽣⽆法按时验证完每个版本的分⽀。
有两种⽅式可供参考：
1.在原本测试⽤例的基础上，再次放⼤⽤例描述的模糊度，以利于⽤例可⽤于相似但细节不同的功能。以登陆界⾯的字符长度为12双字节的⽤户名提⽰框为例：
原始⽤例步骤：在登陆界⾯⽤户名输⼊框输⼊11个中⽂字符。
修改后的⽤例步骤：在登陆界⾯输⼊不超过字符长度限制的⽤户名。
山药种植开沟机点评：原始⽤例步骤仅适合登陆界⾯⽤户名字符长度限制为11以上的编辑框。修改后的⽤例可⽤于任何字符长度的⽤户名编辑框。此⽅法还可⽤于对流程描述，如”进⼊编辑⽤户名界⾯”可替换为”编辑⽤户名”。
2.建⽴较为完善的基础⽤例库，项⽬⽤例作为基础⽤例库的⼦集存在。这样的⽤例库在针对单个功能时，存在多种不同的描述和设计。如1点的模糊程度不同可作为相同⽤例的不同两⽀⽤例存在。⽽在以后的实际项⽬中，根据项⽬实际需求，从基础⽤例库筛选合适的⽤例组作为项⽬⽤例组。
广谱抗菌素3、有些公司的⿊盒测试⽤例会演进为⾃动化⽤例。如果单⼀覆盖点测试⽤例，会导致⾃动化脚本代码复⽤率不⾼。像这样的问题，应该如何解决？
专家分析：⾸先⼀般都是按照测试⽤例去做的，单⼀运⾏，假如希望脚本复⽤⾼，需要整理业务函数脚本，把常⽤的业务函数化调⽤。这个是你们负责设计框架的⼈去想的。如果觉得业务利⽤率不⾼，就写成公共⽅法调⽤。 4、是不是性能测试适合男⽣？有专家说性能测试和功能测试没多⼤关联，没必要先学功能测试再学性能测试。这个观点对吗？
专家分析：其实性能测试并没有趋向于男⽣，就像开发⼈员也没有男⽣优先的招聘条件⼀样。之所以有这个说法，⽆⾮是⼤多数男⽣⽐⼥⽣更喜欢逻辑推理⽽已。
性能测试与功能测试还是有关联的。有些性能测试还必须在⼀定功能测试基础上测试。
5、做了⼏年测试，⾃我感觉没有什么提升，始终是在做⼀些⼿⼯测试，项⽬来了先不写测试⽤例⽽是先测试，等以后项⽬不紧张了再补充测试⽤例。我个⼈认为这样是很不规范的。我⼀直都认为写测试⽤例是最关键的，但是这⼏年好像没怎么写过测试⽤例。还有⾯试的时候考官也会给你出⼀道题，让你⼤概说下你设计测试⽤例的思路。这些总让我感到脑⼦⾥好像空空的，没什么思路。专家能否给些指点。
专家分析：1.“项⽬来了先不写测试⽤例⽽是先测试，等以后项⽬不紧张了再补充测试⽤例” 其实这种⽅式并不规范。如果你们已经有基础测试⽤例组，那么在项⽬需求确认后，第⼀时间开始⽤例的筛选和更新适⽤的⽤例组，并在项⽬前期交付于项⽬组各个部门评审。这样的操作⽆论对于项⽬质量控制还是项⽬出现问题后，对于测试⼈员的责任分摊，都是有极⼤利益的。
2.测试⽤例的设计本⾝是测试技能中最重要的技术之⼀。但是由于它本⾝涉及整个测试系统的其他各个技能，所以对⽤例的理解，实际上就是测试⼈员对测试的理解。若发现⽆法再写出更好的⽤例，可多看看业务相关的资料，同时学习测试流程，将⾃⾝的测试思想涉及相关业务的边边⾓⾓，并融⼊到实际使⽤的测试流程中。这时你将发现之前的测试⽤例设计思想存在较⼤的提升空间，也逐渐能开始通过分析测试环境（不仅仅包括执⾏测试环境），熟练驾驭测试框架，制定测试策略。⽽之前设计⽤例⽋缺的⽴⾜点，也会相应得到补⾜。有理有据，⾃然⽤例设计逻辑就清晰起来了。 6、⼿机软件的性能应考察哪些⽅⾯？
专家分析：从⼿机产品来看，⼿机性能测试可分为两部分：硬件测试和软件测试。
1.硬件测试操作简单，但⽬前国内很多⼿机硬件测试⼈员都处于初级阶段，即可执⾏测试，但⽆法提出优化解决⽅案，故普遍待遇较低。⽽要发展为⾼级硬件测试⼈员，必须掌握⼿机硬件测试设计原理，⽽掌握这部分的测试⼈员，⼤多都转为硬件开发。
2.⼿机软件性能测试⽬前在国内也⽐较⿇烦，主要由于以下⼏点：
1）嵌⼊式平台受于开源程度，⾃动化⼯具⼤多还是不⾜。勉强凑合的开源⾃动化⼯具⽆法应对多元化的客户和测试⼈员需求，往往需要⼆次开发。
2）由于市场竞争过于激烈，低成本的硬件器件⽆法达到最好的性能指标，导致在测试后期，测试⼈员还在纠结于如何平衡客户需求指标与实际测试性能指标。软件性能指标的不断变更同样也导致某些测试团队⽆法正确评估性能测试结果到底是通过还是失败。
3）软件性能测试周期长，投⼊资源较多，收益较功能测试少，故很多⼿机设计公司对这⼀块持观望态度。
7、测试⽤例有很多模版，该如何选择？测试⽤例是根据以前测试的积累步骤写还是要根据写测试⽤例的⽅法写？
专家分析：测试⽤例模板，可⾃⼰根据实际测试的环境来选择。建议选择表格式的模板，⽐如excel，⽐较好统计。
不同的测试⼈员，写测试⽤例的⽅法各不⼀样。并没有哪种⽅法就绝对好，都需要根据实际情况来看。如项⽬本⾝就很紧，若⼤张旗⿎的重新按照测试⽅法设计⽤例，必然导致中后期测试执⾏时间短
缺，⽆法达到预定的迭代次数，⽽对项⽬产⽣更⼤的风险。所以，先分析环境，才可能设计出好的测试⽤例。
8、功能测试做多久才适合做性能测试？
专家分析：功能⼊门简单，性能偏难。有⼀些功能测试基础，学学性能也⽆妨，这个没有时间的约束，看你⾃⼰的能⼒、是否感兴趣或者⼯作的需要。 9、测试⽤例的细度如何把握？什么样的功能点可以考虑放在同⼀条⽤例验证？什么样的功能点必须是由⼀条⽤例验证？
专家分析：⽤例粒度⽆论选择什么⽅法，都存在利弊，所以在实际测试⽤例设计中，如何选取，需要结合整个测试团队和产品未来发展来看，⽽⾮简单的只分析测试⽤例原理就能得到结果。提供⼀个⽤例粒度供参考。单个quick check test 单个测试⼈员在2⼩时完成，组成的⽤例组要求覆盖产品所有功能，⽽每个⽤例都可从System cases中直接提取。以此为标准，可评估出每个⽤例的覆盖粒度。
10、如何挑选回归⽤例？什么样的⽤例可以作为回归⽤例？如果在备选的⽤例库⾥边没有可作为回归⽤例的测试⽤例时我们应该怎么处理？专家分析：回归⽤例Quick Check Test⽤例差不多，满⾜2个要求：⼀是功能覆盖率，⼆是可在规定的执⾏时间内完成。
如果备选的⽤例库⾥没有相应的回归⽤例，则需要更新备选⽤例库。
11、新⼿该如何做好测试？
专家分析：测试对新⼿的要求很简单：
1.只相信实际测试的结果。
2.不懂就问，问完就想，想不通再问。切记重复的问题莫多次提问。
3.没事就多看资料，不管是否觉得和⾃⼰的业务相关，先看先了解，说不定以后哪天就⽤上了。
12、刚刚从开发转做测试，怎样才能将测试⽤例设计的全⾯？
专家分析：有个很简单的⽅法，你先按照⾃⼰的思路把⽤例写⼀次。然后⽤1倍的时间给⾃⼰的⽤例茬，然后将漏掉的点分类，再思考当初设计⽤例的时候，怎么可以将这些⽤例漏掉的点预先设计进去。
如果其他测试⼈员有时间，强烈建组织⽤例评审。
13、对于⽶聊，飞信这种软件如何设计好的测试⽤例才能保证没有功能遗漏，这种软件如何做性能⽅
⾯的测试？
专家分析：如果将兼容性测试划到性能测试中的话，那么⽶聊，飞信这类第三⽅的软件功能测试还算是⽐较简单的，需要注意两点：
1）交互。由于很多系统在设计时，并不可能考虑到适应所有的第三⽅软件。所以当第三⽅软件与系统本⾝软件在同时申请资源时，存在较⼤的风险。
2）容错。异常处理机制是软件设计的天⽣缺陷，我们⽆法在⼀开始就设计出完美的软件，特别是在容错⽅⾯。所以错误推断的⽤例设计⽅法通常都是软件设计的命门。
关于性能测试⽅⾯，除了上⾯提到的兼容性测试外，在⼿机端，还需考虑以下9种性能测试。
长周期测试
响应时间测试
电源管理测试
内存测试
多媒体质量测试
应⽤程序接⼝吞吐量测试
耐⼒测试
负载测试
可靠性测试
⽽在服务器端，则主要考虑⼀下6种性能测试
压⼒测试
负载测试
⼤数据量测试
配置测试
可靠性测试
并发测试
14、对于类似于⼿机版淘宝这种软件，它拥有客户端，服务器端还有⼀个后台管理系统类似于进销存管理系统，我如何设计测试⽤例才能保证功能的完全覆盖？他们之间的交互如何设计测试⽤例？
专家分析：对于复合型的第三⽅软件，⾸先需要进⾏功能拆分，如你所说的，拆分为⼿持客户端，服务器，后台管理系统三⼤块。然后再根据每⼀块的单独设计完整测试类型的⽤例组。
⽽针对主体三⼤功能交互⽤例组，由于基础交互⽤例组已经在UI⽤例组（客户端和后台管理）中设计完成，故⽬前主要考虑⼆级以上交互的⽤例设计。具体设计⽅法可考虑根据系统资源分配原理，筛选出可同时申请相同类型系统资源的进程或线程，通过组合的⽅式，设计出交互⽤例组。如，针对⽤户元宝余额的数据库，若⼿机端和后台管理均对此存储块有读写权限，当两者同时申请此块存储地址的权限时，系统是否响应正常。从这⼀点即构造出新的⽤户元宝余额的⼆级交互⽤例。
15、⾯对相对简单、不太规范的业务需求，⽽且没有详细的开发设计⽂档，测试⼈员应该如何做测试。业务需求提出⼈员在系统开发测试接近尾声后，频繁提出需求变更，测试⼈员应如何应对？
专家分析：没有详细⽂档，测试⼈员除了加强部门沟通外，其实没有太好的⽅法来规避风险。若此时测试主管对相关业务设计难度不熟悉的话，那整个测试任务可能⽆法顺利过渡到中期。
对于项⽬后期的需求问题，可考虑引⼊⼀些流程来规范，如软件⼊场标准。也可通过与PM/RD沟通，延长项⽬周期或将风险转嫁给决策⼈（PM）都是⼀些常见的处理⽅式。
16、刚刚接触⿊盒测试，测试计划和测试⽤例应该怎么部署？测试⽤例是不是就是⾃⼰在测试过程中⽤到的实例或步骤呢？
专家分析：做好测试计划的编写⼯作应该从以下⼏个⽅⾯考虑问题：
1、要充分考虑测试计划的实⽤性，即，测试计划与实际之间的接近程度和可操作性。编写测试计划的⽬的在于充分考虑执⾏测试时的各种资源，包括测试内容、测试标准、时间资源、⼈⼒资源等等，准确地说是要分析执⾏时所能够调⽤的⼀切资源以及受各种条件限制，可能受到的各种影响。说的再明确⼀点就是要“计划”“如何”去做“测试⼯作”，⽽不是“如何编写测试计划”。
2、要坚持“5W1H”的原则，明确测试内容与过程。
明确测试的范围和内容（WHAT）；
明确测试的⽬的（WHY）；
明确测试的开始和结束⽇期（WHEN）；
金属卤化物灯接线图
明确给出测试⽂档和软件册存放位置（WHERE）；
明确测试⼈员的任务分配（WHO）；
明确指出测试的⽅法和测试⼯具（HOW）。
3、采⽤评审和更新机制，确保测试计划满⾜实际需求。
因为软件项⽬是⼀个渐进的过程，中间不可避免地会发⽣需求变化，为满⾜需求变化，测试计划也需要及时地进⾏变更。
之所以采取相应的评审制度，就是要对测试计划的完整性、正确性、可⾏性进⾏评估，以保证测试的质量。
4、测试策略要作为测试的重点进⾏描述。
测试策略是测试计划中的重要组成部分，测试计划是从宏观上说明⼀个项⽬的测试需求、测试⽅法、测试⼈员安排等因素，⽽测试策略则是说明实际的测试过程中，应该怎样具体实施。因此，测试策略⼀定要描述详尽并且重点突出。
⾄于测试⽤例⼯作，我认为我们⾸先要明确测试⽤例在整个测试⼯作中的地位及其作⽤。个⼈认为，测试⽤例在整个测试⼯作中的地位和作⽤主要体现在以下⼏个⽅⾯：
1、测试⽤例是测试执⾏的实体，是测试⽅法、测试质量、测试覆盖率的重要依据和表现形式；
2、测试⽤例是团队内部交流以及交叉测试的依据；
3、在回归测试中，测试⽤例的存在可以⼤⼤的降低测试的⼯作量，从⽽提⾼测试的⼯作效率；
4、测试⽤例便于测试⼯作的跟踪管理，包括测试执⾏的进度跟踪，测试质量的跟踪，以及测试⼈员的⼯作量的跟踪和考核；top技术
5、在测试⼯作开展前完成测试⽤例的编写，可以避免测试⼯作开展的盲⽬性；
6、测试⽤例是说服⽤户相信产品质量的最佳依据，同时也可以提供给客户作为项⽬验收的依据。
当我们认识到测试⽤例在政⼯测试⼯作中的地位及其作⽤之后，相信⼤家都已经认识到了测试⽤例对测试⼯作的重要性和必要性，那么，我们就来讨论⼀下如何有效的保证测试⽤例的质量。
1、做好测试⼈员的项⽬培训（主要指对需求分析、软件设计、测试计划的认知程度）⼯作。要想发
挥团队中每⼀个成员的所有能⼒，最好的办法就是让他们每⼀个⼈都清楚这个项⽬中的所有细节，以及⾃⼰要在这个项⽬中所承担的责任。
2、尽可能的利⽤以往其他项⽬的测试⽤例；并将该项⽬中类似模块进⾏归类，按类编写测试⽤例，再根据每个模块的特点进⾏修改，要充分利⽤测试⽤例的可重⽤性。
3、在时间资源紧张的情况下，可以按照测试的关键路径编写测试⽤例，针对关键路径的测试⽤例⼀定要详尽，其他边缘模块的测试⽤例可以考虑仅通过性测试（既仅证真测试）。
4、采⽤针对测试⽤例的模块化编写。个⼈建议将测试⽤例和测试数据分开，测试⽤例中的操作步骤应主要体现于业务流程的检验，⽽测试数据主要体现于针对系统的数据处理结果的检验。考虑到软件项⽬的需求变更问题，建议将这两项分开，通过测试⽤例编号进⾏关联，以应对需求变化造成的测试⽤例的修改，从⽽减少测试⽤例的修改量，缩短项⽬周期，提⾼⼯作效率。
17、WEB页⾯测试有哪些⽅⾯？重点在哪⾥？需要注意的有哪些？
专家分析：基于Web的系统测试与传统的软件测试既有相同之处，也有不同的地⽅，对软件测试提出了新的挑战。基于Web的系统测试不但需要检查和验证是否按照设计的要求运⾏，⽽且还要评价系统在不同⽤户的浏览器端的显⽰是否合适。重要的是，还要从最终⽤户的⾓度进⾏安全性和可⽤性测试。下⾯从功能、性能、可⽤性、客户端兼容性、安全性等⽅⾯讨论基于Web的系统测试⽅法。
随着Internet和Intranet/Extranet的快速增长，Web已经对商业、⼯业、银⾏、财政、教育、政府和娱乐及我们的⼯作和⽣活产⽣了深远的影响。许多传统的信息和数据库系统正在被移植到互联⽹上，电⼦商务迅速增长，早已超过了国界。范围⼴泛的、复杂的分布式应⽤正在Web 环境中出现。Web的流⾏和⽆所不在，是因为它能提供⽀持所有类型内容连接的信息发布，容易为最终⽤户存取。在基于Web的系统开发中，如果缺乏严格的过程，我们在开发、发布、实施和维护Web的过程中，可能就会碰到⼀些严重的问题，失败的可能性很⼤。⽽且，随着基于Web的系统变得越来越复杂，⼀个项⽬的失败将可能导致很多问题。当这种情况发⽣时，我们对Web和Internet的信⼼可能会⽆法挽救地动摇，从⽽引起Web危机。并且，Web危机可能会⽐软件开发⼈员所⾯对的软件危机更加严重、更加⼴泛。
在Web⼯程过程中，基于Web系统的测试、确认和验收是⼀项重要⽽富有挑战性的⼯作。基于Web的系统测试与传统的软件测试不同，它不但需要检查和验证是否按照设计的要求运⾏，⽽且还要测试系统在不同⽤户的浏览器端的显⽰是否合适。重要的是，还要从最终⽤户的⾓度进⾏安全性和可⽤性测试。然⽽，Internet和Web媒体的不可预见性使测试基于Web的系统变得困难。因此，我们必须为测试和评估复杂的基于Web的系统研究新的⽅法和技术。
⼀、功能测试
1、链接测试
链接是Web应⽤系统的⼀个主要特征，它是在页⾯之间切换和指导⽤户去⼀些不知道地址的页⾯的主要⼿段。链接测试可分为三个⽅⾯。⾸先，测试所有链接是否按指⽰的那样确实链接到了该链接的页⾯；其次，测试所链接的页⾯是否存在；最后，保证Web应⽤系统上没有孤⽴的页⾯，所谓孤⽴页⾯是指没有链接指向该页⾯，只有知道正确的URL地址才能访问。链接测试可以⾃动进⾏，现在已经有许多⼯具可以采⽤。链接测试必须在集成测试阶段完成，也就是说，在整个Web应⽤系统的所有页⾯开发完成之后进⾏链接测试。
2、表单测试
当⽤户给Web应⽤系统管理员提交信息时，就需要使⽤表单操作，例如⽤户注册、登陆、信息提交等。在这种情况下，我们必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。例如：⽤户填写的出⽣⽇期与职业是否恰当，填写的所属省份与所在城市是否匹配等。如果使⽤了默认值，还要检验默认值的正确性。如果表单只能接受指定的某些值，则也要进⾏测试。例如：只能接受某些字符，测试时可以跳过这些字符，看系统是否会报错。
3、Cookies测试
Cookies通常⽤来存储⽤户信息和⽤户在某应⽤系统的操作，当⼀个⽤户使⽤Cookies访问了某⼀个应⽤系统时，Web服务器将发送关于⽤户的信息，把该信息以Cookies的形式存储在客户端计算机上，
这可⽤来创建动态和⾃定义页⾯或者存储登陆等信息。
如果Web应⽤系统使⽤了Cookies，就必须检查Cookies是否能正常⼯作。测试的内容可包括Cookies是否起作⽤，是否按预定的时间进⾏保存，刷新对Cookies有什么影响等。
4、设计语⾔测试
Web设计语⾔版本的差异可以引起客户端或服务器端严重的问题，例如使⽤哪种版本的HTML等。当在分布式环境中开发时，开发⼈员都不在⼀起，这个问题就显得尤为重要。除了HTML的版本问题外，不同的脚本语⾔，例如Java、JavaScript、 ActiveX、VBScript或Perl等也要进⾏验证。
5、数据库测试
在Web应⽤技术中，数据库起着重要的作⽤，数据库为Web应⽤系统的管理、运⾏、查询和实现⽤户对数据存储的请求等提供空间。在Web 应⽤中，最常⽤的数据库类型是关系型数据库，可以使⽤SQL对信息进⾏处理。
在使⽤了数据库的Web应⽤系统中，⼀般情况下，可能发⽣两种错误，分别是数据⼀致性错误和输出错误。数据⼀致性错误主要是由于⽤户提交的表单信息不正确⽽造成的，⽽输出错误主要是由于⽹络速度或程序设计问题等引起的，针对这两种情况，可分别进⾏测试。
⼆、性能测试
1、连接速度测试
⽤户连接到Web应⽤系统的速度根据上⽹⽅式的变化⽽变化，他们或许是电话拨号，或是宽带上⽹。当下载⼀个程序时，⽤户可以等较长的时间，但如果仅仅访问⼀个页⾯就不会这样。如果Web系统响应时间太长（例如超过5秒钟），⽤户就会因没有耐⼼等待⽽离开。
另外，有些页⾯有超时的限制，如果响应速度太慢，⽤户可能还没来得及浏览内容，就需要重新登陆了。⽽且，连接速度太慢，还可能引起数据丢失，使⽤户得不到真实的页⾯。
2、负载测试
负载测试是为了测量Web系统在某⼀负载级别上的性能，以保证Web系统在需求范围内能正常⼯作。负载级别可以是某个时刻同时访问Web 系统的⽤户数量，也可以是在线数据处理的数量。例如：Web应⽤系统能允许多少个⽤户同时在线？如果超过了这个数量，会出现什么现象？Web应⽤系统能否处理⼤量⽤户对同⼀个页⾯的请求？
3、压⼒测试
负载测试应该安排在Web系统发布以后，在实际的⽹络环境中进⾏测试。因为⼀个企业内部员⼯，特别是项⽬组⼈员总是有限的，⽽⼀个Web系统能同时处理的请求数量将远远超出这个限度，所以，只有放在Internet上，接受负载测试，其结果才是正确可信的。
进⾏压⼒测试是指实际破坏⼀个Web应⽤系统，测试系统的反映。压⼒测试是测试系统的限制和故障恢复能⼒，也就是测试Web应⽤系统会不会崩溃，在什么情况下会崩溃。⿊客常常提供错误的数据负载，直到Web应⽤系统崩溃，接着当系统重新启动时获得存取权。
压⼒测试的区域包括表单、登陆和其他信息传输页⾯等。
三、可⽤性测试
1、导航测试
导航描述了⽤户在⼀个页⾯内操作的⽅式，在不同的⽤户接⼝控制之间，例如按钮、对话框、列表和窗⼝等；或在不同的连接页⾯之间。通过考虑下列问题，可以决定⼀个Web应⽤系统是否易于导航：导航是否直观？Web系统的主要部分是否可通过主页存取？Web系统是否需要站点地图、搜索引擎或其他的导航帮助？
在⼀个页⾯上放太多的信息往往起到与预期相反的效果。Web应⽤系统的⽤户趋向于⽬的驱动，很快
地扫描⼀个Web应⽤系统，看是否有满⾜⾃⼰需要的信息，如果没有，就会很快地离开。很少有⽤户愿意花时间去熟悉Web应⽤系统的结构，因此，Web应⽤系统导航帮助要尽可能地准确。
导航的另⼀个重要⽅⾯是Web应⽤系统的页⾯结构、导航、菜单、连接的风格是否⼀致。确保⽤户凭直觉就知道Web应⽤系统⾥⾯是否还有内容，内容在什么地⽅。
Web应⽤系统的层次⼀旦决定，就要着⼿测试⽤户导航功能，让最终⽤户参与这种测试，效果将更加明显。
2、图形测试
在Web应⽤系统中，适当的图⽚和动画既能起到⼴告宣传的作⽤，⼜能起到美化页⾯的功能。⼀个Web应⽤系统的图形可以包括图⽚、动画、边框、颜⾊、字体、背景、按钮等。图形测试的内容有：
（1）要确保图形有明确的⽤途，图⽚或动画不要胡乱地堆在⼀起，以免浪费传输时间。Web应⽤系统的图⽚尺⼨要尽量地⼩，并且要能清楚地说明某件事情，⼀般都链接到某个具体的页⾯。
（2）验证所有页⾯字体的风格是否⼀致。
通用机关零件（3）背景颜⾊应该与字体颜⾊和前景颜⾊相搭配。
（4）图⽚的⼤⼩和质量也是⼀个很重要的因素，⼀般采⽤JPG或GIF压缩。
3、内容测试
内容测试⽤来检验Web应⽤系统提供信息的正确性、准确性和相关性。
信息的正确性是指信息是可靠的还是误传的。例如，在商品价格列表中，错误的价格可能引起财政问题甚⾄导致法律纠纷；信息的准确性是指是否有语法或拼写错误。这种测试通常使⽤⼀些⽂字处理软件来进⾏，例如使⽤Microsoft Word的"拼⾳与语法检查"功能；信息的相关性是指是否在当前页⾯可以到与当前浏览信息相关的信息列表或⼊⼝，也就是⼀般Web站点中的所谓"相关⽂章列表"。
4、整体界⾯测试
整体界⾯是指整个Web应⽤系统的页⾯结构设计，是给⽤户的⼀个整体感。例如：当⽤户浏览Web应⽤系统时是否感到舒适，是否凭直觉就知道要的信息在什么地⽅？整个Web应⽤系统的设计风格是否⼀致？
对整体界⾯的测试过程，其实是⼀个对最终⽤户进⾏调查的过程。⼀般Web应⽤系统采取在主页上做⼀个调查问卷的形式，来得到最终⽤户的反馈信息。
对所有的可⽤性测试来说，都需要有外部⼈员（与Web应⽤系统开发没有联系或联系很少的⼈员）的参与，最好是最终⽤户的参与。
四、客户端兼容性测试
1、平台测试
市场上有很多不同的操作系统类型，最常见的有Windows、Unix、Macintosh、Linux等。Web应⽤系统的最终⽤户究竟使⽤哪⼀种操作系统，取决于⽤户系统的配置。这样，就可能会发⽣兼容性问题，同⼀个应⽤可能在某些操作系统下能正常运⾏，但在另外的操作系统下可能会运⾏失败。
因此，在Web系统发布之前，需要在各种操作系统下对Web系统进⾏兼容性测试。
2、浏览器测试
浏览器是Web客户端最核⼼的构件，来⾃不同⼚商的浏览器对Java，、JavaScript、 ActiveX、 plug-ins或不同的HTML规格有不同的⽀持。例如，ActiveX是Microsoft的产品，是为Internet Explorer⽽设计的，JavaScript是Netscape的产品，Java是Sun的产品等等。另外，框架和层次结构风格在不同的浏览器中也有不同的显⽰，甚⾄根本不显⽰。不同的浏览器对安全性和Java的设置也不⼀样。
测试浏览器兼容性的⼀个⽅法是创建⼀个兼容性矩阵。在这个矩阵中，测试不同⼚商、不同版本的浏览器对某些构件和设置的适应性。
五、安全性测试
Web应⽤系统的安全性测试区域主要有：
（1）现在的Web应⽤系统基本采⽤先注册，后登陆的⽅式。因此，必须测试有效和⽆效的⽤户名和密码，要注意到是否⼤⼩写敏感，可以试多少次的限制，是否可以不登陆⽽直接浏览某个页⾯等。
（2）Web应⽤系统是否有超时的限制，也就是说，⽤户登陆后在⼀定时间内（例如15分钟）没有点击任何页⾯，是否需要重新登陆才能正常使⽤。
（3）为了保证Web应⽤系统的安全性，⽇志⽂件是⾄关重要的。需要测试相关信息是否写进了⽇志⽂件、是否可追踪。
（4）当使⽤了安全套接字时，还要测试加密是否正确，检查信息的完整性。
（5）服务器端的脚本常常构成安全漏洞，这些漏洞⼜常常被⿊客利⽤。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。
六、总结
以上从功能、性能、可⽤性、客户端兼容性、安全性等⽅⾯讨论了基于Web的系统测试⽅法。
基于Web的系统测试与传统的软件测试既有相同之处，也有不同的地⽅，对软件测试提出了新的挑战。基于Web的系统测试不但需要检查和验证是否按照设计的要求运⾏，⽽且还要评价系统在不同⽤户的浏览器端的显⽰是否合适。重要的是，还要从最终⽤户的⾓度进⾏安全性和可⽤性测试。
web页⾯测试注意事项：
Web测试往往不被测试⼈员重视，认为是没有技术含量的体⼒活，本⼈结合⾃⼰的⼯作经验谈谈Web测试中的⼀些注意事项，或许会对⼤家有所帮助。测试过程中主要考虑HTML页⾯、TCP/IP通讯、Internet链接、防⽕墙和运⾏在web页⾯上的⼀些程序（例如，applet、javascript、应⽤程序插件），以及运⾏在服务器端的应⽤程序（例如，CGI脚本、数据库接⼝、⽇志程序、动态页⾯产⽣器）。另外，因为服务器和浏览器类型很多，不同版本差别很⼩，但是表现出现的结果却不同，连接速度以及⽇益迅速的技术和多种标准、协议。当然还可以借助Web测试⼯具对其进⾏⾃动化测试。其它要考虑的如下：
1、服务器上期望的负载是多少（例如，每单位时间内的点击量），在这些负载下应该具有什么样的
性能（例如，服务器反应时间，数据库查询时间）。性能测试需要什么样的测试⼯具呢（例如，web负载测试⼯具，其它已经被采⽤的测试⼯具，web ⾃动下载⼯具，等等）？
2、系统⽤户是谁？他们使⽤什么样的浏览器？使⽤什么类型的连接速度？他们是在公司内部还是外部？
3、在客户端希望有什么样的性能（例如，页⾯显⽰速度？动画、applets的速度等？如何引导和运⾏）？
4、允许⽹站维护或升级吗？
5、需要考虑安全⽅⾯（防⽕墙，加密、密码等）是否需要，如何做？怎么能被测试？需要连接的Internet⽹站可靠性有多⾼？对备份系统或冗余链接请求如何处理和测试？web⽹站管理、升级时需要考虑哪些步骤？需求、跟踪、控制页⾯内容、图形、链接等有什么需求？
6、需要考虑哪种HTML规范？多么严格？允许终端⽤户浏览器有哪些变化？
7、页⾯显⽰和/或图⽚占据整个页⾯或页⾯⼀部分有标准或需求吗？
8、内部和外部的链接能够被验证和升级吗？多久⼀次？
9、产品系统上能被测试吗？或者需要⼀个单独的测试系统？浏览器的缓存、浏览器操作设置改变、拨号上⽹连接以及Internet中产⽣的“交通堵塞”问题在测试中是否解决，这些考虑了吗？
10、服务器⽇志和报告内容能定制吗？它们是否被认为是系统测试的主要部分并需要测试吗？
11、CGI程序、applets、javascripts、ActiveX 组件等能被维护、跟踪、控制和测试吗？rat组合
18、测试⽤的评审需要注意⼀些什么？主要是针对哪些⼈？
专家分析：在国内这个评审这个概念很淡薄，但是却是⽆处不在的。⽐如经常做的代码⾛查、⽴项会议、需求讨论等等其实都是⼀种简化的评审，有的公司把这叫做“头脑风暴”（往往是遇到难题的时候集中⼤家的智慧来冲关）
1、可以评审的东东很多，需求、策略、计划、⽤例、代码.....基本上项⽬中你能想到的东西，都可以拿出来评审。
2、组织评审需要有清晰的⽬的（这个是整个环节中重要的部分），很简单，你⾸先要知道，你需要从这个评审中得到什么？也许是希望被评审东东更加完善，也许是希望增加⼤家交流的机会，甚⾄可能是为了应付上⾯的检查等等。
3、不同⽬的评审，参与⼈员⾃然也随之变化：⽐如，希望需求更加完善的评审，理论⼀切与产品有关的⼈员，⼤到项⽬经理，⼩到⼀线销售⼈员都需要来参加。但是，往往评审的⼈员越多，时间上就越难安排，所以需要结合实际情况来删减。当然，也不是说必须要XX⼈参加的评审才叫评审，⽐如⼀个BA与⼀个客户或开发⼈员私下的⼀次交流，只要做了详细的记录，也可以算作是⼀个评审。
所以，有内容的评审其实是不拘形式的，假如⾮得搞个内审或外审来规范，我只能说那是⾛过场⽽已。
4、在组织评审的细节上，有⼀点很重要：不要在评审过程中“照本宣书”。
很多公司在评审前不做准备，评审时拉个主持⼈上去就对着⽂档、PPT⼀阵读，半天下来，问⼤家有没问题，结果只能是只⾔⽚语。
所以，在评审前最好先做预审，也就是在评审前，给予评审⼈员⼀定的时间，也许是三、两天，也许是⼀星期，让评审⼈员熟悉评审⽬标，并提出⾃⼰的意见，由⼀个统⼀的程序收集起来，在评审中逐⼀解决。这样的效果会好很多。
5、最后说说⽐较规范的评审流程
确定评审⽬标——确定参与⼈员（包括主持⼈、记录员、评审员等）——安排评审时间——预审——
整理预审报告——评审——整理评审报告——作者修改评审⽬标——复审（复审可以⾛简单流程，由各个提建议的评审⼈员查看⾃⼰的建议是否得到合理的修改）——存档
19、测试⽤例的粒度如何界定？碰到功能复杂的测试，应该如何书写测试⽤例？
专家分析：根据需求来定。较复杂的，可以先画出流程图，再进⾏编写测试⽤例。
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议