游戏测试的设计评审
在设计评审时,测试人员的介入可以充分的对当前的系统构架发表自己的意见,由于测试人员的眼光是最苛刻的,并且有多年的测试经验,可以比较早的发现曾经出现的设计上的问题,比如在玩家转换服务器时是否作了事务的支持与数据的校验,在过去设计中由于没有事务支持与数据的校验从而导致玩家数据丢失,而这些风险可以在早期就规避掉。
上面所说的是对游戏程序本身的测试设计,对于游戏情节的测试则可以从策划获得,由于前期的策划阶段只是对游戏情节大方向上的描述,并没有针对某一个具体的情节进行设计,进入设计阶段时,某个游戏情节逻辑已经完整的形成了,策划可以给出情节的详细设计说明书,称为任务说明书,通过任务说明书我们可以设计出任务测试案例,比如某一个门派的任务由那些组成,我们可以设计出完整的任务测试案例,从而保证测试可能最大化的覆盖到所有的任务逻辑,如果是简单任务,还可以提出自动化需求,采用机器人自动完成。
集成测试阶段:集成测试是对整个系统的测试。
由于前期测试与开发的并行,集成测试已经基本完成,这时只需要对前期在设计阶段中设计的系统测试案例运行一下就可以。
我们主要的重心在集成测试中的兼容性测试,由于游戏测试的特殊性,对兼容性的要求特别高,所以我们采用了外部与内部同部进行的方式,内部我们有自己的平台试验室,搭建主流的硬软件测试环境,同时我们还通过一些专业的兼容性测试机构对我们的游戏软件做兼容性分析,让我们的游戏软件可以跑在更多的机器上。
在团队中若是有资深的测试人员要具备的一项基本的素质就是可以针对UML的用例图,时序图,状态图来设计出重要系统的测试案例,只有重要系统的质量得到充分的测试,游戏程序的质量才可以得到充分的保证。
一个用户登陆游戏系统的时序图。
从这里我们可以很明确的了解玩家是如何验证并登陆系统的,在这个过程中要与那些对象进行交互,比如这里我们就是三个系统之间的交互,客户端(玩家部分),网关,账号服务之间的一个时序变化关系,为了能够完整的对这个流程进行测试,我们必需设计出可以覆盖整个流程的测试案例,并考虑其中可能的非法情况,因为这个时序图只是考虑了用户正常登陆成功的情况,并没有考虑密码错误,通信失败等许多可能存有的情况,并形成完整的测试案例库,从而对登陆系统的系统化测试做了充分的准备。
同时通过这张图,性能分析人员还可以分析出可能存的性能瓶颈,比如这里可能有的瓶颈如下,总网关是否可以达到多少用户的并发,是如果达不到,是否可以采用分布式部署或是支持负载平衡,三者之间的网络带宽的比例分配,账号服务器是否可以承载多个网关的连接请求,最大连接请求可以达到多少等等,同时会针对这些风险做性能测试的设计,并提出自动化测试的需求,比如模拟玩家登陆的压力工具等等。
性能测试与优化:最后要单独提一下的是性能优化,在单机版的时代,性能的要求并不是很高,但是在网络版的时代,则是两个完全不同的概念,主要包含了以下几个方面:应用在客户端性能的测试、应用在网络上性能的测试和应用在服务器端性能的测试。
通常情况下,三方面有效、合理的结合,可以达到对系统性能全面的分析和瓶颈的预测。
不过在测试过程中有这样一个原则,就是由于测试是在集成测试完成或接近完成时进行,要求测试的功能点能够走通,这时你首先要进行优化的是数据库或是网络本身的配制,只有这样才可以规避改动程序的风险。
同时性能的测试与优化是一个逐步完善的过程,需要前期的很多的工作,比如性能需求,测试工具等等,不过由于前期工作的完善,这些都在前期完成了。
测试过程不可能在真空中进行。
如果测试人员不了解游戏是由那几个部分组成的,那么执行测试就非常的困难,同时测试计划可以明确测试的目标,需要什么资源,进度的安排,通过测试计划,既可以让测试人员了解此次游戏测试中那些是测试重点,又可以与产品开发小组进行交流。
在企业开发中,测试计划书来源于需求说明文档,同样在游戏开发过程中,测试计划的来源则是策划书。
策划书包含了游戏定位,风格,故事情节,要求的配制等等。
从里面了解到游戏的组成,可玩性,平衡(经济与能力),与形式(单机版还是网络游戏),而测试在这一阶段主要的事情就是通过策划书来制定详细的测试计划,主要分两个方面一是游戏程序本身的测试计划,比如任务系统,聊天,组队,地图等等由程序来实现的功能测试计划,二是游戏可玩性有测试计划,比如经济平衡标准是否达到要求,各个门派技能平衡测试参数与方法,游戏风格的测试,三是关于性能测试的计划,比如客户端的要求,网络版的对服务器的性能要求。
同时测试计划书中还写明了基本的测试方法,要设计的自动化工具的需求,为后期的测试打下良好的基础。
同时由于测试人员参与到策划评审,对游戏也有很深入的了解,会对策划提出自己的看法,包含可玩性,用户群,性能要求等等并形成对产品的风险评估分析报告,但这份报告不同于策划部门自己的风险分析报告,主要从旁观者的角度对游...
软件开发的基本介绍
1.概念 需求的定义包括从用户角度(系统的外部行为),以及从开发者角度(一些内部特性)来阐述需求. 关键的问题是一定要编写需求文档.我曾经目睹过一个项目中途更换了所有的开发者,客户被迫与新的需求分析者坐到一起.系统的分析人员说:"我们想与你谈谈你的需求."客户的第一反应便是:"我已经将我的要求都告诉你们前任了,现在我要的就是给我编一个系统". 百事通 而实际上,UGGs,需求并未编写成文档,因此新的分析人员不得不从头做起.所以如果只有一堆邮件、会谈记录或一些零碎的未整理的对话,你就确信你已明白用户的需求,那完全是自欺欺人. 需求的另外一种定义认为需求是"用户所需要的并能触发一个程序或系统开发工作的说明".有些需求分析专家拓展了这个概念:"从系统外部能发现系统所具有的满足于用户的特点、功能及属性等".这些定义强调的是产品是什么样的,而并非产品是怎样设计、构造的.而下面的定义则从用户需要进一步转移到了系统特性: 需求是指明必须实现什么的规格说明.它描述了系统的行为、特性或属性,是在开发过程中对系统的约束. 从上面这些不同形式的定义不难发现:并没有一个清晰、毫无二义性的"需求"术语存在,真正的"需求"实际上在人们的脑海中,这个人们主要是指客户,但一般情况下,用户并不能描述自己的需要,只就需要系统分析人员根据用户的自己语言的描述整理出相关的需要再进一步和客户核对.系统分析员和客户需要确保所有项目风险承担者在描述需求的那些名词的理解上务必达成共识. 任何文档形式的需求(例如如下将要描述的需求规格说明书)仅是一个模型,一种描述. 2.需求分析的任务 开发软件系统最为困难的部分就是准确说明开发什么.最为困难的概念性工作便是编写出详细技术需求,这包括所有面向用户、面向机器和其它软件系统的接口.同时这也是一旦做错,将最终会给系统带来极大损害的部分,并且以后再对它进行修改也极为困难. 目前,国内产品的庞杂,一家企业可能有几个系统并立运行,它们之间接口是系统开发人员最头痛的问题. 对于商业最终用户应用程序,企业信息系统和软件作为一个大系统的一部分的产品是显而易见的.但是对于我们开发人员来说,并没有编写出客户认可的需求文档,我们如何知道项目于何时结束?而如果我们不知道什么对客户来说是重要的,那我们又如何能使客户感到满意呢? 然而,即便并非出于商业目的的软件需求也是必须的.例如库、组件和工具这些供开发小组内部使用的软件.当然你可能偶尔勿需文档说明就能与其他人意见较为一致,但更常见的是出现重复返工这种不可避免的后果,而重新编制代码的代价远远超过重写一份需求文档的代价,这些血的教训正在国内的软件开发者身上发生. 近来,我遇到一个开发小组开发包括代码编辑器在内的一套内部使用的计算机辅助软件.不幸的是,当他们开发完这个工具后,发现这个工具不能打印出源代码文件,使用者当然希望有这个功能.结果这个小组只好手工抄写源代码文档以供代码检查.这说明那怕需求明确无误并构思准确,如果我们没有编写文档,软件达不到期望目标也只能是咎由自取了. 相反的情况,我曾见一个要集成到"错误跟踪系统"中的简单界面写了一页需求说明.而操作系统系统管理员在为处理脚本时发现简单的一张需求清单竟是如此有用.他们依据需求对系统进行测试时,此系统不仅非常清晰地实现了所有必需功能,而且未发现任何错误. 事实上,需求文档在开发过程中一直起指导作用. 3.需求分析过程 可把整个软件需求工程研究领域划分为需求开发和需求管理两部分更合适,如图4-1所示: 图4-1 需求工程域的层次分解示意图 需求开发可进一步分为:问题获取、分析、编写规格说明和验证四个阶段.这些子项包括软件类产品中需求收集、评价、编写文档等所有活动.需求开发活动包括以下几个方面: 确定产品所期望的用户类别. 获取每个用户类的需求. 了解实际用户任务和目标以及这些任务所支持的业务需求. 分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息. 将系统级的需求分为几个子系统,并将需求中的一部份分配给软件组件. 了解相关质量属性的重要性. 商讨实施优先级的划分. 将所收集的用户需求编写成文档和模型. 评审需求规格说明,确保对用户需求达到共同的理解与认识,并在整个开发小组接受说明之前将问题都弄清楚. 需求管理需要"建立并维护在软件工程中同客户达成的合同" .这种合同都包含在编写的需求文档与模型中.客户的接受仅是需求成功的一半,开发人员也必须能够接受他们,并真正把需求应用到产品中.通常的需求管理活动包括: 定义需求基线(迅速制定需求文档的主体). 评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它. 以一种可控制的方式将需求变更融入到项目中. 使当前的项目计划与需求一致. 估计变更需求所产生影响并在此基础上协商新的承诺,这种承诺具体体现在项目解决方案上. 让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪. 在整个项目过程中跟踪需求状态及其...
软件测试师
女孩子做软件软件测试的还是比较多.这个行业可以让女人工作没那么累.要想学软件测试 可以在网上找一些书看看. 软件测试教程. 软件测试技术.在看点文档.和一些测试模板.在下载些简单的工具.去找工作估计没什么问题了.QTP, silktest 或是 lr 都可以. www.rjzl.gov.cn照大纲复习了.上网找一些最新资料 一、考试说明 1.考试要求: (1) 掌握数据表示、算术和逻辑运算; (2) 掌握相关的应用数学、离散数学的基础知识; (3) 掌握计算机体系结构以及各主要部件的性能和基本工作原理; (4) 掌握操作系统、程序设计语言的基础知识,了解编译程序的基本知识; (5) 熟练掌握常用数据结构和常用算法; (6) 熟悉数据库、网络和多媒体的基础知识; (7) 掌握C程序设计语言,以及C++、Java、Visual、Basic、Visual C++中的一种程序设计语言; (8) 熟悉软件工程、软件过程改进和软件开发项目管理的基础知识; (9) 熟悉掌握软件设计的方法和技术; (10) 掌握常用信息技术标准、安全性,以及有关法律、法规的基本知识; (11) 了解信息化、计算机应用的基础知识; (12) 正确阅读和理解计算机领域的英文资料。
2.通过本考试的合格人员能根据软件开发项目管理和软件工程的要求,按照系统总体设计规格说明书进行软件设计,编写程序设计规格说明书等相应的文档,组织和指导程序员编写、调试程序,并对软件进行优化和集成测试,开发出符合系统总体设计要求的高质量软件;具有工程的实际工作能力和业务水平。
3.本考试设置的科目包括: (1) 计算机与软件工程知识,考试时间为150分钟,笔试; (2) 软件设计,考试时间为150分钟,笔试。
二、考试范围 考试科目1:计算机与软件工程知识 1.计算机科学基础 1.1 数制及其转换 · 二进制、十进制和十六进制等常用制数制及其相互转换 1.2 数据的表示 · 数的表示(原码、反码、补码、移码表示,整数和实数的机内表示,精度和溢出) · 非数值表示(字符和汉字表示、声音表示、图像表示) · 校验方法和校验码(奇偶校验码、海明校验码、循环冗余校验码) 1.3 算术运算和逻辑运算 · 计算机中的二进制数运算方法 · 逻辑代数的基本运算和逻辑表达式的化简 1.4 数学基础知识 · 命题逻辑、谓词逻辑、形式逻辑的基础知识 · 常用数值计算(误差、矩阵和行列式、近似求解方程、插值、数值积分) · 排列组合、概率论应用、应用统计(数据的统计分析) · 运算基本方法(预测与决策、线性规划、网络图、模拟) 1.5 常用数据结构 · 数组(静态数组、动态数组)、线性表、链表(单向链表、双向链表、循环链表)、队列、栈、树(二叉树、查找树、平衡树、线索树、线索树、堆)、图等的定义、存储和操作 · Hash(存储地址计算,冲突处理) 1.6 常用算法 · 排序算法、查找算法、数值计算方法、字符串处理方法、数据压缩算法、递归算法、图的相关算法 · 算法与数据结构的关系、算法效率、算法设计、算法描述(流程图、伪代码、决策表)、算法的复杂性 2.计算机系统知识 2.1 硬件知识 2.1.1 计算机系统的组成、体系结构分类及特性 · CPU和存储器的组成、性能和基本工作原理 · 常用I/O设备、通信设备的性能,以及基本工作原理 · I/O接口的功能、类型和特性 · I/O控制方式(中断系统、DMA、I/O处理机方式) · CISC/RISC,流水线操作,多处理机,并行处理 2.1.2 存储系统 · 主存-Cache存储系统的工作原理 · 虚拟存储器基本工作原理,多级存储体系的性能价格 · RAID类型和特性 2.1.3 安全性、可靠性与系统性能评测基础知识 · 诊断与容错 · 系统可靠性分析评价 · 计算机系统性能评测方式 2.2 软件知识 2.2.1 操作系统知识 · 操作系统的内核(中断控制)、进程、线程概念 · 处理机管理(状态转换、共享与互斥、分时轮转、抢占、死锁) · 存储管理(主存保护、动态连接分配、分段、分页、虚存) · 设备管理(I/O控制、假脱机) · 文件管理(文件目录、文件组织、存取方法、存取控制、恢复处理) · 作业管理(作业调度、作业控制语言(JCL)、多道程序设计) · 汉字处理,多媒体处理,人机界面 · 网络操作系统和嵌入式操作系统基础知识 · 操作系统的配置 2.2.2 程序设计语言和语言处理程序的知识 · 汇编、编译、解释系统的基础知识和基本工作原理 · 程序设计语言的基本成分:数据、运算、控制和传输,过程(函数)调用 · 各类程序设计语言主要特点和适用情况 2.3 计算机网络知识 · 网络体系结构(网络拓扑、OSI/RM、基本的网络协议) · 传输介质、传输技术、传输方法、传输控制 · 常用网络设备和各类通信设备 · Client/Server结构、Browser/Server结构 · LAN拓扑,存取控制,LAN的组网,LAN间连接,LAN-WAN连接 · 因特网基础知识以及应用 · 网络软件 · 网络管理 · 网络性能分析 2.4 数据库知识 · 数据库管理系统的功能和特征 · 数据库模型(概念模式、外模式、内模式) · 数据模型,ER图,第一范式、第二范式、第三范式 · 数据操作(集合运算和关系运算) · 数据库语言(SQL) · 数据库的控制功能(并发控制、恢复、安全性、完整性) ...
如何审核基于电子版(文件)的管理体系
当前,越来越多的组织正日益依赖于电子媒介,用于其管理体系的运行与控制。
这意味着认证机构及其审核员必须考虑新的审核方法,以确保审核是有效的。
ISO9001审核实践组认为过程审核方法和与之相关的文件、记录必须被重新考虑。
首先,请回答下列选择题,测试一下你的相关知识(正确答案在本文的最后) 1、电子版的管理体系是什么? a) 一个用来管理审核的由认证机构建立的体系。
b) 一个允许审核在非现场进行的体系(例如:通过审核员的个人电脑进行审核)。
c) 一个依赖于应用日常运行的电子版本文件、数据和软件的体系。
d) 以上所有选项。
2、在策划一次电子版本管理体系的审核时,你应该考虑: a) 审核组如何获得电子版管理体系?b) 安全装置,以确保审核员保护电子版文件的保密性。
c) 受审核方用于其信息技术基础设施的方针。
d) 以上所有选项。
3、为了确认是否符合过程要求,你发现一些审核时间必须要花在一台计算机工作站上,这台计算 机工作站又不在实际过程的附近。
在这种情况下,你应该: a) 作为不合格项,显著标明这个位置。
b) 在这个过程的实际地点上,减少实际审核时间。
c) 允许额外用于到这个过程的实际现场的路途时间。
d) 以上所有选项。
4、当审核电子版文件的控制时,你应该: a) 确保所有文件是同一格式的,例如:文本格式、超文本链接标示语言或可移植文档格式。
b) 了解组织对有关使用者授权的方针和程序。
c) 确保在电子版管理体系内有效的文件都被控制了。
d) 以上所有选项。
5、当评审组织的信息技术功能起作用时,就应该考虑: a) 外部和内部软件的控制。
b) 环境方面与电子版管理体系有联系。
c) 人员有能力操作硬件和软件。
d) 以上所有选项。
(一)策划审核一个电子版管理体系 一个组织可能有一个适当的依赖于电子版文件、数据和软件的管理体系,这些文件、数据和软件应用在其日常的运行中。
这就是人们所知道的电子版管理体系(EBMS)。
在审核的初级阶段(第一阶段审核),审核员必须确定要审核的组织结构,以及电子版管理体系的范围。
例如:它可能是一个集中的电子版管理体系的多现场的组织,或者是一个虚拟组织。
因此,审核员应该确认,在组织的方针和程序中,是否已恰当地陈述并建立了对一个多现场管理体系的控制。
审核员检查单 l 确保审核组有机会去熟悉受审核方的电子版管理体系;l 评审受审核方应用在其信息技术基础设施的方针;l 评审访问记录的作业指导书,获得必要的忠诚调查;l 检查是否有安全装置,以确保审核员能够保护电子版文件的保密性;l 检查审核组对电子版管理体系开展一个有效的审核的能力,有关通用信息技术趋势和审核组应该提供的培训;l 确保在非现场进行了文件评审,而不是在线进行的,或通过电子邮件下载收到的文件;如果从技术或安全方面不允许这么做,那么对电子版文件的评审就需要在第一阶段的审核过程中,在受审核方的设备上进行。
(二)现场实现活动 典型的审核员的追踪应该包括被审核过程的实际现场。
在很多情况下,对于一个电子版管理体系(EBMS),确认其是否符合标准要求所需的时间,可能需要花在一台计算机工作站上,这台计算机工作站又不在实际过程的附近。
这样,在过程的实际现场的实际审核时间可以减少,并且要有特殊的考虑,即要考虑到去这个过程的实际现场的路途时间。
审核员应该评价在实际过程和电子媒介在使用方法上的交互作用,以确保相关信息的正确性。
(三)审核电子版文件的控制 电子版文件建立的管理体系方针和程序能够以各种格式存在,例如:文本格式、超文本链接标示语言或可移植文档格式等等。
电子制表软件和数据库也可被认为是电子版文件,都要作为管理体系的控制因素进行审核。
审核员检查单 l 在大体上,确保适用于对管理体系书面文件的控制管理方针,同样也适用于电子版文件;l 确认在电子版环境内是否有有效的方法,以确保管理体系文件适当的评审、批准、发布和分发;l 了解特殊适用的控制范围,这些也被用来作为一个符合管理体系标准的依据; l 特别关注于控制因素,例如:文件级别和文件版本识别;l 确认已经考虑了应用于对作废文件管理的控制方法;l 对于与电子版文件相关的功能和控制因素,确认电子版管理体系文件(EBMS)的存在为使用者提供了一个方向;l 了解组织有关使用者权力的方针和程序;l 确认与第三方交换的电子版本文件的程度,这些第三方是否已在电子版本管理体系中被介绍了且受控了。
(四)审核对电子版本记录的控制 电子版本的记录包括电子版过程输出数据。
电子表格的控制因素不必与电子版本记录的控制一致。
例如:在电子表格的情况下,关于识别条件需要参照电子表格自身的分类。
当识别是电子版本记录时,那就参照为设定的数据,而使用的唯一的电子表格。
组织的绩效数据可能差不多完全是电子版的记录,审核员应该评审组织用于保护以电子版本方式保留的信息的方法。
有关信息安全的更多信息可参照ISO/IEC 17799:2005。
(五)信息技术组织资源 由于组织转而使用一个电子版管理体系(EBMS),那么信息技术功...
品管员是干什么职业
品管员:工业术语是"产品质量管理员"、"商品管理员"的简称,指负责产品质量控制,质量体系建立和运行,生产质量监督,以及与上级质量监督检验局的接洽事宜进行组织,执行,实施的工作人员。
一、品管员主要职责如下:1、 参与维护、监督质量体系的运行、组织和管理内部质量审核工作;2、根据检验计划完成当日首件、巡检工作任务;3、确认生产单位的自检记录;4、按相应流程对待检产品进行检验,检验前以及检验过程中认真核对产品代码、名称,填写检验记录,并提交品管组长;5、汇总、存档各项质检记录及相关资料;6、为纠正质量问题,有权暂时停止现场生产,并立即向上级报告;7、中晚班人员如遇一般外观不良,有权停止现场生产,如遇紧急生产或修模,可电话联络上级作决定;8、 现场不合格产品的确认,初步处理;9、不合格品处理单和纠正预防措施表的开出,追踪和验证;10、不合格品处理单和纠正预防措施表做好登录,以便追踪;11、及时上报批量质量问题,不合格信息的及时传递;12、向下一班交接检验用具和生产注意点;13、 协助质量主管完成其它质量管理体系方面的工作。
二、品管员行使权限如下:1、对生产现场质量问题全面负责监督检查;2、对生产中出现的质量问题进行分析,并提出解决方案,及时上报部门主管处理;3、对于半成品或库存品,有权进行抽样检查,并要求返工;4、对于不合格的矿石原料、材料配件、酸碱药剂、包装标识,有权要求整改退换;5、对生产现场设备、工具、物料和环境脏、乱、差现象,有权要求相关班组按要求整改。
软件开发各阶段测试主要针对查找什么类型的缺陷?
这个还是可以谈一谈的,不要一棍子打死嘛。
不过作者明显没有全过程的测试经验,而要写一些理论性的文章。
一般软件开发的生命周期遵循以下几个阶段:需求,设计,开发和测试。
那么,测试在各个阶段的具体实现是不同的。
需求阶段,测试侧重于考察需求对业务的支持。
体现在对需求规格说明书中的,业务流程,子系统划分,用户用例,状态图,数据流图等的测试,主要是业务分析测试;当然,目前很多公司由于测试团队能力不足,只能执行文档测试,找点儿文档编写方面的缺陷,以及可测性方面的缺陷。
系统功能测试计划,用例在需求阶段可以同时编写。
设计阶段,测试侧重于考察设计对需求的支持。
体现在对设计文档中的数据结构,内部外部接口定义等内容的同行评审。
另外,测试驱动开发,则要求在接口文档产生后,编写接口测试的计划和用例。
开发阶段,测试人员可以编写单元测试用例,单元测试脚本等。
这时候也应当进行代码走查和结对开发。
这个阶段测试侧重于考察代码对设计的准确实现,因此基本都是对代码本身的测试。
另外在开发阶段的中后期,开始集成测试,前面写的接口测试用例和脚本在这里都会使用。
该测试主要是用来验证系统正确集成,功能可用。
测试阶段,系统已经集成完毕或者基本稳定,系统被放到模拟生产环境中进行系统测试,在需求阶段编写的系统测试用例可以实施。
这个阶段主要是确认业务流程可以完整实施。
一般情况下,国内只有在这个阶段才开始性能/稳定性/兼容性/可用性/安全性测试。
而事实上,在前面描述的各个阶段,这些内容都应当在评审或者测试的范围内。
在这之后,就是交付甲方的UAT,之后是商业BETA等等阶段。
这些阶段是各种测试的混合,但是最核心的是系统的业务完整性,系统安全性和系统可用性这三个方面。
在需求阶段前,是立项-投标阶段,实际上,呵呵,这个阶段同样有测试存在,主要是同行评审,技术委员会实施的。
总而言之,软件测试这个东西,只是产品质量保证体系中的一部分,在CMMI中属于验证和确认实践。
验证和确认实践中除了软件测试,就是同行评审。
越是前期工作,同行评审的比重越大,测试的比重越小;越是后期,前者越小,后者越大。
我前文是混淆了测试和评审,用广义的验证和确认更加准确。