[你问我来答第20期]：如何编写好的测试用例？(已结束)

楠族开心果

回复 102# 霸王别妖



能不能不回复用引用啊，看到了回复就得上前面看问的内容。
我还在上学，正好有软件测试这门课，我想知道我们有没有必要去深究一下？毕竟多余时间可以用来练习其他代码

即使以后打算走开发路线，也有必要了解一些测试知识。在将来写代码的过程中，会为你提供不少的容错设计思路

楠族开心果

回复 105# baby-julie

我现在在通信行业公司中做测试，涉及到手机终端软件例如米聊，飞信这种软件的测试，还有类似于淘宝这种电子商务网站的测试，我想请教专家一下问题：
1、对于米聊，飞信这种软件如何设计好的测试用例才能保证没有功能遗漏，这种软件如何做性能方面的测试？
2、对于类似于手机版淘宝这种软件，它拥有客户端，服务器端还有一个后台管理系统类似于进销存管理系统，我如何设计测试用例才能保证功能的完全覆盖？他们之间的交互如何设计测试用例？
谢谢

1、如果将兼容性测试划到性能测试中的话，那么米聊，飞信这类第三方的软件功能测试还算是比较简单的，需要注意两点：

1）
.交互。由于很多系统在设计时，并不可能考虑到适应所有的第三方软件。所以当第三方软件与系统本身软件在同时申请资源时，存在较大的风险。

2）
容错。异常处理机制是软件设计的天生缺陷，我们无法在一开始就设计出完美的软件，特别是在容错方面。所以错误推断的用例设计方法通常都是软件设计的命门。

关于性能测试方面，除了上面提到的兼容性测试外，在手机端，还需考虑以下9种性能测试。

长周期测试

响应时间测试

电源管理测试
内存测试
多媒体质量测试
应用程序接口吞吐量测试
耐力测试
负载测试
可靠性测试

而在服务器端，则主要考虑一下6种性能测试

压力测试

负载测试

大数据量测试

配置测试

可靠性测试

并发测试

2、对于复合型的第三方软件，首先需要进行功能拆分，如你所说的，拆分为手持客户端，服务器，后台管理系统三大块。然后再根据每一块的单独设计完整测试类型的用例组。

而针对主体三大功能交互用例组，由于基础交互用例组已经在UI用例组（客户端和后台管理）中设计完成，故目前主要考虑二级以上交互的用例设计。具体设计方法可考虑根据系统资源分配原理，筛选出可同时申请相同类型系统资源的进程或线程，通过组合的方式，设计出交互用例组。如，针对用户元宝余额的数据库，若手机端和后台管理均对此存储块有读写权限，当两者同时申请此块存储地址的权限时，系统是否响应正常。从这一点即构造出新的用户元宝余额的二级交互用例。

楠族开心果

手机测试，在没有任何需求文档的情况下，如何把用例写好？
chaoyue0662 发表于 2012-3-15 14:55

可考虑多借鉴参考样机功能，在设计用例过程中，也可考虑从UI结构图入手设计。

楠族开心果

回复 125# PjiL

我感觉测试用例都可以套用，比如添加功能，我就会很自然的想到1.进入增加功能页面2.页面布局显示3.必填项、非必填项检查4.各字段前中后加入空格5.各字段长度校验6.各字段支持的特殊字符7.各字段输入最大长度，页面显示8.增加内容唯一性验证9.支持tab、enter键10.增加、取消成功11.增加、取消的提示信息12.增加、取消后页面显示，这样下次碰到这样的功能只要再稍加变通了，不知道是否这样学习？

其实目前很多大公司的用例模型也是这样的，单个用例描述一个功能，而每个步骤描述该测试功能的子功能。而在实际执行时，会针对每一个测试步骤都记录执行结果。当一个用例所有步骤都Pass后，整个用例才是Pass.

这样的用例较易于拆分和跟踪问题出现的具体位置。

楠族开心果

做黑盒已经到瓶颈了，现在想转自动化或者性能，求指条明路
ned747id88 发表于 2012-3-19 10:58

你的瓶颈指的是什么个概念？手工功能测试？无论做自动化还是性能，依然需要掌握些黑盒测试基础。建议先静下心来，仔细思考自己的目标及职业发展规划。是否转为自动化或性能就能在预定年限内达到自己的期望。若还未到程度，继续努力，寻找自身欠缺的东西，准备再次提升。

楠族开心果

回复 142# femir
问题：
1、需求范围如何确定？
2、手机助手（91，豌豆荚）测试更注重哪些测试类型，或者说不重视那些测试类型？
3、自动化测试在小公司能不能生存？（QTP），我想往QTP方向走，但是现在公司没有涉及这块？
  请老师指点   谢谢

1．一般情况下，需求基本是开发（部门）经理与客户确定的，测试的可以参与并适当的提出些建议

2．手机测试我没研究过，抱歉不能回答

3．自动化测试小公司也可以生存，主要看你是否愿意去学。如果在公司项目中使用，那需要考虑下成本问题

楠族开心果

回复 143# aspstar

请求专家，面对相对简单、不太规范的业务需求，而且没有详细的开发设计文档，测试人员应该如何做测试。业务需求提出人员在系统开发测试接近尾声后，频繁提出需求变更，测试人员应如何应对？

没有详细文档，测试人员除了加强部门沟通外，其实没有太好的方法来规避风险。若此时测试主管对相关业务设计难度不熟悉的话，那整个测试任务可能无法顺利过渡到中期。

对于项目后期的需求问题，可考虑引入一些流程来规范，如软件入场标准。也可通过与PM/RD沟通，延长项目周期或将风险转嫁给决策人（PM）都是一些常见的处理方式。

楠族开心果

我想问一下 性能测试怎样进进行呢，工具是不是比手工好呢
ranquan 发表于 2012-3-21 17:21

性能用手工测试。。第一次听说，不过确实需要用手点击鼠标、输入代码……

性能测试，常用的开始loadrunner，如何学习，可以去看看云层、于涌的书和博客

楠族开心果

专家：黑盒测试的真正出路在哪？纠结中
zbl0531 发表于 2012-3-21 17:31

可以参考我之前的回答。在这里不再阐述

楠族开心果

怎样去组建和管理一个比较全的通用测试用例库？对于通用的测试用例，如何去进行编写？

帮忙回答一下，谢 ...
sun_0910 发表于 2012-3-22 13:54

这个问题可以去参考各位网友的回答。
http://bbs.51testing.com/viewthread.php?tid=500041&extra=&page=1

楠族开心果

来晚了，但是最近一直有个问题困扰，CS的测试用例怎么样编写才是规范的，
zhangnan080923 发表于 2012-3-15 15:05

CS 业务？这种用例的规范有差异？不太明白。这个涉及面实在广，这里不做解答，有时间的可以进一步交流

楠族开心果

回复 151# Jane70301

庄姐，看到你，很高兴。我的问题不是关于技术，是职业发展方面。我也是做黑盒，所有黑盒经验愈多，就觉得不知以后怎么发展。就像某个行友说的一样，黑盒还是大部分是功能性，设计技术含量似乎不如白盒和性能之类，我也非常困惑。不知能否与你请教你是怎么规划的呢

谢谢，看到你，我也很高兴。个人也觉得黑盒测试技术确实不如白盒、性能。毕竟这些都需要有些开发基础的。

楠族开心果

回复 153# 薰衣草の香


新手，求指教，活了23年了第一次自己想学点东西，上大学是父母的要求，学编程技术纯粹是为了跟风，现在真心想学测试，求高手，求速成方法，23岁了，不小了，貌似真的等不起了，跪求

如果是跟风或者速成的话，劝你别学了。作为一个测试人的话，切记不要浮躁，一定要一步一个脚印踏踏实实的学下去

aspstar

回复  Jane70301
庄姐，看到你，很高兴。我的问题不是关于技术，是职业发展方面。我也是做黑盒，所有黑盒 ...
楠族开心果 发表于 2012-3-31 10:37

谢谢，看到你，我也很高兴。个人也觉得黑盒测试技术确实不如白盒、性能。毕竟这些都需要有些开发基础的。

    专家，您前面不是说自动化和性能也属于黑盒，怎么出说黑盒不如性能测试技术性强，让人感觉很乱啊

楠族开心果

回复 106# 妖娆小妖

刚刚加入黑盒测试的行列，测试计划和测试用例应该怎么部署？测试用例是不是就是自己在测试过程中用到的实例或步骤呢

　　个人认为做好测试计划的编写工作应该从以下几个方面考虑问题：

　　1、要充分考虑测试计划的实用性，即，测试计划与实际之间的接近程度和可操作性。

　　编写测试计划的目的在于充分考虑执行测试时的各种资源，包括测试内容、测试标准、时间资源、人力资源等等，准确地说是要分析执行时所能够调用的一切资源以及受各种条件限制，可能受到的各种影响。说的再明确一点就是要“计划”“如何”去做“测试工作”，而不是“如何编写测试计划”。

　　2、要坚持“5W1H”的原则，明确测试内容与过程。

　　明确测试的范围和内容（WHAT）；

　　明确测试的目的（WHY）；

　　明确测试的开始和结束日期（WHEN）；

　　明确给出测试文档和软件册存放位置（WHERE）；

　　明确测试人员的任务分配（WHO）；

　　明确指出测试的方法和测试工具（HOW）。

　　3、采用评审和更新机制，确保测试计划满足实际需求。

　　因为软件项目是一个渐进的过程，中间不可避免地会发生需求变化，为满足需求变化，测试计划也需要及时地进行变更。

　　之所以采取相应的评审制度，就是要对测试计划的完整性、正确性、可行性进行评估，以保证测试的质量。

　　4、测试策略要作为测试的重点进行描述。

　　测试策略是测试计划中的重要组成部分，测试计划是从宏观上说明一个项目的测试需求、测试方法、测试人员安排等因素，而测试策略则是说明世纪的测试过程中，应该怎样具体实施。因此，测试策略一定要描述详尽并且重点突出。

　　至于测试用例工作，我认为我们首先要明确测试用例在整个测试工作中的地位及其作用。个人认为，测试用例在整个测试工作中的地位和作用主要体现在以下几个方面：

　　1、测试用例是测试执行的实体，是测试方法、测试质量、测试覆盖率的重要依据和表现形式；

　　2、测试用例是团队内部交流以及交叉测试的依据；

　　3、在回归测试中，测试用例的存在可以大大的降低测试的工作量，从而提高测试的工作效率；

　　4、测试用例便于测试工作的跟踪管理，包括测试执行的进度跟踪，测试质量的跟踪，以及测试人员的工作量的跟踪和考核；

　　5、在测试工作开展前完成测试用例的编写，可以避免测试工作开展的盲目性；

　　6、测试用例是说服用户相信产品质量的最佳依据，同时也可以提供给客户作为项目验收的依据。

　当我们认识到测试用例在政工测试工作中的地位及其作用之后，相信大家都已经认识到了测试用例对测试工作的重要性和必要性，那么，我们就来讨论一下如何有效的保证测试用例的质量。

　　1、做好测试人员的项目培训（主要指对需求分析、软件设计、测试计划的认知程度）工作。要想发挥团队中每一个成员的所有能力，最好的办法就是让他们每一个人都清楚这个项目中的所有细节，以及自己要在这个项目中所承担的责任。

　　2、尽可能的利用以往其他项目的测试用例；并将该项目中类似模块进行归类，按类编写测试用例，再根据每个模块的特点进行修改，要充分利用测试用例的可重用性。

　　3、在时间资源紧张的情况下，可以按照测试的关键路径编写测试用例，针对关键路径的测试用例一定要详尽，其他边缘模块的测试用例可以考虑仅通过性测试（既仅证真测试）。

　　4、采用针对测试用例的模块化编写。个人建议将测试用例和测试数据分开，测试用例中的操作步骤应主要体现于业务流程的检验，而测试数据主要体现于针对系统的数据处理结果的检验。考虑到软件项目的需求变更问题，建议将这两项分开，通过测试用例编号进行关联，以应对需求变化造成的测试用例的修改，从而减少测试用例的修改量，缩短项目周期，提高工作效率。

　　以上是个人见解，如有不同意见，请大家及时指出和补充。

楠族开心果

专家，您前面不是说自动化和性能也属于黑盒，怎么出说黑盒不如性能测试技术性强，让人感觉很乱啊
aspstar 发表于 2012-3-31 11:05

这个并不矛盾。自动化、性能测试是需要掌握了些黑盒测试基础上进行的。性能、自动化都需要掌握些脚本开发技术，自然而然要比黑盒技术要求来的高

楠族开心果

if(a>0||b30)测试用例的总数？
我是新手，最好把分析过程写得详细些，非常感谢
xullnscc 发表于 2012-3-15 17:35

可以参考：http://bbs.51testing.com/viewthread.php?tid=533885&extra=&page=6 118楼的回答

楠族开心果

回复 154# femir

测试用例的字段越多越好你怎么看？
随着测试的回归，bug数越来越少，怎样才能写出发现至今还没有发现的bug用例？

不是说测试用例字段越多越好。如果写点无关的，你觉得好吗？测试用例主要还是精确并详细为准。

写出发现至今还没有发现的bug用例，这个几乎办不到。至今为止，没有任何一款软件自称没有bug的。

楠族开心果

WEB页面测试有哪些方面？重点在哪里？需要注意的有哪些？测试用例的方向在哪边？请版主指导！
link0313 发表于 2012-3-26 11:01

基于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 组件等能被维护、跟踪、控制和测试吗？

楠族开心果

庄姐，对于pos机怎么设计测试用例，测试的重点在哪里；需要注意那些地方呢 ？
天使V3坠落 发表于 2012-3-26 13:10

可参考http://bbs.51testing.com/thread-12531-1-1.html的回答