测试计划十篇

测试计划篇1

下面一共有三个部分的测试题，每个部分有10个问题，你可以选择“是”、“也许侑时”或“否”来回答。答 “是”加10分，答“也许／有时”得5分，答“否”得O分，最后分别计算总分。根据你的得分情况，我们已经为你度身定制了一个新年调理计划，依计行事，肯定能让你常保交际健康。

测试一　自信心爆棚还是自卑心笼罩？

1．和朋友相比，你觉得自己对父母更孝顺吗?

2．和其他家庭成员相比，你是否觉得自己对家庭的贡献最大?

3．你的工作取得了成功，主要原因是你努力勤奋或者天赋出众吗?

4．面对难题，只要你愿意，就一定可以找到解决方案吗?

5．购物时，你总能买到价廉物美的东西吗?

6．你觉得自己的衣着品位比朋友高一筹吗?

7．玩牌时，你会指责牌友吗?

8．你觉得自己要比大多数人聪明一点点吗?

9．要是你来做老板，你会比他干得更好吗?

10．你对社会焦点问题的看法往往是符合社会主流观点的吗?

这一组题目测试的是你的交际心理，诊断如下：

70-100 亚健康

你在人际交往中处于超强自信状态。在获得成绩以后，你会把功劳归于自己，乐于接受各种荣誉，并认为这是理所当然的；在遭受挫折时，则把失败归咎于他人以推托责任。你认为自己看待世界的方式是最正常的，别人也应该和你保持一致。你觉得自己的才智和品德是异乎寻常的，一些很困难的事情，即使别人都失败了，你也可能获得成功。

你要认识到：

1.不管你是不是天才，人人都讨厌永远不会犯错，动辄对别人指手画脚的人。

2．每个人的思想观点和生活方式都值得尊重，不要把自己的标准强加于人。

新年调理计划：

在新的一年里，你可以完成以下三件事

1.每次做完一件事，就把一张白纸一折为二，在一边写上自己的原因，在另一边写上别人的原因，这样有助于你客观地评价自己。

2．每天自嘲三次，嘲笑别人是刻薄，嘲笑自己就是幽默，先拿自己开涮吧!

3.给自己的交际活动录一段音，找出那些自我膨胀的话语，如“这事我在行”，“要是我来做就没问题了”，“这件事不怪我”，“你怎么就不能像我一样呢”……努力“消灭”它们。

35-65 健康

恭喜!你对自己的评价是客观的，在交际中你总能摆正自己的位置。

0-35 亚健康

你在人际交往中处于不自信状态。你总是认为别人比自己强，因而养成了万事依赖他人的习惯。在任何场合你都依附别人的观点，没有自己的想法，有时难免被人利用。你常常觉得自己一无是处，心情非常沮丧，但独当一面的机会来临时，又会犹豫不决，最后总是临阵脱逃。

你要认识到：

1.天生我材必有用，你肯定有比别人强的方面。2要对自己充满信心，否则别人怎么会对你有信心呢?

新年调理计划

在新的一年里，你可以完成以下三件事：

1．在征求家人、朋友的意见后，对自己的才能做一个正面评价，然后写下来，情绪低落时看一看，给自己一个良好的心理暗示。

2.每天独立完成一件事，事无大小(可以是购物、看电影、逛街)，但要坚持。

3．每次完成一个工作都小小庆祝一下，请客吃饭或者分发一些小礼物，和别人分享成功能使你自信十足，并且对更大的成功充满希望。

测试二　交际过度还是交际匮乏

1．每次在街上遇到一个熟人，你都要聊十分钟以上吗?

2.参加婚宴，餐桌上很沉闷，你会主动挑起一个话题吗?

3.一个人坐长途车，你会主动和邻座聊天吗?

4．每次同学聚会你都参加吗?

5.每周都要和朋友或同事共进晚餐吗?

6．你每天拨打的电话超过10个吗?

7．出门忘带手机就浑身不自在吗?

8.别人给你的有趣E-mail你每次都转发吗?

9．经常给别人做媒吗?

10．在集体活动中做过主持人吗?

这一组题目测试的是你的交际心理，诊断如下：

70-100 亚健康

这一组题目测试的是你的交际心理，诊断如下：你热情外向，口齿伶俐，人缘很好，是一个天生的外交家。在陌生的环境中，总可以在第一时间交到新朋友。每一次朋友聚会都不能离开了你，否则各种活动都会逊色不少。但你投人在社交活动中的精力和时间过多了一点，常常被人讥笑为“言语的巨人，行动的侏儒”。

你要认识到：

1．“交际过度”会使你失去和家人的情感交流，同时会使你觉得时间总是不够用，经常不能做自己喜欢的事。2、有时候沉默是最有力的交际武器，孤独也是可以用来享受的。

新年调理计划

在新的一年里，你可以完成以下三件事：

1．独身旅游一次，多欣赏自然历史之美妙，这是一种和天地、历史、文化的交际。

2.每月至少阅读一本书，这是和古今中外名人的交际。

3．每天回顾做的事情和说的事情，不断总结，让做实事的时间超过说空话的时间。

35-65　健康

恭喜!你的交际态度是合宜的，面对不同交际场景你总能找到合适的交际态度。

0-35　亚健康

你是一个沉默寡言的人，喜欢孤独，也许沉溺于虚拟的网络世界。你可能认为家人最重要，家是最让人舒服的地方。朋友很少，从不公开表达自己的意见，厌恶参加社交活动。别人误解你，你也懒得和他们解释。在公众场合往往更显得紧张，一开口经常结结巴巴。

你要认识到：

1．朋友多一个好一个，即使是泛泛之交，也随时有可能为你提供重要的帮助。

2．请相信你的想法很有意思，和别人交流意见很重要。

新年调理计划

在新的一年里，你可以完成以下三件事：

1．参加更多的集体活动，比以往至少多一倍。更重要的不是次数，而是要在每一次活动中寻找属于自己的乐趣。

2．交更多的朋友，在通讯录上至少增加20个人的联系方式。

3.每次集体讨论都大胆地说出自己的想法。

测试三　语无伦次和索然无味？

1．在公开发言的时候，是不是经常声音颤抖、不知所云呢?

2．在参加讨论时，是不是想开口但总是找不到好的时机?

3．和别人沟通时，常常因为表达不清而遭人误解吗?

4.经常听不懂别人的言外之意，以至于搞错别人的用意吗?

5．每次聊起自己感到有趣的事情，别人总是不以为然吗?

6．回应自己不感兴趣的邀请时，经常得罪邀请者或者只好违心地：

7.经常自以为说的是真心话却反而得罪人吗?

8．和陌生人交往，经常说不上几句就冷场吗?

9．经常被推销员打动，买下一些事后后悔的东西吗?

10．别人对你的评价是“人还不错，就是不会说话”吗?

这一组题目测试的是你的交际心理，诊断如下：

60-100　亚健康

这一组题目测试的是你的交际心理，诊断如下：你为说话问题而苦恼，经常说错话，弄错别人的意思。不知什么原因，你总是在不恰当的场合说出不恰当的话语，因而成为别人嘲笑的对象。在你嘴里，简明的道理乱成一团浆糊，精彩的经历让人摸不着头脑，好玩的笑话变得味同嚼蜡。

你要认识到：

1.说明事件要按照时间顺序，注意精彩的细节：说明道理要按照因果顺序，注意逻辑连贯：说明计划要按照轻重顺序，注

意依次展开。2．有些话语是有言外之意的，它们比字面意义更重要。

新年调理计划

在新的一年里，你可以完成以下三件事：

1．每次游玩归来都把最精彩的事件告诉别人，不妨打一下腹稿，一次失败就换一个人再试，直到听众听得津津有味为止。

2.观看电视访谈节目，阅读访谈文章，领会其中的问答技巧，在潜移默化中提升交际水平。

3.找一些情景喜剧或话剧的剧本，把一些有弦外之音的对话找出来。在聆听别人交谈时，注意捕捉这样的隐含意义：在自己说话时，也尝试着使用这样的含蓄语言。

0-60　健康

首先要恭喜你已经拥有了良好的言谈技巧!

你要认识到：

交际技巧没有最好，只有更好，如果你还需要进一步提高的话，可以从两方面人手：1提高公开演讲能力，虽然对公开演讲感到紧张是人之常情，但要成为一个社交家，这是必须要过的一关。2．提高身体语言表达能力。有很多意见并不需要滔滔不绝的宏篇巨论才能表达，很多时候，只要一丝微笑、一个手势、一种身姿就行了。

新年调理计划

在新的一年里，你可以完成以下三件事：

1．多欣赏话剧和哑剧，话剧演员的面部表情和哑剧演员的身体动作完全脱离语言就“说出”了复杂的意思，这是最高级的

交际技巧。

测试计划篇2

关键词：卓越工程师；软件测试技术；教学改革；教学方法

0 引言

“卓越工程师教育培养计划”（简称卓越计划）是教育部为贯彻落实《国家中长期教育改革和发展规划纲要（20113—2020年）》和《国家中长期人才发展规划纲要（2010—2020年）》而设立的重大改革项目。该项目旨在培养一批创新能力强、适应经济社会发展需要的高质量工程技术人才。在计算机科学与技术学院软件工程专业卓越T程师的培养计划中，软件测试技术是该专业的一门核心课程。通过该课程的学习，学生需要理解软件测试的基本概念，熟练掌握各种软件测试技术，了解不同测试阶段的测试目标、测试方法和相关测试文档，掌握经典测试工具的使用。为了适应卓越计划的新要求并融合软件测试在工业界的最新发展，培养出符合企业实际需求的软件测试卓越工程师，课程亟须改变传统教学理念，即更新已有教学内容，补充新的知识和技术，同时改进教学方法。笔者结合近些年的教学经历、工程实践和科学研究，分别从课堂教学内容、实验教学内容、创新实验项目建设等方面，论述卓越计划驱动下软件测试技术课程教学改革的措施和体会。

1 软件测试技术课程开设背景

当今软件行业面临复杂性、开放性、演化性等诸多挑战，而软件测试是保障软件质量的一种重要手段。统计数据表明，软件测试所需开销占软件开发总开销的40%，对于一些关键性软件，其占据比例甚至会提升到80%。近些年来，软件测试日益得到工业界、教育界和学术界的广泛关注。在工业界，软件企业对软件测试工作日益重视，因此设置了软件测试部门并招聘大量软件测试工程师，由于软件测试工作本身的高复杂性，使得目前测试人员的地位和待遇逐步提高；在教育界，国内外大学和社会培训机构陆续开设了软件测试技术相关课程，与软件测试相关的专业书籍也日渐增多，计算机技术与软件专业技术资格（水平）考试还增添了软件评测师中级资格；在学术界，软件测试是目前软件工程研究领域中的一个研究热点，每年均有大量的高质量研究，其中一些研究成果已经成功融入到企业的软件测试实践中。

基于上述背景，学院从2007年开始为全日制本科三年级学生开设了软件测试技术这门课程。该课程属于必修课，共48学时，其中理论3时，上机时。课程的先修课程包括离散数学、数据结构、高级编程语言、软件工程、编译原理等。截止到目前，学院先后有4名教师担任过该门课程的教学工作，约900名学生选修了这门课。通过与相关任课教师和听课学生的深入交流，我们发现该课程在卓越计划的新要求下仍存在如下问题：

（1）与软件工程专业的传统课程，如数据结构、操作系统和数据库技术相比，软件测试技术的教学内容并不成熟。该课程作为一门独立课程在国内院校中普遍开设较晚，早期一般作为软件工程课程的一部分进行讲解。通过分析市面上已经出版的一些经典教材，我们发现这些教材关注的知识点较为分散，授课老师普遍反映通过这些教材难以把握授课的重点和难点。同时，与企业目前的需求相比，这些知识点较为陈旧，甚至有的已经不能满足企业的实际需求。

（2）课程涉及的知识点多而繁杂且概念抽象，测试标准和规范类的教学内容偏多。由于听课学生欠缺软件测试经验，他们普遍认为课程内容抽象枯燥，学习兴趣不高，大部分学生存在听课时似懂非懂、考试时死记硬背、考完后全部忘记的现象。

（3）教师偏重理论知识讲解，缺乏实际案例。软件测试技术是一门实践性较强的课程，但目前的课程开设缺乏合理的实验项目设计，因此，老师可以由浅入深、循序渐进地培养并提高学生的软件测试技能，让学生通过实训验证在课堂学到的理论知识。

2 教学改革思路

按照卓越计划的指导思想、基本思路和基本要求，卓越计划驱动下软件测试技术课程的教学改革需要按企业测试部门的通用标准和行业标准来培养软件测试人才，同时，培养学生在完成软件测试任务时的工程能力和创新能力。基于课程的重要地位和特点，我们在教学改革时提出如下教学理念：

（1）教学内容要立足现代。立足现代是指对传统教学内容进行更新，即在原有的基本教学内容基础上，通过分析该领域在企业实践和学术研究上的最新进展，将一些操作性和实用性强的测试技术引入到教学中去。

（2）注重学生测试技能的培养。教学不仅要让学生知其然，而且还要让他们知其所以然，即不仅要掌握软件测试的基本概念和方法，而且在软件测试过程中，能够借助已有工具或自己开发工具来解决测试过程中出现的疑难问题，真正做到将所学知识灵活应用到实际软件测试工作中。

3 课堂教学内容改革

我们以上述教学理念为指导，分别从课堂教学内容、实验教学内容和创新实验项目建设上对课程教学进行改革，主要改革措施包括：

（1）教材选择上，力求教材更加贴近企业实际需求，同时在理论上具有一定的深度。在中国互动出版网、京东网、当当网和亚马逊网上输入关键词“软件测试”或“软件质量保障”，通过筛选，我们最终在一百多本教材中确定了两本英文教材和一本中文教材。两本英文教材分别是美国乔治·梅森大学Ammann教授等编写的《Introduction to Software Testing》和普渡大学Mathur教授编写的《Foundations of SoftwareTesting》。中文教材是同济大学朱少民教授编写的《软件测试方法和技术（第二版）》。前两本教材对软件测试的基本理论给出清晰的讲解，后一本教材则更加贴近企业的实际测试实践。

（2）以“基本概念一测试方法一测试流程一测试工具”为主线组织教学内容。针对卓越计划，我们对已有的教学内容进行重新设定，没定后的教学内容见表1。其中，基本概念模块是教学的核心，构成后续模块学习的基础，而软件测试技术（包括白盒测试技术和黑盒测试技术）模块、测试流程模块和测试工具模块则三者相互依赖。具体来讲，不同测试技术有不同的测试工具支撑，测试流程中的不同阶段借助不同的测试技术。例如，测试阶段以白盒测试技术为主，而集成测试和系统测试阶段则以黑盒测试技术为主。通过这条主线，可以将软件测试中的知识点有机融合并相互贯通。

（3）结合科研和企业实践，我们将软件测试技术的最新进展融入到教学内容中。在传统教学内容基础上，我们引入了很多具有较强使用价值的软件测试技术，具体包括：黑盒测试技术模块教学在正交实验法基础上引入组合测试（combinatorial testing）方法；在白盒测试技术模块教学中，不仅讲解了传统控制流覆盖准则（包括语句覆盖准则、判定覆盖准则、条件覆盖准则等），还深入介绍了数据流覆盖准则（包括all-defs覆盖准则、a11-uses覆盖准则和all-du-paths覆盖准则等）；在高级技术教学中，讲解了一种用于评估测试用例集测试充分性的变异测试（mutation testing）技术，并介绍了相关开源工具；在回归测试中，介绍了一系列测试用例维护技术，包括测试用例选择、测试用例集缩减和测试用例优先排序等。通过引入这些契合企业需求且可操作性强的新兴技术，学生提高了学习兴趣，丰富了自己的知识，锻炼了动手能力，有效满足了教学内容要立足现代的教学理念。

（4）提高学生的自学能力。在企业实践和学术研究的推动下，新的测试技术和理念不断被推出，所以提高学生的自学能力构成培养软件测试卓越工程师的一个重要目标。我们在日常授课时应注重学生自学能力的培养，对一些新的测试方法，要着重讲解方法的动机和核心思想；对方法的实现细节，则通过读书报告或创新实验项目方式，鼓励学生充分利用课余时间，自己查找相关文献予以完成。例如在讲解组合测试方法时，我们仅讲解了两种经典算法AETG和IPO的核心思想，对于具体的实现细节，我们鼓励学生用自己熟悉的编程语言去实现这两种算法。通过这种教学方式，可以培养良好的自学意识和高效的自学方法，最终有助于将学生培养为合格的软件测试卓越工程师。

4 实验教学内容改革

卓越计划对课程的实验教学环节提出了新的要求。如何在有限的实验时间内，最大限度地加深学生对软件测试基本理论的理解，为后续的专业学习和工作打好基础，是实验教学的首要任务。

在实验项目设计上有两种方案，一种方案是使用商用测试工具，另一种是使用基于开源软件的测试工具。对这两种方案进行可行性分析后，我们认为，如果采用商用测试工具，则存在投入高、适用面窄等问题；而采用开源软件，一方面投入较低，另一方面因开源软件可以获取源代码，将提高实验设计的灵活性。

在完成上述可行性分析后，我们基于Java编程语言，充分利用了一些经典开源软件，设计出如下三个难度适宜的实验项目。

1）单元测试工具JUnit的使用。

项目要求：掌握Eclipse、JUnit和Ant工具的使用。

项目内容：首先编码实现三角形类型判断程序，该程序的输入是三条边的大小，输出是三角形的类型（需要考虑等边三角形、等腰三角形、其他种类三角形、不能构成三角形等情况）；然后基于JUnit编写测试用例，在设计测试用例时需要采用等价类划分、边界值分析等测试技术；最后编写Ant脚本驱动测试用例并生成测试报告。

2）代码覆盖工具EclEmma的使用。

项目要求：掌握Eclipse、JUnit、Ant和EclEmma工具的使用。

项目内容：首先在Eclipse开发工具内安装EclEmma工具并完成配置工作，然后在项目1的基础上，通过使用EclEmma工具分析出测试用例集的条件覆盖情况。若出现测试用例尚未覆盖的条件，则通过修改被测程序或添加测试用例来确保所有条件均被充分覆盖到。

3）单元测试工具EasyMock的使用。

项目要求：掌握Eclipse、JUnit、EclEmma和EasyMock工具的使用。

项目内容：首先完成一个简单自动取款机（ATM）系统的设计和开发，该系统包括存款、取款、账户余额查询等功能；随后借助EasyMock工具来模拟ATM系统常用功能从而完成ATM系统的测试；最后借助EclEmma工具对测试用例的代码覆盖率进行分析。

上述二个实验项目在实际设定时，可以根据被测程序特征和学生自身技能特点，采用其他开源软件予以替代。例如，若测试cH编程语言实现的程序，可以考虑采用CPPUnit工具或gTest工具等。代码覆盖工具可以考虑gcov工具或Clover工具等。Mock工具可以考虑JMock等。

通过这三个实验项目的依次完成，逐渐增强了学生对软件测试知识的感性认识，使抽象枯燥的教学内容变得形象具体，从而培养了课程学习的兴趣，也使学生进一步加深了对Java编程语言的理解。

5 创新实验项目建设

在课程教学过程中，我们也加强了对优秀学生的培养。对于基础知识较为扎实、实践动手能力较强、创新思维和批判性思维较为活跃的学生，在完成课堂教学和实验教学阶段后，我们对他们增加了创新实践阶段。创新实践中的实验项目可以来自企业的实践需求，也可以来自教师平时的科研工作。例如，我们曾经组织2010级的若干拔尖学生组成一个小组，在有经验教师的指导下，通过研读相关论文，开发出一个错误定位（fault localization）工具。该工具以Tarantula方法为基础，通过搜集通过测试用例和未通过测试用例的语句覆盖信息，借助启发式公式将包含缺陷可能性高的语句用红色进行特别标记，实践表明该工具可以有效辅助程序员的软件调试工作。目前我们以该工具为基础，组织学生考虑更多的错误定位方法。

通过创新实验项目的建设，我们认为这些项目可以有效培养学生的实际动手能力和创新意识。在我们培养的学生中，有的学生在毕业后进入软件测试部门并得到用人单位的好评，有的学生在考取研究生之后选择了软件测试作为自己的研究方向。

测试计划篇3

5G预商用系统曝光

大唐电信集团（以下简称大唐）也不例外，在此次展会上，大唐展示了其5G端到端预商用系统，包括BBU+AAU、仪表、核心网（含MEC）、可信云服务器等。

一进到大唐展台门口就能看到其5G试验进展和计划的展示区。据介绍，大唐目前正积极展开5G外场试验，除了在怀柔建设了部分基站参加IMT-2020（5G）推进组组织的外场试验，还在昌平与中国移动联合开展5G试验。

试验进展上，大唐认为超密集组网能够满足热点高容量场景需求，并在室内室外做了超密集组网测试。根据测试结果显示，在室外建设8个小站，覆盖300平方米，容量密度可以超过10Tbps/km2，流量密度达到10Tbps/km2，并能提升边缘性能接近10倍。除此之外，大唐5G核心网也通过工信部测试。

另外，针对TDD/FDD融合组网趋势，大唐提出目标网络“All in One”方案，涵盖支持多层、多制式网络融合的设备及配套解决方案，全面支撑5G之前的各类网络融合，使网络能够承载更多类无线通信业务。

测试节奏紧密

同r，工作人员告诉《通信产业报》（网）记者，根据工信部和中国移动的5G研发计划，大唐也制定了5G试验计划。具体来说，希望在今年底达到7站规模试验，2018年达到20站规模试验，在2019年达到100站规模试验，在2020年形成能够完整支持5G三大应用场景的端到端商用产品。同时，大唐也展示了其5G预商用的BBU和RRU。

测试计划篇4

关键词：软件测试；测试管理；测试工具；Quality Center

软件开发团队的质量意识不断提升，团队对测试的重视与依赖程度也逐步提高。软件质量是各种特性的复杂组合，软件测试是软件质量保证的一个重要环节，通过软件测试来验证软件是否满足了需求，验证产品是否满足内部质量和外部质量。

复杂的项目和有限的工期，要求测试人员用更短的时间、更高的效率进行软件测试。测试人员组成的团队，需要有效而明确的管理。软件测试管理是一种活动，可以对各阶段的测试计划、测试用例、测试流程、测试文档等进行跟踪、管理并记录其结果。随着软件产品的迅速发展，软件复杂度逐渐提升，这给软件测试带来了更多挑战，测试的组织与执行成为软件工程的重要部分。

借助工具，可以使测试管理可视化，协助测试顺利进行。在IT企业的软件测试团队中，结合软件测试理论与方法，适当选择工具软件，可以促进企业工作规范化，提升团队工作效率，让多人协作完成复杂测试工作成为一项管理清晰、目标明确的系统工程。

1 Quality Center简介

Quality Center是HP（惠普）公司的软件测试管理产品，该产品前身是Mercury Iteractive（美科利）公司的Test Director，后被惠普公司收购，正式命名为HP Quality Center（后文简称QC）。QC是一个基于Web的测试管理工具，可以组织和管理应用程序测试流程的所有阶段，包括指定测试需求、计划测试、执行测试和跟踪缺陷。此外，通过Quality Center还可以创建报告和图来监控测试流程。

QC功能比较丰富，善用QC可以完成复杂的测试管理工作。相比其他过程管理与缺陷管理软件，QC是一个“重量级”的软件帮手。介于使用成本的限制，更适合于企业级应用。在系统测试的组织与管理方面，更显优势。

2 使用QC管理系统测试

QC软件模块较多，本文从最实用模块入手，主要包含版本管理、测试需求、测试版本管理、测试用例、测试执行与缺陷管理六个方面，完成整个测试过程的监控、管理与执行。下文将通过图文描述，展示具体的操作过程与方法。该测试方法的解决方案经过实际系统测试工作的检验，是一种有效的测试管理手段。

2.1 权限管理――自定义中的“组”

测试管理的主体是“测试人员”，测试人员在测试团队中有不同的分工，测试经理、测试用例设计人员、测试用例执行人员各司其职。根据项目复杂度的区别，人员配置会有不同。

测试经理的职责是制定测试计划和进度并及时反馈、建立与维护测试基线、团队成员能力了解与工作安排等[4]；测试用例设计人员应掌握项目的具体细节和操作流程，设计出合理用例。在实际工作中，存在着人员复用情况。管理与设计人员需要拥有操作QC的较高权限。测试执行人员根据设计的用例进行执行，对整个测试需求、用例的修改需要较为慎重，所拥有的权限应较低。可以根据实际项目的人员分工设施操作权限。

设置权限的方法如下，管理员账号登陆，点击右上方“工具”--“自定义”，出现权限管理界面。点击“组”，可以建立或修改权限分类。点击“项目用户”，可以添加、编辑和删除用户，并确定测试人员所属的组。

2.2 测试需求――QC中“需求”模块

项目需求不同于测试需求，不能够指导实际的测试工作。而如何将项目需求转化为测试需求，考验着每一个测试经理的工作能力。使用QC，可以清晰地梳理测试需求，是需求处理工作的得力助手。

QC支持以树状结构建立需求，并为每一个需求分配ID。实际测试过程中，可以将“需求”模块用作测试需求的梳理，结合整体需求文档建立所需要测试的需求。每个功能需求均须有测试需求对应，根据实际情况，功能需求可能需要对应多个测试需求来进行测试。

2.3 测试版本――QC中“版本”模块

测试工作非一蹴而就，测试需求与用例都可能存在多个版本。可以在QC的“版本”模块建立相应的测试版本。版本名可以根据项目具体需要确定。在版本的下一级建立循环以表明测试的轮次，可以在每一轮次中，记录本轮次的开始日期和结束日期。

这里提供一些实用技巧：

当系统测试只涉及一个基线时，可以使用“轮次_基线”来命名测试轮次当系统测试包含几个基线时，可以使用“轮次”作为测试轮次名，在详细信息中写明所有系统的基线。在“详细信息”中写明所有系统的基线。

可以在每一轮次中，记录本轮次的开始日期和结束日期。

建议使用“系统名_模块名_基线日期”来规范基线名称。

2.4 测试用例设计――QC中“测试计划”模块

用例编写是测试工作的核心任务之一。

测试计划中包含所编写的所用用例，并可以控制用例的版本。介于QC的测试实验室部分展示不方便，所以实际的执行结果，也会体现在测试计划之中。

2.4.1 从“需求”导出“测试计划”中的用例

“需求”模块可以直接转换为测试计划中的用例或者文件夹，右键点击要转换的需求，选择“转换为测试..”，之后会弹出对话框，可以根据需求粒度，来选择转换方式。可以将最底层子需求转换为设计步骤、测试或主题。当需求较复杂，未拆分到具体步骤时，建议选择的是“将底层的子要求转换为测试”。转换后，测试计划中，就会生成与需求对应的测试主题，根据具体需求可以增减主题，调整目录结构，设计具体的测试用例。

2.4.2 关联用例与需求

设计用例时，可以让用例与需求关联，这样可以清晰显示测试需求的覆盖度与完成度。在每个用例中，点击“需求覆盖”，然后点击“选择需求”，右侧会出现具体的需求，选择相应需求则可以将此需求关联到用例中。

2.4.3 用例设计

具体到每一个用例，可以分为“步骤名称”“描述”和“预期结果”三个部分。不同项目对此三个模块的应用方式不同。以某具体项目为例，定义用例编写规范如下：

步骤名称：以步骤编号开头，并简要描述步骤执行的意义

描述：此步骤执行的具体方法，根据此描述，可以指导测试的输入

预期结果：这部分填写实际测试结果，记录真实的测试情况

2.4.4 保存每一轮次的用例

QC的测试实验室模块对测试结果的保存有待优化，所以，在非自动化执行的测试中，建议项目选用测试计划模块保存用例结果。值得注意的是，如果选择在测试计划中呈现具体的执行结果，即将“预期结果”填写为实际执行结果时，一定要注意：对于多轮测试时要复制测试计划中的用例，并单独与轮次关联和命名。

2.4.5 测试执行――QC中“测试实验室”模块

QC设计测试实验室模块是希望用此模块来记录实际测试的执行情况。但因为展现不清晰，所以，实际测试结果记录在了测试计划的“预期结果”中。这部分内容可以根据项目具体调整。此外，测试实验室还有以下作用：管理每一轮测试所执行的用例，监控本轮次用例状态、测试进度，以及分派测试任务。

测试实验室可以根据测试计划，来建立测试用例集。通常，测试计划的树状结构和测试实验室的树状结构是一致的，测试计划中最底层文件夹，对应测试计划中的一个测试集。当然，也可以建立一个测试集，将测试计划中所有的用例放置在一个测试集中，并分配测试给相关测试人员。具体建立测试集的方法如下：根据测试建立测试文件夹，在测试文件夹下建立测试集，并使用“选择测试”将测试计划中的测试用例拖入相应测试集中，分配测试给相关测试人员。

在测试过程中根据测试用例的实际执行情况，由测试人员将测试用例的状态置为：

测试未执行，状态为“No Run”

测试正在执行，状态为“Not Completed”

测试执行完成并通过，状态为“Pass”

测试失败，状态为“Failed”

2.5 缺陷管理――QC中“缺陷”模块

使用工具管理缺陷，可以清晰地向开发人员反馈问题，记录问题沟通和修改状况，是测试历史过程的重要参考。

缺陷由测试人员根据实际情况填写，进入“缺陷”模块，点击“新建缺陷”，并根据提示填写“摘要”、“测试版本”、“测试轮次”、“测试日期”、“测试者”、“模块”、“缺陷状态”、“严重程度”、“原因分类”以及“描述”，并将缺陷与引发此缺陷的测试用例关联起来。在笔者工作过程中发现，缺陷的描述越清晰对开发人员定位问题越有帮助。

一个完整的缺陷描述应包含以下元素：

测试数据：运行该测试用例时建立的数据，如指令内容、输入字符串等。

测试步骤：执行该测试用例的操作过程。如果是前台程序，需要详细描述打开界面的title、录入的内容、点击的按钮等；如果是后台程序，需要详细描述测试环境（服务器、环境变量）运行的指令、SQL语句等。

期望结果：根据需求确定该测试用例的预期。

实际结果：测试用例执行后的真实结果 试用例执行后的真实结果，可以用文本形式或截图形式来展现。

3 结论

QC工具拥有自身的一些特点，会给测试工作带来一定影响。通过企业级项目测试的应用，发觉QC最大的优点是使得工作分配与测试用例完成情况可视化，并可以清晰地梳理测试用例等。而同样有QC带来的缺点，最显著的缺点是网页反应慢，操作耗时长，贴图不方便，内容导出困难等。

在笔者工作的测试团队中，同样一个项目的测试人员来自不同的部门，甚至所属不同城市。这时，测试的管理是非常棘手的问题。多人合作的项目测试，使用QC管理带来的好处完全弥补了它的不足。使用QC进行系统测试的维护和管理，能够达到降低沟通成本、明确任务划分、实时反馈测试问题的良好效果。

参考文献

[1]苏秦，何进，张涑贤.软件过程质量管理[M].北京：科学出版社，2008.

[2]吴慧韫，李卓群.基于H 模型的软件测试管理应用模型研究[J].计算机工程与设计.2006，27（11）：1993-1995.

[3]Black.R，龚波.软件测试过程管理[M].北京：及其工业出版社，2003.10：1-53.

[4]http：//

测试计划篇5

关键词：自动化测试；自动化测试管理平台

中图分类号：TN98 文献标识码：A文章编号：1009-3044(2011)28-7003-05

1 概述

目前中国大部分电信运营商都是以省为单位建设业务支撑系统（以下简称BSS系统），BSS系统包括客户关系管理子系统（简称CRM系统），计费账务子系统以及与其它系统的各种接口。省级运营商市场部门以及下属分公司市场部门为了市场的需要会不断提出各种业务需求，这就需要不断在BSS系统进行修改、增加功能，而BSS系统的支撑既要保障相关的功能修改或增加都必须是安全可靠，又要保障支撑的速度能跟上市场快速发展的需要。但由于软件开发往往采取模块化设计和增量集成的方式，测试版本的和系统上线时间非常有限，大量的变更问题需要验证，还需要进行大量回归测试，这些工作都存在大量的重复性劳动，容易让测试人产生疲惫感，要保证质量难度很大，有必要引入和运用自动化测试方法，将自动化测试和人工测试相结合，让测试人员更好的关注新功能或者改造的功能，做更有意义的测试，降低重复测试投入的成本，提前发现问题，保障系统稳定，提高用户感知。所以本文结合运营商的实际情况和自动化测试在业务支撑系统不断更新过程中的运用，对功能自动化测试在电信运营支撑系统中的引入和具体实施进行阐述。

2 电信行业自动化测试需求

作为运营商的核心生产系统之一，BSS系统的稳定性运行非常关键，其每次发生的重大故障都会给运营商带来严重的经济损失。而BSS系统的稳定运行，与应用开发/集成商提供的应用软件本身的稳定性密切相关。

BSS系统稳可以分为3个方面：系统功能稳定，不要动辄操作失败；系统运行效率好，实时性高；系统运行平稳，不要动辄重启服务器解决严重性能故障问题。而要做到这三方面，不对应用软件进行充分的测试，是无法保证的。

在BSS的实际建设和维护过程中，关于应用软件导致的系统不稳定（主机、存储等设备，数据库、中间件等系统软件导致的不稳定，本文不作讨论），可以大致归结为以下几种：

1）运营商的业务需求繁杂多变，开发周期短，难以进行充分的测试即被迫匆匆上线。每次系统升级前除了进行需求确认测试外，还应进行全量回归测试，以保障变更不会影响到其他功能，这在管理上是很难实现的！

2）新上线系统的BUG过多，功能不稳定。某个新系统上线后，才发现应用软件的BUG很多，营业员时不时的操作失败，而又不是每次都操作失败，让人难以琢磨该系统的“性格”。

3）新上线业务功能导致原有正常业务功能出错。这可以说是BSS系统维护中最常发生的不稳定问题，实际上就是新功能开发时，只对新功能进行了测试，而没有对原有功能的影响进行大量的测试，导致上线前没有发现问题，而仓促上线所致。

4）系统BUG修复后，因回归测试不全面，在上线时会产生新的BUG，得不偿失。

5）新上线业务越来越多，系统越来越慢，直至系统后台死机不处理。这属于典型的性能、压力的测试和分析不够，并进而对系统支撑业务能力估算不足所致

这5个问题，从另一个角度来看，可以理解为解决当前BSS应用软件测试问题的三个步骤。

首先必须加强上线前开发/集成商的软件测试，建立完整的测试流程和测试环境。

在此基础上，对每个新上线的业务功能，除了执行新功能本身的测试外，还通过建立丰富的测试用例库来确保执行严格的功能回归测试，才能确保新上线业务没有对原有正常业务功能产生不良影响;

同时，引入适当的测试工具软件。一方面，即使针对正在研发中的软件，由于在开发过程中不断引入的变更（发现错误进行的变更，业务需求变化引起的变更等），对于已经测试通过的功能，也需要在每次修改代码后进行回归测试，只有这样才能保证即使在代码不断修改的情况下，软件时相应的功能测试仍然是通过的。而这种回归测试的工作量非常之巨，以至于如果完全人工来做，是不可能实际做到的，自动化测试可以解决回归测试、重复测试的问题。这样才能解决以上问题中1、2、3和4；

最后，有了这些测试流程、测试环境、测试用例库，才可以进行严格的性能测试和分析，为新业务上线对系统荷载造成的影响进行科学客观的分析，从而准确地把握系统实际运行荷载的变化趋势，并进而尽早发现系统支撑能力的“临界点”。

因此，电信行业的业务运营支撑系统有必要启用自动化测试。

3 自动化测试的好处

自动化测试长久以来，一直是软件测试领域的热点，而今从事或者具有自动化测试技能的工程师更是就业市场非常需要的人才。这是因为自动化测试可以带来很多好处。

将精力投入更有意义的测试。自动化测试的引入会减轻重复的工作，使得测试人员有更多的时间去分析测试需求、设计详细的测试计划、测试用例、构建更复杂的测试。可以说这是自动化测试带给我们的最大好处之一。

回归测试，降低测试成本。这可能是自动化测试最主要的任务，特别是在程序修改比较频繁时，效果是非常明显的。由于回归测试的动作和用例是完全设计好的，测试期望的结果也是完全可以预料的，将回归测试自动运行，可以极大提高测试效率，缩短回归测试时间。

充分利用资源。可以在无人时定时执行自动化测试脚本，到时候直接看执行结果即可。人工测试和自动化测试相结合使用，可以在白天上班时间进行新功能的手工测试，原有功能的自动化测试可以在晚上或者周末执行，第二天就可以看到执行的结果。即避免了开发和测试之间的等待，又充分利用时间资源，提高测试效率。

测试具有一致性和可重复性。由于测试是自动执行的，每次测试的结果和执行的内容的一致性是可以得到保障的，从而达到测试的可重复的效果。

测试的复用性。由于自动测试通常采用脚本技术，这样就有可能只需要做少量的甚至不做修改，实现在不同的测试过程中使用相同的用例。

加大软件信任度。由于测试是自动执行的，所以不存在执行过程中的疏忽和错误，完全取决于测试的设计质量。一旦软件通过了强有力的自动测试后，软件的信任度也会增加。

公司实力的象征。自动化测试也从一定程度上体现出一个公司对测试质量的重视和实力，增强用户对软件的信任度。

自动化测试是对手工测试的一种补充，自动化测试不可能完全替代手工测试，因为很多数据的正确性、界面是否美观、业务逻辑的满足程度等都离不开测试人员的人工判断。而仅仅依赖手工测试，则会让测试过于低效，尤其是回归测试的重复工作量对测试人员造成了巨大的压力。自动化测试的意义不是为了取代人在手工测试中的位置，而是将人从重复繁琐的工作中解放出来，做更有价值的测试工作。

4 自动化测试框架

前面章节介绍了电信行业业务支撑系统对于自动化测试的需求，下面来介绍自动化测试在某省BSS系统支撑过程中的实际应用。

4.1 自动化测试框架整体介绍

建立自动化测试框架就是为了把测试数据与测试用例的分离、测试数据与业务流程的分离、测试用例与业务流程的分离，让自动化测试更容易维护、用例的重复利用率更高，最后再和需求管理、开发进度管理统一起来，整个质量控制体系就更加完善。

自动化测试框架包括：自动化测试管理和自动化测试工具。自动化测试管理包配置管理、组件管理、测试用例管理、测试计划管理、数据管理，自动化测试报告管理。在本自动化测试框架中使用的是SilkTest测试工具和自主配套研发的自动化测试管理工具平台。运用在实际的电信行业中的框架如图1所示。

5 自动化测试工具选用

自动化测试的工具很多，当前主流的自动化测试工具有Mercury Interactive Corporation、IBM Rational、Compuware Corporation、Segue Software等公司的系列产品。产品简介如下，这里选用的是Borland Software SilkTest（原SegueSoftware产品）

SilkTest 是面向 Web 应用、 Java 应用和传统的 C/S 应用，进行自动化的功能测试和回归测试的工具。它提供了用于测试的创建、定制的工作流设置、测试计划和管理、直接的数据库访问及校验等功能，使用户能够高效率地进行软件自动化测试。为提高测试效率， SilkTest 提供多种手段来提高测试的自动化程度，包括：从测试脚本的生成、测试数据的组织、测试过程的自动化、测试结果的分析等方面来进行规范。

SilkTest的脚本语言采用面向对象的编程语言 4Test 来编写灵活的测试脚本，并且SilkTest 有较好的跨平台性。

6 自动化测试管理平台

为了能够让自动化测试入门更简单，维护更加简单容易。我们自主研发了自动化测试管理平台，是基于自动测试工具的自动测试统一工作平台。自动化测试管理平台为B/S结构的系统包括组件管理、测试用例管理、测试计划管理，测试报告管理等。自动化测试工具和自动测试统平台的交互，能够很好的维护自动测试脚本及工程文件，并能以更加直观方式对自动测试结果进行展示。统一的自动化测试平台有如下特点:

通过自动测试平台对象管理功能，可以显示对象的增量修改功能；

SilkTest工具编写的脚本，可以导入到自动测试平台，并通过可视化界面对脚本进行维护；

自动测试平台可以对脚本进行有效的管理，保证脚本的唯一性；

自动测试平台可以对SilkTest整个工程进行管理，方便整个工程的读取；

自动测试平台可以将测试结果文件以pdf文件的形式导出，便于对测试结果的阅读和分析。

6.1 组件管理

组件管理包括：对象导入、对象维护、对象导出。

对象获取。要管理对象，就要先获取取对象。对象获取和整理是编写用例的前提。整理好对象会对在平台上编写用例有很大帮助。也会对接手维护的人员有很大帮助。对象是通过SilkTest工具来获取的，获取对象有两种途径：Window Declarations（获得整个页面的对象）和Window Identifiers（获取单个对象的属性）。Window Declarations获取的对象，结果如图2所示。

对象导入。通过自动化测试平台的导入对象功能，将SilkTest获取的对象存储到数据库中，以便后期维护和部署。页面如图3所示。

对象导出。通过自动化测试平台导出对象文件以便部署到服务器上。页面如图4所示。

对象维护。对导入的对象进行修改或者添加新的元素，页面如图5所示。

6.2 自动化测试用例管理

自动化测试用例的管理包括：测试用例添加，测试用例维护，测试用例导出。

用例添加。需要填写用例名称、用例说明、期望结果和用例类型。操作页面如图6所示。

用例维护。添加用例完成后，在用例维护中将SilkTest中的脚本写成操作步骤。此时页面右边的树就是我们导入的对象，点击对象就可以添加操作步骤。补换卡业务的测试步骤截图如图7所示。

用例导出。将用导出为SilkTest可执行的脚本文件，以后需要调试该用例时，直接通过自动测试管理平台导出用例执行，直接部署到自动化测试机上。操作页面如图8所示。

6.3 数据管理

在编写测试用例的过程中，一定会涉及到数据的交互，例如测试用例的输入数据从哪里获得，如何对输出结果进行验证等。

通常有两种方法：数据写到脚本里面；将数据与脚本分离，存放到excel或数据库中。我们现在选择的是将脚本和数据分离的方式，这样做有如下好处：

1）便于脚本的维护；

2）便于一个脚本支持多个用例，当编写一个新用例时，只需去配置与该用例相关的数据即可；

3）利于扩展和组织测试计划。

6.4 测试计划管理

测试计划管理包括：计划新增、计划维护和计划生成。

计划新增。自动化测试管理平台上有测试计划管理功能，查询出用例并放到新计划中。同时系统还提供了对测试计划维护的功能。如图9。

计划维护。自动化测试管理平台上有测试计划维护功能，即修改已经存在的计划里面包含的用例，可增加或者删除，操作页面如图10所示。

计划生成。由测试计划生成功能，生成脚本、生成计划。即可部署到自动化测试主机上执行。如图11。

6.5 自动化定时执行

编写一个bat文件，定时执行即可，如图12。

6.6 自动化测试报告管理

结果数据的抽取、汇总与展示。在测试执行过程中，通过特定的数据采集组件以及事件触发，获得我们关心的中间结果数据，并且将数据全部入库，根据客户需求，展现一份客户能够看得懂的报告。避免了工具原有报告难理解的问题。同时，记录下来的中间数据可以很好的体现出每个步骤地详细信息和过程时间，这样可以提供一段时间内的横向和纵向的对比，为系统特别是生产系统上的性能渐变提供有力的监控和依据。

自动化测试平台从数据库中捞出测试结果进行处理，根据需要生成用户容易看懂的PDF格式的自动化测试报告，如图13，图14所示。

7 自动化测试流程

有了上面自动化测试管理平台的支撑，自动测试流程中编写测试脚本、执行自动化测试的开展就会更加顺利。

表1为自动化测试流程角色表。自动化测试流程如图15所示。

1）制定测试计划。测试经理要制定测试计划，明确测试对象、测试目的、测试的项目内容、测试的方法、测试的进度要求，并确保测试所需的人力、硬件、数据等资源都准备充分。制定好测试计划后，分派给QA；

2）分析测试需求。QA根据测试计划和需求说明书，分析测试需求，设计测试需求树，以便用例设计时，能够覆盖所有的需求点；

3）设计测试用例。QA通过分析测试需求，设计足够多能够覆盖所有需求点的测试用例，形成专门的测试用例文档。并不是所有的测试用例都能用自动化来执行，所以需要将能够执行自动化测试的用例汇总成自动化测试用例；

4）搭建测试环境。自动化测试人员在用例设计工作开展的同时即可着手搭建测试环境。包括被测系统的部署、测试硬件的调用、测试工具的安装和设置、网络环境的布置等等；

5）编写测试脚本。自动化测试人员在自动化测试管理平台的支持下，编写自动化测试用例步骤，通过自动化测试工具编辑脚本插入检查点和异常判定反馈语句，调试脚本；

6）执行自动测试。自动化测试人员测试测试计划，验证软件功能，执行回归测试、流程测试等，以替代重复性的手工测试工作；

7）分析测试结果。自动化测试人员根据执行结果，分析测试通过与没通过的情况，通过自动化测试平台生产用户容易读懂的自动化测试报告；

8）记录测试问题。QA在测试脚本执行完毕之后，即可查看测试工具的测试报告，然后将没有通过的地方提取出来，描述成BUG，反馈给开发人员；

9）跟踪测试BUG。QA将测试中发现的BUG记录到BUG管理工具中去，以便定期跟踪处理。开发人员修改后，需要对此问题执行回归测试，即重复执行一次该问题对应的脚本，通过则关闭，否则继续修改。如果问题（BUG）的修改方案与客户达成了一致，但与原来的需求有所偏离，那么回归测试前，还需对脚本进行必要的修改和调试。

8 系统软硬件环境

系统的软硬件基本要求如表2所示。

9 结束语

电信行业业务支撑系统随着电信业务的发展和计算机技术的日新月异，系统功能不断扩充和更新。每次需求变更，系统缺陷，都会给系统带来大大小小的频繁更新。在需求管理、测试流程管理、测试环境这些都具备的条件下，要满足运营商给开发商预留的项目工期越来越紧，对软件的质量要求越来越高，对开发商软件正式上线前尽量减少程序BUG这些要求，这就必须要提高软件测试的质量和效率，在手工测试的基础上引入自动化测试，建立完善的自动化测试管理平台，统一管理测试用例库，让自动化测试完成大量的回归测试和重复性测试，让测试人员将精力投入更有意义的测试，制定更加合理的测试计划、设计更完善的测试用例，使得测试覆盖率更高，发现更多的问题，最终保障BSS系统的质量、降低业务支撑系统给运营商带来的风险，也将对电信运营商的业务支持起到非常积极的作用。

参考文献：

[1] 科兹纳.项目管理：计划、进度和控制的系统方法[M].10版.杨爱华,译.北京:电子工业出版社,2010:19-102.

[2] 柳胜.软件自动化测试框架设计与实践[M].北京:人民邮电出版社,2009.

[3] 陈能技.软件自动化测试成功之道[M].北京:人民邮电出版社,2010.

[4] Paul C.Jorgensen. 软件测试[M].韩柯,杜旭涛,译.北京:机械工业出版社,2003.

[5] 胡贝蒂.软件质量和软件测试[M].马博,赵云龙,译注.北京:清华大学出版社,2003.

[6] 布莱克.软件测试实践[M].郭耀,译.北京:清华大学出版社,2008.

[7] 朱少民.轻轻松松自动化测试[M].北京:电子工业出版社,2009.

[8] 蔡为东.赢在测试[M].北京:电子工业出版社,2010.

[9] 温伯格.完美软件[M].宋锐,译.北京:电子工业出版社,2009.

[10] 惠特克.探索式软件测试[M].方敏,张胜,钟颂东,等,译注.北京:清华大学出版社,2010.

[11] 曹向志.软件测试项目实战[M].北京:电子工业出版社,2010.

[12] Dennis M.Ahern.CMMI精粹[M].3版.北京:清华大学出版社,2009.

测试计划篇6

关键词：测试风险 风险识别 应对计划措施 风险控制。

一、前言

吉林省电子信息产品监督检验研究院/中国赛宝（吉林）实验室（）始建于1973年，隶属于吉林省工业和信息化厅，是非盈利性事业单位，业务领域涉及电子元器件及液晶、家电、视听、安防、计算机、通讯、医用电器设备、电池等电子应用产品及计算软件产品、网络系统、信息安全的质量监督、检验、鉴定和仲裁，其中，软件产品测试业务是我院重要的一项核心业务。我院软件产品测试业务于2004年通过了中国合格评定国家认可委员会（CNAS）的评审，是省内唯一授权的第三方软件评测机构，同时，也是我省双软认定工作中唯一指定进行软件产品登记测试的单位，现开展软件测试服务已经10余年，主要开展的项目有：软件产品的登记测试、鉴定测试、确认测试、性能测试、验收测试、定制性测试、白盒测试等。经过多年的持续发展，目前拥有一批高素质、高水平的专业测试人才队伍和先进的测试设备，优质、高效地完成了各种类型的软件产品测试项目，得到了广大客户的高度认可和好评。

二、背景和立意

软件测试风险管理在软件测试项目中的地位是不容忽视的，本文主要通过对软件测试项目在测试风险管理方面的相关内容的讨论，使读者从中会体会到软件测试风险管理对测试项目的重要性和给项目带来的帮助。

三、以“锅炉优化燃烧专家诊断系统”软件的测试风险管理为例，论述软件测试的风险管理。

1、系统描述：

“锅炉优化燃烧专家诊断系统”软件（以下简称本软件）应用于锅炉设备燃烧情况的监测领域，通过温度场范围、烟气场范围、计算诊断结果范围等初始参数设置，模拟量量程、一次风差量程等串口设置，及开始设置、保存数据等模块，实现了锅炉内部温度场及烟气场的情况推算及结果显示等功能。对本软件测试的要求是在20个工作日内完成本项测试任务，在最后回归测试时的结果需达到预期要求。

2、测试类型：功能测试

功能测试是黑盒测试，是对软件产品的各项功能进行验证的测试，注重于测试软件的功能性需求。

3、编制测试风险管理计划

在测试的初期，我们会编制测试风险管理计划，主要描述如何在对本软件的测试中处理和执行风险管理活动在责任、资源、时间等方面的安排。我们全面考虑了风险对测试的影响，制定了充分的测试风险管理计划。其中，我们详细编制了单个测试风险管理计划和综合测试风险管理计划，为后续实施的测试风险管理做好了准备，并形成了依据。

4、测试风险识别及测试风险分析

本软件测试之前，我们以会议讨论的形式，根据以往的经验，列出检查项目列表，并进行分解，通过假定分析，最后研究、识别、确定了影响测试计划实施的因素。

我们还对预测的测试风险进行了分析，确定测试风险对测试的影响程度及发生几率，并对风险进行量化、选择、排序，确定哪些风险是可以接受的，哪些风险是必须要应对的，哪些风险是可以忽略的。进行测试风险管理应该把主要精力集中在那些概率高、影响力大的风险上。

经过测试风险识别及风险分析，确定测试过程中我们主要关注的可能存在的对测试影响程度大的主要风险，如下：

（1）由于本软件是针对锅炉设备燃烧情况的监测领域的软件，需要测试人员对锅炉设备燃烧情况的监测领域相关知识有所了解，故测试人员对锅炉设备燃烧情况的监测领域了解不足或不了解，导致测试人员对被测系统的业务流程不熟悉，对需求的理解上把握不准、理解不透彻、理解错误等，对测试形成风险。

（2）测试人员出具软件测试问题报告单后，与企业开发人员交流时，开发人员对发现的问题理解程度不佳，导致对测试问题的修改不满足要求，或由于企业原因，企业再次报送相关修改结果速度过慢。

（3）测试人员实施测试时的测试方法有错误或缺失，导致对功能点没有采用正确的测试方法，或某些测试方法被忽视，如边界测试等，导致测试不充分。

（4）测试环境出现故障，给测试带来的影响。

5、测试风险应对计划措施

对已识别的主要风险制定的对应应对计划措施，如下：

（1）请企业相关人员培训测试人员学习锅炉设备燃烧情况的监测领域的相关知识，测试人员也要通过网络和书籍多查找锅炉设备燃烧情况的监测领域相关资料，做好测试前了解行业知识的准备。

（2）加强对测试人员的沟通能力和服务意思的培训，保证测试人员能详细、认真、准确的讲解测试问题报告单中体现的bug，使得企业软件开发人员能明白测试人员的讲解，并确认软件中存在的bug，及时快速的修复bug，且在与企业人员沟通中，强调测试进度及修改速度的重要性，督促企业人员尽快再次报送相关修改结果，保证测试按测试计划完成。

（3）加强对测试人员测试方法相关知识的培训，要求测试人员主动翻阅历史测试经验的积累记录，充实经验方面的不足，并向有经验的人员请教。

（4）严格按照软件文档的要求搭建测试环境，尽量避免测试环境出现故障，安排1名维护人员（兼职），当测试环境出现故障时，尽快安排维护人员整修、排除故障，尽量减小对测试进度的影响。

6、测试风险控制及实际测试情况

在进行测试的过程中，我们会对已识别出的测试风险的状态进行跟踪，监控测试风险的发生，做好对测试风险的监督控制，及时应对已发生的测试风险，并深入分析，继续识别新出现的测试风险，复审测试风险应对计划措施的执行情况和效果，根据实际情况修改测试风险应对计划措施，对新识别的测试风险，制定新的测试风险应对计划措施。

在实际测试时，我们对已出现的测试风险按照测试风险应对计划措施做好了相应的应对措施，效果十分明显，有效的避免了测试风险对测试的影响或把测试风险的影响降到了最低，但还是由于企业原因，企业再次报送相关修改结果过慢，影响了测试进度，我们对晚报送的修改结果进行了加班测试、并添加测试人员的应对措施，虽然根据测试计划规定，实施测试的时间延期了1天，但我们缩短了出具测试报告的时间，使得测试任务按时圆满的完成了，测试结果得到了客户的认可，而且，我们在测试的过程中给企业提出了许多规范、改善、优化企业软件开发或维护方面的建议，企业人员对我们的建议予以接受，同时，企业对我们的服务态度及服务质量给予了高度的评价和赞扬，肯定了我们各方面的服务。

四、总结

通过对“锅炉优化燃烧专家诊断系统”软件的测试风险管理案例的讨论，论述了怎样进行软件测试的风险管理，总结了本人对软件测试风险管理的认识和积累的经验，希望能通过本文使读者有所收获。

对软件测试管理方面的研究，我们还要继续努力，不断加强测试管理方面的知识积累及探索，提高测试管理方面的能力和水平，使自己成为优秀的软件评测员及测试管理员。

参考文献：

[1]《软件测试方法和技术》作者：朱少民；出版日期：2005年7月；出版社：清华大学出版社

执行标准：

[1]《GB/T 17544-1998 信息技术 软件包 质量要求和测试》

[2]《GB/T 16260.1-2006 软件工程 产品质量 第1部分：质量模型》

[3]《GB/T 16260.2-2006 软件工程 产品质量 第2部分：外部度量》

测试计划篇7

1.

开发框架

开发的系统中所应用的技术都是基于JavaEE，技术成熟稳定又能保持先进性。采用B/S架构使系统能集中部署分布使用，有利于系统升级维护；采用MVC的开发模式并参考SOA体系架构进行功能设计，使得能快速扩展业务功能而不会影响现有系统功能的正常使用，可根据实际业务量进行部分功能扩容，在满足系统运行要求的同时实现成本最小化。系统采用分布式部署，系统功能隔离运行，保障系统整体运行的稳定性。

图1.开发框架与体系结构图

1.1.

web端技术栈

（1）前端采用elementUI/jquery/bootstrap/vue实现，前端和Controller交换数据基于json格式。

1.2

业务端技术栈

（1）

业务端基于springboot、springMVC、JPA、SpringData技术栈构建，对于复杂的系统则采用springCloud构建。

（2）

四层分隔：controller（Facade）/service/dao/entity,其中façade主要用于生成json，实现和前端的数据交换。

（2）命名：按照功能模块划分各层包名，各层一致。

2.

系统安全保障

2.1

访问安全性

权限管理是系统安全的重要方式，必须是合法的用户才可以访问系统（用户认证），且必须具有该资源的访问权限才可以访问该资源（授权）。

我们系统设计权限模型，标准权限数据模型包括

：用户、角色、权限（包括资源和权限）、用户角色关系、角色权限关系。权限分配：通过UI界面方便给用户分配权限，对上边权限模型进行增、删、改、查操作。

基于角色的权限控制策略根据角色判断是否有操作权限，因为角色的变化

性较高，如果角色修改需要修改控制代码。

而基于资源的权限控制：根据资源权限判断是否有操作权限，因为资源较为固定，如果角色修改或角色中权限修改不需要修改控制代码，使用此方法系统可维护性很强。建议使用。

2.2

数据安全性

可以从三个层面入手：操作系统；应用系统；数据库；比较常用的是应用系统和数据库层面的安全保障措施。

在操作系统层面通过防火墙的设置。如设置成端口8080只有自己的电脑能访问。应用系统层面通过登陆拦截，拦截访问请求的方式。密码不能是明文，必须加密；加密算法必须是不可逆的，不需要知道客户的密码。密码的加密算法{

MD5--不安全，可被破解。需要把MD5的32位字符串再次加密(次数只有你自己知道)，不容易破解；加密多次之后，登录时忘记密码，只能重置密码，它不会告诉你原密码，因为管理员也不知道。

3.

项目计划的编制和管理

本公司项目基于敏捷过程的方式组织，项目计划基于需求和团队反复讨论的过程。在开发系统时都经过了解需求，开需求分析会议，确定开发任务，推进开发进度，测试，试点，交付等开发步骤，其中具体内容有：

1，了解需求：跟客户沟通，充分了解对方的需求，然后对需求进行过滤，最后整体成需求文档

2，需求分析会议：也就是项目启动会议之后要做的事情，对拿来的需求进行讨论，怎么做满足需求。主要对需求进行全面的梳理，让开发，产品，项目都熟悉整个需求。

3，确定开发任务：根据敏捷开发法则，需求变成一个一个功能点之后就是安排开发任务了。根据团队现有的资源合理分配任务，和时间节点

4，

推进开发进度：在开发的实际过程中，注意节奏的把控，注重功能点完成的时间点。

5，

每一个功能点完成之后都会有测试工程师进行单元测试。

6，试点单位进行试用，然后解决问题。

7，交付

4.

项目进度保障体系

4.1制度保障

实行项目经理负责制，建立强有力的开发指挥机构和开发保障体系，投入能保证开发进度如期实现的足够的开发队伍，实行专业化开发。建立从项目经理到各开发人员的开发任务，全面、及时掌握并迅速、准确地处理开发过程中遇到的各种问题。对开发过程中遇到的需求变更进行协调管理，对重大关键问题超前研究，制定措施，及时调整开发的公共类保证开发过程的连续性和高效性。强化开发过程的时间点把控问题，对开发任务实行动态管理。保证在时间点内完成开发任务。实行内部经济承包责任制。使责任和效益挂钩，个人利益和完成工作量挂钩，做到多劳多得，调动开发团队、个人的积极性。编制科学合理的总体开发进度计划，运用专业管理软件，对开发计划进行动态控制；并在总计划的基础上分解明确的月及旬计划，项目经理抓住主要技术难点，严格按计划安排组织开发，重点抓好关键技术的开发。定期检查开发计划的执行情况，及时对开发进度计划进行调整；在开发过程中，根据开发进展和各种因素的变化情况，不断优化开发的方案，保证各开发有条不紊的执行。

4.2开发进度开发工期保证措施

任务分发将利用一流的开发策划、高效的组织、科学的领导和动态的控制，用一流的运作与协调、一流的技术框架与技术、一流的团队素质等来实现一流的管理，从而通过过程控制实现最终产品的精品，满足客户对工期、质量等各方面的要求。

完善的开发计划保证体系是保证项目工期的纲要，掌握开发管理主动权，全面而宏观的控制整个开发的过程，是保证开发进度的关键。通过完善的开发计划保证体系，采用先进的开发计划计算、设计软件，制定出科学合理的开发进度计划。

1．

编制三级网络计划

在开发过程中中我单位将分级编制网络计划来控制整个项目的开发。

（1）一级网路计划

根据项目总工期控制项目各阶段里程碑目标。

（2）二级网路计划

根据各阶段分项业务的工期目标控制分解成分部目标。

（3）三级网路计划

主要技术使用控制周计划和日计划。通过对关键技术开发编制标准业务，建立计划统计数据库，利用项目管理信息系统对工期进行全方位管理。

2.制定派生计划

根据总控工期、阶段工期和分项业务工作量制定出技术保障、商务合同、物资采购、设备定货、人力资源等派生计划，是进度管理的重要组成部分，按照最迟完成或最迟准备的插入时间原则，制定各类派生保障计划，作到各项工作有备而来，有章可循。

工期保证体系框图

技术保证体系

综合保证体系

组织保证体系

技术总监

开发组织设计

技术总监

开发人员

测试人员

试验室

项目经理

制

度

保

证

奖惩制度

岗位责任制

经济责任制

开发团队

单元测试

技术培训

测试用例

开发进度计划保证

月度计划

季度计划

年度计划

技术工作责任制

技术标准

设计文件

招标文件

技术规范

技术工作标准化

开发团队

实现工期目标

4.3施工进度三阶段控制措施

（一）开发进度“事前控制”

1.积极做好业务需求，业务流程等准备工作，为自己尽早投入开发创造好条件，把准备工作做细做充分，确保按时无障碍开发。

2.编制详细的开发进度计划，包括需求文档，业务分工计划，业务流程等。

3.关键技术或特殊技术编制相应的开发进度计划，制定相应的节点，编制节点控制计划。

4.编制开发节点实施细则，明确搭接和流水的节拍。

（二）开发进度“事中控制”

1.严格审核开发人员的进度计划、季度计划、月计划，并监督各人员按照已制定的开发进度计划进行开发。

2.在本项目开发期间，按开发进度需要，配备充足的开发人员，确保时间点的正常运行。

3.在开发期间，每周结束前，组织召开一次碰头会，协商解决当周开发过程中和第二周开发中将会发生的问题，应解决的问题决不拖延。

4.狠抓开发进度与质量，加强技术培训。只有在确保技术过关、质量的前提下才能求速度、讲进度、抓工期。

5.根据开发的实际情况，及时修改和调整开发进度，并定期向客户通报系统开发进展情况。

（三）施工进度“事后控制”

1.根据开发进度计划，及时组织测试人员通过事先编写的测试用例进行分项测试与系统测试。

2.定期整理有关开发进度的资料，汇总编目，建立相应的档案。

5.

项目质量保障体系

5.1过程中的保证

依据项目的软件特点、合作方的项目实施要求，采取需求分析，系统设计，软件项目计划，软件需求分析，软件模型设计，软件详细设计，单元测试设计，编写单元测试，系统培训，系统测试等一些列的措施在过程中保证项目的质量。

5.2技术方面的保证

公司研发人员均为国内高校分子计算机专业或招聘的高级技术人才，专业基础和工作经验扎实丰富，整个团队具有高级工程师、博士的人才搭配，具备强大的持续研发能力。

5.3软件质量管理责任分配

角色

职责

配置管理员

制定、创建和维护配置库，提供文档规范，并传达到各个部门。

QA（质量保证）

参与项目各个阶段的评审，进行过程评审和产品审计，检查文档和代码的规范执行情况

QC（质量控制）

软件测试是质量控制的主要手段，测试人员进行软件的测试设计和执行工作

5.4工作产品和活动

活动

责任人

工作产品

是否可裁剪

项目立项

项目经理

项目计划

否

配置管理员

配置管理计划

是

QA

质量保证计划

是

测试人员

系统测试计划

否

需求管理活动

项目经理

需求调研报告

是

需求规格说明书

否

用户、项目经理

用户确认书

是

QA

评审报告

是

设计过程、决策分析活动

设计组

概要设计说明书

否

界面设计图

是

详细设计说明书

是

项目经理

决策分析评议表

是

QA

评审报告

是

开发编码、集成过程活动

项目经理

版本记录

否

QA

评审报告

是

开发人员

程序代码

否

系统测试活动

测试人员

测试用例、测试报告

否

QA

评审报告

是

项目结项、交付与维护活动

项目经理

培训教材

是

用户手册

是

安装手册

是

项目总结报告

否

项目经理、客户

用户验收报告

是

QA

评审报告

是

项目跟踪与监控活动

项目经理

项目问题跟踪日志

是

QA

不符合项问题跟踪记录表

否

项目跟踪与监控活动检查单

是

风险管理活动

项目经理

风险管理列表

是

QA

风险管理活动检查单

是

配置管理活动

配置管理员

配置状态报告

是

变更请求审批表

是

变更跟踪记录表

是

QA

配置管理活动检查单

是

评审活动

项目成员

评审报告

否

QA

评审活动检查单

是

5.5评审

评审是以一种正式的形式进行，如有正式的、事先定义好的有关职责的各种角色，并遵循组织规定的流程。

对于任何工作产品的审计，都会组建与之对应的专门评审组，包括作者、主持人、记录员以及陪审员若干。评审组的成员可以包括PPQA、项目组成员，但不能有作者的直接领导或者管理者。

评审小组先召开一个预备，作者会针对工作产品向大家做个总体的介绍，例如讲解一下本工作产品的目标是什么，以及其相关的实现

细节、开发标准等。应该允许甚至鼓励评审组成员动手查看工作产品，或者查看开发过程中所用到的检查单。

评审小组的主持人负责确定什么时间开始真正的评审会议，在预备会和正式评审会议之间，评审小组成员对工作产品进行彻底检查，并依据相关标准和准则评审工作产品。

在预定时间，评审小组成员以会议形式聚在一起，依次对产品进行检查，主持人负责对整个会议的进展进行控制，记录员记录下这个过程。

在工作产品中发现的每一个缺陷都会被认真记录下来，并被适当分类。

会议结束后，负责人需要分析相关缺陷，找出产生此缺陷的原因并加以修正。

主持人应确保所有的缺陷都会得到解决和修正。如果过程需要加以变更的话，应将相关问题移交相关的质量保证人员。

阶段

评审内容

评审时机

参加人员

是否可裁剪

计划阶段

项目计划

项目启动会议

项目所有成员

否

配置管理计划

项目所有成员

是

质量保证计划

项目所有成员

是

系统测试计划

项目所有成员

否

需求阶段

需求调研报告

项目评审会议1

需求分析师、项目经理、系统架构师、设计组成员、QA

是

需求规格说明书

需求分析师、项目经理、系统架构师、设计组成员、QA

否

设计阶段

概要设计说明书

项目评审会议2

需求分析师、项目经理、系统架构师、设计组成员、QA

否

UI设计图

UI美工、需求分析师、项目经理、系统架构师、设计组成员、QA

是

详细设计说明书

需求分析师、项目经理、系统架构师、设计组成员、QA

是

决策分析评议表

需求分析师、项目经理、系统架构师、设计组成员、QA

是

编码阶段

代码检查（1）

项目评审会议3

开发组成员、项目经理、需求分析师、系统架构师、QA

否

代码检查（2）

开发组成员、项目经理、需求分析师、系统架构师、QA

否

测试阶段

系统测试用例

项目评审会议4

测试人员、项目经理、开发组成员、需求分析师、系统架构师、QA

否

系统测试报告（1）

测试人员、项目经理、开发组成员、需求分析师、系统架构师、QA

否

系统测试报告（2）

测试人员、项目经理、开发组成员、需求分析师、系统架构师、QA

否

阶段

用户手册

项目总结会议

项目所有成员

是

项目总结报告

项目所有成员

否

5.6质量保证（QA）

QA工作审计产品

文档

责任人

项目计划

项目经理

需求规格说明书

项目经理

概要设计说明书

项目经理

源代码

开发组

系统测试用例

测试组

系统测试报告

测试组

用户手册

项目经理

项目总结报告

项目经理

入最佳实践库的产品

项目经理

QA工作中需要审计的活动

活动

评审时机

项目立项

计划阶段

需求管理活动

需求阶段

设计过程活动

设计阶段

决策分析活动

设计阶段

开发编码活动

编码阶段

集成过程活动

编码阶段

系统测试活动

测试阶段

项目结项

阶段

交付与维护

阶段

项目跟踪与监控活动

每月一次

风险管理活动

每月一次

配置管理活动

每月一次

评审活动

每月一次

QA审计中的不符合项目问题

对QA审计过程中发现的不符合项问题要写入《不符合项跟踪记录表》，以邮件的方式发给问题的相关人员，做好和项目成员、项目经理、部门经理之间的沟通，问题的上报流程：项目组成员沟通解决——项目经理——部门经理——总经理。QA要对不符合项问题进行跟踪与监控，直到问题解决，QA验证并关闭不符合项。

6.

系统测试验收方案

系统测试验收主要包含以下四方面的工作内容，分别是验收测试、系统试运行、系统文档验收以及项目终验。

6.1.

验收测试

验收测试即对信息系统进行全面的测试，依照双方合同约定的系统环境，以确保系统的功能和技术设计满足建设方的功能需求和非功能需求，并能正常运行。验收测试阶段应包括编写验收测试用例，建立验收测试环境，全面执行验收测试，出具验收测试报告以及验收测试报告的签署。

6.2系统试运行

信息系统通过验收测试环节以后，可以开通系统试运行。系统试运行期间主要包括数据迁移、日常维护以及缺陷跟踪和修复等方面的工作内容。为了检验系统的试运行情况，甲方可将部分数据或配置信息加载到信息系统上进行正常操作。在试运行期间，甲乙双方可以进一步确定具体的工作内容并完成相应的交接工作。对于在试运行期间系统发生的问题，根据其性质判断是否是系统缺陷，如果是系统缺陷，应该及时更正系统的功能；如果不是系统自身缺陷，而是额外的信息系统新需求，此时可以遵循项目变更流程进行变更，也可以将其暂时搁置，作为后续升级项目工作内容的一部分。

6.3系统文档验收

系统经过验收测试后，系统的文档逐步、全面地移交给客户。客户按照合同或者项目工作说明书的规定，对所交付的文档加以检查和评价；对不清晰的地方可以提出修改要求，在最终交付系统前，系统的所有文档都需要验收合格并经双方签字认可。

6.4项目终验

在系统经过试运行以后的约定时间，双方启动项目的最终验收工作。 最终验收的工作包括双方对验收测试文件的认可和接受、双方对系统试运行期间的工作状况的认可和接受、双方对系统文档的认可和接受、双方对结束项目工作的认可和接受。 项目最终验收合格后，由双方的项目组撰写验收报告。

7.

技术服务与支撑

我公司在合同有效期内提供免费维护期和长期的技术服务，向用户用户相关技术人员免费提供原理和技术上的指导和咨询，使用户能正确熟练地使用本协议的软件开发及测试成果。

根据用户使用系统的相关部门人员现状，一旦系统安装调试完毕投入正常运行后，卓安公司在交付本系统的一段时间内，专门指派若干名专业工程师为用户使用部门进行指导培训和维护，直到用户安排的技术人员能完全接管本系统的操作管理为止。

7.1.

现场支持

系统在售后期间，提供7×24小时的技术支持服务。如系统出现故障，将保证30分钟远程响应；影响生产的故障4小时抵达现场，并派出专业工程师在8小时内排出故障；不影响生产的故障8小时内抵达现场，并派出专业工程师在2个工作日内排除故障。如在2个工作日内无法解决，将在2日内向用户方提出详细解决方案及日程安排，交给用户方确认。

7.2.

技术支持

长期电话技术咨询和技术服务和远程在线服务。用户可以随时拨打技术支持热线电话或通过远程协助进行有关技术咨询，专业技术人员会耐心解答用户的问题。免费提供需求预测、系统规划等支持。当用户需要对系统扩容、调整时，将免费协助用户准备预算、规范书、工程有关事项。

7.3.

常规维护

系统在售后期间，会安排工程师定期对系统进行运行检查。如有功能需求分析范围内的问题，及时进行修改；维护期后发现的在需求规格说明书范围内问题，同样及时进行修改。对用户提出的方便操作和易用等可用性方面的要求，尽可能满足用户要求，并保证在接到要求后两周内解决。用户提出性能要求，如属于软件编制因素导致性能较差，技术人员主动调整软件，以提高性能，保证在一个月内解决。

7.4.

变更管理

对系统的应用平台和开发、运行环境以及应用系统的变更和升级的详细资料第一时间提交用户。

8.

培训计划

8.1.1.

培训工作概述

用户软件系统项目建设完工后，为了使各个使用本系统的部门能熟练的操作系统，利用系统提供的功能来处理日常工作，本公司将对使用系统的相关部门员工进行一次全面的培训。

培训过程按系统使用部门划分，分别培训各部门使用的系统功能点及业务流程。另外为了用户管理需要，将重点培训2名系统管理员，培训系统管理相关功能。

8.1.2.

培训规范

由于培训过程涉及到时间、场地、人员等诸多不确定因素，本方案所提及项只作为参考大纲。实际培训安排因由主管部门统一规划，并下文到各系统使用部门。

培训的效果与参与人员的重视程度有很大的关系，客户各部门对参与人员要做好工作，引起重视。主管部门可以考虑是否需要在培训结束并且参与培训人员试用一段时间后，组织一次系统使用测验。

通过系统使用培训，达到以下目标：

Ø

使相关使用部门了解系统运作，熟悉系统功能。

Ø

使系统有效的推广到相关使用部门，让员工积极参与使用系统。

测试计划篇8

关键词 计算机；软件测试；管理应用；技术探讨

中图分类号：TP311 文献标识码：A 文章编号：1671-7597（2013）13-0092-01

计算机软件管理的规范性、严肃性、安全性、严谨性以及稳定性等功能已经逐步取代了传统的人工管理，虽然计算机软件管理可以为领导提供正确的决策、可靠的信息、完善的计划、可信的数据和量化的管理，但是由于它自身的知识密集性、知识高度性和逻辑复杂性，使得在运行时总会出现一些错误，而这些错误是不可避免的。所以，为了改变因为软件质量问题而出现错误，出现了软件测试。软件测试是指利用软件开发过程的程序、规格说明、内部结构来设计出的一种测试软件，也就是说软件测试既可以检验软件是否合格，还可以发现软件中出现的错误，是目前利用率最为广泛的发现软件错误的办法之一。

1 计算机软件测试

软件测试是指利用软件开发过程的程序、规格说明、内部结构来设计出的一种测试软件，这种软件可以及时发现程序出现的错误过程。

1.1 白盒测试和黑盒测试

白盒测试是通过程序内部的各种信息、逻辑结构来进行测试软件的选择或者设计，它可以测试出程序的所有路径和所有逻辑信息。白盒测试所具备的程序结构特性也称之为结构测试法。白盒测试一般应用于拥有独立路径的模块中，它可以对每个逻辑进行检查，并判断出是真是假，还可以对每个循环变量中终值、中间值以及初值进行检查，此外，白盒测试还可以对程序内部的结构、数据进行检查，从而得出是否有效。白盒测试主要用于检查程序中的不正确条件、书写错误、逻辑错误、印刷错误以及意外路径。

黑盒测试与白盒测试相比，黑盒测试不用考虑程序内部的特性和逻辑结构，它主要考虑程序的说明书、规格以及需求，如果出现程序功能与功能说明不相符时，证明软件出现错误。黑盒测试所具备的功能检查、要求检查特性也称之为功能测试法。黑盒测试一般应用于需要强调软件功能要求的计算机，对于强调程序内部的细节实现和结构内部的软件不适用，此外，黑盒测试对于终止错误、漏掉功能、初始化、不正确功能、接口错误、性能错误、数据结构错误以及外部数据库访问错误等错误，具有较强的检测性。

1.2 程序错误分类

程序错误分类主要应用于软件测观点、系统错误、代码错误、加工错误、功能错误以及数据错误等错误的检测，其中，系统错误主要表现为系统与资源管理错误、硬件机构内部的不清晰、硬件结构相关联的软件错误、通信手段错误、硬件结构内部的不合理、操作系统相关联的错误以及程序和程序间的联系；代码错误表现为指令不正确、语法错误、理解错误、语句错误以及印刷错误；加工错误表现为初始化错误、逻辑静态错误、算数错误、控制错误、操作错误以及顺序错误；功能错误表现为自身矛盾、用户要求、程序功能、实现功能和说明书不一样，以及测试员的缺乏了解、不正确的需求说明、测试标准错误；数据错误表现为属性错误、元素数据错误、数据结构内容、静态数据错误以及动态数据错误。

2 计算机管理应用测试

2.1 软件测试流程

软件进行测试主要有计划、设计、执行和验证四大步骤，这种测试流程不仅可以测试系统、单元以及集成，还可以单个进行测试、描述。测试计划是指针对资源、时间进行产生、测试、预先的指导性规划和测试所设计的计划文档，它主要是进行软件的测试，需要一个可以执行预先分析的整体计划，对于可执行的单元与集成测试、系统测试项目，则需要进行单独的规划设计。假设在进行软件验证时，如果发生了影响软件的速度和测试进度的情况，就需要对正在进行的软件测试作出调整和计划；测试设计需要注意的是进行严格的设计文档，通过软件的测试流程可以知道，系统测试是根据软件所配备的规格需求说明书作为基础而进行的，所以集成测试的设计过程中，应根据软件配备说明书进行操作，但单元测试设计是以软件配备详细说明书为基础；测试执行需要注意的是进行软件测试的设计，如果在测试中出现文档测试不充分问题，需要以新设计测试软件来弥补旧测试软件，并且在测试执行完成以后，将软件补充或者归入测试之中。测试验证过程中，若出现错误问题就要对其进行重新的修正，由测试人员进行开发人员修改软件的验证。

2.2 软件测试的注意事项

黑盒测试一般应用于系统测试中，所以系统测试需要有测试人员独立完成，测试系统时需要注意压力测试在各种情况问题和操作模式问题，其中压力测试问题就是发生异常情况，针对边界状况进行系统的测试，即测试重点放在了系统测试层面之上。然而，在此过程中需要考虑压力状况，然后再进行具体的测试；操作模式问题主要表现在设计软件上的低耦合以及高内聚方向进行，但是这种配置在软件功能上总会出现操作限制问题，而这种限制是我们不可避免的，所以就算检测的软件全部合格，还是会出现在一定模式下的操作顺序发生问题，这样限制操作顺序我们称之为操作模式。一般而言，白盒测试在单元测试中应用通常以代码来完成。在单元测试过程中，需达到语句覆盖百分之百；若函数没有更多的条件用以判断，那么可要求条件达到百分之百。

参考文献

[1]严少清，陈革，万年红.软件测试自动化管理系统的设计与实现[J].计算机工程，2009（13）：152-154.

[2]柳永坡，邹磊，金茂忠，刘雪梅.软件测试领域知识管理技术的研究与应用[J].计算机集成制遣系统，2010（11）：105-110.

测试计划篇9

需求分析由产品人员制定，他们要做的不是一份简单的文档，而是细化每一个功能的细节，每一个按钮的位置，对于稍大或复杂一点的需求都进行建模。

需求评审

需求评审（产品需求人员、开发人员、测试人员、设计人员）前期需求进入会大大增加测试人员对产品的功能的整体把握，现在测试人员担任的是测试和产品体验员的身份。测试人员提出需求，开发人员考虑功能实现的方案与可行性、当然开发负责也是要参与的。测试人员主要是对需求的理解提出疑问，以便才能根据需求写用例。QA人员是最终对软件质量进行验证的人，所以也需求了解需求。

开发人员编写排期

开发人员需求根据需求功能点进行排期。然后将开计划转交给测试人员。

测试计划排期

测试人员根据开发计划，对测试具体测试时间，也就是开发功能完成后的时间，进行几轮测试等。然后，把项目的开发与测试计划发送给各部门负责人及参与项目的所有人员。

编写测试用例

根据详细的需求分档，开始进行用例的编写。

【开发人员写开发计划--》测试人员编写测试计划--》邮件通知所有人员及部门负责人。】

用例评审

在用例进行评审之间，先以邮件形式将用例发送给相关人员，以便他们事先了解用例对哪些功能进行验证以及验证的细节。

然后，测试人员组进行用例评审，开发人员对用例与实际功能不符合有哪些，产品人员对会通过用例对功能的具体实现进行把握等等。

【测试用例评审（产品需求人员、开发人员、测试人员、QA人员）】

提交基线

开发人员完成所有功能后，会对自己的功能进行一个自测。自测完成后提交测试人员进行基线。【开发代码及自测---》编写测试用例】

具体测试流程

开发人员对于基到测试线的功能进行测试，发现的问题通过缺陷管理工具进行反馈，开发人员对问题进行修复，然后，准备第二轮测试。

测试人员完成第一轮测试后，需要写测试结论，发到相关人员。然后对基线后的第二轮进行测试，第二轮会对第一轮中发现的问题进行重点回归。

测试具体流程如下：

1

、测试和发现软件中存在的软件缺陷

使用各种测试技术和方法来测试和发现软件中存在的软件缺陷。测试技术主要分为黑盒测试和白盒测试两大类。

其中黑盒测试技术主要有等价类划分法、边界值法、因果图法、状态图法、测试大纲法以及各类典型的软件故障模型等;白盒测试的主要技术有语句覆盖、分支覆盖、判定覆盖、基本路径覆盖等;

2

、测试工作需要贯穿整个软件开发生命周期

完整的软件测试工作包括单元测试、集成测试、确认测试和系统测试工作。

单元测试工作主要在编码阶段完成，由开发人员和软件测试工程师共同完成，其主要依据是详细测试。集成测试的主要工作测试软件模块之间的接口是否正确实现，基本依据是软件体系结构设计。确认测试和系统测试是在软件开发完成后，验证软件的功能与需求的一致性、验证软件在相应的硬件条件下的系统功能是否满足用户需求，其主要依据是用户需求。

3

、缺陷报告编写及提交

测试人员将发现的缺陷编写成正式的缺陷报告，提交给开发人员进行缺陷的确认和修复。缺陷报告编写最主要的要求是保证缺陷的重现。要求测试人员具有很好的文字表达能力和语言组织能力。

4、软件质量分析

测试人员需要分析软件质量。

在测试完成后，测试人员需要根据测试结果来分析软件质量，包括缺陷率、缺陷分布、缺陷修复趋势等。给出软件各种质量特性包括有功能性、可靠性、易用性、安全性、时间与资源特性等的具体度量。最后给出一个软件是否可以或提交用户使用的结论。

5、测试计划制定

测试过程中，为了更好地组织与实施测试工作，测试负责人需要制定测试计划，包括有测试资源、测试进度、测试策略、测试方法、测试工具、测试风险等。

6、测试用例报告形成

测试人员为了更好更有效地进行测试，保证测试工作质量，需要在执行测试工作之前首先需要设计测试用例，形成测试用例报告。设计测试用例是保证测试质量的核心工作，很多测试技术都可以用来指导设计用例。

7

、自动化测试工具引进

为了提高工作效率或提高测试水平，测试工作需要引进自动化测试工具，测试人员需要学会使用自动化测试工具，编写测试脚本，进行性能测试等。

8

、测试水平提高

测试负责人在测试工作中，还需要根据实际情况不断改进测试过程，提高测试水平，进行测试队伍的建设等。

缺陷管理

使用bug缺陷管理工具，redmine项目管理，通过测试对发现的问题提交到redmine上并进行跟踪。视情况可以将比较简单的bug直接对接开发人员，通过当面交流的方式阐明简单bug的问题所在，提高开发人员修复bug的效率，同时要在redmine上做好bug记录，测试新的版本的时候复测问题。

测试管理

经过两到三轮或四轮的测试后，直到没发现新的问题，或暂时无法解决，或不紧急的问题。通过上级确认，可以通过。编写测试报告与验收方案。

验收方案是交由QA进行验证的。在现公司的流程中是将测试与QA分开的，测试人员重点关注的是功能是否可以正常运行。QA关注的是整个流程的质量以及最终用户的质量。有些公司QA与测试是不区分的，但这对测试的要求会更高，除了关心功能，还需要关心整体流程与质量。

测试计划篇10

为了提高程序设计语言在线评测系统的软件质量，确保该系统最终能够满足教师和学生的各种功能需求。本文通过结合程序设计语言在线评测系统中几个功能模块的实例，详细介绍几种黑盒测试技术在程序设计语言在线评测系统中测试用例的设计和应用。

系统功能简介

程序设计语言在线测评系统是一款以减少计算机程序语言教师作业批改工作量和提高学生学习程序语言效率的软件。整个系统的设计采用B/S模式以及MVC三层架构，主要包含以下五大功能模块：第一、用户注册与登录模块。第二、学生在线答题与成绩查询模块。第三、程序在线评测模块。第四、教师试题录入与编辑模块。第五、在线疑难问题讨论模块。

黑盒测试技术

黑盒测试技术是软件测试的主要方法之一。由于在黑盒测试中，主要关注于被测软件的功能实现而不是逻辑，又叫做功能测试。测试人员不需要了解软件的具体实现方法，不需要具备应用程序代码和编程语言等专业知识，只需要了解程序的输入、输出和系统的功能，从用户角度对软件界面、功能和外部结构进行测试。执行黑盒测试的人员通常是不同于系统开发人员的第三方，他们可以依据系统的用户需求文档，在软件实现工作的同时，并行开展测试用例的开发工作，最终达到缩短整个项目的开发周期的目的。

常见的黑盒测试技术主要包括有等价类划分测试法、边界值分析测试法、特殊值分析测试法、错误猜测测试法、因果图测试法和基于判定表的测试方法等等。

黑盒测试技术在程序设计语言在线评测系统中的典型应用

1.等价类划分测试法

等价类划分测试法主要是指，把输入的数据的可能值按照一定的标准划分为若干个具有一定共性的等价类，而只需要在每个等价类之中抽取一个有代表性的元素来构造测试用例，就是说只要该等价类中的一个测试用例测试结果正确，就代表该类中所有测试用例的测试结果都正确。这种测试方法的目的一是大大降低测试用例直接的冗余，二是期望进行某种意义上完备的测试。

对于等价类的划分一般又分为有效等价类和无效等价类。有效等价类主要是指那些符合系统的需求文档的正确、合理的“有效”输入值；而无效等价类则是指那些不符合系统的需求文档的错误、不合理的“无效”输入值。在设计无效等价类测试用例的时候，为了避免遗漏掉某一类的错误，通常要从多个不同的角度设置多个无效等价类，并为每类设计测试用例。

在程序设计语言在线评测系统的登录模块中，根据系统的需求文档，使用该系统的登录人员主要有三类：学生、教师和管理员。各类用户凭借自己的用户名和密码进行登录。以学生用户为例，学生以学号作为用户名进行登录，学号通常是以“入学年份+班号+人头号”的数字形式出现，假设该学校第一届学生入学是1994年，班号以最多1 000个班为界，从000到999用三位数字表示，再假设每班人数不超过70人，用数字00到69进行表示。对于学生用户登录的等价类划分如表1，设计覆盖（1.1）到（1.9）的9个等价类的测试用例，具体的测试用例见表2。

2.边界值分析测试法

边界值分析测试法可以看成是对等价类划分测试法的一个补充。大量的测试经验表明，程序的错误常常出现在输入变量的极值附近。因此，在设计边界值测试用例的时候，不同于在等价类划分测试法中取每一个等价类的典型输入值，而是取每一个等价类中，刚好等于、略微小于或是略微大于边界值的输入值作为测试数据。

仍然以程序设计语言在线评测系统中登录模块的学生用户登录功能为例，补充之前的表2，设计测试用例如表3。

3.错误猜测测试法

错误猜测测试法是一种依据测试人员的经验和直觉，对程序中可能会出现错误的地方进行有针对性测试的辅助测试手段。这种方法主要是通过对程序中有可能出现错误的地方进行“猜测”，并将所有的错误类型列出清单，再根据清单逐一设计测试用例的方法来实现的。